]> Ciena

ndavis@ciena.com

AREA WG Working Group photonic plugs CMIS I2C AppSel OpenConfig This document considers control of photonic plugs in devices with packet functions from an architecture perspective. Three specific control solution deployment strategies are examined:

• network technology partitioned domain controllers, with an orchestrator (higher level controller) to coordinate the domain controllers
• single controller dealing with all network technologies
• single control fabric in which components, from various vendors, each focused on a specific control function, interact as peers to provide holistic control of the network

For all of the examined control solution deployment strategies, the control functions specializing in photonics determine the photonic network setup on-going and these control functions directly control the photonics of the network including the photonic plugs in devices with packet functions. There is a clear separation of concerns between packet function control and photonic 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 photonic control functions and vice versa. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the WG Working Group mailing list (), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction Optical component design continues to improve density to the point where a whole optical terminal system that 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). However, optical networks are analogue requiring complex control. Consequently, coordination of control of the optical aspects of such a plug in a device with packet functions with the control of the rest of the optical network is desirable to simplify 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 use the CMIS bus [OIF CMIS] and that 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 photonic 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 photonic path is terminated at each end using a plug from the same vendor. The photonic plug encapsulates significant sophisticated photonic functions which often require specialist adjustment. This draft explores the control of the photonic plug and explains the approach to control of the plug identifying appropriate interfaces and parameters to be manipulated. The draft considers the networking aspects of control and works through some (somewhat stylized) use cases exploring initial planning, commissioning, general operation, restoration (where relevant) and adjustment. This draft does not provide YANG models as it is assumed that YANG model work already underway is essentially appropriate. The following sections include diagrams that show various aspects of the optical network. Each diagram set has an associated explanation / key to aid interpretation.

Optical network viability 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.

Network with unequipped plugs The diagram below shows a network with three devices with packet functions, "ixi", each with two sockets for photonic plugs with the plugs not equipped. This can be generalized to multiple sockets. The connectors for the photonic 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 photonic 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 photonic network but there are fibers with connectors, "{" and "}", that will enable interconnection when the photonic plugs are equipped that are accessible in the packet sites. Figure 1: Devices with packet functions, with no equipped plugs, and a photonic network 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 photonic networking. The devices with packet functions would have some plug sockets empty, and this would allow for network expansion.

Network Contexts 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 photonic plug in the optical domain. The devices with packet functions are in "packet sites" that are some distance apart. Some of the diagrams show:

• packet functions, ixi
• analogue photonics, "~"
• photonic crossconnects, "~x~"
• photonic amplifiers, ">~<"
• electrical regenerators, "e=e"
• abstract links (as in RFC8345), "- -"
• electrical-optical interfacing in the plugs "E O"

Basic direct connect 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. Figure 2: Basic direct connection The direct interconnect may be viable with standard ZR plugs, or it may need a more capable vendor proprietary plug configurations.

Optical network with ROADMs and Amplifiers 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 photonic protection etc. (depending upon network strategy). The packet sites may also have photonic equipments present so ROADM1 may be in the same site as Router A etc. ~<}=={~x~>~<}=={~x~}==={>~<}=={>~<~x~}=={>~<~] | | +----+ +------+ +---+ +---+ +------+ +----+ | | | ROADM1 ROADM2 Amp ROADM3 | | +---+ +Amp +Amp +---+ ]]> Figure 3: Optical network with ROADMs and amplifiers

Optical network with regenerators 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 photonic protection etc. ~<}=={~x~>~<}=={~x~}=={~ ~}=={>~<}=={>~<~x~}=={>~<~] | | +----+ +------+ +---+ +---+ +---+ +------+ +----+ | | | ROADM1 ROADM2 Regen Amp ROADM3 | | +---+ +Amp +Amp +---+ ]]> Figure 3: Optical network with regenerators

Control Solution This section works through a general architecture in the form of an abstract functional representation of the control of networks focussing on the optical/photonic considerations in the context of packet services. The assessment starts with a brief more detailed description a photonic plug in a device with packet functions and then sets out some relevant abstract control functions. These functions have been given somewhat arbitrary names to avoid apparent support for any particular detailed functional architecture. There are several arrangements that these functions could take in a control solution. Three specific forms are explored:

• A single controller controlling all aspects of the network
• A single control fabric with a set of interacting control components
• A traditional control hierarchy where controllers are partitioned by network technology domain and are coordinated by an orchestrator

Photonic plug in a device with packet functions The diagram below shows a photonic plug in a device with packet functions. The diagram also shows a connected photonic device (to the right). The diagram highlights the control of the packet functions and of the photonic functions and emphasizes that these functions can be decoupled such that there is no overlap with respect to configuration. Clearly there is a need for the CMIS lane configuration of the plug to match that of the packet functions. As will be discussed later, where there is a choice of lane configuration, the considerations are:

• which lane configurations are supported by the device with packet functions and the photonic plug
• which lane configurations are required for the data to be transferred
• where there are options, which lane configuration provides the best characteristics

