Updating a transport stack in a content centric network

Abstract

One embodiment provides a transport stack updating system that facilitates updating a component of a transport stack of a computer system. During operation, the system sets, by a component of the transport stack, a state of the component as quiesced in response to receiving a pause message. A component in the quiesced state is precluded from processing an interest or a content object. The system determines whether the pause message triggers a rejection passes an acknowledgment message of the pause message up the transport stack. The acknowledgment message indicates that the pause message has been successfully processed by a respective component of the transport stack.

Description

BACKGROUND

Field

This disclosure is generally related to a transport framework. More specifically, this disclosure is related to a method and system for facilitating command messages to be communicated in a layer-agnostic manner between components of the same or different stacks.

Related Art

The proliferation of the Internet and e-commerce continues to create a vast amount of digital content. Content centric network (CCN) architectures have been designed to facilitate accessing and processing such digital content. A CCN includes entities, or nodes, such as network clients, forwarders (e.g., routers), and content producers, which communicate with each other by sending “interest” packets for various content items and receiving “content object” packets in return. CCN interests and content objects are identified by their unique names, which are typically hierarchically structured variable-length identifiers (HSVLI). An HSVLI can include contiguous name components ordered from a most general level to a most specific level.

A CCN node implements a transport stack, which includes layers of independent components that forward messages to one another. A component in the stack can also be referred to as a module. The stack is assembled and initialized at when a CCN node is initiated. The stack implements CCN protocols and integrates external services, such as caches, identity, key, and certificate services. The stack also facilitates control messages to coordinate operations. The node uses the stack to forward messages with interests and content objects.

Each component of the stack can process the messages in either direction. This can change the system state of the node or modify message contents. Furthermore, the component may queue the messages or generate new messages. In addition, the node can modify the transport stack (e.g., can insert a new component or remove an existing component). Such modifications may require coordination among the components. In order to avoid duplicate or interfering operations by the components, configuration, control, and management of the components may require the ability to guarantee a known state for a period of time necessary to implement and activate new state or change its configuration.

SUMMARY

One embodiment provides a transport stack updating system that facilitates updating a component of a transport stack of a computer system. During operation, the system sets, by a component of the transport stack, a state of the component as quiesced in response to receiving a pause message. A component in the quiesced state is precluded from processing an interest or a content object. The system determines whether the pause message triggers a rejection passes an acknowledgment message of the pause message up the transport stack. The acknowledgment message indicates that the pause message has been successfully processed by a respective component of the transport stack.

In a variation on this embodiment, the component is a final component of the transport stack. The system then generates the acknowledgment message in response to receiving the pause message.

In a variation on this embodiment, the system receives an update message and, in response, updates the component based on the content of the update message.

In a variation on this embodiment, the system sends an update failure message up the transport stack in response to determining that the pause message triggers a rejection.

In a further variation, reasons for rejection include one or more of: a stack component detecting a timeout event, processing a back flow, or identifying inter-dependent messages.

In a variation on this embodiment, the system sets the state of the component as active in response to receiving a resume message. A component in the active state resumes processing an interest or a content object.

In a variation on this embodiment, the pause message is an interest message. The system then transfers control to an administrator agent for updating the component.

In a variation on this embodiment, a name for a component of the transport stack is based on one or more of: a hierarchically structured variable length identifier (HSVLI), which comprises contiguous name components ordered from a most general level to a most specific level, wherein the HSVLI is applicable in a portal instance corresponding to the stack; a flat name that does not indicate any hierarchy; a role of the component of the stack; and a unique identifier which is specific to the component of the stack.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1A illustrates an exemplary content centric network (CCN) that facilitates updating a transport stack based on quiescing, in accordance with an embodiment of the present invention.

FIG. 1B illustrates an exemplary transport stack of a CCN node, in accordance with an embodiment of the present invention.

FIG. 2A illustrates an exemplary communication that initiates quiescing of a transport stack, in accordance with an embodiment of the present invention.

FIG. 2B illustrates an exemplary communication that updates a transport stack, in accordance with an embodiment of the present invention.

