idnits 2.17.1 draft-dimitri-ccamp-gmpls-ason-routing-sol-01.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 957. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 964. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 970. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 938), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** 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 19 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 'SHOULD not' in this paragraph: For opaque LSAs including the Node Attribute TLV, if one of the included prefixes has been already installed into the TEDB, the LSA should not be re-originated with that prefix since the corresponding reachable end-points belonging to a router part of the target area. If no prefix remains, the LSA SHOULD not be re-originated. -- 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 (March 2006) is 6616 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: 'RFC4203' is mentioned on line 287, but not defined == Missing Reference: 'RFC4205' is mentioned on line 296, but not defined ** Obsolete undefined reference: RFC 4205 (Obsoleted by RFC 5307) == Missing Reference: 'OSPF-TE-CAP' is mentioned on line 707, but not defined == Missing Reference: 'OSPF-CAP' is mentioned on line 709, but not defined == Missing Reference: 'ISIS-TE-CAP' is mentioned on line 644, but not defined == Missing Reference: 'ISIS-CAP' is mentioned on line 661, but not defined == Unused Reference: 'RFC2026' is defined on line 744, but no explicit reference was found in the text == Unused Reference: 'RFC3477' is defined on line 755, but no explicit reference was found in the text == Unused Reference: 'RFC3667' is defined on line 762, but no explicit reference was found in the text == Unused Reference: 'RFC3668' is defined on line 765, but no explicit reference was found in the text == Unused Reference: 'RFC3946' is defined on line 772, 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 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 3784 (Obsoleted by RFC 5305) ** Obsolete normative reference: RFC 3946 (Obsoleted by RFC 4606) ** Downref: Normative reference to an Proposed Standard RFC: RFC 4202 == Outdated reference: A later version (-03) exists of draft-ietf-ccamp-gmpls-ason-routing-eval-02 Summary: 17 errors (**), 0 flaws (~~), 18 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: August 2006 March 2006 8 Link State Routing Protocols Extensions for ASON Routing 10 draft-dimitri-ccamp-gmpls-ason-routing-sol-01.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). All Rights Reserved. 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 IETF Link State Routing 47 Protocols to meet the routing requirements for an Automatically 48 Switched Optical Network (ASON) as defined by ITU-T. 50 D.Papadimitriou et al. - Expires August 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). 74 ASON (Routing) terminology sections are provided in Appendix 1 and 2. 76 3. Reachability 78 3.1 OSPFv2 80 In order to advertise blocks of reachable address prefixes a 81 summarization mechanism is introduced that complements the 82 techniques described in [OSPF-NODE]. 84 This extension takes the form of a network mask (a 32-bit number 85 indicating the range of IP addresses residing on a single IP 86 network/subnet). The set of local addresses are carried in an OSPF 87 TE LSA node attribute TLV (a specific sub-TLV is defined per address 88 family, e.g., IPv4 and IPv6). 90 The proposed solution is to advertise the local address prefixes of 91 a router as new sub-TLVs of the (OSPFv2 TE LSA) Node Attribute top 92 level TLV (of Type TBD). This document defines the following sub- 93 TLVs: 95 - Node IPv4 Local Prefix sub-TLV: Type 3 - Length: variable 96 - Node IPv6 Local Prefix sub-TLV: Type 4 - Length: variable 98 3.1.1 Node IPv4 local prefix sub-TLV 100 The node IPv4 local prefix sub-TLV has a type of 3 and contains one 101 or more local IPv4 prefixes. It has the following format: 103 D.Papadimitriou et al. - Expires August 2006 2 104 0 1 2 3 105 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 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 | 3 | Length | 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 109 | Network Mask 1 | 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 | IPv4 Address 1 | 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 . . . 114 . . . 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 | Network Mask n | 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 | IPv4 Address n | 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 The length is set to 8 * n where n is the number of local prefixes 122 included in the sub-TLV. 124 Network mask: A 32-bit number indicating the IPv4 address mask 125 for the advertised destination prefix. 127 Each pair listed as part of this sub- 128 TLV represents a reachable destination prefix hosted by the 129 advertising Router ID. 131 The local addresses that can be learned from TE LSAs i.e. router 132 address and TE interface addresses SHOULD not be advertised in the 133 node IPv4 local prefix sub-TLV. 135 3.1.2 Node IPv6 local prefix sub-TLV 137 The node IPv6 local prefix sub-TLV has a type of 4 and contains one 138 or more local IPv6 prefixes. IPv6 Prefix Representation uses RFC 139 2740 Section A.4.1. It has the following format: 141 0 1 2 3 142 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 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | 4 | Length | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | PrefixLength | PrefixOptions | (0) | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | | 149 | IPv6 Address Prefix 1 | 150 | | 151 | | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 . . . 154 . . . 156 D.Papadimitriou et al. - Expires August 2006 3 157 . . . 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | PrefixLength | PrefixOptions | (0) | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | | 162 | IPv6 Address Prefix n | 163 | | 164 | | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 PrefixLength: length in bits of the prefix. 169 PrefixOptions: 8-bit field describing various capabilities 170 associated with the prefix (see [RFC2740] Section A.4.2). 172 Address Prefix: encoding of the prefix itself as an even multiple of 173 32-bit words, padding with zero bits as necessary. 175 The Length is set to Sum[n][4 + #32-bit words/4] where n is the 176 number of local prefixes included in the sub-TLV. 178 The local addresses that can be learned from TE LSAs i.e. router 179 address and TE interface addresses SHOULD not be advertised in the 180 node IPv6 local prefix sub-TLV. 182 3.2 IS-IS 184 A similar mechanism does not exist for IS-IS as the Extended IP 185 Reachability TLV [RFC3784] focuses on IP reachable end-points 186 (terminating points), as its name indicates. 188 For this purpose, a new Extended TE Reachability TLV (Type TBD) is 189 defined as follows 191 7 octets of system Id and pseudonode number 192 1 octet of length of sub-TLVs 193 0-246 octets of sub-TLVs, 194 where each sub-TLV consists of a sequence of 195 1 octet of sub-type 196 1 octet of length of the value field of the sub-TLV 197 0-244 octets of value 199 Each sub-TLV (Type TBD) is either an IPv4 TE Reachability sub-TLV or 200 an IPv6 TE Reachability sub-TLV. 202 3.2.1 IPv4 TE Reachability sub-TLV 204 The "IPv4 TE Reachability" sub-TLV describes TE reachability through 205 the specification of a routing prefix, a bit to indicate if the 206 prefix is being advertised down from a higher level, and optionally 207 the existence of sub-TLVs to allow for later extension. The 208 following illustrates encoding of the Value field of this sub-TLV 210 D.Papadimitriou et al. - Expires August 2006 4 211 0 1 2 3 212 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 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 |U| Reserved | Prefix Len| Prefix | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Prefix | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 The 6 bits of prefix length can have the values 0-32 and indicate 220 the number of significant bits in the prefix. The prefix is encoded 221 in the minimal number of octets for the given number of significant 222 bits. The remaining bits of prefix are transmitted as zero and 223 ignored upon receipt. 225 The U bit is described in Section 6.2. 227 3.2.2 IPv6 TE Reachability sub-TLV 229 The "IPv6 TE Reachability" sub-TLV describes TE reachability through 230 the specification of a routing prefix, a bit to indicate if the 231 prefix is being advertised down from a higher level, and optionally 232 the existence of sub-TLVs to allow for later extension. The 233 following illustrates encoding of the Value field of this sub-TLV 235 0 1 2 3 236 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 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 |U| Reserved | Prefix Len | Prefix | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | | 241 ~ Prefix ~ 242 | | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Prefix ... | 245 +-+-+-+-+-+-+-+-+ 247 The 8 bits of prefix length can have the values 0-128 and indicate 248 the number of significant bits in the prefix. Only the required 249 number of octets of prefix are present. This number can be computed 250 from the prefix length octet as follows: 252 prefix octets = integer of ((prefix length + 7) / 8) 254 The U bit is described in Section 6.2. 256 4. Link Attribute 258 4.1 Local Adaptation 260 The Local Adaptation is defined as TE link attribute (i.e. sub-TLV) 261 that describes the cross/inter-layer relationships. 263 D.Papadimitriou et al. - Expires August 2006 5 264 The Interface Switching Capability Descriptor (ISCD) TE Attribute 265 [RFC4202] identifies the ability of the TE link to support cross- 266 connection to another link within the same layer and the ability to 267 use a locally terminated connection that belongs to one layer as a 268 data link for another layer (adaptation capability). However, the 269 information associated to the ability to terminate connections 270 within that layer (referred to as the termination capability) is 271 embedded with the adaptation capability. 273 For instance, a link between two optical cross-connects will contain 274 at least one ISCD attribute describing LSC switching capability. 275 Whereas a link between an optical cross-connect and an IP/MPLS LSR 276 will contain at least two ISCD attributes: one for the description 277 of the LSC termination capability and one for the PSC adaptation 278 capability. 280 Note that per [RFC4202], an interface may have more than one ISCD 281 sub-TLV. Hence, the corresponding advertisements should not result 282 in any compatibility issue. 284 4.1.2 OSPFv2 286 In OSPFv2, the Interface Switching Capability Descriptor is a sub- 287 TLV (of type TBA) of the Link TLV (of type 2) [RFC4203]. 289 The adaptation and termination capabilities are advertised using two 290 separate ISCD sub-TLVs within the same top-level link TLV. 292 4.1.2 IS-IS 294 In IS-IS, the Interface Adaptation Capability Descriptor is a sub- 295 TLV (of type TBA) of the Extended IS Reachability TLV (of type 22) 296 [RFC4205]. 298 The adaptation and termination capabilities are advertised using two 299 separate ISCD sub-TLVs within the same Extended IS Reachability TLV. 301 4.2 Technology Specific Bandwidth Accounting 303 GMPLS Routing defines an Interface Switching Capability Descriptor 304 (ISCD) that delivers among others the information about the 305 (maximum/minimum) bandwidth per priority an LSP can make use of. 307 In the ASON context, accounting on per timeslot basis using 32-bit 308 tuples of the form may optionally be incorporated in the 310 technology specific field of the ISCD TE link attribute when the 311 switching capability field is set to TDM value. When included, 312 format and encoding MUST follow the rules defined in [RFC4202]. 314 D.Papadimitriou et al. - Expires August 2006 6 315 The purpose is purely informative: there is no mandatory processing 316 or topology/traffic-engineering significance associated to this 317 information. 319 4.2.1 OSPFv2 321 In OSPF, the Interface Switching Capability Descriptor is a sub-TLV 322 (of type 15) of the Link TLV (of type 2). 324 4.2.2 IS-IS 326 In IS-IS, the Interface Switching Capability Descriptor is a sub-TLV 327 (of type 21) of the Extended IS Reachability TLV (of type 22). 329 5. Routing Information Scope 331 The Ri is a logical control plane entity that is associated to a 332 control plane "router". The latter is the source for topology 333 information that it generates and shares with other control plane 334 "routers". The Ri is identified by the (advertising) Router_ID. The 335 routing protocol MUST support a single Ri advertising on behalf of 336 more than one Li. Each Li is identified by a unique TE Router ID. 338 5.1 Link Advertisement (Local and Remote TE Router ID sub-TLV) 340 A Router_ID (Ri) advertising on behalf multiple TE Router_ID (Li's) 341 creates a 1:N relationship between the Router_ID and the TE 342 Router_ID. As the link local and link remote (unnumbered) ID 343 association is not unique per node (per Li unicity), the 344 advertisement needs to indicate the remote Lj value and rely on the 345 initial discovery process to retrieve the [Li;Lj] relationship. In 346 brief, as unnumbered links have their ID defined on per Li bases, 347 the remote Lj needs to be identified to scope the link remote ID to 348 the local Li. Therefore, the routing protocol MUST be able to 349 disambiguate the advertised TE links so that they can be associated 350 with the correct TE Router ID. 352 5.1.1 OSPFv2 354 For this purpose, a new sub-TLV of the (OSPFv2 TE LSA) top level 355 Link TLV is introduced that defines the local and the remote 356 TE_Router_ID. 358 The type of this sub-TLV is 17, and length is eight octets. The 359 value field of this sub-TLV contains four octets of Local TE Router 360 Identifier followed by four octets of Remote TE Router Identifier. 361 The value of the Remote TE Router Identifier SHOULD NOT be set to 0. 363 The format of this sub-TLV is the following: 365 0 1 2 3 366 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 368 D.Papadimitriou et al. - Expires August 2006 7 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | 17 | Length | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | Local TE Router Identifier | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | Remote TE Router Identifier | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 This sub-TLV is optional and SHOULD only be included as part of the 378 top level Link TLV if the Router_ID is advertising on behalf of more 379 than one TE_Router_ID. In any other case, this sub-TLV SHOULD be 380 omitted. 382 Note: The Link ID sub-TLV that identifies the other end of the link 383 (i.e. Router ID of the neighbor for point-to-point links) MUST 384 appear exactly once per Link TLV. 386 5.1.2 IS-IS 388 For this purpose, a new sub-TLV of the Extended IS Reachability TLV 389 (Type 22, RFC 3784) is introduced that defines the local and the 390 remote TE_Router_ID. 392 The type of this sub-TLV is TBD, and length is eight octets. The 393 value field of this sub-TLV contains four octets of Local TE Router 394 Identifier followed by four octets of Remote TE Router Identifier. 395 The value of the Remote TE Router Identifier SHOULD NOT be set to 0. 397 The format of the value field of this sub-TLV is the following: 399 0 1 2 3 400 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 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Local TE Router Identifier | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | Remote TE Router Identifier | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 This sub-TLV is optional and SHOULD only be included as part of the 408 Extended IS Reachability TLV if the RC is advertising on behalf of 409 more than one TE_Router_ID. In any other case, this sub-TLV SHOULD 410 be omitted. 412 5.2 Reachability Advertisement (Local TE Router ID sub-TLV) 414 When the Router_ID advertises on behalf of multiple TE Router_IDs, 415 the routing protocol MUST be able to associate the advertised 416 reachability information with the correct TE Router ID. 418 5.2.1 OSPFv2 420 D.Papadimitriou et al. - Expires August 2006 8 421 For this purpose, a new sub-TLV of the (OSPFv2 TE LSA) top level 422 Node Attribute TLV is introduced. This TLV associates the local 423 prefixes (sub-TLV 3 and 4, see above) to a given TE Router_ID. 425 The type of this sub-TLV is 5, and length is four octets. The value 426 field of this sub-TLV contains four octets of Local TE Router 427 Identifier [RFC3630]. 429 The format of this sub-TLV is the following: 431 0 1 2 3 432 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 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | 5 | Length | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | Local TE Router Identifier | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 This sub-TLV is optional and SHOULD only be included as part of the 440 Node Attribute TLV if the Router_ID is advertising on behalf of more 441 than one TE_Router_ID. In any other case, this sub-TLV SHOULD be 442 omitted. 444 5.2.2 IS-IS 446 For this purpose, a new sub-TLV of the newly defined Extended TE 447 Reachability TLV is introduced that defines the local TE_Router_ID. 449 The type of this sub-TLV is TBD, and length is four octets. The 450 value field of this sub-TLV contains four octets of Local TE Router 451 Identifier [RFC3784]. 453 The format of the value field of this sub-TLV is the following: 455 0 1 2 3 456 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 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | Local TE Router Identifier | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 This sub-TLV is optional and SHOULD only be included as part of the 462 Extended TE Reachability TLV if the RC is advertising on behalf of 463 more than one TE_Router_ID. In any other case, this sub-TLV SHOULD 464 be omitted. 466 6. Routing Information Dissemination 468 6.1 OSPFv2 470 RC disseminates downward/upward the hierarchy by re-originating this 471 routing information as Opaque TE LSA (Opaque Type 1) of LS Type 10. 473 D.Papadimitriou et al. - Expires August 2006 9 474 The information that MAY be exchanged between adjacent levels 475 includes the Router_Address, Link and Node_Attribute top level TLV. 477 The Opaque TE LSA re-origination is governed as follows: 478 - If the target interface is associated to the same area than the 479 one associated with the receiving interface, the Opaque LSA MUST 480 NOT be re-originated out that interface. 481 - If a match is found between the Advertising Router ID in the 482 received Opaque TE LSA and one of the Router ID belonging to the 483 area of the target interface, the Opaque LSA MUST NOT be re- 484 originated out that interface. 485 - If these two conditions are met the Opaque TE LSA MAY be re- 486 originated. 488 The re-originated content MAY be transformed e.g. filtered, as long 489 as the resulting routing information is consistent. In particular, 490 when than one RC are bound to adjacent levels and both allowed to 491 redistribute routing information it is expected that these 492 transformation are performed in consistent manner. Definition of 493 these policy mechanisms is outside the scope of this document. 495 In practice, and in order to avoid scalability and processing 496 overhead, routing information re-distributed downward/upward the 497 hierarchy is expected to include reachability information (see 498 Section 3.1) and upon strict policy control link topology 499 information. 501 6.1.1 Discovery and Selection 503 In order to discover RCs that are capable to disseminate routing 504 information upward the routing hierarchy, the following Capability 505 Descriptor bit [OSPF-TE-CAP] are defined: 507 - U bit: when set, this flag indicates that the RC is capable to 508 disseminate routing information upward the adjacent level. 510 In case of multiple supporting RCs, the RC with the highest Router 511 ID SHOULD be selected. More precisely, the RC with the highest 512 Router ID among the RCs having set the U bit SHOULD be selected as 513 the RC for upward dissemination of routing information. It is 514 expected that other RCs will not participate in the upward 515 dissemination of routing information as long as the opaque LSA 516 information corresponding to the highest Router ID RC does not reach 517 MaxAge. 519 Note that alternatively if this information cannot be discovered 520 automatically, it MUST be manually configured. 522 The same mechanism is used for selecting the RC taking in charge 523 dissemination of routing information downward the hierarchy with the 524 restriction that the RC selection process needs to take into account 525 that an upper level may be adjacent to one or more lower levels. For 527 D.Papadimitriou et al. - Expires August 2006 10 528 this purpose a specific TLV indexing the (lower) area ID to which 529 the RC's are capable to disseminate routing information is needed. 531 OSPF Associated Area ID TLV format carried in the OSPF router 532 information LSA [OSPF-CAP] is defined. This TLV has the following 533 format: 535 0 1 2 3 536 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 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | Type | Length | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | Associated Area ID | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 Type (16 bits): identifies the TLV type 544 Length (16 bits): length of the value field in octets 545 Value (32 bits): Associated Area ID whose value space is the Area ID 546 as defined in [RFC2328]. 548 Note that this information MUST be present when the D bit is set. To 549 discover RCs that are capable to disseminate routing information 550 downward the routing hierarchy, the following Capability Descriptor 551 bit [OSPF-TE-CAP] is defined, that MUST be advertised together with 552 the OSPF Area ID TLV: 554 - D bit: when set, this flag indicates that the RC is capable to 555 disseminate routing information downward the adjacent level. 557 In case of multiple supporting RCs for the same Associated Area ID, 558 the RC with the highest Router ID SHOULD be selected. More 559 precisely, the RC with the highest Router ID among the RCs having 560 set the D bit SHOULD be selected as the RC for downward 561 dissemination of routing information. It is expected that other RCs 562 for the same Associated Area ID will not participate in the downward 563 dissemination of routing information as long as the opaque LSA 564 information corresponding to the highest Router ID RC does not reach 565 MaxAge. 567 Note that alternatively if this information cannot be discovered 568 automatically, it MUST be manually configured. 570 The OSPF Router information opaque LSA (opaque type of 4, opaque ID 571 of 0) and its content in particular, the Router Informational 572 Capabilities TLV [OSPF-CAP] and TE Node Capability Descriptor TLV 573 [OSPF-TE-CAP] MUST NOT be re-originated. 575 6.1.2 Loop prevention 577 When more than one RC are bound to adjacent levels of the hierarchy, 578 configured and selected to redistribute upward and downward the 579 routing information, a specific mechanism is required to avoid 581 D.Papadimitriou et al. - Expires August 2006 11 582 looping/re-introduction of routing information back to the upper 583 level. In all other cases, the procedure described in this section 584 is optional. 586 When these conditions are met, it is necessary to have a mean by 587 which an RC receiving an Opaque TE LSA re-originated downward by an 588 RC associated to the same area omits to re-originate back the 589 content of this LSA upward into the (same) upper level. 591 Thus we need some way of filtering the downward/onward re-originated 592 Opaque TE LSA. 594 For opaque LSAs including the Router Address TLV, if the Router 595 address has been already installed into the TEDB, the LSA should not 596 be re-originated since this address belongs to a router part of the 597 target area. 599 For opaque LSAs including the Link TLV, if the Link ID has been 600 already installed into the TEDB, the LSA should not be re-originated 601 since the corresponding router ID belongs to a router part of the 602 target area. 604 For opaque LSAs including the Node Attribute TLV, if one of the 605 included prefixes has been already installed into the TEDB, the LSA 606 should not be re-originated with that prefix since the corresponding 607 reachable end-points belonging to a router part of the target area. 608 If no prefix remains, the LSA SHOULD not be re-originated. 610 6.2. IS-IS 612 6.2.1 Discovery and Selection 614 In order to discover RCs that are capable to disseminate routing 615 information upward the routing hierarchy, the following Capability 616 Descriptor bit [ISIS-TE-CAP] are defined: 618 - U bit: when set, this flag indicates that the RC is capable to 619 disseminate routing information upward the adjacent level. 621 In case of multiple supporting RCs, the RC with the highest Router 622 ID [ISIS-CAP] SHOULD be selected. More precisely, the RC with the 623 highest Router ID among the RCs having set the U bit SHOULD be 624 selected as the RC for upward dissemination of routing information. 625 It is expected that other RCs will not participate in the upward 626 dissemination of routing information as long as the routing 627 information corresponding to the highest Router ID RC is not 628 withdrawn. 630 Note that alternatively if this information cannot be discovered 631 automatically, it MUST be manually configured. 633 D.Papadimitriou et al. - Expires August 2006 12 634 The same mechanism is used for selecting the RC taking in charge 635 dissemination of routing information downward the hierarchy with the 636 restriction that the RC selection process needs to take into account 637 that an upper level may be adjacent to one or more lower levels. For 638 this purpose a specific TLV indexing the (lower) ISIS area ID to 639 which the RC's are capable to disseminate routing information is 640 needed. 642 To discover RCs that are capable to disseminate routing information 643 downward the routing hierarchy, the following Capability Descriptor 644 bit [ISIS-TE-CAP] is defined: 646 - D bit: when set, this flag indicates that the RC is capable to 647 disseminate routing information downward the adjacent level. 649 In case of multiple supporting RCs for the same ISIS Area ID, the RC 650 with the highest Router ID SHOULD be selected. More precisely, the 651 RC with the highest Router ID among the RCs having set the D bit 652 SHOULD be selected as the RC for downward dissemination of routing 653 information. It is expected that other RCs for the same Area ID will 654 not participate in the downward dissemination of routing information 655 as long as the routing information corresponding to the highest 656 Router ID RC is not withdrawn. 658 Note that alternatively if this information cannot be discovered 659 automatically, it MUST be manually configured. 661 The ISIS Router Capability TLV [ISIS-CAP] and its content in 662 particular MUST NOT be redistributed between adjacent levels. 664 6.2.2 Loop prevention 666 As described in [RFC3784], to prevent this looping of TE reachable 667 prefixes between levels, an up/down bit (U bit) is defined in the 668 newly defined extended TE reachability TLV. 670 The up/down bit MUST be set to 0 when a prefix is first injected 671 into IS-IS. If a prefix is advertised from a higher level to a 672 lower level (e.g. level 2 to level 1), the bit MUST be set to 1, 673 indicating that the prefix has traveled down the hierarchy. Prefixes 674 that have the up/down bit set to 1 may only be advertised down the 675 hierarchy, i.e. to lower levels. 677 For the extended IS reachability TLV, the same re-origination rules 678 as described in Section 6.1.2 applies. 680 7. OSPFv2 Extensions 682 7.1 Compatibility 684 Extensions specified in this document are associated to the 686 D.Papadimitriou et al. - Expires August 2006 13 687 OSPFv2 TE LSA: 689 o) Router Address top level TLV (Type 1): 690 - no additional sub-TLV 692 o) Link top level TLV (Type 2): 693 - Local and Remote TE Router ID sub-TLV: optional sub-TLV for 694 scoping link attributes per TE_Router ID 696 o) Node Attribute top level TLV (Type TBD): 697 - Node IPv4 Local Prefix sub-TLVs: optional sub-TLV for IPv4 698 reachability advertisement 699 - Node IPv6 Local Prefix sub-TLVs: optional sub-TLV for IPv6 700 reachability advertisement 701 - Local TE Router ID sub-TLV: optional sub-TLV for scoping 702 reachability per TE_Router ID 704 OSPFv2 RI LSA: 706 o) Routing information dissemination 707 - U and D bit in Capability Descriptor TLV [OSPF-TE-CAP] 708 - Associated Area ID TLV in the OSPF Routing Information LSA 709 [OSPF-CAP] 711 7.2 Scalability 713 o) Routing information exchange upward/downward the hierarchy 714 between adjacent areas SHOULD by default be limited to reachability. 715 In addition, several transformation such as prefix aggregation are 716 recommended when allowing decreasing the amount of information re- 717 originated by a given RC without impacting consistency. 719 o) Routing information exchange upward/downward the hierarchy when 720 involving TE attributes MUST be under strict policy control. Pacing 721 and min/max thresholds for triggered updates are strongly 722 recommended. 724 8. IS-IS Extensions and Compatibility 726 TBD 728 9. Acknowledgements 730 The authors would like to thank Alan Davey and Adrian Farrel for 731 their useful comments and suggestions. 733 10. References 735 11.1 Normative References 737 D.Papadimitriou et al. - Expires August 2006 14 739 [OSPF-NODE] R.Aggarwal, and K.Kompella, "Advertising a Router's 740 Local Addresses in OSPF TE Extensions," Internet Draft, 741 (work in progress), draft-ietf-ospf-te-node-addr- 742 02.txt, March 2005. 744 [RFC2026] S.Bradner, "The Internet Standards Process -- 745 Revision 3", BCP 9, RFC 2026, October 1996. 747 [RFC2328] J.Moy, "OSPF Version 2", RFC 2328, April 1998. 749 [RFC2740] R.Coltun et al. "OSPF for IPv6", RFC 2740, December 750 1999. 752 [RFC2119] S.Bradner, "Key words for use in RFCs to Indicate 753 Requirement Levels", BCP 14, RFC 2119, March 1997. 755 [RFC3477] K.Kompella et al. "Signalling Unnumbered Links in 756 Resource ReSerVation Protocol - Traffic Engineering 757 (RSVP-TE)", RFC 3477, January 2003. 759 [RFC3630] D.Katz et al. "Traffic Engineering (TE) Extensions to 760 OSPF Version 2", RFC 3630, September 2003. 762 [RFC3667] S.Bradner, "IETF Rights in Contributions", BCP 78, 763 RFC 3667, February 2004. 765 [RFC3668] S.Bradner, Ed., "Intellectual Property Rights in IETF 766 Technology", BCP 79, RFC 3668, February 2004. 768 [RFC3784] H.Smit and T.Li, "Intermediate System to Intermediate 769 System (IS-IS) Extensions for Traffic Engineering (TE)," 770 RFC 3784, June 2004. 772 [RFC3946] E.Mannie, and D.Papadimitriou, (Editors) et al., 773 "Generalized Multi-Protocol Label Switching Extensions 774 for SONET and SDH Control," RFC 3946, October 2004. 776 [RFC4202] Kompella, K. (Editor) et al., "Routing Extensions in 777 Support of Generalized MPLS," RFC 4202, October 2005. 779 8.2 Informative References 781 [ASON-EVAL] C.Hopps et al. "Evaluation of existing Routing Protocols 782 against ASON Routing Requirements", Work in progress, 783 draft-ietf-ccamp-gmpls-ason-routing-eval-02.txt, October 784 2005. 786 [ASON-RR] D.Brungard et al. "Requirements for Generalized MPLS 787 (GMPLS) Routing for Automatically Switched Optical 788 Network (ASON)," RFC 4258, November 2005. 790 For information on the availability of ITU Documents, please see 792 D.Papadimitriou et al. - Expires August 2006 15 793 http://www.itu.int 795 [G.7715] ITU-T Rec. G.7715/Y.1306, "Architecture and 796 Requirements for the Automatically Switched Optical 797 Network (ASON)," June 2002. 799 [G.7715.1] ITU-T Draft Rec. G.7715.1/Y.1706.1, "ASON Routing 800 Architecture and Requirements for Link State Protocols," 801 November 2003. 803 [G.8080] ITU-T Rec. G.8080/Y.1304, "Architecture for the 804 Automatically Switched Optical Network (ASON)," 805 November 2001 (and Revision, January 2003). 807 9. Author's Addresses 809 Dimitri Papadimitriou (Alcatel) 810 Francis Wellensplein 1, 811 B-2018 Antwerpen, Belgium 812 Phone: +32 3 2408491 813 EMail: dimitri.papadimitriou@alcatel.be 815 D.Papadimitriou et al. - Expires August 2006 16 816 Appendix 1: ASON Terminology 818 This document makes use of the following terms: 820 Administrative domain: (see Recommendation G.805) for the purposes of 821 [G7715.1] an administrative domain represents the extent of resources 822 which belong to a single player such as a network operator, a service 823 provider, or an end-user. Administrative domains of different players 824 do not overlap amongst themselves. 826 Control plane: performs the call control and connection control 827 functions. Through signaling, the control plane sets up and releases 828 connections, and may restore a connection in case of a failure. 830 (Control) Domain: represents a collection of (control) entities that 831 are grouped for a particular purpose. The control plane is subdivided 832 into domains matching administrative domains. Within an 833 administrative domain, further subdivisions of the control plane are 834 recursively applied. A routing control domain is an abstract entity 835 that hides the details of the RC distribution. 837 External NNI (E-NNI): interfaces are located between protocol 838 controllers between control domains. 840 Internal NNI (I-NNI): interfaces are located between protocol 841 controllers within control domains. 843 Link: (see Recommendation G.805) a "topological component" which 844 describes a fixed relationship between a "subnetwork" or "access 845 group" and another "subnetwork" or "access group". Links are not 846 limited to being provided by a single server trail. 848 Management plane: performs management functions for the Transport 849 Plane, the control plane and the system as a whole. It also provides 850 coordination between all the planes. The following management 851 functional areas are performed in the management plane: performance, 852 fault, configuration, accounting and security management 854 Management domain: (see Recommendation G.805) a management domain 855 defines a collection of managed objects which are grouped to meet 856 organizational requirements according to geography, technology, 857 policy or other structure, and for a number of functional areas such 858 as configuration, security, (FCAPS), for the purpose of providing 859 control in a consistent manner. Management domains can be disjoint, 860 contained or overlapping. As such the resources within an 861 administrative domain can be distributed into several possible 862 overlapping management domains. The same resource can therefore 863 belong to several management domains simultaneously, but a management 864 domain shall not cross the border of an administrative domain. 866 Subnetwork Point (SNP): The SNP is a control plane abstraction that 867 represents an actual or potential transport plane resource. SNPs (in 869 D.Papadimitriou et al. - Expires August 2006 17 870 different subnetwork partitions) may represent the same transport 871 resource. A one-to-one correspondence should not be assumed. 873 Subnetwork Point Pool (SNPP): A set of SNPs that are grouped together 874 for the purposes of routing. 876 Termination Connection Point (TCP): A TCP represents the output of a 877 Trail Termination function or the input to a Trail Termination Sink 878 function. 880 Transport plane: provides bi-directional or unidirectional transfer 881 of user information, from one location to another. It can also 882 provide transfer of some control and network management information. 883 The Transport Plane is layered; it is equivalent to the Transport 884 Network defined in G.805 Recommendation. 886 User Network Interface (UNI): interfaces are located between protocol 887 controllers between a user and a control domain. Note: there is no 888 routing function associated with a UNI reference point. 890 D.Papadimitriou et al. - Expires August 2006 18 891 Appendix 2: ASON Routing Terminology 893 This document makes use of the following terms: 895 Routing Area (RA): a RA represents a partition of the data plane and 896 its identifier is used within the control plane as the representation 897 of this partition. Per [G.8080] a RA is defined by a set of sub- 898 networks, the links that interconnect them, and the interfaces 899 representing the ends of the links exiting that RA. A RA may contain 900 smaller RAs inter-connected by links. The limit of subdivision 901 results in a RA that contains two sub-networks interconnected by a 902 single link. 904 Routing Database (RDB): repository for the local topology, network 905 topology, reachability, and other routing information that is updated 906 as part of the routing information exchange and may additionally 907 contain information that is configured. The RDB may contain routing 908 information for more than one Routing Area (RA). 910 Routing Components: ASON routing architecture functions. These 911 functions can be classified as protocol independent (Link Resource 912 Manager or LRM, Routing Controller or RC) and protocol specific 913 (Protocol Controller or PC). 915 Routing Controller (RC): handles (abstract) information needed for 916 routing and the routing information exchange with peering RCs by 917 operating on the RDB. The RC has access to a view of the RDB. The RC 918 is protocol independent. 920 Note: Since the RDB may contain routing information pertaining to 921 multiple RAs (and possibly to multiple layer networks), the RCs 922 accessing the RDB may share the routing information. 924 Link Resource Manager (LRM): supplies all the relevant component and 925 TE link information to the RC. It informs the RC about any state 926 changes of the link resources it controls. 928 Protocol Controller (PC): handles protocol specific message exchanges 929 according to the reference point over which the information is 930 exchanged (e.g. E-NNI, I-NNI), and internal exchanges with the RC. 931 The PC function is protocol dependent. 933 D.Papadimitriou et al. - Expires August 2006 19 934 Full Copyright Statement 936 Copyright (C) The Internet Society (2005). This document is subject 937 to the rights, licenses and restrictions contained in BCP 78, and 938 except as set forth therein, the authors retain all their rights. 940 This document and the information contained herein are provided on 941 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 942 REPRESENTSOR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 943 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 944 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 945 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 946 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 948 Intellectual Property 950 The IETF takes no position regarding the validity or scope of any 951 Intellectual Property Rights or other rights that might be claimed 952 to pertain to the implementation or use of the technology described 953 in this document or the extent to which any license under such 954 rights might or might not be available; nor does it represent that 955 it has made any independent effort to identify any such rights. 956 Information on the procedures with respect to rights in RFC 957 documents can be found in BCP 78 and BCP 79. 959 Copies of IPR disclosures made to the IETF Secretariat and any 960 assurances of licenses to be made available, or the result of an 961 attempt made to obtain a general license or permission for the use 962 of such proprietary rights by implementers or users of this 963 specification can be obtained from the IETF on-line IPR repository 964 at http://www.ietf.org/ipr. 966 The IETF invites any interested party to bring to its attention any 967 copyrights, patents or patent applications, or other proprietary 968 rights that may cover technology that may be required to implement 969 this standard. Please address the information to the IETF at ietf- 970 ipr@ietf.org. 972 D.Papadimitriou et al. - Expires August 2006 20