0 Bewertungen0% fanden dieses Dokument nützlich (0 Abstimmungen)
46 Ansichten6 Seiten
Network operators are considering using content delivery network (CDN) technologies. Video traffic continues to be the primary content that uses an ever larger portion of the network. One report indicates that in 2015, upwards of 90% of Internet traffic will be video content.
Network operators are considering using content delivery network (CDN) technologies. Video traffic continues to be the primary content that uses an ever larger portion of the network. One report indicates that in 2015, upwards of 90% of Internet traffic will be video content.
Network operators are considering using content delivery network (CDN) technologies. Video traffic continues to be the primary content that uses an ever larger portion of the network. One report indicates that in 2015, upwards of 90% of Internet traffic will be video content.
Integrating Routing with Content Delivery Networks
Brian Field Ph.D.
Comcast Corporation Centennial, Colorado Brian_Field@cable.comcast.com Jan van Doorn Jan_VanDoorn@cable.comcast.com Jim Hall jim_hall2@cable.comcast.com
AbstractSeveral research efforts are underway to associate content names to the network space. There is a general belief that video and other types of cacheable content are going to continue to demand ever larger portions of a networks bandwidth. Technologies that enable network link bandwidth increases are struggling to keep up with the network operators bandwidth demand at appealing cost-points. Network operators are considering using content delivery network (CDN) technologies as a means to cache content in the network and thus slow the need for ever larger network link bandwidths. In this paper we present an approach to extend the Border Gateway Protocol (BGP) with a new address family geared to carry the uniform resource identifier (URI) namespace. Besides the benefits of using a proven scalable protocol, having both the CDN service and the network infrastructure operating across the same domain of information provides compelling benefits in the cross CDN and network traffic modeling space, as well as in the planning and operational domains. I. INTRODUCTION Video traffic continues to be the primary content that uses an ever larger portion of the Internet and Internet Service Provider (ISP) network capacity. One report [1] indicates that in 2015, upwards of 90% of Internet traffic will be video content. New video technologies, such as fragmented video, have a number of benefits in an Internet environment, including their ability to be cached by a content delivery network (CDN) infrastructure. The evolution of optical and router high-speed link technology struggles to keep up with network operator bandwidth needs at cost-effective price points. CDN technology offers the possibility that running Caches and Origins on Common Off the Shelf (COTS) technology is a cost-effective way to reduce network bandwidth needs at the cost of a CDN caching infrastructure. Deploying a CDN infrastructure within an operators network has another key benefit, namely reduced Transmission Control Protocol round- trip times (TCP RTT). Smaller TCP RTT enables better download performance across a cross-section of end-client TCP stack implementations, and thus enables these end-clients to pull the larger and hence, higher video quality fragments. A CDN infrastructure thus can directly improve video quality to customers. An open CDN protocol that enables multiple vendors' Caching and Origin platforms to co-exist and interact in a single, unified CDN does not currently exist. Instead, each CDN component vendor has created their own set of proprietary protocols for how their caching components interact collectively to form a single, cohesive, vendor- proprietary CDN. There are a number of working groups, working in part or in their entirety to standardize key aspects in the CDN inter-op space to enable an open CDN protocol. From our perspective, there are three (3) key criteria to the open CDN protocol problem that need to be considered: 1) Caches and Origins must use a single consistent open protocol to enable cross-vendor and platform inter-op, 2) Caches must be aware of the network, and 3) CDNs must be able to change the CDN performance or treatment provided to one or more assets over time. By meeting these criteria, a CDN will be capable of changing its behavior based on its knowledge of current network topology and resources. This paper proposes extending an existing routing protocol to satisfy these three criteria. The CDN Interconnection (CDNI) working group at the IETF has defined four interfaces for CDNI (control, request routing, logging and metadata) [2]. This paper addresses issues of control and routing of content, but does not tackle metadata or logging. II. CURRENT STATE OF CDN TECHNOLOGY While standard protocols such as HTTP and DNS play a vital role in today's CDNs, many, if not most, aspects of CDN operation depend on vendor-proprietary protocols. There is no agreed upon CDN protocol that enables a CDN operator to select Caching and Origin components from different vendors and have them function individually, but cooperatively, as a single, unified CDN entity. In effect, there is currently no CDN protocol to solve the intra-CDN problem. We include Origin IEEE INFOCOM 2012 Workshop on Emerging Design Choices in Name-Oriented Networking 978-1-4673-1017-8/12/$31.00 2012 IEEE 292 functionality into the intra-CDN problem space, as Origins tend to be treated as separate from the CDN components, yet are foundational to the overall function of the CDN. In this paper, we treat Origin functionality as an equal partner and participant in the CDN, and thus it needs to be included in the overall solution. Much like how classic ISPs "peer" with each other to enable the exchange of routes, but still focus resources on a subset of a geography or business dimension, there is agreement in the CDN community that CDNs will also want to peer with each other. Again, there is no common agreed upon protocol for how CDNs will peer with each other. Recent activity in the IETF has resulted in a number of proposals, including an Internet draft that proposes creating a new Address Family in the Border Gateway Protocol (BGP) to carry IP prefix information to address request routing across CDNs [3]. We believe this approach is a step in the right direction and is a subset of the overall solution defined in this paper. A complementary problem, and one not addressed in this paper, is how CDNs signal to which Content Service Providers (CSPs) they have access. The flow of signaling messages from CSP (or Origins or upstream CDNs) to downstream CDNs needs to be defined and open, and is a key component to any intra- or inter-CDN solution. In this paper, we propose a solution to address the signaling of content information from the CSP to downstream CDNs. As mentioned previously, there is an expectation that a majority of traffic on the Internet in 2015 will be video, likely cacheable, and a key network operator problem will be optimizing the network to cost effectively carry cacheable video. An alternative way to think about this optimization problem is to make the application itself, namely the CDN components (i.e. Caches and Origins), network aware. A number of approaches have been proposed to make CDN and peer-to-peer technologies more efficient in their use of network resources, including Application-Layer Traffic Optimization (ALTO) [4] and Decoupled Application Data Enroute (DECADE) [5]. While these are both useful technologies, neither will adequately address the CDN space. One important requirement on the CDN is the ability to make CDN service and traffic engineering decisions based on as much baseline network information as possible. The manner in which mechanisms such as ALTO present information to a client results in a number of inefficiencies. A CDN operator will want to refine the set of network dimensions it optimizes and these optimizations might be considered operator proprietary. The implication here is that each time a CDN operator opts to change its business or service model, it may very well need a third-party ALTO server to create a completely new type of map that provides the network information now needed to satisfy the new CDN business or service rules. We do not believe this model is scalable, nor provides the network insights needed by a CDN operator, and does not align into many operators vision of emerging application empowering technologies like OpenFlow [6] or Software Defined Networking [7]. One aspect within the CDN service space that is often overlooked is how to address the mapping of a content asset to the set of CDN components used to serve this content. It is clearly understood that for a given library some assets will be accessed more often than others. Out of a library of assets, a subset of assets will be hot for some period of time or an asset will coldused by few or no clients. Assets will likely transition from being cold to hot and then eventually back to cold. The open CDN protocol must provide a way for a CDN to dynamically change how an asset is treated by the set of CDN components in order to get the most overall effectiveness out of the entire CDN caching infrastructure. An efficient solution in the CDN space should be able to enable the CDN system to dynamically treat an asset differently from a CDN delivery perspective. Namely, a CDN should have the ability to treat cold assets differently from hot assets. A CDN operator might reap the best network bandwidth savings by mapping hot assets to a larger portion of their CDN infrastructure, while cold assets would be mapped to a smaller set of the CDN infrastructure. While it is certainly possible to treat both hot and cold assets the same in the CDN (i.e. map all assets to the same set of CDN components), better CDN caching efficiencies are possible if hot and cold assets are treated differently within the CDN. Specifically, allocating more resources to hot content will result in better caching hit rates and hence caching resource efficiencies. Allocating fewer resources or less storage to cold content likely also helps overall caching efficiency, as cold content does not cause hot content to be removed from the cache. Better CDN caching efficiencies translates into more cost savings at both the CDN level and at the network level. The solution proposed in this paper is not to replace caching logic within an individual cache component, but instead empower the entire CDN infrastructure to operate holistically and more efficiently. We use the discussion of treating cold and hot assets differently in a CDN as a means to develop a compelling solution to the problems listed here. III. ROUTING AND FOCUSED USE OF NETWORK RESOURCES The network (layer 3 routing) domain gains benefits from being able to associate specific network link resources to specific IP end-points (e.g. map different IP prefixes to different links to maximize link efficiencies). An ISP that peers with multiple ISPs uses business and bandwidth constraints to dynamically move network traffic (IP prefixes) across different peering links. This can be done via both prefix size manipulation and by using BGP policy capabilities. For instance, an ISP could demote the use of a peering link for some IP prefixes by AS (Autonomous System) padding the respective BGP announcement. Another approach to adjust how traffic arrives over a set of peering links is to send more specific advertisements over different peering linksthis is a common way for an ISP to traffic engineer how traffic arrives over an ISPs peering links. This traffic engineering approach of announcing more specifics is similar in nature to the engineering we would like to perform at the CDN level to treat hot or cold assets differently. We propose that network traffic engineering using more specifics is a way to solve the hot and cold asset treatment problem within the CDN space. 293 A. Routing and More Specifics as a Traffic Engineering Tool Consider the two ISP networks in Fig. 1. ISP 1 has the 24.24.0.0/16 address space that it is announcing from router 1 (R1) to ISP 2 over a single link to associated ISP 2 router 2 (R2). While ISP 2 might need to require connectivity to all of the 24.24.0.0/16 space, assume that most of the traffic from ISP 2 to ISP 1 is to a subset of the 24.24.0.0/16 space. Assume that most of ISP 2s traffic is to 24.24.24.0/24. Further assume that the existing link between the two ISPs is often overloaded and both ISPs agree that they should augment capacity between the two networks with a second network link. In general, there are two common ways these ISPs could add capacity between their networks (see Fig. 2). The Option 1 approach would be to add a single link between existing routers R1 and R2 and announce 24.24.0.0/16 over both these links. The Option 2 approach would be for ISP 1 to setup a new router (R3) that is connected to, or network-wise, near the 24.24.24.0/24 subnet. ISP 1 could deploy R3 and then build the second link from R3 in ISP 1s network to R2 in ISP 2s network. ISP 1 could then announce just the more specific route 24.24.24.0/24 to R2 from the R3 router and continue to announce the aggregate of 24.24.0.0/16 from R1 to R2. Using this approach where ISP 1 announces a more specific route, ISP 1 can cause a more efficient use of its network resources by causing traffic to 24.24.24.0/24 to be sent directly to R3, which is close or directly connected to the 24.24.24.0/24 network. This concept of more specifics is a common way for an ISP to traffic engineer how traffic arrives into or across its network infrastructure. The network model outlined here provides the functionality we are looking for in the CDN space: namely the ability to treat hot and cold assets differently within a CDN. In the above example, we are logically treating the 24.24.24.0/24 subnet as being hot and the rest of the 24.24.0.0/16 subnet as being cold. We now apply the routing paradigm to the CDN domain. B. More Specifics Applied to the CDN Space Imagine that we treat Caches as "routers of content" that forward requests for content, much like IP routers forward packets, and where URI prefixes are advertised by Origins that store certain sets of content and by Caches that have access to certain sets of content. In this scenario, the network prefix 24.24.0.0/16 is analogous to an aggregate URI prefix http://nbc.com. Assume that the more specific IP prefix 24.24.24.0/24 is akin to a sub-set of the nbc.com domain that has hot URI assets, namely NBC Olympic content that might be created during the upcoming Olympics in 2012 (i.e. http://nbc.com/olympics). Replace the router designations in the previous examples with Caches, as shown in Fig. 3. Here, R2 becomes a child Cache (CC-2) and routers R1 and R3 become parent Caches (PC-1 and PC-3 respectively). The child Cache CC-2 can use either PC-1 or PC-3 to reach NBC content, but we want to make access to the Olympic content, which is hot, as effective as possible. By applying the routing paradigm to the announcement of the URI namespace, in Option 1, PC-1 could announce nbc.com to CC-2. In Option 2, we define a new parent Cache (PC-3) that announces the Olympic more specific prefixes to CC-2 (i.e. nbc.com/olympics). In option 2, CC-2 would see two announcements, an aggregate (i.e. nbc.com from PC-1) and a more specific (i.e. nbc.com/olympics from PC-3), and build a forwarding information base (FIB) like structure. Much like in the classic routing paradigm, the FIB would associate URI prefixes with an associated next-hop address to parent Caches that have announced access to a set of the URI namespace. On a cache miss, CC-2 would do a longest match lookup on the miss request URI against its locally created FIB and determine which parent Cache should be used to support the content request. For a URI request to CC-2 for the content nbc.com/olympics/swimming-results, CC-2 would perform the FIB longest-match lookup and send the HTTP GET request for this URI to PC-3. If CC-2 received a URI request for the URI http://nbc.com/30rock/episode-42, CC-2 would send the HTTP GET request to PC-1. There are clear parallels between the traffic engineering in 24.24.0.0/16 24.24.24.0/24 R1 ISP 2 ISP 1 R2 R1 announces to R2 24.24.0.0/16 ->R1
Fig. 1. Base ISP connectivity 24.24.0.0/16 24.24.24.0/24 R1 ISP 2 ISP 1 R2 R1 announces to R2 24.24.0.0/16 ->R1 R3 R3 announces to R2 24.24.24.0/24 ->R3 24.24.0.0/16 24.24.24.0/24 R1 ISP 2 ISP 1 R2 R1 announces to R2 24.24.0.0/16 ->R1 over both links Option 1 Option 2 Fig. 2. Network augment and associated routing options Nbc.com Nbc.com/ olympics PC-1 announces to CC-2 Nbc.com -> PC-1 Nbc.com Nbc.com/ olympics PC-1 announces to CC-2 nbc.com ->PC-1 Option 1 Option 2 Network connectivity Network connectivity Network connectivity Network connectivity PC-1 CC-2 PC-1 CC-2 PC-3 announces to CC-2 Nbc.com/olympics -> PC-3 PC-3 Fig. 3. Applying routing options to CDN paradigm 294 the network space and corresponding needs in the CDN space. If routing has the right mechanisms to do the types of traffic engineering we would like to do in the CDN space, namely associated prefixes and next-hops together, then we should consider the existing routing protocols as the signaling mechanism in the CDN space. This leads us to BGP, or specifically, Multi-protocol BGP (M-BGP) [8]. IV. MULTI-PROTOCOL BGP ADDRESS FAMILY EXTENSIONS FOR CARRYING URIS We propose the creation of a new BGP address family (AF) that is specialized for carrying content URI prefixes and associating these prefixes to IPv4/IPv6 next-hop addresses. At a high level, this URI AF defines new BGP Network Layer Reachability Information (NLRI), where the prefix is a portion (aggregate) or entire (more specific) asset URI string and the next-hop is an IPv4 or IPv6 address. BGP using this new AF is targeted at carrying URI announcements within a CDN domain, mimicking how Internal BGP (iBGP) works within routers in an ISP network (with some subtle changes). A CDN domain will consist of all the Caches and Origins that operate as a single cohesive CDN; all CDN components with a CDN domain would use the same BGP autonomous system number (ASN). This CDN ASN need not be tied to the underlying network ASN(s); the CDN operates as an overlay to the network and the CDN BGP information also operates as an overlay to the network BGP information. What this means is that the underlying network routing infrastructure does not see or participate in the CDN BGP URI informationthis CDN BGP information is only carried and processed by the CDN elements. Once we make the leap to carry URI prefixes in BGP in the intra-CDN domain, this URI AF could also be used to carry URI prefix announcements between CDN administrative domains (inter-CDN). This parallels how External BGP (eBGP) works between multiple ISPs in the existing IPv4/IPv6 namespace. Note that this URI AF is complementary to the IETF ID that addresses request routing [3]. Our proposal addresses URI announcements from the CSP through CDNs toward intermediate (transit) CDNs and towards edge (regional) CDNs, while the IETF ID proposal addresses the announcements of client address space from edge CDNs, up through transit CDNs to CSPs. Our expectation is that CDNs will operate much like ISPs, namely that CDNs will peer based on business relationships that make strategic and economic sense between CDN operators. A. Internal CDN Tiering A large ISP might server linear and video on demand content to millions of subscribers.. Building a CDN to deliver video to this number of end-points will require a large number of Edge Caches. To reduce network bandwidth between these Edge Caches and the Origins, one or more CDN mid caching tiers might exist between the Origins and Edge Caches. The number of mid-tier layers required to scale are a function of a CDN operator's specific business and network requirements, as well as the CDN components performance profile. Without a loss of generality, we discuss a CDN domain that consists of three (3) caching tiers and an Origin layer. End-clients connect to an Edge Cache. The Edge Cache might be configured to have access to one or more Mid-Tier Caches. These Mid-Tier Caches might have access to one or more Caches operating at a Root Caching tier. The Root Cache tier then has access to the Origin(s). We envision Caches being associated with a specific tier. A tier is defined simply as a numeric value between 0 and 255 that represents the layer in which this Cache operates in respect to other Caches within the CDN. A Caches tier only has significance within its CDN domain. We assume an Origin has a tier value of 0 and an Edge Cache has a tier value of 250. Edge-clients (or dCDNs) only access Edge Caches (those with a tier value of 250). Edge Caches and all Intermediate Caches can pull content from any Cache that is at a lower tier numeric value. Since a single CDN domain operates as a single BGP AS, it is this logical CDN tiering structure that enforces directionality of how content is pulledand thus prevent loops from forming inside the CDN. B. NLRI Format In the BGP URI AF, the BGP URI AF NLRI consists of three (3) routing constructs and one operational construct. The three routing constructs are: 1) the complete or partial URI prefix; 2) the tier of the Cache making the announcement; and 3) the IP address of this Cache. These are all self-explanatory. In the NLRI, we also embed information that is operationally useful to a CDN operatorspecifically the Cache reports the set of parent Cache IPs that it has installed into its FIB for this URI prefix. This piece of information is not necessary for the CDN to operate properly, but it greatly simplifies a key operational requirement, namely understanding what the CDN distribution tree looks like for a given URI prefix at any point in time. C. URI Prefix Selection URI prefix selection in this new AF is nearly identical to how BGP network path selection works. The one refinement is that a single CDN domain might have multiple caching tiers and we need to force the CDN delivery structure to be loop free across these tiers. This is done by augmenting the BGP prefix selection process with a tier validation step. Basically, a Cache operating at tier X should only consider BGP URI announcements from a CDN component that has a tier value less than X. This step assures the CDN to operate loop free. If a Cache (C-100) is operating at tier 100 and receives an announcement for some URI from a Cache (C-50) operating at tier 50, a Cache (C-20) operating at tier 20, and a cache (C- 200) operating at tier 200, the C-100 Cache will ignore the C- 200 announcement. C-100 will consider both the C-50 and C- 20 announcements, but will prefer the C-50 over C-20, as it is the closest to its own tier value. If the C-50 Cache announcement disappears from BGP or becomes invalid because the announcement next-hop is not present in the Caches routing table, C-100 will then select and install the C- 20 announcement into its Cache FIB. Note that since we use the base BGP prefix selection algorithm, the network distance to a next-hop Cache IP is 295 considered. It is this step in the prefix selection process that makes the Cache network aware. Much like in the classic BGP case, a network topology event would trigger the CDN to re-perform the URI path selection, thus enabling the Cache to always pick the nearest upstream Cache for pulling content. Further, given the use of the tiering mechanism to enforce a loop free CDN, multiple same tier parent Caches can be installed into a Cache FIB for some URI prefix, even if these parent Caches are at different network cost or metrics from the child Cache. Since we are using BGP, we can leverage all the existing BGP constructs and policies as part of making the CDN network aware. CDN network awareness for some aspects of the CDN operation might be based on the nearness of an upstream Cache (i.e. per Interior Gateway Protocol (IGP) cost or metrics). Alternatively, the CDN operation might want to use a policy to pick a specific upstream Cache and only use another if the primary Cache becomes unavailable (e.g. using the BGP LOCAL_PREF mechanism). All other normal BGP steps remain intact and are processed in the standard BGP prefix selection order. D. Logical CDNs and Using BGP Communities One of the key criterion in the CDN space we listed earlier was the need to treat a hot asset differently from a cold asset in terms of which CDN components might be used to service hot or cold content and how caching on these components might be configured (caching versus cut-through). We use the concept of BGP communities as both a tagging mechanism on a URI announcement and as a filtering mechanism on a Cache. Specifically, a CDN operator will select one BGP community value to indicate when an asset is hot and another community value when an asset is cold. Caches are configured with the BGP community values they are to support. A Cache configured to support hot content will accept URI announcements that have the hot BGP community tag. This Cache will then inbound drop all URI announcements that do not have the hot BGP community tag. Likewise, a Cache configured to support only cold assets will accept URI announcements with the cold BGP community tag and will inbound drop all other URI announcements. A CDN provider may have a more detailed business policy that can be enforced by applying additional BGP community values to the announcements and the Caches filtering logic. BGP communities become the mechanism to signal to the CDN the delivery treatment that should be applied for any URI at the current time. As assets transition from cold to hot and then back to cold, the CDN will have some internal analytics and associated business rules to determine when to treat (and BGP signal) a URI as hot or cold. The mechanism for determining hot and/or cold assets is outside the scope of this paper, but the real-time means to change the CDN treatment for a URI prefix is driven by applying the right BGP community to the URI announcement. E. Benefits of BGP in the CDN Space Before we talk about the benefits of using BGP for carrying content URI prefixes, we enumerate some base assumptions for the CDN BGP URI solution. A CDN domain need not use the same ASN as the underlying network ASN. In fact, a single CDN domain could span multiple network ASNs. To prevent URI namespace hijacking, all URI announcements should be secured using the mechanisms defined by the Secure Inter-Domain Routing working group. This URI AF only exists on Caches and Origins; it is not run on the routing infrastructure. The following points detail the benefits of using BGP: BGP is well known. Using BGP in the URI space means instant expertise and vetted implementations. The continuous refinement and capabilities added to the BGP protocol in the network domain instantly become available and applicable to the CDN domain. All existing operational tools available for network BGP analysis and capacity planning would instantly be useable in the CDN space. F. Additional Related BGP Address Families This paper has focused on a mechanism for how announcements from a CSP (or Origin) can percolate through a single CDN, or across multiple CDNs. The CDNI Footprint Advertisement Internet draft [3] details a similar approach that addresses how client prefix information is used to enable CDNs to announce or learn which IP prefixes are served by a CDN (or through a transition of CDNs). The approach put forth in this ID and the BGP URI AF approach proposed in this paper are very much aligned and complementary. The AF detailed in the ID addresses the request routing problem, while the BGP URI AF presented here addresses CDN delivery and associated URI treatment. In addition to these two AFs, we also propose an additional AF that is applicable in the CDN space. This additional AF is one where the prefix is a URI and the next-hop could be a URI or related control constructs (e.g. BGP community value(s)). The initial benefit of this is to allow an Edge Cache to rewrite a client URI to the target Origin URI namespace, but can also be used to promote or demote assets from cold to hot or vice versa. G. Scaling of BGP for CDNs BGP is the foundation for announcing both IPv4 and IPv6 connectivity Internet wide. The URI namespace is much larger than the IPv4 or IPv6 namespace. One might deduce that in the CDN namespace, there must be one or more CDNs that carry a default-free view of the URI namespace and thus come to the conclusion that the number of URI prefixes that need to be carried are of the order of the number of DNS domain names, which far exceed what is likely to be possible to be carried in BGP in the near future [9]. This thinking, however, is applying the Internet connectivity model to the CDN, which is both unnecessary and counter-productive to caching efficiency. Recall that the purpose of a CDN is to cache content. If one considers Internet content to be the library, then one can easily deduce that a vast majority of the URI namespace does not 296 yield value in being cached in a CDN. For instance, theres likely little value in caching content associated with the multitude of niche domain names. A CDN should only carry the URI namespace that results in caching efficiencies, meaning a CDN need only carry a very small portion of the entire Internet URI namespace in the BGP URI AF. A further constraint to the number of URIs that should be carried in a CDNs BGP URI AF is the CDN storage footprint. The CDN storage footprint places a very restrictive bound on how many assets can be cached and yield positive caching efficiencies. V. RELATED WORK The concepts presented within this paper clearly parallel the Content Centric Networking (CCN) paradigm [10] suggested by the researchers at PARC. The CCN approach uses Interest packets to signal directly on the routing infrastructure interested in some piece of content. It is suggested that these Interest packets are routed, implying there is some FIB-like mechanism used to determine which outgoing interface is closest to the desired URI. The CCN researchers, as do we, suggest announcing the URI information in some routing protocolthe CCN team suggests IGP, while we suggest announcing this content namespace in BGP. In the CCN space, it would be natural to extend carrying the content names between CCN domains using BGPmuch like we are proposing. The CCN approach suggests that one can use a routers line card packet buffers (the Content Store, or CS) to effectively cache content directly on the forwarding path. Our approach uses standalone Caches that connect into the routing infrastructure. In our proposed solution, content hairpins from the Router to the Cache, and back again to the Router, which is somewhat inefficient. The CCN approach attempts to cache the content in the CS. If the CS uses just the line card packet buffers, it seems highly unlikely much caching efficiencies will be gained in cores of large ISP networks. Given current and suggested future routing architectures, and associated technology limitations, the CS size will be many orders of magnitudes smaller (and more costly) than the storage one can expect in the stand-alone caching platform. What this means is that for the CS to be caching efficient, the number of assets it can cache will be very small relative to the stand-alone caching model, maybe to the point where little network bandwidth will be saved. The stand-alone caching model (dedicated Caches) leverages a Content Router to determine which requests use the CDN and which do not. What this means is that the CDN operator can choose which assets (or the number of assets) to run through the CDN and default everything else to direct client-Origin connectivity. We see no similar filtering functionality in the CCN architecture, which suggests that the CCN approach will struggle to provide useful caching efficiencies in the core of large ISP networks compared to the stand-alone caching approach. VI. CONCLUSION In this paper, we have proposed that BGP be augmented with a new AF to carry URL prefixes as a means to: 1) have both Caches and Origins use a single consistent open protocol to enable cross-vendor and platform inter-operability, 2) make the Caches aware of the network, and 3) enable CDNs to change the CDN performance or treatment provided to one or more assets over time. We have provided details on what the NLRI structure would look like, and detailed the URI prefix selection process. We have provided insight into why BGP is a sound and scalable approach to carry URI prefixes. We concluded with how this approach both aligns and differs from the CCN technology approach. ACKNOWLEDGEMENTS The authors would like to thank Bruce Davie for his comments and thoughts on earlier revisions of this paper. REFERENCES [1] Cisco, VNI - Forecast and Methodology, 2010-2015, http://www.cisco.com/en/US/solutions/collateral/ns341/ns525/ns537/ns7 05/ns827/white_paper_c11- 481360_ns827_Networking_Solutions_White_Paper.html, June 2011. [2] K. Lueng, Y. Lee - Content Distribution Network Interconnection (CDNI) Requirements, http://tools.ietf.org/html/draft-ietf-cdni- requirements-02 [3] S. Previdi, F. Le Faucheur, A Gilluou, J. Medved - CDNI Footprint Advertisement http://www.ietf.org/internet-drafts/draft-previdi-cdni-footprint- advertisement-00.txt [4] B. Niven-Jenkins, N. Bitar, J..Medved, S.Previdi - Use Cases for ALTO within CDNs draft-jenkins-alto-cdn-use-cases-01, June 2011 [5] H. Song, Y. Yang, R. Alimi - DECoupled Application Data Enroute (DECADE) Problem Statement, draft-ietf-decade-problem-statement-04, October 2011 [6] http://www.openflow.org/ [7] N. McKeown - Software Defined Networking http://tiny-tera.stanford.edu/~nickm/talks/infocom_brazil_2009_v1-1.pdf [8] T. Bates, R. Chandra, D. Katz, and Y. Rekhter, Multiprotocol Extensions for BGP-4, January 2007 [9] A, Narayan, D. Oran - NDN and routing can it scale?,http://trac.tools.ietf.org/group/irtf/trac/attachment/wiki/icnrg/IRT F%20-%20CCN%20And%20IP%20Routing%20-%202.pdf [10] V. Jacobson, D. K. Smetters, J. D. Thornton, M. F. Plass, N. H. Briggs, R. L. Braynard (PARC) - Networking Named Content, CoNEXT 2009, Rome, December, 2009. 297