Network Working Group J. Ren Internet-Draft City University of Hong Kong Intended status: Informational W. Liu Expires: April 18, 2013 Huawei Technologies J. Wang F. Tang City University of Hong Kong October 15, 2012 On the Content Retrieval In Information-Centric Network draft-ren-icn-content-retrieval-00 Abstract Information-Centric Network(ICN), as an emerging network architecture, focus on delivering content more efficiently. This brief paper discusses some issues about content retrieval in the Information-Centric Network. It first lists a set of basic requirements on the basis of previous literatures. Then, it tries to identify the fundamental functionalities required to satisfy the foregoing requirements. Last, it summarizes the implementation status of such functionalities in various Information-Centric Network architectures. 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 18, 2013. Copyright Notice Copyright (c) 2012 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 Ren, et al. Expires April 18, 2013 [Page 1] Internet-Draft Report of NAT Reveal TCP Options October 2012 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Requirements of content retrieval . . . . . . . . . . . . . . 4 4. Fundamental functionalities for content retrieval . . . . . . 4 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Content name resolution . . . . . . . . . . . . . . . . . 5 5.2. k-anycast and multicast . . . . . . . . . . . . . . . . . 6 5.3. Content replication . . . . . . . . . . . . . . . . . . . 7 5.4. In-network cache discovery . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Ren, et al. Expires April 18, 2013 [Page 2] Internet-Draft Report of NAT Reveal TCP Options October 2012 1. Introduction Information-Centric Network (also known as content-oriented network [CON], data-oriented network [DON], or name-based network [NBN]) is a new communication paradigm which puts the content at the center of the network architecture. It is motivated by the mismatch between the increasing demand for highly scalable and efficient distribution of content and inefficiently content delivery of the traditional host-centric communication paradigm. Content distribution, including file sharing and media streaming, has contributed to the ever-increasing Internet traffic nowadays. Content consumers, in general, are more concerned about what content they want than where that content resides. Unfortunately, current Internet is based on a host-centric communication paradigm where a consumer has to specify where the content is and the network only can deliver the content from the specified source to the consumer. Moreover, it is usually difficult to exploit many superior technologies, such as multicast, k-anycast, etc. To overcome the aforementioned issues, several Information-Centric Network designs have been proposed. In these designs, each content is given a unique name which is not associated with its location. Consumers can use the content name to request the content which they intend to get. More importantly, all the routings are based on the content name, which enables the request to be routed to any potential content sources. Moreover, many technologies, including content replication, caching, k-anycast etc., can now be used to achieve faster content retrieval. Although the Information-Centric Network is considered as a promising way to solve the aforementioned issues, ICN is still a work in progress and there is a long way to go for standardizing it. This paper tries to list a set of basic requirements and fundamental functionalities for content retrieval in ICN. We hope this work will benefit the design of ICN. 2. Terminology 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]. Content original provider: an end entity that publishes and provides the content. Content consumer: an end entity that wants to retrieve a content. Ren, et al. Expires April 18, 2013 [Page 3] Internet-Draft Report of NAT Reveal TCP Options October 2012 Content holder: any entity that has a complete copy of the content (including provider, router, cache, and other devices which hold the content). Content name: every content is given a unique name. Content consumer requests the content by specifying its name rather than its location. 3. Requirements of content retrieval To provide efficient content delivery, several requirements should be satisfied: 1. Persistency and unique content name. Each content should be given a unique name. This name should be valid as long as the corresponding content is available. In other words, the content name should not be changed no matter where it is. 2. Availability. Availability means the content should be reachable at all times with low-latency. Replication can be used to guarantee availability, and the network is responsible for finding the nearby copies which have low-latency. 3. Failure recovery. End-to-end communication is often disrupted due to the endpoint mobility and link/router failure. These disruptions should not disturb the content delivery. 4. Authenticity. Any communication entities, including router, end- device, application, etc., can verify whether the content comes from the authenticated source. 5. Bandwidth efficiency. Since the volume of content is huge, appropriate technologies should be used to minimize bandwidth consumption. 4. Fundamental functionalities for content retrieval The requirements listed above are the most important ones. More requirements will be added further. To satisfy these requirements, several fundamental functionalities should be provided: 1. Content name resolution. Name resolution service translates content name into network location. In ICN, multiple content holders can provide the same content. The requests should be directed to the intended content holder according to some policies, such as lowest delivery latency, minimum bandwidth utilization, etc. Ren, et al. Expires April 18, 2013 [Page 4] Internet-Draft Report of NAT Reveal TCP Options October 2012 2. K-anycast. K-anycast is a communication model which allows K servers to cooperate with each other to accomplish content delivery. With k-anycast, the network can deliver the content much faster and provide quick failure recovery. 3. Multicast. Multicast can be used to deliver content to all the content consumers interested in the content. It can effectively save the network bandwidth. 4. Content replication. Content can be stored in end-hosts according to some off-line replication policies. Well-designed replication policy can reduce the content retrieval time. 5. In-network cache discovery. In-network caching is considered as one of the most significant properties of ICN. To fully utilize the caches, however, the network needs a mechanism to discover the caches. 5. Summary This section summarizes the implementation status of the aforementioned fundamental functionalities in different ICN projects. In this draft, EU FP7 projects, US NSF projects and some academic projects are compared. 5.1. Content name resolution Ren, et al. Expires April 18, 2013 [Page 5] Internet-Draft Report of NAT Reveal TCP Options October 2012 +---------------+----------------------------------------------------------+ | SAIL/4 WARD | A Multilevel Distributed Hash Table (MDHT) is used to | | | establish a global resolution system. | +---------------+----------------------------------------------------------+ | PSIRP/PUIRUIT | Following a pub-sub communication model, a rendezvous | | | system is employed to notify the appropriate content | | | holder to send content to the requested consumers. | +---------------+----------------------------------------------------------+ | CONVERGENCE | Dedicate Name-System-Nodes (similar to DNS) are | | | deployed. | +---------------+----------------------------------------------------------+ | TRIAD | An Internet Relay Protocol (INRP) is designed to perform | | | name-to-address conversion in TRIAD by using the routing | | | information maintained by relay nodes. | +---------------+----------------------------------------------------------+ | COMET | A content resolution function is used to resolve content | | | names to content properties. | +---------------+----------------------------------------------------------+ | COAST | Search engine is used to partially provide content name | | | resolution service. | +---------------+----------------------------------------------------------+ | Postcards | A File Name Resolution System is employed to resolve | | from the Edge | file names to potential cached locations. | +---------------+----------------------------------------------------------+ | MobilityFirst | A Global name resolution service (GNRS) is developed for | | | Globally Unique Flat Identifier (GUID) to Network | | | Address (NA) mapping. The GNRS is implemented based on | | | DHT between routers. | +---------------+----------------------------------------------------------+ | NDN | Packets are routed based on the content name instead of | | | resolving the content name to an underlying address. | +---------------+----------------------------------------------------------+ 5.2. k-anycast and multicast Ren, et al. Expires April 18, 2013 [Page 6] Internet-Draft Report of NAT Reveal TCP Options October 2012 +---------------+----------------------------------------------------------+ | SAIL/4 WARD | Different chunks are retrieved from different locations | | | via several concurrent HTTP connections. | +---------------+----------------------------------------------------------+ | PSIRP/PUIRUIT | Forwarding Identifier (FID) is used for source routing. | | | Multiple FIDs can be integrated to form a multicast | | | tree. | +---------------+----------------------------------------------------------+ | CONVERGENCE | Traditional point-to-point sessions between two upper | | | layer entities can be supported by coupling the upper | | | layer entities with named-service-assess-points. This | | | functionality can be extended to support multicast. | +---------------+----------------------------------------------------------+ | TRIAD | The EXPRESS single-source model of multicast can be | | | supported. | +---------------+----------------------------------------------------------+ | COMET | NOT MENTIONED. | +---------------+----------------------------------------------------------+ | COAST | Multicast can be achieved through an Information | | | Overlay. | +---------------+----------------------------------------------------------+ | Postcards | Multicast trees are set up by using a Rendezvous Point | | from the Edge | (RP). | +---------------+----------------------------------------------------------+ | MobilityFirst | Multicast GUID are mapped to multiple consumers by GNRS. | +---------------+----------------------------------------------------------+ | NDN | Since PIT(Pending Interest Table) includes the set of | | | interfaces over which Interests have arrived, multicast | | | functionality can naturally be supported. | +---------------+----------------------------------------------------------+ 5.3. Content replication Ren, et al. Expires April 18, 2013 [Page 7] Internet-Draft Report of NAT Reveal TCP Options October 2012 +---------------+----------------------------------------------------------+ | SAIL/4 WARD | The content, called Information Objects (IOs), can be | | | stored in the NetInf architecture to speed up content | | | retrieval. | +---------------+----------------------------------------------------------+ | PSIRP/PUIRUIT | The most popular objects are replicated to different k | | | storage devices by using a greedy algorithm. | +---------------+----------------------------------------------------------+ | CONVERGENCE | Multiple replica nodes can be provisioned as Content | | | Delivery Network. | +---------------+----------------------------------------------------------+ | TRIAD | Content are replicated at multiple sites and DNS lookups | | | will be redirected to the nearby site. | +---------------+----------------------------------------------------------+ | COMET | Replication can be supported. However, no concrete | | | scheme is proposed. | +---------------+----------------------------------------------------------+ | COAST | The content may be stored/cached at the Information | | | Overlay or at the lower hierarchy layer. | +---------------+----------------------------------------------------------+ | Postcards | Replication can be supported. However, no concrete | | from the Edge | scheme is proposed. | +---------------+----------------------------------------------------------+ | MobilityFirst | The global GUID-NA mapping information are replicated in | | | k different ASes. | +---------------+----------------------------------------------------------+ | NDN | Replication can be supported. However, no concrete | | | scheme is proposed. | +---------------+----------------------------------------------------------+ 5.4. In-network cache discovery Ren, et al. Expires April 18, 2013 [Page 8] Internet-Draft Report of NAT Reveal TCP Options October 2012 +---------------+----------------------------------------------------------+ | SAIL/4 WARD | The cache information is advertised in local area. | +---------------+----------------------------------------------------------+ | PSIRP/PUIRUIT | The cache which is on the content request path can be | | | used. | +---------------+----------------------------------------------------------+ | CONVERGENCE | The cache which is on the content request path can be | | | used. | +---------------+----------------------------------------------------------+ | TRIAD | The cache which is on the content request path can be | | | used. | +---------------+----------------------------------------------------------+ | COMET | The cache which is on the content request path can be | | | used. | +---------------+----------------------------------------------------------+ | COAST | The cache discovery can be achieved by an Information | | | Overlay. | +---------------+----------------------------------------------------------+ | Postcards | A Caching Service Protocol is developed, which exchanges | | from the Edge | the cache information between different | | | Cache-and-Forward Nodes (CNFs). | +---------------+----------------------------------------------------------+ | MobilityFirst | Delay-Tolerant Networking (DTN) liked Caching and | | | forwarding design is proposed. | +---------------+----------------------------------------------------------+ | NDN | The cache which is on the content request path can be | | | used. Cache can also be discovered through flooding | | | content request. | +---------------+----------------------------------------------------------+ 6. IANA Considerations This document makes no request of IANA. 7. Security Considerations Security issues are not discussed in this memo. 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. Ren, et al. Expires April 18, 2013 [Page 9] Internet-Draft Report of NAT Reveal TCP Options October 2012 8.2. Informative References [COAST] COAST Home Page, "http://www.coast-fp7.eu/". [COMET] COMET Home Page, "http://www.comet-project.org/overview.html". [CON] C. Jaeyoung, et al., "A Survey on content-oriented networking for efficient content delivery", 2011. [CONVERGENCE] CONVERGENCE Home Page, "http://www.ict-convergence.eu/". [DON] T. Koponen, et al., "A data-oriented (and beyond) network architecture", 2007. [MobilityFirst] MobilityFirst Home Page, "http://mobilityfirst.winlab.rutgers.edu/". [NBN] V. Jacobson, et al., "Networking named content", 2009. [NDN] NDN Home Page, "http://www.named-data.net/index.html". [PSIRP] PSIRP Home Page, "http://www.psirp.org/". [PURSUIT] PURSUIT Home Page, "http://www.fp7-pursuit.eu/PursuitWeb/". [Postcards-From-The-Edge] Postcards from the Edge Home Page, "http://www.nets-find.net/Funded/Postcards.php". [SAIL] SAIL Home Page, "http://www.sail-project.eu/". [TRIAD] TRIAD Home Page, "http://gregorio.stanford.edu/triad/". [WARD] 4WARD Home Page, "http://www.4ward-project.eu/index.php". Ren, et al. Expires April 18, 2013 [Page 10] Internet-Draft Report of NAT Reveal TCP Options October 2012 Authors' Addresses Jing Ren City University of Hong Kong Tat Chee Avenue Hong Kong P.R. China Email: jingren@cityu.edu.hk Will Liu Huawei Technologies Bantian, Longgang District Shenzhen 518129 P.R. China Email: liushucheng@huawei.com JianPing Wang City University of Hong Kong Tat Chee Avenue Hong Kong P.R. China Email: jianwang@cityu.edu.hk Fei Tang City University of Hong Kong Tat Chee Avenue Hong Kong P.R. China Email: feitang@cityu.edu.hk Ren, et al. Expires April 18, 2013 [Page 11]