idnits 2.17.1 draft-ren-icn-content-retrieval-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 120 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 231 has weird spacing: '...trieved from ...' == Line 239 has weird spacing: '...ntities can b...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 15, 2012) is 4210 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'COAST' is defined on line 340, but no explicit reference was found in the text == Unused Reference: 'COMET' is defined on line 342, but no explicit reference was found in the text == Unused Reference: 'CONVERGENCE' is defined on line 348, but no explicit reference was found in the text == Unused Reference: 'MobilityFirst' is defined on line 354, but no explicit reference was found in the text == Unused Reference: 'NDN' is defined on line 360, but no explicit reference was found in the text == Unused Reference: 'PSIRP' is defined on line 362, but no explicit reference was found in the text == Unused Reference: 'PURSUIT' is defined on line 364, but no explicit reference was found in the text == Unused Reference: 'Postcards-From-The-Edge' is defined on line 367, but no explicit reference was found in the text == Unused Reference: 'SAIL' is defined on line 371, but no explicit reference was found in the text == Unused Reference: 'TRIAD' is defined on line 373, but no explicit reference was found in the text == Unused Reference: 'WARD' is defined on line 375, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 15 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Ren 3 Internet-Draft City University of Hong Kong 4 Intended status: Informational W. Liu 5 Expires: April 18, 2013 Huawei Technologies 6 J. Wang 7 F. Tang 8 City University of Hong Kong 9 October 15, 2012 11 On the Content Retrieval In Information-Centric Network 12 draft-ren-icn-content-retrieval-00 14 Abstract 16 Information-Centric Network(ICN), as an emerging network 17 architecture, focus on delivering content more efficiently. This 18 brief paper discusses some issues about content retrieval in the 19 Information-Centric Network. It first lists a set of basic 20 requirements on the basis of previous literatures. Then, it tries to 21 identify the fundamental functionalities required to satisfy the 22 foregoing requirements. Last, it summarizes the implementation 23 status of such functionalities in various Information-Centric Network 24 architectures. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 18, 2013. 43 Copyright Notice 45 Copyright (c) 2012 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Requirements of content retrieval . . . . . . . . . . . . . . 4 63 4. Fundamental functionalities for content retrieval . . . . . . 4 64 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 5.1. Content name resolution . . . . . . . . . . . . . . . . . 5 66 5.2. k-anycast and multicast . . . . . . . . . . . . . . . . . 6 67 5.3. Content replication . . . . . . . . . . . . . . . . . . . 7 68 5.4. In-network cache discovery . . . . . . . . . . . . . . . . 8 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 73 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 76 1. Introduction 78 Information-Centric Network (also known as content-oriented network 79 [CON], data-oriented network [DON], or name-based network [NBN]) is a 80 new communication paradigm which puts the content at the center of 81 the network architecture. It is motivated by the mismatch between 82 the increasing demand for highly scalable and efficient distribution 83 of content and inefficiently content delivery of the traditional 84 host-centric communication paradigm. 86 Content distribution, including file sharing and media streaming, has 87 contributed to the ever-increasing Internet traffic nowadays. 88 Content consumers, in general, are more concerned about what content 89 they want than where that content resides. Unfortunately, current 90 Internet is based on a host-centric communication paradigm where a 91 consumer has to specify where the content is and the network only can 92 deliver the content from the specified source to the consumer. 93 Moreover, it is usually difficult to exploit many superior 94 technologies, such as multicast, k-anycast, etc. 96 To overcome the aforementioned issues, several Information-Centric 97 Network designs have been proposed. In these designs, each content 98 is given a unique name which is not associated with its location. 99 Consumers can use the content name to request the content which they 100 intend to get. More importantly, all the routings are based on the 101 content name, which enables the request to be routed to any potential 102 content sources. Moreover, many technologies, including content 103 replication, caching, k-anycast etc., can now be used to achieve 104 faster content retrieval. 106 Although the Information-Centric Network is considered as a promising 107 way to solve the aforementioned issues, ICN is still a work in 108 progress and there is a long way to go for standardizing it. This 109 paper tries to list a set of basic requirements and fundamental 110 functionalities for content retrieval in ICN. We hope this work will 111 benefit the design of ICN. 113 2. Terminology 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in [RFC2119]. 119 Content original provider: an end entity that publishes and provides 120 the content. 122 Content consumer: an end entity that wants to retrieve a content. 124 Content holder: any entity that has a complete copy of the content 125 (including provider, router, cache, and other devices which hold the 126 content). 128 Content name: every content is given a unique name. Content consumer 129 requests the content by specifying its name rather than its location. 131 3. Requirements of content retrieval 133 To provide efficient content delivery, several requirements should be 134 satisfied: 136 1. Persistency and unique content name. Each content should be 137 given a unique name. This name should be valid as long as the 138 corresponding content is available. In other words, the content name 139 should not be changed no matter where it is. 141 2. Availability. Availability means the content should be reachable 142 at all times with low-latency. Replication can be used to guarantee 143 availability, and the network is responsible for finding the nearby 144 copies which have low-latency. 146 3. Failure recovery. End-to-end communication is often disrupted 147 due to the endpoint mobility and link/router failure. These 148 disruptions should not disturb the content delivery. 150 4. Authenticity. Any communication entities, including router, end- 151 device, application, etc., can verify whether the content comes from 152 the authenticated source. 154 5. Bandwidth efficiency. Since the volume of content is huge, 155 appropriate technologies should be used to minimize bandwidth 156 consumption. 158 4. Fundamental functionalities for content retrieval 160 The requirements listed above are the most important ones. More 161 requirements will be added further. To satisfy these requirements, 162 several fundamental functionalities should be provided: 164 1. Content name resolution. Name resolution service translates 165 content name into network location. In ICN, multiple content holders 166 can provide the same content. The requests should be directed to the 167 intended content holder according to some policies, such as lowest 168 delivery latency, minimum bandwidth utilization, etc. 170 2. K-anycast. K-anycast is a communication model which allows K 171 servers to cooperate with each other to accomplish content delivery. 172 With k-anycast, the network can deliver the content much faster and 173 provide quick failure recovery. 175 3. Multicast. Multicast can be used to deliver content to all the 176 content consumers interested in the content. It can effectively save 177 the network bandwidth. 179 4. Content replication. Content can be stored in end-hosts 180 according to some off-line replication policies. Well-designed 181 replication policy can reduce the content retrieval time. 183 5. In-network cache discovery. In-network caching is considered as 184 one of the most significant properties of ICN. To fully utilize the 185 caches, however, the network needs a mechanism to discover the 186 caches. 188 5. Summary 190 This section summarizes the implementation status of the 191 aforementioned fundamental functionalities in different ICN projects. 192 In this draft, EU FP7 projects, US NSF projects and some academic 193 projects are compared. 195 5.1. Content name resolution 196 +---------------+----------------------------------------------------------+ 197 | SAIL/4 WARD | A Multilevel Distributed Hash Table (MDHT) is used to | 198 | | establish a global resolution system. | 199 +---------------+----------------------------------------------------------+ 200 | PSIRP/PUIRUIT | Following a pub-sub communication model, a rendezvous | 201 | | system is employed to notify the appropriate content | 202 | | holder to send content to the requested consumers. | 203 +---------------+----------------------------------------------------------+ 204 | CONVERGENCE | Dedicate Name-System-Nodes (similar to DNS) are | 205 | | deployed. | 206 +---------------+----------------------------------------------------------+ 207 | TRIAD | An Internet Relay Protocol (INRP) is designed to perform | 208 | | name-to-address conversion in TRIAD by using the routing | 209 | | information maintained by relay nodes. | 210 +---------------+----------------------------------------------------------+ 211 | COMET | A content resolution function is used to resolve content | 212 | | names to content properties. | 213 +---------------+----------------------------------------------------------+ 214 | COAST | Search engine is used to partially provide content name | 215 | | resolution service. | 216 +---------------+----------------------------------------------------------+ 217 | Postcards | A File Name Resolution System is employed to resolve | 218 | from the Edge | file names to potential cached locations. | 219 +---------------+----------------------------------------------------------+ 220 | MobilityFirst | A Global name resolution service (GNRS) is developed for | 221 | | Globally Unique Flat Identifier (GUID) to Network | 222 | | Address (NA) mapping. The GNRS is implemented based on | 223 | | DHT between routers. | 224 +---------------+----------------------------------------------------------+ 225 | NDN | Packets are routed based on the content name instead of | 226 | | resolving the content name to an underlying address. | 227 +---------------+----------------------------------------------------------+ 229 5.2. k-anycast and multicast 230 +---------------+----------------------------------------------------------+ 231 | SAIL/4 WARD | Different chunks are retrieved from different locations | 232 | | via several concurrent HTTP connections. | 233 +---------------+----------------------------------------------------------+ 234 | PSIRP/PUIRUIT | Forwarding Identifier (FID) is used for source routing. | 235 | | Multiple FIDs can be integrated to form a multicast | 236 | | tree. | 237 +---------------+----------------------------------------------------------+ 238 | CONVERGENCE | Traditional point-to-point sessions between two upper | 239 | | layer entities can be supported by coupling the upper | 240 | | layer entities with named-service-assess-points. This | 241 | | functionality can be extended to support multicast. | 242 +---------------+----------------------------------------------------------+ 243 | TRIAD | The EXPRESS single-source model of multicast can be | 244 | | supported. | 245 +---------------+----------------------------------------------------------+ 246 | COMET | NOT MENTIONED. | 247 +---------------+----------------------------------------------------------+ 248 | COAST | Multicast can be achieved through an Information | 249 | | Overlay. | 250 +---------------+----------------------------------------------------------+ 251 | Postcards | Multicast trees are set up by using a Rendezvous Point | 252 | from the Edge | (RP). | 253 +---------------+----------------------------------------------------------+ 254 | MobilityFirst | Multicast GUID are mapped to multiple consumers by GNRS. | 255 +---------------+----------------------------------------------------------+ 256 | NDN | Since PIT(Pending Interest Table) includes the set of | 257 | | interfaces over which Interests have arrived, multicast | 258 | | functionality can naturally be supported. | 259 +---------------+----------------------------------------------------------+ 261 5.3. Content replication 262 +---------------+----------------------------------------------------------+ 263 | SAIL/4 WARD | The content, called Information Objects (IOs), can be | 264 | | stored in the NetInf architecture to speed up content | 265 | | retrieval. | 266 +---------------+----------------------------------------------------------+ 267 | PSIRP/PUIRUIT | The most popular objects are replicated to different k | 268 | | storage devices by using a greedy algorithm. | 269 +---------------+----------------------------------------------------------+ 270 | CONVERGENCE | Multiple replica nodes can be provisioned as Content | 271 | | Delivery Network. | 272 +---------------+----------------------------------------------------------+ 273 | TRIAD | Content are replicated at multiple sites and DNS lookups | 274 | | will be redirected to the nearby site. | 275 +---------------+----------------------------------------------------------+ 276 | COMET | Replication can be supported. However, no concrete | 277 | | scheme is proposed. | 278 +---------------+----------------------------------------------------------+ 279 | COAST | The content may be stored/cached at the Information | 280 | | Overlay or at the lower hierarchy layer. | 281 +---------------+----------------------------------------------------------+ 282 | Postcards | Replication can be supported. However, no concrete | 283 | from the Edge | scheme is proposed. | 284 +---------------+----------------------------------------------------------+ 285 | MobilityFirst | The global GUID-NA mapping information are replicated in | 286 | | k different ASes. | 287 +---------------+----------------------------------------------------------+ 288 | NDN | Replication can be supported. However, no concrete | 289 | | scheme is proposed. | 290 +---------------+----------------------------------------------------------+ 292 5.4. In-network cache discovery 293 +---------------+----------------------------------------------------------+ 294 | SAIL/4 WARD | The cache information is advertised in local area. | 295 +---------------+----------------------------------------------------------+ 296 | PSIRP/PUIRUIT | The cache which is on the content request path can be | 297 | | used. | 298 +---------------+----------------------------------------------------------+ 299 | CONVERGENCE | The cache which is on the content request path can be | 300 | | used. | 301 +---------------+----------------------------------------------------------+ 302 | TRIAD | The cache which is on the content request path can be | 303 | | used. | 304 +---------------+----------------------------------------------------------+ 305 | COMET | The cache which is on the content request path can be | 306 | | used. | 307 +---------------+----------------------------------------------------------+ 308 | COAST | The cache discovery can be achieved by an Information | 309 | | Overlay. | 310 +---------------+----------------------------------------------------------+ 311 | Postcards | A Caching Service Protocol is developed, which exchanges | 312 | from the Edge | the cache information between different | 313 | | Cache-and-Forward Nodes (CNFs). | 314 +---------------+----------------------------------------------------------+ 315 | MobilityFirst | Delay-Tolerant Networking (DTN) liked Caching and | 316 | | forwarding design is proposed. | 317 +---------------+----------------------------------------------------------+ 318 | NDN | The cache which is on the content request path can be | 319 | | used. Cache can also be discovered through flooding | 320 | | content request. | 321 +---------------+----------------------------------------------------------+ 323 6. IANA Considerations 325 This document makes no request of IANA. 327 7. Security Considerations 329 Security issues are not discussed in this memo. 331 8. References 333 8.1. Normative References 335 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 336 Requirement Levels", BCP 14, RFC 2119, March 1997. 338 8.2. Informative References 340 [COAST] COAST Home Page, "http://www.coast-fp7.eu/". 342 [COMET] COMET Home Page, 343 "http://www.comet-project.org/overview.html". 345 [CON] C. Jaeyoung, et al., "A Survey on content-oriented 346 networking for efficient content delivery", 2011. 348 [CONVERGENCE] 349 CONVERGENCE Home Page, "http://www.ict-convergence.eu/". 351 [DON] T. Koponen, et al., "A data-oriented (and beyond) network 352 architecture", 2007. 354 [MobilityFirst] 355 MobilityFirst Home Page, 356 "http://mobilityfirst.winlab.rutgers.edu/". 358 [NBN] V. Jacobson, et al., "Networking named content", 2009. 360 [NDN] NDN Home Page, "http://www.named-data.net/index.html". 362 [PSIRP] PSIRP Home Page, "http://www.psirp.org/". 364 [PURSUIT] PURSUIT Home Page, 365 "http://www.fp7-pursuit.eu/PursuitWeb/". 367 [Postcards-From-The-Edge] 368 Postcards from the Edge Home Page, 369 "http://www.nets-find.net/Funded/Postcards.php". 371 [SAIL] SAIL Home Page, "http://www.sail-project.eu/". 373 [TRIAD] TRIAD Home Page, "http://gregorio.stanford.edu/triad/". 375 [WARD] 4WARD Home Page, "http://www.4ward-project.eu/index.php". 377 Authors' Addresses 379 Jing Ren 380 City University of Hong Kong 381 Tat Chee Avenue 382 Hong Kong 383 P.R. China 385 Email: jingren@cityu.edu.hk 387 Will Liu 388 Huawei Technologies 389 Bantian, Longgang District 390 Shenzhen 518129 391 P.R. China 393 Email: liushucheng@huawei.com 395 JianPing Wang 396 City University of Hong Kong 397 Tat Chee Avenue 398 Hong Kong 399 P.R. China 401 Email: jianwang@cityu.edu.hk 403 Fei Tang 404 City University of Hong Kong 405 Tat Chee Avenue 406 Hong Kong 407 P.R. China 409 Email: feitang@cityu.edu.hk