CCAMP Working Group D. Ceccarelli Internet-Draft D. Caviglia Intended status: Standards Track F. Fondelli Expires: April 24, 2010 Ericsson F. Zhang D. Li Huawei Technologies M. Corsi Altran D. Beller Alcatel-Lucent October 21, 2009 Link Management Protocol (LMP) Test Messages Extensions for Evolutive Optical Transport Networks (OTN) draft-ceccarelli-ccamp-gmpls-g709-lmp-test-01 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 24, 2010. Copyright Notice Copyright (c) 2009 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 Ceccarelli, et al. Expires April 24, 2010 [Page 1] Internet-Draft G709 Encoding for LMP Test Messages October 2009 publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document specifies Link Management Protocol (LMP) extensions for the support of enhanced Optical Transport Networks (OTN). In particular it updates LMP test messages detailing the ITU-T G.709 OTN technology specific information and extends them in order to cover also recently introduced signal types and containers defined by the ITU-T. Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Verifying Link Connectivity . . . . . . . . . . . . . . . . . 3 3.1. Encoding Type . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Verify Transport Mechanism . . . . . . . . . . . . . . . . 5 3.3. Transmission Rate . . . . . . . . . . . . . . . . . . . . 6 4. Trace Monitoring . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. TRACE Object for evolutive OTN . . . . . . . . . . . . . . 7 4.2. Discovery Response Message for Layer Adjacency Discovery . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Ceccarelli, et al. Expires April 24, 2010 [Page 2] Internet-Draft G709 Encoding for LMP Test Messages October 2009 1. Terminology 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 [RFC2119]. 2. Introduction [RFC4204] defines the Link Management Protocol (LMP), which is a protocol of the Generalized Multi-Protocol Label Switching (GMPLS) [RFC3945] suite used to manage Traffic Engineering (TE) links. A TE link may be made by multiple physical resources interconnecting Label Switched Routers (LSRs), that are combined together for scalability reasons. Current definition of LMP consists of two mandatory procedures: - Control channel management: used to maintain control channels connectivity between adjacent LSRs. Such procedure is based on the exchange of a message called Config message followed by a lightweight keep-alive message exchange - Link property correlation: used to combine multiple physical links into a single TE link. and two optional procedures: - Link verification: used to verify the connectivity of the physical links composing a TE link and to exchange their Interface_Ids - Fault management: used to suppress alarms and locate failures. This feature may not be needed in G.709 networks because fault management mechanisms are provided by the G.709 architecture. This document defines G.709 technology specific information needed when running LMP. In particular it is focused on link verification and link property correlation functionalities and the G.709 test procedures they are based on. Such procedures require the definition of a G.709 specific TRACE object. After data links have been verified, it is possible to group them into the TE links. 3. Verifying Link Connectivity [RFC4204] defines a link verification procedure based on the in-band transmission of Test messages over the data links. It is used to Ceccarelli, et al. Expires April 24, 2010 [Page 3] Internet-Draft G709 Encoding for LMP Test Messages October 2009 verify the physical connectivity of such links, to discover data plane resources and to exchange the Interface_Ids. It is also possible to use a single procedure to verify multiple data links and correlate the information collected by means of the Verify_Id assigned to the procedure. The link verification procedure works as follows: - BeginVerify message: the local node sends a BeginVerify message over a control channel. It includes a BEGIN_VERIFY object which contains all the parameters characterizing the data link like, for example, the number of data links that must be verified, the transmission interval of the Test messages or the wavelength over which the Test messages will be sent. - BeginVerifyAck: if the remote node, upon receiving a BeginVerify message, is ready to begin the procedure, it replies with a BeginVerifyAck message. Such message specifies the desired transport mechanism for the Test messages and the Verify_Id of the procedure assigned by the remote node. - Data link Testing: the local node, upon receiving the BeginVerifyAck message, can begin testing the data links repeatedly sending Test messages over them. The remote node will reply either with a TestStatsSuccess or a TestStatusFailure for each data link. As a consequence the local node will send a TestStatusAck. - End of testing: The local node can terminate the Test procedure at anytime just sending an EndVerifyMessage towards the remote node. Evolutive OTNs need the support from LMP for the testing of all the possible data links defined by ITU-T. This document provides, at present, support to the data links defined by G.709 and G.709 amendment 3 recommendations and to G.Sup43 temporary document. The BEGIN_VERIFY class is defined in Section 13.8 of [RFC4204]. The following fields are extended: Encoding Type, Verify Transport Mechanism and Transmission Rate. 3.1. Encoding Type The Encoding Type identifies the type of encoding supported by the interface. LMP encoding type is consistent with the LSP encoding types defined for RSVP-TE [RFC3471]. In particular, the value to be used for G.709 hierarchy ODU and OTU signals is "Digital Wrapper". Ceccarelli, et al. Expires April 24, 2010 [Page 4] Internet-Draft G709 Encoding for LMP Test Messages October 2009 3.2. Verify Transport Mechanism This field defines the transport mechanism for the Test messages and its scope depends on each encoding type. It is a 16 bit mask set by the local node where each bit identifies the various mechanisms it can support for LMP test messages transmission. This document defines the field values with respect to the G.709 digital encoding (they are expressed in network byte order). - 0x01 OTUk TTI: 64 byte Test Message Capability of transmitting Test messages using OTUk Trail Trace Identifier (TTI) overhead with frame length of 64 bytes. See ITU G.709 Section 15.2 and Section 15.7 for the structure and definition. The Test message is sent according to [RFC4204]. - 0x02 ODUk TTI: 64 byte Test Message Capability of transmitting Test messages using ODUk Trail Trace Identifier (TTI) overhead with frame length of 64 bytes. See ITU G.709 Section 15.2 and Section 15.8 for the structure and definition. The Test message is sent according to [RFC4204]. - 0x04 GCC0: Test Message over the GCC0 Capability of transmitting Test messages using the OTUk Overhead General Communications Channel (GCC0). See ITU G.709 Section 15.7 for the structure and definition. The Test message is sent according to [RFC4204] using bit-oriented HDLC framing format [RFC1662]. - 0x08 GCC1/2: Test Message over the GCC1/2 Capability of transmitting Test messages using the ODUk Overhead General Communications Channels (GCC1/2). See ITU G.709 Section 15.8 for the structure and definition. The Test message is sent according to [RFC4204] using bit-oriented HDLC framing format [RFC1662]. - 0x10 OTUk TTI - Section Trace Correlation Capability of transmitting OTUk Trail Trace Identifier (TTI) as defined in ITU-T G.709. The Test message is not transmitted using the OTUk TTI overhead bytes (i.e. data link), but is sent over the control channel and correlated for consistency to the received pattern. The correlation between the Interface_Id and the in-band pattern is achieved using the TRACE Object as defined in Section 4 of [RFC4207]. No modification to TestStatusSuccess or Ceccarelli, et al. Expires April 24, 2010 [Page 5] Internet-Draft G709 Encoding for LMP Test Messages October 2009 TestStatusFailure messages is required. - 0x20 ODUk TTI - Path Trace Correlation Capability of transmitting ODUk Trail Trace Identifier (TTI) as defined in ITU-T G.709. The Test message is not transmitted using the OTUk TTI overhead bytes (i.e. data link), but is sent over the control channel and correlated for consistency to the received pattern. The correlation between the Interface_Id the Test message is sent from and the pattern sent in-band is achieved using the TRACE Object as defined in Section 4 of [RFC4207]. No modification to TestStatusSuccess or TestStatusFailure messages is required. 3.3. Transmission Rate The transmission rate of the data links where the link verification procedure can be performed is defined into the TransmissionRate field of the BEGIN_VERIFY class ([RFC4204] Section 13.8). Values are expressed in IEEE floating point format using a 32-bit number field and expressed in bytes per second. The following table defines the values to be used in OTNs. Non normative Signal Types are marked with (*): +-------------+-----------------+-------------------+ | Signal Type | Bit-rate (kbps) | Value (Bytes/Sec) | +-------------+-----------------+-------------------+ | ODU0 | 1 244 160 | 0x4D1440C0 | +-------------+-----------------+-------------------+ | ODU1 | 2 498 775 | 0x4D94F048 | | OTU1 | 2 666 057 | 0x4D9EE8CD | +-------------+-----------------+-------------------+ | ODU2 | 10 037 274 | 0x4E959129 | | OTU2 | 10 709 226 | 0x4E9F9475 | +-------------+-----------------+-------------------+ | ODU2e | 10 399 525 | 0x4E9AF70A | +-------------+-----------------+-------------------+ | ODU3 | 40 319 219 | 0X4F963367 | | OTU3 | 43 018 416 | 0X4FA0418F | +-------------+-----------------+-------------------+ | ODU3e1* | 41 774 364 | 0x4F9B9F23 | | OTU3e1* | 44 570 974 | 0x4FA60A31 | | ODU3e2* | 41 785 968 | 0x4F9BAA34 | | OTU3e2* | 44 583 355 | 0x4FA61600 | +-------------+-----------------+-------------------+ | ODU4 | 104 794 445 | 0x504331E3 | | OTU4 | 111 809 973 | 0x50504326 | Ceccarelli, et al. Expires April 24, 2010 [Page 6] Internet-Draft G709 Encoding for LMP Test Messages October 2009 +-------------+-----------------+-------------------+ Transmission Rate values (Bytes/Sec) 4. Trace Monitoring [RFC4207] describes the set of trace monitoring procedures that allow a node to do trace monitoring by using the G.709 hierarchy capabilities. This document defines a new C-Type of the TRACE Object class used for Trace Monitoring features as defined in [RFC4207]. 4.1. TRACE Object for evolutive OTN The TRACE Object Class assigned by IANA is 21. A new C-Type is TBA and value 2 is suggested. The TRACE Object format is the same as defined in [RFC4207] and is shown in the following: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N| C-Type | Class | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Trace Type | Trace Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Trace Message // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TRACE Object Class Trace Type: 16 bits The Trace Type field is used to identify the type of the trace message. The following values are defined and all other values are reserved and should be sent as zero and ignored on receipt. Ceccarelli, et al. Expires April 24, 2010 [Page 7] Internet-Draft G709 Encoding for LMP Test Messages October 2009 1 = OTUk TTI 2 = ODUk TTI 3 = Level 1 ODUkT TTI 4 = Level 2 ODUkT TTI 5 = Level 3 ODUkT TTI 6 = Level 4 ODUkT TTI 7 = Level 5 ODUkT TTI 8 = Level 6 ODUkT TTI (default for layer adjacency discovery) It shall be noted that an Amendment to ITU-T G.7714.1 is planned to be approved in June 2010 that defines an extension for OTN layer adjacency discovery based on the ODUk TCM function (ODUkT) providing 6 TCM levels. By default the TCM level 6 SHALL be used. Trace Length: 16 bits Expresses the length of the trace message in bytes (as specified by the Trace Type). Trace Message: This field includes the value of the expected message to be received in-band. The valid length and value combinations are determined by the ITU.T G.709 recommendation. The message MUST be padded with zeros to a 32-bit boundary, if necessary. Trace Length does not include padding zeroes. This object is non negotiable. 4.2. Discovery Response Message for Layer Adjacency Discovery ITU-T Recommendation G.7714.1 [ITUT-G.7714.1] describes an automatic layer adjacency discovery procedure that can be applied to the ITU-T G.709 OTN technology. The discovery message can be sent to the adjacent node via the Trail Trace Identifier (TTI) and Appendix III of G.7714.1 describes how the discovery response message can be sent back to the originator of the discovery message (discovery agent in G.7714.1 terminology) using the LMP protocol. As defined in [ITUT-G.7714.1], the TraceMonitor message [RFC4207] is used to convey the discovery response message. The following mapping table shows how the discovery response message attributes are mapped to TraceMonitor message objects or other fields of the LMP message (see G.7714.1, section 11 for the description of the attributes): Ceccarelli, et al. Expires April 24, 2010 [Page 8] Internet-Draft G709 Encoding for LMP Test Messages October 2009 | G.7714.1 discovery response | TraceMonitor/LMP message field message attribute | ---------------------------------+---------------------------------------- | : received discovery message | | : received discovery message | | IP source address in the IP header | | identical to | | | The received TTI, more specifically the discovery message in the SAPI field contains the and the . These attributes are included in the discovery response message by copying the received TTI into the field of the TraceMonitor message. The IP address of the node sending the discovery response message corresponds to the and is the IP source address in the IP header of the LMP TraceMonitor message. Typically, the Trail Connection Point (TCP-)IDs in transmit and receive direction are identical for OTN equipment, i.e., the is identical to the . The identifies the TCP on which the Discovery Message was received and corresponds to the object in the TraceMonitor message. 5. Security Considerations TBD 6. Acknowledgements The authors would like to thank Attila Takacs, Andras Kern, Sergio Belotti and Pietro Grandi for the kind review of the ID and the valuable comments provided. Ceccarelli, et al. Expires April 24, 2010 [Page 9] Internet-Draft G709 Encoding for LMP Test Messages October 2009 7. IANA Considerations A new C-Type value for the Trace Object Class (21) is TBA by IANA. 8. References 8.1. Normative References [ITUT-G.7714.1] ITU-T, "Protocol for automatic discovery in SDH and OTN networks, G.7714.1 Recommendation", April 2003. [RFC1662] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662, July 1994. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004. [RFC4204] Lang, J., "Link Management Protocol (LMP)", RFC 4204, October 2005. [RFC4207] Lang, J. and D. Papadimitriou, "Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) Encoding for Link Management Protocol (LMP) Test Messages", RFC 4207, October 2005. 8.2. Informative References [ITUT-G.709] ITU-T, "Interface for the Optical Transport Network (OTN)", G.709 Recommendation (and Amendment 1), February 2001. Ceccarelli, et al. Expires April 24, 2010 [Page 10] Internet-Draft G709 Encoding for LMP Test Messages October 2009 Authors' Addresses Daniele Ceccarelli Ericsson Via A. Negrone 1/A Genova - Sestri Ponente Italy Email: daniele.ceccarelli@ericsson.com Diego Caviglia Ericsson Via A. Negrone 1/A Genova - Sestri Ponente Italy Email: diego.caviglia@ericsson.com Francesco Fondelli Ericsson Via A. Negrone 1/A Genova - Sestri Ponente Italy Email: francesco.fondelli@ericsson.com Fatai Zhang Huawei Technologies F3-5-B R&D Center, Huawei Base Shenzhen 518129 P.R.China Bantian, Longgang District Phone: +86-755-28972912 Email: zhangfatai@huawei.com Dan Li Huawei Technologies F3-5-B R&D Center, Huawei Base Shenzhen 518129 P.R.China Bantian, Longgang District Phone: +86-755-28973237 Email: danli@huawei.com Ceccarelli, et al. Expires April 24, 2010 [Page 11] Internet-Draft G709 Encoding for LMP Test Messages October 2009 Marco Corsi Altran Via A. Negrone 1/A Genova - Sestri Ponente Italy Email: marco.corsi@altran.it Dieter Beller Alcatel-Lucent Lorenzstrasse 10 Stuttgart 70435 Germany Email: dieter.beller@alcatel-lucent.com Ceccarelli, et al. Expires April 24, 2010 [Page 12]