The diagram also shows a Control Plane function, "CP" in the photonic device which is potentially coordinating the settings of the transponder via a signalling method. | | | | _ _ | | | Packet Fnc |<===={=>|E O ~| }==={| ~ |}= | |_ _ _ _ _ _ _|<===={=>|_ _ _| | ||_ _|| | Device with CMIS +----------+ +-----+ | packet functions Bus | +---------------------------------+ ]]> Figure 4: Device with packet function and a photonic plug The diagram shows distinct separable blocks of data, "!xxx!", various traffic functions, "_ _ _", a control plane function, "***", and control information flow, ":". The following terms are also used in the diagram:

• NC Netconf (with IETF model, [OpenConfig] model etc. (specific model not relevant)) (M&C)
• OG [OpenConfig] over GNMI
• c A proprietary protocol control access
• M&C Monitoring and Control
• M&E Monitoring and Expectation (where the device is primed to expect a particular plug)
• M Monitoring
• I2C CMIS [OIF-CMIS] control interface
• ~ Photonics
• EO~ Media (line) side electrical, optical and photonic details
• CP Control Plane

The capabilities of the plug are accessed either through an [OpenConfig] model over [GNMI] running independently of the Netconf interface accessing the packet functions of the device or via Netconf where the model may be [OpenConfig] or any other appropriate YANG model. When Netconf is used for both plug configuration and packet capability configuration, the data can be either logically partitioned, with two sessions over one interface, or physically partitioned, with two separate interfaces. The CMIS Bus requires configuration of the number of Lanes and protocol along with electrical characteristics and FEC settings. The photonic plug may require configuration of CMIS AppSel, power, frequency, various shaping parameters etc. As some configuration adjustments will require several parameters to be set to achieve the change, locking of the configuration is recommended.

Abstract control functions - control of the devices The figure below shows some stylized abstracted functions of a solution involved in set up and control of a packet/photonic network comprising devices with packet functions with photonic plugs and other photonic equipments. The functions are intentionally placed in a cloud as there are many potential alternative deployment strategies. Some deployment strategies will be discussed later in this document. The solution is driven by Service intent and optimized using a combination of Capacity Analysis, which in this case emphasizes Inter Packet Site Capacity (IPSC), Photonic Connection Viability (PCV) and Photonic Network Optimization (PNO). The photonic optimization functions are aware of the opportunities for equipping devices with packet functions with photonic plugs and also of building cabling opportunities to interconnect plugs to existing optical network (including fibers, ROADMs etc.). The functions involved in Packet Management & Control and Photonic Management & Control are separated (separation of concerns) as there is a light client-server coupling between packet networking and photonic networking in that the photonic network provides interconnection capacity to the packet network. There is also a clear separation of concerns in terms of process phasing, configuration intensity etc. The control functions interact with Photonic Plugs via the Devices with packet functions using alternative combinations of NetConf (NC) and [OpenConfig] over [GNMI] (OG) where the Photonic plug properties are provisioned either via [OpenConfig] over [GNMI] or via NetConf and where the Photonic parameters are provided by the Photonic control functions. The cohesion and configuration interdependence of the components in the photonic network provide a clear need for coordination of the photonic networking end-end. The solution in the photonic network may involve restoration schemes where these may require changes to transponder properties during the restoration action. The photonic network optimization actions may need to adjust the photonic parameters which will be constrained by the agreed service intent. As noted in the earlier diagram showing a Photonic plug in a device with packet functions, there may be a photonic control plane which will use signalling to coordinate some of the plug photonic configuration. Figure 5: Abstract control functions See "Photonic plug in a device with packet functions" for detail of the device with packet functions with photonic plugs and diagram key. The figure below clarifies the responsibility of the two M&C functions in the controller emphasizing that the Photonic control functions control the plug, and the packet control functions control the packet capabilities of the router. The models for the two aspects can be quite separate. Figure 6: Functional control relationship

A single controller controlling all aspects of the network In this case the single appropriately scalable (multi-platform) controller (from a single vendor) includes all relevant functions to control all layers etc. including those shown in the figure above. The controller may also control devices that use the packet data and devices that provide wireless transport etc. In this case it would be expected that there would be a similar decoupling of the control functions for each domain. In this architecture functionality decoupling is driven by control specialization resulting from specialization of the functions being controlled.

A single control fabric with an assembly of interacting control components Whilst, from the perspective of the figures in this document, this is indistinguishable from the single controller, the distinction is in the deployment decoupling. The single control fabric is realized in a consistent multi-platform environment (cloud etc.). Each control component is delivered into the control fabric independently and the control components may be from a mix of vendors. This is considered a likely evolution of the current control environment. In this case it is anticipated that there will be coordination of the control of all aspect of the solution via some mix of hierarchy and peering. This coordination will enable appropriate autonomy of operations. Specific components will have direct control over their areas of "expertise" and will have direct access to the devices where appropriate. The coordination of control and appropriate use of transactional strategies including locking of configurations etc. will ensure consistency of configuration within the device through transitions etc.

