Skip to main content

Extension to the Link Management Protocol (LMP/DWDM -rfc4209) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems to manage the application code of optical interface parameters in DWDM application
draft-ietf-ccamp-dwdm-if-lmp-09

Document Type Active Internet-Draft (ccamp WG)
Authors Dharini Hiremagalur , Gert Grammel , Gabriele Galimberti , Ruediger Kunze , Dieter Beller
Last updated 2024-01-23
Replaces draft-dharinigert-ccamp-dwdm-if-lmp
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Proposed Standard
Formats
Additional resources Mailing list discussion
Stream WG state WG Document
Associated WG milestone
Mar 2023
Submit DWDM interface LMP and YANG to IESG for review
Document shepherd (None)
IESG IESG state I-D Exists
Consensus boilerplate Yes
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-ccamp-dwdm-if-lmp-09
Internet Engineering Task Force                      D. Hiremagalur, Ed.
Internet-Draft                                           G. Grammel, Ed.
Intended status: Standards Track                                 Juniper
Expires: 26 July 2024                                 G. Galimberti, Ed.
                                                                   Cisco
                                                           R. Kunze, Ed.
                                                        Deutsche Telekom
                                                               D. Beller
                                                                   Nokia
                                                            January 2024

Extension to the Link Management Protocol (LMP/DWDM -rfc4209) for Dense
 Wavelength Division Multiplexing (DWDM) Optical Line Systems to manage
the application code of optical interface parameters in DWDM application
                    draft-ietf-ccamp-dwdm-if-lmp-09

Abstract

   This memo defines extensions to LMP RFC4209 for managing Optical
   parameters associated with Wavelength Division Multiplexing (WDM)
   systems in accordance with the Interface Application Identifier
   approach defined in ITU-T Recommendation G.694.1 and its extensions.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

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 4 July 2024.

Hiremagalur, et al.       Expires 26 July 2024                  [Page 1]
Internet-Draft       draft-ietf-ccamp-dwdm-if-lmp-09        January 2024

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  DWDM line system  . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Optical interface parameter collection  . . . . . . . . .   4
     3.2.  DWDM client - ROADM interconection discovery  . . . . . .   4
     3.3.  Service Setup . . . . . . . . . . . . . . . . . . . . . .   5
     3.4.  Link Monitoring Use Cases . . . . . . . . . . . . . . . .   6
   4.  Extensions to LMP-WDM Protocol  . . . . . . . . . . . . . . .   7
   5.  General Parameters - OCh_General  . . . . . . . . . . . . . .   7
   6.  ApplicationIdentifier - OCh_ApplicationIdentifier . . . . . .   9
   7.  OCh_Ss - OCh transmit parameters  . . . . . . . . . . . . . .  11
   8.  OCh_Rs - receive parameters . . . . . . . . . . . . . . . . .  11
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   11. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  12
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  13
     12.2.  Informative References . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   LMP [RFC4209] provides link property correlation capabilities that
   can be used between a transceiver device and an Optical Line System
   (OLS) device.  Link property correlation is a procedure by which,
   intrinsic parameters and capabilities are exchanged between two ends
   of a link.  Link property correlation as defined in RFC3591 allows
   either end of the link to supervise the received signal and operate
   within a commonly understood parameter window.  Here the term 'link'
   refers in particular to the attachment link between OXC and OLS (see
   Figure 1).  The relevant interface parameters are in line with
   "draft-ietf-ccamp-dwdm-if-param-yang".  Use cases are 1- Optical

Hiremagalur, et al.       Expires 26 July 2024                  [Page 2]
Internet-Draft       draft-ietf-ccamp-dwdm-if-lmp-09        January 2024

   interface parameter collection, 2- DWDM client - ROADM interconection
   discovery, 3- Service Setup, 4- Link Monitoring

