Flow control with network named fragments

Abstract

One embodiment provides a system that facilitates efficient and secure flow control based on a fragmentation protocol. During operation, the system receives, by an intermediate node, a first fragment which is a fragment of a content object that is fragmented into a plurality of fragments, wherein the plurality of fragments includes at least one named fragment, which indicates a name associated with the content object, the name being a hierarchically structured variable-length identifier that comprises contiguous name components ordered from a most general level to a most specific level. The intermediate node detects a congestion, and sets an indicator for congestion notification in the received fragment. The intermediate node forwards the received fragment, and drops a second fragment received after the forwarded fragment.

Description

RELATED APPLICATION

The subject matter of this application is related to the subject matter in the following applications:

• • U.S. patent application Ser. No. 13/847,814, entitled “ORDERED-ELEMENT NAMING FOR NAME-BASED PACKET FORWARDING,” by inventor Ignacio Solis, filed 20 Mar. 2013 (hereinafter “U.S. patent application Ser. No. 13/847,814”);
  • U.S. patent application Ser. No. 12/338,175, entitled “CONTROLLING THE SPREAD OF INTERESTS AND CONTENT IN A CONTENT CENTRIC NETWORK,” by inventors Van L. Jacobson and Diana K. Smetters, filed 18 Dec. 2008 (hereinafter “U.S. patent application Ser. No. 12/338,175”);
  • U.S. Pat. No. 8,386,622, entitled “METHOD AND APPARATUS FOR FACILITATING COMMUNICATION IN A CONTENT CENTRIC NETWORK,” by inventor Van Jacobson, filed 11 Dec. 2008 (hereinafter “U.S. Pat. No. 8,386,622”);
  • U.S. Pat. No. 8,204,060, entitled “METHOD AND SYSTEM FOR FACILITATING FORWARDING A PACKET IN A CONTENT-CENTRIC NETWORK,” by inventor Van L. Jacobson and James D. Thornton, filed 17 Dec. 2009 (hereinafter “U.S. Pat. No. 8,204,060”);
  • U.S. patent application Ser. No. 14/065,691, entitled “SYSTEM AND METHOD FOR HASH-BASED FORWARDING OF PACKETS WITH HIERARCHICALLY STRUCTURED VARIABLE-LENGTH IDENTIFIERS,” by inventors Marc E. Mosko and Michael F. Plass, filed 29 Oct. 2013 (hereinafter “U.S. patent application Ser. No. 14/065,691”); and
  • U.S. patent application Ser. No. 14/851,894, entitled “NETWORK NAMED FRAGMENTS IN A CONTENT CENTRIC NETWORK,” by inventors Marc E. Mosko and Christopher A. Wood, filed 11 Sep. 2015 (hereinafter “U.S. patent application Ser. No. 14/851,894”);the disclosures of which are herein incorporated by reference in their entirety.

BACKGROUND

Field

This disclosure is generally related to distribution of digital content. More specifically, this disclosure is related to a system and method for flow control based on a secure fragmentation protocol in a content centric network.

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. Generally, interests and content objects travel through a number of links before they can reach their destination. Each link can have its own maximum transmission unit (MTU), where the differing MTU limits impose different fragmentation requirements.

Fragmentation protocols related to CCN continue to evolve. One secure fragmentation protocol for CCN is known as Fragmentation with Integrity Guarantees and Optional Authentication (FIGOA), described in Ghali et al., “Secure Fragmentation for Content-Centric Networks,” Computing Research Repository, 1405.2861 (2014), which disclosure is herein incorporated by reference in its entirety. The FIGOA protocol operates by creating fragments that are chained via hash computation, transmitting fragments with a name that match an interest for the name, and including a signature in the final fragment. However, under the FIGOA protocol, a content producer signs the final fragment, which creates a delayed verification of the signature by a requesting entity until all fragments have been received. This delayed verification may decrease the overall throughput of data and may also result in the injection of malicious packets, which can create inefficiencies and introduce security issues in the network. In addition, the FIGOA protocol does not provide a method to selectively request re-transmission of a specific fragment or subsequence of fragments. When a fragment is dropped, an intermediate node has no way to mark the point at which it drops a fragment stream. A requesting entity re-requests the entire data stream, resulting in further inefficiencies in the network.

SUMMARY

One embodiment provides a system that facilitates efficient and secure flow control based on a fragmentation protocol. During operation, the system receives, by an intermediate node, a first fragment which is a fragment of a content object that is fragmented into a plurality of fragments, wherein the plurality of fragments includes at least one named fragment, which indicates a name associated with the content object, the name being a hierarchically structured variable-length identifier that comprises contiguous name components ordered from a most general level to a most specific level. The intermediate node detects a congestion and sets an indicator for congestion notification in the received fragment. The intermediate node forwards the received fragment and drops a second fragment received after the forwarded fragment.

In a variation on this embodiment, in response to detecting the congestion, the intermediate node determines that the received fragment indicates an optimal position to restart a flow of the fragment, wherein the indicator for congestion notification is an indicator for early congestion notification.

In a further variation, the intermediate node determines that the received fragment indicates an optimal position to restart a flow of the fragment. The intermediate node also determines that the received fragment is a previous fragment that directly precedes a named fragment.

In a further variation, the intermediate node determines that the received fragment does not indicate an optimal position to restart a flow of the fragment, wherein the indicator for congestion notification is an indicator for early discarding.

In a further variation, the intermediate node receives a third fragment with the indicator for early congestion notification. The intermediate node identifies an alternate path not associated with the congestion, and generates an interest for a remainder of the plurality of fragments starting from a next fragment that directly follows the third fragment. The intermediate node resets the indicator for early congestion notification, and forwards the interest based on an interface associated with the alternate path.

In a further variation, the intermediate node computes an intermediate state for the next fragment based on a hash function performed on an intermediate state from the received fragment, wherein the received fragment indicates an intermediate state which is based on a hash function performed on an intermediate state from a previous fragment and data included in the received fragment. The intermediate node determines a payload size for the remainder of the plurality of fragments starting from the next fragment, and includes in a name for the interest the computed intermediate state and the determined payload size.

