| Internet-Draft | PPCA | July 2023 |
| Davis | Expires 11 January 2024 | [Page] |
This document considers control of photonic plugs in devices with packet functions from an architecture perspective. Three specific control solution deployment strategies are examined:¶
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.¶
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 11 January 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.¶
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 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 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.¶
+---+
|ixi|
++ |
} |
+---+ ++ | +---+
|ixi| {======================} | | |ixi|
| ++ ++ | ++ |
| { } | } |
| ++ +-+ +-+ +-+ ++ | ++ |
| | {=={~}=={ }=={ }=======} +---+ | |
| ++ +-+ |~| |~| +-+ ++ |
| { | | | }=={~}=============} } |
| ++ | | +-+ +-+ ++ |
+---+ | }=======================} +---+
+-+
¶
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.¶
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:¶
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 +---+
|ixi|- - - - - - - -|ixi|
| | Packet | |
|...|......................|...|
| | Optical | |
| +----+Plug A Plug B+----+ |
| {E |- - - - - -| E} |
| [O | | O] |
| [~ }================{ ~] |
| +----+ +----+ |
| | | |
+---+ +---+
¶
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.¶
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.¶
Router A Router B
+---+ IP Link +---+
|ixi|- - - - - - - - - - - - - - -|ixi|
| | Packet | |
|...|...........................................|...|
| | Optical | |
| +----+ Plug A Plug B +----+ |
| {E |- - - - - - - - - - - - -| E} |
| [O | +------+ +---+ +---+ +------+ | O] |
| [~>~<}=={~x~>~<}=={~x~}==={>~<}=={>~<~x~}=={>~<~] |
| +----+ +------+ +---+ +---+ +------+ +----+ |
| | ROADM1 ROADM2 Amp ROADM3 | |
+---+ +Amp +Amp +---+
¶
Figure 3: Optical network with ROADMs and amplifiers¶
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.¶
Router A Router B
+---+ IP Link +---+
|ixi|- - - - - - - - - - - - - - - - -|ixi|
| | Packet | |
| | ............................................. | |
| | Optical | |
| +----+ Plug A +---+ Plug B +----+ |
| {E |- - - - - - -|e=e|- - - - - - -| E} |
| [O | +------+ +---+ |O O| +---+ +------+ | O] |
| [~>~<}=={~x~>~<}=={~x~}=={~ ~}=={>~<}=={>~<~x~}=={>~<~] |
| +----+ +------+ +---+ +---+ +---+ +------+ +----+ |
| | ROADM1 ROADM2 Regen Amp ROADM3 | |
+---+ +Amp +Amp +---+
¶
Figure 3: Optical network with regenerators¶
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:¶
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:¶
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.¶
:: :: :
/\ /\ :
+--------------*NC*---------*OG*--+ :
| _ _ __ _ _ / \_ _ _ _ _:_ | :
|!Packet(M&C)! !Plug I2C(M&C)!| :
|! Pkt Fnc ! ! EO~ !| :
|! ! ! Lanes !| :
|!Plug (M) ! ! Loopback etc!| :
|! Lanes ! ! Power, Temp !| :
|! Power ! !Phys (M&E) !| :
|! Temp ! ! Inventory !| :
|!_ _ _ _ _ _! !_ _ _ _ _ _ _!| :
| \ \ \ : : | :
| \ \ \ : : | :
| \ \ \ Power : : I2C | :
| \ \ \ : : | :
| \ \ \ : : +----------+ :
| \ \ \ : : [ | :
| \ \ \ : +-{ Plug | :
| \ \ \ : [ | ^
| Pkt Fnc \ \ ---+----{ | +-*c*-+
| \ \ Lanes [ | |*****|
| \ -------\ | /---}- -{*CP *|
| _ _ _ _ \ _ _ \[ _ / _ | |*****|
| | |<===={=>| | | | _ _ |
| | 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:¶
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.¶
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.¶
***********************
* Capacity Analysis *
***********************
: :
+---------------------+ :
: :
****************** :
* Service Intent * :
****************** **********
: * IPSC *
_ _ _ _:_ _ _ _ _ _ **********
! Packet Domain ! : :
! Service & Network ! : :
! Models ! ********* *********
!_ _ _ _ _ _ _ _ _ _! * PCV * * PNO *
: : ********* *********
: : _ _ _:_ _ _ _ _ _:_ _
: : !Photonic Domain !
: : !Service&Network Model!
: : !_ _ _ _ _ _ _ _ _ _ _!
: : :
_ _:_ _ _ _ _:_ _ _ _ _ _ _:_ _ _ _ _ _
!Packet ! !Device ! ! Photonic !
!Nodal ! !Physical ! ! Nodal !
! ! ! ! ! !
!_ _ _ _! !_ _ _ _ _! !_ _ _ _ _ _ _ _ _ _ _!
: : :
****************** ************************
* Packet (M&C) * * Photonic (M&C) *
****************** ************************
: : : :
: : : :
: : : :
+------------*NC*---------*NC**OG*------------*c*-+
\/ \/ \/ v
:: :: :: :
:+---+-------+: :: :
+---+---------+ :: :
:: :: :
/\ /\ ^
+--------------*NC*---------*OG*--+ +-*c*-+
| Device with Photonic plugs | | ~ |
+---------------------------------+ +-----+
¶
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.¶
_ _:_ _ _ _ _:_ _ _ _ _ _ _:_ _ _ _ _ _
!Packet ! !Device ! ! Photonic !
!Nodal ! !Physical ! ! Nodal !
! ! ! ! ! !
!_ _ _ _! !_ _ _ _ _! !_ _ _ _ _ _ _ _ _ _ _!
: : :
****************** ************************
* Packet (M&C) * * Photonic (M&C) *
****************** ************************
: :
: :
: :
+-------------:----------------:------------------+
: :
: :
+-----------:----------------:----+
| _ _ __ _ _: _ _ _ _ _:_ _ |
|!Packet(M&C)! !Plug I2C(M&C)!|
|! Pkt Fnc ! ! EO~ !|
|! ! ! Lanes !|
|!Plug (M) ! ! Loopback etc!|
|! Lanes ! ! Power, Temp !|
|! Power ! !Phys (M&E) !|
|! Temp ! ! Inventory !|
|!_ _ _ _ _ _! !_ _ _ _ _ _ _!|
| \ \ \ : : |
| \ \ \ : : |
¶
Figure 6: Functional control relationship¶
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.¶
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 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.¶
+--------------------------------------+
| Orchestrator *********************** |
| * Capacity Analysis * |
| *********************** |
+-------------------:-------:----------+
+---------------------+ : RC
+--------:-----------+ +-------------:----------+
|****************** | | Photonic : |
|* Service Intent * | | Controller : |
|****************** | | ********** |
| : | | * IPSC * |
| _ _ _ _:_ _ _ _ _ | | ********** |
|! Packet Domain ! | | : : |
|! Service&Network ! | | : : |
|! Models ! | | ********* ********* |
|!_ _ _ _ _ _ _ _ _! | | * PCV * * PNO * |
| : : | | ********* ********* |
| :Packet : | | _ _ _:_ _ _ _ _ _:_ _ |
| :Controller : | | !Photonic Domain !|
| : : | | !Service&Network Model!|
| : : | | !_ _ _ _ _ _ _ _ _ _ _!|
| : : | | : |
|_ _:_ _ _ _ _:_ _ | | _ _ _ _ _:_ _ _ _ _ _ |
!Packet ! !Device !| | ! Photonic !|
!Nodal ! !Physical !| | ! Nodal !|
! ! ! !| | ! !|
!_ _ _ _! !_ _ _ _ _!| | !_ _ _ _ _ _ _ _ _ _ _!|
| : : | | : |
| ******************| |************************|
| * Packet (M&C) *| |* Photonic (M&C) *|
| ******************| |************************|
| : | | : : : |
| : | | : : : |
| : | | : : : |
+------------*NC*----+ +*NC**OG*------------*c*-+
\/ \/ \/ v
:: :: :: :
:+---+-------+: :: :
+---+---------+ :: :
:: :: :
/\ /\ ^
+--------------*NC*---------*OG*---+ +-*c*-+
| Device with Photonic plugs | | ~ |
+----------------------------------+ +-----+
¶
Figure 7: Control hierarchy partitioned by network technology domain¶
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 balancing capability (in orchestrator or IP controller) identified additional bandwidth requirement between devices with packet functions:¶
Orchestrator requests photonic control capabilities (planning, routing, provisioning etc.) to determine appropriate details to connect relevant devices with packet functions:¶
Photonic control identifies optimum route(s), determines use of ROADMs/Regens etc. and selects appropriate plugs with settings:¶
Depending upon policy the photonic controller:¶
Note that the solution has plug type, plug setting, fiber interconnect and lane setting details.¶
Photonic controller now has photonic intent and full solution.¶
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).¶
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).¶
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).¶
Photonic controller tests plug-plug and coordinates any loopbacks, PRBS settings, measurements along the path etc.¶
The photonic controller enables photonic path:¶
Highlight the possible need to adjust the transponder during the protection activity.¶
TBD¶
Highlight the possible need to adjust the transponder coordinated as part of the network grooming activity.¶
TBD¶
This document has considered control of photonic 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 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.¶
This document has no IANA actions.¶