Network working group L. Yong Internet Draft Huawei Category: Informational M. Toy Comcast A. Isaac Bloomberg V. Manral Hewlett-Packard Expires: December 2012 June 22, 2012 Use Cases for DC Network Virtualization Overlays draft-mity-nvo3-use-case-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. This Internet-Draft will expire on November 30, 2012. Copyright Notice Copyright (c) 2009 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 MITY Expires November 2012 [Page 1] Internet-Draft NVO3 Use Case June 2012 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This draft describes NVO3 use cases. The framework draft [NVO3FRWK] layouts the NVO3 architecture reference model, functional modules, and NVO3 and VPN interworking aspects and challenges. This draft presents the use cases that help in validating the framework and requirements as well as the solution development. Conventions used in this document 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 RFC-2119 [RFC2119]. Table of Contents 1. Introduction...................................................3 2. Terminology....................................................4 3. Multiple virtual networks across multiple DCs..................4 4. Interconnection of DC Virtual Network and Carrier VPN..........6 4.1. One virtual network method across DCs and WAN networks....6 4.2. NVO3 and VPN Interconnections between DC and WAN networks.7 5. Cloud Services Using NVO3......................................9 5.1. Public Cloud Service......................................9 5.2. Private Cloud Service....................................10 5.3. Virtual Data Center......................................11 6. OAM Considerations............................................13 7. Summary.......................................................13 8. Security Considerations.......................................14 9. IANA Considerations...........................................14 10. Acknowledgements.............................................14 11. References...................................................14 11.1. Normative References....................................14 11.2. Informative References..................................15 Authors' Addresses...............................................15 MITY Expires December 2012 [Page 2] Internet-Draft NVO3 Use Case June 2012 1. Introduction This document provides the use cases for Network Virtualization Overlay, i.e. NVO3, which is driven by Data Center Networks. These use cases are intended to help in validating the framework and requirements as well as the solution development. The advent of the hypervisor eliminated the tight coupling of an endpoint from the physical computer on which it ran. This change has allowed the physical computer to become a service point rather than a client. The goal of NVO3 is to no longer treat the physical computer as a client of the network but as a native service point of the network. Although overlay networks have been around for many years, hypervisor-aware overlay networks have certain characteristics that are suited for the DC environment. The main characteristic difference between other overlay network technology and NVO3 is that the client edges of the NVO3 network are individual virtualized hosts and not network sites or LANs. Other differentiating characteristics include (1) the potential for lower overall costs when compared to comparable network-based overlays, (2) better loop- free scaling over traditional DC network virtualization solutions (3) better virtual host access and mobility. The NVO3 framework [NVO3FRWK] provides the architecture reference model, functional modules, and the overlay/underlying network aspects, which empowers Data Center service designs. Data Center service is to provide applications and/or virtual compute and/or storage and networking. The key requirements for Data Center service networks are to enable secure, virtual, and segregation networks that are highly scalable in number and size, native extension of these virtual networks to the virtual interface of virtual machines, flexible operator-defined virtual network topologies, natural interconnection of networks and interposing of network services, and the simple and rapid enablement of network access and services. Either an L3 or L2 virtual network instance can be constructed over the underlying networks. Use cases for the NVO3 framework [NVO3FRWK] can be highly varied. This document outlines some basic scenarios and groups them into three set. One set of NVO3 use cases is connecting many, many tenant end systems in one and/or multiple DC sites and forming an L2 or L3 communication domain. Using overlay tenant virtual network instances MITY Expires December 2012 [Page 3] Internet-Draft NVO3 Use Case June 2012 segregate the traffic from different tenants, allows each tenant instance having its own address space and isolating the space from DC infrastructure. In addition, support VM move. The second set of NVO3 use cases is for a DC provider to offer a secure DC service to an enterprise customer. In these cases, the enterprise customer may use a traditional L3/L2 VPN provided by a carrier connecting to an overlay virtual network instance offered by a Data Center provider, and offload its applications on to the servers located in provider Data Center sites. The third set of NVO3 use cases is to enable DC provider design various cloud services through the applications, compute, storage, and the networking. In this case, NVO3 provides the networking functions of a service rather than the service itself. 2. Terminology This document uses the terminologies defined in [NVO3FRWK], [RFC4364]. Some additional terms used in the document are listed here. VNIF: VNI Interconnection Interface on an NVE L2 VPI: L2 Virtual Network Instance L3 VNI: L3 Virtual Network Instance ARP: Address Resolution Protocol DNS: Domain Name Service NAT: Network Address Translation 3. Multiple virtual networks across multiple DCs A DC operator may have multiple DC sites for space, regional proximity, availability or other reasons. The DC operator may furthermore require the ability to group and segregate end systems at the network level to securely host customer or internal end systems. To satisfy these requirements, the DC operator may choose the NVO3 to interconnect and segregate end systems within and/or across his DC sites. In this scenario, the DC operator is required to span a single NVO3 instance to interconnect end-systems across multiple DCs. The NVO3 instance may be an L2 or L3 based virtual network instance. MITY Expires December 2012 [Page 4] Internet-Draft NVO3 Use Case June 2012 Figure 1 depicts NVE1 and NVE2 in two DC locations, respectively. Each NVE are configured with multiple virtual network instances that have different topologies. In this illustration, three virtual network instances with VN context Ta, Tn, and Tm are shown. VNIa terminates on both NVE1 and NVE2; VNIn terminates on NVE1 and VNIm at NVE2 only. In general, each NVE has one overlay module to perform frame encapsulation/decapsulation and tunneling initiation/termination. It is possible that two NVO3 instances use different encapsulation and/or tunneling schemes, thus more than one overlay modules on an NVE may be required. In this scenario, the end-to-end tunneling between NVE1 and NVE2 is necessary for the VNIa and consists of intra and inter DC tunnels. The tunneling may in turn be tunneled over other intermediate tunnels over the Internet or other WAN. It is also possible that intra DC and inter DC tunnels are stitched together to form an end- to-end tunnel between two NVEs.[PION] Note: if both NVE1 and NVE2 are in the same DC, only intra DC tunnel is necessary. An VNI terminated on an NVE may locally associate to one or more VAPs each of which may associate with one of more TESs. It is possible that the VNI does not attach to any VAP (see section 5). One VAP associates to one VNI terminated on an NVE. One tenant virtual network instance may terminate on many NVEs and interconnect several thousands of TESs across multiple DC sites, the ability of supporting a large number of TESs per tenant instance is critical for NVO3 solution. +------- L3 Network ------+ | Tunnel Overlay | +------------+--------+ +--------+-------------+ | +----------+------+ | | +------+----------+ | | | Overlay Module | | | | Overlay Module | | | +---+---------+---+ | | +--+----------+---+ | | |Ta |Tn | | |Ta |Tm | | +--+---+ +--+---+ | | +-+----+ +--+---+ | | | VNIa |..| VNIn | | | | VNIa |..| VNIm | | NVE1 | ++----++ ++----++ | | ++----++ ++----++ | NVE2 | |VAPs| |VAPs| | | |VAPs| |VAPs| | +---+----+----+----+--+ +---+----+----+----+---+ | | | | | | | | ------+----+----+----+------ -----+----+----+----+----- | .. | | .. | Tenant | .. | | .. | | | | | Service IF | | | | Tenant End Systems Tenant End Systems MITY Expires December 2012 [Page 5] Internet-Draft NVO3 Use Case June 2012 DC Site A DC Site Z Figure 1 NVo3 for DC interconnection Individual virtual network instances may use its own address space and the space is isolated from DC infrastructure. This eliminates IP subnet constraints in the infrastructure when moving VMs. Note: the NVO3 solution still have to address the discovery of VM move. 4. Interconnection of DC Virtual Network and Carrier VPN In this scenario, the enterprise customer utilizes the DC provider's compute and storage resources to run its applications, and the DC provider allows the customer to access his hosted end systems through a Carrier WAN. This use case requires a tenant instance in the DC to interconnect with a carrier VPN for customer access. The enterprise customer may also utilize the Carrier's VPN to connect its corporate locations, and/or the DC provider's locations where his tenant instance exists. The DC provider creates a tenant instance for the enterprise customer that interconnects all the VMs and storage resources allocated to the customer. The customer unique instance provides the customer with traffic segregation from other customers and free selection of the address space. Both DC VNI and carrier VPN instance can run at either L2 or L3. 4.1. One virtual network method across DCs and WAN networks If both DC Provider and Carrier use the same encapsulation and tunneling technology, it is possible to configure one overlay virtual network instance across DC networks and Carrier networks. For example, if both DC provider and Carrier use existing MPLS-based VPN solutions [RFC4364] and IP tunnel, the NVE in DC and the PE in WAN can be members of one VN instance. Figure 2 illustrates this scenario. The left side of the figure presents a NVE (NVE1) in DC Provider site and the right shows Provider Edge (PE1) in a WAN network connecting to Customer Edge (CE) at an Enterprise site. The CE is often a network site and contains routers and/or switches and terminal systems. In this case, an L3 VNI and L3VPN instance are configured on NVE1 and PE1, respectively. If the MPLS label is used as VN context/VPN identifier and IP tunnel is established between NVE1 and PE1, the configuration will provide the L3 connectivity between a TES and CE. The MPLS label for the L3 VNI identifier (Ta) on NVE1 can be different from the MPLS label for the L3VPN identifier (VPNID) on PE1 since MPLS labels are locally significant. Although the figure MITY Expires December 2012 [Page 6] Internet-Draft NVO3 Use Case June 2012 shows Overlay Module on NVE1 and Encap/Decap (Encapsulation/Decapsulation) on PE1, both perform the same functions; it is just matter of using different terminologies in NVO3 framework [NVO3FRWK] and L3VPN [RFC4364]. The DC and WAN networks may belong to different ASs, control plane protocol or management plane can facilitate the VN configuration. Note: A TES is an end system, not a network site as the CE in figure 2; more than likely it does not run any routing protocol. Thus the routing between NVE1 and TES are static routing, which may be done by the API or software assisted configuration in a secured way. Routing and forwarding between NVE1 and PE1 and between PE1 and CE are specified in RFC4364 [RFC4364]. ) DC ( WAN ) +----------- IP tunnel -------+ | ( | | ) | +--------+------------+ ( +-------+--------+ | +------+----------+ | | +-----+------+ | | | Overlay Module | | | | Encap/Decap| | | +--------+--------+ | | +-----+------+ | | |Ta | | |VPNID |PE1 | | | | +---+---+ | | +-------+-------+ | | | VRF | | | | L3 VNI | | | +---+---+ | NVE1 | +-+-----------+-+ | +-------+--------+ | | VAPs | | | +----+-----------+----+ | | ... | Customer Edge (CE) Tenant End Systems DC Provider Site Enterprise Site Figure 2 One VN solution across DCs and Carrier Networks 4.2. NVO3 and VPN Interconnections between DC and WAN networks DC Provider and Carrier may build a tenant instance and VPN instance for an enterprise customer independently and interconnect two together at DC GW. Figure 3 depicts this case. The GW supports both NVE and PE capability. Here an L3 VNI instance is built between NVE1 and DC GW and an L3VPN instance is configured on DC GW and PE1, MITY Expires December 2012 [Page 7] Internet-Draft NVO3 Use Case June 2012 respectively. The GW performs L3 VNI function, NVO3 encapsulation, and tunneling toward the DC; it also performs L3VPN function toward the WAN. Both L2 tunnel and LSP Tunnel terminate at DC GW. The packets are processed at the L3 VNI on DC GW. Operator may choose use of one routing table for both instances as shown in the figure or one for each. This implementation is more complex than one in figure 2. However it provides DC network and WAN network demarcation clearly and allows each network use of different VN implementations, which is necessary in some situations. The alternative of this case is physically split the gateway function on to DC GW and WAN PE devices. In this case, the tenant instance is terminated on the DC GW and L3VPN instance terminates at a PE in WAN. An Ethernet interface is used to physically connect to the DC GW and PE devices and an Ethernet VLAN is configured on both devices for interconnecting two instances. DC DC GW WAN ''''''''''''''''''''' '+-------+---------+' '| +--+---+ |' +-L2 Tunnel--+(OM)+L3VNI +(E/D)+-- MPLS/LSP Tunnel | '| +--+---+ |' | | '+-------+---------+' | | ' NVE PE ' | | ''''''''''''''''''''' | +--------+---------+ +------+--------+ | +------+-------+ | | +----+------+ | | |Overlay Module| | | |Encap/Decap| | | +------+-------+ | | +-----+-----+ |PE1 | |Ta | | +--+--+ | | +-----+------+ | | | VRF | | | | L3 VNI | | | +--+--+ | NVE1 | +-+--------+-+ | +-------+-------+ | | VAPs | | | +----+--------+----+ CE | ... | Tenant End Systems DC Provider Site Enterprise Site Note: OM: Overlay Module; E/D: Encap/Decap Figure 3 L3 VNI and L3VPN interconnection across multi networks MITY Expires December 2012 [Page 8] Internet-Draft NVO3 Use Case June 2012 If an enterprise only has few locations, it may use P2P VPWS connecting to the DC GW. Further some enterprises may connect to DC GW via Internet by using IPsec. In this case, DC GW needs to provide some authentication scheme for the security. Such interconnection may also apply to one or across multiple DC sites. During the migration process, it is possible that some portion of DC site may be able to support NVE and other may not. Such gateway function may be used to interconnect a tenant instance and a regular underlying VPN that provides the connectivity to the VMs belonging to the same tenant. 5. Cloud Services Using NVO3 NVO3 brings DC operators power and flexibility to design different applications for cloud services. DC operators construct VMs, storage, applications, and interconnect them together via an VNI. Since DC operator manages both tenant end systems and NVEs, they can assign some functions on VMs and some on NVEs. For example, designate a VM for running firewall and/or a VM for DNS for a tenant; apply forwarding policies and/or access list on an VNI terminated on an NVE. Operators may dedicate some VMs and/or storages for these applications and allocate other VMs/storages for running tenant specific applications. Furthermore, the design of a cloud service for a customer may often require creating both L2 VNI and L3 VNI per a tenant on one or more NVEs and interconnecting the VNIs together like physical router and switch devices in a traditional DC. 5.1. Public Cloud Service Figure 4 depicts that an L2 VNI is used to connect all the TESs together and provides a simple LAN among TESs; an L3 VNI is used for public Internet Access and firewall access. Note: An L3 VNI provides virtualized IP routing and forwarding and an L2 VNI provides Ethernet LAN emulation. The firewall application runs on a tenant end system connecting to the L3 VNI terminated on NVE1 and NVE2. Ta in Figure 4 is the VN context of the L2 VNI. Internal VNI interconnecting interface (VNIF) is used to connect the L2 VNI and L3 VNI on NVE1 and NVE2. In this case, the L3 VNI connects to external switch directly, not to an overlay module. Operator defined policies can directly apply to the L3 VNI terminated on NVE. Furthermore, the L3 VNI does not have to co-exist with the L2 VNI on every NVEs; the several NVEs where the L2 VNI terminates can connect to one NVE where the L3 VNI terminates. In this case, VNIF reachability should be known by these NVEs. MITY Expires December 2012 [Page 9] Internet-Draft NVO3 Use Case June 2012 Internet +--IP GRE Tunnel ---+ Internet | | | | | | | | +----+---------+-----+ +-----+--------+-----+ | | +--+---+ | | +---+--+ | | | | | OM | | | | OM | | | | | +--+---+ | | +--+---+ | | | | |Ta | | |Ta | | | +--+--+VNIF+-+---+ | | +--+--+VNIF+--+--+ | | |L3VNI+----+L2VNI| | | |L2VNI+----+L3VNI| | NVE1 | +--+--+ ++----+ | | ++----+ +--+--+ | NVE2 | | |VAPs| | | |VAPs| | | +----+--------|----|-+ +--+----+-------+----+ | | | | | | -------+--------+----+--- -----+----+-------+----- | | .. | | .. | | | | | | | | FW TES TESs TESs FW TES DC Site A DC Site Z Figure 4 L2 VNI for connecting TESs and L3 VNI for public Internet access In this case, if the tenant uses private IP addresses on Tenant End Systems, the NAT is needed for public Internet access. Operator may allocate another TES connecting to L3 VNI and run NAT application on it. 5.2. Private Cloud Service Figure 5 below illustrates another overlay bridging and routing example. A L2 VNI is used for local LAN switching and L3 VNI is used for interconnecting NVEs remotely and providing IETF IP VPN functionality. In this case, the L2 VNI terminated on an NVE only has local significance. MITY Expires December 2012 [Page 10] Internet-Draft NVO3 Use Case June 2012 +----IP Tunnel -----+ | | +---------------+-----+ +-----+---------------+ | +-------------+---+ | | +---+-----------+ | | | Overlay Module | | | | Overlay Module| | | +---+-------------+ | | +-------------+-+ | | |Ta | | Ta| | | | | | | | | +--+---+ +-----+ | | +------+ +--+--+ | | | L3VNI+---+L2VNI| | | | L2VNI+--+L3VNI| | NVE1 | +------+ ++----+ | | ++----++ +-----+ | NVE2 | |VAPs| | | |VAPs| | +--------------|----|-+ +---+----+------------+ | | | | -----------------+----+--- ------+----+------------- | .. | Tenant | .. | | | Service IF | | Tenant End Systems Tenant End Systems DC Site A DC Site Z Figure 5 NVO3 for Virtual Bridging and Routing Per Tenant The DC provider may also create an NVE on DC GW and configure the L3 VNI on the NVE (instead of co-resident with L2 VNI on the same NVE). Thus L2 overlay is used within a DC, and L3 overlay is used for inter-DCs. 5.3. Virtual Data Center Enterprise DC today may often uses several routers and switches devices to construct a secure network for intranet and extranet. [SANS] DC Provider may want to offer Virtual DC called Infrastructure as service (IaaS) to such enterprise customers. Instead of using many router/switch hardware devices, with the overlay and virtualization technology of NVO3, DC operators can build them on top of a common network infrastructure for many customers and run applications per customer basis. The applications may include firewall, DNS, load balancer, NAT, etc. MITY Expires December 2012 [Page 11] Internet-Draft NVO3 Use Case June 2012 Figure 6 below illustrates this scenario. For the simplification, it only shows the VNIs as logic routers or switches. In this case, DC operators construct several L2 VNIs (x, y, z in figure 6) to group the end tenant systems together per application basis, create an L3 VNI (L3 VNIa in the figure) for internal routing and another L3 VNI (L3 VNIb in the figure) for broad routing. Allocate a TES to run a firewall application between L3 VNIa and L3 VNIb. The design implements the security policy with the appropriate firewall rules and Layer 3 access list. Configure an interconnection between the L3VNIa to an L3VPN over the WAN to reach Enterprise Sites. The Enterprise as a customer decides which applications are accessed by intranet only and which by both intranet and extranet; DC operators then design and configure the proper security policy. DC operators can further set different QoS levels for the different applications for a customer. This application requires NVO3 solution to provide DC operator an easy way to create NVEs and VNIs for any design and to quickly assign TESs to an VNI, and configure policies on an NVE easily. ^ Internet | +--+---+ |L3VNIb| +--+---+ +---+-----+ WAN |FireWall*| /^^^^^^^^^\ +------+--+ /---| VPN/MPLS |-- CE | / \vvvvvvvvv/ +-+--+-+ Enterprise Site +------+L3VNIa+--------+ | +---+--+ | | | | +--+---+ +--+---+ +--+---+ |L2VNIx| |L2VNIy| |L2VNIz| +-+--+-+ +-+--+-+ +-+--+-+ |..| |..| |..| | | | | | | App1 TESs App2 TESs App3 TESs DC Provider Site * firewall may run on VMs MITY Expires December 2012 [Page 12] Internet-Draft NVO3 Use Case June 2012 Figure 6 Secure Cloud Service by Using NVO3 6. OAM Considerations NVO3 brings the ability for a DC provider to segregate tenant traffic. A DC provider needs to manage and maintain NVO3 instances. Similarly, the tenant needs to be informed about tunnel failures impacting tenant applications. Various OAM and SOAM tools and procedures are defined in [IEEE 802.1ag, ITU-T Y.1731, RFC4378, ITU-T Y.1564] for L2 and L3 networks, and for user, including continuity check, loopback, link trace, testing, alarms such as AIS/RDI, and on-demand and periodic measurements. These procedures may apply to tenant overlay networks and tenants not only for proactive maintenance, but also to ensure support of Service Level Agreements (SLAs). As the tunnel traverses different networks, OAM messages need to be translated at the edge of each network to ensure end-to-end OAM. It is important that failures at lower layers which do not affect NVo3 instance are to be suppressed. 7. Summary The document intends to illustrate some basic potential use cases. The combination of these cases should give operators flexibility and power to design more sophisticated cases for various purposes. The main characteristic difference between other overlay network technologies and NVO3 is that the client edges of the NVO3 network are individual virtualized hosts and not network sites or LANs. NVO3 is to no longer treat the physical computer as a client of the network but as a native service point of the network. The same operator manages both NVO3 network and its clients. NVO3 lets individual virtual network instances use its own address space and isolate the space from the network infrastructure. The approach not only segregates the traffic from multi tenants on a common infrastructure but also makes VM mobility easier within a tenant. Cloud services are about providing virtual processing/storage, applications, and networking in a secured and virtualized manner, in which the NV03 is just a portion of a service, not a service itself. NVO3 decouples cloud services and DC network infrastructure. MITY Expires December 2012 [Page 13] Internet-Draft NVO3 Use Case June 2012 NVO3 underlying network provides the tunneling between NVEs so that two NVEs appear as one hop each other. Many tunneling technologies can serve this function. The tunneling may in turn be tunneled over other intermediate tunnels over the Internet or other WAN. It is also possible that intra DC and inter DC tunnels are stitched together to form an end-to-end tunnel between two NVEs. The key requirements for NVO3 are 1) traffic segregation; 2) support a large scale number of TESs in an VNI; 3) VM mobility 4) easy to construct an VNI and its associated TES; 5) NVO3 Management. 8. Security Considerations Please see it in NVO3 Framework. [NVO3FMWK] 9. IANA Considerations This document does not request any action from IANA. 10. Acknowledgements Authors like to thank Linda Dunbar, Sue Hares, and Young Lee for the review and suggestions. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. [IEEE 802.1ag] Virtual Bridged Local Area Networks - Amendment 5: Connectivity Fault Management, December 2007. [ITU-T G.8013/Y.1731] OAM Functions and Mechanisms for Ethernet based Networks, 2011. [ITU-T Y.1564] Ethernet service activation test methodology, 2011. [RFC4378], A Framework for Multi-Protocol Label Switching (MPLS) Operations and Management (OAM) MITY Expires December 2012 [Page 14] Internet-Draft NVO3 Use Case June 2012 11.2. Informative References [NVO3FRWK] Lasserre, M., Motin, T., and etc, "Framework for DC Network Virtualization", draft-lasserre-NVO3-framework-02, June 2012. [PION] Jin, L. and Khasnabish, B., "Architecture of PSN Independent Overlay Network (PION)", draft-kj-nvo3-pion-architecture- 00, May 2012 [SANS] Daniel Oxenhander, "Designing a Secure Local Area Network", 2003 Authors' Addresses Lucy Yong Huawei Technologies, 4320 Legacy Dr. Plano, Tx75025 US Phone: +1-469-277-5837 Email: lucy.yong@huawei.com Mehmet Toy Comcast 1800 Bishops Gate Blvd., Mount Laurel, NJ 08054 Phone : +1-856-792-2801 E-mail : mehmet_toy@cable.comcast.com Aldrin Isaac Bloomberg E-mail: aldrin.isaac@gmail.com Vishwas Manral Hewlett-Packard Corp. 191111 Pruneridge Ave. Cupertino, CA 95014 Phone: 408-447-1497 Email: vishwas.manral@hp.com MITY Expires December 2012 [Page 15]