In a further variation, the intermediate node receives a third fragment with the indicator for early discarding. The intermediate node identifies an alternate path not associated with the congestion, and further identifies a previously received named fragment that is closest in order to the received fragment. The intermediate node generates an interest for a remainder of the plurality of fragments starting from the previously received named fragment. The intermediate node resets the indicator for early discarding and forwards the interest based on an interface associated with the alternate path.

In a further variation, the intermediate node determines a payload size for the remainder of the plurality of fragments starting from the previously received named fragment. The intermediate node includes in a name for the interest message an intermediate state for the previously received named fragment and the determined payload size, wherein the intermediate state for the previously received named fragment is based on a hash function performed on an intermediate state from a previous fragment that directly precedes the previously named fragment and data included in the previously received named fragment.

In a further variation, a name for an interest includes a digest for the content object, and a number indicating a byte offset that corresponds to a starting byte for the received fragment or a previously received named fragment closest in order to the received fragment.

In another embodiment, the system receives, by a content requesting device, a first fragment which is a fragment of a content object message that is fragmented into a plurality of fragments, wherein the plurality of fragments includes at least one named fragment, which indicates a name associated with the content object, the name being a hierarchically structured variable-length identifier that comprises contiguous name components ordered from a most general level to a most specific level. The content requesting device determines that an indicator for congestion notification in the received fragment is set, and generates an interest for a remainder of the plurality of fragments starting from a named fragment.

In a variation on this embodiment, the indicator for congestion notification is an indicator for early congestion notification, and the named fragment is a next fragment that directly follows the received fragment. The content requesting device computes an intermediate state for the next fragment based on a hash function performed on an intermediate state from the received fragment, wherein the received fragment indicates an intermediate state which is based on a hash function performed on an intermediate state from a previous fragment and data included in the received fragment. The content requesting device determines a payload size for the remainder of the plurality of fragments starting from the next fragment, and includes in a name for the interest the computed intermediate state and the determined payload size.

In a further variation, the content requesting device updates a corresponding entry in a pending interest table based on a payload offset of the received fragment, wherein the payload offset is a number indicating a byte offset that corresponds to a starting byte for the received fragment.

In a further variation, the indicator for congestion notification is an indicator for early discarding, and the named fragment is a previously received named fragment that is closest in order to the received fragment. The content requesting device determines a payload size for the remainder of the plurality of fragments starting from the previously received named fragment, and includes in a name for the interest an intermediate state for the previously received named fragment and the determined payload size, wherein the intermediate state for the previously received named fragment is based on a hash function performed on an intermediate state from a previous fragment that directly precedes the previously named fragment and data included in the previously received named fragment.

In a further variation, the content requesting device updates a corresponding entry in a pending interest table based on a payload offset of the previously received named fragment, wherein the payload offset is a number indicating a byte offset that corresponds to a starting byte for the previously received named fragment.

In a further variation, in response to determining that the indicator for congestion notification in the received fragment is not set, the content requesting device processes the received fragment for reassembly.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 illustrates an exemplary network facilitating flow control based on a secure fragmentation protocol, in accordance with an embodiment of the present invention.

FIG. 2A illustrates an exemplary format for a first fragment of a content object message, in accordance with an embodiment of the present invention.

FIG. 2B illustrates an exemplary format for a named fragment of a content object message, in accordance with an embodiment of the present invention.

FIG. 3A illustrates a fragmented content object, including an unnamed fragment that is a previous fragment that directly precedes a named fragment, in accordance with an embodiment of the present invention.

FIG. 3B illustrates a fragmented content object that corresponds to the fragmented content object in FIG. 3A, including an indicator of early congestion notification that is set to an active value, in accordance with an embodiment of the present invention.

FIG. 3C illustrates a fragmented content object, including an unnamed fragment that is not a previous fragment that directly precedes a named fragment, in accordance with an embodiment of the present invention.

FIG. 3D illustrates a fragmented content object that corresponds to the fragmented content object in FIG. 3C, including an indicator of early discarding that is set to an active value, in accordance with an embodiment of the present invention.

FIG. 4 presents a flow chart illustrating a method by an intermediate node for processing a fragment of a content object message when congestion is detected, in accordance with an embodiment of the present invention.

FIG. 5A presents a flow chart illustrating a method by an intermediate node for processing a fragment of a content object message, where the fragment indicates congestion and an alternate non-congested path is identified, in accordance with an embodiment of the present invention.

FIG. 5B presents a flow chart illustrating a method by an intermediate node for processing a fragment of a content object message, where the fragment indicates congestion and an alternate non-congested path is identified, in accordance with an embodiment of the present invention.

FIG. 5C presents a flow chart illustrating a method by an intermediate node for processing a fragment of a content object message, where the fragment indicates congestion and an alternate non-congested path is identified, in accordance with an embodiment of the present invention.

FIG. 6A presents a flow chart illustrating a method by a content requesting device for processing a fragment of a content object message, in accordance with an embodiment of the present invention.

FIG. 6B presents a flow chart illustrating a method by a content requesting device for processing a fragment of a content object message, in accordance with an embodiment of the present invention.

FIG. 7A illustrates an exemplary apparatus that facilitates flow control based on a secure fragmentation protocol, in accordance with an embodiment of the present invention.

FIG. 7B illustrates an exemplary apparatus that facilitates flow control based on a secure fragmentation protocol, in accordance with an embodiment of the present invention.

FIG. 8A illustrates an exemplary computer system that facilitates flow control based on a secure fragmentation protocol, in accordance with an embodiment of the present invention.

FIG. 8B illustrates an exemplary computer system that facilitates flow control based on a secure fragmentation protocol, 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 provide a system that solves the problem of re-requesting an entire fragment stream when only one fragment is dropped by allowing an intermediate node to mark the dropping point and by providing a secure fragmentation protocol where one or more fragments carry a network addressable name (i.e., a named fragment). An intermediate node may detect congestion and drop a fragment at any point. The marked dropping point and the unique name allow a content requestor to re-request only a subsequence of the fragment stream, rather than the entire fragment stream. As a result, the flow of the congested dropped stream is more efficiently resumed. The intermediate node can be a part of a content centric network (CCN), where communication is based on a secure fragmentation protocol known as the Network Named Fragments protocol.

