idnits 2.17.1 draft-so-yong-mpls-ctg-framework-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 16, 2009) is 5306 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ITU-T G.800' is mentioned on line 207, but not defined Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Routing Working Group N. So 2 Internet Draft A. Malis 3 Intended Status: Informational D. McDysan 4 Expires: Verizon 5 L. Yong 6 Huawei 7 F. Jounay 8 France Telecom 9 Y. Kamite 10 NTT 11 October 16, 2009 13 Framework for MPLS Over Composite Link 15 draft-so-yong-mpls-ctg-framework-00 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. This document may not be modified, 24 and derivative works of it may not be created, and it may not be 25 published except as an Internet-Draft. 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. This document may not be modified, 29 and derivative works of it may not be created, except to publish it 30 as an RFC and to translate it into languages other than English. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html 48 This Internet-Draft will expire on December 17, 2009. 50 Copyright Notice 52 Copyright (c) 2009 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents in effect on the date of 57 publication of this document (http://trustee.ietf.org/license-info). 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. 61 Abstract 63 This document describes a framework for managing aggregated traffic 64 over a composite link. A composite link consists of a group of non- 65 homogenous links that have the same forward adjacency and can be 66 considered as a single TE link or an IP link used for MPLS. The 67 document primarily focuses on MPLS data plane and control plane 68 traffic over a composite link and composite link advertisement within 69 IGP. MPLS traffic can be set up by either RSVP-TE or LDP signaling. 70 Applicability is described for a single pair of MPLS-capable nodes, a 71 sequence of MPLS-capable nodes, or a set of layer networks connecting 72 MPLS-capable nodes. 74 Table of Contents 76 1. Introduction...................................................2 77 2. Conventions used in this document..............................3 78 2.1. Acronyms..................................................3 79 2.2. Terminology...............................................4 80 3. Composite Link Framework.......................................4 81 3.1. Composite Link Architecture...............................4 82 3.2. Interior Functions........................................6 83 3.2.1. Functions specific to LSP flows with TE information..7 84 3.2.2. Functions specific to LSP flows without TE information7 85 3.2.3. Functions for LSP flows with and without TE information 86 ............................................................7 87 3.3. Exterior Functions........................................8 88 3.3.1. Composite Link Advertisement and Component Link Setup8 89 3.3.2. Functions specific to LSP flows with TE information..8 90 3.3.3. Functions specific to LSP flows without TE information8 91 3.3.4. Functions to LSP flows with and without TE information9 92 4. Applicability..................................................9 93 4.1. Single-Layer Scenarios....................................9 94 4.2. Multi-Layer Scenario.....................................10 95 5. Security Considerations.......................................10 96 6. IANA Considerations...........................................11 97 7. References....................................................11 98 7.1. Normative References.....................................11 99 7.2. Informative References...................................11 100 8. Acknowledgments...............................................11 102 1. Introduction 104 This document describes a framework of Composite Link in IP/MPLS 105 network. Single link and link bundle [RFC4201] have been widely used 106 in today's IP/MPLS networks. A link bundle bundles a group of 107 homogeneous links as a TE link to make routing approach more 108 scalable. A composite link allows bundling non-homogenous links 109 together as a single logical link. The motivations for using a 110 composite link are descried in the document [CL Requirement]. This 111 document states composite link framework in the context of MPLS 112 network with MPLS control plane. 114 A composite link is a single logical link that contains multiple 115 parallel component links between two routers. Unlike a link bundle 116 [RFC4201], the component links in a composite link can have different 117 properties such as cost or capacity. A composite link can transport 118 aggregated traffic as other physical links from the network 119 perspective and use its component links to carry the traffic 120 internally. To achieve the better component link utilization and 121 avoid component link congestion, the document describes some new 122 aspects on the traffic flow assignment to component links. The 123 document also describes the advertisement of a composite link as a 124 routing interface in MPLS control plane and the addition of component 125 links to a composite link. 127 Specific protocol solutions are outside the scope of this document. 129 2. Conventions used in this document 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in RFC-2119. 135 2.1. Acronyms 137 BW: Bandwidth 139 CTG: Composite Transport Group 141 ECMP: Equal Cost Multi-Path 143 FRR: Fast Re-Route 145 LAG: Link Aggregation Group 147 LDP: Label Distribution Protocol 149 LSA: Link State Advertisements 151 LSP: Label Switched Path 153 MPLS: Multi-Protocol Label Switching 155 OAM: Operation, Administration, and Management 156 PDU: Protocol Data Unit 158 PE: Provider Edge device 160 RSVP: ReSource reserVation Protocol 162 RTD: Real Time Delay 164 TE: Traffic Engineering 166 VRF: Virtual Routing and Forwarding 168 2.2. Terminology 170 Composite Link: a group of component links, which can be considered 171 as a single MPLS TE link or as a single IP link used for MPLS. 173 Component Link: a physical link (e.g., Lambda, Ethernet PHY, SONET/ 174 SDH, OTN, etc.) with packet transport capability, or a logical link 175 (e.g., MPLS LSP, Ethernet VLAN, MPLS-TP LSP, etc.) 177 Connection: An aggregation of traffic flows which are treated 178 together as a single unit by Composite Link Interior Functions for 179 the purpose of routing onto a specific component link and measuring 180 traffic volume. 182 Exterior Functions: These are performed by an MPLS router that makes 183 a composite link useable by the network via control protocols, or by 184 an MPLS router that interacts with other routers to dynamically 185 configure a component link within a composite link. These functions 186 are those that interact via routing and/or signaling protocols with 187 other routers in the same layer network or other layer networks. 189 Interior Functions: Actions performed by the MPLS routers directly 190 connected by a composite link. This includes the determination of the 191 component link on which a traffic flow is placed. This is local 192 implementation. 194 Traffic Flow: A set of packets with a common identifier and 195 characteristics that is used by Composite link interior functions to 196 place the set of packets on the same component link. Identifiers can 197 be an MPLS label stack or any combination of IP addresses and 198 protocol types for routing, signaling, and management packets. 200 Virtual Interface: Composite link is advertised as a interface in IGP 202 3. Composite Link Framework 204 3.1. Composite Link Architecture 206 Composite Link Characteristics is defined at a high level in ITU-T 207 [ITU-T G.800] that makes multiple parallel component links between 208 two transport nodes appear as a single logical link from the network 209 perspective. Each component link in a composite link can be 210 supported by a separate server layer trail, i.e. the component links 211 in a composite link can have the same or different properties such as 212 latency and capacity. Composite link framework is illustrated in 213 Figure 1, where a composite link is configured between routers R1 and 214 R2. The composite link has three component links. Individual 215 component links in a composite link may be supported by different 216 transport technologies such as wavelength, Ethernet VLAN, or can be a 217 logical link configured on a LSP [LSP Hierarchy]. Even if the 218 transport technology implementing the component links is identical, 219 the characteristics (e.g., bandwidth, latency) of the component links 220 may differ. 222 Composite Link can apply to MPLS network. As shown in Figure 1, the 223 composite link may carry LSP traffic flows and control plane packets. 224 A LSP may be established over the link by either RSVP-TE or LDP 225 signaling protocols. All component links in a composite link have the 226 same forwarding adjacency. The composite link forms one routing 227 interface between two connected routers for MPLS control plane. In 228 other words, two routers connected via a composite link have 229 forwarding adjacency and routing adjacency. Each component link only 230 has significance to the composite link, i.e. it does not appear as a 231 link in the control plane. 233 Composite link relies on its component links to carry the traffic. An 234 important framework concept is the connection shown in Figure 1. The 235 connection only exists within the composite link and is controlled by 236 the composite link function. At the transmitting end (R1 in Figure 237 1), composite link maps a set of traffic flows including control 238 plane packets into one connection and routes the connection on a 239 specific component link. This method enables connection based routing 240 over component links and traffic volume measurement on a per 241 connection basis. As a result, it guarantees the ordering per traffic 242 flow. One component link may carry one or more connections. At the 243 receiving end (R2 in Figure 1), composite link receives traffic flows 244 from its component links and sends them to MPLS forwarding engine 245 like a regular link. Note that a special case of this model is where 246 a single flow is mapped to a single connection. 248 Management Plane 249 Configuration and Measurement <------------+ 250 ^ | 251 | | 252 | | 253 | | 254 +-------+-+ +-+-------+ 255 | | | | | | 256 CP Packets V | | V CP Packets 257 | V +-+-+ Component Link 1 +-+-+ ^ | 258 | | | |===========================| | | | 259 | +--|-|*|****** connections ********|*|-|--+ | 260 ~~|~~>~~|~| |===========================| |~|~~>~~|~~ 261 LSP ~~|~~>~~|~| | Component Link 2 | |~|~~>~~|~~ LSP 262 Traffic~|~~>~~|~| |===========================| |~|~~>~~|~~ Traffic 263 Flows ~~|~~>~~|~|*|****** connections ********|*|~|~~>~~|~~ Flows 264 ~~|~~>~~|~| |===========================| |~|~~>~~|~~ 265 ~~|~~>~~|~| | Component Link 3 | |~|~~>~~|~~ 266 ~~|~~>~~|~| |===========================| |~|~~>~~|~~ 267 | | |*|****** connections ********|*| | | 268 | | | |===========================| | | 269 | +---+ +---+ | 270 +---------+ +---------+ 271 ! ! ! ! 272 ! !<---- Component Links ---->! ! 273 !<------- Composite Link ---------->! 275 Figure 1: Composite Link Architecture Model 277 3.2. Interior Functions 279 The interior functions are implemented within the interior of MPLS 280 routers connected via a composite link. This includes local 281 determination of the component link on which a traffic flow is 282 placed, i.e. the flow to the interface mapping. Although this 283 assignment is local, management configuration for some aspects of 284 these interior functions is important to achieve operational 285 consistency. 287 As described in section 3.1, the Interior Functions map traffic flows 288 to a connection and route connections to component links based on 289 traffic flow parameters, connection parameters, and component link 290 parameters. The connection parameters may be calculated from the 291 parameters of the flows mapped to the connection or may derive from 292 the measurement of the traffic volume on the connection plus 293 configured connection parameters via the management plane. 295 A component link in a composite link may fail independently. The 296 interior functions are able to detect component link failure and re- 297 assign impacted flows to other active component links. When a 298 composite link can't recover some impacted flows, it notifies control 299 plane about the flows. When a composite link is not able to transport 300 all flows, it preempts some flows based upon local management 301 configuration and informs the control plane on these preempted flows. 302 This action ensures the remaining traffic is transported properly. 304 The interior functions provide component link fault notification and 305 composite link fault notification upon the failure of a component 306 link or a composite link. Component link fault notification is sent 307 to the management plane. Composite link fault notification is sent to 308 the control plane and management plane. Composite link allows 309 operator to trace which component link a LSP is assigned to. 311 3.2.1. Functions specific to LSP flows with TE information 313 When a composite link is deployed in a MPLS-TE network, LSPs are 314 signaled by RSVP-TE protocol. The protocol message contains LSP 315 parameters like BW, setting/holding priority, latency, etc. The 316 composite link will take these parameters into account when assigning 317 LSP to a connection and a connection to a component link. 319 3.2.2. Functions specific to LSP flows without TE information 321 When a composite link is deployed in a non-TE MPLS network, LSPs are 322 signaled by LDP. LDP message does not provide LSP TE information. 323 These LSPs can be mapped to local configured connections with minimum 324 bandwidth, maximum bandwidth, preemption priority, and holding 325 priority parameters. The interior function measures the traffic 326 volume on the connection and derives the BW parameter for the 327 connection. The interior functions use these parameters to assign the 328 connection to a component link. 330 When the connection bandwidth exceeds the component link capacity, 331 the interior functions are able to reassign the traffic flows to 332 other connections that are over different component links. 334 3.2.3. Functions for LSP flows with and without TE information 336 When a composite link carries LSPs that are signaled by LDP or RSVP- 337 TE, the interior functions separates them into different connections 338 that have independent parameters. If there is a shortage of capacity 339 in a composite link, interior functions perform preemption, rerouting 340 or termination of flows based on the traffic flow priority. 342 3.3. Exterior Functions 344 The Exterior Functions have the aspects that are applicable exterior 345 to the connected MPLS routers. These exterior functions apply to 346 routing and signaling protocols. Protocol solutions are for further 347 study. 349 3.3.1. Composite Link Advertisement and Component Link Setup 351 In IGP, a composite Link is advertised as a single virtual routable 352 interface between two connected routers, which forms routing and 353 forwarding adjacency between the connected routers. A composite link 354 must be advertised as a link in IGP.[RFC2328] The interface 355 parameters for the composite link can be pre-configured by operator 356 or be derived from its component links. Composite link latency may be 357 advertised for other routers to perform route computation. 359 A composite link may contain the set of component links. A component 360 link may be configured by operator or signaled by the control plane. 361 In both cases, it is necessary to convey component link parameters to 362 the composite link. 364 When a component link is supported by lower layer network as 365 described in section 4.2, the control plane that the composite link 366 resides is able to interoperate with the GMPLS or MPLS-TP control 367 plane that lower layer network uses for component link addition and 368 deletion. 370 Composite link advertisement and component link setup requirements 371 are specified in [CTG Requirement] 373 3.3.2. Functions specific to LSP flows with TE information 375 When RSVP-TE [RFC3209] signals a LSP over a composite link, the 376 composite link takes the signaled LSP parameters as the flow 377 parameters and sends the PATH message to the downstream router of the 378 composite link. The downstream router selects the LSP label that is 379 used over the composite link and sends RESV message with the label 380 info. to the upstream LSR. The forward engine at the upstream LSR 381 will push the label into the LSP packets. Composite link interior 382 functions map the label to a connection that is assigned to a 383 component link. 385 When a composite link is advertised as a TE link in MPLS-TE network 386 [RFC3630], composite link capacity is advertised. It is possible to 387 advertise multiple capacities and latencies to reflect individual 388 component link property. [CTG requirement] 390 3.3.3. Functions specific to LSP flows without TE information 392 When LDP [RFC5036] is used to signal LSPs over a composite link, a 393 LDP session has to be established between two LSRs connected via a 394 composite link. When signaling a LSP for a FEC over the composite 395 link, the upstream LSR sends label request message to the downstream 396 LSR, the downstream LSR selects a label for the FEC and sends the 397 label mapping message back to the upstream LSR. 399 3.3.4. Functions to LSP flows with and without TE information 401 When there is a shortage of capacity in a composite link which 402 supports LSP flows with and without TE information, interior 403 functions are able to perform preemption, rerouting or termination of 404 flows to ensure transport quality, the exterior functions are able to 405 inform LSR control plan preempted flows. Thus the control plan 406 informs the LSP head-end if it is singled by RSVP-TE or prunes label 407 distribution for the LSP that is singled by LDP. 409 4. Applicability 411 A composite link may be deployed between two Ps, P and PE, and two 412 PEs. Two routers connected via a composite link forms forwarding 413 adjacency and routing adjacency. It can be used in MPLS-TE only, MPLS 414 non-TE only, or combined environment. 416 In MPLS-TE application, the composite link is advertised as a link in 417 IGP and a TE link in IGP TE extension that uses either OSPF-TE or IS- 418 IS-TE. RSVP-TE signaling protocol is used to establish a LSP. TE 419 tunnel and private line are examples of applications. 421 In MPLS non-TE application, the composite link is advertised as a 422 link within the IGP that uses either OSPF or IS-IS as routing 423 protocol. In this case, LDP signaling protocol is used to establish a 424 LSP. L3VPN is the most popular application for this case. 426 In the hybrid application, the composite link is advertised as a link 427 and a TE link within IGP by using different types of LSA and both 428 RSVP-TE and LDP signaling for LSP establishment, as described in 429 section 3. 431 4.1. Single-Layer Scenarios 433 The component links of Figure 1 applies to at least the scenarios 434 illustrated in Figure 2. The component links may be physical or 435 logical, or supported by different technologies. In the first 436 scenario, a set of physical links connect adjacent (P) routers 437 (R1/R2). 439 In the second scenario, a set of logical links connect adjacent (P or 440 PE) routers over other equipment (i.e., R3/R4) that may implement 441 RSVP-TE signaled MPLS tunnels which may be in the same IGP as R1/R2. 442 In this case, R3/R4 provides a TE-LSP segment of TE-LSP from R1 and 443 R2. In another case, R3/R4 are in different IGP from R1/R2, R3 and R4 444 provide connectivity for R1 and R2. The connectivity provides a 445 component link in the composite link of R1/R2. R3 and P4 may 446 implement MPLS-TP. 448 +----+---+ 1. Physical Link +---+----+ 449 | | |----------------------------------------------| | | 450 | | | | | | 451 | | | +------+ +------+ | C | | 452 | | C | | MPLS | 2. Logical Link | MPLS | | | | 453 | | |.... |......|.....................|......|....| | | 454 | | |-----| R3 |---------------------| R4 |----| | | 455 | | T | +------+ +------+ | T | | 456 | | | | | | 457 | | | | | | 458 | | G | +------+ +------+ | G | | 459 | | | |GMPLS | 3. Lower Layer Link |GMPLS | | | | 460 | | |. ...|......|.....................|......|....| | | 461 | | |-----| R5 |---------------------| R6 |----| | | 462 | | | +------+ +------+ | | | 463 | R1 | | | | R2 | 464 +----+---+ +---+----+ 465 |<---------- Composite Link ----------------->| 467 Figure 4: Illustration of Component Link Types 469 4.2. Multi-Layer Scenario 471 In the third scenario in Figure 2, GMPLS lower layer LSPs (e.g., 472 Fiber, Wavelength, TDM) as determined by a lower layer network in a 473 multi-layer network deployment as illustrated by R5/R6. In this case, 474 R5 and R6 would usually not be part of the same IGP as R1/R2 and may 475 have a static interface, or may have a signaling but not a routing 476 association with R1 and R2. Note that in scenarios 2 and 3 when the 477 intermediate routers are not part of the same IGP as R1/R2 (i.e., can 478 be viewed as operating at a lower layer) that the characteristics of 479 these links (e.g., latency) may change dynamically, and there is an 480 operational desire to handle this type of situation in a more 481 automated fashion than is currently possible with existing protocols. 482 Note that this problem currently occurs with a single lower-layer 483 link in existing networks and it would be desirable for the solution 484 to handle the case of a single lower-layer component link as well. 485 Note that the interfaces at R1 and R2 are associated with these 486 different component links can be configured with IP addresses or use 487 unnumbered links as an interior, local function since the individual 488 component links are not advertised as the virtual interface. 490 5. Security Considerations 492 The solution is a local function on the router to support traffic 493 engineering management over multiple parallel links. It does not 494 introduce a security risk for control plane and data plane. 496 The solution could change the frequency of routing update messages 497 and therefore could change routing convergence time. The solution 498 MUST provide controls to dampen the frequency of such changes so as 499 to not destabilize routing protocols. 501 6. IANA Considerations 503 IANA actions to provide solutions are for further study. 505 7. References 507 7.1. Normative References 509 [RFC2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 511 [RFC3209] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. 512 Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels," December 513 2001 515 [RFC3630] Katz, D., "Traffic Engineering (TE) Extension to OSPF 516 Version 2", RFC 3630, September 2003. 518 [RFC4201] Kompella, K., "Link Bundle in MPLS Traffic Engineering", 519 RFC 4201, March 2005. 521 [RFC5036] Andersson, L., "LDP Specification", RFC 5036 , October 522 2007. 524 7.2. Informative References 526 [Entropy Label] Kompella, K. and S. Amante, "The Use of Entropy 527 Labels in MPLS Forwarding", November 2008, Work in Progress 529 [LSP Hierarchy] Shiomoto, K. and A. Farrel, "Procedures for 530 Dynamically Signaled Hierarchical Label Switched 531 Paths", November 2008, Work in Progress 533 [Soft Preemption] Meyer, M. and J. Vasseur, "MPLS Traffic Engineering 534 Soft Preemption", February 2009, Work in Progress 536 [CTG Requirement] So, N. and Yong, L, "Requirements for MPLS Over 537 Composite Link", Oct. 2009, Work in Progress 539 8. Acknowledgments 541 Authors would like to thank Adrian Farrel for his extensive comments 542 and suggestions, Ron Bonica, Nabil Bitar, Eric Gray, Lou Berger, and 543 Kireeti Kompella for their reviews and great suggestions. 545 This document was prepared using 2-Word-v2.0.template.dot. 547 Copyright (c) 2009 IETF Trust and the persons identified as authors 548 of the code. All rights reserved. 550 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 551 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 552 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 553 A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 554 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 555 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 556 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 557 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 558 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 559 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 560 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 562 This code was derived from IETF RFC [insert RFC number]. Please 563 reproduce this note if possible. 565 Authors' Addresses 567 So Ning 568 Verizon 569 2400 N. Glem Ave., 570 Richerdson, TX 75082 571 Phone: +1 972-729-7905 572 Email: ning.so@verizonbusiness.com 574 Andrew Malis 575 Verizon 576 117 West St. 577 Waltham, MA 02451 578 Phone: +1 781-466-2362 579 Email: andrew.g.malis@verizon.com 581 Dave McDysan 582 Verizon 583 22001 Loudoun County PKWY 584 Ashburn, VA 20147 585 Email: dave.mcdysan@verizon.com 587 Lucy Yong 588 Huawei USA 589 1700 Alma Dr. Suite 500 590 Plano, TX 75075 591 Phone: +1 469-229-5387 592 Email: lucyyong@huawei.com 594 Frederic Jounay 595 France Telecom 596 2, avenue Pierre-Marzin 597 22307 Lannion Cedex, 598 FRANCE 599 Email: frederic.jounay@orange-ftgroup.com 601 Yuji Kamite 602 NTT Communications Corporation 603 Granpark Tower 604 3-4-1 Shibaura, Minato-ku 605 Tokyo 108-8118 606 Japan 607 Email: y.kamite@ntt.com