[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-kdkgall-ccamp-dwdm-if-mng-ctrl-fwk) 00 01 02 03 04 05 06 07 08 09 10 11

Internet Engineering Task Force                            R. Kunze, Ed.
Internet-Draft                                          Deutsche Telekom
Intended status: Informational                           G. Grammel, Ed.
Expires: December 13, 2018                                       Juniper
                                                               D. Beller
                                                                   Nokia
                                                      G. Galimberti, Ed.
                                                                   Cisco
                                                               J. Meuric
                                                                  Orange
                                                           June 11, 2018


    A framework for Management and Control of DWDM optical interface
                               parameters
                draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-11

Abstract

   The control and management of DWDM interfaces are a precondition for
   enhanced multilayer networking.  They are needed to ensure an
   efficient data transport, to meet the requirements requested by
   today's IP-services and to provide a further automation of network
   provisioning and operations.  This document describes use cases,
   requirements and solutions for the control and management of optical
   interface parameters according to different types of single channel
   DWDM interfaces.  The focus is on automating the network provisioning
   process irrespective on how it is triggered i.e. by Element Manager
   System (EMS), Network Management System (NMS) or Generalized Multi
   Protocol Label Switching (GMPLS).  This document covers management
   and control considerations in different scenarios of single channel
   DWDM interfaces.  The purpose is to identify the necessary
   information and processes to be used by control or management systems
   to properly and efficiently drive the network.

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




Kunze, et al.           Expires December 13, 2018               [Page 1]


Internet-Draft  draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-11       June 2018


   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 December 13, 2018.

Copyright Notice

   Copyright (c) 2018 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 Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
   2.  Terminology and Definitions . . . . . . . . . . . . . . . . .   4
   3.  Solution Space  . . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  Comparison of Approaches for Transverse Compatibility . .   6
       3.1.1.  Multivendor DWDM Line System with Transponders  . . .   6
       3.1.2.  Integrated Single Channel DWDM Deployments on the
               Client Site . . . . . . . . . . . . . . . . . . . . .   7
   4.  Solutions for Managing and Controlling Single Channel Optical
       Interface . . . . . . . . . . . . . . . . . . . . . . . . . .   9
     4.1.  Separate Operation and Management Approaches  . . . . . .  10
       4.1.1.  Direct Connection to the Management System  . . . . .  10
       4.1.2.  Indirect Connection to the DWDM Management System
               (First Optical Node)  . . . . . . . . . . . . . . . .  11
     4.2.  Control Plane Considerations  . . . . . . . . . . . . . .  13
       4.2.1.  Considerations Using GMPLS Signaling  . . . . . . . .  14
   5.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .  15
     5.1.  Service Setup . . . . . . . . . . . . . . . . . . . . . .  15
     5.2.  Link Monitoring Use Cases . . . . . . . . . . . . . . . .  16
       5.2.1.  Pure Access Link (AL) Monitoring Use Case . . . . . .  19
       5.2.2.  Power Control Loop Use Case . . . . . . . . . . . . .  21
   6.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .  23
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  25
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  25
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  25
   10. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  25



Kunze, et al.           Expires December 13, 2018               [Page 2]


Internet-Draft  draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-11       June 2018


   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  26
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  26
     11.2.  Informative References . . . . . . . . . . . . . . . . .  28
   Appendix A.  Appendix . . . . . . . . . . . . . . . . . . . . . .  29
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  29

1.  Introduction

   The usage of external single channel Dense Wavelenght Division
   Multiplexing (DWDM) interfaces (e.g. in routers) connected to a DWDM
   Network (e.g. router connected to a network of Reconfigurable Optical
   Add Drop Multiplexers (ROADM) and optical amplifiers) adds a further
   networking option for operators but requires an harmonised control
   and management plane interaction between the different network
   domains.

   Carriers deploy their networks today based on transport and packet
   network infrastructures as domains to ensure high availability and a
   high level of redundancy combining the Packet and Transport
   restoration.  Both network domains were operated and managed
   separately.  This is the status quo in many carrier networks today.
   In the case of deployments where the optical transport interface
   moves into the client device (e.g. router) an interaction between
   those domains becomes necessary (e.g.  Lambda reprovisioning due to
   an optical restoration).

   This framework specifies different levels of control and management
   plane interaction to support the usage of single channel optical
   interfaces in carrier networks in an efficient manner.  The
   interfaces between the two layers can be either gray or coloured.

   Although Optical routing and wavelength assignment based on
   Wavelenght Switched Optical Network (WSON) is out of scope, they can
   benefit from the optical parameters that are exchanged between the
   Client and the DWDM Network.  Also, the wavelength ordering process
   and determining the demand for a new wavelength path through the
   network are out of scope.  The GMPLS and PCE functions will use the
   information collected from the Client and the DWDM network, the
   definition on how PCE and GMPLS can use the information and cooperate
   to implement RWA and circuit/service provisioning ar aout of scope of
   this document.

   Note that the Control and Management Planes are two separate entities
   that may handle the same information in different ways.







Kunze, et al.           Expires December 13, 2018               [Page 3]


Internet-Draft  draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-11       June 2018


1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP_14, RFC 2119 [RFC2119], RFC 8174 [RFC8174] when, and only when,
   they appear in all capitals, as shown here.

   While RFC 2119 [RFC2119] RFC 8174 [RFC8174] describe interpretations
   of these key words in terms of protocol specifications and
   implementations, they are used in this document to describe design
   requirements for protocol extensions.