FIG. 2C illustrates an exemplary communication that updates a transport stack based on control sharing, in accordance with an embodiment of the present invention.

FIG. 2D illustrates an exemplary communication of an unsuccessful quiescing of a transport stack, in accordance with an embodiment of the present invention.

FIG. 3 presents a flow chart illustrating a method for quiescing and updating a transport stack, in accordance with an embodiment of the present invention.

FIG. 4A presents a flow chart illustrating a method for quiescing and updating a module of a transport stack, in accordance with an embodiment of the present invention.

FIG. 4B presents a flow chart illustrating a method for quiescing and updating a final stack component of a transport stack, in accordance with an embodiment of the present invention.

FIG. 5 illustrates an exemplary apparatus that facilitates updating a transport stack based on quiescing, in accordance with an embodiment of the present invention.

FIG. 6 illustrates an exemplary computer system that facilitates updating a transport stack based on quiescing, in accordance with an embodiment of the present invention.

In the figures, like reference numerals refer to the same figure elements.

DETAILED DESCRIPTION

The following description is presented to enable any person skilled in the art to make and use the embodiments, and is provided in the context of a particular application and its requirements. Various modifications to the disclosed embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the present disclosure. Thus, the present invention is not limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features disclosed herein.

Overview

Embodiments of the present invention solve the problem of efficiently updating a stack module of a CCN node by quiescing the stack components during the updating process. In this way, the operations required for the update can be executed without interruption before the stack is allowed to continue regular operations. The node provides a set of network components that can be combined into a transport “stack” that achieves communication functionality.

Each of the components within a transport stack performs a specific function, and some components can implement a functionality that is more specific or more generic than other versions of the same component. Some components may take parameters at load time that define their behavior, and some components may be configured at runtime based on parameters that they receive from a local application or from a device over the network. For example, some components may adapt to changing operating environment conditions or network conditions over time. The transport stack provides a way for configuration messages and information to be sent between the components, thereby allowing components within the stack to communicate with each other.

In some embodiments, an administrator agent of the CCN node can update a component of the stack (e.g., add a new component or update an existing component). To ensure consistency, the agent sends a pause message down the stack. A component receives the pause message and flushes the local buffer (e.g., empties the message buffer associated with the component). The component stops further processing of messages (e.g., interests and content objects), sets the local state as “quiesced,” and passes the pause message down the stack to the next component.

When the pause message reaches the final component of the stack, which is typically a forwarder adapter, the final component flushes the local buffer and sets the local state as quiesced. The final component then generates an acknowledgment message and sends the acknowledgment message up the stack. A respective component passes the acknowledgment message up the stack. The agent receives the acknowledgment message and determines that the stack has been successfully quiesced. The agent then passes an update message down the stack and updates the component. When the component is updated, the agent passes a resume message down the stack, thereby instructing a respective component to resume operation.

In some embodiments, a transport stack operates under the CCN architecture. In CCN, each piece of content is individually named, and each piece of data is bound to a unique name that distinguishes the data from any other piece of data, such as other versions of the same data or data from other sources. This unique name allows a network device to request the data by disseminating a request or an interest that indicates the unique name, and can obtain the data independently of the data's storage location, network location, application, and means of transportation. The following terms are used to describe the CCN architecture:

Content Object (or “content object”): A single piece of named data, which is bound to a unique name. Content Objects are “persistent,” which means that a Content Object can move around within a computing device, or across different computing devices, but does not change. If any component of the Content Object changes, the entity that made the change creates a new Content Object that includes the updated content, and binds the new Content Object to a new unique name.

Unique Names: A name in a CCN is typically location-independent and uniquely identifies a Content Object. A data-forwarding device can use the name or name prefix to forward a packet toward a network node that generates or stores the Content Object, regardless of a network address or physical location for the Content Object. In some embodiments, the name may be a hierarchically structured variable-length identifier (HSVLI). The HSVLI can be divided into several hierarchical components, which can be structured in various ways. For example, the individual name components pare, home, ccn, and test.txt can be structured in a left-oriented, prefix-major fashion to form the name “/parc/home/ccn/test.txt.” Thus, the name “/parc/home/ccn” can be a “parent” or “prefix” of “/parc/home/ccn/test.txt.” Additional components can be used to distinguish among different versions of the content item, such as a collaborative document.

