idnits 2.17.1 draft-li-idr-mpls-path-programming-02.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 -- The document date (October 17, 2015) is 3104 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3032' is defined on line 508, but no explicit reference was found in the text == Unused Reference: 'RFC4271' is defined on line 518, but no explicit reference was found in the text == Unused Reference: 'RFC5036' is defined on line 528, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-pce-pce-initiated-lsp' is defined on line 538, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-idr-custom-decision-06 == Outdated reference: A later version (-22) exists of draft-ietf-idr-tunnel-encaps-00 == Outdated reference: A later version (-11) exists of draft-ietf-pce-pce-initiated-lsp-04 -- Obsolete informational reference (is this intentional?): RFC 3107 (Obsoleted by RFC 8277) Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Li 3 Internet-Draft Z. Zhuang 4 Intended status: Standards Track Huawei Technologies 5 Expires: April 19, 2016 S. Lu 6 Tencent 7 October 17, 2015 9 BGP Extensions for Service-Oriented MPLS Path Programming (MPP) 10 draft-li-idr-mpls-path-programming-02 12 Abstract 14 Service-oriented MPLS programming (SoMPP) is to provide customized 15 service process based on flexible label combinations. BGP will play 16 an important role for MPLS path programming to download programmed 17 MPLS path and map the service path to the transport path. This 18 document defines BGP extensions to support Service-oriented MPLS path 19 programming. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC 2119 [RFC2119]. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on April 19, 2016. 44 Copyright Notice 46 Copyright (c) 2015 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Architecture and Usecases of SoMPP . . . . . . . . . . . . . 3 64 3.1. Architecture . . . . . . . . . . . . . . . . . . . . . . 3 65 3.2. Usecases . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3.2.1. Deterministic ECMP . . . . . . . . . . . . . . . . . 4 67 3.2.2. Centralized Mapping of Service to Tunnels . . . . . . 5 68 4. Download of MPLS Path . . . . . . . . . . . . . . . . . . . . 5 69 5. Download of Mapping of Service Path to Transport Path . . . . 7 70 5.1. Specify Tunnel Type . . . . . . . . . . . . . . . . . . . 7 71 5.2. Specify Specific Tunnel . . . . . . . . . . . . . . . . . 7 72 6. Route Flag Extended Community . . . . . . . . . . . . . . . . 9 73 7. Destination Node Attribute . . . . . . . . . . . . . . . . . 9 74 8. Capability Negotiation . . . . . . . . . . . . . . . . . . . 10 75 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 76 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 77 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 79 11.2. Informative References . . . . . . . . . . . . . . . . . 12 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 82 1. Introduction 84 The label stack capability of MPLS would have been utilized well to 85 implement flexible path programming to satisfy all kinds of service 86 requirements. But in the distributed environment, the flexible 87 programming capability is difficult to implement and always confined 88 to reachability. As the introducing of central control in the 89 network, the flexible MPLS programming capability becomes possible 90 owing to two factors: 1. It becomes easier to allocate label for 91 more purposes than reachability; 2. It is easy to calculate the MPLS 92 path in a global network view. Moreover, the MPLS path programming 93 capability can be utilized to satisfy more requirements of service 94 bearing in the service layer which is defined as Service-oriented 95 MPLS path programming. BGP will play an important role for MPLS path 96 programming to download programmed MPLS path and map the service path 97 to the transport path. This document defines BGP extensions to 98 support Service-oriented MPLS path programming. 100 2. Terminology 102 BGP: Border Gateway Protocol 104 EVPN: Ethernet VPN 106 L2VPN: Layer 2 VPN 108 L3VPN: Layer 3 VPN 110 MPP: MPLS Path Programming 112 MVPN: Multicast VPN 114 RR: Route Reflector 116 SR-Path: Segment Routing Path 118 NLRI: Network Layer Reachability Information 120 3. Architecture and Usecases of SoMPP 122 3.1. Architecture 124 The architecture of BGP-based MPLS path programming is shown in the 125 Figure 1. Central control plays an important role in MPLS path 126 programming. It can extend the MPLS path programming capability 127 easily. The central controller can calculate path in a global 128 network view and implement the MPLS path programming to satisfy 129 different requirements of services. The result of MPLS path 130 programming can be advertised from the central controller to the 131 client nodes through BGP extensions to the ingress PEs. When client 132 nodes receives the result of MPLS path programming, it will install 133 the MPLS forwarding entry for the specified BGP prefix to implement 134 the service process. 136 +-------------------+ 137 | Central | 138 | Controller | 139 |----------|(Path Calculation |--------| 140 | | /Path Programming)| | 141 | +-------------------+ | 142 | | 143 MPLS Path MPLS Path 144 | | 145 | | 146 | | 147 +--------+ +--------+ +--------+ 148 | CLIENT | | CLIENT | | CLIENT | 149 | | ...... | | ...... | | 150 | (PE) | | (P) | | (PE) | 151 | | | | | | 152 +--------+ +--------+ +--------+ 154 Figure 1 BGP-based MPLS Path Programming 156 3.2. Usecases 158 3.2.1. Deterministic ECMP 160 Entropy Label[RFC6790] is introduced to improve the ECMP capability 161 by encapsulate the entropy label in the MPLS label stack. The 162 existing implementation is always to calculate the entropy label 163 based on the header of packets by specific hash algorithm in the 164 ingress node. That is, the entropy label is determined locally by 165 the ingress node. The method can improve the hash of packets in the 166 network for load-sharing. But since the ingress node lacks the 167 knowledge of the global traffic pattern of the network and calculates 168 the entropy label by itself it may be not able to improve the ECMP 169 capability accurately and in some cases it may deteriorate the 170 imbalance of load-sharing. 172 With the central controlled MPLS path programming, the central 173 controller can collect the global traffic pattern information of the 174 network and based on the information deterministically calculate the 175 entropy label for specific flows to help improve the load-sharing of 176 the network. Then the central controller can download the label 177 stack information with the deterministic entropy label to the ingress 178 PEs for the specific BGP prefix. The ingress node can install the 179 MPLS forwarding entry shown in the following figure to help optimize 180 the ECMP of the flow specified by the BGP prefix, then optimize the 181 ECMP of the whole network. 183 +----------+ +----------+----------+ 184 | BGP | ---> | Entropy |BGP Prefix| ---> Transport 185 | Prefix | | Label | Label | Tunnel 186 +----------+ +----------+----------+ 188 3.2.2. Centralized Mapping of Service to Tunnels 190 In the network there can be multiple tunnels to one specific 191 destination which satisfy different constraints. In the traditional 192 way, the tunnel is set up by the distributed forwarding nodes. As 193 the PCE-initiated LSP setup [I-D.ietf-pce-pce-initiated-lsp]is 194 introduced, the tunnel with different constraints can be set up in 195 the central controlled way. In order to satisfy different service 196 requirements, it is necessary to provide the capability to flexibly 197 map the service to different tunnels which constraints can satisfy 198 the required service requirement. Since the central controller has 199 enough information of the whole network view, it can be an effective 200 way to map the service (such as L3VPN and L2VPN) to the tunnel by the 201 central controller and advertise the mapping information to the 202 ingress PE of the service to guide the mapping in the forwarding 203 node. 205 There can be two types of behaviors to map service to the tunnel: 207 1. Specify the tunnel type: with the method BGP will carry the 208 tunnel type information for the BGP prefix. When the ingress PE 209 receives the information, it will use the tunnel type and the nexthop 210 address (or other specified target IP address) to search the 211 corresponding tunnels to bear the flow specified by the BGP prefix. 212 If there are more than one tunnels, the ingress PE will load share 213 the traffic across all the tunnels. 215 2. Specify the specific tunnel: For MPLS TE/SR-TE tunnel, there can 216 be multiple MPLS TE tunnels from one ingress PE to a specific 217 destination with different constraints. BGP can carry the tunnel 218 identifier information for the BGP prefix from the controller to the 219 ingress node. When the ingress PE receives the information, it will 220 use the tunnel identifier information to search the corresponding 221 tunnels to bear the flow specified by the BGP prefix. If there are 222 multiple tunnel identifiers, the ingress PE will load share the 223 traffic across all the tunnels. 225 4. Download of MPLS Path 227 According to the service requirements, the central controller can 228 combine MPLS labels flexibly. Then it can download the service label 229 combination for specific prefix.BGP extensions are necessary to 230 advertise label stacks for the prefix in NLRI field. 232 +---------------------------+ 233 | Length (1 octet) | 234 +---------------------------+ 235 | Label (3 octets) | 236 +---------------------------+ 237 ............................. 238 +---------------------------+ 239 | Prefix (variable) | 240 +---------------------------+ 241 Figure 1: NLRI Definition in RFC3107 243 [RFC3107] defines above NLRI to advertise label binding for specific 244 prefix. The label field can carry one or more labels. Each label is 245 encoded as 3 octets, where the high-order 20 bits contain the label 246 value, and the low order bit contains "Bottom of Stack". But for 247 other AFI/SAFIs using label binding such as VPNv4, VPNv6, EVPN, MVPN, 248 etc., it dose not support the capability to carry more labels for the 249 specific prefix. Moreover for the AFI/SAFIs which do not support 250 label binding capability originally, but may possibly adopt MPLS path 251 programming now, there is no label field in the NLRI. In order to 252 support flexible MPLS path programming, this document defines and 253 uses a new BGP attribute called the "Extended Label attribute". This 254 is an optional transitive BGP attribute. The format of this 255 attribute is defined as follows: 257 +---------------------------+ 258 | Label 1 (3 octets) | 259 +---------------------------+ 260 | Label 2 (3 octets) | 261 +---------------------------+ 262 ............................. 263 +---------------------------+ 264 | Label n (3 octets) | 265 +---------------------------+ 266 Figure 2: Extended Label Attribute 268 The Label field carries one or more labels (that corresponds to the 269 stack of labels [[RFC3032]]). Each label is encoded as 3 octets, 270 where the high-order 20 bits contain the label value, and the low 271 order bit contains "Bottom of Stack" (as defined in [[RFC3032]]). 273 The central controller for MPLS path programming could build a route 274 with Extended Label attribute and send it to the ingress routers. 276 Upon receiving such a route from the central Controller, the ingress 277 router SHOULD select such a route as the best path. If a packet 278 comes into the ingress router and uses such a path, the ingress 279 router will encapsulate the stack of labels which is derived from the 280 Extended Label Attribute of the route into the packet and forward the 281 packet along the path. 283 The "Extended Label attribute" can be used for various BGP address 284 families. Before using this attribute, firstly, it is necessary to 285 negotiate the capability between two nodes to support MPLS path 286 programming for a specific BGP address family. If negotiation fails, 287 a node MUST NOT send this attribute and MUST discard this attribute 288 when it receives. 290 5. Download of Mapping of Service Path to Transport Path 292 5.1. Specify Tunnel Type 294 [I-D.ietf-idr-tunnel-encaps] proposes the Tunnel Encapsulation 295 Attribute which can be used without BGP Encapsulation SAFI to specify 296 a set of tunnels. It defines a series of Encapsulation Sub-TLVs for 297 particular tunnel types. It also defines the Remote Endpoint 298 Attributes Sub-TLV to specify the remote tunnel endpoint address for 299 each tunnel which can be different the BGP nexthop. The Tunnel 300 Encapsulation Attributes can be reused for the MPLS path programming 301 to specify the tunnel types, the encapsulation and the remote tunnel 302 endpoint address which can determine a set of tunnels which the 303 service can map to. Now the limited MPLS tunnel types are defined 304 for the Tunnel Encapsulation Attributes. In order to support MPLS 305 path programming, the following MPLS tunnel types are to be defined: 307 Value Tunnel Type 308 ------- --------------------------------------------------- 309 TBD LDP LSP 310 TBD RSVP-TE LSP 311 TBD MPLS-based Segment Routing Best-effort Path 312 TBD MPLS-based Segment Routing Traffic Engineering Path 314 5.2. Specify Specific Tunnel 316 Besides specifying the tunnel types to determine the set of tunnels 317 which the service traffic can map to, the specific tunnels can be 318 specified directly by the tunnel identifiers when map the service 319 traffic to the path. BGP extensions is necessary that through the 320 community attribute of BGP the identifier of the transport path can 321 be carried when advertise the specific prefix. 323 In order to support the application, this document defines a new BGP 324 attribute called the "Extended Unicast Tunnel attribute". This is an 325 optional transitive BGP attribute. The format of this attribute is 326 defined as follows: 328 +------------------------------------------------+ 329 | Flags (1 octet) | 330 +------------------------------------------------+ 331 | Tunnel Type (1 octets) | 332 +------------------------------------------------+ 333 | Tunnel Identifier (variable) | 334 +------------------------------------------------+ 336 The Flags is reserved and must be set as zero. The Tunnel Type 337 identifies the type of the tunneling technology used for the unicast 338 service path. The tunnel type determines the syntax and semantics of 339 the Tunnel Identifier field. This document defines following Tunnel 340 Types: 342 + 0 - No tunnel information present 343 + 1 - RSVP-TE LSP 344 + 2 - MPLS-based Segment Routing Traffic Engineering Path 346 Tunnel Specific Attributes contains the attributes of the tunnel. 347 The field is optional. The value depends on the tunnel type. It 348 will be defined in the future versions. 350 When the Tunnel Type is set to "No tunnel information present", the 351 Tunnel attribute carries no tunnel information (no Tunnel 352 Identifier). when the type is used, the tunnel used for the service 353 path is determined by the ingress router. 355 When the Tunnel Type is set to RSVP - Traffic Engineering (RSVP-TE) 356 Label Switched Path (LSP), the Tunnel Identifier is as specified in 358 [RFC3209] If C-Type = 7, Tunnel Sender Address and Tunnel End-point 359 Address are IPv4 address in 4 octets. If C-Type = 8, Tunnel Sender 360 Address and Tunnel End-point Address are IPv6 address in 16 octets. 361 The other fields in the RSVP-TE LSP Identifier are the same as 362 specified in [RFC3209]. 364 When the Tunnel Type is set to MPLS-based Segment Routing Traffic 365 Engineering Path, the Tunnel Identifier is . If C-Type = 7, Tunnel 367 Sender Address and Tunnel End-point Address are IPv4 address in 4 368 octets. If C-Type = 8, Tunnel Sender Address and Tunnel End-point 369 Address are IPv6 address in 16 octets. The tunnel identifier is 370 similar as that of RSVP-TE LSP. 372 BGP can carry multiple Extended Unicast Tunnel Attributes for 373 specific prefix. If there are multiple tunnel identifiers, the 374 ingress PE will load share the traffic across all the specified 375 tunnels for the service traffic determined by the specific BGP 376 prefix. 378 6. Route Flag Extended Community 380 In order to make the MPLS path programming to take effect, the route 381 advertised by the central controller after the MPLS Path Programming 382 should be selected by the ingress PE over other routes for the same 383 BGP prefix. There are two options of BGP extensions for the purpose: 385 Option 1: A new BGP Extended Community called as the "Route Flag 386 Extended Community" can be introduced. The Type value is to be 387 assigned by IANA. 389 The Route Flag Extended Community is used to carry the flag appointed 390 by the BGP central controller. 392 The format of this extended community is defined as follows: 394 0 1 2 3 4 5 6 7 395 +-----+-----+-----+-----+-----+-----+-----+-----+ 396 | Type | Reserved |Flag | 397 +-----+-----+-----+-----+-----+-----+-----+-----+ 399 Flag = 0, Treat as normal route 400 Flag = 1, Treat as best route 402 When a router receives a BGP route with a Route Flag Extended 403 Community and the Flag set to "1", it SHOULD use the route as the 404 best route when select the route from multiple routes for a specific 405 prefix. 407 Option 2: [I-D.ietf-idr-custom-decision] defines a new Extended 408 Community, called the Cost Community, which can be used in tie 409 breaking during the best path selection process. The Cost Community 410 can be reused by the MPLS path programming to set the "Point of 411 Insertion" as 128 to make the route advertised by the central 412 controller to be chosen. 414 7. Destination Node Attribute 416 This document defines and uses a new BGP attribute called as the 417 "Destination Node attribute" which Type value is to be assigned by 418 IANA. The Destination Node attribute is an optional non-transitive 419 attribute that can be applied to any address family. 421 The Destination Node attribute is used to carry a list of node 422 addresses, which are intended to be used to determine the nodes where 423 the route with such attribute SHOULD be considered. If a node 424 receives a BGP route with a Destination Node attribute, it MUST check 425 the node address list. If one address of the list belongs to this 426 node, the route MUST be used in this node. Otherwise the route MUST 427 be ignored silently. 429 The format of this attribute is defined as follows: 431 0 1 2 3 432 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | AFI | SAFI | Reserved | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 ~ ~ 437 ~ Destination Node Address List ~ 438 ~ ~ 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 AFI: Address Family Identifier (16 bits). 443 SAFI: Subsequent Address Family Identifier (8 bits). 445 Reserved: One octet reserved for special flags 447 Destination Node Address List: The list of IPv4 (AFI=1) or IPv6 448 (AFI=2) address. 450 8. Capability Negotiation 452 It is necessary to negotiate the capability to support MPLS path 453 programming. The MPLS-Path-Programming Capability is a new BGP 454 capability [RFC5492]. The Capability Code for this capability is to 455 be specified by the IANA. The Capability Length field of this 456 capability is variable. The Capability Value field consists of one 457 or more of the following tuples: 459 +--------------------------------------------------+ 460 | Address Family Identifier (2 octets) | 461 +--------------------------------------------------+ 462 | Subsequent Address Family Identifier (1 octet) | 463 +--------------------------------------------------+ 464 | Send/Receive (1 octet) | 465 +--------------------------------------------------+ 467 The meaning and use of the fields are as follows: 469 Address Family Identifier (AFI): This field is the same as the one 470 used in [RFC4760]. 472 Subsequent Address Family Identifier (SAFI): This field is the same 473 as the one used in [RFC4760]. 475 Send/Receive: This field indicates whether the sender is (a) willing 476 to receive programming MPLS paths from its peer (value 1), (b) would 477 like to send programming MPLS paths to its peer (value 2), or (c) 478 both (value 3) for the . 480 9. IANA Considerations 482 TBD. 484 10. Security Considerations 486 TBD. 488 11. References 490 11.1. Normative References 492 [I-D.ietf-idr-custom-decision] 493 Retana, A. and R. White, "BGP Custom Decision Process", 494 draft-ietf-idr-custom-decision-06 (work in progress), 495 April 2015. 497 [I-D.ietf-idr-tunnel-encaps] 498 Rosen, E., Patel, K., and G. Velde, "Using the BGP Tunnel 499 Encapsulation Attribute without the BGP Encapsulation 500 SAFI", draft-ietf-idr-tunnel-encaps-00 (work in progress), 501 August 2015. 503 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 504 Requirement Levels", BCP 14, RFC 2119, 505 DOI 10.17487/RFC2119, March 1997, 506 . 508 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 509 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 510 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 511 . 513 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 514 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 515 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 516 . 518 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 519 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 520 DOI 10.17487/RFC4271, January 2006, 521 . 523 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 524 "Multiprotocol Extensions for BGP-4", RFC 4760, 525 DOI 10.17487/RFC4760, January 2007, 526 . 528 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 529 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 530 October 2007, . 532 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 533 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 534 2009, . 536 11.2. Informative References 538 [I-D.ietf-pce-pce-initiated-lsp] 539 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 540 Extensions for PCE-initiated LSP Setup in a Stateful PCE 541 Model", draft-ietf-pce-pce-initiated-lsp-04 (work in 542 progress), April 2015. 544 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 545 BGP-4", RFC 3107, DOI 10.17487/RFC3107, May 2001, 546 . 548 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 549 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 550 RFC 6790, DOI 10.17487/RFC6790, November 2012, 551 . 553 Authors' Addresses 555 Zhenbin Li 556 Huawei Technologies 557 Huawei Bld., No.156 Beiqing Rd. 558 Beijing 100095 559 China 561 Email: lizhenbin@huawei.com 563 Shunwan Zhuang 564 Huawei Technologies 565 Huawei Bld., No.156 Beiqing Rd. 566 Beijing 100095 567 China 569 Email: zhuangshunwan@huawei.com 571 Sujian Lu 572 Tencent 573 Tengyun Building,Tower A ,No. 397 Tianlin Road,Xuhui District 574 Shanghai 200233 575 China 577 Email: jasonlu@tencent.com