2.  Terminology and Definitions

   The current generation of Wavelenght Division Multiplexing (WDM)
   networks are single vendor networks where the optical line system and
   the transponders are tightly integrated.  The DWDM interface
   migration from integrated transponders to third party transponders or
   colored interfaces change this scenario and introduces a standardized
   interface at the level of OCh between the DWDM interface and the DWDM
   network.

   Black Link: The Black Link [ITU-T.G.698.2] allows supporting an
   optical transmitter/receiver pair (of a single vendor or from
   different vendors) to provide a single optical channel interface and
   transport it over an optical network composed of amplifiers, filters,
   add-drop multiplexers these being possibly from different vendors.
   Therefore the standard defines the ingress and egress parameters for
   the optical interfaces at the reference points Source side (Ss) and
   Receive side (Rs).

   Single Channel DWDM Interface: The single channel interfaces to DWDM
   systems defined in [ITU-T.G.698.2], which currently include the
   following features: channel frequency spacing: 50 GHz and wider
   (defined in [ITU-T.G.694.1] ); bit rate of single channel: Up to 10
   Gbit/s.  Future revisions are expected to include application codes
   for bit rates up to 40 Gb/s.

   Forward Error Correction (FEC): FEC is a way of improving the
   performance of high-capacity optical transmission systems.  Employing
   FEC in optical transmission systems yields system designs that can
   accept relatively large BER (much more than 10^-12) in the optical
   transmission line (before decoding).

   Administrative domain [ITU-T.G.805]: the extent of resources which
   belong to a single player such as a network operator, a service




Kunze, et al.           Expires December 13, 2018               [Page 4]


Internet-Draft  draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-11       June 2018


   provider or an end-user.  Administrative domains of different players
   do not overlap amongst themselves.

   Intra-domain interface (IaDI) [ITU-T.G.872]: A physical interface
   within an administrative domain.

   Inter-domain interface (IrDI) [ITU-T.G.872]: A physical interface
   that represents the boundary between two administrative domains.

   Management Plane [ITU-T.G.8081],: The management plane performs
   management functions for the transport plane, the control plane and
   the system as a whole.  It also provides coordination between all the
   planes.  The following management functional areas are performed in
   the management plane: performance management, fault management,
   configuration management, accounting management and security
   management.

   Control Plane [ITU-T.G.8081]: Through signaling, the control plane
   sets up and releases connections, may restore a connection in case of
   a failure, and also performs other functions (e.g., neighbor
   discovery, topology distribution) in support of those.

   Transponder: A Transponder is a network element that performs O/E/O
   (Optical /Electrical/Optical) conversion.  In this document it is
   referred only transponders with 3R (rather than 2R or 1R
   regeneration) as defined in [ITU-T.G.872].

   Line System: A Line System is a portion of the network including
   Reconfigurable Add Drop Multiplexers (ROADM) Line Amplifiers and the
   the fibers connecting them.

   Client DWDM interface: A Transceiver element that performs E/O
   (Electrical/Optical) conversion.  In this document it is referred as
   the DWDM side of a transponder as defined in [ITU-T.G.872].

3.  Solution Space

   The solution space of this document is focusing on aspects related to
   the management and control of single-channel optical interface
   parameters of physical point-to-point and ring DWDM applications on
   single-mode optical fibres and allows the direct connection of a wide
   variety of equipment using a DWDM link, for example

   1.  A digital cross-connect with multiple optical interfaces,
       supplied by a different vendor from the line system

   2.  Devices as routing, switching or compute nodes, each from a
       different vendor, providing optical line interfaces



Kunze, et al.           Expires December 13, 2018               [Page 5]


Internet-Draft  draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-11       June 2018


   3.  A combination of the above

3.1.  Comparison of Approaches for Transverse Compatibility

   This section describes two ways to achieve transverse compatibility.
   Section 3.1.1 describes the classic model based on well defined
   inter-domain interfaces.  Section 3.1.2 defines a model ensuring
   interoperability on the line side of the optical network.

3.1.1.  Multivendor DWDM Line System with Transponders

   As illustrated in Figure 1, for this approach interoperability is
   achieved via the use of optical transponders providing OEO (allowing
   conversion to appropriate parameters).  The optical interfaces can
   then be any short reach standardized optical interface that both
   vendors support, such as those found in [ITU-T.G.957], [ITU-T.G.691],
   [ITU-T.G.693], etc.



               IrDI                            IaDI
                |                                |
                .                                .
                |   +----------------------------|----+
                .   |     +    WDM Domain     +  .    |
                |   |     |\                 /|  |    |
   +------+     .   |     | \     |\        / |  .    |       +------+
   |  TX/ |-->--+---+--T/-|OM|----|/-------|OD|--+-\T-+---->--| RX/  |
   |  RX  |--<--+---+--T/-|  |----- /|-----|  |--.-\T-+----<--| TX   |
   +------+     |   |     | /       \|      \ |  |    |       +------+
                .   |     |/                 \|  .    |
                |   |     +                   +  |    |
                .   +----------------------------.----+
                |                                |


           TX/RX = Single channel non-DWDM interfaces
           T/ = Transponder
           OM = Optical Mux
           OD = Optical Demux


         Figure 1: Inter and Intra-Domain Interface Identification

   In the scenario of Figure 1 the administrative domain is defined by
   the Interdomain Interface (IrDI).  This interface terminates the DWDM
   domain.  The line side is characterized by the IaDI.  This interface
   specifies the internal parameter set of the optical administrative



Kunze, et al.           Expires December 13, 2018               [Page 6]


