idnits 2.17.1 draft-ietf-rtgwg-cl-requirement-11.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 (July 11, 2013) is 3935 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: January 12, 2014 Verizon 6 S. Ning 7 Tata Communications 8 A. Malis 9 Verizon 10 L. Yong 11 Huawei USA 12 July 11, 2013 14 Requirements for Advanced Multipath in MPLS Networks 15 draft-ietf-rtgwg-cl-requirement-11 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 January 12, 2014. 43 Copyright Notice 45 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . 7 66 3.3. Parallel Component Links with Different Characteristics . 8 67 4. Derived Requirements . . . . . . . . . . . . . . . . . . . . . 11 68 5. Management Requirements . . . . . . . . . . . . . . . . . . . 12 69 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 73 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 74 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 77 1. Introduction 79 There is often a need to provide large aggregates of bandwidth that 80 are best provided using parallel links between routers or carrying 81 traffic over multiple MPLS LSP. In core networks there is often no 82 alternative since the aggregate capacities of core networks today far 83 exceed the capacity of a single physical link or single packet 84 processing element. 86 The presence of parallel links, with each link potentially comprised 87 of multiple layers has resulted in additional requirements. Certain 88 services may benefit from being restricted to a subset of the 89 component links or a specific component link, where component link 90 characteristics, such as latency, differ. Certain services require 91 that an LSP be treated as atomic and avoid reordering. Other 92 services will continue to require only that reordering not occur 93 within a microflow as is current practice. 95 The purpose of this document is to clearly enumerate a set of 96 requirements related to the protocols and mechanisms that provide 97 MPLS based Advanced Multipath. The intent is to first provide a set 98 of functional requirements that are as independent as possible of 99 protocol specifications (Section 3). For certain functional 100 requirements this document describes a set of derived protocol 101 requirements (Section 4) and management requirements (Section 5). 103 1.1. Requirements Language 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in RFC 2119 [RFC2119]. 109 Any statement which requires the solution to support some new 110 functionality through use of [RFC2119] keywords, SHOULD be 111 interpretted as follows. The implementation either MUST or SHOULD 112 support the new functionality depending on the use of either MUST or 113 SHOULD in the requirements statement. The implementation SHOULD in 114 most or all cases allow any new functionality to be individually 115 enabled or disabled through configuration. A service provider or 116 other deployment MAY choose to enable or disable any feature in their 117 network, subject to implementation limitations on sets of features 118 which can be disabled. 120 2. Definitions 121 Multipath 122 The term multipath includes all techniques in which 124 1. Traffic can take more than one path from one node to a 125 destination. 127 2. Individual packets take one path only. Packets are not 128 subdivided and reassembled at the receiving end. 130 3. Packets are not resequenced at the receiving end. 132 4. The paths may be: 134 a. parallel links between two nodes, or 136 b. may be specific paths across a network to a destination 137 node, or 139 c. may be links or paths to an intermediate node used to 140 reach a common destination. 142 The paths need not have equal capacity. The paths may or may not 143 have equal cost in a routing protocol. 145 Advanced Multipath 146 Advanced Multipath meets the requirements defined in this 147 document. A key capability of advanced multipath is the support 148 of non-homogeneous component links. 150 Composite Link 151 The term Composite Link had been a registered trademark of Avici 152 Systems, but was abandoned in 2007. The term composite link is 153 now defined by the ITU in [ITU-T.G.800]. The ITU definition 154 includes multipath as defined here, plus inverse multiplexing 155 which is explicitly excluded from the definition of multipath. 157 Inverse Multiplexing 158 Inverse multiplexing either transmits whole packets and 159 resequences the packets at the receiving end or subdivides 160 packets and reassembles the packets at the receiving end. 161 Inverse multiplexing requires that all packets be handled by a 162 common egress packet processing element and is therefore not 163 useful for very high bandwidth applications. 165 Component Link 166 The ITU definition of composite link in [ITU-T.G.800] and the 167 IETF definition of link bundling in [RFC4201] both refer to an 168 individual link in the composite link or link bundle as a 169 component link. The term component link is applicable to all 170 forms of multipath. The IEEE uses the term member rather than 171 component link in Ethernet Link Aggregation [IEEE-802.1AX]. 173 Client LSP 174 A client LSP is an LSP which has been set up over a server layer. 175 In the context of this discussion, a client LSP is a LSP which 176 has been set up over a multipath as opposed to an LSP 177 representing the multipath itself or any LSP supporting a 178 component links of that multipath. 180 Flow 181 A sequence of packets that should be transferred in order on one 182 component link of a multipath. 184 Flow identification 185 The label stack and other information that uniquely identifies a 186 flow. Other information in flow identification may include an IP 187 header, pseudowire (PW) control word, Ethernet MAC address, etc. 188 Note that a client LSP may contain one or more Flows or a client 189 LSP may be equivalent to a Flow. Flow identification is used to 190 locally select a component link, or a path through the network 191 toward the destination. 193 Load Balance 194 Load split, load balance, or load distribution refers to 195 subdividing traffic over a set of component links such that load 196 is fairly evenly distributed over the set of component links and 197 certain packet ordering requirements are met. Some existing 198 techniques better acheive these objectives than others. 200 Performance Objective 201 Numerical values for performance measures, principally 202 availability, latency, and delay variation. Performance 203 objectives may be related to Service Level Agreements (SLA) as 204 defined in RFC2475 or may be strictly internal. Performance 205 objectives may span links, edge-to-edge, or end-to-end. 206 Performance objectives may span one provider or may span multiple 207 providers. 209 A Component Link may be a point-to-point physical link (where a 210 "physical link" includes one or more link layer plus a physical 211 layer) or a logical link that preserves ordering in the steady state. 212 A component link may have transient out of order events, but such 213 events must not exceed the network's Performance Objectives. For 214 example, a compoent link may be comprised of any supportable 215 combination of link layers over a physical layer or over logical sub- 216 layers, including those providing physical layer emulation. 218 The ingress and egress of a multipath may be midpoint LSRs with 219 respect to a given client LSP. A midpoint LSR does not participate 220 in the signaling of any clients of the client LSP. Therefore, in 221 general, multipath endpoints cannot determine requirements of clients 222 of a client LSP through participation in the signaling of the clients 223 of the client LSP. 225 The term Advanced Multipath is intended to be used within the context 226 of this document and the related documents, 227 [I-D.ietf-rtgwg-cl-use-cases] and [I-D.ietf-rtgwg-cl-framework] and 228 any other related document. Other advanced multipath techniques may 229 in the future arise. If the capabilities defined in this document 230 become commonplace, they would no longer be considered "advanced". 231 Use of the term "advanced multipath" outside this document, if 232 refering to the term as defined here, should indicate Advanced 233 Multipath as defined by this document, citing the current document 234 name. If using another definition of "advanced multipath", documents 235 may optionally clarify that they are not using the term "advanced 236 multipath" as defined by this document if clarification is deemed 237 helpful. 239 3. Functional Requirements 241 The Functional Requirements in this section are grouped in 242 subsections starting with the highest priority. 244 3.1. Availability, Stability and Transient Response 246 Limiting the period of unavailability in response to failures or 247 transient events is extremely important as well as maintaining 248 stability. The transient period between some service disrupting 249 event and the convergence of the routing and/or signaling protocols 250 MUST occur within a time frame specified by Performance Objective 251 values. 253 FR#1 An advanced multipath MAY be announced in conjunction with 254 detailed parameters about its component links, such as 255 bandwidth and latency. The advanced multipath SHALL behave as 256 a single IGP adjacency. 258 FR#2 The solution SHALL provide a means to summarize some routing 259 advertisements regarding the characteristics of an advanced 260 multipath such that the updated protocol mechanisms maintain 261 convergence times within the timeframe needed to meet or no 262 significantly exceed existing Performance Objective for 263 convergence on the same network or convergence on a network 264 with a similar topology. 266 FR#3 The solution SHALL ensure that restoration operations happen 267 within the timeframe needed to meet existing Performance 268 Objective for restoration time on the same network or 269 restoration time on a network with a similar topology. 271 FR#4 The solution SHALL provide a mechanism to select a path for a 272 flow across a network that contains a number of paths comprised 273 of pairs of nodes connected by advanced multipath in such a way 274 as to automatically distribute the load over the network nodes 275 connected by advanced multipaths while meeting all of the other 276 mandatory requirements stated above. The solution SHOULD work 277 in a manner similar to that of current networks without any 278 advanced multipath protocol enhancements when the 279 characteristics of the individual component links are 280 advertised. 282 FR#5 If extensions to existing protocols are specified and/or new 283 protocols are defined, then the solution SHOULD provide a means 284 for a network operator to migrate an existing deployment in a 285 minimally disruptive manner. 287 FR#6 Any load balancing solutions MUST NOT oscillate. Some change 288 in path MAY occur. The solution MUST ensure that path 289 stability and traffic reordering continue to meet Performance 290 Objective on the same network or on a network with a similar 291 topology. Since oscillation may cause reordering, there MUST 292 be means to control the frequency of changing the component 293 link over which a flow is placed. 295 FR#7 Management and diagnostic protocols MUST be able to operate 296 over advanced multipaths. 298 Existing scaling techniques used in MPLS networks apply to MPLS 299 networks which support Advanced Multipaths. Scalability and 300 stability are covered in more detail in 301 [I-D.ietf-rtgwg-cl-framework]. 303 3.2. Component Links Provided by Lower Layer Networks 305 A component link may be supported by a lower layer network. For 306 example, the lower layer may be a circuit switched network or another 307 MPLS network (e.g., MPLS-TP)). The lower layer network may change 308 the latency (and/or other performance parameters) seen by the client 309 layer. Currently, there is no protocol for the lower layer network 310 to inform the higher layer network of a change in a performance 311 parameter. Communication of the latency performance parameter is a 312 very important requirement. Communication of other performance 313 parameters (e.g., delay variation) is desirable. 315 FR#8 The solution SHALL specify a protocol means to allow a lower 316 layer server network to communicate latency to the higher 317 layer client network. 319 FR#9 The precision of latency reporting SHOULD be configurable. A 320 reasonable default SHOULD be provided. Implementations SHOULD 321 support precision of at least 10% of the one way latencies for 322 latency of 1 ms or more. 324 FR#10 The solution SHALL provide a means to limit the latency to 325 meet a Performance Objective target on a per flow basis or 326 group of flow basis, where flows or groups of flows are 327 identifiable in the forwarding plane and are signaled using in 328 the control plane or set up using the management plane. 330 The Performance Objectives differ across the services, and 331 some services have different Performance Objectives for 332 different QoS classes, for example, one QoS class may have a 333 much larger latency bound than another. Overload can occur 334 which would violate a Performance Objective parameter (e.g., 335 loss) and some remedy to handle this case for an advanced 336 multipath is required. 338 FR#11 If the total demand offered by traffic flows exceeds the 339 capacity of the advanced multipath, the solution SHOULD define 340 a means to cause some traffic flows or groups of flows to move 341 to some other point in the network that is not congested. 342 These "preempted flows" may not be restored if there is no 343 uncongested path in the network. 345 The intent is to measure the predominant latency in uncongested 346 service provider networks, where geographic delay dominates and is on 347 the order of milliseconds or more. The argument for including 348 queuing delay is that it reflects the delay experienced by 349 applications. The argument against including queuing delay is that 350 it if used in routing decisions it can result in routing instability. 351 This tradeoff is discussed in detail in 352 [I-D.ietf-rtgwg-cl-framework]. 354 3.3. Parallel Component Links with Different Characteristics 356 As one means to provide high availability, network operators deploy a 357 topology in the MPLS network using lower layer networks that have a 358 certain degree of diversity at the lower layer(s). Many techniques 359 have been developed to balance the distribution of flows across 360 component links that connect the same pair of nodes. When the path 361 for a flow can be chosen from a set of candidate nodes connected via 362 advanced multipaths, other techniques have been developed. Refer to 363 the Appendices in [I-D.ietf-rtgwg-cl-use-cases] for a description of 364 existing techniques and a set of references. 366 FR#12 The solution SHALL measure traffic flows or groups of traffic 367 flows and dynamically select the component link on which to 368 place this traffic in order to balance the load so that no 369 component link in the advanced multipath between a pair of 370 nodes is overloaded. 372 FR#13 When a traffic flow is moved from one component link to 373 another in the same advanced multipath between a set of nodes 374 (or sites), it MUST be done so in a minimally disruptive 375 manner. 377 FR#14 Load balancing MAY be used during sustained low traffic 378 periods to reduce the number of active component links for the 379 purpose of power reduction. 381 FR#15 The solution SHALL provide a means to identify flows whose 382 rearrangement frequency needs to be bounded by a configured 383 value and MUST provide a means to bound the rearrangement 384 frequency for these flows. 386 FR#16 The solution SHALL provide a means that communicates whether 387 the flows within an client LSP can be split across multiple 388 component links. The solution SHOULD provide a means to 389 indicate the flow identification field(s) which can be used 390 along the flow path which can be used to perform this 391 function. 393 FR#17 The solution SHALL provide a means to indicate that a traffic 394 flow will traverse a component link with the minimum latency 395 value. 397 FR#18 The solution SHALL provide a means to indicate that a traffic 398 flow will traverse a component link with a maximum acceptable 399 latency value as specified by protocol. 401 FR#19 The solution SHALL provide a means to indicate that a traffic 402 flow will traverse a component link with a maximum acceptable 403 delay variation value as specified by protocol. 405 FR#20 The solution SHALL provide a means local to a node that 406 automatically distributes flows across the component links in 407 the advanced multipath such that Performance Objectives are 408 met as described in prior requirements. 410 FR#21 The solution SHALL provide a means to distribute flows from a 411 single client LSP across multiple component links to handle at 412 least the case where the traffic carried in an client LSP 413 exceeds that of any component link in the advanced multipath. 414 As defined in Section 2, a flow is a sequence of packets that 415 should be transferred on one component link and should be 416 transferred in order. 418 FR#22 The solution SHOULD support the use case where an advanced 419 multipath itself is a component link for a higher order 420 advanced multipath. For example, an advanced multipath 421 comprised of MPLS-TP bi-directional tunnels viewed as logical 422 links could then be used as a component link in yet another 423 advanced multipath that connects MPLS routers. 425 FR#23 The solution MUST support an optional means for client LSP 426 signaling to bind a client LSP to a particular component link 427 within an advanced multipath. If this option is not 428 exercised, then a client LSP that is bound to an advanced 429 multipath may be bound to any component link matching all 430 other signaled requirements, and different directions of a 431 bidirectional client LSP can be bound to different component 432 links. 434 FR#24 The solution MUST support a means to indicate that both 435 directions of co-routed bidirectional client LSP MUST be bound 436 to the same component link. 438 A minimally disruptive change implies that as little disruption as is 439 practical occurs. Such a change can be achieved with zero packet 440 loss. A delay discontinuity may occur, which is considered to be a 441 minimally disruptive event for most services if this type of event is 442 sufficiently rare. A delay discontinuity is an example of a 443 minimally disruptive behavior corresponding to current techniques. 445 A delay discontinuity is an isolated event which may greatly exceed 446 the normal delay variation (jitter). A delay discontinuity has the 447 following effect. When a flow is moved from a current link to a 448 target link with lower latency, reordering can occur. When a flow is 449 moved from a current link to a target link with a higher latency, a 450 time gap can occur. Some flows (e.g., timing distribution, PW 451 circuit emulation) are quite sensitive to these effects. A delay 452 discontinuity can also cause a jitter buffer underrun or overrun 453 affecting user experience in real time voice services (causing an 454 audible click). These sensitivities may be specified in a 455 Performance Objective. 457 As with any load balancing change, a change initiated for the purpose 458 of power reduction may be minimally disruptive. Typically the 459 disruption is limited to a change in delay characteristics and the 460 potential for a very brief period with traffic reordering. The 461 network operator when configuring a network for power reduction 462 should weigh the benefit of power reduction against the disadvantage 463 of a minimal disruption. 465 4. Derived Requirements 467 This section takes the next step and derives high-level requirements 468 on protocol specification from the functional requirements. 470 DR#1 The solution SHOULD attempt to extend existing protocols 471 wherever possible, developing a new protocol only if this adds 472 a significant set of capabilities. 474 DR#2 A solution SHOULD extend LDP capabilities to meet functional 475 requirements (without using TE methods as decided in 476 [RFC3468]). 478 DR#3 Coexistence of LDP and RSVP-TE signaled LSPs MUST be supported 479 on an advanced multipath. Other functional requirements should 480 be supported as independently of signaling protocol as 481 possible. 483 DR#4 When the nodes connected via an advanced multipath are in the 484 same MPLS network topology, the solution MAY define extensions 485 to the IGP. 487 DR#5 When the nodes are connected via an advanced multipath are in 488 different MPLS network topologies, the solution SHALL NOT rely 489 on extensions to the IGP. 491 DR#6 The solution SHOULD support advanced multipath IGP 492 advertisement that results in convergence time better than that 493 of advertising the individual component links. The solution 494 SHALL be designed so that it represents the range of 495 capabilities of the individual component links such that 496 functional requirements are met, and also minimizes the 497 frequency of advertisement updates which may cause IGP 498 convergence to occur. 500 Examples of advertisement update triggering events to be 501 considered include: client LSP establishment/release, changes 502 in component link characteristics (e.g., latency, up/down 503 state), and/or bandwidth utilization. 505 DR#7 When a worst case failure scenario occurs, the number of 506 RSVP-TE client LSPs to be resignaled will cause a period of 507 unavailability as perceived by users. The resignaling time of 508 the solution MUST support protocol mechanisms meeting existing 509 provider Performance Objective for the duration of 510 unavailability without significantly relaxing those existing 511 Performance Objectives for the same network or for networks 512 with similar topology. For example, the processing load due to 513 IGP readvertisement MUST NOT increase significantly and the 514 resignaling time of the solution MUST NOT increase 515 significantly as compared with current methods. 517 5. Management Requirements 519 MR#1 Management Plane MUST support polling of the status and 520 configuration of an advanced multipath and its individual 521 advanced multipath and support notification of status change. 523 MR#2 Management Plane MUST be able to activate or de-activate any 524 component link in an advanced multipath in order to facilitate 525 operation maintenance tasks. The routers at each end of an 526 advanced multipath MUST redistribute traffic to move traffic 527 from a de-activated link to other component links based on the 528 traffic flow TE criteria. 530 MR#3 Management Plane MUST be able to configure a client LSP over an 531 advanced multipath and be able to select a component link for 532 the client LSP. 534 MR#4 Management Plane MUST be able to trace which component link a 535 client LSP is assigned to and monitor individual component link 536 and advanced multipath performance. 538 MR#5 Management Plane MUST be able to verify connectivity over each 539 individual component link within an advanced multipath. 541 MR#6 Component link fault notification MUST be sent to the 542 management plane. 544 MR#7 Advanced multipath fault notification MUST be sent to the 545 management plane and MUST be distributed via link state message 546 in the IGP. 548 MR#8 Management Plane SHOULD provide the means for an operator to 549 initiate an optimization process. 551 MR#9 An operator initiated optimization MUST be performed in a 552 minimally disruptive manner as described in Section 3.3. 554 6. Acknowledgements 556 Frederic Jounay of France Telecom and Yuji Kamite of NTT 557 Communications Corporation co-authored a version of this document. 559 A rewrite of this document occurred after the IETF77 meeting. 560 Dimitri Papadimitriou, Lou Berger, Tony Li, the former WG chairs John 561 Scuder and Alex Zinin, the current WG chair Alia Atlas, and others 562 provided valuable guidance prior to and at the IETF77 RTGWG meeting. 564 Tony Li and John Drake have made numerous valuable comments on the 565 RTGWG mailing list that are reflected in versions following the 566 IETF77 meeting. 568 Iftekhar Hussain and Kireeti Kompella made comments on the RTGWG 569 mailing list after IETF82 that identified a new requirement. 570 Iftekhar Hussain made numerous valuable comments on the RTGWG mailing 571 list that resulted in improvements to document clarity. 573 In the interest of full disclosure of affiliation and in the interest 574 of acknowledging sponsorship, past affiliations of authors are noted. 575 Much of the work done by Ning So occurred while Ning was at Verizon. 576 Much of the work done by Curtis Villamizar occurred while at 577 Infinera. Infinera continues to sponsor this work on a consulting 578 basis. 580 Tom Yu and Francis Dupont provided the SecDir and GenArt reviews 581 respectively. Both reviews provided useful comments. Lou Berger 582 provided the RtgDir review which resulted in substantial 583 clarification of terminology and document wording, particularly in 584 the Abstract, Introduction, and Definitions sections. 586 7. IANA Considerations 588 This memo includes no request to IANA. 590 8. Security Considerations 592 The security considerations for MPLS/GMPLS and for MPLS-TP are 593 documented in [RFC5920] and [RFC6941]. This document does not impact 594 the security of MPLS, GMPLS, or MPLS-TP. 596 The additional information that this document requires does not 597 provide significant additional value to an attacker beyond the 598 information already typically available from attacking a routing or 599 signaling protocol. If the requirements of this document are met by 600 extending an existing routing or signaling protocol, the security 601 considerations of the protocol being extended apply. If the 602 requirements of this document are met by specifying a new protocol, 603 the security considerations of that new protocol should include an 604 evaluation of what level of protection is required by the additional 605 information specified in this document, such as data origin 606 authentication. 608 9. References 610 9.1. Normative References 612 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 613 Requirement Levels", BCP 14, RFC 2119, March 1997. 615 9.2. Informative References 617 [I-D.ietf-rtgwg-cl-framework] 618 Ning, S., McDysan, D., Osborne, E., Yong, L., and C. 619 Villamizar, "Composite Link Framework in Multi Protocol 620 Label Switching (MPLS)", draft-ietf-rtgwg-cl-framework-01 621 (work in progress), August 2012. 623 [I-D.ietf-rtgwg-cl-use-cases] 624 Ning, S., Malis, A., McDysan, D., Yong, L., and C. 625 Villamizar, "Composite Link Use Cases and Design 626 Considerations", draft-ietf-rtgwg-cl-use-cases-01 (work in 627 progress), August 2012. 629 [IEEE-802.1AX] 630 IEEE Standards Association, "IEEE Std 802.1AX-2008 IEEE 631 Standard for Local and Metropolitan Area Networks - Link 632 Aggregation", 2006, . 635 [ITU-T.G.800] 636 ITU-T, "Unified functional architecture of transport 637 networks", 2007, . 640 [RFC3468] Andersson, L. and G. Swallow, "The Multiprotocol Label 641 Switching (MPLS) Working Group decision on MPLS signaling 642 protocols", RFC 3468, February 2003. 644 [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling 645 in MPLS Traffic Engineering (TE)", RFC 4201, October 2005. 647 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 648 Networks", RFC 5920, July 2010. 650 [RFC6941] Fang, L., Niven-Jenkins, B., Mansfield, S., and R. 651 Graveman, "MPLS Transport Profile (MPLS-TP) Security 652 Framework", RFC 6941, April 2013. 654 Authors' Addresses 656 Curtis Villamizar (editor) 657 OCCNC, LLC 659 Email: curtis@occnc.com 661 Dave McDysan (editor) 662 Verizon 663 22001 Loudoun County PKWY 664 Ashburn, VA 20147 665 USA 667 Email: dave.mcdysan@verizon.com 669 So Ning 670 Tata Communications 672 Email: ning.so@tatacommunications.com 674 Andrew Malis 675 Verizon 676 60 Sylvan Road 677 Waltham, MA 02451 678 USA 680 Phone: +1 781-466-2362 681 Email: andrew.g.malis@verizon.com 682 Lucy Yong 683 Huawei USA 684 5340 Legacy Dr. 685 Plano, TX 75025 686 USA 688 Phone: +1 469-277-5837 689 Email: lucy.yong@huawei.com