2.  DWDM line system

   Figure 1 shows a set of reference points (Rs and Ss), for a single-
   channel connection between transmitter (Tx) and receiver (Rx)
   devices.  Here the DWDM network elements in between those devices
   include an Optical Multiplexer (OM) and an Optical Demultiplexer
   (OD).  In addition it may include one or more Optical Amplifiers (OA)
   and one or more Optical Add-Drop Multiplexers (OADM).

          +-------------------------------------------------+
       Ss |              DWDM Network Elements              | Rs
   +--+ | |  | \                                       / |  |  | +--+
   Tx L1--|->|   \    +------+            +------+   /   |--|-->Rx L1
   +---+  |  |    |   |      |  +------+  |      |  |    |  |    +--+
   +---+  |  |    |   |      |  |      |  |      |  |    |  |    +--+
   Tx L2--|->| OM |-->|------|->|ROADM |--|------|->| OD |--|-->Rx L2
   +---+  |  |    |   |      |  |      |  |      |  |    |  |    +--+
   +---+  |  |    |   |      |  +------+  |      |  |    |  |    +--+
   Tx L3--|->|   /    | DWDM |    |  ^    | DWDM |   \   |--|-->Rx L3
   +---+  |  | /      | Link +----|--|----+ Link |     \ |  |    +--+
          +-----------+           |  |           +----------+
                               +--+  +--+
                               |        |
                            Rs v        | Ss
                            +-----+  +-----+
                            |RxLx |  |TxLx |
                            +-----+  +-----+

   Ss = Sender reference point at the DWDM network element
        tributary output
   Rs = Receiver reference point at the DWDM network element
        tributary input
   Lx = Lambda x
   OM = Optical Mux
   OD = Optical Demux
   ROADM = Reconfigurable Optical Add Drop Mux

                  Figure 1: Linear Single Channel approach

   from Fig. 5.1/G.698.2

   Figure 2 Extended LMP Model ( from [RFC4209] )

Hiremagalur, et al.       Expires 26 July 2024                  [Page 3]
Internet-Draft       draft-ietf-ccamp-dwdm-if-lmp-09        January 2024

            +------+ Ss    +------+       +------+    Rs +------+
            |      | ----- |      |       |      | ----- |      |
            | OXC1 | ----- | OLS1 | ===== | OLS2 | ----- | OXC2 |
            |      | ----- |      |       |      | ----- |      |
            +------+       +------+       +------+       +------+
              ^  ^             ^              ^             ^  ^
              |  |             |              |             |  |
              |  +-----LMP-----+              +-----LMP-----+  |
              |                                                |
              +----------------------LMP-----------------------+

   OXC        : is an entity that contains transponders
   OLS        : generic optical system, it can be -
                Optical Mux, Optical Demux, Optical Add
                Drop Mux, Amplifier etc.
   OLS to OLS : represents the Optical Multiplex section
                <xref target="ITU-T.G709"/>
   Rs/Ss      : reference points in between the OXC and the OLS

                        Figure 2: Extended LMP Model

3.  Use Cases

   A comparison with the traditional operation scenarios provides an
   insight of similarities and distinctions in operation and management
   of DWDM interfaces.  The following use cases provide an overview
   about operation and maintenance processes.

3.1.  Optical interface parameter collection

   It is necessary to identify the Optical interface characteristics and
   setting in order to properly calculate the ent to end path and match
   the Head End interface against the Tail End interface compatibility.
   The optical parameters may have multiple possible values that the
   Controller (SDN or GMPLS) can use and select for the best network
   optimisation.  In case of GMPLS, the LMP is suitable to support the
   parameters exchange between the ROADM and the Transponder (or DWDM
   interface located into the client box).

3.2.  DWDM client - ROADM interconection discovery

   Being the DWDM port (Rs and Ss) and ROADM port belonging to different
   domains and Network Elements, the interconnection between them is not
   embedded in the Optical Nodes (OLS layer) and can not be shared to
   the EMS and the Controller.  The Controller needs then to retrieve
   the connectivity using data coming from the two domains correlating
   them to discover the relationship.  The methods to discover the
   interconnection can be LMP, LLDP, installation provisioning or any

Hiremagalur, et al.       Expires 26 July 2024                  [Page 4]
Internet-Draft       draft-ietf-ccamp-dwdm-if-lmp-09        January 2024

   other mechanism using the light (or power) transmitted by the DWDM
   transmitter and detecter by the ROADM port photodiode.  This use case
   is fundamental to build the interconnections between the DWDM and
   Client layer (e.g.  Routers) and re-build the multilayer network
   topology.

