idnits 2.17.1 draft-ceccarelli-ccamp-gmpls-g709-lmp-test-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 12, 2012) is 4305 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) == Missing Reference: 'LMP-NEG' is mentioned on line 381, but not defined == Unused Reference: 'ITUT-G.709' is defined on line 439, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ITUT-G.7714.1' Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group D. Ceccarelli 3 Internet-Draft D. Caviglia 4 Intended status: Standards Track F. Fondelli 5 Expires: January 13, 2013 Ericsson 6 F. Zhang 7 D. Li 8 Huawei Technologies 9 D. Beller 10 Alcatel-Lucent 11 July 12, 2012 13 Link Management Protocol (LMP) Test Messages Extensions for Evolutive 14 Optical Transport Networks (OTN) 15 draft-ceccarelli-ccamp-gmpls-g709-lmp-test-04 17 Abstract 19 This document specifies Link Management Protocol (LMP) extensions for 20 the support of enhanced Optical Transport Networks (OTN). In 21 particular it updates LMP test messages detailing the ITU-T G.709 OTN 22 technology specific information and extends them in order to cover 23 also recently introduced signal types and containers defined by the 24 ITU-T. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 13, 2013. 43 Copyright Notice 45 Copyright (c) 2012 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Verifying Link Connectivity . . . . . . . . . . . . . . . . . 3 63 3.1. Encoding Type . . . . . . . . . . . . . . . . . . . . . . 4 64 3.2. Verify Transport Mechanism . . . . . . . . . . . . . . . . 5 65 3.3. Transmission Rate . . . . . . . . . . . . . . . . . . . . 6 66 4. Trace Monitoring . . . . . . . . . . . . . . . . . . . . . . . 7 67 4.1. TRACE Object for evolutive OTN . . . . . . . . . . . . . . 7 68 4.2. Discovery Response Message for Layer Adjacency 69 Discovery . . . . . . . . . . . . . . . . . . . . . . . . 8 70 5. LMP Behavior Negotiation update . . . . . . . . . . . . . . . 9 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 72 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 76 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 79 1. Terminology 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in [RFC2119]. 85 2. Introduction 87 [RFC4204] defines the Link Management Protocol (LMP), which is a 88 protocol of the Generalized Multi-Protocol Label Switching (GMPLS) 89 [RFC3945] suite used to manage Traffic Engineering (TE) links. A TE 90 link may be made by multiple physical resources interconnecting Label 91 Switched Routers (LSRs), that are combined together for scalability 92 reasons. 94 Current definition of LMP consists of two mandatory procedures: 96 - Control channel management: used to maintain control channels 97 connectivity between adjacent LSRs. Such procedure is based on 98 the exchange of a message called Config message followed by a 99 lightweight keep-alive message exchange 101 - Link property correlation: used to combine multiple physical 102 links into a single TE link. 104 and two optional procedures: 106 - Link verification: used to verify the connectivity of the 107 physical links composing a TE link and to exchange their 108 Interface_Ids 110 - Fault management: used to suppress alarms and locate failures. 111 This feature may not be needed in G.709 networks because fault 112 management mechanisms are provided by the G.709 architecture. 114 This document defines G.709 technology specific information needed 115 when running LMP. In particular it is focused on link verification 116 and link property correlation functionalities and the G.709 test 117 procedures they are based on. Such procedures require the definition 118 of a G.709 specific TRACE object. After data links have been 119 verified, it is possible to group them into the TE links. 121 3. Verifying Link Connectivity 123 [RFC4204] defines a link verification procedure based on the in-band 124 transmission of Test messages over the data links. It is used to 125 verify the physical connectivity of such links, to discover data 126 plane resources and to exchange the Interface_Ids. It is also 127 possible to use a single procedure to verify multiple data links and 128 correlate the information collected by means of the Verify_Id 129 assigned to the procedure. 131 The link verification procedure works as follows: 133 - BeginVerify message: the local node sends a BeginVerify message 134 over a control channel. It includes a BEGIN_VERIFY object which 135 contains all the parameters characterizing the data link like, for 136 example, the number of data links that must be verified, the 137 transmission interval of the Test messages or the wavelength over 138 which the Test messages will be sent. 140 - BeginVerifyAck: if the remote node, upon receiving a BeginVerify 141 message, is ready to begin the procedure, it replies with a 142 BeginVerifyAck message. Such message specifies the desired 143 transport mechanism for the Test messages and the Verify_Id of the 144 procedure assigned by the remote node. 146 - Data link Testing: the local node, upon receiving the 147 BeginVerifyAck message, can begin testing the data links 148 repeatedly sending Test messages over them. The remote node will 149 reply either with a TestStatsSuccess or a TestStatusFailure for 150 each data link. As a consequence the local node will send a 151 TestStatusAck. 153 - End of testing: The local node can terminate the Test procedure 154 at anytime just sending an EndVerifyMessage towards the remote 155 node. 157 Evolutive OTNs need the support from LMP for the testing of all the 158 possible data links defined by ITU-T. This document provides, at 159 present, support to the data links defined by G.709 and G.709 160 amendment 3 recommendations and to G.Sup43 temporary document. 162 The BEGIN_VERIFY class is defined in Section 13.8 of [RFC4204]. The 163 following fields are extended: Encoding Type, Verify Transport 164 Mechanism and Transmission Rate. 166 3.1. Encoding Type 168 The Encoding Type identifies the type of encoding supported by the 169 interface. LMP encoding type is consistent with the LSP encoding 170 types defined for RSVP-TE [RFC3471]. In particular, the value to be 171 used for G.709 hierarchy ODU and OTU signals is "Digital Wrapper". 173 3.2. Verify Transport Mechanism 175 This field defines the transport mechanism for the Test messages and 176 its scope depends on each encoding type. It is a 16 bit mask set by 177 the local node where each bit identifies the various mechanisms it 178 can support for LMP test messages transmission. This document 179 defines the field values with respect to the G.709 digital encoding 180 (they are expressed in network byte order). 182 - 0x01 OTUk TTI: 64 byte Test Message 184 Capability of transmitting Test messages using OTUk Trail Trace 185 Identifier (TTI) overhead with frame length of 64 bytes. See ITU 186 G.709 Section 15.2 and Section 15.7 for the structure and 187 definition. The Test message is sent according to [RFC4204]. 189 - 0x02 ODUk TTI: 64 byte Test Message 191 Capability of transmitting Test messages using ODUk Trail Trace 192 Identifier (TTI) overhead with frame length of 64 bytes. See ITU 193 G.709 Section 15.2 and Section 15.8 for the structure and 194 definition. The Test message is sent according to [RFC4204]. 196 - 0x04 GCC0: Test Message over the GCC0 198 Capability of transmitting Test messages using the OTUk Overhead 199 General Communications Channel (GCC0). See ITU G.709 Section 15.7 200 for the structure and definition. The Test message is sent 201 according to [RFC4204] using bit-oriented HDLC framing format 202 [RFC1662]. 204 - 0x08 GCC1/2: Test Message over the GCC1/2 206 Capability of transmitting Test messages using the ODUk Overhead 207 General Communications Channels (GCC1/2). See ITU G.709 Section 208 15.8 for the structure and definition. The Test message is sent 209 according to [RFC4204] using bit-oriented HDLC framing format 210 [RFC1662]. 212 - 0x10 OTUk TTI - Section Trace Correlation 214 Capability of transmitting OTUk Trail Trace Identifier (TTI) as 215 defined in ITU-T G.709. The Test message is not transmitted using 216 the OTUk TTI overhead bytes (i.e. data link), but is sent over the 217 control channel and correlated for consistency to the received 218 pattern. The correlation between the Interface_Id and the in-band 219 pattern is achieved using the TRACE Object as defined in Section 4 220 of [RFC4207]. No modification to TestStatusSuccess or 221 TestStatusFailure messages is required. 223 - 0x20 ODUk TTI - Path Trace Correlation 225 Capability of transmitting ODUk Trail Trace Identifier (TTI) as 226 defined in ITU-T G.709. The Test message is not transmitted using 227 the OTUk TTI overhead bytes (i.e. data link), but is sent over the 228 control channel and correlated for consistency to the received 229 pattern. The correlation between the Interface_Id the Test 230 message is sent from and the pattern sent in-band is achieved 231 using the TRACE Object as defined in Section 4 of [RFC4207]. No 232 modification to TestStatusSuccess or TestStatusFailure messages is 233 required. 235 3.3. Transmission Rate 237 The transmission rate of the data links where the link verification 238 procedure can be performed is defined into the TransmissionRate field 239 of the BEGIN_VERIFY class ([RFC4204] Section 13.8). Values are 240 expressed in IEEE floating point format using a 32-bit number field 241 and expressed in bytes per second. The following table defines the 242 values to be used in OTNs: 244 +-------------+-----------------+-------------------+ 245 | Signal Type | Bit-rate (kbps) | Value (Bytes/Sec) | 246 +-------------+-----------------+-------------------+ 247 | ODU0 | 1 244 160 | 0x4D1450C0 | 248 +-------------+-----------------+-------------------+ 249 | ODU1 | 2 498 775 | 0x4D94F048 | 250 | OTU1 | 2 666 057 | 0x4D9EE8CD | 251 +-------------+-----------------+-------------------+ 252 | ODU2 | 10 037 274 | 0x4E959129 | 253 | OTU2 | 10 709 226 | 0x4E9F9475 | 254 +-------------+-----------------+-------------------+ 255 | ODU2e | 10 399 525 | 0x4E9AF70A | 256 +-------------+-----------------+-------------------+ 257 | ODU3 | 40 319 219 | 0X4F963367 | 258 | OTU3 | 43 018 416 | 0X4FA0418F | 259 +-------------+-----------------+-------------------+ 260 | ODU4 | 104 794 445 | 0x504331E3 | 261 | OTU4 | 111 809 973 | 0x50504326 | 262 +-------------+-----------------+-------------------+ 264 Transmission Rate values (Bytes/Sec) 266 4. Trace Monitoring 268 [RFC4207] describes the set of trace monitoring procedures that allow 269 a node to do trace monitoring by using the G.709 hierarchy 270 capabilities. 272 This document defines a new C-Type of the TRACE Object class used for 273 Trace Monitoring features as defined in [RFC4207]. 275 4.1. TRACE Object for evolutive OTN 277 The TRACE Object Class assigned by IANA is 21. A new C-Type is TBA 278 and value 2 is suggested. The TRACE Object format is the same as 279 defined in [RFC4207] and is shown in the following: 281 0 1 2 3 282 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 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 |N| C-Type | Class | Length | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | Trace Type | Trace Length | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | | 289 // Trace Message // 290 | | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 TRACE Object Class 295 Trace Type: 16 bits 297 The Trace Type field is used to identify the type of the trace 298 message. The following values are defined and all other values are 299 reserved and should be sent as zero and ignored on receipt. 301 1 = OTUk TTI 302 2 = ODUk TTI 303 3 = Level 1 ODUkT TTI 304 4 = Level 2 ODUkT TTI 305 5 = Level 3 ODUkT TTI 306 6 = Level 4 ODUkT TTI 307 7 = Level 5 ODUkT TTI 308 8 = Level 6 ODUkT TTI (default for layer adjacency discovery) 310 It shall be noted that an Amendment to ITU-T G.7714.1 has been 311 approved in September 2010 that defines an extension for OTN layer 312 adjacency discovery based on the ODUk TCM function (ODUkT) providing 313 6 TCM levels. By default the TCM level 6 SHALL be used. 315 Trace Length: 16 bits 317 Expresses the length of the trace message in bytes (as specified by 318 the Trace Type). 320 Trace Message: 322 This field includes the value of the expected message to be received 323 in-band. The valid length and value combinations are determined by 324 the ITU.T G.709 recommendation. The message MUST be padded with 325 zeros to a 32-bit boundary, if necessary. Trace Length does not 326 include padding zeroes. 328 This object is non negotiable. 330 4.2. Discovery Response Message for Layer Adjacency Discovery 332 ITU-T Recommendation G.7714.1 [ITUT-G.7714.1] describes an automatic 333 layer adjacency discovery procedure that can be applied to the ITU-T 334 G.709 OTN technology. The discovery message can be sent to the 335 adjacent node via the Trail Trace Identifier (TTI) and Appendix III 336 of G.7714.1 describes how the discovery response message can be sent 337 back to the originator of the discovery message (discovery agent in 338 G.7714.1 terminology) using the LMP protocol. 340 As defined in [ITUT-G.7714.1], the TraceMonitor message [RFC4207] is 341 used to convey the discovery response message. The following mapping 342 table shows how the discovery response message attributes are mapped 343 to TraceMonitor message objects or other fields of the LMP message 344 (see G.7714.1, section 11 for the description of the attributes): 346 | 347 G.7714.1 discovery response | TraceMonitor/LMP message field 348 message attribute | 349 ---------------------------------+---------------------------------------- 350 | : received discovery message 351 | 352 | : received discovery message 353 | 354 | IP source address in the IP header 355 | 356 | identical to 357 | 358 | 359 | 361 The received TTI, more specifically the discovery message in the SAPI 362 field contains the and the . 363 These attributes are included in the discovery response message by 364 copying the received TTI into the field of the TraceMonitor 365 message. 367 The IP address of the node sending the discovery response message 368 corresponds to the and is the IP source address in 369 the IP header of the LMP TraceMonitor message. 371 Typically, the Trail Connection Point (TCP-)IDs in transmit and 372 receive direction are identical for OTN equipment, i.e., the is identical to the . The 374 identifies the TCP on which the Discovery Message was received and 375 corresponds to the object in the TraceMonitor 376 message. 378 5. LMP Behavior Negotiation update 380 This docuemnt also introduces an update to the BehaviorConfig C-Type 381 defined in [LMP-NEG]. A new flag in the BehaviorConfig is needed for 382 the indication of the support for OTN Test Messages: 384 0 1 2 3 385 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 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 |S|D|C|O| Must Be Zero (MBZ) | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 - O: 1 bit 391 This bit indicates support for the TEST behavior of OTN 392 technology-specific defined in this document 394 6. Security Considerations 396 TBD 398 7. Acknowledgements 400 The authors would like to thank Attila Takacs, Andras Kern, Sergio 401 Belotti and Pietro Grandi for the kind review of the ID and the 402 valuable comments provided. 404 8. IANA Considerations 406 A new C-Type value for the Trace Object Class (21) is TBA by IANA. 408 9. References 410 9.1. Normative References 412 [ITUT-G.7714.1] 413 ITU-T, "Protocol for automatic discovery in SDH and OTN 414 networks, G.7714.1 Recommendation", April 2003. 416 [RFC1662] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662, 417 July 1994. 419 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 420 Requirement Levels", BCP 14, RFC 2119, March 1997. 422 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 423 (GMPLS) Signaling Functional Description", RFC 3471, 424 January 2003. 426 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching 427 (GMPLS) Architecture", RFC 3945, October 2004. 429 [RFC4204] Lang, J., "Link Management Protocol (LMP)", RFC 4204, 430 October 2005. 432 [RFC4207] Lang, J. and D. Papadimitriou, "Synchronous Optical 433 Network (SONET)/Synchronous Digital Hierarchy (SDH) 434 Encoding for Link Management Protocol (LMP) Test 435 Messages", RFC 4207, October 2005. 437 9.2. Informative References 439 [ITUT-G.709] 440 ITU-T, "Interface for the Optical Transport Network 441 (OTN)", G.709 Recommendation (and Amendment 1), 442 February 2001. 444 Authors' Addresses 446 Daniele Ceccarelli 447 Ericsson 448 Via E. Melen 77 449 Genova - Sestri Ponente 450 Italy 452 Email: daniele.ceccarelli@ericsson.com 454 Diego Caviglia 455 Ericsson 456 Via E. Melen 77 457 Genova - Sestri Ponente 458 Italy 460 Email: diego.caviglia@ericsson.com 462 Francesco Fondelli 463 Ericsson 464 Via Moruzzi 1 465 Pisa 466 Italy 468 Email: francesco.fondelli@ericsson.com 469 Fatai Zhang 470 Huawei Technologies 471 F3-5-B R&D Center, Huawei Base 472 Shenzhen 518129 P.R.China Bantian, Longgang District 473 Phone: +86-755-28972912 475 Email: zhangfatai@huawei.com 477 Dan Li 478 Huawei Technologies 479 F3-5-B R&D Center, Huawei Base 480 Shenzhen 518129 P.R.China Bantian, Longgang District 481 Phone: +86-755-28973237 483 Email: danli@huawei.com 485 Dieter Beller 486 Alcatel-Lucent 487 Lorenzstrasse 10 488 Stuttgart 70435 489 Germany 491 Email: dieter.beller@alcatel-lucent.com