idnits 2.17.1 draft-ietf-rtgwg-cl-requirement-06.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 (June 7, 2012) is 4335 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-ietf-l2vpn-vpms-frmwk-requirements-04 == Outdated reference: A later version (-06) exists of draft-so-yong-rtgwg-cl-framework-05 == Outdated reference: A later version (-01) exists of draft-symmvo-rtgwg-cl-use-cases-00 Summary: 0 errors (**), 0 flaws (~~), 6 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: December 9, 2012 Verizon 6 S. Ning 7 Tata Communications 8 A. Malis 9 Verizon 10 L. Yong 11 Huawei USA 12 June 7, 2012 14 Requirements for MPLS Over a Composite Link 15 draft-ietf-rtgwg-cl-requirement-06 17 Abstract 19 There is often a need to provide large aggregates of bandwidth that 20 are best provided using parallel links between routers or MPLS LSR. 21 In core networks there is often no alternative since the aggregate 22 capacities of core networks today far exceed the capacity of a single 23 physical link or single packet processing element. 25 The presence of parallel links, with each link potentially comprised 26 of multiple layers has resulted in additional requirements. Certain 27 services may benefit from being restricted to a subset of the 28 component links or a specific component link, where component link 29 characteristics, such as latency, differ. Certain services require 30 that an LSP be treated as atomic and avoid reordering. Other 31 services will continue to require only that reordering not occur 32 within a microflow as is current practice. 34 Current practice related to multipath is described briefly in an 35 appendix. 37 Status of this Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on December 9, 2012. 54 Copyright Notice 56 Copyright (c) 2012 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 73 2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 4. Network Operator Functional Requirements . . . . . . . . . . . 5 76 4.1. Availability, Stability and Transient Response . . . . . . 5 77 4.2. Component Links Provided by Lower Layer Networks . . . . . 6 78 4.3. Parallel Component Links with Different Characteristics . 8 79 5. Derived Requirements . . . . . . . . . . . . . . . . . . . . . 10 80 6. Management Requirements . . . . . . . . . . . . . . . . . . . 11 81 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 83 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 84 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 85 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 86 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 87 Appendix A. ITU-T G.800 Composite Link Definitions and 88 Terminology . . . . . . . . . . . . . . . . . . . . . 14 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 91 1. Introduction 93 The purpose of this document is to describe why network operators 94 require certain functions in order to solve certain business problems 95 (Section 2). The intent is to first describe why things need to be 96 done in terms of functional requirements that are as independent as 97 possible of protocol specifications (Section 4). For certain 98 functional requirements this document describes a set of derived 99 protocol requirements (Section 5). Appendix A provides a summary of 100 G.800 terminology used to define a composite link. 102 1.1. Requirements Language 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in RFC 2119 [RFC2119]. 108 2. Assumptions 110 The services supported include L3VPN RFC 4364 [RFC4364], RFC 4797 111 [RFC4797]L2VPN RFC 4664 [RFC4664] (VPWS, VPLS (RFC 4761 [RFC4761], 112 RFC 4762 [RFC4762]) and VPMS VPMS Framework 113 [I-D.ietf-l2vpn-vpms-frmwk-requirements]), Internet traffic 114 encapsulated by at least one MPLS label (RFC 3032 [RFC3032]), and 115 dynamically signaled MPLS (RFC 3209 [RFC3209] or RFC 5036 [RFC5036]) 116 or MPLS-TP LSPs (RFC 5921 [RFC5921]) and pseudowires (RFC 3985 117 [RFC3985]). The MPLS LSPs supporting these services may be point-to- 118 point, point-to-multipoint, or multipoint-to-multipoint. 120 The locations in a network where these requirements apply are a Label 121 Edge Router (LER) or a Label Switch Router (LSR) as defined in RFC 122 3031 [RFC3031]. 124 The IP DSCP cannot be used for flow identification since L3VPN 125 requires Diffserv transparency (see RFC 4031 5.5.2 [RFC4031]), and in 126 general network operators do not rely on the DSCP of Internet 127 packets. 129 3. Definitions 131 ITU-T G.800 Based Composite and Component Link Definitions: 132 Section 6.9.2 of ITU-T-G.800 [ITU-T.G.800] defines composite and 133 component links as summarized in Appendix A. The following 134 definitions for composite and component links are derived from 135 and intended to be consistent with the cited ITU-T G.800 136 terminology. 138 Composite Link: A composite link is a logical link composed of a 139 set of parallel point-to-point component links, where all 140 links in the set share the same endpoints. A composite link 141 may itself be a component of another composite link, but only 142 a strict hierarchy of links is allowed. 144 Component Link: A point-to-point physical link (including one or 145 more link layer) or a logical link that preserves ordering in 146 the steady state. A component link may have transient out of 147 order events, but such events must not exceed the network's 148 specific NPO. Examples of a physical link are: any set of 149 link layers over a WDM wavelength or any supportable 150 combination of Ethernet PHY, PPP, SONET or OTN over a 151 physical link. Examples of a logical link are: MPLS LSP, 152 Ethernet VLAN, MPLS-TP LSP. A set of link layers supported 153 over pseudowire is a logical link that appears to the client 154 to be a physical link. 156 Flow: A sequence of packets that must be transferred in order on one 157 component link. 159 Flow identification: The label stack and other information that 160 uniquely identifies a flow. Other information in flow 161 identification may include an IP header, PW control word, 162 Ethernet MAC address, etc. Note that an LSP may contain one or 163 more Flows or an LSP may be equivalent to a Flow. Flow 164 identification is used to locally select a component link, or a 165 path through the network toward the destination. 167 Network Performance Objective (NPO): Numerical values for 168 performance measures, principally availability, latency, and 169 delay variation. See [I-D.symmvo-rtgwg-cl-use-cases] for more 170 details. 172 4. Network Operator Functional Requirements 174 The Functional Requirements in this section are grouped in 175 subsections starting with the highest priority. 177 4.1. Availability, Stability and Transient Response 179 Limiting the period of unavailability in response to failures or 180 transient events is extremely important as well as maintaining 181 stability. The transient period between some service disrupting 182 event and the convergence of the routing and/or signaling protocols 183 MUST occur within a time frame specified by NPO values. 184 [I-D.symmvo-rtgwg-cl-use-cases] provides references and a summary of 185 service types requiring a range of restoration times. 187 FR#1 The solution SHALL provide a means to summarize some routing 188 advertisements regarding the characteristics of a composite 189 link such that the routing protocol converges within the 190 timeframe needed to meet the network performance objective. A 191 composite link CAN be announced in conjunction with detailed 192 parameters about its component links, such as bandwidth and 193 latency. The composite link SHALL behave as a single IGP 194 adjacency. 196 FR#2 The solution SHALL ensure that all possible restoration 197 operations happen within the timeframe needed to meet the NPO. 198 The solution may need to specify a means for aggregating 199 signaling to meet this requirement. 201 FR#3 The solution SHALL provide a mechanism to select a path for a 202 flow across a network that contains a number of paths comprised 203 of pairs of nodes connected by composite links in such a way as 204 to automatically distribute the load over the network nodes 205 connected by composite links while meeting all of the other 206 mandatory requirements stated above. The solution SHOULD work 207 in a manner similar to that of current networks without any 208 composite link protocol enhancements when the characteristics 209 of the individual component links are advertised. 211 FR#4 If extensions to existing protocols are specified and/or new 212 protocols are defined, then the solution SHOULD provide a means 213 for a network operator to migrate an existing deployment in a 214 minimally disruptive manner. 216 FR#5 Any automatic LSP routing and/or load balancing solutions MUST 217 not oscillate such that performance observed by users changes 218 such that an NPO is violated. Since oscillation may cause 219 reordering, there MUST be means to control the frequency of 220 changing the component link over which a flow is placed. 222 FR#6 Management and diagnostic protocols MUST be able to operate 223 over composite links. 225 Existing scaling techniques used in MPLS networks apply to MPLS 226 networks which support Composite Links. Scalability and stability 227 are covered in more detail in [I-D.so-yong-rtgwg-cl-framework]. 229 4.2. Component Links Provided by Lower Layer Networks 231 Case 3 as defined in [ITU-T.G.800] involves a component link 232 supporting an MPLS layer network over another lower layer network 233 (e.g., circuit switched or another MPLS network (e.g., MPLS-TP)). 234 The lower layer network may change the latency (and/or other 235 performance parameters) seen by the MPLS layer network. Network 236 Operators have NPOs of which some components are based on performance 237 parameters. Currently, there is no protocol for the lower layer 238 network to inform the higher layer network of a change in a 239 performance parameter. Communication of the latency performance 240 parameter is a very important requirement. Communication of other 241 performance parameters (e.g., delay variation) is desirable. 243 FR#7 In order to support network NPOs and provide acceptable user 244 experience, the solution SHALL specify a protocol means to 245 allow a lower layer server network to communicate latency to 246 the higher layer client network. 248 FR#8 The precision of latency reporting SHOULD be configurable. A 249 reasonable default SHOULD be provided. Implementations SHOULD 250 support precision of at least 10% of the one way latencies for 251 latency of 1 ms or more. 253 FR#9 The solution SHALL provide a means to limit the latency on a 254 per LSP basis between nodes within a network to meet an NPO 255 target when the path between these nodes contains one or more 256 pairs of nodes connected via a composite link. 258 The NPOs differ across the services, and some services have 259 different NPOs for different QoS classes, for example, one QoS 260 class may have a much larger latency bound than another. 261 Overload can occur which would violate an NPO parameter (e.g., 262 loss) and some remedy to handle this case for a composite link 263 is required. 265 FR#10 If the total demand offered by traffic flows exceeds the 266 capacity of the composite link, the solution SHOULD define a 267 means to cause the LSPs for some traffic flows to move to some 268 other point in the network that is not congested. These 269 "preempted LSPs" may not be restored if there is no 270 uncongested path in the network. 272 The intent is to measure the predominant latency in uncongested 273 service provider networks, where geographic delay dominates and is on 274 the order of milliseconds or more. The argument for including 275 queuing delay is that it reflects the delay experienced by 276 applications. The argument against including queuing delay is that 277 it if used in routing decisions it can result in routing instability. 278 This tradeoff is discussed in detail in 279 [I-D.so-yong-rtgwg-cl-framework]. 281 4.3. Parallel Component Links with Different Characteristics 283 Corresponding to Case 1 of [ITU-T.G.800], as one means to provide 284 high availability, network operators deploy a topology in the MPLS 285 network using lower layer networks that have a certain degree of 286 diversity at the lower layer(s). Many techniques have been developed 287 to balance the distribution of flows across component links that 288 connect the same pair of nodes. When the path for a flow can be 289 chosen from a set of candidate nodes connected via composite links, 290 other techniques have been developed. Refer to the Appendices in 291 [I-D.symmvo-rtgwg-cl-use-cases] for a description of existing 292 techniques and a set of references. 294 FR#11 The solution SHALL measure traffic on a labeled traffic flow 295 and dynamically select the component link on which to place 296 this flow in order to balance the load so that no component 297 link in the composite link between a pair of nodes is 298 overloaded. 300 FR#12 When a traffic flow is moved from one component link to 301 another in the same composite link between a set of nodes (or 302 sites), it MUST be done so in a minimally disruptive manner. 304 FR#13 The solution SHALL provide a means to identify flows whose 305 rearrangement frequency needs to be bounded by a configured 306 value. 308 FR#14 The solution SHALL provide a means that communicates whether 309 the flows within an LSP can be split across multiple component 310 links. The solution SHOULD provide a means to indicate the 311 flow identification field(s) which can be used along the flow 312 path which can be used to perform this function. 314 FR#15 The solution SHALL provide a means to indicate that a traffic 315 flow shall select a component link with the minimum latency 316 value. 318 FR#16 The solution SHALL provide a means to indicate that a traffic 319 flow shall select a component link with a maximum acceptable 320 latency value as specified by protocol. 322 FR#17 The solution SHALL provide a means to indicate that a traffic 323 flow shall select a component link with a maximum acceptable 324 delay variation value as specified by protocol. 326 FR#18 The solution SHALL provide a means local to a node that 327 automatically distributes flows across the component links in 328 the composite link such that NPOs are met. 330 FR#19 The solution SHALL provide a means to distribute flows from a 331 single LSP across multiple component links to handle at least 332 the case where the traffic carried in an LSP exceeds that of 333 any component link in the composite link. As defined in 334 section 3, a flow is a sequence of packets that must be 335 transferred on one component link. 337 FR#20 The solution SHOULD support the use case where a composite 338 link itself is a component link for a higher order composite 339 link. For example, a composite link comprised of MPLS-TP bi- 340 directional tunnels viewed as logical links could then be used 341 as a component link in yet another composite link that 342 connects MPLS routers. 344 FR#21 The solution MUST support an optional means for LSP signaling 345 to bind an LSP to a particular component link within a 346 composite link. If this option is not exercised, then an LSP 347 that is bound to a composite link may be bound to any 348 component link matching all other signaled requirements, and 349 different directions of a bidirectional LSP can be bound to 350 different component links. 352 FR#22 The solution MUST support a means to indicate that both 353 directions of co-routed bidirectional LSP MUST be bound to the 354 same component link. 356 A minimally disruptive change implies that as little disruption as is 357 practical occurs. Such a change can be achieved with zero packet 358 loss. A delay discontinuity may occur, which is considered to be a 359 minimally disruptive event for most services if this type of event is 360 sufficiently rare. A delay discontinuity is an example of a 361 minimally disruptive behavior corresponding to current techniques. 363 A delay discontinuity is an isolated event which may greatly exceed 364 the normal delay variation (jitter). A delay discontinuity has the 365 following effect. When a flow is moved from a current link to a 366 target link with lower latency, reordering can occur. When a flow is 367 moved from a current link to a target link with a higher latency, a 368 time gap can occur. Some flows (e.g., timing distribution, PW 369 circuit emulation) are quite sensitive to these effects. A delay 370 discontinuity can also cause a jitter buffer underrun or overrun 371 affecting user experience in real time voice services (causing an 372 audible click). These sensitivities may be specified in an NPO. 374 5. Derived Requirements 376 This section takes the next step and derives high-level requirements 377 on protocol specification from the functional requirements. 379 DR#1 The solution SHOULD attempt to extend existing protocols 380 wherever possible, developing a new protocol only if this adds 381 a significant set of capabilities. 383 DR#2 A solution SHOULD extend LDP capabilities to meet functional 384 requirements (without using TE methods as decided in 385 [RFC3468]). 387 DR#3 Coexistence of LDP and RSVP-TE signaled LSPs MUST be supported 388 on a composite link. Other functional requirements should be 389 supported as independently of signaling protocol as possible. 391 DR#4 When the nodes connected via a composite link are in the same 392 MPLS network topology, the solution MAY define extensions to 393 the IGP. 395 DR#5 When the nodes are connected via a composite link are in 396 different MPLS network topologies, the solution SHALL NOT rely 397 on extensions to the IGP. 399 DR#6 The solution SHOULD support composite link IGP advertisement 400 that results in convergence time better than that of 401 advertising the individual component links. The solution SHALL 402 be designed so that it represents the range of capabilities of 403 the individual component links such that functional 404 requirements are met, and also minimizes the frequency of 405 advertisement updates which may cause IGP convergence to occur. 407 Examples of advertisement update triggering events to be 408 considered include: LSP establishment/release, changes in 409 component link characteristics (e.g., latency, up/down state), 410 and/or bandwidth utilization. 412 DR#7 When a worst case failure scenario occurs, the number of 413 RSVP-TE LSPs to be resignaled will cause a period of 414 unavailability as perceived by users. The resignaling time of 415 the solution MUST meet the NPO objective for the duration of 416 unavailability. The resignaling time of the solution MUST not 417 increase significantly as compared with current methods. 419 6. Management Requirements 421 MR#1 Management Plane MUST support polling of the status and 422 configuration of a composite link and its individual composite 423 link and support notification of status change. 425 MR#2 Management Plane MUST be able to activate or de-activate any 426 component link in a composite link in order to facilitate 427 operation maintenance tasks. The routers at each end of a 428 composite link MUST redistribute traffic to move traffic from a 429 de-activated link to other component links based on the traffic 430 flow TE criteria. 432 MR#3 Management Plane MUST be able to configure a LSP over a 433 composite link and be able to select a component link for the 434 LSP. 436 MR#4 Management Plane MUST be able to trace which component link a 437 LSP is assigned to and monitor individual component link and 438 composite link performance. 440 MR#5 Management Plane MUST be able to verify connectivity over each 441 individual component link within a composite link. 443 MR#6 Management Plane SHOULD provide the means for an operator to 444 initiate an optimization process. 446 MR#7 Any statement which requires the solution to support some new 447 functionality through use of the words new functionality, 448 SHOULD be interpretted as follows. The implementation either 449 MUST or SHOULD support the new functionality depending on the 450 use of either MUST or SHOULD in the requirements statement. 451 The implementation SHOULD in most or all cases allow any new 452 functionality to be individually enabled or disabled through 453 configuration. 455 7. Acknowledgements 457 Frederic Jounay of France Telecom and Yuji Kamite of NTT 458 Communications Corporation co-authored a version of this document. 460 A rewrite of this document occurred after the IETF77 meeting. 461 Dimitri Papadimitriou, Lou Berger, Tony Li, the WG chairs John Scuder 462 and Alex Zinin, and others provided valuable guidance prior to and at 463 the IETF77 RTGWG meeting. 465 Tony Li and John Drake have made numerous valuable comments on the 466 RTGWG mailing list that are reflected in versions following the 467 IETF77 meeting. 469 Iftekhar Hussain and Kireeti Kompella made comments on the RTGWG 470 mailing list after IETF82 that identified a new requirement. 471 Iftekhar Hussain made numerous valuable comments on the RTGWG mailing 472 list that resulted in improvements to document clarity. 474 In the interest of full disclosure of affiliation and in the interest 475 of acknowledging sponsorship, past affiliations of authors are noted. 476 Much of the work done by Ning So occurred while Ning was at Verizon. 477 Much of the work done by Curtis Villamizar occurred while at 478 Infinera. Infinera continues to sponsor this work on a consulting 479 basis. 481 8. IANA Considerations 483 This memo includes no request to IANA. 485 9. Security Considerations 487 This document specifies a set of requirements. The requirements 488 themselves do not pose a security threat. If these requirements are 489 met using MPLS signaling as commonly practiced today with 490 authenticated but unencrypted OSPF-TE, ISIS-TE, and RSVP-TE or LDP, 491 then the requirement to provide additional information in this 492 communication presents additional information that could conceivably 493 be gathered in a man-in-the-middle confidentiality breach. Such an 494 attack would require a capability to monitor this signaling either 495 through a provider breach or access to provider physical transmission 496 infrastructure. A provider breach already poses a threat of numerous 497 tpes of attacks which are of far more serious consequence. Encrption 498 of the signaling can prevent or render more difficult any 499 confidentiality breach that otherwise might occur by means of access 500 to provider physical transmission infrastructure. 502 10. References 504 10.1. Normative References 506 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 507 Requirement Levels", BCP 14, RFC 2119, March 1997. 509 10.2. Informative References 511 [I-D.ietf-l2vpn-vpms-frmwk-requirements] 512 Kamite, Y., JOUNAY, F., Niven-Jenkins, B., Brungard, D., 513 and L. Jin, "Framework and Requirements for Virtual 514 Private Multicast Service (VPMS)", 515 draft-ietf-l2vpn-vpms-frmwk-requirements-04 (work in 516 progress), July 2011. 518 [I-D.so-yong-rtgwg-cl-framework] 519 So, N., McDysan, D., Osborne, E., Yong, L., and C. 520 Villamizar, "Composite Link Framework in Multi Protocol 521 Label Switching (MPLS)", 522 draft-so-yong-rtgwg-cl-framework-05 (work in progress), 523 March 2012. 525 [I-D.symmvo-rtgwg-cl-use-cases] 526 Malis, A., Villamizar, C., McDysan, D., Yong, L., and N. 527 So, "Composite Link USe Cases and Design Considerations", 528 draft-symmvo-rtgwg-cl-use-cases-00 (work in progress), 529 February 2012. 531 [ITU-T.G.800] 532 ITU-T, "Unified functional architecture of transport 533 networks", 2007, . 536 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 537 Label Switching Architecture", RFC 3031, January 2001. 539 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 540 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 541 Encoding", RFC 3032, January 2001. 543 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 544 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 545 Tunnels", RFC 3209, December 2001. 547 [RFC3468] Andersson, L. and G. Swallow, "The Multiprotocol Label 548 Switching (MPLS) Working Group decision on MPLS signaling 549 protocols", RFC 3468, February 2003. 551 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- 552 Edge (PWE3) Architecture", RFC 3985, March 2005. 554 [RFC4031] Carugi, M. and D. McDysan, "Service Requirements for Layer 555 3 Provider Provisioned Virtual Private Networks (PPVPNs)", 556 RFC 4031, April 2005. 558 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 559 Networks (VPNs)", RFC 4364, February 2006. 561 [RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual 562 Private Networks (L2VPNs)", RFC 4664, September 2006. 564 [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service 565 (VPLS) Using BGP for Auto-Discovery and Signaling", 566 RFC 4761, January 2007. 568 [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service 569 (VPLS) Using Label Distribution Protocol (LDP) Signaling", 570 RFC 4762, January 2007. 572 [RFC4797] Rekhter, Y., Bonica, R., and E. Rosen, "Use of Provider 573 Edge to Provider Edge (PE-PE) Generic Routing 574 Encapsulation (GRE) or IP in BGP/MPLS IP Virtual Private 575 Networks", RFC 4797, January 2007. 577 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 578 Specification", RFC 5036, October 2007. 580 [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. 581 Berger, "A Framework for MPLS in Transport Networks", 582 RFC 5921, July 2010. 584 Appendix A. ITU-T G.800 Composite Link Definitions and Terminology 586 Composite Link: 587 Section 6.9.2 of ITU-T-G.800 [ITU-T.G.800] defines composite link 588 in terms of three cases, of which the following two are relevant 589 (the one describing inverse (TDM) multiplexing does not apply). 590 Note that these case definitions are taken verbatim from section 591 6.9, "Layer Relationships". 593 Case 1: "Multiple parallel links between the same subnetworks 594 can be bundled together into a single composite link. Each 595 component of the composite link is independent in the sense 596 that each component link is supported by a separate server 597 layer trail. The composite link conveys communication 598 information using different server layer trails thus the 599 sequence of symbols crossing this link may not be preserved. 600 This is illustrated in Figure 14." 602 Case 3: "A link can also be constructed by a concatenation of 603 component links and configured channel forwarding 604 relationships. The forwarding relationships must have a 1:1 605 correspondence to the link connections that will be provided 606 by the client link. In this case, it is not possible to 607 fully infer the status of the link by observing the server 608 layer trails visible at the ends of the link. This is 609 illustrated in Figure 16." 611 Subnetwork: A set of one or more nodes (i.e., LER or LSR) and links. 612 As a special case it can represent a site comprised of multiple 613 nodes. 615 Forwarding Relationship: Configured forwarding between ports on a 616 subnetwork. It may be connectionless (e.g., IP, not considered 617 in this draft), or connection oriented (e.g., MPLS signaled or 618 configured). 620 Component Link: A topolological relationship between subnetworks 621 (i.e., a connection between nodes), which may be a wavelength, 622 circuit, virtual circuit or an MPLS LSP. 624 Authors' Addresses 626 Curtis Villamizar (editor) 627 OCCNC, LLC 629 Email: curtis@occnc.com 631 Dave McDysan (editor) 632 Verizon 633 22001 Loudoun County PKWY 634 Ashburn, VA 20147 636 Email: dave.mcdysan@verizon.com 638 So Ning 639 Tata Communications 641 Email: ning.so@tatacommunications.com 642 Andrew Malis 643 Verizon 644 117 West St. 645 Waltham, MA 02451 647 Phone: +1 781-466-2362 648 Email: andrew.g.malis@verizon.com 650 Lucy Yong 651 Huawei USA 652 1700 Alma Dr. Suite 500 653 Plano, TX 75075 655 Phone: +1 469-229-5387 656 Email: lucyyong@huawei.com