idnits 2.17.1 draft-ietf-ccamp-gmpls-ason-routing-eval-03.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 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 936. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 913. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 920. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 926. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 17 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (May 2006) is 6553 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 3630' is mentioned on line 192, but not defined == Missing Reference: 'RFC 3784' is mentioned on line 188, but not defined ** Obsolete undefined reference: RFC 3784 (Obsoleted by RFC 5305) == Missing Reference: 'RFC 2328' is mentioned on line 198, but not defined == Missing Reference: 'RFC 1195' is mentioned on line 199, but not defined == Missing Reference: 'RFC 3477' is mentioned on line 271, but not defined == Missing Reference: 'GMPLS-ISIS' is mentioned on line 351, but not defined == Unused Reference: 'RFC3477' is defined on line 681, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2966 (Obsoleted by RFC 5302) ** Obsolete normative reference: RFC 3784 (Obsoleted by RFC 5305) ** Obsolete normative reference: RFC 3946 (Obsoleted by RFC 4606) ** Obsolete normative reference: RFC 4205 (Obsoleted by RFC 5307) == Outdated reference: A later version (-07) exists of draft-ietf-opsec-current-practices-02 == Outdated reference: A later version (-07) exists of draft-ietf-ospf-te-node-addr-02 Summary: 9 errors (**), 0 flaws (~~), 11 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group Chris Hopps (Cisco) 3 Internet Draft Lyndon Ong (Ciena) 4 Category: Informational Dimitri Papadimitriou (Alcatel) 5 Jonathan Sadler (Tellabs) 6 Expiration Date: December 2006 Stephen Shew (Nortel) 7 Dave Ward (Cisco) 9 May 2006 11 Evaluation of existing Routing Protocols 12 against ASON routing requirements 14 draft-ietf-ccamp-gmpls-ason-routing-eval-03.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other documents 30 at any time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 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 an evaluation of the IETF Routing Protocols 47 against the routing requirements for an Automatically Switched 48 Optical Network (ASON) as defined by ITU-T. 50 C.Hopps et al. - Expires December 2006 1 51 1. Contributors 53 This document is the result of the CCAMP Working Group ASON Routing 54 Solution design team joint effort. 56 Dimitri Papadimitriou (Alcatel, Team Leader and Editor) 57 EMail: dimitri.papadimitriou@alcatel.be 58 Chris Hopps (Cisco) 59 EMail: chopps@rawdofmt.org 60 Lyndon Ong (Ciena Corporation) 61 EMail: lyong@ciena.com 62 Jonathan Sadler (Tellabs) 63 EMail: jonathan.sadler@tellabs.com 64 Stephen Shew (Nortel Networks) 65 EMail: sdshew@nortelnetworks.com 66 Dave Ward (Cisco) 67 EMail: dward@cisco.com 69 2. Conventions used in this document 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 73 document are to be interpreted as described in RFC 2119 [RFC2119]. 75 The reader is expected to be familiar with the terminology introduced 76 in [RFC4258]. 78 3. Introduction 80 There are certain capabilities that are needed to support the ITU-T 81 Automatically Switched Optical Network (ASON) control plane 82 architecture as defined in [G.8080]. 84 [RFC4258] details the routing requirements for the GMPLS routing 85 suite of protocols to support the capabilities and functionality of 86 ASON control planes identified in [G.7715] and in [G.7715.1]. The 87 ASON routing architecture provides for a conceptual reference 88 architecture, with definition of functional components and common 89 information elements to enable end-to-end routing in the case of 90 protocol heterogeneity and facilitate management of ASON networks. 91 This description is only conceptual: no physical partitioning of 92 these functions is implied. 94 However, [RFC4258] does not address GMPLS routing protocol 95 applicability or capabilities. This document evaluates the IETF 96 Routing Protocols against the requirements identified in [RFC4258]. 97 The result of this evaluation is detailed in Section 5. Close 98 examination of applicability scenarios and the result of the 99 evaluation of these scenarios are provided in Section 6. 101 ASON (Routing) terminology sections are provided in Appendix 1 and 2. 103 C.Hopps et al. - Expires January 2006 2 104 4. Requirements - Overview 106 The following functionality is expected from GMPLS routing protocols 107 to instantiate the ASON hierarchical routing architecture realization 108 (see [G.7715] and [G.7715.1]): 109 - Routing Areas (RAs) shall be uniquely identifiable within a 110 carrier's network, each having a unique RA Identifier (RA ID) 111 within the carrier's network. 112 - Within a RA (one level), the routing protocol shall support 113 dissemination of hierarchical routing information (including 114 summarized routing information for other levels) in support of an 115 architecture of multiple hierarchical levels of RAs; the number of 116 hierarchical RA levels to be supported by a routing protocol is 117 implementation specific. 118 - The routing protocol shall support routing information based on a 119 common set of information elements as defined in [G.7715] and 120 [G.7715.1], divided between attributes pertaining to links and 121 abstract nodes (each representing either a sub-network or simply a 122 node). [G.7715] recognizes that the manner in which the routing 123 information is represented and exchanged will vary with the 124 routing protocol used. 125 - The routing protocol shall converge such that the distributed 126 Routing DataBases (RDB) become synchronized after a period of 127 time. 129 To support dissemination of hierarchical routing information, the 130 routing protocol must deliver: 131 - Processing of routing information exchanged between adjacent 132 levels of the hierarchy (i.e. Level N+1 and N) including 133 reachability, and (upon policy decision) summarized topology 134 information. 135 - Self-consistent information at the receiving level resulting from 136 any transformation (filter, summarize, etc.) and forwarding of 137 information from one Routing Controller (RC) to RC(s) at different 138 levels when multiple RCs are bound to a single RA. 139 - A mechanism to prevent re-introduction of information propagated 140 into the Level N RA's RC back to the adjacent level RA's RC from 141 which this information has been initially received. 143 Note: the number of hierarchical levels to be supported is routing 144 protocol specific and reflects a containment relationship. 146 Reachability information may be advertised either as a set of UNI 147 Transport Resource address prefixes, or a set of associated 148 Subnetwork Point Pool (SNPP) link IDs/SNPP link ID prefixes, assigned 149 and selected consistently in their applicability scope. The formats 150 of the control plane identifiers in a protocol realization are 151 implementation specific. Use of a routing protocol within a RA should 152 not restrict the choice of routing protocols for use in other RAs 153 (child or parent). 155 C.Hopps et al. - Expires January 2006 3 156 As ASON does not restrict the control plane architecture choice, 157 either a co-located architecture or a physically separated 158 architecture may be used. A collection of links and nodes such as a 159 sub-network or RA must be able to represent itself to the wider 160 network as a single logical entity with only its external links 161 visible to the topology database. 163 5. Evaluation 165 This section evaluates support of existing IETF routing protocols 166 with respect to the requirements summarized from [RFC4258] in Section 167 4. Candidate routing protocols are IGP (OSPF and IS-IS) and BGP. The 168 latter is not addressed in the current version of this document. BGP 169 is not considered a candidate protocol mainly because of 170 - non-support of TE information exchange: each BGP router advertises 171 only its path to each destination in its vector for loop avoidance, 172 with no costs or hop counts; each BGP router knows little about 173 network topology 174 - BGP can only advertise routes that are eligible for use (local RIB) 175 or routing loops can occur; there is one best route per prefix, and 176 that is the route that is advertised. 177 - BGP is not widely deployed in optical equipment and networks 179 5.1 Terminology and Identification 181 - Pi is a physical (bearer/data/transport plane) node 183 - Li is a logical control plane entity that is associated to a 184 single data plane (abstract) node. The Li is identified by the 185 TE Router_ID. The latter is a control plane identifier defined as 186 follows: 187 . [RFC 3630]: Router_Address (top level) TLV of the Type 1 TE LSA 188 . [RFC 3784]: Traffic Engineering Router ID TLV (Type 134) 190 Note: this document does not define what the TE Router ID is. This 191 document simply states the use of the TE Router ID to 192 identify Li. [RFC 3630] and [RFC3784] provide the definitions. 194 - Ri is a logical control plane entity that is associated to a 195 control plane "router". The latter is the source for topology 196 information that it generates and shares with other control plane 197 "routers". The Ri is identified by the (advertising) Router_ID 198 . [RFC 2328]: Router ID (32-bit) 199 . [RFC 1195]: IS-IS System ID (48-bit) 201 The Router_ID, represented by Ri and that corresponds to the RC_ID 202 [RFC4258], does not enter into the identification of the logical 203 entities representing the data plane resources such as links. The 204 Routing DataBase (RDB) is associated to the Ri. Note that, in the 205 ASON context, an arrangement consisting of multiple Ri's 206 announcing routing information related to a single Li is under 207 evaluation. 209 C.Hopps et al. - Expires January 2006 4 210 Aside from the Li/Pi mappings, these identifiers are not assumed to 211 be in a particular entity relationship except that the Ri may have 212 multiple Li in its scope. The relationship between Ri and Li is 213 simple at any moment in time: an Li may be advertised by only one Ri 214 at any time. However, an Ri may advertise a set of one or more Li's. 215 Thus, the routing protocol MUST be able to advertise multiple TE 216 Router IDs (see Section 5.7). 218 Note: Si is a control plane signaling function associated with one 219 or more Li. This document does not assume any specific constraint on 220 the relationship between Si and Li. This document does not discuss 221 issues of control plane accessibility for the signaling function, 222 and makes no assumptions about how control plane accessibility to 223 the Si is achieved. 225 5.2 RA Identification 227 G.7715.1 notes some necessary characteristics for RA identifiers, 228 e.g., that they may provide scope for the Ri, and that they must be 229 provisioned to be unique within an administrative domain. The RA ID 230 format itself is allowed to be derived from any global address space. 231 Provisioning of RA IDs for uniqueness is outside the scope of this 232 document. 234 Under these conditions, GMPLS link state routing protocols provide 235 the capability for RA Identification without further modification. 237 5.3 Routing Information Exchange 239 In this section, the focus is on routing information exchange Ri 240 entities (through routing adjacencies) within a single hierarchical 241 level. Routing information mapping between levels require specific 242 processing (see Section 5.5). 244 The control plane does not transport Pi identifiers as these are 245 data plane addresses for which the Li/Pi mapping is kept (link) 246 local - see for instance the transport LMP document [RFC4394] where 247 such an exchange is described. Example: the transport plane 248 identifier is the Pi (the identifier assigned to the physical 249 element) that could be for instance "666B.F999.AF10.222C", whereas 250 the control plane identifier is the Li (the identifier assigned by 251 the control plane), which could be for instance "192.0.2.1". 253 The control plane exchanges the control plane identifier information 254 but not the transport plane identifier information (i.e. not 255 "666B.F999.AF10.222C" but only "192.0.2.1"). The mapping Li/Pi is 256 kept local. So, when the Si receives a control plane message 257 requesting the use of "192.0.2.1", Si knows locally that this 258 information refers to the data plane entity identified by the 259 transport plane identifier "666B.F999.AF10.222C". 261 C.Hopps et al. - Expires January 2006 5 262 Note also that the Li and Pi addressing spaces may be identical. 264 The control plane carries: 265 1) its view of the data plane link end-points and other link 266 connection end-points 267 2) the identifiers scoped by the Li's i.e. referred to as an 268 associated IPv4/IPv6 addressing space; note that these identifiers 269 may either be bundled TE link addresses or component link addresses 270 3) when using OSPF or ISIS as the IGP in support of traffic 271 engineering, [RFC 3477] RECOMMENDS that the Li value (referred to 272 the "LSR Router ID") to be set to the TE Router ID value. 274 Therefore, OSPF and IS-IS carry sufficient node identification 275 information without further modification. 277 5.3.1 Link Attributes 279 [RFC4258] provides a list of link attributes and characteristics 280 that need to be advertised by a routing protocol. All TE link 281 attributes and characteristics are currently handled by OSPF and IS- 282 IS (see Table 1) with the exception of Local Adaptation support. 283 Indeed, GMPLS routing does not currently consider the use of 284 dedicated TE link attribute(s) to describe the cross/inter-layer 285 relationships. 287 In addition, the representation of bandwidth requires further 288 consideration. GMPLS Routing defines an Interface Switching 289 Capability Descriptor (ISCD) that delivers information about the 290 (maximum/ minimum) bandwidth per priority of which an LSP can make 291 use. This information is usually used in combination with the 292 Unreserved Bandwidth sub-TLV that provides the amount of bandwidth 293 not yet reserved on a TE link. 295 In the ASON context, other bandwidth accounting representations are 296 possible, e.g., in terms of a set of tuples . The latter representation may also require 298 definition of additional signal types (from those defined in 299 [RFC3946]) to represent support of contiguously concatenated signals 300 i.e. STS-(3xN)c SPE / VC-4-Nc, N = 4, 16, 64, 256. 302 However, the method proposed in [RFC4202] is the most 303 straightforward without requiring any bandwidth accounting change 304 from an LSR perspective (in particular, when the ISCD sub-TLV 305 information is combined with the information provided by the 306 Unreserved Bandwidth sub-TLV). 308 Link Characteristics GMPLS OSPF 309 ----------------------- ---------- 310 Local SNPP link ID Link local part of the TE link identifier 311 sub-TLV [RFC4203] 313 C.Hopps et al. - Expires January 2006 6 314 Remote SNPP link ID Link remote part of the TE link identifier 315 sub-TLV [RFC4203] 316 Signal Type Technology specific part of the Interface 317 Switching Capability Descriptor sub-TLV 318 [RFC4203] 319 Link Weight TE metric sub-TLV [RFC3630] 320 Resource Class Administrative Group sub-TLV [RFC3630] 321 Local Connection Types Switching Capability field part of the 322 Interface Switching Capability Descriptor 323 sub-TLV [RFC4203] 324 Link Capacity Unreserved bandwidth sub-TLV [RFC3630] 325 Max LSP Bandwidth part of the Interface 326 Switching Capability Descriptor sub-TLV 327 [RFC4203] 328 Link Availability Link Protection sub-TLV [RFC4203] 329 Diversity Support SRLG sub-TLV [RFC4203] 330 Local Adaptation support see above 332 Table 1. TE link Attributes in GMPLS OSPF-TE 334 Link Characteristics GMPLS IS-IS 335 ----------------------- ----------- 336 Local SNPP link ID Link local part of the TE link identifier 337 sub-TLV [RFC4205] 338 Remote SNPP link ID Link remote part of the TE link identifier 339 sub-TLV [RFC4205] 340 Signal Type Technology specific part of the Interface 341 Switching Capability Descriptor sub-TLV 342 [RFC4205] 343 Link Weight TE Default metric [RFC3784] 344 Resource Class Administrative Group sub-TLV [RFC3784] 345 Local Connection Types Switching Capability field part of the 346 Interface Switching Capability Descriptor 347 sub-TLV [RFC4205] 348 Link Capacity Unreserved bandwidth sub-TLV [RFC3784] 349 Max LSP Bandwidth part of the Interface 350 Switching Capability Descriptor sub-TLV 351 [GMPLS-ISIS] 352 Link Availability Link Protection sub-TLV [RFC4205] 353 Diversity Support SRLG sub-TLV [RFC4205] 354 Local Adaptation support see above 356 Table 2. TE link Attributes in GMPLS IS-IS-TE 358 Note: Link Attributes represent layer resource capabilities and 359 their utilization i.e. the IGP should be able to advertise these 360 attributes on a per-layer basis. 362 5.3.2 Node Attributes 364 Node attributes are the "Logical Node ID" (described in Section 5.1) 365 and the reachability information described in Section 5.3.3. 367 C.Hopps et al. - Expires January 2006 7 368 5.3.3 Reachability Information 370 Advertisement of reachability can be achieved using the techniques 371 described in [OSPF-NODE] where the set of local addresses are 372 carried in an OSPF TE LSA node attribute TLV (a specific sub-TLV is 373 defined per address family, e.g., IPv4 and IPv6). However, [OSPF- 374 NODE] is restricted to advertisement of Host addresses and not 375 prefixes, and therefore requires enhancement (see below). Hence, in 376 order to advertise blocks of reachable address prefixes a 377 summarization mechanism is additionally required. This mechanism may 378 take the form of a prefix length (that indicates the number of 379 significant bits in the prefix) or a network mask. 381 A similar mechanism does not exist for IS-IS. Moreover, the Extended 382 IP Reachability TLV [RFC3784] focuses on IP reachable end-points 383 (terminating points), as its name indicates. 385 5.4 Routing Information Abstraction 387 G.7715.1 describes both static and dynamic methods for abstraction of 388 routing information for advertisement at a different level of the 389 routing hierarchy. However, the information that is advertised 390 continues to be in the form of link and node advertisements 391 consistent with the link state routing protocol used at that level. 392 Hence, no specific capabilities need to be added to the routing 393 protocol beyond the ability to locally identify when routing 394 information originates outside of a particular RA. 396 The methods used for abstraction of routing information are outside 397 the scope of GMPLS routing protocols. 399 5.5 Dissemination of routing information in support of multiple 400 hierarchical levels of RAs 402 G.7715.1 does not define specific mechanisms to support multiple 403 hierarchical levels of RAs, beyond the ability to support abstraction 404 as discussed above. However, if RCs bound to adjacent levels of the 405 RA hierarchy are allowed to redistribute routing information in both 406 directions between adjacent levels of the hierarchy without any 407 additional mechanisms, they would not be able to determine looping 408 of routing information. 410 To prevent this looping of routing information between levels, IS-IS 411 [RFC1195] allows only advertising routing information upward in the 412 level hierarchy, and disallows the advertising of routing 413 information downward in the hierarchy. [RFC2966] defines the up/down 414 bit to allow advertising downward in the hierarchy the "IP Internal 415 Reachability Information" TLV (Type 128) and "IP External 416 Reachability Information" TLV (Type 130). [RFC3784] extends its 417 applicability for the "Extended IP Reachability" TLV (Type 135). 418 Using this mechanism, the up/down bit is set to 0 when routing 420 C.Hopps et al. - Expires January 2006 8 421 information is first injected into IS-IS. If routing information is 422 advertised from a higher level to a lower level, the up/down bit is 423 set to 1, indicating that it has traveled down the hierarchy. 424 Routing information that has the up/down bit set to 1 may only be 425 advertised down the hierarchy, i.e. to lower levels. This mechanism 426 applies independently of the number of levels. However, this 427 mechanism does not apply to the "Extended IS Reachability" TLV (Type 428 22) used to propagate the summarized topology (see Section 5.3), 429 traffic engineering information as listed in Table 1, as well as 430 reachability information (see Section 5.3.3). 432 OSPFv2 [RFC2328] prevents inter-area routes (which are learned from 433 area 0) from being passed back to area 0. However, GMPLS makes use of 434 Type 10 (area-local scope) LSAs to propagate TE information 435 [RFC3630], [RFC4202]. Type 10 Opaque LSAs are not flooded beyond the 436 borders of their associated area. It is therefore necessary to have 437 a means by which Type 10 Opaque LSA may carry the information that a 438 particular piece of routing information has been learned from a 439 higher level RC when propagated to a lower level RC. Any downward RC 440 from this level, which receives an LSA with this information would 441 omit the information in this LSA and thus not re-introduce this 442 information back into a higher level RC. 444 5.6 Routing Protocol Convergence 446 Link state protocols have been designed to propagate detected 447 topological changes (such as interface failures, link attributes 448 modification). The convergence period is short and involves a 449 minimum of routing information exchange. 451 Therefore, existing routing protocol convergence involves mechanisms 452 are sufficient for ASON applications. 454 5.7 Routing Information Scoping 456 The routing protocol MUST support a single Ri advertising on behalf 457 of more than one Li. Since each Li is identified by a unique 458 TE Router ID, the routing protocol MUST be able to advertise 459 multiple TE Router IDs. That is, for [RFC3630], multiple Router 460 Addresses and for [RFC3784] multiple Traffic Engineering Router Ids. 462 The Link sub-TLV currently part of the top level Link TLV associates 463 the link to the Router_ID. However, having the Ri advertising on 464 behalf of multiple Li's creates the following issue, as there is no 465 longer a 1:1 relationship between the Router_ID and the TE 466 Router_ID, but a 1:N relationship is possible (see Section 5.1). As 467 the link local and link remote (unnumbered) ID association may be 468 not unique per abstract node (per Li unicity), the advertisement 469 needs to indicate the remote Lj value and rely on the initial 470 discovery process to retrieve the {Li;Lj} relationship(s). In brief, 471 as unnumbered links have their ID defined on per Li bases, the 472 remote Lj needs to be identified to scope the link remote ID to the 474 C.Hopps et al. - Expires January 2006 9 475 local Li. Therefore, the routing protocol MUST be able to 476 disambiguate the advertised TE links so that they can be associated 477 with the correct TE Router ID. 479 Moreover, when the Ri advertises on behalf multiple Li's, the 480 routing protocol MUST be able to disambiguate the advertised 481 reachability information (see Section 5.3.3) so that it can be 482 associated with the correct TE Router ID. 484 6. Evaluation Scenarios 486 The evaluation scenarios are the following; they are respectively 487 referred to as case 1, 2, 3, and 4. 489 In Figure 1 below: 490 - R3 represents an LSR with all components collocated. 491 - R2 shows how the "router" component may be disjoint from the node 492 - R1 shows how a single "router" may manage multiple nodes 494 ------------------- ------- 495 |R1 | |R2 | 496 | | | | ------ 497 | L1 L2 L3 | | L4 | |R3 | 498 | : : : | | : | | | 499 | : : : | | : | | L5 | 500 Control ---+-----+-----+--- ---+--- | : | 501 Plane : : : : | : | 502 ----------------+-----+-----+-----------+-------+---+--+- 503 Data : : : : | : | 504 Plane -- : -- -- | -- | 505 ----|P1|--------|P3|--------|P4|------+-|P5|-+- 506 -- \ : / -- -- | -- | 507 \ -- / | | 508 |P2| ------ 509 -- 511 Figure 1. Evaluation Case 1, 2 and 3 513 Case 1 as represented refers either to direct links between edges or 514 "logical links" as shown in Figure 2 (or any combination of them) 516 ------ ------ 517 | | | | 518 | L1 | | L2 | 519 | : | | : | 520 | : R1| | : R2| 521 Control Plane --+--- --+--- 522 Elements : : 523 ------------------+-----------------------------+------------------ 524 Data Plane : : 525 Elements : : 526 ----+-----------------------------+----- 528 C.Hopps et al. - Expires January 2006 10 529 | : : | 530 | --- --- --- | 531 | | |----------| P |----------| | | 532 ---+--| | --- | |---+--- 533 | | | | | | 534 | | P1|-------------------------| P2| | 535 | --- --- | 536 ---------------------------------------- 538 Figure 2. Case 1 with Logical Links 540 Another case (referred to as Case 4) is constituted by the Abstract 541 Node as represented in Figure 3. There is no internal structure 542 associated (externally) to the abstract node. 544 -------------- 545 |R4 | 546 | | 547 | L6 | 548 | : | 549 | ...... | 550 ---:------:--- 551 Control Plane : : 552 +------+------+------+ 553 Data Plane : : 554 ---:------:--- 555 |P8 : : | 556 | -- -- | 557 --+-|P |----|P |-+-- 558 | -- -- | 559 -------------- 561 Figure 3. Case 4: Abstract Node 563 Note: the "signaling function" i.e. the control plane entity that 564 processes the signaling messages (referred to as Si) is not 565 represented in these Figures. 567 7. Summary of Necessary Additions to OSPF and IS-IS 569 The following sections summarize the additions to be provided to 570 OSPF and IS-IS in support of ASON routing. 572 7.1 OSPFv2 574 Reachability Extend Node Attribute sub-TLVs to support 575 address prefixes (see Section 5.3.3) 577 Link Attributes Representation of cross/inter-layer 578 relationships in link top-level link TLV (see 579 Section 5.3.1) 581 C.Hopps et al. - Expires January 2006 11 582 Optionally, provide for per signal-type 583 bandwidth accounting (see Section 5.3.1). 585 Scoping TE link advertisements to allow for retrieving 586 their respective local-remote TE Router_ID 587 relationship(s) (see Section 5.7) 589 Prefixes part of the reachability 590 advertisements (using Node Attribute top level 591 TLV) needs to be associated to their respective 592 local TE Router_ID (see Section 5.7) 594 Hierarchy Provide a mechanism by which Type 10 Opaque LSA 595 may carry the information that a particular 596 piece of routing information has been learned 597 from a higher level RC when propagated to a 598 lower level RC (such as to not re-introduce this 599 information back into a higher level RC) 601 7.2 IS-IS 603 Reachability Provide for reachability advertisement (in the 604 form of reachable TE prefixes) 606 Link Attributes Representation of cross/inter-layer 607 relationships in Extended IS Reachability TLV 608 (see Section 5.3.1) 610 Optionally, provide for per signal-type 611 bandwidth accounting (see Section 5.3.1). 613 Scoping Extended IS Reachability TLVs to allow for 614 retrieving their respective local-remote TE 615 Router_ID relationship(s) (see Section 5.7) 617 Prefixes part of the reachability advertisements 618 needs to be associated to their respective local 619 TE Router_ID (see Section 5.7) 621 Hierarchy Extend the up/down bit mechanisms to propagate 622 the summarized topology (see Section 5.3), 623 traffic engineering information as listed in 624 Table 1, as well as reachability information 625 (see Section 5.3.3). 627 8. Security Considerations 629 The introduction of a dynamic control plane to an ASON network 630 exposes it to additional security risks that may have been 631 controlled or limited by the use of management plane solutions. The 632 routing protocols play a part in the control plane and may be 634 C.Hopps et al. - Expires January 2006 12 635 attacked so that they are unstable, or provide incorrect information 636 for use in path computation or by the signaling protocols. 638 Nevertheless, there is no reason why the control plane components 639 cannot be secured, and the security mechanisms developed for the 640 routing protocol and used within the Internet are equally applicable 641 within an ASON context. 643 [RFC4258] describes the requirements for security of routing 644 protocols for the Automatically Switched Optical Network. Reference 645 is made to [M.3016] that lays out the overall security objectives of 646 confidentiality, integrity, and accountability, and these are well 647 discussed for the Internet routing protocols in [THREATS]. 649 A detailed discussion of routing threats and mechanisms, which are 650 currently deployed in operational networks to counter these 651 threats, is found in [OPSECPRACTICES]. A detailed listing of the 652 device capabilities that can be used to support these practices can 653 be found in [RFC3871]. 655 9. IANA Considerations 657 This draft makes no requests for IANA action. 659 10. Acknowledgements 661 The authors would like to thank Adrian Farrel for having initiated 662 the proposal of an ASON Routing Solution Design Team and the ITU-T 663 SG15/Q14 for their careful review and input. 665 11. References 667 11.1 Normative References 669 [RFC1195] R.Callon, "Use of OSI IS-IS for Routing in TCP/IP and 670 Dual Environments", RFC 1195, December 1990. 672 [RFC2966] T.Li, T. Przygienda, and H. Smit et al. "Domain-wide 673 Prefix Distribution with Two-Level IS-IS", RFC 2966, 674 October 2000. 676 [RFC2328] J.Moy, "OSPF Version 2", RFC 2328, April 1998. 678 [RFC2119] S.Bradner, "Key words for use in RFCs to Indicate 679 Requirement Levels", BCP 14, RFC 2119, March 1997. 681 [RFC3477] K.Kompella et al. "Signalling Unnumbered Links in 682 Resource ReSerVation Protocol - Traffic Engineering 683 (RSVP-TE)", RFC 3477, January 2003. 685 [RFC3630] D.Katz et al. "Traffic Engineering (TE) Extensions to 686 OSPF Version 2", RFC 3630, September 2003. 688 C.Hopps et al. - Expires January 2006 13 690 [RFC3784] H.Smit and T.Li, "Intermediate System to Intermediate 691 System (IS-IS) Extensions for Traffic Engineering (TE)," 692 RFC 3784, June 2004. 694 [RFC3871] G.Jones, Ed., "Operational Security Requirements for 695 Large Internet Service Provider (ISP) IP Network 696 Infrastructure", RFC 3871, September 2004. 698 [RFC3946] E.Mannie, and D.Papadimitriou, (Editors) et al., 699 "Generalized Multi-Protocol Label Switching Extensions 700 for SONET and SDH Control," RFC 3946, October 2004. 702 [RFC4202] K.Kompella (Editor) et al., "Routing Extensions in 703 Support of Generalized Multi-Protocol Label Switching 704 (GMPLS)", RFC 4202, October 2005. 706 [RFC4203] K.Kompella, Y.Rekhter, et al, "OSPF Extensions in 707 Support of Generalized Multi-Protocol Label Switching 708 (GMPLS)", RFC 4203, October 2005. 710 [RFC4205] K.Kompella, Y.Rekhter, et al, "Intermediate System 711 to Intermediate System (IS-IS) Extensions in Support 712 of Generalized Multi-Protocol Label Switching (GMPLS)", 713 RFC 4205, October 2005. 715 [RFC4258] D.Brungard et al. "Requirements for Generalized MPLS 716 (GMPLS) Routing for Automatically Switched Optical 717 Network (ASON)," RFC 4258, November 2005. 719 11.2 Informative References 721 [RFC4394] D.Fedyk et al., "A Transport Network View of the Link 722 Management Protocol (LMP)," RFC 4394, February 2006. 724 [OPSECPRACTICES] M.Kaeo, "Operational Security Current Practices", 725 Internet Draft (Work in progress), draft-ietf-opsec- 726 current-practices-02.txt, October 2005. 728 [OSPF-NODE] R.Aggarwal, and K.Kompella, "Advertising a Router's 729 Local Addresses in OSPF TE Extensions," Internet Draft, 730 (work in progress), draft-ietf-ospf-te-node-addr- 731 02.txt, March 2005. 733 [THREATS] A.Barbir et al., "Generic Threats to Routing 734 Protocols", Internet Draft (work in progress), draft- 735 ietf-rpsec-routing-threats-07.txt, October 2004. 737 For information on the availability of ITU Documents, please see 738 http://www.itu.int 740 [G.7715] ITU-T Rec. G.7715/Y.1306, "Architecture and 742 C.Hopps et al. - Expires January 2006 14 743 Requirements for the Automatically Switched Optical 744 Network (ASON)," June 2002. 746 [G.7715.1] ITU-T Draft Rec. G.7715.1/Y.1706.1, "ASON Routing 747 Architecture and Requirements for Link State Protocols," 748 November 2003. 750 [G.8080] ITU-T Rec. G.8080/Y.1304, "Architecture for the 751 Automatically Switched Optical Network (ASON)," 752 November 2001 (and Revision, January 2003). 754 11. Author's Addresses 756 Lyndon Ong (Ciena Corporation) 757 PO Box 308 758 Cupertino, CA 95015 , USA 759 Phone: +1 408 705 2978 760 EMail: lyong@ciena.com 762 Dimitri Papadimitriou (Alcatel) 763 Francis Wellensplein 1, 764 B-2018 Antwerpen, Belgium 765 Phone: +32 3 2408491 766 EMail: dimitri.papadimitriou@alcatel.be 768 Jonathan Sadler 769 1415 W. Diehl Rd 770 Naperville, IL 60563 771 EMail: jonathan.sadler@tellabs.com 773 Stephen Shew (Nortel Networks) 774 PO Box 3511 Station C 775 Ottawa, Ontario, CANADA K1Y 4H7 776 Phone: +1 613 7632462 777 EMail: sdshew@nortelnetworks.com 779 Dave Ward (Cisco Systems) 780 170 W. Tasman Dr. 781 San Jose, CA 95134 USA 782 Phone: +1-408-526-4000 783 EMail: dward@cisco.com 785 C.Hopps et al. - Expires January 2006 15 786 Appendix 1: ASON Terminology 788 This document makes use of the following terms: 790 Administrative domain: (see Recommendation G.805) for the purposes of 791 [G7715.1] an administrative domain represents the extent of resources 792 which belong to a single player such as a network operator, a service 793 provider, or an end-user. Administrative domains of different players 794 do not overlap amongst themselves. 796 Control plane: performs the call control and connection control 797 functions. Through signaling, the control plane sets up and releases 798 connections, and may restore a connection in case of a failure. 800 (Control) Domain: represents a collection of (control) entities that 801 are grouped for a particular purpose. The control plane is subdivided 802 into domains matching administrative domains. Within an 803 administrative domain, further subdivisions of the control plane are 804 recursively applied. A routing control domain is an abstract entity 805 that hides the details of the RC distribution. 807 External NNI (E-NNI): interfaces are located between protocol 808 controllers between control domains. 810 Internal NNI (I-NNI): interfaces are located between protocol 811 controllers within control domains. 813 Link: (see Recommendation G.805) a "topological component" which 814 describes a fixed relationship between a "subnetwork" or "access 815 group" and another "subnetwork" or "access group". Links are not 816 limited to being provided by a single server trail. 818 Management plane: performs management functions for the Transport 819 Plane, the control plane and the system as a whole. It also provides 820 coordination between all the planes. The following management 821 functional areas are performed in the management plane: performance, 822 fault, configuration, accounting and security management 824 Management domain: (see Recommendation G.805) a management domain 825 defines a collection of managed objects which are grouped to meet 826 organizational requirements according to geography, technology, 827 policy or other structure, and for a number of functional areas such 828 as configuration, security, (FCAPS), for the purpose of providing 829 control in a consistent manner. Management domains can be disjoint, 830 contained or overlapping. As such the resources within an 831 administrative domain can be distributed into several possible 832 overlapping management domains. The same resource can therefore 833 belong to several management domains simultaneously, but a management 834 domain shall not cross the border of an administrative domain. 836 Subnetwork Point (SNP): The SNP is a control plane abstraction that 837 represents an actual or potential transport plane resource. SNPs (in 839 C.Hopps et al. - Expires January 2006 16 840 different subnetwork partitions) may represent the same transport 841 resource. A one-to-one correspondence should not be assumed. 843 Subnetwork Point Pool (SNPP): A set of SNPs that are grouped together 844 for the purposes of routing. 846 Termination Connection Point (TCP): A TCP represents the output of a 847 Trail Termination function or the input to a Trail Termination Sink 848 function. 850 Transport plane: provides bi-directional or unidirectional transfer 851 of user information, from one location to another. It can also 852 provide transfer of some control and network management information. 853 The Transport Plane is layered; it is equivalent to the Transport 854 Network defined in G.805 Recommendation. 856 User Network Interface (UNI): interfaces are located between protocol 857 controllers between a user and a control domain. Note: there is no 858 routing function associated with a UNI reference point. 860 C.Hopps et al. - Expires January 2006 17 861 Appendix 2: ASON Routing Terminology 863 This document makes use of the following terms: 865 Routing Area (RA): a RA represents a partition of the data plane and 866 its identifier is used within the control plane as the representation 867 of this partition. Per [G.8080] a RA is defined by a set of sub- 868 networks, the links that interconnect them, and the interfaces 869 representing the ends of the links exiting that RA. A RA may contain 870 smaller RAs inter-connected by links. The limit of subdivision 871 results in a RA that contains two sub-networks interconnected by a 872 single link. 874 Routing Database (RDB): repository for the local topology, network 875 topology, reachability, and other routing information that is updated 876 as part of the routing information exchange and may additionally 877 contain information that is configured. The RDB may contain routing 878 information for more than one Routing Area (RA). 880 Routing Components: ASON routing architecture functions. These 881 functions can be classified as protocol independent (Link Resource 882 Manager or LRM, Routing Controller or RC) and protocol specific 883 (Protocol Controller or PC). 885 Routing Controller (RC): handles (abstract) information needed for 886 routing and the routing information exchange with peering RCs by 887 operating on the RDB. The RC has access to a view of the RDB. The RC 888 is protocol independent. 890 Note: Since the RDB may contain routing information pertaining to 891 multiple RAs (and possibly to multiple layer networks), the RCs 892 accessing the RDB may share the routing information. 894 Link Resource Manager (LRM): supplies all the relevant component and 895 TE link information to the RC. It informs the RC about any state 896 changes of the link resources it controls. 898 Protocol Controller (PC): handles protocol specific message exchanges 899 according to the reference point over which the information is 900 exchanged (e.g. E-NNI, I-NNI), and internal exchanges with the RC. 901 The PC function is protocol dependent. 903 C.Hopps et al. - Expires January 2006 18 904 Intellectual Property Statement 906 The IETF takes no position regarding the validity or scope of any 907 Intellectual Property Rights or other rights that might be claimed 908 to pertain to the implementation or use of the technology described 909 in this document or the extent to which any license under such 910 rights might or might not be available; nor does it represent that 911 it has made any independent effort to identify any such rights. 912 Information on the procedures with respect to rights in RFC 913 documents can be found in BCP 78 and BCP 79. 915 Copies of IPR disclosures made to the IETF Secretariat and any 916 assurances of licenses to be made available, or the result of an 917 attempt made to obtain a general license or permission for the use 918 of such proprietary rights by implementers or users of this 919 specification can be obtained from the IETF on-line IPR repository 920 at http://www.ietf.org/ipr. 922 The IETF invites any interested party to bring to its attention any 923 copyrights, patents or patent applications, or other proprietary 924 rights that may cover technology that may be required to implement 925 this standard. Please address the information to the IETF at 926 ietf-ipr@ietf.org. 928 Disclaimer of Validity 930 This document and the information contained herein are provided on 931 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 932 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 933 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 934 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 935 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 936 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 938 Copyright Statement 940 Copyright (C) The Internet Society (2006). This document is subject 941 to the rights, licenses and restrictions contained in BCP 78, and 942 except as set forth therein, the authors retain all their rights. 944 Acknowledgment 946 Funding for the RFC Editor function is currently provided by the 947 Internet Society. 949 C.Hopps et al. - Expires January 2006 19