idnits 2.17.1 draft-boucadair-6man-64-flag-bit-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 (August 20, 2014) is 3530 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) == Outdated reference: A later version (-18) exists of draft-ietf-softwire-dslite-multicast-07 == Outdated reference: A later version (-25) exists of draft-ietf-softwire-mesh-multicast-07 == Outdated reference: A later version (-15) exists of draft-ietf-softwire-multicast-prefix-option-06 -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6man Working Group M. Boucadair, Ed. 3 Internet-Draft France Telecom 4 Intended status: Standards Track J. Qin 5 Expires: February 21, 2015 Cisco 6 Y. Lee 7 Comcast 8 S. Venaas 9 Cisco Systems 10 X. Li 11 CERNET Center/Tsinghua University 12 M. Xu 13 Tsinghua University 14 August 20, 2014 16 IPv6 Multicast Address With Embedded IPv4 Multicast Address 17 draft-boucadair-6man-64-flag-bit-01 19 Abstract 21 This document reserves one bit (M-bit) of the unicast prefix-based 22 multicast IPv6 address for ASM and an IPv6 multicast prefix for SSM 23 mode to be used in the context of IPv4-IPv6 interconnection. 25 The document specifies an algorithmic translation of an IPv6 26 multicast address to a corresponding IPv4 multicast address, and vice 27 versa. This algorithmic translation can be used in both IPv4-IPv6 28 translation or encapsulation schemes. 30 Requirements Language 32 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 33 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 34 document are to be interpreted as described in RFC 2119 [RFC2119]. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on February 21, 2015. 53 Copyright Notice 55 Copyright (c) 2014 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 72 3. IPv4-Embedded IPv6 Multicast Prefix & Address . . . . . . . . 4 73 3.1. ASM Mode . . . . . . . . . . . . . . . . . . . . . . . . 4 74 3.2. SSM Mode . . . . . . . . . . . . . . . . . . . . . . . . 5 75 3.3. IPv4-Embedded IPv6 Multicast Address . . . . . . . . . . 5 76 3.4. Address Translation Algorithm . . . . . . . . . . . . . . 6 77 3.5. Textual Representation . . . . . . . . . . . . . . . . . 6 78 3.6. Source IPv4 Address in the IPv6 Realm . . . . . . . . . . 6 79 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6 80 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 82 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 83 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 84 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 85 8.2. Informative References . . . . . . . . . . . . . . . . . 8 86 Appendix A. Motivations . . . . . . . . . . . . . . . . . . . . 9 87 A.1. Why an Address Format is Needed for Multicast IPv4-IPv6 88 Interconnection? . . . . . . . . . . . . . . . . . . . . 9 89 A.2. Why Identifying an IPv4-Embedded IPv6 Multicast Address 90 is Required? . . . . . . . . . . . . . . . . . . . . . . 10 91 A.3. Location of the IPv4 Address . . . . . . . . . . . . . . 10 92 Appendix B. Design Considerations . . . . . . . . . . . . . . . 11 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 95 1. Introduction 97 Various solutions (e.g., [I-D.ietf-softwire-mesh-multicast], 98 [I-D.ietf-softwire-dslite-multicast]) have been proposed to allow 99 access to IPv4 multicast content from hosts attached to IPv6-enabled 100 domains. Even if these solutions have distinct applicability scopes 101 (translation vs. encapsulation) and target different use cases, they 102 all make use of specific IPv6 multicast addresses to embed an IPv4 103 multicast address. Particularly, the IPv4-Embedded IPv6 Multicast 104 Address is used as a destination IPv6 address of multicast flows 105 received from an IPv4-enabled domain and injected by the IPv4-IPv6 106 Interconnection Function into an IPv6-enabled domain. It is also 107 used to build an IPv6 multicast state (*, G6) or (S6, G6) 108 corresponding to their (*, G4) or (S4, G4) IPv4 counter parts by the 109 IPv4-IPv6 Interconnection Function. [I-D.ietf-mboned-v4v6-mcast-ps] 110 provides more discussion about issues related to IPv4/IPv6 multicast. 112 This document reserves one bit of the unicast prefix-based multicast 113 IPv6 address ([I-D.ietf-6man-multicast-addr-arch-update]) for Any- 114 Source Multicast (ASM) mode and an IPv6 multicast prefix for Source- 115 Specific Multicast (SSM) mode to be used in the context of IPv4-IPv6 116 interconnection. This document also defines how IPv4-Embedded IPv6 117 Multicast Addresses are constructed. Both IPv4-IPv6 translation and 118 encapsulation schemes can make use of this specification. 120 This specification can be used in conjunction with other extensions 121 such as embedding the rendezvous point [RFC3956]. Unicast prefix- 122 based and embedded-RP techniques are important tools to simplify IPv6 123 multicast deployments. Indeed, unicast prefix-based IPv6 addressing 124 is used in many current IPv6 multicast deployments, and has also been 125 defined for IPv4, and is seen as a very useful technique. Also 126 embedded-RP is used in existing deployments. 128 This document is a companion document to [RFC6052] which focuses 129 exclusively on IPv4-embedded IPv6 unicast addresses. 131 2. Terminology 133 This document makes use of the following terms: 135 o IPv4-Embedded IPv6 Multicast Address: denotes a multicast IPv6 136 address which includes in 32 bits an IPv4 address. 138 o Multicast Prefix64 (or MPREFIX64 for short) refers to an IPv6 139 multicast prefix to be used to construct IPv4-Embedded IPv6 140 Multicast Addresses. This prefix is used to build an 141 IPv4-Embedded IPv6 Multicast Address as defined in Section 3.4. 143 Section 3.4 specifies also how to extract an IPv4 address from an 144 IPv4-Embedded IPv6 Multicast Address. 146 o ASM_MPREFIX64: denotes a multicast Prefix64 used in Any Source 147 Multicast (ASM) mode. 149 o SSM_MPREFIX64: denotes a multicast Prefix64 used in Source 150 Specific Multicast (SSM) mode. 152 o IPv4-IPv6 Interconnection Function: refers to a function which is 153 enabled in a node interconnecting an IPv4-enabled domain with an 154 IPv6-enabled one. It can be located in various places of the 155 multicast network. Particularly, in terms of multicast control 156 messages, it can be an IGMP/MLD Interworking Function or an 157 IPv4-IPv6 PIM Interworking Function. An IPv4-IPv6 Interconnection 158 Function is configured with one or two MPREFIX64s. 160 3. IPv4-Embedded IPv6 Multicast Prefix & Address 162 3.1. ASM Mode 164 The format specified in Figure 1 uses some bits defined in 165 [I-D.ietf-6man-multicast-addr-arch-update]: M-bit (20th bit position, 166 where bit 1 is the most significant bit) now has a meaning. 168 Details on design considerations are discussed in Appendix B. 170 | 8 | 4 | 4 | 4 | 76 | 32 | 171 +--------+----+----+----+------------------------------+----------+ 172 |11111111|ff1 |scop|ff2 | sub-group-id |v4 address| 173 +--------+----+----+----+-----------------------------------------+ 174 +-+-+-+-+ 175 ff2 (flag field 2) is a set of 4 flags: |r|r|r|M| 176 +-+-+-+-+ 178 "r" bits MUST each be set to 0. 180 Figure 1: IPv4-Embedded IPv6 Multicast Address Format: ASM Mode 182 The description of the fields is as follows: 184 o "ff1" field is defined in 185 [I-D.ietf-6man-multicast-addr-arch-update]. 186 o "scop" field is defined in [RFC3956]. 187 o M (20th bit position): When this bit is set to 1, it indicates 188 that a multicast IPv4 address is embedded in the low-order 32 bits 189 of the multicast IPv6 address. 191 o sub-group-id: This field is configurable according to local 192 policies (e.g., enable embedded-RP) of the entity managing the 193 IPv4-IPv6 Interconnection Function. This field MUST follow the 194 recommendations specified in [RFC3306] if unicast-based prefix is 195 used or the recommendations specified in [RFC3956] if embedded-RP 196 is used. The default value is all zeros. 197 o The low-order 32 bits MUST include an IPv4 multicast address when 198 the M-bit is set to 1. The enclosed IPv4 multicast address SHOULD 199 NOT be in 232/8 range. 201 3.2. SSM Mode 203 For SSM mode, and given what is discussed in Appendix B, the 204 following IPv6 prefix to embed IPv4 multicast addresses is reserved: 206 o ff3x:0:8000::/96 ('x' is any valid scope). 208 3.3. IPv4-Embedded IPv6 Multicast Address 210 For the delivery of the IPv4-IPv6 multicast interconnection services, 211 a dedicated multicast prefix denoted as MPREFIX64 should be 212 provisioned (e.g., using NETCONF or 213 [I-D.ietf-softwire-multicast-prefix-option]) to any function 214 requiring to build an IPv4-Embedded IPv6 Multicast Address based on 215 an IPv4 multicast address. MPREFIX64 can be of ASM or SSM type. 216 When both modes are used, two prefixes are required to be 217 provisioned. 219 The length of MPREFIX64 MUST be /96. For SSM, MPREFIX64 MUST be 220 equal to ff3x:0:8000::/96. For the ASM mode, MPREFIX64 MUST have the 221 M-bit set to 1. Furthermore, the format of the ASM_MPREFIX64 should 222 follow what is specified in [RFC3306] and [RFC3956] if corresponding 223 mechanisms are used. If not, bits 21-96 can be set to any value. 225 Figure 2 shows how to build an IPv4-Embedded IPv6 Multicast Address 226 using a configured MPREFIX64 and an IPv4 multicast address. The low- 227 order 32 bits MUST include an IPv4 multicast address. The enclosed 228 IPv4 multicast address SHOULD NOT be in 232/8 range if an 229 ASM_PREFIX64 is configured. The enclosed IPv4 multicast address 230 SHOULD be in 232/8 range if an SSM_PREFIX64 is configured. 232 Embedding an IPv4 multicast address in the last 32 bits does not 233 conflict with the Group IDs assigned by IANA (i.e., 0x00000001 to 234 0x3FFFFFFF [RFC3307]). 236 When several MPREFIX64 are available, it is RECOMMENDED to use the 237 MPREFIX64 which preserve the scope of the IPv4 multicast address. 239 | 96 | 32 | 240 +------------------------------------------------------+----------+ 241 | MPREFIX64 |v4 address| 242 +------------------------------------------------------+----------+ 244 Figure 2: IPv4-Embedded IPv6 Multicast Address Format 246 3.4. Address Translation Algorithm 248 IPv4-Embedded IPv6 Multicast Addresses are composed according to the 249 following algorithm: 251 o Concatenate the MPREFIX64 and the 32 bits of the IPv4 address to 252 obtain a 128-bit address. 254 The IPv4 multicast addresses are extracted from the IPv4-Embedded 255 IPv6 Multicast Addresses according to the following algorithm: 257 o If the multicast address has the 20th bit set to 1 or it matches 258 ff3x:0:8000::/96 or a preconfigured MPREFIX64, extract the last 32 259 bits of the IPv6 multicast address. 261 3.5. Textual Representation 263 The embedded IPv4 address in an IPv6 multicast address is included in 264 the last 32 bits; therefore dotted decimal notation can be used. 266 3.6. Source IPv4 Address in the IPv6 Realm 268 An IPv4 source is represented in the IPv6 realm with its 269 IPv4-converted IPv6 address [RFC6052]. 271 4. Examples 273 Figure 3 provides some examples of ASM IPv4-Embedded IPv6 Address 274 while Figure 4 provides an example of SSM IPv4-Embedded IPv6 Address. 276 IPv4 multicast addresses used in the examples are derived from the 277 IPv4 multicast block reserved for documentation in [RFC6676]. 279 +----------------------+--------------+-----------------------------+ 280 | MPREFIX64 | IPv4 address | IPv4-Embedded IPv6 Address | 281 +----------------------+--------------+-----------------------------+ 282 | ff3x:z000:0:abc::/96 | 233.252.0.1 |ff3x:z000:0:abc::233.252.0.1 | 283 | ff7x:z000:0:abc::/96 | 233.252.0.2 |ff7x:z000:0:abc::233.252.0.2 | 284 +----------------------+--------------+-----------------------------+ 285 where: 286 "x" is any valid scope 287 "z" is any 4 bits where the last bit is set (e.g., 1, 3, 7, ...) 289 Figure 3: Example of ASM IPv4-embedded IPv6 address 291 +---------------------+--------------+----------------------------+ 292 | MPREFIX64 | IPv4 address | IPv4-Embedded IPv6 Address | 293 +---------------------+--------------+----------------------------+ 294 | ff3x:0:8000::/96 | 233.252.0.5 | ff3x:0:8000::233.252.0.5 | 295 +---------------------+--------------+----------------------------+ 297 Figure 4: Example of SSM IPv4-embedded IPv6 address 299 5. IANA Considerations 301 This document requests IANA to reserve: 303 o ff3x:0:8000::/96 SSM range to embed an IPv4 multicast address in 304 the last 32 bits. 306 6. Security Considerations 308 This document defines an algorithmic translation of an IPv6 multicast 309 address into an IPv4 multicast address, and vice versa. The security 310 considerations discussed in [RFC6052] are to be taken into 311 consideration. 313 7. Acknowledgements 315 Many thanks to R. Bonica, B. Sarikaya, P. Savola, T. Tsou, C. 316 Bormann, T. Chown, P. Koch, B. Haberman, and B. Hinden for their 317 comments and review. 319 8. References 321 8.1. Normative References 323 [I-D.ietf-6man-multicast-addr-arch-update] 324 Boucadair, M. and S. Venaas, "Updates to the IPv6 325 Multicast Addressing Architecture", draft-ietf-6man- 326 multicast-addr-arch-update-08 (work in progress), August 327 2014. 329 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 330 Requirement Levels", BCP 14, RFC 2119, March 1997. 332 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 333 Multicast Addresses", RFC 3306, August 2002. 335 [RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast 336 Addresses", RFC 3307, August 2002. 338 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 339 Point (RP) Address in an IPv6 Multicast Address", RFC 340 3956, November 2004. 342 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 343 IP", RFC 4607, August 2006. 345 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 346 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 347 October 2010. 349 8.2. Informative References 351 [I-D.ietf-behave-nat64-learn-analysis] 352 Korhonen, J. and T. Savolainen, "Analysis of solution 353 proposals for hosts to learn NAT64 prefix", draft-ietf- 354 behave-nat64-learn-analysis-03 (work in progress), March 355 2012. 357 [I-D.ietf-mboned-v4v6-mcast-ps] 358 Jacquenet, C., Boucadair, M., Lee, Y., Qin, J., Tsou, T., 359 and Q. Qiong, "IPv4-IPv6 Multicast: Problem Statement and 360 Use Cases", draft-ietf-mboned-v4v6-mcast-ps-04 (work in 361 progress), September 2013. 363 [I-D.ietf-softwire-dslite-multicast] 364 Qin, J., Boucadair, M., Jacquenet, C., Lee, Y., and Q. 365 Wang, "Delivery of IPv4 Multicast Services to IPv4 Clients 366 over an IPv6 Multicast Network", draft-ietf-softwire- 367 dslite-multicast-07 (work in progress), March 2014. 369 [I-D.ietf-softwire-mesh-multicast] 370 Xu, M., Cui, Y., Wu, J., Yang, S., Metz, C., and G. 371 Shepherd, "Softwire Mesh Multicast", draft-ietf-softwire- 372 mesh-multicast-07 (work in progress), July 2014. 374 [I-D.ietf-softwire-multicast-prefix-option] 375 Boucadair, M., Qin, J., Tsou, T., and X. Deng, "DHCPv6 376 Option for IPv4-Embedded Multicast and Unicast IPv6 377 Prefixes", draft-ietf-softwire-multicast-prefix-option-06 378 (work in progress), March 2014. 380 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 381 Description Protocol", RFC 4566, July 2006. 383 [RFC6676] Venaas, S., Parekh, R., Van de Velde, G., Chown, T., and 384 M. Eubanks, "Multicast Addresses for Documentation", RFC 385 6676, August 2012. 387 Appendix A. Motivations 389 A.1. Why an Address Format is Needed for Multicast IPv4-IPv6 390 Interconnection? 392 Arguments why an IPv6 address format is needed to embed multicast 393 IPv4 address are quite similar to those of [RFC6052]. Concretely, 394 the definition of a multicast address format embedding a multicast 395 IPv4 address allows: 397 o Stateless IPv4-IPv6 header translation of multicast flows; 399 o Stateless IPv4-IPv6 PIM interworking function; 401 o Stateless IGMP-MLD interworking function (e.g., required for an 402 IPv4 receiver to access to IPv4 multicast content via an IPv6 403 network); 405 o Stateless (local) synthesis of IPv6 address when IPv4 multicast 406 address are embedded in application payload (e.g., SDP [RFC4566]); 408 o Except the provisioning of the same MPREFIX64, no coordination is 409 required between IPv4-IPv6 PIM interworking function, IGMP-MLD 410 interworking function, IPv4-IPv6 Interconnection Function and any 411 ALG (Application Level Gateway) in the path; 413 o Minimal operational constraints on the multicast address 414 management: IPv6 multicast addresses can be constructed using what 415 has been deployed for IPv4 delivery mode. 417 A.2. Why Identifying an IPv4-Embedded IPv6 Multicast Address is 418 Required? 420 Reserving a dedicated multicast prefix for IPv4-IPv6 interconnection 421 purposes is a means to guide the address selection process at the 422 receiver side; in particular it assists the receiver to select the 423 appropriate IP multicast address while avoiding to involve an 424 IPv4-IPv6 interconnection function in the path. 426 Two use cases to illustrate this behavior are provided below: 428 1. An ALG is required to help an IPv6 receiver to select the 429 appropriate IP address when only the IPv4 address is advertised 430 (e.g., using SDP); otherwise the access to the IPv4 multicast 431 content can not be offered to the IPv6 receiver. The ALG may be 432 located downstream the receiver. As such, the ALG does not know 433 in advance whether the receiver is dual-stack or IPv6-only. The 434 ALG may be tuned to insert both the original IPv4 address and 435 corresponding IPv6 multicast address. If a dedicated prefix is 436 not used, a dual-stack receiver may prefer to use the IPv6 437 address to receive the multicast content. This address selection 438 would require multicast flows to cross an IPv4-IPv6 439 interconnection function. 441 2. In order to avoid involving an ALG in the path, an IPv4-only 442 source can advertise both its IPv4 address and IPv4-Embedded IPv6 443 Multicast Address. If a dedicated prefix is not reserved, a 444 dual-stack receiver may prefer to use the IPv6 address to receive 445 the multicast content. This address selection would require 446 multicast flows to cross an IPv4-IPv6 interconnection function. 448 Reserving dedicated IPv6 multicast prefixes for IPv4-IPv6 449 interconnection purposes mitigates the issues discussed in 450 [I-D.ietf-behave-nat64-learn-analysis] in a multicast context. 452 A.3. Location of the IPv4 Address 454 There is no strong argument to allow for flexible options to encode 455 the IPv4 address inside the multicast IPv6 address. The option 456 retained by the authors is to encode the multicast IPv4 address in 457 the low-order 32 bits of the IPv6 address. 459 This choice is also motivated by the need to be compliant with 460 [RFC3306] and [RFC3956]. 462 Appendix B. Design Considerations 464 The following constraints should be met when reserving dedicated 465 prefix(es) to be used for IPv4/IPv6 multicast interconnection: 467 1: Belong to SSM prefix range (preferably ff3x::/32) and be 468 compatible with unicast-based prefix [RFC3306] for SSM. Note 469 that [RFC3306] suggests to set "plen" to 0 and "network-prefix" 470 to 0. As such, any prefix in the 33-96 range can be convenient. 471 Given [RFC4607] indicates future specifications may allow a non- 472 zero network prefix field, a /33 would allow for future 473 extensions but it has the drawback of reserving a large block. A 474 /96 would be adequate for the use cases already identified in 475 [I-D.ietf-mboned-v4v6-mcast-ps]. In the event of any concrete 476 extension, reserving additional prefixes may be considered. 478 2: Be compatible with embedded-RP [RFC3956] and unicast-based prefix 479 [RFC3306] for ASM. This results in associating a meaning with 480 one of the reserved bits in 481 [I-D.ietf-6man-multicast-addr-arch-update]. Defining the 17-20 482 bits range to have a meaning and be used for IPv4/IPv6 transition 483 has the advantage of allowing for future extensions but it may be 484 seen as a waste of the multicast address space. Consequently, 485 using one of the reserved bits (in the range 17-20) from the 486 unicast-based IPv6 multicast address format [RFC3306] is 487 preferred. 489 Meeting (1) and (2) with the same reserved bit is not feasible 490 without modifying embedded-RP and unicast-based prefix 491 specifications; this option is avoided. 493 As a consequence, this document proposes to reserve a multicast 494 prefix for SSM and define one bit of the unicast prefix-based 495 multicast IPv6 address for ASM when embedding IPv4 multicast address 496 in an IPv6 multicast address. 498 Authors' Addresses 500 Mohamed Boucadair (editor) 501 France Telecom 502 Rennes 35000 503 France 505 Email: mohamed.boucadair@orange.com 506 Jacni Qin 507 Cisco 508 China 510 Email: jacni@jacni.com 512 Yiu L. Lee 513 Comcast 514 U.S.A 516 Email: yiu_lee@cable.comcast.com 518 Stig Venaas 519 Cisco Systems 520 Tasman Drive 521 San Jose, CA 95134 522 USA 524 Email: stig@cisco.com 526 Xing Li 527 CERNET Center/Tsinghua University 528 Room 225, Main Building, Tsinghua University 529 Beijing 100084 530 P.R. China 532 Phone: +86 10-62785983 533 Email: xing@cernet.edu.cn 535 Mingwei Xu 536 Tsinghua University 537 Department of Computer Science, Tsinghua University 538 Beijing 100084 539 P.R.China 541 Phone: +86-10-6278-5822 542 Email: xmw@cernet.edu.cn