Internet-Draft  draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-11       June 2018


   domain.  In the case of a client DWDM interface deployment this
   interface moves into the client device and extends the optical and
   administrative domain towards the client node.  [ITU-T.G.698.2] for
   example specifies a set of parameter set for a certain set of
   applications.

   This document elaborates only the IaDI (Intra Domain Interface) as
   shown in Figure 1 as DWDM transversely compatible and multi-vendor
   interface within one administrative domain controlled by the network
   operator.

   SNMP/Simple Management Interface (SMI), NETCONF/RESTCONF and Link
   Management Protocol (LMP) TLV to support the direct exchange of
   information between the client and the network management and control
   plane will be specified in further documents.

   The YANG based NETCONF and RESTCONF protocol are better suited for
   creating and modifying configuration state and thus RECOMMENDED to be
   used over SNMP MIB.  The SNMP MIB creating and modifying
   configuration state could be used for legacy network.

3.1.2.  Integrated Single Channel DWDM Deployments on the Client Site

   In case of a deployment as shown in Figure 2, through the use of DWDM
   interfaces, multi-vendor interconnection can also be achieved.  Among
   the possible use cases, it may be used to remove the need for one
   short reach transmitter and receiver pair per channel (eliminating
   the transponders).























Kunze, et al.           Expires December 13, 2018               [Page 7]


Internet-Draft  draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-11       June 2018


   Figure 2 shows a set of reference points, for single-channel
   connection (Ss and Rs) between transmitters (Tx) and receivers (Rx).
   Here the DWDM network elements include an optical multiplexer (OM)
   and an optical demultiplexer (OD) (which are used as a pair with the
   peer element), one or more optical amplifiers and may also include
   one or more ROADMs.


        |==================== Black Link =======================|


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

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


   Linear DWDM network as per ITU-T G.698.2

                        Figure 2: Linear Black Link

   The single administrative domain may consist of several vendor
   domains.  Even in that case a common network management and control
   is required to ensure a consistent operation and provisioning of the
   entire connection.





Kunze, et al.           Expires December 13, 2018               [Page 8]


Internet-Draft  draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-11       June 2018


   SNMP/SMI, NETCONF/RESTCONF and LMP TLV to support the direct exchange
   of information between the client and the network management and
   control plane will be specified in further documents.

4.  Solutions for Managing and Controlling Single Channel Optical
    Interface

   Operation and management of WDM systems is traditionally seen as a
   homogenous group of tasks that could be carried out best when a
   single management system or a hierarchical management system is used.
   Currently each WDM vendor provides an Element Management System (EMS)
   that also provisions the wavelengths.  In a multi-vendor line system,
   such single-vendor EMS requirement is no more effective.  New methods
   of managing and controlling line systems need to be looked at.

   Therefore from the operational point of view the following approaches
   will be considered to manage and operate optical interfaces.

   1.  Separate operation and management of client device and the
       transport network whereas the interface of the client belongs to
       the administrative domain of the transport network and will be
       managed by the transport group.  This results in two different
       approaches to send information to the management system

       a.  Direct connection from the client node to the transport
       management system, ensuring a management of the DWDM interface of
       the optical network (e.g.  EMS, NMS)

       b.  Indirect connection to the management system of the optical
       network using a protocol (e.g.  LMP) between the client device
       and the directly connected WDM system node to exchange management
       information with the optical domain

   2.  Common operation and management of client device including the
       single channel DWDM part and the Transport network

   The first option keeps the status quo in large carrier networks as
   mentioned above.  In that case it must be ensured that the full FCAPS
   Management (Fault, Configuration, Accounting, Performance and
   Security) capabilities are supported.  This means from the management
   staff point of view nothing changes.  The transceiver/receiver
   optical interface will be part of the optical management domain and
   will be managed from the transport management staff.

   The second solution addresses the case where underlying WDM transport
   network is mainly used to interconnect a homogeneous set of client
   nodes (e.g.  IP routers or digital crossconnects).  Since the service
   creation and restoration could be done by the higher layers (e.g.



Kunze, et al.           Expires December 13, 2018               [Page 9]


Internet-Draft  draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-11       June 2018


   IP), this may lead to an efficient network operation and a higher
   level of integration.

4.1.  Separate Operation and Management Approaches

4.1.1.  Direct Connection to the Management System

   As depicted in Figure 3 (case 1a) one possibility to manage the
   optical interface within the client domain is a direct connection to
   the management system of the optical domain.  This ensures
   manageability as usual.

                        +-----+
                        | NMS |
                        |_____|
                        /_____/
                           |
                           |
                           |
                       +---+---+
                +----->+  EMS  |
               /       |       |
              /        +-------+
             /             | MI SNMP or NETCONF/RESTCONF
       SNMP / or NETCONF   |                DCN Network
       --------------------+-------------------------------
          /         +------+-----------------------+
         /          |     +|     WDM Domain   +    |
        /           |     |\                 /|    |
   +---+--+         |     | \     |\        / |    |          +------+
   |  CL  |-/C------+-----|OM|----|/-------|OD|----+-------/C-|  CL  |
   |      |-/C------+-----|  |----- /|-----|  |----+-------/C-|      |
   +------+         |     | /       \|      \ |    |          +------+
                    |     |/                 \|    |
                    |     +                   +    |
                    +------------------------------+

           CL = Client Device
           /C = Single Channel Optical Interface
           OM = Optical Mux
           OD = Optical Demux
           EMS = Element Management System
           MI = Management Interface
           DCN = Data Control Network

       Figure 3: Connecting Single Channel optical interfaces to the
                        Transport Management system




Kunze, et al.           Expires December 13, 2018              [Page 10]


Internet-Draft  draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-11       June 2018


   The exchange of management information between client device and the
   management system assumes that some form of a direct management
   communication link exists between the client device and the DWDM
   management system (e.g.  EMS).  This may be an Ethernet Link or a DCN
   connection (management communication channel MCC).

   It must be ensured that the optical network interface can be managed
   in a standardized way to enable interoperable solutions between
   different optical interface vendors and vendors of the optical
   network management application.  [RFC3591] defines managed objects
   for the optical interface type but needs further extension to cover
   the optical parameters required by this framework document.

   Is to be noted that the CL (client device) and the DWDM network are
   belonging to the same operator so the DWDM EMS and the Client devices
   are connected to the same DCN and the communication security
   considerations are applicable to CL as per DWDM devices.

   Note that a software update of the optical interface components of
   the client nodes must not lead obligatory to an update of the
   software of the EMS and vice versa.

