idnits 2.17.1 draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 805. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 812. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 818. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == The page length should not exceed 58 lines per page, but there was 16 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: The local addresses that can be learned from TE LSAs i.e. router address and TE interface addresses SHOULD not be advertised in the node IPv4 local prefix sub-TLV. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: The local addresses that can be learned from TE LSAs i.e. router address and TE interface addresses SHOULD not be advertised in the node IPv6 local prefix sub-TLV. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: In case of multiple supporting RCs for the same Associated Area ID, the RC with the highest Router ID, among the RCs having set the D bit, MUST be selected as the RC for downward dissemination of routing information. The other RCs for the same Associated Area ID MUST not participate in the downward dissemination of routing information as long as the opaque LSA information corresponding to the highest Router ID RC does not reach MaxAge. This mechanism prevents from having more than one RC advertizing routing information downward the routing hierarchy. -- 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 (June 2006) is 6525 days in the past. Is this intentional? Checking references for intended status: Full Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'OSPF-TE-CAP' is mentioned on line 424, but not defined == Unused Reference: 'RFC2026' is defined on line 581, but no explicit reference was found in the text == Unused Reference: 'RFC3477' is defined on line 595, but no explicit reference was found in the text == Unused Reference: 'RFC3667' is defined on line 602, but no explicit reference was found in the text == Unused Reference: 'RFC3668' is defined on line 605, but no explicit reference was found in the text == Unused Reference: 'RFC3946' is defined on line 608, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-ospf-te-node-addr-02 ** Downref: Normative reference to an Proposed Standard draft: draft-ietf-ospf-te-node-addr (ref. 'OSPF-NODE') ** Obsolete normative reference: RFC 2370 (Obsoleted by RFC 5250) ** Obsolete normative reference: RFC 2740 (Obsoleted by RFC 5340) ** Downref: Normative reference to an Proposed Standard RFC: RFC 3477 ** Downref: Normative reference to an Proposed Standard RFC: RFC 3630 ** Obsolete normative reference: RFC 3667 (Obsoleted by RFC 3978) ** Obsolete normative reference: RFC 3668 (Obsoleted by RFC 3979) ** Obsolete normative reference: RFC 3946 (Obsoleted by RFC 4606) ** Downref: Normative reference to an Proposed Standard RFC: RFC 4202 ** Downref: Normative reference to an Proposed Standard RFC: RFC 4203 == Outdated reference: A later version (-11) exists of draft-ietf-ospf-cap-08 Summary: 16 errors (**), 0 flaws (~~), 13 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group Dimitri Papadimitriou 3 Internet Draft (Alcatel) 4 Category: Standard 6 Expiration Date: December 2006 June 2006 8 OSPFv2 Routing Protocols Extensions for ASON Routing 10 draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other documents 26 at any time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 The Generalized MPLS (GMPLS) suite of protocols has been defined to 42 control different switching technologies as well as different 43 applications. These include support for requesting TDM connections 44 including SONET/SDH and Optical Transport Networks (OTNs). 46 This document provides the extensions of the OSPFv2 Link State 47 Routing Protocol to meet the routing requirements for an 48 Automatically Switched Optical Network (ASON) as defined by ITU-T. 50 D.Papadimitriou et al. - Expires December 2006 1 51 1. Conventions used in this document 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 55 document are to be interpreted as described in RFC 2119 [RFC2119]. 57 The reader is assumed to be familiar with the terminology and 58 requirements developed in [ASON-RR] and the evaluation outcomes 59 detailed in [ASON-EVAL]. 61 2. Introduction 63 There are certain capabilities that are needed to support the ITU-T 64 Automatically Switched Optical Network (ASON) control plane 65 architecture as defined in [G.8080]. [ASON-RR] details the routing 66 requirements for the GMPLS suite of routing protocols to support the 67 capabilities and functionality of ASON control planes identified in 68 [G.7715] and in [G.7715.1]. 70 [ASON-EVAL] evaluates the IETF Link State Routing Protocols against 71 the requirements identified in [ASON-RR]. Candidate routing protocols 72 are IGP (OSPFv2 and IS-IS). This document details the OSPFv2 73 specifics for ASON routing. 75 ASON (Routing) terminology sections are provided in Appendix 1 and 2. 77 3. Reachability 79 In order to advertise blocks of reachable address prefixes a 80 summarization mechanism is introduced that complements the 81 techniques described in [OSPF-NODE]. 83 This extension takes the form of a network mask (a 32-bit number 84 indicating the range of IP addresses residing on a single IP 85 network/subnet). The set of local addresses are carried in an OSPFv2 86 TE LSA node attribute TLV (a specific sub-TLV is defined per address 87 family, e.g., IPv4 and IPv6). 89 The proposed solution is to advertise the local address prefixes of 90 a router as new sub-TLVs of the (OSPFv2 TE LSA) Node Attribute top 91 level TLV (of Type TBD). This document defines the following sub- 92 TLVs: 94 - Node IPv4 Local Prefix sub-TLV: Type 3 - Length: variable 95 - Node IPv6 Local Prefix sub-TLV: Type 4 - Length: variable 97 3.1 Node IPv4 local prefix sub-TLV 99 The node IPv4 local prefix sub-TLV has a type of 3 and contains one 100 or more local IPv4 prefixes. It has the following format: 102 D.Papadimitriou et al. - Expires December 2006 2 103 0 1 2 3 104 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 105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 106 | 3 | Length | 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 | Network Mask 1 | 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 | IPv4 Address 1 | 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 . . . 113 . . . 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 | Network Mask n | 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 117 | IPv4 Address n | 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 The length is set to 8 * n where n is the number of local prefixes 121 included in the sub-TLV. 123 Network mask: A 32-bit number indicating the IPv4 address mask 124 for the advertised destination prefix. 126 Each pair listed as part of this sub- 127 TLV represents a reachable destination prefix hosted by the 128 advertising Router ID. 130 The local addresses that can be learned from TE LSAs i.e. router 131 address and TE interface addresses SHOULD not be advertised in the 132 node IPv4 local prefix sub-TLV. 134 3.2 Node IPv6 local prefix sub-TLV 136 The node IPv6 local prefix sub-TLV has a type of 4 and contains one 137 or more local IPv6 prefixes. IPv6 Prefix Representation uses RFC 138 2740 Section A.4.1. It has the following format: 140 0 1 2 3 141 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 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | 4 | Length | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | PrefixLength | PrefixOptions | (0) | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | | 148 | IPv6 Address Prefix 1 | 149 | | 150 | | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 . . . 153 . . . 154 . . . 156 D.Papadimitriou et al. - Expires December 2006 3 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | PrefixLength | PrefixOptions | (0) | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | | 161 | IPv6 Address Prefix n | 162 | | 163 | | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 PrefixLength: length in bits of the prefix. 168 PrefixOptions: 8-bit field describing various capabilities 169 associated with the prefix (see [RFC2740] Section A.4.2). 171 Address Prefix: encoding of the prefix itself as an even multiple of 172 32-bit words, padding with zero bits as necessary. 174 The Length is set to Sum[n][4 + #32-bit words/4] where n is the 175 number of local prefixes included in the sub-TLV. 177 The local addresses that can be learned from TE LSAs i.e. router 178 address and TE interface addresses SHOULD not be advertised in the 179 node IPv6 local prefix sub-TLV. 181 4. Link Attribute 183 4.1 Local Adaptation 185 The Local Adaptation is defined as TE link attribute (i.e. sub-TLV) 186 that describes the cross/inter-layer relationships. 188 The Interface Switching Capability Descriptor (ISCD) TE Attribute 189 [RFC4202] identifies the ability of the TE link to support cross- 190 connection to another link within the same layer and the ability to 191 use a locally terminated connection that belongs to one layer as a 192 data link for another layer (adaptation capability). However, the 193 information associated to the ability to terminate connections 194 within that layer (referred to as the termination capability) is 195 embedded with the adaptation capability. 197 For instance, a link between two optical cross-connects will contain 198 at least one ISCD attribute describing LSC switching capability. 199 Whereas a link between an optical cross-connect and an IP/MPLS LSR 200 will contain at least two ISCD attributes: one for the description 201 of the LSC termination capability and one for the PSC adaptation 202 capability. 204 Note that per [RFC4202], an interface may have more than one ISCD 205 sub-TLV. Hence, the corresponding advertisements should not result 206 in any compatibility issue. 208 D.Papadimitriou et al. - Expires December 2006 4 209 In OSPFv2, the Interface Switching Capability Descriptor is a sub- 210 TLV (of type 15) of the top-level Link TLV (of type 2) [RFC4203]. 212 The adaptation and termination capabilities are advertised using two 213 separate ISCD sub-TLVs within the same top-level link TLV. 215 4.2 Technology Specific Bandwidth Accounting 217 GMPLS Routing defines an Interface Switching Capability Descriptor 218 (ISCD) that delivers among others the information about the 219 (maximum/minimum) bandwidth per priority an LSP can make use of. 221 In the ASON context, accounting on per timeslot basis using 32-bit 222 tuples of the form may optionally be incorporated in the 224 technology specific field of the ISCD TE link attribute when the 225 switching capability field is set to TDM value. When included, 226 format and encoding MUST follow the rules defined in [RFC4202]. 228 The purpose is purely informative: there is no mandatory processing 229 or topology/traffic-engineering significance associated to this 230 information. 232 In OSPF, the Interface Switching Capability Descriptor is a sub-TLV 233 (of type 15) of the Link TLV (of type 2). 235 5. Routing Information Scope 237 The Ri is a logical control plane entity that is associated to a 238 control plane "router". The latter is the source for topology 239 information that it generates and shares with other control plane 240 "routers". The Ri is identified by the (advertising) Router_ID. The 241 routing protocol MUST support a single Ri advertising on behalf of 242 more than one Li. Each Li is identified by a unique TE Router ID. 244 5.1 Link Advertisement (Local and Remote TE Router ID sub-TLV) 246 A Router_ID (Ri) advertising on behalf multiple TE Router_ID (Li's) 247 creates a 1:N relationship between the Router_ID and the TE 248 Router_ID. As the link local and link remote (unnumbered) ID 249 association is not unique per node (per Li unicity), the 250 advertisement needs to indicate the remote Lj value and rely on the 251 initial discovery process to retrieve the [Li;Lj] relationship. In 252 brief, as unnumbered links have their ID defined on per Li bases, 253 the remote Lj needs to be identified to scope the link remote ID to 254 the local Li. Therefore, the routing protocol MUST be able to 255 disambiguate the advertised TE links so that they can be associated 256 with the correct TE Router ID. 258 For this purpose, a new sub-TLV of the (OSPFv2 TE LSA) top level 259 Link TLV is introduced that defines the local and the remote 260 TE_Router_ID. 262 D.Papadimitriou et al. - Expires December 2006 5 263 The type of this sub-TLV is 17, and length is eight octets. The 264 value field of this sub-TLV contains four octets of Local TE Router 265 Identifier followed by four octets of Remote TE Router Identifier. 266 The value of the Remote TE Router Identifier SHOULD NOT be set to 0. 268 The format of this sub-TLV is the following: 270 0 1 2 3 271 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 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | 17 | Length | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | Local TE Router Identifier | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | Remote TE Router Identifier | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 This sub-TLV is optional and SHOULD only be included as part of the 281 top level Link TLV if the Router_ID is advertising on behalf of more 282 than one TE_Router_ID. In any other case, this sub-TLV SHOULD be 283 omitted. 285 Note: The Link ID sub-TLV that identifies the other end of the link 286 (i.e. Router ID of the neighbor for point-to-point links) MUST 287 appear exactly once per Link TLV. 289 5.2 Reachability Advertisement (Local TE Router ID sub-TLV) 291 When the Router_ID advertises on behalf of multiple TE Router_IDs, 292 the routing protocol MUST be able to associate the advertised 293 reachability information with the correct TE Router ID. 295 For this purpose, a new sub-TLV of the (OSPFv2 TE LSA) top level 296 Node Attribute TLV is introduced. This TLV associates the local 297 prefixes (sub-TLV 3 and 4, see above) to a given TE Router_ID. 299 The type of this sub-TLV is 5, and length is four octets. The value 300 field of this sub-TLV contains four octets of Local TE Router 301 Identifier [RFC3630]. 303 The format of this sub-TLV is the following: 305 0 1 2 3 306 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 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | 5 | Length | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | Local TE Router Identifier | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 D.Papadimitriou et al. - Expires December 2006 6 314 This sub-TLV is optional and SHOULD only be included as part of the 315 Node Attribute TLV if the Router_ID is advertising on behalf of more 316 than one TE_Router_ID. In any other case, this sub-TLV SHOULD be 317 omitted. 319 6. Routing Information Dissemination 321 RC disseminates downward/upward the hierarchy by re-originating this 322 routing information as Opaque TE LSA (Opaque Type 1) of LS Type 10. 324 The information that MAY be exchanged between adjacent levels 325 includes the Router_Address, Link and Node_Attribute top level TLV. 327 The Opaque TE LSA re-origination is governed as follows: 328 - If the target interface is associated to the same area as the 329 one associated with the receiving interface, the Opaque LSA MUST 330 NOT be re-originated out that interface. 331 - If a match is found between the Advertising Router ID in the 332 header of the received Opaque TE LSA and one of the Router ID 333 belonging to the area of the target interface, the Opaque LSA MUST 334 NOT be re-originated out that interface. 335 - If these two conditions are not met the Opaque TE LSA MAY be re- 336 originated. 338 The re-originated content MAY be transformed e.g. filtered, as long 339 as the resulting routing information is consistent. In particular, 340 when more than one RC are bound to adjacent levels and both are 341 allowed to redistribute routing information it is expected that 342 these transformation are performed in consistent manner. Definition 343 of these policy mechanisms is outside the scope of this document. 345 In practice, and in order to avoid scalability and processing 346 overhead, routing information re-distributed downward/upward the 347 hierarchy is expected to include reachability information (see 348 Section 3) and upon strict policy control link topology information. 350 6.1 Discovery and Selection 352 In order to discover RCs that are capable to disseminate routing 353 information upward the routing hierarchy, the following Capability 354 Descriptor bit [OSPF-CAP] are defined: 356 - U bit: when set, this flag indicates that the RC is capable to 357 disseminate routing information upward the adjacent level. 359 In case of multiple RC are advertized with their U bit set, the RC 360 with the highest Router ID, among the RCs having set the U bit, 361 SHOULD be selected as the RC for upward dissemination of routing 362 information. The other RCs MUST NOT participate in the upward 363 dissemination of routing information as long as the opaque LSA 364 information corresponding to the highest Router ID RC does not reach 366 D.Papadimitriou et al. - Expires December 2006 7 367 MaxAge. This mechanism prevents from having more than one RC 368 advertizing routing information upward the routing hierarchy. 370 Note that alternatively if this information cannot be discovered 371 automatically, it MUST be manually configured. 373 The same discovery - not election - mechanism is used for selecting 374 the RC taking in charge dissemination of routing information 375 downward the hierarchy. However, an additional restriction MUST be 376 applied such that the RC selection process takes into account that 377 an upper level may be adjacent to one or more lower levels. For this 378 purpose a specific TLV indexing the (lower) area ID to which the 379 RC's are capable to disseminate routing information is needed. 381 OSPF Associated Area ID TLV format carried in the OSPF router 382 information LSA [OSPF-CAP] is defined. This TLV has the following 383 format: 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 | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Associated Area ID | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 Type (16 bits): identifies the TLV type 394 Length (16 bits): length of the value field in octets 395 Value (32 bits): Associated Area ID whose value space is the Area ID 396 as defined in [RFC2328]. 398 Note that this information MUST be present when the D bit is set. To 399 discover RCs that are capable to disseminate routing information 400 downward the routing hierarchy, the following Capability Descriptor 401 bit [OSPF-CAP] is defined, that MUST be advertised together with the 402 OSPF Area ID TLV: 404 - D bit: when set, this flag indicates that the RC is capable to 405 disseminate routing information downward the adjacent level. 407 In case of multiple supporting RCs for the same Associated Area ID, 408 the RC with the highest Router ID, among the RCs having set the D 409 bit, MUST be selected as the RC for downward dissemination of 410 routing information. The other RCs for the same Associated Area ID 411 MUST not participate in the downward dissemination of routing 412 information as long as the opaque LSA information corresponding to 413 the highest Router ID RC does not reach MaxAge. This mechanism 414 prevents from having more than one RC advertizing routing 415 information downward the routing hierarchy. 417 Note that alternatively if this information cannot be discovered 418 automatically, it MUST be manually configured. 420 D.Papadimitriou et al. - Expires December 2006 8 421 The OSPF Router information opaque LSA (opaque type of 4, opaque ID 422 of 0) and its content in particular, the Router Informational 423 Capabilities TLV [OSPF-CAP] and TE Node Capability Descriptor TLV 424 [OSPF-TE-CAP] MUST NOT be re-originated. 426 6.2 Loop prevention 428 When more than one RC are bound to adjacent levels of the hierarchy, 429 configured and selected to redistribute upward and downward the 430 routing information, a specific mechanism is required to avoid 431 looping/re-introduction of routing information back to the upper 432 level. This specific case occurs when the RC advertizing routing 433 information downward the hierarchy is not the one advertizing 434 routing upward the hierarchy (or vice-versa). 436 In all other cases, the procedure described in this section SHOULD 437 NOT be applied. 439 When these conditions are met, it is necessary to have a mean by 440 which an RC receiving an Opaque TE LSA re-originated downward by an 441 RC associated to the same area omits to re-originate back the 442 content of this LSA upward into the (same) upper level. 444 6.2.1 Associated Area ID 446 Thus we need some way of filtering the downward/onward re-originated 447 Opaque TE LSA. Per [RFC2370], the information contained in Opaque 448 LSAs may be used directly by OSPF. Henceforth, by adding the Area ID 449 associated to the incoming routing information the loop prevention 450 problem can be solved. This additional information carried in opaque 451 LSAs including the Router Address TLV, opaque LSAs including the 452 Link TLV, and opaque LSAs including the Node Attribute TLV is 453 referred to as the Associated Area ID. 455 The format of the Associated Area ID TLV is defined as follows: 457 0 1 2 3 458 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 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | Type | Length | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | Associated Area ID | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 Type (16 bits): identifies the TLV type 466 Length (16 bits): length of the value field in octets 467 Value (32 bits): Associated Area ID whose value space is the Area ID 468 as defined in [RFC2328]. 470 6.2.2 Processing 472 D.Papadimitriou et al. - Expires December 2006 9 473 When fulfilling the rules detailed in Section 6.0 a given Opaque LSA 474 is re-originated downward or upward the routing hierarchy, the 475 Associated Area ID TLV is added to the received opaque LSA list of 476 TLVs such as to identify the area from where this routing 477 information has been received. 479 When the RC adjacent to the lower or upper level routing level 480 receives this opaque LSA, the following rule is applied (in addition 481 the rule governing the re-origination of opaque LSAs as detailed in 482 Section 6.0). 484 - If a match is found between the Associated Area ID of the received 485 Opaque TE LSA and the Area ID belonging to the area of the target 486 interface, the Opaque LSA MUST NOT be re-originated out that 487 interface. 489 - Otherwise, this opaque LSA MAY be originated downward or upward 490 the routing hierarchy. 492 This mechanism ensures that no race condition occurs in the 493 following conditions for instance: 495 RC_5 ---------- RC_6 496 | | Area Y 497 | | 498 ========== RC_1 ========== RC_2 ========== 499 | | 500 | | Area X 501 RC_3 --- .. --- RC_4 503 Assume that RC_1 is configured for exchanging routing information 504 upward toward Area Y (upward the routing hierarchy) and that RC_2 is 505 configured for exchanging routing information toward Area X 506 (downward the routing hierarchy). 508 Assumes that RC_3 advertized routing information would reach faster 509 to RC_4 across Area Y. 511 If RC_2 is not able to prevent from re-originating that information, 512 RC_4 may receive that information before the same advertisement 513 would propagate to RC_4. 515 7. OSPFv2 Extensions 517 7.1 Compatibility 519 Extensions specified in this document are associated to the 521 Opaque TE LSA: 523 o) Router Address top level TLV (Type 1): 524 - Associated Area ID sub-TLV: optional sub-TLV for loop avoidance 526 D.Papadimitriou et al. - Expires December 2006 10 527 (see Section 6.2) 529 o) Link top level TLV (Type 2): 530 - Local and Remote TE Router ID sub-TLV: optional sub-TLV for 531 scoping link attributes per TE_Router ID 532 - Associated Area ID sub-TLV: optional sub-TLV for loop avoidance 533 (see Section 6.2) 535 o) Node Attribute top level TLV (Type TBD): 536 - Node IPv4 Local Prefix sub-TLVs: optional sub-TLV for IPv4 537 reachability advertisement 538 - Node IPv6 Local Prefix sub-TLVs: optional sub-TLV for IPv6 539 reachability advertisement 540 - Local TE Router ID sub-TLV: optional sub-TLV for scoping 541 reachability per TE_Router ID 542 - Associated Area ID sub-TLV: optional sub-TLV for loop avoidance 543 (see Section 6.2) 545 Opaque RI LSA: 547 o) Routing information dissemination 548 - U and D bit in Capability Descriptor TLV [OSPF-CAP] 549 - Associated Area ID TLV in the OSPF Routing Information LSA 550 [OSPF-CAP] 552 7.2 Scalability 554 o) Routing information exchange upward/downward the hierarchy 555 between adjacent areas SHOULD by default be limited to reachability. 556 In addition, several transformation such as prefix aggregation are 557 recommended when allowing decreasing the amount of information re- 558 originated by a given RC without impacting consistency. 560 o) Routing information exchange upward/downward the hierarchy when 561 involving TE attributes MUST be under strict policy control. Pacing 562 and min/max thresholds for triggered updates are strongly 563 recommended. 565 8. Acknowledgements 567 The authors would like to thank Pandian Vijay, Alan Davey and Adrian 568 Farrel for their useful comments and suggestions. 570 9. References 572 9.1 Normative References 574 [OSPF-NODE] R.Aggarwal, and K.Kompella, "Advertising a Router's 575 Local Addresses in OSPF TE Extensions," Internet Draft, 576 (work in progress), draft-ietf-ospf-te-node-addr- 577 02.txt, March 2005. 579 D.Papadimitriou et al. - Expires December 2006 11 581 [RFC2026] S.Bradner, "The Internet Standards Process -- 582 Revision 3", BCP 9, RFC 2026, October 1996. 584 [RFC2328] J.Moy, "OSPF Version 2", RFC 2328, April 1998. 586 [RFC2370] R.Coltun, "The OSPF Opaque LSA Option", RFC 2370, July 587 1998. 589 [RFC2740] R.Coltun et al. "OSPF for IPv6", RFC 2740, December 590 1999. 592 [RFC2119] S.Bradner, "Key words for use in RFCs to Indicate 593 Requirement Levels", BCP 14, RFC 2119, March 1997. 595 [RFC3477] K.Kompella et al. "Signalling Unnumbered Links in 596 Resource ReSerVation Protocol - Traffic Engineering 597 (RSVP-TE)", RFC 3477, January 2003. 599 [RFC3630] D.Katz et al. "Traffic Engineering (TE) Extensions to 600 OSPF Version 2", RFC 3630, September 2003. 602 [RFC3667] S.Bradner, "IETF Rights in Contributions", BCP 78, 603 RFC 3667, February 2004. 605 [RFC3668] S.Bradner, Ed., "Intellectual Property Rights in IETF 606 Technology", BCP 79, RFC 3668, February 2004. 608 [RFC3946] E.Mannie, and D.Papadimitriou, (Editors) et al., 609 "Generalized Multi-Protocol Label Switching Extensions 610 for SONET and SDH Control," RFC 3946, October 2004. 612 [RFC4202] Kompella, K. (Editor) et al., "Routing Extensions in 613 Support of Generalized MPLS," RFC 4202, October 2005. 615 [RFC4203] Kompella, K. (Editor) et al., "OSPF Extensions in 616 Support of Generalized Multi-Protocol Label Switching 617 (GMPLS)," RFC 4203, October 2005. 619 8.2 Informative References 621 [ASON-EVAL] C.Hopps et al. "Evaluation of existing Routing Protocols 622 against ASON Routing Requirements", Work in progress, 623 draft-ietf-ccamp-gmpls-ason-routing-eval-03.txt, May 624 2006. 626 [ASON-RR] D.Brungard et al. "Requirements for Generalized MPLS 627 (GMPLS) Routing for Automatically Switched Optical 628 Network (ASON)," RFC 4258, November 2005. 630 [OSPF-CAP] A.Lindem et al. "Extensions to OSPF for Advertising 631 Optional Router Capabilities", Work in progress, draft- 632 ietf-ospf-cap-08.txt, November 2005. 634 D.Papadimitriou et al. - Expires December 2006 12 636 [OSPF-TE-CAP]J.P. Vasseur et al. , "Routing extensions for discovery 637 of Traffic Engineering Node Capabilities", Work in 638 progress, draft-ietf-ccamp-te-node-cap-01.txt, June 2006 640 For information on the availability of ITU Documents, please see 641 http://www.itu.int 643 [G.7715] ITU-T Rec. G.7715/Y.1306, "Architecture and 644 Requirements for the Automatically Switched Optical 645 Network (ASON)," June 2002. 647 [G.7715.1] ITU-T Draft Rec. G.7715.1/Y.1706.1, "ASON Routing 648 Architecture and Requirements for Link State Protocols," 649 November 2003. 651 [G.8080] ITU-T Rec. G.8080/Y.1304, "Architecture for the 652 Automatically Switched Optical Network (ASON)," 653 November 2001 (and Revision, January 2003). 655 9. Author's Addresses 657 Dimitri Papadimitriou (Alcatel) 658 Francis Wellensplein 1, 659 B-2018 Antwerpen, Belgium 660 Phone: +32 3 2408491 661 EMail: dimitri.papadimitriou@alcatel.be 663 D.Papadimitriou et al. - Expires December 2006 13 664 Appendix 1: ASON Terminology 666 This document makes use of the following terms: 668 Administrative domain: (see Recommendation G.805) for the purposes of 669 [G7715.1] an administrative domain represents the extent of resources 670 which belong to a single player such as a network operator, a service 671 provider, or an end-user. Administrative domains of different players 672 do not overlap amongst themselves. 674 Control plane: performs the call control and connection control 675 functions. Through signaling, the control plane sets up and releases 676 connections, and may restore a connection in case of a failure. 678 (Control) Domain: represents a collection of (control) entities that 679 are grouped for a particular purpose. The control plane is subdivided 680 into domains matching administrative domains. Within an 681 administrative domain, further subdivisions of the control plane are 682 recursively applied. A routing control domain is an abstract entity 683 that hides the details of the RC distribution. 685 External NNI (E-NNI): interfaces are located between protocol 686 controllers between control domains. 688 Internal NNI (I-NNI): interfaces are located between protocol 689 controllers within control domains. 691 Link: (see Recommendation G.805) a "topological component" which 692 describes a fixed relationship between a "subnetwork" or "access 693 group" and another "subnetwork" or "access group". Links are not 694 limited to being provided by a single server trail. 696 Management plane: performs management functions for the Transport 697 Plane, the control plane and the system as a whole. It also provides 698 coordination between all the planes. The following management 699 functional areas are performed in the management plane: performance, 700 fault, configuration, accounting and security management 702 Management domain: (see Recommendation G.805) a management domain 703 defines a collection of managed objects which are grouped to meet 704 organizational requirements according to geography, technology, 705 policy or other structure, and for a number of functional areas such 706 as configuration, security, (FCAPS), for the purpose of providing 707 control in a consistent manner. Management domains can be disjoint, 708 contained or overlapping. As such the resources within an 709 administrative domain can be distributed into several possible 710 overlapping management domains. The same resource can therefore 711 belong to several management domains simultaneously, but a management 712 domain shall not cross the border of an administrative domain. 714 Subnetwork Point (SNP): The SNP is a control plane abstraction that 715 represents an actual or potential transport plane resource. SNPs (in 717 D.Papadimitriou et al. - Expires December 2006 14 718 different subnetwork partitions) may represent the same transport 719 resource. A one-to-one correspondence should not be assumed. 721 Subnetwork Point Pool (SNPP): A set of SNPs that are grouped together 722 for the purposes of routing. 724 Termination Connection Point (TCP): A TCP represents the output of a 725 Trail Termination function or the input to a Trail Termination Sink 726 function. 728 Transport plane: provides bi-directional or unidirectional transfer 729 of user information, from one location to another. It can also 730 provide transfer of some control and network management information. 731 The Transport Plane is layered; it is equivalent to the Transport 732 Network defined in G.805 Recommendation. 734 User Network Interface (UNI): interfaces are located between protocol 735 controllers between a user and a control domain. Note: there is no 736 routing function associated with a UNI reference point. 738 D.Papadimitriou et al. - Expires December 2006 15 739 Appendix 2: ASON Routing Terminology 741 This document makes use of the following terms: 743 Routing Area (RA): a RA represents a partition of the data plane and 744 its identifier is used within the control plane as the representation 745 of this partition. Per [G.8080] a RA is defined by a set of sub- 746 networks, the links that interconnect them, and the interfaces 747 representing the ends of the links exiting that RA. A RA may contain 748 smaller RAs inter-connected by links. The limit of subdivision 749 results in a RA that contains two sub-networks interconnected by a 750 single link. 752 Routing Database (RDB): repository for the local topology, network 753 topology, reachability, and other routing information that is updated 754 as part of the routing information exchange and may additionally 755 contain information that is configured. The RDB may contain routing 756 information for more than one Routing Area (RA). 758 Routing Components: ASON routing architecture functions. These 759 functions can be classified as protocol independent (Link Resource 760 Manager or LRM, Routing Controller or RC) and protocol specific 761 (Protocol Controller or PC). 763 Routing Controller (RC): handles (abstract) information needed for 764 routing and the routing information exchange with peering RCs by 765 operating on the RDB. The RC has access to a view of the RDB. The RC 766 is protocol independent. 768 Note: Since the RDB may contain routing information pertaining to 769 multiple RAs (and possibly to multiple layer networks), the RCs 770 accessing the RDB may share the routing information. 772 Link Resource Manager (LRM): supplies all the relevant component and 773 TE link information to the RC. It informs the RC about any state 774 changes of the link resources it controls. 776 Protocol Controller (PC): handles protocol specific message exchanges 777 according to the reference point over which the information is 778 exchanged (e.g. E-NNI, I-NNI), and internal exchanges with the RC. 779 The PC function is protocol dependent. 781 D.Papadimitriou et al. - Expires December 2006 16 782 Full Copyright Statement 784 Copyright (C) The Internet Society (2006). This document is subject 785 to the rights, licenses and restrictions contained in BCP 78, and 786 except as set forth therein, the authors retain all their rights. 788 This document and the information contained herein are provided on 789 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 790 REPRESENTSOR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 791 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 792 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 793 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 794 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 796 Intellectual Property 798 The IETF takes no position regarding the validity or scope of any 799 Intellectual Property Rights or other rights that might be claimed 800 to pertain to the implementation or use of the technology described 801 in this document or the extent to which any license under such 802 rights might or might not be available; nor does it represent that 803 it has made any independent effort to identify any such rights. 804 Information on the procedures with respect to rights in RFC 805 documents can be found in BCP 78 and BCP 79. 807 Copies of IPR disclosures made to the IETF Secretariat and any 808 assurances of licenses to be made available, or the result of an 809 attempt made to obtain a general license or permission for the use 810 of such proprietary rights by implementers or users of this 811 specification can be obtained from the IETF on-line IPR repository 812 at http://www.ietf.org/ipr. 814 The IETF invites any interested party to bring to its attention any 815 copyrights, patents or patent applications, or other proprietary 816 rights that may cover technology that may be required to implement 817 this standard. Please address the information to the IETF at ietf- 818 ipr@ietf.org. 820 D.Papadimitriou et al. - Expires December 2006 17