idnits 2.17.1 draft-ietf-rtgwg-cl-requirement-15.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 (January 25, 2014) is 3737 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-ietf-rtgwg-cl-framework-01 == Outdated reference: A later version (-06) exists of draft-ietf-rtgwg-cl-use-cases-01 Summary: 0 errors (**), 0 flaws (~~), 3 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: July 29, 2014 Verizon 6 S. Ning 7 Tata Communications 8 A. Malis 9 Consultant 10 L. Yong 11 Huawei USA 12 January 25, 2014 14 Requirements for Advanced Multipath in MPLS Networks 15 draft-ietf-rtgwg-cl-requirement-15 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 July 29, 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 microflow 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 that are as independent as possible of 108 protocol specifications in Section 3. 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 either transmits whole packets and 172 resequences the packets at the receiving end or subdivides 173 packets and reassembles the packets at the receiving end. 174 Inverse multiplexing requires that all packets be handled by a 175 common egress packet processing element and is therefore not 176 useful for very high bandwidth applications. 178 Component Link 179 The ITU-T definition of composite link in [ITU-T.G.800] and the 180 IETF definition of link bundling in [RFC4201] both refer to an 181 individual link in the composite link or link bundle as a 182 component link. The term component link is applicable to all 183 forms of multipath. The IEEE uses the term member rather than 184 component link in Ethernet Link Aggregation [IEEE-802.1AX]. 186 Client Layer 187 A client layer is the one immediately above a server layer. 189 Server Layer 190 A server layer is the latey immediately below a client layer. 192 Higher Layers 193 Relative to a particular layer, a client layer and any layer 194 above that is considered a higher layer. Upper layer is 195 synonymous with higher layer. 197 Lower Layers 198 Relative to a particular layer, a server layer and any layer 199 below that is considered a lower layer. 201 Client LSP 202 A client LSP is an LSP which has been set up over one or more 203 lower layers. In the context of this discussion, one type of 204 client LSP is a LSP which has been set up over an AMG. 206 Flow 207 A sequence of packets that should be transferred in order on one 208 component link of a multipath. 210 Flow identification 211 The label stack and other information that uniquely identifies a 212 flow. Other information in flow identification may include an IP 213 header, pseudowire (PW) control word, Ethernet MAC address, etc. 214 Note that a client LSP may contain one or more Flows or a client 215 LSP may be equivalent to a Flow. Flow identification is used to 216 locally select a component link, or a path through the network 217 toward the destination. 219 Load Balance 220 Load split, load balance, or load distribution refers to 221 subdividing traffic over a set of component links such that load 222 is fairly evenly distributed over the set of component links and 223 certain packet ordering requirements are met. Some existing 224 techniques better achieve these objectives than others. 226 Performance Objective 227 Numerical values for performance measures, principally 228 availability, latency, and delay variation. Performance 229 objectives may be related to Service Level Agreements (SLA) as 230 defined in RFC2475 or may be strictly internal. Performance 231 objectives may span links, edge-to-edge, or end-to-end. 232 Performance objectives may span one provider or may span multiple 233 providers. 235 A Component Link may be a point-to-point physical link (where a 236 "physical link" includes one or more link layer plus a physical 237 layer) or a logical link that preserves ordering in the steady state. 238 A component link may have transient out of order events, but such 239 events must not exceed the network's Performance Objectives. For 240 example, a component link may be comprised of any supportable 241 combination of link layers over a physical layer or over logical sub- 242 layers, including those providing physical layer emulation, or over 243 MPLS server layer LSP. 245 The ingress and egress of a multipath may be midpoint LSRs with 246 respect to a given client LSP. A midpoint LSR does not participate 247 in the signaling of any clients of the client LSP. Therefore, in 248 general, multipath endpoints cannot determine requirements of clients 249 of a client LSP through participation in the signaling of the clients 250 of the client LSP. 252 This document makes no statement on whether Advanced Multipath is 253 itself a layer or whether an instance of AMG is itself a layer. This 254 is to avoid engaging in long and pointless discussions about what 255 consistitutes a proper layer. 257 The term Advanced Multipath is intended to be used within the context 258 of this document and the related documents, 259 [I-D.ietf-rtgwg-cl-use-cases] and [I-D.ietf-rtgwg-cl-framework] and 260 any other related document. Other advanced multipath techniques may 261 in the future arise. If the capabilities defined in this document 262 become commonplace, they would no longer be considered "advanced". 263 Use of the term "advanced multipath" outside this document, if 264 referring to the term as defined here, should indicate Advanced 265 Multipath as defined by this document, citing the current document 266 name. If using another definition of "advanced multipath", documents 267 may optionally clarify that they are not using the term "advanced 268 multipath" as defined by this document if clarification is deemed 269 helpful. 271 3. Functional Requirements 273 The Functional Requirements in this section are grouped in 274 subsections starting with the highest priority. 276 3.1. Availability, Stability and Transient Response 278 Limiting the period of unavailability in response to failures or 279 transient events is extremely important as well as maintaining 280 stability. 282 FR#1 The transient period between some service disrupting event and 283 the convergence of the routing and/or signaling protocols MUST 284 occur within a time frame specified by Performance Objective 285 values. 287 FR#2 An AMG MAY be announced in conjunction with detailed parameters 288 about its component links, such as bandwidth and latency. The 289 AMG SHALL behave as a single IGP adjacency. 291 FR#3 The solution SHALL provide a means to summarize some routing 292 advertisements regarding the characteristics of an AMG such that 293 the updated protocol mechanisms maintain convergence times within 294 the timeframe needed to meet or not significantly exceed existing 295 Performance Objective for convergence on the same network or 296 convergence on a network with a similar topology. 298 FR#4 The solution SHALL ensure that restoration operations happen 299 within the timeframe needed to meet existing Performance 300 Objective for restoration time on the same network or restoration 301 time on a network with a similar topology. 303 FR#5 The solution shall provide a mechanism to select a set of paths 304 for an LSP across a network in such a way that flows within the 305 LSP are distributed across the set of paths while meeting all of 306 the other requirements stated above. The solution SHOULD work in 307 a manner similar to existing multipath techniques except as 308 necessary to accommodate Advanced Multipath requirements. 310 FR#6 If extensions to existing protocols are specified and/or new 311 protocols are defined, then the solution SHOULD provide a means 312 for a network operator to migrate an existing deployment in a 313 minimally disruptive manner. 315 FR#7 Any load balancing solutions MUST NOT oscillate. Some change 316 in path MAY occur. The solution MUST ensure that path stability 317 and traffic reordering continue to meet Performance Objective on 318 the same network or on a network with a similar topology. Since 319 oscillation may cause reordering, there MUST be means to control 320 the frequency of changing the component link over which a flow is 321 placed. 323 FR#8 Management and diagnostic protocols MUST be able to operate 324 over AMGs. 326 Existing scaling techniques used in MPLS networks apply to MPLS 327 networks which support Advanced Multipath. Scalability and stability 328 are covered in more detail in [I-D.ietf-rtgwg-cl-framework]. 330 3.2. Component Links Provided by Lower Layer Networks 332 A component link may be supported by a lower layer network. For 333 example, the lower layer may be a circuit switched network or another 334 MPLS network (e.g., MPLS-TP)). The lower layer network may change 335 the latency (and/or other performance parameters) seen by the client 336 layer. Currently, there is no protocol for the lower layer network 337 to inform the higher layer network of a change in a performance 338 parameter. Communication of the latency performance parameter is a 339 very important requirement. Communication of other performance 340 parameters (e.g., delay variation) is desirable. 342 FR#9 The solution SHALL specify a protocol means to allow a server 343 layer network to communicate latency to the client layer network. 345 FR#10 The precision of latency reporting SHOULD be configurable. A 346 reasonable default SHOULD be provided. Implementations SHOULD 347 support precision of at least 10% of the one way latencies for 348 latency of 1 msec or more. 350 The intent is to measure the predominant latency in uncongested 351 service provider networks, where geographic delay dominates and is on 352 the order of milliseconds or more. The argument for including 353 queuing delay is that it reflects the delay experienced by 354 applications. The argument against including queuing delay is that 355 if used in routing decisions it can result in routing instability. 356 This tradeoff is discussed in detail in 357 [I-D.ietf-rtgwg-cl-framework]. 359 3.3. Component Links with Different Characteristics 361 As one means to provide high availability, network operators deploy a 362 topology in the MPLS network using lower layer networks that have a 363 certain degree of diversity at the lower layer(s). Many techniques 364 have been developed to balance the distribution of flows across 365 component links that connect the same pair of nodes or ultimately 366 lead to a common destination. 368 FR#11 In requirements that follow in this document the word 369 "indicate" is used where information may be provided by either 370 the combination of link state IGP advertisement and MPLS LSP 371 signaling or via management plane protocols. In later documents 372 providing framework and protocol definitions both signaling and 373 management plane mechanisms MUST be defined. 375 FR#12 The solution SHALL provide a means for the client layer to 376 indicate a requirement that a client LSP will traverse a 377 component link with the minimum latency value. This will provide 378 a means by which minimum latency Performance Objectives of flows 379 within the client LSP can be supported. 381 FR#13 The solution SHALL provide a means for the client layer to 382 indicate a requirement that a client LSP will traverse a 383 component link with a maximum acceptable latency value as 384 specified by protocol. This will provide a means by which 385 bounded latency Performance Objectives of flows within the client 386 LSP can be supported. 388 FR#14 The solution SHALL provide a means for the client layer to 389 indicate a requirement that a client LSP will traverse a 390 component link with a maximum acceptable delay variation value as 391 specified by protocol. 393 The above set of requirements apply to component links with different 394 characteristics regardless as to whether those component links are 395 provided by parallel physical links between nodes or provided by sets 396 of paths across a network provided by server layer LSP. 398 Allowing multipath to contain component links with different 399 characteristics can improve the overall load balance and can be 400 accomplished while still accommodating the more strict requirements 401 of a subset of client LSP. 403 3.4. Considerations for Bidirectional Client LSP 405 Some client LSP MAY require a path bound to a specific set of 406 component links. This case is most likely to occur in bidirectional 407 client LSP where time synchronization protocols such as Precision 408 Time Protocol (PTP) or Network Time Protocol (NTP) are carried, or in 409 any other case where symmetric delay is highly desirable. There may 410 be other uses of this capability. 412 Other client LSP may only require that the LSP path serve the same 413 set of nodes in both directions. This is necessary if protocols are 414 carried which make use of the reverse direction of the LSP as a back 415 channel in cases such OAM protocols using IPv4 Time to Live (TTL) or 416 IPv4 Hop Limit to monitor or diagnose the underlying path. There may 417 be other uses of this capability. 419 FR#15 The solution SHALL provide a means for the client layer to 420 indicate a requirement that a client LSP be bound to a particular 421 component link within an AMG. If this option is not exercised, 422 then a client LSP that is carried over an AMG may be bound to any 423 component link or set of component links matching all other 424 signaled requirements, and different directions of a 425 bidirectional client LSP can be bound to different component 426 links. 428 FR#16 The solution MUST support a means for the client layer to 429 indicate a requirement that for a specific co-routed 430 bidirectional client LSP both directions of the co-routed 431 bidirectional client LSP MUST be bound to the same set of nodes. 433 FR#17 A client LSP which is bound to a specific component link SHOULD 434 NOT exceed the capacity of a single component link. This is 435 inherent in the assumption that a network SHOULD NOT operate in a 436 congested state if congestion is avoidable. 438 For some large bidirectional client LSP it may not be necessary (or 439 possible due to the client LSP capacity) to bind the LSP to a common 440 set of component links but may be necessary or desirable to constrain 441 the path taken by the LSP to the same set of nodes in both 442 directions. Without an entirely new and highly dynamic protocol, it 443 is not feasible to constrain such an bidirectional client LSP to take 444 multiple paths and coordinate load balance on each side to keep both 445 directions of flows within such an LSP on common paths. 447 3.5. Multipath Load Balancing Dynamics 449 Multipath load balancing attempts to keep traffic levels on all 450 component links below congestion levels if possible and preferably 451 well balanced. Load balancing is minimally disruptive (see 452 discussion below this section's list of requirements). The 453 sensitivity to these minimal disruptions of traffic flows within 454 specific client LSP needs to be considered. 456 FR#18 The solution SHALL provide a means for the client layer to 457 indicate a requirement that a specific client LSP MUST NOT be 458 split across multiple component links. 460 FR#19 The solution SHALL provide a means local to a node that 461 automatically distributes flows across the component links in the 462 AMG such that Performance Objectives are met as described in 463 prior requirements in Section 3.3. 465 FR#20 The solution SHALL measure traffic flows or groups of traffic 466 flows and dynamically select the component link on which to place 467 this traffic in order to balance the load so that no component 468 link in the AMG between a pair of nodes is overloaded. 470 FR#21 When a traffic flow is moved from one component link to another 471 in the same AMG between a set of nodes, it MUST be done so in a 472 minimally disruptive manner. 474 FR#22 Load balancing MAY be used during sustained low traffic periods 475 to reduce the number of active component links for the purpose of 476 power reduction. 478 FR#23 The solution SHALL provide a means for the client layer to 479 indicate a requirement that a specific client LSP contains 480 traffic whose frequency of component link change due to load 481 balancing needs to be bounded by a specific value. The solution 482 MUST provide a means to bound the frequency of component link 483 change due to load balancing for subsets of traffic flow on AMGs. 485 FR#24 The solution SHALL provide a means to distribute traffic flows 486 from a single client LSP across multiple component links to 487 handle at least the case where the traffic carried in an client 488 LSP exceeds that of any component link in the AMG. 490 FR#25 The solution SHOULD support the use case where an AMG itself is 491 a component link for a higher order AMG. For example, an AMG 492 comprised of MPLS-TP bi-directional tunnels viewed as logical 493 links could then be used as a component link in yet another AMG 494 that connects MPLS routers. 496 FR#26 If the total demand offered by traffic flows exceeds the 497 capacity of the AMG, the solution SHOULD define a means to cause 498 some client LSP to move to an alternate set of paths that are not 499 congested. These "preempted LSP" may not be restored if there is 500 no uncongested path in the network. 502 A minimally disruptive change implies that as little disruption as is 503 practical occurs. Such a change can be achieved with zero packet 504 loss. A delay discontinuity may occur, which is considered to be a 505 minimally disruptive event for most services if this type of event is 506 sufficiently rare. A delay discontinuity is an example of a 507 minimally disruptive behavior corresponding to current techniques. 509 A delay discontinuity is an isolated event which may greatly exceed 510 the normal delay variation (jitter). A delay discontinuity has the 511 following effect. When a flow is moved from a current link to a 512 target link with lower latency, reordering can occur. When a flow is 513 moved from a current link to a target link with a higher latency, a 514 time gap can occur. Some flows (e.g., timing distribution, PW 515 circuit emulation) are quite sensitive to these effects. A delay 516 discontinuity can also cause a jitter buffer underrun or overrun 517 affecting user experience in real time voice services (causing an 518 audible click). These sensitivities may be specified in a 519 Performance Objective. 521 As with any load balancing change, a change initiated for the purpose 522 of power reduction may be minimally disruptive. Typically the 523 disruption is limited to a change in delay characteristics and the 524 potential for a very brief period with traffic reordering. The 525 network operator when configuring a network for power reduction 526 should weigh the benefit of power reduction against the disadvantage 527 of a minimal disruption. 529 4. General Requirements for Protocol Solutions 531 This section defines requirements for protocol specification used to 532 meet the functional requirements specified in Section 3. 534 GR#1 The solution SHOULD extend existing protocols wherever 535 possible, developing a new protocol only where doing so adds a 536 significant set of capabilities. 538 GR#2 A solution SHOULD extend LDP capabilities to meet functional 539 requirements. This MUST be accomplished without defining LDP 540 Traffic Engineering (TE) methods as decided in [RFC3468]). 542 GR#3 Coexistence of LDP and RSVP-TE signaled LSPs MUST be supported 543 on an AMG. Function requirements SHOULD, where possible, be 544 accommodated in a manner that supports LDP signaled LSP, RSVP 545 signaled LSP, and LSP set up using management plane mechanisms. 547 GR#4 When the nodes connected via an AMG are in the same routing 548 domain, the solution MAY define extensions to the IGP. 550 GR#5 When the nodes are connected via an AMG are in different MPLS 551 network topologies, the solution SHALL NOT rely on extensions to 552 the IGP. 554 GR#6 The solution SHOULD support AMG IGP advertisement that results 555 in convergence time better than that of advertising the 556 individual component links. The solution SHALL be designed so 557 that it represents the range of capabilities of the individual 558 component links such that functional requirements are met, and 559 also minimizes the frequency of advertisement updates which may 560 cause IGP convergence to occur. 562 Examples of advertisement update triggering events to be 563 considered include: client LSP establishment/release, changes in 564 component link characteristics (e.g., latency, up/down state), 565 and/or bandwidth utilization. 567 GR#7 When a worst case failure scenario occurs, the number of RSVP- 568 TE client LSPs to be resignaled will cause a period of 569 unavailability as perceived by users. The resignaling time of 570 the solution MUST support protocol mechanisms meeting existing 571 provider Performance Objective for the duration of unavailability 572 without significantly relaxing those existing Performance 573 Objectives for the same network or for networks with similar 574 topology. For example, the processing load due to IGP 575 readvertisement MUST NOT increase significantly and the 576 resignaling time of the solution MUST NOT increase significantly 577 as compared with current methods. 579 5. Management Requirements 581 MR#1 Management Plane MUST support polling of the status and 582 configuration of an AMG and its individual component links and 583 support notification of status change. 585 MR#2 Management Plane MUST be able to activate or de-activate any 586 component link in an AMG in order to facilitate operation 587 maintenance tasks. The routers at each end of an AMG MUST 588 redistribute traffic to move traffic from a de-activated link to 589 other component links based on the traffic flow TE criteria. 591 MR#3 Management Plane MUST be able to configure a client LSP over an 592 AMG and be able to select a component link for the client LSP. 594 MR#4 Management Plane MUST be able to trace which component link a 595 client LSP is assigned to and monitor individual component link 596 and AMG performance. 598 MR#5 Management Plane MUST be able to verify connectivity over each 599 individual component link within an AMG. 601 MR#6 Component link fault notification MUST be sent to the 602 management plane. 604 MR#7 AMG fault notification MUST be sent to the management plane and 605 MUST be distributed via link state message in the IGP. 607 MR#8 Management Plane SHOULD provide the means for an operator to 608 initiate an optimization process. 610 MR#9 An operator initiated optimization MUST be performed in a 611 minimally disruptive manner as described in Section 3.5. 613 6. Acknowledgements 615 Frederic Jounay of France Telecom and Yuji Kamite of NTT 616 Communications Corporation co-authored a version of this document. 618 A rewrite of this document occurred after the IETF77 meeting. 619 Dimitri Papadimitriou, Lou Berger, Tony Li, the former WG chairs John 620 Scuder and Alex Zinin, the current WG chair Alia Atlas, and others 621 provided valuable guidance prior to and at the IETF77 RTGWG meeting. 623 Tony Li and John Drake have made numerous valuable comments on the 624 RTGWG mailing list that are reflected in versions following the 625 IETF77 meeting. 627 Iftekhar Hussain and Kireeti Kompella made comments on the RTGWG 628 mailing list after IETF82 that identified a new requirement. 629 Iftekhar Hussain made numerous valuable comments on the RTGWG mailing 630 list that resulted in improvements to document clarity. 632 In the interest of full disclosure of affiliation and in the interest 633 of acknowledging sponsorship, past affiliations of authors are noted. 634 Much of the work done by Ning So occurred while Ning was at Verizon. 635 Much of the work done by Curtis Villamizar occurred while at 636 Infinera. Much of the work done by Andy Malis occurred while Andy 637 was at Verizon. 639 Tom Yu and Francis Dupont provided the SecDir and GenArt reviews 640 respectively. Both reviews provided useful comments. The current 641 wording of the security section is based on suggested wording from 642 Tom Yu. Lou Berger provided the RtgDir review which resulted in the 643 document being renamed and substantial clarification of terminology 644 and document wording, particularly in the Abstract, Introduction, and 645 Definitions sections. 647 7. IANA Considerations 649 This memo includes no request to IANA. 651 8. Security Considerations 653 The security considerations for MPLS/GMPLS and for MPLS-TP are 654 documented in [RFC5920] and [RFC6941]. This document does not impact 655 the security of MPLS, GMPLS, or MPLS-TP. 657 The additional information that this document requires does not 658 provide significant additional value to an attacker beyond the 659 information already typically available from attacking a routing or 660 signaling protocol. If the requirements of this document are met by 661 extending an existing routing or signaling protocol, the security 662 considerations of the protocol being extended apply. If the 663 requirements of this document are met by specifying a new protocol, 664 the security considerations of that new protocol should include an 665 evaluation of what level of protection is required by the additional 666 information specified in this document, such as data origin 667 authentication. 669 9. References 671 9.1. Normative References 673 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 674 Requirement Levels", BCP 14, RFC 2119, March 1997. 676 9.2. Informative References 678 [I-D.ietf-rtgwg-cl-framework] 679 Ning, S., McDysan, D., Osborne, E., Yong, L., and C. 680 Villamizar, "Composite Link Framework in Multi Protocol 681 Label Switching (MPLS)", draft-ietf-rtgwg-cl-framework-01 682 (work in progress), August 2012. 684 [I-D.ietf-rtgwg-cl-use-cases] 685 Ning, S., Malis, A., McDysan, D., Yong, L., and C. 686 Villamizar, "Composite Link Use Cases and Design 687 Considerations", draft-ietf-rtgwg-cl-use-cases-01 (work in 688 progress), August 2012. 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 Consultant 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