4.1.2.  Indirect Connection to the DWDM Management System (First Optical
        Node)



























Kunze, et al.           Expires December 13, 2018              [Page 11]


Internet-Draft  draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-11       June 2018


   An alternative as shown in Figure 4 should be used in cases where a
   more integrated relationship between transport node (e.g.  OM or OD
   or ROADM) and client device is aspired.  In that case a combination
   of control plane features and manual management will be used.

                        +-----+
                        | NMS |
                        |_____|
                        /_____/
                           |
                           |
                       +---+---+
                       | EMS   |
                       |       |
                       +-------+
                           | MI  SNMP or NETCONF/RESTCONF
                           |
           LMP      +------+-----------------------+
       +------------+---+ +|                  +    |
       |            |   | |\                 /|    |
   +---+--+         |   +-+ \     |\        / |    |          +------+
   |  CL  |-/C------+--- -|OM|----|/-------|OD|--- +-------/C-|  CL  |
   |      |-/C------+--- -|  |----- /|-----|  |----+-------/C-|      |
   +------+         |     | /       \|      \ |    |          +------+
                    |     |/                 \|    |
                    |     +                   +    |
                    +------------------------------+

           CL = Client Device
           /C = Single Channel optical Interface
           OM = Optical Mux
           OD = Optical Demux
           EMS= Element Management System
           MI= Management Interface

      Figure 4: Direct connection between peer node and first optical
                               network node

   For information exchange between the client node and the direct
   connected node of the optical transport network LMP as specified in
   RFC 4209 [RFC4209] should be used.  This extension of LMP may be used
   between a peer node and an adjacent optical network node as depicted
   in Figure 4.

   At the time of writing this document, LMP does not yet support the
   transmission of configuration data (information).  This functionality
   would need to be added to the protocol.  The use of LMP assumes that




Kunze, et al.           Expires December 13, 2018              [Page 12]


Internet-Draft  draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-11       June 2018


   some form of a control channel exists between the client node and the
   WDM equipment.  This may be a dedicated lambda or an Ethernet Link.

4.2.  Control Plane Considerations

   The concept of integrated single channel DWDM interfaces equally
   applies to management and control plane mechanisms.  GMPLS control
   plane protocols have been extended for WSON, e.g.  RFC 7689 [RFC7689]
   ) for fixed grid signal and for flexi-grid RFC 7792 [RFC7792] ).  One
   important aspect of the Black Link [ITU-T.G.698.2] is the fact that
   it includes the wavelength that is supported by the given link.
   Therefore, the link can logically be considered as a fiber that is
   transparent only for a single wavelength.  In other words, the
   wavelength becomes a characteristic of the link itself.

   Nevertheless the procedure to light up the fiber may vary depending
   on the implementation.  Since the implementation is unknown a priori,
   different sequences to light up a wavelength need to be considered:

   1.  Interface first, interface tuning: The transmitter is switched on
       and the link is immediately transparent to its wavelength.  This
       requires the transmitter to carefully tune power and frequency
       not overload the line system or to create transients.

   2.  Interface first, Optical Line System (OLS) tuning: The
       transmitter is switched on first and can immediately go to the
       max power allowed since the OLS performs the power tuning.  This
       leads to an intermediate state where the receiver does not
       receive a valid signal while the transmitter is sending out one.
       Alarm suppression mechanisms shall be employed to overcome that
       condition.

   3.  OLS first, interface tuning: At first the OLS is tuned to be
       transparent for a given wavelength, then transponders need to be
       tuned up.  Since the OLS in general requires the presence of a
       wavelength to fine-tune its internal facilities there may be a
       period where a valid signal is transmitted but the receiver is
       unable to detect it.  This equally need to be covered by alarm
       suppression mechanisms.

   4.  OLS first, OLS tuning: The OLS is programmed to be transparent
       for a given wavelength, then the interfaces need to be switched
       on and further power tuning takes place.  The sequencing of
       enabling the link needs to be covered as well.

   The preferred way to address these in a Control Plane enabled network
   is neighbour discovery including exchange of link characteristics and
   link property correlation.  The general mechanisms are covered in RFC



Kunze, et al.           Expires December 13, 2018              [Page 13]


Internet-Draft  draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-11       June 2018


   4209 [RFC4209] and RFC 4204 [RFC4204] which provides the necessary
   protocol framework to exchange those characteristics between client
   and Black Link.  LMP-WDM is not intended for exchanging routing or
   signaling information nor to provision the lambda in the transceiver
   but covers:

   1.  Control channel management

   2.  Link property correlation

   3.  Link verification

   4.  Fault management

   Extensions to LMP covering the parameter sets (e.g. application
   codes) are needed.  Additionally, when client and server side are
   managed by different operational entities, the link state may be
   useful to help the management system to do troubleshooting or alarm
   correlation.

4.2.1.  Considerations Using GMPLS Signaling

   The deployment of single channel optical interfaces is leading to
   some functional changes related to the control plane models and has
   therefore some impact on the existing interfaces especially in the
   case of a model where the edge node requests resources from the core
   node and the edge node do not participate in the routing protocol
   instance that runs among the core nodes.  RFC 4208 [RFC4208] defines
   the GMPLS UNI that can be used between edge and core node.  In case
   of integrated interfaces deployment additional functionalities are
   needed to setup a connection.

   It is necessary to differentiate between topology/signalling
   information and configuration parameters that are needed to setup a
   wavelength path.  Using RSVP-TE could be used for the signalling and
   the reservation of the wavelength path.  But there are additional
   information needed before RSVP-TE can start the signalling process.
   There are three possibilities to proceed:

   a.  Using RSVP-TE only for the signalling and LMP as described above
       to exchange information on the configured optical interface
       within the edge node

   b.  RSVP-TE (typically with loose ERO) to transport additional
       information






