Abstract: One embodiment provides a system that facilitates an intermediate node to handle a potential timeout event. During operation, the system receives, by an intermediate node, a keep-alive control packet which indicates a name for an Interest message, an indicator to keep alive a Pending Interest Table (PIT) entry, and a time period for which to keep the PIT entry alive. The intermediate node determines whether the keep-alive control packet corresponds to the PIT entry based on the name, and, responsive to determining that the keep-alive control packet corresponds to the PIT entry, updates a timeout value of the PIT entry based on the time period indicated in the keep-alive control packet. Responsive to determining one or more interfaces specified in the PIT entry from which the Interest message is received, the intermediate node forwards the keep-alive control packet to the one or more interfaces.

Abstract: One embodiment provides a transport-framework system that facilitates command messages to be communicated in a layer-agnostic manner. During operation, the system generates, by a component of a stack of communication modules, a first command message for a target entity. The first command message includes a name unique to the target entity, and the stack does not require a respective communication module to communicate only with a layer above or below thereof. The component sends the first command message to the target entity by inserting the first command message into a queue corresponding to the component. The component can also receive a second command message from a sending entity via a queue corresponding to the sending entity, and the second command message includes a name unique to the component. This facilitates command messages to be communicated in a layer-agnostic manner.

Abstract: An identity management and initialization scheme, along with a naming scheme for a transport stack and its components, facilitates directly addressing each component in the transport stack. During operation, the system receives, by a forwarder, a packet that corresponds to an interest, where the interest includes a name. In response to determining that the interest is destined for a component of a stack of communication modules, the forwarder sends the interest to the destined component based on the name for the interest, where the stack does not require a respective communication module to communicate only with a layer above or below thereof. In response to determining that the interest is not destined for a component of the stack, the forwarder sends the interest to a network element based on the name for the interest. This facilitates directly addressing individual components of the stack.

Abstract: A packet-forwarding network node can process a programmable packet based on a reputation value for a name prefix to perform a customized operation on a local resource. The programmable packet can include a name prefix, and a header comprising reputation criteria for the packet's name prefix and one or more resource fields. A resource field can include instructions that perform an operation on a corresponding resource of the network node. When the network node receives the programmable packet, the node determines a reputation value for the name prefix at the local node, and compares this reputation value to the packet's reputation criteria. If the reputation value for the name prefix at the local node satisfies the reputation criteria, the node proceeds to execute the one or more instructions of the respective resource field to perform the operation on the corresponding resource.

Abstract: One embodiment of the present invention provides a system for performing concurrent hashing of packet streams. During operation, the system receives a stream of packets at a controller. The controller then identifies types and parameters for a plurality of different hashing operations based on a received packet. The controller further sends the packet concurrently to corresponding different hashing modules to produce different hash values, which can be used to facilitate packet forwarding.

Abstract: A computer system can perform service discovery in a content-centric network (CCN) by receiving a registration interest associated with a service from a service provider, and generating a confirmation content object in response to the registration interest. The confirmation content object includes at least a name for the service and an admission token. The computer system then returns the confirmation content object to the service provider, thereby enabling the service provider to provide the service to the CCN.

Abstract: A device can process commands from a remote device that manages the local device over a content centric network. During operation, the device can receive an Interest for managing a device resource, such that the Interest's name includes a name or a name prefix associated with the device resource, and includes a command for managing the resource. If the device determines that the name prefix corresponds to the local device, the device analyzes the Interest's command to determine a device resource and performs the resource-managing operation on the device resource. If the name prefix does not correspond to the local device, the device performs a longest-prefix-matching lookup using the Interest's name prefix to determine a destination for the Interest. If the Interest's destination corresponds to a component of the local device, the device forwards the Interest to the component or a local agent for the component.

