Control Architecture of Optical Pluggables in Packet Devices Under ACTN POI Framework

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

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¶
• 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¶
• 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 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¶
• 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:¶

• 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

In option-2 shown in Figure 2, the packet controller is the only control component which has access to the packet device, including the pluggables. The packet controller implements all management capabilities. The packet controller is in charge of the entire management life cycle of the pluggables including discovery, configuration/adjustment, monitoring performances and faults (via the asynchronous notifications coming for the pluggable). The information collected needs to be exposed to the optical controller via the packet controller NBI and higher layer controller. The information includes physical impairment data needed for the computation and validation of the optical channel.¶

For both option-1 and 2, the higher layer controller MDSC is required not only to coordinate the end-to-end optical service configuration, but to provides the multi-layer coordination between IP and optical layers.¶

                       -------------------
                       |   Higher layer  |
                       |    Controller   |
                       |   (e.g. MDSC)   |
                       -------------------
                              ^    ^
                              |    |
                     |--------|    |-------|  NBI
                     v                     v
              ---------------        ---------------
              | Packet      |        | Optical     |
              | Controller  |        | Controller  |
              |(e.g. P-PNC) |        |(e.g. O-PNC) |
              ---------------        ---------------
                    ^                      ^
      (R/W for plug |                      |
       and packet)  |                      |  SBI
                    v                      v
                /----------\          /----------\
               /   Packet   \        /            \
              /    Devices   \      /   Optical    \
              \      +       /      \   Devices    /
               \   Plugs    /        \            /
                \----------/          \----------/

  Legend:
    Optical Devices: ROADM + Amplifier + Regen
    Packet Devices: Routers

This draft extends draft [draft-poidt-ccamp-actn-poi-pluggable] by providing an additional architectural option-3 to control the multi-layer packet optical network when optical coherent plugs are equipped in the packet device. This third option enables direct control of the coherent plug by the optical controller.¶

• 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.¶

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

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.¶

        |------------|     |------------|
        | 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

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:¶

            .....................................
            .    -----------------              .
            .    |  Higher layer |              .
            .    |   Controller  |              .
            .    -----------------              .
            ............                        .
                       .                        .
     ---------------   .    ---------------     .
     | Packet      |   .    | Optical     |     .
     | Controller  |   .    | Controller  |     .
     ---------------   .    ---------------     .
                       ..........................
                  (Realizaton A)

  ....................................
  .              -----------------   .
  .              |  Higher layer |   .
  .              |   Controller  |   .
  .              -----------------   .
  .                    ...............
  .                    .
  .  ---------------   .    ---------------
  .  | Packet      |   .    | Optical     |
  .  | Controller  |   .    | Controller  |
  .  ---------------   .    ---------------
  ......................
                  (Realizaton B)

  ..............................................
  .              -----------------             .
  .              |  Higher layer |             .
  .              |   Controller  |             .
  .              -----------------             .
  .                                            .
  .  ---------------        ---------------    .
  .  | Packet      |        | Optical     |    .
  .  | Controller  |        | Controller  |    .
  .  ---------------        ---------------    .
  ..............................................
                   (Realizaton C)

  .....................  ......................
  .  ---------------  .  .  ---------------   .
  .  | Packet      |  .  .  | Optical     |   .
  .  | Controller  |  .  .  | Controller  |   .
  .  ---------------  .  .  ---------------   .
  .....................  ......................
                   (Realizaton D)
 (In this realization there is no need for higer layer controller)

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.¶

• In networks with limited deployment of basic optics where the business focus is mainly packet, there may be a single controller dealing with both the packet and the basic optical network. If more sophisticated optical capabilities are deployed and optical controller will become necessary. The operator may then choose to separate the optical and packet control, where option-3 focusses, or may choose to unify this control. Unified control will benefit from the direct access to the photonic capabilities of the packet device, as per option-3, especially where protection/restoration is required.¶

• In networks where there is limited packet deployment, where the business focus is mainly optical, there may be a single controller dealing with optical and the limited packet deployment. Option-3 maintains the direct control of optical components when deployed as coherent plugs on packet devices.¶