Kunze, et al.           Expires December 13, 2018              [Page 14]


Internet-Draft  draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-11       June 2018


   c.  Leaking IGP information instead of exchanging this information
       needed from the optical network to the edge node (UNI will be
       transformed to a border-peer model, see RFC 5146 [RFC5146] )

   Furthermore following issues should be addressed:

   a) The transceivers of peering edge nodes must be compatible.  For
   example, it may be required to know about FEC, modulation scheme, The
   modulation format, the baudrate and many other parameters described
   in the drafts reported in the Annex.  Depending on where the
   information is available, compatibility check may either happen
   before signaling, when the signaling reaches the optical network
   (e.g. at path computation time), or in the tail end node.  An
   extended version of LMP is needed to exchange this information in
   case a. above, and to RSVP-TE as well in b.  It would be helpful to
   define some common profiles that will be supported (e.g. the
   "application identifier") to summarize interface capabilities: if
   both profiles match, signaling can succeed and provisioning be
   achieved.

   b) Due to the bidirectional wavelength path that must be setup, the
   upstream edge node must include a wavelength value into the RSVP-TE
   Path message.  But in the case of a UNI model the client device may
   not have full information about which wavelength must/should be
   selected, whereas this information must be exchanged between the edge
   and the core node.  The special value defined in
   [Network-Assigned-Upstream-Label] allows the optical network to
   assign the actual wavelength to be used by the upstream transponder,
   which is a simple and efficient solution to this issue.

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

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



Kunze, et al.           Expires December 13, 2018              [Page 15]


Internet-Draft  draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-11       June 2018


   scheme, modulation parameters, FEC to name a few.  If both
   transceivers are controlled by the same NMS or CP, such data is
   readily available.  However in cases like Figure 4, 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 a 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.

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




Kunze, et al.           Expires December 13, 2018              [Page 16]


Internet-Draft  draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-11       June 2018


   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] and a copy of this figure
   is provided below in Figure 5.  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.

















Kunze, et al.           Expires December 13, 2018              [Page 17]


Internet-Draft  draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-11       June 2018


   Use case 1: Access Link monitoring


                                       +--------------------------+
                                       |    P(in) = P(Tx) - a(Tx) |
                                       |    ___                   |
       +----------+                    |    \ /   Power Monitor   |
       |          | P(Tx)              |     V    P(in)           |
       |  +----+  | Ss    //\\         |     |    |\              |
       |  | TX |----|-----\\//------------------->| \             |
       |  +----+  | Access Link (AL-T) |       .  |  |            |
       |          | attenuation a(Tx)  |       .  |  |==============>
       |          |                    |       .  |  |            |
       | External |                    |      --->| /             |
       | Optical  |                    |          |/              |
       |Transpond.|                    |    P(out)                |
       |          |                    |    ___                   |
       |          |                    |    \ /   Power Monitor   |
       |          | P(Rx)              |     V    P(out)          |
       |  +----+  | Rs    //\\         |     |    |\              |
       |  | RX |<---|-----\\//--------------------| \             |
       |  +----+  | Access Link (AL-R) |       .  |  |            |
       |          | Attenuation a(Rx)  |       .  |  |<==============
       +----------+                    |       .  |  |            |
                                       |      <---| /             |
       P(Rx) = P(out) - a(Rx)          |          |/              |
                                       |                          |
                                       |           ROADM          |
                                       +--------------------------+

        -  For AL-T monitoring: P(Tx) and a(Tx) must be known
        -  For AL-R monitoring: P(RX) and a(Rx) must be known

       An alarm shall be raised if P(in) or P(Rx) drops below a
       configured threshold (t [dB]):
       -  P(in) < P(Tx) - a(Tx) - t (Tx direction)
       -  P(Rx) < P(out) - a(Rx) - t (Rx direction)
       -  a(Tx) =| a(Rx)

      Alarms and events can be shared between Client and Network
      via LMP.

                  Figure 5: Access Link Power Monitoring








Kunze, et al.           Expires December 13, 2018              [Page 18]


Internet-Draft  draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-11       June 2018


5.2.1.  Pure Access Link (AL) Monitoring Use Case


     Figure 6 illustrates the access link monitoring use case and the
     different physical properties involved that are defined below:

   - Ss, Rs: Single Channel reference points
   - P(Tx):  current optical output power of transmitter Tx
   - a(Tx):  access link attenuation in Tx direction (external
             transponder point of view)
   - P(in):  measured current optical input power at the input port
             of border DWDM NE
   - t:      user defined threshold (tolerance)
   - P(out): measured current optical output power at the output port
             of border DWDM NE
   - a(Rx):  access link attenuation in Rx direction (external
             transponder point of view)
   - P(Rx):  current optical input power of receiver Rx

   Description:
   - The access link attenuation in both directions (a(Tx), a(Rx))
     is known or can be determined as part of the commissioning
     process.  Typically, both values are very similar.
   - A threshold value t has been configured by the operator. This
     should also be done during commissioning.
   - A control plane protocol is in place that allows
     to periodically send the optical power values P(Tx) and P(Rx)
     to the control plane protocol instance on the DWDM border NE.
     This is illustrated in Figure 3.
   - The DWDM border NE is capable to periodically measure the optical
     power P(in) and P(out) as defined in G.697 by power monitoring
     points depicted as triangles in the figures below.

   Access Link monitoring process:
   - Tx direction: the measured optical input power P(in) is compared
     with the expected optical input power P(Tx) - a(Tx). If the
     measured optical input power P(in) drops below the value
     (P(Tx) - a(Tx) - t) a low power alarm shall be raised indicating
     that the access link attenuation has exceeded a(Tx) + t.
   - Rx direction: the measured optical input power P(Rx) is
     compared with the expected optical input power P(out) - a(Rx).
     If the measured optical input power P(Rx) drops below the value
     (P(out) - a(Rx) - t) a low power alarm shall be raised indicating
     that the access link attenuation has exceeded a(Rx) + t.
   - to avoid toggling errors, the low power alarm threshold shall be
     lower than the alarm clear threshold.





