idnits 2.17.1 draft-ietf-ccamp-gmpls-rsvp-te-ason-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 23. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2097. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2074. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2081. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2087. ** 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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 37 longer pages, the longest (page 2) being 59 lines 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 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. Further, they will see the C bit in the ADMIN STATUS object of Path and Resv messages that are used to establish 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 (July 2005) is 6853 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: 'RFC2961' is mentioned on line 190, but not defined == Missing Reference: 'RFC-3473' is mentioned on line 387, but not defined == Missing Reference: 'GMPLS-E2E' is mentioned on line 430, but not defined == Missing Reference: 'GMPLS-RTG' is mentioned on line 746, but not defined == Missing Reference: 'RFC3743' is mentioned on line 1188, but not defined == Missing Reference: 'OIF-UNI' is mentioned on line 1769, but not defined == Missing Reference: 'RFC1884' is mentioned on line 1845, but not defined ** Obsolete undefined reference: RFC 1884 (Obsoleted by RFC 2373) == Unused Reference: 'GMPLS-ROUTING' is defined on line 1554, but no explicit reference was found in the text == Unused Reference: 'RFC2026' is defined on line 1561, but no explicit reference was found in the text == Unused Reference: 'RFC3667' is defined on line 1592, but no explicit reference was found in the text == Unused Reference: 'RFC3668' is defined on line 1595, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ASON-REQ' -- Possible downref: Non-RFC (?) normative reference: ref. 'BUNDLE' -- Possible downref: Non-RFC (?) normative reference: ref. 'GMPLS-CRANK' -- Possible downref: Non-RFC (?) normative reference: ref. 'GMPLS-FUNCT' -- Possible downref: Non-RFC (?) normative reference: ref. 'GMPLS-OVERLAY' -- Possible downref: Non-RFC (?) normative reference: ref. 'GMPLS-ROUTING' -- Possible downref: Non-RFC (?) normative reference: ref. 'LMP' ** Obsolete normative reference: RFC 2402 (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 3667 (Obsoleted by RFC 3978) ** Obsolete normative reference: RFC 3668 (Obsoleted by RFC 3979) == Outdated reference: A later version (-02) exists of draft-kompella-rsvp-change-01 Summary: 9 errors (**), 0 flaws (~~), 16 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group J. Drake (Boeing) 3 Internet Draft D. Papadimitriou (Alcatel) 4 Proposed Category: Standard Track A. Farrel (Old Dog Consulting) 5 D. Brungard (ATT) 6 Z. Ali (Cisco) 7 A. Ayyangar (Juniper) 8 H. Ould-Brahim (Nortel) 9 D. Fedyk (Nortel) 11 Expiration Date: January 2006 July 2005 13 Generalized MPLS (GMPLS) RSVP-TE Signalling 14 in support of Automatically Switched Optical Network (ASON) 16 draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt 18 Status of this Memo 20 By submitting this Internet-Draft, each author represents that any 21 applicable patent or other IPR claims of which he or she is aware 22 have been or will be disclosed, and any of which he or she becomes 23 aware will be disclosed, in accordance with Section 6 of BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that other 27 groups may also distribute working documents as Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on January 19, 2006. 42 Copyright Notice 44 Copyright (C) The Internet Society (2005). 46 Abstract 48 This document specifies how Generalized MPLS (GMPLS) RSVP-TE 49 signaling may be used and extended to satisfy the requirements of the 50 Automatically Switched Optical Network (ASON) architecture specified 51 by the ITU-T. The requirements are in a companion document 52 "Requirements for Generalized MPLS (GMPLS) Usage and Extensions for 53 Automatically Switched Optical Network (ASON)." 55 D.Papadimitriou et al. - Expires January 2006 1 56 In particular, this document details the mechanisms for setting up 57 Soft Permanent Connections (SPC), the necessary extensions in 58 delivering full and logical call/connection separation support, the 59 extended restart capabilities during control plane failures, extended 60 label usage and crankback signalling capability. 62 The mechanisms proposed in this document are applicable to any 63 environment (including multi-area) and for any type of interface: 64 packet, layer-2, time-division multiplexed, lambda or fiber 65 switching. 67 1. Table of Content 69 Abstract ......................................................... 1 70 1. Table of Content .............................................. 2 71 2. Conventions used in this document ............................. 3 72 3. Introduction .................................................. 3 73 3.1 Comparison with Previous Work ................................ 4 74 3.2 Applicability ................................................ 5 75 3.2.1 Network-Network Interface (I-NNI and E-NNI) ................ 6 76 3.2.2 User-Network Interface (UNI) ............................... 8 77 4. Fulfilling ASON Requirements for GMPLS Signaling .............. 8 78 4.1 Soft Permanent Connection (SPC) .............................. 8 79 4.2 Call/Connection Separation .................................. 8 80 4.3 Call Segments ................................................ 9 81 4.4 Control Plane Restart Capabilities ........................... 9 82 4.5 Extended Label Association ................................... 9 83 4.6 Crankback Signaling .......................................... 9 84 4.7 Additional Error Codes ....................................... 9 85 5. Concepts and Terms ........................................... 10 86 5.1 What is a Call? ............................................. 10 87 5.2 Hierarchy of Calls, Connections, Tunnels and LSPs ........... 10 88 5.3 Exchanging Access Link Capabilities ......................... 10 89 5.3.1 Network-initiated Calls ................................... 11 90 5.3.2 User-initiated Calls ...................................... 11 91 5.3.3 Utilizing Call Setup ...................................... 11 92 6. Protocol Extensions for Calls and Connections ................ 11 93 6.1 Call Identification ......................................... 11 94 6.1.1 Long Form Call Identification ............................. 12 95 6.1.2 Short Form Call Identification ............................ 12 96 6.1.3 Short Call ID Encoding .................................... 13 97 6.2 LINK_CAPABILITY Object ...................................... 14 98 6.3 Revised Message Format ...................................... 14 99 6.3.1 Notify Message ............................................ 15 100 6.4 ADMIN_STATUS Object ......................................... 15 101 7. Procedures in Support of Call and Connections ................ 16 102 7.1 Call/Connection Setup Procedures ............................ 16 103 7.2 Independent Call Setup ...................................... 17 104 7.2.1 Accepting Independent Call Setup .......................... 18 105 7.2.2 Rejecting Independent Call Setup .......................... 19 106 7.3 Adding a Connection to a Call ............................... 19 107 7.3.1 Adding a Reverse Direction Connection to a Call ........... 20 109 D.Papadimitriou et al. - Expires January 2006 2 110 7.4 Simultaneous Call/Connection Setup .......................... 20 111 7.4.1 Accepting Simultaneous Call/Connection Setup .............. 20 112 7.4.2 Rejecting Simultaneous Call/Connection Setup .............. 21 113 7.5 Call-Free Connection Setup .................................. 21 114 7.6 Call Collision .............................................. 21 115 7.7 Call/Connection Teardown .................................... 22 116 7.7.1 Removal of a Connection from a Call ....................... 22 117 7.7.2 Removal of the Last Connection from a Call ................ 23 118 7.7.3 Teardown of an "Empty" Call ............................... 23 119 7.7.4 Teardown of a Call with Existing Connections .............. 23 120 7.7.5 Teardown of a Call from the Egress ........................ 23 121 7.8 Control Plane Survivability ................................. 24 122 8. Applicability of Call and Connection Procedures .............. 25 123 8.1 Network-initiated Calls ..................................... 25 124 8.2 User-initiated Calls ........................................ 25 125 8.3 External Call Managers ...................................... 26 126 8.3.1 Call Segments ............................................. 26 127 9. Non-support of Call ID ....................................... 26 128 9.1 Non-support by External Call Managers ....................... 26 129 9.2 Non-support by Transit Nodes ................................ 27 130 9.3 Non-support by Egress Nodes ................................. 27 131 10. Security Considerations ..................................... 28 132 10.1 Call and Connection Security Considerations ................ 28 133 11. IANA Considerations ......................................... 28 134 12. Acknowledgements ............................................ 29 135 13. References .................................................. 29 136 13.1 Normative References ....................................... 30 137 13.2 Informative References ..................................... 30 138 14. Author's Addresses .......................................... 31 139 Appendix 1. Analysis of G.7713.2 against GMPLS RSVP-TE Signaling 140 Requirements in Support of ASON.................................. 32 142 2. Conventions used in this document 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in [RFC2119]. 148 In addition, the reader is assumed to be familiar with the 149 terminology used in [RFC3471], [RFC3473], [RFC3477] and [RFC3945]. 151 3. Introduction 153 This document describes how GMPLS RSVP-TE signaling [RFC3473] can be 154 used and extended in support of Automatically Optical Switched 155 Networks (ASON) as specified in the ITU-T G.8080 recommendation 156 [G.8080]. Note, however, that the mechanisms that it describes and 157 references have a larger scope than the one described in this 158 document. 160 [ASON-REQ] identifies the requirements to be covered by the 161 extensions to the GMPLS signaling protocols to support the 162 capabilities of an ASON network. 164 D.Papadimitriou et al. - Expires January 2006 3 165 The following are expected from the GMPLS protocol suite to realize 166 the needed ASON functionality: 167 a) support for soft permanent connection functionality 168 b) support for call and connection separation 169 c) support for call segments 170 d) support for extended restart capabilities during control plane 171 failures 172 e) support for extended label association 173 f) support for crankback capability. 175 This document is aligned with the [RSVP-CHANGE] process, which 176 requires evaluation of existing protocol functionality for achieving 177 the requested functionality and justification for any requested 178 changes or new extensions. In this context, the following summarizes 179 the evaluation made: 181 1. Signaling across the internal network-network interface (I-NNI) 182 and user-network interface (UNI) can be done as described in 183 [RFC3473] and [GMPLS-OVERLAY] respectively. Thus, the processing 184 of standard objects and functions (such as EXPLICIT_ROUTE Object 185 and RECORD_ROUTE Object) are as described in those documents. 187 2. The second is that any GMPLS RSVP-TE object, message or procedure 188 not defined in this document or in a directly referenced document 189 is handled exactly as described in [RFC3473], [RFC3209], 190 [RFC2961], and [RFC2205]. An important consideration is that the 191 procedures introduced by this document do not introduce any 192 forward or backward compatibility issue. 194 3. The mechanisms proposed in this document are not restricted to 195 LSC or TDM capable interfaces, but are equally applicable to any 196 packet (PSC) or layer-2 interfaces (L2SC). As a consequence, the 197 present document proposes ubiquitously applicable RSVP 198 extensions. 200 3.1 Comparison with Previous Work 202 Informational RFC [RFC3474] documents the code points for the 203 signaling extensions defined in [G.7713.2] to meet the requirements 204 of ASON Distributed Call and Connection Management (DCM) as specified 205 in [G.7713]. 207 While [G.7713.2] make use of GMPLS RSVP-TE signaling, there are key 208 differences from the problem statement in [ASON-REQ] and the solution 209 it provides. These differences result from the development of a 210 fuller and clearer set of requirements in [G.8080] after the time 211 that [G.7713.2] was published and [ASON-REQ] considerations for 212 compatibility aspects with GMPLS [RFC3473]. These differences are 213 enumerated below and detailed in Appendix 1. 215 1. As described in [G.8080], there are various models and multiple 216 methods of achieving connections across multiple domains. 218 D.Papadimitriou et al. - Expires January 2006 4 220 [G.7713.2] is similar to a cooperative connection model between 221 domains, that is, there is no overall coordination, and it uses 222 point-to-point external NNI (E-NNI) signaling between inter- 223 domain border controllers (i.e. single-hop LSP). Additionally, it 224 requires address resolution at both border controllers regardless 225 of the address space used. Recent enhancements to [G.8080] 226 include end-to-end network capabilities based on flexible (end- 227 to-end) path selection to support optimal route selection i.e. 228 source-based re-routing and crankback. 230 To provide for these enhancements and future capabilities (e.g., 231 VPNs), [ASON-REQ] is based on an inter-domain model using an end- 232 to-end call model, modeling multiple domains as one virtual 233 network, and optional one-time (ingress) address resolution 234 (optional, if multiple address families are needed). Note that 235 this model is the same model used by [RFC3471], [RFC3473] and 236 [GMPLS-OVERLAY]. 238 2. [G.7713.2] distinguishes between use of [G.7713.2] for ASON 239 networks and use of [RFC3473] for GMPLS networks; however, no 240 compatibility aspects are addressed. [ASON-REQ] addresses ASON 241 requirements for GMPLS networks. Backward compatibility allows 242 for the coexistence of nodes supporting GMPLS RSVP-TE [RFC3473] 243 with nodes supporting GMPLS RSVP-TE for ASON (as described in 244 this document). 246 [ASON-REQ] requires that for any new and existing GMPLS features, 247 [RFC3473] transit nodes do not need to be updated and do not need 248 to modify their behavior to support the end-to-end features of 249 ASON. The solution provided by [G.7713.2] is not backward 250 compatible with [RFC3473]. Moreover, [G.7713.2] can not be used 251 in a network with [RFC3473], as incorrect network behavior will 252 result. 254 3. While existing GMPLS signalling [RFC3473] supports Soft Permanent 255 Connections (SPCs), [G.7713.2] defines a new mechanism to support 256 SPCs, and this new mechanism is incompatible with [RFC3473]. 258 4. [G.7713.2] does not support full call and connection separation, 259 multiple connections per call, or ingress/egress node capability 260 negotiation prior to connection establishment. 262 5. [G.7713.2] does not support call segment signaling mechanisms, as 263 required in [G.8080] and [G.7713]. 265 6. [G.7713.2] defines control plane restart capabilities that are 266 incompatible with those described in [RFC3473]. 268 7. [G.7713.2] does not support crankback signaling mechanisms 269 [GMPLS-CRANK], as required in [G.8080] and [G.7713]. 271 3.2 Applicability 273 D.Papadimitriou et al. - Expires January 2006 5 274 The requirements placed on the signaling plane of an optical network 275 to support the capabilities of an Automatically Switched Optical 276 Network (see [ASON-REQ]) apply at both the network-network interface 277 (NNI) and the user-network interface (UNI). 279 Some extensions to the core signaling features (see [RFC3473]) are 280 required in support of some of the ASON requirements. [GMPLS-OVERLAY] 281 defines a common set of standard procedures at the user-network 282 interface (UNI). Other documents referenced in specific subsections 283 of this document define specific protocol extensions in support of 284 specific ASON requirements. 286 3.2.1 Network-Network Interface (I-NNI and E-NNI) 288 At the NNI, the ingress and egress core nodes play a full part in the 289 GMPLS network from a signaling point of view. Applicability of GMPLS 290 RSVP-TE signaling at the I-NNI is implicitly detailed in [RFC3471] 291 and [RFC3473]. Routing information is fully or partially distributed 292 through this multi-vendor interface. 294 The following paragraphs further detail the applicability of 295 [RFC3471] and [RFC3473] mechanisms at the E-NNI. Note also that the 296 use of these RFCs at the E-NNI does not preclude the use of another 297 signaling protocol for the I-NNI as long as an inter-working function 298 is provided by the non-GMPLS domain. Routing information may be fully 299 or partially distributed through this interface. 301 The basic GMPLS RSVP-TE operations at the E-NNI reference point 302 involves (as inspired from [GMPLS-OVERLAY]): 304 1. Addressing 306 Two adjacent egress/ingress core nodes must share the same address 307 space, which is used by GMPLS E-NNI signaling. A set of egress/ 308 ingress core node tuples share the same address space if the ingress 309 or ingress core node in the set could exchange GMPLS RSVP-TE messages 310 among themselves. Within a control domain, the address space used by 311 the core nodes to communicate among themselves MAY, but need not be 312 shared with the address space used by any of the egress/ingress core 313 node tuples. 315 A core node is identified by either a single IP address representing 316 its Node ID, or by one or more un/numbered TE links that interconnect 317 core-nodes. A core node needs only to know (and track) the interface 318 addresses and/or Node IDs of client nodes to which incoming messages 319 are directed. 321 Links may be either numbered or unnumbered. Further, links may be 322 bundled or unbundled. See [BUNDLE] and [RFC3477], respectively. 323 (IF_ID) RSVP_HOP object processing at E-NNI boundaries follows the 324 rules defined in [RFC3473]. 325 2. ERO Processing 327 D.Papadimitriou et al. - Expires January 2006 6 328 An ingress core node MAY receive and potentially reject a Path 329 message that contains an ERO. Such behavior is controlled by 330 (hopefully consistent) configuration. If an ingress core node rejects 331 a Path message due to the presence of an ERO it SHOULD return a 332 PathErr message with an error code of "Unknown object class" toward 333 the sender. This causes the path setup to fail. 335 Further an ingress core node MAY accept EROs that include a sequence 336 of []. This is to support 337 explicit label control on the egress core node interface. Incoming 338 EROs may also include a combination of the latter with sequence of 339 loose ingress core node addresses and/or AS numbers. If an ingress 340 core node rejects a Path message due to the presence of an ERO not of 341 the permitted format it SHOULD return a PathErr message with an error 342 code of Bad Explicit Route Object as defined in [RFC3209]. 344 - Path Message without ERO: when an ingress core node receives a Path 345 message from an egress core node that contains no ERO, it MUST 346 calculate a route to the destination and include that route in a 347 ERO, before forwarding the PATH message. One exception would be if 348 the egress core node were also adjacent to this core node. If no 349 route can be found, the ingress core node SHOULD return a PathErr 350 message with an Error code and value of 24,5 - "No route available 351 toward destination". 353 - Path Message with ERO: when an ingress core node receives a Path 354 message from an egress core node that contains an ERO, the ingress 355 core node SHOULD verify the route against its topology database 356 before forwarding the PATH message. If the route is not viable, 357 then a PathErr message with an error code and value of 24,5 - "No 358 route available toward destination" should be returned. 360 3. RRO Processing 362 An egress or an ingress core node MAY include an RRO and MAY remove 363 the RRO from the received Path message before forwarding it. Further 364 an egress or an ingress core node MAY remove the RRO from a Resv 365 message before forwarding it. Such behavior is controlled by 366 (hopefully consistent) configuration. 368 Further an ingress core node MAY edit the RRO in a Resv message such 369 that it includes only the subobjects from the egress core node 370 through the ingress core node of a neighboring E-NNI. This is to 371 allow the ingress core node to be aware of the selected link and 372 labels on the far end of the connection traversing this network. 374 4. Notification 376 An ingress core node MAY include a NOTIFY_REQUEST object in both the 377 Path and Resv messages it forwards. An ingress node MAY remove the 378 NOTIFY_REQUEST object from the Path and Resv message before 379 forwarding it. An egress node MAY remove the NOTIFY_REQUEST object 380 from the Path and Resv message before forwarding it. Core nodes may 382 D.Papadimitriou et al. - Expires January 2006 7 383 send Notification messages to ingress/egress core nodes, which have 384 included the NOTIFY_REQUEST object. 386 Note: the use of the Notify message for independent Call setup as 387 defined in this document extends the one specified in [RFC-3473]. 389 3.2.2 User-Network Interface (UNI) 391 At the UNI, the ingress and/or the egress nodes are not full players 392 in the GMPLS network. Signaling information may be filtered and 393 substituted by the network. This process is described in [GMPLS- 394 OVERLAY]. Routing information leaked to the ingress/egress nodes is 395 very limited. 397 The ingress node may initiate an LSP setup/teardown request to the 398 network using standard GMPLS procedures. The modifications to 399 behavior described in [GMPLS-OVERLAY] apply to the nodes within the 400 network (in particular, the network edge nodes) and not ingress or 401 egress nodes. 403 4. Fulfilling ASON Requirements for GMPLS Signaling 405 This section briefly describes how the requirements identified in 406 [ASON-REQ] are met by existing GMPLS specifications, by procedures 407 described in this document, or by other means. 409 4.1 Soft Permanent Connection (SPC) 411 A Soft Permanent Connection (SPC) is defined as a combination of a 412 permanent connection at the network edges and a switched connection 413 within the network. 415 SPC setup is provided using Explicit Label Control as specified in 416 [RFC3473], with the augmented procedures described in [GMPLS- 417 OVERLAY]. 419 4.2 Call/Connection Separation 421 The call concept for optical networks is defined in [G.8080] where it 422 is used to deliver the following capabilities: 424 - Verification and identification of the call initiator (prior to 425 LSP setup) 427 - Support of virtual concatenation with diverse path component LSPs 429 - Multiple LSP association with a single call (note aspects related 430 to recovery are detailed in [GMPLS-FUNCT] and [GMPLS-E2E]) 432 - Facilitate control plane operations by allowing operational status 433 change of the associated LSP. 435 D.Papadimitriou et al. - Expires January 2006 8 436 Procedures and protocol extensions to support Call setup, and the 437 association of Calls with Connections are described in sections 5 and 438 onwards of this document. 440 4.3 Call Segments 442 Call segments capabilities MUST be supported by both independent call 443 setup and simultaneous call/connection setup. 445 Procedures and (GMPLS) RSVP-TE signaling protocol extensions to 446 support call segments are described in sections 8.4.1 of this 447 document. 449 4.4 Control Plane Restart Capabilities 451 Restart capabilities are provided by GMPLS RSVP-TE signaling in case 452 of control plane failure including nodal and control channel faults. 453 The handling of node and control channels faults is described in 454 [RFC3473] Section 9. No additional RSVP mechanisms or objects are 455 required to fulfill the ASON control plane restart capabilities. 457 However, it should be noted that restart considerations must form 458 part of each of the procedures referenced from or described in this 459 document. 461 4.5 Extended Label Association 463 Dynamic discovery of label associations as described in [ASON-REQ] 464 can be either performed through manual provisioning or using the Link 465 Management Protocol [LMP] capabilities. 467 4.6 Crankback Signaling 469 Crankback signaling allows a connection setup request to be retried 470 on an alternate path that detours around a blocked link or node upon 471 a setup failure, for instance, because a link or a node along the 472 selected path has insufficient resources. Crankback mechanisms may 473 also be applied during connection recovery by indicating the location 474 of the failed link or node. This would significantly improve the 475 successful recovery ratio for failed connections, especially in 476 situations where a large number of setup requests are simultaneously 477 triggered. 479 Crankback mechanisms for (GMPLS) RSVP-TE signaling are covered in a 480 dedicated companion document [GMPLS-CRANK]. That document is intended 481 to fulfill all the corresponding ASON requirements as well as 482 satisfying any other crankback needs. 484 4.7 Additional Error Codes 486 Error codes corresponding to the mechanisms defined in this document 487 are specified along each section and summarized in Section 11. 489 D.Papadimitriou et al. - Expires January 2006 9 490 5. Concepts and Terms 492 The concept of a Call and a Connection are discussed in the ASON 493 architecture [G.8080]. This section is not intended as a substitute 494 for that document, but is a brief summary of the key terms and 495 concepts. 497 5.1 What is a Call? 499 A Call is an agreement between endpoints possibly in cooperation with 500 the nodes that provide access to the network. Call setup may include 501 capability exchange, policy, authorization and security. 503 A Call is used to facilitate and manage a set of Connections that 504 provide end to end data services. While Connections require state to 505 be maintained at nodes along the data path within the network, Calls 506 do not involve the participation of transit nodes except to forward 507 the Call management requests as transparent messages. 509 A Call may be established and maintained independently of the 510 Connections that it supports. 512 5.2 A Hierarchy of Calls, Connections, Tunnels and LSPs 514 Clearly there is a hierarchical relationship between Calls and 515 Connections. One or more Connections may be associated to a Call. A 516 Connection may not be part of more than one call. A Connection may, 517 however, exist without a Call. 519 In GMPLS RSVP-TE [RFC3473], a Connection is identified with a GMPLS 520 TE Tunnel. Commonly a Tunnel is identified with a single LSP, but it 521 should be noted that for protection, load balancing and many other 522 functions, a Tunnel may be supported by multiple parallel LSPs. The 523 following identification reproduces this hierarchy: 525 - Call IDs are unique within the context of the pair of addresses 526 that are the source and destination of the Call. 528 - Tunnel IDs are unique within the context of the Session (that is 529 the destination of the Tunnel). Applications may also find it 530 convenient to keep the Tunnel ID unique within the context of a 531 Call. 533 - LSP IDs are unique within the context of a Tunnel. 535 Note that the Call_ID value of zero is reserved and MUST NOT be used 536 during LSP-independent call establishment. 538 Throughout the remainder of this document, the terms LSP and Tunnel 539 are used interchangeably with the term Connection. The case of a 540 Tunnel that is supported by more than one LSP is covered implicitly. 542 D.Papadimitriou et al. - Expires January 2006 10 543 5.3 Exchanging Access Link Capabilities 545 It is useful for the ingress node of an LSP to know the link 546 capabilities of the link between the network and the egress node. 547 This information may allow the ingress node to tailor its LSP request 548 to fit those capabilities and to better utilize network resources 549 with regard to those capabilities. 551 In particular, this may be used to achieve end-to-end spectral 552 routing attribute negotiation for signal quality negotiation (such as 553 BER) in photonic environments where network edges are signal 554 regeneration capable. Similarly, it may be used to provide end-to-end 555 spatial routing attribute negotiation in multi-area routing 556 environments, in particular, when TE links have been bundled based on 557 technology specific attributes. 559 Call setup may provide a suitable mechanism to exchange information 560 for this purpose, although several other possibilities exist. 562 5.3.1 Network-initiated Calls 564 In this case, there may be no need to distribute additional link 565 capability information over and above the information distributed by 566 the TE and GMPLS extensions to the IGP. Further, it is possible that 567 future extensions to these IGPs will allow the distribution of more 568 detailed information including optical impairments. 570 5.3.2 User-initiated Calls 572 In this case, edge link information may not be visible within the 573 core network, nor (and specifically) at other edge nodes. This may 574 prevent an ingress from requesting suitable LSP characteristics to 575 ensure successful LSP setup. 577 Various solutions to this problem exist including the definition of 578 static TE links (that is, not advertised by a routing protocol) 579 between the core network and the edge nodes. Nevertheless, special 580 procedures may be necessary to advertise edge TE link information to 581 the edge nodes outside of the network without advertising the 582 information specific to the contents of the network. 584 In the future, when the requirements are understood on the 585 information that needs to be supported, TE extensions to EGPs may be 586 defined that provide this function. 588 5.3.3 Utilizing Call Setup 590 When IGP and EGP solutions are not available at the UNI, there is 591 still a requirement to have, at the local edge nodes, the knowledge 592 of the remote edge link capabilities. 594 The Call setup procedure provides an opportunity to discover edge 595 link capabilities of remote edge nodes before LSP setup is attempted. 597 D.Papadimitriou et al. - Expires January 2006 11 598 The LINK CAPABILITY object is defined to allow this information to be 599 exchanged. The information that is included in this object is similar 600 to that distributed by GMPLS-capable IGPs (see [GMPLS-RTG]). 602 6. Protocol Extensions for Calls and Connections 604 This section describes the protocol extensions needed in support of 605 Call identification and management of Calls and Connections. 606 Procedures for the use of these protocol extensions are described in 607 section 7. 609 6.1 Call Identification 611 As soon as the concept of a call is introduced, it is necessary to 612 support some means of identifying the call. This becomes particularly 613 important when calls and connections are separated and connections 614 must contain some reference to the call. 616 According to [ASON-REQ], a call may be identified by a sequence of 617 bytes that may have considerable (but not arbitrary) length. A Call 618 ID of 40 bytes would not be unreasonable. It is not the place of this 619 document to supply rules for encoding or parsing Call IDs, but it 620 must provide a suitable means to communicate Call IDs within the 621 protocol. The full call identification as required by ASON is 622 referred to as the long Call ID. 624 The Call_ID is only relevant at the sender and receiver nodes. 625 Maintenance of this information in the signaling state is not 626 mandated at any intermediate node. Thus no change in [RFC3473] 627 transit implementations is required and there are no backward 628 compatibility issues. Forward compatibility is maintained by using 629 the existing default values to indicate that no Call processing is 630 required. 632 6.1.1 Long Form Call Identification 634 The "Session Name" attribute of the SESSION_ATTRIBUTE Object is used 635 to carry the long form of the Call ID. 637 A unique value per call is inserted in the "Session Name" field by 638 the initiator of the call. Subsequent network nodes MAY inspect this 639 object and MUST forward this object transparently across network 640 interfaces until reaching the egress node. Note that the structure of 641 this field MAY be the object of further formatting depending on the 642 naming convention(s). However, [RFC3209] defines the "Session Name" 643 field as a Null padded display string, and that any formatting 644 conventions for the Call ID must be limited to this scope. 646 6.1.2 Short Form Call Identification 648 The connections (LSPs) associated with a call need to carry a 649 reference to the call - the Call ID. Each LSP MAY carry the full long 650 Call ID in the "Session Name" of the SESSION ATTRIBUTE object to 652 D.Papadimitriou et al. - Expires January 2006 12 653 achieve this purpose. However, existing (and future) implementations 654 may need to place other strings in this field (in particular, the 655 field is currently intended to provide the Session Name). To allow 656 for this possibility a new field is added to the signaling protocol 657 to identify an individual LSP with the Call to which it belongs. 659 The new field is a 16-bit identifier (unique within the context of 660 the address pairing provided by the Tunnel_End_Point_Address and the 661 Sender_Address) that MUST be exchanged during Call initialization and 662 is used on all subsequent LSP setups that are associated with the 663 Call. This identifier is known as the short Call ID and is encoded as 664 described in Section 6.1.3. When relevant, the Call Id MUST NOT be 665 used as part of the processing to determine the session to which an 666 RSVP signaling message applies. This does not generate any backward 667 compatibility issue since the reserved field of the SESSION object 668 defined in [RFC3209] MUST NOT be examined on receipt. 670 In the unlikely case of short Call_ID exhaustion, local node policy 671 decides upon specific actions to be taken. Local policy details are 672 outside of the scope of this document. 674 6.1.3 Short Form Call ID Encoding 676 The short Call ID is carried in a 16-bit field in the SESSION object 677 used during Call and LSP setup. The field used was previously 678 reserved (MUST be set to zero on transmission and ignored on 679 receipt). This ensures backward compatibility with nodes that do not 680 utilize calls. 682 The figure below shows the new version of the object. 684 Class = SESSION, Class-Num = 1, C-Type = 7(IPv4)/8(IPv6) 686 0 1 2 3 687 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 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 | IPv4/IPv6 Tunnel end point address | 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 | Call_ID | Tunnel ID | 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 | Extended Tunnel ID | 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 IPv4/IPv6 Tunnel End Point Address: 32 bits/128 bits (see [RFC3209]) 698 Call_ID: 16 bits 700 A 16-bit identifier used in the SESSION object that remains 701 constant over the life of the call. The Call_ID value MUST be 702 set to zero when there is no corresponding call. 704 Tunnel ID: 16 bits (see [RFC3209]) 706 D.Papadimitriou et al. - Expires January 2006 13 707 Extended Tunnel ID: 32 bits/128 bits (see [RFC3209]) 709 6.2 LINK_CAPABILITY object 711 The LINK CAPABILITY object is introduced to support link capability 712 exchange during Call setup. This optional object includes the bundled 713 link local capabilities of the call initiating node (or terminating 714 node) indicated by the source address of the Notify message. 716 The Class Number is selected so that the nodes that do not recognize 717 this object drop it silently. That is, the top bit is set and the 718 next bit is clear. 720 This object has the following format: 722 Class-Num = TBA (form 10bbbbbb), C_Type = 1 724 0 1 2 3 725 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 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 | | 728 // (Subobjects) // 729 | | 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 The contents of the LINK_CAPABILITY object is defined as series of 733 variable-length data items called subobjects. The subobject format is 734 defined in [RFC3209]. 736 The following subobjects are currently defined: 737 - Type 1: the link local IPv4 address (numbered bundle) using the 738 format defined in [RFC3209] 739 - Type 2: the link local IPv6 address (numbered bundle) using the 740 format defined in [RFC3209] 741 - Type 4: the link local identifier (unnumbered links and bundles) 742 using the format defined in [RFC3477] 743 - Type 64: the Maximum Reservable Bandwidth corresponding to this 744 bundle (see [BUNDLE]) 745 - Type 65: the interface switching capability descriptor (see 746 [GMPLS-RTG]) corresponding to this bundle (see also [BUNDLE]). 748 Note: future revisions of this document may extend the above list. 750 This object MAY also be used to exchange more than one bundled link 751 capability. In this case, the following ordering MUST be followed: 752 one identifier subobject (Type 1, 2 or 4) MUST be inserted before any 753 capability subobject (Type 64 or 65) to which it refers. 755 6.3 Revised Message Formats 757 The Notify message is enhanced (and referred thereby to as an 758 unsolicited Notify message) to support Call establishment and 760 D.Papadimitriou et al. - Expires January 2006 14 761 teardown of Calls that operate independent of LSPs. See section 7 for 762 a description of the procedures. 764 6.3.1 Notify Message 766 The Notify message is modified in support of Call establishment by 767 the optional addition of the LINK CAPABILTY object. Further, the 768 SESSION ATTRIBUTE object is added to the sequence to 769 carry the long Call ID. The presence of the SESSION ATTIBUTE object 770 MAY be used to distinguish a Notify message used for Call management. 771 The MAY be used to setup simultaneously 772 multiple Calls. 774 The format of the Notify Message is as follows: 776 ::= [ ] 777 [[ | ]...] 778 [ ] 779 780 782 ::= [ ] 784 ::= [ ] 785 [ ...] 786 [ ] 787 [ ] 788 [ | ] 790 ::= see [RFC3473] 792 ::= see [RFC3473] 794 6.4 ADMIN_STATUS Object 796 Messages (such as Notifys, Paths, etc.) exchanged for Call control 797 and management purposes carry a specific new bit (the Call Management 798 or C bit) in the ADMIN STATUS object. 800 The format and the contents of the ADMIN_STATUS object are both 801 dictated by [RFC3473] in favor of [RFC3471]. The new "C" bit is added 802 as shown below. 804 0 1 2 3 805 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 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 |R| Reserved |C|T|A|D| 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 Reflect (R): 1 bit - see [RFC3471] 811 Testing (T): 1 bit - see [RFC3471] 812 Administratively down (A): 1 bit - see [RFC3471] 813 Deletion in progress (D): 1 bit - see [RFC3471] 815 D.Papadimitriou et al. - Expires January 2006 15 816 Call Management (C): 1 bit 818 This bit is set when the message is being used to control 819 and manage a Call. 821 The procedures for the use of the C bit are described in section 7. 823 Note that the use of the C bit may appear as redundant since Call 824 setup can be distinguished by the presence of the SESSION ATTRIBUTE 825 object in a Notify message or an non-zero short Call ID value in a 826 Path message. However, in the case of lost messages and node restart, 827 this further distinction is useful to distinguish Path messages that 828 set up Calls from Path messages that belong to calls. 830 7. Procedures in Support of Calls and Connections 832 7.1 Call/Connection Setup Procedures 834 This section describes the processing steps for call and connection 835 setup. 837 There are four cases considered: 839 - A Call and Connection may be established simultaneously. That is, 840 a Connection may be established and designated as belonging to a 841 new Call. It is an implementation decision how the work a the 842 ingress and egress points is split and whether the qualities of 843 the Call are policed before, after or at the same time as those of 844 the Connection. In the event that the establishment of either the 845 Call or the Connection fails, an error is returned as described in 846 Section 7.4.2 and neither is set up. 848 - A Call can be set up on its own. That is, without any associated 849 Connection. It is assumed that Connections will be added to the 850 Call at a later time, but this is neither a requirement nor 851 a constraint. 853 - A Connection may be added to an existing Call. This may happen if 854 the Call was set up without any associated Connections, or if a 855 further Connection is added to a Call that already has one or more 856 associated Connections. 858 - A Connection may be established without any reference to a Call. 859 This encompasses the previous LSP setup procedure. 861 Note that a Call MAY NOT be imposed upon a Connection that is already 862 established. To do so would require changing the short Call Id in the 863 SESSION OBJECT of the existing LSPs and this would constitute a 864 change in the Session Identifier. This is not allowed by existing 865 protocol specifications. 867 D.Papadimitriou et al. - Expires January 2006 16 868 Call and Connection teardown procedures are described later in 869 Section 7.7. 871 7.2 Independent Call Setup 873 It is possible to set up a Call before, and independent of, LSP 874 setup. A Call setup without LSPs MUST follow the procedure described 875 in this section. 877 Prior to the LSP establishment, Call setup MAY necessitate 878 verification of the link status and link capability negotiation 879 between the Call ingress node and the Call egress node. The procedure 880 described below is applied only once for a Call and hence only once 881 for the set of LSPs associated with a Call. 883 The Notify message (see [RFC3473]) is used to signal the Call setup 884 request and response. The new Call Management (C) bit in the 885 ADMIN_STATUS object is used to indicate that this Notify is managing 886 a Call. The Notify message is sent with source and destination 887 IPv4/IPv6 address set to any of the routable ingress/egress node 888 addresses respectively. 890 At least one session MUST be listed in the of 891 the Notify message. In order to allow for long identification of the 892 Call the SESSION_ATTRIBUTE object is added as part of the . Note that the ERROR SPEC object is not relevant in 894 Call setup and MUST carry the Error Code zero ("Confirmation") to 895 indicate that there is no error. 897 During Call setup, the ADMIN STATUS object is sent with the following 898 bits set. Bits not listed MUST be set to zero. 900 R - to cause the egress to respond 901 C - to indicate that this message is managing a Call. 903 The SESSION, SESSION ATTRIBUTE, SENDER_TEMPLATE, SENDER_TSPEC objects 904 included in the of the Notify message are built as 905 follows: 907 - The SESSION object includes as Tunnel_End_Point_Address any of the 908 call terminating (egress) node's IPv4/IPv6 routable addresses. The 909 Call_ID is set to a non-zero value unique within the context of 910 the address pairing provided by the Tunnel_End_Point_Address and 911 the Sender_Address from the SENDER TEMPLATE object (see below). 912 Note that the Call_ID value of zero is reserved and MUST NOT be 913 used during LSP-independent call establishment. The Tunnel_ID of 914 the SESSION object is not relevant for this procedure and SHOULD 915 be set to zero. The Extended_Tunnel_ID of the SESSION object is 916 not relevant for this procedure and MAY be set to zero or to an 917 address of the ingress node. 919 - The SESSION ATTRIBUTE object contains priority flags. Currently no 920 use of these flags is envisioned, however, future work may 922 D.Papadimitriou et al. - Expires January 2006 17 923 identify value is assigning priorities to Calls; accordingly the 924 Priority fields MAY be set to non-zero values. None of the Flags 925 in the SESSION ATTRIBUTE object are relevant to this process and 926 this field SHOULD be set to zero. The Session Name field is used 927 to carry the long Call Id as described in Section 6. 929 - The SENDER_TEMPLATE object includes as Sender Address any of the 930 call initiating (ingress) node's IPv4/IPv6 routable addresses. The 931 LSP_ID is not relevant and SHOULD be set to zero. 933 - The bandwidth value inserted in the SENDER_TSPEC and FLOWSPEC 934 objects MUST be ignored upon receipt and SHOULD be set to zero 935 when sent. 937 Additionally, ingress/egress nodes that need to communicate their 938 respective link local capabilities may include a LINK_CAPABILITY 939 object in the Notify message. 941 The receiver of a Notify message may identify whether it is part of 942 Call management or reporting an error by the presence or absence of 943 the SESSION ATTRIUBTE object in the . Full 944 clarity, however, may be achieved by inspection of the new Call 945 Management (C) bit in the ADMIN STATUS object. 947 Note that the POLICY_DATA object may be included in the and may be used to identify requestor credentials, 949 account numbers, limits, quotas, etc. This object is opaque to RSVP, 950 which simply passes it to policy control when required. 952 Message IDs MUST be used during independent Call setup. 954 7.2.1 Accepting Independent Call Setup 956 A node that receives a Notify message carrying the ADMIN STATUS 957 object with the R and C bits set is being requested to set up a Call. 958 The receiver may perform authorization and policy according to local 959 requirements. 961 If the Call is acceptable, the receiver responds with a Notify 962 message reflecting the information from the Call request with two 963 exceptions. 965 - The responder removes any LINK CAPABLITY object that was received 966 and MAY insert a LINK CAPABILITY object that describes its own 967 access link. 969 - The ADMIN STATUS object is sent with only the C bit set. All other 970 bits MUST be set to zero. 972 The responder MAY use the Message ID object to ensure reliable 973 delivery of the response. If no Message ID Acknowledgement is 974 received after the configured number of retries, the responder should 976 D.Papadimitriou et al. - Expires January 2006 18 977 continue to assume that the Call was successfully established. Call 978 liveliness procedures are covered in section 7.8. 980 7.2.2 Rejecting Independent Call Setup 982 Call setup may fail or be rejected. 984 If the Notify message can not be delivered, no Message ID 985 acknowledgement will be received by the sender. In the event that the 986 sender has retransmitted the Notify message a configurable number of 987 times without receiving a Message ID Acknowledgement (as described in 988 [RFC3473]), the initiator SHOULD declare the Call failed and SHOULD 989 send a Call teardown request (see section 7.7). 991 It is also possible that a Message ID Acknowledgement is received but 992 no Call response Notify message is received. In this case, the 993 initiator MAY re-send the Call setup request a configurable number of 994 times (see Section 7.8) before declaring the Call has failed. At this 995 point the initiator MUST send a Call teardown request (see Section 996 7.7). 998 If the Notify message cannot be parsed or is in error it MAY be 999 responded to with a Notify message carrying the error code 13 1000 ("Unknown object class") or 14 ("Unknown object C-Type"). 1002 The Call setup may be rejected by the receiver because of security, 1003 authorization or policy reasons. Suitable error codes already exist 1004 and can be used in the ERROR SPEC object included in the Notify 1005 message sent in response. 1007 Error response Notify messages SHOULD also use the Message ID object 1008 to achieve reliable delivery. No action should be taken on the 1009 failure to receive a Message ID Acknowledgement after the configured 1010 number of retries. 1012 7.3 Adding a Connections to a Call 1014 Once a Call has been established, LSPs can be added to the Call. 1015 Since the short Call ID is part of the SESSION Object, any LSP that 1016 has the same Call ID value in the SESSION Object belongs to the same 1017 Call. There will be no confusion between LSPs that are associated 1018 with a Call and those which are not since the Call ID value MUST be 1019 equal to zero for LSPs which are not associated with a Call. 1021 LSPs for different Calls can be distinguished because the Call ID is 1022 unique within the context of the source address (in the SENDER 1023 TEMPLATE object) and the destination address (in the SESSION object). 1025 Ingress and egress nodes may group together LSPs associated with the 1026 same call and process them as a group according to implementation 1027 requirements. Transit nodes need not be aware of the association of 1028 multiple LSPs with the same Call. 1030 D.Papadimitriou et al. - Expires January 2006 19 1031 The ingress node MAY choose to set the "Session Name" of an LSP to 1032 match the long Call ID of the associated Call and the "Session Name" 1033 MAY still be used to distinguish between virtually concatenated LSPs 1034 belonging to the same Call. Thus, there is not necessarily a one-to- 1035 one mapping between the "Session Name" of an LSP and the short 1036 Call_ID. 1038 The C bit of the ADMIN STATUS object MUST NOT be set on LSP messages. 1040 7.3.1 Adding a Reverse Direction LSP to a Call 1042 Note that once a Call has been established it is symmetric. That is, 1043 either end of the Call may add LSPs to the Call. 1045 Special care is needed when managing LSPs in the reverse direction 1046 since the addresses in the SESSION and SENDER TEMPLATE are reversed. 1047 However, since the short Call ID is unique in the context of a given 1048 ingress-egress address pair it may safely be used to associate the 1049 LSP with the Call. 1051 7.4 Simultaneous Call/Connection Setup 1053 It is not always necessary to establish a Call before adding 1054 Connections to the Call. Where the features made available by 1055 independent Call setup are not required, a simplification can be made 1056 by establish a Call at the same time as the first Connection 1057 associated to the Call. 1059 Simultaneous Call and LSP setup requires the usage of Call 1060 identification and an indication that a Call is being managed. No 1061 other protocol mechanisms beyond those described in [RFC3473] are 1062 needed. Normal RSVP-TE GMPLS processing takes place. 1064 The Path message used to simultaneously set up the Call and LSP MUST 1065 carry the ADMIN STATUS object with the R and C bits set. Other bits 1066 may be set or cleared according to the requirements of LSP setup. The 1067 D bit MUST NOT be set. 1069 The Path message MUST also carry the long Call ID in the Session Name 1070 field of the SESSION ATTRIBUTE object as described above. This field 1071 is not available to contain a Session Name distinct from the Call ID. 1073 A non-zero short Call ID MUST be placed in the new Call ID field of 1074 the SESSION object as described above. The reserved value of zero is 1075 used when the LSP is being set up with no association to a Call. 1077 7.4.1 Accepting Simultaneous Call/Connection Setup 1079 A Path message that requests simultaneous Call and Connection setup 1080 is subject to local authorization and policy procedures applicable to 1081 Call establishment in addition to the standard procedures associated 1082 with LSP setup described in [RFC3473]. 1084 D.Papadimitriou et al. - Expires January 2006 20 1085 If the Call and LSP setup is to be accepted, a Resv message is 1086 returned. The Resv message MUST carry the ADMIN STATUS object with 1087 the R bit clear and the C bit set. Other bits may be set or cleared 1088 according to the requirements of LSP setup. The D bit MUST NOT be 1089 set. 1091 The Call ID MUST be reflected in the SESSION object. 1093 7.4.2 Rejecting Simultaneous Call/Connection Setup 1095 The Path message that is sent to set up a Call and Connection 1096 simultaneously may fail or be rejected. 1098 Failures may include all those reasons described in [RFC3473]. 1099 Additionally, policy and authorization reasons specifically 1100 associated with Call setup may cause the Path message to be rejected. 1102 The PathErr message is issued to signal such failures and no new 1103 error codes are required. It is RECOMMENDED that the procedures for 1104 PathErr with state removal described in [RFC3473] is used during Call 1105 setup failure processing. 1107 7.5 Call-Free Connection Setup 1109 It continues to be possible to set up LSPs as per [RFC3473] without 1110 associating them with a Call. If the short Call ID in the SESSION 1111 Object is set to zero, there is no associated Call and the Session 1112 Name field in the SESSION ATTRIBUTE object SHOULD be interpreted 1113 simply as the name of the session (see [RFC3209]). 1115 The new C bit in the ADMIN STATUS object SHOULD be set to zero in 1116 such messages and MUST be ignored if the Call ID is zero. 1118 7.6 Call Collision 1120 Since Calls are symmetrical, it is possible that both ends of a call 1121 will attempt to establish a Call with the same long Call ID at the 1122 same time. This is only an issue if the source and destination 1123 address pair matches. This situation can be avoided by applying some 1124 rules to the contents of the long Call ID, but that is outside the 1125 scope of this document. 1127 If a node that has sent a Call setup request and has not yet received 1128 a response, itself receives a Call setup request with the same long 1129 Call ID and matching source/destination addresses it should process 1130 as follows. 1132 - If its source address is numerically greater than the remote 1133 source address, it MUST discard the received message and continue 1134 to wait for a response to its setup request. 1136 - If its source address is numerically smaller than the remote 1137 source address, it MUST discard state associated with the Call 1139 D.Papadimitriou et al. - Expires January 2006 21 1140 setup that it initiated, and MUST respond to the received Call 1141 setup. 1143 In the second case, special processing is necessary if simultaneous 1144 Call and Connection establishment was being used. Firstly, the node 1145 that is discarding the Call that it initiated MUST send a PathTear 1146 message to remove state from transit nodes. Secondly, this node may 1147 want to hold onto the Connection request and establish an LSP once 1148 the Call is in place since only the Call that it was trying to 1149 establish has been set up by the destination - the Connection may 1150 still be required. 1152 A further possibility for contention arises when Call IDs are 1153 assigned by a pair of nodes for two distinct Calls that are set up 1154 simultaneously. In this event a node receives a Call setup request 1155 carrying a short Call ID that matches one that it previously sent for 1156 the same address pair. The following processing MUST be followed. 1158 - If the receiver's source address is numerically greater than the 1159 remote source address, the receiver returns an error (Notify 1160 message or PathErr message as appropriate) with the new Error Code 1161 "Call Management" (TBD) and the new Error Value "Call ID 1162 Contention" (TBD). 1164 - If the receiver's source address is numerically less than the 1165 remote source address, the receiver accepts and processes the Call 1166 request. It will receive an error message sent as described above, 1167 and at that point it selects a new short Call ID and re-sends the 1168 Call setup request. 1170 Note: these procedures apply for any combination of independent and 1171 simultaneous call establishment. 1173 7.7 Call/Connection Teardown 1175 As with Call/Connection setup, there are several cases to consider. 1177 - Removal of a Connection from a Call 1178 - Removal of the last Connection from a Call 1179 - Teardown of an "empty" Call 1181 The case of tearing down an LSP that is not associated with a Call 1182 does not need to be examined as it follows exactly the procedures 1183 described in [RFC3473]. 1185 7.7.1 Removal of a Connection from a Call 1187 An LSP that is associated with a Call may be deleted using the 1188 standard procedures described in [RFC3743]. No special procedures are 1189 required. 1191 Note that it is not possible to remove an LSP from a Call without 1192 deleting the LSP. It is not valid to change the short Call ID from 1194 D.Papadimitriou et al. - Expires January 2006 22 1195 non-zero to zero since this involves a change to the SESSION object, 1196 which is not allowed. 1198 7.7.2 Removal of the Last Connection from a Call 1200 When the last LSP associated with a Call is deleted the question 1201 arises as to what happens to the Call. Since a Call may exist 1202 independently of Connections, it is not always acceptable to say that 1203 the removal of the last LSP from a Call removes the Call. 1205 If the Call was set up using independent Call setup (that is, using a 1206 Notify message) the removal of the last LSP does not remove the Call 1207 and the procedures described in the next section MUST be used to 1208 delete the Call. 1210 If the Call was set up using simultaneous Call/Connection 1211 establishment, the removal of the last LSP does remove the Call and 1212 the Call ID becomes invalid. 1214 7.7.3 Teardown of an "Empty" Call 1216 When all LSPs have been removed from a Call that was set up 1217 independent of Connections, the Call may be torn down or left for use 1218 by future LSPs. 1220 Deletion of such Calls is achieved by sending a Notify message just 1221 as for Call setup, but the ADMIN STATUS object carries the R, D and C 1222 bits on the teardown request and the D and C bits on the teardown 1223 response. Other bits MUST be set to zero. 1225 When a Notify message is sent for deleting a call and the initiator 1226 does not receive the corresponding reflected Notify message (or 1227 possibly even the Message ID Ack), the initiator MAY retry the 1228 deletion request using the same retry procedures as used during Call 1229 establishment. If no response is received after full retry, the node 1230 deleting the Call MAY declare the Call deleted, but under such 1231 circumstances the node SHOULD avoid re-using the long or short Call 1232 IDs for at least the five times the Notify refresh period. 1234 7.7.4 Teardown of a Call with Existing Connections 1236 If a Notify request with the D bit of the ADMIN STATUS object set is 1237 received for a Call for which LSPs still exist, the request MUST be 1238 rejected with the Error Code "Call Management" (TBD) and Error Value 1239 "Connection Still Exists" (TBD). 1241 7.7.5 Teardown of a Call from the Egress 1243 Since Calls are symmetric they may be torn down from the ingress or 1244 egress. 1246 If the Call was established using simultaneous Call/Connection setup 1247 the removal of the last LSP deletes the Call. This, regardless of 1249 D.Papadimitriou et al. - Expires January 2006 23 1250 whether the LSP is torn down by using a PathTear message (for an 1251 egress-initiated LSP) or by using a PathErr message with the 1252 Path_State_Removed flag set (for an ingress-initiated LSP). 1254 If the Call was established using independent Call/Connection setup 1255 and the Call is "empty" it may be deleted by the egress sending a 1256 Notify message just as described above. 1258 Note that there is still a possibility that both ends of a Call 1259 initiate a simultaneous Call deletion. In this case, the Notify 1260 message acting as teardown request is interpreted by its recipient as 1261 a teardown response. Since the Notify messages carry the R bit in the 1262 ADMIN STATUS object, they are responded to anyway. If a teardown 1263 request Notify message is received for an unknown Call ID it is, 1264 nevertheless, responded to in the affirmative. 1266 7.8 Control Plane Survivability 1268 Delivery of Notify messages is secured using message ID 1269 acknowledgements as described in previous sections. 1271 Notify messages provide end-to-end communication that does not rely 1272 on constant paths through the network but are routed according to IGP 1273 routing information. No consideration is, therefore, required for 1274 network resilience (for example, make-before-break, protection, fast 1275 re-route), although end-to-end resilience is of interest for node 1276 restart and completely disjoint networks. 1278 Periodic Notify messages SHOULD be sent by the initiator and 1279 terminator of the Call to keep the Call alive and to handle ingress 1280 or egress node restart. The time period for these retransmissions is 1281 a local matter, but it is RECOMMENDED that this period should be 1282 twice the refresh period of the LSPs associated with the Call. The 1283 Notify messages are identical to those sent as if establishing the 1284 Call for the first time, except for the LINK CAPABILITY object, which 1285 may have changed since the Call was first established, due to, e.g., 1286 the establishment of connections, link failures, and the addition of 1287 new component links. The current link information is useful for the 1288 establishment of subsequent connections. A node that receives a 1289 refresh Notify message MUST respond with a Notify response. A node 1290 that receives a refresh Notify message (response or request) MAY 1291 reset its timer - thus, in normal processing, Notify refreshes 1292 involve a single exchange once per time period. 1294 A node that is unsure of the status of a Call MAY immediately send a 1295 Notify message as if establishing the Call for the first time. 1297 Failure to receive a refresh Notify request has no specific meaning. 1298 If it receives no response to a refresh Notify request (including no 1299 Message ID Acknowledgement) a node MAY assume that the remote node is 1300 unreachable or unavailable. It is a local policy matter whether this 1301 causes the local node to teardown associated LSPs and delete the 1302 Call. 1304 D.Papadimitriou et al. - Expires January 2006 24 1305 In the event that an edge node restarts without preserved state, it 1306 MAY relearn LSP state from adjacent nodes and Call state from remote 1307 nodes. If a Path or Resv message is received with a non-zero Call ID 1308 but without the C bit in the ADMIN STATUS, and for a Call ID that is 1309 not recognized, the receiver is RECOMMENDED to assume that the Call 1310 establishment is delayed and ignore the received message. If the Call 1311 setup never materializes the failure by the restarting node to 1312 refresh state will cause the LSPs to be torn down. Optionally, the 1313 receiver of such an LSP message for an unknown Call ID may return an 1314 error (PathErr or ResvErr) with the error code "Call Management" 1315 (TBD) and Error Value "Unknown Call ID" (TBD). 1317 8. Applicability of Call and Connection Procedures 1319 This section considers the applicability of the different Call 1320 establishment procedures at the NNI and UNI reference points. This 1321 section is informative and is not intended to prescribe or prevent 1322 other options. 1324 8.1 Network-initiated Calls 1326 Both independent and simultaneous Call/Connection setups are 1327 applicable. 1329 Since the link properties and other traffic-engineering attributes 1330 are likely known through the IGP, the LINK CAPABILITY object is not 1331 usually required. 1333 In multi-area networks, possibly, access link properties and other 1334 traffic-engineering attributes are not known since the areas do not 1335 leak this sort of information. In this case, the independent Call 1336 setup mechanism may be preferred to allow the inclusion of the LINK 1337 CAPABILITY object. 1339 8.2 User-initiated Calls 1341 Both independent and simultaneous Call/Connection setups are 1342 applicable. 1344 It is possible that the access link properties and other traffic- 1345 engineering attributes are not shared across the core network. In 1346 this case, the independent Call setup mechanism may be preferred to 1347 allow the inclusion of the LINK CAPABILITY object. 1349 Further, the first node in the network may be responsible for 1350 managing the Call. In this case, the Notify message that is used to 1351 set up the Call is addressed to the first node of the core network. 1352 Moreover, neither the long Call ID nor the short Call ID is supplied 1353 (the Session Name Length is set to zero and the Call ID value is set 1354 to zero). The Notify message is passed to the first network node 1355 which is responsible for generating the long and short Call IDs 1356 before dispatching the message to the remote Call end point (which is 1358 D.Papadimitriou et al. - Expires January 2006 25 1359 known from the SESSION object). Similarly, the first network node may 1360 be responsible for generating the long and short Call IDs for 1361 inclusion in Path messages that have the C bit set in the ADMIN 1362 STATUS object. 1364 Further, when used in an overlay context, the first core node is 1365 allowed (see [GMPLS-OVERLAY]) to replace the Session Name assigned by 1366 the ingress node and passed in the Path message. In the case of Call 1367 management, the first network node MUST in addition 1) be aware that 1368 the name it inserts MUST be a long Call ID and 2) replace the long 1369 Call ID when it returns the Resv message to the ingress node. 1371 8.3 External Call Managers 1373 Third party Call management agents may be used to apply policy and 1374 authorization at a point that is neither the initiator nor terminator 1375 of the Call. The previous example is a particular case of this, but 1376 the process and procedures are identical. 1378 8.3.1 Call Segments 1380 Call segments exist between a set of default and configured External 1381 Call Managers along a path between the ingress and egress nodes, and 1382 use the protocols described in this document. 1384 The techniques that are used by a given service provider to identify 1385 which External Call Managers within its network should process a 1386 given call are beyond the scope of this document. 1388 For independent call setup, an External Call manager uses normal IP 1389 routing to route the Notify message to the next External Call 1390 Manager. For simultaneous call/connection setup, an External Call 1391 Manager expands the EXPLICIT_ROUTE Object to route the Path message 1392 to the next External Call Manager. 1394 9. Non-support of Call ID 1396 It is important that the procedures described above operate as 1397 seamlessly as possible with legacy nodes that do not support the 1398 extensions described. 1400 Clearly there is no need to consider the case where the Call 1401 initiator does not support Call setup initiation. 1403 9.1 Non-Support by External Call Managers 1405 It is unlikely that a Call initiator will be configured to send Call 1406 establishment Notify requests to an external Call manager including 1407 the first network node, if that node does not support Call setup. 1409 A node that receives an unexpected Call setup request will fall into 1410 one of the following categories. 1412 D.Papadimitriou et al. - Expires January 2006 26 1413 - Node does not support RSVP. The message will fail to be delivered 1414 or responded. No Message ID Acknowledgement will be sent. The 1415 initiator will retry and then give up. 1417 - Node supports RSVP or RSVP-TE but not GMPLS. The message will be 1418 delivered but not understood. It will be discarded. No Message ID 1419 Acknowledgement will be sent. The initiator will retry and then 1420 give up. 1422 - Node supports GMPLS but not Call management. The message will be 1423 delivered, but parsing will fail because of the presence of the 1424 SESSION ATTRIBUTE object. A Message ID Acknowledgement may be sent 1425 before the parse fails. When the parse fails the Notify message 1426 may be discarded in which case the initiator will retry and then 1427 give up, alternatively a parse error may be generated and returned 1428 in a Notify message which will indicate to the initiator that Call 1429 management is not set up. 1431 9.2 Non-Support by Transit Node 1433 Transit nodes SHOULD not examine Notify messages that are not 1434 addressed to them. However, they will see short Call IDs in all LSPs 1435 associated with Calls. Further, they will see the C bit in the ADMIN 1436 STATUS object of Path and Resv messages that are used to establish 1437 Calls. 1439 Previous specifications state that these fields SHOULD be ignored on 1440 receipt and MUST be transmitted as zero. This is interpreted by some 1441 implementations as meaning that the fields should be zeroed before 1442 the objects are forwarded. If this happens, LSP setup (and so 1443 possibly Call setup if simultaneous establishment is used) will not 1444 be possible. If either of the fields is zeroed either on the Path or 1445 the Resv message, the Resv will reach the initiator with the field 1446 set to zero - this is indication to the initiator that some node in 1447 the network is preventing Call management. Use of Explicit Routes may 1448 help to mitigate this issue by avoiding such nodes. The use of 1449 independent Call setup may also help since it removes the need for 1450 the C bit in the Path and Resv messages. Ultimately, however, it may 1451 be necessary to upgrade the offending nodes to handle these protocol 1452 extensions. 1454 9.3 Non-Support by Egress Node 1456 It is unlikely that an attempt will be made to set up a Call to 1457 remote node that does not support Calls. 1459 If the egress node does not support Call management through the 1460 Notify message it will react (as described in Section 9.1) in the 1461 same way as an external Call manager. 1463 If the egress node does not support the use of the C bit in the ADMIN 1464 STATUS object or the Call ID in the SESSION object, it MAY respond 1466 D.Papadimitriou et al. - Expires January 2006 27 1467 with the fields zeroed in which case the initiator will know that the 1468 Call setup has failed. 1470 On the other hand, it is possible that the egress will respond 1471 copying the fields from the Path message without understanding or 1472 acting on the fields. In this case the initiator will believe that 1473 the Call has been set up when it has not. This occurrence can be 1474 prevented using the independent Call setup procedures, but is, in any 1475 case, detected when a Notify message is sent to keep the Call alive. 1477 10. Security Considerations 1479 Please refer to each of the referenced documents for a description of 1480 the security considerations applicable to the features that they 1481 provide. 1483 10.1 Call and Connection Security Considerations 1485 Call setup is vulnerable to attacks both of spoofing and denial of 1486 service. Since Call setup uses either Path messages or Notify 1487 messages, the process can be protected by the measures applicable to 1488 securing those messages as described in [RFC3471], [RFC3209] and 1489 [RFC2205]. 1491 Note, additionally, that the process of Call establishment 1492 independent of LSP setup may be used to apply an extra level of 1493 authentication and policy to hop-by-hop LSP setup. It may be possible 1494 to protect the Call setup exchange using end-to-end security 1495 mechanisms such as those provided by Insect (see [RFC2402] and 1496 [RFC2406]). 1498 11. IANA Considerations 1500 A new RSVP object is introduced: 1502 o LINK CAPABILITY object 1504 Class-Num = TBA (form 10bbbbbb) 1506 The Class Number is selected so that nodes not recognizing 1507 this object drop it silently. That is, the top bit is set 1508 and the next bit is cleared. 1510 C-Type = 1 (TE Link Capabilities) 1512 New RSVP Error Codes and Error Values are introduced 1514 o Error Codes: 1516 - Call Management (value TBA) 1518 o Error Values: 1520 D.Papadimitriou et al. - Expires January 2006 28 1521 - Call Management/Call ID Contention (value TBA) 1522 - Call Management/Connections still Exist (value TBA) 1523 - Call Management/Unknown Call ID (value TBA) 1525 12. Acknowledgements 1527 The authors would like to thank George Swallow, Yakov Rekhter, Lou 1528 Berger, Jerry Ash and Kireeti Kompella for their very useful input 1529 and comments to this document. 1531 13. References 1533 13.1 Normative References 1535 [ASON-REQ] D.Papadimitriou, et al., "Requirements for 1536 Generalized MPLS (GMPLS) Usage and Extensions for 1537 Automatically Switched Optical Network (ASON)," Work 1538 in progress, Oct'04. 1540 [BUNDLE] K.Kompella, Y.Rekhter and L.Berger, "Link Bundling 1541 in MPLS Traffic Engineering," Work in Progress. 1543 [GMPLS-CRANK] A.Farrel (Editor) et al., "Crankback Routing 1544 Extensions for MPLS Signaling," Work in progress, 1545 Oct'04. 1547 [GMPLS-FUNCT] J.P.Lang and B.Rajagopalan (Editors) et al., 1548 "Generalized MPLS Recovery Functional 1549 Specification," Work in Progress, Oct'04. 1551 [GMPLS-OVERLAY] G.Swallow et al., "GMPLS RSVP Support for the 1552 Overlay Model," Work in Progress, Oct'04. 1554 [GMPLS-ROUTING] K.Kompella and Y.Rekhter (Editors) et al., "Routing 1555 Extensions in Support of Generalized MPLS," Work in 1556 Progress, Oct'03. 1558 [LMP] J.P.Lang (Editor) et al. "Link Management Protocol 1559 (LMP) - Version 1," Work in progress, Oct'03. 1561 [RFC2026] S.Bradner, "The Internet Standards Process -- 1562 Revision 3," BCP 9, RFC 2026, Oct'96. 1564 [RFC2119] S.Bradner, "Key words for use in RFCs to Indicate 1565 Requirement Levels," BCP 14, RFC 2119, Mar'97. 1567 [RFC2205] R.Braden et al., "Resource ReSerVation Protocol 1568 (RSVP)- Version 1 Functional Specification," 1569 RFC 2205, Sep'97 1571 [RFC2402] S.Kent and R.Atkinson, "IP Authentication Header," 1572 RFC 2402, Nov'98. 1574 D.Papadimitriou et al. - Expires January 2006 29 1576 [RFC2406] S.Kent and R.Atkinson, "IP Encapsulating Payload 1577 (ESP)," RFC 2406, Nov'98. 1579 [RFC3209] D.Awduche et al., "RSVP-TE: Extensions to RSVP for 1580 LSP Tunnels," RFC 3209, Dec'01. 1582 [RFC3471] L.Berger (Editor) et al., "Generalized MPLS - 1583 Signaling Functional Description," RFC 3471, Jan'03. 1585 [RFC3473] L.Berger (Editor) et al., "Generalized MPLS 1586 Signaling - RSVP-TE Extensions," RFC 3473, Jan'03. 1588 [RFC3477] K.Kompella and Y.Rekhter, "Signalling Unnumbered 1589 Links in Resource ReSerVation Protocol - Traffic 1590 Engineering (RSVP-TE)," RFC 3477, Jan'03. 1592 [RFC3667] S.Bradner, "IETF Rights in Contributions", BCP 78, 1593 RFC 3667, February 2004. 1595 [RFC3668] S.Bradner, Ed., "Intellectual Property Rights in IETF 1596 Technology", BCP 79, RFC 3668, February 2004. 1598 [RFC3945] E.Mannie, Ed., "Generalized Multi-Protocol Label 1599 Switching (GMPLS) Architecture", RFC 3945, October 1600 2004. 1602 [RSVP-CHANGE] K.Kompella and J.P.Lang, "Procedures for Modifying 1603 RSVP," Work in Progress, draft-kompella-rsvp-change- 1604 01.txt, Jun'03. 1606 13.2 Informative References 1608 [RFC3474] Z.Lin (Editor), " Documentation of IANA assignments 1609 for Generalized MultiProtocol Label Switching 1610 (GMPLS) Resource Reservation Protocol - Traffic 1611 Engineering (RSVP-TE) Usage and Extensions for 1612 Automatically Switched Optical Network (ASON)," RFC 1613 3474, Mar'03. 1615 [RFC3476] B.Rajagopalan (Editor), "Documentation of IANA 1616 Assignments for Label Distribution Protocol 1617 (LDP), Resource ReSerVation Protocol (RSVP), and 1618 Resource ReSerVation Protocol-Traffic Engineering 1619 (RSVP-TE) Extensions for Optical UNI Signaling," RFC 1620 3476, Mar'03. 1622 For information on the availability of the following documents, 1623 please see http://www.itu.int. 1625 [G.7713] ITU-T, "Distributed Call and Connection Management," 1626 Recommendation G.7713/Y.1304, Nov'01. 1628 D.Papadimitriou et al. - Expires January 2006 30 1630 [G.7713.2] ITU-T, "DCM Signalling Mechanisms Using GMPLS RSVP- 1631 TE," Recommendation G.7713.2, Jan'03. 1633 [G.8080] ITU-T, "Architecture for the Automatically Switched 1634 Optical Network (ASON)," Recommendation G.8080/ 1635 Y.1304, Nov'01 (and Revision, Jan'03). 1637 14. Author's Addresses 1639 Dimitri Papadimitriou (Alcatel) 1640 Fr. Wellesplein 1, 1641 B-2018 Antwerpen, Belgium 1642 Phone: +32 3 240-8491 1643 EMail: dimitri.papadimitriou@alcatel.be 1645 John Drake 1646 Boeing Satellite Systems 1647 2300 East Imperial Highway 1648 El Segundo, CA 90245 1649 EMail: John.E.Drake2@boeing.com 1651 Adrian Farrel 1652 Old Dog Consulting 1653 Phone: +44 (0) 1978 860944 1654 EMail: adrian@olddog.co.uk 1656 Deborah Brungard (AT&T) 1657 Rm. D1-3C22 - 200 S. Laurel Ave. 1658 Middletown, NJ 07748, USA 1659 EMail: dbrungard@att.com 1661 Zafar Ali (Cisco) 1662 100 South Main St. #200 1663 Ann Arbor, MI 48104, USA 1664 EMail: zali@cisco.com 1666 Arthi Ayyangar (Juniper) 1667 1194 N.Mathilda Ave 1668 Sunnyvale, CA 94089, USA 1669 EMail: arthi@juniper.net 1671 Don Fedyk (Nortel Networks) 1672 600 Technology Park Drive 1673 Billerica, MA, 01821, USA 1674 Email: dwfedyk@nortelnetworks.com 1676 D.Papadimitriou et al. - Expires January 2006 31 1677 Appendix 1: Analysis of G.7713.2 against GMPLS RSVP-TE Signaling 1678 Requirements in support of ASON 1680 Informational RFC [RFC3474] (and [RFC3476]) documents the code points 1681 for the signaling extensions defined in [G.7713.2] to meet the 1682 requirements of ASON Distributed Call and Connection Management (DCM) 1683 as specified in [G.7713]. 1685 While [G.7713.2] make use of GMPLS RSVP-TE signaling, there are key 1686 differences from the problem statement in [ASON-REQ] and the solution 1687 it provides. These differences result from the development of a 1688 fuller and clearer set of requirements in [G.8080] after the time 1689 that [G.7713.2] was published and [ASON-REQ] considerations for 1690 compatibility aspects with GMPLS [RFC3473]. These differences lead to 1691 a substantially different protocol solution and implementation. 1693 This appendix analyzes the rationale and the relevance of the 1694 informational IANA code-point assignments RFCs [RFC3474] and 1695 [RFC3476] against the ASON requirements identified in [ASON-REQ]. The 1696 latter details the requirements to be covered by the extensions to 1697 the GMPLS signaling protocols (see [RFC3471] and [RFC3473]) to 1698 support the capabilities of an ASON network. The following are 1699 expected from the GMPLS protocol suite to realize the needed ASON 1700 functionality: 1701 o soft permanent connection capability 1702 o call and connection separation 1703 o call segments 1704 o extended restart capabilities during control plane failures 1705 o extended label usage 1706 o crankback capability 1708 1. Support for UNI and E-NNI Signaling Session 1710 In GMPLS (see [RFC3473] and related), a connection is identified with 1711 a GMPLS tunnel. A tunnel is generally identified with a single LSP 1712 but may be supported by multiple LSPs. 1714 LSP tunnels are identified by a combination of the SESSION and 1715 SENDER_TEMPLATE objects. The relevant fields are as follows. 1717 IPv4 (or IPv6) tunnel end point address 1719 IPv4 (or IPv6) address of the egress node for the tunnel. 1721 Tunnel ID 1723 A 16-bit identifier used in the SESSION that remains constant 1724 over the life of the tunnel. 1726 Extended Tunnel ID 1728 D.Papadimitriou et al. - Expires January 2006 32 1729 A 32-bit (IPv4) or 128-bit (IPv6) identifier used in the SESSION 1730 that remains constant over the life of the tunnel. Normally set 1731 to all zeros. Ingress nodes that wish to narrow the scope of a 1732 SESSION to the ingress-egress pair may place their IP address 1733 here as a globally unique identifier. 1735 IPv4 (or IPv6) tunnel sender address 1737 IPv4 (or IPv6) address for a sender node 1739 LSP ID 1741 A 16-bit identifier used in the SENDER_TEMPLATE and the 1742 FILTER_SPEC that can be changed to allow a sender to share 1743 resources with itself. 1745 The first three of these are in the SESSION object and are the basic 1746 identification of the tunnel. The "Extended Tunnel ID" MAY be set to 1747 an IP address of the head-end LSR allowing the scope of the SESSION 1748 to be narrowed to only LSPs sent by that node. The last two are in 1749 the SENDER_TEMPLATE. Multiple LSPs may belong to the same tunnel (and 1750 thus SESSION) and in this case they are uniquely identified by their 1751 LSP IDs. 1753 In contrast, [G.7713.2] defines an E-NNI IPv4/IPv6 SESSION object and 1754 an UNI IPv4/IPv6 SESSION object. It mandates the use of these objects 1755 to support the E-NNI (UNI, respectively) signaling session when IPv4 1756 and IPv6 addressing is used. The "Tunnel End-point Address" field 1757 contains the IPv4 or IPv6 address of the downstream controller. In 1758 addition, [G.7713.2] mandates that the "Extended Tunnel ID" field to 1759 be set to the IPv4 or IPv6 of the upstream controller. It also 1760 mandates that the tunnel sender address field of the SENDER_TEMPLATE 1761 be set to the IPv4 or the IPv6 address of the upstream controller. 1763 Thus, these RFCs define a point-to-point signaling interface allowing 1764 for LSP tunnel provisioning between adjacent controllers only. This 1765 approach mandates the introduction of an additional object and sub- 1766 objects for connection identification purposes (see [G.7713.2]): the 1767 GENERALIZED_UNI object and its connection end-point address sub- 1768 objects (IPv4/IPv6/NSAP) referred to as "TNA or Transport Network 1769 Address" as defined by the [OIF-UNI] implementation agreement. 1771 The situation is summarized in the following table, using the 1772 following example and a connection set from node A to Z: 1774 UNI E-NNI E-NNI UNI 1775 A ----- B -- ... -- I ----- J -- .. -- M ----- N -- ... -- Y ----- Z 1777 At node I, the GMPLS compliant [RFC3473] Path message would include 1778 the following information in the IP header, the SESSION and 1779 SENDER_TEMPLATE objects: 1781 D.Papadimitriou et al. - Expires January 2006 33 1782 Source IP address (Header): Node I IP Controller Address 1783 Dest. IP address (Header): Node J IP Controller Address 1784 Tunnel End-point Address: Routable Node Z IP Address 1785 Tunnel ID: 16 bit (selected by the sender) 1786 Extended Tunnel ID: optionally set to Node A IP Address 1787 Tunnel Sender Address: Routable Node A IP Address 1788 LSP ID: 16 bit (selected by the sender) 1790 At node I, the [G.7713.2] Path message would include the following: 1792 Source IP address (Header): Node I IP Controller Address 1793 Dest. IP address (Header): Node J IP Controller Address 1794 Tunnel End-point Address: Node J IP Controller Address 1795 Tunnel ID: 16 bit (selected by the sender) 1796 Extended Tunnel ID: Node I IP Controller Address 1797 Tunnel Sender Address: Node I IP Controller Address 1798 LSP ID: 16 bit (selected by the sender) 1799 GENERALIZED_UNI object: 1800 - Source Address (Connection): End-point A Address (IPv4/IPv6/NSAP) 1801 - Dest. Address (Connection): End-point Z Address (IPv4/IPv6/NSAP) 1803 The same observation would apply at node M, by replacing I by M and J 1804 by N. 1806 The following can be thus deduced from the above example: 1808 1. For a given connection, the [G.7713.2] point-to-point signaling 1809 interface leads to a sequence of at least N different 1810 identifications of the same connection when crossing N 1811 signaling interfaces (due to the setup and maintenance of N 1812 distinct LSP tunnels). 1814 2. The information included in the RSVP message header and in the 1815 SESSION/SENDER_TEMPLATE objects, is redundant in [G.7713.2]. 1817 3. [G.7713.2] allows only for single-hop LSP tunnels and mandates 1818 the processing of a new object, i.e. the GENERALIZED_UNI object, 1819 for the definition of the source and destination connection end- 1820 point addresses (A and Z in the above example). 1822 4. The processing of the signaling Path message, in particular, the 1823 EXPLICIT ROUTE object (ERO), mandates the processing of the 1824 GENERALIZED_UNI object at E-NNI reference points and at UNI 1825 reference points, for the connection end-point addresses (A and 1826 Z, in the above example). 1828 5. Connection end-point addresses A and Z are allowed by [G.7713.2] 1829 to be from different address spaces (for instance, IPv4 source 1830 and IPv6 destination or an IPv4 source and NSAP destination). 1831 Address resolution, management of addresses, e.g., for 1832 uniqueness, and impact evaluation on processing performance, are 1833 not provided in these RFCs (considered out of scope). 1835 D.Papadimitriou et al. - Expires January 2006 34 1836 Note: the [ASON-REQ] addressing model of supporting only IP 1837 addressing is aligned with ITU-T G.7713.1 (PNNI) which only uses 1838 NSAP addresses, multiple address families are not supported. 1840 6. [G.7713.2] defines an incompatible and redundant addressing 1841 mechanism with [RFC3473] to support IPv4, IPv6, and NSAP 1842 addresses. [RFC3473] is part of a GMPLS protocol suite based on 1843 use of IPv4 and IPv6 addresses. The use of NSAP addresses with 1844 [RFC3473] is supported by established procedures defined in 1845 [RFC1884] "IPv6 Addressing Architecture", and only requiring 1846 support by border entities, e.g., DNS. Any other support for 1847 NSAP addressing is redundant with IETF supported procedures. 1848 [G.7713.2] provides no guidance on the operational aspects 1849 resulting from this modified procedure which uses a non-standard 1850 object, the GENERALIZED_UNI object, to support. Use of the 1851 GENERALIZED_UNI object requires every entity to support multi- 1852 address family resolution, e.g., for ERO processing, and in the 1853 case of multi-region path setup. Requiring multi-address family 1854 resolution at all entities severely impacts performance, scaling, 1855 and introduces unnecessary complexity for operations. This 1856 limitation is well recognized, e.g. [G.7713.2] use in demos has 1857 been limited to only IPv4 prefixes with pre-configured mappings. 1859 Conclusion: 1861 1) The solution proposed by [G.7713.2] is not backward compatible 1862 with [RFC3473]. A GMPLS-compliant node [RFC3473] is not interoperable 1863 with a [G.7713.2] node. Also, the "RSVP paradigm" is broken because 1864 the solution requires that all the UNI reference points (A, B and Y, 1865 Z, in the above example) and the E-NNI reference points (I, J and M, 1866 N, in the above example) support the GENERALIZED_UNI object. 1867 Additionally, the management of the network requires maintaining 1868 multiple LSP tunnels per single connection, with no end-to-end view 1869 provided for expedient fault notification or recovery operations. 1871 2) The solution proposed by [G.7713.2] also introduces processing 1872 overhead for address resolution that during time critical operations 1873 (such as recovery) will severely impact performance and scalability. 1874 Whereas the ITU-T G.7713.1 (PNNI) and [ASON-REQ] by using a single 1875 address family (with address mapping provided at edge nodes if 1876 needed) supports a scalable model for inter-domain interworking 1877 applications. 1879 2. Support for Soft Permanent Connections (SPC) 1881 A Soft Permanent Connection (SPC) is defined as a permanent 1882 connection at the network edges and as a switched connection within 1883 the network. 1885 [G.7713.2] mandates the use of the GENERALIZED_UNI subobjects (End- 1886 point Connection Address and SPC_LABEL) to support SPC capability. 1887 Thus, in addition to suffering from the problem described in Section 1888 4, it mandates the processing of an object where it should never 1890 D.Papadimitriou et al. - Expires January 2006 35 1891 occur. This is because SPCs do not assume the existence of a UNI 1892 signaling interface between the source and the destination user-to- 1893 network interface. Note also that the SPC_LABEL as defined in 1894 [G.7713.2] does not comply with the generalized label C-Type 1895 definition of [RFC3473] meaning that an implementation adhering to 1896 [RFC3473] cannot be the "soft" side of the connection. 1898 This requires the mandatory usage of dedicated connection end-point 1899 addresses by the ingress and egress nodes for SPC capability support. 1900 The existing RECORD_ROUTE object and its capabilities get corrupted 1901 by the use of the dedicated end-point address subobjects falling 1902 outside of the corresponding EXPLICIT ROUTE object. 1904 SPC support is already provided by [RFC3473] using Explicit Label 1905 Control and its application to the overlay model in [GMPLS-OVERLAY]. 1906 Therefore, [G.7713.2] defines a new method for an existing capability 1907 of GMPLS signaling. 1909 3. Call/Connection Separation 1911 The call concept for optical networks is defined in [G.8080]. It is 1912 used to deliver the following capabilities: 1913 - Verification and identification of the call initiator (prior to 1914 LSP setup) including negotiation between call ingress/egress nodes 1915 - Support of multiple connections can be associated with a single 1916 call. 1917 - Facilitate control plane operations by allowing operational status 1918 change of the associated LSP. 1920 A call is an agreement between end-points (possibly in cooperation 1921 with the nodes that provide access to the network) used to manage a 1922 set of connections that provide end to end services. While 1923 connections require state to be maintained at nodes along the data 1924 path within the network, *** calls do not involve the participation 1925 of transit nodes except to forward the call management requests as 1926 transparent messages ***. Moreover, a call may be established and 1927 maintained independently of the connections that it supports. 1929 Also, there is a hierarchical relationship between calls and 1930 connections. One or more (or even no) connections may be associated 1931 with a given call but a connection can not be part of more than one 1932 call. A connection may, however, exist without a call. Moreover, the 1933 establishment of a call can be independent ("full call/connection 1934 separation") or simultaneous ("logical call/connection separation") 1935 from the connection setup (i.e. establishing a call before adding 1936 connections to the call or perform these operations simultaneously). 1938 Thus, with the introduction of the call concept, it is necessary to 1939 support a means of identifying the call. This becomes important when 1940 calls and connections are separated and a connection must contain a 1941 reference to its associated call. The following identification 1942 enables this hierarchy: 1943 - Call IDs are unique within the context of the pair of addresses 1945 D.Papadimitriou et al. - Expires January 2006 36 1946 that are the source and destination of the call. 1947 - Tunnel IDs are unique within the context of the Session (that is 1948 the destination of the Tunnel) and Tunnel IDs may be unique within 1949 the context of a Call. 1950 - LSP IDs are unique within the context of a Tunnel. 1952 For this purpose, [G.7713.2] introduces two new objects: a CALL_ID 1953 and a CALL_OPS object to be used in the Path, Resv, PathTear, 1954 PathErr, and Notify messages (note: additional requirements for 1955 ResvErr and ResvTear messages' support are not addressed). The 1956 CALL_OPS object is also referred to as a "call capability" object, 1957 since it specifies the capability of the call. These objects belongs 1958 to the range 224-255 defined as "RSVP will silently ignore, but 1959 FORWARD an object with a Class Number in this range that it does not 1960 understand." 1962 However, the solution described in [G.7713.2]: 1964 - Does not provide backward compatible extensions in support of full 1965 call/connection separation and thus only supports logical call/ 1966 connection separation (i.e. a call with zero connections is not 1967 supported). This because node that does not implement [G.7713.2], 1968 will not process the CALL_OPS object, though it will establish the 1969 *connection* (while forwarding the "Call Setup" message), i.e. 1970 allocating labels and possibly attempting to reserve bandwidth. 1971 [G.7713.2] forbids this behavior by a transit node, but only a 1972 node implementing [G.7713.2] will know the difference between a 1973 call and a connection. 1975 In turn, the required signaling protocol independence between 1976 intra- and inter-domain reference points is broken: an operator 1977 does not have the possibility to use GMPLS [RFC3473] and must 1978 exclusively use [G.7713.2]. 1980 - Does not describe how to support multiple connections per call but 1981 limits the description to a single connection per call. Further, 1982 in the case of complete call/connection separation, it does not 1983 describe how to add the first connection to the call. 1985 - Does not describe how to support multiple connections per call and 1986 limits the description to a single connection per call. Further, 1987 it does not describe how to add the first connection to the call 1988 when to support call/connection separation. 1990 - Does not specify any procedure for negotiating call ingress/egress 1991 node capabilities during call setup. 1993 - Does not allow for call support *independently* of the initiating/ 1994 terminating nodes (the CALL_ID is attached to the ingress node) 1995 thus restricting the flexibility in terms of call identifiers. 1997 - Requires the inclusion of the CALL ID and CALL OPS objects in 1998 PathErr messages that may be generated at transit nodes, which do 2000 D.Papadimitriou et al. - Expires January 2006 37 2001 not implement [G.7713.2] and so do not support these objects. 2003 4. Call Segments 2005 [G.7713.2] cannot, by definition, support call segments signaling 2006 mechanisms, as required in [G.8080] and [G.7713], since [G.7713.2] 2007 does not support full call/connection separation. 2009 5. Control Plane Restart Capabilities 2011 Restart capabilities are provided by GMPLS RSVP-TE signaling in case 2012 of control plane failure including nodal and control channel faults. 2013 The handling of node and control channels faults is described in 2014 [RFC3473] Section 9. No additional RSVP mechanisms or objects are 2015 required to fulfill the ASON control plane restart capabilities. 2017 However, [G.7713.2] defines additional procedures for control plane 2018 recovery, three of them being considered in the context of an 2019 interaction with the management plane and thus outside the scope of 2020 the present document. The last one expects persistent state storage 2021 and the restart mechanism defined in [RFC3473] is to be used for 2022 verification of neighbor states, while the persistent storage 2023 provides the local recovery of lost state. However, per [RFC3473], if 2024 during the Hello synchronization the restarting node determines that 2025 a neighbor does not support state recovery and the restarting node 2026 maintains its local state on a per neighbor basis, the restarting 2027 node should immediately consider the Recovery as completed. Therefore, 2028 the procedure described in [G.7713.2] requires disabling state 2029 recovery on each neighboring node leading also to an unspecified 2030 verification procedure. 2032 6. Extended Label Usage 2034 No specific GMPLS RSVP-TE extensions have been proposed in [G.7713.2] 2035 for extended label usage. 2037 7. Crankback Signaling 2039 [G.7713.2] does not support crankback signaling mechanisms, as 2040 required in [G.8080] and [G.7713]. 2042 8. Security Considerations 2044 This is an informational draft and does not introduce any new 2045 security considerations. 2047 Please refer to each of the referenced documents for a description of 2048 the security considerations applicable to the features that they 2049 provide. 2051 Note that although [RFC3474] is an informational RFC it does document 2052 new protocol elements and functional behavior and as such introduces 2053 new security considerations. In particular, the ability to place 2055 D.Papadimitriou et al. - Expires January 2006 38 2056 authentication and policy details within the context of Call 2057 establishment may strengthen the options for security and may weaken 2058 the security of subsequent Connection establishment. Also the 2059 potential to subvert accidentally or deliberately a soft permanent 2060 connection by establishing the soft part of the connection from a 2061 false remote node needs to be examined. However, [RFC3474] has a 2062 minimal security considerations section. 2064 D.Papadimitriou et al. - Expires January 2006 39 2065 Intellectual Property Statement 2067 The IETF takes no position regarding the validity or scope of any 2068 Intellectual Property Rights or other rights that might be claimed to 2069 pertain to the implementation or use of the technology described in 2070 this document or the extent to which any license under such rights 2071 might or might not be available; nor does it represent that it has 2072 made any independent effort to identify any such rights. Information 2073 on the procedures with respect to rights in RFC documents can be 2074 found in BCP 78 and BCP 79. 2076 Copies of IPR disclosures made to the IETF Secretariat and any 2077 assurances of licenses to be made available, or the result of an 2078 attempt made to obtain a general license or permission for the use of 2079 such proprietary rights by implementers or users of this 2080 specification can be obtained from the IETF on-line IPR repository at 2081 http://www.ietf.org/ipr. 2083 The IETF invites any interested party to bring to its attention any 2084 copyrights, patents or patent applications, or other proprietary 2085 rights that may cover technology that may be required to implement 2086 this standard. Please address the information to the IETF at ietf- 2087 ipr@ietf.org. 2089 Disclaimer of Validity 2091 This document and the information contained herein are provided on an 2092 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2093 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2094 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2095 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2096 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2097 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2099 Copyright Statement 2101 Copyright (C) The Internet Society (2005). This document is subject 2102 to the rights, licenses and restrictions contained in BCP 78, and 2103 except as set forth therein, the authors retain all their rights. 2105 Acknowledgment 2107 Funding for the RFC Editor function is currently provided by the 2108 Internet Society. 2110 D.Papadimitriou et al. - Expires January 2006 40