| Internet-Draft | PPCA | September 2023 |
| Davis, et al. | Expires 1 April 2024 | [Page] |
This draft presents an additional architectural option for control of packet over optical networks by extending and complementing the IETF draft-poidt-ccamp-actn-poi-pluggable and by introducing an additional approach for control of optical plugs in packet devices. It provides the direct read/write access of coherent plugs to the optical controller, thereby allowing the end-to-end optical service management. The approach, introduced in this draft, can be further generalized to support other uses cases.¶
The architectural option for control of packet over optical networks, introduced by this draft, also provides a clear separation between control of packet functions and control of optical functions. The packet and optical controls are partitioned so that the functions specializing in control of the optical capabilities can control corresponding functions in packet devices, optical devices or both without interfering with packet control functions.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://example.com/LATEST. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-davis-ccamp-photonic-plug-control-arch/.¶
Discussion of this document takes place on the WG Working Group mailing list (mailto:WG@example.com), which is archived at https://example.com/WG.¶
Source for this draft and an issue tracker can be found at https://github.com/USER/REPO.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 1 April 2024.¶
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT" "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in th document are to be interpreted as described in [RFC2119].¶
The following terms abbreviations are used in this document:¶
Packet traffic has been transferred over optical networks for many years blending the benefits of optical transmission and switching with packet switching. Optical systems have been separated from packet systems, both of which have had specific dedicated devices. In many existing network deployments, the packet and the optical networks are engineered, operated and controlled independently. The operation of these packet and optical networks is often siloed which results in non-optimal and inefficient networking. Both packet and optical systems have had relatively independent evolution. Optical systems have been developed with increasing capacity especially with the emergence of coherent optical techniques.¶
Optical component design has continued to improve density to the point where a whole coherent optical terminal system that use to require many circuit packs can now fit onto a single small form factor "coherent plug". Placing coherent plugs in a device with packet functions can reduce network cost, power consumption and footprint as well as improve data transfer rates, reduce latency and expand capacity (although in some cases, other engineering and deployment considerations still lead to separate packet and optical solutions).¶
Optical transmission/switching is analogue and requires complex and holistic control. Consequently, coordination of control of the coherent plugs (in a device with packet functions) with the control of the rest of the optical network is highly desirable as this best enables robust network functionality and simplifies network operations.¶
The combination of these above trends along with the desire to select best in breed components has led to the emergence of open optical plugs that offer a standard bus for traffic and that use CMIS [OIF CMIS] for control. These plugs are such that a plug from vendor X can be installed in vendor Y's device with packet functions.¶
Whilst basic applications can be handled by standardized modes of transmission such as ZR [OIF-400ZR], to achieve optimum performance vendor proprietary modes are necessary. For many applications especially those in the core of the network where longer haul routes are prevalent, amplification and photonic switching is necessary. This leads to networks that utilise optical plugs in devices with packet functions interconnected to a ROADM mesh often including regenerators (where optical-electrical-optical conversion is necessary).¶
Although in ZR applications it is possible to interoperate between plugs from different vendors, in the more strenuous core environments each optical path is terminated at each end using a plug from the same vendor. The optical plug encapsulates significant sophisticated photonic functions which often require specialist adjustment.¶
As noted, the complex analogue nature of optical technology leads to the need for holistic control end to end (including the optical capabilities of the pluggables). The control functionality can be considered independent of specific functional deployment. However, it is important that any deployment approach does not significantly fragment the optical control. Several deployment approaches are examined:¶
Likewise, the network capability can be considered in terms of functions independent of specific deployment. Control of a function including explosure of parameters etc. should be the same regardless of the hardware configuration of the function deployment. An important consideration is the approach to accessing the functionality. This is considered in detail.¶
Since the complete automation and control of packet and transport networks is vital for meeting emerging demand for high-bandwidth use cases, different Standards Development Organizations (SDO) proposed several approaches on how to control and manage the converged packet over optical networks where there are transponders/muxponders in the network or where there are coherent plugs in packet devices. For example, as proposed by [MANTRA-whitepaper-IPoWDM-convergent-SDN-architecture] an architecture analysis has already been carried out by the MANTRA sub-group in the OOPT / TIP group (Open Optical & Packet Transport / Telecom Infra Project). Also IETF [draft-ietf-teas-actn-poi-applicability] considers the applicability of IETF Abstraction and Control of TE Networks (ACTN) architecture to Packet Optical Integration (POI) in the context of IP/MPLS and optical internetworking.¶
Two architectural options to plug control are explored in [draft-poidt-ccamp-actn-poi-pluggable] which extends [draft-ietf-teas-actn-poi-applicability] to the use cases where the DWDM optical coherent plugs are equipped in the packet device. To manage both optical and packet networks along with coherent plugs, section 2 of draft [draft-poidt-ccamp-actn-poi-pluggable] has proposed two architectural options, namely:¶
Figure 1 shows option-1 where the packet devices allow the dual management, i.e., it allows both the packet controller and the optical controller have access to the coherent plugs on the packet devices. The interface between optical controller and packet devices are read-only and allows the following tasks:¶
All configuration operations on the coherent plugs are carried out by the packet controller.¶
-------------------
| Higher layer |
| Controller |
| (e.g. MDSC) |
-------------------
^ ^
| |
|--------| |-------| NBI
v v
--------------- ---------------
| Packet | | Optical |
| Controller | | Controller |
|(e.g. P-PNC) | |(e.g. O-PNC) |
--------------- ---------------
^ ^ ^
(R/W for plug | (RO for plug) | |
and packet) | |----------------| | SBI
v | v
/----------\ /----------\
/ Packet \ / \
/ Devices \ / Optical \
\ + / \ Devices /
\ Plugs / \ /
\----------/ \----------/
Legend:
Optical Devices: ROADM + Amplifier + Regen
Packet Devices: Routers
RO: Read-Only, interface from packet device is RO for plugs
In option-2 shown in Figure 2, the packet controller is the only control component which has access to the packet device, including the pluggables. The packet controller implements all management capabilities. The packet controller is in charge of the entire management life cycle of the pluggables including discovery, configuration/adjustment, monitoring performances and faults (via the asynchronous notifications coming for the pluggable). The information collected needs to be exposed to the optical controller via the packet controller NBI and higher layer controller. The information includes physical impairment data needed for the computation and validation of the optical channel.¶
For both option-1 and 2, the higher layer controller MDSC is required not only to coordinate the end-to-end optical service configuration, but to provides the multi-layer coordination between IP and optical layers.¶
-------------------
| Higher layer |
| Controller |
| (e.g. MDSC) |
-------------------
^ ^
| |
|--------| |-------| NBI
v v
--------------- ---------------
| Packet | | Optical |
| Controller | | Controller |
|(e.g. P-PNC) | |(e.g. O-PNC) |
--------------- ---------------
^ ^
(R/W for plug | |
and packet) | | SBI
v v
/----------\ /----------\
/ Packet \ / \
/ Devices \ / Optical \
\ + / \ Devices /
\ Plugs / \ /
\----------/ \----------/
Legend:
Optical Devices: ROADM + Amplifier + Regen
Packet Devices: Routers
This draft extends draft [draft-poidt-ccamp-actn-poi-pluggable] by providing an additional architectural option-3 to control the multi-layer packet optical network when optical coherent plugs are equipped in the packet device. This third option enables direct control of the coherent plug by the optical controller.¶
The upcoming sections introduce the additional architectural option-3 for control of the coherent plug, identifying appropriate interfaces and parameters to be manipulated. As part of this explanation the networking aspects of control are considered and some use cases exploring initial planning, commissioning, general operation, restoration and adjustment are developed.¶
The YANG models are out of scope of this draft.¶
As explained in Section 3, draft [draft-poidt-ccamp-actn-poi-pluggable] has proposed two architectural option-1 and option-2 to control both optical and packet networks along with coherent plug. This section explains an additional architectural option-3 shown in Figure 3 for control of the coherent plug, identifying appropriate interfaces and parameters to be manipulated. As part of this explanation the networking aspects of control are considered and some use cases exploring initial planning, commissioning, general operation, restoration and adjustment are developed.¶
In option-3 the packet device has two management interfaces (A) and (B). Management interface (A) allows the packet controller read/write access to the packet functions of the device and management interface (B) allows the optical controller read/write access to the coherent plug functions.¶
The packet device can realize the management interfaces (A) and (B) as a single physical interface or two separate interfaces. More details are provided in section 5.¶
Unlike option-1 and 2 Figure 1 and Figure 2 where the higher layer controller MDSC is mandatory, in option-3 Figure 3 the MDSC is not needed for provisioning of the end-to-end optical services, which simplifies the design of MDSC and minimize the information flow between various controller.¶
Having said that, option-3 can benefit from "higher layer controller" to provide various multi-layer packet over optical capabilities and operational benefits to operators such as multi-layer optimization, multi-layer assurance, multi-layer resiliency/protection/restoration multi-layer planning etc.¶
-------------------------
| Optional Higher layer |
| Controller |
| (e.g. MDSC) |
------------------------
^ ^
| |
|--------| |-------| NBI
v v
--------------- ---------------
| Packet | | Optical |
| Controller | | Controller |
|(e.g. P-PNC) | |(e.g. O-PNC) |
--------------- ---------------
^ ^ ^
(R/W for Packet) | (R/W for Plug) | |
| |----------------| |
| | | SBI
| | |
(A) v v (B) v (C)
/----------\ /----------\
/ Packet \ / \
/ Devices \ / Optical \
\ + / \ Devices /
\ Plugs / \ /
\----------/ \----------/
Legend:
Optical Devices: ROADM + Amplifier + Regen
Packet Devices: Routers
R/W: Provides Read/Write access ONLY for Plug life cycle management
In a network with packet and optical devices (including converged devices), it is important for the packet controller and the optical controllers to have direct control of the corresponding capabilities in the devices. In other words, a packet controller should have direct control of the packet capabilities and an optical controller should have direct control of the optical capabilities of the device regardless of their physical assembly.¶
The rationale and implications of this statement are explored in the following subsections.¶
Figure 4 shows a packet device with an optical plug and also shows a connected optical device to the right. It highlights the control of the packet and optical functions and emphasizes that these functions can be decoupled such that there is no overlap between the optical and packet control functions.¶
The Figure 4 shows the packet device in more detail. It shows interfaces (A), (B) and (C) as in Figure 3 but also exposes some internal detail highlighting:¶
|------------| |------------|
| Packet | | Optical |
| Controller | | Controller |
|------------| |------------|
^ ^ ^
| | |
| | |------------------------|
| | |
v (A) v (B) |
+----------------------------------+ |
| |-----------| |-----------| | |
| | Packet | (D) | Coherent | | |
| | Device | <--> | Plug | | |
| | Data | | Data | | |
| | | | | | |
| |-----------| |-----------| | |
| . ^ | |
| . (E) | | |
| . | | |
| . | | v (C)
| . | | +---------+
| . (F) v | | |
| |-------------| (G) |----------| (H) | Optical |
| |Packet |<=======>| Coherent |===========| Device |
| |Data function| | Plug | | |
| |-------------| |----------| +---------+
| |
| Packet Device |
+---------------------------------+
Legend
(A),(B),(C): Packet device, plug, optical device management interfaces
(e.g., Netconf, gNMI, gRPC etc.)
(D): Internal packet device dependency between plug and packet data
(E): CMIS management interface via I2C (i.e., plug to packet device interface)
(F): Internal interface between packet data and packet data function
(G): Packet device data function Interfaces
(H): Optical fiber connecting optical devices and/or optical pluggables
The packet device has several possible distinct realizations in Figure 4:¶
Realizations (2), (3) and (4) above have clear separation between access to packet and plug data, whereas realization (1) requires some form of access limitation. The following approaches might be employed to provide this access limitation:¶
There is a need for the packet and plug data path functions to be configured at interface (G) to match each other. The configuration properties might include the number of lanes, protocol, electrical characteristics and FEC settings. To understand appropriate solutions for this, it is necessary to assess the likely approach to network operations.¶
The choice of pluggable (where not yet installed) and settings of the pluggable, at any stage during installation and operation, are determined as a result of optical network analysis, including photonic path viability (See Appendix B), by the optical controller. To carry out this analysis, the optical controller needs to be aware of which types of pluggable the packet device can accommodate and also of the capabilities of those pluggable types. On completion of the analysis the selection of pluggable, where not already set, and pluggable configuration including CMIS AppSel, power, frequency, various shaping parameters and necessary settings for interface (G) are known. As the optical controller has all the necessary data, it is in the best position to set the pluggable properties directly.¶
Considering this, interface (G) configuration can be performed in one of the following ways:¶
Note that the detail of the method used to provide data via (D) depend upon the realization approach.¶
The data model for the coherent pluggable could be derived from any YANG data model such as OpenConfig, OIF etc. where the appropriate part of that YANG model could be mounted in the single YANG tree.¶
This section explores different levels of optical network configuration and operation complexity. Networks using grey optic where no significant optical control is required are in scope of this document.¶
This document focuses on networks where the DWDM is used to establish optical services which may include optical switching, amplification and regeneration using optical contrtollers. A practical deployment of packet over optical network might also be a mix of cases of grey optics, directly connected DWDM, switched DWDM etc. The networks are explored in more detail in the appendix (A).¶
The optical network essentially includes the amplifiers, switches, transponders (including pluggables) and all other components that work with photonic signals as well as those that work with the electrical signals directly applied to the photonic signals. At the transponder, it includes the adaptation functions that support the client layers (i.e., packet function). The adaptation function includes the capability to allow multiple wavelengths to carry a single signal etc.¶
Optical networks complexity depends upon transmission distance, need for flexibility in the photonic layer and need for photonic resilience.¶
For directly connected DWDM, there will be a need for configuration of basic optical parameters during commissioning whereas for cases where there is longer reach, switching and/or restoration there is a need for sophisticated network analysis to determine viability and need for more complex parameter settings.¶
For very long reach cases there may be a need to include optical regeneration (where the signal is taken from optical through electrical back to optical (O-E-O)). The regeneration node is not a packet device and is wholly controlled by the optical controller. Knowledge of the adaptation options in the regenerators and in the packet device is necessary for the correct choice and setup of regeneration nodes.¶
In all cases, it is necessary to evaluate options to determine the best optical network solution [see [ITU-T_G.sup39] for engineering considerations]. Hence, in a network where there are various solutions, even for situations where a basic interconnect turns out to be the right configuration, it is necessary to analyse the network in detail to determine this. Hence, it is necessary to involve the optical controller in all decisions about optical network configuration.¶
For some restoration cases there is a need for near real time optical configuration. The pluggable settings may need to be adjusted during restoration control actions. For example, it is possible that regeneration may be identified as required during a restoration activity and that as a result of this or other considerations, optical parameter changes, including wavelength and power may need to be applied to a pluggable during normal operation.¶
Commissioning of more capable, and hence expensive, coherent plugs in routers tends to follow a just-in-time deployment pattern where the pluggables are not installed in the router until they are required for service. These pluggables are used in more challenging applications that require sophisticated photonic viability assessment. The specialist photonic viability tools reside in the optical control function set.¶
Where there is a need to install a new pluggable, the process will operate in a relatively slow time frame. Once the pluggables are detected the optical controller the parameters of the pluggables can be configured and progress through any necessary validation testing on the optical network. This testing may involve the need to control the pluggables optical parameters along with parameters of other devices supporting the optical/photonic signals.¶
In deployments of converged packet over optical networks, there is a need for control functionality focussed on packet control (the packet controller) and control functionality focussed on optical control (the optical controller) as discussed in this document.¶
Industry is progressing towards generalilzed optical viability functions (see Appendix (B)) but currently, these functions tend to be vendor specific and reside in the vendor controllers. Current deployments tend to have a generalized optical controller from a particular optical device vendor controlling other vendor optical controllers. The optical controller discussed in this document is the collection of all optical control capabilities including whatever assembly of vendor controllers and generalized controllers are present.¶
It is assumed that the overall request for capacity will originate from some use of the network, e.g., data transfer between data centers. This request will be analyzed against current network capability. In some cases it will be identified that an enhancement to the optical network is required. This is may:¶
It is for the optical controller to determine network viability and most appropriate plug choice and configuration. Relevant bus lane configuration and adjustment will also be determined.¶
A control solution will normally be built with a generalized topology model, potentially following or guided by a standard (such as IETF RFC8345, ONF TAPI, TMF SID etc.) around which functions dealing with technology specific control (for packet, optical, radio etc.) are arranged. These functions cover commissioning, provisioning and dynamic behavior for service setup, incident/problem analysis etc. Sophisticated control solutions (that follow a digital twin approach) close the loop taking action to ensure maintenance of both short-term and long-term intent.¶
Current control solution architectures tend to be hierarchical in nature, partly driven by traditional strategies. The hierarchy often leads to the partitioning of control on a per-technology basis. This partitioning leads to packet domain controllers, optical domain controllers etc. The network control is pulled together by an orchestrator or high level controller. Many of the sophisticated optical control functions currently reside in a vendor specific controllers.¶
In current networks, it is likely that there is a single optical domain controller overarching several lower level specific vendor controllers, where the assembly is considered to be the single optical controller and multiple packet controllers due to regional demarcation etc.¶
As solutions evolve it is likely that artificial domain partitioning and hierarchy will dematerialized in favour of vast-scale cloud based solutions. In these solutions, vendor controller demarcation will also dematerialize. This is essentially a disaggregation of the control solution.¶
In this evolved solution, there will be a single point for each specific control consideration (e.g., single physical control capability, single upgrade capability) covering the entire network (bounded by commercial, political and regulatory considerations), working on any relevant grouping of things dependent upon the specific need at that moment. In this solution, each control capability will be appropriately independent and will coordinate with peers. These independent control capabilities will have the necessary direct access to the relevant parts of devices that they are responsible for. It is also anticipated that an intent (outcome oriented constraint based) interaction approach will apply at all points in the solution (including to the devices).¶
Clearly, some interface technologies will be better suited to this style of interaction than others. Ideally, device capability exposure will match the division of control responsibility and appropriate views will be offered to each control function. Some traditional interfaces that expose a monolithic model will need to utilize locking strategies to account for multiple clients even where the responsibility demarcation is clearly such that there will be no collision of control.¶
The automation of the multi-layer multi-domain packet over optical networks (i.e., IP/Optical convergence) is an area which captures the attention of most service providers. Any control architecture which covers the full automation of such networks shall address the following requirements:¶
The following aspects of optical service life cycle shall be managed and controlled by a single functional entity in the network.¶
Please note that this requirement addresses the optical controller functional aspects but not how they are realized in the network and not how the information needed by the optical controller is collected from the network (See Requirement R2 on this aspect where there are serveral approaches to realization of an optical controller considered).¶
In general, the industry agrees on the functional components that are needed for converged operations: there needs to be a multi-layer controllers that spans both the packet and optical domains in order to synthesize data from both domains and make optimal decisions regarding utilization of assets to deliver high-resiliency and high-performance network services. There is however a difference between packet and optical controllers functional components and their realization – there are different ways service providers can choose to deploy the multi-layer packet over optical controllers including coherent plugs to realize a solution that works in their specific operational environment.¶
There are several realization approaches including a single control fabric where the optical and packet control functions are deployed in the cloud or simple distinct hierarchy etc. For examples Figure 5 shows a few possible schemes to realize the multi-layer packet over optical controllers. Please also note that in some realization approaches there is not need for higher layer controller as shown in "Realizatoin D".¶
.....................................
. ----------------- .
. | Higher layer | .
. | Controller | .
. ----------------- .
............ .
. .
--------------- . --------------- .
| Packet | . | Optical | .
| Controller | . | Controller | .
--------------- . --------------- .
..........................
(Realizaton A)
....................................
. ----------------- .
. | Higher layer | .
. | Controller | .
. ----------------- .
. ...............
. .
. --------------- . ---------------
. | Packet | . | Optical |
. | Controller | . | Controller |
. --------------- . ---------------
......................
(Realizaton B)
..............................................
. ----------------- .
. | Higher layer | .
. | Controller | .
. ----------------- .
. .
. --------------- --------------- .
. | Packet | | Optical | .
. | Controller | | Controller | .
. --------------- --------------- .
..............................................
(Realizaton C)
..................... ......................
. --------------- . . --------------- .
. | Packet | . . | Optical | .
. | Controller | . . | Controller | .
. --------------- . . --------------- .
..................... ......................
(Realizaton D)
(In this realization there is no need for higer layer controller)
Requirement R1 emphasizes that the packet and optical control architecture shall deal with any network deployment and administration approaches as coherent plugs are deployed without imposing significant change to the operator's current operational practices (including network planning, commissioning, provisioning, assurance, optimization and protection/restoration).¶
As shown in Figure 9, in a traditional packet and optical disaggregated (not converged) network, the packet devices are connected to optical network via transponders/muxponders (i.e., the optical nodes which do not process packets and just aggregating packet device traffic into a single optical channel). In this deployment model, the optical controller controls, plans and manages the end-to-end optical services between client ports of transponders/muxponders via the optical network. In this model, the existing operational practices related to optical networks assume a single optical controllers for the entire optical domain. The packet network is administered and controlled separately from the optical network. Both networks have dedicated management/control platforms etc.¶
Appendix A Figure 10 and Figure 11 depicts other deployment models for packet over optical networks.¶
There will be significant benefit to operators allowing them to continue to use their existing operational practices to provision and monitor optical services end to end either between transponders/muxpnders or between coherent plugs.¶
For operators who have specific demarcation between operations of packet network and optical network (with separate physically partitioned controllers) as discussed, it is important that the introduction of converged optical-packet devices does not force a change to their existing operational practices.¶
As a network evolves, the operational practice may need to change, however, it is clearly always the case that complex photonic networking will require sophisticated dedicated control functions regardless of how the administration is organized.¶
The solution shall enable the use of various existing YANG data models, currently used to configure/monitor coherent transponders (e.g., OpenConfig, IETF etc.), for configuration/monitoring of coherent plugs in packet devices.¶
Where there is network technology based responsibility partitioning, the controllers should abide by the technology boundaries. The packet controller shall control packet functions and the optical controller shall control optical functions. The optical technology includes coherent terminal functions and hence these shall be controlled by the optical controller. The packet controller shall not need to be exposed to coherent plugs optical attributes. Optical technology is a separate, distinct and complex technology from packet technology.¶
The majority of the packet over optical deployments do not have or do not need a higher level controller. This requirement states that the existence of the higher level control shall be optional. Forcing the addition of a higher level controller makes the deployment more complex.¶
During some of the operation and restoration/protection cycles of the converged packet and optical networks, urgent action on the configuration of the pluggable may be required where the decision to take the action and the action detail are the responsibility of the optical controller. For example, during the restoration and protection of the Optical services, there might be a need for re-tuning and re-coloring of optical services. This involves changes in both the coherent plugs and ROADM networks.¶
It is highly beneficial to closely coordinate setting of configuration parameter settings across the optical network including pluggables as inconsistent configuration can potentially cause disruption to other photonic paths.¶
It shall be possible to access all configuration information and telemetry data available from the coherent plug with no (or only limited) intermediate transformation of data.¶
Transit through intermediate systems that process the syntax of the information, but that never take action on the information should be avoided.¶
It shall be possible to access all configuration information and telemetry data available from the coherent plug as directly as possible (ideally with no intervening transfer delays).¶
The multi-layer packet over optical capabilities and operational benefits among packet and optical controllers such as multi-layer optimization, multi-layer assurance, multi-layer resiliency/protection/restoration and multi-layer planning shall be addressed for full automation in a packet over optical networks.¶
Telemetry data and any change in state should be provided by the plug to the optical controller via a stream in a timely manner.¶
Many optical services will have a coherent plug in a packet device at one end and a coherent plug, or coherent optics on some other circuit pack type, in a non-packet device (e.g., storage, application platform, optical regen) at the other end. The solution shall support all current and expected configurations in a uniform fashion.¶
Some optical services will have protection. Some protection will be such that there are more than two ends (e.g., mixed layer protection) in the optical layer. This may be combined with regens, where there may be a regen in one protection branch and no regen in the other. The solution shall support all current and expected configurations in a uniform fashion.¶
The solution shall be designed to provide a clear evolution path to the probable future architecture (which is expected to be focussed on disaggregation of control). In this architecture it is expected that control components with specific focussed functions will have direct access to the corresponding functions in target systems and that asynchronous and simultaneous access to these functions will be vital.¶
The solution shall be designed to provide a clear evolution path to support control of packet and optical functions deployed using emerging strategies (e.g., cloud based routing) where the routing functions are not constrained by physical boundaries. Operational approaches native to these environments should be supported.¶
This section explains how the proposed architectural option-3 addresses the requirements covered in section 6 to achieve full automation in packet over optical converged networks.¶
R1 - There shall be a "single functional entity" responsible for optical services life cycle management¶
Requirement R1 emphasizes that one FUNCTIONAL entity is needed for life cycle management of the optical services. This requirment is supported by Option-3.¶
R2 - There shall be a clear distinction between functional components of an optical control vs. its realization¶
This requirment is supported by Option-3 where it allows any combination of optical, packet and higher layer controllers to be realized in operator's networks.¶
R3 - Existing operational practices shall be supported¶
Requirement R3 emphasizes that the packet and optical control architecture shall deal with any network deployment model without imposing significant changes to the operator's current operational approach in the area of network planning, commissioning, provisioning, assurance, optimization and protection/restoration).¶
Option-3 covers deployments where there is already a significant optical solution, that solution is administered and controlled separately from a packet solution (with strong administrative demarcation between optical functions including coherent terminals and packet devices) and deployment of coherent plugs is occurring. Option-3 enables the same workflow for coherent pluggables as used with their existing coherent terminals, i.e., no need to change the current operational approaches. This is a significant benefit as the plug deployment progresses.¶
In networks with limited deployment of basic optics where the business focus is mainly packet, there may be a single controller dealing with both the packet and the basic optical network. If more sophisticated optical capabilities are deployed and optical controller will become necessary. The operator may then choose to separate the optical and packet control, where option-3 focusses, or may choose to unify this control. Unified control will benefit from the direct access to the photonic capabilities of the packet device, as per option-3, especially where protection/restoration is required.¶
In networks where there is limited packet deployment, where the business focus is mainly optical, there may be a single controller dealing with optical and the limited packet deployment. Option-3 maintains the direct control of optical components when deployed as coherent plugs on packet devices.¶
R4 - Various YANG Data Models shall be accommodated¶
Requirement R4 states that the solution shall support various existing YANG data models used for current coherent optical solutions for coherent plugs (and various interfaces between the packet and optical controllers).¶
Option-3 supports this requirement. Referring to Figure 4, the optical controller can use packet device management interface (B) to control the coherent plugs. This interface can for example use the OpenConfig YANG data model [openconfig-platform-transceiver], [openconfig-platform] and [openconfig-terminal-device] over gNMI or any other YANG data models over Netconf, gNMI etc. As a result, the optical controller will have a holistic view of entire optical network from plugs to plugs.¶
R5 - Holistic control of optical network shall follow clear demarcation¶
Requirement R5 states that the network controllers shall abide by technology boundaries.¶
Option-3 inherently supports this requirement since the optical controller has access to the entire optical network for both provisioning/fulfilment and monitoring/assurance of optical services from plug to plug including all optical parameters.¶
R6 - Higher level controller shall be optional¶
Option-3 inherently supports this requirement as there is no need for the higher level controller to be present to configure the coherent plug (since the entire optical network is controlled, managed and monitored directly by a single optical controller).¶
R7 - Urgent optical control actions shall be supported in a timely manner.¶
Option-3 provides direct access from the optical controller to the coherent plug minimizing the time taken to apply any changes it has determined are necessary. The aim is to minimumize the round trip from detection of an issue in the coherent plug to application of any necessary action. This is achieved by direct access to data and to control of the coherent plug.¶
R8 - Solution shall minimize fragmentation of optical parameter provisioning.¶
Option-3 minimizes fragmentation of optical parameter provisioning as the optical controller has direct access to all devices with optical capabilities including to the coherent plugs in packet devices.¶
In many deployments, there will be multiple packet controllers with one optical controller. Clearly, localizing the direct control of the entire optical network to one optical controller minimizes fragmentation of control of the end-to-end optical services (whereas spreading the responsibility of optical services across the multiple packet controllers increases the fragmentation).¶
R9 - Access to the coherent plug properties shall be as transparent as possible.¶
Option-3 offers direct access to the coherent plugs from the optical controller minimizing the number of intervening functions/devices. It is the optical controller that needs access to the parameters of the coherent plug. The packet controller does not need access to these parameters. Option-3 does not require the packet controller to interpret or map the parameters.¶
In many deployments, there will be multiple packet controllers, potentially from different vendors, with one optical controller. In these deployment scenarios communication between optical controller and multiple packet controllers either directly or via a higher controller introduces many opportunities for misinterpretation and inappropriate mapping. As a result there is a greater likelihood of failure.¶
R10 - Network information shall take direct path to relevant controller¶
Option-3 optimizes the path from optical network functions including the coherent plug to the optical controller.¶
Communication between optical controller and packet controllers either directly or via a higher controller makes the path for communication of the optical parameters longer.¶
R11 - Multi-layer operational benefits shall be addressed¶
It is beneficial to treat the network as a whole. Considering a packet over optical network, multi-layer operational benefits such as multi-layer optimization, multi-layer assurance, multi-layer resiliency/protection/restoration and multi-layer planning need to be achieved.¶
Option-3 enables several solution approaches including: - a control hierarchy with a higher controller coordinating the optical controller and packet controllers - a single controller that provides an optimum integration of optical and packet control (both peer and hierarchical strategies as appropriate) - a disaggregated control solution where specialist functions interact together and with the network to provide a view of the whole network¶
R12 - Coherent plug telemetry data shall be collected¶
Option-3 provides direct access to plug telemetry for the optical controller.¶
R13 - Mix of plugs and Transponders/Muxponders (inc. Regens) shall be supported¶
Option-3 enables the optical controller to have direct access to coherent optical functions in devices regardless of the device.¶
R14 - Optical deployments with protection/restoration shall be supported¶
Option-3 provides the optical controller with a full view of the optical protection/restoration schemes. Since in option-3 the optical controller has a complete view and control of end-to-end optical services between coherent plugs, upon any optical failure, it can perform the optical restoration/protection by calculating the new optical path, performing the optical viability on that path and establish the new optical path in the network. The optical controller has full knowldedge to perform all these actions.¶
R15 - Evolution to expected future controller deployment approaches shall be supported.¶
Editor's note: This section will be completed.¶
R16 - Evolution to future packet processing deployment approaches¶
Editor's note: This section will be completed.¶
This section considers: - network planning focussing on development of a solution to the demand for more capacity in the packet network - Restoration of optical service¶
Figure 6 shows a network consists of routers A and B. The intention of this use-case is to create a new IP link with 400 Gbps bandwidth between router ports which are occupied with coherent plugs A and B. However before doing so, the connectivity between plugs should be establish on optical network by creating a new optical service from plug A to plug B. In this use-case the new IP link will be mapped to a single optical service, i.e., there is 1:1 mapping between the IP link and optical service.¶
So, the 400G IP link is mapped to a single 400G optical service because the optical network is capable of providing the 400G optical service, i.e., the optical service is viable. Use-case 8.3 will cover the viability where the optical service is not capable of providing 400G service.¶
In this case, since the underlay connectivity between plugs A and B does not exist, the creation of the IP link workflow (which is part of the packet controller), should first invoke the optical controller to create a new 400G optical service from plug A to plug B considering the other optical devices in optical network (i.e., ROADM). When the optical service is created, the packet device controller can create the new IP link.¶
Option-3 proposed in this draft will natively support this use-case since the interaction between packet and optical controllers just needed when the optical controller notifies the packet controller at the end of optical service creation. All other aspects of optical service creation is supported by optical controller because it has a complete visibility on optical network including the coherent plugs.¶
Packet Controller controls the packet devices Routers A and B
Optical Controller controls the optical network along with Plugs A & B
Router A Router B
+----+ New IP Link (between Router Ports) @ 400G +----+
| |.............................................................| |
| | | |
| | | |
| | | |
| | New Optical Service (Plug-to-Plug) @ 400G | |
| | ..................................................... | |
| +------+ +------+ |
| | | | | |
| |Plug A| +-------+ +-------+ +-------+ |Plug B| |
| | |======| ROADM |======| ROADM |======| ROADM |======| | |
| | | | + Amp | | | | + Amp | | | |
| +------+ +-------+ +-------+ +-------+ +------+ |
| | | |
+----+ +----+
Figure 7 shows the packet over optical network {figure-use-case-new-ip-link where the optical service between plugs A and B has been moved to a restoration path due to an issue on optical network (e.g., fiber cut). However, the optical network was not able to provide the original 400G data rate but in lower rate of 200G. As a result, the following tasks are needed to happen and option-3 should be able to addressed them:¶
IP Link @200G
(Rate reduced to 200G since the underlay
Router A optical service is on restoration path Router B
+----+ with 200G capacity) +----+
| |.............................................................| |
| | | |
| | | |
| | Optical Service @200G | |
| | (Rate reduced from 400G to 200G | |
|. | due to optical service restoration) | |
| | ..................................................... | |
| +------+ +------+ |
| | | | | |
| |Plug A| +-------+ +-------+ +-------+ |Plug B| |
| | |======| ROADM |======| ROADM |======| ROADM |======| | |
| | | | + Amp | | | | + Amp | | | |
| +------+ +-------+ +-------+ +-------+ +------+ |
| | | |
+----+ +----+
Optical transmission is an analogue technology where success is influenced and impacted by real physical conditions and where determining viability is complex. Other than for the most basic short direct optical links, it is necessary to employ optical viability tools to identify necessary intermediate components and define optimum optical set-up.¶
Optical components are relatively expensive and are often not deployed in the network until needed. As a consequence, there is often no simple potential link opportunity, and instead understanding of optical interconnectability relies on knowledge of semi-abstracted interbuilding fibering, potential plug capabilities and device with packet functions compatibility.¶
The combination of these two considerations means that it is often not possible to simply turn on an existing physical setup to cause further link capacity to be realized.¶
Figure 8 is same network as Figure 6 where the details of the optical network is removed. This use-case covers the interaction between coherent plugs and the optical network when the optical services switches to the restoration/protection paths (due to a fault in the optical network such as fiber cut). When the optical service moves to the new restoration/protection path, the new optical path's characteristics such as optical power, optical frequency (i.e., Lambda or optical channel), optical model etc. might change which should be communicated to the coherent plugs. As a result, there is a need for communication and interaction between coherent plugs and optical network on fiber links (H1) and (H2).¶
Since option-3 proposed in this draft provides the control of the coherent plugs and optical network on one optical controller, interaction between plugs and optical network on fiber links (H1) and (H2) is native and supported. No additional controller or network element needed to support the optical service restoration/protection.¶
Router A Router B
+----+ IP Link (between Router Ports) +----+
| |........................................................| |
| | | |
| | | |
| | Optical Service (Plug-to-Plug) | |
| | ............................................. | |
| | | |
| +------+ +------+ |
| | | |-------------------------| | | |
| |Plug A| +-----+ +-----+ |Plug B| |
| | | (H1) |ROADM| |ROADM| (H2) | | |
| | |=======| | | |=======| | |
| +------+ +-----+ +-----+ +------+ |
| | |-------------------------| | |
+----+ Optical Network +----+
we need to talk about re-coloring and re-assignment during the de-fragmentation which needs plug coordination with optical network This use-case has some similarities with use-case #4 but is more complex¶
Editor's note: This chapter will be completed.¶
Editor's note: This chapter will be completed.¶
Initial configuration¶
Requirement for additional capacity:¶
Packet network balancing capability (in orchestrator or IP controller) identified additional bandwidth requirement between devices with packet functions:¶
Developing the solution:¶
Orchestrator requests optical control capabilities (planning, routing, provisioning etc.) to determine appropriate details to connect relevant devices with packet functions:¶
Optical control identifies optimum route(s), determines use of ROADMs/Regens etc. and selects appropriate plugs with settings:¶
Evaluating the solution:¶
Depending upon policy the optical controller:¶
Note that the solution has plug type, plug setting, fiber interconnect and lane setting details. Optical controller now has optical intent and full solution.¶
Acquiring the plug¶
Lane settings:¶
If the optical controller is in charge of the CMIS bus (lanes etc.) in the device with packet functions, then these are set. If not, then the orchestrator passes lane settings to the packet controller as part of link intent (the orchestrator was provided with these settings by the optical controller earlier in the process).¶
Some packet settings require to match at both ends, if the packet controller does not have visibility of both ends then this coordination must be performed by the orchestrator. The packet controller may pre-set the lanes etc. in the devices with packet functions (or it may leave this till optical configuration is detected).¶
Plug installation and power-up:¶
When plugs are installed in the device with packet functions, the plug is powered up. Plug power-up to low power is the responsibility of the optical controller within the power budget of the device with packet functions.¶
Once the plugs are powered up to low power state, the optical controller coordinates optical provisioning across plugs, ROADMs etc., including for the plugs entering full power-up. The optical controller sets specialist photonic parameters and other configuration as appropriate. Lane configuration of the plug and CMIS settings are achieved via the provision of AppSel value, via other parameter settings etc. (note that lane settings may require tweaking off-default for specific device with packet functions capability).¶
Commissioning:¶
Optical controller tests plug-plug and coordinates any loopbacks, PRBS settings, measurements along the path etc.¶
Path enabled:¶
The optical controller enables optical path:¶
This document has considered control of optical plugs in devices with packet functions. Three specific control solution deployment strategies were examined:¶
Whilst the deployment strategies apply to control of a network in general, this draft focused on control of the optical network and in particular the control of the optical plug in a device with packet functions. The orchestrator strategy and the single controller strategy essentially exist to a degree in solutions today. The single control fabric strategy is an anticipated evolution of the control solutions. For all of the examined control solution deployment strategies, the control functions specializing in photonics determine the optical network setup on-going and these control functions directly control the photonics of the network including the optical plugs in devices with packet functions. Various indirect control options are not discussed in this draft.¶
There is a clear separation of concerns between packet function control and optical function control such that the control can be partitioned so that control functions specializing in control of the packet network can control corresponding functions in the device with packet functions with no interference from the optical control functions and vice versa. The optical control functions do not control any aspect of the packet functions in those devices. To ensure that there are no transaction issues, locking of the config is recommended.¶
Direct control of the optical plug by the optical control functions (in the optical controller) appears to be a natural and valid approach.¶
This document has no IANA actions.¶
A packet over an optical network represents an efficient paradigm that harnesses the power of both packet-switching and optical technologies. In this approach, the IP or MPLS packets are transmitted through an underlying optical network which combines the advantages of packet-switching and optical transmission. The fusion of packet and optical networks offers a host of advantages, including accelerated data transfer rates, diminished latency, and expanded network capacity.¶
Various deployment models can be employed to deploy the packet over optical networks. The first approach is disaggregated solution as shown in Figure 9. This solution involves the separation of IP network from Optical network allowing for greater flexibility, scalability, and efficiency in network management and operation. In this setup, the IP (Internet Protocol) layer responsible for routing and forwarding is decoupled from the underlying optical transport layer.¶
This approach offers several benefits, including the ability to scale each layer independently, optimize resource utilization, and simplify network management through centralized software control. Disaggregation enables network operators to choose best-of-breed components for each layer, fostering innovation and competition in the networking industry. However, implementing and managing a disaggregated network also comes with challenges related to interoperability, integration, and maintaining end-to-end performance across the various layers.¶
IP Network
|----------| |----------|
| | IP Link | |
| Packet-1 |================================| Packet-2 |
| |\ /| |
| | \ / | |
|----------| | | |----------|
| |
| | Optical Network
.............. | ....................... | ..............
. | | .
. |---------| (-------) |---------| .
. | xPonder | ( ROADMs ) | xPonder | .
. | |----( + Amp )-----| | .
. |---------| (+ Regen ) |---------| .
. (-------) .
.........................................................
Legend:
==== IP Link
---- Optical fibers
Packet: Packet devices (i.e., Router)
xPonder: Optical network muxponder or transponder
ROADMS: Optical/Photonic layer devices responsible for Lambda switching + Regen + Amplifier
Optical network: xPonders + Photonic Layer (i.e. ROADMS, Amp, regen)
The second approach is to shrink the functions of the xPonders into a single small form factor plugs (aka Coherent pluggables) and then place them directly into the packet devices as shown in Figure 10. This is possible because the optical component design continues to improve density to the point where a whole transponder and muxponder which use to require many circuit packs can now fit onto a single small form factor pluggable. Placing this small form factor pluggable in a device with packet functions can reduce network cost, power consumption and footprint (when these benefits are not outweighed by other engineering considerations). Depends on the application, distance between packet devices, quality of fibers and so on it might be that there is no need for a ROADM network, i.e., direct connectivity between packet devices via plugs.¶
By incorporating coherent plugs into routers, network operators can achieve higher data rates, greater spectral efficiency, and improved tolerance to optical impairments. This is especially valuable in scenarios where traditional electronic signaling might encounter limitations. Coherent plugs enable routers to leverage advanced modulation schemes, digital signal processing, and error correction techniques, enhancing their ability to handle complex optical signals.¶
One of the key advantages of using coherent plugs in routers is the potential to bridge the gap between long-haul and metro networks, providing a seamless and efficient transition of data across various network segments. This technology can contribute to the evolution of high-speed data centers, interconnection between data centers, and the overall growth of data-intensive applications.¶
However, implementing coherent plugs in routers requires careful consideration of factors such as power consumption, form factor, cost, and integration with existing network infrastructure. As technology continues to evolve, coherent plugs hold the promise of extending the capabilities of routers and optical networks.¶
IP Network
|----------| |----------|
| | IP Link | |
| |===============================| |
| Packet-1 +++ +++ Packet-2 |
| | \ / | |
| | \ / | |
| | | | | |
|----------| | | |----------|
|---------------------|
Optical Network
Legend:
++++ coherent pluggables
==== IP Link
---- Optical fibers
Packet: Packet devices (i.e., Router)
Optical network: Coherent plugs
Another flavor of Figure 10 is shown in Figure 11 where the transponder and muxponder functionality is provided by plugs but there is still a need for ROADM network. The packet over optical architecture is important for long-haul use cases since they exhibit several distinctive characteristics that make them suitable for efficiently transmitting data over vast distances such as:¶
|----------| |----------|
| | IP Link | |
| |==================================| |
| Packet-1 +++ +++ Packet-2 |
| | \ / | |
| | \ / | |
| | | | | |
|----------| | | |----------|
| |
| (------) |
| ( ROADMs ) |
|----- ( + Amp ) -----|
( + Regen)
(------)
Optical Network
Legend:
++++ coherent pluggables
==== IP Link
---- Optical fibers
Packet: Packet devices (i.e., Router)
ROADMS: Optical/Photonic layer devices responsible for Lambda switching
Optical network: Coherent Plugs + Photonic Layer (i.e. ROADMS, Amp, Regen)
Optical transmission is an analogue technology where success is influenced and impacted by real physical conditions and where determining viability is complex. Other than for the most basic short direct optical links, it is necessary to employ optical viability tools to identify necessary intermediate components and define optimum optical set-up.¶
Optical components are relatively expensive and are often not deployed in the network until needed. As a consequence, there is often no simple potential link opportunity, and instead understanding of optical interconnectability relies on knowledge of semi-abstracted interbuilding fibering, potential plug capabilities and device with packet functions compatibility.¶
The combination of these two considerations means that it is often not possible to simply turn on an existing physical setup to cause further link capacity to be realized.¶
The diagram below shows a network with three devices with packet devices each with two sockets for optical plugs with the plugs not equipped. This can be generalized to multiple sockets. The connectors for the optical plugs are depicted with "{" and "}" in the devices with packet functions. The devices with packet functions are assumed to be on separate sites (packet sites). The diagram also shows four devices with only optical functions, "~" (could be OLS, Amplifier, ROADM Regenerator, protection switch unit etc.) which are interconnected with fibers "=". The devices with packet functions are not yet connected to the optical network but there are fibers with connectors, "{" and "}", that will enable interconnection when the optical plugs are equipped that are accessible in the packet sites.¶
Router A Router B
+----+ IP Link (between Router Ports) +----+
| |.............................................................| |
| | | |
| | | |
| | | |
| | Optical Service (Plug-to-Plug) | |
| | ..................................................... | |
| +-+ +------+ |
| | | | |
| | +-------+ +-------+ +-------+ |Plug B| |
| | ======| ROADM |======| ROADM |======| ROADM |======| | |
| | | + Amp | | | | + Amp | | | |
| +-+ +-------+ +-------+ +-------+ +------+ |
| | | |
+----+ +----+
Clearly, in general in a running network, devices with packet functions would have some plugs equipped and would be interconnected to other devices with packet functions via active optical networking. The devices with packet functions would have some plug sockets empty, and this would allow for network expansion.¶
The following sections set out key network forms that may result from photonic viability analysis. In all networks a device with packet functions, "ixi", straddles the packet domain and optical domains with the packet function in the packet domain and the optical functions of the optical plug in the optical domain. The devices with packet functions are in "packet sites" that are some distance apart.¶
To determine that direct connection is viable, photonic tools need to be used to validate reach etc.¶
As discussed above, plugs may not be present when viability is assessed.¶
Router A Router B
+----+ IP Link (between Router Ports) +----+
| |.............................................................| |
| | | |
| | Optical Service (Plug-to-Plug) | |
| | ..................................................... | |
| +------+ +------+ |
| | | | | |
| |Plug A| |Plug B| |
| | |===================================================| | |
| | | | | |
| +------+ +------+ |
| | | |
+----+ +----+
The direct interconnect may be viable with standard ZR plugs, or it may need a more capable vendor proprietary plug configurations.¶
In the following diagram, the devices with packet functions are a significant distance apart requiring the use of more sophisticated optical/photonic capabilities including amplifiers and ROADMs. The network may be more complex than shown and may involve optical protection etc. (depending upon network strategy). The packet sites may also have optical equipments present so ROADM1 may be in the same site as Router A etc.¶
Router A Router B
+----+ IP Link (between Router Ports) +----+
| |.............................................................| |
| | | |
| | | |
| | | |
| | Optical Service (Plug-to-Plug) | |
| | ..................................................... | |
| +------+ +------+ |
| | | | | |
| |Plug A| +-------+ +-------+ +-------+ |Plug B| |
| | |======| ROADM |======| ROADM |======| ROADM |======| | |
| | | | + Amp | | | | + Amp | | | |
| +------+ +-------+ +-------+ +-------+ +------+ |
| | | |
+----+ +----+
In the following diagram, the devices with packet functions are a great distance apart requiring the use of optical regenerators. It is possible several regenerators may be required. As for the previous case, there may also be optical protection etc.¶
Router A Router B
+----+ IP Link (between Router Ports). +----+
| |.............................................................| |
| | | |
| | | |
| | Optical Services | |
| | +-------+ | |
| | ..................... | | ..................... | |
| +------+ | | +------+ |
| | | | | | | |
| |Plug A| +-------+ | | +-------+ |Plug B| |
| | |======| ROADM |======| Regen |======| ROADM |======| | |
| | | | + Amp | | | | + Amp | | | |
| +------+ +-------+ +-------+ +-------+ +------+ |
| | | |
+----+ +----+
This section describes alternative control architecture aiming at disaggregated could-based realization solutions.¶
Thanks to Sergio Belotti from Nokia (sergio.belotti@nokia.com) for his contribution to this document.¶