idnits 2.17.1 draft-ietf-anima-prefix-management-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 502: '... It is RECOMMENDED that DHCPv6 PD, i...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 11, 2016) is 3028 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-11) exists of draft-greevenbosch-appsawg-cbor-cddl-07 == Outdated reference: A later version (-30) exists of draft-ietf-anima-autonomic-control-plane-01 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-01 == Outdated reference: A later version (-15) exists of draft-ietf-anima-grasp-01 ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ANIMA WG S. Jiang, Ed. 3 Internet-Draft Z. Du 4 Intended status: Informational Huawei Technologies Co., Ltd 5 Expires: July 14, 2016 B. Carpenter 6 Univ. of Auckland 7 Q. Sun 8 China Telecom 9 January 11, 2016 11 Autonomic IPv6 Edge Prefix Management in Large-scale Networks 12 draft-ietf-anima-prefix-management-00 14 Abstract 16 This document describes an autonomic solution for IPv6 prefix 17 management at the edge of large-scale ISP networks. An important 18 purpose of the document is to use it for validation of the design of 19 various components of the autonomic networking infrastructure. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on July 14, 2016. 38 Copyright Notice 40 Copyright (c) 2016 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 58 3.1. Intended User and Administrator Experience . . . . . . . 4 59 3.2. Analysis of Parameters and Information Involved . . . . . 4 60 3.2.1. Parameters each device can decide for itself . . . . 5 61 3.2.2. Information needed from policy intent . . . . . . . . 5 62 3.2.3. Comparison with current solutions . . . . . . . . . . 5 63 3.3. Interaction with other devices . . . . . . . . . . . . . 6 64 3.3.1. Information needed from other devices . . . . . . . . 6 65 3.3.2. Monitoring, diagnostics and reporting . . . . . . . . 6 66 4. Autonomic Edge Prefix Management Solution . . . . . . . . . . 7 67 4.1. Behaviors on prefix requesting device . . . . . . . . . . 7 68 4.2. Behaviors on prefix providing device . . . . . . . . . . 8 69 4.3. Behavior after Successful Negotiation . . . . . . . . . . 9 70 4.4. Prefix logging . . . . . . . . . . . . . . . . . . . . . 9 71 5. Autonomic Prefix Management Options . . . . . . . . . . . . . 9 72 5.1. Edge Prefix Objective Option . . . . . . . . . . . . . . 9 73 6. Prefix Management Intent . . . . . . . . . . . . . . . . . . 10 74 6.1. Example of Prefix Management Intent . . . . . . . . . . . 10 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 76 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 77 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 78 10. Change log [RFC Editor: Please remove] . . . . . . . . . . . 12 79 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 81 11.2. Informative References . . . . . . . . . . . . . . . . . 13 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 84 1. Introduction 86 This document proposes an autonomic solution for IPv6 prefix 87 management in large-scale networks. The background to Autonomic 88 Networking (AN) is described in [RFC7575] and [RFC7576]. A generic 89 autonomic signaling protocol (GRASP) is specified by 90 [I-D.ietf-anima-grasp] and would be used by the proposed autonomic 91 prefix management solution. An important purpose of the present 92 document is to use it for validation of the design of GRASP and other 93 components of the autonomic networking infrastructure described in 94 [I-D.behringer-anima-reference-model]. 96 This document is not intended to solve all cases of IPv6 prefix 97 management. In fact, it assumes that the network's main 98 infrastructure elements already have addresses and prefixes. The 99 document is dedicated to how to make IPv6 prefix management at the 100 edges of large-scale networks as autonomic as possible. It is 101 specifically written for service provider (ISP) networks. Although 102 there are similarities between ISPs and large enterprise networks, 103 the requirements for the two use cases differ. 105 However, the solution is designed in a general way. Its use for a 106 broader scope than edge prefixes, including some or all 107 infrastructure prefixes, is left for future discussion. 109 Note in draft: This version is preliminary. In particular, many 110 design details may be subject to change until the Anima 111 specifications become agreed. 113 2. Terminology 115 TBD 117 3. Problem Statement 119 The autonomic networking use case considered here is autonomic IPv6 120 prefix management at the edge of large-scale ISP networks. 122 Although DHCPv6 Prefix Delegation [RFC3633] supports automated 123 delegation of IPv6 prefixes from one router to another, prefix 124 management is still largely depending on human planning. In other 125 words, there is no basic information or policy to support autonomic 126 decisions on the prefix length that each router should request or be 127 delegated, according to its role in the network. Roles could be 128 locally defined or could be generic (edge router, interior router, 129 etc.). Furthermore, IPv6 prefix management by humans tends to be 130 rigid and static after initial planning. 132 The problem to be solved by autonomic networking is how to 133 dynamically manage IPv6 address space in large-scale networks, so 134 that IPv6 addresses can be used efficiently. Here, we limit the 135 problem to assignment of prefixes at the edge of the network, close 136 to access routers that support individual fixed-line subscribers, 137 mobile customers, and corporate customers. We assume that the core 138 infrastructure of the network has already been established with 139 appropriately assigned prefixes. The AN approach discussed in this 140 document is based on the assumption that there is a generic discovery 141 and negotiation protocol that enables direct negotiation between 142 intelligent IP routers. GRASP [I-D.ietf-anima-grasp] is intended to 143 be such a protocol. 145 3.1. Intended User and Administrator Experience 147 The intended experience is, for the administrator(s) of a large-scale 148 network, that the management of IPv6 address space at the edge of the 149 network can be run with minimum efforts, as devices at the edge are 150 added and removed and as customers of all kinds join and leave the 151 network. In the ideal scenario, the administrator(s) only have to 152 specify a single IPv6 prefix for the whole network and the initial 153 prefix length for each device role. As far as users are concerned, 154 IPv6 prefix assignment would occur exactly as it does in any other 155 network. 157 The actual prefix usage needs to be logged for potential offline 158 management operations including audit and security incident tracing. 160 3.2. Analysis of Parameters and Information Involved 162 For specific purposes of address management, a few parameters are 163 involved on each edge device (some of them can be pre-configured 164 before they are connected). They include: 166 o Identity, authentication and authorization of this device. This 167 is expected to use the autonomic networking secure bootstrap 168 process [I-D.ietf-anima-bootstrapping-keyinfra], following which 169 the device could safely take part in autonomic operations. 171 o Role of this device. 173 o An IPv6 prefix length for this device. 175 o An IPv6 prefix that is assigned to this device and its downstream 176 devices. 178 A few parameters are involved in the network as a whole. They are: 180 o Identity of a trust anchor, which is a certification authority 181 (CA) maintained by the network administrator(s), used during the 182 secure bootstrap process. 184 o Total IPv6 address space available for edge devices. It is one 185 (or several) IPv6 prefix(es). 187 o The initial prefix length for each device role. 189 3.2.1. Parameters each device can decide for itself 191 This section identifies those of the above parameters that do not 192 need external information in order for the devices concerned to set 193 them to a reasonable value after bootstrap or after a network 194 disruption. There are few of these: 196 o Role of this device. 198 o Default IPv6 prefix length for this device. 200 o Identity of this device. 202 The device may be shipped from the manufacturer with pre-configured 203 role and default prefix length, which could be modified by an 204 autonomic mechanism. 206 3.2.2. Information needed from policy intent 208 This section identifies those parameters that need external 209 information about policy intent in order for the devices concerned to 210 set them to a non-default value. 212 o Non-default value for the IPv6 prefix length for this device. 213 This needs to be decided based on the role of this device. 215 o The initial prefix length for each device role. 217 o Whether to allow the device request more address space. 219 o The policy when to request more address space, for example, if the 220 address usage reaches a certain limit or percentage. 222 3.2.3. Comparison with current solutions 224 This section briefly compares the above use case with current 225 solutions. Currently, the address management is still largely 226 dependent on human planning. It is rigid and static after initial 227 planning. Address requests will fail if the configured address space 228 is used up. 230 Some autonomic and dynamic address management functions may be 231 achievable by extending the existing protocols, for example, 232 extending DHCPv6-PD to request IPv6 prefixes according to the device 233 role. However, defining uniform device roles may not be a practical 234 task. Some functions are not suitable to be achieved by any existing 235 protocols. 237 Using a generic autonomic discovery and negotiation protocol instead 238 of specific solutions has the advantage that additional parameters 239 can be included in the autonomic solution without creating new 240 mechanisms. This is the principal argument for a generic approach. 242 3.3. Interaction with other devices 244 3.3.1. Information needed from other devices 246 This section identifies those of the above parameters that need 247 external information from neighbor devices (including the upstream 248 devices). In many cases, two-way dialogue with neighbor devices is 249 needed to set or optimize them. 251 o Identity of a trust anchor. 253 o The device will need to discover a device, from which it can 254 acquire IPv6 address space. 256 o The initial prefix length for each device role, particularly for 257 its own downstream devices. 259 o The default value of the IPv6 prefix length may be overridden by a 260 non-default value. 262 o The device will need to request and acquire IPv6 prefix that is 263 assigned to this device and its downstream devices. 265 o The device may respond to prefix delegation request from its 266 downstream devices. 268 o The device may require to be assigned more IPv6 address space, if 269 it used up its assigned IPv6 address space. 271 3.3.2. Monitoring, diagnostics and reporting 273 This section discusses what role devices should play in monitoring, 274 fault diagnosis, and reporting. 276 o The actual address assignments need to be logged for the potential 277 offline management operations. 279 o In general, the usage situation of address space should be 280 reported to the network administrators, in an abstract way, for 281 example, statistics or visualized report. 283 o A forecast of address exhaustion should be reported. 285 4. Autonomic Edge Prefix Management Solution 287 This section introduces an autonomic edge prefix management solution. 288 It uses the generic discovery and negotiation protocol defined by 289 [I-D.ietf-anima-grasp]. The relevant options are defined in 290 Section 5. 292 The procedures described below are carried out by an Autonomic 293 Service Agent (ASA) in each device that participates in the solution. 294 We will refer to this as the PrefixManager ASA. 296 4.1. Behaviors on prefix requesting device 298 If the device containing an PrefixManager ASA has used up its address 299 pool, it can request more space according to its requirements. It 300 should decide the length of the requested prefix by the intent-based 301 mechanism, described in Section 6. 303 An PrefixManager ASA that needs additional address space should 304 firstly discover peers that may be able to provide extra address 305 space. The ASA should send out a GRASP Discovery message that 306 contains an PrefixManager Objective option Section 5.1 in order to 307 discover peers also supporting that option. Then it should choose 308 one such peer, most likely the first to respond. 310 If the GRASP discovery Response message carries a divert option 311 pointing to an off-link PrefixManager ASA, the requesting ASA may 312 initiate negotiation with that ASA diverted device to find out 313 whether it can provide the requested length prefix. 315 In any case, the requesting ASA will act as a GRASP negotiation 316 initiator by sending a GRASP Request message with an PrefixManager 317 Objective option. The ASA indicates in this option both the length 318 of the requested prefix and whether the ASA supports the DHCPv6 319 Prefix Delegation (PD) function [RFC3633]. This starts a GRASP 320 negotiation process. 322 During the subsequent negotiation, the ASA will decide at each step 323 whether to accept the offered prefix. That decision, and the 324 decision to end negotiation, is an implementation choice. 326 The ASA could alternatively initiate rapid mode GRASP discovery with 327 an embedded negotiation request, if it is implemented. 329 4.2. Behaviors on prefix providing device 331 A device that receives a Discovery message with an PrefixManager 332 Objective option should respond with a GRASP Response message if it 333 contains an PrefixManager ASA. Further details of the discovery 334 process are described in [I-D.ietf-anima-grasp]. When this ASA 335 receives a subsequent Request message it should conduct a GRASP 336 negotiation sequence, using Negotiate, Confirm-waiting, and 337 Negotiation-ending messages as appropriate. The Negotiate messages 338 carry an PrefixManager Objective option. This will indicate whether 339 the sending device supports the PD function. More importantly, it 340 will indicate the prefix and its length offered to the requesting 341 ASA. As described in [I-D.ietf-anima-grasp], negotiation will 342 continue until either end stops it with a Negotiation-ending message. 343 If the negotiation succeeds, the prefix providing ASA will remove the 344 negotiated prefix from its pool, and the requesting ASA will add it. 345 If the negotiation fails, the party sending the Negotiation-ending 346 message may include an error code string. 348 During the negotiation, the ASA will decide at each step how large a 349 prefix to offer. That decision, and the decision to end negotiation, 350 is an implementation choice. 352 The ASA could alternatively negotiate in response to rapid mode GRASP 353 discovery, if it is implemented. 355 This specification is independent of whether the PrefixManager ASAs 356 are all embedded in routers, but that would be a rather natural 357 scenario. A gateway router in a hierarchical network topology 358 normally provides prefixes for routers within its subnet, and it is 359 likely to contain the first PrefixManager ASA discovered by its 360 downstream routers. However, the GRASP discovery model, including 361 its Redirect feature, means that this is not an exclusive scenario, 362 and a downstream PrefixManager ASA could negotiate a new prefix with 363 a router other than its upstream router. 365 A resource shortage may cause the gateway router to request more 366 resource in turn from its own upstream device. This would be another 367 independent GRASP discovery and negotiation process. During the 368 processing time, the gateway router should send a Confirm-waiting 369 Message to the initial requesting router, to extend its timeout. 370 When the new resource becomes available, the gateway router responds 371 with a GRASP Negotiate message with a prefix length matching the 372 request. 374 The algorithm to choose which prefixes to assign on the prefix 375 providing devices is an implementation choice. 377 4.3. Behavior after Successful Negotiation 379 Upon receiving a GRASP Negotiation-ending message that indicates that 380 an acceptable prefix length is available, the requesting device may 381 request the prefix using DHCPv6 PD, if both ASAs have indicated that 382 they are within a device that supports PD. Otherwise, it is 383 permissible for the initiating ASA to use the negotiated prefix 384 without further messages. 386 [Author's note: It is not intended to undermine DHCPv6 PD. But in 387 fact, if PD is not supported and the GRASP negotiation has succeeded, 388 there should be no problem with this and it seems consistent as a 389 solution.] 391 4.4. Prefix logging 393 Within the autonomic prefix management, all the prefix assignment is 394 done by devices without human intervention. It is therefore 395 important to record all the prefix assignment history. However, the 396 logging and reporting process is out of scope for this specification. 398 5. Autonomic Prefix Management Options 400 This section defines the GRASP options that are used to support 401 autonomic prefix management. 403 5.1. Edge Prefix Objective Option 405 The PrefixManager Objective option is a GRASP objective option 406 conforming to [I-D.ietf-anima-grasp]. Its name is "PrefixManager" 407 (see Section 8) and it carries up to three data items as its value: 408 the PD support flag, the prefix length, and the actual prefix bits. 409 The format of the PrefixManager Objective option is described as 410 follows in CBOR data definition language (CDDL) 411 [I-D.greevenbosch-appsawg-cbor-cddl]: 413 objective = ["PrefixManager", objective-flags, loop-count, 414 PD-support, length, ?prefix] 416 loop-count = 0..255 ; as in the GRASP specification 417 objective-flags /= ; as in the GRASP specification 418 PD-support = true / false ; indicates whether sender supports PD 419 length = 0..128 ; requested or offered prefix length 420 prefix = bytes .size 16 ; offered prefix in binary format 422 6. Prefix Management Intent 424 With in a single administrative domain, the network operator could 425 provide intent for all devices with a certain role. Thus it would be 426 possible to apply an intended policy for every device in a simple 427 way, without human intervention or configuration files. 429 For example, the network operator could define the default prefix 430 length for each type of role. A prefix management intent, which 431 contains all mapping information of device roles and their default 432 prefix lengths, should be flooded in the network, through the 433 Autonomic Control Plane (ACP) 434 [I-D.ietf-anima-autonomic-control-plane]. The intent flooding 435 mechanism is not yet defined, but one possibility would be define a 436 suitable GRASP synchronization objective and flood it through the 437 network. To make this concrete, there could be an objective defined 438 as follows: 440 objective = ["Intent.PrefixManager", objective-flags, text] 442 loop-count = 0..255 ; as in the GRASP specification 443 objective-flags /= ; as in the GRASP specification 445 ;The text object would be the relevant intent statements (such 446 ;as the example below) transmitted as a single string with all 447 ;whitespace and format characters removed. 449 This could be flooded to all nodes, and any PrefixManager ASA that 450 did not receive it for some reason could obtain a copy using GRASP 451 synchronization. Upon receiving the prefix management intent, every 452 device can decide its default prefix length by matching its own role. 454 6.1. Example of Prefix Management Intent 456 The prefix management intent in this document is used to carry 457 mapping information of device roles and their default prefix lengths 458 in an autonomic domain. For example, an IPRAN operator wants to 459 configure the prefix length of RNC Site Gateway (RSG) as 34, the 460 prefix length of Aggregation Site Gateway (ASG) as 44, and the prefix 461 length of Cell Site Gateway (CSG) as 56. She/he may input the 462 following intent into the autonomic network: 464 {"autonomic_intent": 465 [ 466 {"model_version": "1.0"}, 467 {"intent_type": "Network management"}, 468 {"autonomic_domain": "Customer_X_intranet"}, 469 {"intent_name": "Prefix management"}, 470 {"intent_version": 73}, 471 {"Timestamp": "20150606 00:00:00"}, 472 {"Lifetime": "Permanent"}, 473 {"signature": "XXXXXXXXXXXXXXXXXXX"}, 474 {"content": 475 [ 476 {"role": [{"role_name": "RSG"}, 477 {"role_characteristic": 478 [{"prefix_length": "34"}]} 479 ]}, 480 {"role": [{"role_name": "ASG"}, 481 {"role_characteristic": 482 [{"prefix_length": "44"}]} 483 ]}, 484 {"role": [{"role_name": "CSG"}, 485 {"role_characteristic": 486 [{"prefix_length": "56"}]} 487 ]} 488 ] 489 } 490 ] 491 } 493 7. Security Considerations 495 Relevant security issues are discussed in [I-D.ietf-anima-grasp]. 496 The preferred security model is that devices are trusted following 497 the secure bootstrap procedure 498 [I-D.ietf-anima-bootstrapping-keyinfra] and that a secure Autonomic 499 Control Plane (ACP) [I-D.ietf-anima-autonomic-control-plane] is in 500 place. 502 It is RECOMMENDED that DHCPv6 PD, if used, should be operated using 503 DHCPv6 authentication or Secure DHCPv6. 505 8. IANA Considerations 507 This document defines one new GRASP Objective Option name, 508 "PrefixManager". The IANA is requested to add this to the GRASP 509 Objective Names Table registry defined by [I-D.ietf-anima-grasp] (if 510 approved). 512 9. Acknowledgements 514 Valuable comments were received from Michael Behringer, Joel Halpern, 515 and Chongfeng Xie. 517 This document was produced using the xml2rfc tool [RFC2629]. 519 10. Change log [RFC Editor: Please remove] 521 draft-jiang-anima-prefix-management-00: original version, 2014-10-25. 523 draft-jiang-anima-prefix-management-01: add intent example and 524 coauthor Zongpeng Du, 2015-05-04. 526 draft-jiang-anima-prefix-management-02: update references and the 527 format of the prefix management intent, 2015-10-14. 529 draft-ietf-anima-prefix-management-00: WG adoption, clarify scope and 530 purpose, update text to match latest GRASP spec, 2016-01-11. 532 11. References 534 11.1. Normative References 536 [I-D.greevenbosch-appsawg-cbor-cddl] 537 Vigano, C. and H. Birkholz, "CBOR data definition language 538 (CDDL): a notational convention to express CBOR data 539 structures", draft-greevenbosch-appsawg-cbor-cddl-07 (work 540 in progress), October 2015. 542 [I-D.ietf-anima-autonomic-control-plane] 543 Behringer, M., Bjarnason, S., BL, B., and T. Eckert, "An 544 Autonomic Control Plane", draft-ietf-anima-autonomic- 545 control-plane-01 (work in progress), October 2015. 547 [I-D.ietf-anima-bootstrapping-keyinfra] 548 Pritikin, M., Richardson, M., Behringer, M., and S. 549 Bjarnason, "Bootstrapping Key Infrastructures", draft- 550 ietf-anima-bootstrapping-keyinfra-01 (work in progress), 551 October 2015. 553 [I-D.ietf-anima-grasp] 554 Bormann, C., Carpenter, B., and B. Liu, "A Generic 555 Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- 556 grasp-01 (work in progress), October 2015. 558 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 559 Host Configuration Protocol (DHCP) version 6", RFC 3633, 560 DOI 10.17487/RFC3633, December 2003, 561 . 563 11.2. Informative References 565 [I-D.behringer-anima-reference-model] 566 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 567 Liu, B., Jeff, J., and J. Strassner, "A Reference Model 568 for Autonomic Networking", draft-behringer-anima- 569 reference-model-04 (work in progress), October 2015. 571 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 572 DOI 10.17487/RFC2629, June 1999, 573 . 575 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 576 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 577 Networking: Definitions and Design Goals", RFC 7575, 578 DOI 10.17487/RFC7575, June 2015, 579 . 581 [RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap 582 Analysis for Autonomic Networking", RFC 7576, 583 DOI 10.17487/RFC7576, June 2015, 584 . 586 Authors' Addresses 588 Sheng Jiang (editor) 589 Huawei Technologies Co., Ltd 590 Q14, Huawei Campus, No.156 Beiqing Road 591 Hai-Dian District, Beijing, 100095 592 P.R. China 594 Email: jiangsheng@huawei.com 596 Zongpeng Du 597 Huawei Technologies Co., Ltd 598 Q14, Huawei Campus, No.156 Beiqing Road 599 Hai-Dian District, Beijing, 100095 600 P.R. China 602 Email: duzongpeng@huawei.com 603 Brian Carpenter 604 Department of Computer Science 605 University of Auckland 606 PB 92019 607 Auckland 1142 608 New Zealand 610 Email: brian.e.carpenter@gmail.com 612 Qiong Sun 613 China Telecom 614 No.118, Xizhimennei Street 615 Beijing 100035 616 P. R. China 618 Email: sunqiong@ctbri.com.cn