Data Modelling and Gap Analysis of Optical Pluggables in Packet Over Optical Network

4.1. Optical Channel/OTSi

The media side of the optical module is further divided into two functional blocks; Optical Channel/OTSi and Media Logical Channels. The characteristics of the Optical channel/OTSi are (See section 2.3.1 of [I-D.ietf-ccamp-optical-impairment-topology-yang] and also section 3.2.4 [G.959.1]).¶

• This is the module interfaces facing the optical network.¶

• Represents the digital wrapper that transports services over a wavelength¶

• Represents the wavelength and the optical aspects of the signal modulated onto baud-rate, bit-rate, modulation scheme, frequency, tx-power, etc.¶

• Optical signal FEC termination/source, FEC characteristic information – configuration, if possible, Pre-FEC BER, Post-FEC BER, fail/degrade thresholds, raw corrected/uncorrected counts¶

• Provides configuration of the signal and monitoring capabilities¶

• Provides monitoring capabilities in the Tx (toward fiber/medium) and Rx (from fiber/medium) directions, Total optical power, optical channel power, optical statistics¶

4.2. Media Logical Channels

The characteristics of the Media Logical Channels are:¶

• Logical representation of the hierarchical view of the digital framing layers used for transport of services over the wavelength¶

• Provides access to information for configuration and monitoring characteristics. For example, for 400ZR/OpenZR+ [OIF-400ZR], it represents the 400ZR frame structure in which Ethernet services are mapped and for an OTN encapsulated signal, it represents the OTU, ODU, OPU frame structures, perhaps with a multi-layer multiplex structure, in which Ethernet and other types of services are mapped¶

4.3. Host Logical Channels

The host side of the optical module is further divided into two functional blocks; Host Logical Channels and Electrical channels. The characteristics of the Host Logical Channels are:¶

• Logical representation of the hierarchical view of the digital framing layers for services carried on the electrical lanes of the device¶

• Provides information for configuration and monitoring characteristics of each service¶

• Represents each service carried over the media logical channel and optical interface/wavelength, e.g., 25GE, 50GE, 100GE, 200GE, 400GE, OTU4, OTUCn etc.¶

4.4. Electrical Channels

The characteristics of the Electrical Channels are:¶

Note that the purpose of this section is to clarify the role of electrical channel in the optical module. This purpose of this draft is not to define the data model of the electrical channels.¶

• The host side lanes of the device forming the physical interface to the host platform data path device(s)¶

• Lanes grouped to support the type/format and bandwidth of the signal used for a service¶

• Provides information for configuration and monitoring characteristics of the signal for a service in the electrical domain, e.g., Interface-format, FEC, alarming thresholds, etc.¶

• Provides monitoring capabilities in the Tx (toward fiber) and Rx (from the fiber).¶

4.5. Equipment

The "Equipment functional block" in Figure 2 represents the pluggable module itself and has the following characteristics:¶

• Provides manufacturer identification information for the device¶

• Advertises capabilities of the device including capabilities for the host/client side and the media/line side¶

• Provides monitoring capabilities of physical characteristics and health of the device, e.g., temperature, voltage, optical transmitter/receiver characteristics¶

• Provides for configuration where applicable – e.g., of device environmental thresholds¶

• Supports device level capabilities such as firmware installation, restarts, etc.¶

5.1. optical module Capability Attributes (aka, Supported-Modes)

Coherent optical modules have revolutionized optical networking by offering a powerful combination of high performance, flexibility, and ease of deployment. These modules support a broad range of capabilities, making them both efficient and versatile. Their extensive functional capabilities further enhance their effectiveness in diverse networking environments.¶

From a data modeling perspective, a set of attributes is grouped together and represented by a single identifier known as the "Operational Mode." In essence, each operational mode encapsulates a combination of properties, limitations and capabilities, such as modulation type, bit rate, baud rate, chromatic dispersion, polarization, FEC, and more. Some of these attributes limit value ranges (e.g., minimum and maximum). A optical module can support multiple operational modes, each of which can be defined by one of the following methods.¶

Note that this current draft adheres to the definitions provided in draft [I-D.ietf-ccamp-optical-impairment-topology-yang]. See Section 2.6 of draft [I-D.ietf-ccamp-optical-impairment-topology-yang] for:¶

• Standard Mode: This mode pertains to optical specifications developed by standards development organizations (SDOs), such as the ITU-T recommendation [G.698.2].¶

• Organizational Mode: In this mode, optical interface specifications are defined by operators, industry forums (e.g., Optical Internetworking Forum (OIF) or OpenConfig), or equipment vendors. This allows for the utilization of optical module capabilities that extend beyond existing standards.¶

• Explicit Mode: This mode enables the explicit encoding of any subset of parameters (e.g., FEC type, modulation type) to facilitate interoperability checks by a controller entity through means not covered within this draft.¶

