Internet Engineering Task Force                             R.Kunze, Ed.
Internet-Draft                                       Deutsche Telekom AG
Intended status: Informational                            G.Grammel, Ed.
Expires: September 10, 2012                             Juniper Networks
                                                  GMG. G.Galimberti, Ed.
                                                        H.Schmidtke, Ed.
                                                        Juniper Networks
                                                           March 9, 2012

  A framework for Management and Control of G.698.2 optical interface


   This document provides a framework that describes a solution space
   for the control and management of optical interfaces parameters
   according to the Black Link approach as specified by ITU-T [ITU
   G.698.2].  In particular, it examines topological elements and
   related network management processes to operate this construct.  This
   framework is scoped to address the Optical Channel (OCh)-layer
   covered by G.698.2.  The focus is on enabling the wavelength
   provisioning process in a black link approach 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 a single channel DWDM interface as defined by
   ITU-G.698.2.  The purpose is to identify the necessary information
   elements and processes to be used by control or management devices
   for further processing.  Hence wavelength routing and selection
   processes as defined e.g. in WSON are beyond the scope of this

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

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

R.Kunze, et al.        Expires September 10, 2012               [Page 1]

Internet-Draft   draft-kunze-g698-mgnt-ctrl-framework-02      March 2012

   This Internet-Draft will expire on September 10, 2012.