In some embodiments, the name can include an identifier, such as a hash value that is derived from the Content Object's data (e.g., a checksum value) and/or from elements of the Content Object's name. A description of a hash-based name is described in U.S. patent application Ser. No. 13/847,814, which is herein incorporated by reference. A name can also be a flat label. Hereinafter, “name” is used to refer to any name for a piece of data in a name-data network, such as a hierarchical name or name prefix, a flat name, a fixed-length name, an arbitrary-length name, or a label (e.g., a Multiprotocol Label Switching (MPLS) label).

Interest (or “interest”): A packet that indicates a request for a piece of data, and includes a name (or a name prefix) for the piece of data. A data consumer can disseminate a request or Interest across an information-centric network, which CCN/NDN routers can propagate toward a storage device (e.g., a cache server) or a data producer that can provide the requested data to satisfy the request or Interest.

In addition, “lei” and “ccnx” refer to labeled content information and indicate a Universal Resource Indicator (URI) compliant identifier in which name segments carry a label. Network protocols such as CCN can use labeled content information by applying specific labels to each name segment of a URI. In a hierarchically structured name, a labeled content name assigns a semantic type or label to each segment. For example, a type of name segment can include a name segment, which is a generic name segment that includes arbitrary octets, which allows a CCN to use a binary on-the-wire representation for messages.

The methods disclosed herein are not limited to CCN networks and are applicable to other architectures as well. A description of a CCN architecture is described in U.S. patent application Ser. No. 12/338,175, which is herein incorporated by reference.

Exemplary Network and Communication

FIG. 1A illustrates an exemplary content centric network (CCN) that facilitates updating a transport stack based on quiescing, in accordance with an embodiment of the present invention. A network 100, which can be a CCN, can include a client device 116, a content-producing device 118, and a router or other forwarding device at nodes 102, 104, 106, 108, 110, 112, and 114. A node can be a computer system, an endpoint representing users, and/or a device that can generate an interest or originate a content object. Suppose that nodes 102 and 104 have transport stacks 130 and 170, respectively. In a CCN node, the transport stack is often configured based on instructions from an administrator agent. Transport stacks 130 and 170 are usually modified by explicit administrative commands at runtime.

To update stack 130, node 102 typically quiesces stack 130 so that the operations associated with the update can be executed without interruption before stack 130 is allowed to continue regular operations. Similarly, node 104 typically quiesces stack 170 to update stack 170. Node 102 can quiesce the entire stack (e.g., each component of stack 130) and all message transmissions, or only specific messages or messages matching a specific set of rules.

In some embodiments, node 102 passes a pause message down stack 130. This pause message can be an interest for a name that each stack component recognizes and processes. Upon receiving the pause message, a respective component of stack 130 flushes its buffer and pauses its operations. When node 102 completes updating one or more components of stack 130, node 102 sends a resume message via stack 130. This resume message can be a content object associated with the name. Upon receiving the resume message, a respective component of stack 130 resumes its operations. In this way, the operations required for updating stack 130 can be executed without interruption before stack 130 is allowed to continue regular operations.

FIG. 1B illustrates an exemplary transport stack of a CCN node, in accordance with an embodiment of the present invention. In this example, node 102 can include an administrator agent 152, which communicates with transport stack 130 via a portal 120. Transport stack 130 can include stack components 134.1-134.n. Node 102 can also include forwarder 140 (e.g., a network interface card, or a router in a local area network), which can transfer packets between stack 130 (and individual stack components) and network 100. Similarly, node 104 can include administrator agent 154, which communicates with transport stack 170 via portal 160. Transport stack 170 can include stack components 174.1-174.p. Node 104 can also include a forwarder 180, which can transfer packets between stack 170 (and individual stack components) and network 100. Forwarders 140 and 180 can also facilitate the transfer of packets directly between individual stack components 134.1-134.n and 174.1-174.p, respectively.