For more detailed information, please refer to draft [I-D.ietf-ccamp-optical-impairment-topology-yang].¶

5.2. optical module Configurations Attributes

Referring to Figure 3, optical modules support a set of read-write attributes which are configurable. Example of such configuration attributes are output power, central frequency and operational-mode. Note that as discussed in Section 5.1, since optical modules may support multiple operational-modes, as part of these configuration attributes, operator should configure which of these operational-mode is desired and should be functional.¶

 |-----------------------------------------------------------------|
 |  optical-channel  // OTSi channels                              |
 |      configuration // list of R/W plug configuration attributes |
 |           config-attribute-1                                    |
 |           config-attribute-2                                    |
 |           .....                                                 |
 |           config-attribute-m                                    |
 |-----------------------------------------------------------------|

5.3. optical optical module Performance Monitoring Data

Figure 4 shows the list of optical module Performance Monitoring (PM) and state data, which are critical components in optical networks, enabling network engineers to ensure optimal performance, identify issues, and maintain network reliability. Operators monitor a range of attributes on both the optical/photonic and electrical sides of optical modules, including channel input power, channel output power, central frequency, current Optical Signal-to-Noise Ratio (OSNR), Bit Error Rate (BER), chromatic dispersion, laser temperature, link status, and more. These parameters directly impact the quality and integrity of the transmitted data across both optical and electrical domains.¶

 |-----------------------------------------------------------------|
 |  optical-channel  // OTSi channels                              |
 |      pm and states  // list of R/O pm and state attributes      |
 |                     // Note-1: Each pm-attribute might have     |
 |                     //         threshold definitions            |
 |                     // Note-2: For each monitored attributes,   |
 |                     //         one SCTG profile can be assigned |
 |           monitored-attribute-1                                 |
 |           monitored-attribute-2                                 |
 |           .....                                                 |
 |           monitored-attribute-p                                 |
 |-----------------------------------------------------------------|

As coherent optical technology continues to gain traction, PM has evolved to include more advanced techniques, such as monitoring the quality of modulated signals and detecting impairments that could degrade performance over long distances. By leveraging these PM capabilities, engineers can ensure that the optical layer operates effectively, optimize the utilization of optical resources, and maintain high levels of service continuity and performance throughout the network.¶

It is important to note that the "monitored attributes" encompass parameters from the media side, host side, and hardware components of optical modules.¶

Performance Monitoring (PM) data is generated for various "monitored attributes" by optical modules, representing a range of real-time metrics, including current, average, minimum, and maximum values, as well as counters and states. The PM data can be categorized as follows:¶

• Basic Monitoring PM data: The analogue values which provide the "current values" of a "monitored attributes" such as laser temperature, eSNR (Effective Signal-to-Noise Ratio) at media input, eSNR at host input, laser frequency error, and more.¶

• Advanced Monitoring PM data: The analogue values which provide the "current, average, minimum, and maximum values" of "monitored attributes" such as transmit signal power, Bit Error Rate (BER), chromatic dispersion, etc.¶

• Up Counters: The discrete counter values of "monitored attributes" that only increment, such as Bit Error Count, FEC (Forward Error Correction) Uncorrected Errors, Loss of Signal (LOS) count, Loss of Frame (LOF) count, and others.¶

• Up/Down Counters: The discrete counter values of "monitored attributes" that can both incremented and decremented.¶

• Operational/Admin States: Represents the states of "monitored attributes" such as link up/down state, alarm state, laser on/off state, Automatic Power Control (APC) status, and more.¶

For "Up Counters" there might be two approaches:¶

• Continuous Increment: The counter value continuously increments without resetting upon read.¶

• Reset on Read: The counter value resets either on read or based on a predefined condition.¶

For "advanced monitoring performance management (PM) data", where current, average, minimum, and maximum values are provided by the optical module, a "windowing mechanism" is essential. Currently, this mechanism is implemented by the host platform, not the module itself. For instance, the host platform utilizes the windowing mechanism to segment the PM data collected by the optical module. Within each window, the host calculates the minimum, maximum, and average values of the PM data, enabling a granular and time-specific analysis of the module's performance.¶

A variety of performance monitoring metrics, including minimum, maximum, average, and instantaneous values, can be collected. These metrics offer a comprehensive view of performance fluctuations, allowing for precise monitoring and quicker response times to anomalies. Minimum and maximum values help identify the extremes of performance, while average values give a sense of typical performance levels. Instantaneous values, on the other hand, provide real-time insights, which are crucial for immediate issue detection and resolution. This multi-faceted approach ensures that network performance is consistently monitored and maintained at high standards.¶

Section 5.4 will discuss the collection type and how they are related to the above-mentioned PM data. It also covers the optical modules support for threshold crossing alerts (TCA) for all or a subset of monitored attributes.¶

5.4. optical module Threshold Definition