3.3.  Service Setup

   It is necessary to differentiate between different operational issues
   for setting up a light path (a DWDM connection is specific in having
   defined maximum impairments) within an operational network.

   The first step is to determine if transceivers located at different
   end-points are interoperable, i.e. support a common set of
   operational parameters.  In this step it is required to determine
   transceiver capabilities in a way to be able to correlate them for
   interoperability purposes.  Such parameters include modulation
   scheme, modulation parameters, FEC to name a few.  If both
   transceivers are controlled by the same NMS or Control Plane, such
   data is readily available.  However in cases where the transceivers
   are controlled by different Control Pplanes, a protocol needs to be
   used to inform the controlling instance (NMS or CP) about transceiver
   parameters.  It is suggested to extend LMP for that purpose.

   The second step is to determine the feasibility of a lightpath
   between two transceivers without applying an optical signal.
   Understanding the limitations of the transceiver pair, a path through
   the optical network has to be found, whereby each path has an
   individual set of impairments deteriorating a wavelength traveling
   along that path.  Since a single transceiver can support multiple
   parameter sets, the selection of a path may limit the permissible
   parameter sets determined in previous steps.

   The third step is then to setup the connection itself and to
   determine the Wavelength.  This is done using the NMS of the optical
   transport network or by means of a control plane interaction such as
   signaling and includes the path information as well as the parameter
   set information necessary to enable communication.

   In the fourth step, optical monitoring is activated in the WDM
   network in order to monitor the status of the connection.  The
   monitor functions of the optical interfaces at the terminals are also
   activated in order to monitor the end to end connection.

   Furthermore it should be possible to automate this step.  After
   connecting the client device to the neighbor control plane-enabled
   transport node, a control adjacency may be automatically established,
   e.g. using LMP.

Hiremagalur, et al.       Expires 26 July 2024                  [Page 5]
Internet-Draft       draft-ietf-ccamp-dwdm-if-lmp-09        January 2024

3.4.  Link Monitoring Use Cases

   The use cases described below are assuming that power monitoring
   functions are available in the ingress and egress network element of
   the DWDM network, respectively.  By performing link property
   correlation it would be beneficial to include the current transmit
   power value at reference point Ss and the current received power
   value at reference point Rs.  For example if the Client transmitter
   power has a value of 0dBm and the ROADM interface measured power is
   -6dBm the fiber patch cord connecting the two nodes may be pinched or
   the connectors are dirty.  As discussed before, the actual path or
   selection of a specific wavelength within the allowed set is outside
   the scope of LMP.  The computing entities (e.g. the first optical
   node originating the circuit) can rely on GMPLS IGP (OSPF) to
   retrieve all the information related to the network, calculate the
   path to reach the endpoint and signal the path implementation through
   the network via RSVP-TE.

   [ITU-T.G.698.2] defines a single channel optical interface for DWDM
   systems that allows interconnecting network-external optical
   transponders across a DWDM network.  The optical transponders are
   external to the DWDM network.  This so-called 'Black Link' approach
   illustrated in Fig. 5-1 of [ITU-T.G.698.2].  The single channel fiber
   link between the Ss/Rs reference points and the ingress/egress port
   of the network element on the domain boundary of the DWDM network
   (DWDM border NE) is called access link.  Based on the definition in
   [ITU-T.G.698.2] it is part of the DWDM network.  The access link is
   typically realized as a passive fiber link that has a specific
   optical attenuation (insertion loss).  As the access link is an
   integral part of the DWDM network, it is desirable to monitor its
   attenuation.  Therefore, it is useful to detect an increase of the
   access link attenuation, for example, when the access link fiber has
   been disconnected and reconnected (maintenance) and a bad patch panel
   connection (connector) resulted in a significantly higher access link
   attenuation (loss of signal in the extreme case of an open connector
   or a fiber cut).  In the following section, two use cases are
   presented and discussed:

        1) pure access link monitoring
        2) access link monitoring with a power control loop

   These use cases require a power monitor as described in G.697 (see
   section 6.1.2), that is capable to measure the optical power of the
   incoming or outgoing single channel signal.  The use case where a
   power control loop is in place could even be used to compensate an
   increased attenuation if the optical transmitter can still be
   operated within its output power range defined by its application
   code.

Hiremagalur, et al.       Expires 26 July 2024                  [Page 6]
Internet-Draft       draft-ietf-ccamp-dwdm-if-lmp-09        January 2024

