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