idnits 2.17.1 draft-ietf-ccamp-gmpls-rsvp-te-call-04.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, updated by RFC 4748 on line 1498. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1475. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1482. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1488. 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 IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 2007) is 6305 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) ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group D. Papadimitriou (Alcatel) 2 Internet Draft A. Farrel (Old Dog Consulting) 3 Updates RFC 3473 4 Proposed Category: Standard Track 5 Expiration Date: July 2007 January 2007 7 Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions 8 in support of Calls 10 draft-ietf-ccamp-gmpls-rsvp-te-call-04.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 Papadimitriou and Farrel January 2007 56 Table of Content 58 1. Conventions used in this document ............................. 3 59 2. Introduction .................................................. 3 60 2.1 Applicability to ASON ........................................ 4 61 3. Requirements .................................................. 4 62 3.1 Basic Call Function .......................................... 4 63 3.2 Call/Connection Separation ................................... 4 64 3.3 Call Segments ................................................ 5 65 4. Concepts and Terms ............................................ 5 66 4.1 What is a Call? .............................................. 5 67 4.2 A Hierarchy of Calls, Connections, Tunnels and LSPs .......... 5 68 4.3 Exchanging Access Link Capabilities .......................... 6 69 4.3.1 Network-initiated Calls .................................... 7 70 4.3.2 User-initiated Calls ....................................... 7 71 4.3.3 Utilizing Call Setup ....................................... 7 72 5. Protocol Extensions for Calls and Connections ................. 8 73 5.1 Call Setup and Teardown ...................................... 8 74 5.2 Call Identification .......................................... 8 75 5.2.1 Long Form Call Identification .............................. 9 76 5.2.2 Short Form Call Identification ............................. 9 77 5.2.3 Short Form Call ID Encoding ................................ 9 78 5.3 LINK_CAPABILITY object ...................................... 10 79 5.4 Revised Message Formats ..................................... 11 80 5.4.1 Notify Message ............................................ 21 81 5.5 ADMIN_STATUS Object ......................................... 21 82 6. Procedures in Support of Calls and Connections ............... 32 83 6.1 Call/Connection Setup Procedures ............................ 32 84 6.2 Call Setup .................................................. 32 85 6.2.1 Accepting Call Setup ...................................... 54 86 6.2.2 Call Setup Failure and Rejection .......................... 65 87 6.3 Adding a Connections to a Call .............................. 65 88 6.3.1 Adding a Reverse Direction LSP to a Call .................. 76 89 6.4 Call-Free Connection Setup .................................. 76 90 6.5 Call Collision .............................................. 76 91 6.6 Call/Connection Teardown .................................... 87 92 6.6.1 Removal of a Connection from a Call ....................... 98 93 6.6.2 Removal of the Last Connection from a Call ................ 98 94 6.6.3 Teardown of an "Empty" Call ............................... 98 95 6.6.4 Attempted Teardown of a Call with Existing Connections .... 98 96 6.6.5 Teardown of a Call from the Egress ........................ 20 97 6.7 Control Plane Survivability ................................. 20 98 7. Applicability of Call and Connection Procedures .............. 21 99 7.1 Network-initiated Calls ..................................... 21 100 7.2 User-initiated Calls ........................................ 21 101 7.3 External Call Managers ...................................... 22 102 7.3.1 Call Segments ............................................. 22 103 8. Non-support of Call ID ....................................... 22 104 8.1 Non-Support by External Call Managers ....................... 23 105 8.2 Non-Support by Transit Node ................................. 23 107 Papadimitriou and Farrel January 2007 109 8.3 Non-Support by Egress Node .................................. 24 110 9. Security Considerations ...................................... 24 111 9.1 Call and Connection Security Considerations ................. 24 112 10. IANA Considerations ......................................... 25 113 10.1 RSVP Objects ............................................... 25 114 10.2 RSVP Error Codes and Error Values .......................... 25 115 10.3 RSVP ADMIN_STATUS object Bits .............................. 26 116 11. Acknowledgements ............................................ 26 117 12. References .................................................. 26 118 12.1 Normative References ....................................... 26 119 12.2 Informative References ..................................... 27 120 13. Contact Addresses ........................................... 28 121 14. Authors' Addresses .......................................... 28 123 1. Conventions used in this document 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in [RFC2119]. 129 In addition, the reader is assumed to be familiar with the 130 terminology used in [RFC3471], [RFC3473], [RFC3477] and [RFC3945]. 132 2. Introduction 134 This document defines protocol procedures and extensions to support 135 Calls within Generalized MPLS (GMPLS). 137 A Call is an association between endpoints and possibly between key 138 transit points (such as network boundaries) in support of an instance 139 of a service. The end-to-end association is termed a "Call," and the 140 association between two transit points or between an endpoint and a 141 transit point is termed a "Call Segment." An entity that processes a 142 Call or Call Segment is called a "Call Manager." 144 A Call does not provide the actual connectivity for transmitting user 145 traffic, but only builds a relationship by which subsequent 146 Connections may be made. In GMPLS such Connections are known as Label 147 Switched Paths (LSPs). This document does not modify Connection setup 148 procedures defined in [RFC3473], [RFC4208] and [STITCH]. Connections 149 set up as part of a Call follow the rules defined in these documents. 151 A Call may be associated with zero, one, or more than one Connection, 152 and a Connection may be associated with zero or one Call. Thus full 153 and logical Call/Connection separation is needed. 155 An example of the requirement for Calls can be found in the ITU-T's 156 Automatically Switched Optical Network (ASON) architecture [G.8080] 157 and specific requirements for support of Calls in this context can be 158 found in [RFC4139]. Note, however, that while the mechanisms 160 Papadimitriou and Farrel January 2007 162 described in this document meet the requirements stated in [RFC4139], 163 they have wider applicability. 165 The mechanisms defined in this document are equally applicable to any 166 packet (PSC) interface, layer-2 interfaces (L2SC), TDM capable 167 interfaces, LSC interfaces, or FSC interfaces. The mechanisms and 168 protocol extensions are backward compatible, and can be used for Call 169 management where only the Call Managers need to be aware of the 170 protocol extensions. 172 2.1 Applicability to ASON 174 [RFC4139] details the requirements on GMPLS signaling to satisfy the 175 ASON architecture described in [G.8080]. The mechanisms described in 176 this document meet the requirements for Calls as described in 177 Sections 4.2 and 4.3 of [RFC4139] and the additional Call-related 178 requirements in Sections 4.4, 4.7, 5 and 6 of [RFC4139]. 180 [ASON-APPL] describes the applicability of GMPLS protocols to the 181 ASON architecture. 183 3. Requirements 185 3.1 Basic Call Function 187 The Call concept is used to deliver the following capabilities. 189 - Verification and identification of the Call initiator (prior to 190 LSP setup). 192 - Support of virtual concatenation with diverse path component LSPs. 194 - Association of multiple LSPs with a single Call (note aspects 195 related to recovery are detailed in [RFC4426] and [GMPLS-E2E]). 197 - Facilitation of control plane operations by allowing operational 198 status change of the associated LSP. 200 Procedures and protocol extensions to support Call setup, and the 201 association of Calls with Connections are described in Section 5 and 202 onwards of this document. 204 3.2 Call/Connection Separation 206 Full and logical Call and Connection separation is required. That is: 208 - It MUST be possible to establish a Connection without dependence 209 on a Call. 211 Papadimitriou and Farrel January 2007 213 - It MUST be possible to establish a Call without any associated 214 Connections. 216 - It MUST be possible to associate more than one Connection with a 217 Call. 219 - Removal of the last Connection associated with a Call SHOULD NOT 220 result in the automatic removal of the Call except as a matter of 221 local policy at the ingress of the Call. 223 - Signaling of a Connection associated with a Call MUST NOT require 224 the distribution or retention of Call-related information (state) 225 within the network. 227 3.3 Call Segments 229 Call Segment capabilities MUST be supported. 231 Procedures and (GMPLS) RSVP-TE signaling protocol extensions to 232 support Call Segments are described in Section 7.3.1 of this 233 document. 235 4. Concepts and Terms 237 The concept of a Call and a Connection are also discussed in the ASON 238 architecture [G.8080] and [RFC4139]. This section is not intended as 239 a substitute for those documents, but is a brief summary of the key 240 terms and concepts. 242 4.1 What is a Call? 244 A Call is an agreement between endpoints possibly in cooperation with 245 the nodes that provide access to the network. Call setup may include 246 capability exchange, policy, authorization and security. 248 A Call is used to facilitate and manage a set of Connections that 249 provide end to end data services. While Connections require state to 250 be maintained at nodes along the data path within the network, Calls 251 do not involve the participation of transit nodes except to forward 252 the Call management requests as transparent messages. 254 A Call may be established and maintained independently of the 255 Connections that it supports. 257 4.2 A Hierarchy of Calls, Connections, Tunnels and LSPs 259 Clearly there is a hierarchical relationship between Calls and 260 Connections. One or more Connections may be associated with a Call. A 261 Connection may not be part of more than one Call. A Connection may, 262 however, exist without a Call. 264 Papadimitriou and Farrel January 2007 266 In GMPLS RSVP-TE [RFC3473], a Connection is identified with a GMPLS 267 TE Tunnel. Commonly a Tunnel is identified with a single LSP, but it 268 should be noted that for protection, load balancing and many other 269 functions, a Tunnel may be supported by multiple parallel LSPs. The 270 following identification reproduces this hierarchy. 272 - Call IDs are unique within the context of the pair of addresses 273 that are the source and destination of the Call. 275 - Tunnel IDs are unique within the context of the Session (that is 276 the destination of the Tunnel). Applications may also find it 277 convenient to keep the Tunnel ID unique within the context of a 278 Call. 280 - LSP IDs are unique within the context of a Tunnel. 282 Note that the Call_ID value of zero is reserved and MUST NOT be used 283 during LSP-independent Call establishment. 285 Throughout the remainder of this document, the terms LSP and Tunnel 286 are used interchangeably with the term Connection. The case of a 287 Tunnel that is supported by more than one LSP is covered implicitly. 289 4.3 Exchanging Access Link Capabilities 291 In an overlay model, it is useful for the ingress node of an LSP to 292 know the link capabilities of the link between the network and the 293 remote overlay network. In the language of [RFC4208], the ingress 294 node can make use of information about the link between the egress 295 network node (NN) and the remote edge node (EN). We call this link 296 the egress network link. This information may allow the ingress node 297 to tailor its LSP request to fit those capabilities and to better 298 utilize network resources with regard to those capabilities. 300 For example, this might be used in transparent optical networks to 301 supply information on lambda availability on egress network links, 302 or, where the egress NN is capable of signal regeneration, it might 303 provide a mechanism for negotiating signal quality attributes (such 304 as bit error rate). Similarly, in multi-domain routing environments 305 it could be used to provide end-to-end selection of component links 306 (i.e., spatial attribute negotiation) where TE links have been 307 bundled based on technology specific attributes. 309 In some circumstances, the Traffic Engineering Database (TED) may 310 contain sufficient information for decisions to be made about which 311 egress network link to use. In other circumstances, the TED might not 312 contain this information and Call setup may provide a suitable 313 mechanism to exchange information for this purpose. The 314 Call-responder may use the Call parameters to select a subset of the 315 available egress network links between the egress NN and the remote 317 Papadimitriou and Farrel January 2007 319 EN, and may report these links and their capabilities on the Call 320 response so that the Call-initiator may select a suitable link. 322 The sections that follow indicate the cases where the TED may be 323 used, and those where Call parameter exchange may be appropriate. 325 4.3.1 Network-initiated Calls 327 Network-initiated Calls arise when the ingress (and correspondingly 328 the egress) lie within the network and there may be no need to 329 distribute additional link capability information over and above the 330 information distributed by the TE and GMPLS extensions to the IGP. 331 Further, it is possible that future extensions to these IGPs will 332 allow the distribution of more detailed information including optical 333 impairments. 335 4.3.2 User-initiated Calls 337 User-initiated Calls arise when the ingress (and correspondingly the 338 egress) lie outside the network. Edge link information may not be 339 visible within the core network, nor (and specifically) at other edge 340 nodes. This may prevent an ingress from requesting suitable LSP 341 characteristics to ensure successful LSP setup. 343 Various solutions to this problem exist, including the definition of 344 static TE links (that is, not advertised by a routing protocol) 345 between the NNs and ENs. Nevertheless, special procedures may be 346 necessary to advertise to the edge nodes outside of the network 347 information about egress network links without also advertising the 348 information specific to the contents of the network. 350 In the future, when the requirements on the information that needs to 351 be supported are better understood, TE extensions to EGPs may be 352 defined that provide this function, and new rules for leaking TE 353 information between routing instances may be used. 355 4.3.3 Utilizing Call Setup 357 When IGP and EGP solutions are not available at the User-to-Network 358 Interface (UNI), there is still a requirement to have, at the local 359 edge nodes, the knowledge of the remote edge link capabilities. 361 The Call setup procedure provides an opportunity to discover edge 362 link capabilities of remote edge nodes before LSP setup is attempted. 364 - The Call-responder can return information on one or more egress 365 network links. The Call-reponder could return a full list of the 366 available links with information about the link capabilities, or it 367 could filter the list to return information about only those links 368 which might be appropriate to support the Connections needed by the 370 Papadimitriou and Farrel January 2007 372 Call. To do this second option, the Call-responder must determine 373 such appropriate links from information carried in the Call request 374 including destination of the Call, and the level of service 375 (bandwidth, protection, etc.) required. 377 - On receiving a Call response, the Call-initiator must determine 378 paths for the Connections (LSPs) that it will set up. The way that 379 it does this is out of scope for this document since it is an 380 implementation-specific, algorithmic process. However, it can take 381 as input the information about the available egress network links 382 as supplied in the Call response. 384 The LINK_CAPABILITY object is defined to allow this information to be 385 exchanged. The information that is included in this object is similar 386 to that distributed by GMPLS-capable IGPs (see [RFC4202]). 388 5. Protocol Extensions for Calls and Connections 390 This section describes the protocol extensions needed in support of 391 Call identification and management of Calls and Connections. 392 Procedures for the use of these protocol extensions are described in 393 Section 6. 395 5.1 Call Setup and Teardown 397 Calls are established independently of Connections through the use of 398 the Notify message. The Notify message is a targeted message and does 399 not need to follow the path of LSPs through the network. 401 Simultaneous Call and Connection establishment (sometimes referred to 402 as piggybacking) is not supported. 404 5.2 Call Identification 406 As soon as the concept of a Call is introduced, it is necessary to 407 support some means of identifying the Call. This becomes particularly 408 important when Calls and Connections are separated and Connections 409 must contain some reference to the Call. 411 A Call may be identified by a sequence of bytes that may have 412 considerable (but not arbitrary) length. A Call ID of 40 bytes would 413 not be unreasonable. It is not the place of this document to supply 414 rules for encoding or parsing Call IDs, but it must provide a 415 suitable means to communicate Call IDs within the protocol. The full 416 Call identification is referred to as the long Call ID. 418 The Call_ID is only relevant at the sender and receiver nodes. 419 Maintenance of this information in the signaling state is not 420 mandated at any intermediate node. Thus no change in [RFC3473] 421 transit implementations is required and there are no backward 423 Papadimitriou and Farrel January 2007 425 compatibility issues. Forward compatibility is maintained by using 426 the existing default values to indicate that no Call processing is 427 required. 429 Further, the long Call ID is not required as part of the Connection 430 (LSP) state even at the sender and receiver nodes so long as some 431 form of correlation is available. This correlation is provided 432 through the short Call ID. 434 5.2.1 Long Form Call Identification 436 The long Call ID is only required on the Notify message used to 437 establish the Call. It is carried in the "Session Name" field of the 438 SESSION_ATTRIBUTE Object on the Notify message. 440 A unique value per Call is inserted in the "Session Name" field by 441 the initiator of the Call. Subsequent network nodes MAY inspect this 442 object and MUST forward this object transparently across network 443 interfaces until reaching the egress node. Note that the structure of 444 this field MAY be the object of further formatting depending on the 445 naming convention(s). However, [RFC3209] defines the "Session Name" 446 field as a Null padded display string, and that any formatting 447 conventions for the Call ID must be limited to this scope. 449 5.2.2 Short Form Call Identification 451 The Connections (LSPs) associated with a Call need to carry a 452 reference to the Call - the short Call ID. A new field is added to 453 the signaling protocol to identify an individual LSP with the Call to 454 which it belongs. 456 The new field is a 16-bit identifier (unique within the context of 457 the address pairing provided by the Tunnel_End_Point_Address and the 458 Sender_Address of the SENDER TEMPLATE object) that MUST be exchanged 459 on the Notify message during Call initialization and is used on all 460 subsequent LSP messages that are associated with the Call. This 461 identifier is known as the short Call ID and is encoded as described 462 in Section 5.2.3. The Call ID MUST NOT be used as part of the 463 processing to determine the session to which an RSVP signaling 464 message applies. This does not generate any backward compatibility 465 issue since the reserved field of the SESSION object defined in 466 [RFC3209] MUST NOT be examined on receipt. 468 In the unlikely case of short Call_ID exhaustion, local node policy 469 decides upon specific actions to be taken, but might include the use 470 of second Sender_Address. Local policy details are outside of the 471 scope of this document. 473 Papadimitriou and Farrel January 2007 475 5.2.3 Short Form Call ID Encoding 477 The short Call ID is carried in a 16-bit field in the SESSION object 478 carried on the Notify message used during Call setup, and on all 479 messages during LSP setup and management. The field used was 480 previously reserved (MUST be set to zero on transmission and ignored 481 on receipt). This ensures backward compatibility with nodes that do 482 not utilize Calls. 484 The figure below shows the new version of the object. 486 Class = SESSION, Class-Num = 1, C-Type = 7(IPv4)/8(IPv6) 488 0 1 2 3 489 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 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 ~ IPv4/IPv6 Tunnel end point address ~ 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | Call_ID | Tunnel ID | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | Extended Tunnel ID | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 IPv4/IPv6 Tunnel End Point Address: 32 bits/128 bits (see [RFC3209]) 500 Call_ID: 16 bits 502 A 16-bit identifier used in the SESSION object that remains 503 constant over the life of the Call. The Call_ID value MUST be 504 set to zero when there is no corresponding Call. 506 Tunnel ID: 16 bits (see [RFC3209]) 508 Extended Tunnel ID: 32 bits/128 bits (see [RFC3209]) 510 5.3 LINK_CAPABILITY object 512 The LINK_CAPABILITY object is introduced to support link capability 513 exchange during Call setup and MAY be included in a Notify message 514 used for Call setup. This optional object includes the link local 515 capabilities of a link joining the Call-initiating node (or 516 Call-terminating node) to the network. The specific node is indicated 517 by the source address of the Notify message. 519 The link reported can be a single link or can be a bundled link 520 [RFC4201]. 522 The Class Number is selected so that the nodes that do not recognize 523 this object drop it silently. That is, the top bit is set and the 524 next bit is clear. 526 Papadimitriou and Farrel January 2007 528 This object has the following format: 530 Class-Num = TBA (form 10bbbbbb), C_Type = 1 532 0 1 2 3 533 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 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | | 536 // (Subobjects) // 537 | | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 The contents of the LINK_CAPABILITY object is defined as series of 541 variable-length data items called subobjects. The subobject format is 542 defined in [RFC3209]. 544 The following subobjects are currently defined. 545 - Type 1: the link local IPv4 address of a link or a numbered bundle 546 using the format defined in [RFC3209] 547 - Type 2: the link local IPv6 address of a link or a numbered bundle 548 using the format defined in [RFC3209] 549 - Type 4: the link local identifier of an unnumbered link or bundle 550 using the format defined in [RFC3477] 551 - Type 64: the Maximum Reservable Bandwidth corresponding to this 552 link or bundle (see [RFC4201]) 553 - Type 65: the interface switching capability descriptor (see 554 [RFC4202]) corresponding to this link or bundle (see also 555 [RFC4201]). 557 Note: future revisions of this document may extend the above list. 559 A single instance of this object MAY be used to exchange capablity 560 information relating to more than one link or bundled link. In this 561 case, the following ordering MUST be used: 562 - each link MUST be identified by an identifier subobject (Type 1, 2 563 or 4) 564 - capability subobjects (Type 64 or 65, and future subobjects) MUST 565 be placed after the identifier subobject for the link or bundle to 566 which they refer. 568 Mulitple instances of the LINK_CAPABILITY object within the same 569 Notify message are not supported by this specification. In the event 570 that a Notify message contains multiple LINK_CAPABILITY objects, the 571 receiver SHOULD process the first one as normal and SHOULD ignore 572 subsequent instances of the object. 574 5.4 Revised Message Formats 576 The Notify message is enhanced to support Call establishment and 577 teardown of Calls. See Section 6 for a description of the procedures. 579 Papadimitriou and Farrel January 2007 581 5.4.1 Notify Message 583 The Notify message is modified in support of Call establishment by 584 the optional addition of the LINK CAPABILTY object. Further, the 585 SESSION ATTRIBUTE object is added to the sequence to 586 carry the long Call ID. The presence of the SESSION ATTRIBUTE object 587 MAY be used to distinguish a Notify message used for Call management, 588 but see Section 5.5 for another mechanism. The 589 MAY be used to simultaneously set up multiple Calls. 591 The format of the Notify Message is as follows: 593 ::= [ ] 594 [[ | ]...] 595 [ ] 596 597 599 ::= [ ] 601 ::= [ ] 602 [ ...] 603 [ ] 604 [ ] 605 [ | ] 607 ::= see [RFC3473] 609 ::= see [RFC3473] 611 5.5 ADMIN_STATUS Object 613 Notify messages exchanged for Call control and management purposes 614 carry a specific new bit (the Call Management or C bit) in the ADMIN 615 STATUS object. 617 [RFC3473] indicates that the format and contents of the ADMIN_STATUS 618 object are as defined in [RFC3471]. The new "C" bit is added for Call 619 control as shown below. 621 0 1 2 3 622 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 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 |R| Reserved |C|T|A|D| 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 Reflect (R): 1 bit - see [RFC3471] 628 Testing (T): 1 bit - see [RFC3471] 629 Administratively down (A): 1 bit - see [RFC3471] 630 Deletion in progress (D): 1 bit - see [RFC3471] 632 Papadimitriou and Farrel January 2007 634 Call Management (C): 1 bit 636 This bit is set when the message is being used to control 637 and manage a Call. 639 The procedures for the use of the C bit are described in Section 6. 641 6. Procedures in Support of Calls and Connections 643 6.1 Call/Connection Setup Procedures 645 This section describes the processing steps for Call and Connection 646 setup. 648 There are three cases considered: 650 - A Call is set up without any associated 651 Connection. It is assumed that Connections will be added to the 652 Call at a later time, but this is neither a requirement nor 653 a constraint. 655 - A Connection may be added to an existing Call. This may happen if 656 the Call was set up without any associated Connections, or if 657 another Connection is added to a Call that already has one or more 658 associated Connections. 660 - A Connection may be established without any reference to a Call 661 (see Section 6.4). This encompasses the previous LSP setup 662 procedure. 664 Note that a Call MUST NOT be imposed upon a Connection that is 665 already established. To do so would require changing the short Call 666 ID in the SESSION OBJECT of the existing LSPs and this would 667 constitute a change in the Session Identifier. This is not allowed by 668 existing protocol specifications. 670 Call and Connection teardown procedures are described later in 671 Section 6.6. 673 6.2 Call Setup 675 A Call is set up before, and independent of, LSP (i.e. Connection) 676 setup. 678 Call setup MAY necessitate verification of the link status and link 679 capability negotiation between the Call ingress node and the Call 680 egress node. The procedure described below is applied only once for a 681 Call and hence only once for the set of LSPs associated with a Call. 683 Papadimitriou and Farrel January 2007 685 The Notify message (see [RFC3473]) is used to signal the Call setup 686 request and response. The new Call Management (C) bit in the 687 ADMIN_STATUS object is used to indicate that this Notify is managing 688 a Call. The Notify message is sent with source and destination 689 IPv4/IPv6 addresses set to any of the routable ingress/egress node 690 addresses respectively. 692 At least one session MUST be listed in the of 693 the Notify message. In order to allow for long identification of the 694 Call, the SESSION_ATTRIBUTE object is added as part of the . Note that the ERROR SPEC object is not relevant in 696 Call setup and MUST carry the Error Code zero ("Confirmation") to 697 indicate that there is no error. 699 During Call setup, the ADMIN STATUS object is sent with the following 700 bits set. Bits not listed MUST be set to zero. 702 R - to cause the egress to respond 703 C - to indicate that the Notify message is managing a Call. 705 The SESSION, SESSION ATTRIBUTE, SENDER_TEMPLATE, SENDER_TSPEC objects 706 included in the of the Notify message are built as 707 follows. 709 - The SESSION object includes as Tunnel_End_Point_Address any of the 710 Call-terminating (egress) node's IPv4/IPv6 routable addresses. The 711 Call_ID is set to a non-zero value unique within the context of 712 the address pairing provided by the Tunnel_End_Point_Address and 713 the Sender_Address from the SENDER TEMPLATE object (see below). 714 This value will be used as the short Call ID carried on all 715 messages for LSPs associated with this Call. 717 Note that the Call_ID value of zero is reserved and MUST NOT be 718 used since it will be present in SESSION objects of LSPs 719 that are not associated with Calls. The Tunnel_ID of 720 the SESSION object is not relevant for this procedure and SHOULD 721 be set to zero. The Extended_Tunnel_ID of the SESSION object is 722 not relevant for this procedure and MAY be set to zero or to an 723 address of the ingress node. 725 - The SESSION ATTRIBUTE object contains priority flags. Currently no 726 use of these flags is envisioned, however, future work may 727 identify value in assigning priorities to Calls; accordingly the 728 Priority fields MAY be set to non-zero values. None of the Flags 729 in the SESSION ATTRIBUTE object is relevant to this process and 730 this field SHOULD be set to zero. The Session Name field is used 731 to carry the long Call Id as described in Section 5. 733 Papadimitriou and Farrel January 2007 735 - The SENDER_TEMPLATE object includes as Sender Address any of the 736 Call-initiating (ingress) node's IPv4/IPv6 routable addresses. The 737 LSP_ID is not relevant and SHOULD be set to zero. 739 - The bandwidth value inserted in the SENDER_TSPEC and FLOWSPEC 740 objects MUST be ignored upon receipt and SHOULD be set to zero 741 when sent. 743 Additionally, ingress/egress nodes that need to communicate their 744 respective link local capabilities may include a LINK_CAPABILITY 745 object in the Notify message. 747 The receiver of a Notify message may identify whether it is part of 748 Call management or reporting an error by the presence or absence of 749 the SESSION ATTRIUBTE object in the . Full 750 clarity, however, may be achieved by inspection of the new Call 751 Management (C) bit in the ADMIN STATUS object. 753 Note that the POLICY_DATA object may be included in the and MAY be used to identify requestor credentials, 755 account numbers, limits, quotas, etc. This object is opaque to RSVP, 756 which simply passes it to policy control when required. 758 Message IDs MUST be used during Call setup. 760 6.2.1 Accepting Call Setup 762 A node that receives a Notify message carrying the ADMIN STATUS 763 object with the R and C bits set is being requested to set up a Call. 764 The receiver MAY perform authorization and policy according to local 765 requirements. 767 If the Call is acceptable, the receiver responds with a Notify 768 message reflecting the information from the Call request with two 769 exceptions. 771 - The responder removes any LINK CAPABLITY object that was received 772 and MAY insert a LINK_CAPABILITY object that describes its own 773 access link. 775 - The ADMIN STATUS object is sent with only the C bit set. All other 776 bits MUST be set to zero. 778 The responder MUST use the Message ID object to ensure reliable 779 delivery of the response. If no Message ID Acknowledgement is 780 received after the configured number of retries, the responder SHOULD 781 continue to assume that the Call was successfully established. Call 782 liveliness procedures are covered in Section 6.7. 784 Papadimitriou and Farrel January 2007 786 6.2.2 Call Setup Failure and Rejection 788 Call setup may fail or be rejected. 790 If the Notify message can not be delivered, no Message ID 791 acknowledgement will be received by the sender. In the event that the 792 sender has retransmitted the Notify message a configurable number of 793 times without receiving a Message ID Acknowledgement (as described in 794 [RFC2961]), the initiator SHOULD declare the Call failed and SHOULD 795 send a Call teardown request (see Section 6.6). 797 It is also possible that a Message ID Acknowledgement is received but 798 no Call response Notify message is received. In this case, the 799 initiator MAY re-send the Call setup request a configurable number of 800 times (see Section 6.7) before declaring that the Call has failed. At 801 this point the initiator MUST send a Call teardown request (see 802 Section 6.6). 804 If the Notify message cannot be parsed or is in error it MAY be 805 responded to with a Notify message carrying the error code 13 806 ("Unknown object class") or 14 ("Unknown object C-Type") if 807 appropriate to the error detected. 809 The Call setup MAY be rejected by the receiver because of security, 810 authorization or policy reasons. Suitable error codes already exist 811 [RFC2205] and can be used in the ERROR SPEC object included in the 812 Notify message sent in response. 814 Error response Notify messages SHOULD also use the Message ID object 815 to achieve reliable delivery. No action should be taken on the 816 failure to receive a Message ID Acknowledgement after the configured 817 number of retries. 819 6.3 Adding a Connections to a Call 821 Once a Call has been established, LSPs can be added to the Call. 822 Since the short Call ID is part of the SESSION Object, any LSP that 823 has the same Call ID value in the SESSION Object belongs to the same 824 Call, and the Notify message used to establish the Call carried the 825 same Call ID in its SESSION object. 827 There will be no confusion between LSPs that are associated with a 828 Call and those which are not, since the Call ID value MUST be equal 829 to zero for LSPs which are not associated with a Call, and MUST NOT 830 be equal to zero for a valid Call ID. 832 LSPs for different Calls can be distinguished because the Call ID is 833 unique within the context of the source address (in the SENDER 834 TEMPLATE object) and the destination address (in the SESSION object). 836 Papadimitriou and Farrel January 2007 838 Ingress and egress nodes MAY group together LSPs associated with the 839 same Call and process them as a group according to implementation 840 requirements. Transit nodes need not be aware of the association of 841 multiple LSPs with the same Call. 843 The ingress node MAY choose to set the "Session Name" of an LSP to 844 match the long Call ID of the associated Call. 846 The C bit of the ADMIN STATUS object MUST NOT be set on LSP messages 847 including on Notify messages that pertain to the LSP and MUST be 848 ignored. 850 6.3.1 Adding a Reverse Direction LSP to a Call 852 Note that once a Call has been established it is symmetric. That is, 853 either end of the Call may add LSPs to the Call. 855 Special care is needed when managing LSPs in the reverse direction 856 since the addresses in the SESSION and SENDER TEMPLATE are reversed. 857 However, since the short Call ID is unique in the context of a given 858 ingress-egress address pair it may safely be used to associate the 859 LSP with the Call. 861 Note that since Calls are defined here to be symmetrical, the issue 862 of potential Call ID collision arises. This is discussed in Section 863 6.5. 865 6.4 Call-Free Connection Setup 867 It continues to be possible to set up LSPs as per [RFC3473] without 868 associating them with a Call. If the short Call ID in the SESSION 869 Object is set to zero, there is no associated Call and the Session 870 Name field in the SESSION ATTRIBUTE object MUST be interpreted simply 871 as the name of the session (see [RFC3209]). 873 The C bit of the ADMIN STATUS object MUST NOT be set on messages for 874 LSP control, including on Notify messages that pertain to LSPs, and 875 MUST be ignored when received on such messages. 877 6.5 Call Collision 879 Since Calls are symmetrical, it is possible that both ends of a Call 880 will attempt to establish Calls with the same long Call IDs at the 881 same time. This is only an issue if the source and destination 882 address pairs match. This situation can be avoided by applying some 883 rules to the contents of the long Call ID, but such mechanisms are 884 outside the scope of this document. 886 If a node that has sent a Call setup request and has not yet received 887 a response, itself receives a Call setup request with the same long 889 Papadimitriou and Farrel January 2007 891 Call ID and matching source/destination addresses, it SHOULD process 892 as follows. 894 - If its source address is numerically greater than the remote 895 source address, it MUST discard the received message and continue 896 to wait for a response to its setup request. 898 - If its source address is numerically smaller than the remote 899 source address, it MUST discard state associated with the Call 900 setup that it initiated, and MUST respond to the received Call 901 setup. 903 If a node receives a Call setup request carrying an address pair and 904 long Call ID that match an existing Call, the node MUST return an 905 error message (Notify message) with the new Error Code "Call 906 Management" and the new Error Value "Duplicate Call" in response to 907 the new Call request, and MUST NOT make any changes to the existing 908 Call. 910 A further possibility for contention arises when short Call IDs are 911 assigned by a pair of nodes for two distinct Calls that are set up 912 simultaneously using different long Call IDs. In this event a node 913 receives a Call setup request carrying a short Call ID that matches 914 one that it previously sent for the same address pair. The following 915 processing MUST be followed. 917 - If the receiver's source address is numerically greater than the 918 remote source address, the receiver returns an error (Notify 919 message) with the new Error Code "Call Management" and the new 920 Error Value "Call ID Contention". 922 - If the receiver's source address is numerically less than the 923 remote source address, the receiver accepts and processes the Call 924 request. It will receive an error message sent as described above, 925 and at that point it selects a new short Call ID and re-sends the 926 Call setup request. 928 6.6 Call/Connection Teardown 930 As with Call/Connection setup, there are several cases to consider. 932 - Removal of a Connection from a Call 933 - Removal of the last Connection from a Call 934 - Teardown of an "empty" Call 936 The case of tearing down an LSP that is not associated with a Call 937 does not need to be examined as it follows exactly the procedures 938 described in [RFC3473]. 940 Papadimitriou and Farrel January 2007 942 6.6.1 Removal of a Connection from a Call 944 An LSP that is associated with a Call may be deleted using the 945 standard procedures described in [RFC3473]. No special procedures are 946 required. 948 Note that it is not possible to remove an LSP from a Call without 949 deleting the LSP. It is not valid to change the short Call ID from 950 non-zero to zero since this involves a change to the SESSION object, 951 which is not allowed. 953 6.6.2 Removal of the Last Connection from a Call 955 When the last LSP associated with a Call is deleted, the question 956 arises as to what happens to the Call. Since a Call may exist 957 independently of Connections, it is not always acceptable to say that 958 the removal of the last LSP from a Call removes the Call. 960 The removal of the last LSP does not remove the Call and the 961 procedures described in the next Section MUST be used to delete the 962 Call. 964 6.6.3 Teardown of an "Empty" Call 966 When all LSPs have been removed from a Call, the Call may be torn 967 down or left for use by future LSPs. 969 Deletion of Calls is achieved by sending a Notify message just as for 970 Call setup, but the ADMIN STATUS object carries the R, D and C bits 971 on the teardown request and the D and C bits on the teardown 972 response. Other bits MUST be set to zero. 974 When a Notify message is sent for deleting a Call and the initiator 975 does not receive the corresponding reflected Notify message (or 976 possibly even the Message ID Ack), the initiator MAY retry the 977 deletion request using the same retry procedures as used during Call 978 establishment. If no response is received after full retry, the node 979 deleting the Call MAY declare the Call deleted, but under such 980 circumstances the node SHOULD avoid re-using the long or short Call 981 IDs for at least five times the Notify refresh period. 983 6.6.4 Attempted Teardown of a Call with Existing Connections 985 If a Notify request with the D bit of the ADMIN STATUS object set is 986 received for a Call for which LSPs still exist, the request MUST be 987 rejected with the Error Code "Call Management" and Error Value 988 "Connections Still Exist". The state of the Call MUST NOT be changed. 990 Papadimitriou and Farrel January 2007 992 6.6.5 Teardown of a Call from the Egress 994 Since Calls are symmetric they may be torn down from the ingress or 995 egress. 997 When the Call is "empty" (has no associated LSPs) it may be deleted 998 by the egress sending a Notify message just as described above. 1000 Note that there is a possibility that both ends of a Call initiate 1001 Call deletion at the same time. In this case, the Notify message 1002 acting as teardown request MAY be interpreted by its recipient as a 1003 teardown response. But since the Notify messages acting as teardown 1004 requests carry the R bit in the ADMIN STATUS object, they MUST be 1005 responded to anyway. If a teardown request Notify message is received 1006 for an unknown Call ID, it is, nevertheless, responded to in the 1007 affirmative. 1009 6.7 Control Plane Survivability 1011 Delivery of Notify messages is secured using message ID 1012 acknowledgements as described in previous sections. 1014 Notify messages provide end-to-end communication that does not rely 1015 on constant paths through the network. Notify messages are routed 1016 according to IGP routing information. No consideration is, therefore, 1017 required for network resilience (for example, make-before-break, 1018 protection, fast re-route), although end-to-end resilience is of 1019 interest for node restart and completely disjoint networks. 1021 Periodic Notify messages SHOULD be sent by the initiator and 1022 terminator of the Call to keep the Call alive and to handle ingress 1023 or egress node restart. The time period for these retransmissions is 1024 a local matter, but it is RECOMMENDED that this period should be 1025 twice the shortest refresh period of any LSP associated with the 1026 Call. When there are no LSPs associated with a Call, an LSR is 1027 RECOMMENDED to use a refresh period of no less than one minute. The 1028 Notify messages are identical to those sent as if establishing the 1029 Call for the first time, except for the LINK_CAPABILITY object, which 1030 may have changed since the Call was first established, due to, e.g., 1031 the establishment of Connections, link failures, or the addition of 1032 new component links. The current link information is useful for the 1033 establishment of subsequent Connections. A node that receives a 1034 refresh Notify message carrying the R bit in the ADMIN STATUS object 1035 MUST respond with a Notify response. A node that receives a refresh 1036 Notify message (response or request) MAY reset its timer - thus, in 1037 normal processing, Notify refreshes involve a single exchange once 1038 per time period. 1040 Papadimitriou and Farrel January 2007 1042 A node (sender or receiver) that is unsure of the status of a Call 1043 MAY immediately send a Notify message as if establishing the Call for 1044 the first time. 1046 Failure to receive a refresh Notify request has no specific meaning. 1047 A node that fails to receive a refresh Notify request MAY send its 1048 own refresh Notify request to establish the status of the Call. If a 1049 node receives no response to a refresh Notify request (including no 1050 Message ID Acknowledgement) a node MAY assume that the remote node is 1051 unreachable or unavailable. It is a local policy matter whether this 1052 causes the local node to teardown associated LSPs and delete the 1053 Call. 1055 In the event that an edge node restarts without preserved state, it 1056 MAY relearn LSP state from adjacent nodes and Call state from remote 1057 nodes. If a Path or Resv message is received with a non-zero Call ID 1058 but without the C bit in the ADMIN STATUS, and for a Call ID that is 1059 not recognized, the receiver is RECOMMENDED to assume that the Call 1060 establishment is delayed and ignore the received message. If the Call 1061 setup never materializes, the failure by the restarting node to 1062 refresh state will cause the LSPs to be torn down. Optionally, the 1063 receiver of such an LSP message for an unknown Call ID may return an 1064 error (PathErr or ResvErr message) with the error code "Call 1065 Management" and Error Value "Unknown Call ID". 1067 7. Applicability of Call and Connection Procedures 1069 This section considers the applicability of the different Call 1070 establishment procedures at the NNI and UNI reference points. This 1071 section is informative and is not intended to prescribe or prevent 1072 other options. 1074 7.1 Network-initiated Calls 1076 Since the link properties and other traffic-engineering attributes 1077 are likely known through the IGP, the LINK_CAPABILITY object is not 1078 usually required. 1080 In multi-domain networks, it is possible that access link properties 1081 and other traffic-engineering attributes are not known since the 1082 domains do not share this sort of information. In this case, the Call 1083 setup mechanism may include the LINK_CAPABILITY object. 1085 7.2 User-initiated Calls 1087 It is possible that the access link properties and other traffic- 1088 engineering attributes are not shared across the core network. In 1089 this case, the Call setup mechanism may include the LINK_CAPABILITY 1090 object. 1092 Papadimitriou and Farrel January 2007 1094 Further, the first node within the network may be responsible for 1095 managing the Call. In this case, the Notify message that is used to 1096 set up the Call is addressed by the user network edge node to the 1097 first node of the core network. Moreover, neither the long Call ID 1098 nor the short Call ID is supplied (the Session Name Length is set to 1099 zero and the Call ID value is set to zero). The Notify message is 1100 passed to the first network node which is responsible for generating 1101 the long and short Call IDs before dispatching the message to the 1102 remote Call end point (which is known from the SESSION object). 1104 Further, when used in an overlay context, the first core node is 1105 allowed (see [RFC4208]) to replace the Session Name assigned by the 1106 ingress node and passed in the Path message. In the case of Call 1107 management, the first network node: 1108 1) MAY insert a long Call ID in the Session Name of a Path message 1109 2) MUST replace the Session Name with that originally issued by the 1110 user edge node when it returns the Resv message to the ingress node. 1112 7.3 External Call Managers 1114 Third party Call management agents may be used to apply policy and 1115 authorization at a point that is neither the initiator nor terminator 1116 of the Call. The previous example is a particular case of this, but 1117 the process and procedures are identical. 1119 7.3.1 Call Segments 1121 Call Segments exist between a set of default and configured External 1122 Call Managers along a path between the ingress and egress nodes, and 1123 use the protocols described in this document. 1125 The techniques that are used by a given service provider to identify 1126 which External Call Managers within its network should process a 1127 given Call are beyond the scope of this document. 1129 An External Call Manager uses normal IP routing to route the Notify 1130 message to the next External Call Manager. Notify messages (requests 1131 and responses) are therefore encapsulated in IP packets that identify 1132 the sending and receiving External Call Managers, but the addresses 1133 used to identify the Call (the Sender Address in the SENDER TEMPLATE 1134 object and the Tunnel Endpoint Address in the SESSION object) 1135 continue to identify the endpoints of the Call. 1137 8. Non-support of Call ID 1139 It is important that the procedures described above operate as 1140 seamlessly as possible with legacy nodes that do not support the 1141 extensions described. 1143 Papadimitriou and Farrel January 2007 1145 Clearly, there is no need to consider the case where the Call 1146 initiator does not support Call setup initiation. 1148 8.1 Non-Support by External Call Managers 1150 It is unlikely that a Call initiator will be configured to send Call 1151 establishment Notify requests to an external Call manager, including 1152 the first network node, if that node does not support Call setup. 1154 A node that receives an unexpected Call setup request will fall into 1155 one of the following categories. 1157 - Node does not support RSVP. The message will fail to be delivered 1158 or responded. No Message ID Acknowledgement will be sent. The 1159 initiator will retry and then give up. 1161 - Node supports RSVP or RSVP-TE but not GMPLS. The message will be 1162 delivered but not understood. It will be discarded. No Message ID 1163 Acknowledgement will be sent. The initiator will retry and then 1164 give up. 1166 - Node supports GMPLS but not Call management. The message will be 1167 delivered, but parsing will fail because of the presence of the 1168 SESSION ATTRIBUTE object. A Message ID Acknowledgement may be sent 1169 before the parse fails. When the parse fails the Notify message 1170 may be discarded in which case the initiator will retry and then 1171 give up, alternatively a parse error may be generated and returned 1172 in a Notify message which will indicate to the initiator that Call 1173 management is not supported. 1175 8.2 Non-Support by Transit Node 1177 Transit nodes SHOULD NOT examine Notify messages that are not 1178 addressed to them. However, they will see short Call IDs in all 1179 messages for all LSPs associated with Calls. 1181 Previous specifications state that these fields SHOULD be ignored on 1182 receipt and MUST be transmitted as zero. This might interpreted by 1183 some implementations as meaning that the fields should be zeroed 1184 before the objects are forwarded. If this happens, LSP setup will not 1185 be possible. If either of the fields is zeroed either on the Path or 1186 the Resv message, the Resv message will reach the initiator with the 1187 field set to zero - this is indication to the initiator that some 1188 node in the network is preventing Call management. Use of Explicit 1189 Routes may help to mitigate this issue by avoiding such nodes. 1190 Ultimately, however, it may be necessary to upgrade the offending 1191 nodes to handle these protocol extensions. 1193 Papadimitriou and Farrel January 2007 1195 8.3 Non-Support by Egress Node 1197 It is unlikely that an attempt will be made to set up a Call to 1198 remote node that does not support Calls. 1200 If the egress node does not support Call management through the 1201 Notify message it will react (as described in Section 8.1) in the 1202 same way as an External Call Manager. 1204 9. Security Considerations 1206 Please refer to each of the documents referenced in the following 1207 sections for a description of the security considerations applicable 1208 to the features that they provide. 1210 9.1 Call and Connection Security Considerations 1212 Call setup is vulnerable to attacks both of spoofing and denial of 1213 service. Since Call setup uses Notify messages, the process can be 1214 protected by the use of the Integrity object to secure those messages 1215 as described in [RFC2205] and [RFC3473]. Deployments where 1216 security is a concern SHOULD use this mechanism. 1218 Implementations and deployments MAY additionally protect the 1219 Call setup exchange using end-to-end security mechanisms such as 1220 those provided by IPsec (see [RFC4302] and [RFC4303]), or using RSVP 1221 security [RFC2747]. 1223 Note, additionally, that the process of independent Call 1224 establishment, where the Call is set up separately from the LSPs, may 1225 be used to apply an extra level of authentication and policy for the 1226 end-to-end LSPs above that which is available with Call-less, 1227 hop-by-hop LSP setup. 1229 The frequency of Call establishment is application dependent and hard 1230 to generalize. Key exchange for Call-related message exchanges is 1231 therefore something that should be configured or arranged dynamically 1232 in different deployments according to the advice in [RFC4107]. Note 1233 that the remote RSVP-TE signaling relationship between Call endpoints 1234 is no different from the signaling relationship between LSRs that 1235 establish an LSP. That is, the LSRs are not necessarily IP-adjacent 1236 in the control plane in either case. Thus key exchange should be 1237 regarded as a remote procedure, not a single hop procedure. There are 1238 several procedures for automatic remote exchange of keys, and IKEv2 1239 [RFC4306] is particularly suggested in [RFC3473]. 1241 Papadimitriou and Farrel January 2007 1243 10. IANA Considerations 1245 10.1 RSVP Objects 1247 A new RSVP object is introduced. IANA is requested to make an 1248 assignment from the "RSVP Parameters" registry using the sub-registry 1249 "Class Names, Class Numbers, and Class Types". 1251 o LINK_CAPABILITY object 1253 Class-Num = TBA (form 10bbbbbb - suggested value 132) 1255 The Class Number is selected so that nodes not recognizing 1256 this object drop it silently. That is, the top bit is set 1257 and the next bit is cleared. 1259 C-Type = 1 (TE Link Capabilities) 1261 The LINK_CAPABILITY object is only defined for inclusion on Notify 1262 messages. 1264 Refer to Section 5.3 of this document. 1266 IANA is requested to maintain a list of subobjects that may be 1267 carried in this object. This list should be maintained in the 1268 registry entry for the LINK_CAPABILITY object as is common 1269 practice for the subobjects of other RSVP objects. For each 1270 subobject, IANA should list: 1271 - subobject type number 1272 - subobject name 1273 - reference indicating where subobject is defined. 1275 The initial list of subobjects is provided in Section 5.3 of this 1276 document. 1278 10.2 RSVP Error Codes and Error Values 1280 A new RSVP Error Code and new Error Values are introduced. IANA is 1281 requested to make assignments from the "RSVP Parameters" registry 1282 using the sub-registry "Error Codes and Globally-Defined Error 1283 Value Sub-Codes". 1285 o Error Codes: 1286 - Call Management (value TBA - suggested value 32) 1288 o Error Values: 1289 - Call Management/Call ID Contention (value TBA- suggested 1) 1290 - Call Management/Connections still Exist (value TBA- suggested 2) 1291 - Call Management/Unknown Call ID (value TBA- suggested 3) 1292 - Call Management/Duplicate Call (value TBA- suggested 4) 1294 Papadimitriou and Farrel January 2007 1296 10.3 RSVP ADMIN_STATUS object Bits 1298 [GMPLS-E2E] requests IANA to manage the bits of the RSVP ADMIN_STATUS 1299 object. A new "Administrative Status Information Flags" sub-registry 1300 of the "GMPLS Signaling Parameters" registry is created. 1302 This document defines one new bit, the C bit, to be tracked in that 1303 sub-registry. Bit number 28 is suggested. See Section 5.5 of this 1304 document. 1306 11. Acknowledgements 1308 The authors would like to thank George Swallow, Yakov Rekhter, 1309 Lou Berger, Jerry Ash and Kireeti Kompella for their very useful 1310 input to, and comments on, an earlier revision of this document. 1312 Thanks to Lyndon Ong and Ben Mack-Crane for lengthy discussions 1313 during and after working group last call, and to Deborah Brungard for 1314 a final, detailed review. 1316 Thanks to Suresh Krishnan for the GenArt review, and to Magnus 1317 Nystrom for discussions about security. 1319 Useful comments were received during IESG review from Brian 1320 Carpenter, Lars Eggert, Ted Hardie, Russ Housley, 1322 12. References 1324 12.1 Normative References 1326 [GMPLS-E2E] Lang, J.P., Rekhter, Y., and D. Papadimitriou, "RSVP- 1327 TE Extensions in support of End-to-End Generalized 1328 Multi-Protocol Label Switching (GMPLS)-based Recovery," 1329 draft-ietf-ccamp-gmpls-recovery-e2e-signaling, work in 1330 progress. 1332 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 1333 Requirement Levels," BCP 14, RFC 2119, March 1997. 1335 [RFC2205] R. Braden et al., "Resource ReSerVation Protocol 1336 (RSVP)- Version 1 Functional Specification," 1337 RFC 2205, September 1997. 1339 [RFC2747] Baker, F., Lindell, B. and M. Talwar, "RSVP 1340 Cryptographic Authentication", RFC 2747, January 1341 2000. 1343 [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, 1344 F. and S. Molendini, "RSVP Refresh Overhead 1345 Reduction Extensions", RFC 2961, April 2001. 1347 Papadimitriou and Farrel January 2007 1349 [RFC3209] D. Awduche et al., "RSVP-TE: Extensions to RSVP for 1350 LSP Tunnels," RFC 3209, December 2001. 1352 [RFC3471] L. Berger (Editor) et al., "Generalized MPLS - 1353 Signaling Functional Description," RFC 3471, January 1354 2003. 1356 [RFC3473] L. Berger (Editor) et al., "Generalized MPLS Signaling 1357 - RSVP-TE Extensions," RFC 3473, January 2003. 1359 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered 1360 Links in Resource ReSerVation Protocol - Traffic 1361 Engineering (RSVP-TE)," RFC 3477, January 2003. 1363 [RFC3945] E. Mannie, Ed., "Generalized Multi-Protocol Label 1364 Switching (GMPLS) Architecture", RFC 3945, October 1365 2004. 1367 [RFC4201] Kompella K., Rekhter Y., and L. Berger, "Link Bundling 1368 in MPLS Traffic Engineering," RFC 4201, October 2005. 1370 [RFC4202] Kompella, K. and Y. Rekhter (Editors) et al., "Routing 1371 Extensions in Support of Generalized MPLS," RFC 4202, 1372 October 2005. 1374 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Rekhter, Y. 1375 "Generalized Multiprotocol Label Switching (GMPLS) 1376 User-Network Interface (UNI): Resource ReserVation 1377 Protocol-Traffic Engineering (RSVP-TE) Support for the 1378 Overlay Model", RFC 4208, October 2005. 1380 [RFC4302] Kent, S., "IP Authentication Header," RFC 4302, 1381 December 2005. 1383 [RFC4303] Kent, S., "IP Encapsulating Payload (ESP)," RFC 4303, 1384 December 2005. 1386 [RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) 1387 Protocol", RFC 4306, December 2005. 1389 [RFC4426] Lang, J.P., and B. Rajagopalan (Editors) et al., 1390 "Generalized MPLS Recovery Functional 1391 Specification," RFC 4426, March 2006. 1393 12.2 Informative References 1395 [ASON-APPL] D. Papadimitriou et. al., "Generalized MPLS (GMPLS) 1396 RSVP-TE signaling usage in support of Automatically 1397 Switched Optical Network (ASON)," 1398 draft-ietf-ccamp-gmpls-rsvp-te-ason, work in progress. 1400 Papadimitriou and Farrel January 2007 1402 [RFC4107] S. Bellovin and R. Housley, "Guidelines for Cryptographic 1403 Key Management", BCP 107, RFC 4107, June 2005. 1405 [RFC4139] D. Papadimitriou, et al., "Requirements for Generalized 1406 MPLS (GMPLS) Signaling Usage and Extensions for 1407 Automatically Switched Optical Network (ASON)," RFC 1408 4139, July 2005. 1410 [STITCH] Ayyangar, A., Kompella, K., and Vasseur, JP., "Label 1411 Switched Path Stitching with Generalized MPLS Traffic 1412 Engineering", draft-ietf-ccamp-lsp-stitching, work in 1413 progress. 1415 For information on the availability of the following document, 1416 please see http://www.itu.int. 1418 [G.8080] ITU-T, "Architecture for the Automatically Switched 1419 Optical Network (ASON)," Recommendation G.8080/ 1420 Y.1304, November 2001 (and Revision, January 2003). 1422 13. Contact Addresses 1424 Dimitri Papadimitriou 1425 Alcatel-Lucent, 1426 Fr. Wellesplein 1, 1427 B-2018 Antwerpen, Belgium 1428 Phone: +32 3 240-8491 1429 EMail: dimitri.papadimitriou@alcatel-lucent.be 1431 Adrian Farrel 1432 Old Dog Consulting 1433 Phone: +44 (0) 1978 860944 1434 EMail: adrian@olddog.co.uk 1436 14. Authors' Addresses 1438 John Drake 1439 Boeing Satellite Systems 1440 2300 East Imperial Highway 1441 El Segundo, CA 90245 1442 EMail: John.E.Drake2@boeing.com 1444 Deborah Brungard (AT&T) 1445 Rm. D1-3C22 - 200 S. Laurel Ave. 1446 Middletown, NJ 07748, USA 1447 EMail: dbrungard@att.com 1449 Papadimitriou and Farrel January 2007 1451 Zafar Ali (Cisco) 1452 100 South Main St. #200 1453 Ann Arbor, MI 48104, USA 1454 EMail: zali@cisco.com 1456 Arthi Ayyangar (Nuova Systems) 1457 2600 San Tomas Expressway 1458 Santa Clara, CA 95051 1459 EMail: arthi@nuovasystems.com 1461 Don Fedyk (Nortel Networks) 1462 600 Technology Park Drive 1463 Billerica, MA, 01821, USA 1464 Email: dwfedyk@nortel.com 1466 Intellectual Property Statement 1468 The IETF takes no position regarding the validity or scope of any 1469 Intellectual Property Rights or other rights that might be claimed to 1470 pertain to the implementation or use of the technology described in 1471 this document or the extent to which any license under such rights 1472 might or might not be available; nor does it represent that it has 1473 made any independent effort to identify any such rights. Information 1474 on the procedures with respect to rights in RFC documents can be 1475 found in BCP 78 and BCP 79. 1477 Copies of IPR disclosures made to the IETF Secretariat and any 1478 assurances of licenses to be made available, or the result of an 1479 attempt made to obtain a general license or permission for the use of 1480 such proprietary rights by implementers or users of this 1481 specification can be obtained from the IETF on-line IPR repository at 1482 http://www.ietf.org/ipr. 1484 The IETF invites any interested party to bring to its attention any 1485 copyrights, patents or patent applications, or other proprietary 1486 rights that may cover technology that may be required to implement 1487 this standard. Please address the information to the IETF at ietf- 1488 ipr@ietf.org. 1490 Disclaimer of Validity 1492 This document and the information contained herein are provided on an 1493 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1494 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1495 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1496 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1497 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1498 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1500 Papadimitriou and Farrel January 2007 1502 Copyright Statement 1504 Copyright (C) The IETF Trust (2007). 1506 This document is subject to the rights, licenses and restrictions 1507 contained in BCP 78, and except as set forth therein, the authors 1508 retain all their rights.