Skip to main content

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

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Ruediger Kunze , Gert Grammel , Dieter Beller , Gabriele Galimberti
Last updated 2017-03-13 (Latest revision 2016-10-31)
Replaces draft-kdkgall-ccamp-dwdm-if-mng-ctrl-fwk
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state I-D Exists
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-04
Internet Engineering Task Force                            R. Kunze, Ed.
Internet-Draft                                          Deutsche Telekom
Intended status: Informational                           G. Grammel, Ed.
Expires: September 14, 2017                                      Juniper
                                                               D. Beller
                                                                   Nokia
                                                      G. Galimberti, Ed.
                                                                   Cisco
                                                          March 13, 2017

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

Abstract

   To ensure an efficient data transport, meeting the requirements
   requested by today's IP-services the control and management of DWDM
   interfaces is a precondition for enhanced multilayer networking and
   for an further automation of network provisioning and operation.
   This document describes use cases and requirements for the control
   and management of optical interfaces 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 EMS, NMS or GMPLS.  This document covers management
   as well as control plane considerations in different management cases
   of single channel DWDM interfaces.  The purpose is to identify the
   necessary information elements and processes to be used by control or
   management systems for further processing.

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 http://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 September 14, 2017.

Kunze, et al.          Expires September 14, 2017               [Page 1]
Internet-Draft  draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-04      March 2017

Copyright Notice

   Copyright (c) 2017 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
   (http://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.  Direct connection to the DWDM management system . . .  11
     4.2.  Control Plane Considerations  . . . . . . . . . . . . . .  13
       4.2.1.  Considerations using GMPLS UNI  . . . . . . . . . . .  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 . . . . . .  18
       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
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  26
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  26
     11.2.  Informative References . . . . . . . . . . . . . . . . .  27
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  28

Kunze, et al.          Expires September 14, 2017               [Page 2]
Internet-Draft  draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-04      March 2017

1.  Introduction

   The usage of the single channel DWDM interfaces (e.g. in routers)
   connected to a DWDM Network (which include ROADMs and optical
   amplifiers) adds a further networking option for operators allowing
   new scenarios and requiring more control/management plane
   integration.

   Carriers deploy their networks today as a combination of transport
   and packet infrastructures to ensure high availability and flexible
   data transport.  Both network technologies are usually managed by
   different operational units using different management concepts.
   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), it is necessary to coordinate the
   management of the optical interface at the client domain with the
   optical transport domain.  There are different levels of
   coordination, which are specified in this framework.

   The objective of this document is to provide a framework that
   describes the solution space for the control and management of single
   channel interfaces and providing use cases on how to manage these
   solutions.  In particular, it examines topological elements and
   related network management measures.  From an architectural point of
   view, the network can be considered as a set of pre- configured/
   qualified unidirectional, single-fiber, network connections between
   reference points S and R shown in figure 2.  The optical transport
   network is managed and controlled in order to provide optical
   connections at the intended centre frequencies and the optical
   interfaces are managed and controlled to generate signals of the
   intended centre frequencies and further parameters as specified for
   example in ITU-T Recommendations G.698.2 and G.798.  The management
   or control plane of the client and DWDM network is aware of the
   parameters of the interfaces to properly set up the optical link.
   This knowledge can be used furthermore, to support fast fault
   detection.

   Optical routing and wavelength assignment based on WSON is out of
   scope although can benefit of the way the optical parameters are
   exchanged between the Client and the DWDM Network.

   Additionally, the wavelength ordering process and the process how to
   determine the demand for a new wavelength from A to Z is out of
   scope.

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

Kunze, et al.          Expires September 14, 2017               [Page 3]
Internet-Draft  draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-04      March 2017

   document covers management as well as control plane considerations in
   different management cases of single channel DWDM interfaces.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

