Network Working Group R. Penno Internet-Draft S. Raghunath Intended status: Experimental J. Medved Expires: December 6, 2010 M. Bakshi Juniper Networks R. Alimi Yale University S. Previdi Cisco Systems June 04, 2010 ALTO and Content Delivery Networks draft-penno-alto-cdn-00 Abstract Networking applications can request through the ALTO protocol information about the underlying network topology from the ISP or Content Provider (henceforth referred as Provider) point of view. In other words, what a Provider prefers in terms of traffic optimization -- and a way to distribute it. The ALTO Service provides information such as preferences of network resources with the goal of modifying network resource consumption patterns while maintaining or improving application performance. A main use case of the ALTO Service is its integration with of Content Delivery Networks (CDN). In this document we describe the deployment scenarios and considerations for a ALTO Service in the case of CDNs. Requirements Language 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]. 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 Penno, et al. Expires December 6, 2010 [Page 1] Internet-Draft Abbreviated-Title June 2010 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 December 6, 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. Penno, et al. Expires December 6, 2010 [Page 2] Internet-Draft Abbreviated-Title June 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. HTTP Redirect . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. ALTO Server Discovery . . . . . . . . . . . . . . . . . . 7 4.2. CDN Node Discovery and Status . . . . . . . . . . . . . . 7 4.3. CDN Node Status Updates received by HTTP Redirector . . . 7 4.4. CDN Node Status Updates received by ALTO Server . . . . . 8 5. DNS Integration . . . . . . . . . . . . . . . . . . . . . . . 10 6. Administrative domains and ALTO . . . . . . . . . . . . . . . 11 6.1. CDN nodes in the ISP administrative domain . . . . . . . . 11 6.2. CDN nodes in a separate administrative domain from that of ISP . . . . . . . . . . . . . . . . . . . . . . . 12 6.3. Integrating with managed DNS service . . . . . . . . . . . 14 6.3.1. Managed DNS resolver used to redirect to local cache . . . . . . . . . . . . . . . . . . . . . . . . 14 6.3.2. Managed DNS resolver used with multiple CDN vendors . 16 7. Tracker Integration . . . . . . . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 11.2. Informative References . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Penno, et al. Expires December 6, 2010 [Page 3] Internet-Draft Abbreviated-Title June 2010 1. Introduction Content Delivery Networks are becoming increasingly important in the Internet [ARBOR] and many CDNs today already use some form of application proximity through geolocation. But in many cases the content provider and the Service Provider are disjoint and even if content servers are co-located into the ISP's networks, there is no standardized way to share information. Therefore a natural step forward would be to use ALTO for full integration. Another key aspect of ALTO in the context of CDNs deployments is that there is an expectation that no changes to the hosts are needed (or would be transparent to the user). In other words, a traditional web browser is all there is needed to take advantage of ALTO information. This is significant difference from the P2P file sharing case where a special client is needed and ALTO is normally used as a way to reduce operational expense. 2. Scope This document discusses how Content Delivery Networks can benefit from ALTO through integration of the ALTO Service with the main request routing techniques. Whenever a gap in protocol functionality is identified to achieve such integration, it will be enumerated with 'GAP-'. Each gap is documented in a section of their own in order to foster parallel discussion and possible adoption. 3. Terminology Content-aware Proximity Redirector: The Redirector knows about locations and presence of content & media objects in the network. Therefore the redirection to a CDN node is made based on availability of content or content-type in that CDN node and the proximity of the CDN node to the user. Service-aware Proximity Redirector: The Redirector knows about locations of CDN nodes in the network and redirects user to the closest CDN node. The redirection made irrespective of content presence in the CDN Node; if content not present, the cache will be populated with the content before or when the content is served to the user. HTTP Redirector: a Content-Aware or Service Aware Proximity Redirector for HTTP. It embeds an HTTP Server that performs HTTP Redirects, an ALTO client that retrieves network mapping from the ALTO Server and a Location Database which stores network mappings Penno, et al. Expires December 6, 2010 [Page 4] Internet-Draft Abbreviated-Title June 2010 received from the ALTO Client. The HTTP Server consults the Location Database when making redirection decisions. 4. HTTP Redirect In this case an HTTP GET request from a host is received by an HTTP Redirector which sends back an HTTP responses with Status-Code 302 (Redirect) informing the host of the best location to fetch the content. The HTTP Redirection method is already commonly used in production CDNs as described in RFC3568 [RFC3568]. ALTO integration provides localization services where the device that performs the redirection becomes an ALTO client. The ALTO client embedded in the HTTP Redirector fetches the cost and network map from the ALTO Server and provides that information to the HTTP Server. When the HTTP Redirector intercepts an HTTP GET request (1), it looks up the source IP address on the GET request, consults the Location Database and returns an HTTP redirect with the URL of the best CDN node from which to service the host. The URL in 302 Redirect may contain the IP address of the selected CDN node or a domain name instead of IP address due to virtual hosting. Therefore the IP addresses contained in the cost maps may need to be correlated to domain names a priori. Penno, et al. Expires December 6, 2010 [Page 5] Internet-Draft Abbreviated-Title June 2010 +-----------------+ | HTTP Redirector | +------+ 1 | +-------------+ | | |--------------> | | HTTP Server | | | Host |<-------------- | +-------------+ | +------+ 2 | ^ | | | | | +-------------+ | | | Location DB | | | +-------------+ | | ^ | | | | | +-------------+ | | | ALTO Client | | | +-------------+ | +-----------------+ | ^ | | ALTO Protocol | | (Map Service) v | +-----------------+ | ALTO Server | +-----------------+ Figure 1: HTTP Redirector The Network Maps generated by the ALTO server contain Host PIDs and CDN Node PIDs, i.e., Host PIDs contain host subnets; CDN PIDs contain IP addresses of available CDN nodes. Cost Maps contain only cost from each host PID to each CDN PID and not the full matrix across all PIDs. The reason is that the HTTP Redirector can only redirect a host to a CDN node, not to another host as in the P2P case. Moreover, there is no generic way to disambiguate PIDs containing only hosts from PIDs containing CDN nodes (GAP). The cost for CDN PID to CDN PID and from between host PIDs are assumed to be infinity (GAP). The HTTP Redirector looks up the source address on the HTTP GET request, and uses the cost map to select the best CDN PID and a CDN node from it. The CDN node selection method can be random, round-robin, or the HTTP Redirector can use some level of content awareness (i.e. send requests for the same content (URL) to the same CDN node. GAP-1 (PID Attributes): In order to disambiguate between PIDs that contain endpoints of a specific class, a PID property is needed. A PID can be classified as containing "CDN nodes", "Mobile Hosts", "Wireline Hosts", etc. Penno, et al. Expires December 6, 2010 [Page 6] Internet-Draft Abbreviated-Title June 2010 GAP-2 (PID Attributes and Query): PID attributes can be used by the Client to select a appropriate host and also passed as a constraint in the map filtering service. GAP-3 (Default Cost): The issue of default cost if one of importance. Without a default PID with endpoint '0.0.0.0/0', what should be the cost between two PIDs? Moreover, if the default PID mandatory in the protocol? A future revision will incorporate analysis of ALTO Server - HTTP Redirector interaction with Endpoint Cost Service 4.1. ALTO Server Discovery 4.2. CDN Node Discovery and Status The method of discovering available caches and their locations is not specified. We assume the CDN nodes are discovered in some way. It is desirable that not only CDN node locations, but also real-time status (like health, load, cache utilization, CPU, etc.) is communicated either to the HTTP Redirector or to the ALTO Server. CDN node status can be retrieved from the existing Load Balancer infrastructure. Most Load Balancers today have mechanisms to poll caches/servers via ping, HTTP Get, traceroute, etc. Most LBs have SNMP trap capabilities to let other devices know about these thresholds. The HTTP Redirector or the ALTO Server can implement an SNMP agent and get to know whatever is needed. For greenfield installations, the ALTO Server could also provide an API (for example, a Web Service or XMPP-based API) that could be used by CDN nodes to communicate their status to the ALTO server directly. 4.3. CDN Node Status Updates received by HTTP Redirector In this use case the HTTP Redirector receives CDN Status updates. Penno, et al. Expires December 6, 2010 [Page 7] Internet-Draft Abbreviated-Title June 2010 +-----------------+ | HTTP Redirector | +------+ 1 | +-------------+ | | |--------------> | | HTTP Server | | | Host |<-------------- | +-------------+ | +------+ 2 | ^ | | | | | +-------------+ | | | Location DB | |<--- Real-time CDN | +-------------+ | status updates | ^ | | | | | +-------------+ | | | ALTO Client | | | +-------------+ | +-----------------+ | ^ | | ALTO Protocol | | (Map Service) v | +-----------------+ | ALTO Server | +-----------------+ Figure 2: RT CDN Updates to HTTP Redirector 4.4. CDN Node Status Updates received by ALTO Server This model generally simplifies the HTTP Redirector. It allows an easier distribution of the HTTP Redirector, and to keep real time CDN status data updates in a logically centralized ALTO Server or in an ALTO Server Cluster. It allows for the HTTP Redirector and the ALTO Server to be in different administrative domains. For example, the HTTP Redirector can be in a Content Provider's domain, the ALTO Server and CDN Nodes in a Network Service Provider's domain. Penno, et al. Expires December 6, 2010 [Page 8] Internet-Draft Abbreviated-Title June 2010 +-----------------+ | HTTP Redirector | +------+ 1 | +-------------+ | | |--------------> | | HTTP Server | | | Host |<-------------- | +-------------+ | +------+ 2 | ^ | | | | | +-------------+ | | | Location DB | | | +-------------+ | | ^ | | | | | +-------------+ | | | ALTO Client | | | +-------------+ | +-----------------+ | ^ | | ALTO Protocol | | (Map Service) v | +-----------------+ | ALTO Server |<--- Real-time CDN +-----------------+ status updates Figure 3: RT CDN Updates to ALTO Server In this model it is recommended that a given HTTP Redirector may be designated as being responsible for a fixed set of Host PIDs. This information can be made available to the HTTP Redirector before it receives requests from clients. If the set of Host PIDs is not known ahead of time, the latency for serving requests will be impacted by the capabilities of the ALTO server. With such information ahead of time, the HTTP Redirector may pre-download the network map for the interesting Host PIDs and the CDN PIDs. It can also start periodically pulling cost maps for relevant PID 2-tuples. The HTTP Redirector can rely on the ALTO Server generated Cache- Control headers to decide how often to fetch CDN PID network map and Host PID network maps. In order to better deal with outages of caches or changes to CDN PIDs, a push mechanism from ALTO server to ALTO client would be needed (GAP-4). In the general P2P scenario this may not make sense, but with content delivery this may be important from a service continuity perspective. If the maps are large and change often a natural extension to the protocol is to allow incremental Map Updates (GAP-5). This requirement becomes more emphasized when the ALTO Server is the recipient of CDN nodes' status updates, because their load/status Penno, et al. Expires December 6, 2010 [Page 9] Internet-Draft Abbreviated-Title June 2010 changes are typically more frequent than topology changes in the network. GAP-4 (Push Mechanism): It is important for the ALTO Service through the ALTO protocol or a companion protocol to provide a push mechanism from server to client. The push mechanism can be a notification that new data is vailable or the data itself. GAP-5 (Incremental Map Updates): A natural evolution to the protocol if maps are large and change often is to allow for incremental map updates. In this sense the map contained in the reply would be considered the delta from the previous version. 5. DNS Integration In the case of DNS request routing, the DNS server handling client requests is integrated with an ALTO client. When the host performs a DNS query lookup, the IP address contained in the response are already optimal for that query. As in the previous example, no changes in the host are needed. DNS queries can be either iterative or recursive. Iterative queries can be used with ALTO if the client itself queries the DNS Servers, or if the DNS Proxy used by the host is topologically close to the host. If the Host queries the DNS Servers, the authoritative DNS Server can see directly the host's IP address. If the the DNS Proxy's is topologically close to the Host, its IP address is a good approximation for the host's location. In recursive queries, the authoritative DNS Server sees the IP address of the previous DNS Server in the resolution chain, and the IP address of the host is unknown. DNS-based request routing does not work with recursive DNS queries. In an iterative DNS lookup with DNS Proxy, as shown in examples in the next section, the host queries the Proxy, which in turn first queries one of the root servers to find the server authoritative for the top-level domain (com in our example). The Proxy then queries the obtained top-level-domain DNS server for the address of the DNS server authoritative for the cdn domain. Finally, the Proxy queries the DNS server that is authoritative for the cdn.com domain. The authoritative DNS Server for the cdn.com will perform the request routing to the most appropriate CDN node, based on the source IP address of the requestor. The client will then request the content directly from the CDN Node. Penno, et al. Expires December 6, 2010 [Page 10] Internet-Draft Abbreviated-Title June 2010 6. Administrative domains and ALTO With DNS-based redirection, among others, there are two models that are worth further study - one, where the CDN nodes are in the administrative domain of the ISP and two, where CDN nodes are part of a separate domain from that of the ISP. In the first use case, the Host, the CDN Nodes, the ALTO Server and the Authoritative DNS Server for the CDN domain are in the same administrative domain. In the second use case, Hosts and CDN Nodes are in different administrative domains. 6.1. CDN nodes in the ISP administrative domain When the CDN nodes are within the ISP's administrative domain, the DNS server with the ALTO client is under the ISP's management. As described earlier, the best CDN node is picked by performing an ALTO query on the source IP address of the DNS request. Penno, et al. Expires December 6, 2010 [Page 11] Internet-Draft Abbreviated-Title June 2010 2 +----------------+ +------------------> | root | | +----------------- | Name Server | +----------+ | | 3 +----------------+ | Content | | | | Provider | | | 4 +----------------+ +----------+ | | +------------> | com | | | | +----------- | Name Server | | | | | 5 +----------------+ .......|.|...|.|............................................... : | V | V : : +---------+ +----------------+ : : | DNS |---------> | cdn.com | : : | Proxy |<--------- | Name Server | : : +---------+ 7 | | : : ^ | | +------------+ | : : 1 | | 8 | |ALTO Client | | : : | V | +------------+ | : : +---------+ +----------------+ : : | Host | | ^ : : +---------+ | | ALTO Protocol : : | | | (Map Service) : : | V | : : V +----------------+ : : CDN Node | ALTO Server | : : +----------------+ : : : : NSP/CDN Administrative Domain : :.............................................................: Figure 4: DNS Resolution with single admin domain 6.2. CDN nodes in a separate administrative domain from that of ISP In many situations, the CDN nodes are in a separate network managed by an entity that is distinct from the ISP. Consequently, the CDN nodes belong to a network with its own ALTO server that is distinct from the ALTO server of the ISP where the subscriber belongs. Penno, et al. Expires December 6, 2010 [Page 12] Internet-Draft Abbreviated-Title June 2010 ................................. : +-----------------+ : : | cdn.com | : : | Name Server | : +----------+ : | | : | Content | : | +-------------+ | : | Provider | : | | ALTO Client | | : +----------+ : | +-------------+ | : : +-----------------+ : : ^ : : | : : +-----------------+ : ................................. : | ALTO Server | : : : : | | : : +----------------+ : : | +-------------+ | : : | ALTO Server |--------------------->| ALTO Client | | : : +----------------+ : : | +-------------+ | : : : : +-----------------+ : : : : : : +------+ C(1-4) +--------+ : : +--------+ C(6-8) +------+ : : | Host |<--------->| Border |: c6 :| Border |<--------->| CDN | : : | PID1 | +-->| Router |-------| Router |<--+ | PID8 | : : +------+ |+->| PID4 | : :| PID6 |<-+| +------+ : : || +--------+ : : +--------+ || : : || : : || : : +------+ C(2-4)|| : : ||C(6-9) +------+ : : | Host |<------+| : : |+------>| CDN | : : | PID2 | | : : | | PID9 | : : +------+ | : : | +------+ : : | : : | : : | : : | : : +------+ C(3-4) | +--------+ : : +--------+ | C(6-10)+------+ : : | Host |<-------+ | Border |: c7 :| Border | +------->| CDN | : : | PID3 | | Router |-------| Router | | PID10| : : +------+ | PID5 | : : | PID7 | +------+ : : +--------+ : : +--------+ : : : : : : ISP Administrative Domain : : CDN Administrative Domain : :...............................: :...............................: Figure 5: Map advertising between ISP and CDN domains The ALTO server in the CDN provider network is assumed to be initialized with information about the ISP networks it serves. For every such ISP network, it consults the routing plane to find the set of Border routers. The CDN network ALTO server computes the cost of reaching each Border router from every CDN node (say, C_cdn). Penno, et al. Expires December 6, 2010 [Page 13] Internet-Draft Abbreviated-Title June 2010 Next, the CDN ALTO server contacts the ISP network's ALTO server and downloads the network map. In order to help the CDN ALTO server compute the cost from a CDN node to a subscriber's PID, we break it down into two parts - the cost from the CDN node to the Border router (C_cdn) and the cost from the Border router to the subscriber's PID (say, C_isp). Note that, this implies that each Border router is a PID in itself to accommodate this cost computation. Hence the cost map at the ISP's ALTO server has the costs between every pair of subscriber PID and Border router PID. With the network map and the cost map from the ISP ALTO server, the CDN ALTO server now computes the cost of reaching each subscriber PID from a given CDN node as: C_cdn(CDN Node, Border router) + C_isp(Border router, Subscriber PID). In this computation, the Border router is the one that is on the best path from the CDN node to the Subscriber PID. The CDN ALTO server now has a cost map that provides the cost from each CDN node to all known Subscriber PIDs. The ALTO client in the CDN DNS server downloads this cost map in preparation for subscriber DNS requests. When a subscriber DNS request arrives at the CDN provider's DNS server, it looks up the network map and maps the source IP address to a Subscriber PID. It then uses the cost map to pick the best CDN node for this Subscriber PID. GAP-6: Federation of ALTO servers: There is a need to define how ALTO servers may communicate with each other in a federated model. GAP-7: ALTO Border Router PID attribute: In order for administrative domains to collate costs across domain boundaries, the border routers may be placed in their own PIDs. Such PIDs may be identified by a Border Router attribute. 6.3. Integrating with managed DNS service Many organizations / content providers outsource DNS management to the external vendors for various reasons like reliability, performance improvement, DNS security etc. Managed DNS service could be used either with caches owned by the organization itself (section 6.3.1) OR with external CDNs (section 6.3.2) 6.3.1. Managed DNS resolver used to redirect to local cache One of the common functions offered by managed DNS service vendor is DNS traffic management where DNS resolver can load balance traffic dynamically across content servers. Penno, et al. Expires December 6, 2010 [Page 14] Internet-Draft Abbreviated-Title June 2010 Typically managed DNS service provider has DNS resolvers spread across geographical locations to improve performance. This also makes easier for DNS resolver to redirect host to the nearest cache. Such a DNS resolver would be an ideal candidate to implement ALTO client where it can fetch network map and cost map from ALTO servers located in the same geographical area only. Load balancing implemented with the knowledge of network and cost map would be more efficient than other mechanisms like round robin. 2 +----------------+ +--------------------> | root | | +------------------- | Name Server | | | 3 +----------------+ | | | | 4 +----------------+ | | +--------------> | com | | | | +------------- | Name Server | | | | | 5 +----------------+ | | | | _|-|---|-|--------------------. ,-'' | V | V `--. ' +---------+ 6 +---------------`+. | | DNS |-------->| xyz.com | ` | | Proxy |<--------| DNS Resolver | | | +---------+ 7 | | | | 1^ | 8 | +------------+ | | | | | | |ALTO Client | | | | +-----V---+ | +------------+ | | | | Host | +----------------.-' | +---------+ | ^ .-' | | DOMAIN 1 | |-' ALTO Protocol | V |.-'| (Map Service) `--. CDN Node __.--:-| | `----. _.--' | | `---.-'' ,---------+-------. ,'+----------------+ \ / | ALTO Server | : ( +----------------+ | \ ; \ DOMAIN 2 ,' `-----------------' In the figure above, there exists 2 possibilities: Case 1: Domain 1 and Domain 2 are connected to the same service provider network. This case is similar to section 6.1 Case 2: Domain 1 and Domain 2 are connected to different service Penno, et al. Expires December 6, 2010 [Page 15] Internet-Draft Abbreviated-Title June 2010 provider network. This case is similar to section 6.2 6.3.2. Managed DNS resolver used with multiple CDN vendors In this Model, Managed DNS service can be used along with multiple CDN vendors where DNS resolver can redirect to different caches depending on the subdomain e.g. DNS resolver could have below records subdomain1.xyz.com CNAME cdn1.com subdomain2.xyz.com CNAME cdn2.com In this case CDN DNS resolver needs to be an ALTO client. This deployment will be similar to ones described in section 6.1 and section 6.2 earlier. 7. Tracker Integration In the case of P2P CDNs, the application tracker takes the role of the ALTO Client, fetching the map from the ALTO Server and integrating it its peer database. The result is a peer database taking into account current metrics such as peer availability, content availability and also localization. This architecture in the context of file sharing was extensively studied and trialed by ISPs such as Comcast [RFC5632] under the P4P [P4P] protocol. 8. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 9. Security Considerations When the ALTO Server and Client are operated by different entities the issue of trust and security comes forward. The exchange of information could be done using the encryption methods already present in HTTP but preventing unauthorized redistribution comes into play. A further issue is if the ALTO information information is transitive, which modifications are allowed. Penno, et al. Expires December 6, 2010 [Page 16] Internet-Draft Abbreviated-Title June 2010 10. Acknowledgements TBD 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. 11.2. Informative References [ARBOR] Labovitz, "Internet Traffic and Content Consolidation", 2009, . [I-D.ietf-alto-protocol] Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", draft-ietf-alto-protocol-03 (work in progress), March 2010. [P4P] Xie, H., Yang, YR., Krishnamurthy, A., Liu, Y., and A. Silberschatz, "P4P: Provider Portal for (P2P) Applications", March 2009. [RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known Content Network (CN) Request-Routing Mechanisms", RFC 3568, July 2003. [RFC5632] Griffiths, C., Livingood, J., Popkin, L., Woundy, R., and Y. Yang, "Comcast's ISP Experiences in a Proactive Network Provider Participation for P2P (P4P) Technical Trial", RFC 5632, September 2009. Authors' Addresses Reinaldo Penno Juniper Networks 1194 N Mathilda Avenue Sunnyvale USA Email: rpenno@juniper.net Penno, et al. Expires December 6, 2010 [Page 17] Internet-Draft Abbreviated-Title June 2010 Satish Raghunath Juniper Networks 1194 N Mathilda Avenue Sunnyvale USA Email: satishr@juniper.net Jan Medved Juniper Networks 1194 N Mathilda Avenue Sunnyvale USA Email: jmedved@juniper.net Mayuresh Bakshi Juniper Networks 1194 N Mathilda Avenue Sunnyvale USA Email: mbakshi@juniper.net Richard Alimi Yale University Email: richard.alimi@yale.edu Stefano Previdi Cisco Systems Email: sprevidi@cisco.com Penno, et al. Expires December 6, 2010 [Page 18]