idnits 2.17.1 draft-so-yong-mpls-ctg-requirement-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 16, 2009) is 5277 days in the past. Is this intentional? Checking references for intended status: Full Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 3209' is mentioned on line 551, but not defined == Missing Reference: 'RFC 2215' is mentioned on line 551, but not defined == Missing Reference: 'RFC 4124' is mentioned on line 563, but not defined == Missing Reference: 'RFC3031' is mentioned on line 644, but not defined == Missing Reference: 'RFC 3630' is mentioned on line 730, but not defined == Missing Reference: 'RFC 3468' is mentioned on line 744, but not defined == Unused Reference: 'RFC2119' is defined on line 820, but no explicit reference was found in the text == Unused Reference: 'RFC2215' is defined on line 823, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 827, but no explicit reference was found in the text == Unused Reference: 'RFC4090' is defined on line 835, but no explicit reference was found in the text == Unused Reference: 'RFC4124' is defined on line 838, but no explicit reference was found in the text == Unused Reference: 'RFC3468' is defined on line 859, but no explicit reference was found in the text == Unused Reference: 'RFC3630' is defined on line 865, but no explicit reference was found in the text ** Downref: Normative reference to an Proposed Standard RFC: RFC 2215 ** Downref: Normative reference to an Proposed Standard RFC: RFC 3209 ** Downref: Normative reference to an Proposed Standard RFC: RFC 4206 ** Downref: Normative reference to an Proposed Standard RFC: RFC 4090 ** Downref: Normative reference to an Proposed Standard RFC: RFC 4124 ** Downref: Normative reference to an Proposed Standard RFC: RFC 4201 Summary: 8 errors (**), 0 flaws (~~), 15 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Routing Working Group N. So 2 Internet Draft A. Malis 3 Intended Status: Standard D. McDysan 4 Expires: Verizon 5 L. Yong 6 Huawei 7 F. Jounay 8 France Telecom 9 Y. Kamite 10 NTT 11 October 16, 2009 13 Requirements for MPLS Over Composite Link 15 draft-so-yong-mpls-ctg-requirement-00 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. This document may not be modified, 24 and derivative works of it may not be created, and it may not be 25 published except as an Internet-Draft. 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. This document may not be modified, 29 and derivative works of it may not be created, except to publish it 30 as an RFC and to translate it into languages other than English. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html 48 This Internet-Draft will expire on December 17, 2009. 50 Copyright Notice 52 Copyright (c) 2009 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents in effect on the date of 57 publication of this document (http://trustee.ietf.org/license-info). 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. 61 Abstract 63 This document presents motivation, a problem statement and 64 operational requirements for a traffic distribution problem in 65 today's IP/MPLS network when multiple links are configured between 66 two routers. It defines a composite link as a group of parallel links 67 that can be considered as a single traffic engineering link or as an 68 IP link, and used for MPLS. The framework described in a companion 69 document is used to organize the requirements. 71 Table of Contents 73 1. Introduction........................................3 74 2. Conventions used in this document .......................4 75 2.1. Acronyms .......................................4 76 2.2. Terminology.....................................4 77 3. Motivation and Summary Problem Statement..................5 78 3.1. Motivation......................................5 79 3.2. Summary of Problems Requiring Solution ...............7 80 4. Requirements........................................7 81 4.1. Interior Functions ...............................8 82 4.1.1. Functions common to all LSP flows ...............8 83 4.1.1.1. Traffic Flow and Connection Mapping..........9 84 4.1.1.2. Management of Other Operational Aspects.......9 85 4.1.1.2.1. Resilience..........................9 86 4.1.1.2.2. Fault management requirement ...........9 87 4.1.1.2.3. Flow/Connection Mapping Change Frequency.10 88 4.1.2. Functions specific to LSP flows with TE information11 89 4.1.3. Functions specific to LSP flows without TE information12 90 4.1.4. Sets of LSP flows with and without TE information..12 91 4.1.4.1. Handling Bandwidth Shortage Events..........13 92 4.2. Exterior Functions ..............................13 93 4.2.1. Functions common to all LSP flows ..............13 94 4.2.1.1. Signaling Protocol Extensions..............13 95 4.2.1.2. Routing Advertisement Extensions...........13 96 4.2.2. Functions specific to LSP flows with TE information14 97 4.2.2.1. Signaling Protocol Extensions Requirements...14 98 4.2.2.2. Routing Advertisement Extensions...........15 99 4.2.3. Functions specific to LSP flows without TE information15 100 4.2.3.1. Signaling Protocol Extensions..............15 101 4.2.3.2. Routing Advertisement Extensions...........16 102 4.2.4. Functions specific to LSP flows with and without TE 103 information......................................16 104 4.2.4.1. Signaling Protocol Extensions..............16 105 4.2.4.2. Routing Advertisement Extensions...........16 107 5. Security Considerations ..............................16 108 6. IANA Considerations..................................16 109 7. References.........................................17 110 7.1. Normative References.............................17 111 7.2. Informative References...........................17 112 8. Acknowledgments.....................................18 114 1. Introduction 116 IP/MPLS network traffic growth forces carriers to deploy multiple 117 parallel physical/logical links between adjacent routers as the total 118 capacity of all aggregated traffic flows exceed the capacity of a 119 single link. The network is expected to carry aggregated traffic 120 flows some of which approach the capacity of any single link, and 121 also some flows that may be very small compared to the capacity of a 122 single link. 124 Operating an MPLS network with multiple parallel links between all 125 adjacent routers causes scaling problems in the routing protocols. 126 This issue is addressed in [RFC4201] which defines the notion of a 127 Link Bundle -- a set of identical parallel traffic engineered (TE) 128 links (called component links) that are grouped together and 129 advertised as a single TE link within the routing protocol. 131 The Link Bundle concept is somewhat limited because of the 132 requirement that all component links must have identical 133 capabilities, and because it applies only to TE links. This document 134 sets out a more generic set of requirements for grouping together a 135 set of parallel data links that may have different characteristics, 136 and for advertising and operating them as a single TE or non-TE link 137 called a Composite Link. 139 First, there is a set of requirements related to the interior 140 functioning of a router, of which the operational requirement is to 141 have consistent configuration, reporting and alarm notification. The 142 functions that impact the routers other than those connected by the 143 composite link are control plane routing and signaling protocols. A 144 further subdivision of the requirements is based upon characteristics 145 of the combination of MPLS signaling protocols in use, namely RSVP-TE 146 only, LDP only, or a combination of RSVP_TE and LDP. Extension 147 requirements to IGP-related protocols are also described in this 148 document. Furthermore, there are requirements that relate to use of 149 signaling (and possibly routing) that can be used within the same 150 layer or between layers. 152 Applicability of the work within this document is focused on MPLS 153 traffic as controlled through control plane protocols. Thus, this 154 document describes requirements related to the routing protocols that 155 advertise link parameters and the Resource Reservation Protocol 156 (RSVP-TE) and the Label Distribution Protocol (LDP) signaling 157 protocols that distribute MPLS labels and establish Label Switched 158 Paths (LSPs). Interactions between the control plane and the data and 159 management planes are also addressed. The focus of this document is 160 on MPLS traffic either signaled by RSVP-TE or LDP. IP traffic over 161 multiple parallel links is handled relatively well by ECMP or 162 LAG/hashing methods. The handling of IP control plane traffic is 163 within the scope of the requirements of this document. 165 A companion framework document [CLFRAMEWORK] further describes the 166 overall context, a structure, and some standardization considerations. 167 Specific protocol solutions are outside the scope of this document. 169 2. Conventions used in this document 171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 172 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 173 document are to be interpreted as described in RFC-2119. 175 2.1. Acronyms 177 BW: Bandwidth 179 ECMP: Equal Cost Multi-Path 181 FRR: Fast Re-Route 183 LAG: Link Aggregation Group 185 LDP: Label Distribution Protocol 187 LSP: Label Switched Path 189 MPLS: Multi-Protocol Label Switching 191 OAM: Operation, Administration, and Management 193 PDU: Protocol Data Unit 195 PE: Provider Edge device 197 RSVP: ReSource reserVation Protocol 199 RTD: Real Time Delay 201 TE: Traffic Engineering 203 VRF: Virtual Routing and Forwarding 205 2.2. Terminology 207 Composite Link: a group of component links, which can be considered 208 as a single MPLS TE link or as a single IP link used for MPLS. 210 Component Link: a physical link (e.g., Lambda, Ethernet PHY, SONET/ 211 SDH, OTN, etc.) with packet transport capability, or a logical link 212 (e.g., MPLS LSP, Ethernet VLAN, MPLS-TP LSP, etc.) 214 Connection: An aggregation of traffic flows which are treated 215 together as a single unit by the CTG Interior Function for the 216 purpose of routing onto a specific component link and measuring 217 traffic volume. 219 Exterior Functions: These are performed by an MPLS router that makes 220 a composite link useable by the network via control protocols, or by 221 an MPLS router that interacts with other routers to dynamically 222 control a component link as part a composite link. These functions 223 are those that interact via routing and/or signaling protocols with 224 other routers in the same layer network or other layer networks. 225 Interior Functions: Actions performed by the MPLS routers directly 226 connected by a composite link. This includes the determination of the 227 connection and component link on which a traffic flow is placed. 228 Although a local implementation matter, the configuration control of 229 certain aspects of these interior functions is an important 230 operational requirement. 232 Traffic Flow: A set of packets that with common identifier 233 characteristics that the composite link is able to use to aggregate 234 traffic into Connections. Identifiers can be an MPLS label stack or 235 any combination of IP addresses and protocol types for routing, 236 signaling and management packets. 238 Virtual Interface: Composite link characteristics advertised in IGP 240 3. Motivation and Summary Problem Statement 242 3.1. Motivation 244 There are several established approaches to using multiple parallel 245 links between a pair of routers. These have limitations as 246 summarized below. 248 o ECMP/Hashing/LAG: IP traffic composed of a large number of flows 249 with bandwidth that is small with respect to the individual link 250 capacity can be handled relatively well using ECMP/LAG approaches. 251 However, these approaches do not make use of MPLS control plane 252 information nor traffic volume information. Distribution 253 techniques applied only within the data plane can result in less 254 than ideal load balancing across component links of a composite 255 link. 257 o Advertisement of each component link into the IGP. Although this 258 would address the problem, it has a scaling impact on IGP routing, 259 and was an important motivation for the specification of link 260 bundling [RFC4201]. However, link bundling does not support a set 261 of component links with different characteristics (e.g., 262 bandwidth, latency) and only supports RSVP-TE. 264 o Inverse Multiplexing: Making multiple parallel links to appear as 265 a single link using inverse multiplexing techniques, such as 266 proposals under discussion in the [PWBONDING]. However, the 267 inverse multiplexed link will have a latency of the link with the 268 largest latency. When there is a mix of latency sensitive traffic 269 with other traffic that is less sensitive to latency, having all 270 traffic experience the latency of the worst link is not acceptable 271 to operators. 273 o Planning Tool LSP Assignment: Although theoretically optimal, an 274 external system that participates in the IGP, measures traffic and 275 assigns TE LSPs and/or adjusts IGP metrics has a potentially large 276 response time to certain failure scenarios. Furthermore, such a 277 system could make use of more information than provided by link 278 bundling IGP advertisements and could make use of mechanisms that 279 would allow pinning MPLS traffic to a particular component link in 280 a CTG. 282 o In a multi-layer network, the characteristics of a component link 283 can be altered by a lower layer network and this can create 284 significant operational impact in some cases. For example, if a 285 lower layer network performs restoration and markedly increases 286 the latency of a link in a link bundle, the traffic placed on this 287 longer latency link may generate user complaints and/or exceed the 288 parameters of a Service Level Agreement (SLA). 290 o In the case where multiple routing instances could share a 291 composite link, inefficiency can result if either 1) specific 292 component links are assigned to an individual routing instance, or 293 2) if statically assigned capacity is made to a logical/sub 294 interface in each component link of a composite link for each 295 routing instance. In other words, the issue is that unused 296 capacity in one routing instance cannot be used by another in 297 either of these cases. 299 o Unicast LDP signaled LSP flows follow the IGP determined topology 300 in a multipoint-to-point manner. The principal means of control of 301 LDP flows is through adjustment of the IGP metric. The simplicity 302 of this method is attractive. However, this means that the LDP 303 flow traffic level can change significantly in response to some 304 link and/or node failures, thus significantly change the traffic 305 level at points within a network. A means for operators to better 306 manage LDP signaled flows is therefore highly desirable. 308 3.2. Summary of Problems Requiring Solution 310 The following bullets highlight aspects of solutions for which 311 detailed requirements are stated in Section 5. 313 o Ensure the ability to transport both RSVP-TE and LDP signaled non- 314 TE LSPs on the same composite link (i.e., a single set of 315 component links) while maintaining acceptable service quality for 316 both RSVP-TE and LDP signaled LSPs. 318 o Extend a link bundling type function to scenarios with groups of 319 links having different characteristics (e.g., bandwidth, latency). 321 o When an end-to-end LSP signaled by RSVP-TE uses a composite link, 322 the composite link must select a component link that meets the 323 end-to-end requirements for the LSP. To perform this function, the 324 network elements at the end of a composite link must be made aware 325 of the required, desired, and acceptable link characteristics 326 (e.g., latency, optimization frequency) for each hop in the path. 327 The solution should be able to operate in a statically configured 328 or dynamically signaled manner. 330 o Support sets of component links between routers across 331 intermediate nodes at the same and/or lower layers where the 332 characteristics (e.g., latency) of said links may change 333 dynamically. The solution should support the case where the 334 changes in characteristics of these links are not communicated by 335 the IGP (e.g., a link in a lower layer network has a change in 336 latency or QoS due to a restoration action). The solution could 337 measure the performance (e.g., latency), and/or receive the 338 results of a measurement or computation from lower layer 339 configuration data via signaling. 341 4. Requirements 343 As defined in the terminology section a (traffic) flow is the 344 smallest unit of traffic assignable to a connection, and connections 345 are assigned to a component link that is part of a composite link. 346 The composite link has routing information, normal IGP that has no TE 347 information and IGP with TE extensions (IGP-TE) and signaling 348 information with TE information (RSVP-TE) and without TE information. 349 The following table summarizes the three cases covered in this 350 requirements section. 352 Flows IGP IGP-TE RSVP-TE LDP 354 ----------------------- --- ------ ------- --- 356 With TE Info Y Y Y N 358 Wihtout TE Info Y N N Y 360 With & Without TE Info Y Y Y Y 362 Furthermore, if a requirement would be repeated for each of the above 363 three cases (e.g., IGP related routing information) it is described 364 in a section common to all flows. 366 Therefore, the outline of this section is structured as follows: 368 o Management/Measurement of Interior Functions 370 - Functions common to all LSP flows 372 - Functions specific to LSP flows with TE information 374 - Functions specific to LSP flows without TE information 376 - Sets of LSP flows with and without TE information 378 o Exterior Functions 380 - Functions common to all LSP flows 382 - Functions specific to LSP flows with TE information 384 - Functions specific to LSP flows without TE information 386 - Sets of LSP flows with and without TE information 388 4.1. Interior Functions 390 4.1.1. Functions common to all LSP flows 392 The operator SHALL be able to configure a "virtual interface" 393 corresponding to a composite link that has at least all of the normal 394 IGP routing parameters . 396 The solution SHALL allow configuration of virtual interface IGP 397 parameters for a non-TE (i.e., normal IP routing) link used for MPLS 398 (e.g., administrative cost or weight). 400 o The solution SHALL support configuration of a composite link 401 composed of set of component links that may be logical or 402 physical. 404 The "virtual interface" SHALL appear as a fully-featured routing 405 adjacency not just as an FA [RFC4206]. In particular, it needs to 406 work with at least the following IP/MPLS control protocols: OSPF/IS- 407 IS, LDP, IGPOSPF-TE/ISIS-TE, and RSVP-TE. 409 The solution SHALL accept a new component link or remove an existing 410 component link by operator provisioning or in response to signaling 411 at a lower layer (e.g., using GMPLS). 413 The solution SHALL support derivation of the advertised interface 414 parameters from configured component link parameters based on 415 operator policy. 417 A composite link SHALL be configurable as a numbered or unnumbered 418 link (virtual interface in IP/MPLS). 420 A component link SHALL be configurable as a numbered link or 421 unnumbered link. A component link should be not advertised in IGP. 423 4.1.1.1. Traffic Flow and Connection Mapping 425 The solution SHALL support operator assignment of traffic flows to 426 specific connections. 428 The solution SHALL support operator assignment of connections to 429 specific component links. 431 The solution SHALL support IP packet transport across a composite 432 link for control plane (signaling, routing) and management plane 433 functions. 435 In order to prevent packet loss, the solution must employ make- 436 before-break when a change in the mapping of a connection to a 437 component link mapping change has to occur. 439 4.1.1.2. Management of Other Operational Aspects 441 4.1.1.2.1. Resilience 443 The component link recovery scheme SHALL perform equal to or better 444 than existing local recovery methods. A short service disruption may 445 occur during the recovery period. Fast ReRoute (FRR) SHALL be 446 configurable for a composite link. 448 As part of FRR, a method to recover from CTG node failure is 449 desirable. OAM Messaging Support 451 4.1.1.2.2. Fault management requirement 453 There are two aspects of fault management in the solution. One is 454 about composite link between two local adjacent routers. The other 455 is about the individual component link. 457 OAM protocols for fault management from the outside routers (e.g., 458 LSP-Ping/Trace, IP-ping/Trace) SHALL be transparently treated. 460 For example, it is expected that LSP-ping/trace message is able to 461 diagnose composite link status and its associated virtual interface 462 information; however, it is not required to directly treat individual 463 component link and CTG-connection because they are local matter of 464 two routers. 466 The solution SHALL support fault notification mechanism (e.g., 467 syslog, SNMP trap to the management system/operators) with the 468 granularity level of affected part as detailed below: 470 o Data-plane of component link level 472 o Data-plane of composite link level (as a whole, and as a sum of 473 associated component links) 475 o Control-plane of the virtual interface level (i.e., 476 routing/signaling on it) 478 o A composite link that believes that the underlying component link 479 server layers might not efficiently report failures, can run 480 Bidirectional Forwarding Detection (BFD) at the component link 481 layer. 483 Race conditions: The solution shall support configuration of timers 484 so that lower layer methods have time to detect/restore faults before 485 a composite link function would be invoked. 487 The solution SHALL allow operator or control plane to query the 488 component link to which an LSP is assigned. 490 4.1.1.2.3. Flow/Connection Mapping Change Frequency 492 The solution requires methods to dampen the frequency of flow to 493 connection mapping change, connection bandwidth change, and/or 494 connection to component link mapping changes (e.g., for re- 495 optimization). Operator imposed control policy regarding the 496 frequency of change for sets of flows SHALL be supported. 498 The solution SHALL support latency and delay variation sensitive 499 traffic and limit the mapping change for these flows, and place them 500 on component links that have lower latency. 502 The determination of latency sensitive traffic SHALL be determined by 503 any of the following methods: 505 o Use of a pre-defined local policy setting at composite link 506 ingress that can be mapped to a flow 508 o A manually configured setting at composite link ingress that can 509 be mapped to a flow 511 The determination of latency sensitive traffic SHOULD be determined 512 (if possible) by any of the following methods: 514 o Pre-set bits in the Payload (e.g., DSCP bits for IP or Ethernet 515 user priority for Ethernet payload) which are typically assigned 516 by end-user 518 o MPLS Traffic-Class Field (aka EXP) which is typically mapped by 519 the LER/LSR on the basis that its value is given for 520 differentiating latency-sensitive traffic of end-users 522 4.1.2. Functions specific to LSP flows with TE information 524 The following requirements apply to the case of RSVP-TE signaled LSPs 525 where the virtual interface is configured with IGP TE extensions. 527 The solution SHALL allow configuration of virtual interface 528 parameters for TE extensions link (e.g., available bandwidth, maximum 529 bandwidth, maximum allowable LSP bandwidth, TE metric, and resource 530 classes (i.e., administrative groups) or link colors). 532 The solution SHALL support configuration of a composite link composed 533 of set of component links , with each component link potentially 534 having at least the following characteristics which may differ: 536 o Bandwidth 538 o Latency 540 o QoS characteristics (e.g., jitter, error rate) 542 The solution SHALL support the admission control by RSVP-TE that is 543 signaled from the routers outside the composite link. Note that RSVP- 544 TE signaling need not specify the actual component link to be used? 545 because the selection of component link is the local matter of two 546 adjacent routers based upon signaled and locally configured 547 information. 549 The solution shall be able to receive, interpret and act upon at 550 least the following RSVP-TE signaled parameters: bandwidth setup 551 priority, and holding priority [RFC 3209, RFC 2215] preemption 552 priority and traffic class [RFC 4124], and apply them to the CTG 553 connections where the LSP is mapped. 555 The solution shall support configuration of at least the following 556 parameters on a per composite link basis: 558 o Local Bandwidth Oversubscription factor 559 The determination of latency sensitive traffic SHALL be determined by 560 any of the following methods: 562 o MPLS traffic class in a RSVP-TE signaling message (i.e., Diffserv- 563 TE traffic class [RFC 4124]) 565 4.1.3. Functions specific to LSP flows without TE information 567 The following requirements apply to the case of LDP signaled LSPs 568 when no signaled TE information is available. 570 The solution shall map LDP-assigned labeled packets based upon local 571 configuration (e.g., label stack depth) to define a connection that 572 is mapped to one of the component link. 574 The solution SHALL map LDP-assigned labeled packets that identify the 575 outer label's FEC. 577 The solution SHALL support entropy labels [Entropy Label] to map more 578 granular flows to connections. 580 The solution SHALL be able to measure the bandwidth actually used by 581 a particular connection and derive proper local traffic TE 582 information for the connection. 584 When the connection bandwidth exceeds the component link capacity, 585 the solution SHALL be able to reassign the traffic flows to several 586 connections. 588 The solution SHALL support management plane controlled parameters 589 that define at least a minimum bandwidth, maximum bandwidth, 590 preemption priority, and holding priority for each connection without 591 TE information (i.e., LDP signaled LSP that does not contain the same 592 information as an RSVP-TE signaled LSP). 594 4.1.4. Sets of LSP flows with and without TE information 596 The solution shall support separation of resources for traffic flows 597 mapped to connections that have access to TE information (e.g., RSVP- 598 TE signaled flows) from those that do not have access to TE 599 information (e.g., LDP-signaled flows or RSVP-TE LSP with Zero 600 bandwidth). 602 Component links in a composite link may fail independently. The 603 failure of a component link may impact some connections. The 604 impacted connections shall be transferred to other active component 605 links using the same rules as for the original assignment of 606 connections to component links. In the event that all connections 607 cannot be recovered, configured priority and preemption parameters 608 SHOULD be employed. 610 4.1.4.1. Handling Bandwidth Shortage Events 612 The following requirements apply to a virtual interface that supports 613 traffic flows both with and without TE information, in response to a 614 bandwidth shortage event. A "bandwidth shortage" can arise in a 615 composite link if the total bandwidth of the connections with 616 provisioned/signaled TE information and those signaled without TE 617 information (but with measured bandwidth) exceeds the bandwidth of 618 the composite link that carries connections. 620 The solution shall support a policy-based preemption capability such 621 that, in the event of such a "bandwidth shortage", the signaled or 622 configured preemption and holding parameters can be applied to the 623 following treatments to the connections: 625 o For a connection that has RSVP-TE LSPs, signal the router that the 626 LSP has been preempted. The solution shall support soft 627 preemption (i.e., notify the preempted LSP source prior to 628 preemption). [Soft Preemption] 630 o For a connection that has LDP(s), where the routers connected via 631 the composite link is aware of the LDP signaling involved to the 632 preempted label stack depth, signal release of the label to the 633 router 635 o For a connection that has non-re-routable RSVP-TE LSPs or non- 636 releasable LDP labels, signal the router or operator that the LSP 637 or LDP label has been lost. 639 4.2. Exterior Functions 641 4.2.1. Functions common to all LSP flows 643 The solution MUST be able to interoperate with exiting IETF MPLS 644 [RFC3031] control and data planes where appropriate. 646 4.2.1.1. Signaling Protocol Extensions 648 The solution SHALL support signaling a composite link between two 649 routers (e.g., P, P/PE, or PE). 651 The solution SHALL support signaling a component link as part of a 652 composite link. 654 The solution SHALL support signaling a composite link and 655 automatically injecting it into the IGP [LSP Hieararchy bis] or 656 connected two routers. 658 4.2.1.2. Routing Advertisement Extensions 660 The solution SHALL support IGP extensions to identify that the 661 advertised routing adjacency as a composite link. 663 4.2.1.3. Multi-Layer Networking Aspects 665 The solution MUST be able to interoperate with existing IETF 666 GMPLS/MPLS-TP control and data planes where appropriate, for example, 667 when signaling a component link. 669 The solution SHALL support derivation of the advertised interface 670 parameters from signaled component link parameters from a lower layer 671 (e.g., latency, capacity) based on operator policy. 673 The solution SHALL be able to accept the GMPLS/MPLS-TP control plane 674 signaled component link. It SHALL be able to support the following 675 component link parameters 677 o Maximum (estimated or measured) acceptable latency 679 o Actual(estimated or measured) assigned latency 681 o Bandwidth 683 o Delay Variation 685 It SHOULD support the following component link parameter 687 o Loss rate 689 4.2.2. Functions specific to LSP flows with TE information 691 4.2.2.1. Signaling Protocol Extensions Requirements 693 The solution SHALL support per LSP signaling of at least the 694 following additional parameters for an LSP 696 o Maximum (estimated or measured) acceptable latency 698 o Actual (estimated or measured) accumulated latency based upon the 699 actual component link assigned by the composite link 701 o Bandwidth of the highest and lowest speed 703 The solution SHOULD support per LSP signaling of at least the 704 following additional parameters: 706 o Delay Variation 708 o Loss rate 710 As part of determining the path of an LSP, the client may query a 711 Patch Computation Element (PCE) and use the response in determining 712 the (complete or partial) source route sent in the TE signaling 713 message. 715 Note that an LSP can be a component link or a client LSP. Since 716 component links may involve GMPLS, separate signaling protocol 717 extensions may be needed for particular switching capabilities. 719 4.2.2.2. Routing Advertisement Extensions 721 It SHALL be possible for the solution to represent multiple values, 722 or a range of values, for the composite link interface parameters in 723 order to communicate information about differences in the constituent 724 component links in an exterior function route advertisement 726 Some of these capabilities are specified for link bundling [RFC 727 4201], but some extensions may be needed. Techniques such as those 728 described in [RFC 2676] for encoding latency and using it in routing 729 should be considered. LSA encoding techniques such as those described 730 in [RFC 3630] should also be considered. 732 For example, a range of latencies, a range of capacities and/or other 733 characteristics for the component links that comprise the composite 734 links could be advertised. When a range of characteristics is 735 advertised, these can be used in a constrained path computation, that 736 is, certain composite links can be excluded since no component link 737 meets the characteristic as part of the overall path. 739 4.2.3. Functions specific to LSP flows without TE information 741 A straightforward set of requirement would result if the same 742 functions specified for RSVP-TE were also specified for LDP. However, 743 the IETF MPLS Working Group's decision on MPLS signaling protocols 744 [RFC 3468] to not pursue such an approach by not adding functions to 745 CR-LDP means that a different approach must be taken. 747 As described in the Interior Function section, 4.1.3, a basic 748 composite link capability when there is no TE information is to be 749 able to measure the amount of LDP signaled traffic that is sent on an 750 LSP. It is highly desirable to be able to signal and advertise 751 certain aspects of these measurements, if they cannot be explicitly 752 signaled via extensions to LDP. 754 4.2.3.1. Signaling Protocol Extensions 756 The solution SHOULD allow addition of an object to an LDP label 757 mapping message that indicates how much measured capacity can be sent 758 to a pair of nodes connected via a composite link. This signaling 759 should be conveyed at least to nodes which are adjacent to the pair 760 of nodes connected via a composite link. 762 Nodes SHOULD be able to use this information in conjunction with the 763 IGP link information to decide which label mappings it will use for 764 forwarding LDP signaled flows toward a pair of nodes connected via a 765 composite link. 767 4.2.3.2. Routing Advertisement Extensions 769 Signaling via LDP the available capacity on a composite link for 770 flows without TE information is one method. A preferable method would 771 be to extend the IGP to indicate the amount of capacity allocated by 772 an Interior function to flows without TE information so that nodes in 773 the network using LDP can make better informed decisions about which 774 label mapping messages are used to form an LDP LSP. 776 4.2.4. Functions specific to LSP flows with and without TE information 778 As described in the Interior Function section, 4.1.4, the principal 779 driver in this case is how to handle bandwidth shortage events when 780 both RSVP-TE and LDP signaled LSPs are present in the composite link. 781 The requirements relevant to the nodes connected by the composite 782 link are described in section 4.1.4, and this section describes 783 additional desirable functions beyond these nodes. Since RSVP-TE 784 signaling defines parameters and procedures for preemption, the focus 785 is on extensions to better support LDP signaled LSPs. 787 4.2.4.1. Signaling Protocol Extensions 789 The solution SHOULD allow addition of an object to an LDP label 790 mapping message that indicates that a node controlling the composite 791 link wants to preempt the traffic offered by an LSP. This should have 792 the effect of pruning label distribution for the LSP at the node pair 793 connected via a composite link. 795 4.2.4.2. Routing Advertisement Extensions 797 The solution SHOULD allow addition of an object to the IGP that 798 indicates that all LDP signaled traffic should avoid the advertised 799 composite link. 801 5. Security Considerations 803 The solution is a local function on the router to support traffic 804 engineering management over multiple parallel links. It does not 805 introduce a security risk for control plane and data plane. 807 The solution could change the frequency of routing update messages 808 and therefore could change routing convergence time. The solution 809 MUST provide controls to dampen the frequency of such changes so as 810 to not destabilize routing protocols. 812 6. IANA Considerations 814 IANA actions to provide solutions are for further study. 816 7. References 818 7.1. Normative References 820 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 821 Requirement Levels", BCP 14, RFC 2119, March 1997. 823 [RFC2215] S. Shenker, J. Wroclawski, "General Characterization 824 Parameters for Integrated Service Network Elements." 825 September 1997 827 [RFC3209] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. 828 Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels," December 829 2001 831 [RFC4206] Label Switched Paths (LSP) Hierarchy with Generalized 832 Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE) K. 833 Kompella, Y. Rekhter October 2005 835 [RFC4090] Pan, P., "Fast Reroute Extensions to RSVP-TE for LSP 836 Tunnels", RFC 4090, May 2005. 838 [RFC4124] Protocol Extensions for Support of Diffserv-aware MPLS 839 Traffic Engineering F. Le Faucheur, Ed. June 2005 841 [RFC4201] Kompella, K., "Link Bundle in MPLS Traffic Engineering", 842 RFC 4201, March 2005. 844 7.2. Informative References 846 [Entropy Label] Kompella, K. and S. Amante, "The Use of Entropy 847 Labels in MPLS Forwarding", November 2008, Work in Progress 849 [LSP Hierarchy] Shiomoto, K. and A. Farrel, "Procedures for 850 Dynamically Signaled Hierarchical Label Switched 851 Paths", November 2008, Work in Progress 853 [Soft Preemption] Meyer, M. and J. Vasseur, "MPLS Traffic Engineering 854 Soft Preemption", February 2009, Work in Progress 856 [CLFRAMEWORK] Yong, L. Ed, "Framework for MPLS Over Composite Link," 857 work in progress. 859 [RFC3468] L. Andersson, G. Swallow, "The Multiprotocol Label 860 Switching (MPLS) Working Group decision on MPLS signaling 861 protocols." 863 [PWBONDING] Stein, Y, "PW Bonding", Dec. 2008 865 [RFC3630] Katz, D., "Traffic Engineering (TE) Extension to OSPF 866 Version 2", RFC 3630, September 2003. 868 [RFC 2676] G. Apostolopoulos, S. Kama, D. Williams, R. Guerin, A. 869 Orda, T. Przygienda, "QoS Routing Mechanisms and OSPF Extensions," 870 August, 1999 872 8. Acknowledgments 874 Authors would like to thank Adrian Farrel from Olddog for his 875 extensive comments and suggestions, Ron Bonica from Juniper, Nabil 876 Bitar from Verizon, Eric Gray from Ericsson, Lou Berger from LabN, 877 and Kireeti Kompella from Juniper, for their reviews and great 878 suggestions. 880 This document was prepared using 2-Word-v2.0.template.dot. 882 Copyright (c) 2009 IETF Trust and the persons identified as authors 883 of the code. All rights reserved. 885 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 886 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 887 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 888 A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 889 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 890 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 891 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 892 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 893 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 894 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 895 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 897 This code was derived from IETF RFC [insert RFC number]. Please 898 reproduce this note if possible. 900 Authors' Addresses 902 So Ning 903 Verizon 904 2400 N. Glem Ave., 905 Richerdson, TX 75082 906 Phone: +1 972-729-7905 907 Email: ning.so@verizonbusiness.com 909 Andrew Malis 910 Verizon 911 117 West St. 912 Waltham, MA 02451 913 Phone: +1 781-466-2362 914 Email: andrew.g.malis@verizon.com 916 Dave McDysan 917 Verizon 918 22001 Loudoun County PKWY 919 Ashburn, VA 20147 920 Email: dave.mcdysan@verizon.com 922 Lucy Yong 923 Huawei USA 924 1700 Alma Dr. Suite 500 925 Plano, TX 75075 926 Phone: +1 469-229-5387 927 Email: lucyyong@huawei.com 929 Frederic Jounay 930 France Telecom 931 2, avenue Pierre-Marzin 932 22307 Lannion Cedex, 933 FRANCE 934 Email: frederic.jounay@orange-ftgroup.com 936 Yuji Kamite 937 NTT Communications Corporation 938 Granpark Tower 939 3-4-1 Shibaura, Minato-ku 940 Tokyo 108-8118 941 Japan 942 Email: y.kamite@ntt.com