idnits 2.17.1 draft-ietf-ccamp-gmpls-ason-routing-reqts-05.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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 941. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 918. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 925. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 931. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 947), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** 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 18 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 == Line 504 has weird spacing: '...ristics see ...' == 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: The physical location of RCs for adjacent RA levels, their relationship and their communication protocol(s) are outside the scope of this document. No assumption is made regarding how RCs communicate between adjacent RA levels. If routing information is exchanged between a RC, its parent, and its child RCs, it SHOULD include reachability (see Section 4.5.3) and MAY include, upon policy decision, node and link topology. Communication between RAs only takes place between RCs with a parent/child relationship. RCs of one RA never communicate with RCs of another RA at the same level. There SHOULD not be any dependencies on the different routing protocols used within a RA or in different RAs. == 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 'SHALL not' in this paragraph: ASON uses the term, SubNetwork Point (SNP), for the control plane representation of a transport plane resource. The control plane representation and transport plane topology is NOT assumed to be congruent, the control plane representation SHALL not be restricted by the physical topology. The relational grouping of SNPs for routing is termed a SNP Pool (SNPP). The routing function understands topology in terms of SNPP links. Grouping MAY be based on different link attributes (e.g., SRLG information, link weight, etc). == 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: In summary, the ASON routing architecture assumes: - A network is subdivided into ASON RAs, which MAY support multiple routing protocols, no one-to-one relationship SHALL be assumes. - Routing Controllers (RC) provide for the exchange of routing information (primitives) for the RA. The RC is protocol independent and MAY be realized by multiple, different protocol controllers within a RA. The routing information exchanged between RCs SHALL be subject to policy constraints imposed at reference points (External- and Internal-NNI). - In a multi-level RA hierarchy based on containment, communication between RCs of different RAs only happens when there is a parent/ child relationship between the RAs. RCs of child RAs never communicate with the RCs of other child RAs. There SHOULD not be any dependencies on the different routing protocols used within a child RA and that of its parent. The routing information exchanged within the parent RA SHALL be independent of both the routing protocol operating within a child RA, and any control distribution choice(s), e.g. centralized, fully distributed. - For a RA, the set of RCs is referred to as an ASON routing (control) domain. The routing information exchanged between routing domains (inter-RA, i.e. inter-domain) SHALL be independent of both the intra-domain routing protocol(s), and the intra-domain control distribution choice(s), e.g. centralized, fully distributed. RCs bounded to different RA levels MAY be co-located within the same physical element or physically distributed. - The routing adjacency topology (i.e. the associated PC connectivity topology) and the transport network topology SHALL NOT be assumed to be congruent. - The routing topology SHALL support multiple links between nodes and RAs. -- 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 7133 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2026' is defined on line 699, but no explicit reference was found in the text == Unused Reference: 'RFC3667' is defined on line 705, but no explicit reference was found in the text == Unused Reference: 'RFC3668' is defined on line 708, 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) Summary: 9 errors (**), 0 flaws (~~), 9 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Deborah Brungard (ATT) 2 Internet Draft Editor 3 Category: Informational 4 Expiration Date: April 2005 October 2004 6 Requirements for Generalized MPLS (GMPLS) Routing 7 for Automatically Switched Optical Network (ASON) 9 draft-ietf-ccamp-gmpls-ason-routing-reqts-05.txt 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of section 3 of RFC 3667. By submitting this Internet-Draft, each 15 author represents that any applicable patent or other IPR claims of 16 which he or she is aware have been or will be disclosed, and any of 17 which he or she become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that other 22 groups may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). All Rights Reserved. 39 Abstract 41 The Generalized Multi-Protocol Label Switching (GMPLS) suite of 42 protocols has been defined to control different switching 43 technologies as well as different applications. These include support 44 for requesting Time Division Multiplexing (TDM) connections including 45 Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy 46 (SDH) and Optical Transport Networks (OTNs). 48 This document concentrates on the routing requirements on the GMPLS 49 suite of protocols to support the capabilities and functionalities 50 for an Automatically Switched Optical Network (ASON) as defined by 51 ITU-T. 53 D.Brungard et al. - Expires April 2005 1 54 Table of Contents 56 Status of this Memo .............................................. 1 57 Abstract ......................................................... 1 58 Table of Contents ................................................ 2 59 1. Contributors .................................................. 2 60 2. Conventions used in this document ............................. 2 61 3. Introduction .................................................. 2 62 4. ASON Routing Architecture and Requirements .................... 4 63 4.1 Multiple Hierarchical Levels of ASON Routing Areas (RAs) ..... 5 64 4.2 Hierarchical Routing Information Dissemination ............... 5 65 4.3 Configuration ................................................ 7 66 4.3.1 Configuring the Multi-Level Hierarchy ...................... 7 67 4.3.2 Configuring RC Adjacencies ................................. 8 68 4.4 Evolution .................................................... 8 69 4.5 Routing Attributes ........................................... 8 70 4.5.1 Taxonomy of Routing Attributes ............................. 8 71 4.5.2 Commonly Advertised Information ............................ 9 72 4.5.3 Node Attributes ............................................ 9 73 4.5.4 Link Attributes ........................................... 10 74 5. Security Considerations ...................................... 11 75 6. Conclusions .................................................. 12 76 7. Acknowledgements ............................................. 13 77 8. References ................................................... 14 78 8.1 Normative References ........................................ 14 79 8.2 Informative References ...................................... 14 80 9. Author's Addresses ........................................... 14 81 Appendix 1: ASON Terminology .................................... 16 82 Appendix 2: ASON Routing Terminology ............................ 18 83 Intellectual Property Statement ................................. 19 84 Disclaimer of Validity .......................................... 19 85 Copyright Statement ............................................. 19 87 1. Contributors 89 This document is the result of the CCAMP Working Group ASON Routing 90 Requirements design team joint effort. The following are the design 91 team member authors that contributed to the present document: 93 Wesam Alanqar (Sprint) 94 Deborah Brungard (ATT) 95 David Meyer (Cisco Systems) 96 Lyndon Ong (Ciena) 97 Dimitri Papadimitriou (Alcatel) 98 Jonathan Sadler (Tellabs) 99 Stephen Shew (Nortel) 101 2. Conventions used in this document 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in RFC 2119 [RFC2119]. 107 D.Brungard et al. - Expires April 2005 2 108 While [RFC2119] describes interpretations of these key words in terms 109 of protocol specifications and implementations, they are used in this 110 document to describe design requirements for protocol extensions. 112 3. Introduction 114 The Generalized Multi-Protocol Label Switching (GMPLS) suite of 115 protocols provides among other capabilities support for controlling 116 different switching technologies. These include support for 117 requesting TDM connections utilizing SONET/SDH (see ANSI T1.105/ITU-T 118 G.707, respectively) as well as Optical Transport Networks (OTN, see 119 ITU-T G.709). However, there are certain capabilities that are needed 120 to support the ITU-T G.8080 control plane architecture for 121 Automatically Switched Optical Network (ASON). Therefore, it is 122 desirable to understand the corresponding requirements for the GMPLS 123 protocol suite. The ASON control plane architecture is defined in 124 [G.8080], ASON routing requirements are identified in [G.7715], and 125 in [G.7715.1] for ASON link state protocols. These Recommendations 126 apply to all G.805 layer networks (e.g. SDH and OTN), and provide 127 protocol neutral functional requirements and architecture. 129 This document focuses on the routing requirements for the GMPLS suite 130 of protocols to support the capabilities and functionality of ASON 131 control planes. This document summarizes the ASON requirements using 132 ASON terminology. This document does not address GMPLS applicability 133 or GMPLS capabilities. Any protocol (in particular, routing) 134 applicability, design or suggested extensions is strictly outside the 135 scope of this document. ASON (Routing) terminology sections are 136 provided in Appendix 1 and 2. 138 The ASON routing architecture is based on the following assumptions: 139 - A network is subdivided based on operator decision and criteria 140 (e.g. geography, administration, and/or technology), the network 141 subdivisions are defined in ASON as Routing Areas (RAs). 142 - The routing architecture and protocols applied after the network 143 is subdivided is an operator's choice. A multi-level hierarchy of 144 RAs, as defined in ITU-T [G.7715] and [G.7715.1], provides for a 145 hierarchical relationship of RAs based on containment, i.e. child 146 RAs are always contained within a parent RA. The hierarchical 147 containment relationship of RAs provides for routing information 148 abstraction, thereby enabling scalable routing information 149 representation. The maximum number of hierarchical RA levels to be 150 supported is not specified (outside the scope). 151 - Within an ASON RA and for each level of the routing hierarchy, 152 multiple routing paradigms (hierarchical, step-by-step, source- 153 based), centralized or distributed path computation, and multiple 154 different routing protocols MAY be supported. The architecture 155 does not assume a one-to-one correspondence of a routing protocol 156 and a RA level and allows the routing protocol(s) used within 157 different RAs (including child and parent RAs) to be different. 158 The realization of the routing paradigm(s) to support the 160 D.Brungard et al. - Expires April 2005 3 161 hierarchical levels of RAs is not specified. 162 - The routing adjacency topology (i.e. the associated Protocol 163 Controller (PC) connectivity) and transport topology is NOT 164 assumed to be congruent. 165 - The requirements support architectural evolution, e.g. a change in 166 the number of RA levels, as well as aggregation and segmentation 167 of RAs. 169 The description of the ASON routing architecture provides for a 170 conceptual reference architecture, with definition of functional 171 components and common information elements to enable end-to-end 172 routing in the case of protocol heterogeneity and facilitate 173 management of ASON networks. This description is only conceptual: no 174 physical partitioning of these functions is implied. 176 4. ASON Routing Architecture and Requirements 178 The fundamental architectural concept is the RA and its related 179 functional components (see Appendix 2 on terminology). The routing 180 services offered by a RA are provided by a Routing Performer (RP). A 181 RP is responsible for a single RA, and it MAY be functionally 182 realized using distributed Routing Controllers (RC). The RC, itself, 183 MAY be implemented as a cluster of distributed entities (ASON refers 184 to the cluster as a Routing Control Domain (RCD)). The RC components 185 for a RA receive routing topology information from their associated 186 Link Resource Manager(s) (LRMs) and store this information in the 187 Routing Information Database (RDB). The RDB is replicated at each RC 188 bounded to the same RA, and MAY contain information about multiple 189 transport plane network layers. Whenever the routing topology 190 changes, the LRM informs the corresponding RC, which in turn updates 191 its associated RDB. In order to assure RDB synchronization, the RCs 192 co-operate and exchange routing information. Path computation 193 functions MAY exist in each RC, MAY exist on selected RCs within the 194 same RA, or MAY be centralized for the RA. 196 In this context, communication between RCs within the same RA is 197 realized using a particular routing protocol (or multiple protocols). 198 In ASON, the communication component is represented by the protocol 199 controller (PC) component(s) and the protocol messages are conveyed 200 over the ASON control plane's Signaling Control Network (SCN). The PC 201 MAY convey information for one or more transport network layers 202 (refer to Section 4.2 Note). The RC is protocol independent and RC 203 communications MAY be realized by multiple, different PCs within a 204 RA. 206 The ASON routing architecture defines a multi-level routing hierarchy 207 of RAs based on a containment model to support routing information 208 abstraction. [G.7715.1] defines the ASON hierarchical link state 209 routing protocol requirements for communication of routing 210 information within an RA (one level) to support hierarchical routing 211 information dissemination (including summarized routing information 212 for other levels). The communication between any of the other 214 D.Brungard et al. - Expires April 2005 4 215 functional component(s) (e.g. SCN, LRM, and between RCDs (RC-RC 216 communication between RAs)), is outside the scope of [G.7715.1] 217 protocol requirements and, thus, is also outside the scope of this 218 document. 220 ASON Routing components are identified by identifiers that are drawn 221 from different name spaces (see [G.7715.1]). These are control plane 222 identifiers for transport resources, components, and SCN addresses. 223 The formats of those identifiers in a routing protocol realization 224 SHALL be implementation specific and outside the scope of this 225 document. 227 The failure of a RC, or the failure of communications between RCs, 228 and the subsequent recovery from the failure condition MUST NOT 229 disrupt calls in progress (i.e. already established) and their 230 associated connections. Calls being set up MAY fail to complete, and 231 the call setup service MAY be unavailable during recovery actions. 233 4.1 Multiple Hierarchical Levels of ASON Routing Areas (RAs) 235 [G.8080] introduces the concept of Routing Area (RA) in reference to 236 a network subdivision. RAs provide for routing information 237 abstraction. Except for the single RA case, RAs are hierarchically 238 contained: a higher level (parent) RA contains lower level (child) 239 RAs that in turn MAY also contain RAs, etc. Thus, RAs contain RAs 240 that recursively define successive hierarchical RA levels. 242 However, the RA containment relationship describes only an 243 architectural hierarchical organization of RAs. It does not restrict 244 a specific routing protocol's realization (e.g. OSPF multi-areas, 245 path computation, etc.). Moreover, the realization of the routing 246 paradigm to support a hierarchical organization of RAs and the number 247 of hierarchical RA levels to be supported is routing protocol 248 specific and outside the scope of this document. 250 In a multi-level hierarchy of RAs, it is necessary to distinguish 251 among RCs for the different levels of the RA hierarchy. Before any 252 pair of RCs establishes communication, they MUST verify they are 253 bound to the same parent RA (see Section 4.2). A RA identifier (RA 254 ID) is required to provide the scope within which the RCs can 255 communicate. To distinguish between RCs bound to the same RA, an RC 256 identifier (RC ID) is required; the RC ID MUST be unique within its 257 containing RA. 259 A RA represents a partition of the data plane, and its identifier 260 (i.e. RA ID) is used within the control plane as a reference to the 261 data plane partition. Each RA within a carrier's network SHALL be 262 uniquely identifiable. RA IDs MAY be associated with a transport 263 plane name space whereas RC IDs are associated with a control plane 264 name space. 266 4.2 Hierarchical Routing Information Dissemination 268 D.Brungard et al. - Expires April 2005 5 269 Routing information can be exchanged between RCs bound to adjacent 270 levels of the RA hierarchy i.e. Level N+1 and N, where Level N 271 represents the RAs contained by Level N+1. The links connecting RAs 272 may be viewed as external links (inter-RA links), and the links 273 representing connectivity within a RA may be viewed as internal links 274 (intra-RA links). The external links to a RA at one level of the 275 hierarchy may be internal links in the parent RA. Intra-RA links of a 276 child RA MAY be hidden from the parent RA's view. 278 The physical location of RCs for adjacent RA levels, their 279 relationship and their communication protocol(s) are outside the 280 scope of this document. No assumption is made regarding how RCs 281 communicate between adjacent RA levels. If routing information is 282 exchanged between a RC, its parent, and its child RCs, it SHOULD 283 include reachability (see Section 4.5.3) and MAY include, upon policy 284 decision, node and link topology. Communication between RAs only 285 takes place between RCs with a parent/child relationship. RCs of one 286 RA never communicate with RCs of another RA at the same level. There 287 SHOULD not be any dependencies on the different routing protocols 288 used within a RA or in different RAs. 290 Multiple RCs bound to the same RA MAY transform (filter, summarize, 291 etc.) and then forward information to RCs at different levels. 292 However, in this case, the resulting information at the receiving 293 level must be self-consistent (i.e. ensure consistency between 294 transform operations performed on routing information at different 295 levels to ensure proper information processing). This MAY be achieved 296 using a number of mechanisms. 298 Note: there is no implied relationship between multi-layer transport 299 networks and multi-level routing. Implementations MAY support a 300 hierarchical routing topology (multi-level) with a single routing 301 protocol instance for multiple transport switching layers or a 302 hierarchical routing topology for one transport switching layer. 304 1. Type of Information Exchanged 306 The type of information flowing upward (i.e. Level N to Level 307 N+1) and the information flowing downward (i.e. Level N+1 to 308 Level N) are used for similar purposes, namely, the exchange of 309 reachability information and summarized topology information to 310 allow routing across multiple RAs. The summarization of topology 311 information may impact the accuracy of routing and may require 312 additional path calculation. 314 The following information exchanges are expected: 316 - Level N+1 visibility to Level N reachability and topology (or 317 upward information communication) allowing RC(s) at Level N+1 318 to determine the reachable endpoints from Level N. 319 - Level N visibility to Level N+1 reachability and topology (or 321 D.Brungard et al. - Expires April 2005 6 322 downward information communication) allowing RC(s) bounded to a 323 RA at Level N to develop paths to reachable endpoints outside 324 of the RA. 326 2. Interactions between Upward and Downward Communication 328 When both upward and downward information exchanges contain 329 endpoint reachability information, a feedback loop could 330 potentially be created. Consequently, the routing protocol MUST 331 include a method to: 333 - prevent information propagated from a Level N+1 RA's RC into 334 the Level N RA's RC from being re-introduced into the Level N+1 335 RA's RC, and 337 - prevent information propagated from a Level N-1 RA's RC into 338 the Level N RA's RC from being re-introduced into the Level N-1 339 RA's RC. 341 The routing protocol SHALL differentiate the routing information 342 originated at a given level RA from derived routing information 343 (received from external RAs), even when this information is 344 forwarded by another RC at the same level. This is a necessary 345 condition to be fulfilled by routing protocols to be loop free. 347 3. Method of Communication 349 Two approaches exist for communication between Level N and N+1. 351 - The first approach places an instance of a Level N routing 352 function and an instance of a Level N+1 routing function in the 353 same system. The communications interface is within a single 354 system and is thus not an open interface subject to 355 standardization. However, information re-advertisement or 356 leaking MUST be performed in a consistent manner to ensure 357 interoperability and basic routing protocol correctness (e.g. 358 cost/metric value). 360 - The second approach places the Level N routing function on a 361 separate system from the Level N+1 routing function. In this 362 case, a communication interface must be used between the 363 systems containing the routing functions for different levels. 364 This communication interface and mechanisms are outside the 365 scope of this document. 367 4.3 Configuration 369 4.3.1 Configuring the Multi-Level Hierarchy 371 The RC MUST support static (i.e. operator assisted) and MAY support 372 automated configuration of the information describing its 373 relationship to its parent and its child within the hierarchical 375 D.Brungard et al. - Expires April 2005 7 376 structure (including RA ID and RC ID). When applied recursively, the 377 whole hierarchy is thus configured. 379 4.3.2 Configuring RC Adjacencies 381 The RC MUST support static (i.e. operator assisted) and MAY support 382 automated configuration of the information describing its associated 383 adjacencies to other RCs within a RA. The routing protocol SHOULD 384 support all the types of RC adjacencies described in Section 9 of 385 [G.7715]. The latter includes congruent topology (with distributed 386 RC) and hubbed topology (e.g. note that the latter does not 387 automatically imply designated RC). 389 4.4 Evolution 391 The containment relationships of RAs may change, motivated by events 392 such as mergers, acquisitions, and divestitures. 394 The routing protocol SHOULD be capable of supporting architectural 395 evolution in terms of number of hierarchical levels of RAs, as well 396 as aggregation and segmentation of RAs. RA ID uniqueness within an 397 administrative domain may facilitate these operations. The routing 398 protocol is not expected to automatically initiate and/or execute 399 these operations. Reconfiguration of the RA hierarchy may not disrupt 400 calls in progress, though calls being set up may fail to complete, 401 and the call setup service may be unavailable during reconfiguration 402 actions. 404 4.5 Routing Attributes 406 Routing for transport networks is performed on a per layer basis, 407 where the routing paradigms MAY differ among layers and within a 408 layer. Not all equipment supports the same set of transport layers or 409 the same degree of connection flexibility at any given layer. A 410 server layer trail may support various clients, involving different 411 adaptation functions. Additionally, equipment may support variable 412 adaptation functionality, whereby a single server layer trail 413 dynamically supports different multiplexing structures. As a result, 414 routing information MAY include layer specific, layer independent, 415 and client/server adaptation information. 417 4.5.1 Taxonomy of Routing Attributes 419 Attributes can be organized according to the following categories: 421 - Node related or link related 423 - Provisioned, negotiated or automatically configured 425 - Inherited or layer specific (client layers can inherit some 426 attributes from the server layer while other attributes like 427 Link Capacity are specified by layer). 429 D.Brungard et al. - Expires April 2005 8 430 (Component) link attributes MAY be statically or automatically 431 configured for each transport network layer. This may lead to 432 unnecessary repetition. Hence, the inheritance property of attributes 433 MAY also be used to optimize the configuration process. 435 ASON uses the term, SubNetwork Point (SNP), for the control plane 436 representation of a transport plane resource. The control plane 437 representation and transport plane topology is NOT assumed to be 438 congruent, the control plane representation SHALL not be restricted 439 by the physical topology. The relational grouping of SNPs for routing 440 is termed a SNP Pool (SNPP). The routing function understands 441 topology in terms of SNPP links. Grouping MAY be based on different 442 link attributes (e.g., SRLG information, link weight, etc). 444 Two RAs may be linked by one or more SNPP links. Multiple SNPP links 445 may be required when component links are not equivalent for routing 446 purposes with respect to the RAs they are attached to, or to the 447 containing RA, or when smaller groupings are required. 449 4.5.2 Commonly Advertised Information 451 Advertisements MAY contain the following common set of information 452 regardless of whether they are link or node related: 453 - RA ID of the RA to which the advertisement is bounded 454 - RC ID of the entity generating the advertisement 455 - Information to uniquely identify advertisements 456 - Information to determine whether an advertisement has been updated 457 - Information to indicate when an advertisement has been derived 458 from a different level RA. 460 4.5.3 Node Attributes 462 All nodes belong to a RA, hence, the RA ID can be considered an 463 attribute of all nodes. Given that no distinction is made between 464 abstract nodes and those that cannot be decomposed any further, the 465 same attributes MAY be used for their advertisement. In the following 466 tables, Capability refers to the level of support required in the 467 realization of a link state routing protocol, whereas Usage refers to 468 the degree of operational control that SHOULD be available to the 469 operator. 471 The following Node Attributes are defined: 473 Attribute Capability Usage 474 ----------- ----------- --------- 475 Node ID REQUIRED REQUIRED 476 Reachability REQUIRED OPTIONAL 478 Table 1. Node Attributes 480 D.Brungard et al. - Expires April 2005 9 481 Reachability information describes the set of endpoints that are 482 reachable by the associated node. It MAY be advertised as a set of 483 associated external (e.g. UNI) address/address prefixes or a set of 484 associated SNPP link IDs/SNPP ID prefixes, the selection of which 485 MUST be consistent within the applicable scope. These are control 486 plane identifiers, the formats of these identifiers in a protocol 487 realization is implementation specific and outside the scope of this 488 document. 490 Note: no distinction is made between nodes that may have further 491 internal details (i.e., abstract nodes) and those that cannot be 492 decomposed any further. Hence the attributes of a node are not 493 considered only as single switch attributes but MAY apply to a node 494 at a higher level of the hierarchy that represents a sub-network. 496 4.5.4 Link Attributes 498 The following Link Attributes are defined: 500 Link Attribute Capability Usage 501 --------------- ----------- --------- 502 Local SNPP link ID REQUIRED REQUIRED 503 Remote SNPP link ID REQUIRED REQUIRED 504 Layer Specific Characteristics see Table 3 506 Table 2. Link Attributes 508 The SNPP link ID MUST be sufficient to uniquely identify (within the 509 Node ID scope) the corresponding transport plane resource taking into 510 account separation of data and control planes (see Section 4.5.1, the 511 control plane representation and transport plane topology is not 512 assumed to be congruent). The SNPP link ID format is routing protocol 513 specific. 515 Note: when the remote end of a SNPP link is located outside of the 516 RA, the remote SNPP link ID is OPTIONAL. 518 The following link characteristic attributes are defined: 520 - Signal Type: This identifies the characteristic information of the 521 layer network. 523 - Link Weight: The metric indicating the relative desirability of a 524 particular link over another e.g. during path computation. 526 - Resource Class: This corresponds to the set of administrative 527 groups assigned by the operator to this link. A link MAY belong to 528 zero, one or more administrative groups. 530 - Connection Types: This attribute identifies whether the local SNP 531 represents a Termination Connection Point (CP), a Connection Point 532 (CP), or can be flexibly configured as a TCP. 534 D.Brungard et al. - Expires April 2005 10 535 - Link Capacity: This provides the sum of the available and 536 potential bandwidth capacity for a particular network transport 537 layer. Other capacity measures MAY be further considered. 539 - Link Availability: This represents the survivability capability 540 such as the protection type associated with the link. 542 - Diversity Support: This represents diversity information such as 543 the SRLG information associated with the link. 545 - Local Adaptation Support: This indicates the set of client layer 546 adaptations supported by the TCP associated with the Local SNPP. 547 This is only applicable when the local SNP represents a TCP or can 548 be flexibly configured as a TCP. 550 Link Characteristics Capability Usage 551 ----------------------- ---------- --------- 552 Signal Type REQUIRED OPTIONAL 553 Link Weight REQUIRED OPTIONAL 554 Resource Class REQUIRED OPTIONAL 555 Local Connection Types REQUIRED OPTIONAL 556 Link Capacity REQUIRED OPTIONAL 557 Link Availability OPTIONAL OPTIONAL 558 Diversity Support OPTIONAL OPTIONAL 559 Local Adaptation support OPTIONAL OPTIONAL 561 Table 3. Link Characteristics 563 Note: separate advertisements of layer specific attributes MAY be 564 chosen. However, this may lead to unnecessary duplication. This can 565 be avoided using the inheritance property, so that the attributes 566 derivable from the local adaptation information do not need to be 567 advertised. Thus, an optimization MAY be used when several layers are 568 present by indicating when an attribute is inheritable from a server 569 layer. 571 5. Security Considerations 573 ASON routing protocol MUST deliver the operational security 574 objectives where required. The overall security objectives (defined 575 in ITU-T Recommendation M.3016) of confidentiality, integrity, 576 accountability may take on varying level of importance. These 577 objectives do not necessarily imply requirements on the routing 578 protocol itself, and MAY be met by other established means. 580 Note: a threat analysis of a proposed routing protocol SHOULD address 581 masquerade, eavesdropping, unauthorized access, loss or corruption of 582 information (includes replay attacks), repudiation, forgery and 583 denial of service attacks. 585 D.Brungard et al. - Expires April 2005 11 586 6. Conclusions 588 The description of the ASON routing architecture and components is 589 provided in terms of routing functionality. This description is only 590 conceptual: no physical partitioning of these functions is implied. 592 In summary, the ASON routing architecture assumes: 593 - A network is subdivided into ASON RAs, which MAY support multiple 594 routing protocols, no one-to-one relationship SHALL be assumes. 595 - Routing Controllers (RC) provide for the exchange of routing 596 information (primitives) for the RA. The RC is protocol 597 independent and MAY be realized by multiple, different protocol 598 controllers within a RA. The routing information exchanged between 599 RCs SHALL be subject to policy constraints imposed at reference 600 points (External- and Internal-NNI). 601 - In a multi-level RA hierarchy based on containment, communication 602 between RCs of different RAs only happens when there is a parent/ 603 child relationship between the RAs. RCs of child RAs never 604 communicate with the RCs of other child RAs. There SHOULD not be 605 any dependencies on the different routing protocols used within a 606 child RA and that of its parent. The routing information exchanged 607 within the parent RA SHALL be independent of both the routing 608 protocol operating within a child RA, and any control distribution 609 choice(s), e.g. centralized, fully distributed. 610 - For a RA, the set of RCs is referred to as an ASON routing 611 (control) domain. The routing information exchanged between 612 routing domains (inter-RA, i.e. inter-domain) SHALL be independent 613 of both the intra-domain routing protocol(s), and the intra-domain 614 control distribution choice(s), e.g. centralized, fully 615 distributed. RCs bounded to different RA levels MAY be co-located 616 within the same physical element or physically distributed. 617 - The routing adjacency topology (i.e. the associated PC 618 connectivity topology) and the transport network topology SHALL 619 NOT be assumed to be congruent. 620 - The routing topology SHALL support multiple links between nodes 621 and RAs. 623 In summary, the following functionality is expected from GMPLS 624 routing to instantiate the ASON hierarchical routing architecture 625 realization (see [G.7715] and [G.7715.1]): 626 - RAs SHALL be uniquely identifiable within a carrier's network, 627 each having a unique RA ID within the carrier's network. 628 - Within a RA (one level), the routing protocol SHALL support 629 dissemination of hierarchical routing information (including 630 summarized routing information for other levels) in support of an 631 architecture of multiple hierarchical levels of RAs; the number of 632 hierarchical RA levels to be supported by a routing protocol is 633 implementation specific. 634 - The routing protocol SHALL support routing information based on a 635 common set of information elements as defined in [G.7715] and 636 [G.7715.1], divided between attributes pertaining to links and 637 abstract nodes (each representing either a sub-network or simply a 639 D.Brungard et al. - Expires April 2005 12 640 node). [G.7715] recognizes that the manner in which the routing 641 information is represented and exchanged will vary with the 642 routing protocol used. 643 - The routing protocol SHALL converge such that the distributed RDBs 644 become synchronized after a period of time. 646 To support hierarchical routing information dissemination within an 647 RA, the routing protocol MUST deliver: 648 - Processing of routing information exchanged between adjacent 649 levels of the hierarchy (i.e. Level N+1 and N) including 650 reachability and upon policy decision summarized topology 651 information. 652 - Self-consistent information at the receiving level resulting from 653 any transformation (filter, summarize, etc.) and forwarding of 654 information from one RC to RC(s) at different levels when multiple 655 RCs bound to a single RA. 656 - A mechanism to prevent re-introduction of information propagated 657 into the Level N RA's RC back to the adjacent level RA's RC from 658 which this information has been initially received. 660 In order to support operator assisted changes in the containment 661 relationships of RAs, the routing protocol SHALL support evolution in 662 terms of number of hierarchical levels of RAs. For example: support 663 of non-disruptive operations such as adding and removing RAs at the 664 top/bottom of the hierarchy, adding or removing a hierarchical level 665 of RAs in or from the middle of the hierarchy, as well as aggregation 666 and segmentation of RAs. The number of hierarchical levels to be 667 supported is routing protocol specific, and reflects a containment 668 relationship e.g. a RA insertion involves supporting a different 669 routing protocol domain in a portion of the network. 671 Reachability information (see Section 4.5.3) of the set of endpoints 672 reachable by a node may be advertised either as a set of UNI 673 Transport Resource addresses/ address prefixes, or a set of 674 associated SNPP link IDs/SNPP link ID prefixes, assigned and selected 675 consistently in their applicability scope. The formats of the control 676 plane identifiers in a protocol realization are implementation 677 specific. Use of a routing protocol within a RA should not restrict 678 the choice of routing protocols for use in other RAs (child or 679 parent). 681 As ASON does not restrict the control plane architecture choice used, 682 either a co-located architecture or a physically separated 683 architecture may be used. A collection of links and nodes such as a 684 sub-network or RA MUST be able to represent itself to the wider 685 network as a single logical entity with only its external links 686 visible to the topology database. 688 7. Acknowledgements 690 D.Brungard et al. - Expires April 2005 13 691 The authors would like to thank Kireeti Kompella for having initiated 692 the proposal of an ASON Routing Requirement Design Team and the ITU-T 693 SG15/Q14 for their careful review and input. 695 8. References 697 8.1 Normative References 699 [RFC2026] S.Bradner, "The Internet Standards Process -- 700 Revision 3", BCP 9, RFC 2026, October 1996. 702 [RFC2119] S.Bradner, "Key words for use in RFCs to Indicate 703 Requirement Levels", BCP 14, RFC 2119, March 1997. 705 [RFC3667] S.Bradner, "IETF Rights in Contributions", BCP 78, 706 RFC 3667, February 2004. 708 [RFC3668] S.Bradner, Ed., "Intellectual Property Rights in IETF 709 Technology", BCP 79, RFC 3668, February 2004. 711 8.2 Informative References 713 For information on the availability of the following documents, 714 please see http://www.itu.int: 716 [G.7715] ITU-T Rec. G.7715/Y.1306, "Architecture and 717 Requirements for the Automatically Switched Optical 718 Network (ASON)," June 2002. 720 [G.7715.1] ITU-T Draft Rec. G.7715.1/Y.1706.1, "ASON Routing 721 Architecture and Requirements for Link State Protocols," 722 November 2003. 724 [G.8080] ITU-T Rec. G.8080/Y.1304, "Architecture for the 725 Automatically Switched Optical Network (ASON)," 726 November 2001 (and Revision, January 2003). 728 9. Author's Addresses 730 Wesam Alanqar (Sprint) 731 EMail: wesam.alanqar@mail.sprint.com 733 Deborah Brungard (AT&T) 734 Rm. D1-3C22 - 200 S. Laurel Ave. 735 Middletown, NJ 07748, USA 736 Phone: +1 732 4201573 737 EMail: dbrungard@att.com 739 David Meyer (Cisco Systems) 740 EMail: dmm@1-4-5.net 742 Lyndon Ong (Ciena Corporation) 744 D.Brungard et al. - Expires April 2005 14 745 5965 Silver Creek Valley Rd, 746 San Jose, CA 95128, USA 747 Phone: +1 408 8347894 748 EMail: lyong@ciena.com 750 Dimitri Papadimitriou (Alcatel) 751 Francis Wellensplein 1, 752 B-2018 Antwerpen, Belgium 753 Phone: +32 3 2408491 754 EMail: dimitri.papadimitriou@alcatel.be 756 Jonathan Sadler 757 1415 W. Diehl Rd 758 Naperville, IL 60563 759 EMail: jonathan.sadler@tellabs.com 761 Stephen Shew (Nortel Networks) 762 PO Box 3511 Station C 763 Ottawa, Ontario, CANADA K1Y 4H7 764 Phone: +1 613 7632462 765 EMail: sdshew@nortelnetworks.com 767 D.Brungard et al. - Expires April 2005 15 768 Appendix 1: ASON Terminology 770 This document makes use of the following terms: 772 Administrative domain: (see Recommendation G.805) for the purposes of 773 [G7715.1] an administrative domain represents the extent of resources 774 which belong to a single player such as a network operator, a service 775 provider, or an end-user. Administrative domains of different players 776 do not overlap amongst themselves. 778 Adaptation function: (see Recommendation G.805) A "transport 779 processing function" which processes the client layer information for 780 transfer over a server layer trail. 782 Client/Server relationship: The association between layer networks 783 that is performed by an "adaptation" function to allow the link 784 connection in the client layer network to be supported by a trail in 785 the server layer network. 787 Control plane: performs the call control and connection control 788 functions. Through signaling, the control plane sets up and releases 789 connections, and may restore a connection in case of a failure. 791 (Control) Domain: represents a collection of (control) entities that 792 are grouped for a particular purpose. The control plane is subdivided 793 into domains matching administrative domains. Within an 794 administrative domain, further subdivisions of the control plane are 795 recursively applied. A routing control domain is an abstract entity 796 that hides the details of the RC distribution. 798 External NNI (E-NNI): interfaces are located between protocol 799 controllers between control domains. 801 Internal NNI (I-NNI): interfaces are located between protocol 802 controllers within control domains. 804 Link: (see Recommendation G.805) a "topological component" which 805 describes a fixed relationship between a "subnetwork" or "access 806 group" and another "subnetwork" or "access group". Links are not 807 limited to being provided by a single server trail. 809 Management plane: performs management functions for the Transport 810 Plane, the control plane and the system as a whole. It also provides 811 coordination between all the planes. The following management 812 functional areas are performed in the management plane: performance, 813 fault, configuration, accounting and security management 815 Management domain: (see Recommendation G.805) a management domain 816 defines a collection of managed objects which are grouped to meet 817 organizational requirements according to geography, technology, 818 policy or other structure, and for a number of functional areas such 819 as configuration, security, (FCAPS), for the purpose of providing 821 D.Brungard et al. - Expires April 2005 16 822 control in a consistent manner. Management domains can be disjoint, 823 contained or overlapping. As such the resources within an 824 administrative domain can be distributed into several possible 825 overlapping management domains. The same resource can therefore 826 belong to several management domains simultaneously, but a management 827 domain shall not cross the border of an administrative domain. 829 Multiplexing: (see Recommendation G.805) Multiplexing techniques are 830 used to combine client layer signals. The many-to-one relationship 831 represents the case of several link connections of client layer 832 networks supported by one server layer trail at the same time. 834 Subnetwork Point (SNP): The SNP is a control plane abstraction that 835 represents an actual or potential transport plane resource. SNPs (in 836 different subnetwork partitions) may represent the same transport 837 resource. A one-to-one correspondence should not be assumed. 839 Subnetwork Point Pool (SNPP): A set of SNPs that are grouped together 840 for the purposes of routing. 842 Termination Connection Point (TCP): A TCP represents the output of a 843 Trail Termination function or the input to a Trail Termination Sink 844 function. 846 Trail: (see Recommendation G.805) A "transport entity" which consists 847 of an associated pair of "unidirectional trails" capable of 848 simultaneously transferring information in opposite directions 849 between their respective inputs and outputs. 851 Transport plane: provides bi-directional or unidirectional transfer 852 of user information, from one location to another. It can also 853 provide transfer of some control and network management information. 854 The Transport Plane is layered; it is equivalent to the Transport 855 Network defined in G.805 Recommendation. 857 User Network Interface (UNI): interfaces are located between protocol 858 controllers between a user and a control domain. Note: there is no 859 routing function associated with a UNI reference point. 861 Variable adaptation function: A single server layer trail may 862 dynamically support different multiplexing structures i.e. link 863 connections for multiple client layer networks. 865 D.Brungard et al. - Expires April 2005 17 866 Appendix 2: ASON Routing Terminology 868 This document makes use of the following terms: 870 Routing Area (RA): a RA represents a partition of the data plane and 871 its identifier is used within the control plane as the representation 872 of this partition. Per [G.8080] a RA is defined by a set of sub- 873 networks, the links that interconnect them, and the interfaces 874 representing the ends of the links exiting that RA. A RA may contain 875 smaller RAs inter-connected by links. The limit of subdivision 876 results in a RA that contains two sub-networks interconnected by a 877 single link. 879 Routing Database (RDB): repository for the local topology, network 880 topology, reachability, and other routing information that is updated 881 as part of the routing information exchange and may additionally 882 contain information that is configured. The RDB may contain routing 883 information for more than one Routing Area (RA). 885 Routing Components: ASON routing architecture functions. These 886 functions can be classified as protocol independent (Link Resource 887 Manager or LRM, Routing Controller or RC) and protocol specific 888 (Protocol Controller or PC). 890 Routing Controller (RC): handles (abstract) information needed for 891 routing and the routing information exchange with peering RCs by 892 operating on the RDB. The RC has access to a view of the RDB. The RC 893 is protocol independent. 895 Note: Since the RDB may contain routing information pertaining to 896 multiple RAs (and possibly to multiple layer networks), the RCs 897 accessing the RDB may share the routing information. 899 Link Resource Manager (LRM): supplies all the relevant component and 900 TE link information to the RC. It informs the RC about any state 901 changes of the link resources it controls. 903 Protocol Controller (PC): handles protocol specific message exchanges 904 according to the reference point over which the information is 905 exchanged (e.g. E-NNI, I-NNI), and internal exchanges with the RC. 906 The PC function is protocol dependent. 908 D.Brungard et al. - Expires April 2005 18 909 Intellectual Property Statement 911 The IETF takes no position regarding the validity or scope of any 912 Intellectual Property Rights or other rights that might be claimed to 913 pertain to the implementation or use of the technology described in 914 this document or the extent to which any license under such rights 915 might or might not be available; nor does it represent that it has 916 made any independent effort to identify any such rights. Information 917 on the procedures with respect to rights in RFC documents can be 918 found in BCP 78 and BCP 79. 920 Copies of IPR disclosures made to the IETF Secretariat and any 921 assurances of licenses to be made available, or the result of an 922 attempt made to obtain a general license or permission for the use of 923 such proprietary rights by implementers or users of this 924 specification can be obtained from the IETF on-line IPR repository at 925 http://www.ietf.org/ipr. 927 The IETF invites any interested party to bring to its attention any 928 copyrights, patents or patent applications, or other proprietary 929 rights that may cover technology that may be required to implement 930 this standard. Please address the information to the IETF at 931 ietf-ipr@ietf.org. 933 Disclaimer of Validity 935 This document and the information contained herein are provided on an 936 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 937 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 938 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 939 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 940 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 941 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 943 Copyright Statement 945 Copyright (C) The Internet Society (2004). This document is subject 946 to the rights, licenses and restrictions contained in BCP 78, and 947 except as set forth therein, the authors retain all their rights. 949 Acknowledgment 951 Funding for the RFC Editor function is currently provided by the 952 Internet Society. 954 D.Brungard et al. - Expires April 2005 19