idnits 2.17.1 draft-ietf-ccamp-gmpls-ason-routing-ospf-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 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 (August 16, 2009) is 5338 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4970 (Obsoleted by RFC 7770) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Dimitri Papadimitriou 2 Internet Draft (Alcatel-Lucent) 3 Category: Experimental 4 Created: August 16, 2009 5 Expires: February 16, 2010 7 OSPFv2 Routing Protocols Extensions for ASON Routing 9 draft-ietf-ccamp-gmpls-ason-routing-ospf-09.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 Internet- 19 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/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 The ITU-T has defined an architecture and requirements for operating 35 an Automatically Switched Optical Network (ASON). 37 The Generalized Multiprotocol Label Switching (GMPLS) protocol suite 38 is designed to provide a control plane for a range of network 39 technologies including optical networks such as time division 40 multiplexing (TDM) networks including SONET/SDH and Optical Transport 41 Networks (OTNs), and lambda switching optical networks. 43 The requirements for GMPLS routing to satisfy the requirements of 44 ASON routing, and an evaluation of existing GMPLS routing protocols 45 are provided in other documents. This document defines extensions to 46 the OSPFv2 Link State Routing Protocol to meet the requirements for 47 routing in an ASON. 49 Note that this work is scoped to the requirements and evaluation 50 expressed in RFC 4258 and RFC 4652 and the ITU-T Recommendations 51 current when those documents were written. Future extensions of 52 revisions of this work may be necessary if the ITU-T Recommendations 53 are revised or if new requirements are introduced into a revision of 54 RFC 4258. 56 Table of Contents 58 1. Introduction................................................. 3 59 1.1. Conventions Used In This Document.......................... 4 60 2. Routing Areas, OSPF Areas, and Protocol Instances............ 4 61 3. Reachability................................................. 5 62 3.1 Node IPv4 Local Prefix Sub-TLV.............................. 5 63 3.2 Node IPv6 Local Prefix Sub-TLV.............................. 6 64 4. Link Attribute............................................... 7 65 4.1 Local Adaptation............................................ 7 66 4.2 Bandwidth Accounting........................................ 8 67 5. Routing Information Scope.................................... 8 68 5.1 Terminology and Identification.............................. 8 69 5.2 Link Advertisement (Local and Remote TE Router ID Sub-TLV).. 9 70 5.3 Reachability Advertisement (Local TE Router ID Sub-TLV).... 10 71 6. Routing Information Dissemination........................... 11 72 6.1 Import/Export Rules........................................ 11 73 6.2 Discovery and Selection.................................... 12 74 6.2.1 Upward Discovery and Selection........................... 12 75 6.2.2 Downward Discovery and Selection......................... 13 76 6.2.3. Router Information Experimental Capabilities TLV........ 15 77 6.3 Loop Prevention............................................ 15 78 6.3.1 Associated RA ID......................................... 16 79 6.3.2 Processing............................................... 17 80 6.4 Resiliency................................................. 18 81 6.5 Neighbor Relationship and Routing Adjacency................ 19 82 6.6 Reconfiguration............................................ 19 83 7. OSPFv2 Scalability.......................................... 20 84 8. Security Considerations..................................... 20 85 9. IANA Considerations......................................... 20 86 10. Experimental Code Points................................... 21 87 10.1. Sub-TLVs of the Link TLV................................. 21 88 10.2. Sub-TLVs of the Node Attribute TLV....................... 21 89 10.3. Sub-TLVs of the Router Address TLV....................... 22 90 10.4. TLVs of the Router Information LSA....................... 22 91 11. References................................................. 23 92 11.1 Normative References...................................... 23 93 11.2 Informative References.................................... 24 94 12. Author's Address........................................... 25 95 Appendix 1: ASON Terminology................................... 26 96 Appendix 2: ASON Routing Terminology........................... 28 98 1. Introduction 100 The Generalized Multiprotocol Label Switching (GMPLS) [RFC3945] 101 protocol suite is designed to provide a control plane for a range of 102 network technologies including optical networks such as time division 103 multiplexing (TDM) networks including SONET/SDH and Optical Transport 104 Networks (OTNs), and lambda switching optical networks. 106 The ITU-T defines the architecture of the Automatically Switched 107 Optical Network (ASON) in [G.8080]. 109 [RFC4258] details the routing requirements for the GMPLS suite of 110 routing protocols to support the capabilities and functionality of 111 ASON control planes identified in [G.7715] and in [G.7715.1]. 113 [RFC4652] evaluates the IETF Link State Routing Protocols against the 114 requirements identified in [RFC4258]. Section 7.1 of [RFC4652] 115 summarizes the capabilities to be provided by OSPFv2 [RFC2328] in 116 support of ASON routing. This document details the OSPFv2 specifics 117 for ASON routing. 119 Multi-layer transport networks are constructed from multiple networks 120 of different technologies operating in a client-server relationship. 121 The ASON routing model includes the definition of routing levels that 122 provide scaling and confidentiality benefits. In multi-level routing, 123 domains called routing areas (RAs) are arranged in a hierarchical 124 relationship. Note that as described in [RFC4652] there is no implied 125 relationship between multi-layer transport networks and multi-level 126 routing. The multi-level routing mechanisms described in this 127 document work for both single layer and multi-layer networks. 129 Implementations may support a hierarchical routing topology (multi- 130 level) for multiple transport network layers and/or a hierarchical 131 routing topology for a single transport network layer. 133 This document details the processing of the generic (technology- 134 independent) link attributes that are defined in [RFC3630], 135 [RFC4202], and [RFC4203] and that are extended in this document. As 136 detailed in Section 4.2, technology-specific traffic engineering 137 attributes (and their processing) may be defined in other documents 138 that complement this document. 140 Note that this work is scoped to the requirements and evaluation 141 expressed in [RFC4258] and [RFC4652] and the ITU-T Recommendations 142 current when those documents were written. Future extensions of 143 revisions of this work may be necessary if the ITU-T Recommendations 144 are revised or if new requirements are introduced into a revision of 145 [RFC4258]. 147 This document is classified as Experimental. Significant changes to 148 routing protocols are of concern to the stability of the Internet. 149 The extensions described in this document are intended for cautious 150 use in self-contained environments. The objective is to determine 151 whether these extensions are stable and functional, whether there is 152 a demand for implementation and deployment, and whether the 153 extensions have any impact on existing routing protocol deployments. 155 1.1. Conventions Used in This Document 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 159 document are to be interpreted as described in RFC 2119 [RFC2119]. 161 The reader is assumed to be familiar with the terminology and 162 requirements developed in [RFC4258] and the evaluation outcomes 163 detailed in [RFC4652]. 165 General ASON terminology is provided in Appendix 1. ASON routing 166 terminology is described in Appendix 2. 168 2. Routing Areas, OSPF Areas, and Protocol Instances 170 An ASON routing area (RA) represents a partition of the data plane 171 and its identifier is used within the control plane as the 172 representation of this partition. 174 RAs are arranged in hierarchical levels such that any one RA may 175 contain multiple other RAs, and is wholly contained by a single RA. 176 Thus, an RA may contain smaller RAs inter-connected by links. The 177 limit of the subdivision results in an RA that contains just two 178 sub-networks interconnected by a single link. 180 An ASON RA can be mapped to an OSPF area, but the hierarchy of ASON 181 RA levels does not map to the hierarchy of OSPF routing areas. 182 Instead, successive hierarchical levels of RAs MUST be represented by 183 separate instances of the protocol. Thus, inter-level routing 184 information exchange (as described in Section 6) involves the export 185 and import of routing information between protocol instances. 187 An ASON RA may therefore be identified by the combination of its OSPF 188 instance identifier and its OSPF area identifier. With proper and 189 careful network-wide configuration, this can be achieved using just 190 the OSPF area identifier, and this process is RECOMMENDED in this 191 document. These concepts and the subsequent handling of network 192 reconfiguration is discussed in Section 6. 194 3. Reachability 196 In order to advertise blocks of reachable address prefixes a 197 summarization mechanism is introduced that complements the 198 techniques described in [OSPF-NODE]. 200 This extension takes the form of a network mask (a 32-bit number 201 indicating the range of IP addresses residing on a single IP 202 network/subnet). The set of local addresses are carried in an OSPFv2 203 TE LSA node attribute TLV (a specific sub-TLV is defined per address 204 family, i.e., IPv4 and IPv6, used as network-unique identifiers). 206 The proposed solution is to advertise the local address prefixes of 207 a router as new sub-TLVs of the (OSPFv2 TE LSA) Node Attribute top 208 level TLV. This document defines the following sub-TLVs: 210 - Node IPv4 Local Prefix sub-TLV: Length: variable 211 - Node IPv6 Local Prefix sub-TLV: Length: variable 213 3.1 Node IPv4 Local Prefix Sub-TLV 215 The Type field of the Node IPv4 Local Prefix sub-TLV is assigned a 216 value in the range 32768-32777 agreed by all participants in the 217 experiment. The Value field of this sub-TLV contains one or more 218 local IPv4 prefixes. The Length is measured in bytes and, as defined 219 in [RFC3630] reports the length in bytes of the Value part of the 220 sub-TLV. It is set to 8 x n, where n is the number of local IPv4 221 prefixes included in the sub-TLV. 223 The Node IPv4 Local Prefix sub-TLV has the following format: 225 0 1 2 3 226 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 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Type | Length (8 x n) | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Network Mask 1 | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | IPv4 Address 1 | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | | 235 // ... // 236 | | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Network Mask n | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | IPv4 Address n | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 Network mask i: A 32-bit number indicating the IPv4 address mask 244 for the ith advertised destination prefix. 246 Each pair listed as part of this sub- 247 TLV represents a reachable destination prefix hosted by the 248 advertising Router ID. 250 The local addresses that can be learned from Opaque TE LSAs (that is, 251 the router address and TE interface addresses) SHOULD NOT be 252 advertised in the node IPv4 local prefix sub-TLV. 254 3.2 Node IPv6 Local Prefix Sub-TLV 256 The Type field of the Node IPv6 Local Prefix sub-TLV is assigned a 257 value in the range 32768-32777 agreed by all participants in the 258 experiment. The Value field of this sub-TLV contains one or more 259 local IPv6 prefixes. IPv6 Prefix representation uses [RFC5340] 260 Section A.4.1. 262 The Node IPv6 Local Prefix sub-TLV has the following format: 264 0 1 2 3 265 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 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Type | Length | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | PrefixLength | PrefixOptions | (0) | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | | 272 | IPv6 Address Prefix 1 | 273 | | 274 | | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | | 277 // ... // 278 | | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | PrefixLength | PrefixOptions | (0) | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | | 283 | IPv6 Address Prefix n | 284 | | 285 | | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 Length reports the length of the Value part of the sub-TLV in 288 bytes. It is set to the sum over all of the local prefixes 289 included in the sub-TLV of 290 (4 + (number of 32-bit words in the prefix) * 4). 291 The encoding of each prefix potentially using fewer than four 292 32-bit words is described below. 294 PrefixLength: Length in bits of the prefix. 296 PrefixOptions: 8-bit field describing various capabilities 297 associated with the prefix (see [RFC5340] Section A.4.2). 299 IPv6 Address Prefix i: The ith IPv6 address prefix in the list. 300 Each prefix is encoded in an even multiple of 32-bit words using 301 the fewest pairs of 32-bit words necessary to include the entire 302 prefix. Thus, each prefix is encoded in either 64 or 128 bits 303 with trailing zero bit padding as necessary. 305 The local addresses that can be learned from TE LSAs, i.e., router 306 address and TE interface addresses, SHOULD NOT be advertised in the 307 node IPv6 local prefix sub-TLV. 309 4. Link Attribute 311 [RFC4652] provides a map between link attributes and characteristics 312 and their representation in sub-TLVs of the top level Link TLV of the 313 Opaque TE LSA [RFC3630] and [RFC4203], with the exception of the 314 Local Adaptation (see below). Advertisement of this information 315 SHOULD be supported on a per-layer basis, i.e., one Opaque TE LSA per 316 switching capability (and per bandwidth granularity, e.g., low-order 317 virtual container and high-order virtual container). 319 4.1 Local Adaptation 321 Local Adaptation is defined as a TE link attribute (i.e., sub-TLV) 322 that describes the cross/inter-layer relationships. 324 The Interface Switching Capability Descriptor (ISCD) TE Attribute 325 [RFC4202] identifies the ability of the TE link to support cross- 326 connection to another link within the same layer, and the ability to 327 use a locally terminated connection that belongs to one layer as a 328 data link for another layer (adaptation capability). However, the 329 information associated to the ability to terminate connections 330 within that layer (referred to as the termination capability) is 331 embedded with the adaptation capability. 333 For instance, a link between two optical cross-connects will contain 334 at least one ISCD attribute describing the lambda switching capable 335 (LSC) switching capability. Whereas a link between an optical cross- 336 connect and an IP/MPLS LSR will contain at least two ISCD attributes: 337 one for the description of the LSC termination capability and one for 338 the packet switching capable (PSC) adaptation capability. 340 In OSPFv2, the Interface Switching Capability Descriptor (ISCD) is a 341 sub-TLV (of type 15) of the top-level Link TLV (of type 2) [RFC4203]. 343 The adaptation and termination capabilities are advertised using two 344 separate ISCD sub-TLVs within the same top-level link TLV. 346 Per [RFC4202] and [RFC4203], an interface MAY have more than one 347 ISCD sub-TLV. Hence, the corresponding advertisements should not 348 result in any compatibility issues. 350 Further refinement of the ISCD sub-TLV for multi-layer networks is 351 outside the scope of this document. 353 4.2 Bandwidth Accounting 355 GMPLS Routing defines an Interface Switching Capability Descriptor 356 (ISCD) that delivers, among other things, information about the 357 (maximum/minimum) bandwidth per priority that an LSP can make use of. 358 Per [RFC4202] and [RFC4203], one or more ISCD sub-TLVs can be 359 associated with an interface. This information, combined with the 360 Unreserved Bandwidth (sub-TLV defined in [RFC3630], Section 2.5.8), 361 provides the basis for bandwidth accounting. 363 In the ASON context, additional information may be included when the 364 representation and information in the other advertised fields are 365 not sufficient for a specific technology (e.g., SDH). The definition 366 of technology-specific information elements is beyond the scope of 367 this document. Some technologies will not require additional 368 information beyond what is already defined in [RFC3630], [RFC4202], 369 and [RFC4203]. 371 5. Routing Information Scope 373 5.1. Terminology and Identification 375 The definition of short-hand terminology introduced in [RFC4652] is 376 repeated here for clarity. 378 - Pi is a physical (bearer/data/transport plane) node. 380 - Li is a logical control plane entity that is associated to a single 381 data plane (abstract) node. Each Li is identified by a unique TE 382 Router-ID. The latter is a control plane identifier, defined as the 383 Router Address top level TLV of the Type 1 TE LSA [RFC3630]. 385 Note: the Router Address top-level TLV definition, processing and 386 usage remain per [RFC3630]. This TLV specifies a stable IP address 387 of the advertising router (Ri) that is always reachable if there is 388 any IP connectivity to it (e.g. via the Data Communication 389 Network). Moreover, each advertising router advertises a unique, 390 reachable IP address for each Pi on behalf of which it makes 391 advertisements. 393 - Ri is a logical control plane entity that is associated to a 394 control plane "router". The latter is the source for topology 395 information that it generates and shares with other control plane 396 "routers". The Ri is identified by the (advertising) Router-ID 397 (32-bit) [RFC2328]. 399 The Router-ID, which is represented by Ri and which corresponds to 400 the RC-ID [RFC4258], does not enter into the identification of the 401 logical entities representing the data plane resources such as 402 links. The Routing DataBase (RDB) is associated to the Ri. 404 Note: Aside from the Li/Pi mappings, these identifiers are not 405 assumed to be in a particular entity relationship except that the Ri 406 may have multiple Lis in its scope. The relationship between Ri and 407 Li is simple at any moment in time: an Li may be advertised by only 408 one Ri at any time. However, an Ri may advertise a set of one or 409 more Lis. Hence, the OSPFv2 routing protocol must support a single 410 Ri advertising on behalf of more than one Li. 412 5.2 Link Advertisement (Local and Remote TE Router ID sub-TLV) 414 A Router-ID (Ri) advertising on behalf multiple TE Router_IDs (Lis) 415 creates a 1:N relationship between the Router-ID and the TE 416 Router-ID. As the link local and link remote (unnumbered) ID 417 association is not unique per node (per Li unicity), the 418 advertisement needs to indicate the remote Lj value and rely on the 419 initial discovery process to retrieve the [Li;Lj] relationship. In 420 brief, as unnumbered links have their ID defined on per Li bases, 421 the remote Lj needs to be identified to scope the link remote ID to 422 the local Li. Therefore, the routing protocol MUST be able to 423 disambiguate the advertised TE links so that they can be associated 424 with the correct TE Router-ID. 426 For this purpose, a new sub-TLV of the (OSPFv2 TE LSA) top level 427 Link TLV is introduced that defines the local and the remote 428 TE Router-ID. 430 The Type field of the Local and Remote TE Router-ID sub-TLV is 431 assigned a value in the range 32768-32777 agreed by all participants 432 in the experiment. The Length field takes the value 8. The Value 433 field of this sub-TLV contains 4 octets of Local TE Router Identifier 434 followed by 4 octets of Remote TE Router Identifier. The value of the 435 Local and the Remote TE Router Identifier SHOULD NOT be set to 0. 437 The format of the Local and Remote TE Router-ID sub-TLV is: 439 0 1 2 3 440 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 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | Type | Length (8) | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | Local TE Router Identifier | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | Remote TE Router Identifier | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 This sub-TLV is only required to be included as part of the top 450 level Link TLV if the Router-ID is advertising on behalf of more 451 than one TE Router-ID. In any other case, this sub-TLV SHOULD be 452 omitted except if operator plans to start of with 1 Li and 453 progressively add more Li's (under the same Ri) such as to maintain 454 consistency. 456 Note: The Link ID sub-TLV that identifies the other end of the link 457 (i.e., Router-ID of the neighbor for point-to-point links) MUST 458 appear exactly once per Link TLV. This sub-TLV MUST be processed as 459 defined in [RFC3630]. 461 5.3 Reachability Advertisement (Local TE Router ID sub-TLV) 463 When the Router-ID is advertised on behalf of multiple TE Router-IDs 464 (Lis), the routing protocol MUST be able to associate the advertised 465 reachability information with the correct TE Router-ID. 467 For this purpose, a new sub-TLV of the (OSPFv2 TE LSA) top level 468 Node Attribute TLV is introduced. This TLV associates the local 469 prefixes (see above) to a given TE Router-ID. 471 The Type field of the Local TE Router-ID sub-TLV is assigned a value 472 in the range 32768-32777 agreed by all participants in the 473 experiment. The Length field takes the value 4. The Value field of 474 this sub-TLV contains the Local TE Router Identifier [RFC3630] 475 encoded over 4 octets. 477 The format of the Local TE Router-ID sub-TLV is: 479 0 1 2 3 480 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 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | Type | Length (4) | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | Local TE Router Identifier | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 This sub-TLV is only required to be included be included as part of 488 the Node Attribute TLV if the Router-ID is advertising on behalf of 489 more than one TE Router-ID. In any other case, this sub-TLV SHOULD 490 be omitted. 492 6. Routing Information Dissemination 494 An ASON routing area (RA) represents a partition of the data plane 495 and its identifier is used within the control plane as the 496 representation of this partition. A RA may contain smaller RAs inter- 497 connected by links. The limit of the subdivision results is an RA 498 that contains two sub-networks interconnected by a single link. ASON 499 RA levels do not reflect routing protocol levels (such as OSPF 500 areas). 502 Successive hierarchical levels of RAs can be represented by separate 503 instances of the protocol. 505 Routing controllers (RCs) supporting RAs disseminate information 506 downward and upward in this hierarchy. The vertical routing 507 information dissemination mechanisms described in this section do not 508 introduce or imply a new OSPF routing area hierarchy. RCs supporting 509 RAs at multiple levels are structured as separate OSPF instances with 510 routing information exchanges between levels described by import and 511 export rules operating between OSPF instances. 513 The implication is that an RC that performs import/export of routing 514 information as described in this document does not implement an Area 515 Border Router (ABR) functionality. 517 6.1 Import/Export Rules 519 RCs supporting RAs disseminate information upward and downward in the 520 hierarchy by importing/exporting routing information as Opaque TE 521 LSAs (Opaque Type 1) of LS Type 10. The information that MAY be 522 exchanged between adjacent levels includes the Router-Address, Link, 523 and Node-Attribute top-level TLVs. 525 The Opaque TE LSA import/export rules are governed as follows: 527 - If the export target interface is associated with the same RA as is 528 associated with the import interface, the Opaque LSA MUST NOT be 529 imported. 531 - If a match is found between the Advertising Router-ID in the 532 header of the received Opaque TE LSA and one of the Router-IDs 533 belonging to the RA of the export target interface, the Opaque LSA 534 MUST NOT be imported. 536 - If these two conditions are not met the Opaque TE LSA MAY be 537 imported according to local policy. If imported, the LSA MAY be 538 disseminated according to local policy. If disseminated, the normal 539 OSPF flooding rules MUST be followed and the Advertising Router-ID 540 MUST be set to the importing router's router-ID. 542 The imported/exported routing information content MAY be transformed, 543 e.g., filtered or aggregated, as long as the resulting routing 544 information is consistent. In particular, when more than one RC is 545 bound to adjacent levels and both are allowed to import/export 546 routing information, it is expected that these transformation are 547 performed in a consistent manner. Definition of these policy-based 548 mechanisms is outside the scope of this document. 550 In practice, and in order to avoid scalability and processing 551 overhead, routing information imported/exported downward/upward in 552 the hierarchy is expected to include reachability information (see 553 Section 3) and, upon strict policy control, link topology 554 information. 556 6.2 Discovery and Selection 558 6.2.1 Upward Discovery and Selection 560 In order to discover RCs that are capable of disseminating routing 561 information up the routing hierarchy, the following capability 562 descriptor bit is set in the OSPF Router Information Experimental 563 Capabilities TLV (see Section 6.2.3) carried in the Router 564 Information LSA ([RFC4970]). 566 - U bit: When set, this flag indicates that the RC is capable of 567 disseminating routing information upward to the adjacent level. 569 In the case that multiple RCs are advertized from the same RA with 570 their U bit set, the RC with the highest Router-ID, among those RCs 571 with the U bit set, SHOULD be selected as the RC for upward 572 dissemination of routing information. The other RCs MUST NOT 573 participate in the upward dissemination of routing information as 574 long as the opaque LSA information corresponding to the highest 575 Router-ID RC does not reach MaxAge. This mechanism prevents more than 576 one RC advertizing routing information upward in the routing 577 hierarchy from the same RA. 579 Note that if the information to allow the selection of the RC that 580 will be used to disseminate routing information up the hierarchy from 581 a specific RA cannot be discovered automatically, it MUST be manually 582 configured. 584 Once an RC has been selected, it remains unmodified even if an RC 585 with a higher Router-ID is introduced and advertizes its capability 586 to disseminate routing information upward the adjacent level (i.e., 587 U bit set). This hysteresis mechanism prevents from disturbing the 588 upward routing information dissemination process in case, e.g., of 589 flapping. 591 6.2.2 Downward Discovery and Selection 593 The same discovery mechanism is used for selecting the RC responsible 594 for dissemination of routing information downward in the hierarchy. 595 However, an additional restriction MUST be applied such that the RC 596 selection process takes into account that an upper level may be 597 adjacent to one or more lower (RA) levels. For this purpose a 598 specific TLV indexing the (lower) RA ID to which the RC's are capable 599 of disseminating routing information is needed. 601 The Downstream Associated RA ID TLV is carried in the OSPF Router 602 Information LSA [RFC4970]. The Type field of the Downstream 603 Associated RA ID TLV is assigned a value in the range 32768-32777 604 agreed by all participants in the experiment. The Length of this TLV 605 is n x 4 octets. The Value field of this sub-TLV contains the list of 606 Associated RA IDs. Each Associated RA ID value is encoded following 607 the OSPF area ID (32 bits) encoding rules defined in [RFC2328]. 609 The format of the Downstream Associated RA ID TLV is: 611 0 1 2 3 612 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 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | Type | Length (4 x n) | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | Associated RA ID 1 | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | | 619 // ... // 620 | | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | Associated RA ID n | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 To discover RCs that are capable to disseminate routing information 626 downward the routing hierarchy, the following capability descriptor 627 bit is set in the OSPF Router Information Experimental Capabilities 628 TLV (see Section 6.2.3) carried in the Router Information LSA 629 ([RFC4970]). 631 Note that the Downstream Associated RA ID TLV MUST be present when 632 the D bit is set. 634 - D bit: when set, this flag indicates that the RC is capable to 635 disseminate routing information downward the adjacent levels. 637 If multiple RCs are advertised for the same Associated RA ID, the RC 638 with the highest Router ID, among the RCs with the D bit set, MUST be 639 selected as the RC for downward dissemination of routing information. 640 The other RCs for the same Associated RA ID MUST NOT participate in 641 the downward dissemination of routing information as long as the 642 opaque LSA information corresponding to the highest Router ID RC does 643 not reach MaxAge. This mechanism prevents from having more than one 644 RC advertizing routing information downward the routing hierarchy. 646 Note that if the information to allow the selection of the RC that 647 will be used to disseminate routing information down the hierarchy to 648 a specific RA cannot be discovered automatically, it MUST be manually 649 configured. 651 The OSPF Router information Opaque LSA (Opaque type of 4, Opaque ID 652 of 0) and its content, in particular the Router Informational 653 Capabilities TLV [RFC4970] and TE Node Capability Descriptor TLV 654 [RFC5073], MUST NOT be re-originated. 656 6.2.3. Router Information Experimental Capabilities TLV 658 A new TLV is defined for inclusion in the Router Information LSA to 659 carry experimental capabilities because the assignment policy for 660 bits in the Router Informational Capabilities TLV is "Standards 661 Action" [RFC5226] prohibiting its use from Experimental documents. 663 The format of the Router Information Experimental Capabilities TLV is 664 as follows: 666 0 1 2 3 667 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 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | Type | Length | 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 | Experimental Capabilities | 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 Type A value in the range 32768-32777 agreed by all 675 participants in the experiment. 677 Length A 16-bit field that indicates the length of the value 678 portion in octets and will be a multiple of 4 octets 679 dependent on the number of capabilities advertised. 680 Initially, the length will be 4, denoting 4 octets of 681 informational capability bits. 683 Value A variable length sequence of capability bits rounded 684 to a multiple of 4 octets padded with undefined bits. 686 The following experimental capability bits are assigned: 688 Bit Capabilities 690 0 The U bit (see Section 6.2.1) 691 1 The D bit (see Section 6.2.2) 693 6.3 Loop Prevention 695 When more than one RC is bound to an adjacent level of the hierarchy, 696 and is configured or selected to redistribute routing information 697 upward and downward, a specific mechanism is required to avoid 698 looping of routing information. Looping is the re-introduction of 699 routing information that has been advertized from the upper level 700 back to the upper level. This specific case occurs, for example, when 701 the RC advertizing routing information downward in the hierarchy is 702 not the same one that advertizes routing upward in the hierarchy. 704 When these conditions are met, it is necessary to have a means by 705 which an RC receiving an Opaque TE LSA imported/exported downward by 706 an RC associated to the same RA, does not import/export the content 707 of this LSA back upward into the (same) upper level. 709 Note that configuration and operational simplification can be 710 obtained when both functionalities are configured on a single RC (per 711 pair of adjacent levels) fulfilling both roles. Figure 1 provides an 712 example where such simplification applies. 714 .................................................... 715 . . 716 . RC_5 ------------ RC_6 . 717 . | | . 718 . | | RA_Y . 719 Upper . ********* ********* . 720 Layer ............* RC_1a *.........* RC_2a *............. 721 __________________* | *_________* | *__________________ 722 ............* RC_1b *... ...* RC 2b *............. 723 Lower . ********* . . ********* . 724 Layer . | . . | . 725 . RA_Z | . . | RA_X . 726 . RC_3 . . RC_4 . 727 . . . . 728 ........................ ......................... 730 Figure 1. Hierarchical Environment (Example) 732 In this case, the procedure described in this section MAY be 733 omitted, as long as these conditions are permanently guaranteed. In 734 all other cases, without exception, the procedure described in this 735 section MUST be applied. 737 6.3.1 Associated RA ID 739 We need some way of filtering the downward/upward re-originated 740 Opaque TE LSA. Per [RFC5250], the information contained in Opaque 741 LSAs may be used directly by OSPF. By adding the RA ID associated 742 with the incoming routing information the loop prevention problem can 743 be solved. 745 This additional information, referred to as the Associated RA ID, MAY 746 be carried in opaque LSAs that including any of the following top 747 level TLVs: 748 - the Router Address top level TLV 749 - the Link top level TLV 750 - the Node Attribute top level TLV. 752 The Associated RA ID reflects the identifier of the area from which 753 the routing information is received. For example, for a multi-level 754 hierarchy, this identifier does not reflect the originating RA ID, it 755 will reflect the RA from which the routing information is imported. 757 The Type field of the Associated RA ID sub-TLV is assigned a value in 758 the range 32768-32777 agreed by all participants in the experiment. 759 The same value MUST be used for the Type regardless of which TLV the 760 sub-TLV appears in. 762 The Length of the Associated RA ID TLV is 4 octets. The Value field 763 of this sub-TLV contains the Associated RA ID. The Associated RA ID 764 value is encoded following the OSPF area ID (32 bits) encoding rules 765 defined in [RFC2328]. 767 The format of the Associated RA ID TLV is defined as follows: 769 0 1 2 3 770 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 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 | Type | Length (4) | 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 | Associated RA ID | 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 6.3.2 Processing 779 When fulfilling the rules detailed in Section 6.1 a given Opaque LSA 780 is imported/exported downward or upward the routing hierarchy, the 781 Associated RA ID TLV is added to the received opaque LSA list of TLVs 782 such as to identify the area from which this routing information has 783 been received. 785 When the RC adjacent to the lower or upper level routing level 786 receives this opaque LSA, the following rule is applied (in addition 787 the rule governing the import/export of opaque LSAs as detailed in 788 Section 6.1). 790 - If a match is found between the Associated RA ID of the received 791 Opaque TE LSA and the RA ID belonging to the area of the export 792 target interface, the Opaque TE LSA MUST NOT be imported. 794 - Otherwise, this opaque LSA MAY be imported and disseminated 795 downward or upward the routing hierarchy following the OSPF 796 flooding rules. 798 This mechanism ensures that no race condition occurs when the 799 conditions depicted in Figure 2 are met. 801 RC_5 ------------- RC_6 802 | | 803 | | RA_Y 804 Upper ********* ********* 805 Layer ............* RC_1a *.........* RC_2a *............. 806 __________________* | *_________* | *__________________ 807 ............* RC_1b *.........* RC 2b *............. 808 Lower ********* ********* 809 Layer | | 810 | | RA_X 811 RC_3 --- . . . --- RC_4 813 Figure 2. Race Condition Prevention (Example) 815 Assume that RC_1b is configured for exporting routing information 816 upward toward RA_Y (upward the routing hierarchy) and that RC_2a is 817 configured for exporting routing information toward RA_X (downward 818 the routing hierarchy). 820 Assumes that routing information advertised by RC_3 would reach 821 RC_4 faster across RA_Y through hierarchy. 823 If RC_2b is not able to prevent from importing that information, 824 RC_4 may receive that information before the same advertisement 825 would propagate in RA_X (from RC_3) to RC_4. For this purpose RC_1a 826 inserts the Associated RA X to the imported routing information 827 from RA_X. Because RC_2b finds a match between the Associated RA 828 ID (X) of the received Opaque TE LSA and the ID (X) of the RA of the 829 export target interface, this LSA MUST NOT be imported. 831 6.4 Resiliency 833 OSPF creates adjacencies between neighboring routers for the purpose 834 of exchanging routing information. After a neighbor has been 835 discovered, bidirectional communication is ensured, and a routing 836 adjacency is formed between RCs, loss of communication may result in 837 partitioned OSPF areas and so in partitioned RAs. 839 Consider for instance (see Figure 2.) the case where RC_1a and RC_1b 840 is configured for exchanging routing information downward and upward 841 RA_Y, resp., and that RC_2a and RC_2b are not configured for 842 exchanging routing any routing information toward RA_X. If the 843 communication between RC_1a and RC_2a is broken (due, e.g., to RC_5 - 844 RC_6 communication failure), RA_Y could be partitioned. 846 In these conditions, it is RECOMMENDED that RC_2a be re-configurable 847 such as to allow for exchanging routing information downward to RA_X. 848 This reconfiguration MAY be performed manually or automatically. In 849 the latter cases, automatic reconfiguration uses the mechanism 850 described in Section 6.2 (forcing MaxAge of the corresponding opaque 851 LSA information in case the originating RC becomes unreachable). 852 Manual reconfiguration MUST be supported. 854 6.5 Neighbor Relationship and Routing Adjacency 856 It is assumed that (point-to-point) IP control channels are 857 provisioned/configured between RCs belonging to the same routing 858 level. Provisioning/configuration techniques are outside the scope 859 of this document. 861 Once established, the OSPF Hello Protocol is responsible for 862 establishing and maintaining neighbor relationships. This protocol 863 also ensures that communication between neighbors is bidirectional. 864 Routing adjacency can subsequently be formed between RCs following 865 mechanisms defined in [RFC2328]. 867 6.6 Reconfiguration 869 This section details the RA ID reconfiguration steps. 871 Reconfiguration of the RA ID occurs when the RA ID is modified 872 e.g. from value Z to value X or Y (see Figure 2.). 874 The process of reconfiguring the RA ID involves: 876 - Disable the import/export of routing information from the upper 877 and lower level (to prevent any LS information update). 879 - Change the RA ID of the local level RA from e.g. Z to X or Y. 880 Perform an LSDB checksum on all routers to verify that LSDB are 881 consistent. 883 - Enable import of upstream and downstream routing information such 884 as to re-synchronize local level LSDB from any LS information that 885 may have occurred in an upper or a lower routing level. 887 - Enable export of routing information downstream such as to re-sync 888 the downstream level with the newly reconfigured RA ID (as part of 889 the re-advertised Opaque TE LSA). 891 - Enable export of routing information upstream such as to re-sync 892 the upstream level with the newly reconfigured RA ID (as part of 893 the re-advertised Opaque TE LSA). 895 Note that the re-sync operation needs to be carried out only between 896 the directly adjacent upper and lower routing level. 898 7. OSPFv2 Scalability 900 - Routing information exchange upward/downward in the hierarchy 901 between adjacent RAs SHOULD by default be limited to reachability 902 information. In addition, several transformations such as prefix 903 aggregation are RECOMMENDED when allowing decreasing the amount of 904 information imported/exported by a given RC without impacting 905 consistency. 907 - Routing information exchange upward/downward in the hierarchy 908 involving TE attributes MUST be under strict policy control. Pacing 909 and min/max thresholds for triggered updates are strongly 910 RECOMMENDED. 912 - The number of routing levels MUST be maintained under strict policy 913 control. 915 8. Security Considerations 917 This document specifies the contents and processing of Opaque LSAs 918 in OSPFv2 [RFC2328]. Opaque TE and RI LSAs defined in this document 919 are not used for SPF computation, and so have no direct effect on IP 920 routing. Additionally, ASON routing domains are delimited by the 921 usual administrative domain boundaries. 923 Any mechanisms used for securing the exchange of normal OSPF LSAs 924 can be applied equally to all Opaque TE and RI LSAs used in the ASON 925 context. Authentication of OSPFv2 LSA exchanges (such as OSPF 926 cryptographic authentication [RFC2328] and [OSPF-CA]) can be used to 927 secure against passive attacks and provide significant protection 928 against active attacks. [OSPF-CA] defines a mechanism for 929 authenticating OSPF packets by making use of the HMAC algorithm in 930 conjunction with the SHA family of cryptographic hash functions. 932 [RFC2154] adds i) digital signatures to authenticate OSPF LSA data, 933 ii) certification mechanism for distribution of routing information, 934 and iii) use a neighbor-to-neighbor authentication algorithm to 935 protect local OSPFv2 protocol exchanges. 937 9. IANA Considerations 939 This document makes no requests for IANA action. 941 10. Experimental Code Points 943 This document is classified as Experimental. It defines new TLVs and 944 sub-TLVs for inclusion in OSPF LSAs. According to the assignment 945 policies for the registries of codepoints for these TLVs and sub- 946 TLVs, values must be assigned from the experimental ranges and must 947 not be recorded by IANA or mentioned in this document. 949 The following sections summarise the TLVs and sub-TLVs concerned. 951 10.1. Sub-TLVs of the Link TLV 953 This document defines the following sub-TLVs of the Link TLV carried 954 in the OSPF TE LSA: 956 - Local and Remote TE Router ID sub-TLV 957 - Associated RA ID sub-TLV 959 The defining text for code point assignment for sub-TLVs of the OSPF 960 TE Link TLV says ([RFC3630]): 962 o Types in the range 10-32767 are to be assigned via Standards 963 Action. 964 o Types in the range 32768-32777 are for experimental use; these 965 will not be registered with IANA, and MUST NOT be mentioned by 966 RFCs. 967 o Types in the range 32778-65535 are not to be assigned at this 968 time. 970 That means that the new sub-TLVs must be assigned type values from 971 the range 32768-32777. It is a matter for experimental 972 implementations to assign their own code points, and to agree with 973 cooperating implementations participating in the same experiments 974 what values to use. 976 Note that the same value for the Associated RA ID sub-TLV MUST be 977 used when it appears in the Link TLV, the Node Attribute TLV, and the 978 Router Address TLV. 980 10.2. Sub-TLVs of the Node Attribute TLV 982 This document defines the following sub-TLVs of the Node Attribute 983 TLV carried in the OSPF TE LSA. 985 - Node IPv4 Local Prefix sub-TLV 986 - Node IPv6 Local Prefix sub-TLV 987 - Local TE Router ID sub-TLV 988 - Associated RA ID sub-TLV 989 The defining text for code point assignment for sub-TLVs of the OSPF 990 Node Attribute TLV says ([OSPF-NODE]): 992 o Types in the range 3-32767 are to be assigned via Standards 993 Action. 994 o Types in the range 32768-32777 are for experimental use; these 995 will not be registered with IANA, and MUST NOT be mentioned by 996 RFCs. 997 o Types in the range 32778-65535 are not to be assigned at this 998 time. Before any assignments can be made in this range, there 999 MUST be a Standards Track RFC that specifies IANA 1000 Considerations that covers the range being assigned. 1002 That means that the new sub-TLVs must be assigned type values from 1003 the range 32768-32777. It is a matter for experimental 1004 implementations to assign their own code points, and to agree with 1005 cooperating implementations participating in the same experiments 1006 what values to use. 1008 Note that the same value for the Associated RA ID sub-TLV MUST be 1009 used when it appears in the Link TLV, the Node Attribute TLV, and the 1010 Router Address TLV. 1012 10.3. Sub-TLVs of the Router Address TLV 1014 The OSPF Router Address TLV is defined in [RFC3630]. No sub-TLVs are 1015 defined in that document and there is no registry or allocation 1016 policy for sub-TLVs of the Router Address TLV. 1018 This document defines the following new sub-TLVs for inclusion in the 1019 OSPF Router Address TLV: 1021 - Associated RA ID sub-TLV 1023 Note that the same value for the Associated RA ID sub-TLV MUST be 1024 used when it appears in the Link TLV, the Node Attribute TLV, and the 1025 Router Address TLV. This is consistent with potential for a future 1026 definition of a registry with policies that match the other existing 1027 registries. 1029 10.4. TLVs of the Router Information LSA 1031 This document defines two new TLVs to be carried in the Router 1032 Information LSA. 1034 - Downstream Associated RA ID TLV 1035 - Router Information Experimental Capabilities TLV 1036 The defining text for code point assignment for TLVs of the OSPF 1037 Router Information LSA says ([RFC4970]): 1039 o 1-32767 Standards Action. 1041 o Types in the range 32768-32777 are for experimental use; these 1042 will not be registered with IANA and MUST NOT be mentioned by 1043 RFCs. 1045 o Types in the range 32778-65535 are reserved and are not to be 1046 assigned at this time. Before any assignments can be made in 1047 this range, there MUST be a Standards Track RFC that specifies 1048 IANA Considerations that covers the range being assigned. 1050 That means that the new TLVs must be assigned type values from the 1051 range 32768-32777. It is a matter for experimental implementations to 1052 assign their own code points, and to agree with cooperating 1053 implementations participating in the same experiments what values to 1054 use. 1056 11. References 1058 11.1 Normative References 1060 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 1061 Requirement Levels", BCP 14, RFC 2119, March 1997. 1063 [RFC2154] Murphy, S., Badger, M. and B. Wellington, "OSPF with 1064 Digital Signatures", RFC 2154, June 1997. 1066 [RFC2328] J. Moy, "OSPF Version 2", RFC 2328, STD 54, April 1998. 1068 [RFC3630] D. Katz et al. "Traffic Engineering (TE) Extensions to 1069 OSPF Version 2", RFC 3630, September 2003. 1071 [RFC3945] E.Mannie, Ed., "Generalized Multi-Protocol Label 1072 Switching (GMPLS) Architecture", RFC 3945, October 2004. 1074 [RFC4202] K. Kompella (Editor) et al., "Routing Extensions in 1075 Support of Generalized MPLS," RFC 4202, October 2005. 1077 [RFC4203] K. Kompella (Editor) et al., "OSPF Extensions in 1078 Support of Generalized Multi-Protocol Label Switching 1079 (GMPLS)," RFC 4203, October 2005. 1081 [RFC4970] A. Lindem et al., "Extensions to OSPF for Advertising 1082 Optional Router Capabilities", RFC 4970, July 2007. 1084 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1085 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1086 May 2008. 1088 [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 1089 OSPF Opaque LSA Option", RFC 5250, July 2008. 1091 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1092 for IPv6", RFC 5340, July 2008. 1094 [OSPF-NODE] R. Aggarwal and K. Kompella, "Advertising a Router's 1095 Local Addresses in OSPF TE Extensions", draft-ietf-ospf- 1096 te-node-addr, work in progress. 1098 11.2 Informative References 1100 [RFC4258] D.Brungard (Ed.) et al. "Requirements for Generalized 1101 MPLS (GMPLS) Routing for Automatically Switched Optical 1102 Network (ASON)," RFC 4258, November 2005. 1104 [RFC4652] D.Papadimitriou (Ed.) et al. "Evaluation of existing 1105 Routing Protocols against ASON Routing Requirements", 1106 RFC 4652, October 2006. 1108 [RFC5073] J.P.Vasseur et al., "Routing extensions for discovery of 1109 Traffic Engineering Node Capabilities", RFC 5073, 1110 December 2007. 1112 [OSPF-CA] Bhatia, M., Manral, V., White, R., and M., Barnes, "OSPF 1113 HMAC-SHA Cryptographic Authentication", draft-ietf-ospf- 1114 hmac-sha, work in progress. 1116 For information on the availability of ITU Documents, please see 1117 http://www.itu.int 1119 [G.7715] ITU-T Rec. G.7715/Y.1306, "Architecture and 1120 Requirements for the Automatically Switched Optical 1121 Network (ASON)," June 2002. 1123 [G.7715.1] ITU-T Draft Rec. G.7715.1/Y.1706.1, "ASON Routing 1124 Architecture and Requirements for Link State Protocols," 1125 November 2003. 1127 [G.8080] ITU-T Rec. G.8080/Y.1304, "Architecture for the 1128 Automatically Switched Optical Network (ASON)," 1129 November 2001 (and Revision, January 2003). 1131 12. Author's Address 1133 Dimitri Papadimitriou 1134 Alcatel-Lucent Bell 1135 Copernicuslaan 50 1136 B-2018 Antwerpen 1137 Belgium 1138 Phone: +32 3 2408491 1139 EMail: dimitri.papadimitriou@alcatel-lucent.be 1141 Acknowledgements 1143 The authors would like to thank Dean Cheng, Acee Lindem, Pandian 1144 Vijay, Alan Davey, Adrian Farrel, Deborah Brungard, and Ben Campbell 1145 for their useful comments and suggestions. 1147 Lisa Dusseault and Jari Arkko provided useful comments during IESG 1148 review. 1150 Question 14 of Study Group 15 of the ITU-T provided useful and 1151 constructive input. 1153 Appendix 1: ASON Terminology 1155 This document makes use of the following terms: 1157 Administrative domain: (see Recommendation G.805) for the purposes of 1158 [G7715.1] an administrative domain represents the extent of resources 1159 which belong to a single player such as a network operator, a service 1160 provider, or an end-user. Administrative domains of different players 1161 do not overlap amongst themselves. 1163 Control plane: performs the call control and connection control 1164 functions. Through signaling, the control plane sets up and releases 1165 connections, and may restore a connection in case of a failure. 1167 (Control) Domain: represents a collection of (control) entities that 1168 are grouped for a particular purpose. The control plane is subdivided 1169 into domains matching administrative domains. Within an 1170 administrative domain, further subdivisions of the control plane are 1171 recursively applied. A routing control domain is an abstract entity 1172 that hides the details of the RC distribution. 1174 External NNI (E-NNI): interfaces are located between protocol 1175 controllers between control domains. 1177 Internal NNI (I-NNI): interfaces are located between protocol 1178 controllers within control domains. 1180 Link: (see Recommendation G.805) a "topological component" which 1181 describes a fixed relationship between a "subnetwork" or "access 1182 group" and another "subnetwork" or "access group". Links are not 1183 limited to being provided by a single server trail. 1185 Management plane: performs management functions for the Transport 1186 Plane, the control plane and the system as a whole. It also provides 1187 coordination between all the planes. The following management 1188 functional areas are performed in the management plane: performance, 1189 fault, configuration, accounting and security management 1191 Management domain: (see Recommendation G.805) a management domain 1192 defines a collection of managed objects which are grouped to meet 1193 organizational requirements according to geography, technology, 1194 policy or other structure, and for a number of functional areas such 1195 as configuration, security, (FCAPS), for the purpose of providing 1196 control in a consistent manner. Management domains can be disjoint, 1197 contained or overlapping. As such the resources within an 1198 administrative domain can be distributed into several possible 1199 overlapping management domains. The same resource can therefore 1200 belong to several management domains simultaneously, but a management 1201 domain shall not cross the border of an administrative domain. 1203 Subnetwork Point (SNP): The SNP is a control plane abstraction that 1204 represents an actual or potential transport plane resource. SNPs (in 1205 different subnetwork partitions) may represent the same transport 1206 resource. A one-to-one correspondence should not be assumed. 1208 Subnetwork Point Pool (SNPP): A set of SNPs that are grouped together 1209 for the purposes of routing. 1211 Termination Connection Point (TCP): A TCP represents the output of a 1212 Trail Termination function or the input to a Trail Termination Sink 1213 function. 1215 Transport plane: provides bi-directional or unidirectional transfer 1216 of user information, from one location to another. It can also 1217 provide transfer of some control and network management information. 1218 The Transport Plane is layered; it is equivalent to the Transport 1219 Network defined in G.805 Recommendation. 1221 User Network Interface (UNI): interfaces are located between protocol 1222 controllers between a user and a control domain. Note: there is no 1223 routing function associated with a UNI reference point. 1225 Appendix 2: ASON Routing Terminology 1227 This document makes use of the following terms: 1229 Routing Area (RA): a RA represents a partition of the data plane and 1230 its identifier is used within the control plane as the representation 1231 of this partition. Per [G.8080] a RA is defined by a set of sub- 1232 networks, the links that interconnect them, and the interfaces 1233 representing the ends of the links exiting that RA. A RA may contain 1234 smaller RAs inter-connected by links. The limit of subdivision 1235 results in a RA that contains two sub-networks interconnected by a 1236 single link. 1238 Routing Database (RDB): repository for the local topology, network 1239 topology, reachability, and other routing information that is updated 1240 as part of the routing information exchange and may additionally 1241 contain information that is configured. The RDB may contain routing 1242 information for more than one Routing Area (RA). 1244 Routing Components: ASON routing architecture functions. These 1245 functions can be classified as protocol independent (Link Resource 1246 Manager or LRM, Routing Controller or RC) and protocol specific 1247 (Protocol Controller or PC). 1249 Routing Controller (RC): handles (abstract) information needed for 1250 routing and the routing information exchange with peering RCs by 1251 operating on the RDB. The RC has access to a view of the RDB. The RC 1252 is protocol independent. 1254 Note: Since the RDB may contain routing information pertaining to 1255 multiple RAs (and possibly to multiple layer networks), the RCs 1256 accessing the RDB may share the routing information. 1258 Link Resource Manager (LRM): supplies all the relevant component and 1259 TE link information to the RC. It informs the RC about any state 1260 changes of the link resources it controls. 1262 Protocol Controller (PC): handles protocol specific message exchanges 1263 according to the reference point over which the information is 1264 exchanged (e.g. E-NNI, I-NNI), and internal exchanges with the RC. 1265 The PC function is protocol dependent. 1267 Full Copyright Statement 1269 Copyright (c) 2009 IETF Trust and the persons identified as the 1270 document authors. All rights reserved. 1272 This document is subject to BCP 78 and the IETF Trust's Legal 1273 Provisions Relating to IETF Documents in effect on the date of 1274 publication of this document (http://trustee.ietf.org/license-info). 1275 Please review these documents carefully, as they describe your rights 1276 and restrictions with respect to this document.