Clouds H. Yokota Internet-Draft KDDI Lab Intended status: Standards Track F. J. Lin Expires: April 21, 2011 Telcordia Technologies A. Dutta NIKSUN C. Williams MCSR Labs October 18, 2010 Service Mobility for Virtualized Networks draft-yokota-cloud-service-mobility-00.txt Abstract Network virtualization technique leveraged by a virtual machine makes it possible to dynamically relocate functional entities without topological and physical constraints. By tapping into this technique, service mobility, which deals with not only functional entities but also sessions established between those entities, will become possible and such capability is especially longed for realizing more scalable and reliable telecom networks. This document provides the reference model for service mobility in a virtual environment and defines the control protocol between the virtualized platform and the managing controller to realize service mobility. 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 21, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. Yokota, et al. Expires April 21, 2011 [Page 1] Internet-Draft Service Mobility for Virtualized Networks October 2010 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. Yokota, et al. Expires April 21, 2011 [Page 2] Internet-Draft Service Mobility for Virtualized Networks October 2010 Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview and Terminology . . . . . . . . . . . . . . . . . . . 6 4. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 9 5. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. Common header format . . . . . . . . . . . . . . . . . . . 12 5.2. Control messages . . . . . . . . . . . . . . . . . . . . . 14 5.2.1. REGISTRATION . . . . . . . . . . . . . . . . . . . . . 14 5.2.2. KEEP-ALIVE . . . . . . . . . . . . . . . . . . . . . . 14 5.2.3. OPERATION . . . . . . . . . . . . . . . . . . . . . . 14 5.2.4. STATUS-UPDATE . . . . . . . . . . . . . . . . . . . . 15 5.2.5. DE-REGISTRATION . . . . . . . . . . . . . . . . . . . 15 5.2.6. ACK . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.3. Operation commands . . . . . . . . . . . . . . . . . . . . 16 5.3.1. GET Operation . . . . . . . . . . . . . . . . . . . . 16 5.3.2. ADD Operation . . . . . . . . . . . . . . . . . . . . 16 5.3.3. DELETE Operation . . . . . . . . . . . . . . . . . . . 17 5.3.4. MOVE Operation . . . . . . . . . . . . . . . . . . . . 17 5.3.5. COPY Operation . . . . . . . . . . . . . . . . . . . . 18 5.3.6. MOVE_SESSION Operation . . . . . . . . . . . . . . . . 19 5.4. Option values . . . . . . . . . . . . . . . . . . . . . . 19 5.4.1. IPv4 address . . . . . . . . . . . . . . . . . . . . . 19 5.4.2. IPv6 address . . . . . . . . . . . . . . . . . . . . . 20 5.4.3. Port number . . . . . . . . . . . . . . . . . . . . . 20 5.4.4. Node ID . . . . . . . . . . . . . . . . . . . . . . . 20 5.4.5. Function ID . . . . . . . . . . . . . . . . . . . . . 20 5.4.6. Node information . . . . . . . . . . . . . . . . . . . 20 5.4.7. Function information . . . . . . . . . . . . . . . . . 21 5.4.8. Session information . . . . . . . . . . . . . . . . . 21 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 8.1. Normative references . . . . . . . . . . . . . . . . . . . 25 8.2. Informative references . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Yokota, et al. Expires April 21, 2011 [Page 3] Internet-Draft Service Mobility for Virtualized Networks October 2010 1. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Yokota, et al. Expires April 21, 2011 [Page 4] Internet-Draft Service Mobility for Virtualized Networks October 2010 2. Introduction There is a growing consensus that a significant number of services will be delivered using a cloud-computing model. These applications and services will be hosted in data centers located in various parts of the network. New services will be instantiated by deploying a service delivery system in a dynamic manner such that the network and data center resources are allocated dynamically. At the same time, telecom networks are moving toward all-IP based systems such as 3GPP SAE (System Architecture Evolution), IMS (IP Multimedia Subsystem) and SDP (Service Delivery Platform), whereby the transport and services are being handled by IP technology. These systems are composed of a number of components or functional entities connected with each other, which makes the whole telecom network even more complex. Wide variety of services ranging from conventional voice, gaming to Web2.0 type of ones such SNS (Social Network Service), are being introduced and the number of users is also dynamically changes. In such environments, the telecom network needs to scale on demand with efficient use of infrastructure as well as to improve reliability and availability. It is imperative that such ever-evolving new services be seen by the user as having no delay and can be accessed from anywhere with high reliability. If service components or functional entities in the telecom networks (e.g., call control function or policy control function) can be located and moved without any topological or geographical constraint, higher reliability can be achieved than conventional redundancy systems. By tapping into cloud-computing technology, telecom network deployed in a virtualized environment (or virtualized telecom network), will be able to scale telecom services on demand, to improve reliability and availability and to efficiently use the infrastructure [IMSAA09]. One of the key features provided by the virtualized telecom network is service mobility. A general property of service mobility is to ensure it is transparent to service user, that is, the on-going service must be continued in a transparent manner and existing protocols or interfaces should not be affected. This document provides the reference model for service mobility in a virtual environment and defines the control protocol between the virtualized platform (e.g., virtual machines) and the managing controller to enable service mobility. Yokota, et al. Expires April 21, 2011 [Page 5] Internet-Draft Service Mobility for Virtualized Networks October 2010 3. Overview and Terminology The components in the virtualized network include "Manager Node", "Execution Node" and optional "Information Server". The management role for the execution nodes can be realized in both a centralized way as well as a distributed (Peer-to-peer) way. The Execution node is a physical or virtual machines on which target functions (software) are running. For example, in the context of IMS (IP Multimedia Subsystem), the CSCF (Call Session Control Function) and HSS (Home Subscriber Server) are candidates of such functions. Information servers include DHCP, DNS, etc. Use for discovery and assignment of execution node for a session (Proxy-CSCF at a UE's registration). Execution Node: Logical entity that can execute functions. A well-know example is a virtual machine or VM. Manager Node: Logical entity that manages functions running on the execution nodes. Information Server: A server used for discovery of Manager Node or Execution Node via IETF standardized protocols (e.g., DNS server or DHCP server). This entity is so far outside the scope of this document's specifications. Function: Logical unit that provides a specific service such as "authentication" or "call control" Session: Relationship between functions providing a specific service. Each function maintains a state related to the session. Service mobility: Capability to move function(s) among execution nodes with maintaining the ongoing service. Node ID: Uniquely identifies the execution node, which provided and managed by the manager node. Function ID: Uniquely identifies the function, which is provided and managed by the manager node. Yokota, et al. Expires April 21, 2011 [Page 6] Internet-Draft Service Mobility for Virtualized Networks October 2010 The reference model for service mobility is shown in Figure 1. The service user on the upper layer utilizes service units provided by the service provider via the service access point (SAP). By interacting with the management plane, the service unit may move its physical or topological location. This movement must be transparent to the service user meaning that the on-going service must be continued. Existing protocols and interfaces should not be affected by this capability. +-----------------------------------+ +-------+ | | | | | Service User | | | | | | | | | | | | Cloud | +-------------| SAP |-------------+ | Mgmt | | | | | | | |+-------+ +-------+ +-------+| | | ||Service| |Service| <...> |Service||<==>| | || Unit | | Unit | | Unit || | | |+-------+ +-------+ +-------+| | | | Service Provider | | | +-----------------------------------+ +-------+ Figure 1: Reference model Service mobility in the virtual environment is depicted in Figure 2. The virtual environment provides the capability to move execution nodes among physical hardware. An execution node can run on one physical hardware unit (e.g., a server machine) or on multiple hardware units. How the virtual environment is provided is outside the scope of this document. Functions run on the execution nodes and one or more session(s) may be established with the corresponding status information. When functions and/or sessions move from one execution node to another, consistency in the status information must be maintained to continue the sessions. Yokota, et al. Expires April 21, 2011 [Page 7] Internet-Draft Service Mobility for Virtualized Networks October 2010 ^ Session ^ * ******************* * +-----*------*-----+ +---------*-----*-----------+ | (Status) * | | (Status)* | | +-*+ * | | +--+ +*-+ * +--+ | | |FN|*** <.........> |FN| |FN|* |FN| | | +--+ | | +--+ +--+ +--+ | | +-------------+ | | +---------+ +---------+ | | | Execution | | | |Execution| |Execution| | | |Node(e.g.,VM)| | | | Node | | Node | | | +-------------+ | | +---------+ +---------+ | +------------------+ +---------------------------+ ^ ^ | | Physical hardware FN=Function VM=Virtual Machine Figure 2: Service mobility in virtual environment The roles of the manager node and execution nodes and their relationship are depicted in Figure 3. The manager node communicates with the execution nodes to control the mobility of functions. The manger node can be deployed in a centralized or distributed fashion; however, that must be transparent to the execution nodes. The execution nodes communicate with each other to move functions between the nodes. An external information server or repository may be involved to support those nodes to discover other nodes. The main focus of this document is the control protocol between the manager node and execution nodes. +----------------+ ............. | Manager Node |<......>:Information: | (Cloud Mgmt) | : Server : +----------------+ :...........: / \ ^ / \ : v v : +---------+ +---------+ : |Execution| |Execution|<.........: | Node | | Node | +---------+ +---------+ ^ ^ :..............: Figure 3: Roles and relationship between components Yokota, et al. Expires April 21, 2011 [Page 8] Internet-Draft Service Mobility for Virtualized Networks October 2010 4. Protocol Operations Figure 4 shows the signaling flow between the manager and execution nodes. When the execution node boots up, it registers itself with the manger node by sending the Registration message. The manager node may periodically check the status of each registered execution node by sending the Keep-Alive message. According to the situation on the execution nodes, the manager node sends various types of operation commands to the execution node. If the status of the execution node changes, it sends the Status-Update message to the manager node. Finally, if the execution node goes out of the scope of the management by the manager node or is going to be shut down, it sends the De-registration message to the manager node. For each message, the recipient MUST send back the ACK message. Execution Manager Node Node | | | Registration | |------------------------>| | Ack | |<------------------------| | | | Keep-Alive | |<------------------------| | Ack | |------------------------>| | | | <*> Operation | |<------------------------| | Ack | |------------------------>| | | | Status-Update | |------------------------>| | Ack | |<------------------------| | | | De-registration | |------------------------>| | Ack | |<------------------------| | | Figure 4: Signaling flow between the manager and execution nodes Yokota, et al. Expires April 21, 2011 [Page 9] Internet-Draft Service Mobility for Virtualized Networks October 2010 In this document, the following control messages are defined: Registration: Used for the execution node to register itself with the manager node, by which the execution node goes under the control of the manager node. Keep-Alive: Used for the manager node to check the status of the managed execution node. Operation: Used for the manager node to indicate the execution node to do a specific action to the function or sessions on that execution node. Status-Update: Used for the execution node to notify the manager node on the updated status. De-registration: Used for the execution node to release the registration from the manager node. The manager node can also send this message to the execution node to force de-registration. Ack: Used to respond to the above messages for acknowledgment and returning requested information and/or status code (success or failure). Further, the following operations are defined: GET operation: Used for the manager node to obtain specific information from the target execution node. ADD operation: Used to instruct the target execution node to run a new function. DELETE operation: Used to instruct the target execution node to terminate a running function. MOVE operation: Combination of ADD and DELETE operation, but the status information on the related function is also passed to a new execution node. Yokota, et al. Expires April 21, 2011 [Page 10] Internet-Draft Service Mobility for Virtualized Networks October 2010 COPY operation: Similar to ADD operation, but the status information on the related function is also passed to a new execution node. MOVE_SESSION operation: Used to instruct the target execution node to move sessions to another execution node. Yokota, et al. Expires April 21, 2011 [Page 11] Internet-Draft Service Mobility for Virtualized Networks October 2010 5. Message Format 5.1. Common header format Figure 5 shows the common header format for all messages. 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 | Sub-Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : Options : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : ... : | | Figure 5: Common header format Type Control message type. In this document, the following operations are defined: Registration (1)/Keep-alive (2)/Operation (3)/Status-Update (4)/De-registration (5)/Ack (6). Sub-Type If the Type value is 3 (Operation) or 6 (Ack), the Sub-type represents the operation command. Otherwise, this value MUST be zero and ignored by the receiver. Length 8-bit unsigned integer indicating the length of the whole message in octets, excluding the type, length and reserved fields. Reserved This field is unused for now. The value MUST be initialized to 0 by the sender and MUST be ignored by the receiver. Yokota, et al. Expires April 21, 2011 [Page 12] Internet-Draft Service Mobility for Virtualized Networks October 2010 Code An 8-bit unsigned integer used for containing the status code in the Ack message. For the other message, this field MUST be filled with zero and ignored by the receiver. Sequence Number A 24-bit unsigned integer used by the receiving node to sequence the operation command and by the sending node to match a returned Acknowledgement with this operation command. Options Variable-length field that contains a command message and/or one or more option(s). Figure 6 shows the TLV-encoded option format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OP-Type | Sub-OP-Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : Value : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Option format OP-Type 8-bit unsigned integer indicating the type of the option value. Sub-OP-Type 8-bit unsigned integer indicating the sub-type of the option value. MUST be set to zero if not defined. Length 8-bit unsigned integer indicating the length of the option in octets, excluding the OP-Type, Sub-OP-Type, Length and Reserved fields. Yokota, et al. Expires April 21, 2011 [Page 13] Internet-Draft Service Mobility for Virtualized Networks October 2010 Reserved This field is unused for now. The value MUST be initialized to 0 by the sender and MUST be ignored by the receiver. Value value for the specified option type is contained. 5.2. Control messages 5.2.1. REGISTRATION Type: 1 Mandatory options: o Node ID Additional options: o Node Information 5.2.2. KEEP-ALIVE Type: 2 Mandatory options: o Node ID Additional options: o Node Information o Function ID o Function Information 5.2.3. OPERATION Type: 3 Sub-Type: Requested operation (See Section 5.3) Mandatory options: Yokota, et al. Expires April 21, 2011 [Page 14] Internet-Draft Service Mobility for Virtualized Networks October 2010 o Node ID 5.2.4. STATUS-UPDATE Type: 4 Mandatory options: o Node ID Additional options: o Node Information o Function ID o Function Information 5.2.5. DE-REGISTRATION Type: 5 Mandatory options: o Node ID 5.2.6. ACK Type: 6 Sequence number: MUST be copied from the corresponding control message. Sub-Type: MUST be copied from the corresponding control message. Code: Result code for the requested operation. In this document, the following code values are defined: 0: Successful 128: Failed 129: Insufficient resources 130: Administratively prohibited Yokota, et al. Expires April 21, 2011 [Page 15] Internet-Draft Service Mobility for Virtualized Networks October 2010 131: Status unknown Mandatory options: o Node ID 5.3. Operation commands 5.3.1. GET Operation Type: 3 Sub-Type: 1 Mandatory options: o Node ID o Function ID o List of options (with zero values in the value field) Expected options in ACK: o Node ID o Function ID o List of options (with non-zero values in the value field) o Result Code o Running Status 5.3.2. ADD Operation Type: 3 Sub-Type: 2 Mandatory options: o Node ID o Function Name Yokota, et al. Expires April 21, 2011 [Page 16] Internet-Draft Service Mobility for Virtualized Networks October 2010 o Function ID Some function takes time to boot up, thus when it successfully booted up, the execution node sends Status-update message to the manager node. Expected options in ACK: o Node ID o Function ID o Result Code o Running Status 5.3.3. DELETE Operation Type: 3 Sub-Type: 3 Mandatory options: o Node ID o Function ID Expected options in ACK: o Node ID o Function ID o Result Code o Running Status Some function takes time to terminate, thus when termination is completed, the execution node sends Status update message to the manager node. 5.3.4. MOVE Operation Type: 3 Sub-Type: 4 Yokota, et al. Expires April 21, 2011 [Page 17] Internet-Draft Service Mobility for Virtualized Networks October 2010 Mandatory options: o Source Node ID o Destination Node ID o Function ID Expected options in ACK: o Source Node ID o Destination Node ID o Function ID o Result Code o Running Status The source Node ID and destination Node ID MUST be listed in this order. 5.3.5. COPY Operation Type: 3 Sub-Type: 5 Mandatory options: o Source Node ID o Destination Node ID o Function ID Expected options in ACK: o Source Node ID o Destination Node ID o Function ID Yokota, et al. Expires April 21, 2011 [Page 18] Internet-Draft Service Mobility for Virtualized Networks October 2010 o Result Code o Running Status The source Node ID and destination Node ID MUST be listed in this order. 5.3.6. MOVE_SESSION Operation Type: 3 Sub-Type: 6 Mandatory options: o Source Node ID o Destination Node ID o Session information Additional options: o Function ID Expected options in ACK: o Function ID, if specified in the corresponding operation command. o Result Code o Running Status The source Node ID and destination Node ID MUST be listed in this order. When Function ID is specified, all the sessions related to that Function ID are the target for movement. 5.4. Option values In this document, the following attributes are defined. Sub-OP-type MUST be set zero if not defined. 5.4.1. IPv4 address OP-Type: 1 Length: 4 Yokota, et al. Expires April 21, 2011 [Page 19] Internet-Draft Service Mobility for Virtualized Networks October 2010 Value: Unsigned integer. IPv4 address (e.g., for the target execution node) 5.4.2. IPv6 address OP-Type: 2 Length: 16 value: Unsigned integer. IPv6 address (e.g., for the target execution node) 5.4.3. Port number OP-Type: 3 Length: 2 value: Unsigned integer. Port number (e.g., for the target session) 5.4.4. Node ID OP-Type: 4 Length: 4 Value: Unsigned integer. Node ID for the target execution node 5.4.5. Function ID OP-Type: 5 Length: 4 Value: Unsigned integer. Function ID for the target function 5.4.6. Node information OP-Type: 6 Length: variable Value: Octet string. Node information specified by the Sub-OP-Type. In this document, the following types are defined: Yokota, et al. Expires April 21, 2011 [Page 20] Internet-Draft Service Mobility for Virtualized Networks October 2010 Sub-OP-Type 1: Processing capacity (GHz) 2: Current load (number of waiting processes) 3: Average load (number of waiting processes) 10: Total memory size (byte) 11: Available memory size (byte) 20: Total storage size (byte) 21: Available storage size (byte) 30: Total bandwidth (bps) 31: Current used bandwidth (bps) 32: Average used bandwidth (bps) 40: Boot time (NTP timestamp format) 5.4.7. Function information OP-Type: 7 Length: variable Value: Octet string. Used to describe the type or status of the function. In this document, the following values are defined: Sub-OP-Type 1: Function name (e.g., "P-CSCF" or "HSS") 2: Current load (number of waiting processes) 3: Average load (number of waiting processes) 10: Required memory size (byte) 11: Available memory size (byte) 20: Required storage size (byte) 21: Available storage size (byte) 31: Current used bandwidth (bps) 32: Average used bandwidth (bps) 40: Boot time (NTP timestamp format) 50: Running status ("Starting", "Running", "Terminating" or "Unknown") 5.4.8. Session information OP-Type: 8 Length: variable Value: Octet string to represent one or group of session(s). This value MUST be understood by both the manager and execution nodes. In this document, the following values are defined: Yokota, et al. Expires April 21, 2011 [Page 21] Internet-Draft Service Mobility for Virtualized Networks October 2010 Sub-OP-Type 1: SIP URI (e.g., sip:alice@example.com) 2: Contact address (IPv4 or v6 address) 3: the ratio to the whole sessions (e.g., 0.3) 4: the number of sessions (e.g., 1000) Yokota, et al. Expires April 21, 2011 [Page 22] Internet-Draft Service Mobility for Virtualized Networks October 2010 6. IANA Considerations This specification requests one TCP and SCTP port number for exchanging the defined control messages. Yokota, et al. Expires April 21, 2011 [Page 23] Internet-Draft Service Mobility for Virtualized Networks October 2010 7. Security Considerations It is assumed that necessary level of security between the manager node and execution nodes is provided by other means and a secure connection between them is not mandated in this document. Yokota, et al. Expires April 21, 2011 [Page 24] Internet-Draft Service Mobility for Virtualized Networks October 2010 8. References 8.1. Normative references [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative references [IMSAA09] Dutta, A., Makaya, C., Das, S., Chee, D., Lin, F., Komorita, S., Chiba, T., Yokota, H., and H. Schulzrinne, "Self Organizing IP Multimedia Subsystem", IEEE IMSAA, December 2009. Yokota, et al. Expires April 21, 2011 [Page 25] Internet-Draft Service Mobility for Virtualized Networks October 2010 Authors' Addresses Hidetoshi Yokota KDDI Lab 2-1-15 Ohara, Fujimino Saitama, 356-8502 JP Email: yokota@kddilabs.jp Fuchun J. Lin Telcordia Technologies One Telcordia Drive Piscataway, NJ 08854-4157 US Email: fjlin@research.telcordia.com Ashutosh Dutta NIKSUN 100 Nassau Park Boulevard, Princeton, NJ 08540 US Email: ashutosh.dutta@ieee.org Carl Williams MCSR Labs Palo Alto, CA 94306 US Email: carlw@mcsr-labs.org Yokota, et al. Expires April 21, 2011 [Page 26]