Network Working Group Y. Cui Internet-Draft M. Xu Intended status: Standards Track P. Wu Expires: April 28, 2011 S. Wang J. Wu X. Li Tsinghua University C. Metz Cisco Systems, Inc. October 25, 2010 Translation Spot Negotiation in IPv4/IPv6-Coexist Mesh draft-cui-softwire-pet-03 Abstract IPv4 and IPv6 are expected to coexist for a long period. Currently, there are many IPv4/IPv6 transition/coexistence techniques, roughly divided into the categories of tunneling and translation. Tunneling and translation have respective application scopes, and translation has some technical limitations, including scalability issue, application layer translation, operation complexity, etc. To improve the availability of translation, this draft proposes the method of selecting appropriate translation spot to execute translation. When the translation spot is not on IPv4-IPv6 border, tunnel is used to achieve the traversing between translation spot and IP border. This method applies well in mesh scenario where both IPv4 and IPv6 client network exists, and BGP can be extended to achieve a translation spot signaling. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 28, 2011. Cui, et al. Expires April 28, 2011 [Page 1] Internet-Draft Translation Spot Negotiation October 2010 Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Cui, et al. Expires April 28, 2011 [Page 2] Internet-Draft Translation Spot Negotiation October 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Translation Spot Selection . . . . . . . . . . . . . . . . . . 6 3. Translation Spot Selection in IPv4/IPv6-coexist Mesh . . . . . 8 3.1. Scenario description . . . . . . . . . . . . . . . . . . . 8 3.2. Translation between IPvX and IPvY networks . . . . . . . . 9 3.3. Translation between IPvX network and IPvY Internet . . . . 9 3.4. Translation between IPvY network and IPvX Internet . . . . 9 4. Translation Spot Signaling . . . . . . . . . . . . . . . . . . 10 4.1. Signaling content . . . . . . . . . . . . . . . . . . . . 10 4.2. Extensions in MP-BGP . . . . . . . . . . . . . . . . . . . 10 5. Further discussion . . . . . . . . . . . . . . . . . . . . . . 13 5.1. Achievement of translation spot selection . . . . . . . . 13 5.2. Cooperate with softwire . . . . . . . . . . . . . . . . . 13 5.3. Using NAT64 or IVI as translation mechanism . . . . . . . 13 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 14 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 8.2. Informative References . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Cui, et al. Expires April 28, 2011 [Page 3] Internet-Draft Translation Spot Negotiation October 2010 1. Introduction Recently more and more IPv6 networks have been deployed, especially IPv6 backbone networks. However the existing IPv4 networks still carry the major network traffic and hold the major network services and applications. It has been widely believed that IPv4 and IPv6 networks will coexist for a long term. This leads to the demand for IPv4-IPv6 coexistence technology. Till now there are two types of IPv4-IPv6 coexistence techniques: tunneling and translation. Tunneling can achieve IPv4-over-IPv6/ IPv6-over-IPv4 traversing, by means of encapsulation and decapsulation. Examples of tunneling methods include IP-in-IP tunnel [RFC2893][RFC4213], GRE tunnel [RFC1702], 6to4 tunnel [RFC3056], 6over4 tunnel [RFC2529], softwire mesh technique [RFC5565], etc. Tunneling is transparent and light-weighted. It can be implemented fully by hardware. On the other hand, translation is used to achieve IPv4-IPv6 inter- communication, by means of converting the semantic between IPv4 and IPv6. Examples of translation methods include SIIT [RFC2765], NAT-PT [RFC2766], BIS [RFC2767], BIA [RFC3338], IVI [I-D.xli-behave-ivi], NAT64 [I-D.ietf-behave-v6v4-xlate-stateful] and so on. Translation can achieve IPv4-IPv6 interworking which tunneling cannot do, but it has several technical limitations: o Scalability. In stateful translation, the dynamic mapping of (address, port) tuple should be maintained on the translation device. The total number of mapping entries is up to the order of flow number. As to stateless translation, it has to consume IPv4 addresses to satisfy IPv6 hosts. This is also not scalable since IPv6 address space is much larger than IPv4 address. o Application layer translation. Since translation will modify the address of an IP packet, or we say an end host, an application protocol that contains IP addresses in its payload won't work if we don't convert the addresses. However, due to the variety of applications protocols, it's unrealistic for the translation device to support all of them. o Operation complexity. To accomplish correct translation, the following operations are required: address or (address, port) tuple conversion, IP and ICMP fields translation, TCP/UDP checksum re-computing, application layer detection and translation, fragmentation when necessary. It's rather complex for a per- packet process and probably unacceptable when the volume is high. Cui, et al. Expires April 28, 2011 [Page 4] Internet-Draft Translation Spot Negotiation October 2010 o Lack of efficient NAT46 translation mechanism. No efficient IPv4 to IPv6 communication mechanism has been proposed since NAT-PT. A fundamental difficulty here is that IPv6 address space is much larger than IPv4 so the translation mechanism has to make DNS or other addressing method stateful. Obviously this is not scalable. Though facing all these issues, translation is irreplaceable in its application scope, so it's necessary to find a way to improve its availability. To solve this problem, this draft proposes the method of finding the appropriate translation spot to execute translation. The method adopts tunnel when necessary, to achieve traversing between translation spot and IP border. As an attempt, this draft applies the method in IPv4/IPv6-coexist mesh scenario, and extends BGP to achieve translation spot signaling in the scenario. Cui, et al. Expires April 28, 2011 [Page 5] Internet-Draft Translation Spot Negotiation October 2010 2. Translation Spot Selection The issues of translation listed in section 1 are inherent disadvantages due to the principle of translation. Hence it's difficult to solve these problems by improving the mechanism. However, by choosing the appropriate location to perform translation, these problems can be solved or lightened, and translation can be more available. This draft calls the location to perform translation as "translation spot". The basic idea of translation spot selection is to choose the place where the scalability and complexity is not a concern, i.e., the place where the translator is capable for its own translation traffic. Following this thought, a straightforward principle is to push translation down to edge networks. Since the volume of translation traffic in edge networks is relatively low, it's possible to achieve a real-time per-flow mapping and per-packet modification there. On the contrary, traffic in backbone is aggregated and hence much higher in volume. So routers in backbone would rather only support routing and forwarding than take charge of high-speed translation. However, when the total translation volume is low, it's easier to perform a unified translation in backbone than to distribute the job to many edge networks. To achieve flexible translation spot selection, there's still a difficulty in packet forwarding: in a given topology, the IPv4-IPv6 border spot is fixed; If the translation spot isn't identical to the IP border spot, the packets can't be forwarded between the two spot due to IP diversity. See the example in Figure 1. The IP border is on spot 2 between IPvY backbone and IPvX Internet while the translation spot can be spot 1 or spot 2. If spot 1 is chosen, then packets from IPvY edge network are translated into IPvX on spot 1; they have to traverse to IPvY backbone to reach IPvX Internet. , and packets from IPvX Internet have to traverse the IPvY backbone to reach spot 1 for translation. Similar thing happens when spot 2 is chosen in Figure 2. translation ========== translation spot1 tunnel spot2 +---------+ +---------+ +---------+ |IPvY Edge| +-----+ |IPvY | +-----+ |IPvX | |Network |--|xlate|--|Backbone |--|xlate|--|Internet | | | +-----+ | | +-----+ | | +---------+ +---------+ +---------+ IP border Figure 1 Translation Spot selection Cui, et al. Expires April 28, 2011 [Page 6] Internet-Draft Translation Spot Negotiation October 2010 translation ========== translation spot1 tunnel spot2 +---------+ +---------+ +---------+ |IPvY Edge| +-----+ |IPvX | +-----+ |IPvX | |Network |--|xlate|--|Backbone |--|xlate|--|Internet | | | +-----+ | | +-----+ | | +---------+ +---------+ +---------+ IP border Figure 2 Translation Spot selection This is actually a traversing problem and the typical solution is tunneling. By building a tunnel to connect IP border and the translation spot, the forwarding path can be achieved. In the example of Figure 1, an IPvX-over-IPvY tunnel between spot 1 and spot 2 can be used to forward translated-to-IPvX packets from spot 1 to spot 2, and to-be-translated IPvX packets from spot 2 to spot 1. In Figure 2, an IPvY-over-IPvx tunnel between spot 1 and spot 2 can be used to forward to-be-translated IPvY packets from spot 1 to spot 2, and translated-to-IPvY packet from spot 2 to spot 1. Although the flexible translation spot selection may require an extra tunnel, its cost is much lower than translation, and hence acceptable. Cui, et al. Expires April 28, 2011 [Page 7] Internet-Draft Translation Spot Negotiation October 2010 3. Translation Spot Selection in IPv4/IPv6-coexist Mesh 3.1. Scenario description Translation spot selection can be used in many scenarios. As a demonstration this draft applies it to the mesh scenario described in Figure 3. In this scenario, an IPvX-only backbone is connected to both IPvX networks and IPvY networks. The backbone may also have entrance to IPvX and IPvY Internet. Besides native traffic and IPvY- over-IPvX softwire traffic described in [RFC4925], there're also traffics between IPvX and IPvY networks, between IPvX network and IPvY Internet, and between IPvY network and IPvX Internet. All these three types of traffics require translation, which should be performed on AFBRs (Address Family Border Router) or BRs (Border Router) on the border of the backbone. +--------+ +--------+ | IPvY | | IPvX | |Internet| |Internet| | | | | +--------+ +--------+ | | | | +--------+ +--------+ | AFBR | | BR | +--| Xlator |---| Xlator |--+ | +--------+ +--------+ | +--------+ | | +--------+ | IPvY | +--------+ +--------+ | IPvY | | Client | | AFBR | | AFBR | | Client | | Network|--| Xlator | IPvX | Xlator |--| Network| +--------+ +--------+ only +--------+ +--------+ | | | +--------+ +--------+ | +--| BR |---| BR |--+ | Xlator | | Xlator | +--------+ +--------+ | | | | +--------+ +--------+ | IPvX | | IPvX | | Client | | Client | | Network| | Network| +--------+ +--------+ Figure 3 Translation Spot Selection in IPv4/IPv6-coexist Mesh Cui, et al. Expires April 28, 2011 [Page 8] Internet-Draft Translation Spot Negotiation October 2010 3.2. Translation between IPvX and IPvY networks The communication between an IPvX network and an IPvY network follows the path "IPvX network - BR - IPvX backbone - AFBR - IPvY network". The translation can be performed either on the BR between IPvX network and backbone, or on the AFBR between IPvX backbone and IPvY network. If the BR is chosen to be translation spot, a tunnel should be established for packet forwarding between the BR and the AFBR. Naturally it could be a softwire tunnel since it's a mesh scenario. Besides, to perform correct translation, BR needs the translation context delivered from the AFBR. This will be discussed in the next section. 3.3. Translation between IPvX network and IPvY Internet The communication between an IPvX network and IPvY Internet follows the path "IPvX network - BR - IPvX backbone - AFBR - IPvY Internet". The translation spot can be either the BR between IPvX network and backbone, or the AFBR between IPvX backbone and IPvY Internet. BR can be chosen to avoid scalability and operation complexity issues, and AFBR can be chosen for unified translation purpose. If the BR is chosen to be translation spot, a softwire tunnel should be established between the BR and the AFBR. Also BR needs the translation context delivered from the AFBR. 3.4. Translation between IPvY network and IPvX Internet The communication between an IPvY network and IPvX Internet follows the path "IPvY network - AFBR - IPvX backbone - BR - IPvX Internet". The translation spot can be either the AFBR between IPvY network and IPvX backbone, or the BR between IPvX backbone and IPvX Internet. Usually the AFBR is preferred in this case, since it's the IP border and traffic is not so aggregated as in BR. However, BR can be chosen for unified translation purpose. If the BR is chosen to be translation spot, a softwire tunnel should be established between the BR and the AFBR. Also BR needs the translation context delivered from the AFBR. In all three types of translation-involved communication, translation spot selection is feasible. Yet an auto negotiation method is required to make the translation spot selection and translation context advertisement process more practical in the mesh scenario. This will be discussed in the next section. Cui, et al. Expires April 28, 2011 [Page 9] Internet-Draft Translation Spot Negotiation October 2010 4. Translation Spot Signaling In the IPv4/IPv6-coexist mesh, the total number of client networks, and hence the total number of AFBRs and BRs could be quite high, so an auto negotiation method is required to select the translation spot for all translation-involved communications, rather than manual configuration on every AFBR and BR. This negotiation method is called translation spot signaling. 4.1. Signaling content It's clear that translation should be performed on an appropriate translator, or as in this scenario, an AFBR or BR device. Here the concept of Translation Preference (TP) is defined to represent the appropriateness of a device to perform translation. TP is a quantified value set by the administrator of the corresponding AFBR or BR device. By exchanging and comparing TP values, two translators can decided which one to be the translation spot. The TP value should be decided by the administrator. The general criterion here is, the translator whose performance is better, whose traffic volume is lower, and the size of network behind which is smaller (thus the translation traffic is less aggregated), is preferred to do translation and should have a high value. TP can also be configured based on administrator's policy, such as unified translation. TPs for stateless and stateful translation are separated because they have different foundations (stateless translation requires IPv6 host to possess IPv4 address). In a mixed scenario, some translators can't perform stateless translation like others because IPv6 hosts in its network don't own IPv4 addresses. Besides TP, translation context should also be advertised through signaling. The translation context is the necessary knowledge to perform a translation. For stateless translation it's the mapping prefix, and for stateful translation it's the address pool used for address mapping. For example, in the type of "IPv6 network - BR - IPv6 Backbone - AFBR - IPv4 Internet" communication, if stateless translation is adopted, then AFBR should tell BR the prefix for IPv4- IPv6 address mapping when BR performs the translation; if stateful translation is adopted, then AFBR should tell BR the IPv4 addresses BR can use for address mapping when BR performs the translation. 4.2. Extensions in MP-BGP MP-BGP is adopted to carry the translation spot signaling process since it fits the mesh scenario and is already used in softwire Cui, et al. Expires April 28, 2011 [Page 10] Internet-Draft Translation Spot Negotiation October 2010 mesh[RFC5565]. We define a new a new BGP Attribute, "Translation Information Attribute" to carry the TP and translation context information. It's an optional transitive attribute, and the attribute type code is TBD by IANA. The value field of this attribute is composed of a set of Type-Length-Value (TLV) encodings. The TLV is structured as follows. The Length field stands for the total number of octets in the Value field. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (2 Octets) | Length (2 Octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Value | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ We define 4 TLVs here: Stateless_TP TLV, Stateful_TP TLV, IPv6_Prefix TLV and IPv4_pool TLV. More TLVs may be defined in the future when necessary. o Stateless_TP TLV has the type field assigned to 1 and length field assigned to 2. The value field is filled with the 16bit TP value for stateless translation. High the TP value means high preference to perform translation. o Stateful_TP TLV has the type field 2 and length field 2. The value field is filled with the 16bit TP value for stateful translation. High the TP value means high preference to perform translation. o IPv6_Prefix TLV has the type field assigned to 3. The length field is variable. The value field is filled with the IPv6 prefix for address mapping in stateless translation, encoding in NLRI format[RFC4760]. o IPv4_pool TLV has the type field assigned to 4. The length field is variable. The value field is filled with the IPv4 pool for address mapping in stateful translation, encoding in NLRI format. The AFBRs and BRs in the mesh should run MP-BGP process and peer with each other. When a new BGP session is established, AFBR and BR send a update containing the Translation Information Attribute to each other, which contains the Stateless_TP TLV or Stateful_TP TLV. Each router independently decides translation spot based on received TP Cui, et al. Expires April 28, 2011 [Page 11] Internet-Draft Translation Spot Negotiation October 2010 value. When the selected translation spot isn't the AFBR, then the AFBR should send another update with the Translation Information Attribute containing the IPv6_Prefix TLV or the IPv4_pool TLV to the BR. The tunnel-related routing should be triggered too, if there's any. Cui, et al. Expires April 28, 2011 [Page 12] Internet-Draft Translation Spot Negotiation October 2010 5. Further discussion 5.1. Achievement of translation spot selection To be precise, through translation spot selection, we can solve the scalability problem of stateful translation and the operation complexity problem for both stateless and stateful translation. Also we make it more possible to perform application layer translation and adopt NAT46 mechanisms (NAT-PT) by pushing the translation spot down to the edge. 5.2. Cooperate with softwire In the mesh scenario, softwire[RFC5565] is usually adopted as the tunnel mechanism. If it's used to support forwarding between the BR and the AFBR, then after translation spot signaling, BR and AFBR should trigger the softwire routing process, in which AFBR should advertise the actual IPv4 prefixes, while BR should advertise to AFBR either the address pool assigned from the AFBR (stateful case), or the IPv4 address prefix containing the IPv4 address possessed by the IPv6 hosts (stateless case). 5.3. Using NAT64 or IVI as translation mechanism NAT64[I-D.ietf-behave-v6v4-xlate-stateful] is a typical stateful translation mechanism. It can be used in the IPv4/IPv6-coexist mesh for translation-involved communications across the backbone. If AFBR is chosen to be the translation spot, then the traffic will follow a traditional NAT64 process; else BR is chosen to be the translation spot, then AFBR should divided its public IPv4 address pool and assigned one block to the BR through translation spot signaling. BR will perform the NAT64 translation using the assigned IPv4 address block. In softwire routing, BR should advertise this block to AFBR. IVI[I-D.xli-behave-ivi] is a typical stateless translation mechanism. It can be used in the IPv4/IPv6-coexist mesh for translation-involved communications across the backbone. If AFBR is chosen to be the translation spot, then the traffic will follow a traditional IVI process; else BR is chosen to be the translation spot, then AFBR should inform BR the IVI prefix, then BR can learn the address mapping role and the IPv4 prefix possessed by its network. In softwire routing, BR should advertise this IPv4 prefix to AFBR. Cui, et al. Expires April 28, 2011 [Page 13] Internet-Draft Translation Spot Negotiation October 2010 6. IANA considerations IANA is requested to assign a value from the "BGP Path Attributes" Registry, to be called "Translation Information Attribute", with this document as the reference. Cui, et al. Expires April 28, 2011 [Page 14] Internet-Draft Translation Spot Negotiation October 2010 7. Acknowledgements The authors would like to thank Lixia Zhang, Eric Nordmark, Jari Arkko, Alain Durand and David Ward for their valuable comments on this draft. Cui, et al. Expires April 28, 2011 [Page 15] Internet-Draft Translation Spot Negotiation October 2010 8. References 8.1. Normative References [RFC1702] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing Encapsulation over IPv4 networks", RFC 1702, October 1994. [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529, March 1999. [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000. [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000. [RFC2767] Tsuchiya, K., HIGUCHI, H., and Y. Atarashi, "Dual Stack Hosts using the "Bump-In-the-Stack" Technique (BIS)", RFC 2767, February 2000. [RFC2893] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 2893, August 2000. [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. [RFC3338] Lee, S., Shin, M-K., Kim, Y-J., Nordmark, E., and A. Durand, "Dual Stack Hosts Using "Bump-in-the-API" (BIA)", RFC 3338, October 2002. [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005. [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. [RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire Problem Statement", RFC 4925, July 2007. [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh Framework", RFC 5565, June 2009. Cui, et al. Expires April 28, 2011 [Page 16] Internet-Draft Translation Spot Negotiation October 2010 8.2. Informative References [I-D.ietf-behave-v6v4-xlate-stateful] Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", draft-ietf-behave-v6v4-xlate-stateful-12 (work in progress), July 2010. [I-D.xli-behave-ivi] Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The CERNET IVI Translation Design and Deployment for the IPv4/ IPv6 Coexistence and Transition", draft-xli-behave-ivi-07 (work in progress), January 2010. Cui, et al. Expires April 28, 2011 [Page 17] Internet-Draft Translation Spot Negotiation October 2010 Authors' Addresses Yong Cui Tsinghua University Department of Computer Science, Tsinghua University Beijing 100084 P.R.China Phone: +86-10-6278-5822 Email: cy@csnet1.cs.tsinghua.edu.cn Mingwei Xu Tsinghua University Department of Computer Science, Tsinghua University Beijing 100084 P. R. China Phone: +86-10-6278-5822 Email: xmw@csnet1.cs.tsinghua.edu.cn Peng Wu Tsinghua University Department of Computer Science, Tsinghua University Beijing 100084 P. R. China Phone: +86-10-6278-5822 Email: weapon@csnet1.cs.tsinghua.edu.cn Shengling Wang Tsinghua University Department of Computer Science, Tsinghua University Beijing 100084 P. R. China Phone: +86-10-6278-5822 Email: slwang@csnet1.cs.tsinghua.edu.cn Cui, et al. Expires April 28, 2011 [Page 18] Internet-Draft Translation Spot Negotiation October 2010 Jianping Wu Tsinghua University Department of Computer Science, Tsinghua University Beijing 100084 P. R. China Phone: +86-10-6278-5983 Email: jianping@cernet.edu.cn Xing Li Tsinghua University Department of Electronic Engineering, Tsinghua University Beijing 100084 P. R. China Phone: +86-10-6278-5983 Email: xing@cernet.edu.cn Chris Metz Cisco Systems, Inc. 3700 Cisco Way San Jose, Ca. 95134 USA Email: chmetz@cisco.com Cui, et al. Expires April 28, 2011 [Page 19]