Copyright Notice

   Copyright (c) 2012 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
   ( 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 . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  4
   2.  Terminology and Definitions  . . . . . . . . . . . . . . . . .  5
   3.  Solution Space for optical interfaces using a DWDM Black
       Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Comparison of approaches for transverse compatibility  . .  7
       3.1.1.  Multivendor DWDM line system with transponders . . . .  7
       3.1.2.  Black Link Deployments . . . . . . . . . . . . . . . .  9
   4.  Operational aspects using IUT-T G.698.2 specified single
       channel DWDM interfaces  . . . . . . . . . . . . . . . . . . . 10
     4.1.  Bringing into service  . . . . . . . . . . . . . . . . . . 10
     4.2.  Configuration Management . . . . . . . . . . . . . . . . . 11
     4.3.  In service (performance management)  . . . . . . . . . . . 11
     4.4.  Fault Clearance  . . . . . . . . . . . . . . . . . . . . . 11
   5.  Solutions for managing and controlling the optical
       interface within Black Link scenarios  . . . . . . . . . . . . 11
     5.1.  BL Separate Operation and Management Approaches  . . . . . 12
       5.1.1.  Direct connection to the management system . . . . . . 13
       5.1.2.  Indirect connection to the DWDM management system  . . 15
     5.2.  Control Plane Considerations . . . . . . . . . . . . . . . 16
       5.2.1.  Considerations using GMPLS UNI . . . . . . . . . . . . 17
   6.  Requirements for BL deployments  . . . . . . . . . . . . . . . 18
     6.1.  Interoperability Aspects . . . . . . . . . . . . . . . . . 18
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20
   10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 21

R.Kunze, et al.        Expires September 10, 2012               [Page 2]

Internet-Draft   draft-kunze-g698-mgnt-ctrl-framework-02      March 2012

     11.2. Informative References . . . . . . . . . . . . . . . . . . 22

R.Kunze, et al.        Expires September 10, 2012               [Page 3]

Internet-Draft   draft-kunze-g698-mgnt-ctrl-framework-02      March 2012

1.  Introduction

   The usage of the Black Link approach in carrier applications (which
   include optical amplifiers) adds further networking option for
   operators enabling integration of G.698.2 optical interfaces into
   routers and other types of client devices.

   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 a black link deployment, 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 as specified by the ITU-T Recommendation G.698.2
   [ITU G.698.2].  In particular, it examines topological elements and
   related network management measures.  From an architectural point of
   view, the black link is a set of pre-configured/qualified
   unidirectional, single-fiber, network connections between the G.698.2
   reference points S and R. The optical transport network is managed
   and controlled in order to provide black links of 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 in ITU-T Recommendations G.698.2 and G.798.

   Optical Routing and Wavelength assignment based on WSON is out of

   Furthermore, support for Fast Fault Detection, to e.g., trigger ODUk
   Protection Switching is out of scope of this work.  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
   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",

R.Kunze, et al.        Expires September 10, 2012               [Page 4]

Internet-Draft   draft-kunze-g698-mgnt-ctrl-framework-02      March 2012

   document are to be interpreted as described in RFC 2119 [RFC2119].

2.  Terminology and Definitions

   Current generation WDM netwoks are single vendor networks where the
   optical line system and the transponders are tightly integrated.  The
   Black Link approach changes this situation by introducing a
   standardized interface at the level of OCh between the line system
   and transponders.

   Black Link: The Black Link [ITU 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 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.  In that case the
   optical connection between the two G.968.2 optical interfaces is
   referred to as a Black Link.  G.698.2 provides an optical interface
   specification ensuring the realization of transversely compatible
   dense wavelength division multiplexing (DWDM) systems primarily
   intended for metro applications which include optical amplifiers and
   leads towards a multivendor DWDM optical transmission network.

   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.  Single channel DWDM interfaces to/from other
   vendor(s): G.698.2 provides transverse compatibility at the single-
   channel point, using a direct wavelength-multiplexing configuration,
   for single channel DWDM interfaces to/from other vendors (but not at
   the multi-channel point).

   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

R.Kunze, et al.        Expires September 10, 2012               [Page 5]

Internet-Draft   draft-kunze-g698-mgnt-ctrl-framework-02      March 2012

   administrative domain.

   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

   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

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

3.   Solution Space for optical interfaces using a DWDM Black Link

   The management of optical interfaces using the Black Link approach
   deals with 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.

   The Black Link approach allows the direct connection of a wide
   variety of equipments using a DWDM link, for example:

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

   b.  Multiple optical client devices, each from a different vendor,
       supplying one channel each

   c.  A combination of the above

   Table 1 provides a list of BL management tasks regarding the
   configuration of optical parameters.

R.Kunze, et al.        Expires September 10, 2012               [Page 6]

Internet-Draft   draft-kunze-g698-mgnt-ctrl-framework-02      March 2012

   |                  Task                 |  Domain |  a |  b | c | d |
   |   determination of centre frequency   | optical |  R |  R | R | R |
   |  configuration of centre frequency at |  client | NR | NR | R | R |
   |               optical IF              |         |    |    |   |   |
   |     path computation of wavelength    | optical | NR | NR | R | R |
   |         routing of wavelength         | optical | NR | NR | R | R |
   |    wavelength setup across optical    | optical |  ? |  ? | R | R |
   |                network                |         |    |    |   |   |
   |     detection of wavelength fault     |  client |  R |  R | R | R |
   |   fault isolation, identification of  | optical | NR |  R | R | R |
   |              root failure             |         |    |    |   |   |
   | repair actions within optical network | optical |  R |  R | R | R |
   |   protection switching of wavelength  | optical | NR | NR | R | R |
   |       restoration of wavelength       | optical | NR | NR | R | R |

                   Note: R = relevant, NR = not relevant

              Table 1: List of tasks related to BL management

   Furthermore the following deployment cases will be considered:

   a.  Passive WDM

   b.  P2P WDM systems

   c.  WDM systems with OADMs

   d.  Transparent optical networks supporting specific IPoWDM
       functions, interfaces, protocols etc.

   Case a) is added for illustration only, since passive WDM is
   specified in ITU-T Recommendations G.695 and G.698.1.

   Case b) and case c)are motivated by the usage of legacy equipment
   using the traditional connection as described in Figure 1combined
   with the BL approach.

3.1.  Comparison of approaches for transverse compatibility

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
   labelled "single channel non-DWDM interfaces from other vendor(s)"

R.Kunze, et al.        Expires September 10, 2012               [Page 7]

Internet-Draft   draft-kunze-g698-mgnt-ctrl-framework-02      March 2012

   and "Single channel non DWDM interfaces to/from other vendor(s)" 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 black link deployment this interface moves
   into the client devices and extends the optical and administrative
   domain towards the client node.  ITU-T G.698.2 specifies the
   parameter set for a certain set of applications.

   This document elaborates only the IaDI Interface as specified in
   ITU-T G.698.2 as transversely compatible and multi-vendor interface
   within one administrative domain controlled by the network operator.
   This administrative domain can contain several vendor domains (vendor
   A for the DWDM sub-network, and vendors B1 and B2 at the transmitter
   and receiver terminal side).