The intermediate node can indicate a detected congestion by marking a flag carried in a fragment. The flag indicates the point at which the intermediate node drops the fragment stream. This allows the requestor to generate an interest for only the remainder of the fragments. For example, the intermediate node can set an early congestion notification (ECN) flag. The ECN flag indicates that the next fragment is a named fragment and that the requestor should request the stream starting from that next named fragment onwards. In another example, the intermediate node can set an early discarding (ED) flag. The ED flag indicates that the next fragment is not a named fragment and that the requestor should request the stream starting from a previously received named fragment that is closest to the received fragment.

The NNF protocol provides a naming convention that allows a requestor to request the remainder of a fragment stream, i.e., a subsequence of fragments. Each fragment is uniquely identified based on certain state characteristics, such as overall digest, payload offset, payload size, and intermediate state. These state characteristics can be encoded into the name of the fragment to allow selective retransmission of a subsequence of fragments. A requestor can compute the intermediate state of the next fragment because the fragments are hash chained, i.e., each fragment contains an intermediate state which is based on a hash of the data of the respective fragment and the intermediate state from the previous fragment. The already received fragments include sufficient information to compute a remaining payload size, such as the overall length, remaining length, and payload offset. The requestor or an intermediate node can encode this computed information in an interest name to selectively request a subsequence of fragments, thus obviating the need to re-request the entire stream.

In addition, upon receiving a fragment that indicates congestion, an upstream intermediate node can identify an alternate non-congested path and proactively begin requesting the remainder of the fragment stream on behalf of the content requestor. Such an upstream intermediate node also clears the appropriate flag in the received fragment.

The following terms describe elements of a 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 parc, 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 between different versions of the content item, such as a collaborative document.

In some embodiments, the name can include a non-hierarchical 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. 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 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.

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.

Exemplary Network and Communication

FIG. 1 illustrates an exemplary network 100 facilitating flow control based on a secure fragmentation protocol, in accordance with an embodiment of the present invention. Network 100 can be a content centric network (CCN) and can include a client device or content requesting 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 CCN router can be a CCN forwarding device residing on top of an IP router. In other words, CCN can be implemented as an overlay on top of IP. Other CCN overlay architecture is also possible. A node can be a computer system, an end-point representing users, and/or a device that can generate interests or originate content.

A requesting entity (such as device 116) can generate an interest in a piece of content. Intermediate nodes (such as CCN routers 102, 104, 112, and 114) can receive and forward the interest. A content producer (such as device or content producer 118) can satisfy the requested interest. Producer 118 can fragment a responsive content object 130 into x number of fragments, e.g., fragments 130.1-130.x. Producer 118 can sign the first fragment and create a trusted hash chain of the remaining fragments. Producer 118 can immediately begin forwarding fragments 130.1-130.x, which fragments will travel the reverse path as the interest (e.g., to nodes 114, 112, 104, and 102) and reach device 116. An exemplary content object fragmented by a producer is described below in relation to FIGS. 3A and 3C.

During the forwarding of the fragment stream, an intermediate router (such as node 104) can receive a fragment (e.g., fragment 130.3) and detect congestion. Intermediate node 104 can set an indicator of congestion notification (CN) 140 in fragment 130.3, and drop any fragments received after fragment 130.3, as described below in relation to FIG. 4. Device 116 can receive fragment 130.3 and, based on CN indicator 140, determine that the fragment stream has been dropped by an intermediate node. Using the naming convention of the NNF protocol, device 116 can generate an interest for the remainder of the fragment stream that comprises content object 130. This obviates the need for the requesting entity to re-request the entire fragment stream. Instead, the requesting entity can re-request only the specific portion of the stream based on CN indicator 140. In some embodiments, the CN indicator can be one of two flags: an early congestion notification (ECN) flag or an early discarding (ED) flag, as described below in relation to FIGS. 6A and 6B. The flags indicate the point at which the requesting entity should begin re-requesting the fragment stream. Device 116 can receive content object fragments 130.1-130.x and reassemble content object 130.

Exemplary Format of CCN Content Object Message Fragments

FIG. 2A illustrates an exemplary format for a first fragment 210 of a content object message, in accordance with an embodiment of the present invention. First fragment 210 can include the following fields: a name 211 that can indicate the name of the content object and also contain encoded information to specifically identify the fragment; an overall digest 212 that is the digest of the entire fragmented payload for the CCN content object message; a payload offset 213 that is the byte offset where this fragment begins; an intermediate state 214 that is a value calculated based on the initialization vector and the payload or data associated with this fragment (e.g., data 219); a next fragment named (NFN) flag 215 that indicates whether the next fragment that immediately follows this fragment is a fragment that includes a name (e.g., a named fragment); an early congestion notification (ECN) flag 216 that indicates whether an intermediate node has detected congestion and dropped the stream immediately after this fragment, where the next fragment is a named fragment; an early discarding (ED) flag 217 that indicates whether an intermediate node has detected congestion and dropped the stream immediate after this fragment, where the next fragment is not a named fragment; an overall length 218 that is the total length of the entire fragmented payload; a data 219 that is the payload of this fragment and one of the input fields for the hash function to calculate intermediate state 214; and a signature 220 that is the signature of the producer of the content object message. First fragment 210 cannot be re-fragmented by an intermediate node. Thus, first fragment 210 may contain no payload (e.g., no data 219) or a payload with a size smaller than a known MTU of the network.

In some embodiments, NFN flag 215, ECN flag 216, and ED flag 217 are control flags or bits that comprise CN indicator 140 depicted in FIG. 1. These control flags can be carried outside of the fragmented payload so that they do not influence the computation of the hash of the intermediate state. In addition, the control flags do not need to be secured because attacks on these control signals, similar to malicious or accidental drops, result in the content requestor going through its normal timeout and restart procedures that are in place even without the features described herein.

