idnits 2.17.1 draft-villamizar-mpls-tp-multipath-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 2, 2012) is 4217 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-09) exists of draft-ietf-mpls-tp-security-framework-04 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS C. Villamizar, Ed. 3 Internet-Draft Outer Cape Cod Network 4 Intended status: Informational Consulting 5 Expires: April 5, 2013 October 2, 2012 7 Use of Multipath with MPLS-TP and MPLS 8 draft-villamizar-mpls-tp-multipath-03 10 Abstract 12 Many MPLS implementations have supported multipath techniques and 13 many MPLS deployments have used multipath techniques, particularly in 14 very high bandwidth applications, such as provider IP/MPLS core 15 networks. MPLS-TP has strongly discouraged the use of multipath 16 techniques. Some degradation of MPLS-TP OAM performance cannot be 17 avoided when operating over many types of multipath implementations. 19 Using MPLS Entropy label, MPLS can LSP can be carried over multipath 20 links while also providing a fully MPLS-TP compliant server layer for 21 MPLS-TP LSP. This document describes the means of supporting MPLS as 22 a server layer for MPLS-TP. The use of MPLS-TP LSP as a server layer 23 for MPLS LSP is also discussed. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 5, 2013. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. MPLS as a Server Layer for MPLS-TP . . . . . . . . . . . . . . 5 62 4. MPLS-TP as a Server Layer for MPLS . . . . . . . . . . . . . . 7 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 67 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 1. Introduction 72 Today the requirement to handle large aggregations of traffic, can be 73 handled by a number of techniques which we will collectively call 74 multipath. Multipath applied to parallel links between the same set 75 of nodes includes Ethernet Link Aggregation [IEEE-802.1AX], link 76 bundling [RFC4201], or other aggregation techniques some of which may 77 be vendor specific. Multipath applied to diverse paths rather than 78 parallel links includes Equal Cost MultiPath (ECMP) as applied to 79 OSPF, ISIS, or BGP, and equal cost LSP. Some vendors support load 80 split across equal cost MPLS LSP where the load is split 81 proportionally to the reserved bandwidth of the set of LSP. 83 RFC 5654 requirement 33 requires the capability to carry a client 84 MPLS-TP or MPLS layer over a server MPLS-TP or MPLS layer [RFC5654]. 85 This is possible in all cases with one exception. When an MPLS LSP 86 exceeds the capacity of any single component link it may be carried 87 by a network using multipath techniques, but may not be carried by an 88 MPLS-TP LSP due to the inherent MPLS-TP capacity limitation imposed 89 by MPLS-TP OAM packet ordering constraints. 91 The term composite link is more general than terms such as link 92 aggregation (which is specific to Ethernet) or ECMP (which implies 93 equal cost paths within a routing protocol). The use of the term 94 composite link here is consistent with the broad definition in 95 [ITU-T.G.800]. Multipath is very similar to composite link as 96 defined by ITU, but specifically excludes inverse multiplexing. 98 2. Definitions 100 Multipath 101 The term multipath includes all techniques in which 103 1. Traffic can take more than one path from one node to a 104 destination. 106 2. Individual packets take one path only. Packets are not 107 subdivided and reassembled at the receiving end. 109 3. Packets are not resequenced at the receiving end. 111 4. The paths may be: 113 a. parallel links between two nodes, or 115 b. may be specific paths across a network to a destination 116 node, or 118 c. may be links or paths to an intermediate node used to 119 reach a common destination. 121 Link Bundle 122 Link bundling is a multipath technique specific to MPLS 123 [RFC4201]. Link bundling supports two modes of operations. 124 Either an LSP can be placed on one component link of a link 125 bundle, or an LSP can be load split across all members of the 126 bundle. There is no signaling defined which allows a per LSP 127 preference regarding load split, therefore whether to load split 128 is generally configured per bundle and applied to all LSP across 129 the bundle. 131 Link Aggregation 132 The term "link aggregation" generally refers to Ethernet Link 133 Aggregation [IEEE-802.1AX] as defined by the IEEE. Ethernet Link 134 Aggregation defines a Link Aggregation Control Protocol (LACP) 135 which coordinates inclusion of LAG members in the LAG. 137 Link Aggregation Group (LAG) 138 A group of physical Ethernet interfaces that are treated as a 139 logical link when using Ethernet Link Aggregation is referred to 140 as a Link Aggregation Group (LAG). 142 Equal Cost Multipath (ECMP) 143 Equal Cost Multipath (ECMP) is a specific form of multipath in 144 which the costs of the links or paths must be equal in a given 145 routing protocol. The load may be split equally across all 146 available links (or available paths), or the load may be split 147 proportionally to the capacity of each link (or path). 149 Loop Free Alternate Paths 150 "Loop-free alternate paths" (LFA) are defined in RFC 5714, 151 Section 5.2 [RFC5714] as follows. "Such a path exists when a 152 direct neighbor of the router adjacent to the failure has a path 153 to the destination that can be guaranteed not to traverse the 154 failure." Further detail can be found in [RFC5286]. LFA as 155 defined for IPFRR can be used to load balance by relaxing the 156 equal cost criteria of ECMP, though IPFRR defined LFA for use in 157 selecting protection paths. When used with IP, proportional 158 split is generally not used. LFA use in load balancing is 159 implemented by some vendors though it may be rare or non-existent 160 in deployments. 162 Composite Link 163 The term Composite Link had been a registered trademark of Avici 164 Systems, but was abandoned in 2007. The term composite link is 165 now defined by the ITU in [ITU-T.G.800]. The ITU definition 166 includes multipath as defined here, plus inverse multiplexing 167 which is explicitly excluded from the definition of multipath. 169 Inverse Multiplexing 170 Inverse multiplexing either transmits whole packets and 171 resequences the packets at the receiving end or subdivides 172 packets and reassembles the packets at the receiving end. 173 Inverse multiplexing requires that all packets be handled by a 174 common egress packet processing element and is therefore not 175 useful for very high bandwidth applications. 177 Component Link 178 The ITU definition of composite link in [ITU-T.G.800] and the 179 IETF definition of link bundling in [RFC4201] both refer to an 180 individual link in the composite link or link bundle as a 181 component link. The term component link is applicable to all 182 multipath. 184 LAG Member 185 Ethernet Link Aggregation as defined in [IEEE-802.1AX] refers to 186 an individual link in a LAG as a LAG member. A LAG member is a 187 component link. An Ethernet LAG is a composite link. IEEE does 188 not use the terms composite link or component link. 190 load split 191 Load split, load balance, or load distribution refers to 192 subdividing traffic over a set of component links such that load 193 is fairly evenly distributed over the set of component links and 194 certain packet ordering requirements are met. Some existing 195 techniques better acheive these objectives than others. 197 A small set of requirements are discussed. These requirements make 198 use of keywords such as MUST and SHOULD as described in [RFC2119]. 200 3. MPLS as a Server Layer for MPLS-TP 202 MPLS LSP may be used as a server layer for MPLS-TP LSP as long as all 203 MPLS-TP requirements are met, including the requirement that packets 204 within an MPLS-TP LSP are not reordered, including both payload and 205 OAM packets. 207 Supporting MPLS-TP LSP overa fully MPLS-TP conformant MPLS LSP server 208 layer where the MPLS LSP are making use of multipath, requires 209 special treatment of the MPLS-TP LSP such that those LSP only are not 210 subject to the multipath load slitting. This implies the following 211 brief set of requirements. 213 MP#1 It MUST be possible to identify MPLS-TP LSP. 215 MP#2 It MUST be possible to completely exclude MPLS-TP LSP from the 216 multipath hash and load split. 218 MP#3 It SHOULD be possible to insure that an MPLS-TP LSP will not be 219 moved to another component link as a result of a composite link 220 load rebalancing operation. 222 MP#4 Where an RSVP-TE control plane is used, it MUST be possible for 223 an ingress LSR which is setting up an MPLS-TP or MPLS LSP to 224 determine at CSPF time whether a link or MPLS PSC LSP within 225 the topology can support the MPLS-TP requirements of the LSP. 227 There is currently no signaling mechanism defined to support 228 requirement MP#1. In the absense of a signaling extension, MPLS-TP 229 can be identified through some form of configuration, such as 230 configuration which provides an MPLS-TP compatible server layer to 231 all LSP arriving on a specific interface or originating from a 232 specific set of ingress LSR. Alternately an MPLS-TP LSP can be 233 created with and Entropy Label Indicator (ELI) and entropy label (EL) 234 below the MPLS-TP label [I-D.ietf-mpls-entropy-label]. 236 Some hardware which exists today can support requirement MP#2. 237 Signaling in the absense of MPLS Entropy Label can make use of link 238 bundling with a specific component for MPLS-TP LSP and link bundling 239 with the all-zeros component for MPLS LSP. This prevents MPLS-TP LSP 240 from being carried within MPLS LSP but does allow the co-existance of 241 MPLS-TP and very large MPLS LSP. 243 MPLS-TP LSP can be carried as client LSP within an MPLS server LSP if 244 an Entropy Label Indicator (ELI) and entropy label (EL) is added 245 after the server layer LSP label(s) in the label stack, just above 246 the MPLS-TP LSP label entry [I-D.ietf-mpls-entropy-label]. This 247 allows MPLS-TP LSP to be carried as client LSP within MPLS LSP and 248 satisfies requirement MP#2 but requires that MPLS LSR be able to 249 identify MPLS-TP LSP (requirement MP#1). 251 MPLS-TP traffic can be protected from an degraded performance due to 252 an imperfect load split if the MPLS-TP traffic is given queuing 253 priority (using strict priority and policing or shaping at ingress or 254 locally or weighted queuing locally). This can be accomplished using 255 the Traffic Class field and Diffserv treatment of traffic 256 [RFC5462][RFC2475]. In the event of congestion due to load 257 imbalance, other traffic will suffer as long as there is a minority 258 of MPLS-TP traffic. 260 If MPLS-TP LSP are carried within MPLS LSP and ELI and EL are used, 261 requirement MP#2 is satisfied, but without a signaling extension, 262 requirement MP#3 is not satisfied if there is a need to rebalance the 263 load on any composite link carrying the MPLS server LSP. Load 264 rebalance is generally needed only when congestion occurs, therefore 265 restricting MPLS-TP to be carried only over MPLS LSP that are known 266 to traverse only links which are expected to be uncongested can 267 satisfy requirement MP#3. 269 Requirement MP#4 can be supported using administrative attributes. 270 Administrative attributes are defined in [RFC3209]. Some 271 configuration is required to support this. 273 4. MPLS-TP as a Server Layer for MPLS 275 Carrying MPLS LSP which are larger than a component link over a 276 MPLS-TP server layer requires that the large MPLS client layer LSP be 277 accommodated by multiple MPLS-TP server layer LSPs. MPLS multipath 278 can be used in the client layer MPLS. 280 Creating multiple MPLS-TP server layer LSP places a greater ILM 281 scaling burden on the LSR. High bandwidth MPLS cores with a smaller 282 amount of nodes have the greatest tendency to require LSP in excess 283 of component links, therefore the reduction in number of nodes 284 offsets the impact of increasing the number of server layer LSP in 285 parallel. Today, only in cases where deployed LSR ILM are small 286 would this be an issue. 288 The most significant disadvantage of MPLS-TP as a Server Layer for 289 MPLS is that the use MPLS-TP server layer LSP reduces the efficiency 290 of carrying the MPLS client layer. The service which provides by far 291 the largest offered load in provider networks is Internet, for which 292 the LSP capacity reservations are predictions of expected load. Many 293 of these MPLS LSP may be smaller than component link capacity. Using 294 MPLS-TP as a server layer results in bin packing problems for these 295 smaller LSP. For those LSP that are larger than component link 296 capacity, their capacity are not increments of convenient capacity 297 increments such as 10Gb/s. Using MPLS-TP as an underlying server 298 layer greatly reduces the ability of the client layer MPLS LSP to 299 share capacity. For example, when one MPLS LSP is underutilizing its 300 predicted capacity, the fixed allocation of MPLS-TP to component 301 links may not allow another LSP to exceed its predicted capacity. 302 Using MPLS-TP as a server layer may result in less efficient use of 303 resources may result in a less cost effective network. 305 No additional requirements beyond MPLS-TP as it is now currently 306 defined are required to support MPLS-TP as a Server Layer for MPLS. 307 It is therefore viable but has some undesirable characteristics 308 discussed above. 310 5. IANA Considerations 312 This memo includes no request to IANA. 314 6. Security Considerations 316 This document specifies requirements with discussion of framework for 317 solutions using existing MPLS and MPLS-TP mechanisms. The 318 requirements and framework are related to the coexistence of MPLS/ 319 GMPLS (without MPLS-TP) when used over a packet network, MPLS-TP, and 320 multipath. The combination of MPLS, MPLS-TP, and multipath does not 321 introduce any new security threats. The security considerations for 322 MPLS/GMPLS and for MPLS-TP are documented in [RFC5920] and 323 [I-D.ietf-mpls-tp-security-framework]. 325 7. References 327 7.1. Normative References 329 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 330 Requirement Levels", BCP 14, RFC 2119, March 1997. 332 7.2. Informative References 334 [I-D.ietf-mpls-entropy-label] 335 Kompella, K., Drake, J., Amante, S., Henderickx, W., and 336 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 337 draft-ietf-mpls-entropy-label-06 (work in progress), 338 September 2012. 340 [I-D.ietf-mpls-tp-security-framework] 341 Fang, L., Niven-Jenkins, B., Mansfield, S., and R. 342 Graveman, "MPLS-TP Security Framework", 343 draft-ietf-mpls-tp-security-framework-04 (work in 344 progress), July 2012. 346 [IEEE-802.1AX] 347 IEEE Standards Association, "IEEE Std 802.1AX-2008 IEEE 348 Standard for Local and Metropolitan Area Networks - Link 349 Aggregation", 2006, . 352 [ITU-T.G.800] 353 ITU-T, "Unified functional architecture of transport 354 networks", 2007, . 357 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 358 and W. Weiss, "An Architecture for Differentiated 359 Services", RFC 2475, December 1998. 361 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 362 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 363 Tunnels", RFC 3209, December 2001. 365 [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling 366 in MPLS Traffic Engineering (TE)", RFC 4201, October 2005. 368 [RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast 369 Reroute: Loop-Free Alternates", RFC 5286, September 2008. 371 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 372 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 373 Class" Field", RFC 5462, February 2009. 375 [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., 376 and S. Ueno, "Requirements of an MPLS Transport Profile", 377 RFC 5654, September 2009. 379 [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", 380 RFC 5714, January 2010. 382 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 383 Networks", RFC 5920, July 2010. 385 Author's Address 387 Curtis Villamizar (editor) 388 Outer Cape Cod Network Consulting 390 Email: curtis@occnc.com