idnits 2.17.1 draft-ietf-ipo-optical-inter-domain-02.txt: -(258): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(312): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(333): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(770): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(888): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == There are 27 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 26 longer pages, the longest (page 2) being 69 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 28 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 82 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 1102: '... network MUST be willing to advertis...' RFC 2119 keyword, line 1107: '...ipating carriers MUST agree to fairly ...' RFC 2119 keyword, line 1110: '...carrier claiming those exceptions MUST...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 952 has weird spacing: '...Deleted of o...' -- 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 (February 2003) is 7738 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'G.805' on line 797 -- Looks like a reference, but probably isn't: 'G.803' on line 798 -- Looks like a reference, but probably isn't: 'GB-WDM-SRLG' on line 803 -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' == Outdated reference: A later version (-05) exists of draft-ietf-ipo-impairments-00 ** Downref: Normative reference to an Informational draft: draft-ietf-ipo-impairments (ref. '5') == Outdated reference: A later version (-19) exists of draft-ietf-isis-gmpls-extensions-16 ** Downref: Normative reference to an Informational draft: draft-ietf-isis-gmpls-extensions (ref. '6') == Outdated reference: A later version (-06) exists of draft-ietf-mpls-bundle-04 -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Normative reference to a draft: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '14' Summary: 11 errors (**), 0 flaws (~~), 8 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group G. Bernstein 2 Internet Draft Grotto-Networking 3 Expiration Date: August 2003 B. Rajagopalan 4 Document: draft-ietf-ipo-optical-inter-domain-02.txt D. Pendarakis 5 Tellium 6 Angela Chiu 7 John Strand 8 AT&T 9 V. Sharma 10 Metanoia 11 Dean Cheng 12 Polaris 13 Rauf Izmailov 14 NEC 15 Lyndon Ong 16 Ciena 17 Sudheer Dharanikota 18 Frank Hujber 20 February 2003 22 Optical Inter Domain Routing Considerations 24 Status of this Memo 26 This document is an Internet-Draft and is in full conformance with 27 all provisions of Section 10 of RFC2026 [1]. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. Internet-Drafts are draft documents valid for a maximum of 33 six months and may be updated, replaced, or obsoleted by other 34 documents at any time. It is inappropriate to use Internet- Drafts 35 as reference material or to cite them other than as "work in 36 progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 Abstract 44 This draft investigates the requirements for general inter-domain 45 and inter-area routing in optical networks and reviews the 46 applicability of existing route protocols in various optical routing 47 applications. 49 Table of Contents: 50 1 Introduction 2 51 1.1 Specification of Requirements 3 52 1.2 Abbreviations 3 54 draft-ipo-optical-inter-domain-02.txt February 2003 56 2 Background 3 57 2.1 Basic Concept of Domains and Network Partitioning 3 58 2.2 Major Differences between Optical and IP datagram Routing 59 6 60 2.3 Differences between MPLS and Optical Circuit routing 7 61 2.4 Diversity in Optical Routing 7 62 2.4.1 Generalizing Link Diversity 9 63 2.4.2 Generalizing Node Diversity 9 64 2.5 Routing Information Categorization 10 65 2.5.1 Link and Topology Related Information 10 66 2.5.2 Domain and Node Related Information 11 67 3 Applications of Inter Domain Optical Routing 12 68 3.1 Intra Carrier Applications of Optical Inter Domain Routing 69 12 70 3.1.1 Intra-Carrier Scalability 12 71 3.1.2 Intra-Carrier Inter-vendor 13 72 3.1.3 Inter-Layer Partitioning 16 73 3.1.4 Interaction with IP Layer Routing 17 74 3.1.5 Inter-Business Unit 18 75 3.2 Inter-Carrier Inter-Domain Optical Routing 19 76 3.3 Multi-Domain Connection Control 21 77 4 Multiple Layers of Optical Routing 22 78 5 Conclusion 24 79 6 Security Considerations 24 80 6.1.1 24 81 7 References 25 82 8 Acknowledgments 26 83 9 Author's Addresses 26 85 NOTE: This draft has been updated with more current author contact 86 information and references, but is otherwise unchanged from the 87 previous version. 89 1 Introduction 91 Multi Protocol Label Switching (MPLS) has received much attention 92 recently for use as a control plane for non-packet switched 93 technologies. In particular, optical technologies have a need to 94 upgrade their control plane as reviewed in reference [2]. Many 95 different optical switching and multiplexing technologies exist and 96 more are sure to come. For the purposes of this draft we only 97 consider non-packet (i.e. circuit switching) forms of optical 98 switching. 99 As the requirements for and extensions to interior gateway protocols 100 such as OSPF and IS-IS have begun to be investigated in the single 101 area case, e.g., reference [3], we consider the requirements that 102 optical networking and switching impose in the inter-domain case. 104 First we explore the definition of a control domain and its use in 105 optical and transport networking. This is explored again later in 106 the document when we consider a number of important applications, 107 networking scenarios, where the notions of inter-control domain 108 routing are important. We review the various differences between 109 routing in the datagram case, the virtual circuit case and the 110 (real) optical circuit case. Then we look at the optical path 111 selection/computation needs to provide for path diversity, switching 113 draft-ipo-optical-inter-domain-02.txt February 2003 115 capabilities, transport capabilities and impairments, and 116 bandwidth/resource status reporting. 118 To add to the concreteness of these considerations we try to 119 illustrate them with one or more specific examples from a particular 120 optical networking layer or technology. This is not to reduce the 121 generality of the requirement but to facilitate the understanding of 122 the requirement or concept. 124 1.1 Specification of Requirements 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 127 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 128 this document are to be interpreted as described in RFC 2119. 130 1.2 Abbreviations 132 LSP Label Switched Path (MPLS terminology) 133 LSR Label Switched Router (MPLS terminology) 134 MPLS Multiprotocol Label Switching 135 SDH Synchronous Digital Hierarchy (ITU standard) 136 SONET Synchronous Optical NETwork (ANSI standard) 137 STM(-N) Synchronous Transport Module (-N) 138 STS(-N) Synchronous Transport Signal-Level N (SONET) 139 TU-n Tributary Unit-n (SDH) 140 TUG(-n) Tributary Unit Group (-n) (SDH) 141 VC-n Virtual Container-n (SDH) 142 VTn Virtual Tributary-n (SONET) 144 2 Background 146 2.1 Basic Concept of Domains and Network Partitioning 148 In this draft we use the term domain in a general sense, i.e., 149 beyond the BGP interpretation of an Autonomous System. In this 150 draft we will consider domains as the result of partitioning of a 151 network into subnetworks, as shown in the network of Figure 1. A 152 network may be partitioned for a variety of reasons, such as: 153 * Administrative boundaries 154 * Scalability of routing or signaling 155 * Isolation of partitions for security or reliability reasons 156 * Technology differences in the systems in different domains 158 /------------------------------------\ 159 / \ 160 / /-\ \ 161 | Domain |NE2|<--Internal Node | 162 | B /\-/\ | 163 | / \ | 164 | /-\/ \/-\ | 166 draft-ipo-optical-inter-domain-02.txt February 2003 168 | |NE1|-------|NE3| / 169 \+------\-/ \-/ / 170 /\ | | / 171 / \------+-----------+-----------------/ 172 / | |<--- Inter-Domain Links 173 / /------+-----------+-----------------\ 174 | / | | \ 175 | / | /-\ | /-\ \ 176 | | Domain | |NE2|---+---------|NE3| | 177 | | A | /\-/\ | ------/\-/ | 178 | | | / \ | / | | 179 | | /-\/ \/-\/ | | 180 | | |NE1|-------|NE5|---- | / 181 | \ -- \-/ \-/ \ /-\ / 182 | \ / | | --|NE4| / 183 | \/ | | \-/ / 184 | /\-----+-----------+----------------/ 185 Border Nodes | |<--- Inter-Domain Links 186 \ |<----------+---- (External Links) 187 /\------+-----------+-----------------\ 188 / \ | | \ 189 / \ /-\ /-\ | 190 | --|NE1|-----|NE2| | 191 | \-/ \-/ | 192 | Domain | |<--- Intra-Domain | 193 | C | | Links (Internal| 194 | /-\ /-\ Links) | 195 | |NE3|-----|NE3| | 196 | \-/ \-/ | 197 \ / 198 \------------------------------------/ 200 Figure 1. Partitioning a network into domains. 202 The Inter-Domain interface is likely to have different 203 characteristics than the Intra-Domain interface as the domain 204 boundary exists for the purpose of hiding some aspect within the 205 domain from the outside world. 207 For the remainder of this draft we will be concerned with "control 208 domains" that is a control domain will be hiding the internal 209 details of its control plane from other control domains. This 210 definition has a number of important ramifications when we consider 211 inter-domain protocols for routing or signaling. 213 1. Inter-control domain routing or signaling is required to be 214 independent of a control domain�s internal signaling or route 215 protocol or lack of either a signaling or routing protocol. This 216 is sometimes referred to as the "domain independence" property. 218 draft-ipo-optical-inter-domain-02.txt February 2003 220 2. Inter-control domain routing or signaling can not count on 221 specific protocols being implemented within the domain. 222 3. Inter-control domain routing or signaling can not require that a 223 network element participate in the internal protocols of two 224 different control domains. This is sometimes refered to as 225 "boundary on the wire" property. 226 4. The Inter-control domain routing or signaling protocol does not 227 require that the control domains be interconnected in any 228 particular fashion (except for general graph connectivity). 230 Example #1 (inter-control domain routing) 231 Consider a collection of BGP Autonomous Systems (AS). Each of these 232 may run their own internal IGP. Of these internal IGPs, OSPFv2 and 233 IS-IS are very popular but also incompatible with each other. 234 BGP does not rely on the Autonomous Systems running a particular 235 IGP, i.e., OSPF or IS-IS. Hence it meets the definition of an 236 inter-control domain routing protocol. Note that nothing prevents 237 BGP from being used within an ISP to glue together islands of 238 incompatible IGPs. In fact, the availability of private AS numbers 239 can help in this situation. 241 Example #2 (OSPF Areas) 242 An OSPF Area, on the other hand, is a mechanism within OSPF for 243 providing scalability. It assumes that within each OSPF area that 244 OSPF is being run in addition it requires that all border routers 245 participate in both the backbone area and one or more other their 246 own areas. Hence OSPF with its area concept equated with a control 247 domain doesn't meet the definition of an inter-control domain 248 routing protocol in two ways. It would require OSPF to run within 249 the domains and it requires that a network element (router) 250 participate in the internal routing protocol of two separate 251 domains. 253 Example #3 (PNNI routing Peer Groups) 254 With ATM's PNNI routing hierarchy the concept of a peer group is 255 introduced. PNNI with peer groups does not meet the definition of an 256 a inter-control domain routing protocol since it, like OSPF, 257 requires that within a peer group ATM PNNI routing is running. 258 However, it doesn�t require that border members of a peer group at a 259 given level in the hierarchy participate in the internal protocols 260 of both peer groups. In other words PNNI's hierarchical routing 261 allows for a "boundary on the wire" model. 263 draft-ipo-optical-inter-domain-02.txt February 2003 265 The domain concept as used here is orthogonal to the transport 266 network concept of layering. When the term layer is used with 267 respect to the transport network we are not referring to the 7- 268 layer OSI model which includes application, presentation, etc., 269 layers. With regard to this model all the optical transport layers 270 would lie at the "physical layer". In the transport network, layers 271 are used for multiplexing, performance monitoring and fault 272 management purposes. Layers tend to be very technology specific. At 273 some point an optical routing protocol must include information 274 particular to the technology layer for which it is being used to 275 acquire/disseminate topology and resource status information. For 276 more information on layering and domain concepts see ITU-T 277 recommendation G.805 [14]. 279 2.2 Major Differences between Optical and IP datagram Routing 281 Let us first review the major difference between routing for optical 282 (circuit switched networks) and IP datagram networks. In IP 283 datagram networks packet forwarding is done on a hop-by-hop basis 284 for each packet(no connection established ahead of time), while in 285 circuit switched optical networks end-to-end connections must be 286 explicitly established based on network topology and resource status 287 information. This topology and resource status information can be 288 obtained via routing protocols. Note that the routing protocols in 289 the circuit switch case are not involved with data (or bit) 290 forwarding, i.e., they are not "service impacting", while in the IP 291 datagram case the routing protocols are explicitly involved with 292 data plane forwarding decisions and hence are very much service 293 impacting. Note that signaling or label distribution protocols that 294 set up or tear down the virtual or real circuits are service 295 impacting. 297 This does not imply routing is unimportant in the optical case, only 298 that its service impacting effect is secondary. For example, 299 topology and resource status inaccuracies will affect whether a new 300 connection can be established (or a restoration connection can be 301 established) but will not (and should not) cause an existing 302 connection to be torn down. 304 This tends to lead to a slightly different view towards 305 incorporating new information fields (objects, LSA, etc.) into 306 optical routing protocols versus IP routing protocols. In the 307 optical circuit case, any information that can potentially aid in 308 route computations or be used in service differentiation may be 309 incorporated into the route protocol, as either a standard element 310 or a vendor specific extension. Whether a route computation 311 algorithm uses this information and whether two route computation 312 algorithms use this information in the same way doesn�t matter since 313 the optical connections are explicitly routed (although perhaps 314 loosely). 316 draft-ipo-optical-inter-domain-02.txt February 2003 318 Path selection or route computation in transport case may be based 319 on a different criteria or combination of criteria on a per path 320 basis. For example one connection may requests the lowest economic 321 cost available path while another may request the highest 322 reliability path. One important evaluation criteria for any proposed 323 inter-domain optical routing protocol is the variety of path 324 selection criteria with which it may work. 326 2.3 Differences between MPLS and Optical Circuit routing 328 The bandwidth accounting needed in optical circuit-switched networks 329 is also different than in packet networks. In packet networks using 330 either ATM QoS or MPLS-TE, complex statistical measures are used to 331 characterize the load on a link, often with varying degrees of 332 accuracy. The inexactness of such measures and the 333 ��compressibility�� of statistically multiplexed traffic imply that a 334 small percentage change in link utilization can usually be absorbed 335 by the network. 337 By contrast, if an OC-192 link has just one STS-1 path occupied 338 (less than 1% of the link bandwidth), it cannot accommodate an STS- 339 192c path. Due to the relatively simple finite multiplex structures 340 currently use in optical networks tracking bandwidth resources is 341 much easier than packet switched networks, however much stricter 342 bandwidth accounting is required on circuit switched links. In 343 particular, it is expected that an individual optical circuit 344 switched link can be fully utilized, while due to queuing effects a 345 packet switched link on average can never be run at full capacity 346 and is typically run at less then 80% of capacity. This also 347 affects how protection (or restoration) bandwidth can be committed. 348 In a packet-based network, while the protection path can be 349 preconfigured, resources along it are not used until a failure 350 occurs. In circuit-based networks, a protection path generally 351 implies a committed resource. Such basic differences restrict the 352 direct applicability of some of the traffic engineering mechanisms 353 used in packet-switched networks to circuit-switched networks. 355 2.4 Diversity in Optical Routing 357 There are two basic demands that drive the need to discover diverse 358 routes for establishing optical paths: 359 1. Reliability/Robustness 360 2. Bandwidth capacity. 362 Many times multiple optical connections are set up between the same 363 end points. An important constraint on these connections is that 364 they must be diversely routed in some way [4]. In particular they 365 could be routed over paths that are link diverse, i.e., two 366 connections do not share any common link. Or the more stringent 367 constraint that the two paths should be node diverse, i.e., the two 368 paths do not traverse any common node. 370 draft-ipo-optical-inter-domain-02.txt February 2003 372 Additionally, insufficient bandwidth may exist to set up all the 373 desired connection across the same path (set of links) and hence we 374 need to know about alternative (diverse) ways of reaching the 375 destination that may still have unused capacity. 377 "Diversity" is a relationship between lightpaths. Two lightpaths are 378 said to be diverse if they have no single point of failure. In 379 traditional telephony the dominant transport failure mode is a 380 failure in the interoffice plant, such as a fiber cut inflicted by a 381 backhoe. 383 Data network operators have relied on their private line providers 384 to ensure diversity and so IP routing protocols have not had to deal 385 directly with the problem. GMPLS makes the complexities handled by 386 the private line provisioning process, including diversity, part of 387 the common control plane and so visible to all. 389 Diversity is discussed in the IPO WG document [5]. A key associated 390 concept, "Shared Risk Link Groups", is discussed in a number of 391 other IETF (refs) and OIF (refs) documents. Some implications for 392 routing that are drawn in [5] are: 393 . Dealing with diversity is an unavoidable requirement for 394 routing in the optical layer. It requires dealing with 395 constraints in the routing process but most importantly 396 requires additional state information -- the SRLG relationships 397 and also the routings of any existing circuits from which the 398 new circuit is to be diverse -- to be available to the routing process. 400 . At present SRLG information cannot be self-discovered. Indeed, 401 in a large network it is very difficult to maintain accurate 402 SRLG information. The problem becomes particularly daunting 403 whenever multiple administrative domains are involved, for 404 instance after the acquisition of one network by another, 405 because there normally is a likelihood that there are diversity 406 violations between the domains. It is very unlikely that 407 diversity relationships between carriers will be known any time 408 in the near future. 410 - Considerable variation in what different customers will mean by 411 acceptable diversity should be anticipated. Consequently we suggest 412 that an SRLG should be defined as follows: (i) It is a relationship 413 between two or more links, and (ii) it is characterized by two 414 parameters, the type of compromise (shared conduit, shared ROW, 415 shared optical ring, etc.) and the extent of the compromise (e.g., 416 the number of miles over which the compromise persisted). This will 417 allow the SRLG�s appropriate to a particular routing request to be 418 easily identified. 420 draft-ipo-optical-inter-domain-02.txt February 2003 422 2.4.1 Generalizing Link Diversity 424 Optical networks may posses a number of hierarchical signaling 425 layers. For example two routers interconnected across an optical 426 network may communicate with IP packets encapsulated within an STS- 427 48c SONET path layer signal. Within the optical network this STS- 428 48c signal may be multiplexed at the SONET line layer into an OC-192 429 line layer signal. In addition this OC-192 may be wavelength 430 division multiplexed onto a fiber with other OC-192 signals at 431 different wavelengths (lambdas). These WDM signals can then be 432 either lambda switched, wave band switched or fiber switched. Hence 433 when we talk about diversity we need to specify the layer to which 434 we are referring. In the previous example we can talk about 435 diversity with respect to the SONET line layer, wave bands, and/or 436 optical fibers. A similar situation arises when we consider the 437 definition of node diversity. For example are we talking with 438 respect to a SONET path layer switch or an optical switch or 439 multiplexer? 441 The Shared Risk Link Group concept in reference [6] generalizes 442 the notion of link diversity (general list of numbers). First it's 443 useful with respect to major outages (cable cuts, natural disasters) 444 to have a few more types of diversity defined: 446 1. Cable (conduit) diversity (allows us to know which fibers 447 are in the same cable (conduit). This helps avoid sending 448 signals over routes that are most vulnerable to "ordinary" 449 cable cuts (technically known as backhoe fades). 451 2. Right of Way (ROW) diversity. This helps avoid sending 452 signals over routes that are subject to larger scale 453 disasters such as ship anchor drags, train derailments, etc. 455 3. Geographic Route diversity. This type of diversity can help 456 one avoid sending signals over routes that are subject to 457 various larger scale disasters such as earthquakes, floods, 458 tornadoes, hurricanes, etc. A route could be approximately 459 described by a piecewise set of latitude/longitude or UTM 460 coordinate pairs. 462 We also have a form of link abstraction/summarization via the link 463 bundling concept [7]. 465 2.4.2 Generalizing Node Diversity 467 The concept of a node abstraction associated with GMPLS appears in 468 reference [11] where it is used to generalize the concept of an 469 explicitly routed path. In this case an abstract node can be a set 470 of IP addresses or an AS number. From the point of view of node 471 diverse routing specific concepts of interest include: 472 1. Nodes, i.e., individual switching elements. 473 2. Switching centers, i.e., a central office or exchange site. 474 3. Cities, or towns that contain more that one switching center. 476 draft-ipo-optical-inter-domain-02.txt February 2003 478 4. Metro areas, or counties 479 5. States, 480 6. Countries, or 481 7. Geographic Regions 483 2.5 Routing Information Categorization 484 Different applications of inter-domain optical routing call for 485 different types of information to be shared or hidden between 486 domains. In the following we decompose the information that can be 487 transferred via a routing protocol broadly into link/topology 488 information and node/domain information. We further subdivide these 489 categories and will use this taxonomy of routing information when 490 discussing the routing applications. 492 2.5.1 Link and Topology Related Information 493 -Internal topology- information is information concerning the nodes 494 and links and their connectivity within a domain. This type of 495 information is traditionally shared within a domain via an intra- 496 domain (interior gateway) routing protocol such as OSPF or IS-IS 497 within a single area. For example the existence of nodes that only 498 have links to other nodes within the domain, i.e., do not have links 499 to other domains, would be strictly internal topology information. 500 These nodes are known as internal nodes, while nodes with links to 501 other domains are known as border nodes. Also included in this 502 information is link/port property information such as whether the 503 link is protected and what type of protection is being used, e.g., 504 linear 1+1, linear 1:N, or some type of ring such as a 4F-BLSR [cite 505 T1 document]. 507 -Internal Resource- Information is concerned with the bandwidth 508 available on links within a domain and possibly other resource 509 related information. This information plays an important role in 510 path selection within a domain. 512 -Inter-Domain Topology- Information is concerned with how the 513 domains are interconnected. This information can be key in inter- 514 domain path selection, for example, in determining diverse routes. 515 For the network in Figure 1 this information would let us know that 516 domain A has two distinct links to domain B, domain A has two 517 distinct links to domain C, but that domains B and C are not 518 directly connected via any links. 520 -Inter-Domain Resource- Information is concerned with the available 521 bandwidth on inter-domain links. This information is important for 522 inter-domain path selection and inter-domain traffic engineering 523 purposes. For example in Figure 1 this information would give us 524 some kind of bandwidth or capacity measure on the links between 526 draft-ipo-optical-inter-domain-02.txt February 2003 528 domain A and domain B, and the links between domains A and C. The 529 exact nature of this information may be application/context 530 dependent. 532 2.5.2 Domain and Node Related Information 533 -Reachability- information tells us what addresses are directly 534 reachable via a particular domain. These systems can be end systems 535 (clients) to the network or nodes within the network depending upon 536 the application/context. Suppose in domain B of Figure 1 each of 537 the network elements, NE1-NE3, have subtending end systems, and that 538 NE1-NE3 do not represent a valid final destination for a path. Under 539 this assumption the collection of the addresses of all these 540 subtending end systems would form the reachability information for 541 domain B. 542 -Subnetwork Capability- information is concerned with the 543 capabilities or features offered by the domain as a whole. This 544 information is used in some applications where sharing the internal 545 topology and resource information is inappropriate. This information 546 can include: (a) Switching capabilities, (b) Protection 547 capabilities, (c) Some kind of overall available capacity measure, 548 (d) Reliability measures. 549 Examples: 550 1. For example, in the SONET realm, one subnetwork may switch down 551 to an STS-3c granularity while another switches down to an STS- 552 1 granularity. Understanding what types of signals within a 553 SDH/SONET multiplex structure can be switched by a subnetwork 554 is important. Similar examples of granularity in switching 555 apply to the waveband case. 556 2. Some networking technologies, particularly SONET/SDH, provide a 557 wide range of standardized protection technologies. But not all 558 domains will offer all protection options. For example, a 2/4- 559 F BLSR based subnetwork could offer extra data traffic, ring 560 protected traffic and non-preemptible unprotected traffic, 561 (NUT)[8], while a mesh network might offer shared SONET line 562 layer linear protection and some form of mesh protection. 563 3. Some domains may be in locations that have lower incidences of 564 link failure. Such information could be helpful in computing 565 routes to statistically "share the pain". 567 -End System Capabilities- information: While properties of the 568 subnetwork are very important when trying to decide which domain to 569 use to access a system (in the case of multi-homing), end systems 570 also posses a wide variety of capabilities. Throwing end system 571 capabilities such as a system's ability to support SONET/SDH virtual 572 concatenation for distribution into a routing protocol may not be 573 that advantageous since it somewhat counters the ability to 575 draft-ipo-optical-inter-domain-02.txt February 2003 577 summarize reachability information. Detailed end-system information 578 may alternatively be obtained via a directory service or some type 579 of direct query between the end systems. 581 3 Applications of Inter Domain Optical Routing 583 In this section we review some of the main applications of optical 584 inter-control domain routing. We also review which aspects of the 585 definition of control domain is most relevant to the application. 587 3.1 Intra Carrier Applications of Optical Inter Domain Routing 589 Intra Carrier inter domain routing refers to a situation where the 590 network that is to be partitioned into areas is under the control of 591 one administrative entity. The main reasons for this partitioning in 592 optical networks stem from scalability, inter-vendor 593 interoperability, legacy equipment interoperability, and inter-layer 594 partitioning. 596 3.1.1 Intra-Carrier Scalability 597 As networks grow it is useful to partition a carriers network into 598 separate optical routing domains which share limited or summarized 599 information amongst each other. This reduces the overhead of 600 information exchange across the network as a whole, and reduces the 601 convergence time of routing protocols within a particular area. 602 Hence we see in the inter-carrier scalability application that we 603 will hide or summarize internal topology and resource information, 604 while completely sharing inter-domain topology and resources 605 information so that diverse paths can still be calculated. Note that 606 general domain capabilities/capacity as well as reachability 607 information would tend to be shared as completely as possible. For 608 example the network shown in Figure 1 can be approximately 609 represented as shown in Figure 2. This summarized network topology 610 only has 4 links whose state need to be advertised in a routing 611 protocol versus 17 links in the original network. Note that we may 612 also advertise the capabilities of the three domains in Figure 2 as 613 opposed to the 12 nodes of Figure 1. In Note that this partitioning 614 into domains can recurse, i.e., we can have multiple levels of 615 routing hierarchy to permit larger and larger networks. Such was 616 the motivation behind the extensive hierarchical routing capability 617 within ATM's PNNI routing protocol. The trade off to partitioning 618 into domains for scalability is that less information is available 619 for use in the route selection process, which can lead to 620 inefficient utilization of network resources. On the other hand 621 frequently this partitioning occurs on somewhat "natural" boundaries 622 and as such the potential inefficiencies can be minimized. 624 -------- ------ 626 draft-ipo-optical-inter-domain-02.txt February 2003 628 /- -\ /- -\ ----- 629 // NE 3 \mmmmmm // \\ / \ 630 / Port 2 \ mmmmm NE 3 NE 5 \ /NE 3 \ 631 / \ / Port 4 Port 6 \ mmmmmPort 17 \ 632 | | | mmmmm | | 633 | | | | | | 634 | | | Domain A | | Domain C | 635 | Domain B | | | | | 636 | | | NE 2 NE 1 | | | 637 | | |Port 5 Port 2 mmmmmmmmmNE 1 | 638 | mmm / \Port 21 / 639 \ NE 1 /mmmm \ / \ / 640 \ Port 7 mm \\ // \ / 641 \\ // \- -/ ----- 642 \- -/ ------ 643 -------- 644 Figure 2. Summarized topology for the network of Figure 1. 646 Also in Figure 2 we show the end points of the links between being 647 identified by the triple of (domain, NE address, NE port number). 648 This information is available via the discovery process. Though not 649 strictly necessary including the identification of border nodes in a 650 domain, allowing other nodes to understand whether these links 651 terminate on the same or different nodes is valuable in setting up 652 diverse inter-domain paths. 653 In current intra-domain IP routing protocols, such as OSPF's, a 654 multiple area capability provides for intra-carrier scalability. 655 However, this is currently done by sharing reachability information 656 and using a distance-vector method to obtain routes. This does not 657 discover and propagate inter-domain topology information and hence 658 insufficient information is available for diverse route 659 calculations. In addition OSPF areas are required to be assembled in 660 a particular fashion with all areas bordering on a single backbone 661 area. 662 When the topology within the domain is approximated or hidden then 663 signaling and call processing at the domain border will receive an 664 approximated (loose) route and the border node or signaling entity 665 must then translate this to a precise route through the domain. 666 Hence there is some linkage between multi-domain connection control 667 and inter-area/inter-domain routing. 669 3.1.2 Intra-Carrier Inter-vendor 670 An important application of intra-carrier optical routing is the 671 intra-carrier inter-vendor scenario. From a carrier�s perspective, 672 the use of domains provides a clean way to isolate clouds of 674 draft-ipo-optical-inter-domain-02.txt February 2003 676 equipment belonging to different vendors, while at the same time 677 allowing for interoperability between the vendors. 678 An advantage of this method is that it allows the vendors complete 679 freedom to use any combination of routing protocols or traditional 680 management-based methods to propagate topology and resources 681 internal to their domains. In other words, the routing entity in 682 each domain could obtain this information either by participating in 683 a routing protocol like OSPF, or by querying each NE via an EMS, or 684 by simply having the required information manually configured into 685 it. Here the "domain independence" and "boundary on the wire" 686 properties of an inter-control domain routing protocol are being 687 stressed. 689 Note that the routing entity shown in each vendor�s cloud in Figure 690 3 is in reality an abstract representation of the routing 691 intelligence within the vendor cloud. This intelligence may either 692 be implemented in a distributed way, by having a routing protocol 693 running at each NE, or in a centralized way, through the use of an 694 intelligent, centralized routing entity that communicates with the 695 individual NE�s (either via a protocol or by querying individual 696 elements) to retrieve connectivity and resource information that it 697 uses to build a complete topology and resource map of the domain. 698 Therefore, vendors may use different protocols as the primary option 699 between their own devices, adding specialized features or optimizing 700 their performance based on their choice of protocol. 701 /------------------------------------\ 702 / /-\ \ 703 / Domain B |NE3| +-------+ \ 704 | (Vendor 2) /\-/\ |Routing| | 705 | / \ |Entity | | 706 | /-\/ \/-\ +-------+ | 707 \ |NE1|-------|NE2| @ / 708 \ \-/: \-/ @ / 709 \------+-:---------+---------@-------/ 710 Neighbor discovery | : | @ Exchange of routing 711 Between NEs in the | : | @ information between 712 same domain. ----> | : | @ the domains routing 713 | : | @ entities. 714 /------+-:---------+---------@-------\ 715 / | : | @ \ 716 / /-\ /-\ +-------+ \ 717 | |NE1|-----|NE2| |Routing| | 718 | \-/\ /\-/ |Entity | | 719 | \/-\/ +-------+ | 720 | Domain A |NE3| | 721 | (Vendor 1) \-/ / 722 \ / 723 \------------------------------------/ 725 draft-ipo-optical-inter-domain-02.txt February 2003 727 Figure 3. Intra-Carrier Inter-vendor routing domains 728 Even if it is a centralized entity, the routing entity could still 729 be run on a given NE in the vendor cloud. In other words, these 730 entities could be distributed, or centralized onto a single node, or 731 independent of any of the nodes. In ATM's PNNI protocol, for 732 example, this was centralized on a node elected as the "peer group 733 leader". In the inter-vendor case, it can be particularly 734 advantageous to centralize this so that the flow of information can 735 be monitored. A centralized routing entity could apply flooding and 736 summarization mechanisms as if it is a switching system. Since this 737 is optical rather than IP routing, signaling would be carried by a 738 control channel between the routing entity and the neighboring 739 system, rather than being carried over the data links. The functions 740 of the routing entity include: (a) direct reachability exchange 741 (that is, which NE�s can be directly reached from this domain, (b) 742 verification of area connectedness (that is, understanding how the 743 two domains are interconnected), (c) area/domain topology (possibly 744 summarized) exchange and updates, and (d) topology updates 745 concerning other domains/areas. 747 When a carrier partitions its network for inter-vendor 748 interoperability as described above, it may still share information 749 about the internal topology of the domains in some standardized form 750 that has been agreed upon between the vendors. Although one option 751 is to force both vendors to adopt a new common protocol, another is 752 to require that only a minimum subset of reachability/topology 753 information be shared between the vendor clouds. The latter option 754 helps during fault situations, by providing fault isolation at the 755 domain boundaries. It prevents an outage in a domain composed of one 756 vendor�s equipment from causing a reaction in an adjacent domain 757 composed of another vendor�s equipment, thus preventing a situation 758 that would typically degenerate into a process known as ��finger 759 pointing�� between the two vendors. 761 The setup described above takes into account the three most 762 important sub-cases of inter-carrier inter-vendor partitioning: 763 a. The first is where both vendor domains run distributed 764 routing protocols. This is the most flexible case, and is the 765 situation when new equipment capable of running such protocols 766 is deployed. 768 b. The second is where the optical subnetworks or domains 769 (which includes a large number of existing installations) do 770 not run any internal routing protocol (because the NE�s are not 771 capable of doing so), relying instead on EMS-based topology 772 discovery/resource management. In this case, interoperability 774 draft-ipo-optical-inter-domain-02.txt February 2003 776 with other vendor clouds can be realized by having the routing 777 entity run as a separate software entity with access to the 778 appropriate information. These entities may exchange routing 779 proxy addresses through the neighbor discovery protocol, and 780 then exchange routing information (proxying for the entire 781 domain) with each other. The basic advantage here is that even 782 though the vendor specific element management system (EMS) 783 knows the topology of its subnetwork, it is far easier to get 784 an inter-domain routing protocol to share information than 785 trying to get the separate vendors management systems to 786 communicate. 787 c. The third is where one domain has a centralized routing 788 entity, while the other runs a distributed routing protocol. 789 Once again, the neighbor discovery process between the area 790 border NE�s could be used to advertise the address of the 791 routing entity. 793 3.1.3 Inter-Layer Partitioning 794 In transport networks layering is a part of the multiplex and OA&M 795 structure of the signals, playing a role in multiplexing, monitoring 796 and general link management. Layering in the transport network is 797 defined in fairly abstract terms in [G.805] and the concepts are 798 applied to SDH in [G.803]. As explained in a recent ITU SG15 799 document (WD45 Q.14/15) not all the layers in the transport network 800 are of interest to the control plane, or to routing in particular. 801 Some layers may not contain active switching elements, however this 802 does not mean that information flow concerning a non-switching layer 803 is not valuable in routing. For example in [GB-WDM-SRLG] static WDM 804 layer information was used to set the SRLGs for SONET lines (i.e., 805 information passed around by a link state protocol operating at the 806 SONET line layer). It should be noted that much of the information 807 available from non-switching layers relates to performance 808 monitoring and fault management. 810 In this situation the network is partitioned into sub-networks that 811 operate at different switching layers. One reason for doing this is 812 that not all the information from one layer is necessary or relevant 813 to another layer. For example, between transparent optical switches 814 and SDH/SONET path (VC) layer switches, the optical switches have no 815 direct use for the SONET layer information. In addition optical 816 networks may keep a lot more physical layer information (such as the 817 properties of every optical amplifier on a WDM span) that is of no 818 use to the SONET layer. One again this promotes scalability, but 819 also simplifies the implementation by reducing inter-layer 820 information transfer to that which is actually useful. 822 draft-ipo-optical-inter-domain-02.txt February 2003 824 Now in network planning it is very useful to have a view of the 825 current higher layer traffic matrix [9] being satisfied and higher 826 layer traffic trend measurements over time. Although we can 827 somewhat see this in higher layer resource status changes over time, 828 this represents a link level view when we really desire the trend 829 (change in time) of the traffic matrices between sites. How this 830 information gets distributed is an open issue. Currently individual 831 nodes in a GMPLS network know only about connections that they 832 source or sink. Network planning is generally a longer time horizon 833 process than even traffic engineering hence it is an open question 834 as to whether this would ever be a useful function to incorporate 835 into a network element. 837 Now looking the other way is initially simpler, i.e., it is easier 838 to ask: what can a higher layer use for path selection/computation 839 from a lower layer. The first item that springs to mind is diversity 840 information. For example in setting up a SONET STS-1 path we can use 841 information from a WDM system concerning which SONET lines share 842 the same WDM fiber. This is information, however, is already 843 abstracted into routing protocols via SRLG concept. Other 844 information from a lower layer is of questionable value since it 845 tends to be technology specific and puts more and more burden on the 846 upper layer to be able to effectively understand and use this 847 information. 849 3.1.4 Interaction with IP Layer Routing 850 The applicability of IP-based routing protocols has, over the years, 851 been constantly expanded to increasingly more circuit-oriented 852 layers. The community began with pure datagram routing, gradually 853 expanded to cover virtual-circuit switched packet routing (for e.g., 854 MPLS), and is finally looking at the application of routing 855 protocols to real circuit switching, e.g. the optical layer. 857 However, as pointed out earlier in this document, it is not clear 858 that the different layers should necessarily share the same instance 859 of the routing protocols. Indeed, there may be significant reasons 860 for not doing so and many carrier tend to partition their networks 861 along switching layer boundaries. For example, IP-layer reachability 862 information is not particularly useful for the optical layer, so it 863 seems an overkill to burden the optical equipment with storing and 864 distributing that information. (It is an extra expense on memory and 865 processing for information that the optical layer does not really 866 care about, so there is little incentive for a vendor to want to do 867 so.) Likewise, information on physical plant (fibers, conduits, 868 ducts) diversity, which is crucial at the optical transport layer, 869 is very unlikely to be used directly by the IP layer. So, it would 871 draft-ipo-optical-inter-domain-02.txt February 2003 873 be quite wasteful of resources to burden the IP layer routing with 874 distributing and manipulating this information. Thus, the extent of 875 interaction or integration with IP layer routing (if any) requires 876 careful consideration. 878 3.1.5 Inter-Business Unit 880 A slightly different but interesting application of intra-carrier 881 optical routing occurs in the intra-carrier inter-business unit 882 scenario. This arises because a carrier often has multiple 883 administrative domains, with groups of administrative domains being 884 under the purview of independent BU�s within the carrier. 886 Note that different BU�s represent independent cost centers with 887 their own profit objectives and sales targets. As a result, while 888 the BU�s can profitably share topology information and would like to 889 do so, they may not be so inclined to advertise the details of their 890 resource usage into domains belonging to other BUs. Since each BU 891 has its own revenue targets, advertising detailed resource 892 availability information to other, potentially competing, BUs can 893 have a negative impact on a BUs revenue generation. This is because 894 the knowledge of available resources in one BU may enable other BUs 895 within the carrier to requisition capacity from this BU. This would 896 force the BU in question to yield to their request, possibly at the 897 expense of selling capacity to more profitable, external, revenue 898 generating customers. 899 Thus, this scenario is likely to have an additional dimension of 900 information sharing, namely, policy-based information sharing, which 901 does not apply to the other cases that we have discussed so far. 903 Two examples where the inter-business unit scenario could become 904 important are in the case of metro-core-metro networks within a 905 given carrier, and in the case of regional networks within a 906 carrier. 908 In the metro-core-metro situation, such as the one depicted in 909 resource sharing between them. 911 /------------------------------------\ 912 / \ 913 / /-\ \ 914 | Domain |NE2| | 915 Metro BU | B /\-/\<-- Metro Ring | 916 Network | / \ | 917 | /-\/ \/-\ | 918 | |NE1|-------|NE3| / 919 \ \-/ \-/ / 920 \ | | / 922 draft-ipo-optical-inter-domain-02.txt February 2003 924 \------+-----------+-----------------/ 925 | | 926 /------+-----------+-----------------\ 927 / | | \ 928 / | /-\ | /-\ \ 929 | Domain | |NE2|---+---------|NE3| | 930 CORE BU | A | /\-/\ | ------/\-/ | 931 Network | | / \ | / | | 932 | /-\/ \/-\/ |<--Core | 933 | |NE1|-------|NE5|---- | Mesh / 934 \ \-/ \-/ \ /-\ / 935 \ | | --|NE4| / 936 \ | | \-/ / 937 \-----+-----------+----------------/ 938 | | 939 /------+-----------+-----------------\ 940 / | | \ 941 / /-\ /-\ \ 942 | |NE1|-----|NE2| | 943 Metro BU | Domain \-/ \-/ | 944 Network | C | |<--- Metro Ring | 945 | | | | 946 | /-\ /-\ | 947 | |NE3|-----|NE3| | 948 | \-/ \-/ | 949 \ / 950 \------------------------------------/ 952 Figure 4, the metro network domains could be under the jurisdiction Deleted of one BU, while the core network domains belong to a different BU. 953 In this case, for example, it is possible that the metro BU, armed 954 with resource availability information about the core BU�s domains, 955 could requisition capacity from the core network when needed. This 956 may harm the core network�s profit goals, because they may not be 957 able to charge an internal customer the same rates that they could 958 charge for the same capacity from an external customer, thus 959 motivating the need for selective, policy-based resource sharing 960 between them. 962 /------------------------------------\ 963 / \ 964 / /-\ \ 965 | Domain |NE2| | 966 Metro BU | B /\-/\<-- Metro Ring | 967 Network | / \ | 968 | /-\/ \/-\ | 969 | |NE1|-------|NE3| / 970 \ \-/ \-/ / 971 \ | | / 972 \------+-----------+-----------------/ 973 | | 974 /------+-----------+-----------------\ 975 / | | \ 977 draft-ipo-optical-inter-domain-02.txt February 2003 979 / | /-\ | /-\ \ 980 | Domain | |NE2|---+---------|NE3| | 981 CORE BU | A | /\-/\ | ------/\-/ | 982 Network | | / \ | / | | 983 | /-\/ \/-\/ |<--Core | 984 | |NE1|-------|NE5|---- | Mesh / 985 \ \-/ \-/ \ /-\ / 986 \ | | --|NE4| / 987 \ | | \-/ / 988 \-----+-----------+----------------/ 989 | | 990 /------+-----------+-----------------\ 991 / | | \ 992 / /-\ /-\ \ 993 | |NE1|-----|NE2| | 994 Metro BU | Domain \-/ \-/ | 995 Network | C | |<--- Metro Ring | 996 | | | | 997 | /-\ /-\ | 998 | |NE3|-----|NE3| | 999 | \-/ \-/ | 1000 \ / 1001 \------------------------------------/ 1003 Figure 4. Intra-carrier inter-business unit routing domains. 1005 3.2 Inter-Carrier Inter-Domain Optical Routing 1007 In this case we are talking about dealing with outside entities, 1008 i.e., between service providers. There may be a range of levels of 1009 trust here; for example there might be some level of trust between 1010 two providers that have formed a marketing alliance or have some 1011 other form of business relationship. In general, however, trust can 1012 not be assumed. In this case, all the concerns of revealing too much 1013 information about one's network come into play. However, not 1014 revealing enough, say about diversity capabilities may also lead 1015 customers elsewhere. Also there are some other security issues not 1016 seen before. For example, in route distribution one carrier might 1017 not be inclined to pass on routing information that could point the 1018 way to competitive alternatives. This impacts the methods for route 1019 updates, etc. 1021 With the interest in bandwidth trading [10] we can also look at this 1022 as an advertisement of network connectivity and capability with of 1023 course any "warts" covered up. This would include reliance on other 1024 carrier for fibers or lambdas. Also a fair amount of details such 1025 as "unused capacity" would not be advertised since this maybe 1026 financially sensitive information. 1028 Private line pricing today is based primarily on the service itself 1029 (bandwidth, end-points, etc.) and the holding time, and there is no 1031 draft-ipo-optical-inter-domain-02.txt February 2003 1033 reason to expect that this will change. When multiple service 1034 providers are involved the algorithm for dividing up the revenue 1035 stream (which can be quite large even for a single connection) must 1036 be explicit by connect time. This could be done off-line or could be 1037 done at connect time. In either case, the entity or entities doing 1038 the routing will need to take provider pricing structures into 1039 account whenever there is a choice between providers that needs to 1040 be made. The routing logic could do this explicitly if the prices 1041 are captured in the advertised metrics or some other advertised 1042 data; alternatively it could be done by some sort of policy control, 1043 as it is today by BGP. 1045 The essence of bandwidth trading is the existence of competing price 1046 structures that are known to the entity deciding which competitor to 1047 use. It is possible to create plausible bandwidth trading scenarios 1048 involving the UNI, the NNI, or both. If the NNI is involved, these 1049 price structures will need to be established across it. The 1050 situation is further complicated by the fact that bandwidth trading 1051 could be realized using any one of a number of business models, each 1052 with its own information requirements. To give two examples: If an 1053 auction model were used the buyer might repeatedly broadcast the 1054 lowest bid received to date and solicit lower bids from the 1055 competing providers. On the other hand, if there were a more formal 1056 market the providers might post their asking prices in some public 1057 fashion and a buyer would be matched by some third party with the 1058 lowest offer. 1060 In the inter-carrier case notions of hierarchy seem rather 1061 sensitive, i.e., he who controls the summarization and advertisement 1062 may have an undue advantage over competitors. In addition, a 1063 "bandwidth aggregator" may want to advertise capabilities that he 1064 has put together via deals with multiple carriers... 1066 Notes: We can attempt to extend the SRLG concept to links between 1067 ASs but we will need the two ASs to agree on the meaning and number 1068 of the list of 32 bit integers that comprise the SRLG, i.e., 1069 previously the SRLG concept was one of AS scope. And this is also 1070 where things get tricky since it may not be possible to distinguish 1071 diverse routes based upon differing path vectors (i.e., AS number 1072 traversal list). The reason for this is due the fact that many 1073 carriers "fill out" their networks by renting either dark fiber or 1074 "lambdas" from a WDM system and hence although the path vectors may 1075 be AS diverse they may not even be fiber diverse. 1077 Hence there is a need for sharing of diversity information or 1078 constraints between ASs when setting up diverse connections across 1079 multiple ASs. This gets us somewhat into a quandary over which 1080 information needs to be public and how to coordinate its 1081 distribution. In this sense geographic link information may be the 1082 simplest and least contentious to get various players to disclose 1083 and standardize. 1085 draft-ipo-optical-inter-domain-02.txt February 2003 1087 Notes: (1) The real issue is consistency between the cloud/AS�s 1088 since in many cases they are sharing conduit, ROW, etc. Getting 1089 this to happen could be very problematic. It would be preferable to 1090 see a diversity option that doesn�t require this. For example, 1091 ensure that there is diversity within each cloud and then do 1092 restoration separately within each cloud. (2) See the definition of 1093 SRLG in the Carrier Requirements -- an equivalence class of links, 1094 the extent of violation, and the level. (3) Flexibility in defining 1095 the level of violation seems very desirable -- these historically 1096 have drifted in time. There are many others -- eg, if the shared 1097 resources are SPRING protected that�s less of a problem than 1098 otherwise. 1100 Notes: Participation in the inter-domain network carries constraints 1101 on the carriers. First, in order to participate, each provider 1102 network MUST be willing to advertise the destinations that are 1103 reachable through his network at each entry point and advertise the 1104 formats available. Without providing such information, there is 1105 little motivation to participate since it is unlikely that others 1106 will be able to access services of which they are not aware. Second, 1107 every participating carriers MUST agree to fairly include the 1108 information made available by every other carrier so that each 1109 carrier has an equal opportunity to provide services. There may be 1110 specific exceptions, but the carrier claiming those exceptions MUST 1111 advertise the exceptions themselves. In this manner, other carriers 1112 that might otherwise be aware of distant services can be prompted to 1113 seek those services manually. Note a combination of minimal 1114 required information transferred with deferral to the originating 1115 subnetwork along with some basic security mechanisms such as 1116 integrity and non-repudiation may be useful in helping organizations 1117 to "play nice". 1119 3.3 Multi-Domain Connection Control 1121 MPLS� loose routing capability allows one to specify a route for an 1122 optical connection in terms of a sequence of optical AS numbers. 1123 This, for example, is handled via RSVP-TE�s abstract node concept 1124 [11]. Currently there is nothing in the GMPLS signaling 1125 specification that differentiates between intra AS boundaries, i.e., 1126 between two neighbor optical LSRs in the same AS, and inter AS 1127 boundaries, i.e. between two neighbor optical LSRs in different ASs. 1128 Note that these same notions can apply to separate routing domains 1129 within an AS. There may, however, be some useful reasons for 1130 differentiating these two cases: 1132 1. Separation of signaling domains, 1133 2. Separation of protection domains. 1135 While routing protocols (used for their topology information) in the 1136 optical case are not "service impacting", signaling protocols most 1137 certainly are. It is desirable to build some type of "wall" between 1138 optical ASs so that faults in one that lead to "signaling storms" do 1139 not get propagated to other ASs. Note that the same motivation 1141 draft-ipo-optical-inter-domain-02.txt February 2003 1143 applies for isolating other kinds of clouds, like vendors specific 1144 ones. 1146 The natural situation where "signaling storms" would be most likely 1147 to arise is during network restoration signaling, i.e., signaling to 1148 recover connections during major network outages, e.g., natural 1149 disasters etc. In this case it may be very advantageous to break up 1150 general source reroute forms of restoration into per domain segments 1151 or to start reroute at domain boundaries rather than all the way 1152 back at the originating node. Note that this has the advantage of 1153 reducing the need for globally consistent SRLG�s. (See earlier SRLG 1154 comment.) Such a capability requires some loose coordination between 1155 the local, intermediate and global protection mechanisms [12]. This 1156 is typically implemented via hold off timers, i.e., one layer of 1157 protection will not attempt restoration until a more fundamental 1158 (local) form has been given a chance to recover the connection [12]. 1160 In other words, prevention of restoration related signaling storms 1161 may require the breaking up of a large network into multiple 1162 signaling (and hence routing) domains. These domains could be within 1163 the same AS. 1165 4 Multiple Layers of Optical Routing 1167 As previously discussed, there are multiple layers of signals 1168 included in what in the IP model one would call the Physical Layer. 1169 One could separate the layers by creating sublayers in the Physical 1170 Layer. For example, sublayers in the Physical Layer might be, top 1171 to bottom: SDH LOVCs, SDH HOVCs, and Lambdas. If a system supports 1172 only one of the three, then isolation of the sublayers is a given; 1173 it's geographical. But there are systems which will support more 1174 than one physical sublayer, therefore, it is necessary to establish 1175 whether or not there is a need to isolate the sublayers in the same 1176 manner. Or put another way is there a reason to "integrate" the 1177 sublayers for the purposes of routing (topology dissemination). 1179 If they are isolated, then there will be separate topological models 1180 for each sublayer: one mesh for the LOVC, one for the HOVC, one for 1181 the Lambda, and possibly others. The appropriate way to access a 1182 sublayer is via the use of sublayer SAPs (service access points). 1183 For example, in this way, one may find that use of Lambdas is more 1184 efficient because each sublayer can assess the availability of 1185 services at its own layer before searching for coarser-granularity 1186 services. On the other hand, the control plane must accommodate 1187 three separate routing protocols, or at least three separate 1188 instances of the same routing protocol, all operating at both intra 1189 and inter-domain level. 1191 Example (SDH multiplexing) 1192 For transport across an SDH network, the lower order signals must be 1193 multiplexed into a non-concatenated higher order signal. Hence LOVCs 1194 are not routed independently, but only as tributaries of HOVCs. In 1195 addition in the SDH hierarchy there is a signal, VC3, that can be 1197 draft-ipo-optical-inter-domain-02.txt February 2003 1199 treated (multiplexed) as either a LOVC or a HOVC. With this tight 1200 and somewhat confused coupling of these layers it may beneficial to 1201 sometimes combine them into the same route protocol instance. 1203 The alternative to separate routing protocols per sublayer is the 1204 original notion behind GMPLS routing and the forwarding adjaciency 1205 concept [13]. Rather than separating the route protocols into 1206 separate layers (or sublayers) with distinct topologies, each ONE 1207 would advertise the services it can provide, along with its topology 1208 information. For example, a ONE (optical network element) might 1209 advertise that it carries a route to node A with STS-N service and 1210 clear-channel lambda service and carries multiple routes to node B 1211 with STS-N service. It might, alternatively, advertise its entire 1212 network with summarized link capacity information for every included 1213 link. Neighboring carriers would, implicitly, be allowed to 1214 summarize that information for internal advertisement via its IGP. 1215 Further consideration could be given to a query service, where a 1216 carrier advertises the geographical area it serves without detailed 1217 reachability or capacity information. A second carrier desiring 1218 service could query the first carrier as to reachability for a 1219 specific destination, and the first carrier would respond with 1220 availability and capacity information. 1222 Integrating multiple layers into the same routing protocol instance 1223 leaves us fewer routing protocols to manage. The downside of this is 1224 that more information must be exchanged via this routing protocol 1225 and more network elements participate in this single instance of the 1226 routing protocol which can lead to scalability concerns. If the 1227 equipment working on the different sublayers comes from different 1228 vendors there would be little incentive to integrate multiple layers 1229 into the routing protocol for a single layer product. 1230 Regardless of whether multiple layers are integrated into the same 1231 routing protocol instance it can be very useful to share information 1232 between layers as illustrated by the following examples: 1234 o Drop side links between layers: Capabilities of the links 1235 that are between the (client and server) layers need to be 1236 propagated into the routing protocol. 1237 o Summarize link capabilities: Summarizing the server layer 1238 capabilities in the client layer will reduce the amount of 1239 information required for multi-layer constraint based path 1240 computation. 1241 o Send only that are required: Sending only the capabilities 1242 that are useful in the constraint path computation in the 1243 client layer. 1245 5 Conclusion 1247 draft-ipo-optical-inter-domain-02.txt February 2003 1249 Key properties of optical control domains and an optical inter 1250 control domain routing protocol were reviewed. The stringent 1251 properties of "independence of internal domain control plane 1252 mechanisms" as well as support for "boundary on the wire" were shown 1253 to be crucial to the definition of control domain by showing their 1254 use in several mainstream optical inter-networking scenarios. 1256 Via examples we saw that BGP is the only existing IP routing 1257 protocol for which the "internal domain independence" and "boundary 1258 on the wire" property hold. However, it was described how important 1259 the ability to diversely route optical connections is to the 1260 reliability and resilience of the optical network. In addition it 1261 was pointed out that flexibility in choosing/computing paths can be 1262 very important to an optical network operator so that they can offer 1263 a range of differentiated services. In this light BGP does not 1264 currently meet the needs of an optical inter control domain routing 1265 protocol. 1267 As of this writing we are therefore looking at two alternatives for 1268 an optical inter control domain routing protocol. (1) Extensions to 1269 a link state type protocol (such as OSPF, IS-IS or PNNI routing) to 1270 work at the control domain level rather than node to node level. Or 1271 (2) Extensions to a path vector type protocol (such as BGP) to 1272 provide diverse routing support and enhance path selection/network 1273 optimization. 1275 6 Security Considerations 1277 6.1.1 1279 Protection of the routing information exchanged across an optical 1280 inter-domain interface is of high importance; erroneous reachability 1281 or topology information may result in connection provisioning 1282 requests that either fail or are routed across sub-optimal paths. It 1283 is also possible that failed requests may consume significant 1284 control and transport resources for a transient amount of time. It 1285 follows that erroneous routing information could result in degraded 1286 carrier network operation, or even render a carrier�s network 1287 inoperable. Security requirements are expected to be of higher 1288 importance in interfaces between different administrative domains. 1289 Therefore, an optical inter-domain routing protocol should provide 1290 the following: 1292 1. Authenticate entities with which routing information is exchanged. 1293 For example, a carrier should authenticate the identity of other 1294 carriers it is connected to. The specific mechanisms used for 1295 authentication should provide protection against attacks; for 1296 example they should not be based on simple clear-text password 1297 authentication schemes. 1299 2. Guarantee the integrity of routing information (topology, 1300 reachability and resource status) exchanged across the interface. 1302 draft-ipo-optical-inter-domain-02.txt February 2003 1304 This requirement can be satisfied using security mechanisms at 1305 different layers. For example, each routing message could be 1306 individually authenticated using a keyed message digest, which is 1307 embedded in the message. Both OSPF and BGP provide such options. 1308 Alternatively, the two parties could establish a security 1309 association at the network layer using IPSEC, which could be used 1310 to provide security services to the optical inter-domain routing 1311 protocol. 1313 From the point of view of routing, information integrity is likely 1314 to be the most important requirement. However, in some cases it 1315 might be necessary to provide confidentiality of the routing 1316 information as well. A possible scenario for this is when a carrier 1317 would like to advertise information privately to another carrier, 1318 but does not wish to publicly disseminate this information, due to 1319 policy constraints. 1321 It should be noted than none of the known mechanisms that provide 1322 information integrity (such as keyed digests or IPSEC) can provide 1323 adequate protection against a compromised node participating in the 1324 inter-domain routing protocol. This is an item for further study. 1326 7 References 1328 [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 1329 9, RFC 2026, October 1996. 1331 [2] G. Bernstein, J. Yates, D. Saha, "IP-Centric Control and 1332 Management of Optical Transport Networks", IEEE Communications 1333 Magazine, October 2000. 1335 [3] G. Bernstein, E. Mannie, V. Sharma, "Framework for MPLS-based 1336 Control of Optical SDH/SONET Networks", , February 2003. 1339 [4] Ramesh Bhandari, Survivable Networks: Algorithms for Diverse 1340 Routing, Kluwer Academic Publishers,1999. 1342 [5] Strand, J. (ed.) "Impairments And Other Constraints On Optical 1343 Layer Routing", work in progress, draft-ietf-ipo-impairments- 1344 00.txt, May 2001. 1346 [6] Kompella, K., et. al. "IS-IS Extensions in Support of 1347 Generalized MPLS", Work in Progress, draft-ietf-isis-gmpls- 1348 extensions-16.txt, December 2002. 1350 [7] K. Kompella, et. al. "Link Bundling in MPLS Traffic 1351 Engineering", Work in Progress, draft-ietf-mpls-bundle- 1352 04.txt, July 2002. 1354 draft-ipo-optical-inter-domain-02.txt February 2003 1356 [8] ANSI T1.105.01-1995, Synchronous Optical Network (SONET) 1357 Automatic Protection Switching, American National Standards 1358 institute. 1360 [9] Robert S. Cahn, Wide Area Network Design: Concepts and Tools 1361 for Optimization, Morgan Kaufmann Publishers, Inc., 1998. 1363 [10] Meghan Fuller, "Bandwidth trading no longer a case of 'if' but 1364 'when' says report", Lightwave, June 2001. (www.light-wave.com) 1366 [11] RFC 3209, "RSVP-TE: Extensions to RSVP for LSP 1367 Tunnels", December 2001. 1369 [12] K. Owens, V. Sharma, M. Oommen, "Network Survivability 1370 Considerations for Traffic Engineered IP Networks", Work in 1371 Progress, draft-owens-te-network-survivability-03.txt, May 2002. 1373 [13] K. Kompella and Y. Rekhter, "LSP Hierarchy with MPLS TE", 1374 draft-ietf-mpls-lsp-hierarchy-08.txt, Internet Draft, Work in 1375 Progress, September 2002. 1376 [14] G.805, Generic Functional Architecture of Transport Networks, 1377 ITU-T, March 2000. 1379 8 Acknowledgments 1381 The authors would like to thank Shezad Mirza of BT and Cheryl 1382 Sanchez of Calix for their help. 1384 9 Author's Addresses 1386 Greg Bernstein 1387 Grotto-Networking 1388 Phone: (510) 573-2237 1389 Email: gregb@grotto-networking.com 1391 Lyndon Ong 1392 Ciena Corporation 1393 5965 Silver Creek Valley Road 1394 San Jose, CA 95015 1395 Phone: (408) 834-7894 1396 Email: lyong@ciena.com 1398 Bala Rajagopalan, Dimitrios Pendarakis 1399 Tellium, Inc 1400 2 Crescent Place 1401 Ocean Port, NJ 07757 1402 Email: braja@tellium.com, dpendarakis@Tellium.com 1404 Angela Chiu 1405 John Strand 1406 AT&T Labs 1408 draft-ipo-optical-inter-domain-02.txt February 2003 1410 200 Laurel Ave. 1411 Middletown, NJ 07748 1412 Phone:(732) 420-9061 Angela, (732) 420-9036 John 1413 Email: chiu@research.att.com, jls@research.att.com 1415 Vishal Sharma 1416 Metanoia, Inc. 1417 335 Elan Village Lane, Unit 203 1418 San Jose, CA 95134 1419 Phone: +1 408 943 1794 1420 Email: v.sharma@ieee.org 1422 Rauf Izmailov 1423 NEC USA, Inc. 1424 4 Independence Way 1425 Princeton, NJ 08540 1426 Email: rauf@nec-lab.com 1428 Dean Cheng 1429 Polaris Networks Inc. 1430 6810 Santa Teresa Bl. 1431 San Jose CA 95119 1432 Email: dcheng@polarinetworks.com 1434 Sudheer Dharanikota 1436 Frank Hujber