Kunze, et al.           Expires December 13, 2018              [Page 19]


Internet-Draft  draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-11       June 2018


   Use case 2: Access Link monitoring through LMP



     +----------+                    +--------------------------+
     | +------+ |    P(Tx), P(Rx)    |  +-------+               |
     | |      | | =================> |  |       |               |
     | | LMP  | |    P(in), P(out)   |  |  LMP  |               |
     | | Agent| | <================= |  | Agent |               |
     | +------+ |                    |  +-------+               |
     |          |                    |                          |
     |          |                    |    P(in) - P(Tx) - a(Tx) |
     |          |                    |    ___                   |
     |          |                    |    \ /  Power Monitor    |
     |          | P(Tx)              |     V                    |
     |  +----+  | Ss    //\\         |     |    |\              |
     |  | TX |----|-----\\//------------------->| \             |
     |  +----+  | Access Link (AL-T) |       .  |  |            |
     |          | attenuation a(Tx)  |       .  |  |==============>
     |          |                    |       .  |  |            |
     | External |                    |      --->| /             |
     | Optical  |                    |          |/              |
     |Transpond.|                    |    P(out)                |
     |          |                    |    ___                   |
     |          |                    |    \ /  Power Monitor    |
     |          | P(Rx)              |     V                    |
     |  +----+  | Rs    //\\         |     |    |\              |
     |  | RX |<---|-----\\//--------------------| \             |
     |  +----+  | Access Link (AL-R) |       .  |  |            |
     |          | Attenuation a(Rx)  |       .  |  |<==============
     +----------+                    |       .  |  |            |
                                     |      <---| /             |
     P(Rx) = P(out) - a(Rx)          |          |/              |
                                     |                          |
                                     |           ROADM          |
                                     +--------------------------+

      - For AL-T monitoring: P(Tx) and a(Tx) must be known
      - For AL-R monitoring: P(RX) and a(Rx) must be known
      An alarm shall be raised if P(in) or P(Rx) drops below a
      configured threshold  (t [dB]):
      -  P(in) < P(Tx) - a(Tx) - t (Tx direction)
      -  P(Rx) < P(out) - a(Rx) - t (Rx direction)
      -  a(Tx) = a(Rx)

      Alarms and events can be shared between Client and Network
      via LMP according to [RFC4204] and [RFC4209]




Kunze, et al.           Expires December 13, 2018              [Page 20]


Internet-Draft  draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-11       June 2018


                       Figure 6: Extended LMP Model

5.2.2.  Power Control Loop Use Case


      This use case is based on the access link monitoring as
      described above. In addition, the border NE is running a power
      control application that is capable to control the optical output
      power of the single channel tributary signal at the output port
      of the border DWDM NE (towards the external receiver Rx) and the
      optical output power of the single channel tributary signal at
      the external transmitter Tx within their known operating range.
      The time scale of this control loop is typically relatively slow
      (e.g. some 10s or minutes) because the access link attenuation
      is not expected to vary much over time (the attenuation only
      changes when re-cabling occurs).
      From a data plane perspective, this use case does not require
      additional data plane extensions. It does only require a protocol
      extension in the control plane (e.g. this LMP draft) that allows
      the power control application residing in the DWDM border NE to
      modify the optical output power of the DWDM domain-external
      transmitter Tx within the range of the currently used application
      code. Figure 7 below illustrates this use case utilizing
      LMP with the extensions identified in this document.



























Kunze, et al.           Expires December 13, 2018              [Page 21]


Internet-Draft  draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-11       June 2018


   Use case 3: Power Control Loop



     +----------+                       +--------------------------+
     | +------+ |P(Tx),P(Rx),Set(P(out))|  +-------+   +--------+  |
     | |      | | ====================> |  |       |   | Power  |  |
     | | LMP  | | P(in),P(out),Set(PTx) |  |  LMP  |   |Control |  |
     | |      | | <==================== |  |       |   | Loop   |  |
     | +------+ |                       |  +-------+   +--------+  |
     |     |    |                       |                          |
     | +------+ |                       |    P(in) = P(Tx) - a(Tx) |
     | |C.Loop| |                       |    ___                   |
     | +------+ |                       |    \ /  Power Monitor    |
     |     |    | P(Tx)                 |     V                    |
     | +------+ | Ss    //\\            |     |    |\              |
     | | TX |>----|-----\\//---------------------->| \             |
     | +------+ | Access Link (AL-T)    |       .  |  |            |
     |  VOA(Tx) | attenuation a(Tx)     |       .  |  |==============>
     |          |                       |       .  |  |            |
     | External |                       |      --->| /             |
     | Optical  |                       |          |/              |
     |Transpond.|                       |    P(out)                |
     |          |                       |    ___                   |
     |          |                       |    \ /  Power Monitor    |
     |          | P(Rx)                 |     V                    |
     |  +----+  | Rs    //\\            |     |  VOA(out) |\       |
     |  | RX |<---|-----\\//---------------------<|-------| \      |
     |  +----+  | Access Link (AL-R)    |              .  |  |     |
     |          | attenuation a(Rx)     |              .  |  |<=======
     +----------+                       |        VOA(out) |  |     |
                                        |     <--<|-------| /      |
     P(Rx) = P(out) - a(Rx)             |                 |/       |
                                        |                          |
                                        |            ROADM         |
                                        +--------------------------+

                       Figure 7: Power control loop

      -  The power control loop in transponders and ROADMs controls
         the Variable Optical Attenuators (VOA) to adjust the proper
         power in base of the ROADM and Receiver characteristics and
         the Access Link attenuation