R.Kunze, et al.        Expires September 10, 2012               [Page 8]

Internet-Draft   draft-kunze-g698-mgnt-ctrl-framework-02      March 2012

3.1.2.  Black Link Deployments

   In case of a Black Link deployment as shown in Figure 2, through the
   use of the single channel DWDM interfaces defined in [ITU G.698.2],
   multi-vendor interconnection can also be achieved while removing the
   need for one short reach transmitter and receiver pair per channel
   (eliminating the transponders).

   Figure 2 shows a set of reference points, for the linear "black-link"
   approach, 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 black link as per ITU-T G.698.2

                        Figure 2: Linear Black Link

R.Kunze, et al.        Expires September 10, 2012               [Page 9]

Internet-Draft   draft-kunze-g698-mgnt-ctrl-framework-02      March 2012

   In Figure 2, if the administrative domain consists of several domains
   (e.g.  A for a DWDM network supporting the Black Link, B1 for the
   DWDM Tx, and B2 for the DWDM Rx), it is typical that there will be a
   separate Element Management Systems (EMS) will be used for each
   vendor domain (e.g.  EMS-a for domain A, EMS-b1 for domain B1, and
   EMS-b2 for domain B2).  Each EMS may have a common standard north
   bound management interface to a Network Management System (NMS),
   allowing consistent end-to-end management of the connection.

   To facilitate consistent end-to-end network management, the north
   bound management interface from the EMS to the NMS should be
   consistent (frome a management information point of view) with the
   standard protocol-neutral (or protocol-specific) information model
   used in the EMS south bound management interface to its subtending
   NEs (TX and/or RX).  The [Black-Link-MIB] defines such a protocol-
   specific information using SNMP/SMI.

4.  Operational aspects using IUT-T G.698.2 specified single channel
    DWDM interfaces

   A Comparison of the Black Link with the traditional operation
   scenarios provides an insight of similarities and distinctions in
   operation and management.  The following four use cases provide an
   overview about operation and maintenance processes.

4.1.  Bringing into service

   It is necessary to differentiate between two operational issues for
   setting up a light path (a Black Link 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 Black Link connection.  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-T
   Recommendation M.xxxx.  When needed further Black Link connections
   for resilience are brought into service in the same way.

   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 Black Link connections was determined by the setup
   process.  The optical interfaces at both terminals are set to the
   centre frequency of the Black Link connection before interconnected

R.Kunze, et al.        Expires September 10, 2012              [Page 10]

Internet-Draft   draft-kunze-g698-mgnt-ctrl-framework-02      March 2012

   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 Black
   Link connection.  The monitor functions of the optical interfaces at
   the terminals are also activated in order to monitor the end to end

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

4.2.  Configuration Management


4.3.  In service (performance management)


4.4.  Fault Clearance


5.  Solutions for managing and controlling the optical interface within
    Black Link scenarios

   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 in a pure Black Link or
   in a mixed setup with transponders there are the following approaches
   will be considered to manage and operate optical interfaces.

   1.  Separate operation and management of client device and the
       transport network

       a.  Direct link between the client device and the management
       system of the optical network (e.g.  EMS, NMS)

R.Kunze, et al.        Expires September 10, 2012              [Page 11]

Internet-Draft   draft-kunze-g698-mgnt-ctrl-framework-02      March 2012

       b.  Indirect link to the management system of the optical network
       using a protocol 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 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 to higher layers (e.g.
   IP), this may lead to more efficient network operation and a higher
   level of integration.

5.1.  BL Separate Operation and Management Approaches

R.Kunze, et al.        Expires September 10, 2012              [Page 12]

Internet-Draft   draft-kunze-g698-mgnt-ctrl-framework-02      March 2012

5.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 /              |                DCN Network
          /         +------+-----------------------+
         /          |     +|     WDM Domain   +    |
        /           |     |\                 /|    |
   +---+--+         |     | \     |\        / |    |          +------+
   |  CL  |-/C------+--- -|OM|----|/-------|OD|--- +-------/C-|  CL  |
   |      |-/C------+--- -|  |----- /|-----|  |----+-------/C-|      |
   +------+         |     | /       \|      \ |    |          +------+
                    |     |/                 \|    |
                    |     +                   +    |

           CL = Client Device
           /C = G.698.2 Optical Interface
           OM = Optical Mux
           OD = Optical Demux
           EMS = Element Management System
           MI= Management Interface

     Figure 3: Connecting G.698.2 optical interfaces to the Transport
                             Management system

   The exchange of management information between client device and the
   management system assumes that some form of a direct management

R.Kunze, et al.        Expires September 10, 2012              [Page 13]

Internet-Draft   draft-kunze-g698-mgnt-ctrl-framework-02      March 2012

   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.  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 [Black-Link-MIB].  In that case SNMP is used to exchange
   data between the client device and the management system of the WDM

   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.

R.Kunze, et al.        Expires September 10, 2012              [Page 14]

Internet-Draft   draft-kunze-g698-mgnt-ctrl-framework-02      March 2012

5.1.2.  Indirect connection to the DWDM management system

   The 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
           LMP      +------+-----------------------+
       +------------+---+ +|                  +    |
       |            |   | |\                 /|    |
   +---+--+         |   +-+ \     |\        / |    |          +------+
   |  CL  |-/C------+--- -|OM|----|/-------|OD|--- +-------/C-|  CL  |
   |      |-/C------+--- -|  |----- /|-----|  |----+-------/C-|      |
   +------+         |     | /       \|      \ |    |          +------+
                    |     |/                 \|    |
                    |     +                   +    |

           CL = Client Device
           /C = G.698.2 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] can (should) be used.  This extension of LMP may