FIG. 2B illustrates an exemplary format for a named fragment 220 of a content object message, in accordance with an embodiment of the present invention. Named fragment 220 is a fragment that is not the first fragment of a stream, and includes a name that indicates the name of the content object and can also contain encoded information to specifically identify the fragment. Named fragment 220 can include similar fields as first fragment 210 of FIG. 2A. For example, named fragment 220 can include the following fields: a name 231; an overall digest 232; a payload offset 233; an intermediate state 234; a next fragment named (NFN) flag 235; an early congestion notification (ECN) flag 236; an early discarding (ED) flag 237; an overall length 238; and a data 239. Intermediate state 234 is calculated based on a hash function performed on the intermediate state of the previous fragment. Overall length 238 is the length of the remaining fragment stream, in contrast with overall length 218 (of first fragment 210 in FIG. 2A) which indicates the overall length of the entire fragmented payload. Overall digests 212 and 222 can be included in first fragment 210 and named fragment 230, respectively, when the hash chain and the final overall digest is known in advance, e.g., when fragmenting a known file. Note that signature 220 is only included in first fragment 210, and not in named fragment 230 (or any other subsequent fragments, named or unnamed).

A subsequent fragment that is neither a first fragment nor a named fragment (e.g., an unnamed fragment) includes similar fields as named fragment 230, but does not include an overall length field, and may not include a name field when CCNx Nameless Objects are supported (as described in U.S. patent application Ser. No. 14/337,026). An unnamed fragment that is a previous fragment that directly precedes a named fragment includes the NFN flag set by the content producer (e.g., set to a value of “1” or another active value). An unnamed fragment that is a previous fragment that does not directly precede a named fragment includes the NFN not set by the content producer (e.g., set to a value of “0” or another inactive value).

FIG. 3A illustrates a fragmented content object 350, including an unnamed fragment 305 that is a previous fragment that directly precedes a named fragment 306, in accordance with an embodiment of the present invention. Content object 350 includes fragments 300-310: a first fragment which is a named fragment 300; named fragments 303, 306, and 309; and unnamed fragments 301, 302, 304, 305, 307, 308, and 310. Named (first) fragment 300 includes similar fields as first fragment 210 of FIG. 2A, and named fragments 303, 306, and 309 include similar fields as named fragment 230 of FIG. 2B. Unnamed fragments 301, 302, 304, 305, 307, 308, and 310 also include similar fields as named fragment 230 of FIG. 2B, with the exception described above (e.g., no name or overall length fields). For example, fragment 305 is an unnamed fragment that directly precedes a named fragment. Thus, the NFN flag for fragment 305 is set to “1” by the content producer, indicating that the next fragment is a named fragment. FIG. 3A depicts the content object message generated by the content producer and as received by an intermediate node.

FIG. 3B illustrates fragmented content object 360 that corresponds to fragmented content object 350 in FIG. 3A, including an indicator of early congestion notification that is set to an active value, in accordance with an embodiment of the present invention. As in FIG. 3A, NFN field 354 of unnamed fragment 305 is set to an active value. An intermediate node can receive fragment 305 and detect congestion. The intermediate node can subsequently set ECN flag 355 to an active value (e.g., to a value of “1”), indicating to a content requestor that it will drop all fragments occurring after the current fragment. The ECN flag (e.g., ECN flag 355) also indicates to the requestor that the next fragment is a named fragment (e.g., named fragment 306), thus providing sufficient information for the requestor to generate an interest for the remainder of the fragments (e.g., fragments 306-310), as described below in relation to FIGS. 6A and 6B.

FIG. 3C illustrates a fragmented content object 380, including an unnamed fragment 307 that is not a previous fragment that directly precedes a named fragment, in accordance with an embodiment of the present invention. Content object 380 has similar fragments and fields as content object 350. Content object 380 also includes unnamed fragment 307, which does not directly precede a named fragment. The NFN flag 374 for fragment 307 is not set to an active value (e.g., is set to a value of “0”), indicating that the next fragment is not a named fragment.

FIG. 3D illustrates a fragmented content object 390 that corresponds to fragmented content object 380 in FIG. 3C, including an indicator of early discarding that is set to an active value, in accordance with an embodiment of the present invention. As in FIG. 3C, NFN field 354 of unnamed fragment 307 is not set to an active value. An intermediate node can receive fragment 307 and detect congestion. The intermediate node can subsequently set ED flag 376 to an active value (e.g., to a value of “1”), indicating to a content requestor that it will drop all fragments occurring after the current fragment. The ED flag (e.g., ED flag 376) also indicates to the requestor that the next fragment is a not a named fragment (e.g., unnamed fragment 308). The ED flag thus provides sufficient information for the requestor to generate an interest for the remainder of the fragments starting from a previously received named fragment that is closest in order to the current fragment (e.g., starting from the closest previously received named fragment 306), as described below in relation to FIGS. 6A and 6B.

Selective Retransmission of a Fragment or a Subsequence of Fragments

Because the NNF protocol uniquely identifies each fragment based on, e.g., {Name, OverallDigest, PayloadOffset, IntermediateState}, certain of these characteristics can be encoded into the name to uniquely address a fragment for selective retransmission. For example, Overall Digest (“OD”), Payload Offset (“PO”), and IntermediateState (“IS”) can be encoded in the name for a fragment:/parc.com/movie.alto.mkv/OD=123abc/PO=4096/IS=653efa  (1)By using this naming convention, a requesting entity (such as a content requesting device or an intermediate node) can selectively request a specific fragment.

In addition, a requesting entity can selectively request a subsequence or chain of fragments by including the name and an additional payload size. For example, consider an interest with the following name:/parc.com/movie.alto.mkv/OD=123abc/PO=4096/IS=653efa/PS=8192  (2)If the size of each individual fragment is 1024 B, interest (2) returns a chain of four fragments starting at byte offset 4096. Re-fragmentation can also occur. For example, consider an interest with the following name:/parc.com/movie.alto.mkv/OD=123abc/PO=4096/IS=653efa/PS=7680  (3)Similar to interest (2), interest (3) returns a chain of four fragments. However, the fourth fragment of the chain is re-fragmented to 512 B.

In some embodiments, the interest can carry a TLV field for how many bytes (or blocks or demarcations) to deliver (e.g., the size of the remainder of the plurality of fragments or a specific subsequence of fragments). An intermediate node can truncate the fragment stream at the point indicated in the interest, which allows a requesting entity to limit the congestion created by any single interest.