R4 - Various YANG Data Models shall be accommodated¶

• Requirement R4 states that the solution shall support various existing YANG data models used for current coherent optical solutions for coherent plugs (and various interfaces between the packet and optical controllers).¶

• Option-3 supports this requirement. Referring to Figure 4, the optical controller can use packet device management interface (B) to control the coherent plugs. This interface can for example use the OpenConfig YANG data model [openconfig-platform-transceiver], [openconfig-platform] and [openconfig-terminal-device] over gNMI or any other YANG data models over Netconf, gNMI etc. As a result, the optical controller will have a holistic view of entire optical network from plugs to plugs.¶

R5 - Holistic control of optical network shall follow clear demarcation¶

• Requirement R5 states that the network controllers shall abide by technology boundaries.¶

• Option-3 inherently supports this requirement since the optical controller has access to the entire optical network for both provisioning/fulfilment and monitoring/assurance of optical services from plug to plug including all optical parameters.¶

R6 - Higher level controller shall be optional¶

• Option-3 inherently supports this requirement as there is no need for the higher level controller to be present to configure the coherent plug (since the entire optical network is controlled, managed and monitored directly by a single optical controller).¶

R7 - Urgent optical control actions shall be supported in a timely manner.¶

• Option-3 provides direct access from the optical controller to the coherent plug minimizing the time taken to apply any changes it has determined are necessary. The aim is to minimumize the round trip from detection of an issue in the coherent plug to application of any necessary action. This is achieved by direct access to data and to control of the coherent plug.¶

R8 - Solution shall minimize fragmentation of optical parameter provisioning.¶

• Option-3 minimizes fragmentation of optical parameter provisioning as the optical controller has direct access to all devices with optical capabilities including to the coherent plugs in packet devices.¶

• In many deployments, there will be multiple packet controllers with one optical controller. Clearly, localizing the direct control of the entire optical network to one optical controller minimizes fragmentation of control of the end-to-end optical services (whereas spreading the responsibility of optical services across the multiple packet controllers increases the fragmentation).¶

R9 - Access to the coherent plug properties shall be as transparent as possible.¶

• Option-3 offers direct access to the coherent plugs from the optical controller minimizing the number of intervening functions/devices. It is the optical controller that needs access to the parameters of the coherent plug. The packet controller does not need access to these parameters. Option-3 does not require the packet controller to interpret or map the parameters.¶

• In many deployments, there will be multiple packet controllers, potentially from different vendors, with one optical controller. In these deployment scenarios communication between optical controller and multiple packet controllers either directly or via a higher controller introduces many opportunities for misinterpretation and inappropriate mapping. As a result there is a greater likelihood of failure.¶

R10 - Network information shall take direct path to relevant controller¶

• Option-3 optimizes the path from optical network functions including the coherent plug to the optical controller.¶

• Communication between optical controller and packet controllers either directly or via a higher controller makes the path for communication of the optical parameters longer.¶

R11 - Multi-layer operational benefits shall be addressed¶

• It is beneficial to treat the network as a whole. Considering a packet over optical network, multi-layer operational benefits such as multi-layer optimization, multi-layer assurance, multi-layer resiliency/protection/restoration and multi-layer planning need to be achieved.¶

• Option-3 enables several solution approaches including: - a control hierarchy with a higher controller coordinating the optical controller and packet controllers - a single controller that provides an optimum integration of optical and packet control (both peer and hierarchical strategies as appropriate) - a disaggregated control solution where specialist functions interact together and with the network to provide a view of the whole network¶

R12 - Coherent plug telemetry data shall be collected¶

• Option-3 provides direct access to plug telemetry for the optical controller.¶

R13 - Mix of plugs and Transponders/Muxponders (inc. Regens) shall be supported¶

• Option-3 enables the optical controller to have direct access to coherent optical functions in devices regardless of the device.¶

R14 - Optical deployments with protection/restoration shall be supported¶

• Option-3 provides the optical controller with a full view of the optical protection/restoration schemes. Since in option-3 the optical controller has a complete view and control of end-to-end optical services between coherent plugs, upon any optical failure, it can perform the optical restoration/protection by calculating the new optical path, performing the optical viability on that path and establish the new optical path in the network. The optical controller has full knowldedge to perform all these actions.¶