Administrator agent 152 can issue a pause message for stack 130. In some embodiments, the head of stack 130 (e.g., stack component 134.1, which is typically an application program interface (API) adapter), can also issue the pause message. Upon receiving the message, each component flushes its current buffer, quiesces local operations, and forwards the message via stack 130. In some embodiments, the final component of stack 130, which is stack component 134.n, can send an acknowledgment up stack 130. Agent 152 can specify a lifetime (e.g., a timeout period) for the pause message for a respective stack component. If a timer representing the lifetime expires before receiving the acknowledgment, the stack component detects a timeout event, determines that the pause operation has failed, and resumes regular operations. Since the acknowledgment is not passed up stack 130, the timeout event is propagated via stack 130 to agent 152, thereby resuming operations of a respective stack component.

On the other hand, if the stack component receives the acknowledgment within the lifetime, the stack component passes the acknowledgment up stack 130. Agent 152 receives the acknowledgment and determines that stack 130 has been quiesced. Agent 152 then updates one or more components of stack 130. When the update operation is completed, agent 152 (or the head of stack 130) sends a resume message down stack 130. Upon receiving the message, a respective component restarts regular operations. In some embodiments, stack component 134.n can send a pause content object associated with the name up stack 130. When a stack component receives the content object, the component resumes its regular operation and passes the content object up stack 130.

In some embodiments, the pause message is applied only to a specific namespace. Any interest or content object with a name in that namespace is flushed at stack 130 and is precluded from being processed at stack 130. However, any interest or content object with a name outside of that namespace is processed based on regular operations of stack 130. In some embodiments, a stack component can reject the pause message and respond with a pause failure message with an optional reason for the rejection. Reasons for rejection include, but are not limited to, a stack component detecting a timeout event, processing a back flow, or identifying inter-dependent messages.

Exemplary Quiescing of a Transport Stack

FIG. 2A illustrates an exemplary communication that initiates quiescing of a transport stack, in accordance with an embodiment of the present invention. In this example, an administrator agent 210 uses API 212 to communicate with a portal 220, which interacts with a transport stack 230. In FIG. 2A, transport stack 230 includes stack components 232-238. An API adapter 232 can communicate with one or more transport components of transport stack 230. A flow controller 234 can shape and manage traffic, pipeline and transmit interests, and order content objects. A verifier/signer 236 can encode and sign content objects destined for a network element, decode and verify content objects destined for an associated application, encode interests destined for a network element, and decode interests destined for an associated application.

A forwarder adapter 238, which is typically the final component of stack 230, can communicate with a forwarder 240. Forwarder 240 can communicate with other forwarders over a CCN. Other stack components (not shown) can include functionality related to security (e.g., encryption, decryption, authentication, data signing, signature verification, trust assessment, and filtering), data-processing (e.g., encoding, decoding, encapsulating, decapsulating, transcoding, compression, extraction, and decompression), and storage (e.g., data storage, data retrieval from storage, deduplication, segmentation, and versioning).

In some embodiments, administrator agent 210 can update a component of stack 230 (e.g., add a new component or update an existing component). To ensure consistency, agent 210 sends a pause message 252 down stack 230. A respective component of stack 230 receives pause message 252 and flushes its local buffer, if any. Some components may just receive and process a message (e.g., an interest or a content object), while other components can buffer messages. Suppose that flow controller 234 stores messages in a buffer 235. Upon receiving pause message 252, flow controller 234 flushes buffer 235 (e.g., discards the messages stored in buffer 235). Upon receiving pause message 252, a respective component stops further processing of messages, sets the local state as “quiesced,” and passes pause message 252 down stack 230 to the next component.

When the pause message reaches the final component of stack 230, which is forwarder adapter 238, forwarder adapter 238 also flushes the local buffer, if any, and sets the local state as quiesced. Forwarder adapter 238 then generates a pause acknowledgment message 254 and sends acknowledgment message 254 up stack 230. A respective component receives acknowledgment message 254 without a timer expiring for pause message 252, and the component passes acknowledgment message 254 up stack 230. Agent 210 receives acknowledgment message 254 and determines that stack 230 has been successfully quiesced.