2.  Terminology and Definitions

   The current generation of WDM netwoks are single vendor networks
   where the optical line system and the transponders are tightly
   integrated.  The DWDM interfaces migration from the transponders to
   the colored interfaces changes this scenario, by introducing a
   standardized interface at the level of OCh between the DWDM interface
   and the DWDM network.

   Black Link: The Black Link [ITU.G698.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 which may be from a different vendor.  Therefore the
   standard defines the ingress and egress parameters for the optical
   interfaces at the reference points Ss and Rs.

   Single Channel DWDM Interface: The single channel interfaces to DWDM
   systems defined in 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 [G.805]: For the purposes of this
   Recommendation an administrative domain represents the extent of
   resources which belong to a single player such as a network operator,
   a service provider or an end-user.  Administrative domains of
   different players do not overlap amongst themselves.

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

Kunze, et al.          Expires September 14, 2017               [Page 4]
Internet-Draft  draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-04      March 2017

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

   Management Plane [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[G.8081]: The control plane performs neighbour
   discovery, call control and connection control functions.  Through
   signalling, the control plane sets up and releases connections, and
   may restore a connection in case of a failure.  The control plane
   also performs other functions in support of call and connection
   control, such as neighbour discovery and routing information
   dissemination.

   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.G.872].

   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.G.872].

3.  Solution Space

   The solution space of this document is focusing on aspects related to
   the management 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, supplying one channel each

   3.  A combination of the above

Kunze, et al.          Expires September 14, 2017               [Page 5]
Internet-Draft  draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-04      March 2017

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], [ITU-T G.959.1], 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
   domain.  In the case of a client DWDM interface deployment this
   interface moves into the client device and extends the optical and

Kunze, et al.          Expires September 14, 2017               [Page 6]
Internet-Draft  draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-04      March 2017

   administrative domain towards the client node.  ITU-T G.698.2 for
   example specifies the parameter set for a certain set of
   applications.

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

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
   single channel DWDM interfaces, multi-vendor interconnection can also
   be achieved while removing the need for one short reach transmitter
   and receiver pair per channel (eliminating the transponders).

Kunze, et al.          Expires September 14, 2017               [Page 7]
Internet-Draft  draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-04      March 2017

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

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

           +-------------------------------------------------+
        Ss |  |           DWDM Network Elements           |  | Rs
   +---+ | |  | \                                       / |  | | +---+
   Tx L1---|->|   \    +------+            +------+   /   |--|-->Rx L1
   +---+   |  |    |   |      |  +------+  |      |  |    |  |   +---+
   +---+   |  |    |   |      |  |      |  |      |  |    |  |   +---+
   Tx L2---|->| OM |-|>|------|->| OADM |--|------|->| OD |--|-->Rx L2
   +---+   |  |    |   |      |  |      |  |      |  |    |  |   +---+
   +---+   |  |    |   |      |  +------+  |      |  |    |  |   +---+
   Tx L3---|->|   /    | DWDM |    |  ^    | DWDM |   \   |--|-->Rx L3
   +---+   |  | /      | Link +----|--|----+ 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
     OADM = Optical Add Drop Mux

   Linear DWDM network as per ITU-T G.698.2

                        Figure 2: Linear Black Link

   As shown in Figure 2, the administrative domain may consists of
   several vendor domains.  Even a in that case a common north bound
   management interface is required to ensure a consistent management of
   the entire connection.

