Network Working Group Fatai Zhang Internet Draft Xian Zhang Category: Standards Track Huawei D. Ceccarelli D. Caviglia Ericsson Guoying Zhang CATR D. Beller S.Belotti Alcatel-Lucent Expires: April 11, 2013 October 12, 2012 Link Management Protocol (LMP) extensions for G.709 Optical Transport Networks draft-cecczhang-ccamp-gmpls-g709v3-lmp-00.txt 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 11, 2013. Abstract Recent progress of the Optical Transport Network (OTN) has introduced new signal types (i.e., ODU0, ODU4, ODU2e and ODUflex) and new Tributary Slot granularity (1.25Gbps). Ceccarelli & Zhang Expires April 2013 [Page 1] draft-cecczhang-ccamp-gmpls-g.709v3-lmp-00.txt October 2012 Since equipments deployed prior to recently defined ITU-T recommendations only support 2.5 Gbps Tributary Slot granularity and ODU1, ODU2 and ODU3 containers, the compatibility problem should be considered. In addition, a Higher Order ODU (HO ODU) link may not support all the types of Lower Order ODU (LO ODU) signals defined by the new OTN standard because of the limitation of the devices at the two ends of a link. In these cases, the control plane is required to run the capability discovering functions for the evolutive OTN. This document describes the extensions to the Link Management Protocol (LMP) needed to discover the capability of HO ODU link, including the granularity of Tributary Slot to be used and the LO ODU signal types that the link can support. Moreover, extensions of LMP test messages detailing the OTN technology specific information in order to cover also G.709v3 signal types and containers are also provided. Conventions used in this document 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]. Table of Contents 1. Introduction ................................................ 3 2. Terminology ................................................. 4 3. Overview of the Evolutive G.709 .............................. 4 4. Link Capability Discovery ................................... 5 4.1. Link Capabaplity Discovery Requirements ................. 5 4.1.1. Discovering the Granularity of the TS .............. 5 4.1.2. Discovering the Supported LO ODU Signal Types....... 6 4.2. Extensions: LMP Link Summary Message .................... 7 4.2.1. Message Extension .................................. 7 4.2.1.1. LinkSummary Message ........................... 7 4.2.1.2. LinkSummaryAck Message ........................ 8 4.2.1.3. LinkSummaryNack Message ....................... 8 4.2.2. Object Definitions ................................. 8 4.2.3. Procedures ........................................ 10 5. Verifying Link Connectivity ................................. 12 5.1. Encoding Type ......................................... 13 5.2. Verify Transport Mechanism ............................. 13 5.3. Transmission Rate ...................................... 14 6. Trace Monitoring ........................................... 15 6.1. TRACE Object for evolutive OTN ......................... 15 6.2. Discovery Response Message for Layer Adjacency Discovery 17 Ceccarelli & Zhang Expires April 2013 [Page 2] draft-cecczhang-ccamp-gmpls-g.709v3-lmp-00.txt October 2012 7. LMP Behavior Negotiation Update ............................. 18 8. Security Considerations ..................................... 18 9. IANA Considerations ........................................ 19 10. Acknowledgments ........................................... 19 11. References ................................................ 19 11.1. Normative References .................................. 19 11.2. Informative References ................................ 20 12. Authors' Addresses ........................................ 20 13. Contributors .............................................. 22 1. Introduction The Link Management Protocol (LMP) defined in [RFC4204] is being developed as part of the Generalized MPLS (GMPLS) protocol suite to manage Traffic Engineering (TE) links. Recently, great progress has been made for the Optical Transport Networking (OTN) technologies in ITU-T. New ODU containers (i.e., ODU0, ODU4, ODU2e and ODUflex) and a new Tributary Slot (TS) granularity (1.25Gbps) have been introduced by the [G709-V3], enhancing the flexibility of OTNs. With the evolution and deployment of G.709 technology, the backward compatibility problem requires to be considered. In data plane, the equipment supporting 1.25Gbps TS can combine the specific Tributary Slots together (e.g., combination of TS#i and TS#i+4 on a HO ODU2 link) so that it can interwork with other equipments which support 2.5Gbps TS. From the control plane point of view, it is necessary to discover which type of TS is supported at both ends of a link, so that it can choose and reserve the TS resources correctly in this link for the connection. Additionally, the requirement of discovering the signal types of Lower Order ODU (LO ODU) that can be supported by a Higher Order ODU (HO ODU) should be taken into account. Equipment at one end of a HO ODU link may not support to transport some types of LO ODU signals (e.g., may not support the ODUflex). In this case, this HO ODU link should not be selected for those types of LO ODU connections. From the perspective of control plane, it is necessary to discover the capability of a HO ODUk or OTUk link including the granularity of TS to be used and the LO ODU signal types that the link can support. Note that this capability information can be, in principle, discovered by routing. Since in certain case, routing is not present (e.g., UNI case) we need to extend link management protocol capabilities to cover this aspect. Obviously, in case of routing presence, the discovering procedure by LMP could also be optional. Ceccarelli & Zhang Expires April 2013 [Page 3] draft-cecczhang-ccamp-gmpls-g.709v3-lmp-00.txt October 2012 A further enhancement needed with respect to LMP covers the 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. This document extends the LMP and describes the solution of discovering HO ODU link capability and operating link verification and link property correlation. 2. 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]. 3. Overview of the Evolutive G.709 The traditional OTN standard [ITUT-G709] describes the optical transport hierarchy (OTH) and introduces three ODU signal types (i.e., ODU1, ODU2 and ODU3). The ODUj can be mapped into one or more Tributary Slots (with a granularity of 2.5Gbps) of OPUk where j j) signal can be depicted as follows: - ODU0 into ODU1 multiplexing (with 1,25Gbps TS granularity) - ODU0, ODU1, ODUflex into ODU2 multiplexing (with 1.25Gbps TS granularity) - ODU1 into ODU2 multiplexing (with 2.5Gbps TS granularity) - ODU0, ODU1, ODU2, ODU2e and ODUflex into ODU3 multiplexing (with 1.25Gbps TS granularity) - ODU1, ODU2 into ODU3 multiplexing (with 2.5Gbps TS granularity) - ODU0, ODU1, ODU2, ODU2e, ODU3 and ODUflex into ODU4 multiplexing (with 1.25Gbps TS granularity) Note that If TS auto-negotiation is supported, a node supporting 1.25Gbps TS can interwork with the other nodes that supporting 2.5Gbps TS by combining specific TSs together in data plane, as descirbied in [OTN-frwk]. 4. Link Capability Discovery 4.1. Link Capabaplity Discovery Requirements 4.1.1. Discovering the Granularity of the TS As described in section 3.1, if the two ends of a link use different granularities of TS, The LO ODU must be mapped into specific combined Tributary Slots in the end of link with TS of 1.25Gbps. From the perspective of control plane, when creating a LO ODU connection, the node MUST select and reserve specific TS for the connection if the two ends of a link use different granularities of TS. For example, for an ODU2 link, we suppose that node A only supports the 2.5Gbps TS while node B supports the 1.25Gbps TS. When node B receives a Path message from node A requesting an ODU1 connection, node B MUST reserve the TS#i and TS#i+4 (where i<=4) (with the granularity of 1.25Gbps) and tell node A via the label carried in the Resv message that the TS#i (with the granularity of 2.5Gbps) among the 4 slots has been reserved for the ODU1 connection. Otherwise, the reservation procedure will fail. Ceccarelli & Zhang Expires April 2013 [Page 5] draft-cecczhang-ccamp-gmpls-g.709v3-lmp-00.txt October 2012 +-----+ Path +-----+ | | ------------> | | | A +-------ODU2 link-------+ B | | | <------------- | | +-----+ Resv +-----+ (Support 2.5G TS) (Support 1.25G TS) Therefore, for an ODU2 or ODU3 link, in order to reserve TS resources correctly for a LO ODU connection, the control plane of the two ends MUST know which granularity the other end can support before creating the LO ODU connection. 4.1.2. Discovering the Supported LO ODU Signal Types Many new ODU signal types are introduced by [G709-V3], such as ODU0, ODU4, ODU2e and ODUflex. It is possible that equipment does not always support all the LO ODU signal types introduced by [G709-V3]. If one end of a HO ODU link can not support a certain LO ODU signal type and there is no HO ODU FA LSP able to support this LO ODU signal, the HO ODU link/FA LSP can not be selected to carry such type of LO ODU connection. For example, in the following figure, if the interfaces IF1, IF2, IF8, IF7, IF5 and IF6 can support ODUflex signals, while the interfaces IF 3 and IF4 can not support ODUflex signals. In this case, if one ODUflex connection from A to C is requested, and there is no HO ODU FA LSP from node A to C through node B, link #1 and #2 should be excluded, link #3 and link #4 are the candidates (the possible path could be A-D-C through link #3 and link #4). +-----+ link #3 | | link #4 +-----------------+ D +-----------------+ | IF8| |IF7 | | +-----+ | | | |IF1 IF6| +--+--+ +-----+ +--+--+ | | link #1 | | link #2 | | | A +--------------+ B +--------------+ C | | |IF2 IF3| |IF4 IF5| | +-----+ +-----+ +-----+ Therefore, it is necessary for the two ends of a HO ODU link to discover which types of LO ODU can be supported by the HO ODU link. Ceccarelli & Zhang Expires April 2013 [Page 6] draft-cecczhang-ccamp-gmpls-g.709v3-lmp-00.txt October 2012 After discovering, the capability information can be flooded by IGP, so that the correct path for an ODU connection can be calculated. 4.2. Extensions: LMP Link Summary Message [RFC4204] defines the Link Management Protocol (LMP) which consists of four main procedures: control channel management, link property correlation, link connectivity verification, and fault management. As part of LMP, the link property correlation is used to verify the consistency of the TE and data link information on both sides of a link. This document extends the link property correlation procedure to discover the capability of both sides of a HO ODU link. The designated HO ODU overhead bytes (e.g., the GCC1 and GCC2 overhead bytes) can be used as the control channel to carry the LMP message after the HO ODU link is created. The out-of-band Data Communication Network (DCN) can also be used. 4.2.1. Message Extension Three messages are used for link property correlation: LinkSummary, LinkSummaryAck and LinkSummaryNack Message. This document does not change the basic procedure of LMP but just add a new subobject (HO ODU Link Capability) in the DATA_LINK object to carry the capability of one end of a HO ODU link. The formats of LinkSummary, LinkSummaryAck and LinkSummaryNack messages are defined in [RFC4204]. 4.2.1.1. LinkSummary Message The local end of a TE link can send a LinkSummary message to the remote end to start the negotiation about the capability that the TE link can support. One new Subobject named HO ODU Link Capability Subobject in the DATA_LINK object is introduced by this document. This new subobect is used to tell the remote end of the HO ODU link which TS granularity and which LO ODU signal types that the local end can support. When the DATA_LINK object carries the new HO ODU Link Capability Subobject, the N flag SHOULD be set to 1 which means that the subobject is negotiable. Ceccarelli & Zhang Expires April 2013 [Page 7] draft-cecczhang-ccamp-gmpls-g.709v3-lmp-00.txt October 2012 4.2.1.2. LinkSummaryAck Message The LinkSummaryAck message is used to tell the remote end that it has the same capability as the remote end after the LinkSummary message is received by the local end. 4.2.1.3. LinkSummaryNack Message The LinkSummaryNack message is used to tell the remote end that it has different capability from the remote end after the LinkSummary message is received by the local end. The LinkSummaryNack message also carries the HO ODU Link Capability subobject in the DATA_LINK object to tell the remote end the exact capability of the HO ODU link after negotiation, i.e., the granularity of TS and the types of LO ODU that both side of the HO ODU link can support. 4.2.2. Object Definitions A new HO ODU Link Capability subobject type is introduced to the DATA LINK object to carry the HO ODU link capability information. The format of the new subobject is defined as follow: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |OD(T)Uk| T | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|B|C|D|E|F|G| LO ODU Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type (8 bits): The value of this subobject type is TBD. Length (8 bits): The Length field contains the total length of the subobject in bytes, including the Type and Length fields. As for RFC 4204, the Length MUST be at least 4, and MUST be a multiple of 4. Value of this field is 8. OD(T)Uk (4 bits): This field is used to indicate the HO ODU link type (in case of LO ODUj multiplexing into HO ODUk, wherein j | : received discovery message | | : received discovery message | | IP source address in the IP header | | identical to Ceccarelli & Zhang Expires April 2013 [Page 17] draft-cecczhang-ccamp-gmpls-g.709v3-lmp-00.txt October 2012 | | | 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. 7. LMP Behavior Negotiation Update This docuemnt also introduces an update to the BehaviorConfig C-Type defined in [LMP-NEG]. A new flag in the BehaviorConfig is needed for the indication of the support for OTN Test Messages: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S|D|C|O| Must Be Zero (MBZ) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - O: 1 bit This bit indicates support for the TEST behavior of OTN technology-specific defined in this document. 8. Security Considerations TBD. Ceccarelli & Zhang Expires April 2013 [Page 18] draft-cecczhang-ccamp-gmpls-g.709v3-lmp-00.txt October 2012 9. IANA Considerations TBD. 10. Acknowledgments TBD. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4204] J. Lang, Ed., "Link Management Protocol (LMP)", RFC 4204, October 2005. [OTN-frwk] Zhang, F. et al, "Framework for GMPLS and PCE Control of G.709 Optical Transport Networks", draft-ietf-ccamp- gmpls-g709-framework-08.txt, June 19, 2012. [ITUT-G709] ITU-T, "Interface for the Optical Transport Network (OTN)", G.709 Recommendation, March 2003. [G709-V3] ITU-T, "Interfaces for the Optical Transport Network (OTN)", G.709 Recommendation, December 2009. [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. [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. [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. Ceccarelli & Zhang Expires April 2013 [Page 19] draft-cecczhang-ccamp-gmpls-g.709v3-lmp-00.txt October 2012 11.2. Informative References [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004. [RFC4328] D. Papadimitriou, Ed. "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control", RFC 4328, Jan 2006. [LMP-NEG] D.Li, D.Ceccarelli, L.Berger, "Link Management Protocol Behavior Negotiation and Configuration Modifications," July 2012, draft-ietf-ccamp-lmp-behavior-negotiation-06. 12. Authors' Addresses Fatai Zhang Huawei Technologies F3-5-B R&D Center, Huawei Base Bantian, Longgang District Shenzhen 518129 P.R.China Phone: +86-755-28972912 Email: zhangfatai@huawei.com Xian Zhang Huawei Technologies Co., Ltd. F3-5-B R&D Center, Huawei Base, Bantian, Longgang District Shenzhen 518129 P.R.China Phone: +86-755-28972913 Email: zhang.xian@huawei.com Daniele Ceccarelli Ericsson Via A. Negrone 1/A Genova - Sestri Ponente Italy Email: daniele.ceccarelli@ericsson.com Ceccarelli & Zhang Expires April 2013 [Page 20] draft-cecczhang-ccamp-gmpls-g.709v3-lmp-00.txt October 2012 Diego Caviglia Ericsson Via A. Negrone 1/A Genova - Sestri Ponente Italy Email: diego.caviglia@ericsson.com Francesco Fondelli Ericsson Via Moruzzi 1 Pisa Italy Email: francesco.fondelli@ericsson.com Guoying Zhang China Academy of Telecommunication Research of MII 11 Yue Tan Nan Jie Beijing, P.R.China Phone: +86-10-68094272 Email: zhangguoying@mail.ritt.com.cn Pietro Grandi Alcatel-Lucent Optics CTO Via Trento 30 20059 Vimercate (Milano) Italy +39 039 6864930 Email: pietro_vittorio.grandi@alcatel-lucent.it Sergio Belotti Alcatel-Lucent Optics CTO Via Trento 30 20059 Vimercate (Milano) Italy +39 039 6863033 Email: sergio.belotti@alcatel-lucent.it Dan Li Ceccarelli & Zhang Expires April 2013 [Page 21] draft-cecczhang-ccamp-gmpls-g.709v3-lmp-00.txt October 2012 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 Dieter Beller Alcatel-Lucent Lorenzstrasse 10 Stuttgart 70435 Germany Email: dieter.beller@alcatel-lucent.com 13. Contributors Yi Lin Huawei Technologies Co., Ltd. F3-5-B R&D Center, Huawei Base, Bantian, Longgang District Shenzhen 518129 P.R.China Phone: +86-755-28972914 Email: yi.lin@huawei.com Intellectual Property The IETF Trust takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in any IETF Document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Copies of Intellectual Property disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr Ceccarelli & Zhang Expires April 2013 [Page 22] draft-cecczhang-ccamp-gmpls-g.709v3-lmp-00.txt October 2012 The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement any standard or specification contained in an IETF Document. Please address the information to the IETF at ietf-ipr@ietf.org. The definitive version of an IETF Document is that published by, or under the auspices of, the IETF. Versions of IETF Documents that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of IETF Documents. The definitive version of these Legal Provisions is that published by, or under the auspices of, the IETF. Versions of these Legal Provisions that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of these Legal Provisions. For the avoidance of doubt, each Contributor to the IETF Standards Process licenses each Contribution that he or she makes as part of the IETF Standards Process to the IETF Trust pursuant to the provisions of RFC 5378. No language to the contrary, or terms, conditions or rights that differ from or are inconsistent with the rights and licenses granted under RFC 5378, shall have any effect and shall be null and void, whether published or posted by such Contributor, or included with or in such Contribution. Disclaimer of Validity All IETF Documents and the information contained therein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Full Copyright Statement 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 (http://trustee.ietf.org/license-info) in effect on the date of Ceccarelli & Zhang Expires April 2013 [Page 23] draft-cecczhang-ccamp-gmpls-g.709v3-lmp-00.txt October 2012 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. Ceccarelli & Zhang Expires April 2013 [Page 24]