Processing and Flow Control by an Intermediate Node

FIG. 4 presents a flow chart 400 illustrating a method by an intermediate node for processing a fragment of a content object message when congestion is detected, in accordance with an embodiment of the present invention. During operation, an intermediate node receives a first packet that corresponds to a fragment of a content object message fragmented into a plurality of fragments (operation 402). The plurality of fragments includes at least one named fragment, which indicates a name associated with the content object message, where the name is a hierarchically structured variable-length identifier that comprises contiguous name components ordered from a most general level to a most specific level. The intermediate node determines whether congestion is detected (decision 404). If not, the intermediate node forwards the received fragment to a next-hop node based on a reverse path of a corresponding interest in the pending interest table (PIT) (operation 412). If the intermediate node does detect congestion, the intermediate node determines whether the received fragment indicates an optimal restart position (operation 406). The indication of an optimal restart position can be a next named fragment (NFN) flag, such as NFN flags 354 or 374 of FIGS. 3A and 3C, respectively. If the received fragment indicates an optimal restart position, the intermediate node sets an indicator of early congestion notification (ECN) for the received fragment to an active value (operation 408). If the received fragment does not indicate an optimal restart position, the intermediate node sets an indicator of early discarding (ED) for the received fragment to an active value (operation 410). The intermediate node then forwards the received fragment to a next-hop node based on a reverse path of a corresponding interest in the PIT (operation 412).

Subsequently, the intermediate node determines whether it receives a second packet that corresponds to a subsequent fragment, e.g., a fragment received after the forwarded packet (decision 414). If it does not, the operation returns. If the intermediate node does receive a subsequent fragment, the intermediate node drops the subsequent fragment (operation 416).

FIG. 5A presents a flow chart 500 illustrating a method by an intermediate node for processing a fragment of a content object message, where the fragment indicates congestion and an alternate non-congested path is identified, in accordance with an embodiment of the present invention. During operation, an intermediate node receives a packet that corresponds to a fragment of a content object message fragmented into a plurality of fragments (operation 502). The plurality of fragments includes at least one named fragment. The intermediate node determines whether an indicator for congestion notification is set (operation 504). For example, the intermediate node determines whether either of the ECN or ED flags is set to an active value. If the indicator for CN is not set, the intermediate node forwards the received fragment to a next-hop node based on a reverse path of a corresponding interest in the PIT (operation 514). If the indicator for CN is set (e.g., either of the ECN or ED flags is set), the intermediate node determines whether it can identify a non-congested alternate path (e.g., an alternate path not associated with the congestion) (operation 506). If it cannot, the intermediate node performs operation 514 as described above. If it can identify a non-congested alternate path, the intermediate node determines which of the ECN or ED flags is set to an active value (decision 508). If the ECN flag is set, the operation continues at Label A of FIG. 5B, and if the ED flag is set, the operation continues at Label B of FIG. 5C.

FIG. 5B presents a flow chart 520 illustrating a method by an intermediate node for processing a fragment of a content object message, where the fragment indicates congestion and an alternate non-congested path is identified, in accordance with an embodiment of the present invention. During operation, at Label A, when the intermediate node detects that the ECN flag is set, and a non-congested alternate path is available, the intermediate node generates an interest message for the remainder of the plurality of fragments, starting from the next fragment (operation 522). The next fragment is the fragment which directly follows the received fragment. The intermediate node computes the intermediate state for the next fragment based on a hash function performed on the intermediate state of the received fragment (operation 524). The intermediate node also computes the payload size for the remainder of the plurality of fragments, starting from the next fragment (operation 526). This can be based on, e.g., determining from a PIT lookup the overall length of the content object message in combination with the total number of bytes forwarded for the corresponding entry. The intermediate node includes the computed intermediate state and the computed payload size in a name for the interest message (operation 528). The intermediate node also sets the indicator of early congestion notification for the received fragment to an active value (operation 530), and the operation continues at Label C of FIG. 5C.

At Label B, when the intermediate node detects that the ED flag is set, and a non-congested alternate path is available, the intermediate node identifies a previously received named fragment that is closest in order to the received fragment (operation 532). The intermediate node generates an interest message for a remainder of the plurality of fragments, starting from the previously received name fragment (operation 534). The intermediate node computes the size for the remainder of the plurality of fragments, starting from the previously received named fragment (operation 536). This can be based on, e.g., identifying the payload offset of the received fragment and the overall length of the content object message from a corresponding PIT entry. The intermediate node includes the intermediate state of the previously received name fragment and the computed payload size in a name for the interest message (operation 538). The intermediate node also sets the indicator of early discarding for the received fragment to an inactive value (operation 540), and the operation continues at Label C of FIG. 5C.

FIG. 5C presents a flow chart 550 illustrating a method by an intermediate node for processing a fragment of a content object message, where the fragment indicates congestion and an alternate non-congested path is identified, in accordance with an embodiment of the present invention. During operation, at Label C, the intermediate node forwards the received fragment to a next-hop node based on a reverse path of a corresponding interest in the PIT (operation 552). The intermediate node also forwards the interest message (with the appropriately constructed name, as shown in FIG. 5B) to a next-hop node based on an interface associated with the non-congested alternate path (operation 554). In this way, an upstream intermediate node that detects either the ECN or ED flag set to an active value can proactively begin requesting the remainder of the fragment stream on behalf of the client from a different, non-congested downstream path (e.g., the alternate path), and can also clear the appropriate bit or flag (as in operations 530 and 538).

Processing by a Content Requestor

FIG. 6A presents a flow chart 600 illustrating a method by a content requesting device for processing a fragment of a content object message, in accordance with an embodiment of the present invention. During operation, a content requesting device or a content requestor receives a packet that corresponds to a fragment of a content object message fragmented into a plurality of fragments (operation 602). The plurality of fragments includes at least one named fragment. The requestor determines whether an indicator for congestion notification is set (operation 604). For example, the requestor determines whether either of the ECN or ED flags is set to an active value. If the indicator for congestion notification is not set (e.g., neither of the ECN or ED flags is set), the requestor processes the received fragment for reassembly (operation 612). If the indicator for congestion notification is set (e.g., either of the ECN or ED flags is set), the requestor determines which of the ECN or ED flags is set to an active value (decision 606). If the ECN flag is set, the operation continues at Label D of FIG. 6B, and if the ED flag is set, the operation continues at Label E of FIG. 6B.