Kunze, et al.          Expires September 14, 2017               [Page 8]
Internet-Draft  draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-04      March 2017

   The following documents[DWDM-interface-MIB], [YANG], [LMP] define
   such a protocol- FIX-THE-REFERENCE specific information using SNMP/
   SMI, Yang models and LMP TLV to support the direct exchange of
   information between the client and the network control plane.

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 an umbrella management system is used.
   Currently each WDM vendor provides an Element Management System (EMS)
   that also administers the wavelengths.

   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 single channel 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 to the management
       system,ensuring a management of the single channel of the optical
       network (e.g.  EMS, NMS)

       b.Indirect connection to the management system of the optical
       network using a protocol (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 September 14, 2017               [Page 9]
Internet-Draft  draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-04      March 2017

   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 Yang
       SNMP / or Yang      |                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

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

Kunze, et al.          Expires September 14, 2017              [Page 10]
Internet-Draft  draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-04      March 2017

   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 standardised way to enable interoperable solutions between
   different optical interface vendors and vendors of the optical
   network management application.  RFC 3591 [RFC3591] defines managed
   objects for the optical interface type but needs further extension to
   cover the optical parameters required by this framework document.
   Therefore an extension to this MIB for the optical interface has been
   drafted in [DWDM-interface-MIB].  SNMP is used to read parameters and
   get notifications and alarms, netconf and Yang models are needed to
   easily provision the interface with the right parameter set as
   described in [YANG]

   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.  Direct connection to the DWDM management system

Kunze, et al.          Expires September 14, 2017              [Page 11]
Internet-Draft  draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-04      March 2017

   An alternative as shown in Figure 4 can be used in cases where a more
   integrated relationship between transport node (e.g.  OM or OD) 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 Yang
                           |
           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.

   The LMP based on RFC 4209 does not yet support the transmission of
   configuration data (information).  This functionality must be added
   to the existing extensions of the protocol.  The use of LMP-WDM
   assumes that some form of a control channel exists between the client

Kunze, et al.          Expires September 14, 2017              [Page 12]
Internet-Draft  draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-04      March 2017

   node and the WDM equipment.  This may be a dedicated lambda, an
   Ethernet Link, or other signalling communication channel (SCC or
   IPCC).

4.2.  Control Plane Considerations

   The concept of integrated single channel DWDM interfaces equally
   applies to management and control plane mechanisms.  The general
   GMPLS control plane for wavelength switched optical networks is work
   under definition in the scope of WSON.  One important aspect of the
   BL is the fact that it includes the wavelength that is supported by
   the given link.  Thus a BL 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, 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 it is internal facilities there may be a
       period of time 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
   RFC4209 [LMP-WDM] and RFC 4204[LMP] which provides the necessary
   protocol framework to exchange those characteristics between client

Kunze, et al.          Expires September 14, 2017              [Page 13]
Internet-Draft  draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-04      March 2017

   and black link.  LMP-WDM is not intended for exchanging routing or
   signaling information but covers:

   1.  Control channel management

   2.  Link property correlation

   3.  Link verification

   4.  Fault management

   Extensions to LMP/LMP-WDM covering the code points of the BL
   definition are needed.  Additionally when client and server side are
   managed by different operational entities, link state exchange is
   required to align the management systems.

4.2.1.  Considerations using GMPLS UNI

   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 an overlay model where the edge node requests resources from
   the core node and the edges node do not participate in the routing
   protocol instance that runs among the core nodes.  RFC 4208 [RFC4208]
   defines the GMPLS UNI that will 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.  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 to configure the optical interface within
       the edge node or

   b.  RSVP-TE will be used to transport additional information

   c.  Leaking IGP information instead of exchanging this information
       needed from the optical network to the edge node (overlay will be
       transformed to a border-peer model)

   Furthermore following issues should be addressed:

Kunze, et al.          Expires September 14, 2017              [Page 14]
Internet-Draft  draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-04      March 2017

   a) The Communication between peering edge nodes using an out of band
   control channel.  The two nodes have to exchange their optical
   capabilities.  An extended version of LMP is needed to exchange FEC
   Modulation scheme, etc.  that must be the same.  It would be helpful
   to define some common profiles that will be supported.  Only if the
   profiles match with both interface capabilities it is possible start
   signalling.

   b) Due to the bidirectional wavelength path that must be setup it is
   obligatory that the upstream edge node inserts a wavelength value
   into the path message for the wavelength path towards the upstream
   node itself.  But in the case of an overlay model the client device
   may not have full information which wavelength must/should be
   selectedand this information must be exchanged between the edge and
   the core node.

5.  Use cases

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

5.1.  Service Setup

   It is necessary to differentiate between two 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 the preparation of the connection if no optical signal
   is applied.  Therefore it is necessary to define the path of the
   connection.

   The second step is to setup the connection between the client DWDM
   interface and the ROADM port.  This is done using the NMS of the
   optical transport network.  From the operation point of view the task
   is similar in a Black Link scenario and in a traditional WDM
   environment.  The Black Link connection is measured by using BER
   tester which use optical interfaces according to G.698.2.  These
   measurements are carried out in accordance with [ITU-TG.692].  When
   needed further connections for resilience are brought into service in
   the same way.

   In addition some other parameters like the transmit optical power,
   the received optical power, the frequency, etc. must be considered.

   If the optical interface moves into a client device some of changes
   from the operational point of view have to be considered.  The centre
   frequency of the Optical Channel was determined by the setup process.

