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]