R.Kunze, et al.        Expires September 10, 2012              [Page 15]

Internet-Draft   draft-kunze-g698-mgnt-ctrl-framework-02      March 2012

   be used between a peer node and an adjacent optical network node as
   depicted in Figure 4.

   Recently LMP based on RFC 4209 does not yet support the transmission
   of configuration data (information).  This functionality has to 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
   node and the WDM equipment.  This may be a dedicated lambda, an
   Ethernet Link, or other signaling communication channel (SCC).

5.2.  Control Plane Considerations

   The concept of black link 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 BL implementation.
   Since the implementation of the BL itself is unknown a priori,
   different sequences to light up wavelength need to be considered:

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

   2.  Transponder 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 doesn 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, Transponder 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 transponders need to be switched
       on and further power tuning takes place.  The sequencing of

R.Kunze, et al.        Expires September 10, 2012              [Page 16]

Internet-Draft   draft-kunze-g698-mgnt-ctrl-framework-02      March 2012

       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
   and black link.  LMP-WDM is not intended for exchanging routing or
   signalling information but covers:

      Control channel manangement

      Link property correlation

      Link verification

      Fault Manangement

   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.

5.2.1.  Considerations using GMPLS UNI

   The deployment of G.698.2 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 a black link 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

R.Kunze, et al.        Expires September 10, 2012              [Page 17]

Internet-Draft   draft-kunze-g698-mgnt-ctrl-framework-02      March 2012

   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:

   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

   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 fullinformation which wavelength must/should be
   selectedand this information must be exchanged between the edge and
   the core node.

   ...additional points

6.  Requirements for BL deployments

   This section raises requirements from the carrier perspective and
   will be removed in a separate requirements draft if necessary.

6.1.  Interoperability Aspects

   For carrier network deployments, interoperability is a key
   requirement.  Today it is state-of-the-art to interconnect e.g.
   client devices from different vendors via a WDM transport system
   using short-reach, grey interfaces.  Applying the Black Link (BL)
   concept, client devices (e.g. routers) are now directly connected via
   transport interfaces which must be interoperable to each other.

R.Kunze, et al.        Expires September 10, 2012              [Page 18]

