CCAMP Working Group D. Papadimitriou Internet Draft Alcatel Document: draft-papadimitriou-ccamp-lmp-test-g709-00 Expires: April 2003 J. Lang Calient October 2002 G.709 Encoding for Link Management Protocol (LMP) Test messages draft-papadimitriou-ccamp-lmp-test-g709-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. 1. Abstract This document detail the G.709 Optical Transport Network technology specific information needed when sending Link Management Protocol (LMP) test messages. 2. 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 RFC-2119 [2]. In addition, the reader is assumed to be familiar with the terminology in ITU-T [ITUT-G709] as well as [LMP], [LMP-TEST] and D.Papadimitriou Internet Draft û Expires April 2003 1 draft-papadimitriou-ccamp-lmp-test-g709-00.txt Oct. 2002 [GMPLS-SIG]. Abbreviations used in this document are detailed in Appendix 1. 3. Introduction For scalability purposes, multiple physical resources that interconnect LSRs can be combined to form a single traffic engineering (TE) link for the purposes of path computation and signaling. These resources may represent one or more physical links that connect the LSRs, or they may represent a Label Switched Path (LSP) if LSP hierarchy [LSP-HIER] is used. The management of TE links is not restricted to in-band messaging, but instead can be done using out-of-band techniques. The Link Management Protocol (LMP) [LMP] is being developed as part of the Generalized MPLS (GMPLS) protocol suite to manage traffic engineering (TE) links. LMP currently consists of four main procedures, of which, the first two are mandatory and the last two are optional: 1. Control channel management 2. Link property correlation 3. Link verification 4. Fault management Control channel management is used to establish and maintain control channel connectivity between adjacent nodes. This is done using a Config message exchange followed by a lightweight keep-alive message exchange. Link property correlation is used to aggregate multiple data links into a single TE Link and to synchronize the link properties. Link verification is used to verify the physical connectivity of the data links and to exchange the Interface_Ids of the data links. Fault management is primarily used to suppress alarms and to localize failures in both opaque and transparent networks. When LMP is used with G.709, however, the fault management procedures may not be needed as existing G.709 mechanisms can be used. In this document, we define G.709 technology specific information needed when running LMP. Specifically, we define the G.709 test procedures used for Link verification and link property correlation. This requires a G.709 specific TRACE object that is defined in this document. Once the data links have been verified, they can be grouped to form TE links. 4. Verifying Link Connectivity In [LMP], a link verification procedure is defined whereby Test messages are transmitted in-band over the data links. This is used for data plane discovery, Interface_Id exchange (Interface_Ids are used in GMPLS signaling, either as port labels [GMPLS-SIG] or component link identifiers [MPLS-BDL], depending on the configuration), and physical connectivity verification. Multiple D.Papadimitriou Internet Draft û Expires April 2003 2 draft-papadimitriou-ccamp-lmp-test-g709-00.txt Oct. 2002 data links can be verified using a single verification procedure; the correlation is done using the Verify_Id that is assigned to the procedure. As part of the link verification procedure, a BeginVerify message exchange is used to agree upon parameters for the Test procedure. This can be initiated by sending a BeginVerify message over the control channel. This message includes a BEGIN_VERIFY object that contains a number of fields specifying, among other things, the transmission (bit) rate, encoding type, and transport mechanisms for the Test messages. If the remote node receives a BeginVerify message and is ready to begin the procedure, it sends a BeginVerifyAck message specifying the desired transport mechanism for the Test messages. The remote node also assigns a Verify_Id to the procedure and includes it in the BeginVerifyAck message. The transmission rate of the data link over which the Test messages will be transmitted is represented in IEEE floating point format using a 32-bit number field and expressed in bytes per second. These values are defined as follows: Signal Type Bit-rate (kbps) Value (Bytes/Sec) ----------- -------------- ---------------- ODU1 2 498 775 0x4D94F048 OTU1 2 666 057 0x4D9EE8CD ODU2 10 037 274 0x4E959129 OTU2 10 709 226 0x4E9F9475 ODU3 40 319 219 0x4F963367 OTU3 43 018 416 0x4FA0418F The encoding type identifies the encoding supported by an interface. The defined encoding is consistent with the LSP Encoding Type as defined in [GMPLS-SIG]. For G.709, this value must equal the value given for "G.709 Digital". The transport mechanism is defined using the Verify Transport Mechanism bit mask. The scope of this bit mask is restricted to the link encoding type. Multiple bits may be set when this field is included in the BeginVerify message; however, only one bit may be set when it is included in the BeginVerifyAck message. In the following subsection, we define the various options for Verify Transport Mechanism when the encoding is G.709 Digital. 4.1 Verify Transport Mechanism This field is 16 bits in length. In this document, we define the flags with respect to the G.709 digital encoding. Note that all values are defined in network byte order (i.e., big-endian byte order). D.Papadimitriou Internet Draft û Expires April 2003 3 draft-papadimitriou-ccamp-lmp-test-g709-00.txt Oct. 2002 0x01 OTUk TTI: 64 byte Test Message Capable 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 as defined in [LMP]. 0x02 ODUk TTI: 64 byte Test Message Capable 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 as defined in [LMP]. 0x04 GCC0: Test Message over the GCC0 Capable 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 as defined in [LMP] using bit-oriented HDLC framing format [RFC-1662]. 0x08 GCC1/2: Test Message over the GCC1/2 Capable 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 as defined in [LMP] using bit-oriented HDLC framing format [RFC-1662]. 0x10 OTUk TTI - Section Trace Correlation Capable 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., over the data link), but is sent over the control channel and correlated for consistency to the received pattern. In order to get the mapping between the Interface_Id for which the OTUk TTI Test message is sent and the pattern sent in-band, the transmitting node must provide the correlation between this pattern and the OTUk TTI Test message. This correlation is done using the TRACE object as defined in [LMP-TEST] Section 4. Note D.Papadimitriou Internet Draft û Expires April 2003 4 draft-papadimitriou-ccamp-lmp-test-g709-00.txt Oct. 2002 that no change is required for the TestStatusSuccess or TestStatusFailure messages. 0x20 ODUk TTI - Path Trace Correlation Capable 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., over the data link), but is sent over the control channel and correlated for consistency to the received pattern. In order to get the mapping between the Interface_Id for which the ODUk TTI Test message is sent and the pattern sent in-band, the transmitting node must provide the correlation between this pattern and the ODUk TTI Test message. This correlation is done using the TRACE object as defined in [LMP-TEST] Section 4. Note that no change is required for the TestStatusSuccess or TestStatusFailure messages. 5. Trace Monitoring The trace monitoring features described in [LMP-TEST] allow a node controlling the trace monitoring operations performed using the G.709 capabilities. The following section defines the new C-Type of the TRACE object class allowing for the Trace Monitoring capabilities as defined in [LMP-TEST]. Any other objects and messages as well as their corresponding processing are as defined [LMP-TEST]. 5.1 TRACE Object Class Class = TBA by IANA - C-Type = 2 û Format: 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 Type: 16 bits The type of the trace message. The following values are defined. All other values are reserved and should be sent as zero and ignored on receipt. D.Papadimitriou Internet Draft û Expires April 2003 5 draft-papadimitriou-ccamp-lmp-test-g709-00.txt Oct. 2002 1: OTUk TTI 2: ODUk TTI Trace Length: 16 bits This is the length in bytes of the trace message (as specified by the Trace Type). Trace Message: This is 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. 8. Security Considerations No new security considerations are introduced in this document in addition to [LMP]. 9. References 9.1 Normative References [ITUT-G709] ITU-T G.709 Recommendation, version 1.0 (and Amendment 1), æInterface for the Optical Transport Network (OTN)Æ, ITU-T, February 2001 (and October 2001). [ITUT-G798] ITU-T G.798 Recommendation, version 1.0, æCharacteristics of Optical Transport Network Hierarchy Equipment Functional BlocksÆ, ITU-T, October 2001. [ITUT-G872] ITU-T G.872 Recommendation, version 2.0, æArchitecture of Optical Transport NetworkÆ, ITU-T, October 2001. [GMPLS-ARCH] E.Mannie (Editor) et al., æGeneralized Multi-Protocol Label Switching (GMPLS) ArchitectureÆ, Internet Draft, Work in progress, draft-ietf-ccamp-gmpls-architecture- 03.txt, August 2002. [GMPLS-SIG] L.Berger (Editor) et al., æGeneralized MPLS - Signaling Functional DescriptionÆ, Internet Draft, Work in progress, draft-ietf-mpls-generalized- signaling-09.txt, August 2002. [GMPLS-G709] D.Papadimitriou (Editor) et al., æGeneralized Multiprotocol Label Switching Extensions for G.709 Optical Transport Network ControlÆ, Internet Draft, Work in progress, draft-ietf-ccamp-gmpls-g709-02.txt, September 2002. D.Papadimitriou Internet Draft û Expires April 2003 6 draft-papadimitriou-ccamp-lmp-test-g709-00.txt Oct. 2002 [LMP] J.Lang (Editor) et al., "Link Management Protocol (LMP)," Internet Draft, Work in progress, draft-ietf- ccamp-lmp-05.txt, September 2002. [LMP-TEST] J.Lang and D.Papadimitriou, "SONET/SDH Encoding for Link Management Protocol (LMP) Test messages", Internet Draft, Work in progress, draft-ietf-ccamp-lmp-test- sonet-sdh-00.txt, September 2002. [MPLS-BDL] K.Kompella, Y.Rekhter and L.Berger, "Link Bundling in MPLS Traffic Engineering," Work in progress, Internet Draft, draft-ietf-mpls-bundle-04.txt, August 2002. [RFC-1662] W.Simpson, Ed., "PPP in HDLC-like Framing", IETF RFC 1662, STD 51, July 1994. [RFC-2119] S.Bradner, "Key words for use in RFCs to Indicate Requirement Levels," RFC 2119. 9.2 Informative References [MPLS-HIER] Kompella, K., Rekhter, Y., " LSP Hierarchy with Generalized MPLS TE," (work in progress). 10. Acknowledgments The authors would like to thank Bernard Sales, Emmanuel Desmet, Gert Grammel, Jim Jones, Stefan Ansorge, and James Scott for their many contributions to this document. 11. Author's Addresses Dimitri Papadimitriou (Alcatel) Francis Wellesplein 1, B-2018 Antwerpen, Belgium Phone: +32 3 240-8491 Email: dimitri.papadimitriou@alcatel.be Jonathan P. Lang (Calient Networks) 25 Castilian, Goleta, CA 93117, USA Email: jplang@calient.net Appendix 1 û Abbreviations BSNT Bit Stream without Octet Timing BSOT Bit Stream with Octet Timing CBR Constant Bit Rate FC Fiber Channel FEC Forward Error Correction FSC Fiber Switch Capable GCC General Communication Channel GFP Generic Framing Procedure D.Papadimitriou Internet Draft û Expires April 2003 7 draft-papadimitriou-ccamp-lmp-test-g709-00.txt Oct. 2002 LSC Lambda Switch Capable LSP Label Switched Path MS Multiplex Section naOH non-associated Overhead NMC Number of Multiplexed Components NVC Number of Virtual Components OCC Optical Channel Carrier OCG Optical Carrier Group OCh Optical Channel (with full functionality) OChr Optical Channel (with reduced functionality) ODTUG Optical Date Tributary Unit Group ODU Optical Channel Data Unit OH Overhead OMS Optical Multiplex Section OMU Optical Multiplex Unit OOS OTM Overhead Signal OPS Optical Physical Section OPU Optical Channel Payload Unit OSC Optical Supervisory Channel OTH Optical transport hierarchy OTM Optical transport module OTN Optical transport network OTS Optical transmission section OTU Optical Channel Transport Unit OTUkV Functionally Standardized OTUk PPP Point to Point Protocol PSC Packet Switch Capable RES Reserved RS Regenerator Section TDM Time Division Multiplex TTI Trail Trace Identifier D.Papadimitriou Internet Draft û Expires April 2003 8 draft-papadimitriou-ccamp-lmp-test-g709-00.txt Oct. 2002 Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. D.Papadimitriou Internet Draft û Expires April 2003 9