idnits 2.17.00 (12 Aug 2021) /tmp/idnits28683/draft-zhang-ccamp-gmpls-call-extensions-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 08, 2009) is 4693 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 4974' is mentioned on line 304, but not defined == Missing Reference: 'RFC3974' is mentioned on line 256, but not defined == Missing Reference: 'RFC 5151' is mentioned on line 304, but not defined == Unused Reference: 'RFC5151' is defined on line 393, but no explicit reference was found in the text == Outdated reference: draft-farrel-rtg-common-bnf has been published as RFC 5511 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network work group Fatai Zhang 2 Internet Draft Dan Li 3 Intended status: Standards Track Jianhua Gao 4 Expires: January 2010 Huawei 5 July 08, 2009 7 RSVP-TE extensions to GMPLS Calls 9 draft-zhang-ccamp-gmpls-call-extensions-01.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with 14 the provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on January 08, 2010. 34 Abstract 36 Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource 37 ReserVation Protocol-Traffic Engineering (RSVP-TE) extensions are 38 used to support Calls. Although it is stated that these mechanisms 39 are applicable to any environment (including multi-area), the "Call 40 Path" is determined hop-by-hop by each "Call Manager" in sequence 41 along the path of the Call. 43 However, it is desirable to allow the Call-initiator to identify the 44 Call Path explicitly in some cases (especially in the multi-domain 45 case). 47 This document describes RSVP-TE signaling extensions to allow the 48 Call-initiator to identify the Call Path explicitly when transit 49 nodes (besides the Call-initiator and Call-terminator) are involved 50 in these Calls. 52 Conventions used in this document 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in RFC-2119 [RFC2119]. 58 Table of Contents 60 1. Introduction.................................................2 61 2. Motivation...................................................3 62 3. Solution.....................................................5 63 4. Operations...................................................6 64 4.1. User-Initiated Calls....................................7 65 5. Security Considerations......................................7 66 6. Manageability Considerations.................................7 67 7. IANA Considerations..........................................8 68 7.1. ERO Object..............................................8 69 7.2. RRO Object..............................................8 70 7.3. RSVP Error Codes and Error Values.......................8 71 8. Normative References.........................................9 72 9. Authors' Addresses..........................................10 73 Acknowledgment.................................................10 75 1. Introduction 77 The concept of a Generalized Multi-Protocol Label Switching (GMPLS) 78 Call is introduced in [RFC4974]. A Call is an association between 79 endpoints and possibly between key transit points (such as network 80 boundaries) in support of an instance of a service. The requirements 81 of Calls and the RSVT-TE extensions in support of Calls are also 82 described in [RFC4974]. 84 A Call is usually established between end-points to verify polices 85 and authorization applied on these end-points. However, in a multi- 86 domain environment, some key polices and authorization are usually 87 deployed on the corresponding domain border nodes (domain ingress or 88 egress nodes), so these border nodes are also involved in processing 89 the Call when the Call is going through these domains. These nodes 90 that process the Call are known as "Call Managers". 92 Although it is stated that the mechanisms proposed in [RFC4974] are 93 applicable to any environment (including multi-area), the "Call Path" 94 is determined hop-by-hop by each Call Manager in sequence along the 95 path of the Call. That is, each Call Manager forwards the Notify 96 message that is used to manage the Call to the next Call Manager 97 along the Call Path. The Notify messages are targeted at (i.e., carry 98 the IP address of) the next Call Manager, and the route that the 99 messages follow through the network to reach the next Call Manager is 100 not important. 102 However, it is desirable to allow the Call-initiator to determine the 103 Call Path and to signal it explicitly in some cases (especially in 104 the multi-domain case). 106 This document describes RSVP-TE signaling extensions to allow the 107 Call-initiator to identify the Call Path explicitly when transit Call 108 Managers (besides the Call-initiator and Call-terminator) are 109 involved in a Call. 111 Note that Call and Connection are separated in the signaling, and 112 Call procedures do not impact the Connection procedures, so this 113 document does not modify any Connection procedures defined in 114 [RFC3471], [RFC3473], [RFC4208], and other existing protocol family. 116 2. Motivation 118 In some cases, it is desirable to set up a Call through not only the 119 Call-initiator and Call-terminator, but also some transit Call 120 Manager nodes (e.g., transit border domain nodes) to verify the 121 corresponding polices and authorization applied on these nodes. 123 For instance, in the multi-domain case as shown in Figure 1, there 124 are three interconnected domains. Nodes I, D11, and D12 are in Domain 125 1, and the nodes D11 and D12 are the border nodes. Nodes D21, D22, 126 D23, and D24 are the border nodes of Domain 2, and the internal nodes 127 of Domain 2 are not shown in the figure. Nodes D31, D32, and E are in 128 Domain 3, and the nodes D31 and D32 are the border nodes. 130 Policies and authorization are often applied in domain border nodes, 131 such as the nodes D11, D12, D21, D22, D23, D24, D31, and D32 in this 132 example. Therefore, in this case, when a Call between Call-initiator 133 (node I) and Call-terminator (node E) is going to be setup, the Call 134 should be processed in some domain border nodes (for example, the 135 nodes D11, D21, D23, D31 should process the Call when the Call Path 136 I-D11-D21-D23-D31-E is selected). 138 Note that in this case, there may be several alternative Call Paths 139 between Call-initiator and Call-terminator. For example, in the 140 Figure 1, the possible Call paths may be I-D11-D21-D23-D31-E or I- 141 D12-D22-D24-D32-E, or some other path depending on the 142 interconnectivity across the domains. 144 +------------------+ +----------------+ +-----------------+ 145 | +--+ | | +--+ +--+ | | +--+ | 146 | --| |--|--|--| |----| |--|--|--| |-- | 147 | / | | | | | | | | | | | | \ | 148 | / +--+ | | +--+ +--+ | | +--+ \ | 149 | +--+ / D11 | | D21 D23 | | D31 \ +--+ | 150 | | |- | | | | -| | | 151 | | |- | | | | -| | | 152 | +--+ \ +--+ | | +--+ +--+ | | +--+ / +--+ | 153 | I \ | | | | | | | | | | | | / E | 154 | ---| |--|--|--| |----| |--|--|--| |--- | 155 | +--+ | | +--+ +--+ | | +--+ | 156 | D12 | | D22 D24 | | D32 | 157 | | | | | | 158 +------------------+ +----------------+ +-----------------+ 159 Domain1 Domain2 Domain3 161 Figure 1: Multi-domain Scenario 163 Note that how to determine the Call Path is out of the scope of this 164 document. 166 According to the Section 7.3.1 of [RFC 4974], it is already supported 167 that the third parties (i.e., non-end points such as External Call 168 Managers) are involved in the Call, but there is no mechanisms for 169 the Call-initiator to control the Call Path. The Call Path is 170 determined by each Call Manager in turn selecting the next Call 171 Manager on the path to the Call-terminator and forwarding the Notify 172 message that sets up the Call. 174 However, in the case of a multi-domain Call, commercial and policy 175 motivations normally play a role in selecting the Call Path. This 176 selection may be at a coarse level (for example, identifying which 177 domains should or should not be used), or may be at a finer level 178 (for example, identifying which Call Managers to use). Note that 179 there is no concept of specifying links or resources within the Call 180 Path as the Call is an ordered association of Call Managers, and not 181 a data path in the network. 183 Therefore, it is desirable to allow full control for the Call- 184 initiator, which means that the Call-initiator can identify the full 185 Call Path explicitly. Moreover, the management plane needs to be able 186 to identify the Call Path explicitly as an instruction to the Call- 187 initiator. 189 This document defines protocol extensions that provide a solution for 190 these requirements. 192 3. Solution 194 In order to identify the Call Path explicitly for the Call-initiator, 195 the explicit Call Path can be specified by the EXPLICIT_ROUTE object 196 (ERO) [RFC3209]. 198 A new C_Type of ERO is suggested, C_Type = 2 (suggested, TBD by 199 IANA)), Call Explicit Route. 201 It is obvious that the Call Path can also be recorded by the 202 RECORD_ROUTE object (RRO) [RFC3209]. 204 A new C_Type of RRO is suggested, C_Type = 2 (suggested, TBD by IANA), 205 Call Record Route. 207 Note that the procedures of ERO and RRO for Call Path are similar as 208 defined in [RFC3209]. 210 The revised Notify message is as follows using the meta-language 211 described in [RBNF]: 213 ::= [ ] 215 [[ | ]...] 217 [ ] 219 221 223 Where 225 ::= [ ] 226 228 ::= [ ] 230 [ ...] 232 [ ] 234 [ ] 236 [ ] 238 [ ] 240 [ | ] 242 And where: 244 ::= see [RFC3473] 246 ::= see [RFC3473] 248 4. Operations 250 The processes for the revised Notify message comply with the 251 procedures described in [RFC3974] except that the ERO and RRO are 252 processed at the Call Managers. The processes for the ERO and RRO are 253 similar to the Connection ERO and RRO [RFC3209]. 255 The procedures of Call Setup for the revised Notify message are 256 summarized as follows (other procedures are the same as [RFC3974]): 258 (1)The Call-initiator initiates Call setup and processes the Call 259 locally (e.g., verifies the policy, etc.). After that, it adds 260 the ERO to the Notify message, including the sub-objects to 261 identify the Call Path. If RRO is required, it also should add 262 RRO to the Notify message. Then the Call-initiator sends the 263 Notify message to the first Call Manager indicated by the first 264 sub-object of the ERO (Note that there is no Label Recording in 265 this case). 267 (2)The transit Call Managers process the Call when they receive the 268 Notify messages. After that, they remove themselves from the ERO. 269 If RRO is presented in the Notify message, it should also process 270 RRO similar to [RFC3209]. Then it sends the Notify message to the 271 next Call Manager identified by the ERO. 273 (3)Step 2 recurs until the Notify message gets to the Call- 274 terminator. And the corresponding Notify message returns to Call- 275 initiator in the inverse direction (Note that the inverse Notify 276 message may include RRO object if needed, but it should not 277 include ERO object). 279 If, at any time, the ERO is absent or present but empty (for example, 280 when a transit Call Manager removes itself from the ERO), a Call 281 Manager MUST select a next Call Manager on the Call Path toward the 282 Call-terminator (identified in the Session object of the Notify 283 message). This next Call Manager may be another transit Call Manager 284 or may be the Call-terminator itself. The Call Manager MAY create a 285 new ERO if none exists to define hops to the Call-terminator, or may 286 add hops to the existing ERO between itself and the next hop in the 287 received ERO. Such actions are subject to local policy. 289 4.1. User-Initiated Calls 291 The extensions in this document can also be applied in user-initiated 292 calls, although the example described in this document is about 293 network-initiated Call. Note that, in this case, the first node 294 within the first network domain may be responsible for specifying the 295 Call Path explicitly in the Notify message. The procedures should 296 comply with the description in the Section 7.2 of [RFC 4974]. 298 5. Security Considerations 300 The security considerations about Call setup in single domain are 301 described in [RFC 4974]. In the case of multi-domain environment, the 302 security about Call is similar to that of Connection which is 303 described in [RFC 5151]. Therefore, please refer to the corresponding 304 Security Consideration sections in [RFC 4974] and [RFC 5151] to take 305 into account the security issues. 307 6. Manageability Considerations 309 The mechanisms defined in this document call upon the use of policy 310 at Call Managers. Such policy SHOULD be available for configuration 311 by the operator either directly acting on the Call Manager or through 312 a policy server. Important information for the application of policy 313 is carried in the Call establishment messages (Notify messages) in 314 the Session, Session_Attributes, Sender_Template, Link_Capability, 315 and Policy_Data objects. 317 The mechanism used to determine the entire Call Path or next Call 318 Manager in a Call Path is beyond the scope of this document. One 319 solution is to allow configuration of the Call Path from the operator 320 as part of the service request (just as the explicit path of a label 321 switched path (LSP) can be specified by the operator). 323 Operators will expect to be able to inspect Call Managers and 324 determine for which Calls they are initiator, transit, or terminator. 325 Furthermore, they will expect to be able to inspect a Call at any 326 Call Manager that it uses, and determine all information about the 327 Call including its Call Path. 329 7. IANA Considerations 331 This document introduces a new C_Type ERO and RRO. 333 7.1. ERO Object 335 Class-Num = 20 337 C-Type=2 (suggested, TBD by IANA), Call Explicit Route 339 This type indicates that this ERO is used for Call messages in Notify 340 messages. 342 7.2. RRO Object 344 Class-Num = 21 346 C-Type=2 (suggested, TBD by IANA), Call Record Route 348 This type indicates that this RRO is used for Call messages in Notify 349 messages. 351 7.3. RSVP Error Codes and Error Values 353 The Call message (Notify message) should be rejected when any Call 354 Manager which receives the Call message including ERO does not 355 recognize the ERO. 357 o Error Codes: 359 - Call Management (value 32) 361 o Error Values: 363 - Call Management/Unknown ERO (value=TBD) 365 8. Normative References 367 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 368 Requirement Levels", BCP 14, RFC 2119, March 1997. 370 [RFC4974] D. Papadimitriou, A. Farrel, "Generalized MPLS (GMPLS) 371 RSVP-TE Signaling Extensions in Support of Calls ", RFC 372 4974, August 2007. 374 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., 375 Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions 376 to RSVP for LSP Tunnels", RFC 3209, December 2001. 378 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 379 (GMPLS) Signaling Functional Description", RFC 3471, 380 January 2003. 382 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 383 Switching (GMPLS) Signaling Resource ReserVation Protocol- 384 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 385 January 2003. 387 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 388 "Generalized Multiprotocol Label Switching (GMPLS) User- 389 Network Interface (UNI): Resource ReserVation Protocol- 390 Traffic Engineering (RSVP-TE) Support for the Overlay 391 Model", RFC 4208, October 2005. 393 [RFC5151] A. Farrel, A. Ayyangar, JP. Vasseur, "Inter-Domain MPLS and 394 GMPLS Traffic Engineering-Resource Reservation Protocol- 395 Traffic Engineering (RSVP-TE) Extensions", RFC 5151, 396 February 2008. 398 [RBNF] Farrel, A., "Reduced Backus-Naur Form (RBNF) A Syntax Used 399 in Various Protocol Specifications", draft-farrel-rtg- 400 common-bnf, work in progress. 402 9. Authors' Addresses 404 Fatai Zhang 405 Huawei Technologies 406 F3-5-B R&D Center, Huawei Base 407 Bantian, Longgang District 408 Shenzhen 518129 P.R.China 410 Phone: +86-755-28972912 411 Email: zhangfatai@huawei.com 413 Dan Li 414 Huawei Technologies Co., Ltd. 415 F3-5-B R&D Center, Huawei Base 416 Bantian, Longgang District 417 Shenzhen 518129 P.R.China 419 Phone: +86-755-28973237 420 Email: danli@huawei.com 422 Jianhua Gao 423 Huawei Technologies 424 F3-5-B R&D Center, Huawei Base 425 Bantian, Longgang District 426 Shenzhen 518129 P.R.China 428 Phone: +86-755-28972912 429 Email: gjhhit@huawei.com 431 Acknowledgment 433 TBD. 435 Intellectual Property 437 The IETF Trust takes no position regarding the validity or scope of 438 any Intellectual Property Rights or other rights that might be 439 claimed to pertain to the implementation or use of the technology 440 described in any IETF Document or the extent to which any license 441 under such rights might or might not be available; nor does it 442 represent that it has made any independent effort to identify any 443 such rights. 445 Copies of Intellectual Property disclosures made to the IETF 446 Secretariat and any assurances of licenses to be made available, or 447 the result of an attempt made to obtain a general license or 448 permission for the use of such proprietary rights by implementers or 449 users of this specification can be obtained from the IETF on-line IPR 450 repository at http://www.ietf.org/ipr 452 The IETF invites any interested party to bring to its attention any 453 copyrights, patents or patent applications, or other proprietary 454 rights that may cover technology that may be required to implement 455 any standard or specification contained in an IETF Document. Please 456 address the information to the IETF at ietf-ipr@ietf.org. 458 The definitive version of an IETF Document is that published by, or 459 under the auspices of, the IETF. Versions of IETF Documents that are 460 published by third parties, including those that are translated into 461 other languages, should not be considered to be definitive versions 462 of IETF Documents. The definitive version of these Legal Provisions 463 is that published by, or under the auspices of, the IETF. Versions of 464 these Legal Provisions that are published by third parties, including 465 those that are translated into other languages, should not be 466 considered to be definitive versions of these Legal Provisions. 468 For the avoidance of doubt, each Contributor to the IETF Standards 469 Process licenses each Contribution that he or she makes as part of 470 the IETF Standards Process to the IETF Trust pursuant to the 471 provisions of RFC 5378. No language to the contrary, or terms, 472 conditions or rights that differ from or are inconsistent with the 473 rights and licenses granted under RFC 5378, shall have any effect and 474 shall be null and void, whether published or posted by such 475 Contributor, or included with or in such Contribution. 477 Disclaimer of Validity 479 All IETF Documents and the information contained therein are provided 480 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 481 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 482 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 483 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 484 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 485 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 486 FOR A PARTICULAR PURPOSE. 488 Full Copyright Statement 489 Copyright (c) 2009 IETF Trust and the persons identified as the 490 document authors. All rights reserved. 492 This document is subject to BCP 78 and the IETF Trust's Legal 493 Provisions Relating to IETF Documents in effect on the date of 494 publication of this document (http://trustee.ietf.org/license-info). 495 Please review these documents carefully, as they describe your rights 496 and restrictions with respect to this document.