Kunze, et al.          Expires September 14, 2017              [Page 15]
Internet-Draft  draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-04      March 2017

   The optical interfaces at both terminals are set to the centre
   frequency before interconnected with the dedicated ports of the WDM
   network.  Optical monitoring is activated in the WDM network after
   the terminals are interconnected with the dedicated ports 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 last step.  After
   connecting the client device towards the first control plane managed
   transport node a control connection may e.g. be automatically
   established using LMP to exchange configuration information.

   If tunable interfaces are used in the scenario it would be possible
   to define a series of backup wavelength routes for restoration that
   could be tested and stored in backup profile.  In fault cases this
   wavelength routes can be used to recover the service.

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 (OXC1) has a value of 0dBm and the ROADM interface measured
   power (at OLS1) is -6dBm the fiber patch cord connecting the two
   nodes may be pinched or the connectors are dirty.  More, the
   interface characteristics can be used by the OLS network Control
   Plane in order to check the Optical Channels feasibility.  Finally
   the OXC1 transceivers parameters (Application Code) can be shared
   with OXC2 using the LMP protocol to verify the transceivers
   compatibility.  The actual route selection of a specific wavelength
   within the allowed set is outside the scope of LMP.  In GMPLS, the
   parameter selection (e.g. central frequency) is performed by RSVP-TE.

   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 considered to be
   external to the DWDM network.  This so-called 'black link' approach
   illustrated in Figure 5-1 of G.698.2 and a copy of this figure is
   provided below.  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 in this contribution.  Based on the definition in G.698.2
   it is considered to be part of the DWDM network.  The access link
   typically is realized as a passive fiber link that has a specific

Kunze, et al.          Expires September 14, 2017              [Page 16]
Internet-Draft  draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-04      March 2017

   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 as long as the optical transmitter can still be
   operated within its output power range defined by its application
   code.

Kunze, et al.          Expires September 14, 2017              [Page 17]
Internet-Draft  draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-04      March 2017

   Figure 5 Access Link Power 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)

                       Figure 5: Extended LMP Model

5.2.1.  Pure Access Link (AL) Monitoring Use Case

Kunze, et al.          Expires September 14, 2017              [Page 18]
Internet-Draft  draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-04      March 2017

     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 the same.
   - A threshold value t has been configured by the operator. This
     should also be done during commissioning.
   - A control plane protocol (e.g. this draft) 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 Pin and Pout as defined in G.697 by power monitoring points
     depicted as yellow triangles in the figures below.

   Access Link monitoring process:
   - Tx direction: the measured optical input power Pin 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 September 14, 2017              [Page 19]
Internet-Draft  draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-04      March 2017

   Figure 6 Use case 1: Access Link monitoring

     +----------+                    +--------------------------+
     | +------+ |    P(Tx), P(Rx)    |  +-------+               |
     | |      | | =================> |  |       |               |
     | | LMP  | |    P(in), P(out)   |  |  LMP  |               |
     | |      | | <================= |  |       |               |
     | +------+ |                    |  +-------+               |
     |          |                    |                          |
     |          |                    |    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)

                       Figure 6: Extended LMP Model

Kunze, et al.          Expires September 14, 2017              [Page 20]
Internet-Draft  draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-04      March 2017

5.2.2.  Power Control Loop Use Case

      This use case is based on the access link monitoring use case 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 5 below illustrates this use case utilizing the LMP
      protocol with extensions defined in this draft.

Kunze, et al.          Expires September 14, 2017              [Page 21]
Internet-Draft  draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-04      March 2017

   Figure 7 Use case 2: Power Control Loop

     +----------+                       +--------------------------+
     | +------+ | P(Tx),P(Rx),Set(Pout) |  +-------+   +--------+  |
     | |      | | ====================> |  |       |   | 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 Loops in Transponder and ROADM controls
         the Variable Optical Attenuators (VOA) to adjust the proper
         power in base of the ROADM and Receiver caracteristics and
         the Access Link attenuation

Kunze, et al.          Expires September 14, 2017              [Page 22]
Internet-Draft  draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-04      March 2017

6.  Requirements

   Even if network architectures becomes more complex the 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 has been
   addressed in this section.

   Data Plane interoperability as defined for example in [ITU.G698.2] is
   a precondition to ensure plain solutions and allow the usage of
   standardized interfaces between network and control/management plane.

   The following requirements are focusing on the usage of integrated
   single channel interfaces.

