Internet Engineering Task Force J. Bi Internet-Draft Y. Wang Intended status: Experimental X. Cheng Expires: July 10, 2009 Tsinghua University Jan 6, 2009 The Univer6 Architecture for IPv6 Transition draft-jbi-universal-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright and License Notice Copyright (c) 2008 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. Bi, et al. Expires July 10, 2009 [Page 1] Internet-Draft Univer6 Architecture for IPv6 Transition Jan 2009 Abstract IPv6 transition is becoming an important research topic recently. In traditional architecture, transition mechanisms are closely connected with application, protocol stack, and network equipments. This makes the transition process very complicated, and increases the difficulty of network management. In this document, we present a new network architecture called Univer6. It uses IPv6 as a unified middle layer,thus can adapt to various kinds of applications and network equipments. Univer6 will help provide a smooth transition towards IPv6, simplify network management process, and accelerate the development of IPv6. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirement for the architecture . . . . . . . . . . . . . . . 4 3. The Univer6 architecture . . . . . . . . . . . . . . . . . . . 6 3.1. Description of the architecture . . . . . . . . . . . . . 6 3.2. Advantages of the architecture . . . . . . . . . . . . . . 8 4. Illustration of Univer6 . . . . . . . . . . . . . . . . . . . 10 4.1. Application Interface (AI) layer . . . . . . . . . . . . . 10 4.2. Universal IPv6 layer . . . . . . . . . . . . . . . . . . . 11 4.3. Network Interface (NI) layer . . . . . . . . . . . . . . . 12 5. The challenges . . . . . . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 8.2. Informative References . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Bi, et al. Expires July 10, 2009 [Page 2] Internet-Draft Univer6 Architecture for IPv6 Transition Jan 2009 1. Introduction This memo is intended to descirbe a possible direction for IPv6 transition. With the development of IPv6 protocol, IPv6 network and test-beds are gradually built around the world, including CERNET2 in China, Internet2 in USA, and GeAnt2 in Europe. Meanwhile, IPv6 transition is rapidly becoming an important research topic. Several mechanism concerning IPv6 access, IPv6 tunnel, IPv6 applications have been raised, and many transition methods have been proposed for different network environments. However, in traditional network architecture, the transition methods are usually closely connected with all the factors such as application, protocol stack and network equipments. This close coupling increases the complexity of IPv6 transition process, and makes it difficult to carry out network managements. In order to solve these problems, we propose a new network architecture called Univer6 in this document. It uses IPv6 as a unified layer between different kinds of network infrastructures and the applications in the upper layer, which saves existing investments in network infrastructures, and provides a smooth IPv6 transition once and for all from the end users' point of view. This architecture can also make it easier for network management, and accelerate the transition process towards IPv6. Bi, et al. Expires July 10, 2009 [Page 3] Internet-Draft Univer6 Architecture for IPv6 Transition Jan 2009 2. Requirement for the architecture With the deployment of IPv6, there will be two seperated large networks: o Native IPv4 network. It is the legacy of the current Internet. The routers can only forward IPv4 packets, while the hosts may be dual-stack by updating the software. o Native IPv6 network. There may be no IPv4 address block available when setting up new network. The routers can only forward IPv6 packets. The hosts are using dual-stack, or only supporting IPv6. Even if the routers are dual-stack, there is no global IPv4 address allocated for the network. There are also some dual-stack networks. Both routers and hosts have dual-stack support, and both global IPv6 and IPv4 address are allocated for the network. Such network can be viewed as the overlapped part of native IPv4 network and native IPv6 network as shown in Figure 1. ,----------. ,' IPv4 ` / Native \ / Network \ ; : | ,----------. | : ,' ` ; \/ Dual-Stack \/ /\ Network /\ ; `. ,' : | '--------- | : ; \ IPv6 / \ Native / `. Network ,' '--------- Figure 1. Native IPv4, Native IPv6 and Dual-Stack Network In the coexisting of both IPv4 and IPv6 native networks, to promote the deployment of IPv6, some important requirements should be addressed: 1. Protect the legacy investnment on IPv4 native network. The routers and switches that can only support IPv4 will not be taken place by IPv6-enabled network devices, due to high cost of new devices and the estimation of no extra income from IPv6 in the Bi, et al. Expires July 10, 2009 [Page 4] Internet-Draft Univer6 Architecture for IPv6 Transition Jan 2009 near future. End users should have the ability to access IPv6 even with no changes to the IPv4 routers and switches. 2. Provide a way for universal access. IPv4 and IPv6 are two different "language" that can not directly talk to each other. There has been a large amount of users in the IPv4 native network. With the using up of IPv4 address, it is expected that there will also be a large amount of users in the IPv6 native network. The users in "IPv4 continent" and in "IPv6 continent" should have the ability to access each other in an end-to-end way. 3. Provide support for legacy IPv4 applications. Even some IPv4 applications can be modified to support IPv6, some will never be modified to have IPv6 support. There should have support for such IPv4 application to run over IPv6 only network. Bi, et al. Expires July 10, 2009 [Page 5] Internet-Draft Univer6 Architecture for IPv6 Transition Jan 2009 3. The Univer6 architecture 3.1. Description of the architecture Here we describe an architecture to meet the requirements analyzed above. The Univer6 architecture is composed of three-layers. In the "Infrastructure Layer", there may be IPv4 native network or IPv6 native network. Over the Infrastructure Layer, "Protocol Layer" can provide univeral access to IPv6 for all the users either in the IPv4 native network or in the IPv6 native network. The Protocol Layer should support both IPv4 application and IPv6 application in the Application Layer over the IPv6 protocol. There is a "IPv4 Adaption" function in the "Protocol Layer" to support IPv4 appliation running over IPv6. The basic idea of Univer6 is to use IPv6 as a unified middle layer between applications and network infrastructures. As for applications we have IPv4-only and IPv4/IPv6 applications nowadays. And in the future, IPv6-only applications may start to come up. When it comes to infrastructures, the situation is even more complex. We have IPv4 native network, IPv4/IPv6 dual stack network, and IPv6 native network. And a variety of mechanisms including Tunnel Broker, 6to4, DSTM, ISATAP and Teredo have been deployed to provide IPv6 access in different networks and during different IPv6 transition stages. Considering these factors, we paid special attention to the adaptability of Univer6, and the proposed architecture is as shown in Figure 2. Bi, et al. Expires July 10, 2009 [Page 6] Internet-Draft Univer6 Architecture for IPv6 Transition Jan 2009 +------------+ +------------+ +------------+ | IPv4 App | |IPv4 /v6 App| | IPv6 App | +------------+ +------------+ +------------+ +----------------------------------------+ | +----------------+ +----------------+ | | | API Adaptation | | DNS Adaptation | | | +----------------+ +----------------+ | Application | +------------------------------------+ | interface layer | | IPv6 encapsulation/decapsulation | | | +------------------------------------+ | +----------------------------------------+ +----------------------------------------+ | +----------+ +----------+ +----------+ | | | Address | | Security | | Address | | | |Validation| | | |Management| | Univeral | | Module | | Module | | Module | | IPv6 layer | +----------+ +----------+ +----------+ | +----------------------------------------+ +----------------------------------------+ | +----------------+ +----------------+ | | | API Adaptation | | DNS Adaptation | | | +----------------+ +----------------+ | Network | +------------------------------------+ | interface layer | | IPv6 encapsulation/decapsulation | | | +------------------------------------+ | +----------------------------------------+ +------------+ +------------+ +------------+ | IPv4 Native| | Dual stack | |IPv6 Native | +------------+ +------------+ +------------+ Figure 2. Univer6 architecture From Figure 2, we can see that Univer6 consists of three layers: o Application interface (AI) layer. This layer provides support for the applications in the upper layer, and handles all data packets sent from/to them. In order to support applications, this layer can provide a group of new API, or carry out translation between IPv4 and IPv6 API's. Meanwhile, since IPv4 applications need 32- bit IPv4 addresses to work, AI layer should provide addresses in the correct format. Also, in order to use IPv6 as a unified middle layer, all packets from user applications should be processed first (encapsulated if necessary) into IPv6 packets. This task is carried out in AI layer too. Bi, et al. Expires July 10, 2009 [Page 7] Internet-Draft Univer6 Architecture for IPv6 Transition Jan 2009 o Universal IPv6 layer. This is a unified middle layer in Univer6 architecture, and tasks are mainly concerned about IPv6 protocol itself. In this layer, we designed a security module to provide protections. Mechanisms like IPv6 firewall deal with not only IPv6 security issues, but also security problems during IPv6 transition. We have also designed an address validation module to ensure the validity of IPv6 addresses. This will make IPv6 address a trustable identifier, and help with network management. o Network interface (NI) layer. This layer performs actual data packet transfer. So its main task is to find a proper way to deliver packets according to different network environments. Most of existing transition mechanisms can be included into this layer and applied. Since IPv6 is used as a unified middle layer, encapsulation and decapsulation may be needed in this layer in an IPv4 network environment. In IPv6 environment, packets can be directly delivered, and NI will carry out the task of IPv6 network access. 3.2. Advantages of the architecture Compared with the traditional network architecture, Univer6 have some advantages in the following areas: 1. Smooth IPv6 transition. In the traditional architecture, transition mechanisms are closely related to infrastructures and applications. If the network equipments get upgraded or changed, users have to make corresponding adjustments. This causes much trouble for users during different stages of IPv6 transition. Univer6 will help solve this problem. From the user's point of view, when Univer6 is deployed, it will feel like the transition to IPv6 is finished once and for all, while equipments in the network can be gradually updated or replaced from IPv4 to dual stack, and finally to IPv6. For ISPs and network administrators, this means existing investments can be saved, and they can provide their customers with IPv6 service immediately. 2. Network management. In the traditional architecture, if a host is located in a dual stack network environment, it will have two different kinds of identifiers (IP addresses) at the same time. This will make it harder to build up an identifying system, and bring extra complexity to network configuration and management. In Univer6, IPv6 is used as a universal middle layer for all hosts. The vast space of IPv6 address can provide a global identification for all the users. Furthermore, after we deploy address validation mechanism in Univer6, each user can be correctly identified by its address. This will simplify the network management process, and make network configuration much Bi, et al. Expires July 10, 2009 [Page 8] Internet-Draft Univer6 Architecture for IPv6 Transition Jan 2009 easier and faster. 3. IPv6 usage. Currently, most network applications use IPv4 protocol. Although many are being upgraded to support IPv6, the number of IPv6 applications is still quite small. This results in the fact that many IPv6 networks are not put into use often enough, and valuable bandwidth resources are being wasted. In Univer6 architecture, we can provide support for IPv4 applications in the upper layer, and transfer data packets by using IPv6 networks in the lower layer. This will bring IPv4 applications into IPv6 networks, and make full use of existing IPv6 bandwidth. Bi, et al. Expires July 10, 2009 [Page 9] Internet-Draft Univer6 Architecture for IPv6 Transition Jan 2009 4. Illustration of Univer6 4.1. Application Interface (AI) layer The function of AI layer is to provide support for the network applications in the upper layer, and carry out IPv6 encapsulation / decapsulation process if necessary. The modules in this layer are shown in Figure 3. +------------------------------------------------+ | +------------+ +------------+ +------------+ | | | IPv4 App | |IPv4 /v6 App| | IPv6 App | | | +------------+ +------------+ +------------+ | +------------------------------------------------+ | | | API call | DNS resolution \/ \/ +------------------------------------------------+ | +----------------+ +----------------+ | | | API Module | | DNS Module | | | +----------------+ +----------------+ | +------------------------------------------------+ | | | | | | | Packets | | | \/ | | | +---------------------------+ | | | | Packet Management | | | | +---------------------------+ | | | Address | | | | | Request | IPv4 | | | | \/ | | | | +----------------+ | IPv6 | | | |IPv6 Encap/Decap| | | | | +----------------+ | | | | | | | | \/ \/ \/ | +------------------------------------------------+ Figure 3. Application Interface (AI) layer The function of API module is to provide programming interface support for upper layer applications. It contains a group of IPv4/ IPv6 adaptive interfaces, and carries out automatic translation / conversion between IPv4 and IPv6 API's when it's necessary. For the design of programming interface, IETF v6ops workgroup has proposed some basic guidelines for IPv4/IPv6 application development . As for API translation, existing mechanisms like BIA [RFC3338] contains some similar function modules, and can be used as a reference during Bi, et al. Expires July 10, 2009 [Page 10] Internet-Draft Univer6 Architecture for IPv6 Transition Jan 2009 standardization process. DNS module handles address resolution requests from applications, and its task is to provide addresses in the correct formats. Since IPv6 is the unified middle layer in Univer6, IPv6 addresses will be acquired without difficulty. However, if the upper layer application uses IPv4, DNS module should reply with a 32-bit IPv4 address. If the host is located in an IPv4 or dual stack environment, this address can be acquired directly from the network. If the network environment is IPv6, we can use a mechanism to generate an IPv4 address (like BIS) for the application. Currently, transition mechanisms like BIA and BIS contain some similar functions, and we are also carrying out research to support IPv4 applications in IPv6 environment. The results from these researches can be used for making standards for the DNS module. In the data packet plane, all packets from AI layer are finally delivered to the universal IPv6 layer. IPv6 packets can be delivered directly, and IPv4 packets will be encapsulated in an IPv6 header. Meanwhile, packets from IPv6 layer will be de-encapsulated (if necessary) and passed on to the user applications. 4.2. Universal IPv6 layer After going through AI layer, all packets delivered to this layer are in the format of IPv6. So, Universal IPv6 layer only has to deal with specific issues concern IPv6 protocol. No encapsulation/de- encapsulation process is needed, and packets can be sent to NI layer without modification. In this layer, modules are inserted to provide different IPv6 features including security, mobility, configuration, etc. Meanwhile, in order to provide necessary communication for the other two layers, an address management module is introduced into this layer. Requests from DNS are handled in this module, and addresses acquired from the lower layer are kept in this module, too. The most important modules in this layer are: o Address Validation Module. In IPv6 protocol, the 128 bit address space can give every user in the world a global IPv6 address. This address can be used as an identifier for the user, and become a helpful factor for network configuration and management. However, in current network, the problem of IP address spoofing is very serious. If we want to set up an identification system using IPv6 address, we should first solve the issue of IPv6 address validation. Currently, a lot of researches on address validation are being carried out, and some mechanisms like SAVA [draft-baker-sava-simple-00] and deployment guidelines [draft-wu-sava-testbed-experience-06] have been proposed. These Bi, et al. Expires July 10, 2009 [Page 11] Internet-Draft Univer6 Architecture for IPv6 Transition Jan 2009 research results can be integrated into the address validation module in Univer6. o Security Module. This module deals with not only security issues of IPv6 protocol itself, but also security issues during different stages of IPv6 transition, like security issues for each transition mechanism, risks brought up by IPv4/IPv6 co-existence, effects on existing IPv4 security architecture by applying IPv6, etc. Particularly, the effect brought by IPv6 address allocation needs to be carefully considered. In most IPv4 firewalls and other security mechanisms, IP address always plays a very important role. Rules and ACL's (Access Control List) often contain one or many fixed IP addresses. However, IPv6 uses some new features like SLAAC to acquire an address, and this acquired address may even change from time to time. This causes great challenge to traditional security mechanisms, and may affect their performance and effectiveness. Therefore, the research for a new IPv6 firewall architecture is quite necessary. Currently, the v6ops workgroup at IETF have proposed some drafts about IPv6 transition security [RFC4942], and researches on a proper and comprehensive solution mechanism are being carried out. o Address Management Module. This module provides a communication path between Application Interface layer and Network Interface layer. When a host is connected to a network, addresses acquired from the network will be passed to this module from the NI layer. When DNS module in the AI layer sends a DNS request, this module will return the correct address according to the requirements. For some transition mechanisms like DSTM, hosts should ask a server for an IP address. This address application process is actually carried out in the NI layer, but the triggering of such a process is handled by this module. Aside from these modules, we can also insert many other modules that correspond to some IPv6 features. Like mobility, configuration, multi-homing, etc. With the development of IPv6 protocol, new modules can be continuously added into this layer, and provide better services for the users. 4.3. Network Interface (NI) layer Network interface (NI) layer performs actual data packet transfer. So its main task is to find a proper way to deliver packets according to different network environments. The modules in this layer are shown in Figure 4. Bi, et al. Expires July 10, 2009 [Page 12] Internet-Draft Univer6 Architecture for IPv6 Transition Jan 2009 +-----------------------------------------------------------+ | +--------+ +--------+ +---------------------------------+ | | | | | | |Access/Transfer Method Management| | | | | | | +---------------------------------+ | | | IP | | Network| | | |Address | |Environ-| | | |Acquire/| | ment | +--------+ +--------+ +--------+ | | | Apply | | Detect | | Tunnel | | Overlay| | Direct | | | | | | | | Access/| | Access/| | Access/| | | | | | | |Transfer| |Transfer| |Transfer| | | +--------+ +--------+ +--------+ +--------+ +--------+ | +-------------/---|---\-------------------------------------+ / | \ / | \ +-------+ +-------+ +-------+ | IPv4 | | Dua | | IPv6 | | Native| | stack | | Native| |Network| |Network| |Network| +-------+ +-------+ +-------+ Figure 4. Network Interface (NI) layer Network environment detection module detects the host's network environment. During different stages of transition, transition mechanisms may change from time to time. Network equipments may be upgraded or changed, and some functions may be turned on / off. Meanwhile, a mobile host like notepad may be located in different kinds of networks at different time. All these situations call for an environment detect module. This module will gather information from the lower layers, including IP protocol in use, IP address, and transition strategy. This information is then provided to other modules to make proper decisions. Generally speaking, when a user is connected to a network, the network environment will not change very frequently (for mobile users in wireless LAN, the situation may be a little different). So, the network environment detection module only has to detect once at the beginning of network access, and periodically check the environment change at a lower frequency after that. Access / transfer management module is the most important module in this layer. It will choose proper strategies to carry out IPv6 access and data packet transfer. Basically, there are three kinds of IPv6 access and data transfer: direct access / transfer, tunnel access / transfer, and overlay access / transfer. When a host is located in an IPv6 native network, or a dual stack network that connects to IPv6 backbone network, the direct access mechanism can be used, and data packets are sent in the form of IPv6. If the host is in an IPv4 network, some mechanisms like configured tunnel or 6to4 Bi, et al. Expires July 10, 2009 [Page 13] Internet-Draft Univer6 Architecture for IPv6 Transition Jan 2009 [RFC3056] will be needed to gain access to IPv6 network. IPv6-in- IPv4 tunnel is the most common mechanism today, and data packets are sent through such tunnels in the form of IPv6-in-IPv4 packets. In the early stage of transition, groups of medium-sized IPv6 enterprise / ISP networks will be located around the world. The separated networks seem like a group of IPv6 islands distributed in the Internet, so an overlay mechanism can be introduced to connect them with each other, and to the IPv6 backbone network. In a nutshell, most existing transition mechanisms can be integrated into this module and used for suitable scenarios. As for the automatic network environment detection mechanism, the v6ops workgroup in IETF has proposed some guidelines and possible solutions [draft-palet-v6ops-auto-trans-02]. These guidelines and solutions can be used to help make final standards of the access / transfer module. IP address acquire / apply module is another useful module in the network interface layer. On one hand, when a host gets connected to a network, this module will collect the address information of the host, and provide both IPv6 and IPv4 addresses (if any) to the management module in the upper layer. On the other hand, if the host is located in an IPv6 native network and needs to communicate with another host using IPv4, mechanisms like DSTM will be needed to apply for a temporary IPv4 address from the server. IP address acquire / apply module will send out such requests to the server, and deal with possible authentication / responses from the server. Also, if two hosts are both located in IPv6 native networks, but the applications on them use IPv4 protocol, it is necessary for both of them to find a way to assign an IPv4 address for each other. We have designed a protocol to carry out IPv4 address negotiation between two IPv6 hosts, and this protocol will also be integrated into the IP address acquire / apply module. Bi, et al. Expires July 10, 2009 [Page 14] Internet-Draft Univer6 Architecture for IPv6 Transition Jan 2009 5. The challenges We have described Univer6 and its modules in detail. In order to improve the features of Univer6 and put it into real use, there are still some issues to be considered in the future: o Module Standardization. Currently, many transition mechanisms have been proposed, and some of them are being deployed and used in different networks. During the design of Univer6, it will be very helpful to consider these existing mechanisms, and try to make Univer6 compliant with them. Research on other mechanisms will also provide some useful tips for designing a better architecture, and make the final standards of Univer6 more comprehensive. o Security. As mentioned in the previous sections, the security issues exist not only in IPv6 itself, but also in IPv6 transition. Security research on IPv6 like firewall is still at an early stage, as it goes on, many new features will start to come up. Also, existing IPv4 mechanisms should be taken into consideration. So, it is an important issue to design a flexible security module for Univer6. o Application Mode. Nowadays, most IPv6 applications come from simply upgraded IPv4 applications. If the new features of IPv6 protocol can be fully researched and brought into use, it will greatly accelerate IPv6 transition. Univer6 uses IPv6 as a unified middle layer, and we will try to provide new application modes based on it. For example, after we deploy address validation mechanism in the network, each host can be identified by its own IPv6 address, and source address information in the IP header can be used to provide different kinds of services. We are planning to design a mechanism to provide different levels of QoS (Quality of Service) for different types of IPv6 addresses. We can use 4 to 8 bits in the IPv6 address as a sign for different user levels and kinds of application types. Network administrators and ISP's can make necessary adjustments on the routers to optimize the transfer process according to different flow types. This will provide a better user experience, as well as improve the network management process. Bi, et al. Expires July 10, 2009 [Page 15] Internet-Draft Univer6 Architecture for IPv6 Transition Jan 2009 6. IANA Considerations This document makes no request of IANA. Bi, et al. Expires July 10, 2009 [Page 16] Internet-Draft Univer6 Architecture for IPv6 Transition Jan 2009 7. Security Considerations TBD Bi, et al. Expires July 10, 2009 [Page 17] Internet-Draft Univer6 Architecture for IPv6 Transition Jan 2009 8. References 8.1. Normative References [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. [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ Co-existence Security Considerations", RFC 4942, September 2007. 8.2. Informative References [draft-baker-sava-simple-00] Baker, F., "Simple Source Address Validation", Mar 2007. [draft-palet-v6ops-auto-trans-02] Palet, J., Diaz, M., and M. Mackay, "Evaluation of IPv6 Auto-Transition Algorithm", Oct 2004. [draft-wu-sava-testbed-experience-06] Wu, J. and J. Bi, "SAVA Test-bed and Experiences to Date", May 2008. Bi, et al. Expires July 10, 2009 [Page 18] Internet-Draft Univer6 Architecture for IPv6 Transition Jan 2009 Authors' Addresses Jun Bi Tsinghua University FIT 3-212 Beijing 100084 P.R.C Phone: +86-10-62795818-6270 Email: junbi@tsinghua.edu.cn You Wang Tsinghua University FIT 4-204 Beijing 100084 P.R.C Email: wangyou@netarchlab.tsinghua.edu.cn Xiangbin Cheng Tsinghua University FIT 4-204 Beijing 100084 P.R.C Email: cxb@netarchlab.tsinghua.edu.cn Bi, et al. Expires July 10, 2009 [Page 19]