idnits 2.17.1 draft-ietf-rtgwg-cl-requirement-05.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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: FR#5 Any automatic LSP routing and/or load balancing solutions MUST not oscillate such that performance observed by users changes such that an NPO is violated. Since oscillation may cause reordering, there MUST be means to control the frequency of changing the component link over which a flow is placed. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: DR#7 When a worst case failure scenario occurs, the number of RSVP-TE LSPs to be resignaled will cause a period of unavailability as perceived by users. The resignaling time of the solution MUST meet the NPO objective for the duration of unavailability. The resignaling time of the solution MUST not increase significantly as compared with current methods. -- The document date (January 30, 2012) is 4468 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I-D.ietf-pwe3-fat-pw' is mentioned on line 520, but not defined == Missing Reference: 'RFC1717' is mentioned on line 526, but not defined ** Obsolete undefined reference: RFC 1717 (Obsoleted by RFC 1990) == Missing Reference: 'RFC2475' is mentioned on line 529, but not defined == Missing Reference: 'RFC2615' is mentioned on line 533, but not defined == Missing Reference: 'RFC2991' is mentioned on line 536, but not defined == Missing Reference: 'RFC2992' is mentioned on line 539, but not defined == Missing Reference: 'RFC3260' is mentioned on line 542, but not defined == Missing Reference: 'RFC4201' is mentioned on line 545, but not defined == Missing Reference: 'RFC4301' is mentioned on line 548, but not defined == Missing Reference: 'RFC4385' is mentioned on line 551, but not defined == Missing Reference: 'RFC4928' is mentioned on line 555, but not defined == Unused Reference: 'RFC2702' is defined on line 472, but no explicit reference was found in the text == Unused Reference: 'RFC3809' is defined on line 483, but no explicit reference was found in the text == Unused Reference: 'RFC4665' is defined on line 497, but no explicit reference was found in the text == Unused Reference: 'RFC5254' is defined on line 514, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-ietf-l2vpn-vpms-frmwk-requirements-03 Summary: 1 error (**), 0 flaws (~~), 19 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTGWG C. Villamizar, Ed. 3 Internet-Draft OCCNC, LLC 4 Intended status: Informational D. McDysan, Ed. 5 Expires: August 2, 2012 S. Ning 6 A. Malis 7 Verizon 8 L. Yong 9 Huawei USA 10 January 30, 2012 12 Requirements for MPLS Over a Composite Link 13 draft-ietf-rtgwg-cl-requirement-05 15 Abstract 17 There is often a need to provide large aggregates of bandwidth that 18 are best provided using parallel links between routers or MPLS LSR. 19 In core networks there is often no alternative since the aggregate 20 capacities of core networks today far exceed the capacity of a single 21 physical link or single packet processing element. 23 The presence of parallel links, with each link potentially comprised 24 of multiple layers has resulted in additional requirements. Certain 25 services may benefit from being restricted to a subset of the 26 component links or a specific component link, where component link 27 characteristics, such as latency, differ. Certain services require 28 that an LSP be treated as atomic and avoid reordering. Other 29 services will continue to require only that reordering not occur 30 within a microflow as is current practice. 32 Current practice related to multipath is described briefly in an 33 appendix. 35 Status of this Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on August 2, 2012. 51 Copyright Notice 53 Copyright (c) 2012 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 70 2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 4. Network Operator Functional Requirements . . . . . . . . . . . 5 73 4.1. Availability, Stability and Transient Response . . . . . . 5 74 4.2. Component Links Provided by Lower Layer Networks . . . . . 6 75 4.3. Parallel Component Links with Different Characteristics . 7 76 5. Derived Requirements . . . . . . . . . . . . . . . . . . . . . 9 77 6. Management Requirements . . . . . . . . . . . . . . . . . . . 10 78 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 79 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 80 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 81 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 82 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 83 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 84 10.3. Appendix References . . . . . . . . . . . . . . . . . . . 13 85 Appendix A. Existing Network Operator Practices and Protocol 86 Usage . . . . . . . . . . . . . . . . . . . . . . . . 14 87 Appendix B. Existing Multipath Standards and Techniques . . . . . 14 88 Appendix C. ITU-T G.800 Composite Link Definitions and 89 Terminology . . . . . . . . . . . . . . . . . . . . . 14 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 92 1. Introduction 94 The purpose of this document is to describe why network operators 95 require certain functions in order to solve certain business problems 96 (Section 2). The intent is to first describe why things need to be 97 done in terms of functional requirements that are as independent as 98 possible of protocol specifications (Section 4). For certain 99 functional requirements this document describes a set of derived 100 protocol requirements (Section 5). Three appendices provide 101 supporting details as a summary of existing/prior operator approaches 102 (Appendix A), a summary of implementation techniques and relevant 103 protocol standards (Appendix B), and a summary of G.800 terminology 104 used to define a composite link (Appendix C). 106 1.1. Requirements Language 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in RFC 2119 [RFC2119]. 112 2. Assumptions 114 The services supported include L3VPN RFC 4364 [RFC4364], RFC 4797 115 [RFC4797]L2VPN RFC 4664 [RFC4664] (VPWS, VPLS (RFC 4761 [RFC4761], 116 RFC 4762 [RFC4762]) and VPMS VPMS Framework 117 [I-D.ietf-l2vpn-vpms-frmwk-requirements]), Internet traffic 118 encapsulated by at least one MPLS label, and dynamically signaled 119 MPLS or MPLS-TP LSPs and pseudowires. The MPLS LSPs supporting these 120 services may be pt-pt, pt-mpt, or mpt-mpt. 122 The locations in a network where these requirements apply are a Label 123 Edge Router (LER) or a Label Switch Router (LSR) as defined in RFC 124 3031 [RFC3031]. 126 The IP DSCP cannot be used for flow identification since L3VPN 127 requires Diffserv transparency (see RFC 4031 5.5.2 [RFC4031]), and in 128 general network operators do not rely on the DSCP of Internet 129 packets. 131 3. Definitions 133 ITU-T G.800 Based Composite and Component Link Definitions: 134 Section 6.9.2 of ITU-T-G.800 [ITU-T.G.800] defines composite and 135 component links as summarized in Appendix C. The following 136 definitions for composite and component links are derived from 137 and intended to be consistent with the cited ITU-T G.800 138 terminology. 140 Composite Link: A composite link is a logical link composed of a 141 set of parallel point-to-point component links, where all 142 links in the set share the same endpoints. A composite link 143 may itself be a component of another composite link, but only 144 a strict hierarchy of links is allowed. 146 Component Link: A point-to-point physical or logical link that 147 preserves ordering in the steady state. A component link may 148 have transient out of order events, but such events must not 149 exceed the network's specific NPO. Examples of a physical 150 link are: Lambda, Ethernet PHY, and OTN. Examples of a 151 logical link are: MPLS LSP, Ethernet VLAN, and MPLS-TP LSP. 153 Flow: A sequence of packets that must be transferred in order on one 154 component link. 156 Flow identification: The label stack and other information that 157 uniquely identifies a flow. Other information in flow 158 identification may include an IP header, PW control word, 159 Ethernet MAC address, etc. Note that an LSP may contain one or 160 more Flows or an LSP may be equivalent to a Flow. Flow 161 identification is used to locally select a component link, or a 162 path through the network toward the destination. 164 Network Performance Objective (NPO): Numerical values for 165 performance measures, principally availability, latency, and 166 delay variation. See Appendix A for more details. 168 4. Network Operator Functional Requirements 170 The Functional Requirements in this section are grouped in 171 subsections starting with the highest priority. 173 4.1. Availability, Stability and Transient Response 175 Limiting the period of unavailability in response to failures or 176 transient events is extremely important as well as maintaining 177 stability. The transient period between some service disrupting 178 event and the convergence of the routing and/or signaling protocols 179 MUST occur within a time frame specified by NPO values. Appendix A 180 provides references and a summary of service types requiring a range 181 of restoration times. 183 FR#1 The solution SHALL provide a means to summarize some routing 184 advertisements regarding the characteristics of a composite 185 link such that the routing protocol converges within the 186 timeframe needed to meet the network performance objective. A 187 composite link CAN be announced in conjunction with detailed 188 parameters about its component links, such as bandwidth and 189 latency. The composite link SHALL behave as a single IGP 190 adjacency. 192 FR#2 The solution SHALL ensure that all possible restoration 193 operations happen within the timeframe needed to meet the NPO. 194 The solution may need to specify a means for aggregating 195 signaling to meet this requirement. 197 FR#3 The solution SHALL provide a mechanism to select a path for a 198 flow across a network that contains a number of paths comprised 199 of pairs of nodes connected by composite links in such a way as 200 to automatically distribute the load over the network nodes 201 connected by composite links while meeting all of the other 202 mandatory requirements stated above. The solution SHOULD work 203 in a manner similar to that of current networks without any 204 composite link protocol enhancements when the characteristics 205 of the individual component links are advertised. 207 FR#4 If extensions to existing protocols are specified and/or new 208 protocols are defined, then the solution SHOULD provide a means 209 for a network operator to migrate an existing deployment in a 210 minimally disruptive manner. 212 FR#5 Any automatic LSP routing and/or load balancing solutions MUST 213 not oscillate such that performance observed by users changes 214 such that an NPO is violated. Since oscillation may cause 215 reordering, there MUST be means to control the frequency of 216 changing the component link over which a flow is placed. 218 FR#6 Management and diagnostic protocols MUST be able to operate 219 over composite links. 221 4.2. Component Links Provided by Lower Layer Networks 223 Case 3 as defined in [ITU-T.G.800] involves a component link 224 supporting an MPLS layer network over another lower layer network 225 (e.g., circuit switched or another MPLS network (e.g., MPLS-TP)). 226 The lower layer network may change the latency (and/or other 227 performance parameters) seen by the MPLS layer network. Network 228 Operators have NPOs of which some components are based on performance 229 parameters. Currently, there is no protocol for the lower layer 230 network to inform the higher layer network of a change in a 231 performance parameter. Communication of the latency performance 232 parameter is a very important requirement. Communication of other 233 performance parameters (e.g., delay variation) is desirable. 235 FR#7 In order to support network NPOs and provide acceptable user 236 experience, the solution SHALL specify a protocol means to 237 allow a lower layer server network to communicate latency to 238 the higher layer client network. 240 FR#8 The precision of latency reporting SHOULD be at least 10% of 241 the one way latencies for latency of 1 ms or more. 243 FR#9 The solution SHALL provide a means to limit the latency on a 244 per LSP basis between nodes within a network to meet an NPO 245 target when the path between these nodes contains one or more 246 pairs of nodes connected via a composite link. 248 The NPOs differ across the services, and some services have 249 different NPOs for different QoS classes, for example, one QoS 250 class may have a much larger latency bound than another. 251 Overload can occur which would violate an NPO parameter (e.g., 252 loss) and some remedy to handle this case for a composite link 253 is required. 255 FR#10 If the total demand offered by traffic flows exceeds the 256 capacity of the composite link, the solution SHOULD define a 257 means to cause the LSPs for some traffic flows to move to some 258 other point in the network that is not congested. These 259 "preempted LSPs" may not be restored if there is no 260 uncongested path in the network. 262 4.3. Parallel Component Links with Different Characteristics 264 Corresponding to Case 1 of [ITU-T.G.800], as one means to provide 265 high availability, network operators deploy a topology in the MPLS 266 network using lower layer networks that have a certain degree of 267 diversity at the lower layer(s). Many techniques have been developed 268 to balance the distribution of flows across component links that 269 connect the same pair of nodes. When the path for a flow can be 270 chosen from a set of candidate nodes connected via composite links, 271 other techniques have been developed. 273 FR#11 The solution SHALL measure traffic on a labeled traffic flow 274 and dynamically select the component link on which to place 275 this flow in order to balance the load so that no component 276 link in the composite link between a pair of nodes is 277 overloaded. 279 FR#12 When a traffic flow is moved from one component link to 280 another in the same composite link between a set of nodes (or 281 sites), it MUST be done so in a minimally disruptive manner. 283 When a flow is moved from a current link to a target link with 284 different latency, reordering can occur if the target link 285 latency is less than that of the current or clumping can occur 286 if target link latency is greater than that of the current. 287 Therefore, some flows (e.g., timing distribution, PW circuit 288 emulation) are quite sensitive to these effects, which may be 289 specified in an NPO or are needed to meet a user experience 290 objective (e.g. jitter buffer under/overrun). 292 FR#13 The solution SHALL provide a means to identify flows whose 293 rearrangement frequency needs to be bounded by a configured 294 value. 296 FR#14 The solution SHALL provide a means that communicates whether 297 the flows within an LSP can be split across multiple component 298 links. The solution SHOULD provide a means to indicate the 299 flow identification field(s) which can be used along the flow 300 path which can be used to perform this function. 302 FR#15 The solution SHALL provide a means to indicate that a traffic 303 flow shall select a component link with the minimum latency 304 value. 306 FR#16 The solution SHALL provide a means to indicate that a traffic 307 flow shall select a component link with a maximum acceptable 308 latency value as specified by protocol. 310 FR#17 The solution SHALL provide a means to indicate that a traffic 311 flow shall select a component link with a maximum acceptable 312 delay variation value as specified by protocol. 314 FR#18 The solution SHALL provide a means local to a node that 315 automatically distributes flows across the component links in 316 the composite link such that NPOs are met. 318 FR#19 The solution SHALL provide a means to distribute flows from a 319 single LSP across multiple component links to handle at least 320 the case where the traffic carried in an LSP exceeds that of 321 any component link in the composite link. As defined in 322 section 3, a flow is a sequence of packets that must be 323 transferred on one component link. 325 FR#20 The solution SHOULD support the use case where a composite 326 link itself is a component link for a higher order composite 327 link. For example, a composite link comprised of MPLS-TP bi- 328 directional tunnels viewed as logical links could then be used 329 as a component link in yet another composite link that 330 connects MPLS routers. 332 FR#21 The solution MUST support an optional means for LSP signaling 333 to bind an LSP to a particular component link within a 334 composite link. If this option is not exercised, then an LSP 335 that is bound to a composite link may be bound to any 336 component link matching all other signaled requirements, and 337 different directions of a bidirectional LSP can be bound to 338 different component links. 340 FR#22 The solution MUST support a means to indicate that both 341 directions of co-routed bidirectional LSP MUST be bound to the 342 same component link. 344 5. Derived Requirements 346 This section takes the next step and derives high-level requirements 347 on protocol specification from the functional requirements. 349 DR#1 The solution SHOULD attempt to extend existing protocols 350 wherever possible, developing a new protocol only if this adds 351 a significant set of capabilities. 353 DR#2 A solution SHOULD extend LDP capabilities to meet functional 354 requirements (without using TE methods as decided in 355 [RFC3468]). 357 DR#3 Coexistence of LDP and RSVP-TE signaled LSPs MUST be supported 358 on a composite link. Other functional requirements should be 359 supported as independently of signaling protocol as possible. 361 DR#4 When the nodes connected via a composite link are in the same 362 MPLS network topology, the solution MAY define extensions to 363 the IGP. 365 DR#5 When the nodes are connected via a composite link are in 366 different MPLS network topologies, the solution SHALL NOT rely 367 on extensions to the IGP. 369 DR#6 The Solution SHOULD support composite link IGP advertisement 370 that results in convergence time better than that of 371 advertising the individual component links. The solution SHALL 372 be designed so that it represents the range of capabilities of 373 the individual component links such that functional 374 requirements are met, and also minimizes the frequency of 375 advertisement updates which may cause IGP convergence to occur. 377 Examples of advertisement update triggering events to be 378 considered include: LSP establishment/release, changes in 379 component link characteristics (e.g., latency, up/down state), 380 and/or bandwidth utilization. 382 DR#7 When a worst case failure scenario occurs, the number of 383 RSVP-TE LSPs to be resignaled will cause a period of 384 unavailability as perceived by users. The resignaling time of 385 the solution MUST meet the NPO objective for the duration of 386 unavailability. The resignaling time of the solution MUST not 387 increase significantly as compared with current methods. 389 6. Management Requirements 391 MR#1 Management Plane MUST support polling of the status and 392 configuration of a composite link and its individual composite 393 link and support notification of status change. 395 MR#2 Management Plane MUST be able to activate or de-activate any 396 component link in a composite link in order to facilitate 397 operation maintenance tasks. The routers at each end of a 398 composite link MUST redistribute traffic to move traffic from a 399 de-activated link to other component links based on the traffic 400 flow TE criteria. 402 MR#3 Management Plane MUST be able to configure a LSP over a 403 composite link and be able to select a component link for the 404 LSP. 406 MR#4 Management Plane MUST be able to trace which component link a 407 LSP is assigned to and monitor individual component link and 408 composite link performance. 410 MR#5 Management Plane MUST be able to verify connectivity over each 411 individual component link within a composite link. 413 MR#6 Management Plane SHOULD provide the means for an operator to 414 initiate an optimization process. 416 7. Acknowledgements 418 Frederic Jounay of France Telecom and Yuji Kamite of NTT 419 Communications Corporation co-authored a version of this document. 421 A rewrite of this document occurred after the IETF77 meeting. 422 Dimitri Papadimitriou, Lou Berger, Tony Li, the WG chairs John Scuder 423 and Alex Zinin, and others provided valuable guidance prior to and at 424 the IETF77 RTGWG meeting. 426 Tony Li and John Drake have made numerous valuable comments on the 427 RTGWG mailing list that are reflected in versions following the 428 IETF77 meeting. 430 8. IANA Considerations 432 This memo includes no request to IANA. 434 9. Security Considerations 436 This document specifies a set of requirements. The requirements 437 themselves do not pose a security threat. If these requirements are 438 met using MPLS signaling as commonly practiced today with 439 authenticated but unencrypted OSPF-TE, ISIS-TE, and RSVP-TE or LDP, 440 then the requirement to provide additional information in this 441 communication presents additional information that could conceivably 442 be gathered in a man-in-the-middle confidentiality breach. Such an 443 attack would require a capability to monitor this signaling either 444 through a provider breach or access to provider physical transmission 445 infrastructure. A provider breach already poses a threat of numerous 446 tpes of attacks which are of far more serious consequence. Encrption 447 of the signaling can prevent or render more difficult any 448 confidentiality breach that otherwise might occur by means of access 449 to provider physical transmission infrastructure. 451 10. References 453 10.1. Normative References 455 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 456 Requirement Levels", BCP 14, RFC 2119, March 1997. 458 10.2. Informative References 460 [I-D.ietf-l2vpn-vpms-frmwk-requirements] 461 Kamite, Y., JOUNAY, F., Niven-Jenkins, B., Brungard, D., 462 and L. Jin, "Framework and Requirements for Virtual 463 Private Multicast Service (VPMS)", 464 draft-ietf-l2vpn-vpms-frmwk-requirements-03 (work in 465 progress), July 2010. 467 [ITU-T.G.800] 468 ITU-T, "Unified functional architecture of transport 469 networks", 2007, . 472 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. 473 McManus, "Requirements for Traffic Engineering Over MPLS", 474 RFC 2702, September 1999. 476 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 477 Label Switching Architecture", RFC 3031, January 2001. 479 [RFC3468] Andersson, L. and G. Swallow, "The Multiprotocol Label 480 Switching (MPLS) Working Group decision on MPLS signaling 481 protocols", RFC 3468, February 2003. 483 [RFC3809] Nagarajan, A., "Generic Requirements for Provider 484 Provisioned Virtual Private Networks (PPVPN)", RFC 3809, 485 June 2004. 487 [RFC4031] Carugi, M. and D. McDysan, "Service Requirements for Layer 488 3 Provider Provisioned Virtual Private Networks (PPVPNs)", 489 RFC 4031, April 2005. 491 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 492 Networks (VPNs)", RFC 4364, February 2006. 494 [RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual 495 Private Networks (L2VPNs)", RFC 4664, September 2006. 497 [RFC4665] Augustyn, W. and Y. Serbest, "Service Requirements for 498 Layer 2 Provider-Provisioned Virtual Private Networks", 499 RFC 4665, September 2006. 501 [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service 502 (VPLS) Using BGP for Auto-Discovery and Signaling", 503 RFC 4761, January 2007. 505 [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service 506 (VPLS) Using Label Distribution Protocol (LDP) Signaling", 507 RFC 4762, January 2007. 509 [RFC4797] Rekhter, Y., Bonica, R., and E. Rosen, "Use of Provider 510 Edge to Provider Edge (PE-PE) Generic Routing 511 Encapsulation (GRE) or IP in BGP/MPLS IP Virtual Private 512 Networks", RFC 4797, January 2007. 514 [RFC5254] Bitar, N., Bocci, M., and L. Martini, "Requirements for 515 Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3)", 516 RFC 5254, October 2008. 518 10.3. Appendix References 520 [I-D.ietf-pwe3-fat-pw] 521 Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, 522 J., and S. Amante, "Flow Aware Transport of Pseudowires 523 over an MPLS PSN", draft-ietf-pwe3-fat-pw-03 (work in 524 progress), January 2010. 526 [RFC1717] Sklower, K., Lloyd, B., McGregor, G., and D. Carr, "The 527 PPP Multilink Protocol (MP)", RFC 1717, November 1994. 529 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 530 and W. Weiss, "An Architecture for Differentiated 531 Services", RFC 2475, December 1998. 533 [RFC2615] Malis, A. and W. Simpson, "PPP over SONET/SDH", RFC 2615, 534 June 1999. 536 [RFC2991] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and 537 Multicast Next-Hop Selection", RFC 2991, November 2000. 539 [RFC2992] Hopps, C., "Analysis of an Equal-Cost Multi-Path 540 Algorithm", RFC 2992, November 2000. 542 [RFC3260] Grossman, D., "New Terminology and Clarifications for 543 Diffserv", RFC 3260, April 2002. 545 [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling 546 in MPLS Traffic Engineering (TE)", RFC 4201, October 2005. 548 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 549 Internet Protocol", RFC 4301, December 2005. 551 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 552 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 553 Use over an MPLS PSN", RFC 4385, February 2006. 555 [RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal 556 Cost Multipath Treatment in MPLS Networks", BCP 128, 557 RFC 4928, June 2007. 559 Appendix A. Existing Network Operator Practices and Protocol Usage 561 The network operator practices appendix has been moved to a separate 562 document. When that document has an XML I-D tag the references to 563 this appendix will be changed to that document and this appendix will 564 be deleted. 566 Appendix B. Existing Multipath Standards and Techniques 568 The multipath standards and techniques appendix has been moved to a 569 separate document. When that document has an XML I-D tag the 570 references to this appendix will be changed to that document and this 571 appendix will be deleted. 573 Appendix C. ITU-T G.800 Composite Link Definitions and Terminology 575 Composite Link: 576 Section 6.9.2 of ITU-T-G.800 [ITU-T.G.800] defines composite link 577 in terms of three cases, of which the following two are relevant 578 (the one describing inverse (TDM) multiplexing does not apply). 579 Note that these case definitions are taken verbatim from section 580 6.9, "Layer Relationships". 582 Case 1: "Multiple parallel links between the same subnetworks 583 can be bundled together into a single composite link. Each 584 component of the composite link is independent in the sense 585 that each component link is supported by a separate server 586 layer trail. The composite link conveys communication 587 information using different server layer trails thus the 588 sequence of symbols crossing this link may not be preserved. 589 This is illustrated in Figure 14." 591 Case 3: "A link can also be constructed by a concatenation of 592 component links and configured channel forwarding 593 relationships. The forwarding relationships must have a 1:1 594 correspondence to the link connections that will be provided 595 by the client link. In this case, it is not possible to 596 fully infer the status of the link by observing the server 597 layer trails visible at the ends of the link. This is 598 illustrated in Figure 16." 600 Subnetwork: A set of one or more nodes (i.e., LER or LSR) and links. 601 As a special case it can represent a site comprised of multiple 602 nodes. 604 Forwarding Relationship: Configured forwarding between ports on a 605 subnetwork. It may be connectionless (e.g., IP, not considered 606 in this draft), or connection oriented (e.g., MPLS signaled or 607 configured). 609 Component Link: A topolological relationship between subnetworks 610 (i.e., a connection between nodes), which may be a wavelength, 611 circuit, virtual circuit or an MPLS LSP. 613 Authors' Addresses 615 Curtis Villamizar (editor) 616 OCCNC, LLC 618 Email: curtis@occnc.com 620 Dave McDysan (editor) 621 Verizon 622 22001 Loudoun County PKWY 623 Ashburn, VA 20147 625 Email: dave.mcdysan@verizon.com 627 So Ning 628 Verizon 629 2400 N. Glenville Ave. 630 Richardson, TX 75082 632 Phone: +1 972-729-7905 633 Email: ning.so@verizonbusiness.com 635 Andrew Malis 636 Verizon 637 117 West St. 638 Waltham, MA 02451 640 Phone: +1 781-466-2362 641 Email: andrew.g.malis@verizon.com 642 Lucy Yong 643 Huawei USA 644 1700 Alma Dr. Suite 500 645 Plano, TX 75075 647 Phone: +1 469-229-5387 648 Email: lucyyong@huawei.com