idnits 2.17.1 draft-papadimitriou-ccamp-gmpls-ason-reqts-00.txt: ** The Abstract section seems to be numbered -(226): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 2 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 11 longer pages, the longest (page 7) being 61 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 -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 2003) is 7679 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: 'ITU-T G.8080' is mentioned on line 352, but not defined == Missing Reference: 'RFC 3471' is mentioned on line 257, but not defined == Missing Reference: 'ITU-T G.7713' is mentioned on line 125, but not defined -- Looks like a reference, but probably isn't: '1' on line 292 -- Looks like a reference, but probably isn't: '0' on line 292 == Missing Reference: 'RFC3471' is mentioned on line 359, but not defined == Unused Reference: 'RFC-2026' is defined on line 371, but no explicit reference was found in the text == Unused Reference: 'RFC-2119' is defined on line 376, but no explicit reference was found in the text == Unused Reference: 'RFC-3209' is defined on line 379, but no explicit reference was found in the text == Unused Reference: 'RFC-3471' is defined on line 382, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-iwata-mpls-crankback-05 == Outdated reference: A later version (-09) exists of draft-ietf-ccamp-gmpls-g709-03 Summary: 4 errors (**), 0 flaws (~~), 13 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group D. Papadimitriou (Alcatel) 3 Internet Draft Z. Lin (New York City Transit) 4 Category: Informational J. Drake (Calient) 5 J. Ash (ATT) 6 Expiration Date: October 2003 A. Farrel (Movaz) 7 L. Ong (Ciena) 9 April 2003 11 Requirements for Generalized MPLS (GMPLS) Usage and Extensions 12 for Automatically Switched Optical Network (ASON) 14 draft-papadimitriou-ccamp-gmpls-ason-reqts-00.txt 16 Status of this Memo 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC-2026. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. Internet-Drafts are draft documents valid for a maximum of 25 six months and may be updated, replaced, or obsoleted by other 26 documents at any time. It is inappropriate to use Internet- Drafts 27 as reference material or to cite them other than as "work in 28 progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 1. Abstract 38 The Generalized MPLS (GMPLS) suite of protocol has been defined to 39 control different switching technologies as well as different 40 applications. These include support for requesting TDM connections 41 including SONET/SDH and Optical Transport Networks (OTNs). 43 This document concentrates on the signaling aspects of the GMPLS 44 suite of protocols. It identifies the features to be covered by the 45 signalling protocol to support the capabilities of an Automatically 46 Switched Optical Network (ASON). This document provides a problem 47 statement and additional requirements on the GMPLS signaling 48 protocol to support the ASON functionality. 50 D.Papadimitriou et al. - Expires October 2003 1 51 2. Conventions used in this document 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 55 this document are to be interpreted as described in RFC-2119. 57 3. Introduction 59 The GMPLS suite of protocol specifications provides support for 60 controlling different switching technologies as well as different 61 applications. These include support for requesting TDM connections 62 including SONET/SDH (see ANSI T1.105 and ITU-T G.707, respectively) 63 as well as Optical Transport Networks (see ITU-T G.709). In 64 addition, there are certain capabilities that are needed to support 65 Automatically Switched Optical Networks control planes (their 66 architecture is defined in [ITU-T G.8080]). These include generic 67 capabilities such as call and connection separation and more 68 specific capabilities such as support of soft permanent connections. 70 This document concentrates on the signaling aspects of the GMPLS 71 suite of protocols (see [RFC 3471]). It discusses functional 72 requirements that lead to additional extensions to GMPLS to support 73 the capabilities as specified in the above referenced document. A 74 terminology section is provided in Appendix. 76 Problem Statement: 78 The Automatic Switched Optical Network (ASON) architecture describes 79 the application of an automated control plane for supporting both 80 call and connection management services (for a detailed description 81 see [ITU-T G.8080]). 83 The ASON control plane specification is meant to be applicable to 84 different transport technologies (e.g., SDH/SONET, OTN) in various 85 networking environments (e.g., inter-carrier, intra-carrier). Also, 86 ASON model distinguishes reference points (representing points of 87 protocol information exchange) defined (1) between an administrative 88 domain and a user (2) between administrative domains and (3) between 89 areas of the same administrative domain and when needed between 90 control components (or simply controllers) within areas. A full 91 description of the ASON terms and relationship between ASON model 92 and GMPLS protocol suite may be found in [IPO-ASON]. 94 This document describes the use of GMPLS signalling (and in 95 particular, [RFC 3471]) to provide call and connection management 96 (see [ITU-T G.7713]). The following functionality are expected from 97 the GMPLS protocol suite: (a) support for soft permanent connection 98 capability (b) support for call and connection separation (c) 99 support for extended restart capabilities during control plane 100 failures (d) support for extended label usage (e) support for 101 crankback capability (f) support for additional error cases. 103 Expires October 2003 2 104 4. Requirements for Extending Applicability of GMPLS to ASON 106 The applicability statements regarding how the GMPLS suite of 107 protocols may be applied to the ASON architecture can be found in 108 [IPO-ASON] and [IPO-REQS]. The former includes a summary of the ASON 109 functions as well as a detailed discussion of the applicability of 110 the GMPLS protocol suite. 112 The next sections detail the requirements concerning the functions 113 including: 115 - Support for soft permanent connection capability 116 - Support for call and connection separation 117 - Support for extended restart capabilities during control plane 118 failures 119 - Support for extended label usage 120 - Support for crankback capability 121 - Support for additional error cases 123 Note: support of the above functions is independent of any user-to- 124 network interface and is therefore not constrained nor restricted by 125 its implementation specifics (see [ITU-T G.8080] and [ITU-T G.7713]) 127 4.1 Support for Soft Permanent Connection (SPC) Capability 129 An SPC is a combination of a permanent connection at the source 130 user-to-network side, a permanent connection at the destination 131 user-to-network side, and a switched connection within the network. 132 An Element Management System (EMS) or a Network Management System 133 (NMS) typically initiates the establishment of the switched 134 connection by communicating with the ingress node. The latter then 135 sets the connection using the distributed GMPLS signaling protocol. 136 For the SPC, the communication method between the EMS/NMS and the 137 ingress node is beyond the scope of this document (so it is for any 138 other function described in this document). 140 The end-to-end connection is thus created by associating the 141 incoming interface of the switched connection initiating (also 142 referred to as ingress node) network node with the switched 143 connection within the network and the outgoing interface of the 144 switched connection terminating (also referred to as egress node) 145 network node. An SPC connection is illustrated in the following 146 Figure, which shows user's node A connected to a provider's node B 147 via link #1, user's node Z connected to a provider's node Y via link 148 #3, and an abstract link #2 connecting provider's node B and node Y. 150 --- --- --- --- 151 | A |--1--| B |-----2-//------| Y |--3--| Z | 152 --- --- --- --- 154 In this instance, the connection on link #1 and link #3 are both 155 provisioned (permanent connections that may be simple links). In 156 contrast, the connection over link #2 is set up using the 158 Expires October 2003 3 159 distributed control plane. Thus the SPC is composed of the splicing 160 of link #1, #2 and #3. 162 Thus to support the capability to request a SPC connection: 164 - The GMPLS signaling protocol must be capable of supporting the 165 ability to indicate the outgoing link and label information used 166 when setting up the destination provisioned connection. 168 - In addition, due to the inter-domain applicability of ASON 169 networks, the GMPLS signaling protocol should also support the 170 indication of the service level requested for the SPC. In the case 171 where an SPC spans multiple domains, indication of both source and 172 destination endpoints controlling the SPC request may be needed. 173 These may be done via the source and destination signalling 174 controller addresses. 176 4.2 Support for Call and Connection Separation 178 A call may be simply described as "An association between endpoints 179 that supports an instance of a service" [ITU-T G.8080]. Thus, it can 180 be considered as a service provided between two end-points, where 181 several calls may exist between them. To each call multiple 182 connections may be associated. The call concept provides an abstract 183 relationship between two users, where this relationship describes 184 (or verifies) at which extent the users are willing to offer (or 185 accept) service to each other. Therefore, a call does not provide 186 the actual connectivity for transmitting user traffic, but only 187 builds a relationship by which subsequent connections may be made. 189 A property of a call is to contain multiple connections, where each 190 connection may be of a different type and where each connection may 191 exist independently of other connections within the same call, i.e., 192 each connection is setup and released with separate Path/Resv 193 messages. For example, a call may contain a set of basic connection 194 and virtual concatenated connections (see [GMPLS-SONET] for 195 corresponding connection signaling extensions). 197 The concept of the call allows for a better flexibility in how end- 198 points set up connections and how network offers services to users. 199 In essence, a call allows: 201 - Support for virtual concatenation where each connection can travel 202 on different diverse paths 204 - Facilitate upgrading strategy of the control plane operations, 205 where a call control (service provisioning) may be separate from 206 actual nodes hosting the connections (where the connection control 207 may reside) 209 - Identification of the call initiator (with both network call 210 controller as well as destination user) prior to connection, which 211 may result in decreasing contention during resource reservation 213 Expires October 2003 4 214 - General treatment of multiple connections which may be associated 215 for several purposes; for example a pair of working and recovery 216 connections may belong to the same call. 218 To support the introduction of the call concept, GMPLS signaling 219 should include a call identification mechanism and allow for end-to- 220 end call capability exchange. 222 For instance, a feasible structure for the call identifier (to 223 guarantee global uniqueness) may concatenate a globally unique fixed 224 ID (e.g., may be composed of country code, carrier code) with an 225 operator specific ID (where the operator specific ID may be composed 226 of a unique access point code � such as source LSR address � and a 227 local identifier). Other formats shall also be possible depending on 228 the call identification conventions between parties involved in the 229 call setup process. 231 4.3 Support for Extended Restart Capabilities 233 Various types of failures may occur affecting the ASON control 234 plane. Requirements placed on the control plane failure recovery by 235 [ITU-T G.8080] include: 237 - Any control plane failure must not result in releasing established 238 connections. 240 - Upon recovery from a control plane failure, the recovered node 241 must have the ability to recover the status of the connections 242 established before failure occurrence. 244 - Upon recovery from a control plane failure, the recovered node 245 must have the ability to recover the connectivity information of 246 its neighbors. 248 - Upon recovery from a control plane failure, connections in the 249 process of been established (i.e. pending connection setup 250 requests) may be released. 252 - Upon recovery from a control plane failure, connections in the 253 process of been released must be released. 255 4.4 Support for Extended Label Usage 257 Labels are defined in GMPLS (see [RFC 3471]) to provide information 258 on the resources used on link local basis for a particular 259 connection. The labels may range from specifying a particular 260 timeslot, a particular wavelength to a particular port/fiber. 262 In the ASON context, the value of a label MAY not be consistently 263 the same across a link. For example, the figure below illustrates 264 the case where two GMPLS capable nodes (A and Z) are interconnected 266 Expires October 2003 5 267 across two non-GMPLS capable nodes (B and C), where these nodes are 268 all SONET/SDH nodes providing, e.g., a VC-4 service. 270 ----- ----- 271 | | --- --- | | 272 | A |---| B |---| C |---| Z | 273 | | --- --- | | 274 ----- ----- 276 Labels have an associated implicit imposed structure based on 277 [GMPLS-SONET] and [GMPLS-OTN]. Thus, once the local label is 278 exchanged with its neighboring control plane node, the structure of 279 the local label MAY not be significant to the neighbor node since 280 the association between the local and the remote label may not 281 necessarily be the same. This issue does not present a problem in a 282 simple point-to-point connections between two control plane-enabled 283 nodes where the timeslots are mapped 1:1 across the interface. 284 However, once a non-GMPLS capable sub-network is introduced between 285 these nodes (as in the above figure, where the sub-network provides 286 re-arrangement capability for the timeslots) label scoping MAY 287 become an issue. 289 In this context, there is an implicit assumption that the data plane 290 connections between the GMPLS capable edges already exist prior to 291 any connection request. For instance, node A's outgoing VC-4's 292 timeslot #1 (with SUKLM label=[1,0,0,0,0]) as defined in [GMPLS- 293 SONET]) may be mapped onto node B�s outgoing VC-4's timeslot #6 294 (label=[6,0,0,0,0]) may be mapped onto node C's outgoing VC-4's 295 timeslot #4 (label=[4,0,0,0,0]). Thus by the time node Z receives 296 the request from node A with label=[1,0,0,0,0], the node Z's local 297 label and the timeslot no longer corresponds to the received label 298 and timeslot information. 300 As such to support this capability, a label association mechanism 301 has to be used by the control plane node to map the received 302 (remote) label into a locally significant label. The information 303 necessary to allow mapping from received label value to a locally 304 significant label value may be derived in several ways including: 306 - Manual provisioning of the label association 307 - Discovery of the label association 309 Either method may be used. In case of dynamic association, this 310 implies that the discovery mechanism operates at the timeslot/label 311 level before the connection request is processed at the ingress 312 node. Note that in the case where two nodes are directly connected, 313 no association is required. In particular, for directly connected 314 TDM interfaces no mapping function (at all) is required due to the 315 implicit label structure (see [GMPLS-SONET] and [GMPLS-OTN]). In 316 such instances, the label association function provides a one-to-one 317 mapping of the received to local label values. 319 Expires October 2003 6 320 4.5 Support for Crankback 322 Crankback has been identified as a requirement for ASON networks. It 323 allows an LSP setup request to be retried on an alternate path that 324 detours around a blocked link or node upon a setup failure. 326 Crankback mechanisms can also be applied to LSP restoration by 327 indicating the location of the failure link or node. This would 328 significantly improve the successful recovery ratio for failed LSPs, 329 especially in situations where a large number of setup requests are 330 simultaneously triggered. [GMPLS-CRANK] specifies crankback GMPLS- 331 based signalling mechanisms. 333 4.6 Support for Additional Error Cases 335 To support the ASON network, the following additional category of 336 error cases are defined: 338 - Errors associated with basic call and soft permanent connection 339 support. For example, these may include incorrect assignment of 340 IDs for the Call or an invalid interface ID for the soft permanent 341 connection. 343 - Errors associated with policy failure during processing of the new 344 call and soft permanent connection capabilities. These may include 345 unauthorized request for the particular capability. 347 - Errors associated with incorrect specification of the service 348 level. 350 5. Security Considerations 352 Per [ITU-T G.8080], a connection cannot be established until the 353 associated call has been set up. Also, policy and authentication 354 procedures are applied prior to the establishment of the call (and 355 can then also be restricted to connection establishment in the 356 context of this call). 358 This document introduces no new security requirements to GMPLS 359 signalling (see [RFC3471]). 361 6. Acknowledgements 363 The authors would like to thank Nic Larkin, Osama Aboul-Magd and 364 Dimitrios Pendarakis for their comments and contributions to the 365 previous version of this document. 367 7. References 369 7.1 Normative References 371 [RFC-2026] S.Bradner, "The Internet Standards Process -- 373 Expires October 2003 7 374 Revision 3", BCP 9, RFC 2026, October 1996. 376 [RFC-2119] S.Bradner, "Key words for use in RFCs to Indicate 377 Requirement Levels", BCP 14, RFC 2119, March 1997. 379 [RFC-3209] D.Awduche et al., "RSVP-TE: Extensions to RSVP for 380 LSP Tunnels," RFC 3209, December 2001. 382 [RFC-3471] L.Berger (Editor) et al., "Generalized MPLS - 383 Signaling Functional Description," RFC 3471, January 384 03. 386 [ITUT G.8080] ITU-T Rec. G.8080/Y.1304, "Architecture for the 387 Automatically Switched Optical Network (ASON)," 388 November 2001 (and Revision, January 2003). 390 [GMPLS-CRANK] A.Farrel (Editor), "Crankback Routing Extensions for 391 MPLS Signaling," Work in Progress, draft-iwata-mpls- 392 crankback-05.txt, March 2003. 394 [GMPLS-SONET] E.Mannie and D.Papadimitriou (Editors), "GMPLS 395 Extensions for SONET and SDH Control, Work in 396 Progress," draft-ietf-ccamp-gmpls-sonet-sdh-08.txt, 397 February 2003. 399 [GMPLS-OTN] D.Papadimitriou (Editor), "GMPLS Signalling 400 Extensions for G.709 Optical Transport Networks 401 Control," Work in progress, draft-ietf-ccamp-gmpls- 402 g709-03.txt, November 2002, 404 7.2 Informative References 406 [IPO-ASON] Aboul-Magd (Editor) et al., "Automatic Switched 407 Optical Network (ASON) Architecture and Its Related 408 Protocols," Work in progress, draft-ietf-ipo-ason- 409 02.txt, March 2002. 411 [IPO-REQS] Y.Xue (Editor) et al., "Optical Network Service 412 Requirements," Work in progress, draft-ietf-ipo- 413 carrier-requirements-05.txt. 415 [ITUT G.7713] ITU-T Rec. G.7713/Y.1304, "Distributed Call and 416 Connection Management," November 2001. 418 8. Author's Addresses 420 Dimitri Papadimitriou (Alcatel) 421 Francis Wellesplein 1, 422 B-2018 Antwerpen, Belgium 423 Email: dimitri.papadimitriou@alcatel.be 425 Zhi-Wei Lin (New York City Transit) 427 Expires October 2003 8 428 2 Broadway, Room C3.25 429 New York, NY 10004 430 Email: zhiwlin@nyct.com 432 John Drake (Calient) 433 5853 Rue Ferrari, 434 San Jose, CA 95138, USA 435 Email: jdrake@calient.net 437 Adrian Farrel (Movaz Networks) 438 7926 Jones Branch Drive, 439 McLean, VA 22102, USA 440 Email: afarrel@movaz.com 442 Gerald R. Ash 443 AT&T Labs, Room MT D5-2A01 444 200 Laurel Avenue 445 Middletown, NJ 07748, USA 446 Email: gash@att.com 448 Lyndon Ong (Ciena) 449 5965 Silver Creek Valley Road 450 San Jose, CA 95138, USA 451 Email: lyong@ciena.com 453 Expires October 2003 9 454 Appendix - Terminology 456 This draft defines the following terms: 458 Administrative domain: See Recommendation G.805. 460 Call: association between endpoints that supports an instance of a 461 service. 463 Connection: concatenation of link connections and sub-network 464 connections that allows the transport of user information between 465 the ingress and egress points of a sub-network. 467 Control plane: performs the call control and connection control 468 functions. Through signaling, the control plane sets up and releases 469 connections, and may restore a connection in case of a failure. 471 (Control) Domain: represents a collection of entities that are 472 grouped for a particular purpose. G.8080 applies this G.805 473 recommendation concept (that defines two particular forms, the 474 administrative domain and the management domain) to the control 475 plane in the form of a control domain. The entities that are grouped 476 in a control domain are components of the control plane. 478 External NNI: interfaces are located between protocol controllers 479 between control domains. 481 Internal NNI: interfaces are located between protocol controllers 482 within control domains. 484 Link: See Recommendation G.805. 486 Management plane: performs management functions for the Transport 487 Plane, the control plane and the system as a whole. It also provides 488 coordination between all the planes. The following management 489 functional areas are performed in the management plane: performance, 490 fault, configuration, accounting and security management 492 Management domain: See Recommendation G.805. 494 Transport plane: provides bi-directional or unidirectional transfer 495 of user information, from one location to another. It can also 496 provide transfer of some control and network management information. 497 The Transport Plane is layered; it is equivalent to the Transport 498 Network defined in G.805. 500 Expires October 2003 10 501 Full Copyright Statement 503 "Copyright (C) The Internet Society (2003). All Rights Reserved. 505 This document and translations of it may be copied and furnished to 506 others, and derivative works that comment on or otherwise explain it 507 or assist in its implementation may be prepared, copied, published 508 and distributed, in whole or in part, without restriction of any 509 kind, provided that the above copyright notice and this paragraph 510 are included on all such copies and derivative works. However, this 511 document itself may not be modified in any way, such as by removing 512 the copyright notice or references to the Internet Society or other 513 Internet organizations, except as needed for the purpose of 514 developing Internet standards in which case the procedures for 515 copyrights defined in the Internet Standards process must be 516 followed, or as required to translate it into languages other than 517 English. 519 The limited permissions granted above are perpetual and will not be 520 revoked by the Internet Society or its successors or assigns. 522 This document and the information contained herein is provided on an 523 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 524 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 525 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 526 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 527 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 529 Expires October 2003 11