idnits 2.17.1 draft-ietf-mpls-multipath-use-00.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 (February 19, 2013) is 4083 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-05 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: August 23, 2013 February 19, 2013 7 Use of Multipath with MPLS-TP and MPLS 8 draft-ietf-mpls-multipath-use-00 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 LSPs can be carried over multipath 20 links while also providing a fully MPLS-TP compliant server layer for 21 MPLS-TP LSPs. This document describes the means of supporting MPLS 22 as a server layer for MPLS-TP. The use of MPLS-TP LSPs as a server 23 layer for MPLS LSPs 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 August 23, 2013. 42 Copyright Notice 44 Copyright (c) 2013 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 3.1. MPLS-TP Forwarding and Server Layer Requirements . . . . . 6 63 3.2. Methods of Supporting MPLS-TP client LSPs over MPLS . . . 7 64 4. MPLS-TP as a Server Layer for MPLS . . . . . . . . . . . . . . 10 65 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 66 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 11 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 71 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 1. Introduction 76 Today the requirement to handle large aggregations of traffic, can be 77 handled by a number of techniques which we will collectively call 78 multipath. Multipath applied to parallel links between the same set 79 of nodes includes Ethernet Link Aggregation [IEEE-802.1AX], link 80 bundling [RFC4201], or other aggregation techniques some of which may 81 be vendor specific. Multipath applied to diverse paths rather than 82 parallel links includes Equal Cost MultiPath (ECMP) as applied to 83 OSPF, ISIS, or BGP, and equal cost LSPs. Some vendors support load 84 split across equal cost MPLS LSPs where the load is split 85 proportionally to the reserved bandwidth of the set of LSPs. 87 RFC 5654 requirement 33 requires the capability to carry a client 88 MPLS-TP or MPLS layer over a server MPLS-TP or MPLS layer [RFC5654]. 89 This is possible in all cases with one exception. When an MPLS LSP 90 exceeds the capacity of any single component link it may be carried 91 by a network using multipath techniques, but may not be carried by a 92 single MPLS-TP LSP due to the inherent MPLS-TP capacity limitation 93 imposed by MPLS-TP OAM fate sharing constraints and MPLS-TP LM OAM 94 packet ordering constraints (see Section 3.1). 96 The term composite link is more general than terms such as link 97 aggregation (which is specific to Ethernet) or ECMP (which implies 98 equal cost paths within a routing protocol). The use of the term 99 composite link here is consistent with the broad definition in 100 [ITU-T.G.800]. Multipath is very similar to composite link as 101 defined by ITU, but specifically excludes inverse multiplexing. 103 2. Definitions 105 Multipath 106 The term multipath includes all techniques in which 108 1. Traffic can take more than one path from one node to a 109 destination. 111 2. Individual packets take one path only. Packets are not 112 subdivided and reassembled at the receiving end. 114 3. Packets are not resequenced at the receiving end. 116 4. The paths may be: 118 a. parallel links between two nodes, or 119 b. may be specific paths across a network to a destination 120 node, or 122 c. may be links or paths to an intermediate node used to 123 reach a common destination. 125 Link Bundle 126 Link bundling is a multipath technique specific to MPLS 127 [RFC4201]. Link bundling supports two modes of operations. 128 Either an LSP can be placed on one component link of a link 129 bundle, or an LSP can be load split across all members of the 130 bundle. There is no signaling defined which allows a per LSP 131 preference regarding load split, therefore whether to load split 132 is generally configured per bundle and applied to all LSPs across 133 the bundle. 135 Link Aggregation 136 The term "link aggregation" generally refers to Ethernet Link 137 Aggregation [IEEE-802.1AX] as defined by the IEEE. Ethernet Link 138 Aggregation defines a Link Aggregation Control Protocol (LACP) 139 which coordinates inclusion of LAG members in the LAG. 141 Link Aggregation Group (LAG) 142 A group of physical Ethernet interfaces that are treated as a 143 logical link when using Ethernet Link Aggregation is referred to 144 as a Link Aggregation Group (LAG). 146 Equal Cost Multipath (ECMP) 147 Equal Cost Multipath (ECMP) is a specific form of multipath in 148 which the costs of the links or paths must be equal in a given 149 routing protocol. The load may be split equally across all 150 available links (or available paths), or the load may be split 151 proportionally to the capacity of each link (or path). 153 Loop Free Alternate Paths 154 "Loop-free alternate paths" (LFA) are defined in RFC 5714, 155 Section 5.2 [RFC5714] as follows. "Such a path exists when a 156 direct neighbor of the router adjacent to the failure has a path 157 to the destination that can be guaranteed not to traverse the 158 failure." Further detail can be found in [RFC5286]. LFA as 159 defined for IPFRR can be used to load balance by relaxing the 160 equal cost criteria of ECMP, though IPFRR defined LFA for use in 161 selecting protection paths. When used with IP, proportional 162 split is generally not used. LFA use in load balancing is 163 implemented by some vendors though it may be rare or non-existent 164 in deployments. 166 Composite Link 167 The term Composite Link had been a registered trademark of Avici 168 Systems, but was abandoned in 2007. The term composite link is 169 now defined by the ITU in [ITU-T.G.800]. The ITU definition 170 includes multipath as defined here, plus inverse multiplexing 171 which is explicitly excluded from the definition of multipath. 173 Inverse Multiplexing 174 Inverse multiplexing either transmits whole packets and 175 resequences the packets at the receiving end or subdivides 176 packets and reassembles the packets at the receiving end. 177 Inverse multiplexing requires that all packets be handled by a 178 common egress packet processing element and is therefore not 179 useful for very high bandwidth applications. 181 Component Link 182 The ITU definition of composite link in [ITU-T.G.800] and the 183 IETF definition of link bundling in [RFC4201] both refer to an 184 individual link in the composite link or link bundle as a 185 component link. The term component link is applicable to all 186 multipath. 188 LAG Member 189 Ethernet Link Aggregation as defined in [IEEE-802.1AX] refers to 190 an individual link in a LAG as a LAG member. A LAG member is a 191 component link. An Ethernet LAG is a composite link. IEEE does 192 not use the terms composite link or component link. 194 load split 195 Load split, load balance, or load distribution refers to 196 subdividing traffic over a set of component links such that load 197 is fairly evenly distributed over the set of component links and 198 certain packet ordering requirements are met. Some existing 199 techniques better acheive these objectives than others. 201 A small set of requirements are discussed. These requirements make 202 use of keywords such as MUST and SHOULD as described in [RFC2119]. 204 3. MPLS as a Server Layer for MPLS-TP 206 An MPLS LSP may be used as a server layer for MPLS-TP LSPs as long as 207 all MPLS-TP requirements are met. Section 3.1 reviews the basis for 208 requirements of a server layer that supports MPLS-TP as a client 209 layer. Key requirements include OAM "fate-sharing" the the 210 requirement that packets within an MPLS-TP LSP are not reordered, 211 including both payload and OAM packets. Section 3.2 discusses 212 implied requirements where MPLS is the server layer for MPLS-TP 213 client LSPs, and describes a set of solutions using existing MPLS 214 mechanisms. 216 3.1. MPLS-TP Forwarding and Server Layer Requirements 218 [RFC5960] defines the date plane requirements for MPLS-TP. Two very 219 relevant paragraphs in "Section 3.1.1 LSP Packet Encapsulation and 220 Forwarding" are the following. 222 RFC5960, Section 3.1.1, Paragraph 3 223 Except for transient packet reordering that may occur, for 224 example, during fault conditions, packets are delivered in order 225 on L-LSPs, and on E-LSPs within a specific ordered aggregate. 227 RFC5960, Section 3.1.1, Paragraph 6 228 Equal-Cost Multi-Path (ECMP) load-balancing MUST NOT be performed 229 on an MPLS-TP LSP. MPLS-TP LSPs as defined in this document MAY 230 operate over a server layer that supports load-balancing, but 231 this load-balancing MUST operate in such a manner that it is 232 transparent to MPLS-TP. This does not preclude the future 233 definition of new MPLS-TP LSP types that have different 234 requirements regarding the use of ECMP in the server layer. 236 [RFC5960] paragraph 3 requires that packets within a specific ordered 237 aggregate be delivered in order. This same requirement is already 238 specified by Differentiated Services [RFC2475]. [RFC5960] paragraph 239 6 explicitly allows a server layer to use ECMP provided that it is 240 transparent to the MPLS-TP client layer. 242 [RFC6371] adds a requirement for data traffic and OAM traffic "fate- 243 sharing". The following paragraph in "Section 1 Introduction" 244 summarizes this requirement. 246 RFC6371, Section 1, Paragraph 7 247 OAM packets that instrument a particular direction of a transport 248 path are subject to the same forwarding treatment (i.e., fate- 249 share) as the user data packets and in some cases, where 250 Explicitly TC-encoded-PSC LSPs (E-LSPs) are employed, may be 251 required to have common per-hop behavior (PHB) Scheduling Class 252 (PSC) End-to-End (E2E) with the class of traffic monitored. In 253 case of Label-Only-Inferred-PSC LSP (L-LSP), only one class of 254 traffic needs to be monitored, and therefore the OAM packets have 255 common PSC with the monitored traffic class. 257 [RFC6371] does not prohibit multilink techniques in "Section 4.6 258 Fate-Sharing Considerations for Multilink", where multilink is 259 defined as Ethernet Link Aggregation and the use of Link Bundling for 260 MPLS, but does declare that such a network would be only partially 261 MPLS-TP compliant. The characteristic that is to be avoided is 262 contained in the following sentence in this section. 264 RFC6371, Section 4.6, Paragraph 1, last sentence 265 These techniques frequently share the characteristic that an LSP 266 may be spread over a set of component links and therefore be 267 reordered, but no flow within the LSP is reordered (except when 268 very infrequent and minimally disruptive load rebalancing 269 occurs). 271 A declaration that implies that Link Bundling for MPLS yields a 272 partially MPLS-TP compliant network, is perhaps overstated since only 273 the Link Bundling all-ones component link has this characteristic. 275 [RFC6374] defines a direct Loss Measurement (LM) where LM OAM packets 276 cannot be reordered with respect to payload packets. This will 277 require that payload packets themselves not be reordered. The 278 following paragraph in "Section 2.9.4 Equal Cost Multipath" gives the 279 reason for this restriction. 281 RFC6374, Section 2.9.4, Paragraph 2 282 The effects of ECMP on loss measurement will depend on the LM 283 mode. In the case of direct LM, the measurement will account for 284 any packets lost between the sender and the receiver, regardless 285 of how many paths exist between them. However, the presence of 286 ECMP increases the likelihood of misordering both of LM messages 287 relative to data packets and of the LM messages themselves. Such 288 misorderings tend to create unmeasurable intervals and thus 289 degrade the accuracy of loss measurement. The effects of ECMP 290 are similar for inferred LM, with the additional caveat that, 291 unless the test packets are specially constructed so as to probe 292 all available paths, the loss characteristics of one or more of 293 the alternate paths cannot be accounted for. 295 3.2. Methods of Supporting MPLS-TP client LSPs over MPLS 297 Supporting MPLS-TP LSPs over a fully MPLS-TP conformant MPLS LSP 298 server layer where the MPLS LSPs are making use of multipath, 299 requires special treatment of the MPLS-TP LSPs such that those LSPs 300 meet MPLS-TP forwarding requirements (see Section 3.1). This implies 301 the following brief set of requirements. 303 MP#1 It MUST be possible for a midpoint MPLS-TP LSR which is serving 304 as ingress to a server layer MPLS LSP to identify MPLS-TP LSPs, 305 so that MPLS-TP forwarding requirements can be applied, or to 306 otherwise accommodate the MPLS-TP forwarding requirements. 308 MP#2 It SHOULD be possible to completely exclude MPLS-TP LSPs from 309 the multipath hash and load split. If the selected component 310 link no longer meets requirements, an LSP is considered down 311 which may trigger protection and/or may require that the 312 ingress LSR select a new path and signal a new LSP. 314 MP#3 It SHOULD be possible to insure that MPLS-TP LSPs will not be 315 moved to another component link as a result of a composite link 316 load rebalancing operation. If the selected component link no 317 longer meets requirements, another component link may be 318 selected, however a change in path should not occur solely for 319 load balancing. 321 MP#4 Where an RSVP-TE control plane is used, it MUST be possible for 322 an ingress LSR which is setting up an MPLS-TP or an MPLS LSP to 323 determine at path selection time whether a link or Forwarding 324 Adjacency (FA, see [RFC4206]) within the topology can support 325 the MPLS-TP requirements of the LSP. 327 The reason for requirement MP#1 may not be obvious. A MPLS-TP LSP 328 may be aggregated along with other client LSP by a midpoint LSR into 329 a very large MPLS server layer LSP, as would be the case in a core 330 node to core node MPLS LSP between major cities. In this case the 331 ingress of the MPLS LSP cannot through any existing signaling 332 mechanism determine which client LSP contained within it as MPLS-TP 333 or not MPLS-TP. Multipath load splitting can be avoided for MPLS-TP 334 LSP if at the MPLS server layer LSP ingress LSR an Entropy Label 335 Indicator (ELI) and Entropy Label (EL) are added to the label stack 336 [RFC6790]. For those client LSP that are MPLS-TP LSP, a single EL 337 value must be chosen. For those client LSP that are MPLS LSP, per 338 packet entropy below the top label must, for practical reasons, be 339 used to determine the entropy label value. Requirement MP#1 simply 340 states that there must be a means to make this decision. 342 There is currently no signaling mechanism defined to support 343 requirement MP#1, though that does not preclude a new extension being 344 defined later. In the absense of a signaling extension, MPLS-TP can 345 be identified through some form of configuration, such as 346 configuration which provides an MPLS-TP compatible server layer to 347 all LSP arriving on a specific interface or originating from a 348 specific set of ingress LSR. 350 Alternately, the need for requirement MP#1 can be eliminated if evey 351 MPLS-TP LSP can be created by the MPLS-TP ingress makes use of an 352 Entropy Label Indicator (ELI) and Entropy Label (EL) below the 353 MPLS-TP label [RFC6790]. This would require that all MPLS-TP LSR in 354 a deployment support Entropy Label, which may render it impractical 355 in many deployments. 357 Some hardware which exists today can support requirement MP#2. 358 Signaling in the absense of MPLS Entropy Label can make use of link 359 bundling with the path pinned to a specific component for MPLS-TP LSP 360 and link bundling using the all-ones component for MPLS LSP. This 361 prevents MPLS-TP LSP from being carried within MPLS LSP but does 362 allow the co-existance of MPLS-TP and very large MPLS LSP. 364 MPLS-TP LSPs can be carried as client LSPs within an MPLS server LSP 365 if an Entropy Label Indicator (ELI) and Entropy Label (EL) is added 366 after the server layer LSP label(s) in the label stack, just above 367 the MPLS-TP LSP label entry [RFC6790]. The value of EL can be 368 randomly selected at the client MPLS-TP LSP setup time and the same 369 EL value used for all packets of that MPLS-TP LSP. This allows 370 MPLS-TP LSP to be carried as client LSP within MPLS LSP and satisfies 371 MPLS-TP forwarding requirements but requires that MPLS LSR be able to 372 identify MPLS-TP LSP (requirement MP#1). 374 MPLS-TP traffic can be protected from an degraded performance due to 375 an imperfect load split if the MPLS-TP traffic is given queuing 376 priority (using strict priority and policing or shaping at ingress or 377 locally or weighted queuing locally). This can be accomplished using 378 the Traffic Class field and Diffserv treatment of traffic 379 [RFC5462][RFC2475]. In the event of congestion due to load 380 imbalance, other traffic will suffer as long as there is a minority 381 of MPLS-TP traffic. 383 If MPLS-TP LSP are carried within MPLS LSP and ELI and EL are used, 384 requirement MP#3 is satisfied only for uncongested links where load 385 balancing is not required, or if MPLS-TP LSP use TC and Diffserv and 386 the load rebalancing implementation rebalances only the less 387 preferred traffic. Load rebalance is generally needed only when 388 congestion occurs, therefore restricting MPLS-TP to be carried only 389 over MPLS LSP that are known to traverse only links which are 390 expected to be uncongested can satisfy requirement MP#3. 392 An MPLS-TP LSP can be pinned to a Link Bundle component link if the 393 behavior of requirement MP#2 is preferred. An MPLS-TP LSP can be 394 assigned to a Link Bundle but not pinned if the behavior of 395 requirement MP#3 is preferred. In both of these cases, the MPLS-TP 396 LSP must be the top level LSP, except as noted above. 398 If MPLS-TP LSP can be moved among component links, then the Link 399 Bundle all-ones component link can be used or server layer MPLS LSPs 400 can be used with no restrictions on the server layer MPLS use of 401 multipath except that Entropy Label must be supported along the 402 entire path. An Entropy Label must be used to insure that all of the 403 MPLS-TP payload and OAM traffic are carried on the same component, 404 except during very infrequent transitions due to load balancing. 406 An MPLS-TP LSP may not traverse multipath links on the path where 407 MPLS-TP forwarding requirements cannot be met. Such links include 408 any using pre-RFC6790 Ethernet Link Aggregation, pre-RFC6790 Link 409 Bundling using the all-ones component link, or other form of 410 multipath not supporting termination of the entropy search at the EL 411 label as called for in [RFC6790]. An MPLS-TP LSP must not traverse a 412 server layer MPLS LSP which traverses any form of multipath not 413 supporting termination of the entropy search at the EL label. For 414 this to occur, the MPLS-TP ingress LSR must be aware of these links. 415 This is the reason for requirement MP#4. 417 Requirement MP#4 can be supported using administrative attributes. 418 Administrative attributes are defined in [RFC3209]. Some 419 configuration is required to support this. 421 4. MPLS-TP as a Server Layer for MPLS 423 Carrying MPLS LSP which are larger than a component link over a 424 MPLS-TP server layer requires that the large MPLS client layer LSP be 425 accommodated by multiple MPLS-TP server layer LSPs. MPLS multipath 426 can be used in the client layer MPLS. 428 Creating multiple MPLS-TP server layer LSP places a greater Incoming 429 Label Map (ILM) scaling burden on the LSR. High bandwidth MPLS cores 430 with a smaller amount of nodes have the greatest tendency to require 431 LSP in excess of component links, therefore the reduction in number 432 of nodes offsets the impact of increasing the number of server layer 433 LSP in parallel. Today, only in cases where deployed LSR ILM are 434 small would this be an issue. 436 The most significant disadvantage of MPLS-TP as a Server Layer for 437 MPLS is that the use MPLS-TP server layer LSP reduces the efficiency 438 of carrying the MPLS client layer. The service which provides by far 439 the largest offered load in provider networks is Internet, for which 440 the LSP capacity reservations are predictions of expected load. Many 441 of these MPLS LSP may be smaller than component link capacity. Using 442 MPLS-TP as a server layer results in bin packing problems for these 443 smaller LSP. For those LSP that are larger than component link 444 capacity, their capacity are not increments of convenient capacity 445 increments such as 10Gb/s. Using MPLS-TP as an underlying server 446 layer greatly reduces the ability of the client layer MPLS LSP to 447 share capacity. For example, when one MPLS LSP is underutilizing its 448 predicted capacity, the fixed allocation of MPLS-TP to component 449 links may not allow another LSP to exceed its predicted capacity. 450 Using MPLS-TP as a server layer may result in less efficient use of 451 resources and may result in a less cost effective network. 453 No additional requirements beyond MPLS-TP as it is now currently 454 defined are required to support MPLS-TP as a Server Layer for MPLS. 455 It is therefore viable but has some undesirable characteristics 456 discussed above. 458 5. Acknowledgements 460 Carlos Pignataro, Dave Allan, and Mach Chen provided valuable 461 comments and suggestions. Carlos suggested that MPLS-TP requirements 462 in RFC 5960 be explicitly referenced or quoted. An email 463 conversation with Dave led to the inclusion of references and quotes 464 from RFC 6371 and RFC 6374. Mach made suggestions to improve clarity 465 of the document. 467 6. Implementation Status 469 Note: this section is temporary and supports the experiment called 470 for in draft-sheffer-running-code. 472 This is an informational document which describes usage of MPLS and 473 MPLS-TP. No new protocol extensions or forwarding behavior are 474 specified. Ethernet Link Aggregation and MPLS Link Bundling are 475 widely implemented and deployed. 477 Entropy Label is not yet widely implemented and deployed, but both 478 implementation and deployment are expected soon. At least a few 479 existing high end commodity packet processing chips are capable of 480 supporting Entropy Label. It would be helpful if a few LSR suppliers 481 would state their intentions to support RFC 6790 on the mpls mailing 482 list. 484 Dynamic multipath (multipath load split adjustment in response to 485 observed load) is referred to but not a requirement of the usage 486 recommendations made in this document. Dynamic multipath has been 487 implemented and deployed, however (afaik) the only core LSR vendor 488 supporting dynamic multipath is no longer in the router business 489 (Avici Systems). At least a few existing high end commodity packet 490 processing chips are capable of supporting dynamic multipath. 492 7. IANA Considerations 494 This memo includes no request to IANA. 496 8. Security Considerations 498 This document specifies requirements with discussion of framework for 499 solutions using existing MPLS and MPLS-TP mechanisms. The 500 requirements and framework are related to the coexistence of MPLS/ 501 GMPLS (without MPLS-TP) when used over a packet network, MPLS-TP, and 502 multipath. The combination of MPLS, MPLS-TP, and multipath does not 503 introduce any new security threats. The security considerations for 504 MPLS/GMPLS and for MPLS-TP are documented in [RFC5920] and 505 [I-D.ietf-mpls-tp-security-framework]. 507 9. References 509 9.1. Normative References 511 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 512 Requirement Levels", BCP 14, RFC 2119, March 1997. 514 [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., 515 and S. Ueno, "Requirements of an MPLS Transport Profile", 516 RFC 5654, September 2009. 518 [RFC5960] Frost, D., Bryant, S., and M. Bocci, "MPLS Transport 519 Profile Data Plane Architecture", RFC 5960, August 2010. 521 [RFC6371] Busi, I. and D. Allan, "Operations, Administration, and 522 Maintenance Framework for MPLS-Based Transport Networks", 523 RFC 6371, September 2011. 525 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 526 Measurement for MPLS Networks", RFC 6374, September 2011. 528 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 529 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 530 RFC 6790, November 2012. 532 9.2. Informative References 534 [I-D.ietf-mpls-tp-security-framework] 535 Fang, L., Niven-Jenkins, B., Mansfield, S., and R. 536 Graveman, "MPLS-TP Security Framework", 537 draft-ietf-mpls-tp-security-framework-05 (work in 538 progress), October 2012. 540 [IEEE-802.1AX] 541 IEEE Standards Association, "IEEE Std 802.1AX-2008 IEEE 542 Standard for Local and Metropolitan Area Networks - Link 543 Aggregation", 2006, . 546 [ITU-T.G.800] 547 ITU-T, "Unified functional architecture of transport 548 networks", 2007, . 551 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 552 and W. Weiss, "An Architecture for Differentiated 553 Services", RFC 2475, December 1998. 555 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 556 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 557 Tunnels", RFC 3209, December 2001. 559 [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling 560 in MPLS Traffic Engineering (TE)", RFC 4201, October 2005. 562 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 563 Hierarchy with Generalized Multi-Protocol Label Switching 564 (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 566 [RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast 567 Reroute: Loop-Free Alternates", RFC 5286, September 2008. 569 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 570 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 571 Class" Field", RFC 5462, February 2009. 573 [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", 574 RFC 5714, January 2010. 576 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 577 Networks", RFC 5920, July 2010. 579 Author's Address 581 Curtis Villamizar (editor) 582 Outer Cape Cod Network Consulting 584 Email: curtis@occnc.com