FIG. 2B illustrates an exemplary communication that updates a transport stack, in accordance with an embodiment of the present invention. In this example, upon receiving an acknowledgment message, agent 210 determines that stack 230 has been successfully quiesced. Agent 210 then passes an update message comprising the updates for a stack component. Suppose that agent 210 is updating the verification protocol of verifier/signer 236. Agent 210 then generates an update message 262 comprising the updated verification protocol and passes update message 262 down stack 230. Verifier/signer 236 receives update message 262 from upper components of stack 230, obtains the updated verification protocol from update message 262, and updates verifier/signer 236.

In some embodiments, verifier/signer 236 generates an update acknowledgment message 264 and sends acknowledgment message 264 up stack 230. A respective component passes acknowledgment message 264 up stack 230. Agent 210 receives acknowledgment message 264 and determines that verifier/signer 236 has been successfully updated. Agent 210 then generates a resume message 266 and passes resume message 266 down stack 230, thereby instructing a respective component to resume operation. Upon receiving resume message 266, a respective component resumes processing of messages, sets the local state as “active,” and passes resume message 266 down stack 230 to the next component. When resume message 266 reaches forwarder adapter 238, forwarder adapter 238 resumes processing of messages and sets the local state as “active.”

FIG. 2C illustrates an exemplary communication that updates a transport stack based on control sharing, in accordance with an embodiment of the present invention. In this example, a pause interest message 272 is sent down transport stack 230 with a pre-agreed-upon name that each component is capable of recognizing and processing. Agent 210 (or head of stack 230, which is API adapter 232) can generate and send pause interest message 272. Upon receiving pause interest message 272, a respective component of stack 230 flushes its current buffer, forwards pause interest message 272 via stack 230, quiesces the local component, and waits for a content object return matching pause interest message 272 before processing or forwarding any other messages.

Typically, forwarder adapter 238 is the final component to receive pause interest message 272. When pause interest message 272 reaches forwarder adapter 238, forwarder adapter 238 quiesces the local component and determines that a respective component between forwarder adapter 238 and API adapter 232 has been quiesced. Forwarder adapter 238 then passes control to agent 210. In some embodiments, forwarder adapter 238 sends a control message 274 (e.g., an inter-process message) to agent 210 via stack 230 to pass the control.

Suppose that agent 210 is updating the verification protocol of verifier/signer 236. Agent 210 then generates an update message 276 comprising the updated verification protocol and passes update message 276 down stack 230. Verifier/signer 236 receives update message 276 from the upper components of stack 230, obtains the updated verification protocol from update message 276, and updates verifier/signer 236.

When the updating process is completed, agent 210 passes the control back to forwarder adapter 238 (e.g., using a control message, which is not shown in FIG. 2C). Forwarder adapter 238 constructs a matching pause content object 278 and sends pause content object 278 back up transport stack 230. Upon receiving pause content object 278, a respective component restarts regular operation and sends pause content object 278 onward via stack 230. Once pause content object 278 reaches agent 210 (or API adapter 232), transport stack 230 resumes its regular operations.

FIG. 2D illustrates an exemplary communication of an unsuccessful quiescing of a transport stack, in accordance with an embodiment of the present invention. In some embodiments, a stack component can reject a pause message and respond with a pause failure message with an optional reason for the rejection. Reasons for rejection include, but are not limited to, a stack component detecting a timeout event, processing a back flow, or identifying inter-dependent messages. Suppose that flow controller 234 fails to process pause message 252 (e.g., being unable to flush buffer 235 due to inter-dependencies). As a result, flow controller 234 rejects pause message 252, generates a pause failure message 280 comprising the reason for the rejection, and passes pause failure message 280 upward via stack 230.

