idnits 2.17.1 draft-malis-ccamp-rfc5787bis-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 11, 2011) is 4761 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT A. Malis, ed. 3 Intended Status: Proposed Standard Verizon Communications 4 Expires: October 13, 2011 A. Lindem, ed. 5 Ericsson 6 April 11, 2011 8 Updates to ASON Routing for OSPFv2 Protocols (RFC 5787bis) 9 draft-malis-ccamp-rfc5787bis-03.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/1id-abstracts.html 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 Copyright and License Notice 34 Copyright (c) 2011 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Abstract 49 The ITU-T has defined an architecture and requirements for operating 50 an Automatically Switched Optical Network (ASON). 52 The Generalized Multiprotocol Label Switching (GMPLS) protocol suite 53 is designed to provide a control plane for a range of network 54 technologies including optical networks such as time division 55 multiplexing (TDM) networks including SONET/SDH and Optical Transport 56 Networks (OTNs), and lambda switching optical networks. 58 The requirements for GMPLS routing to satisfy the requirements of 59 ASON routing, and an evaluation of existing GMPLS routing protocols 60 are provided in other documents. This document defines extensions to 61 the OSPFv2 Link State Routing Protocol to meet the requirements for 62 routing in an ASON. 64 Note that this work is scoped to the requirements and evaluation 65 expressed in RFC 4258 and RFC 4652 and the ITU-T Recommendations 66 current when those documents were written. Future extensions of 67 revisions of this work may be necessary if the ITU-T Recommendations 68 are revised or if new requirements are introduced into a revision of 69 RFC 4258. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 1.1. Conventions Used in This Document . . . . . . . . . . . . 5 75 2. Routing Areas, OSPF Areas, and Protocol Instances . . . . . . . 5 76 3. Terminology and Identification . . . . . . . . . . . . . . . . 6 77 4. Reachability . . . . . . . . . . . . . . . . . . . . . . . . . 6 78 5. Link Attribute . . . . . . . . . . . . . . . . . . . . . . . . 7 79 5.1. Local Adaptation . . . . . . . . . . . . . . . . . . . . . 7 80 5.2. Bandwidth Accounting . . . . . . . . . . . . . . . . . . . 8 81 6. Routing Information Scope . . . . . . . . . . . . . . . . . . . 8 82 6.1. Link Advertisement (Local and Remote TE Router ID 83 Sub-TLV) . . . . . . . . . . . . . . . . . . . . . . . . . 9 84 6.2. Reachability Advertisement (Local TE Router ID sub-TLV) 10 85 7. Routing Information Dissemination . . . . . . . . . . . . . . 11 86 7.1 Import/Export Rules . . . . . . . . . . . . . . . . . . . 11 87 7.2 Loop Prevention . . . . . . . . . . . . . . . . . . . . . 11 88 7.2.1 Inter-RA Export Upward/Downward Sub-TLVs . . . . . . 12 89 7.2.2 Inter-RA Export Upward/Downward Sub-TLV Processing . 13 90 8. OSPFv2 Scalability . . . . . . . . . . . . . . . . . . . . . 13 91 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 92 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14 93 10.1. Sub-TLVs of the Link TLV . . . . . . . . . . . . . . . 14 94 10.2. Sub-TLVs of the Node Attribute TLV . . . . . . . . . . 15 95 10.3. Sub-TLVs of the Router Address TLV . . . . . . . . . . 15 96 11. Management Considerations . . . . . . . . . . . . . . . . . 16 97 11.1. Routing Area (RA) Isolation . . . . . . . . . . . . . . 16 98 11.2 Routing Area (RA) Topology/Configuration Changes . . . . 16 99 12. Comparison to Requirements in RFC 4258 . . . . . . . . . . . 16 100 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 101 13.1. Normative References . . . . . . . . . . . . . . . . . 22 102 13.2. Informative References . . . . . . . . . . . . . . . . 23 103 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 104 Appendix A. ASON Terminology . . . . . . . . . . . . . . . . . . 25 105 Appendix B. ASON Routing Terminology . . . . . . . . . . . . . . 26 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 108 1. Introduction 110 The Generalized Multiprotocol Label Switching (GMPLS) [RFC3945] 111 protocol suite is designed to provide a control plane for a range of 112 network technologies including optical networks such as time division 113 multiplexing (TDM) networks including SONET/SDH and Optical Transport 114 Networks (OTNs), and lambda switching optical networks. 116 The ITU-T defines the architecture of the Automatically Switched 117 Optical Network (ASON) in [G.8080]. 119 [RFC4258] describes the routing requirements for the GMPLS suite of 120 routing protocols to support the capabilities and functionality of 121 ASON control planes identified in [G.7715] and in [G.7715.1]. 123 [RFC4652] evaluates the IETF Link State routing protocols against the 124 requirements identified in [RFC4258]. Section 7.1 of [RFC4652] 125 summarizes the capabilities to be provided by OSPFv2 [RFC2328] in 126 support of ASON routing. This document describes the OSPFv2 127 specifics for ASON routing. 129 Multi-layer transport networks are constructed from multiple networks 130 of different technologies operating in a client-server relationship. 131 The ASON routing model includes the definition of routing levels that 132 provide scaling and confidentiality benefits. In multi-level 133 routing, domains called routing areas (RAs) are arranged in a 134 hierarchical relationship. Note that as described in [RFC4652], 135 there is no implied relationship between multi-layer transport 136 networks and multi-level routing. The multi-level routing mechanisms 137 described in this document work for both single-layer and multi-layer 138 networks. 140 Implementations may support a hierarchical routing topology (multi- 141 level) for multiple transport network layers and/or a hierarchical 142 routing topology for a single transport network layer. 144 This document describes the processing of the generic (technology- 145 independent) link attributes that are defined in [RFC3630], 146 [RFC4202], and [RFC4203] and that are extended in this document. As 147 described in Section 5.2, technology-specific traffic engineering 148 attributes and their processing may be defined in other documents 149 that complement this document. 151 Note that this work is scoped to the requirements and evaluation 152 expressed in [RFC4258] and [RFC4652] and the ITU-T Recommendations 153 current when those documents were written. Future extensions of 154 revisions of this work may be necessary if the ITU-T Recommendations 155 are revised or if new requirements are introduced into a revision of 157 [RFC4258]. 159 1.1. Conventions Used in This Document 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 163 document are to be interpreted as described in RFC 2119 [RFC2119]. 165 The reader is assumed to be familiar with the terminology and 166 requirements developed in [RFC4258] and the evaluation outcomes 167 described in [RFC4652]. 169 General ASON terminology is provided in Appendix A. ASON routing 170 terminology is described in Appendix B. 172 2. Routing Areas, OSPF Areas, and Protocol Instances 174 An ASON routing area (RA) represents a partition of the data plane, 175 and its identifier is used within the control plane as the 176 representation of this partition. 178 RAs are hierarchically contained: a higher-level (parent) RA contains 179 lower-level (child) RAs that in turn MAY also contain RAs, etc. 180 Thus, RAs contain RAs that recursively define successive hierarchical 181 RA levels. Routing information may be exchanged between levels of 182 the RA hierarchy, i.e., Level N+1 and N, where Level N represents the 183 RAs contained by Level N+1. The links connecting RAs may be viewed 184 as external links (inter-RA links), and the links representing 185 connectivity within an RA may be viewed as internal links (intra-RA 186 links). The external links to an RA at one level of the hierarchy 187 may be internal links in the parent RA. Intra-RA links of a child RA 188 MAY be hidden from the parent RA's view. [RFC4258] 190 An ASON RA can be mapped to an OSPF area, but the hierarchy of ASON 191 RA levels does not map to the hierarchy of OSPF areas. Instead, 192 successive hierarchical levels of RAs MUST be represented by separate 193 instances of the protocol. Thus, inter-level routing information 194 exchange (as described in Section 7) involves the export and import 195 of routing information between protocol instances. 197 An ASON RA may therefore be identified by the combination of its OSPF 198 instance identifier and its OSPF area identifier. With proper and 199 careful network-wide configuration, this can be achieved using just 200 the OSPF area identifier, and this process is RECOMMENDED in this 201 document. These concepts are discussed in Section 7. 203 A key ASON requirement is the support of multiple transport planes or 204 layers. Each transport node has associated topology (links and 205 reachability) which is used for ASON routing. 207 3. Terminology and Identification 209 This section describes the mapping of key ASON entities to OSPF 210 entities. Appendix A contains a complete glossary of ASON routing 211 terminology. 213 There are three categories of identifiers used for ASON routing 214 (G7715.1): transport plane names, control plane identifiers for 215 components, and SCN addresses. This section discusses the mapping 216 between ASON routing identifiers and corresponding identifiers 217 defined for GMPLS routing, and how these support the physical (or 218 logical) separation of transport plane entities and control plane 219 components. GMPLS supports this separation of identifiers and 220 planes. 222 In the context of OSPF Traffic Engineering (TE), an ASON transport 223 node corresponds to a unique OSPF TE node. An OSPF TE node is 224 uniquely identified by the TE Router Address TLV [RFC3630]. In this 225 document, this TE Router Address is referred to as the TE Router ID, 226 which is in the ASON transport plane name space. The TE Router ID 227 should not be confused with the OSPF Router ID which uniquely 228 identifies an OSPF router within an OSPF routing domain [RFC2328] and 229 is in a name space for control plane components. 231 Note: The Router Address top-level TLV definition, processing, and 232 usage are unchanged from [RFC3630]. This TLV specifies a stable OSPF 233 TE node IP address, i.e., the IP address is always reachable when 234 there is IP connectivity to the associated OSPF TE node. 236 ASON defines a Routing Controller (RC) as an entity that handles 237 (abstract) information needed for routing and the routing information 238 exchange with peering RCs by operating on the Routing Database (RDB). 239 ASON defines a Protocol Controller (PC) as an entity that handles 240 protocol-specific message exchanges according to the reference point 241 over which the information is exchanged (e.g., E-NNI, I-NNI), and 242 internal exchanges with the Routing Controller (RC) [RFC4258]. In 243 this document, an OSPF router advertising ASON TE topology 244 information will perform both the functions of the RC and PC. Each 245 OSPF router is uniquely identified by its OSPF Router ID [RFC2328]. 247 4. Reachability 249 Reachability in ASON refers to the set of endpoints reachable in the 250 transport plane by a node or the reachable endpoints of a level N. 251 Reachable entities are identified in the transport plane name space 252 (ASON SNPP name space). In order to advertise blocks of reachable 253 address prefixes, a summarization mechanism is introduced that is 254 based on the techniques described in [RFC5786]. For ASON reachability 255 advertisement, blocks of reachable address prefixes are advertised 256 together with the associated data plane node. The data plane node is 257 identified in the control plane by its TE Router ID, as discussed in 258 section 6. 260 In order to support ASON reachability advertisement, the Node 261 Attribute TLV defined in [RFC5786] is used to advertise the 262 combination of a TE Router ID and its set of associated reachable 263 address prefixes. The Node Attribute TLV can contain the following 264 sub-TLVs: 266 - TE Router ID sub-TLV: Length: 4; Defined in Section 6.2 267 - Node IPv4 Local Address sub-TLV: Length: variable; [RFC5786] 268 - Node IPv6 Local Address sub-TLV: Length: variable; [RFC5786] 270 A router may support multiple transport nodes as discussed in section 271 6, and, as a result, may be required to advertise reachability (ASON 272 TRIs) separately for each transport node. As a consequence, it MUST 273 be possible for the router to originate more than one TE LSA 274 containing the Node Attribute TLV when used for ASON reachability 275 advertisement. 277 Hence, the Node Attribute TLV [RFC5786] advertisement rules must be 278 relaxed for ASON. A Node Attribute TLV MAY appear in more than one TE 279 LSA originated by the RC when the RC is advertising reachability 280 information for a different transport node identified by the Local TE 281 Router Sub-TLV (refer to section 6.1). 283 5. Link Attribute 285 With the exception of local adaptation (described below), the mapping 286 of link attributes and characteristics to OSPF TE Link TLV Sub-TLVs 287 is unchanged [RFC4652]. OSPF TE Link TLV Sub-TLVs are described in 288 [RFC3630] and [RFC4203]. Advertisement of this information SHOULD be 289 supported on a per-layer basis, i.e., one TE LSA per unique switching 290 capability and bandwidth granularity combination. 292 5.1. Local Adaptation 294 Local adaptation is defined as a TE link attribute (i.e., sub-TLV) 295 that describes the cross/inter-layer relationships. 297 The Interface Switching Capability Descriptor (ISCD) TE Attribute 298 [RFC4202] identifies the ability of the TE link to support cross- 299 connection to another link within the same layer. When advertising 300 link adaptation, it also identifies the ability to use a locally 301 terminated connection that belongs to one layer as a data link for 302 another layer (adaptation capability). However, the information 303 associated with the ability to terminate connections within that 304 layer (referred to as the termination capability) is advertised with 305 the adaptation capability. 307 For instance, a link between two optical cross-connects will contain 308 at least one ISCD attribute describing the Lambda Switching Capable 309 (LSC) switching capability. Conversely, a link between an optical 310 cross-connect and an IP/MPLS Label Switching Router (LSR) will 311 contain at least two ISCD attributes, one for the description of the 312 LSC termination capability and one for the Packet Switching Capable 313 (PSC) adaptation capability. 315 In OSPFv2, the Interface Switching Capability Descriptor (ISCD) is a 316 sub-TLV (type 15) of the top-level Link TLV (type 2) [RFC4203]. The 317 adaptation and termination capabilities are advertised using two 318 separate ISCD sub-TLVs within the same top-level Link TLV. 320 An interface MAY have more than one ISCD sub-TLV, [RFC4202] and 321 [RFC4203]. Hence, the corresponding advertisements should not result 322 in any compatibility issues. 324 5.2. Bandwidth Accounting 326 GMPLS routing defines an Interface Switching Capability Descriptor 327 (ISCD) that provides, among other things, the available 328 (maximum/minimum) bandwidth per priority available for Label Switched 329 Path (LSPs). One or more ISCD sub-TLVs can be associated with an 330 interface, [RFC4202] and [RFC4203]. This information, combined with 331 the Unreserved Bandwidth Link TLV sub-TLV [RFC3630], provides the 332 basis for bandwidth accounting. 334 In the ASON context, additional information may be included when the 335 representation and information in the other advertised fields are not 336 sufficient for a specific technology, e.g., SDH. The definition of 337 technology-specific information elements is beyond the scope of this 338 document. Some technologies will not require additional information 339 beyond what is already defined in [RFC3630], [RFC4202], and 340 [RFC4203]. 342 6. Routing Information Scope 344 For ASON routing, the control plane component routing adjacency 345 topology (i.e., the associated Protocol Controller (PC) connectivity) 346 and the transport topology are NOT assumed to be congruent [RFC4258]. 347 Hence, a single OSPF router (i.e., the PC) MUST be able to advertise 348 on behalf of multiple transport layer nodes. The OSPF routers are 349 identified by OSPF Router ID and the transport nodes are identified 350 by TE Router ID. 352 The Router Address TLV [RFC3630] is used to advertise the TE Router 353 ID associated with the advertising Routing Controller. TE Router IDs 354 for additional transport nodes are advertised through specification 355 of the Local TE Router Identifier in the Local and Remote TE Router 356 TE sub-TLV and the Local TE Router Identifier sub-TLV described in 357 the sections below. These Local TE Router Identifiers are typically 358 used as the local endpoints for TE Label Switched Paths (LSPs) 359 terminating on the associated transport node. 361 It MAY be feasible for multiple OSPF Routers to advertise TE 362 information for the same transport node. However, this is not 363 considered a required use case and is not discussed further. 365 6.1. Link Advertisement (Local and Remote TE Router ID Sub-TLV) 367 An OSPF router advertising on behalf of multiple transport nodes will 368 require additional information to distinguish the link endpoints 369 amongst the subsumed transport nodes. In order to unambiguously 370 specify the transport topology, the local and remote transport nodes 371 MUST be identified by TE router ID. 373 For this purpose, a new sub-TLV of the OSPFv2 TE LSA top-level Link 374 TLV is introduced that defines the Local and Remote TE Router ID. 376 The Type field of the Local and Remote TE Router ID sub-TLV is 377 assigned a value TBD. The Length field takes the value 8. The Value 378 field of this sub-TLV contains 4 octets of the Local TE Router 379 Identifier followed by 4 octets of the Remote TE Router Identifier. 380 The value of the Local and Remote TE Router Identifier SHOULD NOT be 381 set to 0. 383 The format of the Local and Remote TE Router ID sub-TLV is: 385 0 1 2 3 386 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | Type | Length (8) | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Local TE Router Identifier | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | Remote TE Router Identifier | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 This sub-TLV MUST be included as a sub-TLV of the top-level Link TLV 396 if the OSPF router is advertising on behalf of one or more transport 397 nodes having TE Router IDs different from the TE Router ID advertised 398 in the Router Address TLV. Therefore, it MUST be included if the 399 OSPF router is advertising on behalf of multiple transport nodes. 401 Note: The Link ID sub-TLV identifies the other end of the link (i.e., 402 Router ID of the neighbor for point-to-point links) [RFC3630]. When 403 the Local and Remote TE Router ID Sub-TLV is present, it MUST be used 404 to identify local and remote transport node endpoints for the link 405 and the Link-ID sub-TLV MUST be ignored. The Local and Remote ID sub- 406 TLV, if specified, MUST only be specified once. 408 6.2. Reachability Advertisement (Local TE Router ID sub-TLV) 410 When an OSPF router is advertising on behalf of multiple transport 411 nodes, the routing protocol MUST be able to associate the advertised 412 reachability information with the correct transport node. 414 For this purpose, a new sub-TLV of the OSPFv2 TE LSA top-level Node 415 Attribute TLV is introduced. This TLV associates the local prefixes 416 (see above) to a given transport node identified by TE Router ID. 418 The Type field of the Local TE Router ID sub-TLV is assigned a value 419 TBD. The Length field takes the value 4. The Value field of this 420 sub-TLV contains the Local TE Router Identifier [RFC3630] encoded 421 over 4 octets. 423 The format of the Local TE Router ID sub-TLV is: 425 0 1 2 3 426 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | Type | Length (4) | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | Local TE Router Identifier | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 This sub-TLV MUST be included as a sub-TLV of the top-level Node 434 Attribute TLV if the OSPF router is advertising on behalf of one or 435 more transport nodes having TE Router IDs different from the TE 436 Router ID advertised in the Router Address TLV. Therefore, it MUST 437 be included if the OSPF router is advertising on behalf of multiple 438 transport nodes. 440 7. Routing Information Dissemination 442 An ASON routing area (RA) represents a partition of the data plane, 443 and its identifier is used within the control plane as the 444 representation of this partition. An RA may contain smaller RAs 445 inter-connected by links. ASON RA levels do not map directly to OSPF 446 areas. Rather, hierarchical levels of RAs are represented by separate 447 OSPF protocol instances. 449 Routing controllers (RCs) supporting multiple RAs disseminate 450 information downward and upward in this ASON hierarchy. The vertical 451 routing information dissemination mechanisms described in this 452 section do not introduce or imply hierarchical OSPF areas. RCs 453 supporting RAs at multiple levels are structured as separate OSPF 454 instances with routing information exchange between levels described 455 by import and export rules between these instances. The functionality 456 described herein does not pertain to OSPF areas or OSPF Area Border 457 Router (ABR) functionality. 459 7.1 Import/Export Rules 461 RCs supporting RAs disseminate information upward and downward in the 462 hierarchy by importing/exporting routing information as TE LSAs. TE 463 LSAs are area-scoped opaque LSAs with opaque type 1 [RFC3630]. The 464 information that MAY be exchanged between adjacent levels includes 465 the Router Address, Link, and Node Attribute top-level TLVs. 467 The imported/exported routing information content MAY be transformed, 468 e.g., filtered or aggregated, as long as the resulting routing 469 information is consistent. In particular, when more than one RC is 470 bound to adjacent levels and both are allowed to import/export 471 routing information, it is expected that these transformations are 472 performed in a consistent manner. Definition of these policy-based 473 mechanisms is outside the scope of this document. 475 In practice, and in order to avoid scalability and processing 476 overhead, routing information imported/exported downward/upward in 477 the hierarchy is expected to include reachability information (see 478 Section 4) and, upon strict policy control, link topology 479 information. 481 7.2 Loop Prevention 483 When more than one RC is bound to an adjacent level of the ASON 484 hierarchy, and is configured to export routing information upward or 485 downward, a specific mechanism is required to avoid looping of 486 routing information. Looping is the re-advertisement of routing 487 information into an RA that had previously advertised that routing 488 information upward or downward into an upper or lower level RA in the 489 ASON hierarchy. For example, without loop prevention mechanisms, this 490 could happen when the RC advertising routing information downward in 491 the hierarchy is not the same one that advertises routing information 492 upward in the hierarchy. 494 7.2.1 Inter-RA Export Upward/Downward Sub-TLVs 496 The Inter-RA Export Sub-TLVs can be used to prevent the re- 497 advertisement of OSPF TE routing information into an RA which 498 previously advertised that information. The type value TBD will 499 indicate that the associated routing information has been exported 500 downward. The type value TBD will indicate that the associated 501 routing information has been exported upward. While it is not 502 required for routing information exported downward, both Sub-TLVs 503 will include the Routing Area (RA) ID from the which the routing 504 information was exported. This RA is not necessarily the RA 505 originating the routing information but RA from which the information 506 was immediately exported. 508 These additional Sub-TLVs MAY be included in TE LSAs that include any 509 of the following top-level TLVs: 511 - Router Address top-level TLV 512 - Link top-level TLV 513 - Node Attribute top-level TLV 515 The Type field of the Inter-RA Export Upward and Inter-RA Export 516 Downward sub-TLVs are respectively assigned the values TBD1 and TBD2. 517 The Length of the Associated RA ID TLV is 4 octets. The Value field 518 in these sub-TLVs contains the associated RA ID. The RA ID value must 519 be a unique identifier for the RA within the ASON routing domain. 521 The format of the Inter-RA Export Upward and Inter-RA Export Downward 522 Sub-TLVs is graphically depicted below: 524 0 1 2 3 525 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | Upward/Downward Type | Length (4) | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | Associated RA ID | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 7.2.2 Inter-RA Export Upward/Downward Sub-TLV Processing 534 TE LSAs MAY be imported or exported downward or upward in the ASON 535 routing hierarchy. The direction and advertising RA ID are advertised 536 in an Inter-RA Export Upward/Downward Sub-TLV. They MUST be retained 537 and advertised in the receiving RA with the associated routing 538 information. 540 When exporting routing information upward in the ASON routing 541 hierarchy, any information received from a level above, i.e., tagged 542 with an Inter-RA Export Downward Sub-TLV, MUST NOT be exported 543 upward. Since an RA at level N is contained by a single RA at level 544 N+1, this is the only checking that is necessary and the associated 545 RA ID is used solely for informational purposes. 547 When exporting routing information downward in the ASON routing 548 hierarchy, any information received from a level below, i.e., tagged 549 with an Inter-RA Export Upward Sub-TLV MUST NOT be exported downward 550 if the target RA ID matches the RA ID associated with the routing 551 information. This additional checking is required for routing 552 information exported downward since a single RA at level N+1 may 553 contain multiple RAs at level N in the ASON routing hierarchy. In 554 order words, routing information MUST NOT be exported downward into 555 the RA from which it was received. 557 8. OSPFv2 Scalability 559 The extensions described herein are only applicable to ASON routing 560 domains and it is not expected that the attendant reachability (see 561 Section 4) and link information will ever be mixed with global or 562 local IP routing information. If there were ever a requirement for a 563 given RC to participate in both domains, separate OSPFv2 instances 564 would be utilized. However, in a multi-level ASON hierarchy, the 565 potential volume of information could be quite large and the 566 recommendations in this section SHOULD be followed by RCs 567 implementing this specification. 569 - Routing information exchange upward/downward in the hierarchy 570 between adjacent RAs SHOULD, by default, be limited to reachability 571 information. In addition, several transformations such as prefix 572 aggregation are RECOMMENDED to reduce the amount of information 573 imported/exported by a given RC when such transformations will not 574 impact consistency. 576 - Routing information exchange upward/downward in the ASON hierarchy 577 involving TE attributes MUST be under strict policy control. 578 Pacing and min/max thresholds for triggered updates are strongly 579 RECOMMENDED. 581 - The number of routing levels MUST be maintained under strict policy 582 control. 584 9. Security Considerations 586 This document specifies the contents and processing of OSPFv2 TE LSAs 587 [RFC3630] and [RFC4202]. The TE LSA extensions defined in this 588 document are not used for SPF computation, and have no direct effect 589 on IP routing. Additionally, ASON routing domains are delimited by 590 the usual administrative domain boundaries. 592 Any mechanisms used for securing the exchange of normal OSPF LSAs can 593 be applied equally to all TE LSAs used in the ASON context. 594 Authentication of OSPFv2 LSA exchanges (such as OSPF cryptographic 595 authentication [RFC2328] and [RFC5709]) can be used to secure against 596 passive attacks and provide significant protection against active 597 attacks. [RFC5709] defines a mechanism for authenticating OSPFv2 598 packets by making use of the HMAC algorithm in conjunction with the 599 SHA family of cryptographic hash functions. 601 If a stronger authentication were believed to be required, then the 602 use of a full digital signature [RFC2154] would be an approach that 603 should be seriously considered. Use of full digital signatures would 604 enable precise authentication of the OSPF router originating each 605 OSPF link-state advertisement, and thereby provide much stronger 606 integrity protection for the OSPF routing domain. 608 10. IANA Considerations 610 This document is classified as Standards Track. It defines new sub- 611 TLVs for inclusion in OSPF TE LSAs. According to the assignment 612 policies for the registries of code points for these sub-TLVs, values 613 must be assigned by IANA [RFC3630]. 615 The following subsections summarize the required sub-TLVs. 617 10.1. Sub-TLVs of the Link TLV 619 This document defines the following sub-TLVs of the Link TLV 620 advertised in the OSPF TE LSA: 622 - Local and Remote TE Router ID sub-TLV 623 - Associated RA ID sub-TLV 624 - Inter-RA Export Upward sub-TLV 625 - Inter-RA Export Downward sub-TLV 627 Codepoints for these Sub-TLVs should be allocated from the "Types for 628 sub-TLVs of TE Link TLV (Value 2)" registry standards action range (0 629 - 32767) [RFC3630]. 631 Note that the same values for the Associated RA ID sub-TLV, Inter-RA 632 Export Upward sub-TLV, and Inter-RA Export Downward Sub-TLV MUST be 633 used when they appear in the Link TLV, Node Attribute TLV, and Router 634 Address TLV. 636 10.2. Sub-TLVs of the Node Attribute TLV 638 This document defines the following sub-TLVs of the Node Attribute 639 TLV advertised in the OSPF TE LSA: 641 - Local TE Router ID sub-TLV 642 - Associated RA ID sub-TLV 643 - Inter-RA Export Upward sub-TLV 644 - Inter-RA Export Downward sub-TLV 646 Codepoints for these Sub-TLVs should be assigned from the "Types for 647 sub-TLVs of TE Node Attribute TLV (Value 5)" registry standards 648 action range (0 - 32767) [RFC5786]. 650 Note that the same values for the Associated RA ID sub-TLV, Inter-RA 651 Export Upward sub-TLV, and Inter-RA Export Downward Sub-TLV MUST be 652 used when they appear in the Link TLV, Node Attribute TLV, and Router 653 Address TLV. 655 10.3. Sub-TLVs of the Router Address TLV 657 The Router Address TLV is advertised in the OSPF TE LSA [RFC3630]. 658 Since this TLV currently has no Sub-TLVs defined, a "Types for sub- 659 TLVs of Router Address TLV (Value 1)" registry must be defined. 661 The registry guidelines for the assignment of types for sub-TLVs of 662 the Router Address TLV are as follows: 664 o Types in the range 0-32767 are to be assigned via Standards 665 Action. 667 o Types in the range 32768-32777 are for experimental use; these 668 will not be registered with IANA, and MUST NOT be mentioned by 669 RFCs. 671 o Types in the range 32778-65535 are not to be assigned at this 672 time. Before any assignments can be made in this range, there 673 MUST be a Standards Track RFC that specifies IANA 674 Considerations that covers the range being assigned. 676 This document defines the following sub-TLVs for inclusion in the 677 Router Address TLV: 679 - Associated RA ID sub-TLV 680 - Inter-RA Export Upward sub-TLV 681 - Inter-RA Export Downward sub-TLV 683 Codepoints for these Sub-TLVs should be allocated from the "Types for 684 sub-TLVs of Router Address TLV (Value 1)" registry standards action 685 range (0 - 32767). 687 Note that the same values for the Associated RA ID sub-TLV, Inter-RA 688 Export Upward sub-TLV, and Inter-RA Export Downward Sub-TLV MUST be 689 used when they appear in the Link TLV, Node Attribute TLV, and Router 690 Address TLV. 692 11. Management Considerations 694 11.1. Routing Area (RA) Isolation 696 If the RA Identifier is mapped to the OSPF Area ID as recommended in 697 section 2.0, OSPF [RFC2328] implicitly provides isolation. On any 698 intra-RA link, packets will only be accepted if the area-id in the 699 OSPF packet header matches the area ID for the OSPF interface on 700 which the packet was received. Hence, RCs will only establish 701 adjacencies and exchange reachability information (see Section 4.0) 702 with RCs in the same RC. Other mechanisms for RA isolation are 703 beyond the scope of this document. 705 11.2 Routing Area (RA) Topology/Configuration Changes 707 The GMPLS Routing for ASON requirements [RFC4258] dictate that the 708 routing protocol MUST support reconfiguration and SHOULD support 709 architectural evolution. OSPF [RFC2328] includes support for the 710 dynamic introduction or removal of ASON reachability information 711 through the flooding and purging of OSPF opaque LSAs [RFC5250]. Also, 712 when an RA is partitioned or an RC fails, stale LSAs SHOULD NOT be 713 used unless the advertising RC is reachable. The configuration of 714 OSPF RAs and the policies governing the redistribution of ASON 715 reachability information between RAs are implementation issues 716 outside of the OSPF routing protocol and beyond the scope of this 717 document. 719 12. Comparison to Requirements in RFC 4258 721 The following table shows how this draft complies with the 722 requirements in [RFC4258]. The first column contains a requirements 723 number (1-30) and the relevant section in RFC 4258. The second column 724 describes the requirement, the third column discusses the compliance 725 to that requirement, and the fourth column lists the relevant section 726 in draft, and/or another RFC that already satisfies the requirement. 728 +----------+---------------------------+---------------+-------------+ 729 | RFC 4258 | RFC 4258 Requirement | Compliance | Reference | 730 | Section | | | | 731 | (Req. | | | | 732 | Number) | | | | 733 +----------+---------------------------+---------------+-------------+ 734 | 3.0 (1) | The failure of an RC, or | Implied by | Not an | 735 | | the failure of | separation of |attribute of | 736 | |communications between RCs,| transport and | routing | 737 | |and the subsequent recovery|control plane. | protocol. | 738 | |from the failure condition | | | 739 | | MUST NOT disrupt call in | | | 740 | | progress. | | | 741 +----------+---------------------------+---------------+-------------+ 742 | 3.1 (2) |Multiple Hierarchical Level| Yes | Sections 2 | 743 | | of ASON Routing Areas | | and 3 | 744 | | (RAs). | | | 745 +----------+---------------------------+---------------+-------------+ 746 | 3.1 (3) | Prior to establishing | Yes when RA |Section 11.1 | 747 | | communications, RCs MUST | maps to OSPF | | 748 | |verify that they are bound | Area ID. | | 749 | | to the same parent RA. | | | 750 +----------+---------------------------+---------------+-------------+ 751 | 3.1 (4) | The RC ID MUST be unique | Yes |RFC 2328 and | 752 | | within its containing RA. | | Section 3. | 753 +----------+---------------------------+---------------+-------------+ 754 | 3.1 (5) |Each RA within a carrier's |Yes - although | Sections 2, | 755 | | network SHALL be uniquely | uniqueness is | 3, and 11.1 | 756 | |identifiable. RA IDs MAY be|the operator's | | 757 | |associated with a transport|responsibility.| | 758 | | plane name space, whereas | | | 759 | |RC IDs are associated with | | | 760 | |a control plane name space.| | | 761 +----------+---------------------------+---------------+-------------+ 762 | 3.2 (6) | Hierarchical Routing | Yes | Section 7 | 763 | | Information Dissemination | | | 764 +----------+---------------------------+---------------+-------------+ 765 | 3.2 (7) | Routing Information | Yes | Section 7.1 | 766 | |exchanged between levels N | | | 767 | | and N+1 via separate | | | 768 | | instances and | | | 769 | | import/export. | | | 770 +----------+---------------------------+---------------+-------------+ 771 +----------+---------------------------+---------------+-------------+ 772 | 3.2 (8) | Routing Information | No - Not | | 773 | |exchanged between levels N | described. | | 774 | | and N+1 via external link | | | 775 | | (inter-RA links). | | | 776 +----------+---------------------------+---------------+-------------+ 777 | 3.2 (9) | Routing information | Yes | Sections 4, | 778 | | exchange MUST include | |6, 6.1, 6.2, | 779 | | reachability information | | and 8 | 780 | | and MAY include, upon | | | 781 | | policy decision, node and | | | 782 | | link topology. | | | 783 +----------+---------------------------+---------------+-------------+ 784 | 3.2 (10) | There SHOULD NOT be any |Yes - separate | Sections 2 | 785 | | dependencies on the | instances. | and 3 | 786 | |different routing protocols| | | 787 | | used within an RA or in | | | 788 | | different RAs. | | | 789 +----------+---------------------------+---------------+-------------+ 790 | 3.2 (11) |The routing protocol SHALL | Yes | Section 7.2 | 791 | | differentiate the routing | | | 792 | |information originated at a| | | 793 | |given-level RA from derived| | | 794 | | routing information | | | 795 | | (received from external | | | 796 | | RAs), even when this | | | 797 | |information is forwarded by| | | 798 | | another RC at the same | | | 799 | | level. | | | 800 +----------+---------------------------+---------------+-------------+ 801 | 3.2 (12) | The routing protocol MUST | Yes | Section 7.2 | 802 | | provide a mechanism to | | | 803 | | prevent information | | | 804 | |propagated from a Level N+1| | | 805 | | RA's RC into the Level N | | | 806 | | RA's RC from being | | | 807 | | re-introduced into the | | | 808 | | Level N+1 RA's RC. | | | 809 +----------+---------------------------+---------------+-------------+ 810 | 3.2 (13) | The routing protocol MUST | Yes | Section 7.2 | 811 | | provide a mechanism to | | | 812 | | prevent information | | | 813 | |propagated from a Level N-1| | | 814 | | RA's RC into the Level N | | | 815 | | RA's RC from being | | | 816 | | re-introduced into the | | | 817 | | Level N-1 RA's RC. | | | 818 +----------+---------------------------+---------------+-------------+ 819 +----------+---------------------------+---------------+-------------+ 820 | 3.2 (14) | Instance of a Level N | Yes | Sections 2, | 821 | | routing function and an | | 3, and 7 | 822 | | instance of a Level N+1 | | | 823 | | routing function in the | | | 824 | | same system. | | | 825 +----------+---------------------------+---------------+-------------+ 826 | 3.2 (15) | The Level N routing | Not described | N/A | 827 | | function is on a separate | but possible. | | 828 | | system the Level N+1 | | | 829 | | routing function. | | | 830 +----------+---------------------------+---------------+-------------+ 831 | 3.3 (16) |The RC MUST support static | Yes - | Sections 2 | 832 | | (i.e., operator assisted) | automation |and 3. Config| 833 | | and MAY support automated |requirement is | is product | 834 | | configuration of the | ambiguous. | specific. | 835 | |information describing its | | | 836 | |relationship to its parent | | | 837 | | and its child within the | | | 838 | | hierarchical structure | | | 839 | | (including RA ID and RC | | | 840 | | ID). | | | 841 +----------+---------------------------+---------------+-------------+ 842 | 3.3 (17) |The RC MUST support static |Yes - when OSPF|RFC 2328 and | 843 | | (i.e., operator assisted) |area maps to RA|Section 11.1 | 844 | | and MAY support automated | discovery is | | 845 | | configuration of the | automatic. | | 846 | |information describing its | | | 847 | | associated adjacencies to | | | 848 | | other RCs within an RA. | | | 849 +----------+---------------------------+---------------+-------------+ 850 | 3.3 (18) |The routing protocol SHOULD| Yes | RFC 2328 | 851 | |support all the types of RC| | | 852 | | adjacencies described in | | | 853 | |Section 9 of [G.7715]. The | | | 854 | | latter includes congruent | | | 855 | |topology (with distributed | | | 856 | | RC) and hubbed topology | | | 857 | |(e.g., note that the latter| | | 858 | | does not automatically | | | 859 | | imply a designated RC). | | | 860 +----------+---------------------------+---------------+-------------+ 861 +----------+---------------------------+---------------+-------------+ 862 | 3.4 (19) |The routing protocol SHOULD| Yes |RFC 2328, RFC| 863 | | be capable of supporting | | 5250, and | 864 | |architectural evolution in | |Section 11.2.| 865 | | terms of the number of | | | 866 | |hierarchical levels of RAs,| | | 867 | |as well as the aggregation | | | 868 | | and segmentation of RAs. | | | 869 +----------+---------------------------+---------------+-------------+ 870 |3.5.2 (20)|Advertisements MAY contain | | | 871 | |the following common set of| | | 872 | | information regardless of | | | 873 | | whether they are link or | | | 874 | | node related: | | | 875 | | - RA ID of the RA to | Yes |Section 7.2.1| 876 | |which the advertisement is | | | 877 | | bounded | | | 878 | | - RC ID of the entity | Yes | RFC 2328 | 879 | | generating the | | | 880 | | advertisement | | | 881 | | - Information to | Yes |RFC 2328, RFC| 882 | | uniquely identify | | 5250 | 883 | | advertisements | | | 884 | | - Information to | No - Must | | 885 | | determine whether an |compare to old | | 886 | | advertisement has been | | | 887 | | updated | | | 888 | | - Information to | Yes |Section 7.2.1| 889 | | indicate when an | | | 890 | | advertisement has been | | | 891 | | derived from a different | | | 892 | | level RA | | | 893 +----------+---------------------------+---------------+-------------+ 894 |3.5.3 (21)|The Node Attributes Node ID|Yes - Prefixes | RFC 5786, | 895 | | and Reachability must be | only for |Section 4 and| 896 | | advertised. It MAY be | reachability | 6 | 897 | | advertised as a set of | | | 898 | |associated external (e.g., | | | 899 | | User Network Interface | | | 900 | | (UNI)) address/address | | | 901 | | prefixes or a set of | | | 902 | | associated SNPP link | | | 903 | | IDs/SNPP ID prefixes, the | | | 904 | |selection of which MUST be | | | 905 | | consistent within the | | | 906 | | applicable scope. | | | 907 +----------+---------------------------+---------------+-------------+ 908 +----------+---------------------------+---------------+-------------+ 909 |3.5.4 (22)| The Link Attributes Local | Yes | Section 6.1 | 910 | | SNPP link ID, Remote SNPP | | | 911 | |link ID, and layer specific| | | 912 | | characteristics must be | | | 913 | | advertised. | | | 914 +----------+---------------------------+---------------+-------------+ 915 |3.5.4 (23)| Link Signaling Attributes | Yes | Section 5, | 916 | |other than Local Adaptation| | RFC 4652 - | 917 | |(Signal Type, Link Weight, | |Section 5.3.1| 918 | | Resource Class, Local | | | 919 | | Connection Types, Link | | | 920 | | Capacity, Link | | | 921 | | Availability, Diversity | | | 922 | | Support) | | | 923 +----------+---------------------------+---------------+-------------+ 924 |3.5.4 (24)| Link Signaling Local | Yes | Section 5.1 | 925 | | Adaptation | | | 926 +----------+---------------------------+---------------+-------------+ 927 | 5 (25) | The routing adjacency | Yes |Section 2, 3,| 928 | | topology (i.e., the | | and 6 | 929 | |associated PC connectivity | | | 930 | |topology) and the transport| | | 931 | |network topology SHALL NOT | | | 932 | |be assumed to be congruent.| | | 933 +----------+---------------------------+---------------+-------------+ 934 | 5 (26) |The routing topology SHALL | Yes |RFC 2328, RFC| 935 | | support multiple links | | 3630 | 936 | | between nodes and RAs. | | | 937 +----------+---------------------------+---------------+-------------+ 938 | 5 (27) |The routing protocol SHALL | Yes |RFC 2328, RFC| 939 | | converge such that the | | 5250 | 940 | | distributed RDBs become | | | 941 | |synchronized after a period| | | 942 | | of time. | | | 943 +----------+---------------------------+---------------+-------------+ 944 | 5 (28) |Self-consistent information|Yes - However, | Section 7.1 | 945 | | at the receiving level | this is not a | | 946 | | resulting from any | routing | | 947 | | transformation (filter, | protocol | | 948 | | summarize, etc.) and | function. | | 949 | | forwarding of information | | | 950 | | from one RC to RC(s) at | | | 951 | | different levels when | | | 952 | |multiple RCs are bound to a| | | 953 | | single RA. | | | 954 +----------+---------------------------+---------------+-------------+ 955 +----------+---------------------------+---------------+-------------+ 956 | 5 (29) | In order to support |Partial - OSPF |RFC 2328 and | 957 | | operator-assisted changes | supports the | RFC 5250 | 958 | | in the containment | purging of | | 959 | | relationships of RAs, the | stale | | 960 | | routing protocol SHALL |advertisements | | 961 | |support evolution in terms |and origination| | 962 | | of the number of | of new. The | | 963 | |hierarchical levels of RAs.|non-disruptive | | 964 | | For example: support of | behavior is | | 965 | | non-disruptive operations |implementation | | 966 | |such as adding and removing| specific. | | 967 | | RAs at the top/bottom of | | | 968 | | the hierarchy, adding or | | | 969 | | removing a hierarchical | | | 970 | |level of RAs in or from the| | | 971 | |middle of the hierarchy, as| | | 972 | | well as aggregation and | | | 973 | | segmentation of RAs. | | | 974 +----------+---------------------------+---------------+-------------+ 975 | 5 (30) | A collection of links and |Yes - Within an| Sections 4 | 976 | |nodes such as a subnetwork | RA it must be | and 6 | 977 | | or RA MUST be able to | consistent. | | 978 | | represent itself to the | | | 979 | | wider network as a single | | | 980 | | logical entity with only | | | 981 | |its external links visible | | | 982 | | to the topology database. | | | 983 +----------+---------------------------+---------------+-------------+ 985 13. References 987 13.1. Normative References 989 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 990 Requirement Levels", BCP 14, RFC 2119, March 1997. 992 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 994 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic 995 Engineering (TE) Extensions to OSPF Version 2", RFC 996 3630, September 2003. 998 [RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label 999 Switching (GMPLS) Architecture", RFC 3945, October 2004. 1001 [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing 1002 Extensions in Support of Generalized Multi-Protocol 1003 Label Switching (GMPLS)", RFC 4202, October 2005. 1005 [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions 1006 in Support of Generalized Multi-Protocol Label Switching 1007 (GMPLS)", RFC 4203, October 2005. 1009 [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 1010 OSPF Opaque LSA Option", RFC 5250, July 2008. 1012 [RFC5786] Aggarwal, R. and K. Kompella, "Advertising a Router's 1013 Local Addresses in OSPF TE Extensions", RFC 5786, March 1014 2010. 1016 13.2. Informative References 1018 [RFC2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with 1019 Digital Signatures", RFC 2154, June 1997. 1021 [RFC4258] Brungard, D., Ed., "Requirements for Generalized Multi- 1022 Protocol Label Switching (GMPLS) Routing for the 1023 Automatically Switched Optical Network (ASON)", RFC 1024 4258, November 2005. 1026 [RFC4652] Papadimitriou, D., Ed., Ong, L., Sadler, J., Shew, S., 1027 and D. Ward, "Evaluation of Existing Routing Protocols 1028 against Automatic Switched Optical Network (ASON) 1029 Routing Requirements", RFC 4652, October 2006. 1031 [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, 1032 M., Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA 1033 Cryptographic Authentication", RFC 5709, October 2009. 1035 For information on the availability of ITU Documents, please see 1036 http://www.itu.int. 1038 [G.7715] ITU-T Rec. G.7715/Y.1306, "Architecture and Requirements 1039 for the Automatically Switched Optical Network (ASON)", 1040 June 2002. 1042 [G.7715.1] ITU-T Draft Rec. G.7715.1/Y.1706.1, "ASON Routing 1043 Architecture and Requirements for Link State Protocols", 1044 November 2003. 1046 [G.805] ITU-T Rec. G.805, "Generic functional architecture of 1047 transport networks)", March 2000. 1049 [G.8080] ITU-T Rec. G.8080/Y.1304, "Architecture for the 1050 Automatically Switched Optical Network (ASON)," 2006 1051 (and Amendments 1 and 2). 1053 14. Acknowledgements 1055 The editors would like to thank Dimitri Papadimitriou for editing RFC 1056 5787, from which this document is derived, and Lyndon Ong, Remi 1057 Theillaud, Stephen Shew, Jonathan Sadler, Deborah Brungard, and Lou 1058 Berger for their useful comments and suggestions. 1060 Appendix A. ASON Terminology 1062 This document makes use of the following terms: 1064 Administrative domain: (See Recommendation [G.805].) For the 1065 purposes of [G7715.1], an administrative domain represents the 1066 extent of resources that belong to a single player such as a 1067 network operator, a service provider, or an end-user. 1068 Administrative domains of different players do not overlap amongst 1069 themselves. 1071 Control plane: performs the call control and connection control 1072 functions. Through signaling, the control plane sets up and 1073 releases connections, and may restore a connection in case of a 1074 failure. 1076 (Control) Domain: represents a collection of (control) entities that 1077 are grouped for a particular purpose. The control plane is 1078 subdivided into domains matching administrative domains. Within 1079 an administrative domain, further subdivisions of the control 1080 plane are recursively applied. A routing control domain is an 1081 abstract entity that hides the details of the RC distribution. 1083 External NNI (E-NNI): interfaces located between protocol controllers 1084 between control domains. 1086 Internal NNI (I-NNI): interfaces located between protocol controllers 1087 within control domains. 1089 Link: (See Recommendation G.805.) A "topological component" that 1090 describes a fixed relationship between a "subnetwork" or "access 1091 group" and another "subnetwork" or "access group". Links are not 1092 limited to being provided by a single server trail. 1094 Management plane: performs management functions for the transport 1095 plane, the control plane, and the system as a whole. It also 1096 provides coordination between all the planes. The following 1097 management functional areas are performed in the management plane: 1098 performance, fault, configuration, accounting, and security 1099 management. 1101 Management domain: (See Recommendation G.805.) A management domain 1102 defines a collection of managed objects that are grouped to meet 1103 organizational requirements according to geography, technology, 1104 policy, or other structure, and for a number of functional areas 1105 such as configuration, security, (FCAPS), for the purpose of 1106 providing control in a consistent manner. Management domains can 1107 be disjoint, contained, or overlapping. As such, the resources 1108 within an administrative domain can be distributed into several 1109 possible overlapping management domains. The same resource can 1110 therefore 1111 belong to several management domains simultaneously, but a 1112 management domain shall not cross the border of an administrative 1113 domain. 1115 Subnetwork Point (SNP): The SNP is a control plane abstraction that 1116 represents an actual or potential transport plane resource. SNPs 1117 (in different subnetwork partitions) may represent the same 1118 transport resource. A one-to-one correspondence should not be 1119 assumed. 1121 Subnetwork Point Pool (SNPP): A set of SNPs that are grouped together 1122 for the purposes of routing. 1124 Termination Connection Point (TCP): A TCP represents the output of a 1125 Trail Termination function or the input to a Trail Termination 1126 Sink function. 1128 Transport plane: provides bidirectional or unidirectional transfer of 1129 user information, from one location to another. It can also 1130 provide transfer of some control and network management 1131 information. The transport plane is layered; it is equivalent to 1132 the Transport Network defined in Recommendation G.805. 1134 User Network Interface (UNI): interfaces are located between protocol 1135 controllers between a user and a control domain. Note: There is 1136 no routing function associated with a UNI reference point. 1138 Appendix B. ASON Routing Terminology 1140 This document makes use of the following terms: 1142 Routing Area (RA): an RA represents a partition of the data plane, 1143 and its identifier is used within the control plane as the 1144 representation of this partition. Per [G.8080], an RA is defined 1145 by a set of sub-networks, the links that interconnect them, and 1146 the interfaces representing the ends of the links exiting that RA. 1147 An RA may contain smaller RAs inter-connected by links. The 1148 limit of subdivision results in an RA that contains two sub- 1149 networks interconnected by a single link. 1151 Routing Database (RDB): a repository for the local topology, network 1152 topology, reachability, and other routing information that is 1153 updated as part of the routing information exchange and may 1154 additionally contain information that is configured. The RDB may 1155 contain routing information for more than one routing area (RA). 1157 Routing Components: ASON routing architecture functions. These 1158 functions can be classified as protocol independent (Link Resource 1159 Manager or LRM, Routing Controller or RC) or protocol specific 1160 (Protocol Controller or PC). 1162 Routing Controller (RC): handles (abstract) information needed for 1163 routing and the routing information exchange with peering RCs by 1164 operating on the RDB. The RC has access to a view of the RDB. 1165 The RC is protocol independent. 1167 Note: Since the RDB may contain routing information pertaining to 1168 multiple RAs (and possibly to multiple layer networks), the RCs 1169 accessing the RDB may share the routing information. 1171 Link Resource Manager (LRM): supplies all the relevant component and 1172 TE link information to the RC. It informs the RC about any state 1173 changes of the link resources it controls. 1175 Protocol Controller (PC): handles protocol-specific message exchanges 1176 according to the reference point over which the information is 1177 exchanged (e.g., E-NNI, I-NNI), and internal exchanges with the 1178 RC. The PC function is protocol dependent. 1180 Authors' Addresses 1182 Andrew G. Malis 1183 Verizon Communications 1184 117 West St. 1185 Waltham MA 02451 USA 1187 EMail: andrew.g.malis@verizon.com 1189 Acee Lindem 1190 Ericsson 1191 102 Carric Bend Court 1192 Cary, NC 27519 1194 EMail: acee.lindem@ericsson.com