Internet DRAFT - draft-davis-ccamp-photonic-plug-control-arch
draft-davis-ccamp-photonic-plug-control-arch
CCAMP Working Group N. Davis
Internet-Draft R. Rokui
Intended status: Informational Ciena
Expires: 1 April 2024 P. Maheshwari
Airtel
U. Joshi
Jio Reliance
B. Vadhadiya
H. Dave
Vi
A. Guo
Futurewei Technologies
29 September 2023
Control Architecture of Optical Pluggables in Packet Devices Under ACTN
POI Framework
draft-davis-ccamp-photonic-plug-control-arch-02
Abstract
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.
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, et al. Expires 1 April 2024 [Page 1]
Internet-Draft PPCA September 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 1 April 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Architectural Approaches for Control of Converged Packet Over
Optical Networks . . . . . . . . . . . . . . . . . . . . 8
4. Architectural Option-3 for Control of Converged Packet Over
Optical Networks . . . . . . . . . . . . . . . . . . . . 11
5. Solution Details of proposed New Architectural Approach . . . 13
5.1. Optical Plug in a Device with Packet Functions . . . . . 13
Davis, et al. Expires 1 April 2024 [Page 2]
Internet-Draft PPCA September 2023
5.2. Optical Network Configuration and Operation . . . . . . . 16
5.2.1. Optical network boundary . . . . . . . . . . . . . . 17
5.2.2. Optical network complexity and configuration/control
implications . . . . . . . . . . . . . . . . . . . . 17
5.2.3. Coherent plug commissioning and operation . . . . . . 18
5.3. Architecture of Converged packet optical Control
Solution . . . . . . . . . . . . . . . . . . . . . . . . 18
5.3.1. Generalized control . . . . . . . . . . . . . . . . . 18
5.3.2. Control flow . . . . . . . . . . . . . . . . . . . . 18
5.3.3. Control Solution structure . . . . . . . . . . . . . 19
5.3.4. Separation of Control Solution . . . . . . . . . . . 19
5.3.5. Evolution of Control Solution . . . . . . . . . . . . 19
6. Architectural Requirements to Achieve full Automation in Packet
over Optical Converged Networks . . . . . . . . . . . . . 20
6.1. R1: There shall be a "single functional entity" responsible
for optical services life cycle management . . . . . . . 20
6.2. R2: There shall be a clear distinction between functional
components of optical control vs. its realization . . . 21
6.3. R3: Existing operational practices shall be supported . . 22
6.4. R4: Various existing YANG Data Models shall be
accommodated . . . . . . . . . . . . . . . . . . . . . . 23
6.5. R5: Holistic control of optical network shall follow clear
demarcation . . . . . . . . . . . . . . . . . . . . . . 23
6.6. R6: Higher level controller shall be optional . . . . . . 24
6.7. R7: Urgent optical control actions shall be supported in a
timely manner . . . . . . . . . . . . . . . . . . . . . 24
6.8. R8: The solution shall minimize fragmentation of optical
parameter provisioning . . . . . . . . . . . . . . . . . 24
6.9. R9: Access to the coherent plug properties shall be as
transparent as possible . . . . . . . . . . . . . . . . 24
6.10. R10: Network information shall take direct path to relevant
controller . . . . . . . . . . . . . . . . . . . . . . . 24
6.11. R11: Multi-layer operational benefits shall be
addressed . . . . . . . . . . . . . . . . . . . . . . . 25
6.12. R12: Coherent plug telemetry data shall be collected . . 25
6.13. R13: Mix of plugs and Transponders/Muxponders (inc.
Regens) shall be supported . . . . . . . . . . . . . . . 25
6.14. R14: Optical deployments with protection/restoration shall
be supported . . . . . . . . . . . . . . . . . . . . . . 25
6.15. R15: Evolution to expected future controller deployment
approaches shall be supported . . . . . . . . . . . . . 25
6.16. R16: Evolution to future packet processing deployment
approaches . . . . . . . . . . . . . . . . . . . . . . . 26
7. How Option-3 Addresses the Architecture Requirements . . . . 26
8. Packet over optical Use-cases . . . . . . . . . . . . . . . . 30
8.1. Use-case: Optical service creation to support creation of a
new IP link . . . . . . . . . . . . . . . . . . . . . . . 30
Davis, et al. Expires 1 April 2024 [Page 3]
Internet-Draft PPCA September 2023
8.2. Use-case: Optical service modification to support increase/
decrease B/W of IP link . . . . . . . . . . . . . . . . . 31
8.3. Use-case: Considering the optical viability during IP link
creation . . . . . . . . . . . . . . . . . . . . . . . . 32
8.4. Use-case: Interaction between coherent plugs and optical
network during restoration/protection of optical
services . . . . . . . . . . . . . . . . . . . . . . . . 33
8.5. Use-case: Plug coordination to support Optical network
rebalancing/de-fragmentation . . . . . . . . . . . . . . 34
8.6. Uses-case related to monitoring and telemetry
collection . . . . . . . . . . . . . . . . . . . . . . . 34
8.7. Use-case when one side is plug and other side is
xPonder . . . . . . . . . . . . . . . . . . . . . . . . . 34
8.8. Use-case for Regen . . . . . . . . . . . . . . . . . . . 34
8.9. Use-case: Optical service life cycle management . . . . . 34
9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 37
10. Security Considerations . . . . . . . . . . . . . . . . . . . 38
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
12.1. Normative References . . . . . . . . . . . . . . . . . . 38
12.2. Informative References . . . . . . . . . . . . . . . . . 38
Appendix A. Multi-layer Packet Over Optical Integration . . . . 39
Appendix B. Appendix: Optical network viability . . . . . . . . 43
B.1. Network with unequipped plugs . . . . . . . . . . . . . . 44
Appendix C. Network Deployment Contexts . . . . . . . . . . . . 45
C.1. Basic direct connect . . . . . . . . . . . . . . . . . . 45
C.2. Optical network with ROADMs and Amplifiers . . . . . . . 46
C.3. Optical network with regenerators . . . . . . . . . . . . 46
Appendix D. Control Architecture Options . . . . . . . . . . . . 47
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 47
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48
1. Terminology
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:
* Coherent plug: Coherent optical module refers to hot-pluggable
coherent optical transceiver that uses coherent modulation
(BPSK/QPSK/QAM) rather than amplitude modulation (RZ/NRZ/PAM4) and
is typically used in high-bandwidth data communications
applications.
* Coherent pluggable: Another term for coherent plug
Davis, et al. Expires 1 April 2024 [Page 4]
Internet-Draft PPCA September 2023
* Optical controller: The control functions specializing in
management/control of optical and photonic functions (virtual or
physical) including network provisioning, assurance, viability
analysis, network protection and restoration, network rebalancing
and so on.
* Packet controller: The control functions specializing in
management/control of packet functions (virtual or physical).
* MDSC: Multi-Domain Service Coordinator. See Framework for
Abstraction and Control of TE Networks (ACTN) RFC 8453
* PNC: Provisioning Network Controller. See Framework for
Abstraction and Control of TE Networks (ACTN) RFC 8453
* P-PNC: Packet PNC. Same as Packet controller
* O-PNC: Optical PNC. Same as Optical controller
* ROADM: A reconfigurable optical add-drop multiplexer that enables
switching of bands of photonic spectrum (or wavelengths) from a
wavelength-division multiplexing (WDM) system.
* Transponder: An optical transponder, short for "transmitter-
receiver," is a device in optical communication systems which
converts incoming electrical signal into optical signals for
transmission over a fiber-optic network and vice versa. Optical
transponders are essential components in modern fiber-optic
networks and are used for various purposes, including signal
regeneration, wavelength conversion, signal multiplexing, and
format conversion.
* Muxponder: A muxponder, short for "multiplexer-demultiplexer-
transponder," is a device used in optical communication systems to
aggregate multiple lower-speed data streams into a higher-speed
signal for transmission over a fiber-optic link. It also performs
the reverse function by demultiplexing and converting incoming
high-speed signals back into individual lower-speed data streams
at the receiving end. Muxponders are commonly used in wavelength
division multiplexing (WDM) systems to optimize the utilization of
optical network resources and increase data capacity.
* DWDM: Dense wavelength-division multiplexing is an optical fiber
multiplexing technology that increases the bandwidth of fiber
networks. DWDM combines data signals from sources over a single
pair of optical fibers and it maintains separation of the data
streams
Davis, et al. Expires 1 April 2024 [Page 5]
Internet-Draft PPCA September 2023
* CMIS: The Content Management Interoperability Services defines a
management communication interface together with a generic
management interaction protocol between hosts (e.g., packet
devices) and managed modules (e.g. optical pluggable). See
[OIF-CMIS]* Coherent plug: A small form factor module, supporting
a transceiver with coherent optics, that plugs into a module in a
device such as an IP router and is used in high-bandwidth data
communications applications. It is typically hot-pluggable.
* FEC: Forward Error Correction where the transmitter sends
additional data that enables the receiver to correct errors in the
received signal
* gNMI: gRPC Network Management Interface. gNMI is an gRPC-based
protocol for the both modification/retrieval of configuration from
a target device, and control/generation of telemetry streams from
a target device to a data collection system. The intention is
that a single gRPC service definition can cover both configuration
and telemetry. All messages within the gRPC service definition
are defined as protocol buffers.
* I2C: Inter-Integrated Circuit (pronounced as “eye-squared-C”),
alternatively known as I2C or IIC, is a synchronous, multi-master/
multi-slave, packet switched, single-ended, serial communication
bus and is widely used for attaching lower-speed peripheral ICs to
processors and microcontrollers in short-distance, intra-board
communication.
2. Introduction
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
Davis, et al. Expires 1 April 2024 [Page 6]
Internet-Draft PPCA September 2023
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:
* Network technology based partitioned domain controllers (i.e.,
separate packet and optical controller devices), with an optional
higher level controller to deal with overall network abstractions
* Single controller dealing with all network technologies
Davis, et al. Expires 1 April 2024 [Page 7]
Internet-Draft PPCA September 2023
* 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
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.
3. Architectural Approaches for Control of Converged Packet Over
Optical Networks
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:
* Option-1: Dual SBI management of packet devices (i.e., IP routers)
* Option-2: Single SBI management of packet devices (i.e., IP
routers)
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:
Davis, et al. Expires 1 April 2024 [Page 8]
Internet-Draft PPCA September 2023
* Device discovery, poll or stream configuration, state and static
capabilities
* Performance monitoring, periodically poll or stream performance
counters
* Fault notification, received asynchronous alarm notifications
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
Figure 1: Option-1 Dual SBI management Scenario
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,
Davis, et al. Expires 1 April 2024 [Page 9]
Internet-Draft PPCA September 2023
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
Figure 2: Option-2 Single SBI management Scenario
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.
Davis, et al. Expires 1 April 2024 [Page 10]
Internet-Draft PPCA September 2023
* Option-3: Read/Write Optical controller access with dual SBI
management on packet devices
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.
* Section 4 describes the architecture of option-3
* Section 5 outlines the details of the new architectural approach
* Section 6 describes the packet over optical architectural
requirements for achieving full automation
* Section 7 demonstrates how option-3 addresses the packet over
optical architecture requirements
* Section 8 describes a few multi-layer use-cases in a packet over
optical networks
The YANG models are out of scope of this draft.
4. Architectural Option-3 for Control of Converged Packet Over Optical
Networks
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.
Davis, et al. Expires 1 April 2024 [Page 11]
Internet-Draft PPCA September 2023
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
Figure 3: Option-3 Dual SBI architecture with Read/Write Access
Davis, et al. Expires 1 April 2024 [Page 12]
Internet-Draft PPCA September 2023
5. Solution Details of proposed New Architectural Approach
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.
5.1. Optical Plug in a Device with Packet Functions
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:
* Separation of packet and coherent plug data where the packet
controller has read/write access to the packet device data through
(A) and the optical controller has read/write access to the
coherent plug data through (B).
* Read only data to be made available through (D) as there is some
information that both controllers need to see
* Access to coherent plug data to the plug through (E) and access to
packet data to the packet data path through (F)
* The actual data flow between the coherent plug and the packet data
function through (G)
* The flow of photonic signal through (H) that may also carry
signalling from the optical device to the coherent plug
Davis, et al. Expires 1 April 2024 [Page 13]
Internet-Draft PPCA September 2023
|------------| |------------|
| 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
Figure 4: Network Device with packet function and an optical plug
The packet device has several possible distinct realizations in
Figure 4:
1. Single config structure with both packet data and plug data in a
single model tree where (A) and (B) are conceptually separate
accesses, via separate sessions (at the same IP address)
Davis, et al. Expires 1 April 2024 [Page 14]
Internet-Draft PPCA September 2023
2. Two distinct config structures, one for packet data and another
one for plug data, where (A) accesses the packet data and (B)
accesses the plug data. Interfaces (A) and (B) have distinct IP
addresses and may use different transport protocols (e.g.,
interface (A) may use Netconf and interface (B) may use gRPC).
3. Two distinct config structures, one for packet data and another
one for plug data, where (A) accesses the packet data and
combination of (B) and (H) provide R/W access for plug data in
some combinations
4. Two distinct config structures, one for packet data and another
one for plug data, where (A) accesses the packet data and another
method provides plug direct method (e.g., out of band management
via data path)
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:
* Partition the responsibility by trust where it is understood by
the designers of each controller what access the controller should
have
* Provide restricted control using access control list protection
* Include use of config locking to ensure partial configs are not
applied (as some configuration actions may require several
parameters to be set to define a consistent configuration)
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.
Davis, et al. Expires 1 April 2024 [Page 15]
Internet-Draft PPCA September 2023
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:
1. The settings applied by the optical controller are applied to
both coherent plugs and packet data function at interface (G)
2. The settings applied by the optical controller to coherent plugs
and are made visible to the packet controller via (D) and the
packet controller configures the packet data functions at (G) to
match
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.
5.2. Optical Network Configuration and Operation
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).
Davis, et al. Expires 1 April 2024 [Page 16]
Internet-Draft PPCA September 2023
5.2.1. Optical network boundary
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.
5.2.2. Optical network complexity and configuration/control
implications
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.
Davis, et al. Expires 1 April 2024 [Page 17]
Internet-Draft PPCA September 2023
5.2.3. Coherent plug commissioning and 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.
5.3. Architecture of Converged packet optical Control Solution
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.
5.3.1. Generalized control
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.
5.3.2. Control flow
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:
* include the need for installation of new pluggables in existing
routers
Davis, et al. Expires 1 April 2024 [Page 18]
Internet-Draft PPCA September 2023
* entail rerouting of existing optical services
* enhancement to existing optical services to include protection/
restoration
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.
5.3.3. Control Solution structure
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.
5.3.4. Separation of Control Solution
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.
5.3.5. Evolution of Control Solution
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.
Davis, et al. Expires 1 April 2024 [Page 19]
Internet-Draft PPCA September 2023
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.
6. Architectural Requirements to Achieve full Automation in Packet over
Optical Converged Networks
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:
6.1. R1: There shall be a "single functional entity" responsible for
optical services life cycle management
The following aspects of optical service life cycle shall be managed
and controlled by a single functional entity in the network.
* Discovery of Optical networks inlcuding coherent pluggables,
ROADMs, Amps, Regen, Transponder/Muxponder etc.
* Optical services viability
* End-to-end Optical services configuration/modification from plug
to plug (or from transponder to transponder).
* Optical services telemetry collection and monitoring performances/
faults including the asynchronous notificatons collected including
coherent pluggables.
Davis, et al. Expires 1 April 2024 [Page 20]
Internet-Draft PPCA September 2023
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).
6.2. R2: There shall be a clear distinction between functional
components of optical control vs. its realization
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 | .
Davis, et al. Expires 1 April 2024 [Page 21]
Internet-Draft PPCA September 2023
. ----------------- .
. ...............
. .
. --------------- . ---------------
. | 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)
Figure 5: A few Packet over Optical Realization Schemes
6.3. R3: Existing operational practices shall be supported
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
Davis, et al. Expires 1 April 2024 [Page 22]
Internet-Draft PPCA September 2023
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.
6.4. R4: Various existing YANG Data Models shall be accommodated
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.
6.5. R5: Holistic control of optical network shall follow clear
demarcation
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.
Davis, et al. Expires 1 April 2024 [Page 23]
Internet-Draft PPCA September 2023
6.6. R6: Higher level controller shall be optional
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.
6.7. R7: Urgent optical control actions shall be supported in a timely
manner
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.
6.8. R8: The solution shall minimize fragmentation of optical parameter
provisioning
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.
6.9. R9: Access to the coherent plug properties shall be as transparent
as possible
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.
6.10. R10: Network information shall take direct path to relevant
controller
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).
Davis, et al. Expires 1 April 2024 [Page 24]
Internet-Draft PPCA September 2023
6.11. R11: Multi-layer operational benefits shall be addressed
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.
6.12. R12: Coherent plug telemetry data shall be collected
Telemetry data and any change in state should be provided by the plug
to the optical controller via a stream in a timely manner.
6.13. R13: Mix of plugs and Transponders/Muxponders (inc. Regens)
shall be supported
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.
6.14. R14: Optical deployments with protection/restoration shall be
supported
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.
6.15. R15: Evolution to expected future controller deployment
approaches shall be supported
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.
Davis, et al. Expires 1 April 2024 [Page 25]
Internet-Draft PPCA September 2023
6.16. R16: Evolution to future packet processing deployment approaches
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.
7. How Option-3 Addresses the Architecture Requirements
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.
Davis, et al. Expires 1 April 2024 [Page 26]
Internet-Draft PPCA September 2023
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
Davis, et al. Expires 1 April 2024 [Page 27]
Internet-Draft PPCA September 2023
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.
Davis, et al. Expires 1 April 2024 [Page 28]
Internet-Draft PPCA September 2023
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
Davis, et al. Expires 1 April 2024 [Page 29]
Internet-Draft PPCA September 2023
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.
8. Packet over optical 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 optical service
8.1. Use-case: Optical service creation to support creation of a new IP
link
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.
Davis, et al. Expires 1 April 2024 [Page 30]
Internet-Draft PPCA September 2023
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 6: Use-case#1: Optical Service Creation to Support
Creation of a New IP Link
8.2. Use-case: Optical service modification to support increase/
decrease B/W of IP link
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:
Davis, et al. Expires 1 April 2024 [Page 31]
Internet-Draft PPCA September 2023
* The reduced new optical service rate from 400G to 200G should be
communicate to coherent plugs for further re-tuning and re-
alignment
* The reduced new rate needed to be communicate to packet engine on
both routers A and B which allows them to further re-configure the
IP ports A and B accordingly [Reza any other aspects???]
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 | | | |
| +------+ +-------+ +-------+ +-------+ +------+ |
| | | |
+----+ +----+
Figure 7: Use-case#2: Optical Service Modification
8.3. Use-case: Considering the optical viability during IP link
creation
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.
Davis, et al. Expires 1 April 2024 [Page 32]
Internet-Draft PPCA September 2023
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.
8.4. Use-case: Interaction between coherent plugs and optical network
during restoration/protection of optical services
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 +----+
Figure 8: Use-case#3: Interaction between Coherent Plug and
Optical Network during optical service restoration/protection
Davis, et al. Expires 1 April 2024 [Page 33]
Internet-Draft PPCA September 2023
8.5. Use-case: Plug coordination to support Optical network
rebalancing/de-fragmentation
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
8.6. Uses-case related to monitoring and telemetry collection
Editor's note: This chapter will be completed.
8.7. Use-case when one side is plug and other side is xPonder
Editor's note: This chapter will be completed.
8.8. Use-case for Regen
Editor's note: This chapter will be completed.
8.9. Use-case: Optical service life cycle management
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:
Davis, et al. Expires 1 April 2024 [Page 34]
Internet-Draft PPCA September 2023
Orchestrator requests optical 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.
Optical 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 optical controller:
- If policy dictates that orchestrator must evaluate options (and
there are options). Optical controller passes details to the
orchestrator of the resolved intent request. The optical
controller provides abstracted info to the orchestrator for
evaluation. The orchestrator selects option and informs the
optical controller.
- If the optical controller is in charge of selecting a single
solution (or there is only a single solution). Optical
controller informs the orchestrator of the solution.
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
- Plug procurement or shipping is initiated
- Work orders are initiated for plug installation and cabling
where necessary
Lane settings:
Davis, et al. Expires 1 April 2024 [Page 35]
Internet-Draft PPCA September 2023
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).
- 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 optical 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 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:
Davis, et al. Expires 1 April 2024 [Page 36]
Internet-Draft PPCA September 2023
- device with packet functions detects link
- device with packet functions network uses new capacity
9. Conclusion
This document has considered control of optical 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 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.
Davis, et al. Expires 1 April 2024 [Page 37]
Internet-Draft PPCA September 2023
10. Security Considerations
11. IANA Considerations
This document has no IANA actions.
12. References
12.1. Normative References
[gNMI-spec]
"gRPC Network Management Interface (gNMI)", 25 May 2023,
<https://www.openconfig.net/docs/gnmi/gnmi-specification>.
[OIF-400ZR]
"OIF Implementation Agreement 400ZR", 10 March 2020,
<https://www.oiforum.com/wp-content/uploads/OIF-400ZR-
01.0_reduced2.pdf>.
[OIF-CMIS] "OIF Implementation Agreement (IA) Common Management
Interface Specification (CMIS))", 27 April 2022,
<https://www.oiforum.com/wp-content/uploads/OIF-CMIS-
05.2.pdf>.
[Open-Config]
"OpenConfg", 27 April 2022, <https://www.openconfig.net>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
12.2. Informative References
[draft-ietf-teas-actn-poi-applicability]
"Applicability of Abstraction and Control of Traffic
Engineered Networks (ACTN) to Packet Optical Integration
(POI)", 1 January 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-teas-
actn-poi-applicability-09>.
[draft-poidt-ccamp-actn-poi-pluggable]
"Applicability of Abstraction and Control", 1 January
2024, <https://datatracker.ietf.org/doc/html/draft-poidt-
ccamp-actn-poi-pluggable-02#ref-MANTRA-whitepaper-IPoWDM>.
Davis, et al. Expires 1 April 2024 [Page 38]
Internet-Draft PPCA September 2023
[ITU-T_G.sup39]
"ITU-T Recommendation G.Sup39 (02/16): Optical system
design and engineering considerations", 26 February 2016,
<https://www.itu.int/rec/T-REC-G.Sup39-201602-I/en>.
[MANTRA-whitepaper-IPoWDM-convergent-SDN-architecture]
"IPoWDM convergent SDN architecture - Motivation,
technical definition & challenges", 31 August 2022,
<https://telecominfraproject.com/wp-content/uploads/
TIP_OOPT_MANTRA_IP_over_DWDM_Whitepaper-Final-
Version3.pdf>.
[openconfig-platform]
"openconfig-platform", 6 February 2023,
<https://github.com/openconfig/public/blob/master/release/
models/platform/openconfig-platform.yang>.
[openconfig-platform-transceiver]
"openconfig-platform-transceiver", 6 February 2023,
<https://github.com/openconfig/public/blob/master/release/
models/platform/openconfig-platform-transceiver.yang>.
[openconfig-terminal-device]
"openconfig-terminal-device", 6 February 2023,
<https://github.com/openconfig/public/blob/master/release/
models/optical-transport/openconfig-terminal-device.yang>.
Appendix A. Multi-layer Packet Over Optical Integration
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.
Davis, et al. Expires 1 April 2024 [Page 39]
Internet-Draft PPCA September 2023
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)
Figure 9: Packet over Optics Disaggregated Deployment Model
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
Davis, et al. Expires 1 April 2024 [Page 40]
Internet-Draft PPCA September 2023
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
Figure 10: Packet over Optics with Plugs Model
Davis, et al. Expires 1 April 2024 [Page 41]
Internet-Draft PPCA September 2023
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:
* High Capacity: Optical networks leverage the immense bandwidth of
fiber-optic cables, allowing them to transmit a large volume of
data simultaneously
* Low Latency: Optical signals travel at nearly the speed of light,
resulting in minimal propagation delay. This low latency is
crucial for real-time applications such as video conferencing,
online gaming, and financial transactions.
* Long Reach: Optical signals can travel over extensive distances
without significant signal degradation. This makes long-haul
optical networks ideal for interconnecting geographically distant
locations.
* Signal Regeneration: Even over long distances, optical signals
need periodic amplification to maintain their strength. Long-haul
optical networks incorporate regenerators or amplifiers at
intermediate points to ensure signal integrity.
* Modulation Techniques: Advanced modulation schemes, such as
coherent modulation, are used to encode multiple bits of data onto
a single optical signal. This improves spectral efficiency and
enables high data rates.
* Wavelength Division Multiplexing (WDM): WDM allows multiple
signals of different wavelengths (colors of light) to be
transmitted concurrently over the same fiber. This further
enhances the network's capacity and efficiency.
* Optical Cross-Connects: Optical cross-connects enable flexible
routing and switching of optical signals, allowing dynamic
provisioning of network resources to accommodate changing traffic
patterns.
* Error Correction: Long-haul optical networks employ powerful error
correction techniques to mitigate signal distortions and losses,
ensuring reliable data transmission.
* Resiliency and Protection: These networks often incorporate
redundancy and protection mechanisms to ensure network
availability in case of fiber cuts or equipment failures.
Davis, et al. Expires 1 April 2024 [Page 42]
Internet-Draft PPCA September 2023
* Multi-Protocol Support: Long-haul packet over optical networks can
carry various types of data, including Ethernet, IP, and other
protocols, making them versatile for different applications.
* Network Management and Control: Centralized management systems
monitor network performance, optimize traffic routing, and
facilitate rapid provisioning of resources.
|----------| |----------|
| | 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)
Figure 11: Packet over Optics with Plugs along with ROADM network
Model
Appendix B. Appendix: 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.
Davis, et al. Expires 1 April 2024 [Page 43]
Internet-Draft PPCA September 2023
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.
B.1. Network with unequipped plugs
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 | | | |
| +-+ +-------+ +-------+ +-------+ +------+ |
| | | |
+----+ +----+
Figure 12: Devices with packet functions, with no equipped plugs,
and a optical network
Davis, et al. Expires 1 April 2024 [Page 44]
Internet-Draft PPCA September 2023
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.
Appendix C. Network Deployment 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 optical plug in the optical domain. The devices
with packet functions are in "packet sites" that are some distance
apart.
C.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 (between Router Ports) +----+
| |.............................................................| |
| | | |
| | Optical Service (Plug-to-Plug) | |
| | ..................................................... | |
| +------+ +------+ |
| | | | | |
| |Plug A| |Plug B| |
| | |===================================================| | |
| | | | | |
| +------+ +------+ |
| | | |
+----+ +----+
Figure 13: Direct connection deployment
The direct interconnect may be viable with standard ZR plugs, or it
may need a more capable vendor proprietary plug configurations.
Davis, et al. Expires 1 April 2024 [Page 45]
Internet-Draft PPCA September 2023
C.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 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 | | | |
| +------+ +-------+ +-------+ +-------+ +------+ |
| | | |
+----+ +----+
Figure 14: Optical network with ROADMs and amplifiers deployment
C.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 optical protection etc.
Davis, et al. Expires 1 April 2024 [Page 46]
Internet-Draft PPCA September 2023
Router A Router B
+----+ IP Link (between Router Ports). +----+
| |.............................................................| |
| | | |
| | | |
| | Optical Services | |
| | +-------+ | |
| | ..................... | | ..................... | |
| +------+ | | +------+ |
| | | | | | | |
| |Plug A| +-------+ | | +-------+ |Plug B| |
| | |======| ROADM |======| Regen |======| ROADM |======| | |
| | | | + Amp | | | | + Amp | | | |
| +------+ +-------+ +-------+ +-------+ +------+ |
| | | |
+----+ +----+
Figure 15: Optical network with ROADMs and Regenerators deployment
Appendix D. Control Architecture Options
This section describes alternative control architecture aiming at
disaggregated could-based realization solutions.
Acknowledgments
Thanks to Sergio Belotti from Nokia (sergio.belotti@nokia.com) for
his contribution to this document.
Contributors
Italo Busi
Huawei Technologies
Email: italo.busi@huawei.com
Ian Alderdice
Ciena
Email: ialderdi@ciena.com
Mark Gibbon
Ciena
Email: mgibbon@ciena.com
Qilei Wang
ZTE
Davis, et al. Expires 1 April 2024 [Page 47]
Internet-Draft PPCA September 2023
Email: wang.qilei@zte.com.cn
Authors' Addresses
Nigel Davis
Ciena
Email: ndavis@ciena.com
Reza Rokui
Ciena
Email: rrokui@ciena.com
Praveen Maheshwari
Airtel
Email: Praveen.Maheshwari@airtel.com
Uday Joshi
Jio Reliance
Email: uday.n.joshi@ril.com
Bhavit Vadhadiya
Vi
Email: bhavit.vadhadiya1@vodafoneidea.com
Xitiz Harshad Dave
Vi
Email: xitij.dave@vodafoneidea.com
Aihua Guo
Futurewei Technologies
Email: aihuaguo.ietf@gmail.com
Davis, et al. Expires 1 April 2024 [Page 48]
