idnits 2.17.1 draft-bernstein-optical-bgp-00.txt: 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. == No 'Intended status' indicated for this document; assuming Proposed Standard 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- 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 2001) is 8471 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) -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 1771 (ref. '4') (Obsoleted by RFC 4271) == Outdated reference: A later version (-09) exists of draft-ietf-mpls-rsvp-lsp-tunnel-07 == Outdated reference: A later version (-19) exists of draft-ietf-isis-gmpls-extensions-01 ** Downref: Normative reference to an Informational draft: draft-ietf-isis-gmpls-extensions (ref. '7') Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group G. Bernstein 2 Internet Draft Ciena 3 Expiration Date: May 2001 B. Rajagopalan 4 Document: draft-bernstein-optical-bgp-00.txt Tellium 5 February 2001 7 Optical Inter Domain Routing Requirements 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026 [1]. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. Internet-Drafts are draft documents valid for a maximum of 18 six months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet- Drafts 20 as reference material or to cite them other than as "work in 21 progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 Abstract 29 GMPLS is being considered as an extension to the MPLS framework to 30 include optical non-packet switched technologies. This draft 31 discusses requirements for inter domain routing protocols such as 32 BGP for use in the optical domain. 34 1. Introduction 36 Multi Protocol Label Switching (MPLS) has received much attention 37 recently for use as a control plane for non-packet switched 38 technologies. In particular optical technologies have a need to 39 upgrade their control plane as reviewed in reference [2]. Many 40 different optical switching and multiplexing technologies exist and 41 more are sure to come. For the purposes of this draft we only 42 consider non-packet (i.e. circuit switching) forms of optical 43 switching. 44 As we have looked at requirements and extensions to interior gateway 45 protocols such as OSPF and IS-IS in reference [3], we consider the 46 requirements that optical networking and switching place on an 47 exterior gateway protocol such as BGP. In particular we look at 48 optical path diversity, various optical switching and transport 49 capabilities, and bandwidth/resource status with respect to inter 50 domain routing. 52 1.1. Specification of Requirements 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 55 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 56 this document are to be interpreted as described in RFC 2119. 58 1.2 Abbreviations 60 LSP Label Switched Path (MPLS terminology) 61 LSR Label Switched Router (MPLS terminology) 62 MPLS Multiprotocol Label Switching 63 SDH Synchronous Digital Hierarchy (ITU standard) 64 SONET Synchronous Optical NETwork (ANSI standard) 65 STM(-N) Synchronous Transport Module (-N) 66 STS(-N) Synchronous Transport Signal-Level N (SONET) 67 TU-n Tributary Unit-n (SDH) 68 TUG(-n) Tributary Unit Group (-n) (SDH) 69 VC-n Virtual Container-n (SDH) 70 VTn Virtual Tributary-n (SONET) 72 2.0. Motivation for Optical Inter Domain Routing 74 The motivation for inter domain routing in optical networks (circuit 75 switched)is very similar to that in the case of IP datagram routing. 77 1. Distribute "reachability" information throughout an 78 internetwork. An internetwork consists of an interconnected 79 set of networks under different routing and/or 80 administrative domains. 82 2. Maintain a clear separation between distinct administrative 83 or routing domains. 85 3. Provide "information hiding" on the internal structure of 86 the distinct administrative or routing domains. 88 4. Limit the scope of interior gateway routing protocols. This 89 is for security, scalability and policy reasons. 91 5. Provide for address/route aggregation. 93 2.1. Major Differences from IP datagram Routing 95 Although the differences in requirements between an exterior gateway 96 protocol for IP datagram routing and that for optical circuit 97 routing will be explored in detail in the following section. It is 98 useful to review the major difference between routing for optical 99 (circuit switched networks) and IP datagram networks. In particular 100 IP datagram networks packet forwarding is done on a hop-by-hop basis 101 (no connection established ahead of time). While with circuit 102 switched optical networks end to end connections must be explicitly 103 set established based on network topology and resource status 104 information. This topology and resource status information can be 105 obtained via routing protocols. Note that the routing protocols in 106 the circuit switch case are not involved with data (or bit) 107 forwarding, i.e., they are not "service impacting". While in the IP 108 datagram case the routing protocols are explicitly involved with 109 data plane forwarding decisions and hence are very much service 110 impacting. 112 This does not imply routing is unimportant in the optical case but 113 that its service impacting effect is secondary. For example, 114 topology and resource status inaccuracies will affect whether a new 115 connection can be established (or a restoration connection can be 116 established) but will not (and should not) cause an existing 117 connection to be torn down. 119 This tends to lead to a slightly different view towards 120 incorporating new information fields (objects, LSA, etc.) into 121 optical routing protocols versus IP routing protocols. In the 122 optical circuit case any information that can potentially aid in 123 route computations or be used in service differentiation may be 124 incorporated into the route protocol as either a standard element or 125 a vendor specific extension. Whether a route computation algorithm 126 uses this information and whether two route computation algorithms 127 use this information in the same way doesn't matter since the 128 optical connections are explicitly routed (although perhaps 129 loosely). The optical route computation problem is really a 130 constraint-based routing problem. 132 2.2. Policy Mechanisms 134 BGP-4 [4] provides a number of policy mechanisms that relate to how 135 routing information is used and disseminated. In particular the E- 136 BGP border router model keeps distinct the routing information 137 received from each of a border routers autonomous systems external 138 peers (Adj-RIBs-In -- Adjacent Routing Information Base In), the 139 routing information that the Autonomous System (AS) itself is using 140 (Loc-RIB -- Local Routing Information Base), and the routing 141 information that the AS forwards onto its external peers (Adj-RIBs- 142 Out -- Adjacent Routing Information Base Out). Via this model one 143 can develop policies with regards to which routes get chosen for use 144 in the AS, i.e., which routes from the Adj-RIBs-In are chosen to 145 populate the Loc-RIB. One also develops policies concerning what 146 routing information gets advertised to external peers, i.e., which 147 routes from Loc-RIB gets exported to each of the Adj-RIBs-Out. 149 The choice of which routes get imported for local routes generally 150 is concerned with the "quality" of those advertising the routes 151 since not too much else is known (besides the AS path vector). In 152 deciding which routes to advertise to external peers "transit 153 policies", i.e., whose traffic is allowed to transit this AS is the 154 prime consideration. 156 In the MPLS and in particular the explicitly routed optical case we 157 have a very strong additional policy mechanism, that of connection 158 admission control (CAC). Although an optical AS probably shouldn't 159 advertise transit capabilities that it doesn't wish to support, CAC 160 during connection establishment will be the final arbiter of any 161 transit policy. In addition, some areas that are being addressed by 162 policies in the IP datagram case such as load balancing are much 163 easier to implement via CAC and/or explicit routing. 165 2.3. Multi-Domain Connection Control 167 MPLS' loose routing allows one to specify a route for an optical 168 connection in terms of a sequence of optical AS numbers. This, for 169 example, is handled via RSVP-TE's abstract node concept [5]. 170 Currently there is nothing in the GMPLS signaling specification that 171 differentiates between intra AS boundaries, i.e., between two 172 neighbor optical LSRs in the same AS, and inter AS boundaries, i.e. 173 between two neighbor optical LSRs in different ASs. Note that these 174 same notions can apply to separate routing domains within an AS. 175 There may however be some useful reasons for differentiating these 176 two cases: 178 1. Separation of signaling domains, 179 2. Separation of protection domains. 181 While routing protocols (used for their topology information) in the 182 optical are not "service impacting", signaling protocols most 183 certainly are. It is desirable to build some type of "wall" between 184 optical ASs so that faults in one that lead to "signaling storms" do 185 not get propagated to other ASs. 187 The natural situation where "signaling storms" would be most likely 188 to arise is during network restoration signaling, i.e., signaling to 189 recover connections during major network outages, e.g., natural 190 disasters etc. In this case it may be very advantageous to break up 191 general source reroute forms of restoration into per domain segments 192 or to start reroute at domain boundaries rather than all the way 193 back at the originating node. Such a capability requires some loose 194 coordination between the local, intermediate and global protection 195 mechanisms. This is typically implemented via hold off timers, 196 i.e., one layer of protection will not attempt restoration until a 197 more fundamental (local) form has been given a chance to recover the 198 connection. 200 In other words: prevention of restoration related signaling storms 201 may require the breaking up of a large network into multiple 202 signaling (and hence routing) domains. These domains could be within 203 the same AS. Routing across these domains will require some BGP-like 204 protocol, hence another motivation for a BGP like protocol. 206 3.0. Diversity in Optical Routing 208 There are two basic demands that drive the need to discover diverse 209 routes for establishing optical paths: 211 1. Reliability/Robustness 212 2. Bandwidth capacity. 214 Many times multiple optical connections are set up between the same 215 end points. An important constraint on these connections is that 216 they must be diversely routed in some way. In particular they could 217 be link diverse (not traversing the same link) or node diverse (not 218 traversing the same nodes). Additionally insufficient bandwidth may 219 exist to set up all the desired connection across the same path (set 220 of links) and hence we need to know about alternative (diverse) ways 221 of reaching the destination that may still have unused capacity. 223 3.1 Pick One! (route that is) 225 With datagram routing we need to pick one route to a destination and 226 make sure this choice is consistent throughout the AS. In 227 particular BGP specifically reduces the number of choices according 228 to the following rule [6]: 230 Fundamental to BGP is the rule that an AS advertises to its 231 neighboring AS's only those routes that it uses. This rule 232 reflects the "hop-by-hop" routing paradigm generally used by 233 the current Internet. 235 In the optical circuits case we are not using a "hop-by-hop" routing 236 paradigm. Hence it seems that BGP constrains our knowledge of 237 diverse routes in the optical case. This hits a major difference in 238 use between the optical and IP datagram forwarding case. In the 239 optical case we are really interested in topology information that 240 allows an optical connection path to be computed based on whatever 241 criteria is desired for that connection. In the IP datagram case we 242 are interested in a consistent set of routes for use in hop-by-hop 243 forwarding. Hence the optical case has tended to favor link state 244 protocols since they furnish raw topology information that can be 245 used in computing routes as opposed to distance vector protocols 246 whose output is a set of routes (without necessarily providing 247 complete topology information). 249 3.2. Some Additional Diversity Issues 251 In a previous section we mentioned node and link diversity and gave 252 a brief definition. Unfortunately these definitions are not really 253 adequate for optical networking. Optical networks may posses a 254 number of hierarchical signaling layers. For example two routers 255 interconnected across an optical network may communicate with IP 256 packets encapsulated within an STS-48c SONET path layer signal. 257 Within the optical network this STS-48c signal may be multiplexed at 258 the SONET line layer into an OC-192 line layer signal. In addition 259 this OC-192 may be wavelength division multiplexed onto a fiber with 260 other OC-192 signals at different wavelengths (lambdas). These WDM 261 signals can then be either lambda switched, wave band switched or 262 fiber switched. Hence when we talk about diversity we need to 263 specify which layer. In the previous example we can talk about 264 diversity with respect to the SONET line layer, wave bands, and 265 optical fibers. A similar situation arises when we consider the 266 definition of node diversity. For example are we talking with 267 respect to a SONET path layer switch or an optical switch or 268 multiplexer? 270 The Shared Risk Link Group concept in reference [7] can help us with 271 this type of information within an AS, but there are some additional 272 complexities in the exterior routing case. First its useful with 273 respect to major outages (cable cuts, natural disasters) to have a 274 few more types of diversity defined: 276 1. Cable (conduit) diversity (allows us to know which fibers 277 are in the same cable (conduit). This helps avoid sending 278 signals over routes that are most vulnerable to "ordinary" 279 cable cuts (technically known as backhoe fades). 281 2. Right of Way (ROW) diversity. This helps avoid sending 282 signals over routes that are subject to larger scale 283 disasters such as ship anchor drags, train derailments, etc. 285 3. Geographic diversity. This type of diversity can help one 286 avoid sending signals over routes that are subject to 287 various larger scale disasters such as earthquakes, floods, 288 tornadoes, hurricanes, etc. 290 We can attempt to extend the SRLG concept to links between ASs but 291 we will need the two ASs to agree on the meaning and number of the 292 list of 32 bit integers that comprise the SRLG, i.e., previously the 293 SRLG concept was one of AS scope. And this is also where things get 294 tricky since it may not be possible to distinguish diverse routes 295 based upon differing path vectors (i.e., AS number traversal list). 296 The reason for this is due the fact that many carriers "fill out" 297 there networks by renting either dark fiber or "lambdas" from a WDM 298 system and hence although the path vectors may be AS diverse they 299 may not even be fiber diverse. 301 Hence there is a need for sharing of diversity information or 302 constraints between ASs when setting up diverse connections across 303 multiple ASs. This gets us somewhat into a quandary over which 304 information needs to be public and how to coordinate. In this sense 305 geographic link information may be the simplest and least 306 contentious to get various players to disclose and standardize. 308 4.0. AS Capability Advertisement 309 In addition to reachability information from an AS we will want to 310 know: 311 1. Switching capabilities 312 2. Protection Capabilities 313 3. Available Capacity 314 4. Reliability Measures (if available) 315 The tricky part of advertising any of these properties is that we 316 would like to summarize this information in a reasonable way so as 317 to keep it reasonably brief and suitable for distribution within a 318 routing protocol but at the same time deliver sufficient information 319 to be of use in most path computation situations. This is in 320 general a topology aggregation problem, but to keep in the spirit of 321 AS autonomy and opaqueness at most this would be represented as a 322 "hub and spoke" type of aggregate where the "psuedo links" and the 323 "hub" can posses various attributes corresponding to the previously 324 mentioned capabilities. 326 5.0 Conclusion and Recommendations 327 This draft highlighted some of the requirements for exterior gateway 328 routing protocol for use in optical internetworking. The 329 similarities and differences between which of these requirements are 330 currently answered by BGP and which would require extensions to BGP 331 were discussed. In addition, information that would need to be 332 shared between optical domains in order for an exterior gateway 333 routing protocol to be viable was discussed. 335 6. Security Considerations 337 Security considerations are not discussed in this version of the 338 document. 340 7. References 342 [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 343 9, RFC 2026, October 1996. 345 [2] G. Bernstein, J. Yates, D. Saha, "IP-Centric Control and 346 Management of Optical Transport Networks", IEEE Communications 347 Magazine, October 2000. 349 [3] G. Bernstein, E. Mannie, V. Sharma, "Framework for MPLS-based 350 Control of Optical SDH/SONET Networks", , November 2000. 352 [4] Rekhter Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)", 353 RFC 1771, T.J. Watson Research Center, IBM Corp., cisco Systems, 354 March 1995. 355 [5] Awduche, D., et. Al., "RSVP-TE: Extensions to RSVP for LSP 356 Tunnels", Work in Progress, draft-ietf-mpls-rsvp-lsp-tunnel- 357 07.txt, August 2000. 358 [6] Rekhter, Y., and P. Gross, "Application of the Border Gateway 359 Protocol in the Internet", RFC 1772, T.J. Watson Research Center, 360 IBM Corp., MCI, March 1995. 361 [7] Kompella, K., et. al. "IS-IS Extensions in Support of 362 Generalized MPLS", Work in Progress, draft-ietf-isis-gmpls- 363 extensions-01.txt, November 2000. 365 8. Acknowledgments 366 9. Author's Addresses 368 Greg Bernstein 369 Ciena Corporation 370 10480 Ridgeview Court 371 Cupertino, CA 94014 372 Phone: (408) 366-4713 373 Email: greg@ciena.com 375 Bala Rajagopalan 376 Tellium, Inc 377 2 Crescent Place 378 Ocean Port, NJ 07757 379 Email: braja@tellium.com