A traditional control hierarchy partitioned by network technology domain A simple adjustment to the earlier figure emphasizes the deployment distinction between this case and the previous cases. Here the photonic/optical control components are provided by a Photonic/Optical Controller and the packet control components are provided by a Packet Controller. The two controllers are coordinated by an orchestrator. The orchestrator is likely to carry out general capacity analysis and to initiate the activities of specific analysis and optimization carried out by the Photonic/Optical Controller etc. The same separation of concerns of photonic networking and packet networking discussed earlier applies here, so the photonic controller determines and configures the photonic parameters of the plug and also, where appropriate, sets up any relevant control plane. When the photonic controller determines the best approach to achieving network connectivity, it also determines the plug lane configuration etc. Figure 7: Control hierarchy partitioned by network technology domain

Use Cases This section considers: - network planning focussing on development of a solution to the demand for more capacity in the packet network - Restoration of photonic service

Packet Network Capacity growth

Initial configuration

• Many devices with packet functions are interconnected by photonics
• Devices with packet functions have spare plug slot capacity
• Service requirements are growing and changing over time

Requirement for additional capacity Packet network balancing capability (in orchestrator or IP controller) identified additional bandwidth requirement between devices with packet functions:

• This is probably a projection forward in time to allow procurement and/or delivery
• The relevant information needs to be available to the orchestrator
• There may be many alternative rearrangements

Developing the solution Orchestrator requests photonic control capabilities (planning, routing, provisioning etc.) to determine appropriate details to connect relevant devices with packet functions:

• There may be several choices of device with packet functions, the bandwidth provisioning may have various options.

Photonic control identifies optimum route(s), determines use of ROADMs/Regens etc. and selects appropriate plugs with settings:

• There may be options for plug procurement and use of device with packet functions plug slots
• The control functions need to know CMIS lane capability of the equipment in the device with packet functions as some options may be eliminated based upon lane capability (speed/lane count etc.)

Evaluating the solution Depending upon policy the photonic controller:

• If policy dictates that orchestrator must evaluate options (and there are options). Photonic controller passes details to the orchestrator of the resolved intent request. The photonic controller provides abstracted info to the orchestrator for evaluation. The orchestrator selects option and informs the photonic controller.
• If the photonic controller is in charge of selecting a single solution (or there is only a single solution). Photonic controller informs the orchestrator of the solution.

Note that the solution has plug type, plug setting, fiber interconnect and lane setting details. Photonic controller now has photonic intent and full solution.

Acquiring the plug

• Plug procurement or shipping is initiated
• Work orders are initiated for plug installation and cabling where necessary

Lane settings If the photonic 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 photonic controller earlier in the process).

• The packet controller uses the link intent with lane constraints to determine lane setting, FEC, etc.
• The device with packet functions sets its side of CMIS (lane config (and separately FEC))to match the plug lane configuration as defined by intent passed to packet controller by the orchestrator (as determined by the photonic controller).

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 photonic 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 photonic controller within the power budget of the device with packet functions. Once the plugs are powered up to low power state, the photonic controller coordinates photonic provisioning across plugs, ROADMs etc., including for the plugs entering full power-up. The photonic 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 Photonic controller tests plug-plug and coordinates any loopbacks, PRBS settings, measurements along the path etc.

Path enabled The photonic controller enables photonic path:

• device with packet functions detects link
• device with packet functions network uses new capacity

Packet Network rearrangement TBD

Restoration of photonic service Highlight the possible need to adjust the transponder during the protection activity. TBD

Rearrangement and grooming of the photonic network Highlight the possible need to adjust the transponder coordinated as part of the network grooming activity. TBD

Conclusion This document has considered control of photonic plugs in devices with packet functions. Three specific control solution deployment strategies were examined:

• network technology partitioned domain controllers, with an orchestrator (higher level controller) to coordinate the domain controllers
• single controller dealing with all network technologies
• single control fabric in which components, from various vendors, each focused on a specific control function, interact as peers to provide holistic control of the network

Whilst the deployment strategies apply to control of a network in general, this draft focused on control of the photonic network and in particular the control of the photonic 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 photonic network setup on-going and these control functions directly control the photonics of the network including the photonic 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 photonic 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 photonic control functions and vice versa. The photonic 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 photonic plug by the photonic control functions (in the photonic controller) appears to be a natural and valid approach.

Security Considerations None

IANA Considerations This document has no IANA actions.

Informative References [OIF CMIS] https://www.oiforum.com/wp-content/uploads/OIF-CMIS-05.2.pdf [OIF 400ZR] https://www.oiforum.com/wp-content/uploads/OIF-400ZR-01.0_reduced2.pdf [OpenConfig] https://www.openconfig.net/ [GNMI] https://www.openconfig.net/docs/gnmi/gnmi-specification/

Problem/Solution Examples TBD

Acknowledgments