FIG. 6B presents a flow chart 620 illustrating a method by a content requesting device for processing a fragment of a content object message, in accordance with an embodiment of the present invention. During operation, at Label D, when the content requesting device or the content requestor determines that the ECN flag is set, the requestor performs operations 622, 624, 626, and 628, which correspond respectively to operations 522, 524, 526, and 528 performed by an intermediate node, as described above in relation to FIG. 5B. The requestor also updates the corresponding PIT entry based on the payload offset of the received fragment (operation 630), which allows the requestor to continue monitoring which fragments have already been received. At Label E, when the requestor determines that the ED flag is set, the requestor performs operations 632, 634, and 636, which correspond respectively to operations 534, 536, and 538 performed by an intermediate node, as described above in relation to FIG. 5B. The requestor also updates the corresponding PIT entry based on the payload offset of the previously received name fragment (operation 638).

Exemplary Apparatus and Computer System

FIG. 7A illustrates an exemplary apparatus 700 that facilitates flow control based on a secure fragmentation protocol, in accordance with an embodiment of the present invention. Apparatus 700 can comprise a plurality of modules which may communicate with one another via a wired or wireless communication channel. Apparatus 700 may be realized using one or more integrated circuits, and may include fewer or more modules than those shown in FIG. 7A. Further, apparatus 700 may be integrated in a computer system, or realized as a separate device which is capable of communicating with other computer systems and/or devices. Specifically, apparatus 700 can comprise a communication module 702, a congestion detecting module 704, an interest constructing module 706, a path identifying module 708, and an optimal restart module 710.

In some embodiments, communication module 702 can send and/or receive data packets to/from other network nodes across a computer network, such as a content centric network, where a data packet can correspond to a fragment of a content object message that is fragmented into a plurality of fragments. For example, communication module 702 can receive, by an intermediate node, a fragment of a content object. Congestion detecting module 704 can detect a congestion and set an indicator for congestion notification in a received fragment. Communication module 702 can forward the received fragment and also drop any fragments received after the forwarded fragment, e.g., for the same stream. Optimal restart module 710 can determine that the received fragment indicates an optimal position to restart a flow of the plurality of fragments, and can also determine that the received fragment is a previous fragment that directly precedes a named fragment. Optimal restart module 710 can further determine that the received fragment does not indicate an optimal position to restart a flow of the plurality of fragments.

Path identifying module 708 can identify an alternate path not associated with the congestion. Optimal restart module 710 can identify a previously received named fragment that is closest in order to the received fragment. Interest constructing module 706 can generate an interest for a remainder of the plurality of fragments starting from a next fragment that directly follows a received fragment or the previously received named fragment. Interest constructing module 706 can also compute an intermediate state for the next fragment, determine a payload size for the remainder of the plurality of fragments starting from the next fragment or the previously received named fragment, and include in a name for the interest the computed intermediate state (or an intermediate state of the previously received named fragment) and the determined payload size. Congestion detecting module 704 can reset an indicator for early congestion notification or for early discarding. Communication module 702 can forward the interest based on an interface associated with the alternate path.

FIG. 7B illustrates an exemplary apparatus 750 that facilitates flow control based on a secure fragmentation protocol, in accordance with an embodiment of the present invention. Apparatus 750 can comprise a plurality of modules which may communicate with one another via a wired or wireless communication channel. Apparatus 750 may be realized using one or more integrated circuits, and may include fewer or more modules than those shown in FIG. 7B. Further, apparatus 750 may be integrated in a computer system, or realized as a separate device which is capable of communicating with other computer systems and/or devices. Specifically, apparatus 750 can comprise a communication module 752, a congestion detecting module 754, an interest constructing module 756, a PIT maintenance module 758, and a fragment processing module 760.

In some embodiments, communication module 752 can send and/or receive data packets to/from other network nodes across a computer network, such as a content centric network, where a data packet can correspond to a fragment of a content object message that is fragmented into a plurality of fragments. For example, communication module 752 can receive, by a content requesting device, a fragment of a content object. Congestion detecting module 754 can determine that an indicator for congestion notification in the received fragment is set. Interest constructing module 756 can generate an interest for a remainder of the plurality of fragments starting from a named fragment.

Interest constructing module 756 can generate an interest for a remainder of the plurality of fragments starting from a next fragment that directly follows a received fragment or identify a previously received named fragment that is closest in order to the received fragment. Interest constructing module 756 can also compute an intermediate state for the next fragment, determine a payload size for the remainder of the plurality of fragments starting from the next fragment or the previously received named fragment, and include in a name for the interest the computed intermediate state (or an intermediate state of the previously received named fragment) and the determined payload size. PIT maintenance module 758 can update a corresponding entry in a PIT based on a payload offset of the received fragment or the previously received named fragment. Fragment processing module 760 can process the received fragment for reassembly.

FIG. 8A illustrates an exemplary computer system 802 that facilitates flow control based on a secure fragmentation protocol, in accordance with an embodiment of the present invention. Computer system 802 includes a processor 804, a memory 806, and a storage device 808. Memory 806 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 802 can be coupled to a display device 810, a keyboard 812, and a pointing device 814. Storage device 808 can store an operating system 816, a content-processing system 818, and data 830.

Content-processing system 818 can include instructions, which when executed by computer system 802, can cause computer system 802 to perform methods and/or processes described in this disclosure. Specifically, content-processing system 818 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 820). For example, content-processing system 818 can include instructions for receiving, by an intermediate node, a data packet that corresponds to a fragment of a content object message that is fragmented into a plurality of fragments (communication module 820).

Content-processing system 818 can include instructions for detecting a congestion and setting an indicator for congestion notification in a received fragment (congestion detecting module 822). Content-processing system 818 can also include instructions for forwarding the received fragment and for dropping any fragments received after the forwarded fragment, e.g., for the same stream (communication module 820). Content-processing system 818 can additionally include instructions for determining whether the received fragment indicates an optimal position to restart a flow of the plurality of fragments, and also for determining that the received fragment is a previous fragment that directly precedes a named fragment (optimal restart module 828).