4.  Extensions to LMP-WDM Protocol

   This document defines extensions to [RFC4209] to allow a set of
   characteristic parameters, to be exchanged between a router or
   optical switch (e.g.  OTN cross connect) and the optical line system
   to which it is attached.  In particular, this document defines
   additional Data Link sub-objects to be carried in the LinkSummary
   message defined in [RFC4204] and [RFC6205].  The OXC and OLS systems
   may be managed by different Network management systems and hence may
   not know the capability and status of their peer.  These messages and
   their usage are defined in subsequent sections of this document.

     The following new messages are defined for the WDM extension for
     ITU-T G.698.2 [ITU-T.G698.2]/ITU-T G.698.1 [ITU-T.G698.1]/
     ITU-T G.959.1 [ITU-T.G959.1]
       - OCh_General                 (sub-object Type = TBA)
       - OCh_ApplicationIdentier     (sub-object Type = TBA)
       - OCh_Ss                      (sub-object Type = TBA)
       - OCh_Rs                      (sub-object Type = TBA)

5.  General Parameters - OCh_General

   These are a set of general parameters as described in [G698.2] and
   [G.694.1].  Please refer to the "draft-ietf-ccamp-dwdm-if-param-yang"
   for more details about these parameters and the [RFC6205] for the
   wavelength definition.

    The general parameters are
     1. Central Frequency - (Tera Hz) 4 bytes (see RFC6205 sec.3.2)
     2. Number of Application Identifiers (A.I.) Supported
     3. Single-channel Application Identifier in use
     4. Application Identifier Type in use
     5. Application Identifier in use

   Figure 3: The format of the this sub-object (Type = TBA, Length =
   TBA) is as follows:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Type       |    Length     |         (Reserved)            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Central Frequency                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Number of Application                 |                     |
    |   Identifiers Supported                 |     (Reserved)      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Single-channel|  A.I. Type    |         A.I. length           |

Hiremagalur, et al.       Expires 26 July 2024                  [Page 7]
Internet-Draft       draft-ietf-ccamp-dwdm-if-lmp-09        January 2024

    | Application   |   in use      |                               |
    | Identifier    |               |                               |
    | Number in use |               |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           Single-channel Application Identifier in use        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           Single-channel Application Identifier in use        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           Single-channel Application Identifier in use        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      A.I. Type in use: STANDARD, PROPRIETARY

         A.I. Type in use: STANDARD

         Refers to G.698.2 recommendation (e.g.) :  B-DScW-ytz(v)

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                Single-channel Application Code                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                Single-channel Application Code                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                Single-channel Application Code                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         A.I. Type in use: PROPRIETARY

      Note: if the A.I. type = PROPRIETARY, the first 6 Octets of the
      Application Identifier in use are six characters of the
      PrintableString must contain the Hexadecimal representation of
      an OUI (Organizationally Unique Identifier) assigned to the
      vendor whose implementation generated the Application
      Identifier; the remaining octets of the PrintableString are
      unspecified.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        OUI                                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              OUI cont.        |           Vendor value        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           Vendor Value                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Hiremagalur, et al.       Expires 26 July 2024                  [Page 8]
Internet-Draft       draft-ietf-ccamp-dwdm-if-lmp-09        January 2024

                           Figure 3: OCh_General