Internet-Draft   draft-kunze-g698-mgnt-ctrl-framework-02      March 2012

   A progressive approach addressing interoperability is shown in
   Figure 5.According to the concept of ITU-T G.698.2 the black link,
   the single channel (coloured) Tx and the Rx can be provided different
   vendors.  The single-channel reference points Ss and Rs indicate the
   demarcation between the Tx/Rx and the black link, and the set of
   optical parameters refers to these reference points according to
   G.698.2.  However, G.698.2 does not give any insight into the client
   equipment (CL), e.g. routers or switches, containing the optical
   transmitters and receivers.This is a valid topic which is subject of
   other standards and multi-source agreement (MSAs) describing
   electrical interfaces, mechanical properties and environmental
   conditions.  Such topics are out of the scope of this document.

                     <========= Black Link =========>
                      |   Black Link              |
   +-----------+      |   +                   +   |      +-----------+
   |CL #1      |     -+---|\                 /|---+-     | CL #2     |
   |    +------+-+    |   | \   +-------+   / |   |    +-+------+    |
   | -+-|  Tx    |    |   |  |  |       |  |  |   |    |   Rx   |-+- |
   | -+-|        +--+-+---|OM|--  OADM  |--|OD|---+-+--+        |-+- |
   | -+-|        | Ss |   |  |  |       |  |  |   | RS |        |-+- |
   |    +------+-+    |   | /   +-------+   \ |   |    +-+------+    |
   |           |     -+---|/                 \|---+-     |           |
   |           |      |   +                   +   |      |           |
   +-----------+      |                           |      +-----------+

           CL = Client Device
           OM = Optical Mux
           OD = Optical Demux

                    Figure 5: Interoperability aspects

7.  Acknowledgements

   The author would like to thank Ulrich Drafz for the very good
   teamwork during the last years and the initial thoughts related to
   the packet optical integration.  Furthermore the author would like to
   thank all people involved within Deutsche Telekom for the support and
   fruitful discussions.

R.Kunze, et al.        Expires September 10, 2012              [Page 19]

Internet-Draft   draft-kunze-g698-mgnt-ctrl-framework-02      March 2012

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

R.Kunze, et al.        Expires September 10, 2012              [Page 20]

Internet-Draft   draft-kunze-g698-mgnt-ctrl-framework-02      March 2012

               Arnold Mattheus
                 Deutsche Telekom

               Manuel Paul
                 Deutsche Telekom

               Josef Roese
                 Deutsche Telekom

                             Frank Luennemann
                 Deutsche Telekom

11.  References

11.1.  Normative References

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

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

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

   [RFC2119]         Bradner, S., "Key words for use in RFCs to Indicate
                     Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3591]         Lam, H-K., Stewart, M., and A. Huynh, "Definitions
                     of Managed Objects for the Optical Interface Type",

R.Kunze, et al.        Expires September 10, 2012              [Page 21]

Internet-Draft   draft-kunze-g698-mgnt-ctrl-framework-02      March 2012

                     RFC 3591, September 2003.

   [RFC4204]         Lang, J., "Link Management Protocol (LMP)",
                     RFC 4204, October 2005.

   [RFC4209]         Fredette, A. and J. Lang, "Link Management Protocol
                     (LMP) for Dense Wavelength Division Multiplexing
                     (DWDM) Optical Line Systems", RFC 4209,
                     October 2005.

11.2.  Informative References

   [Black-Link-MIB]  Internet Engineering Task Force, "A SNMP MIB to
                     manage black-link optical interface parameters of
                     DWDM applications", draft-galimbe-kunze-g-698-2-
                     snmp-mib draft-galimbe-kunze-g-698-2-snmp-mib,
                     July 2011.

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

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

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

R.Kunze, et al.        Expires September 10, 2012              [Page 22]

Internet-Draft   draft-kunze-g698-mgnt-ctrl-framework-02      March 2012

Authors' Addresses

   Ruediger Kunze (editor)
   Deutsche Telekom AG
   Berlin,   10589

   Phone: +49 30 3497 3152

   Gert Grammel (editor)
   Juniper Networks
   dddd,   1234

   Phone: +1 45552

   Gabriele Galimberti (editor)
   Via Philips,12
   20052 - Monza

   Phone: +390392091462

   Hans-Juergen Schmidtke (editor)
   Juniper Networks
   dddd,   1234

   Phone: +1 45552

R.Kunze, et al.        Expires September 10, 2012              [Page 23]