idnits 2.17.1 draft-basak-mpls-oxc-issues-01.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? == 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. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 150 has weird spacing: '...l as on devic...' == Line 252 has weird spacing: '...details to es...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '3' is defined on line 347, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 350, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 354, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 356, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 359, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 362, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 365, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 367, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Downref: Normative reference to an Informational RFC: RFC 2702 (ref. '2') -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' Summary: 6 errors (**), 0 flaws (~~), 11 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Debashis Basak 2 Expires: August, 2000 Marconi 3 4 Daniel O. Awduche 5 UUNet (MCI WorldCom) 7 John Drake 8 Chromisys, Inc 10 Yakov Rekhter 11 Cisco 13 Multi-protocol Lambda Switching: Issues in Combining MPLS 14 Traffic Engineering Control With Optical Cross-connects 16 Status of this Memo 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet- Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Abstract 39 This document describes the domain specific enhancements required to 40 adapt MPLS traffic engineering control plane constructs to control 41 optical cross-connects in emerging automatically switched optical 42 transport networks. These enhancements are within the framework of 43 Multiprotocol LAMBDA switching proposed in [1]. Specifically, this 44 memo investigates the behavior of the MPLS based control plane 45 technique for OXCs, and identifies required enhancements to both OXCs 46 and to existing MPLS traffic engineering control plane objects 47 (routing and signaling protocols) to support the application to OXCs. 49 1. Introduction 51 Recently, a new paradigm for the design of control planes for OXCs 52 intended for data-centric automatically switched optical transport 53 networks was proposed in [1]. This new paradigm is termed 54 Multiprotocol Lambda Switching and exploits recent advances in MPLS 55 traffic engineering control plane technology to foster the expedited 56 development and deployment of a new class of versatile OXCs that 57 specifically address the optical transport needs of the Internet. 59 The MPLS traffic engineering control plane has been shown to be an 60 extensible general purpose control plane technology for a variety of 61 data-centric network elements. For example, the MPLS control plane 62 has been used previously in conjunction with data planes that have 63 specific limitations e.g. ATM-LSRs and frame relay LSRs (FR-LSRs). 64 The adaptation of MPLS traffic engineering control plane concepts to 65 OXCs, which results in OXC-LSRs, needs to consider and reflect the 66 domain specific peculiarities of the OXC data plane. This 67 consideration was noted in [1], but details of the needed extensions 68 were not provided. 70 This memo describes a number of required domain specific enhancements 71 that are necessary to map the MPLS traffic engineering control plane 72 constructs to OXCs. Specifically, this memo describes required 73 enhancements to OXCs and associated WDM devices to support 74 incorporation of the MPLS traffic engineering control plane approach. 75 Additionally, this memo discusses required extensions to the existing 76 MPLS traffic engineering control plane constructs to better 77 accommodate the needs of optical transport network elements. 79 2. Terminology and Definitions 81 This section introduces terminology which is pertinent to the 82 Multiprotocol Lambda Switching concept. We discuss the notions of 83 termination-capable interfaces and termination-incapable interfaces, 84 and a related concept of termination-incapable domain. 86 A termination-capable (TC) interface on an LSR is an interface which 87 is capable of terminating a label switched path (LSP) and 88 subsequently demultiplexing the data carried by the LSP to make 89 further routing/switching decisions. This definition does not pertain 90 to management and control traffic destined for the LSR. A point-to- 91 point interface terminating on an IP router that implements MPLS is 92 an example of a TC interface. 94 A termination-incapable (TI) interface is one which is incapable of 95 terminating LSPs and demultiplexing the data carried by the LSPs to 96 make further routing/switching decisions. A fiber connected to a pure 97 OXC is an example of a TI interface. The definition of TI does not 98 pertain to interfaces which terminate management and control traffic 99 destined for the LSR. 101 For a given bidirectional link, the interfaces associated with the 102 endpoints of the link may be of different types with respect to their 103 capability to terminate LSPs. For example, consider a link between a 104 pure OXC and a (frame-based) LSR (e.g., an IP router); the interface 105 with the OXC is TI while the interface with the frame-based LSR is 106 TC. 108 A single network element may simultaneously have both TC and TI 109 interfaces. For example, it is easy to envision an optical device 110 that switches traffic on some interfaces based on the wavelength or 111 the optical channel trail through which the traffic was received, and 112 switches traffic on other interfaces based on the label information 113 carried by packets. It is also easy to envision a hybrid physical 114 interface in which traffic on certain wavelengths or optical channel 115 trails are forwarded based on the wavelength or optical channel trail 116 through which the traffic was received, and traffic on other 117 wavelengths or optical channel trails are forwarded based on the 118 label information carried by the packets. Such physical interfaces 119 may be considered as two separate logical interfaces, one TC and the 120 other TI. 122 If all the interfaces on an LSR are TI interfaces, then such an LSR 123 will be referred to as a TI-LSR. A contemporary OXC-LSR which 124 provides transit services for data traffic is an example of a TI-LSR 125 (an ATM-LSR within the context of IP-over-ATM is another example of a 126 TI-LSR). 128 If an LSR has at least one TC interface, then such an LSR is referred 129 to as a TC-LSR. A router that implements MPLS is an example of a TC- 130 LSR. 132 We now discuss the concept of a TI-LSR domain. 134 A TI-LSR domain is a set of TI-LSRs which are mutually interconnected 135 by TI interfaces. A transit optical transport network (OTN) composed 136 of contemporary OXC-LSRs is an example of a TI-LSR domain. 138 The Edge set of a TI-LSR domain is the set of TC-LSRs that are 139 interconnected to members of the domain by links with a TC interface 140 on a TC-LSR and a TI interface on a TI-LSR. A TC-LSR which is a 141 member of an Edge set of a TI-LSR domain is called an Edge LSR. 142 Examples of edge LSRs include client network elements and access 143 devices that interconnect to the OTN. Figure 1 below depicts an 144 illustrative network with a single TI-LSR domain consisting of OXCs 145 (O1 through O8) surrounded by an Edge set of TC-LSRs consisting of 146 access routers (M0 through M4). 148 By definition LSPs cannot start/terminate on LSRs within a TI-LSR 149 domain. LSPs can, however, start and terminate on TC-LSRs belonging 150 to the Edge set of a T1-LSR domain as well as on devices situated 151 beyond the edge set. 153 _________________ 154 M0---/--O2-----O9 \ 155 / / \ \ 156 M1--|--O1 --O3--O4---O6-|---M3 157 \ \ / / 158 M2--\--O5 -- O7 --O8--/---M4 159 \_______________/ 160 TI-LSR domain 161 Mk: A TC-LSR (access routers), Ox: A TI-LSR (OXC) 163 Figure 1: An illustrative network with a TI-LSR domain 164 surrounded by an Edge set of TC-LSRs. 166 3. Required Enhancements to OXCs and WDM devices to support MPLS 168 The following discussion contains a list of some basic required 169 enhancements to OXCs and other WDM devices to support MPL(ambda)S: 171 - There should be a mechanism to exchange control information 172 between OXCs, and between OXCs and other LSRs. This can be 173 accomplished in-band or quasi-in-band using the same links 174 (fibers) that are used to carry data-plane traffic, or 175 out-of-band via a separate network. A combination of 176 in-band and out-of-band mechanisms may also be appropriate 177 under certain circumstances. 179 - An OXC must be able to provide the MPLS traffic engineering 180 control plane with pertinent information regarding the state of 181 individual fibers attached to that OXC, as well the state of 182 individual ligthpaths or optical channel trails within each 183 fiber. 185 - An edge LSR might not have intrinsic WDM capabilities. Instead, 186 it might interface to an external WDM device, using a 187 suitable technology such as SONET, GigEthernet, etc. 188 Even when an edge LSR does not have WDM capabilities, it 189 should still have the capability to exchange control information 190 with the OXCs in the domain. 192 4. Required Enhancements to the current MPLS control plane. 194 This section describes some basic required enhancements to the MPLS 195 traffic engineering control plane components (including ISIS/OSPF and 196 RSVP) in order to support MPL(ambda)S. Part (A) of this section 197 covers general enhancements while part (B) covers enhancements that 198 are specific to the nesting of LSPs. 200 A) General enhancements 202 - An MPLS domain may consist of links with different properties 203 depending upon the type of network elements at the endpoints 204 of the links (e.g., some of links may interconnect OXCs, some 205 links may interconnect frame-based LSRs and OXCs, while 206 other links may interconnect frame-based LSRs). Within the 207 context of Multiprotocol Lambda Switching, the properties of a 208 link consisting of a fiber with WDM that interconnects two OXCs 209 are different from the properties of a SONET link that 210 interconnects two LSRs. For example, a conventional LSP cannot 211 be terminated on a link connected to a pure OXC. However, a 212 conventional LSP can certainly be terminated on a link 213 connected to a frame-based LSR. These differences should be 214 taken into account when performing path computations to 215 determine an explicit route for an LSP. Additionally, since 216 the performance characteristics of an LSP will depend on the 217 characteristics of the links traversed by the LSP, it 218 may be useful to have the capability to restrict the path 219 of some LSPs to links with certain characteristics. The 220 concept of resource class attributes defined in [2] is one 221 approach to accomplish this containment, but other 222 mechanisms may also be feasible. 224 Thus, for example, it may be desirable for an IGP to carry 225 information regarding whether a particular link is TC or 226 TI. Path computation algorithms may then take this 227 information into account when computing paths LSPS. 229 - In certain contexts there may be multiple control 230 channels and bearer channels between a pair of adjacent 231 OXCs. Procedures are needed, therefore, to associate control 232 channels to bearer channels in such circumstances. Furthermore, 233 if a control channel is associated with multiple bearer 234 channels, then procedures are required to demultiplex the 235 control traffic for different bearer channels. Procedures are 236 also needed to activate and deactivate bearer channels, to 237 verify proper operation of bearer channels, and to assign 238 bearer channels to an LSP during the process of LSP 239 establishment. The procedures needed to accomplish the 240 objectives include the following aspects: a method to identify 241 the bearer channels associated with any given physical link, 242 methods to identify spare bearer channels for protection 243 purposes (e.g., 1+1, 1:1, and 1:N protection schemes), and 244 methods to identify an impaired bearer channel -- especially 245 in the situation where the physical links carrying the bearer 246 channel are not impaired. 248 - To perform the signaling function in Multiprotocol Lambda 249 Switching networks, RSVP should be extended with Objects, such 250 that when used in conjunction with available information 251 propagated through the IGP, the RSVP Objects will be able to 252 provide sufficient details to establish reconfiguration 253 parameters for OXC switch elements. 255 - When a pair of OXCs are directly connected by multiple links 256 (fibers), an IGP needs to carry information about the physical 257 diversity of the fibers. 259 - Because conventional LSRs and OXCs may support different 260 granularities of bandwidth allocation, an IGP should 261 be able to distribute information regarding the allocatable 262 bandwidth granularity of any particular link. This information 263 should allow multiple granularities within a single link. It 264 should also allow different granularities per priority. 266 Additional requirements which may be imposed by OXCs that cannot 267 perform wavelength translation are outside the scope of this 268 document. 270 B) As indicated in reference [1], the capability to aggregate LSPs 271 through the notion of nested LSPs is an important aspect of 272 using the MPLS traffic engineering control plane with OXCs. 274 Using the MPLS traffic engineering control plane, several 275 methods can be used to implement nested LSPs. One way to 276 accomplish this is to have a single MPLS traffic engineering 277 control plane instance for both conventional LSRs and OXCs, but 278 to allow the control plane to treat subsets of the LSPs as links 279 for the purpose of establishing new LSPs (by the same control 280 plane). In this way, the MPLS traffic engineering control plane 281 could use an LSP (which it had previously instantiated) as a 282 link to establish a new LSP. In principle, this technique can be 283 applied recursively to form several depths of LSP nesting. 285 Another way to accomplish LSP nesting is to have more than one 286 instance of the MPLS traffic engineering control plane, and to 287 allow LSPs created by one instance of the control plane to be 288 used as links by another instance of the control plane. 290 In general, irrespective of whether a single instance of the 291 MPLS traffic engineering control plane is used, or whether 292 multiple instances are used, the LSPs that serve as links for 293 other LSPs could be established by: (a) methods outside the 294 scope of the MPLS traffic engineering control plane (e.g., by 295 administrative configuration), or (b) via the MPLS traffic 296 engineering control plane. 298 The following paragraphs present a list of required enhancements 299 to the MPLS traffic engineering control plane components 300 (ISIS/OSPF and RSVP) in order to support the capability to 301 aggregate and nest LSPs in MPL(ambda)S: 303 - The LSP setup procedures should include support for an LSR at 304 the edge of a TI-LSR domain to aggregate multiple LSPs coming 305 from outside of the TI-LSR domain into an LSP that consists of 306 an optical channel trail. 308 - An LSR should be able to advertise into an IGP a link that 309 is formed from an LSP originated by the LSR, The IGP 310 should be able to advertise the link state for such links. 311 The link state information can be used subsequently for path 312 computations for other LSPs. 314 - In scenarios with more than one instance of the MPLS traffic 315 engineering control plane, one instance of the control plane 316 should be able to advertise LSPs created and maintained by that 317 instance as links to another instance of the MPLS traffic 318 engineering control plane. The instances of the control plane 319 may reside on the same network element or on different network 320 elements. 322 It should be noted that the capability to aggregate LSPs through 323 nesting may be useful in contexts outside of the OXC 324 environment. Therefore the required enhancements specified above to 325 support aggregation of LSPs through nesting should be implemented 326 in a manner such that they remain applicable in conventional 327 non-OXC environments. 329 The detailed specification of the enhancements to the MPLS traffic 330 engineering control component to support the MPL(ambda)S concept 331 will be covered in a supplementary document to follow. 333 5. Security Considerations 335 Security considerations are for future study. 337 6. References 339 [1] D. Awduche, Y. Rekhter, J. Drake, R. Coltun, "Multi-Protocol 340 Lambda Switching: Combining MPLS Traffic Engineering Control With 341 Optical Crossconnects", Internet Draft, Work in Progress. 343 [2] D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, and J. McManus, 344 "Requirements for Traffic Engineering Over MPLS," RFC-2702, September 345 1999. 347 [3] D. Awduche, "MPLS and Traffic Engineering in IP Networks," 348 IEEE Communications Magazine, December 1999. 350 [4] D. Awduche, L. Berger, D. Gan, T. Li, G. Swallow, and V. 351 Srinivasan, "Extensions to RSVP for LSP Tunnels," Internet Draft, 352 Work in Progress, 1999 354 [5] B. Jamoussi et al, "Constraint-Based LSP Setup using LDP," 356 [6] R. Callon, P. Doolan, N. Feldman, A. Fredette, G. Swallow, A. 357 Viswanathan, "A Framework for Multiprotocol Label Switching," 359 [7] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol Label 360 Switching Architecture," Internet Draft, Work in Progress, 1999 362 [8] T. Li, G. Swallow, D. Awduche, "IGP Requirements for Traffic 363 Engineering with MPLS," Internet Draft, Work in Progress, 1999 365 [9] H. Smith and T. Li, "IS-IS extensions for Traffic Engineering," 367 [10] D. Katz, D. Yeung, "Traffic Engineering Extensions to OSPF," 369 7. Author's Addresses 371 Debashis Basak 372 Marconi 373 1000 FORE Drive 374 Warrendale, PA 15086-7502 375 Phone: 724-742-7026 376 Email: dbasak@fore.com 378 Daniel O. Awduche 379 UUNET (MCI WorldCom) 380 22001 Loudoun County Parkway 381 Ashburn, VA 20147 382 Phone: 703-886-5277 383 Email: awduche@uu.net 385 John Drake 386 Chromisys, Inc 387 Phone: (408) 738-4194 x252 388 Email: jdrake@chromisys.com 390 Yakov Rekhter 391 Cisco Systems 392 170 W. Tasman Dr. 393 San Jose, CA 95134 394 Email: yakov@cisco.com