Browse Prior Art Database

DATAPLANE-TRIGGERED CONTENT CACHE IN CONTENT-CENTRIC NETWORKING USING REVERSE PATH TUNNELED RESPONSE

IP.com Disclosure Number: IPCOM000248113D
Publication Date: 2016-Oct-26
Document File: 5 page(s) / 575K

Publishing Venue

The IP.com Prior Art Database

Related People

Carlos M. Pignataro: AUTHOR [+3]

Abstract

Provided herein is a method of using a content-centric header of an "Interest" packet to signal whether the content object Data traffic should follow a reverse path to the client (i.e., "breadcrumb" routing), a shortest/selective path to the client, or a combination thereof.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 42% of the total text.

Page 01 of 5

DATAPLANE-TRIGGERED CONTENT CACHE IN CONTENT-CENTRIC NETWORKING USING REVERSE PATH TUNNELED RESPONSE

AUTHORS:

Carlos M. Pignataro
Nagendra Nainar

Rajiv Asati

CISCO SYSTEMS, INC.

ABSTRACT

    Provided herein is a method of using a content-centric header of an "Interest" packet to signal whether the content object Data traffic should follow a reverse path to the client (i.e., "breadcrumb" routing), a shortest/selective path to the client, or a combination thereof.

DETAILED DESCRIPTION

    In content-centric networking (CNN), the data traffic/flow is based on a content identifier instead of a host identifier. To improve efficiency, CCN allows transit nodes to cache the data and serve any future request directly. In such a dynamic caching environment, upon receiving a request for a content object that is not available, a server forwards an Interest packet to the next server and creates entries in a Pending Interest Table (PIT). In breadcrumb routing frameworks, the Data packet (i.e., the response to the Interest packet) follows the exact reverse path of the Interest packet. Because breadcrumb routing is seen as a challenge/disadvantage, there are proposals to reply back to the client directly based on the shortest/best path instead of breadcrumb routing.

    Current proposals focus on the particular way in which the Data traffic follows breadcrumb-based routing (i.e., exact reverse path) or shortest/best path. However, there is currently no way to control whether the Data packet should follow the same reverse path or the shortest path.

    Traditional proposals are often based on breadcrumb routing, in which the Data packet follows the exact reverse path of the corresponding Interest packet. While such

Copyright 2016 Cisco Systems, Inc.

1


Page 02 of 5

breadcrumb routing helps the transit nodes to cache the Data packet, there are challenges to this approach. Depending on the transit node caching capability/storage or policy, not all the transit CCN forwarders cache all the Data packets. As a result, it is not necessary for Data packets to follow the exact reverse path in all situations. As illustrated in Figure 1 below, the Interest packet is transmitted from the client at R5 to R4, then to R2, and then to R6 before arriving at the object. Under a breadcrumb routing framework, the Data packet travels along the R6-R2-R4-R5-Client path even though the best (i.e., shortest) path available is the path from R6 to R5.

Figure 1

    Provided herein is a simple dataplane-triggered approach in which the Interest packet signals whether the Data packet should be breadcrumb-routed or shortest-path- routed. In particular, the CCN header of the "Interest" packet signals whether the content object data traffic should follow a reverse path (i.e., breadcrumb routing) or the shortest/selective path to the client. This may be decided differently by every forwarder.

    For example, if a transit CCN forwarder intends (e.g., based on its preference) to be in the reverse path (i.e....