As indicated in Section 5.3, optical modules are capable of providing the threshold crossing alert (TCA) for all or subset of "monitored attributes". In this situation, the optical module raises an alert which informs the host about operationally undesired situations or about critical threshold crossings of monitored attributes. The optical module raises an alert by setting an associated Flag on module memory-map that represents the alert.¶

As mentioned previously, the TCA might be supported for a subset of optical module monitored attributes. Since it is possible that the optical module has different capabilities to raise threshold for different monitored attributes, to provide a general solution for threshold definition on optical module monitored attributes, this draft introduces the concept of "Supported Collection and Threshold Group (SCTG)" shown in Figure 5 which defines the configurable threshold values and collection types (i.e., the collection of current value, average value, min/max value are supported).¶

In summary, as outlined in Section 5.3 and Section 5.4, each optical module PM/State attribute can have multiple Performance Monitoring (PM) values, such as current, average, minimum, and maximum, as well as multiple threshold levels, including warning, minor, major, and critical. To streamline this representation in a Google Sheet, each optical module PM/State attribute will be associated with a corresponding SCTG-Type reference.¶

For example, consider the optical module PM attribute "channel-input-power." Tthe optical module collects PM values for current, average, minimum, and maximum, while also supporting the configuration of threshold values for warning, minor, major, and critical levels. As illustrated in Figure 5, the PM attribute "channel-input-power" is linked to "SCTG-Type-1" to simplify its representation in Google Sheet.¶

         Supported-Collection-and-Threshold-Group (SCTG)
 |----------------------------------------------------------------|
 |   SCTG-Type-1:                                                 |
 |     Collection: current, average, min, max                     |
 |     Configured Threshold: warning, minor, major, critical      |
 |                                                                |
 |   SCTG-Type-2:                                                 |
 |     Collection: current                                        |
 |     Configured Threshold: warning, minor, major, critical      |
 |                                                                |
 |   SCTG-Type-3:                                                 |
 |     Collection: current, average, min, max                     |
 |   ...                                                          |
 |   SCTG-Type-n:                                                 |
 |----------------------------------------------------------------|
    // Note:
    // These are just a few examples. More SCTG can be defined

To define the warning, minor, major, critical threshold values for a optical module monitored attribute, operator should set upper and lower limits that delineate acceptable performance ranges. This ensures that any deviations can be quickly identified and addressed. A rolling window between min-time and max-time should be employed to dynamically adjust these thresholds based on recent data trends, providing a more accurate reflection of current network conditions. By continuously updating the thresholds, network performance can be maintained within optimal parameters, reducing the risk of undetected issues.¶

Note that sometimes these thresholds are configurable and sometime they are hard-coded. It is also possible that a vendor can support a sub-set and super-set of monitored attributes (for super-set they need to augment the yang model).¶

5.5. optical module Alarm Notifications