When pause failure message 280 reaches an upstream stack component, such as API adapter 232, the stack component determines that pause message 252 has been rejected, restarts regular operation, and sends pause failure message 280 onward via stack 230. Upon receiving pause failure message 280, agent 210 determines that pause message 252 has been rejected. Agent 210 can wait for a period of time (e.g., a random back-off or a pre-determined time) and re-issue pause message 252.

Operations

FIG. 3 presents a flow chart 300 illustrating a method for quiescing and updating a transport stack, in accordance with an embodiment of the present invention. During operation, an administrator agent (or the head of the stack) sends a pause message down the transport stack (operation 302) and initiates a timer for a pause acknowledgment message (operation 304). The agent checks whether the agent has detected a timeout or a pause failure message (operation 306). If the agent detects a timeout or a pause failure message, the agent waits for a period of time (e.g., based on random back-off or a pre-determined configuration) (operation 308) and sends another pause message down the transport stack (operation 302). If the agent doesn't detect a timeout or a pause failure message, the agent receives a pause acknowledgment message (operation 310).

The agent then determines that the stack has been quiesced. The agent sends an update message to a respective updating component (i.e., the component that the agent is updating) (operation 312). The update message comprises the update for the updating component. The agent then checks whether the update has been successful (operation 314). In some embodiments, the agent determines that the update has been successful upon receiving an acknowledgment for the update message. If the agent determines that the update has not been successful, the agent waits for a period of time (operation 308) and sends another pause message down the transport stack (operation 302). If the agent determines that the update has been successful, the agent sends a resume message down the transport stack (operation 316).

FIG. 4A presents a flow chart 400 illustrating a method for quiescing and updating a module of a transport stack, in accordance with an embodiment of the present invention. During operation, a stack component, which is not the final component of the stack, receives a pause message (operation 402) and checks whether the pause message triggers a rejection (operation 404). Reasons for rejection include, but are not limited to, processing a back flow or identifying inter-dependent messages. If the pause message does not trigger a rejection, the component passes the pause message to the next component down the transport stack (operation 406) and flushes residual local data, if any (operation 408).

The component then checks whether the component has received a pause acknowledgment message (operation 410). If the component has not received a pause acknowledgment message, the component checks for a timeout event (operation 412). If the component detects a timeout event or the pause message triggers a rejection (operation 404), the component generates a pause failure message and passes the pause failure message to the next component up the transport stack (operation 414). On the other hand, if the component has not received a pause acknowledgment message (operation 410) and doesn't detect a timeout event (operation 412), the component continues to flush residual local data, if any (operation 408).

If the component receives a pause acknowledgment message (operation 410), the component sets the local state as “quiesced” (operation 416) and passes the pause acknowledgment message to the next component up the transport stack (operation 418). If the component is the updating component (denoted with dashed line), the component receives an update message and implements updates to the local component (operation 420). In some embodiments, the component can send an acknowledgment up the stack upon successfully updating the local component. The component then receives a resume message (operation 422) and sets the local state as “active” (operation 426).

FIG. 4B presents a flow chart 450 illustrating a method for quiescing and updating a final stack component of a transport stack, in accordance with an embodiment of the present invention. During operation, the component receives a pause message (operation 452) and checks whether the pause message triggers a rejection (operation 454). Reasons for rejection include, but are not limited to, processing a back flow or identifying inter-dependent messages. If the pause message triggers a rejection, the component generates a pause failure message and passes the pause failure message to the next component up the transport stack (operation 468).

If the pause message does not trigger a rejection, the component flushes residual local data, if any (operation 456) and sets the local state as “quiesced” (operation 458). The component then passes the pause acknowledgment message to the next component up the transport stack (operation 460). If the component is the updating component (denoted with dashed line), the component receives an update message and implements updates to the local component (operation 462). In some embodiments, the component can send an acknowledgment up the stack upon successfully updating the local component. The component then receives a resume message (operation 464) and sets the local state as “active” (operation 466).

Exemplary Apparatus and Computer System