R15 - Evolution to expected future controller deployment approaches shall be supported.¶

• Editor's note: This section will be completed.¶

R16 - Evolution to future packet processing deployment approaches¶

• Editor's note: This section will be completed.¶

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¶

    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 |      |      |  |
    |  +------+      +-------+      +-------+      +-------+      +------+  |
    |    |                                                             |    |
    +----+                                                             +----+

                    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 |      |      |  |
    |  +------+      +-------+      +-------+      +-------+      +------+  |
    |    |                                                             |    |
    +----+                                                             +----+

    Router A                                                      Router B
    +----+               IP Link (between Router Ports)           +----+
    |    |........................................................|    |
    |    |                                                        |    |
    |    |                                                        |    |
    |    |              Optical Service (Plug-to-Plug)            |    |
    |    |     .............................................      |    |
    |    |                                                        |    |
    |  +------+                                              +------+  |
    |  |      |          |-------------------------|         |      |  |
    |  |Plug A|       +-----+                  +-----+       |Plug B|  |
    |  |      |  (H1) |ROADM|                  |ROADM|  (H2) |      |  |
    |  |      |=======|     |                  |     |=======|      |  |
    |  +------+       +-----+                  +-----+       +------+  |
    |    |               |-------------------------|              |    |
    +----+                      Optical Network                   +----+

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.¶

10. Security Considerations

11. IANA Considerations

This document has no IANA actions.¶

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.¶

This approach offers several benefits, including the ability to scale each layer independently, optimize resource utilization, and simplify network management through centralized software control. Disaggregation enables network operators to choose best-of-breed components for each layer, fostering innovation and competition in the networking industry. However, implementing and managing a disaggregated network also comes with challenges related to interoperability, integration, and maintaining end-to-end performance across the various layers.¶

IP Network

      |----------|                                |----------|
      |          |           IP Link              |          |
      | Packet-1 |================================| Packet-2 |
      |          |\                              /|          |
      |          | \                            / |          |
      |----------|  |                          |  |----------|
                    |                          |
                    |                          |    Optical Network
     .............. | .......................  | ..............
     .              |                          |              .
     .      |---------|      (-------)       |---------|     .
     .      | xPonder |     ( ROADMs  )      | xPonder |     .
     .      |         |----( + Amp     )-----|         |     .
     .      |---------|     (+ Regen  )      |---------|     .
     .                       (-------)                       .
     .........................................................

  Legend:
    ==== IP Link
    ---- Optical fibers
    Packet: Packet devices (i.e., Router)
    xPonder: Optical network muxponder or transponder
    ROADMS: Optical/Photonic layer devices responsible for Lambda switching + Regen + Amplifier
    Optical network: xPonders + Photonic Layer (i.e. ROADMS, Amp, regen)

The second approach is to shrink the functions of the xPonders into a single small form factor plugs (aka Coherent pluggables) and then place them directly into the packet devices as shown in Figure 10. This is possible because the optical component design continues to improve density to the point where a whole transponder and muxponder which use to require many circuit packs can now fit onto a single small form factor pluggable. Placing this small form factor pluggable in a device with packet functions can reduce network cost, power consumption and footprint (when these benefits are not outweighed by other engineering considerations). Depends on the application, distance between packet devices, quality of fibers and so on it might be that there is no need for a ROADM network, i.e., direct connectivity between packet devices via plugs.¶

By incorporating coherent plugs into routers, network operators can achieve higher data rates, greater spectral efficiency, and improved tolerance to optical impairments. This is especially valuable in scenarios where traditional electronic signaling might encounter limitations. Coherent plugs enable routers to leverage advanced modulation schemes, digital signal processing, and error correction techniques, enhancing their ability to handle complex optical signals.¶

One of the key advantages of using coherent plugs in routers is the potential to bridge the gap between long-haul and metro networks, providing a seamless and efficient transition of data across various network segments. This technology can contribute to the evolution of high-speed data centers, interconnection between data centers, and the overall growth of data-intensive applications.¶