[Editor's note: To be added in a later release.]¶

The optical modules might generate various alarm notifications due to the various reasons.¶

8.1. Approving the pluggable module type and version

pluggable modules, like all equipment, are carefully chosen. A network operations company (the operator) will decide what pluggable modules to use in the network based upon research and an understanding of capabilities of the pluggable modules available in the marketplace. These capabilities will be considered against the specific applications, use cases and scenarios that are of relevance to the operator's business.¶

It is expected that these applications, use cases and scenarios will be developed through "Market research" and as pluggable modules etc. are assessed. The use cases and scenarios will be applied extensively in later stages.¶

The operator will acquire samples of each type & version of pluggable module of interest and probably test and then trial them. They will also probably carry out "type approval" considering each type&version of pluggable module for a particular set of applications (where those applications may be defined by the operator themselves or may be standardized definitions) etc. The full detail of the capability of each type & version of pluggable module is relevant at all of these stages (see Section 8.5). The capabilities are expected to be expressed in a Repository.¶

[Editorial Note: As the main goal of this draft is to identify, we might want to move a portion of this section to an annex or separate draft].¶

8.2. Planning the network

Specific pluggable modules (type&version) will be purchased only after detailed planning of the network. To carry out this planning, full knowledge of each type&version of pluggable module will be required. The planning process will account for key pluggable module properties to explore viability and compatibility. The planning will use predictions of "service demand" (e.g., using a demand matrix) and hence infrastructure need to determine purchase volumes, phasing etc.¶

During the "Network planning" process different types of service relevant for the applications, use cases and scenarios (identified in Section 8.1) will be explores and specific approaches to realizing each resulting type of service will be determined. This will result in design of specific "service realization" patterns and templates that will be used in later stages of the process. The approach to deploying each service type is defined for each operational context (application etc.)¶

As a result of the planning exercise, numbers of each pluggable module type&version required will be known and purchasing can be initiated. The purchased pluggable modules will be added to the inventory and spares holdings.¶

8.3. Dealing with service demand

The planning exercise leads to optical infrastructure requirements with some timetable for deployment. The "Optical infrastructure" is designed (using the patterns/templates designed in Section 8.2. The infrastructure will be deployed as appropriate based upon predicted and actual service demand etc.¶

When optical "services demand" is received, perhaps to provide underlay for the packet network or driven by a specific service contract, optical network analysis is carried out to evaluate how to efficiently and effectively achieve the specific service demanded. This analysis will consider the whole optical network including the plugs and ROADMs etc. In most cases this "Service design" will use patterns/templates constructed in Section 8.2 in conjunction with relevant capability information for the pluggable module type&version.¶

Prior to progressing further it is important to note that pluggable modules are highly valuable, and correspondingly expensive. They are deployed in a controlled fashion. There are a range of policies for deployment of pluggable modules.¶

In some cases, at one extreme end of the range of policy choices, an operator may decide to fully populate a packet device with a selection of pluggable modules and may cable them to adjacent ROADMS. However, it is more likely that pluggable module deployment will be on a just-in-time basis, at the other end of the range of policy choices, so a pluggable module is not deployed (and hence is not cabled) until the solution to realization of the optical service has been determined.¶

Regardless of the deployment approach, the module capability will be accounted for in the optical network analysis activity. Where modules are present, the range of installed modules constrain the possible realizations, where pluggable module modules have not been deployed all approved pluggable module modules (type&version) could be considered during the analysis, although capability of the relevant packet devices to support specific pluggable module modules will also need to be considered, and this may eliminate some pluggable module modules. In addition, if there is some urgency, the availability of the type of pluggable modules to the installation engineer and/or in the local spares holding inventory may also be considered.¶

The optical design will be "validated" in terms of "viability" and compatibility prior to proceeding. This analysis takes into account the full definitions of the pluggable module type&versions of interest, where each is defined in a corresponding and referenced Repository.¶

8.4. Installing and operationalizing the pluggable module

Once the design is available, any necessary physical installation exercise (pluggable module installation, cabling etc.) is carried out, driven by "Work orders" that identify the type&version of pluggable module to instal etc.¶

On detection of the pluggable module instance, the control system will validate that the work order has been carried out correctly. To do this, the full type&version of the pluggable module is read and compared with the intent. Where there are discrepancies, either a work order is constructed to correct the installation error after the detected pluggable module type&version is evaluated for compatibility with the specific design. This evaluation is done using the Repository for that type&version. It is possible that the type&version may be acceptable although perhaps a little more expensive than the optimum choice etc.¶

Once the type&version of pluggable module has been confirmed, the cabling to the pluggable module will be validated and the service set up and validated. Depending upon the operator practices, there may be an extensive service test phase prior to handing over the service. The service may not be enabled immediately, but will be at some point after which the service will become operational. From this point on, normal live service/equipment management/control will be active.¶

Beyond this point normal operational activities such as engineering works, restoration, upgrade, fault location etc. will be carried out. Clearly, there is also the reverse sequence which includes deactivating a service and removing the plug and there are also various edits and refinements that result from changes in demand and changes in understanding of the service needs etc. These steps have not been covered at this stage as the initial list above is sufficient to the develop a deep understanding of the control of the plugs. Further stages will be added in a future version of this document.¶

In addition, during transition towards a more automated future, there are processes related to discovery of existing network etc. In many of these processes the current state of the network is understood including the type&version of each pluggable module. Some degree of understanding of capability of pluggable modules (and any other equipment) is relevant.¶

8.5. Expressing capabilities

As highlighted above, prior to installation of an optical pluggable module in a device, various research, approval, planning and design activities must be carried out (as they would be for any hardware). All of these activities will require information on the capabilities of the pluggable module.¶

Detailed information on the capability of the pluggable module is required long before it is installed and operating. This points to the need for a model of capability (of a type of pluggable module) that is independent of the model of a running instance (and hence points to decoupling of the model of capability from the model of the operation of the pluggable module). This also suggest that discovery of capability detail from the pluggable module is not sufficient/appropriate for deployment (although it may be useful in a lab context).¶

A machine interpretable definition/specification for the pluggable module should be available (independent of the pluggable module instance) for each pluggable module type&version where the statement of type&version (complete type&version) used is to the degree sufficient to precisely identify the relevant (unique) definition/specification. The complete type&version may include hardware type&version, firmware type&version and software type&version details (where the firmware/software influences the operation/control of the pluggable module). This is essentially the type&version used when considering spares holding and like-for-like replacement in the field.¶

From this perspective, all that is required from a running pluggable module is to report the complete type&version detail so that this can be confirmed as the right type&version. The type&version can be used to reference the relevant unique specification.¶

It is important to clarify the definition of capability. In this document, the term capability means "A quality or facility that enables something to carry out some activity and/or take some role". In the context of an equipment, the term applies to its functional and physical properties.¶

Considering a pluggable module (as for many other equipments), this would include specification of capabilities such as:¶

• physical size, form factor and shape (the capability to fit in a particular type of location)¶

• connector type (the capability to physically interconnect with a compatible connector)¶

• bus architecture (the capability to communicate with a compatible component)¶

• optical termination characteristics (the functional capabilities emergent from the powered physical equipment, allowing interconnection with corresponding compatible functions)¶

• measurement opportunities (the functional capabilities to provide information to various control functions)¶

A capability statement may be a precise single value with no uncertainty, a range, a collection of related ranges and thresholds etc. Where some aspect has variability or is controllable, this is also required to be specified.¶

For an equipment to be understood and used by a control system, the detailed information on capabilities must be available in machine interpretable form (to the degree necessary for any particular function to be carried out). The machine interpretable statements may be in the form of software, but preferably should be in the form of data (information) that can be readily ingested by tooling and ideally in a standardized language.¶

Traditionally, the published statements of capability have been in somewhat ambiguous text that require interpretation and conversion into a machine interpretable form through a manual intermediate step (normally performed, with errors and performed many times for any particular device type etc.). It is suggested here that the best source of the machine interpretable data is the specifying authority (e.g., ITU-T for standard applications, the vendor for plug capabilities, an operator for non-standard applications).¶

9.1. Example-1: Coherent Pluggables Already Provisioned

The first example is illustrated in Figure 7. This is a simple example where the packet over optical network has been already provisioned with both optical underlay and packet overlay services. The role of SDN controller is just to discover and manage the network. In other words, the SDN controller was not involved in various aspects of service provisioning and viability. The second example will come all these aspects in more detail.¶

      <------------------ L3 service-1 ------------------->
       <------------------ TE-Tunnel-1 ------------------>
         <----------------- IP link-1 ----------------->
           <------------- L0 service-1 ------------->

   |------------|        |------------------|
   | Coherent   |        |                  |
   | Pluggable  |  <-->  |  SDN Controller  |
   | Repository |        |                  |
   |------------|        |------------------|
                                ^
                                |
                                v
                      |------------------|
         port_a       |                  |
     |------| p1    |------|             |
     |  R1 ++-\     |  m1  |             |       port_b
     |------|  \    |------|          |------|  p2 |------|
                \      |              |  m3  |-----++ R2  |
                 \  |------|          |------|     |------|
                  \-|  m2  |             |
                    |------|             |
                      |                  |
                      |------------------|

  Legend:
    ----        Optical fibers
    ++ p1,p2    Coherent pluggables
    R1, R2      Packet device (i.e., Router)
    m1, m2, m3  Photonic node (ROADM)

In this example, all optical and IP/MPLS services had been already provisioned and deployed and the packet over optical network is fully functional.¶

Within packet devices R1 and R2, coherent pluggables p1 and p2, are installed, interfacing through ports port_a and port_b, respectively. Both coherent pluggables are provisioned for the following operational-mode (see section 3 YANG Model of [I-D.ietf-ccamp-optical-impairment-topology-yang]):¶

• [organization-identifier, operational-mode] = [OIF, 0x3E]¶

A single photonic service is established between these pluggables and an IP link is mapped to this L0 photonic service. The overlay TE-Tunnel-1 and L3 service-1 had been also provisioned. The following steps outline the details of how this network is discovered and managed by SDN controllers (note that the SDN controller was not involved in provisioning):¶

• Packet devices (R1, R2), pluggables (p1, p2), and photonic devices (m1, m2, m3) are all discovered by SDN controllers.¶

• The SDN controller also discovers all underlay and overlay services, i.e., L0 service-1, IP link-1, TE-Tunnel-1 and L3 service-1.¶

• The SDN controller has the network inventory, including coherent pluggables p1 and p2. In particular for coherent pluggables, basic information such as pluggable type, vendor, manufacturer, serial number and software version will be provided by pluggables to SDN controller.¶

• The inventory of packet devices R1 and R2 contains the configurations of pluggable attributes such as "configured operational-mode," "configured central frequency," and "configured output power".¶

• Specifically, using the basic information of pluggables p1 and p2 such as pluggable type, vendor, manufacturer, serial number and software version collected earlier from packet devices R1 and R2, the SDN controller can use the "Coherent Pluggable Repository," to access the entire information of both pluggables p1 and p2. This includes all supported operational-modes along with all attributes related to each supported operational-mode.¶

• The SDN controller can collect all PM telemetry data from the network (including pluggables).¶

• The SDN controller can collect all alarm notifications from the network (including pluggables).¶

• The SDN controller can further change, modify, optimize the network (if needed).¶

9.2. Example-2: Coherent Pluggables Planning

The example in Figure 8 demonstrates the usage of the "Coherent Pluggable Repository" for entire lifecycle of photonic service from including service planning, viability, provisioning, collection of PM telemetry, collection of alarm notifications and optimization.¶

Note that the packet over optical network in Figure 8 is not created yet. The ports port_a and port_b of packet device R1 and R2 are empty and can accept coherent pluggables. In addition, ports port_a and port_b are not connected to the optical network yet, i.e., there is no connection between packet devices R1, R2 and optical network. The port_a and port_b of packet device R1 and R2 can be potentially connected to any photonic nodes m1, m2 or m3.¶

Operator's goal is to use the SDN controller to plan, provision and monitor an optimal IP link-2 between packet devices R1 and R2. Optionally they can also provision overlay TE-Tunnel-2 and L3 service-2. To achieve this, the SDN controller should first plan an optical service-2, perform the viability to make sure this photonic service is feasible, provision it and then map it to an IP link-2.¶

      <------------------ L3 service-2 ------------------->
       <------------------ TE-Tunnel-2 ------------------>
         <----------------- IP link-2 ----------------->
           <------------- L0 service-2 ------------->

   |------------|        |------------------|
   | Coherent   |        |                  |
   | Pluggable  |  <-->  |  SDN Controller  |
   | Repository |        |                  |
   |------------|        |------------------|
                                ^
                                |
                                v
                      |------------------|
         port_a       |                  |
     |------|       |------|             |
     |  R1 .........|  m1  |             |       port_b
     |------|  .    |------|          |------|     |------|
                .     |               |  m3  |....... R2  |
                 .  |------|          |------|     |------|
                  ..|  m2  |             |
                    |------|             |
                      |                  |
                      |------------------|

  Legend:
    .....       Packet device can be potentially
                connected to photonic nodes m1, m2, m3
    R1, R2:     Packet device (i.e., Router)
    m1, m2, m3  Photonic node (ROADM)
    port_a      Router R1 port which is empty and can
                potentially populated by coherent pluggables
    port_b      Router R2 port which is empty and can
                potentially populated by coherent pluggables

Let's assume that the operator of this network has already purchased coherent pluggables from Vendor-X, which can support the following two operational-modes. Note that the detail information of these operational-modes including all optical and photonic attributes are already uploaded to "Coherent Pluggable Repository" by Vendor-X and OIF (see section 3 YANG Model of [I-D.ietf-ccamp-optical-impairment-topology-yang]):¶

• [organization-identifier, operational-mode] = [OIF, 0x3E]¶

• [organization-identifier, operational-mode] = [Vendor-X, 0x22]¶

The following steps outline the details of how this network is planned, provisioned, discovered and managed by SDN controllers:¶

• At first, there are no coherent pluggables installed in the packet devices yet. There are also no connection between packet devices and optical network.¶

• All packet devices (R1, R2) and photonic devices (m1, m2, m3) are managed by the SDN controller.¶

• As a result, the SDN controller maintains an inventory of packet and photonic devices within the network (i.e., nodes R1, R2, m1, m2, m3).¶

• To create the IP link-2, the SDN controller should plan and then provision the optical service-2 between port_a and port_b.¶

• To this end, the SDN controller should first design an optical service and then performs the viability check to make sure the optical service is viable in this network.¶

• So, the SDN controller calculates the best optical path from port_a to port_b.¶

• Next, the SDN controller performs the viability on optical route to make sure the optical path is viable in the network.¶

• To do viability, the SDN controller checks all attributes of all operational-modes to find the most optimal operational-mode. To do this, the SDN controller connects to the "Coherent Pluggable Repository" and access all optical and photonic attributes of all operational-modes (such as chromatic dispersion, FEC, modulation, polarization mode dispersion etc.) and performs the viability.¶

• After performing the optical path calculation and optical viability, the SDN controller selects the best coherent pluggable to be installed on port_a and port_b and the best optical route from port_a to port_b.¶

• Upon completion of the photonic viability check, the SDN controller determines which photonic devices (m1, m2, m3) should be connected to ports port_a and port_b.¶

• The SDN controller informs the operator of the selected coherent pluggables for ports port_a and port_b and provides instructions on how to connect them to the respective photonic devices (m1, m2, m3).¶

• The operator installs the designated pluggables into ports port_a and port_b and connects them to the specified photonic devices.¶

• The SDN controller then manages the newly installed pluggables.¶

• As part of the photonic viability process, the SDN controller knows the specific attributes of the pluggables, including "configured operational mode," "configured central frequency," and "configured output power."¶

• As a result, the SDN controller configures these configurations to each pluggable on port_a and port_b¶

• The SDN controller should also configure optical nodes m1, m2, m3 with attributes such as output power.¶

• The SDN controller provisions the optical service_1 between two coherent pluggables on port_a and port_b.¶

• The SDN controller also provisions the IP link-2 between packet device R1 and R2.¶

• The SDN controller can collect all PM telemetry data from the network (including pluggables).¶

• The SDN controller can collect all alarm notifications from the network (including pluggables).¶

• The SDN controller can further change, modify, optimize the network (if needed).¶

10.1. Support of Opaque Capability Attributes

The coherent pluggable YANG data model is augmented with a list of new capability attributes. As demonstrated in Figure 9, the YANG data model is augmented with the following information:¶

• ID of new capability proprietary attribute¶

• Name of new capability proprietary attribute¶

• Minimum value of new attribute¶

• Maximum value of new attribute¶

The Figure 9 shows an example of new capability attribute "CC" whose min and max values are 1.1 and 3.3, respectively.¶

 +--ro opaque-capability-attribute-list* [cap-attribute-id]
     +--ro cap-attribute-id              uint32
     +--ro cap-attribute-name            string
     +--ro cap-min-value                 decimal64
     +--ro cap-max-value                 decimal64

<opaque-capability-attribute-list xmlns="urn:example:cc">
  <cap-attribute-id> 1 </cap-attribute-id >
  <cap-attribute-name> CC </cap-attribute-name>
  <cap-min-value> 1.1 </cap-min-value>
  <cap-max-value> 3.3 </cap-max-value>
</opaque-capability-attribute-list>

10.2. Support of Opaque Secret Capability Attributes

to be added¶

10.3. Support of Opaque Configuration Attributes (Solution-1)

To support the opaque configuration attributes, there are a few potential solutions which are discussed below. This approach is the simplest solution, as it requires no interpretation by the host platform. The coherent pluggable YANG data model is augmented with a list that directly maps the values of new configuration attributes to the corresponding memory-map locations on the pluggable device. In this solution, the memory-map locations must be known to the operator, potentially provided in the Coherent Pluggable Repository. The Figure 10 illustrates the coherent pluggable YANG data model, which has been augmented with the following information:¶

• ID of new proprietary configuration attribute¶

• Name of new proprietary configuration attribute¶

• Value of new proprietary attribute¶

• The memory map of new proprietary attribute (which is used in CMIS communication between host and pluggable)¶

For instance, consider a scenario where the operator intends to configure a new proprietary attribute, "AA," with a value of 100, and a memory-map location on the pluggable set to 0x1100. In this process, the host platform receives the attribute "AA" as defined in Figure 10. The host platform then relays this information to the coherent pluggable via the CMIS protocol, without performing any interpretation. In other words, the host platform is not required to understand the syntax or semantics of these attributes; it functions merely as a conduit, transmitting the values from the NBI to the designated memory-map locations on the pluggable.¶

 +--rw opaque-config-attribute-list* [conf-attribute-id]
     +--rw conf-attribute-id             uint32
     +--rw conf-attribute-name           string
     +--rw value                         decimal64
     +--rw memory-map                    decimal64

<opaque-config-attribute-list xmlns="urn:example:cc">
  <config-attribute-id> 1 </config-attribute-id >
  <config-attribute-name> AA </config-attribute-name>
  <value> 100 </value>
  <memory-map> 1100 </memory-map>
</opaque-config-attribute-list>

10.4. Support of Opaque Configuration Attributes (Solution-2)

This approach is similar to Figure 10 but requires the host platform to implement lookup logic to determine the memory-map location on the pluggables. In this solution, the coherent pluggable YANG data model is augmented with the following new attributes, as shown in Figure 11:¶

• ID of new proprietary configuration attribute¶

• Name of new proprietary configuration attribute¶

• Value of new proprietary attribute¶

The operator does not have visibility into the specific memory-map locations for these attributes on the coherent pluggable device. Instead, the memory-map for each new attribute is provided in the Coherent Pluggable Repository. In this scenario, the host platform must search the pluggable Repository to locate the corresponding memory-map location for each new attribute. These values are then communicated to the pluggable via the CMIS protocol for configuration. As in Figure 10, the host platform does not need to understand the syntax or semantics of the new attributes; it only needs to search the pluggable Repository to identify the memory-map locations for the new attributes.¶

As illustrated in Figure 11, the host platform receives the new attribute "AA" via its Northbound Interface (NBI), with a configuration value of 0x1100. The host then searches the coherent pluggable Repository to determine the memory-map location associated with this attribute and identifies it as 0x1100. Without interpreting the attribute's syntax or semantics, the host platform communicates this information to the coherent pluggable via the CMIS protocol. Essentially, the host platform functions as a proxy, transmitting the values from the NBI to the appropriate memory-map locations on the pluggable without needing to understand the meaning of the attributes.¶

 +--rw opaque-config-attribute-list* [conf-attribute-id]
     +--rw conf-attribute-id             uint32
     +--rw conf-attribute-name           string
     +--rw value                         decimal64
     Note: The memory-map for each new attribute is provided in
           pluggable Repository.

<opaque-config-attribute-list xmlns="urn:example:cc">
  <config-attribute-id> 1 </config-attribute-id >
  <config-attribute-name> AA </config-attribute-name>
  <value> 1100 </value>
</opaque-config-attribute-list>

10.5. Support of Opaque Configuration Attributes (Solution-3)

This solution represents an advanced approach when a new opaque configuration attribute is mapped to multiple memory-map locations on a pluggable device, or when multiple such attributes are mapped to a single memory-map location on pluggable. Similar to Figure 11, the mapping between these new attributes and their corresponding memory-map locations should be detailed in the pluggable Repository. For each new opaque attribute, the host platform is required to perform a lookup in the pluggable Repository to identify the relevant memory-map locations. The platform then assembles the corresponding values, which are communicated to the pluggable device via the CMIS protocol.¶

Although this solution is included for completeness, it is not practical or desirable due to its complexity and the need for interpretation by the host software¶

10.6. Support of Opaque Secret Configuration Attributes

There are situations where opaque configuration attributes are confidential, and the vendor wishes to conceal their meanings and values. When considering the interface from the pluggable device to the host via CMIS, it is crucial that the pluggable does not expose the meaning or value of these confidential attributes. Ideally, the pluggable device would encrypt the data. Within the context of CMIS, it may be sufficient to allocate an array of register locations to convey the property values. These registers would store an encrypted data blob for read-only properties and accept an encrypted blob for writable registers. The specific value might be set or read through different register positions on each read/write, depending on the encryption technique used.¶

It is important to note that since the pluggable device encrypts the data, mapping the data offers no additional benefit. The YANG model would simply convey the register values as requested. The properties are applied to the memory map in a manner that may appear disordered. The location values must always be read together and written as specified, potentially requiring multiple reads to retrieve all properties. This approach could be incorporated into the basic register-based option discussed in Section 10.3.¶

As an example, let's assume a vendor defines secret attribute "DD" for its coherent pluggable. Vendor first needs to augment IETF data model with a list of encrypted values and memory-maps shown in Figure 12. This very similar to Figure 10 where essentially the host functions as a proxy, transmitting the values from the NBI to the appropriate memory-map locations on the pluggable without needing to understand the meaning and semantics of these attributes.¶

 +--rw opaque-config-attribute-list* [conf-attribute-id]
     +--rw conf-attribute-id             uint32
     +--rw encrypted-attribute-name      string
     +--rw encrypted-attribute-value     string
     +--rw memory-map                    decimal64

10.7. Support of Opaque Performance Monitoring Data

The host packet device is informed of the properties via YANG augments and appropriate mapping definitions. The mapping definitions tell the host that the related properties are related to performance monitoring data such that the host will periodically read the appropriate parts of the pluggable interface as for any other performance monitoring data. AS for all other performance monitoring data, the host does not need to understand the data. The client controller can carry out analysis or can propagate the measures transparently to some other controller etc.¶

14.1. Normative References

[CMIS]

OIF Forum, "OIF Implementation Agreement (IA) Common Management Interface Specification (CMIS))", OIF CMIS IA , September 2024, <https://www.oiforum.com/wp-content/uploads/OIF-CMIS-05.3.pdf>.

[G.698.2]

ITU-T Recommendation G.698.2, "Amplified multichannel dense wavelength division multiplexing applications with single channel optical interfaces", November 2018, <https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.698.2-201811-I!!PDF-E&type=items>.

[OIF-400ZR]

OIF Forum, "Implementation Agreement 400ZR", November 2022, <https://www.oiforum.com/wp-content/uploads/OIF-400ZR-02.0.pdf>.

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

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[SFF8024]

SNIA SFF Technology Affiliate (TA) Technical Work Group (TWG), Small Form Factor Technology Affiliate, "SFF Module Management Reference Code Tables", November 2023, <https://members.snia.org/document/dl/26423>.

14.2. Informative References

[G.959.1]

"Optical transport network physical layer interfaces", February 2012, <ITU-T Recommendation G.959.1>.

[I-D.ietf-ccamp-dwdm-if-param-yang]

Galimberti, G., Hiremagalur, D., Grammel, G., Manzotti, R., and D. Breuer, "A YANG data model to manage configurable DWDM optical interfaces", Work in Progress, Internet-Draft, draft-ietf-ccamp-dwdm-if-param-yang-12, 12 February 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-dwdm-if-param-yang-12>.

[I-D.ietf-ccamp-optical-impairment-topology-yang]

Beller, D., Le Rouzic, E., Belotti, S., Galimberti, G., and I. Busi, "A YANG Data Model for Optical Impairment-aware Topology", Work in Progress, Internet-Draft, draft-ietf-ccamp-optical-impairment-topology-yang-18, 11 April 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-optical-impairment-topology-yang-18>.

[I-D.ietf-ccamp-rfc9093-bis]

Belotti, S., Busi, I., Beller, D., Le Rouzic, E., and A. Guo, "Common YANG Data Types for Layer 0 Networks", Work in Progress, Internet-Draft, draft-ietf-ccamp-rfc9093-bis-13, 17 March 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-rfc9093-bis-13>.