Kunze, et al.           Expires December 13, 2018              [Page 22]


Internet-Draft  draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-11       June 2018


6.  Requirements

   Even if network architectures becomes more complex, management and
   operation as well as the provisioning process should have a higher
   degree of automation or should be fully automated.  Simplifying and
   automating the entire management and provisioning process of the
   network in combination with a higher link utilization and faster
   restoration times will be the major requirements that have been
   addressed in this section.

   YANG based network management protocols such as NETCONF [RFC6241] or
   RESTCONF [RFC8040] are strongly suggested as the base for the
   communication among EMS, Controller and the Data Plane.

   Data plane interoperability as defined for example in [ITU-T.G.698.2]
   is a precondition to take full benefit from standardized interfaces
   between network and control/management plane.

   The following requirements are focusing on the usage of DWDM
   interfaces.































Kunze, et al.           Expires December 13, 2018              [Page 23]


Internet-Draft  draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-11       June 2018


   1  A procedure to setup an optical connection MUST be defined and
      implemented in DWDM and client devices (containing the single
      channel optical interface). The Procedure MAY me defined in a
      dedicated draft as proposed in Appendix.

   2  In order to ensure a lean management and provisioning of single
      channel interfaces, the management and control plane of both the
      client and DWDM network MUST be aware of the right set of
      parameters. Such parameters define the interfaces and the optical
      network and are needed to properly setup the optical connection.

   3  A standard-based northbound API (to network management system)
      based on NETCONF/RESTCONF SHOULD be supported, alternatively SNMP
      MAY be supported too.

   4  A standard-based data model for single channel interfaces MUST be
      supported to exchange optical parameters with control/management
      plane.

   5  NETCONF SHOULD be used also for configuration of the single
      channel interfaces including the power setting

   6  LMP SHOULD be extended and used in cases where optical
      parameters need to be exchanged between two nodes to correlate
      link characteristics and adopt the working mode of the single
      channel interface. The LMP extension MAY be defined in a draft
      as reported in Appendix.

   7  LMP MAY be used to adjust the output power of the single
      channel DWDM interface to ensure that the interface works in
      the right range.

   8  RSVP-TE SHOULD be used to exchange some relevant parameters
      between the client and the optical node (e.g. the label value),
      without preventing the network to remain in charge of the optical
      path computation

   9  Power monitoring functions at both ends of the DWDM connection
      MAY be used to further automate the setup and shutdown
      process of the optical interfaces.

   10 In fault cases, the network SHOULD be able to recover wavelengths,
      either using pre-defined paths or dynamic re-routing.

   11 LMP MAY be used to monitor and observe the access link.






Kunze, et al.           Expires December 13, 2018              [Page 24]


Internet-Draft  draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-11       June 2018


7.  Acknowledgements

   The authors would like to thank all who supported the work with
   fruitful discussions and contributions.

8.  IANA Considerations

   This memo includes no request to IANA.

9.  Security Considerations

   The architecture and solution space in scope of this framework
   imposes no additional requirements to the security models already
   defined in RFC5920 for packet/optical networks using GMPLS, covering
   also Control Plane and Management interfaces.  Respective security
   mechanisms of the components and protocols, e.g.  LMP security
   models, can be applied unchanged.

   As this framework is focusing on the single operator use case, the
   security concerns can be relaxed to a subset compared to a setup
   where information is exchanged between external parties and over
   external interfaces.

   Concerning the access control to Management interfaces, security
   issues can be generally addressed by authentication techniques
   providing origin verification, integrity and confidentiality.
   Additionally, access to Management interfaces can be physically or
   logically isolated, by configuring them to be only accessible out-of-
   band, through a system that is physically or logically separated from
   the rest of the network infrastructure.  In case where management
   interfaces are accessible in-band at the client device or within the
   optical transport network domain, filtering or firewalling techniques
   can be used to restrict unauthorized in-band traffic.  Authentication
   techniques may be additionally used in all cases.

10.  Contributors















Kunze, et al.           Expires December 13, 2018              [Page 25]


Internet-Draft  draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-11       June 2018


               Arnold Mattheus
                 Deutsche Telekom
                 Darmstadt
                 Germany
                 email arnold.Mattheus@telekom.de

               Manuel Paul
                 Deutsche Telekom
                 Berlin
                 Germany
                 email Manuel.Paul@telekom.de

               Josef Roese
                 Deutsche Telekom
                 Darmstadt
                 Germany
                 email j.roese@telekom.de

               Frank Luennemann
                 Deutsche Telekom
                 Muenster
                 Germany
                 email Frank.Luennemann@telekom.de

               Dharini Hiremagalur
                 Juniper
                 1133 Innovation Way
                 Sunnyvale - 94089 California
                 USA
                 dharinih@juniper.net


11.  References

11.1.  Normative References

   [ITU-T.G.694.1]
              International Telecommunications Union, "Spectral grids
              for WDM applications: DWDM frequency grid",
              ITU-T Recommendation G.694.1, Febriary 2012.

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





Kunze, et al.           Expires December 13, 2018              [Page 26]


