idnits 2.17.1 draft-ietf-6man-flow-update-01.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 (January 10, 2011) is 4849 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3697 (Obsoleted by RFC 6437) == Outdated reference: A later version (-03) exists of draft-gont-6man-flowlabel-security-01 == Outdated reference: A later version (-03) exists of draft-hu-flow-label-cases-02 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6MAN S. Amante 3 Internet-Draft Level 3 4 Intended status: Informational B. Carpenter 5 Expires: July 14, 2011 Univ. of Auckland 6 S. Jiang 7 Huawei Technologies Co., Ltd 8 January 10, 2011 10 Update to the IPv6 flow label specification 11 draft-ietf-6man-flow-update-01 13 Abstract 15 Various published proposals for use of the IPv6 flow label are 16 incompatible with its existing specification in RFC 3697. 17 Furthermore, very little practical use is made of the flow label, 18 partly due to some uncertainties about the correct interpretation of 19 the specification. This document describes and motivates proposed 20 changes to the specification in order to clarify it, making it clear 21 what types of usage are possible, and to introduce some additional 22 flexibility. It does not formally update RFC 3697. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on July 14, 2011. 41 Copyright Notice 43 Copyright (c) 2011 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Impact of current specification . . . . . . . . . . . . . . . 4 60 3. Normative Notation . . . . . . . . . . . . . . . . . . . . . . 6 61 4. Proposed changes to specification . . . . . . . . . . . . . . 6 62 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 64 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 65 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 66 9. Change log . . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 69 10.2. Informative References . . . . . . . . . . . . . . . . . 11 70 Appendix A. Alternative Approaches . . . . . . . . . . . . . . . 12 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 73 1. Introduction 75 The flow label field in the IPv6 header was reserved but left 76 experimental by [RFC2460], which mandates only that "Hosts or routers 77 that do not support the functions of the Flow Label field are 78 required to set the field to zero when originating a packet, pass the 79 field on unchanged when forwarding a packet, and ignore the field 80 when receiving a packet." 82 The flow label field was normatively specified by [RFC3697]. In 83 particular, we quote three rules from that RFC: 84 a. "The Flow Label value set by the source MUST be delivered 85 unchanged to the destination node(s)." 86 b. "IPv6 nodes MUST NOT assume any mathematical or other properties 87 of the Flow Label values assigned by source nodes." 88 c. "Router performance SHOULD NOT be dependent on the distribution 89 of the Flow Label values. Especially, the Flow Label bits alone 90 make poor material for a hash key." 92 Additionally, RFC 3697 leaves it undefined what method a host should 93 adopt by default to choose the value of the flow label, if no 94 specific method is in use. It was expected that various signalling 95 methods might be defined for agreeing on values of the flow label, 96 but no such methods have been standardised. 98 RFC 2460 mandates only that "Hosts or routers that do not support the 99 functions of the Flow Label field are required to set the field to 100 zero when originating a packet, pass the field on unchanged when 101 forwarding a packet, and ignore the field when receiving a packet." 103 The flow label is hardly used in practice in existing IPv6 104 implementations. To some extent this is due to the main focus being 105 on basic deployment of IPv6, but the absence of a default method of 106 choosing the flow label value means that most host implementations 107 simply set it to zero. There is also anecdotal evidence that the 108 rules quoted above have led to uncertainty about exactly what is 109 possible. Furthermore, various use cases have been proposed that 110 infringe one or another of the rules. None of these proposals has 111 been accepted as a standard and in practice there is no significant 112 deployment of any mechanism to set the flow label. 114 The intention of this document is to explain this in more detail and 115 to propose changes to RFC 3697 intended to remove the uncertainties 116 and encourage active usage of the flow label. It does not formally 117 update RFC 3697. 119 2. Impact of current specification 121 Rule (a) makes it impossible for the routing system to use the flow 122 label as any form of dynamic routing tag. This was a conscious 123 choice in the early design of IPv6 and there appears to be no 124 practical possibility of revisiting this choice at this stage in the 125 deployment of IPv6, which uses conventional routing mechanisms like 126 those used for IPv4. However, this rule also makes it impossible to 127 make any use at all of the flow label unless hosts choose to set it. 128 It also forbids clearing the flow label for security reasons. 130 This last point highlights the security properties, or rather the 131 lack of them, of the flow label. The flow label field is always 132 unprotected as it travels through the network, because there is no 133 IPv6 header checksum, and the flow label is not included in transport 134 pseudo-header checksums, nor in IPsec checksums. As a result, 135 intentional and malicious changes to its value cannot be detected. 136 Also, it could be used as a covert data channel, since apparently 137 pseudo-random flow label values could in fact consist of covert data. 138 If the flow label were to carry quality of service semantics, then 139 like the diffserv code point [RFC2474], it would not be intrinsically 140 trustworthy across domain boundaries. As a result, some security 141 specialists believe that flow labels should be cleared for safety. 142 These points must be considered when discussing the immutability of 143 the flow label across domain boundaries. 145 Rule (b) appears to forbid any usage in which the bits of the flow 146 label are encoded with a specific semantic meaning. If the word 147 "alone" is overlooked, rule (c) has sometimes been interpreted to 148 forbid the use of the flow label as part of a hash used by load 149 balancing mechanisms. 151 Both before and after these rules were laid down, a considerable 152 number of proposals for use of the flow label were published that 153 seem incompatible with them. Numerous examples and an analysis are 154 presented in [I-D.hu-flow-label-cases]. Those examples propose use 155 cases in which some or all of the following apply: 156 o The flow label may be changed by intermediate systems. 157 o It doesn't matter if the flow label is changed, because the 158 receiver doesn't use it. 159 o Some or all bits of the flow label are encoded: they have specific 160 meanings understood by routers and switches along the path. 161 o The encoding is related to the required quality of service, as 162 well as identifying a flow. 163 o The flow label is used to control forwarding or switching in some 164 way. 166 These proposals all require either some form of encoding of semantics 167 in the bits of the flow label, or the ability for routers to modify 168 the flow label, or both. Thus they appear to infringe the rules from 169 RFC 3697 quoted above. 171 We can conclude that a considerable number of researchers and 172 designers have been stymied by RFC 3697. On the other hand, some 173 other proposals discussed in [I-D.hu-flow-label-cases] appear to be 174 compatible with RFC 3697. Several are based on the originator of a 175 packet choosing a pseudo-random flow label for each flow, which is 176 one option suggested in RFC 3697. Thus, we can also conclude that 177 there is a useful role for this approach. 179 If our goal is for the flow label to be used in practice, the 180 conflict between the various approaches creates a dilemma. There 181 appear to be two major options: 182 1. Discourage locally defined use of the flow label. Strengthen RFC 183 3697 to say that hosts SHOULD set a pseudo-random label value, 184 which would clarify and limit its possible uses. In particular, 185 its use for load balancing would be encouraged. 186 2. Relax the rules to encourage locally defined use of the flow 187 label. This approach would make the flow label completely 188 mutable and would exclude use cases depending on strict end-to- 189 end immutability. It would encourage applications of a pseudo- 190 random flow label, such as load balancing, on a local basis, but 191 it would exclude end-to-end applications. 193 During 2010 there has been considerable debate about these options 194 and variants of them, with a variety of proposals in previous 195 versions of this document and in mailing list discussions. After 196 these discussions, there appears to be a view that simplicity should 197 prevail, and that complicated proposals such as defining quality of 198 service semantics in the flow label, or sub-dividing the flow label 199 field into smaller sub-fields, will not prove efficient or 200 deployable, especially in high speed routers. There is also a 201 clearly expressed view that using the flow label for various forms of 202 stateless load balancing is the best simple application for it. At 203 the same time, it is necessary to recognize that the strict 204 immutability rule has drawbacks as noted above. 206 Even under the rules of RFC 3697, the flow label is intrinsically 207 untrustworthy, because modifcations en route cannot be detected. For 208 this reason, even with the current strict immutability rule, 209 downstream nodes cannot rely on the value being unchanged. In this 210 sense, any use of the flow label must be viewed as an optimisation on 211 a best effort basis; a packet with a changed (or zero) flow label 212 value should never cause a hard failure. 214 The remainder of this document is in the form of a set of proposed 215 modifications to the standard, consistent with the points above and 216 written in normative form. It is suggested that if the proposal is 217 generally accepted, a revised version of RFC 3697 should be produced 218 including these changes. 220 3. Normative Notation 222 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 223 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 224 document are to be interpreted as described in [RFC2119]. 226 4. Proposed changes to specification 228 Although RFC 3697 requires the flow label to be delivered unchanged, 229 as noted above, it is not included in any transport layer pseudo- 230 header checksums nor in IPsec authentication [RFC4302]. Both RFC 231 2460 and RFC 3697 define the default flow label to be zero. At the 232 time of writing, this is the observed value in an overwhelming 233 proportion of IPv6 packets; neither operating systems nor 234 applications currently set it, and routers do not rely on it. Thus 235 there is no reason to expect operational difficulties if a careful 236 change is made to the rules of RFC 3697. 238 In particular, the facts that the label is not checksummed and rarely 239 used mean that the current strict immutability of the label can be 240 moderated without operational consequences. 242 The purposes of the proposed changes are to remove the uncertainties 243 left by RFC 3697, in order to encourage setting of the flow label by 244 default, and to enable its generic use. The proposed generic use is 245 to encourage pseudo-random flow labels that can be used to assist 246 load balancing. There should be no impact on existing IETF 247 specifications other than RFC 3697 and no impact on currently 248 operational software and hardware. 250 A secondary purpose is to modify the immutability of the flow label 251 in a limited way, to allow hosts that do not set the flow label to 252 benefit from it nevertheless. 254 The fact that the flow label may in practice be changed en route is 255 also reflected in the reformulation of the rules. 257 A description of the changes follows. They are written in normative 258 language to avoid ambiguity. They are mainly not written as specific 259 text changes to RFC 3697, and significant rewriting of the latter is 260 needed to incorporate these changes. 262 The definition of a flow is subtly changed from RFC 3697 as follows: 264 A flow is a sequence of packets sent from a particular source to a 265 particular unicast, anycast, or multicast destination that a node 266 desires to label as a flow. A flow could consist of all packets 267 in a specific transport connection or a media stream. However, a 268 flow is not necessarily 1:1 mapped to a transport connection. 270 The change is that the words 'the source' have been replaced by 'a 271 node'. Nodes that do not support the flow label remain subject to 272 RFC 2460. The intention is to enable the following new 273 specifications: 275 1. It is RECOMMENDED that source hosts support the flow label by 276 setting the flow label field for all packets of a flow to the 277 same pseudo-random value. 278 * This rule updates the less precise recommendation made in 279 Section 3 of RFC 3697. Both stateful and stateless methods of 280 assigning a pseudo-random value could be used, but it is 281 outside the scope of this specification to mandate an 282 algorithm. 283 * An OPTIONAL algorithm for generating such a pseudo-random 284 value is proposed in [I-D.gont-6man-flowlabel-security]. 285 * Section 3 of RFC 3697 also allows nodes to participate in an 286 unspecified method of flow state establishment. The changes 287 do not remove that option. 289 2. A node that forwards a flow whose flow label value in arriving 290 packets is zero MAY set the flow label value. In that case, it 291 is RECOMMENDED that the forwarding node sets the flow label field 292 for a flow to a pseudo-random value. 293 * The same considerations apply as to the first recommendation. 294 * This option, if implemented, would presumably be used by 295 ingress routers. It would place a considerable per-packet 296 processing load on them, even if they adopted a stateless 297 method of flow identification and label assignment. This is 298 why the principal recommendation is that the source host 299 should set the label. 301 3. A forwarding node MUST NOT change the flow label value in an 302 arriving packet if it is non-zero. However, there are two 303 qualifications to this rule: 304 1. Implementers are advised that forwarding nodes, especially 305 those acting as domain border devices, might nevertheless be 306 configured to change the flow label value in packets (e.g., 307 to a new pseudo-random value). This is undetectable, unless 308 some future version of IPsec authentication [RFC4302] 309 protects the flow label value. 311 2. To enable stateless load balancing at any point in the 312 Internet, a network domain MUST NOT forward packets outside 313 the domain whose flow label values are other than zero or 314 pseudo-random. Neither domain border egress routers nor 315 intermediate routers/devices (using a flow-label, for 316 example, as a part of an input-key for a load-balancing hash) 317 can determine by inspection that a value is not pseudo- 318 random. Therefore, if nodes within a domain ignore the above 319 recommendations to set zero or pseudo-random flow label 320 values, and such packets are forwarded outside the domain, 321 this would likely result in undesirable operational 322 implications (e.g., congestion, reordering) for not only the 323 inappropriately flow-labelled packets, but also well-behaved 324 flow-labelled packets, during forwarding at various 325 intermediate devices. Thus, a domain must protect its peers 326 by never exporting inappropriately labelled packets. This 327 document does not specify the method for enforcing this rule. 328 The suggested way to enforce it is that nodes within a domain 329 MUST NOT set the flow label to a non-zero and non-pseudo- 330 random number if the packet will leave the domain. If this 331 is not known to be the case, the border router will need to 332 change outgoing flow labels. 334 Note that the new rules above, taken together, allow a given 335 network domain to include routers that set flow labels on behalf 336 of hosts that do not do so. They also require that flow labels 337 exported to the Internet must always be either zero or pseudo- 338 random. These changes replace rule (a) quoted in Section 1. 339 However, there is no way to verify whether a flow label has been 340 modified en route. No Internet-wide mechanism can depend 341 mathematically on immutable flow labels. This leads to the 342 following formal rule: 344 4. IPv6 nodes MUST NOT assume that the Flow Label value in a 345 incoming packet is identical to the value set by the source node. 346 * This replaces rule (b) quoted in Section 1. 348 5. Forwarding nodes such as routers and load balancers MUST NOT 349 depend only on Flow Label values being randomly distributed. In 350 any usage such as a hash key for load balancing, the Flow Label 351 bits MUST be combined with bits from other sources within the 352 packet, so as to produce a suitable distribution of hash values. 353 * This replaces rule (c) quoted in Section 1. Although a 354 pseudo-random flow label is recommended, and will always be 355 helpful for load balancing, it is unsafe to assume its 356 presence in the general case, and the use case needs to work 357 even if the flow label value is zero. 359 5. Discussion 361 The following are the consequences of the above changes, taken 362 together with the unaffected parts of RFC 3697: 363 o Sending hosts that are not updated will in practice continue to 364 send all-zero labels. If there is no label-setting router along 365 the path taken by a packet, the label will be delivered as zero. 366 o Sending hosts conforming to this specification will by default 367 choose pseudo-random labels between 1 and 0xFFFFF. 368 o Sending hosts may continue to send all-zero labels, in which case 369 an ingress router may set pseudo-random labels between 1 and 370 0xFFFFF. 371 o The flow label is no longer unrealistically asserted to be 372 strictly immutable; it is recognised that it may, incorrectly, be 373 changed en route. In some circumstances this will break end-to- 374 end usage, e.g. potential detection of third-party spoofing 375 attacks [I-D.gont-6man-flowlabel-security]. 376 o The expected default usage of the flow label is some form of load 377 balancing, such as the ECMP/LAG usage defined in 378 [I-D.carpenter-flow-ecmp]. 379 o If the rules in Section 4 are followed, including rule 3.2, all 380 IPv6 traffic flows on the Internet will have zero or pseudo-random 381 flow label values. 383 From an operational viewpoint, existing IPv6 hosts that set a default 384 (zero) flow label value and ignore the flow label on receipt will be 385 unaffected by implementations of this specification. In general, it 386 is assumed that hosts will ignore the value of the flow label on 387 receipt; it cannot be relied on as an end-to-end signal. 389 Similarly, routers that ignore the flow label will be unaffected by 390 implementations of this specification. 392 Hosts that set a default (zero) flow label and are in a domain where 393 routers adopt the recommended pseudo-random mechanism in Section 4 394 will benefit from whatever flow label handling is used in the local 395 domain. 397 Hosts and routers that adopt the recommended pseudo-random mechanism 398 will enhance the performance of any load balancing devices that 399 include the flow label in the hash used to select a particular path 400 or server, even when packets leave the local domain. 402 6. Security Considerations 404 The flow label is not protected in any way and can be forged by an 405 on-path attacker. On the other hand, a pseudo-random flow label 406 cannot be readily guessed by an off-path attacker. See RFC 3697 and 407 [I-D.gont-6man-flowlabel-security] for further discussion. 409 Security devices that clear or rewrite flow label values would be in 410 violation of this specification. 412 7. IANA Considerations 414 This document requests no action by IANA. 416 8. Acknowledgements 418 The authors are grateful to Qinwen Hu for general discussion about 419 the flow label and for his work in searching the literature. 420 Valuable comments and contributions were made by Fred Baker, Steve 421 Blake, Remi Despres, Alan Ford, Fernando Gont, Brian Haberman, Tony 422 Hain, Joel Halpern, Chris Morrow, Thomas Narten, Mark Smith, Pascal 423 Thubert, Iljitsch van Beijnum, and other participants in the 6man 424 working group. 426 This document was produced using the xml2rfc tool [RFC2629]. 428 9. Change log 430 draft-ietf-6man-flow-update-01: clarified that this is not a formal 431 update of RFC 3697, clarified text about domains exporting 432 inappropriate labels, 2011-01-10 434 draft-ietf-6man-flow-update-00: adopted as WG document at IETF 79, 435 mutability rules adjusted according to WG discussion, 2010-12-03 437 draft-carpenter-6man-flow-update-04: even more simplified according 438 to WG discussion, 2010-09-16 440 draft-carpenter-6man-flow-update-03: futher simplified according to 441 WG discussion, 2010-05-07 443 draft-carpenter-6man-flow-update-02: revised and simplified according 444 to WG discussion, 2010-04-13 446 draft-carpenter-6man-flow-update-01: revised according to mail list 447 discussion, 2010-03-05 449 draft-carpenter-6man-flow-update-00: original version, 2010-02-18 451 10. References 453 10.1. Normative References 455 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 456 Requirement Levels", BCP 14, RFC 2119, March 1997. 458 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 459 (IPv6) Specification", RFC 2460, December 1998. 461 [RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, 462 "IPv6 Flow Label Specification", RFC 3697, March 2004. 464 10.2. Informative References 466 [I-D.carpenter-flow-ecmp] 467 Carpenter, B. and S. Amante, "Using the IPv6 flow label 468 for equal cost multipath routing and link aggregation in 469 tunnels", draft-carpenter-flow-ecmp-03 (work in progress), 470 October 2010. 472 [I-D.gont-6man-flowlabel-security] 473 Gont, F., "Security Assessment of the IPv6 Flow Label", 474 draft-gont-6man-flowlabel-security-01 (work in progress), 475 November 2010. 477 [I-D.hu-flow-label-cases] 478 Hu, Q. and B. Carpenter, "Survey of proposed use cases for 479 the IPv6 flow label", draft-hu-flow-label-cases-02 (work 480 in progress), September 2010. 482 [I-D.martinbeckman-ietf-ipv6-fls-ipv6flowswitching] 483 Beckman, M., "IPv6 Dynamic Flow Label Switching (FLS)", 484 draft-martinbeckman-ietf-ipv6-fls-ipv6flowswitching-03 485 (work in progress), March 2007. 487 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 488 "Definition of the Differentiated Services Field (DS 489 Field) in the IPv4 and IPv6 Headers", RFC 2474, 490 December 1998. 492 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 493 June 1999. 495 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 496 December 2005. 498 Appendix A. Alternative Approaches 500 A model was discussed in an earlier version of this document which 501 defined a notion of 'flow label domain' analogous to a differentiated 502 services domain [RFC2474]. This model would have encouraged local 503 usage of the flow label as an alternative to any form of generic use, 504 but it required complex rules for the behaviour of domain boundary 505 routers, and proved controversial in discussion. 507 Two even more complex alternative approaches were also considered and 508 rejected. 510 The first was to distinguish locally significant flow labels from 511 those conforming to RFC 3697 by setting or clearing the most 512 significant bit (MSB) of the flow label. This led to quite 513 complicated rules, seems impossible to make fully self-consistent, 514 and was not considered practical. 516 The second was to use a specific differentiated services code point 517 (DSCP)[RFC2474] in the Traffic Class octet instead of the MSB of the 518 flow label itself, to flag a locally defined behaviour. A more 519 elaborate version of this was proposed in 520 [I-D.martinbeckman-ietf-ipv6-fls-ipv6flowswitching]. There are two 521 issues with this approach. One is that DSCP values are themselves 522 only locally significant, inconsistent with the end-to-end nature of 523 the original flow label definition. Secondly, it seems unwise to 524 meld the semantics of differentiated services, which are currently 525 deployed, with the unknown future semantics of flow label usage. 526 However, this approach, while not recommended, does not appear to 527 violate any basic principles if applied strictly within a single 528 differentiated services domain. 530 Authors' Addresses 532 Shane Amante 533 Level 3 Communications, LLC 534 1025 Eldorado Blvd 535 Broomfield, CO 80021 536 USA 538 Email: shane@level3.net 539 Brian Carpenter 540 Department of Computer Science 541 University of Auckland 542 PB 92019 543 Auckland, 1142 544 New Zealand 546 Email: brian.e.carpenter@gmail.com 548 Sheng Jiang 549 Huawei Technologies Co., Ltd 550 Huawei Building, No.3 Xinxi Rd., 551 Shang-Di Information Industry Base, Hai-Dian District, Beijing 552 P.R. China 554 Email: shengjiang@huawei.com