idnits 2.17.1 draft-ietf-rtgwg-cl-requirement-16.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 date (February 06, 2014) is 3725 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-06) exists of draft-ietf-rtgwg-cl-use-cases-05 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTGWG C. Villamizar, Ed. 3 Internet-Draft OCCNC, LLC 4 Intended status: Informational D. McDysan, Ed. 5 Expires: August 10, 2014 Verizon 6 S. Ning 7 Tata Communications 8 A. Malis 9 Huawei 10 L. Yong 11 Huawei USA 12 February 06, 2014 14 Requirements for Advanced Multipath in MPLS Networks 15 draft-ietf-rtgwg-cl-requirement-16 17 Abstract 19 This document provides a set of requirements for Advanced Multipath 20 in MPLS Networks. 22 Advanced Multipath is a formalization of multipath techniques 23 currently in use in IP and MPLS networks and a set of extensions to 24 existing multipath techniques. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on August 10, 2014. 43 Copyright Notice 45 Copyright (c) 2014 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 62 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Functional Requirements . . . . . . . . . . . . . . . . . . . 6 64 3.1. Availability, Stability and Transient Response . . . . . 6 65 3.2. Component Links Provided by Lower Layer Networks . . . . 8 66 3.3. Component Links with Different Characteristics . . . . . 8 67 3.4. Considerations for Bidirectional Client LSP . . . . . . . 9 68 3.5. Multipath Load Balancing Dynamics . . . . . . . . . . . . 10 69 4. General Requirements for Protocol Solutions . . . . . . . . . 12 70 5. Management Requirements . . . . . . . . . . . . . . . . . . . 13 71 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 73 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 75 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 76 9.2. Informative References . . . . . . . . . . . . . . . . . 15 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 79 1. Introduction 81 There is often a need to provide large aggregates of bandwidth that 82 are best provided using parallel links between routers or carrying 83 traffic over multiple MPLS Label Switched Paths (LSPs). In core 84 networks there is often no alternative since the aggregate capacities 85 of core networks today far exceed the capacity of a single physical 86 link or single packet processing element. 88 The presence of parallel links, with each link potentially comprised 89 of multiple layers has resulted in additional requirements. Certain 90 services may benefit from being restricted to a subset of the 91 component links or a specific component link, where component link 92 characteristics, such as latency, differ. Certain services require 93 that an LSP be treated as atomic and avoid reordering. Other 94 services will continue to require only that reordering not occur 95 within a flow as is current practice. 97 Numerous forms of multipath exist today including MPLS Link Bundling 98 [RFC4201], Ethernet Link Aggregation [IEEE-802.1AX], and various 99 forms of Equal Cost Multipath (ECMP) such as for OSPF ECMP, IS-IS 100 ECMP, and BGP ECMP. Refer to the Appendices in 101 [I-D.ietf-rtgwg-cl-use-cases] for a description of existing 102 techniques and a set of references. 104 The purpose of this document is to clearly enumerate a set of 105 requirements related to the protocols and mechanisms that provide 106 MPLS based Advanced Multipath. The intent is to first provide a set 107 of functional requirements, in Section 3, that are as independent as 108 possible of protocol specifications . A set of general protocol 109 requirements are defined in Section 4. A set of network management 110 requirements are defined in Section 5. 112 1.1. Requirements Language 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in RFC 2119 [RFC2119]. 118 Any statement which requires the solution to support some new 119 functionality through use of [RFC2119] keywords should be interpreted 120 as follows. The implementation either MUST or SHOULD support the new 121 functionality depending on the use of either MUST or SHOULD in the 122 requirements statement. The implementation SHOULD in most or all 123 cases allow any new functionality to be individually enabled or 124 disabled through configuration. A service provider or other 125 deployment MAY enable or disable any feature in their network, 126 subject to implementation limitations on sets of features which can 127 be disabled. 129 2. Definitions 131 Multipath 132 The term multipath includes all techniques in which 134 1. Traffic can take more than one path from one node to a 135 destination. 137 2. Individual packets take one path only. Packets are not 138 subdivided and reassembled at the receiving end. 140 3. Packets are not resequenced at the receiving end. 142 4. The paths may be: 144 a. parallel links between two nodes, or 145 b. specific paths across a network to a destination node, or 147 c. links or paths to an intermediate node used to reach a 148 common destination. 150 The paths need not have equal capacity. The paths may or may not 151 have equal cost in a routing protocol. 153 Advanced Multipath 154 Advanced Multipath is a formalization of multipath techniques 155 that meets the requirements defined in this document. A key 156 capability of Advanced Multipath is the support of non- 157 homogeneous component links. 159 Advanced Multipath Group (AMG) 160 An Advanced Multipath Group (AMG) is a collection of component 161 links where Advanced Multipath techniques are applied. 163 Composite Link 164 The term Composite Link had been a registered trademark of Avici 165 Systems, but was abandoned in 2007. The term composite link is 166 now defined by the ITU-T in [ITU-T.G.800]. The ITU-T definition 167 includes multipath as defined here, plus inverse multiplexing 168 which is explicitly excluded from the definition of multipath. 170 Inverse Multiplexing 171 Inverse multiplexing is another method of sending traffic over 172 multiple links. Inverse multiplexing either transmits whole 173 packets and resequences the packets at the receiving end or 174 subdivides packets and reassembles the packets at the receiving 175 end. Inverse multiplexing requires that all packets be handled 176 by a common egress packet processing element and is therefore not 177 useful for very high bandwidth applications. 179 Component Link 180 The ITU-T definition of composite link in [ITU-T.G.800] and the 181 IETF definition of link bundling in [RFC4201] both refer to an 182 individual link in the composite link or link bundle as a 183 component link. The term component link is applicable to all 184 forms of multipath. The IEEE uses the term member rather than 185 component link in Ethernet Link Aggregation [IEEE-802.1AX]. 187 Client Layer 188 A client layer is the layer immediately above a server layer. 190 Server Layer 191 A server layer is the layer immediately below a client layer. 193 Higher Layers 194 Relative to a particular layer, a client layer and any layer 195 above that is considered a higher layer. Upper layer is 196 synonymous with higher layer. 198 Lower Layers 199 Relative to a particular layer, a server layer and any layer 200 below that is considered a lower layer. 202 Client LSP 203 A client LSP is an LSP which has been set up over one or more 204 lower layers. In the context of this discussion, one type of 205 client LSP is a LSP which has been set up over an AMG. 207 Flow 208 A sequence of packets that should be transferred in order on one 209 component link of a multipath. 211 Flow Identification 212 The label stack and other information that uniquely identifies a 213 flow. Other information in flow identification may include an IP 214 header, pseudowire (PW) control word, Ethernet MAC address, etc. 215 Note that a client LSP may contain one or more Flows or a client 216 LSP may be equivalent to a Flow. Flow identification is used to 217 locally select a component link, or a path through the network 218 toward the destination. 220 Load Balance 221 Load split, load balance, or load distribution refers to 222 subdividing traffic over a set of component links such that load 223 is fairly evenly distributed over the set of component links and 224 certain packet ordering requirements are met. Some existing 225 techniques better achieve these objectives than others. 227 Performance Objective 228 Numerical values for performance measures, principally 229 availability, latency, and delay variation. Performance 230 objectives may be related to Service Level Agreements (SLA) as 231 defined in RFC2475 or may be strictly internal. Performance 232 objectives may span links, edge-to-edge, or end-to-end. 233 Performance objectives may span one provider or may span multiple 234 providers. 236 A Component Link may be a point-to-point physical link (where a 237 "physical link" includes one or more link layer plus a physical 238 layer) or a logical link that preserves ordering in the steady state. 239 A component link may have transient out of order events, but such 240 events must not exceed the network's Performance Objectives. For 241 example, a component link may be comprised of any supportable 242 combination of link layers over a physical layer or over logical sub- 243 layers, including those providing physical layer emulation, or over 244 MPLS server layer LSP. 246 The ingress and egress of a multipath may be midpoint LSRs with 247 respect to a given client LSP. A midpoint LSR does not participate 248 in the signaling of any clients of the client LSP. Therefore, in 249 general, multipath endpoints cannot determine requirements of clients 250 of a client LSP through participation in the signaling of the clients 251 of the client LSP. 253 This document makes no statement on whether Advanced Multipath is 254 itself a layer or whether an instance of AMG is itself a layer. This 255 is to avoid engaging in long and pointless discussions about what 256 consistitutes a proper layer. 258 The term Advanced Multipath is intended to be used within the context 259 of this document and the related documents, 260 [I-D.ietf-rtgwg-cl-use-cases] and [I-D.ietf-rtgwg-cl-framework] and 261 any other related document. Other advanced multipath techniques may 262 in the future arise. If the capabilities defined in this document 263 become commonplace, they would no longer be considered "advanced". 264 Use of the term "advanced multipath" outside this document, if 265 referring to the term as defined here, should indicate Advanced 266 Multipath as defined by this document, citing the current document 267 name. If using another definition of "advanced multipath", documents 268 may optionally clarify that they are not using the term "advanced 269 multipath" as defined by this document if clarification is deemed 270 helpful. 272 3. Functional Requirements 274 The Functional Requirements in this section are grouped in 275 subsections starting with the highest priority. 277 3.1. Availability, Stability and Transient Response 279 Limiting the period of unavailability in response to failures or 280 transient events is extremely important as well as maintaining 281 stability. 283 FR#1 The transient period between some service disrupting event and 284 the convergence of the routing and/or signaling protocols MUST 285 occur within a time frame specified by Performance Objective 286 values. 288 FR#2 An AMG MAY be announced in conjunction with detailed parameters 289 about its component links, such as bandwidth and latency. The 290 AMG SHALL behave as a single IGP adjacency. 292 FR#3 The solution SHALL provide a means to summarize some routing 293 advertisements regarding the characteristics of an AMG such that 294 the updated protocol mechanisms maintain convergence times within 295 the timeframe needed to meet or not significantly exceed existing 296 Performance Objective for convergence on the same network or 297 convergence on a network with a similar topology. 299 FR#4 The solution SHALL ensure that restoration operations happen 300 within the timeframe needed to meet existing Performance 301 Objective for restoration time on the same network or restoration 302 time on a network with a similar topology. 304 FR#5 The solution shall provide a mechanism to select a set of paths 305 for an LSP across a network in such a way that flows within the 306 LSP are distributed across the set of paths while meeting all of 307 the other requirements stated above. The solution SHOULD work in 308 a manner similar to existing multipath techniques except as 309 necessary to accommodate Advanced Multipath requirements. 311 FR#6 If extensions to existing protocols are specified and/or new 312 protocols are defined, then the solution SHOULD provide a means 313 for a network operator to migrate an existing deployment in a 314 minimally disruptive manner. 316 FR#7 Any load balancing solutions MUST NOT oscillate. Some change 317 in path MAY occur. The solution MUST ensure that path stability 318 and traffic reordering continue to meet Performance Objective on 319 the same network or on a network with a similar topology. Since 320 oscillation may cause reordering, there MUST be means to control 321 the frequency of changing the component link over which a flow is 322 placed. 324 FR#8 Management and diagnostic protocols MUST be able to operate 325 over AMGs. 327 Existing scaling techniques used in MPLS networks apply to MPLS 328 networks which support Advanced Multipath. Scalability and stability 329 are covered in more detail in [I-D.ietf-rtgwg-cl-framework]. 331 3.2. Component Links Provided by Lower Layer Networks 333 A component link may be supported by a lower layer network. For 334 example, the lower layer may be a circuit switched network or another 335 MPLS network (e.g., MPLS-TP)). The lower layer network may change 336 the latency (and/or other performance parameters) seen by the client 337 layer. Currently, there is no protocol for the lower layer network 338 to inform the higher layer network of a change in a performance 339 parameter. Communication of the latency performance parameter is a 340 very important requirement. Communication of other performance 341 parameters (e.g., delay variation) is desirable. 343 FR#9 The solution SHALL specify a protocol means to allow a server 344 layer network to communicate latency to the client layer network. 346 FR#10 The precision of latency reporting SHOULD be configurable. A 347 reasonable default SHOULD be provided. Implementations SHOULD 348 support precision of at least 10% of the one way latencies for 349 latency of 1 msec or more. 351 The intent is to measure the predominant latency in uncongested 352 service provider networks, where geographic delay dominates and is on 353 the order of milliseconds or more. The argument for including 354 queuing delay is that it reflects the delay experienced by 355 applications. The argument against including queuing delay is that 356 if used in routing decisions it can result in routing instability. 357 This tradeoff is discussed in detail in 358 [I-D.ietf-rtgwg-cl-framework]. 360 3.3. Component Links with Different Characteristics 362 As one means to provide high availability, network operators deploy a 363 topology in the MPLS network using lower layer networks that have a 364 certain degree of diversity at the lower layer(s). Many techniques 365 have been developed to balance the distribution of flows across 366 component links that connect the same pair of nodes or ultimately 367 lead to a common destination. 369 FR#11 In requirements that follow in this document the word 370 "indicate" is used where information may be provided by either 371 the combination of link state IGP advertisement and MPLS LSP 372 signaling or via management plane protocols. In later documents 373 providing framework and protocol definitions both signaling and 374 management plane mechanisms MUST be defined. 376 FR#12 The solution SHALL provide a means for the client layer to 377 indicate a requirement that a client LSP will traverse a 378 component link with the minimum latency value. This will provide 379 a means by which minimum latency Performance Objectives of flows 380 within the client LSP can be supported. 382 FR#13 The solution SHALL provide a means for the client layer to 383 indicate a requirement that a client LSP will traverse a 384 component link with a maximum acceptable latency value as 385 specified by protocol. This will provide a means by which 386 bounded latency Performance Objectives of flows within the client 387 LSP can be supported. 389 FR#14 The solution SHALL provide a means for the client layer to 390 indicate a requirement that a client LSP will traverse a 391 component link with a maximum acceptable delay variation value as 392 specified by protocol. 394 The above set of requirements apply to component links with different 395 characteristics regardless as to whether those component links are 396 provided by parallel physical links between nodes or provided by sets 397 of paths across a network provided by server layer LSP. 399 Allowing multipath to contain component links with different 400 characteristics can improve the overall load balance and can be 401 accomplished while still accommodating the more strict requirements 402 of a subset of client LSP. 404 3.4. Considerations for Bidirectional Client LSP 406 Some client LSP MAY require a path bound to a specific set of 407 component links. This case is most likely to occur in bidirectional 408 client LSP where time synchronization protocols such as Precision 409 Time Protocol (PTP) or Network Time Protocol (NTP) are carried, or in 410 any other case where symmetric delay is highly desirable. There may 411 be other uses of this capability. 413 Other client LSP may only require that the LSP path serve the same 414 set of nodes in both directions. This is necessary if protocols are 415 carried which make use of the reverse direction of the LSP as a back 416 channel in cases such OAM protocols using IPv4 Time to Live (TTL) or 417 IPv4 Hop Limit to monitor or diagnose the underlying path. There may 418 be other uses of this capability. 420 FR#15 The solution SHALL provide a means for the client layer to 421 indicate a requirement that a client LSP be bound to a particular 422 component link within an AMG. If this option is not exercised, 423 then a client LSP that is carried over an AMG may be bound to any 424 component link or set of component links matching all other 425 signaled requirements, and different directions of a 426 bidirectional client LSP can be bound to different component 427 links. 429 FR#16 The solution MUST support a means for the client layer to 430 indicate a requirement that for a specific co-routed 431 bidirectional client LSP both directions of the co-routed 432 bidirectional client LSP MUST be bound to the same set of nodes. 434 FR#17 A client LSP which is bound to a specific component link SHOULD 435 NOT exceed the capacity of a single component link. This is 436 inherent in the assumption that a network SHOULD NOT operate in a 437 congested state if congestion is avoidable. 439 For some large bidirectional client LSP it may not be necessary (or 440 possible due to the client LSP capacity) to bind the LSP to a common 441 set of component links but may be necessary or desirable to constrain 442 the path taken by the LSP to the same set of nodes in both 443 directions. Without an entirely new and highly dynamic protocol, it 444 is not feasible to constrain such an bidirectional client LSP to take 445 multiple paths and coordinate load balance on each side to keep both 446 directions of flows within such an LSP on common paths. 448 3.5. Multipath Load Balancing Dynamics 450 Multipath load balancing attempts to keep traffic levels on all 451 component links below congestion levels if possible and preferably 452 well balanced. Load balancing is minimally disruptive (see 453 discussion below this section's list of requirements). The 454 sensitivity to these minimal disruptions of traffic flows within 455 specific client LSP needs to be considered. 457 FR#18 The solution SHALL provide a means for the client layer to 458 indicate a requirement that a specific client LSP MUST NOT be 459 split across multiple component links. 461 FR#19 The solution SHALL provide a means local to a node that 462 automatically distributes flows across the component links in the 463 AMG such that Performance Objectives are met as described in 464 prior requirements in Section 3.3. 466 FR#20 The solution SHALL measure traffic flows or groups of traffic 467 flows and dynamically select the component link on which to place 468 this traffic in order to balance the load so that no component 469 link in the AMG between a pair of nodes is overloaded. 471 FR#21 When a traffic flow is moved from one component link to another 472 in the same AMG between a set of nodes, it MUST be done so in a 473 minimally disruptive manner. 475 FR#22 Load balancing MAY be used during sustained low traffic periods 476 to reduce the number of active component links for the purpose of 477 power reduction. 479 FR#23 The solution SHALL provide a means for the client layer to 480 indicate a requirement that a specific client LSP contains 481 traffic whose frequency of component link change due to load 482 balancing needs to be bounded by a specific value. The solution 483 MUST provide a means to bound the frequency of component link 484 change due to load balancing for subsets of traffic flow on AMGs. 486 FR#24 The solution SHALL provide a means to distribute traffic flows 487 from a single client LSP across multiple component links to 488 handle at least the case where the traffic carried in an client 489 LSP exceeds that of any component link in the AMG. 491 FR#25 The solution SHOULD support the use case where an AMG itself is 492 a component link for a higher order AMG. For example, an AMG 493 comprised of MPLS-TP bi-directional tunnels viewed as logical 494 links could then be used as a component link in yet another AMG 495 that connects MPLS routers. 497 FR#26 If the total demand offered by traffic flows exceeds the 498 capacity of the AMG, the solution SHOULD define a means to cause 499 some client LSP to move to an alternate set of paths that are not 500 congested. These "preempted LSP" may not be restored if there is 501 no uncongested path in the network. 503 A minimally disruptive change implies that as little disruption as is 504 practical occurs. Such a change can be achieved with zero packet 505 loss. A delay discontinuity may occur, which is considered to be a 506 minimally disruptive event for most services if this type of event is 507 sufficiently rare. A delay discontinuity is an example of a 508 minimally disruptive behavior corresponding to current techniques. 510 A delay discontinuity is an isolated event which may greatly exceed 511 the normal delay variation (jitter). A delay discontinuity has the 512 following effect. When a flow is moved from a current link to a 513 target link with lower latency, reordering can occur. When a flow is 514 moved from a current link to a target link with a higher latency, a 515 time gap can occur. Some flows (e.g., timing distribution, PW 516 circuit emulation) are quite sensitive to these effects. A delay 517 discontinuity can also cause a jitter buffer underrun or overrun 518 affecting user experience in real time voice services (causing an 519 audible click). These sensitivities may be specified in a 520 Performance Objective. 522 As with any load balancing change, a change initiated for the purpose 523 of power reduction may be minimally disruptive. Typically the 524 disruption is limited to a change in delay characteristics and the 525 potential for a very brief period with traffic reordering. The 526 network operator when configuring a network for power reduction 527 should weigh the benefit of power reduction against the disadvantage 528 of a minimal disruption. 530 4. General Requirements for Protocol Solutions 532 This section defines requirements for protocol specification used to 533 meet the functional requirements specified in Section 3. 535 GR#1 The solution SHOULD extend existing protocols wherever 536 possible, developing a new protocol only where doing so adds a 537 significant set of capabilities. 539 GR#2 A solution SHOULD extend LDP capabilities to meet functional 540 requirements. This MUST be accomplished without defining LDP 541 Traffic Engineering (TE) methods as decided in [RFC3468]). 543 GR#3 Coexistence of LDP and RSVP-TE signaled LSPs MUST be supported 544 on an AMG. Function requirements SHOULD, where possible, be 545 accommodated in a manner that supports LDP signaled LSP, RSVP 546 signaled LSP, and LSP set up using management plane mechanisms. 548 GR#4 When the nodes connected via an AMG are in the same routing 549 domain, the solution MAY define extensions to the IGP. 551 GR#5 When the nodes are connected via an AMG are in different MPLS 552 network topologies, the solution SHALL NOT rely on extensions to 553 the IGP. 555 GR#6 The solution SHOULD support AMG IGP advertisement that results 556 in convergence time better than that of advertising the 557 individual component links. The solution SHALL be designed so 558 that it represents the range of capabilities of the individual 559 component links such that functional requirements are met, and 560 also minimizes the frequency of advertisement updates which may 561 cause IGP convergence to occur. 563 Examples of advertisement update triggering events to be 564 considered include: client LSP establishment/release, changes in 565 component link characteristics (e.g., latency, up/down state), 566 and/or bandwidth utilization. 568 GR#7 When a worst case failure scenario occurs, the number of RSVP- 569 TE client LSPs to be resignaled will cause a period of 570 unavailability as perceived by users. The resignaling time of 571 the solution MUST support protocol mechanisms meeting existing 572 provider Performance Objective for the duration of unavailability 573 without significantly relaxing those existing Performance 574 Objectives for the same network or for networks with similar 575 topology. For example, the processing load due to IGP 576 readvertisement MUST NOT increase significantly and the 577 resignaling time of the solution MUST NOT increase significantly 578 as compared with current methods. 580 5. Management Requirements 582 MR#1 Management Plane MUST support polling of the status and 583 configuration of an AMG and its individual component links and 584 support notification of status change. 586 MR#2 Management Plane MUST be able to activate or de-activate any 587 component link in an AMG in order to facilitate operation 588 maintenance tasks. The routers at each end of an AMG MUST 589 redistribute traffic to move traffic from a de-activated link to 590 other component links based on the traffic flow TE criteria. 592 MR#3 Management Plane MUST be able to configure a client LSP over an 593 AMG and be able to select a component link for the client LSP. 595 MR#4 Management Plane MUST be able to trace which component link a 596 client LSP is assigned to and monitor individual component link 597 and AMG performance. 599 MR#5 Management Plane MUST be able to verify connectivity over each 600 individual component link within an AMG. 602 MR#6 Component link fault notification MUST be sent to the 603 management plane. 605 MR#7 AMG fault notification MUST be sent to the management plane and 606 MUST be distributed via link state message in the IGP. 608 MR#8 Management Plane SHOULD provide the means for an operator to 609 initiate an optimization process. 611 MR#9 An operator initiated optimization MUST be performed in a 612 minimally disruptive manner as described in Section 3.5. 614 6. Acknowledgements 616 Frederic Jounay of France Telecom and Yuji Kamite of NTT 617 Communications Corporation co-authored a version of this document. 619 A rewrite of this document occurred after the IETF77 meeting. 620 Dimitri Papadimitriou, Lou Berger, Tony Li, the former WG chairs John 621 Scuder and Alex Zinin, the current WG chair Alia Atlas, and others 622 provided valuable guidance prior to and at the IETF77 RTGWG meeting. 624 Tony Li and John Drake have made numerous valuable comments on the 625 RTGWG mailing list that are reflected in versions following the 626 IETF77 meeting. 628 Iftekhar Hussain and Kireeti Kompella made comments on the RTGWG 629 mailing list after IETF82 that identified a new requirement. 630 Iftekhar Hussain made numerous valuable comments on the RTGWG mailing 631 list that resulted in improvements to document clarity. 633 In the interest of full disclosure of affiliation and in the interest 634 of acknowledging sponsorship, past affiliations of authors are noted. 635 Much of the work done by Ning So occurred while Ning was at Verizon. 636 Much of the work done by Curtis Villamizar occurred while at 637 Infinera. Much of the work done by Andy Malis occurred while Andy 638 was at Verizon. 640 Tom Yu and Francis Dupont provided the SecDir and GenArt reviews 641 respectively. Both reviews provided useful comments. The current 642 wording of the security section is based on suggested wording from 643 Tom Yu. Lou Berger provided the RtgDir review which resulted in the 644 document being renamed and substantial clarification of terminology 645 and document wording, particularly in the Abstract, Introduction, and 646 Definitions sections. 648 7. IANA Considerations 650 This memo includes no request to IANA. 652 8. Security Considerations 654 The security considerations for MPLS/GMPLS and for MPLS-TP are 655 documented in [RFC5920] and [RFC6941]. This document does not impact 656 the security of MPLS, GMPLS, or MPLS-TP. 658 The additional information that this document requires does not 659 provide significant additional value to an attacker beyond the 660 information already typically available from attacking a routing or 661 signaling protocol. If the requirements of this document are met by 662 extending an existing routing or signaling protocol, the security 663 considerations of the protocol being extended apply. If the 664 requirements of this document are met by specifying a new protocol, 665 the security considerations of that new protocol should include an 666 evaluation of what level of protection is required by the additional 667 information specified in this document, such as data origin 668 authentication. 670 9. References 672 9.1. Normative References 674 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 675 Requirement Levels", BCP 14, RFC 2119, March 1997. 677 9.2. Informative References 679 [I-D.ietf-rtgwg-cl-framework] 680 Ning, S., McDysan, D., Osborne, E., Yong, L., and C. 681 Villamizar, "Advanced Multipath Framework in MPLS", draft- 682 ietf-rtgwg-cl-framework-04 (work in progress), July 2013. 684 [I-D.ietf-rtgwg-cl-use-cases] 685 Ning, S., Malis, A., McDysan, D., Yong, L., and C. 686 Villamizar, "Advanced Multipath Use Cases and Design 687 Considerations", draft-ietf-rtgwg-cl-use-cases-05 (work in 688 progress), November 2013. 690 [IEEE-802.1AX] 691 IEEE Standards Association, "IEEE Std 802.1AX-2008 IEEE 692 Standard for Local and Metropolitan Area Networks - Link 693 Aggregation", 2006, . 696 [ITU-T.G.800] 697 ITU-T, "Unified functional architecture of transport 698 networks", 2007, . 701 [RFC3468] Andersson, L. and G. Swallow, "The Multiprotocol Label 702 Switching (MPLS) Working Group decision on MPLS signaling 703 protocols", RFC 3468, February 2003. 705 [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling 706 in MPLS Traffic Engineering (TE)", RFC 4201, October 2005. 708 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 709 Networks", RFC 5920, July 2010. 711 [RFC6941] Fang, L., Niven-Jenkins, B., Mansfield, S., and R. 712 Graveman, "MPLS Transport Profile (MPLS-TP) Security 713 Framework", RFC 6941, April 2013. 715 Authors' Addresses 717 Curtis Villamizar (editor) 718 OCCNC, LLC 720 Email: curtis@occnc.com 722 Dave McDysan (editor) 723 Verizon 724 22001 Loudoun County PKWY 725 Ashburn, VA 20147 726 USA 728 Email: dave.mcdysan@verizon.com 730 So Ning 731 Tata Communications 733 Email: ning.so@tatacommunications.com 735 Andrew Malis 736 Huawei Technologies 738 Email: agmalis@gmail.com 740 Lucy Yong 741 Huawei USA 742 5340 Legacy Dr. 743 Plano, TX 75025 744 USA 746 Phone: +1 469-277-5837 747 Email: lucy.yong@huawei.com