Internet Engineering Task Force R. Kunze, Ed. Internet-Draft Deutsche Telekom Intended status: Informational G. Grammel, Ed. Expires: January 9, 2017 Juniper D. Beller, Ed. Nokia G. Galimberti, Ed. Cisco July 8, 2016 A framework for Management and Control of DWDM optical interface parameters draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-02 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 a single channel DWDM interface. 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 January 9, 2017. Kunze, et al. Expires January 9, 2017 [Page 1] Internet-Draft draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-02 July 2016 Copyright Notice Copyright (c) 2016 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 Client DWDM interface . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . 8 4. Solutions for managing and controlling the 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 . . . 12 4.2. Control Plane Considerations . . . . . . . . . . . . . . 14 4.2.1. Considerations using GMPLS UNI . . . . . . . . . . . 15 5. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.1. Service Setup . . . . . . . . . . . . . . . . . . . . . . 16 5.2. Link monitoring Use Cases . . . . . . . . . . . . . . . . 17 5.2.1. Pure Access Link (AL) Monitoring Use Case . . . . . . 19 5.2.2. Power Control Loop Use Case . . . . . . . . . . . . . 22 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 24 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 11.1. Normative References . . . . . . . . . . . . . . . . . . 26 11.2. Informative References . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 Kunze, et al. Expires January 9, 2017 [Page 2] Internet-Draft draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-02 July 2016 1. Introduction The usage of the single channel DWDM interfaces in client nodes (e.g. routers) connected to a DWDM Network (which include ROADMs and optical amplifiers) adds a further networking option for operators opening to 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 give use cases on how to manage the 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 be 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 document covers management as well as control plane considerations in different management cases of single channel DWDM interfaces. Kunze, et al. Expires January 9, 2017 [Page 3] Internet-Draft draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-02 July 2016 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 Current generation 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 Client interfaces changes this scenario, by introducing a standardized interface at the level of OCh between the Client 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. Inter-domain interface (IrDI) [G.872]: A physical interface that represents the boundary between two administrative domains. Kunze, et al. Expires January 9, 2017 [Page 4] Internet-Draft draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-02 July 2016 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 Client DWDM interface 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 solution allows the direct connection of a wide variety of equipments 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. Multiple optical client devices, each from a different vendor, supplying one channel each 3. A combination of the above Table 1 provides a list of management tasks regarding the configuration of optical parameters. Kunze, et al. Expires January 9, 2017 [Page 5] Internet-Draft draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-02 July 2016 +---------------------------------------+---------+----+----+---+---+ | 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 Client - Network interconnection 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 functions, nterfaces, 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 1 DWDM interface integration on the client side. 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 can Kunze, et al. Expires January 9, 2017 [Page 6] Internet-Draft draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-02 July 2016 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 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. Kunze, et al. Expires January 9, 2017 [Page 7] Internet-Draft draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-02 July 2016 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). 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 Kunze, et al. Expires January 9, 2017 [Page 8] Internet-Draft draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-02 July 2016 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. 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 the 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 Kunze, et al. Expires January 9, 2017 [Page 9] Internet-Draft draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-02 July 2016 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. 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 Kunze, et al. Expires January 9, 2017 [Page 10] Internet-Draft draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-02 July 2016 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 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 Kunze, et al. Expires January 9, 2017 [Page 11] Internet-Draft draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-02 July 2016 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 January 9, 2017 [Page 12] Internet-Draft draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-02 July 2016 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 January 9, 2017 [Page 13] Internet-Draft draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-02 July 2016 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 January 9, 2017 [Page 14] Internet-Draft draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-02 July 2016 and black link. LMP-WDM is not intended for exchanging routing or signalling 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 January 9, 2017 [Page 15] Internet-Draft draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-02 July 2016 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 January 9, 2017 [Page 16] Internet-Draft draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-02 July 2016 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 January 9, 2017 [Page 17] Internet-Draft draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-02 July 2016 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 January 9, 2017 [Page 18] Internet-Draft draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-02 July 2016 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 January 9, 2017 [Page 19] Internet-Draft draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-02 July 2016 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 llustrated 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 January 9, 2017 [Page 20] Internet-Draft draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-02 July 2016 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 January 9, 2017 [Page 21] Internet-Draft draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-02 July 2016 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 January 9, 2017 [Page 22] Internet-Draft draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-02 July 2016 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 January 9, 2017 [Page 23] Internet-Draft draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-02 July 2016 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 standardised integrated single channel interfaces but also valid in other environments. 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 standardized northbound API (to network management system)must be supported based on SNMP and Netconf. 3 A standardized 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 setting of the power. 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 Legacy operational models should be supported (parameters must be exchanged with the DWDM transport EMS to manage the configuration and the transmission of alarms and other FCAPS messages. 7 LMP should be used to adjust the output power of the single channel DWDM interface to ensure that the interface works in the right range defined by the application code. 8 Parameters e.g. PRE-FEC BER could be used to trigger a FRR Kunze, et al. Expires January 9, 2017 [Page 24] Internet-Draft draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-02 July 2016 mechanism on the IP control plane to reroute traffic before the link breaks. 9 LMP should be used to automate the end to end connection setup of the optical connection. 10 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. 11 A standardized procedure to setup an optical connection must 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. 12 Pre-tested and configured backup paths should be stored in so called backup profiles. In fault cases this wavelength routes can be used to recover the service. 13 LMP should be used to monitor and observe the access link. 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. Kunze, et al. Expires January 9, 2017 [Page 25] Internet-Draft draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-02 July 2016 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 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, . Kunze, et al. Expires January 9, 2017 [Page 26] Internet-Draft draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-02 July 2016 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [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, . [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, . [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, . [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, . [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, . [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, . [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. Kunze, et al. Expires January 9, 2017 [Page 27] Internet-Draft draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-02 July 2016 [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. [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 Kunze, et al. Expires January 9, 2017 [Page 28] Internet-Draft draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-02 July 2016 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 Dieter Beller (editor) 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 January 9, 2017 [Page 29]