Internet-Draft  draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-11       June 2018


   [ITU-T.G.805]
              International Telecommunications Union, "Spectral grids
              for WDM applications: DWDM frequency grid",
              ITU-T Recommendation G.805, March 2000.

   [ITU-T.G.872]
              International Telecommunications Union, "Architecture of
              optical transport networks", ITU-T Recommendation G.872,
              November 2001.

   [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/info/rfc2119>.

   [RFC3591]  Lam, H-K., Stewart, M., and A. Huynh, "Definitions of
              Managed Objects for the Optical Interface Type", RFC 3591,
              DOI 10.17487/RFC3591, September 2003,
              <https://www.rfc-editor.org/info/rfc3591>.

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

   [RFC4208]  Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,
              "Generalized Multiprotocol Label Switching (GMPLS) User-
              Network Interface (UNI): Resource ReserVation Protocol-
              Traffic Engineering (RSVP-TE) Support for the Overlay
              Model", RFC 4208, DOI 10.17487/RFC4208, October 2005,
              <https://www.rfc-editor.org/info/rfc4208>.

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

   [RFC7689]  Bernstein, G., Ed., Xu, S., Lee, Y., Ed., Martinelli, G.,
              and H. Harai, "Signaling Extensions for Wavelength
              Switched Optical Networks", RFC 7689,
              DOI 10.17487/RFC7689, November 2015,
              <https://www.rfc-editor.org/info/rfc7689>.









Kunze, et al.           Expires December 13, 2018              [Page 27]


Internet-Draft  draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-11       June 2018


   [RFC7792]  Zhang, F., Zhang, X., Farrel, A., Gonzalez de Dios, O.,
              and D. Ceccarelli, "RSVP-TE Signaling Extensions in
              Support of Flexi-Grid Dense Wavelength Division
              Multiplexing (DWDM) Networks", RFC 7792,
              DOI 10.17487/RFC7792, March 2016,
              <https://www.rfc-editor.org/info/rfc7792>.

   [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/info/rfc8174>.

11.2.  Informative References

   [ITU-T.G.691]
              ITU-T, "Optical interfaces for single channel STM-64 and
              other SDH systems with optical amplifiers",
              ITU-T Recommendation ITU-T G.691, 2008.

   [ITU-T.G.693]
              ITU-T, "Optical interfaces for intra-office systems",
              ITU-T Recommendation ITU-T G.693, 2009.

   [ITU-T.G.8081]
              ITU-T, "Terms and definitions for Automatically Switched
              Optical Networks (ASON)", ITU-T Recommendation G.8081",
              ITU-T Recommendation ITU-T G.8081, September 2010.

   [ITU-T.G.957]
              ITU-T, "Optical interfaces for equipments and systems
              relating to the synchronous digital hierarchy",
              ITU-T Recommendation ITU-T G.957, 2006.

   [Network-Assigned-Upstream-Label]
              Internet Engineering Task Force, "Generalized Multi-
              Protocol Label Switching (GMPLS) Resource reSerVation
              Protocol with Traffic Engineering (RSVP- TE) mechanism
              that enables the network to assign an upstream label for a
              bidirectional LSP", draft-ietf-teas-network-assigned-
              upstream-label draft-ietf-teas-network-assigned-upstream-
              label, June 2017.

   [RFC5146]  Kumaki, K., Ed., "Interworking Requirements to Support
              Operation of MPLS-TE over GMPLS Networks", RFC 5146,
              DOI 10.17487/RFC5146, March 2008,
              <https://www.rfc-editor.org/info/rfc5146>.






Kunze, et al.           Expires December 13, 2018              [Page 28]


Internet-Draft  draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-11       June 2018


Appendix A.  Appendix

   In this section are reported some examples and references on the MIB,
   Yang and LMP usage.  The MIB and TLV defining the parameters
   described above are reported in the drafts below and are intended as
   informative data:

   draft-dharinigert-ccamp-dwdm-if-lmp
      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-ggalimbe-ccamp-flex-if-lmp
      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-dharini-ccamp-dwdm-if-param-yang
      A YANG model to manage the optical interface parameters for an
      external transponder in a WDM network

   draft-ietf-ccamp-flexigrid-yang
      YANG data model for Flexi-Grid Optical Networks

   draft-galimbe-ccamp-iv-yang
      A YANG model to manage the optical parameters for in a WDM network

   NOTE: the above information is defined at the time of publication of
   this document and thus subject to change.


Authors' Addresses

   Ruediger Kunze (editor)
   Deutsche Telekom
   Winterfeldtstr. 21-27
   10781 Berlin
   Germany

   Phone: +491702275321
   Email: RKunze@telekom.de








Kunze, et al.           Expires December 13, 2018              [Page 29]


Internet-Draft  draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-11       June 2018


   Gert Grammel (editor)
   Juniper
   Oskar-Schlemmer Str. 15
   80807 Muenchen
   Germany

   Phone: +49 1725186386
   Email: ggrammel@juniper.net


   Dieter Beller
   Nokia
   Lorenzstrasse, 10
   70435 Stuttgart
   Germany

   Phone: +4971182143125
   Email: Dieter.Beller@nokia.com


   Gabriele Galimberti (editor)
   Cisco
   Via S. Maria Molgora, 48c
   20871 - Vimercate
   Italy

   Phone: +390392091462
   Email: ggalimbe@cisco.com


   Julien Meuric
   Orange
   2, Avenue Pierre Marzin
   22307 Lannion Cedex
   France

   Phone: +33
   Email: julien.meuric@orange.com













Kunze, et al.           Expires December 13, 2018              [Page 30]


Html markup produced by rfcmarkup 1.126, available from https://tools.ietf.org/tools/rfcmarkup/