6.  ApplicationIdentifier - OCh_ApplicationIdentifier

   This message is to exchange the application identifiers supported as
   described in [G698.2].  There can be more than one Application
   Identifier supported by the transmitter/receiver in the OXC.  The
   number of application identifiers supported is exchanged in the
   "OCh_General" message. (from [G698.1]/[G698.2]/[G959.1] and G.874.1)

    The parameters are:

        1. Number of Application Identifiers (A.I.) Supported

        2. Single-channel application identifier Number
           uniquely identifiers this entry - 8 bits

        3. Application Indentifier Type (A.I.) (STANDARD/PROPRIETARY)

        4. Single-channel application identifier -- 96 bits
           (from [G698.1]/[G698.2]/[G959.1]

      - this parameter can have
           multiple instances as the transceiver can support multiple
           application identifiers.

   Figure 4: The format of the this sub-object (Type = TBA, Length =
   TBA) is as follows:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Type       |    Length     |         (Reserved)            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Number of Application                 |                     |
    |   Identifiers Supported                 |     (Reserved)      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Single-channel|  A.I. Type    |         A.I. length           |
    | Application   |               |                               |
    | Identifier    |               |                               |
    | Number        |               |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |               Single-channel Application Identifier           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Hiremagalur, et al.       Expires 26 July 2024                  [Page 9]
Internet-Draft       draft-ietf-ccamp-dwdm-if-lmp-09        January 2024

    |               Single-channel Application Identifier           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |               Single-channel Application Identifier           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    //              ....                                           //
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Single-channel|               |         A.I. length           |
    | Application   |   A.I. Type   |                               |
    | Identifier    |               |                               |
    | Number        |               |                               |
    |               |               |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |               Single-channel Application Identifier           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |               Single-channel Application Identifier           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |               Single-channel Application Identifier           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      A.I. Type in use: STANDARD, PROPRIETARY

       A.I. Type in use: STANDARD
       Refers to G.698.2 recommendation :  B-DScW-ytz(v)

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                Single-channel Application Code                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                Single-channel Application Code                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                Single-channel Application Code                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         A.I. Type in use: PROPRIETARY

      Note: if the A.I. type = PROPRIETARY, the first 6 Octets of the
      Application Identifier in use are six characters of the
      PrintableString must contain the Hexadecimal representation of
      an OUI (Organizationally Unique Identifier) assigned to the
      vendor whose implementation generated the Application
      Identifier; the remaining octets of the PrintableString are
      unspecified.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

Hiremagalur, et al.       Expires 26 July 2024                 [Page 10]
Internet-Draft       draft-ietf-ccamp-dwdm-if-lmp-09        January 2024

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        OUI                                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              OUI cont.        |           Vendor value        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           Vendor Value                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 4: OCh_ApplicationIdentifier

7.  OCh_Ss - OCh transmit parameters

   These are the G.698.2 parameters at the Source(Ss reference points).
   Please refer to "draft-ietf-ccamp-dwdm-if-param-yang" for more
   details about these parameters.

       1. Output power

   Figure 5: The format of the OCh sub-object (Type = TBA, Length = TBA)
   is as follows:

     0                   1                   2                  3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Type       |    Length     |         (Reserved)            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Output Power                             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 5: OCh_Ss transmit parameters

8.  OCh_Rs - receive parameters

   These are the G.698.2 parameters at the Sink (Rs reference points).

       1.  Current Input Power      - (0.1dbm) 4bytes

   Figure 6: The format of the OCh receive sub-object (Type = TBA,
   Length = TBA) is as follows:

Hiremagalur, et al.       Expires 26 July 2024                 [Page 11]
Internet-Draft       draft-ietf-ccamp-dwdm-if-lmp-09        January 2024

     The format of the OCh receive/OLS Sink sub-object (Type = TBA,
     Length = TBA) is as follows:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Type       |    Length     |                   (Reserved)  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                   Current Input Power                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 6: OCh_Rs receive parameters

9.  Security Considerations

   LMP message security uses IPsec, as described in [RFC4204].  This
   document only defines new LMP objects that are carried in existing
   LMP messages, similar to the LMP objects in [RFC:4209].  This
   document does not introduce new security considerations.

10.  IANA Considerations

      LMP <xref target="RFC4204"/> defines the following name spaces and
      the ways in which IANA can make assignments to these namespaces:

    -  LMP Message Type
    -  LMP Object Class
    -  LMP Object Class type (C-Type) unique within the Object Class
    -  LMP Sub-object Class type (Type) unique within the Object Class
     This memo introduces the following new assignments:

      LMP Sub-Object Class names:

    under DATA_LINK Class name (as defined in <xref target="RFC4204"/>)
      - OCh_General                  (sub-object Type = TBA)
      - OCh_ApplicationIdentifier    (sub-object Type = TBA)
      - OCh_Ss                       (sub-object Type = TBA)
      - OCh_Rs                       (sub-object Type = TBA)

11.  Contributors

Hiremagalur, et al.       Expires 26 July 2024                 [Page 12]
Internet-Draft       draft-ietf-ccamp-dwdm-if-lmp-09        January 2024

               Arnold Mattheus
                 Deutsche Telekom
                 Darmstadt
                 Germany
                 email a.mattheus@telekom.de

               John E. Drake
                 Juniper
                 1194 N Mathilda Avenue
                 HW-US,Pennsylvania
                 USA
                 jdrake@juniper.net

               Zafar Ali
                 Cisco
                 3000 Innovation Drive
                 KANATA
                 ONTARIO K2K 3E8
                 zali@cisco.com

12.  References

12.1.  Normative References

   [RFC4204]  Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204,
              DOI 10.17487/RFC4204, October 2005,
              <https://www.rfc-editor.org/info/rfc4204>.

   [RFC4209]  Fredette, A., Ed. and J. Lang, Ed., "Link Management
              Protocol (LMP) for Dense Wavelength Division Multiplexing
              (DWDM) Optical Line Systems", RFC 4209,
              DOI 10.17487/RFC4209, October 2005,
              <https://www.rfc-editor.org/info/rfc4209>.

   [RFC6205]  Otani, T., Ed. and D. Li, Ed., "Generalized Labels for
              Lambda-Switch-Capable (LSC) Label Switching Routers",
              RFC 6205, DOI 10.17487/RFC6205, March 2011,
              <https://www.rfc-editor.org/info/rfc6205>.

   [ITU-T.G.698.2]
              International Telecommunications Union, "Amplified
              multichannel dense wavelength division multiplexing
              applications with single channel optical interfaces",
              ITU-T Recommendation G.698.2, November 2009.

Hiremagalur, et al.       Expires 26 July 2024                 [Page 13]
Internet-Draft       draft-ietf-ccamp-dwdm-if-lmp-09        January 2024

   [ITU-T.G694.1]
              International Telecommunications Union, ""Spectral grids
              for WDM applications: DWDM frequency grid"",
              ITU-T Recommendation G.698.2, February 2012.

   [ITU-T.G709]
              International Telecommunications Union, "Interface for the
              Optical Transport Network (OTN)", ITU-T Recommendation
              G.709, June 2016.

   [ITU-T.G872]
              International Telecommunications Union, "Architecture of
              optical transport networks", ITU-T Recommendation G.872,
              January 2017.

   [ITU-T.G874.1]
              International Telecommunications Union, "Optical transport
              network (OTN): Protocol-neutral management information
              model for the network element view", ITU-T Recommendation
              G.874.1, November 2016.

12.2.  Informative References

   [RFC3410]  Case, J., Mundy, R., Partain, D., and B. Stewart,
              "Introduction and Applicability Statements for Internet-
              Standard Management Framework", RFC 3410,
              DOI 10.17487/RFC3410, December 2002,
              <https://www.rfc-editor.org/info/rfc3410>.

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              DOI 10.17487/RFC2629, June 1999,
              <https://www.rfc-editor.org/info/rfc2629>.

   [RFC4181]  Heard, C., Ed., "Guidelines for Authors and Reviewers of
              MIB Documents", BCP 111, RFC 4181, DOI 10.17487/RFC4181,
              September 2005, <https://www.rfc-editor.org/info/rfc4181>.

   [RFC4054]  Strand, J., Ed. and A. Chiu, Ed., "Impairments and Other
              Constraints on Optical Layer Routing", RFC 4054,
              DOI 10.17487/RFC4054, May 2005,
              <https://www.rfc-editor.org/info/rfc4054>.

Authors' Addresses

Hiremagalur, et al.       Expires 26 July 2024                 [Page 14]
Internet-Draft       draft-ietf-ccamp-dwdm-if-lmp-09        January 2024

   Dharini Hiremagalur (editor)
   Juniper
   1194 N Mathilda Avenue
   Sunnyvale - 94089 California,
   United States of America
   Phone: +1408
   Email: dharinih@juniper.net

   Gert Grammel (editor)
   Juniper
   Oskar-Schlemmer Str. 15
   80807 Muenchen
   Germany
   Phone: +49 1725186386
   Email: ggrammel@juniper.net

   Gabriele Galimberti (editor)
   Cisco
   Via S. Maria Molgora, 48 c
   20871 - Vimercate
   Italy
   Phone: +390392091462
   Email: ggalimbe56@gmail.com

   Ruediger Kunze (editor)
   Deutsche Telekom
   Winterfeldtstr. 21-27
   10781 Berlin
   Germany
   Phone: +491702275321
   Email: RKunze@telekom.de

   Dieter Beller
   Nokia
   Lorenzstrasse, 10
   70435 Stuttgart
   Germany
   Phone: +4971182143125
   Email: Dieter.Beller@nokia.com

Hiremagalur, et al.       Expires 26 July 2024                 [Page 15]