However, implementing coherent plugs in routers requires careful consideration of factors such as power consumption, form factor, cost, and integration with existing network infrastructure. As technology continues to evolve, coherent plugs hold the promise of extending the capabilities of routers and optical networks.¶

IP Network

     |----------|                               |----------|
     |          |             IP Link           |          |
     |          |===============================|          |
     | Packet-1 +++                           +++ Packet-2 |
     |          |  \                         /  |          |
     |          |   \                       /   |          |
     |          |    |                     |    |          |
     |----------|    |                     |    |----------|
                     |---------------------|

                                            Optical Network
  Legend:
    ++++ coherent pluggables
    ==== IP Link
    ---- Optical fibers
    Packet: Packet devices (i.e., Router)
    Optical network: Coherent plugs

Another flavor of Figure 10 is shown in Figure 11 where the transponder and muxponder functionality is provided by plugs but there is still a need for ROADM network. The packet over optical architecture is important for long-haul use cases since they exhibit several distinctive characteristics that make them suitable for efficiently transmitting data over vast distances such as:¶

• 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.¶
• 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)

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.¶

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.¶

    Router A                                                           Router B
    +----+              IP Link (between Router Ports)                 +----+
    |    |.............................................................|    |
    |    |                                                             |    |
    |    |                                                             |    |
    |    |                                                             |    |
    |    |             Optical Service (Plug-to-Plug)                  |    |
    |    |    .....................................................    |    |
    |  +-+                                                        +------+  |
    |  |                                                          |      |  |
    |  |             +-------+      +-------+      +-------+      |Plug B|  |
    |  |       ======| ROADM |======| ROADM |======| ROADM |======|      |  |
    |  |             | + Amp |      |       |      | + Amp |      |      |  |
    |  +-+           +-------+      +-------+      +-------+      +------+  |
    |    |                                                             |    |
    +----+                                                             +----+

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.¶

    Router A                                                           Router B
    +----+              IP Link (between Router Ports)                 +----+
    |    |.............................................................|    |
    |    |                                                             |    |
    |    |             Optical Service (Plug-to-Plug)                  |    |
    |    |    .....................................................    |    |
    |  +------+                                                   +------+  |
    |  |      |                                                   |      |  |
    |  |Plug A|                                                   |Plug B|  |
    |  |      |===================================================|      |  |
    |  |      |                                                   |      |  |
    |  +------+                                                   +------+  |
    |    |                                                             |    |
    +----+                                                             +----+

    Router A                                                           Router B
    +----+              IP Link (between Router Ports)                 +----+
    |    |.............................................................|    |
    |    |                                                             |    |
    |    |                                                             |    |
    |    |                                                             |    |
    |    |             Optical Service (Plug-to-Plug)                  |    |
    |    |    .....................................................    |    |
    |  +------+                                                   +------+  |
    |  |      |                                                   |      |  |
    |  |Plug A|      +-------+      +-------+      +-------+      |Plug B|  |
    |  |      |======| ROADM |======| ROADM |======| ROADM |======|      |  |
    |  |      |      | + Amp |      |       |      | + Amp |      |      |  |
    |  +------+      +-------+      +-------+      +-------+      +------+  |
    |    |                                                             |    |
    +----+                                                             +----+

    Router A                                                           Router B
    +----+              IP Link (between Router Ports).                +----+
    |    |.............................................................|    |
    |    |                                                             |    |
    |    |                                                             |    |
    |    |                      Optical Services                       |    |
    |    |                          +-------+                          |    |
    |    |    ..................... |       | .....................    |    |
    |  +------+                     |       |                     +------+  |
    |  |      |                     |       |                     |      |  |
    |  |Plug A|      +-------+      |       |      +-------+      |Plug B|  |
    |  |      |======| ROADM |======| Regen |======| ROADM |======|      |  |
    |  |      |      | + Amp |      |       |      | + Amp |      |      |  |
    |  +------+      +-------+      +-------+      +-------+      +------+  |
    |    |                                                             |    |
    +----+                                                             +----+

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

Authors' Addresses