idnits 2.17.1 draft-papadimitriou-ccamp-lmp-test-g709-00.txt: ** The Abstract section seems to be numbered -(298): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 23 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 8 longer pages, the longest (page 4) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2002) is 7864 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 19 -- Looks like a reference, but probably isn't: '2' on line 46 == Missing Reference: 'LSP-HIER' is mentioned on line 62, but not defined == Unused Reference: 'ITUT-G798' is defined on line 297, but no explicit reference was found in the text == Unused Reference: 'ITUT-G872' is defined on line 301, but no explicit reference was found in the text == Unused Reference: 'GMPLS-ARCH' is defined on line 304, but no explicit reference was found in the text == Unused Reference: 'GMPLS-G709' is defined on line 314, but no explicit reference was found in the text == Unused Reference: 'RFC-2119' is defined on line 338, but no explicit reference was found in the text == Unused Reference: 'MPLS-HIER' is defined on line 343, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ITUT-G709' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITUT-G798' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITUT-G872' == Outdated reference: A later version (-07) exists of draft-ietf-ccamp-gmpls-architecture-03 == Outdated reference: A later version (-09) exists of draft-ietf-ccamp-gmpls-g709-02 == Outdated reference: A later version (-10) exists of draft-ietf-ccamp-lmp-05 == Outdated reference: A later version (-04) exists of draft-ietf-ccamp-lmp-test-sonet-sdh-00 == Outdated reference: A later version (-06) exists of draft-ietf-mpls-bundle-04 Summary: 4 errors (**), 0 flaws (~~), 15 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group D. Papadimitriou 3 Internet Draft Alcatel 4 Document: draft-papadimitriou-ccamp-lmp-test-g709-00 5 Expires: April 2003 J. Lang 6 Calient 8 October 2002 10 G.709 Encoding for Link Management Protocol (LMP) 11 Test messages 13 draft-papadimitriou-ccamp-lmp-test-g709-00.txt 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026 [1]. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. Internet-Drafts are draft documents valid for a maximum of 24 six months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet- Drafts 26 as reference material or to cite them other than as "work in 27 progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 1. Abstract 37 This document detail the G.709 Optical Transport Network technology 38 specific information needed when sending Link Management Protocol 39 (LMP) test messages. 41 2. Conventions used in this document 43 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 44 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 45 this document are to be interpreted as described in RFC-2119 [2]. 47 In addition, the reader is assumed to be familiar with the 48 terminology in ITU-T [ITUT-G709] as well as [LMP], [LMP-TEST] and 50 D.Papadimitriou Internet Draft � Expires April 2003 1 52 [GMPLS-SIG]. Abbreviations used in this document are detailed in 53 Appendix 1. 55 3. Introduction 57 For scalability purposes, multiple physical resources that 58 interconnect LSRs can be combined to form a single traffic 59 engineering (TE) link for the purposes of path computation and 60 signaling. These resources may represent one or more physical links 61 that connect the LSRs, or they may represent a Label Switched Path 62 (LSP) if LSP hierarchy [LSP-HIER] is used. The management of TE 63 links is not restricted to in-band messaging, but instead can be 64 done using out-of-band techniques. 66 The Link Management Protocol (LMP) [LMP] is being developed as part 67 of the Generalized MPLS (GMPLS) protocol suite to manage traffic 68 engineering (TE) links. LMP currently consists of four main 69 procedures, of which, the first two are mandatory and the last two 70 are optional: 72 1. Control channel management 73 2. Link property correlation 74 3. Link verification 75 4. Fault management 77 Control channel management is used to establish and maintain control 78 channel connectivity between adjacent nodes. This is done using a 79 Config message exchange followed by a lightweight keep-alive message 80 exchange. Link property correlation is used to aggregate multiple 81 data links into a single TE Link and to synchronize the link 82 properties. Link verification is used to verify the physical 83 connectivity of the data links and to exchange the Interface_Ids of 84 the data links. Fault management is primarily used to suppress 85 alarms and to localize failures in both opaque and transparent 86 networks. When LMP is used with G.709, however, the fault management 87 procedures may not be needed as existing G.709 mechanisms can be 88 used. 90 In this document, we define G.709 technology specific information 91 needed when running LMP. Specifically, we define the G.709 test 92 procedures used for Link verification and link property correlation. 93 This requires a G.709 specific TRACE object that is defined in this 94 document. Once the data links have been verified, they can be 95 grouped to form TE links. 97 4. Verifying Link Connectivity 99 In [LMP], a link verification procedure is defined whereby Test 100 messages are transmitted in-band over the data links. This is used 101 for data plane discovery, Interface_Id exchange (Interface_Ids are 102 used in GMPLS signaling, either as port labels [GMPLS-SIG] or 103 component link identifiers [MPLS-BDL], depending on the 104 configuration), and physical connectivity verification. Multiple 106 D.Papadimitriou Internet Draft � Expires April 2003 2 107 data links can be verified using a single verification procedure; 108 the correlation is done using the Verify_Id that is assigned to the 109 procedure. 111 As part of the link verification procedure, a BeginVerify message 112 exchange is used to agree upon parameters for the Test procedure. 113 This can be initiated by sending a BeginVerify message over the 114 control channel. This message includes a BEGIN_VERIFY object that 115 contains a number of fields specifying, among other things, the 116 transmission (bit) rate, encoding type, and transport mechanisms for 117 the Test messages. If the remote node receives a BeginVerify message 118 and is ready to begin the procedure, it sends a BeginVerifyAck 119 message specifying the desired transport mechanism for the Test 120 messages. The remote node also assigns a Verify_Id to the procedure 121 and includes it in the BeginVerifyAck message. 123 The transmission rate of the data link over which the Test messages 124 will be transmitted is represented in IEEE floating point format 125 using a 32-bit number field and expressed in bytes per second. These 126 values are defined as follows: 128 Signal Type Bit-rate (kbps) Value (Bytes/Sec) 129 ----------- -------------- ---------------- 130 ODU1 2 498 775 0x4D94F048 131 OTU1 2 666 057 0x4D9EE8CD 132 ODU2 10 037 274 0x4E959129 133 OTU2 10 709 226 0x4E9F9475 134 ODU3 40 319 219 0x4F963367 135 OTU3 43 018 416 0x4FA0418F 137 The encoding type identifies the encoding supported by an interface. 138 The defined encoding is consistent with the LSP Encoding Type as 139 defined in [GMPLS-SIG]. For G.709, this value must equal the value 140 given for "G.709 Digital". 142 The transport mechanism is defined using the Verify Transport 143 Mechanism bit mask. The scope of this bit mask is restricted to the 144 link encoding type. Multiple bits may be set when this field is 145 included in the BeginVerify message; however, only one bit may be 146 set when it is included in the BeginVerifyAck message. 148 In the following subsection, we define the various options for 149 Verify Transport Mechanism when the encoding is G.709 Digital. 151 4.1 Verify Transport Mechanism 153 This field is 16 bits in length. 155 In this document, we define the flags with respect to the G.709 156 digital encoding. Note that all values are defined in network byte 157 order (i.e., big-endian byte order). 159 D.Papadimitriou Internet Draft � Expires April 2003 3 160 0x01 OTUk TTI: 64 byte Test Message 162 Capable of transmitting Test messages using OTUk Trail Trace 163 Identifier (TTI) overhead with frame length of 64 bytes. See 164 ITU G.709 Section 15.2 and Section 15.7 for the structure and 165 definition. 167 The Test message is sent as defined in [LMP]. 169 0x02 ODUk TTI: 64 byte Test Message 171 Capable of transmitting Test messages using ODUk Trail Trace 172 Identifier (TTI) overhead with frame length of 64 bytes. See 173 ITU G.709 Section 15.2 and Section 15.8 for the structure and 174 definition. 176 The Test message is sent as defined in [LMP]. 178 0x04 GCC0: Test Message over the GCC0 180 Capable of transmitting Test messages using the OTUk Overhead 181 General Communications Channel (GCC0). See ITU G.709 Section 182 15.7 for the structure and definition. 184 The Test message is sent as defined in [LMP] using bit-oriented 185 HDLC framing format [RFC-1662]. 187 0x08 GCC1/2: Test Message over the GCC1/2 189 Capable of transmitting Test messages using the ODUk Overhead 190 General Communications Channels (GCC1/2). See ITU G.709 Section 191 15.8 for the structure and definition. 193 The Test message is sent as defined in [LMP] using bit-oriented 194 HDLC framing format [RFC-1662]. 196 0x10 OTUk TTI - Section Trace Correlation 198 Capable of transmitting OTUk Trail Trace Identifier (TTI) as 199 defined in ITU-T G.709. 201 The Test message is not transmitted using the OTUk TTI overhead 202 bytes (i.e., over the data link), but is sent over the control 203 channel and correlated for consistency to the received pattern. 205 In order to get the mapping between the Interface_Id for which 206 the OTUk TTI Test message is sent and the pattern sent in-band, 207 the transmitting node must provide the correlation between this 208 pattern and the OTUk TTI Test message. This correlation is done 209 using the TRACE object as defined in [LMP-TEST] Section 4. Note 211 D.Papadimitriou Internet Draft � Expires April 2003 4 212 that no change is required for the TestStatusSuccess or 213 TestStatusFailure messages. 215 0x20 ODUk TTI - Path Trace Correlation 217 Capable of transmitting ODUk Trail Trace Identifier (TTI) as 218 defined in ITU-T G.709. 220 The Test message is not transmitted using the OTUk TTI overhead 221 bytes (i.e., over the data link), but is sent over the control 222 channel and correlated for consistency to the received pattern. 224 In order to get the mapping between the Interface_Id for which 225 the ODUk TTI Test message is sent and the pattern sent in-band, 226 the transmitting node must provide the correlation between this 227 pattern and the ODUk TTI Test message. This correlation is done 228 using the TRACE object as defined in [LMP-TEST] Section 4. Note 229 that no change is required for the TestStatusSuccess or 230 TestStatusFailure messages. 232 5. Trace Monitoring 234 The trace monitoring features described in [LMP-TEST] allow a node 235 controlling the trace monitoring operations performed using the 236 G.709 capabilities. 238 The following section defines the new C-Type of the TRACE object 239 class allowing for the Trace Monitoring capabilities as defined in 240 [LMP-TEST]. Any other objects and messages as well as their 241 corresponding processing are as defined [LMP-TEST]. 243 5.1 TRACE Object Class 245 Class = TBA by IANA - C-Type = 2 � Format: 247 0 1 2 3 248 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 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 |N| C-Type | Class | Length | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Trace Type | Trace Length | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | | 255 // Trace Message // 256 | | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 Trace Type: 16 bits 261 The type of the trace message. The following values are 262 defined. All other values are reserved and should be sent as 263 zero and ignored on receipt. 265 D.Papadimitriou Internet Draft � Expires April 2003 5 266 1: OTUk TTI 267 2: ODUk TTI 269 Trace Length: 16 bits 271 This is the length in bytes of the trace message (as specified 272 by the Trace Type). 274 Trace Message: 276 This is the value of the expected message to be received in- 277 band. The valid length and value combinations are determined by 278 the ITU-T G.709 recommendation. The message MUST be padded with 279 zeros to a 32-bit boundary, if necessary. Trace Length does not 280 include padding zeroes. 282 This object is non-negotiable. 284 8. Security Considerations 286 No new security considerations are introduced in this document in 287 addition to [LMP]. 289 9. References 291 9.1 Normative References 293 [ITUT-G709] ITU-T G.709 Recommendation, version 1.0 (and Amendment 294 1), �Interface for the Optical Transport Network 295 (OTN)�, ITU-T, February 2001 (and October 2001). 297 [ITUT-G798] ITU-T G.798 Recommendation, version 1.0, 298 �Characteristics of Optical Transport Network Hierarchy 299 Equipment Functional Blocks�, ITU-T, October 2001. 301 [ITUT-G872] ITU-T G.872 Recommendation, version 2.0, �Architecture 302 of Optical Transport Network�, ITU-T, October 2001. 304 [GMPLS-ARCH] E.Mannie (Editor) et al., �Generalized Multi-Protocol 305 Label Switching (GMPLS) Architecture�, Internet Draft, 306 Work in progress, draft-ietf-ccamp-gmpls-architecture- 307 03.txt, August 2002. 309 [GMPLS-SIG] L.Berger (Editor) et al., �Generalized MPLS 310 - Signaling Functional Description�, Internet Draft, 311 Work in progress, draft-ietf-mpls-generalized- 312 signaling-09.txt, August 2002. 314 [GMPLS-G709] D.Papadimitriou (Editor) et al., �Generalized 315 Multiprotocol Label Switching Extensions for G.709 316 Optical Transport Network Control�, Internet Draft, 317 Work in progress, draft-ietf-ccamp-gmpls-g709-02.txt, 318 September 2002. 320 D.Papadimitriou Internet Draft � Expires April 2003 6 322 [LMP] J.Lang (Editor) et al., "Link Management Protocol 323 (LMP)," Internet Draft, Work in progress, draft-ietf- 324 ccamp-lmp-05.txt, September 2002. 326 [LMP-TEST] J.Lang and D.Papadimitriou, "SONET/SDH Encoding for 327 Link Management Protocol (LMP) Test messages", Internet 328 Draft, Work in progress, draft-ietf-ccamp-lmp-test- 329 sonet-sdh-00.txt, September 2002. 331 [MPLS-BDL] K.Kompella, Y.Rekhter and L.Berger, "Link Bundling in 332 MPLS Traffic Engineering," Work in progress, Internet 333 Draft, draft-ietf-mpls-bundle-04.txt, August 2002. 335 [RFC-1662] W.Simpson, Ed., "PPP in HDLC-like Framing", IETF RFC 336 1662, STD 51, July 1994. 338 [RFC-2119] S.Bradner, "Key words for use in RFCs to Indicate 339 Requirement Levels," RFC 2119. 341 9.2 Informative References 343 [MPLS-HIER] Kompella, K., Rekhter, Y., " LSP Hierarchy with 344 Generalized MPLS TE," (work in progress). 346 10. Acknowledgments 348 The authors would like to thank Bernard Sales, Emmanuel Desmet, Gert 349 Grammel, Jim Jones, Stefan Ansorge, and James Scott for their many 350 contributions to this document. 352 11. Author's Addresses 354 Dimitri Papadimitriou (Alcatel) 355 Francis Wellesplein 1, 356 B-2018 Antwerpen, Belgium 357 Phone: +32 3 240-8491 358 Email: dimitri.papadimitriou@alcatel.be 360 Jonathan P. Lang (Calient Networks) 361 25 Castilian, Goleta, CA 93117, USA 362 Email: jplang@calient.net 364 Appendix 1 � Abbreviations 366 BSNT Bit Stream without Octet Timing 367 BSOT Bit Stream with Octet Timing 368 CBR Constant Bit Rate 369 FC Fiber Channel 370 FEC Forward Error Correction 371 FSC Fiber Switch Capable 372 GCC General Communication Channel 373 GFP Generic Framing Procedure 375 D.Papadimitriou Internet Draft � Expires April 2003 7 376 LSC Lambda Switch Capable 377 LSP Label Switched Path 378 MS Multiplex Section 379 naOH non-associated Overhead 380 NMC Number of Multiplexed Components 381 NVC Number of Virtual Components 382 OCC Optical Channel Carrier 383 OCG Optical Carrier Group 384 OCh Optical Channel (with full functionality) 385 OChr Optical Channel (with reduced functionality) 386 ODTUG Optical Date Tributary Unit Group 387 ODU Optical Channel Data Unit 388 OH Overhead 389 OMS Optical Multiplex Section 390 OMU Optical Multiplex Unit 391 OOS OTM Overhead Signal 392 OPS Optical Physical Section 393 OPU Optical Channel Payload Unit 394 OSC Optical Supervisory Channel 395 OTH Optical transport hierarchy 396 OTM Optical transport module 397 OTN Optical transport network 398 OTS Optical transmission section 399 OTU Optical Channel Transport Unit 400 OTUkV Functionally Standardized OTUk 401 PPP Point to Point Protocol 402 PSC Packet Switch Capable 403 RES Reserved 404 RS Regenerator Section 405 TDM Time Division Multiplex 406 TTI Trail Trace Identifier 408 D.Papadimitriou Internet Draft � Expires April 2003 8 409 Full Copyright Statement 411 "Copyright (C) The Internet Society (date). All Rights Reserved. 412 This document and translations of it may be copied and furnished to 413 others, and derivative works that comment on or otherwise explain it 414 or assist in its implmentation may be prepared, copied, published 415 and distributed, in whole or in part, without restriction of any 416 kind, provided that the above copyright notice and this paragraph 417 are included on all such copies and derivative works. However, this 418 document itself may not be modified in any way, such as by removing 419 the copyright notice or references to the Internet Society or other 420 Internet organizations, except as needed for the purpose of 421 developing Internet standards in which case the procedures for 422 copyrights defined in the Internet Standards process must be 423 followed, or as required to translate it into languages other than 424 English. 426 The limited permissions granted above are perpetual and will not be 427 revoked by the Internet Society or its successors or assigns. 429 This document and the information contained herein is provided on an 430 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 431 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 432 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 433 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 434 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 436 D.Papadimitriou Internet Draft � Expires April 2003 9