FIG. 5 illustrates an exemplary apparatus that facilitates updating a transport stack based on quiescing, in accordance with an embodiment of the present invention. Apparatus 500 can comprise a plurality of modules, which may communicate with one another via a wired or wireless communication channel. Apparatus 500 may be realized using one or more integrated circuits, and may include fewer or more modules than those shown in FIG. 5. Further, apparatus 500 may be integrated in a computer system, or realized as a separate device that is capable of communicating with other computer systems and/or devices. Specifically, apparatus 500 can comprise a communication module 502, a quiescing module 504, an updating module 506, and a message delivering module 508.

In some embodiments, communication module 502 can send and/or receive data packets to/from other network nodes across a computer network, such as a content centric network. Quiescing module 504 can set a state of a stack component as “quiesced” or “active” based on a pause message and a resume message, respectively. Quiescing module 504 can also generate an acknowledgment for the pause message. In some embodiments, quiescing module 504 can flush a local buffer of the component. Updating module 506 can update a component based on an update message. Message delivering module 508 can deliver a message to a component via a transport stack (e.g., can send a message up or down the stack).

FIG. 6 illustrates an exemplary computer system 602 that facilitates command messages to be communicated in a layer-agnostic manner, in accordance with an embodiment of the present invention. Computer system 602 includes a processor 604, a memory 606, and a storage device 608. Memory 606 can include a volatile memory (e.g., RAM) that serves as a managed memory, and can be used to store one or more memory pools. Furthermore, computer system 602 can be coupled to a display device 610, a keyboard 612, and a pointing device 614. Storage device 608 can store an operating system 616, a stack updating system 618, and data 632.

Stack updating system 618 can include instructions, which when executed by computer system 602 or processor 604, can cause computer system 602 or processor 604 to perform methods and/or processes described in this disclosure. Specifically, stack updating system 618 may include instructions for sending and/or receiving data packets to/from other network nodes across a computer network, such as a content centric network (communication module 620). Stack updating system 618 can also include instructions for setting a state of a stack component as “quiesced” or “active” based on a pause message and a resume message, respectively (quiescing module 622). Stack updating system 618 can also include instructions for generating an acknowledgment for the pause message and flushing a local buffer of the component (quiescing module 622).

Furthermore, stack updating system 618 can include instructions for updating a component based on an update message (updating module 624). Stack updating system 618 can include instructions for delivering a message to a component via a transport stack (e.g., can send a message up or down the stack) (message delivering module 626). Storage device 608 can store an administrator agent 630, which can generate and send a pause message, a resume message, and an update message for a transport stack.

Data 632 can include any data that is required as input or that is generated as output by the methods and/or processes described in this disclosure. Specifically, data 632 can include buffered messages by a respective component. Data 632 can also include a forwarding table of computer system 602.

The data structures and code described in this detailed description are typically stored on a computer-readable storage medium, which may be any device or medium that can store code and/or data for use by a computer system. The computer-readable storage medium includes, but is not limited to, volatile memory, non-volatile memory, magnetic and optical storage devices such as disk drives, magnetic tape, CDs (compact discs), DVDs (digital versatile discs or digital video discs), or other media capable of storing computer-readable media now known or later developed.

The methods and processes described in the detailed description section can be embodied as code and/or data, which can be stored in a computer-readable storage medium as described above. When a computer system reads and executes the code and/or data stored on the computer-readable storage medium, the computer system performs the methods and processes embodied as data structures and code and stored within the computer-readable storage medium.

Furthermore, the methods and processes described above can be included in hardware modules. For example, the hardware modules can include, but are not limited to, application-specific integrated circuit (ASIC) chips, field-programmable gate arrays (FPGAs), and other programmable-logic devices now known or later developed. When the hardware modules are activated, the hardware modules perform the methods and processes included within the hardware modules.

The foregoing descriptions of embodiments of the present invention have been presented for purposes of illustration and description only. They are not intended to be exhaustive or to limit the present invention to the forms disclosed. Accordingly, many modifications and variations will be apparent to practitioners skilled in the art. Additionally, the above disclosure is not intended to limit the present invention. The scope of the present invention is defined by the appended claims.

Claims

