idnits 2.17.1 draft-ietf-ccamp-confirm-data-channel-status-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 4 instances of too long lines in the document, the longest one being 1 character 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 seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 14, 2009) is 5209 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) No issues found here. Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group D. Li 2 Internet Draft H. Xu 3 Category: Standards Track Huawei 4 S. Bardalai 5 Fujitsu 6 J. Meuric 7 France Telecom 8 D. Caviglia 9 Ericsson 11 Expires: June 2010 December 14, 2009 13 Data Channel Status Confirmation Extensions 14 for the Link Management Protocol 16 draft-ietf-ccamp-confirm-data-channel-status-09.txt 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Abstract 40 This document defines simple additions to the Link Management 41 Protocol (LMP) to provide a control plane tool that can assist in 42 the location of stranded resources by allowing adjacent Label- 43 Switching Routers (LSRs) to confirm data channel statuses, and 44 provides triggers for notifying the management plane if any 45 discrepancies are found. As LMP is already used to verify data plane 46 connectivity, it is considered to be an appropriate candidate to 47 support this feature. 49 Conventions used in this document 51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 53 document are to be interpreted as described in [RFC2119]. 55 Table of Contents 57 1. Introduction.................................................2 58 2. Problem Explanation..........................................4 59 2.1. Mismatch Caused by Manual Configuration.................4 60 2.2. Mismatch Caused by LSP Deletion.........................5 61 2.3. Failed Resources........................................6 62 3. Motivation...................................................6 63 4. Extensions to LMP............................................7 64 4.1. Confirm Data Channel Status Messages....................7 65 4.1.1. ConfirmDataChannelStatus Messages..................7 66 4.1.2. ConfirmDataChannelStatusAck Messages...............8 67 4.1.3. ConfirmDataChannelStatusNack Messages..............8 68 4.2. Data Channel Status Subobject...........................9 69 4.3. Message Construction...................................10 70 4.4. Backward Compatibility.................................10 71 5. Procedures..................................................10 72 6. Security Considerations.....................................12 73 7. IANA Considerations.........................................12 74 7.1. LMP Message Types......................................12 75 7.2. LMP Data Link Object Subobject.........................12 76 8. Acknowledgments.............................................13 77 9. References..................................................13 78 9.1. Normative References...................................13 79 9.2. Informative References.................................13 80 10. Authors' Addresses.........................................14 81 11. Full Copyright Statement...................................15 82 12. Intellectual Property Statement............................15 83 13. Disclaimer of Validity.....................................16 85 1. Introduction 87 Generalized Multiprotocol Label Switching (GMPLS) networks are 88 constructed from Traffic Engineering (TE) links connecting Label 89 Switching Routers (LSRs). The TE links are constructed from a set of 90 data channels. In this context, a data channel corresponds to a 91 resource label in a non-packet technology (such as a timeslot or a 92 lambda). 94 A data channel status mismatch exists if the LSR at one end of a TE 95 link believes that the data channel is assigned to carry data, but 96 the LSR at the other end does not. The term "ready to carry data" 97 means cross-connected or bound to an end-point for the receipt or 98 delivery of data. 100 Data channel mismatches cannot be detected from the TE information 101 advertised by the routing protocols [RFC4203], [RFC5307]. The 102 existence of some data channel mismatch problems may be detected by 103 a mismatch in the advertised bandwidths where bidirectional TE links 104 and bidirectional services are in use, but where unidirectional 105 services exist, or where multiple data channel mismatches occur, it 106 is not possible to detect such errors through the routing protocol- 107 advertised TE information. In any case, there is no mechanism to 108 isolate the mismatches by determining which data channels are at 109 fault. 111 If a data channel mismatch exists, any attempt to use the data 112 channel for a new Label Switched Path (LSP) will fail. One end of 113 the TE link may attempt to assign the TE link for use, but the other 114 end will report the data channel as unavailable when the control 115 plane or management plane attempts to assign it to an LSP. 117 Although such a situation can be resolved through the use of the 118 Acceptable Label Set object in GMPLS signaling [RFC3473], such a 119 procedure is inefficient since it may require an additional 120 signaling exchange for each LSP that is set up. When many LSPs are 121 to be set up, and when there are many data channel mismatches, such 122 inefficiencies become significant. It is desirable to avoid the 123 additional signaling overhead, and to report the problems to the 124 management plane so that they can be resolved to improve the 125 efficiency of LSP setup. 127 Correspondingly, such a mismatch situation may give rise to 128 misconnections in the data plane especially when LSPs are set up 129 using management plane operations. 131 Resources (data channels) that are in a mismatched state are often 132 described as "stranded resources". They are not in use for any LSP, 133 but they cannot be assigned for use by a new LSP because they appear 134 to be in use. Although it is theoretically possible for management 135 plane applications to audit all network resources to locate stranded 136 resources and to release them, this process is rarely performed 137 because of the difficulty of coordinating different Element 138 Management Systems (EMSs), and the associated risks of accidentally 139 releasing in-use resources. It is desirable to have a control plane 140 mechanism that detects and reports stranded resources. 142 This document defines simple additions to the Link Management 143 Protocol (LMP) [RFC4204] to provide a control plane tool that can 144 assist in the location of stranded resources by allowing adjacent 145 LSRs to confirm data channel statuses, and provides triggers for 146 notifying the management plane if any discrepancies are found. As LMP 147 is already used to verify data plane connectivity, it is considered 148 to be an appropriate candidate to support this feature. 150 2. Problem Explanation 152 Examples of data channel mismatches are described in the following 153 three scenarios. 155 In all of the scenarios, the specific channel resource of a data link 156 will be unavailable because of the data channel status mismatch, and 157 this channel resource will be wasted. Furthermore, a data channel 158 status mismatch may reduce the possibility of successful LSP 159 establishment, because a data channel status mismatch may result in 160 failure when establishing an LSP. 162 So it is desirable to confirm the data channel statuses as early as 163 possible. 165 2.1. Mismatch Caused by Manual Configuration 167 The operator may have configured a cross-connect at only one end of 168 a TE link using an EMS. The resource at one end of the data channel 169 is allocated, but the corresponding resource is still available at 170 the other end of the same data channel. In this case, the data 171 channel may appear to be available for use by the control plane when 172 viewed from one end of the TE link, but will be considered to be 173 unavailable by the other end of the TE link. Alternatively, the 174 available end of the data channel may be cross-connected by the 175 management plane and a misconnection may result from the fact that 176 the other end of the data channel is already cross-connected. 178 Figure 1 shows a data channel between nodes A and B. The resource at 179 A's end of the TE link is allocated through manual configuration, 180 while the resource at B's end of the TE link available, so the data 181 channel status is mismatched. 183 allocated available 184 +-+------------+-+ 185 A |x| | | B 186 +-+------------+-+ 187 data channel 188 Figure 1. Mismatch caused by manual configuration 190 2.2. Mismatch Caused by LSP Deletion 192 The channel status of a data link may become mismatched during the 193 LSP deletion process. If the LSP deletion process is aborted in the 194 middle of the process (perhaps because of a temporary control plane 195 failure), the cross-connect at the upstream node may be removed while 196 the downstream node still keeps its cross-connect, if the LSP 197 deletion was initiated by the source node. 199 For example, in Figure 2 an LSP traverses nodes A, B, and C. Node B 200 resets abnormally when the LSP is being deleted. This results in the 201 cross-connects of node A and C being removed, but the cross-connect 202 of node B still being in use. So the data channel statuses between 203 nodes A and B, and between nodes B and C are both mismatched. 205 <---------LSP---------> 206 +-+-------+-+-------+-+ 207 | | |X| | | 208 +-+-------+-+-------+-+ 209 A B C 210 Figure 2. Mismatch caused by LSP deletion 212 In [RFC2205] and [RFC3209], a soft state mechanism was defined to 213 prevent state discrepancies between LSRs. Resource ReserVation 214 Protocol-Traffic Engineering (RSVP-TE) restart processes ([RFC3473], 215 [RFC5063]) have been defined: adjacent LSRs may resynchronize their 216 control plane state to reinstate information about LSPs that have 217 persisted in the data plane. Both mechanisms aim at keeping state 218 consistency among nodes and allow LSRs to detect mismatched data 219 plane states. The data plane handling of such mismatched state can be 220 treated as a local policy decision. Some deployments may decide to 221 automatically clean up the data plane state so it matches the control 222 plane state, but others may choose to raise an alert to the 223 management plane and leave the data plane untouched just in case it 224 is in use. 226 In such cases, data channel mismatches may arise after restart and 227 might not be cleared up by the restart procedures. 229 2.3. Failed Resources 231 Even if the situation is not common, it might happen that a 232 termination point of a TE-link is seen as failed by one end, while 233 on the other end it is seen as OK. This problem may arise due to 234 some failure either in the hardware or in the status detection of 235 the termination point. 237 This mismatch in the termination point status can lead to failure 238 in case of bidirectional LSP set-up. 240 Good Failed 241 +-+------------+-+ 242 A | | |X| B 243 +-+------------+-+ 244 data channel 245 Path Message with Upstream Label----> 247 Figure 3. Mismatch caused by resource failure 249 In this case upstream node chooses to use termination point A in 250 order to receive traffic from downstream node. From the upstream 251 node's point of view, the resource is available thus usable; however, 252 in the downstream node, the corresponding termination point (resource 253 B) is broken. This leads to a set-up failure. 255 3. Motivation 257 The requirement does not come from a lack in GMPLS specifications 258 themselves but rather from operational concerns because, in most 259 cases, GMPLS-controlled networks will co-exist with legacy networks 260 and legacy procedures. 262 The protocol extensions defined in this document are intended to 263 detect data plane problems resulting from mis-use or mis- 264 configurations triggered by user error, or resulting from failure to 265 clean up the data plane after control plane disconnection. It is 266 anticipated that human mistake is probably the major source of errors 267 to deal with. It is not the intention to provide a protocol mechanism 268 to deal with broken implementations. 270 The procedures defined in this document are designed to be operated 271 on a periodic or on-demand basis. It is NOT RECOMMENDED that the 272 procedures be used to provide a continuous and on-line monitoring 273 process. 275 As LMP is already used to verify data plane connectivity, it is 276 considered to be an appropriate candidate to support this feature. 278 4. Extensions to LMP 280 A control plane tool to detect and isolate data channel mismatches is 281 provided in this document by simple additions to the Link Management 282 Protocol (LMP) [RFC4204]. It can assist in the location of stranded 283 resources by allowing adjacent LSRs to confirm data channel statuses. 285 Outline procedures are described in this section. More detailed 286 procedures are found in Section 5. 288 The message formats in the sections that follow use Backus-Naur Form 289 (BNF) encoding as defined in [RFC5511]. 291 4.1. Confirm Data Channel Status Messages 293 Extensions to LMP to confirm a data channel status are described 294 below. In order to confirm a data channel status, the new LMP 295 messages are sent between adjacent nodes periodically or driven by 296 some event (such as an operator command, a configurable timer, or the 297 rejection of an LSP setup message because of an unavailable resource). 298 The new LMP messages run over the control channel, encapsulated in 299 UDP with an LMP port number and IP addressing as defined in Link 300 Management Protocol (LMP) [RFC4204]. 302 Three new messages are defined to check data channel status: 303 ConfirmDataChannelStatus, ConfirmDataChannelStatusAck, 304 ConfirmDataChannelStatusNack, which are described in detail in the 305 following sections. Message Type numbers are found in Section 7.1. 307 4.1.1. ConfirmDataChannelStatus Messages 309 The ConfirmDataChannelStatus message is used to tell the remote end 310 of the data channel what the status of the local end of the data 311 channel is, and to ask the remote end to report its data channel. The 312 message may report on (and request information about) more than one 313 data channel. 315 ::= 316 317 318 [...] 320 When a node receives the ConfirmDataChannelStatus message, and the 321 data channel status confirmation procedure is supported at the node, 322 the node compares its own data channel statuses with all of the data 323 channel statuses sent by the remote end in the 324 ConfirmDataChannelStatus message. If a data channel status mismatch 325 is found, this mismatch result is expected to be reported to the 326 management plane for further action. Management plane reporting 327 procedures and actions are outside the scope of this document. 329 If the message is a Confirm Data Channel Status message, and the 330 Message_Id value is less than the largest Message_Id value previously 331 received from the sender for the specified TE link, then the message 332 SHOULD be treated as being out-of-order. 334 4.1.2. ConfirmDataChannelStatusAck Messages 336 The ConfirmDataChannelStatusAck message is sent back to the node 337 which originated the ConfirmDataChannelStatus message to return the 338 requested data channel statuses. 340 When the ConfirmDataChannelStatusAck message is received, the node 341 compares the received data channel statuses at the remote end with 342 those at the local end (the same operation as performed by the 343 receiver of the ConfirmDataChannelStatus message). If a data channel 344 status mismatch is found, the mismatch result is expected to be 345 reported to the management plane for further action. 347 ::= 348 349 [...] 351 The contents of the MESSAGE_ID_ACK objects MUST be obtained from the 352 ConfirmDataChannelStatus message being acknowledged. 354 Note that the ConfirmDataChannelStatusAck message is used both when 355 the data channel statuses match and when they do not match. 357 4.1.3. ConfirmDataChannelStatusNack Messages 359 When a node receives the ConfirmDataChannelStatus message, if the 360 data channel status confirmation procedure is not supported but the 361 message is recognized, a ConfirmDataChannelStatusNack message 362 containing an ERROR_CODE indicating "Channel Status Confirmation 363 Procedure not supported" MUST be sent. 365 If the data channel status confirmation procedure is supported, but 366 the node is unable to begin the procedure, a 367 ConfirmDataChannelStatusNack message containing an ERROR_CODE 368 indicating "Unwilling to Confirm" MUST be sent. If a 369 ConfirmDataChannelStatusNack message is received with such an 370 ERROR_CODE, the node which originated the ConfirmDataChannelStatus 371 message MAY schedule the ConfirmDataChannelStatus message 372 retransmission after a configured time. A default value of 10 minutes 373 is suggested for this timer. 375 ::= 376 [] 377 378 380 The contents of the MESSAGE_ID_ACK objects MUST be obtained from the 381 ConfirmDataChannelStatus message being rejected. 383 4.2. Data Channel Status Subobject 385 A new Data Channel Status subobject type is introduced to the DATA 386 LINK object to hold the data channel status and Data Channel 387 Identification. 389 See Section 7.2 for the Subobject Type value. 391 0 1 2 3 392 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 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | Type | Length | Data Channel Status | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | | 397 // Data Channel ID // 398 | | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 Data Channel Status: 403 This is a series of bit flags to indicate the status of the data 404 channel. The following values are defined. 406 0x0000 : The channel is available/free. 407 0x0001 : The channel is unavailable/in-use. 409 Data Channel ID 411 This identifies the data channel. The length of this field can be 412 deduced from the Length field in the subobject. Note that all 413 subobjects must be padded to a four byte boundary with trailing zeros. 415 If such padding is required, the Length field MUST indicate the 416 length of the subobject up to, but not including, the first byte of 417 padding. Thus, the amount of padding is deduced and not represented 418 in the Length field. 420 Note that the Data Channel ID is given in the context of the sender 421 of the ConfirmChannelStatus message. 423 The data-channel ID must be encoded as a label value. Based on the 424 type of signal e.g. SONET/SDH, Lambda etc. the encoding methodology 425 used will be different. For SONET/SDH the label value is encoded as 426 per [RFC4606]. 428 4.3. Message Construction 430 Data_Link Class is included in ConfirmDataChannelStatus and 431 ConfirmDataChannelStatusAck messages, which is defined in section 432 13.12 in [RFC4204]. 434 The status of the TE link end MUST be carried by the Data Channel 435 Status subobject which is defined in section 4.2 of this document. 436 The new subobject MUST be part of Data_Link Class. 438 In the case of SDH/SONET, DATA Channel ID in the new subobject SHOULD 439 be used to identify each timeslot of the data link. 441 4.4. Backward Compatibility 443 Some nodes running in the network may only support the LMP Message 444 Types, which are already defined in [RFC4204]. The three new types of 445 LMP message defined in this document can not be recognized by these 446 nodes. The unknown message behavior is not being specified in 447 [RFC4204], it's suggested to discard the unknown message silently. 448 The mechanism defined in this document presumes a certain non- 449 standard behavior of existing/non-document supporting nodes. To use 450 this mechanism all nodes MUST have the extensions described in this 451 document for compatibility. 453 5. Procedures 455 Adjacent nodes MAY send data channel status confirmation related LMP 456 messages. Periodical timers or some other events requesting the 457 confirmation of channel status for the data link may trigger these 458 messages. It's a local policy decision to start the data channel 459 status confirmation process. The procedure is described below: 461 . Initially, the SENDER constructs a ConfirmDataChannelStatus 462 message which MUST contain one or more DATA_LINK objects. 463 DATA_LINK object is defined in [RFC4204]. Each DATA_LINK object 464 MUST contain one or more Data Channel Status subobjects. The Data 465 Channel ID field in the Data Channel Status subobject MUST 466 indicate which data channel needs to be confirmed, and MUST report 467 the data channel status at the SENDER. The 468 ConfirmDataChannelStatus message is sent to the RECEIVER. 470 . Upon reception of a ConfirmDataChannelStatus message, the RECEIVER 471 MUST extract the data channel statuses from the 472 ConfirmDataChannelStatus message, and SHOULD compare these with 473 its data channel statuses for the reported data channels. If a 474 data channel status mismatch is found, the mismatch result SHOULD 475 be reported to the management plane for further action. The 476 RECEIVER also SHOULD send the ConfirmDataChannelStatusAck message 477 which MUST carry all the local end statuses of the requested data 478 channels to the SENDER. 480 . If the RECEIVER is not able to support or to begin the 481 confirmation procedure, the ConfirmDataChannelStatusNack message 482 MUST be responded with the ERROR_CODE which indicates the reason 483 of rejection. 485 . Upon reception of a ConfirmDataChannelStatusAck message, the 486 SENDER MUST compare the received data channel statuses at the 487 remote end with the data channel statuses at the local end. If a 488 data channel status mismatch is found, the mismatch result SHOULD 489 be reported to the management plane for further action. 491 The data channel status mismatch issue identified by LMP may be 492 automatically resolved by RSVP restart. For example, the restarting 493 node may also have damaged its data plane. This leaves the data 494 channels mismatched. But RSVP restart will re-install the data plane 495 state in the restarting node. The issue may also be resolved via RSVP 496 soft state timeout. 498 If the ConfirmDataChannelStatus message is not recognized by the 499 RECEIVER, the RECEIVER ignores this message, and will not send out an 500 acknowledgment message to the SENDER. 502 Due to message loss problem, the SENDER may not be able to receive 503 the acknowledgment message. 505 ConfirmDataChannelStatus SHOULD be sent using LMP [RFC4204] reliable 506 transmission mechanisms. If after the retry limit is reached, a 507 ConfirmDataChannelStatusAck message or a ConfirmDataChannelStatusNack 508 message is not received by the SENDER, the SENDER SHOULD terminate 509 the data channel confirmation procedure. 511 6. Security Considerations 513 [RFC4204] describes how LMP messages between peers can be secured, 514 and these measures are equally applicable to the new messages defined 515 in this document. 517 The operation of the procedures described in this document does not 518 of themselves constitute a security risk since they do not cause any 519 change in network state. It would be possible, if the messages were 520 intercepted or spoofed to cause bogus alerts in the management plane 521 and so the use of the LMP security measures are RECOMMENDED. 523 Note that operating the procedures described in this document may 524 provide a useful additional security measure to verify that data 525 channels have not been illicitly modified. 527 7. IANA Considerations 529 7.1. LMP Message Types 531 IANA maintains the "Link Management Protocol (LMP)" registry which 532 has a subregistry called "LMP Message Type". IANA is requested to 533 make three new allocations from this registry as follows. The message 534 type values are suggested and to be confirmed by IANA. 536 Value Description 537 ------ --------------------------------- 538 32 ConfirmDataChannelStatus 539 33 ConfirmDataChannelStatusAck 540 34 ConfirmDataChannelStatusNack 542 7.2. LMP Data Link Object Subobject 544 IANA maintains the "Link Management Protocol (LMP)" registry which 545 has a subregistry called "LMP Object Class name space and Class type 546 (C-Type)". This subregistry has an entry for the DATA_LINK object, 547 and there is a further embedded registry called "DATA_LINK Sub-object 548 Class name space". IANA is requested to make the following allocation 549 from this embedded registry. The value shown is suggested and to be 550 confirmed by IANA. 552 Value Description 553 ------ --------------------------------- 554 9 Data Channel Status 556 8. Acknowledgments 558 We would like to thank Adrian Farrel, Dimitri Papadimitriou, Lou 559 Berger for their useful comments. 561 9. References 563 9.1. Normative References 565 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 566 Requirement Levels", BCP 14, RFC 2119, March 1997. 568 [RFC4204] J. Lang, Ed., "Link Management Protocol (LMP)", RFC 4204, 569 October 2005. 571 [RFC5511] A. Farrel, Ed., "Routing Backus-Naur Form (RBNF): A 572 Syntax Used to Form Encoding Rules in Various Routing 573 Protocol Specifications", RFC 5511, April 2009. 575 9.2. Informative References 577 [RFC2205] R. Braden, Ed., "Resource ReSerVation Protocol (RSVP) -- 578 Version 1 Functional Specification", RFC 2205, September 579 1997 581 [RFC3209] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. 582 Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", 583 RFC 3209, December 2001 585 [RFC3473] L. Berger, Ed., "Generalized Multi-Protocol Label 586 Switching (GMPLS) Signaling Resource ReserVation 587 Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 588 3473, January 2003 590 [RFC5063] A. Satyanarayana, R. Rahman, "Extensions to GMPLS RSVP 591 Graceful Restart", RFC 5063, September 2007 593 [RFC4203] K. Kompella, Ed., "OSPF Extensions in Support of 594 Generalized Multi-Protocol Label Switching (GMPLS)", RFC 595 4203, October 2005 597 [RFC4606] E. Mannie, Ed., "Generalized Multi-Protocol Label 598 Switching (GMPLS) Extensions for Synchronous Optical 599 Network (SONET) and Synchronous Digital Hierarchy (SDH) 600 Control", RFC 4606, August 2006 602 [RFC5307] K. Kompella, Ed., "IS-IS Extensions in Support of 603 Generalized Multi-Protocol Label Switching (GMPLS)", RFC 604 5307, October 2008 606 10. Authors' Addresses 608 Dan Li 609 Huawei Technologies 610 F3-5-B R&D Center, Huawei Base, 611 Shenzhen 518129 China 613 Phone: +86 755-289-70230 614 Email: danli@huawei.com 616 Huiying Xu 617 Huawei Technologies 618 F3-5-B R&D Center, Huawei Base, 619 Shenzhen 518129 China 621 Phone: +86 755-289-72910 622 Email: xuhuiying@huawei.com 624 Fatai Zhang 625 Huawei Technologies 626 F3-5-B R&D Center, Huawei Base, 627 Shenzhen 518129 China 629 Phone: +86 755-289-72912 630 Email: zhangfatai@huawei.com 632 Snigdho C. Bardalai 633 Fujitsu Network Communications 634 2801 Telecom Parkway, 635 Richardson, Texas 75082, USA 637 Phone: +1 972 479 2951 638 Email: snigdho.bardalai@us.fujitsu.com 639 Julien Meuric 640 France Telecom Orange Labs 641 2, avenue Pierre Marzin 642 22307 Lannion Cedex, France 644 Phone: +33 2 96 05 28 28 645 Email: julien.meuric@orange-ftgroup.com 647 Diego Caviglia 648 Ericsson 649 Via A. Negrone 1/A 16153 650 Genoa Italy 652 Phone: +39 010 600 3736 653 Email: diego.caviglia@ericsson.com 655 11. Full Copyright Statement 657 Copyright (c) 2009 IETF Trust and the persons identified as the 658 document authors. All rights reserved. 660 This document is subject to BCP 78 and the IETF Trust's Legal 661 Provisions Relating to IETF Documents in effect on the date of 662 publication of this document (http://trustee.ietf.org/license-info). 663 Please review these documents carefully, as they describe your rights 664 and restrictions with respect to this document. 666 This document may contain material from IETF Documents or IETF 667 Contributions published or made publicly available before November 10, 668 2008. The person(s) controlling the copyright in some of this 669 material may not have granted the IETF Trust the right to allow 670 modifications of such material outside the IETF Standards Process. 671 Without obtaining an adequate license from the person(s) controlling 672 the copyright in such materials, this document may not be modified 673 outside the IETF Standards Process, and derivative works of it may 674 not be created outside the IETF Standards Process, except to format 675 it for publication as an RFC or to translate it into languages other 676 than English. 678 12. Intellectual Property Statement 680 The IETF Trust takes no position regarding the validity or scope of 681 any Intellectual Property Rights or other rights that might be 682 claimed to pertain to the implementation or use of the technology 683 described in any IETF Document or the extent to which any license 684 under such rights might or might not be available; nor does it 685 represent that it has made any independent effort to identify any 686 such rights. 688 Copies of Intellectual Property disclosures made to the IETF 689 Secretariat and any assurances of licenses to be made available, or 690 the result of an attempt made to obtain a general license or 691 permission for the use of such proprietary rights by implementers or 692 users of this specification can be obtained from the IETF on-line IPR 693 repository at http://www.ietf.org/ipr 695 The IETF invites any interested party to bring to its attention any 696 copyrights, patents or patent applications, or other proprietary 697 rights that may cover technology that may be required to implement 698 any standard or specification contained in an IETF Document. Please 699 address the information to the IETF at ietf-ipr@ietf.org. 701 13. Disclaimer of Validity 703 All IETF Documents and the information contained therein are provided 704 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 705 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 706 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 707 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 708 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 709 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 710 FOR A PARTICULAR PURPOSE. Provisions Relating to IETF Documents in 711 effect on the date of publication of this document 712 (http://trustee.ietf.org/license-info). Please review these documents 713 carefully, as they describe your rights and restrictions with respect 714 to this document.