Content-processing system 818 can further include instructions for identifying an alternate path not associated with the congestion (path identifying module 826). Content-processing system 818 can include instructions for identifying a previously received named fragment that is closest in order to the received fragment (optimal restart module 828). Content-processing system 818 can include instructions for generating an interest for a remainder of the plurality of fragments starting from a next fragment that directly follows a received fragment or the previously received named fragment (interest constructing module 824). Content-processing system 818 can also include instructions for computing an intermediate state for the next fragment, determining a payload size for the remainder of the plurality of fragments starting from the next fragment or the previously received named fragment, and including in a name for the interest the computed intermediate state (or an intermediate state of the previously received named fragment) and the determined payload size (interest constructing module 824).

Content-processing system 818 can include instructions for resetting an indicator for early congestion notification or for early discarding (congestion detecting module 822). Content-processing system 818 can include instructions for forwarding the interest based on an interface associated with the alternate path (communication module 820).

FIG. 8B illustrates an exemplary computer system 852 that facilitates flow control based on a secure fragmentation protocol, in accordance with an embodiment of the present invention. Computer system 852 includes a processor 854, a memory 856, and a storage device 858. Memory 856 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 852 can be coupled to a display device 860, a keyboard 862, and a pointing device 864. Storage device 858 can store an operating system 866, a content-processing system 868, and data 880.

Content-processing system 868 can include instructions, which when executed by computer system 852, can cause computer system 852 to perform methods and/or processes described in this disclosure. Specifically, content-processing system 868 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 870). For example, content-processing system 818 can include instructions for receiving, by a content requesting device, a data packet that corresponds to a fragment of a content object message that is fragmented into a plurality of fragments (communication module 870).

Content-processing system 868 can include instructions for determining that an indicator for congestion notification in the received fragment is set (congestion detecting module 872). Content-processing system 868 can include instructions for generating an interest for a remainder of the plurality of fragments starting from a named fragment (interest constructing module 874).

Content-processing system 868 can include instructions for generating an interest for a remainder of the plurality of fragments starting from a next fragment that directly follows a received fragment or the previously received named fragment (interest constructing module 874). Content-processing system 868 can also include instructions for computing an intermediate state for the next fragment, determining a payload size for the remainder of the plurality of fragments starting from the next fragment or the previously received named fragment, and including in a name for the interest the computed intermediate state (or an intermediate state of the previously received named fragment) and the determined payload size (interest constructing module 874).

Content-processing system 868 can also include instructions for updating a corresponding entry in a PIT based on a payload offset of the received fragment or the previously received named fragment (PIT maintenance module 876). Content-processing system 868 can also include instructions for processing the received fragment for reassembly (fragment processing module 878).

Data 830 of FIG. 8A and data 880 of FIG. 8B 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 830 and data 880 can store at least: a packet that corresponds to a fragment of a content object message that is fragmented into a plurality of fragments; a unique name that is an HSVLI that comprises contiguous name components ordered from a most general level to a most specific level; a name that is based on a hash of a content object or that indicates a digest; an intermediate state for a fragment which is based on a hash function performed on an intermediate state from a previous fragment and data included in the fragment; a pending interest table; a digest for a content object; a byte offset that corresponds to a starting byte for a fragment; an overall length for a content object; a payload size; an entry in a pending interest table; a digital signature of a content producing device; a total number of bytes forwarded; a name that indicates the intermediate state, the byte offset, the digest, and/or the payload size; an indicator of congestion notification; an indicator of early congestion notification; an indicator of early discarding; an indicator that a next fragment is a named fragment; and an interest for a subsequence of a fragment stream.

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 computer system for facilitating forwarding of packets, the system comprising a processor; anda storage device storing instructions that when executed by the processor cause the processor to perform a method, the method comprising: receiving, by an intermediate node, a first fragment which is a fragment of a content object that is fragmented into a plurality of fragments,wherein the plurality of fragments includes at least one named fragment, which indicates a name associated with the content object, the name being a hierarchically structured variable-length identifier that comprises contiguous name components ordered from a most general level to a most specific level;detecting a congestion;when there is congestion: setting an indicator for congestion notification in the received first fragment;forwarding the received first fragment;dropping a second fragment received after the forwarded first fragment;receiving a third fragment comprising a congestion notification;identifying an alternate path not associated with the congestion;generating an interest for a remainder of the plurality of fragments based on the congestion notification of the third fragment; andforwarding the interest based on an interface associated with the alternate path.

2. The computer system of claim 1, wherein in response to detecting the congestion, the method further comprises: determining that the received first fragment indicates an optimal position to restart a flow of the fragment,wherein the indicator for congestion notification is an indicator for early congestion notification.

3. The computer system of claim 1, wherein the method further comprises: determining that the received first fragment indicates an optimal position to restart a flow of the fragment, which involves: determining that the received first fragment is a previous fragment that directly precedes a named fragment.

4. The computer system of claim 1, wherein the method further comprises: determining that the received first fragment does not indicate an optimal position to restart a flow of the fragment,wherein the indicator for congestion notification is an indicator for early discarding.

5. The computer system of claim 1, wherein the congestion notification in the received third fragment is an indicator for early congestion, and wherein the method further comprises: generating the interest further comprises, generating the interest for the remainder of the plurality of fragments starting from a next fragment that directly follows the received third fragment; andsetting the indicator for early congestion notification in the received third fragment to an inactive value.

6. The computer system of claim 5, wherein generating the interest further comprises: computing an intermediate state for the next fragment based on a hash function performed on an intermediate state from the received third fragment, wherein the received third fragment indicates an intermediate state which is based on a hash function performed on an intermediate state from a previous fragment and data included in the received third fragment;determining a payload size for the remainder of the plurality of fragments starting from the next fragment; andincluding in a name for the interest based on the computed intermediate state and the determined payload size.