Kunze, et al.          Expires September 14, 2017              [Page 23]
Internet-Draft  draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-04      March 2017

    1  To ensure a lean management and provisioning process of single
       channel interfaces management and control plane of the client
       and DWDM network must be aware of the parameters of the
       interfaces and the optical network to properly setup the optical
       connection.

    2  A standard-based northbound API (to network management system)
       based on Netconf should be supported, alternatively SNMP should
       be supported too.

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

    4  Netconf should be used also for configuration of the single
       channel interfaces including the power setting

    5  LMP should be extended and used in cases where optical
       parameters need to be exchanged between peer nodes to correlate
       link characteristics and adopt the working mode of the single
       channel interface.

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

    7  Parameters e.g. PRE-FEC BER should be used to trigger a FRR
       mechanism on the IP control plane to reroute traffic before
       the link breaks.

    8  Power monitoring functions at both ends of the DWDM connection
       should be implemented to further automate the setup and
       shoutdown process of the optical interfaces.

    9  A standardized procedure to setup an optical connection should
       be defined and implemented in DWDM and client devices
       (containing the single channel optical interface).LMP should be
       used to ensure that the process follows the right order.

   10  Pre-tested and configured backup paths should be stored in so
       called backup profiles. In fault cases this wavelength routes
       should be used to recover the service.

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

Kunze, et al.          Expires September 14, 2017              [Page 24]
Internet-Draft  draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-04      March 2017

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 netork 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 September 14, 2017              [Page 25]
Internet-Draft  draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-04      March 2017

               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

11.  References

11.1.  Normative References

   [RFC2863]  McCloghrie, K. and F. Kastenholz, "The Interfaces Group
              MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000,
              <http://www.rfc-editor.org/info/rfc2863>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC2578]  McCloghrie, K., Ed., Perkins, D., Ed., and J.
              Schoenwaelder, Ed., "Structure of Management Information
              Version 2 (SMIv2)", STD 58, RFC 2578,
              DOI 10.17487/RFC2578, April 1999,
              <http://www.rfc-editor.org/info/rfc2578>.

   [RFC2579]  McCloghrie, K., Ed., Perkins, D., Ed., and J.
              Schoenwaelder, Ed., "Textual Conventions for SMIv2",
              STD 58, RFC 2579, DOI 10.17487/RFC2579, April 1999,
              <http://www.rfc-editor.org/info/rfc2579>.

Kunze, et al.          Expires September 14, 2017              [Page 26]
Internet-Draft  draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-04      March 2017

   [RFC2580]  McCloghrie, K., Ed., Perkins, D., Ed., and J.
              Schoenwaelder, Ed., "Conformance Statements for SMIv2",
              STD 58, RFC 2580, DOI 10.17487/RFC2580, April 1999,
              <http://www.rfc-editor.org/info/rfc2580>.

   [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,
              <http://www.rfc-editor.org/info/rfc3591>.

   [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,
              <http://www.rfc-editor.org/info/rfc6205>.

   [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,
              <http://www.rfc-editor.org/info/rfc4209>.

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

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

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

11.2.  Informative References

   [DWDM-interface-MIB]
              Internet Engineering Task Force, "A SNMP MIB to manage the
              DWDM optical interface parameters of DWDM applications",
              draft-galimkunze-ccamp-dwdm-if-snmp-mib draft-galimkunze-
              ccamp-dwdm-if-snmp-mib, July 2011.

Kunze, et al.          Expires September 14, 2017              [Page 27]
Internet-Draft  draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-04      March 2017

   [ITU-TG.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-TG.693]
              ITU-T, "Optical interfaces for intra-office systems",
              ITU-T Recommendation ITU-T G.693, 2009.

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

   [ITU-TG.692]
              ITU-T, "Transmission media characteristics -
              Characteristics of optical components and sub-systems",
              ITU-T Recommendation ITU-T G.692, 1998.

   [ITU-TG.959.1]
              ITU-T, "Optical transport network physical layer
              interfaces", ITU-T Recommendation ITU-T G.959.1, 2009.

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

Authors' Addresses

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

   Phone: +491702275321
   Email: RKunze@telekom.de

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

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

Kunze, et al.          Expires September 14, 2017              [Page 28]
Internet-Draft  draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-04      March 2017

   Dieter Beller
   Nokia
   Lorenzstrasse, 10
   70435 Stuttgart
   Germany

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

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

   Phone: +390392091462
   Email: ggalimbe@cisco.com

Kunze, et al.          Expires September 14, 2017              [Page 29]