--- 1/draft-ietf-ccamp-dwdm-if-lmp-00.txt 2019-11-04 01:13:09.613252308 -0800 +++ 2/draft-ietf-ccamp-dwdm-if-lmp-01.txt 2019-11-04 01:13:09.649253346 -0800 @@ -1,34 +1,34 @@ Internet Engineering Task Force D. Hiremagalur, Ed. Internet-Draft G. Grammel, Ed. Intended status: Standards Track Juniper -Expires: September 27, 2019 G. Galimberti, Ed. +Expires: May 7, 2020 G. Galimberti, Ed. Cisco R. Kunze, Ed. Deutsche Telekom D. Beller Nokia - March 26, 2019 + November 4, 2019 Extension to the Link Management Protocol (LMP/DWDM -rfc4209) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems to manage the application code of optical interface parameters in DWDM application - draft-ietf-ccamp-dwdm-if-lmp-00 + draft-ietf-ccamp-dwdm-if-lmp-01 Abstract This memo defines extensions to LMP(rfc4209) for managing Optical parameters associated with Wavelength Division Multiplexing (WDM) systems in accordance with the Interface Application Identifier - approach defined in ITU-T Recommendation G.694.1.[ITU.G694.1] and its - extensions. + approach defined in ITU-T Recommendation G.694.1.[ITU-T.G694.1] and + its extensions. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. @@ -36,21 +36,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on September 27, 2019. + This Internet-Draft will expire on May 7, 2020. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -58,47 +58,51 @@ 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. DWDM line system . . . . . . . . . . . . . . . . . . . . . . 3 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 4. Extensions to LMP-WDM Protocol . . . . . . . . . . . . . . . 4 - 5. General Parameters - OCh_General . . . . . . . . . . . . . . 5 - 6. ApplicationIdentifier - OCh_ApplicationIdentifier . . . . . . 6 - 7. OCh_Ss - OCh transmit parameters . . . . . . . . . . . . . . 9 - 8. OCh_Rs - receive parameters . . . . . . . . . . . . . . . . . 9 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 - 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 - 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 - 12.1. Normative References . . . . . . . . . . . . . . . . . . 11 - 12.2. Informative References . . . . . . . . . . . . . . . . . 12 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 + 3.1. Optical interface parameter collection . . . . . . . . . 4 + 3.2. DWDM client - ROADM interconection discovery . . . . . . 5 + 3.3. Service Setup . . . . . . . . . . . . . . . . . . . . . . 5 + 3.4. Link Monitoring Use Cases . . . . . . . . . . . . . . . . 6 + 4. Extensions to LMP-WDM Protocol . . . . . . . . . . . . . . . 7 + 5. General Parameters - OCh_General . . . . . . . . . . . . . . 7 + 6. ApplicationIdentifier - OCh_ApplicationIdentifier . . . . . . 9 + 7. OCh_Ss - OCh transmit parameters . . . . . . . . . . . . . . 11 + 8. OCh_Rs - receive parameters . . . . . . . . . . . . . . . . . 12 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 + 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 12.1. Normative References . . . . . . . . . . . . . . . . . . 14 + 12.2. Informative References . . . . . . . . . . . . . . . . . 15 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction - This extension addresses the use cases described by "draft-ietf- - ccamp-dwdm-if-mng-ctrl-fwk". LMP [RFC4902] provides link property - correlation capabilities that can be used between a transceiver - device and an Optical Line System (OLS) device. Link property - correlation is a procedure by which, intrinsic parameters and - capabilities are exchanged between two ends of a link. Link property - correlation as defined in RFC3591 allows either end of the link to - supervise the received signal and operate within a commonly - understood parameter window. Here the term 'link' refers in - particular to the attachment link between OXC and OLS (see Figure 1). - The relevant interface parameters are in line with "draft-dharini- - ccamp-dwdm-if-yang". + LMP [RFC4902] provides link property correlation capabilities that + can be used between a transceiver device and an Optical Line System + (OLS) device. Link property correlation is a procedure by which, + intrinsic parameters and capabilities are exchanged between two ends + of a link. Link property correlation as defined in RFC3591 allows + either end of the link to supervise the received signal and operate + within a commonly understood parameter window. Here the term 'link' + refers in particular to the attachment link between OXC and OLS (see + Figure 1). The relevant interface parameters are in line with + "draft-dharini-ccamp-dwdm-if-yang". Use cases are 1- Optical + interface parameter collection, 2- DWDM client - ROADM interconection + discovery, 3- Service Setup, 4- Service Setup 2. DWDM line system Figure 1 shows a set of reference points (Rs and Ss), for a single- channel connection between transmitter (Tx) and receiver (Rx) devices. Here the DWDM network elements in between those devices include an Optical Multiplexer (OM) and an Optical Demultiplexer (OD). In addition it may include one or more Optical Amplifiers (OA) and one or more Optical Add-Drop Multiplexers (OADM). @@ -145,55 +149,176 @@ | | | | | | | +-----LMP-----+ +-----LMP-----+ | | | +----------------------LMP-----------------------+ OXC : is an entity that contains transponders OLS : generic optical system, it can be - Optical Mux, Optical Demux, Optical Add Drop Mux, Amplifier etc. OLS to OLS : represents the Optical Multiplex section - + Rs/Ss : reference points in between the OXC and the OLS Figure 2: Extended LMP Model 3. Use Cases - The use cases are described in draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk + A comparison with the traditional operation scenarios provides an + insight of similarities and distinctions in operation and management + of DWDM interfaces. The following use cases provide an overview + about operation and maintenance processes. + +3.1. Optical interface parameter collection + + It is necessary to identify the Optical interface characteristics and + setting in order to properly calculate the ent to end path and match + the Head End interface against the Tail End interface compatibility. + The optical parameters may have multiple possible values that the + Controller (SDN or GMPLS) can use and select for the best network + optimisation. In case og GMPLS the LMP is suitable to support the + parameters exchange between the ROADM and the Transponder (or DWDM + interface located into the client box). + +3.2. DWDM client - ROADM interconection discovery + + Being the the DWDM port and ROADM port belonging to different domains + and Network Elements, the interconnection between them is not + embedded in the Optical Nodes and can not be shared to the EMS and + the Controller. The Controller needs then to retrieve the + connectivity using data coming from the two domains correlating them + to discover the relationship. The methods to discover the + interconnection can be LMP, LLDP, installation provisioning or any + other mechanism checking using the light transmitted by the DWDM + transmitter and detecter by the ROAMD port photodiode. This use case + is fundamental to build the interconnections between the DWDM and + Client layer (e.g. Routers) and calculate the multilayer network + topology. + +3.3. Service Setup + + It is necessary to differentiate between different operational issues + for setting up a light path (a DWDM connection is specific in having + defined maximum impairments) within an operational network. + + The first step is to determine if transceivers located at different + end-points are interoperable, i.e. support a common set of + operational parameters. In this step it is required to determine + transceiver capabilities in a way to be able to correlate them for + interoperability purposes. Such parameters include modulation + scheme, modulation parameters, FEC to name a few. If both + transceivers are controlled by the same NMS or CP, such data is + readily available. However in cases where the transceivers are + controlled by different CP, a protocol needs to be used to inform the + controlling instance (NMS or CP) about transceiver parameters. It is + suggested to extend LMP for that purpose. + + The second step is to determine the feasibility of a lightpath + between two transceivers without applying an optical signal. + Understanding the limitations of the transceiver pair, a path through + the optical network has to be found, whereby each path has an + individual set of impairments deteriorating a wavelength traveling + along that path. Since a single transceiver can support multiple + parameter sets, the selection of a path may limit the permissible + parameter sets determined in previous steps. + + The third step is then to setup the connection itself and to + determine the Wavelength. This is done using the NMS of the optical + transport network or by means of a control plane interaction such as + signaling and includes the path information as well as the parameter + set information necessary to enable communication. + + In a fourth step, optical monitoring is activated in the WDM network + in order to monitor the status of the connection. The monitor + functions of the optical interfaces at the terminals are also + activated in order to monitor the end to end connection. + + Furthermore it should be possible to automate this step. After + connecting the client device to the neighbor control plane-enabled + transport node, a control adjacency may be automatically established, + e.g. using LMP. + +3.4. Link Monitoring Use Cases + + The use cases described below are assuming that power monitoring + functions are available in the ingress and egress network element of + the DWDM network, respectively. By performing link property + correlation it would be beneficial to include the current transmit + power value at reference point Ss and the current received power + value at reference point Rs. For example if the Client transmitter + power has a value of 0dBm and the ROADM interface measured power is + -6dBm the fiber patch cord connecting the two nodes may be pinched or + the connectors are dirty. As discussed before, the actual path or + selection of a specific wavelength within the allowed set is outside + the scope of LMP. The computing entities (e.g. the first optical + node originating the circuit) can rely on GMPLS IGP (OSPF) to + retrieve all the information related to the network, calculate the + path to reach the endpoint and signal the path implementation through + the network via RSVP-TE. + + [ITU-T.G.698.2] defines a single channel optical interface for DWDM + systems that allows interconnecting network-external optical + transponders across a DWDM network. The optical transponders are + external to the DWDM network. This so-called 'Black Link' approach + illustrated in Fig. 5-1 of [ITU-T.G.698.2]. The single channel fiber + link between the Ss/Rs reference points and the ingress/egress port + of the network element on the domain boundary of the DWDM network + (DWDM border NE) is called access link. Based on the definition in + [ITU-T.G.698.2] it is part of the DWDM network. The access link is + typically realized as a passive fiber link that has a specific + optical attenuation (insertion loss). As the access link is an + integral part of the DWDM network, it is desirable to monitor its + attenuation. Therefore, it is useful to detect an increase of the + access link attenuation, for example, when the access link fiber has + been disconnected and reconnected (maintenance) and a bad patch panel + connection (connector) resulted in a significantly higher access link + attenuation (loss of signal in the extreme case of an open connector + or a fiber cut). In the following section, two use cases are + presented and discussed: + + 1) pure access link monitoring + 2) access link monitoring with a power control loop + + These use cases require a power monitor as described in G.697 (see + section 6.1.2), that is capable to measure the optical power of the + incoming or outgoing single channel signal. The use case where a + power control loop is in place could even be used to compensate an + increased attenuation if the optical transmitter can still be + operated within its output power range defined by its application + code. 4. Extensions to LMP-WDM Protocol This document defines extensions to [RFC4209] to allow a set of characteristic parameters, to be exchanged between a router or optical switch (e.g. OTN cross connect) and the optical line system to which it is attached. In particular, this document defines additional Data Link sub-objects to be carried in the LinkSummary message defined in [RFC4204] and [RFC6205]. The OXC and OLS systems may be managed by different Network management systems and hence may not know the capability and status of their peer. These messages and their usage are defined in subsequent sections of this document. The following new messages are defined for the WDM extension for - ITU-T G.698.2 [ITU.G698.2]/ITU-T G.698.1 [ITU.G698.1]/ - ITU-T G.959.1 [ITU.G959.1] + ITU-T G.698.2 [ITU-T.G698.2]/ITU-T G.698.1 [ITU-T.G698.1]/ + ITU-T G.959.1 [ITU-T.G959.1] - OCh_General (sub-object Type = TBA) - OCh_ApplicationIdentier (sub-object Type = TBA) - OCh_Ss (sub-object Type = TBA) - OCh_Rs (sub-object Type = TBA) 5. General Parameters - OCh_General These are a set of general parameters as described in [G698.2] and - [G.694.1]. Please refer to the "draft-galikunze-ccamp-dwdm-if-snmp- - mib" and "draft-dharini-ccamp-dwdm-if-yang" for more details about - these parameters and the [RFC6205] for the wavelength definition. + [G.694.1]. Please refer to the "draft-dharini-ccamp-dwdm-if-yang" + for more details about these parameters and the [RFC6205] for the + wavelength definition. The general parameters are 1. Central Frequency - (Tera Hz) 4 bytes (see RFC6205 sec.3.2) 2. Number of Application Identifiers (A.I.) Supported 3. Single-channel Application Identifier in use 4. Application Identifier Type in use 5. Application Identifier in use Figure 3: The format of the this sub-object (Type = TBA, Length = TBA) is as follows: @@ -439,51 +564,44 @@ jdrake@juniper.net Zafar Ali Cisco 3000 Innovation Drive KANATA ONTARIO K2K 3E8 zali@cisco.com 12. References - 12.1. Normative References - [I-D.ietf-ccamp-dwdm-if-mng-ctrl-fwk] - Kunze, R., Grammel, G., Beller, D., Galimberti, G., and J. - Meuric, "A framework for Management and Control of DWDM - optical interface parameters", draft-ietf-ccamp-dwdm-if- - mng-ctrl-fwk-11 (work in progress), June 2018. - - [ITU.G694.1] - International Telecommunications Union, ""Spectral grids - for WDM applications: DWDM frequency grid"", - ITU-T Recommendation G.698.2, February 2012. - - [ITU.G698.2] + [ITU-T.G.698.2] International Telecommunications Union, "Amplified multichannel dense wavelength division multiplexing applications with single channel optical interfaces", ITU-T Recommendation G.698.2, November 2009. - [ITU.G709] + [ITU-T.G694.1] + International Telecommunications Union, ""Spectral grids + for WDM applications: DWDM frequency grid"", + ITU-T Recommendation G.698.2, February 2012. + + [ITU-T.G709] International Telecommunications Union, "Interface for the Optical Transport Network (OTN)", ITU-T Recommendation G.709, June 2016. - [ITU.G872] + [ITU-T.G872] International Telecommunications Union, "Architecture of optical transport networks", ITU-T Recommendation G.872, January 2017. - [ITU.G874.1] + [ITU-T.G874.1] International Telecommunications Union, "Optical transport network (OTN): Protocol-neutral management information model for the network element view", ITU-T Recommendation G.874.1, November 2016. [RFC4054] Strand, J., Ed. and A. Chiu, Ed., "Impairments and Other Constraints on Optical Layer Routing", RFC 4054, DOI 10.17487/RFC4054, May 2005, .