Abstract: A transport-framework system facilitates instantiating a custom transport stack. During operation, the system can obtain a stack requirement for a custom stack. The stack requirement can specify component attributes and a policy for one or more components to instantiate in the custom stack. The system can select a stack component that satisfies the stack requirement for the custom stack, and can instantiate the stack component in the custom stack. For example, the system can select a stack component by analyzing the stack requirement to determine a component requirement for a component that needs to be instantiated in the custom stack. The system determines, from a component repository, a set of matching components that satisfies the component requirement. If multiple matching components exist, the system selects a matching component which is most compatible with other components in the custom stack.

Abstract: One embodiment provides a system that facilitates direct seeking of the ordered content of a manifest based on external metadata. During operation, the system determines, by a content producing device, a root manifest, wherein a manifest indicates a set of content objects and their corresponding digests, wherein a respective content object is a data object or another manifest, and is associated with a name that is a hierarchically structured variable length identifier (HSVLI) which comprises contiguous name components ordered from a most general level to a most specific level. The system generates an index associated with the root manifest, wherein the index allows the set of content objects indicated in the root manifest to be searched and accessed directly, thereby facilitating a content consumer to seek to a desired location in the content represented by the root manifest.

Abstract: A network forwarder can use a Manifest to allocate resources in a content centric network (CCN). Specifically, the forwarder can include a Manifest table which stores a Manifest state for a set of pending Manifests. Each Manifest can include a name associated with a data collection, and includes a list of references to Content Objects that make up the data collection. When the forwarder receives a Manifest for a data collection, the forwarder creates an entry for the Manifest in the Manifest table, and allocates one or more resources for processing the Manifest. When the forwarder receives an Interest, the forwarder performs a lookup in the Manifest table based on the Interest's name to determine whether the Interest is associated with a pending Manifest. If the Interest matches a Manifest state stored in the Manifest table, the forwarder processes the Interest and the Manifest based on the Manifest state.

Abstract: A route-tracing application can measure the performance of a path in a named-data network using trace agents deployed across various network nodes. During operation, a network node can process a route-tracing Interest by performing a lookup operation in a forwarding information base (FIB) using the Interest's name, in which a respective FIB entry may map the name to a forwarding rule. If the FIB does not include an entry for the Interest's route-tracing name, a trace agent at the network node determines one or more outbound interfaces for the route-tracing operation based on the Interest's name, and creates new route-tracing FIB entries that each maps the Interest's name to a forwarding rule for the determined interfaces. The network node returns a Content Object that satisfies the Interest, in which the Content Object includes the names of the new FIB entries, as well as performance information for the path.

Abstract: One embodiment provides a system that facilitates routers in verifying content objects in a cost-effective manner by aggregating content objects into a secure content catalog. During operation, a client computing device receives a secure content catalog, which indicates a set of content objects and their corresponding digests. The catalog is digitally signed with the private key of a producer of the catalog. The client computing device constructs an interest for a content object, where the interest indicates a name for the content object and the corresponding digest for the content object, which is based on the secure content catalog. The name for the request content object is a hierarchically structured variable length identifier (HSVLI) which comprises name components ordered from a most general level to a most specific level.

Abstract: A network-configuring system creates stable virtual interfaces for groups of neighboring network nodes. During operation, the system can obtain network-neighborhood information from one or more network neighbors. This network-neighborhood information includes duplex-neighborhood information that indicates at least a set of neighboring devices to the network neighbor, and a set of remote network nodes which are accessible via a respective neighbor. The system can use the network-neighborhood information to determine one or more groups of network neighbors with common network characteristics, such that a respective group includes one or more mutually-connected network peers. The system can then define a virtual interface for a respective group of stable network neighbors, such that the virtual interface's member nodes include the local network node and the respective group's mutually-connected network peers.