1. A method comprising: at a content centric network node including a transport stack having a plurality of components: sending a pause message down the transport stack while the plurality of components are processing interests and/or content objects, wherein the pause message precludes one or more components of the plurality of components from processing the interests and/or the content objects;after sending the pause message, sending an update message down the transport stack, wherein the update message provides an update for the transport stack while the one or more components are precluded from processing the interests and/or the content objects; andafter sending the update message, sending a resume message down the transport stack, wherein the resume message causes the one or more components to resume processing the interests and/or the content objects in accordance with the update.

2. The method of claim 1, wherein the update message adds a new component to the transport stack.

3. The method of claim 1, wherein the pause message precludes the one or more components from processing the interests and/or the content objects in a specified namespace.

4. The method of claim 1, further comprising: at the content centric network node: sending an acknowledgment message up the transport stack, wherein the acknowledgment message indicates that the pause message has been successfully processed by the one or more components.

5. The method of claim 1, further comprising: at the content centric network node: sending a pause failure message up the transport stack, wherein the pause failure message indicates that the pause message has not been successfully processed by the one or more components.

6. The method of claim 5, further comprising: at the content centric network node: after a period of time, resending the pause message down the transport stack.

7. The method of claim 1, wherein sending the pause message, update message, and resume message includes sending the pause message, update message, and resume message using an administrator agent.

8. The method of claim 1, wherein sending the pause message includes sending the pause message in response to determining that the transport stack is to be updated.

9. The method of claim 1, wherein the pause message causes the one or more components to enter a quiesced state.

10. The method of claim 1, wherein the pause message includes a lifetime upon expiry of which the one or more components resume processing the interests and/or the content objects.

11. An apparatus comprising: a memory configured to store instructions for updating a transport stack having a plurality of components; anda processor in communication with the memory, wherein the processor is configured to: send a pause message down the transport stack while the plurality of components are processing interests and/or content objects, wherein the pause message precludes one or more components of the plurality of components from processing the interests and/or the content objects;after sending the pause message, send an update message down the transport stack, wherein the update message provides an update for the transport stack while the one or more components are precluded from processing the interests and/or the content objects; andafter sending the update message, send a resume message down the transport stack, wherein the resume message causes the one or more components to resume processing the interests and/or the content objects in accordance with the update.

12. The apparatus of claim 11, wherein the update message adds a new component to the transport stack.

13. The apparatus of claim 11, wherein the pause message precludes the one or more components from processing the interests and/or the content objects in a specified namespace.

14. The apparatus of claim 11, wherein the processor is further configured to: send an acknowledgment message up the transport stack, wherein the acknowledgment message indicates that the pause message has been successfully processed by the one or more components.

15. The apparatus of claim 11, wherein the processor is further configured to: send a pause failure message up the transport stack, wherein the pause failure message indicates that the pause message has not been successfully processed by the one or more components.

16. One or more non-transitory computer-readable storage media storing instructions that, when executed by a processor of a content centric network node including a transport stack having a plurality of components, cause the processor to: send a pause message down the transport stack while the plurality of components are processing interests and/or content objects, wherein the pause message precludes one or more components of the plurality of components from processing the interests and/or the content objects;after sending the pause message, send an update message down the transport stack, wherein the update message provides an update for the transport stack while the one or more components are precluded from processing the interests and/or the content objects; andafter sending the update message, send a resume message down the transport stack, wherein the resume message causes the one or more components to resume processing the interests and/or the content objects in accordance with the update.

17. The one or more non-transitory computer-readable storage media of claim 16, wherein the update message adds a new component to the transport stack.

18. The one or more non-transitory computer-readable storage media of claim 16, wherein the pause message precludes the one or more components from processing the interests and/or the content objects in a specified namespace.

19. The one or more non-transitory computer-readable storage media of claim 16, wherein the instructions further cause the processor to: send an acknowledgment message up the transport stack, wherein the acknowledgment message indicates that the pause message has been successfully processed by the one or more components.

20. The one or more non-transitory computer-readable storage media of claim 16, wherein the instructions further cause the processor to: send a pause failure message up the transport stack, wherein the pause failure message indicates that the pause message has not been successfully processed by the one or more components.