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