Abstract: A content-discovery system allows a node in a Content Centric Networks (CCN) to discover content over CCN. The CCN node can generate an Interest that includes a query for discovering content associated with a given name prefix, and after disseminating the Interest over CCN, can receive a query-result Content Object that includes a listing of matching Content Objects and their reputation information. The CCN node can also process Interests issued by other CCN nodes that would like to discover content. After receiving an Interest comprising a query for discovering content, the CCN node searches a repository for a set of Content Objects that match the query. The CCN node generates a results list that includes the Content Object in the search results and their reputation information. The CCN node then generates and returns a query-result Content Object that includes the Interest's name, and whose payload includes the results list.

Abstract: One embodiment provides a system that facilitates an intermediate node to handle a potential timeout event. During operation, the system receives, by an intermediate node, a keep-alive control packet which indicates a name for an Interest message, an indicator to keep alive a Pending Interest Table (PIT) entry, and a time period for which to keep the PIT entry alive. The intermediate node determines whether the keep-alive control packet corresponds to the PIT entry based on the name, and, responsive to determining that the keep-alive control packet corresponds to the PIT entry, updates a timeout value of the PIT entry based on the time period indicated in the keep-alive control packet. Responsive to determining one or more interfaces specified in the PIT entry from which the Interest message is received, the intermediate node forwards the keep-alive control packet to the one or more interfaces.

Abstract: A replica management system facilitates maintaining a distributed and fault-tolerant state for a variable over an Information Centric Network (ICN) by replicating the variable across a set of ICN nodes. During operation, a variable-hosting ICN node can receive an Interest that includes a value-updating command for a replica instance of the variable, current values for a set of replicas of the variable, and a new value for the variable. The ICN node can determine, based on the current values for the set of replica variables, whether the current value for the local replica variable is an authoritative value. If so, the ICN node updates the local replica variable to the new value. However, if the current local value is not the authoritative value, the ICN node rolls back a state of the local replica variable to a previous state, and updates the local replica variable to the new value.

Abstract: A network device can process a payload in an Interest packet. During operation, the network device can receive an Interest packet that includes a name or a name prefix associated with one or more target entities for the Interest. If the network device determines that the Interest packet includes a payload, the network node can analyze the Interest's name and/or payload to determine an operation to perform for processing the payload. The network device then proceeds to process the payload by performing the determined operation.

Abstract: A network node can use reputation values to determine when to forego validating a cached Content Object's authenticity. During operation, the network node can receive an Interest over a Content Centric Network (CCN). If the Content Store includes a matching Content Object that satisfies the Interest, the node obtains the cached Content Object. The node then determines whether the Interest includes a validation token that is to be used to validate the Content Object's authenticity. If so, the node determines a reputation value for the Content Object, such that the reputation value indicates a likelihood that validation of the Content Object's authenticity will be successful. If the network node determines that the reputation value exceeds a predetermined threshold, the node returns the Content Object without validating the Content Object's authenticity.

Abstract: A packet-forwarding network node can process a programmable packet based on a reputation value for a name prefix to perform a customized operation on a local resource. The programmable packet can include a name prefix, and a header comprising reputation criteria for the packet's name prefix and one or more resource fields. A resource field can include instructions that perform an operation on a corresponding resource of the network node. When the network node receives the programmable packet, the node determines a reputation value for the name prefix at the local node, and compares this reputation value to the packet's reputation criteria. If the reputation value for the name prefix at the local node satisfies the reputation criteria, the node proceeds to execute the one or more instructions of the respective resource field to perform the operation on the corresponding resource.

Abstract: One embodiment provides a system that facilitates a content requesting device to handle a potential timeout event. During operation, the system receives, by a content producing device, a packet that corresponds to a first Interest message from a content requesting device, where the first Interest includes a name. Responsive to determining that additional time is required to generate a matching Content Object for the first Interest, the system generates a notification message which indicates a time period after which a second Interest is to be sent out by the content requesting device. The name for the second Interest can be the same as the name for the first Interest or a new name as indicated in the notification message. The system transmits the notification message to the content requesting device, thereby facilitating the content requesting device to handle a potential timeout event.