idnits 2.17.1 draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1317. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1294. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1301. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1307. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: Note that a Call MAY NOT be imposed upon a Connection that is already established. To do so would require changing the short Call ID in the SESSION OBJECT of the existing LSPs and this would constitute a change in the Session Identifier. This is not allowed by existing protocol specifications. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Transit nodes SHOULD not examine Notify messages that are not addressed to them. However, they will see short Call IDs in all LSPs associated with Calls. -- 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 (April 2006) is 6558 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: 'RFC3743' is mentioned on line 847, but not defined ** Obsolete normative reference: RFC 2402 (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (Obsoleted by RFC 4303, RFC 4305) ** Downref: Normative reference to an Informational RFC: RFC 4139 Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 CCAMP Working Group Editors 2 Internet Draft D. Papadimitriou (Alcatel) 3 Updates RFC 3473 A. Farrel (Old Dog Consulting) 4 Proposed Category: Standard Track 5 Expiration Date: October 2006 April 2006 7 Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions 8 in support of Calls 10 draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 In certain networking topologies it may be advantageous to maintain 37 associations between endpoints and key transit points to support an 38 instance of a service. Such associations are known as Calls. 40 A Call does not provide the actual connectivity for transmitting user 41 traffic, but only builds a relationship by which subsequent 42 connections may be made. In Generalized MPLS (GMPLS) such connections 43 are known as Label Switched Paths (LSPs). 45 This document specifies how GMPLS RSVP-TE signaling may be used and 46 extended to support Calls. These mechanisms provide full and logical 47 Call/Connection separation. 49 The mechanisms proposed in this document are applicable to any 50 environment (including multi-area), and for any type of interface: 51 packet, layer-2, time-division multiplexed, lambda or fiber 52 switching. 54 Table of Content 56 1. Conventions used in this document ............................. 3 57 2. Introduction .................................................. 3 58 2.1 Applicability to ASON ........................................ 4 59 3. Requirements .................................................. 4 60 3.1 Basic Call Function .......................................... 4 61 3.2 Call/Connection Separation ................................... 4 62 3.3 Call Segments ................................................ 5 63 4. Concepts and Terms ............................................ 5 64 4.1 What is a Call? .............................................. 5 65 4.2 A Hierarchy of Calls, Connections, Tunnels and LSPs .......... 5 66 4.3 Exchanging Access Link Capabilities .......................... 6 67 4.3.1 Network-initiated Calls .................................... 6 68 4.3.2 User-initiated Calls ....................................... 7 69 4.3.3 Utilizing Call Setup ....................................... 7 70 5. Protocol Extensions for Calls and Connections ................. 7 71 5.1 Call Setup and Teardown ...................................... 7 72 5.2 Call Identification .......................................... 8 73 5.2.1 Long Form Call Identification .............................. 8 74 5.2.2 Short Form Call Identification ............................. 8 75 5.2.3 Short Form Call ID Encoding ................................ 9 76 5.3 LINK_CAPABILITY object ...................................... 10 77 5.4 Revised Message Formats ..................................... 11 78 5.4.1 Notify Message ............................................ 11 79 5.5 ADMIN_STATUS Object ......................................... 11 80 6. Procedures in Support of Calls and Connections ............... 12 81 6.1 Call/Connection Setup Procedures ............................ 12 82 6.2 Call Setup .................................................. 12 83 6.2.1 Accepting Call Setup ...................................... 14 84 6.2.2 Call Setup Failure and Rejection .......................... 15 85 6.3 Adding a Connections to a Call .............................. 15 86 6.3.1 Adding a Reverse Direction LSP to a Call .................. 16 87 6.4 Call-Free Connection Setup .................................. 16 88 6.5 Call Collision .............................................. 16 89 6.6 Call/Connection Teardown .................................... 17 90 6.6.1 Removal of a Connection from a Call ....................... 18 91 6.6.2 Removal of the Last Connection from a Call ................ 18 92 6.6.3 Teardown of an "Empty" Call ............................... 18 93 6.6.4 Attempted Teardown of a Call with Existing Connections .... 18 94 6.6.5 Teardown of a Call from the Egress ........................ 19 95 6.7 Control Plane Survivability ................................. 19 96 7. Applicability of Call and Connection Procedures .............. 20 97 7.1 Network-initiated Calls ..................................... 20 98 7.2 User-initiated Calls ........................................ 20 99 7.3 External Call Managers ...................................... 21 100 7.3.1 Call Segments ............................................. 21 101 8. Non-support of Call ID ....................................... 21 102 8.1 Non-Support by External Call Managers ....................... 22 103 8.2 Non-Support by Transit Node ................................. 22 104 8.3 Non-Support by Egress Node .................................. 23 105 9. Security Considerations ...................................... 23 106 9.1 Call and Connection Security Considerations ................. 23 107 10. IANA Considerations ......................................... 23 108 10.1 RSVP Objects ............................................... 23 109 10.2 RSVP Error Codes and Error Values .......................... 24 110 10.3 RSVP ADMIN_STATUS object Bits .............................. 24 111 11. Acknowledgements ............................................ 24 112 12. References .................................................. 24 113 12.1 Normative References ....................................... 24 114 12.2 Informative References ..................................... 26 115 13. Authors' Addresses .......................................... 26 117 1. Conventions used in this document 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC2119]. 123 In addition, the reader is assumed to be familiar with the 124 terminology used in [RFC3471], [RFC3473], [RFC3477] and [RFC3945]. 126 2. Introduction 128 This document defines protocol procedures and extensions to support 129 Calls within Generalized MPLS (GMPLS). 131 A Call is an association between endpoints and possibly between key 132 transit points (such as network boundaries) in support of an instance 133 of a service. The end-to-end association is termed a "Call," and the 134 association between two transit points or between an endpoint and a 135 transit point is termed a "Call Segment." An entity that processes a 136 Call or Call Segment is called a "Call Manager." 138 A Call does not provide the actual connectivity for transmitting user 139 traffic, but only builds a relationship by which subsequent 140 connections may be made. In GMPLS such connections are known as Label 141 Switched Paths (LSPs). 143 A Call may be associated with zero, one or more connections, and a 144 connection may be associated with zero or one Call. Thus full and 145 logical Call/Connection separation is needed. 147 An example of the requirement for Calls can be found in the ITU-T's 148 Automatically Switched Optical Network (ASON) architecture [G.8080] 149 and specific requirements for support of Calls in this context can be 150 found in [RFC4139]. Note, however, that while the mechanisms 151 described in this document meet the requirements stated in [RFC4139] 152 they have wider applicability. 154 The mechanisms defined in this document are equally applicable to any 155 packet (PSC) interface, layer-2 interfaces (L2SC), TDM capable 156 interfaces, LSC interfaces or FSC interfaces. The mechanisms and 157 protocol extensions are backward compatible, and can be used for Call 158 management where only the Call Managers need to be aware of the 159 protocol extensions. 161 2.1 Applicability to ASON 163 [RFC4139] details the requirements on GMPLS signaling to satisfy the 164 ASON architecture described in [G.8080]. The mechanisms described in 165 this document meet the requirements for Calls as described in 166 Sections 4.2 and 4.3 of [RFC4139] and the additional Call-related 167 requirements in Sections 4.4, 4.7, 5 and 6 of [RFC4139]. 169 [ASON-APPL] describes the applicability of GMPLS protocols to the 170 ASON architecture. 172 3. Requirements 174 3.1 Basic Call Function 176 The Call concept is used to deliver the following capabilities. 178 - Verification and identification of the Call initiator (prior to 179 LSP setup). 181 - Support of virtual concatenation with diverse path component LSPs. 183 - Association of multiple LSPs with a single Call (note aspects 184 related to recovery are detailed in [RFC4426] and [GMPLS-E2E]). 186 - Facilitation of control plane operations by allowing operational 187 status change of the associated LSP. 189 Procedures and protocol extensions to support Call setup, and the 190 association of Calls with Connections are described in Section 5 and 191 onwards of this document. 193 3.2 Call/Connection Separation 195 Full and logical Call and Connection separation is required. That is: 197 - It MUST be possible to establish a Connection without dependence 198 on a Call. 200 - It MUST be possible to establish a Call without any associated 201 Connections. 203 - It MUST be possible to associate more than one Connection with a 204 Call. 206 - Removal of the last Connection associated with a Call SHOULD NOT 207 result in the automatic removal of the Call except as a matter of 208 local policy at the ingress of the Call. 210 - Signaling of a Connection associated with a Call MUST NOT require 211 the distribution or retention of Call-related information (state) 212 within the network. 214 3.3 Call Segments 216 Call Segments capabilities MUST be supported. 218 Procedures and (GMPLS) RSVP-TE signaling protocol extensions to 219 support Call Segments are described in Section 7.3.1 of this 220 document. 222 4. Concepts and Terms 224 The concept of a Call and a Connection are also discussed in the ASON 225 architecture [G.8080] and [RFC4139]. This section is not intended as 226 a substitute for those documents, but is a brief summary of the key 227 terms and concepts. 229 4.1 What is a Call? 231 A Call is an agreement between endpoints possibly in cooperation with 232 the nodes that provide access to the network. Call setup may include 233 capability exchange, policy, authorization and security. 235 A Call is used to facilitate and manage a set of Connections that 236 provide end to end data services. While Connections require state to 237 be maintained at nodes along the data path within the network, Calls 238 do not involve the participation of transit nodes except to forward 239 the Call management requests as transparent messages. 241 A Call may be established and maintained independently of the 242 Connections that it supports. 244 4.2 A Hierarchy of Calls, Connections, Tunnels and LSPs 246 Clearly there is a hierarchical relationship between Calls and 247 Connections. One or more Connections may be associated with a Call. A 248 Connection may not be part of more than one Call. A Connection may, 249 however, exist without a Call. 251 In GMPLS RSVP-TE [RFC3473], a Connection is identified with a GMPLS 252 TE Tunnel. Commonly a Tunnel is identified with a single LSP, but it 253 should be noted that for protection, load balancing and many other 254 functions, a Tunnel may be supported by multiple parallel LSPs. The 255 following identification reproduces this hierarchy: 257 - Call IDs are unique within the context of the pair of addresses 258 that are the source and destination of the Call. 260 - Tunnel IDs are unique within the context of the Session (that is 261 the destination of the Tunnel). Applications may also find it 262 convenient to keep the Tunnel ID unique within the context of a 263 Call. 265 - LSP IDs are unique within the context of a Tunnel. 267 Note that the Call_ID value of zero is reserved and MUST NOT be used 268 during LSP-independent Call establishment. 270 Throughout the remainder of this document, the terms LSP and Tunnel 271 are used interchangeably with the term Connection. The case of a 272 Tunnel that is supported by more than one LSP is covered implicitly. 274 4.3 Exchanging Access Link Capabilities 276 It is useful for the ingress node of an LSP to know the link 277 capabilities of the link between the network and the egress node. 278 This information may allow the ingress node to tailor its LSP request 279 to fit those capabilities and to better utilize network resources 280 with regard to those capabilities. 282 In particular, this may be used to achieve end-to-end spectral 283 routing attribute negotiation for signal quality negotiation (such as 284 BER) in photonic environments where network edges are signal 285 regeneration capable. Similarly, it may be used to provide end-to-end 286 spatial routing attribute negotiation in multi-area routing 287 environments, in particular, when TE links have been bundled based on 288 technology specific attributes. 290 Call setup may provide a suitable mechanism to exchange information 291 for this purpose, although several other possibilities exist. 293 4.3.1 Network-initiated Calls 295 In this case, there may be no need to distribute additional link 296 capability information over and above the information distributed by 297 the TE and GMPLS extensions to the IGP. Further, it is possible that 298 future extensions to these IGPs will allow the distribution of more 299 detailed information including optical impairments. 301 4.3.2 User-initiated Calls 303 In this case, edge link information may not be visible within the 304 core network, nor (and specifically) at other edge nodes. This may 305 prevent an ingress from requesting suitable LSP characteristics to 306 ensure successful LSP setup. 308 Various solutions to this problem exist including the definition of 309 static TE links (that is, not advertised by a routing protocol) 310 between the core network and the edge nodes. Nevertheless, special 311 procedures may be necessary to advertise edge TE link information to 312 the edge nodes outside of the network without advertising the 313 information specific to the contents of the network. 315 In the future, when the requirements are understood on the 316 information that needs to be supported, TE extensions to EGPs may be 317 defined that provide this function. 319 4.3.3 Utilizing Call Setup 321 When IGP and EGP solutions are not available at the UNI, there is 322 still a requirement to have, at the local edge nodes, the knowledge 323 of the remote edge link capabilities. 325 The Call setup procedure provides an opportunity to discover edge 326 link capabilities of remote edge nodes before LSP setup is attempted. 327 The LINK CAPABILITY object is defined to allow this information to be 328 exchanged. The information that is included in this object is similar 329 to that distributed by GMPLS-capable IGPs (see [RFC4202]). 331 5. Protocol Extensions for Calls and Connections 333 This section describes the protocol extensions needed in support of 334 Call identification and management of Calls and Connections. 335 Procedures for the use of these protocol extensions are described in 336 Section 6. 338 5.1 Call Setup and Teardown 340 Calls are established independently of connections through the use of 341 the Notify message. The Notify message is a targeted message and does 342 not follow the path of LSPs through the network. 344 Simultaneous Call and connection establishment (sometimes referred to 345 as piggybacking) is not supported. 347 5.2 Call Identification 349 As soon as the concept of a Call is introduced, it is necessary to 350 support some means of identifying the Call. This becomes particularly 351 important when Calls and connections are separated and connections 352 must contain some reference to the Call. 354 A Call may be identified by a sequence of bytes that may have 355 considerable (but not arbitrary) length. A Call ID of 40 bytes would 356 not be unreasonable. It is not the place of this document to supply 357 rules for encoding or parsing Call IDs, but it must provide a 358 suitable means to communicate Call IDs within the protocol. The full 359 Call identification is referred to as the long Call ID. 361 The Call_ID is only relevant at the sender and receiver nodes. 362 Maintenance of this information in the signaling state is not 363 mandated at any intermediate node. Thus no change in [RFC3473] 364 transit implementations is required and there are no backward 365 compatibility issues. Forward compatibility is maintained by using 366 the existing default values to indicate that no Call processing is 367 required. 369 Further, the long Call ID is not required as part of the connection 370 (LSP) state even at the sender and receiver nodes so long as some 371 form of correlation is available. This correlation is provided 372 through the short Call ID. 374 5.2.1 Long Form Call Identification 376 The long Call ID is only required on the Notify message used to 377 establish the Call. It is carried in the "Session Name" field of the 378 SESSION_ATTRIBUTE Object on the Notify message. 380 A unique value per Call is inserted in the "Session Name" field by 381 the initiator of the Call. Subsequent network nodes MAY inspect this 382 object and MUST forward this object transparently across network 383 interfaces until reaching the egress node. Note that the structure of 384 this field MAY be the object of further formatting depending on the 385 naming convention(s). However, [RFC3209] defines the "Session Name" 386 field as a Null padded display string, and that any formatting 387 conventions for the Call ID must be limited to this scope. 389 5.2.2 Short Form Call Identification 391 The connections (LSPs) associated with a Call need to carry a 392 reference to the Call - the short Call ID. A new field is added to 393 the signaling protocol to identify an individual LSP with the Call to 394 which it belongs. 396 The new field is a 16-bit identifier (unique within the context of 397 the address pairing provided by the Tunnel_End_Point_Address and the 398 Sender_Address of the SENDER TEMPLATE object) that MUST be exchanged 399 on the Notify message during Call initialization and is used on all 400 subsequent LSP messages that are associated with the Call. This 401 identifier is known as the short Call ID and is encoded as described 402 in Section 5.2.3. The Call ID MUST NOT be used as part of the 403 processing to determine the session to which an RSVP signaling 404 message applies. This does not generate any backward compatibility 405 issue since the reserved field of the SESSION object defined in 406 [RFC3209] MUST NOT be examined on receipt. 408 In the unlikely case of short Call_ID exhaustion, local node policy 409 decides upon specific actions to be taken, but might include the use 410 of second Sender Address. Local policy details are outside of the 411 scope of this document. 413 5.2.3 Short Form Call ID Encoding 415 The short Call ID is carried in a 16-bit field in the SESSION object 416 carried on the Notify message used during Call setup, and on all 417 messages during LSP setup and management. The field used was 418 previously reserved (MUST be set to zero on transmission and ignored 419 on receipt). This ensures backward compatibility with nodes that do 420 not utilize Calls. 422 The figure below shows the new version of the object. 424 Class = SESSION, Class-Num = 1, C-Type = 7(IPv4)/8(IPv6) 426 0 1 2 3 427 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 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 ~ IPv4/IPv6 Tunnel end point address ~ 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | Call_ID | Tunnel ID | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | Extended Tunnel ID | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 IPv4/IPv6 Tunnel End Point Address: 32 bits/128 bits (see [RFC3209]) 438 Call_ID: 16 bits 440 A 16-bit identifier used in the SESSION object that remains 441 constant over the life of the Call. The Call_ID value MUST be 442 set to zero when there is no corresponding Call. 444 Tunnel ID: 16 bits (see [RFC3209]) 446 Extended Tunnel ID: 32 bits/128 bits (see [RFC3209]) 448 5.3 LINK_CAPABILITY object 450 The LINK CAPABILITY object is introduced to support link capability 451 exchange during Call setup and MAY be included in a Notify message 452 used for Call setup. This optional object includes the bundled link 453 local capabilities of the Call initiating node (or terminating node) 454 indicated by the source address of the Notify message. 456 The Class Number is selected so that the nodes that do not recognize 457 this object drop it silently. That is, the top bit is set and the 458 next bit is clear. 460 This object has the following format: 462 Class-Num = TBA (form 10bbbbbb), C_Type = 1 464 0 1 2 3 465 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 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | | 468 // (Subobjects) // 469 | | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 The contents of the LINK_CAPABILITY object is defined as series of 473 variable-length data items called subobjects. The subobject format is 474 defined in [RFC3209]. 476 The following subobjects are currently defined: 477 - Type 1: the link local IPv4 address (numbered bundle) using the 478 format defined in [RFC3209] 479 - Type 2: the link local IPv6 address (numbered bundle) using the 480 format defined in [RFC3209] 481 - Type 4: the link local identifier (unnumbered links and bundles) 482 using the format defined in [RFC3477] 483 - Type 64: the Maximum Reservable Bandwidth corresponding to this 484 bundle (see [RFC4201]) 485 - Type 65: the interface switching capability descriptor (see 486 [RFC4202]) corresponding to this bundle (see also [RFC4201]). 488 Note: future revisions of this document may extend the above list. 490 This object MAY also be used to exchange more than one bundled link 491 capability. In this case, the following ordering MUST be followed: 492 one identifier subobject (Type 1, 2 or 4) MUST be inserted before any 493 capability subobject (Type 64 or 65) to which it refers. 495 5.4 Revised Message Formats 497 The Notify message is enhanced to support Call establishment and 498 teardown of Calls. See Section 6 for a description of the procedures. 500 5.4.1 Notify Message 502 The Notify message is modified in support of Call establishment by 503 the optional addition of the LINK CAPABILTY object. Further, the 504 SESSION ATTRIBUTE object is added to the sequence to 505 carry the long Call ID. The presence of the SESSION ATTIBUTE object 506 MAY be used to distinguish a Notify message used for Call management, 507 but see Section 5.5 for another mechanism. The 508 MAY be used to simultaneously set up multiple Calls. 510 The format of the Notify Message is as follows: 512 ::= [ ] 513 [[ | ]...] 514 [ ] 515 516 518 ::= [ ] 520 ::= [ ] 521 [ ...] 522 [ ] 523 [ ] 524 [ | ] 526 ::= see [RFC3473] 528 ::= see [RFC3473] 530 5.5 ADMIN_STATUS Object 532 Notify messages exchanged for Call control and management purposes 533 carry a specific new bit (the Call Management or C bit) in the ADMIN 534 STATUS object. 536 The format and the contents of the ADMIN_STATUS object are both 537 dictated by [RFC3473] in favor of [RFC3471]. The new "C" bit is added 538 as shown below. 540 0 1 2 3 541 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 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 |R| Reserved |C|T|A|D| 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 Reflect (R): 1 bit - see [RFC3471] 546 Testing (T): 1 bit - see [RFC3471] 547 Administratively down (A): 1 bit - see [RFC3471] 548 Deletion in progress (D): 1 bit - see [RFC3471] 550 Call Management (C): 1 bit 552 This bit is set when the message is being used to control 553 and manage a Call. 555 The procedures for the use of the C bit are described in Section 6. 557 6. Procedures in Support of Calls and Connections 559 6.1 Call/Connection Setup Procedures 561 This section describes the processing steps for Call and connection 562 setup. 564 There are three cases considered: 566 - A Call is set up without any associated 567 Connection. It is assumed that Connections will be added to the 568 Call at a later time, but this is neither a requirement nor 569 a constraint. 571 - A Connection may be added to an existing Call. This may happen if 572 the Call was set up without any associated Connections, or if a 573 further Connection is added to a Call that already has one or more 574 associated Connections. 576 - A Connection may be established without any reference to a Call 577 (see Section 6.4). This encompasses the previous LSP setup 578 procedure. 580 Note that a Call MAY NOT be imposed upon a Connection that is already 581 established. To do so would require changing the short Call ID in the 582 SESSION OBJECT of the existing LSPs and this would constitute a 583 change in the Session Identifier. This is not allowed by existing 584 protocol specifications. 586 Call and Connection teardown procedures are described later in 587 Section 6.6. 589 6.2 Call Setup 591 A Call is set up before, and independent of, LSP (i.e. Connection) 592 setup. 594 Call setup MAY necessitate verification of the link status and link 595 capability negotiation between the Call ingress node and the Call 596 egress node. The procedure described below is applied only once for a 597 Call and hence only once for the set of LSPs associated with a Call. 599 The Notify message (see [RFC3473]) is used to signal the Call setup 600 request and response. The new Call Management (C) bit in the 601 ADMIN_STATUS object is used to indicate that this Notify is managing 602 a Call. The Notify message is sent with source and destination 603 IPv4/IPv6 addresses set to any of the routable ingress/egress node 604 addresses respectively. 606 At least one session MUST be listed in the of 607 the Notify message. In order to allow for long identification of the 608 Call the SESSION_ATTRIBUTE object is added as part of the . Note that the ERROR SPEC object is not relevant in 610 Call setup and MUST carry the Error Code zero ("Confirmation") to 611 indicate that there is no error. 613 During Call setup, the ADMIN STATUS object is sent with the following 614 bits set. Bits not listed MUST be set to zero. 616 R - to cause the egress to respond 617 C - to indicate that the Notify message is managing a Call. 619 The SESSION, SESSION ATTRIBUTE, SENDER_TEMPLATE, SENDER_TSPEC objects 620 included in the of the Notify message are built as 621 follows: 623 - The SESSION object includes as Tunnel_End_Point_Address any of the 624 call terminating (egress) node's IPv4/IPv6 routable addresses. The 625 Call_ID is set to a non-zero value unique within the context of 626 the address pairing provided by the Tunnel_End_Point_Address and 627 the Sender_Address from the SENDER TEMPLATE object (see below). 628 This value will be used as the short Call ID carried on all 629 messages for LSPs associated with this Call. 631 Note that the Call_ID value of zero is reserved and MUST NOT be 632 used since it will be present in SESSION objects of LSPs 633 that are not associated with Calls. The Tunnel_ID of 634 the SESSION object is not relevant for this procedure and SHOULD 635 be set to zero. The Extended_Tunnel_ID of the SESSION object is 636 not relevant for this procedure and MAY be set to zero or to an 637 address of the ingress node. 639 - The SESSION ATTRIBUTE object contains priority flags. Currently no 640 use of these flags is envisioned, however, future work may 641 identify value is assigning priorities to Calls; accordingly the 642 Priority fields MAY be set to non-zero values. None of the Flags 643 in the SESSION ATTRIBUTE object is relevant to this process and 644 this field SHOULD be set to zero. The Session Name field is used 645 to carry the long Call Id as described in Section 5. 647 - The SENDER_TEMPLATE object includes as Sender Address any of the 648 call initiating (ingress) node's IPv4/IPv6 routable addresses. The 649 LSP_ID is not relevant and SHOULD be set to zero. 651 - The bandwidth value inserted in the SENDER_TSPEC and FLOWSPEC 652 objects MUST be ignored upon receipt and SHOULD be set to zero 653 when sent. 655 Additionally, ingress/egress nodes that need to communicate their 656 respective link local capabilities may include a LINK_CAPABILITY 657 object in the Notify message. 659 The receiver of a Notify message may identify whether it is part of 660 Call management or reporting an error by the presence or absence of 661 the SESSION ATTRIUBTE object in the . Full 662 clarity, however, may be achieved by inspection of the new Call 663 Management (C) bit in the ADMIN STATUS object. 665 Note that the POLICY_DATA object may be included in the and MAY be used to identify requestor credentials, 667 account numbers, limits, quotas, etc. This object is opaque to RSVP, 668 which simply passes it to policy control when required. 670 Message IDs MUST be used during Call setup. 672 6.2.1 Accepting Call Setup 674 A node that receives a Notify message carrying the ADMIN STATUS 675 object with the R and C bits set is being requested to set up a Call. 676 The receiver MAY perform authorization and policy according to local 677 requirements. 679 If the Call is acceptable, the receiver responds with a Notify 680 message reflecting the information from the Call request with two 681 exceptions. 683 - The responder removes any LINK CAPABLITY object that was received 684 and MAY insert a LINK CAPABILITY object that describes its own 685 access link. 687 - The ADMIN STATUS object is sent with only the C bit set. All other 688 bits MUST be set to zero. 690 The responder MUST use the Message ID object to ensure reliable 691 delivery of the response. If no Message ID Acknowledgement is 692 received after the configured number of retries, the responder SHOULD 693 continue to assume that the Call was successfully established. Call 694 liveliness procedures are covered in Section 6.7. 696 6.2.2 Call Setup Failure and Rejection 698 Call setup may fail or be rejected. 700 If the Notify message can not be delivered, no Message ID 701 acknowledgement will be received by the sender. In the event that the 702 sender has retransmitted the Notify message a configurable number of 703 times without receiving a Message ID Acknowledgement (as described in 704 [RFC2961]), the initiator SHOULD declare the Call failed and SHOULD 705 send a Call teardown request (see Section 6.6). 707 It is also possible that a Message ID Acknowledgement is received but 708 no Call response Notify message is received. In this case, the 709 initiator MAY re-send the Call setup request a configurable number of 710 times (see Section 6.7) before declaring that the Call has failed. At 711 this point the initiator MUST send a Call teardown request (see 712 Section 6.6). 714 If the Notify message cannot be parsed or is in error it MAY be 715 responded to with a Notify message carrying the error code 13 716 ("Unknown object class") or 14 ("Unknown object C-Type") if 717 appropriate to the error detected. 719 The Call setup MAY be rejected by the receiver because of security, 720 authorization or policy reasons. Suitable error codes already exist 721 [RFC2205] and can be used in the ERROR SPEC object included in the 722 Notify message sent in response. 724 Error response Notify messages SHOULD also use the Message ID object 725 to achieve reliable delivery. No action should be taken on the 726 failure to receive a Message ID Acknowledgement after the configured 727 number of retries. 729 6.3 Adding a Connections to a Call 731 Once a Call has been established, LSPs can be added to the Call. 732 Since the short Call ID is part of the SESSION Object, any LSP that 733 has the same Call ID value in the SESSION Object belongs to the same 734 Call, and the Notify message used to establish the Call carried the 735 same Call ID in its SESSION object. 737 There will be no confusion between LSPs that are associated with a 738 Call and those which are not since the Call ID value MUST be equal to 739 zero for LSPs which are not associated with a Call, and MUST NOT be 740 equal to zero for a valid Call ID. 742 LSPs for different Calls can be distinguished because the Call ID is 743 unique within the context of the source address (in the SENDER 744 TEMPLATE object) and the destination address (in the SESSION object). 746 Ingress and egress nodes MAY group together LSPs associated with the 747 same Call and process them as a group according to implementation 748 requirements. Transit nodes need not be aware of the association of 749 multiple LSPs with the same Call. 751 The ingress node MAY choose to set the "Session Name" of an LSP to 752 match the long Call ID of the associated Call. 754 The C bit of the ADMIN STATUS object MUST NOT be set on LSP messages 755 including on Notify messages that pertain to the LSP and MUST be 756 ignored. 758 6.3.1 Adding a Reverse Direction LSP to a Call 760 Note that once a Call has been established it is symmetric. That is, 761 either end of the Call may add LSPs to the Call. 763 Special care is needed when managing LSPs in the reverse direction 764 since the addresses in the SESSION and SENDER TEMPLATE are reversed. 765 However, since the short Call ID is unique in the context of a given 766 ingress-egress address pair it may safely be used to associate the 767 LSP with the Call. 769 Note that since Calls are defined here to be symmetrical the issue of 770 potential Call ID collision arises. This is discussed in Section 6.5. 772 6.4 Call-Free Connection Setup 774 It continues to be possible to set up LSPs as per [RFC3473] without 775 associating them with a Call. If the short Call ID in the SESSION 776 Object is set to zero, there is no associated Call and the Session 777 Name field in the SESSION ATTRIBUTE object MUST be interpreted simply 778 as the name of the session (see [RFC3209]). 780 The C bit of the ADMIN STATUS object MUST NOT be set on messages for 781 LSP control, including on Notify messages that pertain to LSPs, and 782 MUST be ignored when received on such messages. 784 6.5 Call Collision 786 Since Calls are symmetrical, it is possible that both ends of a Call 787 will attempt to establish Calls with the same long Call IDs at the 788 same time. This is only an issue if the source and destination 789 address pairs match. This situation can be avoided by applying some 790 rules to the contents of the long Call ID, but such mechanisms are 791 outside the scope of this document. 793 If a node that has sent a Call setup request and has not yet received 794 a response, itself receives a Call setup request with the same long 795 Call ID and matching source/destination addresses it SHOULD process 796 as follows. 798 - If its source address is numerically greater than the remote 799 source address, it MUST discard the received message and continue 800 to wait for a response to its setup request. 802 - If its source address is numerically smaller than the remote 803 source address, it MUST discard state associated with the Call 804 setup that it initiated, and MUST respond to the received Call 805 setup. 807 If a node receives a Call setup request carrying an address pair and 808 long Call ID that match an existing Call, the node MUST return an 809 error message (Notify message) with the new Error Code "Call 810 Management" and the new Error Value "Duplicate Call" in response to 811 the new Call request, and MUST NOT make any changes to the existing 812 Call. 814 A further possibility for contention arises when short Call IDs are 815 assigned by a pair of nodes for two distinct Calls that are set up 816 simultaneously using different long Call IDs. In this event a node 817 receives a Call setup request carrying a short Call ID that matches 818 one that it previously sent for the same address pair. The following 819 processing MUST be followed. 821 - If the receiver's source address is numerically greater than the 822 remote source address, the receiver returns an error (Notify 823 message) with the new Error Code "Call Management" and the new 824 Error Value "Call ID Contention". 826 - If the receiver's source address is numerically less than the 827 remote source address, the receiver accepts and processes the Call 828 request. It will receive an error message sent as described above, 829 and at that point it selects a new short Call ID and re-sends the 830 Call setup request. 832 6.6 Call/Connection Teardown 834 As with Call/Connection setup, there are several cases to consider. 836 - Removal of a Connection from a Call 837 - Removal of the last Connection from a Call 838 - Teardown of an "empty" Call 840 The case of tearing down an LSP that is not associated with a Call 841 does not need to be examined as it follows exactly the procedures 842 described in [RFC3473]. 844 6.6.1 Removal of a Connection from a Call 846 An LSP that is associated with a Call may be deleted using the 847 standard procedures described in [RFC3743]. No special procedures are 848 required. 850 Note that it is not possible to remove an LSP from a Call without 851 deleting the LSP. It is not valid to change the short Call ID from 852 non-zero to zero since this involves a change to the SESSION object, 853 which is not allowed. 855 6.6.2 Removal of the Last Connection from a Call 857 When the last LSP associated with a Call is deleted the question 858 arises as to what happens to the Call. Since a Call may exist 859 independently of Connections, it is not always acceptable to say that 860 the removal of the last LSP from a Call removes the Call. 862 The removal of the last LSP does not remove the Call and the 863 procedures described in the next Section MUST be used to delete the 864 Call. 866 6.6.3 Teardown of an "Empty" Call 868 When all LSPs have been removed from a Call, the Call may be torn 869 down or left for use by future LSPs. 871 Deletion of Calls is achieved by sending a Notify message just as for 872 Call setup, but the ADMIN STATUS object carries the R, D and C bits 873 on the teardown request and the D and C bits on the teardown 874 response. Other bits MUST be set to zero. 876 When a Notify message is sent for deleting a Call and the initiator 877 does not receive the corresponding reflected Notify message (or 878 possibly even the Message ID Ack), the initiator MAY retry the 879 deletion request using the same retry procedures as used during Call 880 establishment. If no response is received after full retry, the node 881 deleting the Call MAY declare the Call deleted, but under such 882 circumstances the node SHOULD avoid re-using the long or short Call 883 IDs for at least the five times the Notify refresh period. 885 6.6.4 Attempted Teardown of a Call with Existing Connections 887 If a Notify request with the D bit of the ADMIN STATUS object set is 888 received for a Call for which LSPs still exist, the request MUST be 889 rejected with the Error Code "Call Management" and Error Value 890 "Connections Still Exist". The state of the Call MUST NOT be changed. 892 6.6.5 Teardown of a Call from the Egress 894 Since Calls are symmetric they may be torn down from the ingress or 895 egress. 897 When the Call is "empty" (has no associated LSPs) it may be deleted 898 by the egress sending a Notify message just as described above. 900 Note that there is a possibility that both ends of a Call initiate 901 Call deletion at the same time. In this case, the Notify message 902 acting as teardown request MAY be interpreted by its recipient as a 903 teardown response. But since the Notify messages acting as teardown 904 requests carry the R bit in the ADMIN STATUS object, they MUST be 905 responded to anyway. If a teardown request Notify message is received 906 for an unknown Call ID it is, nevertheless, responded to in the 907 affirmative. 909 6.7 Control Plane Survivability 911 Delivery of Notify messages is secured using message ID 912 acknowledgements as described in previous sections. 914 Notify messages provide end-to-end communication that does not rely 915 on constant paths through the network. Notify messages are routed 916 according to IGP routing information. No consideration is, therefore, 917 required for network resilience (for example, make-before-break, 918 protection, fast re-route), although end-to-end resilience is of 919 interest for node restart and completely disjoint networks. 921 Periodic Notify messages SHOULD be sent by the initiator and 922 terminator of the Call to keep the Call alive and to handle ingress 923 or egress node restart. The time period for these retransmissions is 924 a local matter, but it is RECOMMENDED that this period should be 925 twice the shortest refresh period of any LSP associated with the 926 Call. When there are no LSPs associated with a Call, an LSR is 927 RECOMMENDED to use a refresh period of no less than one minute. The 928 Notify messages are identical to those sent as if establishing the 929 Call for the first time, except for the LINK CAPABILITY object, which 930 may have changed since the Call was first established, due to, e.g., 931 the establishment of connections, link failures, and the addition of 932 new component links. The current link information is useful for the 933 establishment of subsequent connections. A node that receives a 934 refresh Notify message carrying the R bit in the ADMIN STATUS object 935 MUST respond with a Notify response. A node that receives a refresh 936 Notify message (response or request) MAY reset its timer - thus, in 937 normal processing, Notify refreshes involve a single exchange once 938 per time period. 940 A node (sender or receiver) that is unsure of the status of a Call 941 MAY immediately send a Notify message as if establishing the Call for 942 the first time. 944 Failure to receive a refresh Notify request has no specific meaning. 945 A node that fails to receive a refresh Notify request MAY send its 946 own refresh Notify request to establish the status of the call. If an 947 LSR receives no response to a refresh Notify request (including no 948 Message ID Acknowledgement) a node MAY assume that the remote node is 949 unreachable or unavailable. It is a local policy matter whether this 950 causes the local node to teardown associated LSPs and delete the 951 Call. 953 In the event that an edge node restarts without preserved state, it 954 MAY relearn LSP state from adjacent nodes and Call state from remote 955 nodes. If a Path or Resv message is received with a non-zero Call ID 956 but without the C bit in the ADMIN STATUS, and for a Call ID that is 957 not recognized, the receiver is RECOMMENDED to assume that the Call 958 establishment is delayed and ignore the received message. If the Call 959 setup never materializes the failure by the restarting node to 960 refresh state will cause the LSPs to be torn down. Optionally, the 961 receiver of such an LSP message for an unknown Call ID may return an 962 error (PathErr or ResvErr message) with the error code "Call 963 Management" and Error Value "Unknown Call ID". 965 7. Applicability of Call and Connection Procedures 967 This section considers the applicability of the different Call 968 establishment procedures at the NNI and UNI reference points. This 969 section is informative and is not intended to prescribe or prevent 970 other options. 972 7.1 Network-initiated Calls 974 Since the link properties and other traffic-engineering attributes 975 are likely known through the IGP, the LINK CAPABILITY object is not 976 usually required. 978 In multi-domain networks it is possible that access link properties 979 and other traffic-engineering attributes are not known since the 980 domains do not share this sort of information. In this case, the Call 981 setup mechanism may include the LINK CAPABILITY object. 983 7.2 User-initiated Calls 985 It is possible that the access link properties and other traffic- 986 engineering attributes are not shared across the core network. In 987 this case, the Call setup mechanism may include the LINK CAPABILITY 988 object. 990 Further, the first node within the network may be responsible for 991 managing the Call. In this case, the Notify message that is used to 992 set up the Call is addressed by the user network edge node to the 993 first node of the core network. Moreover, neither the long Call ID 994 nor the short Call ID is supplied (the Session Name Length is set to 995 zero and the Call ID value is set to zero). The Notify message is 996 passed to the first network node which is responsible for generating 997 the long and short Call IDs before dispatching the message to the 998 remote Call end point (which is known from the SESSION object). 1000 Further, when used in an overlay context, the first core node is 1001 allowed (see [RFC4208]) to replace the Session Name assigned by the 1002 ingress node and passed in the Path message. In the case of Call 1003 management, the first network node: 1004 1) MAY insert a long Call ID in the Session Name of a Path message 1005 2) MUST replace the Session Name with that originally issued by the 1006 user edge node when it returns the Resv message to the ingress node. 1008 7.3 External Call Managers 1010 Third party Call management agents may be used to apply policy and 1011 authorization at a point that is neither the initiator nor terminator 1012 of the Call. The previous example is a particular case of this, but 1013 the process and procedures are identical. 1015 7.3.1 Call Segments 1017 Call Segments exist between a set of default and configured External 1018 Call Managers along a path between the ingress and egress nodes, and 1019 use the protocols described in this document. 1021 The techniques that are used by a given service provider to identify 1022 which External Call Managers within its network should process a 1023 given call are beyond the scope of this document. 1025 An External Call Manager uses normal IP routing to route the Notify 1026 message to the next External Call Manager. Notify messages (requests 1027 and responses) are therefore encapsulated in IP packets that identify 1028 the sending and receiving External Call Managers, but the addresses 1029 used to identify the Call (the Sender Address in the SENDER TEMPLATE 1030 object and the Tunnel Endpoint Address in the SESSION object) 1031 continue to identify the endpoints of the Call. 1033 8. Non-support of Call ID 1035 It is important that the procedures described above operate as 1036 seamlessly as possible with legacy nodes that do not support the 1037 extensions described. 1039 Clearly there is no need to consider the case where the Call 1040 initiator does not support Call setup initiation. 1042 8.1 Non-Support by External Call Managers 1044 It is unlikely that a Call initiator will be configured to send Call 1045 establishment Notify requests to an external Call manager including 1046 the first network node, if that node does not support Call setup. 1048 A node that receives an unexpected Call setup request will fall into 1049 one of the following categories. 1051 - Node does not support RSVP. The message will fail to be delivered 1052 or responded. No Message ID Acknowledgement will be sent. The 1053 initiator will retry and then give up. 1055 - Node supports RSVP or RSVP-TE but not GMPLS. The message will be 1056 delivered but not understood. It will be discarded. No Message ID 1057 Acknowledgement will be sent. The initiator will retry and then 1058 give up. 1060 - Node supports GMPLS but not Call management. The message will be 1061 delivered, but parsing will fail because of the presence of the 1062 SESSION ATTRIBUTE object. A Message ID Acknowledgement may be sent 1063 before the parse fails. When the parse fails the Notify message 1064 may be discarded in which case the initiator will retry and then 1065 give up, alternatively a parse error may be generated and returned 1066 in a Notify message which will indicate to the initiator that Call 1067 management is not supported. 1069 8.2 Non-Support by Transit Node 1071 Transit nodes SHOULD not examine Notify messages that are not 1072 addressed to them. However, they will see short Call IDs in all LSPs 1073 associated with Calls. 1075 Previous specifications state that these fields SHOULD be ignored on 1076 receipt and MUST be transmitted as zero. This is interpreted by some 1077 implementations as meaning that the fields should be zeroed before 1078 the objects are forwarded. If this happens, LSP setup will not be 1079 possible. If either of the fields is zeroed either on the Path or the 1080 Resv message, the Resv message will reach the initiator with the 1081 field set to zero - this is indication to the initiator that some 1082 node in the network is preventing Call management. Use of Explicit 1083 Routes may help to mitigate this issue by avoiding such nodes. 1084 Ultimately, however, it may be necessary to upgrade the offending 1085 nodes to handle these protocol extensions. 1087 8.3 Non-Support by Egress Node 1089 It is unlikely that an attempt will be made to set up a Call to 1090 remote node that does not support Calls. 1092 If the egress node does not support Call management through the 1093 Notify message it will react (as described in Section 8.1) in the 1094 same way as an External Call Manager. 1096 9. Security Considerations 1098 Please refer to each of the referenced documents for a description of 1099 the security considerations applicable to the features that they 1100 provide. 1102 9.1 Call and Connection Security Considerations 1104 Call setup is vulnerable to attacks both of spoofing and denial of 1105 service. Since Call setup uses Notify messages, the process can be 1106 protected by the measures applicable to securing those messages as 1107 described in [RFC3473]. 1109 Note, additionally, that the process of Call establishment 1110 independent of LSP setup may be used to apply an extra level of 1111 authentication and policy to hop-by-hop LSP setup. It may be possible 1112 to protect the Call setup exchange using end-to-end security 1113 mechanisms such as those provided by Insect (see [RFC2402] and 1114 [RFC2406]). 1116 10. IANA Considerations 1118 10.1 RSVP Objects 1120 A new RSVP object is introduced: 1122 o LINK CAPABILITY object 1124 Class-Num = TBA (form 10bbbbbb) 1126 The Class Number is selected so that nodes not recognizing 1127 this object drop it silently. That is, the top bit is set 1128 and the next bit is cleared. 1130 C-Type = 1 (TE Link Capabilities) 1132 The LINK CAPABILITY object is only defined for inclusion on Notify 1133 messages. 1135 Refer to Section 5.3 of this document. 1137 10.2 RSVP Error Codes and Error Values 1139 New RSVP Error Codes and Error Values are introduced 1141 o Error Codes: 1143 - Call Management (value TBA) 1145 o Error Values: 1147 - Call Management/Call ID Contention (value TBA) 1148 - Call Management/Connections still Exist (value TBA) 1149 - Call Management/Unknown Call ID (value TBA) 1150 - Call Management/Duplicate Call (value TBA) 1152 10.3 RSVP ADMIN_STATUS object Bits 1154 [GMPLS-E2E] requests IANA to manage the bits of the RSVP ADMIN_STATUS 1155 object. 1157 One new bit, the C bit, is defined in this document. Bit number 28 is 1158 suggested. 1160 See Section 5.5 of this document. 1162 11. Acknowledgements 1164 The authors would like to thank George Swallow, Yakov Rekhter, 1165 Lou Berger, Jerry Ash and Kireeti Kompella for their very useful 1166 input to and comments on an earlier revision of this document. 1168 12. References 1170 12.1 Normative References 1172 [GMPLS-E2E] Lang, J.P., Rekhter, Y., and D. Papadimitriou, "RSVP- 1173 TE Extensions in support of End-to-End Generalized 1174 Multi-Protocol Label Switching (GMPLS)-based Recovery," 1175 draft-ietf-ccamp-gmpls-recovery-e2e-signaling, work in 1176 progress. 1178 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 1179 Requirement Levels," BCP 14, RFC 2119, March 1997. 1181 [RFC2205] R. Braden et al., "Resource ReSerVation Protocol 1182 (RSVP)- Version 1 Functional Specification," 1183 RFC 2205, September 1997. 1185 [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header," 1186 RFC 2402, November 1998. 1188 [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Payload 1189 (ESP)," RFC 2406, November 1998. 1191 [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, 1192 F. and S. Molendini, "RSVP Refresh Overhead 1193 Reduction Extensions", RFC 2961, April 2001. 1195 [RFC3209] D. Awduche et al., "RSVP-TE: Extensions to RSVP for 1196 LSP Tunnels," RFC 3209, December 2001. 1198 [RFC3471] L. Berger (Editor) et al., "Generalized MPLS - 1199 Signaling Functional Description," RFC 3471, January 1200 2003. 1202 [RFC3473] L. Berger (Editor) et al., "Generalized MPLS 1203 Signaling - RSVP-TE Extensions," RFC 3473, January 1204 2003. 1206 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered 1207 Links in Resource ReSerVation Protocol - Traffic 1208 Engineering (RSVP-TE)," RFC 3477, January 2003. 1210 [RFC3945] E. Mannie, Ed., "Generalized Multi-Protocol Label 1211 Switching (GMPLS) Architecture", RFC 3945, October 1212 2004. 1214 [RFC4139] D. Papadimitriou, et al., "Requirements for 1215 Generalized MPLS (GMPLS) Signaling Usage and 1216 Extensions for Automatically Switched Optical 1217 Network (ASON)," RFC 4139, July 2005. 1219 [RFC4201] Kompella K., Rekhter Y., and L. Berger, "Link Bundling 1220 in MPLS Traffic Engineering," RFC 4201, October 2005. 1222 [RFC4202] Kompella, K. and Y. Rekhter (Editors) et al., "Routing 1223 Extensions in Support of Generalized MPLS," RFC 4202, 1224 October 2005. 1226 [RFC4208] G. Swallow et al., "GMPLS RSVP Support for the Overlay 1227 Model," RFC 4208, October 2005. 1229 [RFC4426] Lang, J.P., and B. Rajagopalan (Editors) et al., 1230 "Generalized MPLS Recovery Functional 1231 Specification," RFC 4426, March 2006. 1233 12.2 Informative References 1235 [ASON-APPL] D. Papadimitriou et. al., "Generalized MPLS (GMPLS) 1236 RSVP-TE signaling usage in support of Automatically 1237 Switched Optical Network (ASON)," 1238 draft-ietf-ccamp-gmpls-rsvp-te-ason, work in progress. 1240 For information on the availability of the following document, 1241 please see http://www.itu.int. 1243 [G.8080] ITU-T, "Architecture for the Automatically Switched 1244 Optical Network (ASON)," Recommendation G.8080/ 1245 Y.1304, November 2001 (and Revision, January 2003). 1247 13. Authors' Addresses 1249 Dimitri Papadimitriou (Alcatel) 1250 Fr. Wellesplein 1, 1251 B-2018 Antwerpen, Belgium 1252 Phone: +32 3 240-8491 1253 EMail: dimitri.papadimitriou@alcatel.be 1255 John Drake 1256 Boeing Satellite Systems 1257 2300 East Imperial Highway 1258 El Segundo, CA 90245 1259 EMail: John.E.Drake2@boeing.com 1261 Adrian Farrel 1262 Old Dog Consulting 1263 Phone: +44 (0) 1978 860944 1264 EMail: adrian@olddog.co.uk 1266 Deborah Brungard (AT&T) 1267 Rm. D1-3C22 - 200 S. Laurel Ave. 1268 Middletown, NJ 07748, USA 1269 EMail: dbrungard@att.com 1271 Zafar Ali (Cisco) 1272 100 South Main St. #200 1273 Ann Arbor, MI 48104, USA 1274 EMail: zali@cisco.com 1276 Arthi Ayyangar (Juniper) 1277 1194 N.Mathilda Ave 1278 Sunnyvale, CA 94089, USA 1279 EMail: arthi@juniper.net 1280 Don Fedyk (Nortel Networks) 1281 600 Technology Park Drive 1282 Billerica, MA, 01821, USA 1283 Email: dwfedyk@nortel.com 1285 Intellectual Property Statement 1287 The IETF takes no position regarding the validity or scope of any 1288 Intellectual Property Rights or other rights that might be claimed to 1289 pertain to the implementation or use of the technology described in 1290 this document or the extent to which any license under such rights 1291 might or might not be available; nor does it represent that it has 1292 made any independent effort to identify any such rights. Information 1293 on the procedures with respect to rights in RFC documents can be 1294 found in BCP 78 and BCP 79. 1296 Copies of IPR disclosures made to the IETF Secretariat and any 1297 assurances of licenses to be made available, or the result of an 1298 attempt made to obtain a general license or permission for the use of 1299 such proprietary rights by implementers or users of this 1300 specification can be obtained from the IETF on-line IPR repository at 1301 http://www.ietf.org/ipr. 1303 The IETF invites any interested party to bring to its attention any 1304 copyrights, patents or patent applications, or other proprietary 1305 rights that may cover technology that may be required to implement 1306 this standard. Please address the information to the IETF at ietf- 1307 ipr@ietf.org. 1309 Disclaimer of Validity 1311 This document and the information contained herein are provided on an 1312 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1313 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1314 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1315 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1316 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1317 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1319 Copyright Statement 1321 Copyright (C) The Internet Society (2006). This document is subject 1322 to the rights, licenses and restrictions contained in BCP 78, and 1323 except as set forth therein, the authors retain all their rights.