Architecture for control of photonic plugs in devices with packet functions
draft-davis-ccamp-photonic-plug-control-arch-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Author | Nigel Davis | ||
| Last updated | 2023-07-10 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-davis-ccamp-photonic-plug-control-arch-00
WG Working Group N. Davis
Internet-Draft Ciena
Intended status: Informational 10 July 2023
Expires: 11 January 2024
Architecture for control of photonic plugs in devices with packet
functions
draft-davis-ccamp-photonic-plug-control-arch-00
Abstract
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
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/.
Davis Expires 11 January 2024 [Page 1]
Internet-Draft PPCA July 2023
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.
Status of This Memo
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 Notice
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Optical network viability . . . . . . . . . . . . . . . . . . 4
2.1. Network with unequipped plugs . . . . . . . . . . . . . . 5
3. Network Contexts . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Basic direct connect . . . . . . . . . . . . . . . . . . 6
3.2. Optical network with ROADMs and Amplifiers . . . . . . . 7
3.3. Optical network with regenerators . . . . . . . . . . . . 7
4. Control Solution . . . . . . . . . . . . . . . . . . . . . . 8
Davis Expires 11 January 2024 [Page 2]
Internet-Draft PPCA July 2023
4.1. Photonic plug in a device with packet functions . . . . . 8
4.2. Abstract control functions - control of the devices . . . 11
4.3. A single controller controlling all aspects of the
network . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.4. A single control fabric with an assembly of interacting
control components . . . . . . . . . . . . . . . . . . . 14
4.5. A traditional control hierarchy partitioned by network
technology domain . . . . . . . . . . . . . . . . . . . . 14
5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.1. Packet Network Capacity growth . . . . . . . . . . . . . 16
5.1.1. Initial configuration . . . . . . . . . . . . . . . . 16
5.1.2. Requirement for additional capacity . . . . . . . . . 16
5.1.3. Developing the solution . . . . . . . . . . . . . . . 16
5.1.4. Evaluating the solution . . . . . . . . . . . . . . . 17
5.1.5. Acquiring the plug . . . . . . . . . . . . . . . . . 17
5.1.6. Lane settings . . . . . . . . . . . . . . . . . . . . 17
5.1.7. Plug installation and power-up . . . . . . . . . . . 18
5.1.8. Commissioning . . . . . . . . . . . . . . . . . . . . 18
5.1.9. Path enabled . . . . . . . . . . . . . . . . . . . . 18
5.2. Packet Network rearrangement . . . . . . . . . . . . . . 18
5.3. Restoration of photonic service . . . . . . . . . . . . . 18
5.4. Rearrangement and grooming of the photonic network . . . 19
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
9. Informative References . . . . . . . . . . . . . . . . . . . 20
Appendix A. Problem/Solution Examples . . . . . . . . . . . . . 20
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20
1. 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.
Davis Expires 11 January 2024 [Page 3]
Internet-Draft PPCA July 2023
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.
2. 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
Davis Expires 11 January 2024 [Page 4]
Internet-Draft PPCA July 2023
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.
2.1. 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.
+---+
|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.
Davis Expires 11 January 2024 [Page 5]
Internet-Draft PPCA July 2023
3. 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"
3.1. 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.
Router A Router B
+---+ IP Link +---+
|ixi|- - - - - - - -|ixi|
| | Packet | |
|...|......................|...|
| | Optical | |
| +----+Plug A Plug B+----+ |
| {E |- - - - - -| E} |
| [O | | O] |
| [~ }================{ ~] |
| +----+ +----+ |
| | | |
+---+ +---+
Davis Expires 11 January 2024 [Page 6]
Internet-Draft PPCA July 2023
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.
3.2. 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.
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
3.3. 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.
Davis Expires 11 January 2024 [Page 7]
Internet-Draft PPCA July 2023
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
4. 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
4.1. 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
Davis Expires 11 January 2024 [Page 8]
Internet-Draft PPCA July 2023
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.
:: :: :
/\ /\ :
+--------------*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 |
+---------------------------------+
Davis Expires 11 January 2024 [Page 9]
Internet-Draft PPCA July 2023
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 (M&C)
* _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.
Davis Expires 11 January 2024 [Page 10]
Internet-Draft PPCA July 2023
4.2. 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.
Davis Expires 11 January 2024 [Page 11]
Internet-Draft PPCA July 2023
***********************
* 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.
Davis Expires 11 January 2024 [Page 12]
Internet-Draft PPCA July 2023
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
4.3. 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.
Davis Expires 11 January 2024 [Page 13]
Internet-Draft PPCA July 2023
4.4. 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.
4.5. 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.
Davis Expires 11 January 2024 [Page 14]
Internet-Draft PPCA July 2023
+--------------------------------------+
| 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
Davis Expires 11 January 2024 [Page 15]
Internet-Draft PPCA July 2023
5. 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
5.1. Packet Network Capacity growth
5.1.1. 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
5.1.2. 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
5.1.3. 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.)
Davis Expires 11 January 2024 [Page 16]
Internet-Draft PPCA July 2023
5.1.4. 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.
5.1.5. Acquiring the plug
* Plug procurement or shipping is initiated
* Work orders are initiated for plug installation and cabling where
necessary
5.1.6. 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.
Davis Expires 11 January 2024 [Page 17]
Internet-Draft PPCA July 2023
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).
5.1.7. 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).
5.1.8. Commissioning
Photonic controller tests plug-plug and coordinates any loopbacks,
PRBS settings, measurements along the path etc.
5.1.9. Path enabled
The photonic controller enables photonic path:
* device with packet functions detects link
* device with packet functions network uses new capacity
5.2. Packet Network rearrangement
TBD
5.3. Restoration of photonic service
Highlight the possible need to adjust the transponder during the
protection activity.
TBD
Davis Expires 11 January 2024 [Page 18]
Internet-Draft PPCA July 2023
5.4. Rearrangement and grooming of the photonic network
Highlight the possible need to adjust the transponder coordinated as
part of the network grooming activity.
TBD
6. 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.
Davis Expires 11 January 2024 [Page 19]
Internet-Draft PPCA July 2023
Direct control of the photonic plug by the photonic control functions
(in the photonic controller) appears to be a natural and valid
approach.
7. Security Considerations
None
8. IANA Considerations
This document has no IANA actions.
9. 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/
Appendix A. Problem/Solution Examples
TBD
Acknowledgments
Author's Address
Nigel Davis
Ciena
Email: ndavis@ciena.com
Davis Expires 11 January 2024 [Page 20]