7. The computer system of claim 1, wherein the congestion notification in the received third fragment is an indicator for early discarding, and wherein the method further comprises: identifying a previously received named fragment that is closest in order to the received third fragment;generating the interest further comprises, generating the interest for the remainder of the plurality of fragments starting from the previously received named fragment; andsetting the indicator for early discarding in the received third fragment to an inactive value.

8. The computer system of claim 7, wherein generating the interest further comprises: determining a payload size for the remainder of the plurality of fragments starting from the previously received named fragment; andincluding in a name for the interest an intermediate state for the previously received named fragment and the determined payload size,wherein the intermediate state for the previously received named fragment is based on a hash function performed on an intermediate state from a previous fragment that directly precedes the previously received named fragment and data included in the previously received named fragment.

9. The computer system of claim 1, wherein a name for an interest includes a digest for the content object, and a number indicating a byte offsetthat corresponds to a starting byte for the received first fragment or a previously received named fragment closest in order to the received first fragment.

10. A computer system for facilitating forwarding of packets, the system comprising: a processor; anda storage device storing instructions that when executed by the processor cause the processor to perform a method, the method comprising: receiving, by a content requesting device, a first fragment which is a fragment of a content object message that is fragmented into a plurality of fragments,wherein the plurality of fragments includes at least one named fragment, which indicates a name associated with the content object, the name being a hierarchically structured variable-length identifier that comprises contiguous name components ordered from a most general level to a most specific level;determining that an indicator for congestion notification in the received first fragment is set;updating a corresponding entry in a pending interest table based on a payload offset of the received first fragment or of a previously received named fragment that is closest in order to the received first fragment, wherein the payload offset is a number indicating a byte offset; andgenerating an interest for a remainder of the plurality of fragments starting from a named fragment.

11. The computer system of claim 10, wherein the indicator for congestion notification is an indicator for early congestion notification, wherein the named fragment is a next fragment that directly follows the received first fragment, and wherein generating the interest further comprises: computing an intermediate state for the next fragment based on a hash function performed on an intermediate state from the received first fragment, wherein the received first fragment indicates an intermediate state which is based on a hash function performed on an intermediate state from a previous fragment and data included in the received first fragment;determining a payload size for the remainder of the plurality of fragments starting from the next fragment; andincluding in a name for the interest based on the computed intermediate state and the determined payload size.

12. The computer system of claim 10, wherein the byte offset corresponds to a starting byte for the received first fragment.

13. The computer system of claim 10, wherein the indicator for congestion notification is an indicator for early discarding, wherein the named fragment is the previously received named fragment that is closest in order to the received first fragment, and wherein generating the interest further comprises: determining a payload size for the remainder of the plurality of fragments starting from the previously received named fragment; andincluding in a name for the interest an intermediate state for the previously received named fragment and the determined payload size,wherein the intermediate state for the previously received named fragment is based on a hash function performed on an intermediate state from a previous fragment that directly precedes the previously received named fragment and data included in the previously received named fragment.

14. The computer system of claim 13, wherein the byte offset corresponds to a starting byte for the previously received named fragment.

15. The computer system of claim 10, wherein the method further comprises: in response to determining that the indicator for congestion notification in the received first fragment is not set, processing the received first fragment forreassembly.

16. A computer-implemented method for forwarding packets, the method comprising: receiving, by an intermediate node, a first fragment which is a fragment of a content object that is fragmented into a plurality of fragments,wherein the plurality of fragments includes at least one named fragment, which indicates a name associated with the content object, the name being a hierarchically structured variable-length identifier that comprises contiguous name components ordered from a most general level to a most specific level;detecting a congestion;when there is congestion: setting an indicator for congestion notification in the received first fragment;forwarding the received first fragment;dropping a second fragment received after the forwarded first fragment;receiving a third fragment comprising a congestion notification;identifying an alternate path not associated with the congestion;generating an interest for a remainder of the plurality of fragments based on the congestion notification of the third fragment; andforwarding the interest based on an interface associated with the alternate path.

17. The method of claim 16, wherein in response to detecting the congestion, the method further comprises: determining that the received first fragment indicates an optimal position to restart a flow of the fragment,wherein the indicator for congestion notification is an indicator for early congestion notification.

18. The method of claim 16, further comprising: determining that the received first fragment indicates an optimal position to restart a flow of the fragment, which involves: determining that the received first fragment is a previous fragment that directly precedes a named fragment.

19. The method of claim 16, further comprising: determining that the received first fragment does not indicate an optimal position to restart a flow of the fragment,wherein the indicator for congestion notification is an indicator for early discarding.

20. The method of claim 16, further comprising wherein the congestion notification in the received third fragment is an indicator for early congestion, the method further comprising: generating the interest further comprising, generating the interest for the remainder of the plurality of fragments starting from a next fragment that directly follows the third fragment; andsetting the indicator for early congestion notification in the received third fragment to an inactive value.

21. The method of claim 20, wherein generating the interest further comprises: computing an intermediate state for the next fragment based on a hash function performed on an intermediate state from the received first fragment, wherein the received first fragment indicates an intermediate state which is based on a hash function performed on an intermediate state from a previous fragment and data included in the received first fragment;determining a payload size for the remainder of the plurality of fragments starting from the next fragment; andincluding in a name for the interest the computed intermediate state and the determined payload size.

22. The method of claim 16, wherein the congestion notification in the received third fragment is an indicator for early discarding, the method further comprising: identifying a previously received named fragment that is closest in order to the received third fragment;generating the interest further comprising, generating the interest for the remainder of the plurality of fragments starting from the previously received named fragment; andsetting the indicator for early discarding in the received third fragment to an inactive value.

23. The method of claim 22, wherein generating the interest further comprises: determining a payload size for the remainder of the plurality of fragments starting from the previously received named fragment; andincluding in a name for the interest an intermediate state for the previously received named fragment and the determined payload size,wherein the intermediate state for the previously received named fragment is based on a hash function performed on an intermediate state from a previous fragment that directly precedes the previously received named fragment and data included in the previously received named fragment.

24. The method of claim 16, wherein a name for an interest includes a digest for the content object, and a number indicating a byte offset that corresponds to a starting byte for the received first fragment or a previously received named fragment closest in order to the received first fragment.