idnits 2.17.1 draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt: 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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (December 2003) is 7436 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: 'RFC 3471' is mentioned on line 152, but not defined == Unused Reference: 'RFC3471' is defined on line 642, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'BUNDLE' -- Possible downref: Non-RFC (?) normative reference: ref. 'G.707' -- Possible downref: Non-RFC (?) normative reference: ref. 'LMP' Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J.P. Lang 3 Internet Draft (Rincon Networks) 4 Category: Standards Track 5 Expires: June 2004 D. Papadimitriou 6 (Alcatel) 8 December 2003 10 SONET/SDH Encoding for Link Management 11 Protocol (LMP) Test messages 13 draft-ietf-ccamp-lmp-test-sonet-sdh-04.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. 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. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 This document details the Synchronous Optical NETwork (SONET)/ 39 Synchronous Digital Hierarchy (SDH) technology specific information 40 needed when sending Link Management Protocol (LMP) test messages. 42 [Editor's note: "Changes from previous version" notes can be removed 43 prior to publication as an RFC.] 45 Changes from previous version: 47 o Modified the IANA Considerations section as a result of IESG 48 review. 50 1. Introduction 52 For scalability purposes, multiple physical resources that 53 interconnect LSRs can be combined to form a single traffic 54 engineering (TE) link for the purposes of path computation and 55 signaling. These resources may represent one or more physical links 56 that connect the LSRs, or they may represent a Label Switched Path 57 (LSP) if LSP hierarchy [LSP-HIER] is used. The management of TE 58 links is not restricted to in-band messaging, but instead can be 59 done using out-of-band techniques. 61 The Link Management Protocol (LMP) [LMP] has been developed as part 62 of the Generalized MPLS (GMPLS) protocol suite to manage Traffic 63 Engineering (TE) links. LMP currently consists of four main 64 procedures, of which, the first two are mandatory and the last two 65 are optional: 67 1. Control channel management 68 2. Link property correlation 69 3. Link verification 70 4. Fault management 72 Control channel management is used to establish and maintain control 73 channel connectivity between adjacent nodes. This is done using a 74 Config message exchange followed by a lightweight keep-alive message 75 exchange. Link property correlation is used to aggregate multiple 76 data links into a single TE Link and to synchronize the link 77 properties. Link verification is used to verify the physical 78 connectivity of the data links and to exchange the Interface_Ids of 79 the data links. Fault management is primarily used to suppress 80 alarms and to localize failures in both opaque and transparent 81 networks. When LMP is used with SONET/SDH, however, the fault 82 management procedures may not be needed as existing SONET/SDH 83 mechanisms can be used. 85 In this document, the SONET/SDH technology specific information for 86 LMP is defined. Specifically, the SONET/SDH test procedures used for 87 Link verification and link property correlation are detailed. These 88 procedures include the trace correlation transport mechanism 89 (defined for J0, J1, J2) that supports a separation of the transport 90 and control plane identifiers. This requires a new trace monitoring 91 function that is also discussed in this document. Once the data 92 links have been verified, they can be grouped to form TE links. 94 2. Terminology 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in [RFC2119]. 100 The reader is assumed to be familiar with the terminology in [LMP], 101 [G.707], and [T1.105]. The following abbreviations are used in this 102 document: 104 CRC-N: Cyclic Redundancy Check-N. 105 DCC: Data communications channel. 106 LOVC: Lower order virtual container 107 HOVC: Higher order virtual container 108 MS: Multiplex section. 109 MSOH: Multiplex section overhead. 110 POH: Path overhead. 111 RS: Regenerator section. 112 RSOH: Regenerator section overhead. 113 SDH: Synchronous digital hierarchy. 114 SOH: Section overhead. 115 SONET: Synchronous Optical Network. 116 STM(-N): Synchronous Transport Module (-N) (SDH). 117 STS(-N): Synchronous Transport Signal-Level N (SONET). 118 VC-n: Virtual Container-n (SDH). 119 VTn: Virtual Tributary-n (SONET). 121 3. Verifying Link Connectivity 123 In [LMP], a link verification procedure is defined whereby Test 124 messages are transmitted in-band over the data links. This is used 125 for data plane discovery, Interface_Id exchange (Interface_Ids are 126 used in GMPLS signaling, either as port labels [RFC 3471] or 127 component link identifiers [BUNDLE], depending on the 128 configuration), and physical connectivity verification. Multiple 129 data links can be verified using a single verification procedure; 130 the correlation is done using the Verify_Id that is assigned to the 131 procedure. 133 As part of the link verification procedure, a BeginVerify message 134 exchange is used to agree upon parameters for the Test procedure. 135 This can be initiated by sending a BeginVerify message over the 136 control channel. This message includes a BEGIN_VERIFY object that 137 contains a number of fields specifying, among other things, the 138 transmission (bit) rate, encoding type, and transport mechanisms for 139 the Test messages. If the remote node receives a BeginVerify message 140 and is ready to begin the procedure, it sends a BeginVerifyAck 141 message specifying the desired transport mechanism for the Test 142 messages. The remote node also assigns a Verify_Id to the procedure 143 and includes it in the BeginVerifyAck message. 145 The transmission rate of the data link over which the Test messages 146 will be transmitted is represented in IEEE floating point format 147 using a 32-bit number field and expressed in bytes per second. See 148 [RFC 3471] for values defined for SONET/SDH. 150 The encoding type identifies the encoding supported by an interface. 151 The defined encoding is consistent with the LSP Encoding Type as 152 defined in [RFC 3471]. For SONET/SDH, this value must equal the 153 value given for "SDH ITU-T G.707/ SONET ANSI T1.105". 155 The transport mechanism is defined using the Verify Transport 156 Mechanism bit mask. The scope of this bit mask is restricted to the 157 link encoding type. Multiple bits may be set when this field is 158 included in the BeginVerify message; however, only one bit may be 159 set when it is included in the BeginVerifyAck message. 161 In the following subsection, the various options for Verify 162 Transport Mechanism are defined when the encoding is SONET/SDH. The 163 trace correlation transport mechanism (defined for J0, J1, J2) 164 supports a separation of the transport and control plane 165 identifiers. 167 3.1. Verify Transport Mechanism 169 This field is 16 bits in length. 171 In this document, the flags for SONET/SDH encoding are defined. 172 Note that all values are defined in network byte order (i.e., big- 173 endian byte order). 175 0x0001 : Reserved 177 0x0002 DCCS: Test Message over the Section/RS DCC 179 Capable of transmitting Test messages using the DCC 180 Section/RS Overhead bytes with bit-oriented HDLC 181 framing format [RFC1662]. 183 The Test message is sent as defined in [LMP]. 185 0x0004 DCCL: Test Message over the Line/MS DCC 187 Capable of transmitting Test messages using the DCC 188 Line/MS Overhead bytes with bit-oriented HDLC framing 189 format [RFC1662]. 191 The Test message is sent as defined in [LMP]. 193 0x0008 J0-trace: J0 Section Trace Correlation 194 Capable of transmitting SONET/SDH Section/RS trace over 195 J0 Section/RS overhead byte as defined in ANSI 196 T1.105/ITU-T G.707. 198 The Test message is not transmitted using the J0 bytes 199 (i.e., over the data link), but is sent over the 200 control channel and correlated for consistency to the 201 received J0 pattern. 203 In order to get the mapping between the Interface_Id 204 over which the J0 test message is sent and the J0 205 pattern sent in-band, the transmitting node must 206 provide the correlation between this pattern and the J0 207 test message. This correlation is done using the TRACE 208 object as defined in Section 4. 210 The format of the test message is as follows: 212 ::= 213 215 0x0010: Reserved 217 0x0020: Reserved 219 0x0040 J1-trace: J1 Path Trace Correlation 221 Capable of transmitting SONET/SDH STS SPE/HOVC Path 222 trace over J1 Path overhead byte as defined in [T1.105] 223 and [G.707]. 225 The Test message is not transmitted using the J1 bytes 226 (i.e., over the data link), but is sent over the 227 control channel and correlated for consistency to the 228 received J1 pattern. 230 In order to get the mapping between the Interface_Id 231 over which the J1 test message is sent and the J1 232 pattern sent in-band, the transmitting node must 233 provide the correlation between this pattern and the J1 234 test message. This correlation is done using the TRACE 235 object as defined in Section 4. 237 The Test Message format is identical to that defined 238 above in J0-trace. 240 0x0080 J2-trace: J2 Section Trace Correlation 242 Capable of transmitting SONET/SDH VT SPE/LOVC Path 243 trace over J2 Path overhead byte as defined in [T1.105] 244 and [G.707]. 246 The Test message is not transmitted using the J2 bytes 247 (i.e., over the data link), but is sent over the 248 control channel and correlated for consistency to the 249 received J2 pattern. 251 In order to get the mapping between the Interface_Id 252 over which the J2 test message is sent and the J2 253 pattern sent in-band, the transmitting node must 254 provide the correlation between this pattern and the J2 255 test message. This correlation is done using the TRACE 256 object as defined in Section 4. 258 The Test Message format is identical to that defined 259 above in J0-trace. 261 4. Trace Monitoring 263 The trace monitoring features described in this section allow a node 264 to do trace monitoring by using the SONET/SDH capabilities. 266 o A node may request its neighbor (the remote node) to monitor 267 a link for a specific pattern in the overhead using the 268 TraceMonitor Message. An example of this overhead is the 269 SONET Section Trace message transmitted in the J0 byte. If 270 the actual trace message does not match the expected trace 271 message, the remote node MUST report the mismatch condition. 273 o A node may request the value of the current trace message on 274 a given data link using the TraceReq Message. 276 o A node may request a remote node to send a specific trace 277 message over a data link using the InsertTrace Message. 279 4.1.1. TraceMonitor Message 281 The TraceMonitor message (Message Type TBA by IANA) is sent over the 282 control channel and is used to request the remote node to monitor a 283 data link for a specific trace value. This value is inserted in the 284 object. The format of the TraceMonitor message is as 285 follows: 287 ::= 288 290 The above transmission order SHOULD be followed. 292 The remote node MUST respond to a TraceMonitor message with either a 293 TraceMonitorAck or TraceMonitorNack Message. 295 4.1.1.1. TRACE Object Class 297 Class = TBA by IANA. 299 o C-Type = 1, Trace 301 0 1 2 3 302 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 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 |N| C-Type | Class | Length | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | Trace Type | Trace Length | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | | 309 // Trace Message // 310 | | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 Trace Type: 16 bits 315 The type of the trace message. The following values are 316 defined. All other values are reserved. 318 1 = SONET Section Trace (J0 Byte) 319 2 = SONET Path Trace (J1 Byte) 320 3 = SONET Path Trace (J2 Byte) 321 4 = SDH Section Trace (J0 Byte) 322 5 = SDH Path Trace (J1 Byte) 323 6 = SDH Path Trace (J2 Byte) 325 Trace Length: 16 bits 327 This is the length in bytes of the trace message (as specified 328 by the Trace Type). 330 Trace Message: 332 This is the value of the expected message to be received in- 333 band. The valid length and value combinations are determined by 334 the specific technology: for SONET see [T1.105] and for SDH see 335 [G.707]. The message MUST be padded with zeros to a 32-bit 336 boundary, if necessary. Trace Length does not include padding 337 zeroes. 339 This object is non-negotiable. 341 4.1.2. TraceMonitorAck Message 343 The TraceMonitorAck message (Message Type TBA by IANA) is used to 344 acknowledge receipt of the TraceMonitor message and indicate that 345 all of the TRACE Objects in the TraceMonitor message have been 346 received and processed correctly (i.e. no Trace Mismatch). 348 The format is as follows: 350 ::= 352 The above transmission order SHOULD be followed. 354 The MESSAGE_ID_ACK object is defined in [LMP]. The contents of the 355 MESSAGE_ID_ACK object MUST be obtained from the TraceMonitor message 356 being acknowledged. 358 4.1.3. TraceMonitorNack Message 360 The TraceMonitorNack message (Message Type TBA by IANA) is used to 361 acknowledge receipt of the TraceMonitor message and indicate that 362 the TRACE Object in the TraceMonitor message was not processed 363 correctly. This could be because the trace monitoring requested is 364 not supported or there was an error in the TRACE object value(s). 366 The format is as follows: 368 ::= 369 371 The above transmission order SHOULD be followed. 373 The MESSAGE_ID_ACK and ERROR_CODE objects are defined in [LMP]. The 374 contents of the MESSAGE_ID_ACK object MUST be obtained from the 375 TraceMonitor message being acknowledged. 377 If the Trace type is not supported, the ERROR_CODE MUST indicate, 378 "Unsupported Trace Type" defined in Section 4.1.3.1. 380 If the TRACE object was not equal to the value seen in the trace, 381 the TraceMonitorNack message MUST include the ERROR_CODE indicating, 382 "Invalid Trace Message". The TraceMismatch message (see Section 383 4.1.4) SHOULD NOT be sent as a result of the mismatch. 385 The TraceMonitorNack message uses a new ERROR_CODE C-Type defined in 386 Section 4.1.3.1. 388 4.1.3.1. ERROR_CODE Class 390 C-Type = TBA by IANA, TRACE_ERROR 392 The following new error code bit-values are defined: 394 0x01 = Unsupported Trace Type 395 0x02 = Invalid Trace Message 397 All other values are Reserved. 399 Multiple bits may be set to indicate multiple errors. 401 This Object is non-negotiable. 403 4.1.4. TraceMismatch Message 405 The TraceMismatch message (Message Type TBA by IANA) is sent over 406 the control channel and is used to report a trace mismatch on a data 407 link for which trace monitoring was requested. The format is as 408 follows: 410 ::= 411 412 [ ...] 414 The above transmission order SHOULD be followed. 416 A neighboring node that receives a TraceMismatch message MUST 417 respond with a TraceMismatchAck message. 419 The LOCAL_INTERFACE_ID object is defined in [LMP]. The 420 LOCAL_INTERFACE_ID in this message is the local Interface Id of the 421 data link that has a trace mismatch. A trace mismatch for multiple 422 LOCAL_INTERFACE_ID's may be reported in the same message. 424 4.1.5. TraceMismatchAck Message 426 The TraceMismatchAck message (Message Type TBA by IANA) is used to 427 acknowledge receipt of a TraceMismatch message. The format is as 428 follows: 430 ::= 432 The MESSAGE_ID_ACK object is defined in [LMP]. The contents of the 433 MESSAGE_ID_ACK object MUST be obtained from the TraceMismatch 434 message being acknowledged. 436 4.1.6. TraceReq Message 438 The TraceReq message (Message Type TBA by IANA) is sent over the 439 control channel and is used to request the current trace value of a 440 data link. 442 ::= 443 445 The above transmission order SHOULD be followed. 447 The format of the TRACE_REQ object is as follows: 449 Class = TBA by IANA. 451 O C-Type = 1, TraceReq 453 0 1 2 3 454 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 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 |N| C-Type | Class | Length | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | Trace Type | (Reserved) | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 Trace Type: 16 bits 463 Defined in Section 4.1.1.1. 465 Reserved: 16 bits 467 This field MUST be set to zero when sent and ignored when 468 received 470 4.1.7. TraceReport Message 472 The TraceReport message (Message Type TBA by IANA) is sent over the 473 control channel after receiving a TraceReq message. 475 ::= 477 The TraceReport message MUST include a TRACE Object (as described in 478 Section 4.1.1.1) for the requested data link. 480 The MESSAGE_ID_ACK object is defined in [LMP]. The contents of the 481 MESSAGE_ID_ACK object MUST be obtained from the TraceReq message 482 being acknowledged. 484 4.1.8. TraceReqNack Message 486 The TraceReqNack message (Message Type TBA by IANA) is sent over the 487 control channel after receiving a TraceReq message. 489 ::= 490 492 The above transmission order SHOULD be followed. 494 The MESSAGE_ID_ACK object is defined in [LMP]. The contents of the 495 MESSAGE_ID_ACK object MUST be obtained from the TraceReq message 496 being acknowledged. 498 The TraceReqNak message MUST include an ERROR_CODE Object (as 499 defined in Section 4.1.3.1) for the requested data link. 501 4.1.9. InsertTrace Message 503 The InsertTrace message (Message Type TBA by IANA) is sent over the 504 control channel and is used to request a remote node to send a 505 specific trace message over a data link (this assumes that the 506 remote knows the mapping between the local and remote interface_Ids 507 before fulfilling such request). 509 The format is as follows: 511 ::= 512 514 The above transmission order SHOULD be followed. 516 A node that receives an InsertTrace message MUST respond with either 517 an InsertTraceAck or an InsertTraceNack Message. 519 Once the InsertTraceAck message is received, the TraceMismatch 520 message (see Section 4.1.4) is used to indicate a trace mismatch has 521 occurred. 523 The MESSAGE_ID_object is defined in [LMP]. 525 4.1.10. InsertTraceAck Message 527 The InsertTraceAck message (Message Type TBA by IANA) is used to 528 acknowledge receipt of the InsertTrace message and indicate that the 529 TRACE Object in the InsertTrace message has been received and 530 processed correctly (i.e. no Trace Mismatch). The format is as 531 follows: 533 ::= 535 The MESSAGE_ID_ACK object is defined in [LMP]. The contents of the 536 MESSAGE_ID_ACK object MUST be obtained from the InsertTrace message 537 being acknowledged. 539 4.1.11. InsertTraceNack Message 541 The InsertTraceNack message (Message Type TBA by IANA) is used to 542 acknowledge receipt of the InsertTrace message and to indicate that 543 the TRACE Object in the InsertTrace message was not processed 544 correctly. This could be because the trace monitoring requested is 545 not supported or there was an error in the value. 547 The format is as follows: 549 ::= 550 552 The above transmission order SHOULD be followed. 554 The MESSAGE_ID_ACK object is defined in [LMP]. 556 The InsertTraceNack message MUST include an ERROR_CODE Object (as 557 defined in Section 4.1.3.1) for the requested data link. 559 5. Security Considerations 561 LMP message security uses IPsec as described in [LMP]. This document 562 introduces no other new security considerations not covered in 563 [LMP]. 565 6. IANA Considerations 567 LMP [LMP] defines the following name spaces and how IANA can make 568 assignments in those namespaces: 570 - LMP Message Type. 571 - LMP Object Class. 572 - LMP Object Class type (C-Type) unique within the Object Class. 573 - LMP Sub-object Class type (Type) unique within the Object Class. 575 This memo introduces the following new assignments: 577 LMP Message Type: 579 o TraceMonitor message (suggested Message type = 21) 580 o TraceMonitorAck message (suggested Message type = 22) 581 o TraceMonitorNack message (suggested Message type = 23) 582 o TraceMismatch message (suggested Message type = 24) 583 o TraceMismatchAck message (suggested Message type = 25) 585 o TraceReq message (suggested Message type = 26) 586 o TraceReport message (suggested Message type = 27) 587 o TraceReqNack message (suggested Message type = 28) 589 o InsertTrace message (suggested Message type = 29) 590 o InsertTraceAck message (suggested Message type = 30) 591 o InsertTraceNack message (suggested Message type = 31) 593 LMP Object Class name space and Class type (C-Type): 595 o TRACE Class name (suggested = 21) 596 - Type 1 (suggested C-Type = 1) 598 o TRACE REQ Class name (suggested = 22) 599 - Type 1 (suggested C-Type = 1) 601 7. Intellectual Property Considerations 603 The IETF takes no position regarding the validity or scope of any 604 intellectual property or other rights that might be claimed to 605 pertain to the implementation or use of the technology described in 606 this document or the extent to which any license under such rights 607 might or might not be available; neither does it represent that it 608 has made any effort to identify any such rights. Information on the 609 IETF's procedures with respect to rights in standards-track and 610 standards-related documentation can be found in BCP-11. Copies of 611 claims of rights made available for publication and any assurances 612 of licenses to be made available, or the result of an attempt made 613 to obtain a general license or permission for the use of such 614 proprietary rights by implementers or users of this specification 615 can be obtained from the IETF Secretariat. 617 The IETF invites any interested party to bring to its attention any 618 copyrights, patents or patent applications, or other proprietary 619 rights which may cover technology that may be required to practice 620 this standard. Please address the information to the IETF Executive 621 Director. 623 8. References 625 8.1. Normative References 627 [BUNDLE] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in 628 MPLS Traffic Engineering," (work in progress). 630 [G.707] ITU-T Recommendation G.707, "Network node interface for 631 the synchronous digital hierarchy (SDH)," October 2000. 633 [LMP] Lang, J., ed., "Link Management Protocol (LMP)," (work 634 in progress). 636 [RFC1662] Simpson, W., ed., "PPP in HDLC-like Framing", IETF RFC 637 1662, STD 51, July 1994. 639 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 640 Requirement Levels", BCP 14, IETF RFC 2119, March 1997. 642 [RFC3471] Berger, L., ed., "Generalized Multi-Protocol Label 643 Switching (GMPLS) Signaling Functional Description", 644 IETF RFC 3471, January 2003. 646 [T1.105] T1.105, "Revised Draft T105 SONET Base Standard," 647 January 2001. 649 8.2. Informative References 651 [LSP-HIER] Kompella, K., Rekhter, Y., "LSP Hierarchy with 652 Generalized MPLS TE," (work in progress). 654 9. Acknowledgements 656 The authors would like to thank Bernard Sales, Emmanuel Desmet, Gert 657 Grammel, Jim Jones, Stefan Ansorge, John Drake, and James Scott for 658 their many contributions to this document. 660 We would also like to thank Greg Bernstein and Michiel van 661 Everdingen for their insightful comments and for acting with a 662 strong combination of toughness, professionalism, and courtesy. 664 10. Author's Addresses 666 Jonathan P. Lang Dimitri Papadimitriou 667 Rincon Networks Alcatel 668 829 De La Vina, Suite 220 Francis Wellesplein 1 669 Santa Barbara, CA 93101 B-2018 Antwerpen, Belgium 670 Email: jplang@ieee.org email: dimitri.papadimitriou@alcatel.be 672 11. Full Copyright Statement 674 Copyright (C) The Internet Society (2003). All Rights Reserved. 676 This document and translations of it may be copied and furnished to 677 others, and derivative works that comment on or otherwise explain it 678 or assist in its implementation may be prepared, copied, published 679 and distributed, in whole or in part, without restriction of any 680 kind, provided that the above copyright notice and this paragraph 681 are included on all such copies and derivative works. However, this 682 document itself may not be modified in any way, such as by removing 683 the copyright notice or references to the Internet Society or other 684 Internet organizations, except as needed for the purpose of 685 developing Internet standards in which case the procedures for 686 copyrights defined in the Internet Standards process must be 687 followed, or as required to translate it into languages other than 688 English. 690 The limited permissions granted above are perpetual and will not be 691 revoked by the Internet Society or its successors or assigns. 693 This document and the information contained herein is provided on an 694 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 695 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 696 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 697 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 698 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.