idnits 2.17.1 draft-ietf-ccamp-gmpls-ason-reqts-07.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.a on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 701. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 678. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 685. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 691. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 707), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 40. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 13 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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 'MUST not' in this paragraph: Backward compatibility means that in a network of nodes, some of which support GMPLS signaling extensions to facilitate the functions described in this document, and some of which do not, it MUST be possible to set up conventional connections (as described by [RFC 3473]) between any arbitrary pair of nodes and traversing any arbitrary set of nodes. Further, the use of any GMPLS signaling extensions to set up calls or connections that support the functions described in this document MUST not perturb existing conventional connections. -- 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 (October 2004) is 7126 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'GMPLS-OVERLAY' is mentioned on line 168, but not defined -- Looks like a reference, but probably isn't: '1' on line 369 -- Looks like a reference, but probably isn't: '0' on line 369 == Unused Reference: 'RFC2026' is defined on line 530, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 538, but no explicit reference was found in the text == Unused Reference: 'RFC3667' is defined on line 550, but no explicit reference was found in the text == Unused Reference: 'RFC3668' is defined on line 553, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3667 (Obsoleted by RFC 3978) ** Obsolete normative reference: RFC 3668 (Obsoleted by RFC 3979) == Outdated reference: A later version (-09) exists of draft-ietf-ccamp-gmpls-g709-08 == Outdated reference: A later version (-06) exists of draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-05 Summary: 9 errors (**), 0 flaws (~~), 10 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group D. Papadimitriou (Alcatel) 2 Internet Draft J. Drake (Calient) 3 Category: Informational J. Ash (ATT) 4 Expiration Date: April 2005 A. Farrel (Old Dog Consulting) 5 L. Ong (Ciena) 7 October 2004 9 Requirements for Generalized MPLS (GMPLS) Signaling Usage 10 and Extensions for Automatically Switched Optical Network (ASON) 12 draft-ietf-ccamp-gmpls-ason-reqts-07.txt 14 Status of this Memo 16 This document is an Internet-Draft and is subject to all provisions 17 of section 3 of RFC 3667. By submitting this Internet-Draft, each 18 author represents that any applicable patent or other IPR claims of 19 which he or she is aware have been or will be disclosed, and any of 20 which he or she become aware will be disclosed, in accordance with 21 RFC 3668. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that other 25 groups may also distribute working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Copyright Notice 40 Copyright (C) The Internet Society (2004). All Rights Reserved. 42 Abstract 44 The Generalized Multi-Protocol Label Switching (GMPLS) suite of 45 protocols has been defined to control different switching 46 technologies as well as different applications. These include support 47 for requesting Time Division Multiplexing (TDM) connections including 48 Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy 49 (SDH) and Optical Transport Networks (OTNs). 51 D.Papadimitriou et al. - Expires April 2005 1 52 This document concentrates on the signaling aspects of the GMPLS 53 suite of protocols. It identifies the features to be covered by the 54 GMPLS signaling protocol to support the capabilities of an 55 Automatically Switched Optical Network (ASON). This document provides 56 a problem statement and additional requirements on the GMPLS 57 signaling protocol to support the ASON functionality. 59 1. Conventions used in this document 61 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 62 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 63 document are to be interpreted as described in [RFC2119]. 65 While [RFC2119] describes interpretations of these key words in terms 66 of protocol specifications and implementations, they are used in this 67 document to describe design requirements for protocol extensions. 69 2. Introduction 71 The Generalized Multi-Protocol Label Switching (GMPLS) suite of 72 protocol specifications provides support for controlling different 73 switching technologies as well as different applications. These 74 include support for requesting Time Division Multiplexing (TDM) 75 connections including Synchronous Optical Network (SONET)/Synchronous 76 Digital Hierarchy (SDH) (see ANSI T1.105 and ITU-T G.707, 77 respectively) as well as Optical Transport Networks (see ITU-T 78 G.709). In addition, there are certain capabilities that are needed 79 to support Automatically Switched Optical Networks control planes 80 (their architecture is defined in [ITU-T G.8080]). These include 81 generic capabilities such as call and connection separation, and more 82 specific capabilities such as support of soft permanent connections. 84 This document concentrates on requirements related to the signaling 85 aspects of the GMPLS suite of protocols. It discusses functional 86 requirements required to support Automatically Switched Optical 87 Networks that may lead to additional extensions to GMPLS signaling 88 (see [RFC3471] and [RFC3473]) to support these capabilities. In 89 addition to ASON signaling requirements, this document includes GMPLS 90 signaling requirements regarding backward compatibility (Section 5). 91 A terminology section is provided in the Appendix. 93 3. Problem Statement 95 The Automatically Switched Optical Network (ASON) architecture 96 describes the application of an automated control plane for 97 supporting both call and connection management services (for a 98 detailed description see [ITU-T G.8080]). The ASON architecture 99 describes a reference architecture, i.e. it describes functional 100 components, abstract interfaces, and interactions. 102 The ASON model distinguishes reference points (representing points of 103 information exchange) defined (1) between a user (service requester) 105 D.Papadimitriou et al. - Expires April 2005 2 106 and a service provider control domain a.k.a. user-network interface 107 (UNI), (2) between control domains a.k.a. external network-network 108 interface (E-NNI) and, (3) within a control domain a.k.a. internal 109 network-network interface (I-NNI). The I-NNI and E-NNI interfaces are 110 between protocol controllers, and may or may not use transport plane 111 (physical) links. It must not be assumed that there is a one-to-one 112 relationship of control plane interfaces and transport plane 113 (physical) links, or that there is a one-to-one relationship of 114 control plane entities and transport plane entities, or that there is 115 a one-to-one relationship of control plane identifiers for transport 116 plane resources. 118 This document describes requirements related to the use of GMPLS 119 signaling (in particular, [RFC3471] and [RFC3473]) to provide call 120 and connection management (see [ITU-T G.7713]). The functionality to 121 be supported includes: 122 (a) soft permanent connection capability 123 (b) call and connection separation 124 (c) call segments 125 (d) extended restart capabilities during control plane failures 126 (e) extended label association 127 (f) crankback capability 128 (g) additional error cases. 130 4. Requirements for Extending Applicability of GMPLS to ASON 132 The next sections detail the signaling protocol requirements for 133 GMPLS to support the ASON functions listed in Section 3. ASON defines 134 a reference model and functions (information elements) to enable end- 135 to-end call and connection support by a protocol across the 136 respective interfaces, regardless of the particular choice of 137 protocol(s) used in a network. ASON does not restrict the use of 138 other protocols or the protocol-specific messages used to support the 139 ASON functions. Therefore, the support of these ASON functions by a 140 protocol shall not be restricted by (i.e. must be strictly 141 independent of and agnostic to) any particular choice of UNI, I-NNI, 142 or E-NNI used elsewhere in the network. In order to allow for 143 interworking between different protocol implementations, [ITU-T 144 G.7713] recognizes an interworking function may be needed. 146 In support of the G.8080 end-to-end call model across different 147 control domains, end-to-end signaling should be facilitated 148 regardless of the administrative boundaries, protocols within the 149 network or method of realization of connections within any part of 150 the network. This implies that there needs to be a clear mapping of 151 ASON signaling requests between GMPLS control domains and non-GMPLS 152 control domains. This document provides signaling requirements for 153 G.8080 distributed call and connection management based on GMPLS, 154 within a GMPLS based control domain (I-NNI) and between GMPLS based 155 control domains (E-NNI). It does not restrict use of other (non 156 GMPLS) protocols to be used within a control domain or as an E-NNI or 157 UNI. Interworking aspects related to the use of non-GMPLS protocols 159 D.Papadimitriou et al. - Expires April 2005 3 160 as UNI, E-NNI, or I-NNI, including mapping of non-GMPLS protocol 161 signaling requests to corresponding ASON signaling functionality and 162 support of non-GMPLS address formats, is not within the scope of the 163 GMPLS signaling protocol. Interworking aspects are implementation- 164 specific and strictly under the responsibility of the interworking 165 function, and thus outside the scope of this document. 167 Any User-Network Interface (UNI) that is compliant with [RFC3473], 168 e.g. [GMPLS-OVERLAY] and [GMPLS-VPN] is considered, by definition, to 169 be included within the GMPLS suite of protocols and MUST be supported 170 by the ASON GMPLS signaling functionality. 172 Compatibility aspects of non-GMPLS systems (nodes) within a GMPLS 173 control domain i.e. the support of GMPLS systems and other systems 174 which utilize other signaling protocols or some which may not support 175 any signaling protocols is described. For instance, Section 4.5 176 'Support for Extended Label Association' covers the requirements when 177 a non-GMPLS capable sub-network is introduced or when nodes do not 178 support any signaling protocols. 180 4.1 Support for Soft Permanent Connection (SPC) Capability 182 An SPC is a combination of a permanent connection at the source user- 183 to-network side, a permanent connection at the destination user-to- 184 network side, and a switched connection within the network. An 185 Element Management System (EMS) or a Network Management System (NMS) 186 typically initiates the establishment of the switched connection by 187 communicating with the node that initiates the switched connection 188 (also known as the ingress node). The latter then sets the connection 189 using the distributed GMPLS signaling protocol. For the SPC, the 190 communication method between the EMS/NMS and the ingress node is 191 beyond the scope of this document (so it is for any other function 192 described in this document). 194 The end-to-end connection is thus created by associating the incoming 195 interface of the ingress node with the switched connection within the 196 network, and the outgoing interface of the switched connection 197 terminating network node (also referred to as egress node). An SPC 198 connection is illustrated in the following Figure. This shows user's 199 node A connected to a provider's node B via link #1, user's node Z 200 connected to a provider's node Y via link #3, and an abstract link #2 201 connecting provider's node B and node Y. Nodes B and Y are referred 202 to as the ingress and egress (respectively) of the network switched 203 connection. 205 --- --- --- --- 206 | A |--1--| B |-----2-//------| Y |--3--| Z | 207 --- --- --- --- 209 In this instance, the connection on link #1 and link #3 are both 210 provisioned (permanent connections that may be simple links). In 211 contrast, the connection over link #2 is set up using the distributed 213 D.Papadimitriou et al. - Expires April 2005 4 214 control plane. Thus the SPC is composed of the stitching of link #1, 215 #2 and #3. 217 Thus, to support the capability to request an SPC connection: 218 - The GMPLS signaling protocol MUST be capable of supporting the 219 ability to indicate the outgoing link and label information used 220 when setting up the destination provisioned connection. 221 - In addition, due to the inter-domain applicability of ASON 222 networks, the GMPLS signaling protocol SHOULD also support 223 indication of the service level requested for the SPC. In the case 224 where an SPC spans multiple domains, indication of both source and 225 destination endpoints controlling the SPC request MAY be needed. 226 These MAY be done via the source and destination signaling 227 controller addresses. 229 Note that the association at the ingress node between the permanent 230 connection and the switched connection is an implementation matter 231 that may be under the control of the EMS/NMS and is not within the 232 scope of the signaling protocol. It is, therefore, outside the scope 233 of this document. 235 4.2 Support for Call and Connection Separation 237 A call may be simply described as "An association between endpoints 238 that supports an instance of a service" [ITU-T G.8080]. Thus, it can 239 be considered as a service provided between two end-points, where 240 several calls may exist between them. Multiple connections may be 241 associated to each call. The call concept provides an abstract 242 relationship between two users, where this relationship describes (or 243 verifies) to what extent the users are willing to offer (or accept) 244 service to each other. Therefore, a call does not provide the actual 245 connectivity for transmitting user traffic, but only builds a 246 relationship by which subsequent connections may be made. 248 A call MAY be associated with zero, one or multiple connections. For 249 the same call, connections MAY be of different types and each 250 connection MAY exist independently of other connections, i.e., each 251 connection is setup and released with separate signaling messages. 253 The concept of the call allows for a better flexibility in how end- 254 points set up connections and how networks offer services to users. 255 For example, a call allows: 256 - An upgrade strategy for control plane operations, where a call 257 control component (service provisioning) may be separate from the 258 actual nodes hosting the connections (where the connection control 259 component may reside) 260 - Identification of the call initiator (with both network call 261 controller as well as destination user) prior to connection, which 262 may result in decreasing contention during resource reservation 263 - General treatment of multiple connections which may be associated 264 for several purposes; for example a pair of working and recovery 265 connections may belong to the same call. 267 D.Papadimitriou et al. - Expires April 2005 5 268 To support the introduction of the call concept, GMPLS signaling 269 SHOULD include a call identification mechanism and SHOULD allow for 270 end-to-end call capability exchange. 272 For instance, a feasible structure for the call identifier (to 273 guarantee global uniqueness) MAY concatenate a globally unique fixed 274 ID (e.g., may be composed of country code, carrier code) with an 275 operator specific ID (where the operator specific ID may be composed 276 of a unique access point code - such as source node address - and a 277 local identifier). Other formats SHALL also be possible depending on 278 the call identification conventions between parties involved in the 279 call setup process. 281 4.3 Support for Call Segments 283 As described in [ITU-T G.8080], call segmentation MAY be applied when 284 a call crosses several control domains. As such, an end-to-end call 285 MAY consist of multiple call segments, when the call traverses 286 multiple control domains. For a given end-to-end call, each call 287 segment MAY have one or more associated connections and the number of 288 connections associated with each call segment MAY be different. 290 The initiating caller interacts with the called party by means of one 291 or more intermediate network call controllers located at control 292 domain boundaries (i.e., at inter-domain reference points, UNI or E- 293 NNI). Call segment capabilities are defined by the policies 294 associated at these reference points. 296 This capability allows for independent (policy based) choices of 297 signaling, concatenation, data plane protection and control plane 298 driven recovery paradigms in different control domains. 300 4.4 Support for Extended Restart Capabilities 302 Various types of failures may occur affecting the ASON control plane. 303 Requirements placed on the control plane failure recovery by [ITU-T 304 G.8080] include: 306 - Any control plane failure (i.e. single or multiple control channel 307 and/or controller failure and any combination) MUST NOT result in 308 releasing established calls and connections (including the 309 corresponding transport plane connections). 311 - Upon recovery from a control plane failure, the recovered control 312 entity MUST have the ability to recover the status of the calls 313 and connections established before failure occurrence. 315 - Upon recovery from a control plane failure, the recovered control 316 entity MUST have the ability to recover the connectivity 317 information of its neighbors. 319 D.Papadimitriou et al. - Expires April 2005 6 320 - Upon recovery from a control plane failure, the recovered control 321 entity MUST have the ability to recover the association between 322 the call and its associated connections. 324 - Upon recovery from a control plane failure, calls and connections 325 in the process of being established (i.e. pending call/connection 326 setup requests) SHOULD be released or continued (with setup). 328 - Upon recovery from a control plane failure, calls and connections 329 in the process of being released MUST be released. 331 4.5 Support for Extended Label Association 333 It is an ASON requirement to enable support for G.805 serial compound 334 links. The text below provides an illustrative example of such a 335 scenario, and the associated requirements. 337 Labels are defined in GMPLS (see [RFC3471]) to provide information on 338 the resources used on link local basis for a particular connection. 339 The labels may range from specifying a particular timeslot, a 340 particular wavelength to a particular port/fiber. In the ASON 341 context, the value of a label may not be consistently the same across 342 a link. For example, the figure below illustrates the case where two 343 GMPLS capable nodes (A and Z) are interconnected across two non-GMPLS 344 capable nodes (B and C), where these nodes are all SONET/SDH nodes 345 providing, e.g., a VC-4 service. 347 ----- ----- 348 | | --- --- | | 349 | A |---| B |---| C |---| Z | 350 | | --- --- | | 351 ----- ----- 353 Labels have an associated implicit imposed structure based on 354 [GMPLS-SONET] and [GMPLS-OTN]. Thus, once the local label is 355 exchanged with its neighboring control plane node, the structure of 356 the local label may not be significant to the neighbor node since the 357 association between the local and the remote label may not 358 necessarily be the same. This issue does not present a problem in 359 simple point-to-point connections between two control plane-enabled 360 nodes where the timeslots are mapped 1:1 across the interface. 361 However, once a non-GMPLS capable sub-network is introduced between 362 these nodes (as in the above figure, where the sub-network provides 363 re-arrangement capability for the timeslots) label scoping may become 364 an issue. 366 In this context, there is an implicit assumption that the data plane 367 connections between the GMPLS capable edges already exist prior to 368 any connection request. For instance, node A's outgoing VC-4's 369 timeslot #1 (with SUKLM label=[1,0,0,0,0]) as defined in [GMPLS- 370 SONET]) may be mapped onto node B's outgoing VC-4's timeslot #6 371 (label=[6,0,0,0,0]) may be mapped onto node C's outgoing VC-4's 373 D.Papadimitriou et al. - Expires April 2005 7 374 timeslot #4 (label=[4,0,0,0,0]). Thus by the time node Z receives the 375 request from node A with label=[1,0,0,0,0], the node Z's local label 376 and the timeslot no longer corresponds to the received label and 377 timeslot information. 379 As such, to support this capability, a label association mechanism 380 SHOULD be used by the control plane node to map the received (remote) 381 label into a locally significant label. The information necessary to 382 allow mapping from received label value to a locally significant 383 label value can be derived in several ways including: 384 - Manual provisioning of the label association 385 - Discovery of the label association 387 Either method MAY be used. In case of dynamic association, this 388 implies that the discovery mechanism operates at the timeslot/label 389 level before the connection request is processed at the ingress node. 390 Note that in the case where two nodes are directly connected, no 391 association is required. In particular, for directly connected TDM 392 interfaces no mapping function (at all) is required due to the 393 implicit label structure (see [GMPLS-SONET] and [GMPLS-OTN]). In such 394 instances, the label association function provides a one-to-one 395 mapping of the received to local label values. 397 4.6 Support for Crankback 399 Crankback has been identified as an important requirement for ASON 400 networks. It allows a connection setup request to be retried on an 401 alternate path that detours around a blocked link or node upon a 402 setup failure, for instance, because a link or a node along the 403 selected path has insufficient resources. 405 Crankback mechanisms MAY also be applied during connection recovery 406 by indicating the location of the failed link or node. This would 407 significantly improve the successful recovery ratio for failed 408 connections, especially in situations where a large number of setup 409 requests are simultaneously triggered. 411 The following mechanisms are assumed during crankback signaling: 412 - the blocking resource (link or node) MUST be identified and 413 returned in the error response message towards the repair node 414 (that may or may not be the ingress node); it is also assumed that 415 this process will occur within a limited period of time 416 - the computation (from the repair node) of an alternate path around 417 the blocking link or node that satisfies the initial connection 418 constraints 419 - the re-initiation of the connection setup request from the repair 420 node (i.e. the node that has intercepted and processed the error 421 response message) 423 The following properties are expected for crankback signaling: 424 - Error information persistence: the entity that computes the 425 alternate (re-routing) path SHOULD store the identifiers of the 427 D.Papadimitriou et al. - Expires April 2005 8 428 blocking resources as indicated in the error message until the 429 connection is successfully established or until the node abandons 430 rerouting attempts. Since crankback may happen more than once 431 while establishing a specific connection, the history of all 432 experienced blockages for this connection SHOULD be maintained (at 433 least until the routing protocol updates the state of this 434 information) to perform an accurate path computation avoiding all 435 blockages. 436 - Rerouting attempts limitation: to prevent an endless repetition of 437 connection setup attempts (using crankback information), the 438 number of retries SHOULD be strictly limited. The maximum number of 439 crankback rerouting attempts allowed MAY be limited per connection 440 or per node: 441 - When the number of retries at a particular node is exceeded, the 442 node currently handling the failure reports the error message 443 upstream to the next repair node where further rerouting attempts 444 MAY be performed. It is important that the crankback information 445 provided indicates that re-routing through this node will not 446 succeed. 447 - When the maximum number of retries for a specific connection 448 has been exceeded, the repair node handling the current 449 failure SHOULD send an error message upstream indicating 450 "Maximum number of re-routings exceeded". This error message 451 will be sent back to the ingress node with no further 452 rerouting attempts. Then, the ingress node MAY choose to 453 retry the connection setup according to local policy but also 454 re-use its original path or compute a path that avoids the 455 blocking resources. 457 Note: after several retries, a given repair point MAY be unable to 458 compute a path to the destination node that avoids all of the 459 blockages. In this case, it MUST pass the error message upstream to 460 the next repair point. 462 4.7 Support for Additional Error Cases 464 To support the ASON network, the following additional category of 465 error cases are defined: 466 - Errors associated with basic call and soft permanent connection 467 support. For example, these MAY include incorrect assignment of 468 IDs for the Call or an invalid interface ID for the soft permanent 469 connection. 470 - Errors associated with policy failure during processing of the new 471 call and soft permanent connection capabilities. These MAY include 472 unauthorized request for the particular capability. 473 - Errors associated with incorrect specification of the service 474 level. 476 5. Backward Compatibility 478 D.Papadimitriou et al. - Expires April 2005 9 479 As noted above, in support of GMPLS protocol requirements, any 480 extensions to the GMPLS signaling protocol in support of the 481 requirements described in this document MUST be backward compatible. 483 Backward compatibility means that in a network of nodes, some of 484 which support GMPLS signaling extensions to facilitate the functions 485 described in this document, and some of which do not, it MUST be 486 possible to set up conventional connections (as described by [RFC 487 3473]) between any arbitrary pair of nodes and traversing any 488 arbitrary set of nodes. Further, the use of any GMPLS signaling 489 extensions to set up calls or connections that support the functions 490 described in this document MUST not perturb existing conventional 491 connections. 493 Additionally, when transit nodes, that do not need to participate in 494 the new functions described in this document, lie on the path of a 495 call or connection, the GMPLS signaling extensions MUST be such that 496 those transit nodes are able to participate in the establishment of 497 the call or connection by passing the setup information onwards, 498 unmodified. 500 Lastly, when a transit or egress node is called upon to support a 501 function described in this document, but does not, the GMPLS 502 signaling extensions MUST be such that they can be rejected by pre- 503 existing GMPLS signaling mechanisms in a way that is not detrimental 504 to the network as a whole. 506 6. Security Considerations 508 Per [ITU-T G.8080], it is not possible to establish a connection in 509 advance of call setup completion. Also, policy and authentication 510 procedures are applied prior to the establishment of the call (and 511 can then also be restricted to connection establishment in the 512 context of this call). 514 This document introduces no new security requirements to GMPLS 515 signaling (see [RFC3471]). 517 7. Acknowledgements 519 The authors would like to thank Nic Larkin, Osama Aboul-Magd and 520 Dimitrios Pendarakis for their contribution to the previous version 521 of this document, Zhi-Wei Lin for his contribution to this document, 522 Deborah Brungard for her input and guidance in our understanding of 523 the ASON model, and Gert Grammel for his decryption effort during the 524 reduction of some parts of this document. 526 8. References 528 8.1 Normative References 530 [RFC2026] S.Bradner, "The Internet Standards Process -- 532 D.Papadimitriou et al. - Expires April 2005 10 533 Revision 3", BCP 9, RFC 2026, October 1996. 535 [RFC2119] S.Bradner, "Key words for use in RFCs to Indicate 536 Requirement Levels", BCP 14, RFC 2119, March 1997. 538 [RFC3209] D.Awduche et al., "RSVP-TE: Extensions to RSVP for 539 LSP Tunnels," RFC 3209, December 2001. 541 [RFC3471] L.Berger (Editor) et al., "Generalized Multi- 542 Protocol Label Switching (GMPLS) - Signaling 543 Functional Description," RFC 3471, January 2003. 545 [RFC3473] L.Berger (Editor) et al., "Generalized Multi-Protocol 546 Label Switching (GMPLS) Signaling - Resource 547 ReserVation Protocol-Traffic Engineering (RSVP-TE) 548 Extensions," RFC 3473, January 2003. 550 [RFC3667] S.Bradner, "IETF Rights in Contributions", BCP 78, 551 RFC 3667, February 2004. 553 [RFC3668] S.Bradner, Ed., "Intellectual Property Rights in IETF 554 Technology", BCP 79, RFC 3668, February 2004. 556 8.2 Informative References 558 [GMPLS-OTN] D.Papadimitriou (Editor), "GMPLS Signaling Extensions 559 for G.709 Optical Transport Networks Control," Work 560 in progress, draft-ietf-ccamp-gmpls-g709-08.txt, 561 September 2004. 563 [GMPLS-OVERLAY]G.Swallow et al., "GMPLS RSVP Support for Overlay 564 Model," Work in Progress, draft-ietf-ccamp-gmpls- 565 overlay-05.txt, October 2004. 567 [GMPLS-SONET] E.Mannie and D.Papadimitriou (Editors), "GMPLS 568 Extensions for SONET and SDH Control, Work in 569 Progress," draft-ietf-ccamp-gmpls-sonet-sdh-08.txt, 570 February 2003. 572 [GMPLS-VPN] H.Ould-Brahim and Y.Rekhter (Editors), "GVPN Services: 573 Generalized VPN Services using BGP and GMPLS 574 Toolkit," Work in Progress, draft-ouldbrahim-ppvpn- 575 gvpn-bgpgmpls-05.txt, May 2004. 577 For information on the availability of the following documents, 578 please see http://www.itu.int. 580 [ITU-T G.7713] ITU-T "Distributed Call and Connection Management," 581 Recommentation G.7713/Y.1304, November 2001. 583 [ITU-T G.8080] ITU-T "Architecture for the Automatically Switched 584 Optical Network (ASON)," Recommendation G.8080/ 586 D.Papadimitriou et al. - Expires April 2005 11 587 Y.1304, November 2001 (and Revision, January 2003). 589 9. Author's Addresses 591 Dimitri Papadimitriou (Alcatel) 592 Francis Wellesplein 1, 593 B-2018 Antwerpen, Belgium 594 Phone: +32 3 2408491 595 EMail: dimitri.papadimitriou@alcatel.be 597 John Drake (Calient) 598 5853 Rue Ferrari, 599 San Jose, CA 95138, USA 600 EMail: jdrake@calient.net 602 Adrian Farrel 603 Old Dog Consulting 604 Phone: +44 (0) 1978 860944 605 EMail: adrian@olddog.co.uk 607 Gerald R. Ash (ATT) 608 AT&T Labs, Room MT D5-2A01 609 200 Laurel Avenue 610 Middletown, NJ 07748, USA 611 EMail: gash@att.com 613 Lyndon Ong (Ciena) 614 5965 Silver Creek Valley Road 615 San Jose, CA 95138, USA 616 EMail: lyong@ciena.com 618 D.Papadimitriou et al. - Expires April 2005 12 619 Appendix - Terminology 621 This document makes use of the following terms: 623 Administrative domain: See Recommendation G.805. 625 Call: association between endpoints that supports an instance of a 626 service. 628 Connection: concatenation of link connections and sub-network 629 connections that allows the transport of user information between the 630 ingress and egress points of a sub-network. 632 Control plane: performs the call control and connection control 633 functions. Through signaling, the control plane sets up and releases 634 connections, and may restore a connection in case of a failure. 636 (Control) Domain: represents a collection of entities that are 637 grouped for a particular purpose. G.8080 applies this G.805 638 recommendation concept (that defines two particular forms, the 639 administrative domain and the management domain) to the control plane 640 in the form of a control domain. The entities that are grouped in a 641 control domain are components of the control plane. 643 External NNI (E-NNI): interfaces are located between protocol 644 controllers between control domains. 646 Internal NNI (I-NNI): interfaces are located between protocol 647 controllers within control domains. 649 Link: See Recommendation G.805. 651 Management plane: performs management functions for the Transport 652 Plane, the control plane and the system as a whole. It also provides 653 coordination between all the planes. The following management 654 functional areas are performed in the management plane: performance, 655 fault, configuration, accounting and security management 657 Management domain: See Recommendation G.805. 659 Transport plane: provides bi-directional or unidirectional transfer 660 of user information, from one location to another. It can also 661 provide transfer of some control and network management information. 662 The Transport Plane is layered; it is equivalent to the Transport 663 Network defined in G.805. 665 User Network Interface (UNI): interfaces are located between protocol 666 controllers between a user and a control domain. 668 D.Papadimitriou et al. - Expires April 2005 13 669 Intellectual Property Statement 671 The IETF takes no position regarding the validity or scope of any 672 Intellectual Property Rights or other rights that might be claimed to 673 pertain to the implementation or use of the technology described in 674 this document or the extent to which any license under such rights 675 might or might not be available; nor does it represent that it has 676 made any independent effort to identify any such rights. Information 677 on the procedures with respect to rights in RFC documents can be 678 found in BCP 78 and BCP 79. 680 Copies of IPR disclosures made to the IETF Secretariat and any 681 assurances of licenses to be made available, or the result of an 682 attempt made to obtain a general license or permission for the use of 683 such proprietary rights by implementers or users of this 684 specification can be obtained from the IETF on-line IPR repository at 685 http://www.ietf.org/ipr. 687 The IETF invites any interested party to bring to its attention any 688 copyrights, patents or patent applications, or other proprietary 689 rights that may cover technology that may be required to implement 690 this standard. Please address the information to the IETF at 691 ietf-ipr@ietf.org. 693 Disclaimer of Validity 695 This document and the information contained herein are provided on an 696 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 697 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 698 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 699 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 700 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 701 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 703 Copyright Statement 705 Copyright (C) The Internet Society (2004). This document is subject 706 to the rights, licenses and restrictions contained in BCP 78, and 707 except as set forth therein, the authors retain all their rights. 709 Acknowledgment 711 Funding for the RFC Editor function is currently provided by the 712 Internet Society. 714 D.Papadimitriou et al. - Expires April 2005 14