JP2014529959A - Generalized dual-mode data transfer plane for information-centric networks - Google Patents

Abstract

The network system includes a content router for an information centric network (ICN) and a plurality of next hop nodes of the ICN coupled to the content router. The content router has a content store (CS), a pending interest table (PIT), a transfer information base (FIB), and a plurality of interfaces. It is configured to receive and transfer interest from one or more users and data from one or more applications. The next hop node is configured to forward interest and data to the content router via the interface. The dual mode forwarding plane uses FIB without CS and PIT for conversational traffic and uses CS, PIT, and FIB for content distribution traffic to transfer interest and data.

Description

  The present invention relates to communication networks, and more particularly to information-centric networks.

  In a content-oriented network (CON), a content router is responsible for routing user requests and content to appropriate recipients. In CON, also referred to as Information Centered Network (ICN), a domain wide unique name is assigned to each entity that is part of the content distribution framework. Entities may include data content such as video clips or web pages, and / or infrastructure elements such as routers, switches, or servers. A content router uses a name prefix, which can be the entire content name or an appropriate prefix of the content name, instead of a network address, to route content packets within the content network. In CON, content delivery including issuance, request, management (eg, change, delete, etc.) can be based on content name rather than location of content. One aspect of CON that may differ from traditional Internet Protocol (IP) networks is that CON interconnects multiple geographical points to temporarily cache content or store content more permanently. Is what you can do. This can allow content to be serviced from the network instead of the original server, thus greatly improving the user experience. Cache / store may be used for real-time data fetched by the user, or persistent data belonging to the user or content provider, eg, a third party provider.

  In one embodiment, a network system comprises a content router for an ICN and a plurality of next hop nodes of the ICN coupled to the content router, the content router comprising a content store (CS) and a pending An interest table (PIT), a forwarding information base (FIB), multiple interfaces, and using dual mode data transfer planes, interest from one or more users and one or more Configured to receive and forward data from an application via the plurality of interfaces such that the plurality of next hop nodes forward the interest and data to the content router via the plurality of interfaces. Composed of the dua Mode transfer plane, the conversational traffic using FIB without using a CS and PIT, the content distribution traffic forwarding CS, PIT, and the interest and data using FIB.

  In another embodiment, the present disclosure is a network component, a transmitter / receiver configured to receive and forward an interest protocol data unit (PDU) and a data PDU indicating a transfer mode A memory comprising a (transceiver), a CS for caching content, a PIT for tracking pending requests for content, a transfer information base for associating content with one or more ports, and a PIT Transfer interest PDUs and data PDUs related to sharable content traffic in the non-priority mode used, and transfer interest PDUs and data PDUs related to non-sharable content traffic in the priority mode using FIB without using PIT And a processor configured urchin, including network components.

  In yet another embodiment, the present disclosure is a method implemented by a network component for forwarding interest and data traffic in an ICN, receiving content interest or data via a receiver; Transferring the content interest or data using a PIT if the content or interest data corresponds to content distribution traffic via a transmitter; and the content or interest data is spoken via the transmitter. In the case of handling type traffic, transferring the content interest or data using FIB without using PIT.

  These and other features will be more clearly understood from the following detailed description taken in conjunction with the accompanying drawings and claims.

  For a more complete understanding of the present disclosure, reference is now made to the following brief description taken in conjunction with the accompanying drawings and detailed description. Like reference numerals represent like parts.

It is the schematic of the operation | movement of a general single mode transfer plane. FIG. 2 is a schematic diagram of a general single mode transfer scenario. FIG. 6 is a schematic diagram of the operation of a dual mode transfer plane according to an embodiment of the present disclosure. FIG. 6 is a schematic diagram of an embodiment of an interest PDU format. FIG. 6 is a schematic diagram of an embodiment of a data PDU format. 1 is a schematic diagram of one embodiment of a simulation topology. FIG. 6 is a graph of one embodiment of the relationship between maximum CS size and voice call rate. 6 is a graph of one embodiment of a relationship between maximum pending interest table (PIT) size and voice call rate. 6 is a graph of one embodiment of a relationship between round trip time and class id. 4 is a graph of one embodiment of the relationship between round trip time and voice call request rate. FIG. 6 is a schematic diagram of one embodiment of a hybrid mode transfer implementation. FIG. 6 is a schematic diagram of an embodiment of a hybrid mode transfer scenario. 6 is a flowchart of an embodiment of a dual mode transfer method. It is the schematic of one Embodiment of a network unit. 1 is a schematic diagram of one embodiment of a general-purpose computer system.

  Initially, exemplary implementations of one or more embodiments are provided below, regardless of whether the disclosed systems and / or methods are currently known or existing. Rather, it should be understood that any number of techniques may be implemented. This disclosure should in no way be limited to the exemplary embodiments, drawings, and techniques shown below, including the exemplary designs and embodiments illustrated and described herein, and is equivalent to their full scope. Together with the subject matter, modifications may be made within the scope of the appended claims.

  CON or ICN is considered the next generation Internet architecture to support both content distribution traffic and conversational traffic. Unlike today's Internet Protocol (IP) routers, ICN routers can combine content routing, content computing capabilities, and content local caching / storage functions. Similar to today's IP networks, ICN (as a new interaction layer) may be able to support multiple different traffic models, such as conversational traffic models and content distribution models. Conversational models include applications such as voice / video multimedia applications, voice over IP (VoIP), instant messaging, social networking, transaction-based online banking, and some real-time transport protocols (RTP) for real-time communications. ) Connections, and / or other similar network traffic. The content distribution model may include content search and push events, such as broadcast or multicast media (eg, IP television) and / or similar traffic. In general, the conversational model may correspond to non-sharable communication between peers, while the distribution model may correspond to sharable content distributed among many people or users.

  In some ICN models, such as content-centric network (CCN) / named data networking (NDN) recommendations, the interaction function may be focused on the content distribution model. A stateful approach may be used to support name-based routing and forwarding in order to efficiently support content distribution in the CCN / NDN data forwarding plane. In a stateful approach, for each request, the content router may maintain a state in the network (eg, within a time limit) and the state may be per content name. For example, for a newly received interest, the CCN / NDN may generate and maintain a status record in the PIT. The PIT can use this stateful information to abort the interest loopback, aggregate other interests into the same content name, and direct the returned content data back to the original requester. PIT can also be used to support dynamic source routing when ICN is applied to ad hoc networks (eg, infrastructure-free networks that do not use IP routing protocols).

  While PIT can be useful or effective in supporting content delivery, it can also lead to disadvantages. Specifically, the PIT status information can be linear or proportional to the number of interests, and therefore, when a conversational traffic model such as VoIP traffic or online banking services is considered, there is a considerable scalability problem. Can have. For example, each exchanged VoIP traffic may require a corresponding end-to-end session where the exchange information cannot be shared with others due to privacy concerns, for example. However, the PIT may not need to keep record entries for VoIP traffic or other similar traffic. Using PIT for VoIP traffic may not improve the handling of VoIP traffic and the routing of such traffic, which may lead to scalability issues.

  Disclosed herein are systems and methods for using dual-mode data transfer plane operations to support both content / information distribution models and host-to-host conversational models. Dual mode data transfer plane operation can solve the PIT scalability problem and can be based on name-based routing and forwarding in ICN or CON. Dual mode data transfer plane operation is non-shared between hosts (eg, between two or more hosts) such as a first mode for handling content distribution using PIT and voice / video traffic, for example. And a second mode for handling possible conversational traffic. Conversational traffic can be handled using, for example, FIB for data routing in both directions of interest and content data. In the first mode, the packet can be processed in the first or slow pass, which may include multiple operations such as local caching data retrieval, PIT lookup and update, and FIB lookup and forwarding. . In the second mode, the packet can be processed in the second or fast path, which may include FIB lookup and forwarding with no other action. To support this dual mode operation, a new header for ICN PDUs may be used, as described in detail below. Dual mode data transfer plane operation can handle both distributed and conversational traffic models flexibly and scalable and can be supervised by traffic applications.

  FIG. 1 shows a typical single mode transfer plane operation 100, which may currently be used in ICN or CON. For example, single mode transfer plane operation 100 may be used in a CCN / NDN data transfer plane. Single mode transfer plane operation 100 may be implemented by a content router 101 in an ICN or CON. The content router 101 has a plurality of ports or interfaces 102 (eg, face 0, face 1, face 2,...) And a plurality of transfer tables or data to properly handle content data transfers in the ICN or CON. And a structure. The interface 102 may be connected to one or more users or content subscribers (not shown) and one via multiple fixed (wired) links, wireless links, networks, the Internet, and / or other components or systems. Or it may be coupled to multiple services or applications 103.

  The forwarding table of the content router 101 may include a CS 110, a PIT 120, and a forwarding information base (FIB) 130. The CS 110 may be used to associate interests (user requests for content) with corresponding data (requested content). For example, CS 110 may include a “name” column indicating each received interest and a “data” column indicating the corresponding content data, which may be received at content router 101 and optionally. Alternatively, it may be partially cached in the content router 101. The PIT 120 associates each interest with one or more requesting or receiving interfaces 102 so that each receiving interest that is being serviced or pending (until the corresponding requested content data is received). May be used to record and track. For example, the PIT 120 may comprise a “prefix” column indicating each interest and a “request face” column indicating one or more receiving interfaces 102 for that interest. The FIB 130 may be used to associate an interest with the corresponding interface 102 through which the interest is received and forwarded. For example, the FIB 130 may comprise a “prefix” column indicating each interest and a “face list” column indicating the corresponding receive and forward interface 102. The content router 101 may include a pointer table 140 or a data structure that indicates each of the three transfer tables. For example, the pointer table 140 includes a “ptr” column that indicates or indicates the location of each forwarding table, and the name or type of each corresponding forwarding table (eg, “C” for CS, “P” for PIT, and FIB). "F") for "type" column may be provided.

  In single mode transfer plane operation 100, interest may be received at a first port or interface 102 (face 0) via a wireless link, eg, from a user or content subscriber (not shown). The interest may comprise a name prefix that indicates the content being requested and may be forwarded to CS 110 or processed at CS 110. Within CS 110, entries may be created for interests received using the indicated name prefix. The name prefix may be entered in a new or empty row of CS 110 under its “name” column. The interest may then be forwarded to PIT 120 or processed at PIT 120. Within the PIT 120, entries may be created for interests received using the indicated name prefix. The requesting or receiving interface 102 (face 0) may also be indicated in the same entry. The name prefix may be entered in a new or empty row of PIT 120 under its “prefix” column, and face 0 may be shown in the same row under its “request face” column. The interest may then be transferred to the FIB 130 or processed at the FIB 130. Within FIB 130, entries may be created for interests received using the indicated name prefix. The requesting interface 102 (face 0) may also be indicated in the same entry. The name prefix may be entered in a new or empty row of FIB 130 under its “prefix” column, and face 0 may be shown in the same row under its “face list” column. The interest may then be forwarded over forwarding interface 102 (Face 1), for example, to the next hop or content router (not shown).

  When the requested content data is received, for example, on the forwarding interface 102 (Face 1) via the next hop, the name prefix indicated in the received data is checked against the corresponding entry in the FIB 130. May be. In this way, the receive transfer interface 102 (face 1) for that data may be added to the “face list” column of the matched entry. The name prefix may then be matched with the corresponding entry in PIT 120. Accordingly, the content data may be transferred on the interface (s) 102 (face 0) indicated in the “request face” column of the matched entry. The name prefix may also be matched with the corresponding entry in CS 110 and the content data may be cached in the “data” column of the matched entry. Content data may or may not be fully or partially cached according to caching standards or schemes.

  For content distribution traffic such as broadcast or multicast media (eg, IP television), interest may be received on multiple interfaces 102, eg, from multiple users or content subscribers. Thus, the “request face” column of the matched entry may indicate multiple interfaces 102 over which content can be transmitted (broadcast or multicast). However, for conversational traffic that is non-sharable, an entry may be created for each receiving interface 102 at the PIT 120. As such, the number of entries may be proportional to the number of requesting users or subscribers, which may greatly increase the size of the PIT 120 as the number of users increases significantly. This may cause scalability problems for larger networks (relatively larger ICN or CON) for PIT 120, thus reducing transfer efficiency, increasing costs, or both. .

  FIG. 2 shows a typical single mode transfer scenario 200 in a network system, which may be based on single mode transfer plane operation 100. Data or content may be transferred within the network system using a name prefix. A network system may include one or more tier 1 networks (eg, for the Internet), one or more tier 2 networks (eg, IP backbone, Internet service provider (ISP), Internet interconnection point (IXP) ), Point of presence (POP),..., And one or more tier 3 networks (eg, for multi-homed ISPs, single-homed ISPs,...) A network (eg, ICN) may be provided. The Tier 3 network may be closer to the user (Internet user), the Tier 1 network may be at the Internet level, and the Tier 2 network may be an intermediate network between the Tier 1 and Tier 3 networks. . The tier network may include a plurality of content routers that may include corresponding PITs, such as content router 101.

  Scenario 200 illustrates multiple content routers, eg, edge routers, across a network system, and may have problems with PIT scalability, for example, the number of PIT entries may be significantly higher. For example, the PITs at the edge routers between tier 1 and tier 2 networks and between tier 2 and tier 3 networks are not (as shown by the “explosion” diagram in FIG. 2). May be scalable. Specifically, this scenario corresponds to a plurality of network conditions as shown in Table 210. Conditions include relative upstream router concentration, average entrance bandwidth, and PIT size (per router) for each group of tier networks (Tier 1, Tier 2, and Tier 3). The upstream router concentration for tier 1 and tier 2 networks (8.4 and 8 respectively) can be significantly greater than the upstream router concentration for tier 3 networks. The average ingress bandwidth may be larger (110G) for tier 1 networks and smaller (3.5G) for tier 3 networks compared to tier 2 networks (36.2 gigabytes (G)) . The PIT size that can be proportional to the average ingress bandwidth is also larger for the Tier 1 network (3.29G) and smaller for the Tier 3 network (0.049G) compared to the Tier 2 network (0.411G). Can be a thing.

  FIG. 3 illustrates one embodiment of a dual mode forwarding plane operation 300 that can be used in an ICN that solves the PIT scalability problem and thus improves routing efficiency in the CCN / NDN data forwarding plane, for example. The dual mode transfer plane operation 300 may be implemented by the content router 301 in the ICN. Content router 301 includes a plurality of ports or interfaces for receiving and transmitting interest / data and a plurality of forwarding tables or data structures for properly handling content data transfers in an ICN, including CS 310, PIT 320, and FIB 330 The body may be provided. In dual mode forwarding plane operation 300, traffic may be forwarded in priority mode or non-priority mode depending on the type of traffic. Specifically, conversational traffic (eg, non-sharable traffic) may be forwarded using priority mode, and content distribution traffic (eg, sharable traffic) is forwarded using non-priority mode. May be. Both each interest and data for each type of traffic may be forwarded according to priority or non-priority mode. The transfer mode may be indicated in the received interest and data, such as using a PDU format as described below.

  Non-priority mode may be used for content distribution or shareable traffic (both interest and data) and may correspond to forwarding plane operation 100. Thus, each of CS 310, PIT 320, and FIB 330 may be used for receiving and handling and forwarding interests and data as described in forwarding plane operation 100. Since content data may be sharable among multiple users or subscribers, the same entry in PIT 330 may be shared for multiple receiving ports, thereby avoiding scalability issues. Priority mode may be used for conversational or non-sharable traffic (both interest and data) and without using CS 310 and PIT 320, FIB 330 is used for receiving and handling and forwarding interest and data. obtain. By avoiding input to PIT 320 (and CS 310), interest and content transfer can be prioritized and PIT scalability issues can be resolved. The FIB 330, like the FIB 130, may be used to associate interests with corresponding ports from which interests are received and forwarded. When the requested content data is received, for example, on a port different from the corresponding interest receiving port, the name prefix indicated in the received data may be matched with the corresponding entry in FIB 330. . The interest receiving port in the matched entry can be used to transfer data, and the port receiving the data can be added to the matched entry. In addition to improving the scalability of the PIT 320, the dual mode transfer plane operation 300 provides flexibility in transferring various types of content interest / data, thus improving overall routing efficiency. it can.

  FIG. 4 shows one embodiment of an interest PDU format 400 that may be used to transmit interest in dual mode transfer plane operation 300. The interest PDU format 400 can indicate the type of traffic to which the interest belongs (conversational or content distribution traffic), so that, as described above, the traffic can be forwarded accordingly. The interest PDU can be received with or as part of the received interest message, message type field 410, transfer mode field 420, source object name field 430, destination object name field 440, check A thumb field 450, an invalid or valid period (TTL) field 460, a signature field 470, a nonce field 480, a meta data list or array 490, and a payload field 499 may be provided. The meta data list or array 490 may include a self-certified alias value or field 491, a device type value or field 492, a global positioning system (GPS) value or field 493, a selector value or field 494, and / or a secured Other values or fields 495 may be provided that may include community identifier (ID) values or fields. The above field preceding the payload field 499 may represent the header of the PDU or may be part of it.

  FIG. 5 shows another embodiment of a data PDU format 500 that may be used to send a data response in dual mode transfer plane operation 300. Data PDUs may be returned to the content router in response to corresponding interest PDUs (in PDU format 400). The PDU format 500 can indicate the type of traffic to which the data belongs (conversational or content distribution traffic) so that the traffic can be forwarded accordingly. The data PDU can be received with or as part of the received content data, and includes a message type field 510, a transfer mode field 520, a source object name field 530, a destination object name field 540, and a check. A thumb field 550, a TTL field 560, a signature field 570, a metadata list or array 590, and a payload field 599 may be provided. The meta data list or array 590 may include self-certified alias values or fields 591, device type values or fields 592, GPS values or fields 593, selector values or fields 594, and / or secured community ID values or fields. Other values or fields 595 that may be included may be provided. The above field preceding the payload field 599 may represent the header of the PDU or may be part of it. The fields in the data PDU format 500 may be configured in substantially the same manner as the corresponding fields in the interest PDU format 400 described below.

  Payload 499 may comprise interest data, and payload 599 may comprise content data that may correspond to the interest data. Message type field 410 may comprise a flag that may be set to indicate whether the PDU is an interest PDU or a data PDU. Alternatively, the message type field 410 may comprise a determined value to indicate whether the PDU is an interest PDU or a data PDU. The interest may be routed with the destination object name in the destination object name field 440. For non-cacheable traffic, the interest may be routed with the destination object name and the corresponding data response may be routed using the source object name in the source object name field 430. Message type field 510 may be configured similarly to message type field 410.

  The transfer mode field 420 may comprise a flag that may be set to indicate whether the PDU is being transferred using a priority mode or a non-priority mode. Alternatively, the transfer mode field 420 may comprise a value determined to indicate whether the PDU is being transferred using a priority mode or a non-priority mode. The flag may be determined by the application. For example, if the PDU is non-cacheable (or non-sharable) content such as personal VoIP / video, the application layer may prioritize the mode. In the case of YouTube® streaming video that may be sharable content, the flag may be set as non-priority. The forwarding engine (for the content router 301) looks up the FIB 330 (based on the source / destination object name) and sends the PDU to the designated port or interface accordingly (priority or fast mode) or PIT operation, local This flag may be examined to determine whether to use cache operations and / or some other arithmetic process (non-priority or slow mode).

  If the transfer mode is set as preferred, the PDU may carry the source object name (in the source object field 430). For example, if the device is mobile and the application on the device subscribes to a seamless mobility service, the application may set the flag to non-preferred and use both the source / destination object name for mobility control. Good. When the device detects a change in connection with the base station, the transfer mode may be set to allow seamless anchor points in the network to cache data for a particular user / application. This may allow the application to retrieve data after the mobile device is re-anchored to a new point of attachment. The transfer mode field 520 may be configured similarly to the transfer mode field 420.

  The source object name field 430 can indicate the requester (or user) name, and the destination object name field 440 can indicate the object name being requested. When the transfer type is preferred, the source object name may be included in the interest PDU. Otherwise, using the source object name may be optional. The destination object name can be included in both preferred and non-preferred modes. For example, for voice communications that may be non-sharable content, the source object name (eg, caller) in the data response PDU (from the callee) has a FIB 330 to return the message to the object requester. It may be used by the content router 301.

  To support the dual mode transfer plane operation 300, the content requester or subscriber (and similarly the content producer) may be expected to issue an associated application prefix that seeks a data response. This may allow the prefix to be populated into the FIB 330, thereby routing the data response back. For shareable content (eg, YouTube video), the interest PDU format 400 may not carry a source identifier (ID), and the returned content may be routed back via a PIT 320 lookup. . When the transfer flag (in message type field 410) is set to priority mode, the source object name can be set in the interest PDU for backward transfer purposes. The source object name and destination object name may be either structured names or flat names. The structured name may have a hierarchical format such as a uniform resource identifier (URI). The flat name may have a digital format, which may be a bit string generated from a hash function. When a structured name is used, the PDU or packet may be forwarded to the default gateway router, where, for example, if the content router 301 cannot find the next hop to forward the PDU, A domain name system (DNS) may be used to determine The content router 301 may then transfer the PDU to the destination server to retrieve the content. The source object name field 530 and the destination object name field 540 may be configured similarly to the source object name field 430 and the destination object name field 440, respectively.

  The checksum field 450 may comprise a value that can be verified to indicate the integrity of the received PDU. The checksum value may be used, for example, to check for errors in the header and payload portion of the PDU to check whether the PDU is corrupted in memory or storage. Setting a checksum in a PDU may require reliable content relaying between two routers (content routers). Otherwise, the transmission of the PDU may not be reliable. Checksum field 550 may be configured similarly to checksum field 450.

  The TTL field 460 may be used to indicate the duration of interest / data stored in the PIT or local cache, or both, depending on the forwarding mode setting, eg, to prevent packet forwarding loops. Therefore, the duration of the received PDU or packet can be indicated. TTL may have different interpretations in different transfer modes. In priority mode, the purpose of the TTL may be to break the forwarding loop when both the source and destination object names in the PDU and FIB are used to supervise the forwarding. For example, a forwarding loop may occur due to multipath forwarding between content routers. In non-priority mode, TTL may be used to indicate how long an interest or data PDU can exist or remain valid in the PIT or local cache.

  In priority mode, TTL may be used in both interest PDUs and data PDUs to prevent forwarding loops. The TTL in this case may be set as the number of maximum allowable hops. During transfer, all hops (routers) may reduce the TTL value by one unit until it reaches a value of about zero. If the TTL value is about 0, the PDU can be discarded. In non-priority mode, the TTL may be set as a unit of current time (TOD), which may indicate the duration of the PDU. For example, persistent interests with relatively long TODs may be stored in the PIT to support event push services in ICN (eg, subscribers pre-search for non-existing content can do). The TTL in the data PDU may indicate how long the data can be stored in each local cache. Using this TTL, the content router may implement a policy-based attenuation function to eliminate stale content in the ICN network. The TTL may be set by the application. The TTL field 560 may be configured in the same manner as the TTL field 460.

  The signature field 470 may comprise a cryptographic hash function that may be based on the name and payload, eg, a hash (name, payload). The signature may be a signed certificate that maintains the relationship between the destination object name, static metadata item, and / or payload in the PDU. The recipient of the PDU can use this signature to verify the specified relationship (eg, whether the content is from a trusted publisher). Nonce field 480 may comprise a random number and can be used to prevent message replay attacks. Using this field, the receiving router can track received PDUs and detect situations where the same PDU is received multiple times, which may indicate a replay attack. The receiving router may discard the replayed (or retransmitted) PDU (s). Signature field 570 and nonce field 580 may be configured similarly to signature field 470 and nonce field 480, respectively.

  The meta data array 490 may be a list of name-based pointers, such as context-based parameters, arithmetic functions, or web links to arithmetic functions. The meta data array 490 may be used to supervise / direct content transfer, access, storage operations, security, and / or specified service processing operations. The self-certified alias value or field 491 in the meta data list or array 490 may be a public key or public key hash from a content publisher. When the requester sends an interest, the alias in this field may be sent in the interest PDU. If a data PDU is returned in response, the data PDU may also carry an alias. The content router can verify whether the alias matches between the interest PDU and the data PDU to verify the issuer's source or origin. Returned data PDUs with non-matching aliases can be discarded because such PDUs may come from unauthorized issuers.

  The device type value 492 in the interest PDU may indicate the type of request object (eg, iPhone® or iPad®). The GPS field 493 may indicate the geographical location (eg, coordinates) of the requester (user device or application). The selector field 494 indicates that the receiving content router performs one or more designated functions before the content is returned to the matched interest (eg, when the data PDU is stored in the local cache). Service function pointers may be provided that may be enabled. The secured community ID can be used in interest and data PDUs to authenticate access control policies. The meta data array 590, the self-certified alias value or field 591, the device type value or field 592, the GPS value or field 593, the selector value or field 594, and other values or fields 595 of the data PDU format 500 are: It may be configured similar to their corresponding fields in the interest PDU format 400.

  In one embodiment, when two content routers, such as content router 301, establish adjacency, the routers need to check whether the checksum value needs to support reliable data transmission, eg, in content layer interaction. You can negotiate. Based on the application type, the user or terminal device may assign a source object name to build an interest PDU as described above. For example, when the application is a voice application, the source object name may be carried in the PDU. Otherwise, if the application is, for example, downloading YouTube video, the video name (eg, URI) may be used as the destination name. A message type flag may be set accordingly (either interest or data). The TTL may be set either by the terminal device or by the first content router to which the device is connected. For example, if the interest is for a future event, the TTL may indicate that the interest is a persistent interest to wait for an upcoming event. In the data PDU, a signature can be appropriately generated as described above. The transfer type can be set accordingly. At least some meta data array fields may be carried in the PDU. For example, in an interest PDU, a secured community ID may be used for access control. Self-certified aliases may also be used for source verification. For example, after the remaining fields in the PDU are set, a checksum may be calculated (if necessary) and then the PDU may be sent to the first content router.

  When the content router receives an interest with a destination object name, the router may verify the checksum in the interest PDU. Therefore, if a damaged packet is detected, it can be discarded. The router can then check the transfer mode. If the transfer mode corresponds to a priority object, the transfer operation can be processed as fast path (or priority mode) as described above. The forwarding engine (FE) of the content router can examine the corresponding FIB to determine to which next hop interface (s) the packet can be forwarded. In this case, the TTL (eg, the number of hops) can be reduced by one unit. If the TTL is reduced to about 0, the PDU can be discarded. If no interest match is found in the FIB based on policy, the packet can be discarded, sent to all egress interfaces (eg, anycast or flooded), or sent to the default gateway router. If the transfer mode corresponds to non-priority, the transfer operation can be processed in a slow pass (or non-priority mode). In this case, if a match is found in the destination object name in the local cache, the content can be sent back. Non-sharable applications or mobility agents can temporarily set non-priority mode (using PDUs) to enable content caching and support seamless mobility. If not, even if the per-name state of the PIT is updated, for example by creating a new entry under the same name state as previously established or by queuing the number of ingress interfaces Good.

  TTL and metadata received within the PDU may be stored within the PIT. A local timer may be used to reduce TTL. When the TTL is dropped to about 0, the corresponding interest can be deleted from the PIT. After the PIT operation, the FE can examine the FIB to determine where the packet can be forwarded. Since the content router may change some components of the PDU (eg, TTL) before sending the packet, the checksum can be recalculated. After a PDU destination object is found in the FIB that may be a second content router or issuer device, a data PDU may be generated as described above. Used by TTL to prevent forwarding loops (in priority mode) or to define how long content can exist in the local cache of the network (in non-priority mode) based on transfer type Can be done. Metadata in the PDU header can be used to support related services. For example, the issuer may define a secured community ID to determine which interests may consume the data. The issuer may also associate a self-certified alias to allow the content router to verify the content source.

  When a data PDU is received, the checksum of the PDU can be verified and the router's FE can check the transfer mode indicated in the PDU. Similar to interest PDUs, forwarding operations can also be processed as fast path or slow path. In slow or non-priority mode, the PDU payload can be replicated in the local cache and processed based on the associated metadata. For example, the content router may determine that only interests with a matched secured community ID or alias can receive data PDUs returned to the requester. Thus, if the alias carried in the data PDU does not match any interest alias in the PIT, the PDU may be discarded (eg, the data PDU may have been sent from an unauthorized issuer). For authentic data PDUs, the PIT can be updated (according to the information in the data PDU) and the corresponding content data is distributed to all or multiple requesters based on the state by name from the PIT. be able to.

  A scheme similar to that described above for receiving and transferring interest and corresponding content data may be used to support push event notification operations. In a push event notification operating scenario, instead of pulling event data by sending an interest, the subscriber may enter one or more event prefixes of interest (eg, via a content routing protocol). Alternatively, data can be input to the FIB of all routers. Thus, one or more routers can configure an event prefix for the router's FIB. The event issuer can then use the event prefix as part of the destination object name and use metadata to indicate which router (s) can store the event. . For example, a transient event can be expressed as a data PDU and can be prioritized when an issuer pushes an event towards a subscriber. The event can be sent to an access router to which the device can be connected. During the distribution process, FEs on one or more routers can forward event data using the associated FIB. In this case, TTL (in the PDU) can be used to break or prevent the forwarding loop. Based on the metadata, the event can be pushed to the designated subscriber (s).

  FIG. 6 illustrates one embodiment of a simulation topology 600 for experimental simulation used to analyze ICN dual mode transfer plane operation 300. The simulation is used to compare the efficiency obtained by operating the CCN in dual mode. The simulation topology 600 can be found at http://abilene.com, which is incorporated herein by reference. internet2. It corresponds to the Internet 2 Abilin topology described in edu /. The simulation topology 600 is configured using an NS3-DCE environment that allows simulation analysis using real world protocol implementations such as CCNx. The NS3-DCE environment is an M.I. As described by Lacage in the November 2010 the University of Nice-Sophia Antipolis in the Doctoral Dissertation entitled “Outils decomposition pour la research en resux”, which is incorporated herein by reference. The ccnx-0.4.0 release is used for this simulation. Further details regarding this simulation can be found in Huawei entitled “Supporting Dual-Mode Forwarding in Content Centric Network”, which is hereby incorporated by reference in its entirety by Ravishankar Ravindran et al. It is described in in-house newsletters (Huawei Research Center, Santa Clara, California) (Ravindran et al.).

  The simulation topology 600 includes a plurality of interconnect nodes (eg, content routers) labeled 0-11. The node hosts conversational applications and content sharing (or content distribution) applications as shown in FIG. The traffic considered for analysis is a combination of content sharing traffic (for content sharing applications) and voice conversation traffic (for conversational applications). Interest routing is performed according to the shortest path priority logic.

  The content sharing application presents a model for traffic due to content sharing between users. The simulation topology 600 includes a node 11 that is configured as a repository node for shareable content. The node 11 is associated with a repository (repo) 610 for storing shared content. As described in detail by Ravindran et al., The repository 610 is initialized with 2000 content objects, and the geometric average size is 100 chunks. The content popularity is obtained by a zip distribution using an index parameter of 2, and the number K of popularity classes is set to 100. In order to keep the simulation time within practical limits, these parameters are A technical report entitled “Modeling data transfer in content central networking” (http: //perso.rd.francetelecom.), Which is hereby incorporated by reference by Carofiglio et al. fr / muscariello / report-itc-transport.pdf, 2011). In simulation topology 600, nodes 1, 5, 7, and 9 are selected to generate a request for shared content. The file sharing application is based on the ccndsendchunks and cnccatchunks2 utilities included in the CCNx release. cnccatchunks2 is operated with a window size of 1.

  A conversational application simulates point-to-point streaming conversational content. As described in detail by Ravindran et al., The application is modeled as a constant bit rate voice application with a packet generation rate of 50 packets / second (s) and a voice payload of 160 bytes (B). A new CCNx utility has been developed for this purpose. This utility implements a two-way voice session where interest and data responses are generated at the same rate. Referring to simulation topology 600, nodes 0, 2, 4, and 8 have been selected to generate conversational content traffic. In the default (or priority) mode, the end of the voice packet is set to 1 s or 5 s depending on the simulation scenario, and in the dual mode the voice packet becomes significantly obsolete when transferred.

  In order to compare the efficiency of priority and non-priority transfer modes or schemes, multiple performance metrics are collected from the simulation. Performance criteria include maximum CS size, maximum PIT size, cache hit rate, error index, and average round trip time (RTT). RTT is the response time per chunk for the application and is measured from the time the interest is issued to the time the data response is received. FIG. 7 shows a relationship 700 between the maximum CS size and the voice call rate obtained from simulation results or output values (parameters). The result shows that links (2 → 1), (5 → 2), (8 → 5) connecting nodes 2, 5, and 8 have the highest link utilization due to the selected load and interest routing logic. Correspond to nodes 2, 5, and 8 when having.

  The various curves in relationship 700 compare the maximum CS size performance for various loads under the two transfer modes. In default or non-priority mode, the maximum CS size increases as the rate of voice calls increases. With increased call rate, more calls can be active per unit time, so more voice content can be cached in the CS, which can increase CS utilization at both edge routers and transit routers Therefore, it is predicted that this will happen. The CS size depends on the proportion of incoming interest, so that nodes 5 and 8 may have a larger CS than node 2. In dual mode, voice data response packets can bypass CS processing, which may leave no packet memory in the edge or transit router. This is represented in FIG. 7, where the CS cache size is only associated with the data response originating from the content sharing application. As a result, the CS size remains substantially the same as the voice call rate increases.

  FIG. 8 shows a relationship 800 between the maximum PIT size and the voice call rate resulting from the simulation results to analyze the efficiency obtained for the maximum PIT size. The maximum PIT size behavior correlates with that of the maximum CS size for both transfer modes. Results are presented for nodes 2, 5, and 8. Relation 800 shows that as the voice call rate increases, the PIT size increases proportionally in the default case, but remains substantially unaffected in the dual mode. This may be due to the fact that voice interests marked as preferred receive high speed transfers using FIB that bypass PIT processing. As with the CS case, the reason for the difference in PIT sizes for the three nodes may be due to the interest arrival pattern and the interest routing logic in the network.

  FIG. 9 shows a relationship 900 between the round trip time and the class id obtained from the simulation results. Relationship 900 shows the average RTT performance for content sharing applications that use both transfer modes. In both cases, the class popularity decreases and the probability of content error increases, so the RTT performance increases with increasing class id. Compared with the case of dual mode transfer, the default can improve the RTT because the cache hit rate is improved in the case of dual mode transfer. This may be because dual-mode transfer eliminates (or significantly reduces) contention for CS resources that benefit content sharing applications, resulting in better hit rates and RTT.

  FIG. 10 shows a relationship 1000 between the round trip time and the voice call request rate obtained from the results of the simulation. Relation 1000 shows the RTT performance of the voice application for the two transfer modes. The results are presented for node 0 having a voice session with nodes 2, 4, and 8. The difference in the average RTT of the node pairs (0,2), (0,4) and (0,8) can be attributed to the increased number of hops and increased utilization of intra-route transit links. . Specifically, for a single CCN node, the interest and corresponding data response is observed to be in the range of 4-5 milliseconds (ms). The simulation setup includes a delay of about 2 milliseconds (ms) per link, and the overhead factors resulting from the simulation setup can reasonably explain the RTT observation. Comparing the default to dual mode, the voice application may not show improvement. It can be seen that the dual mode is as good as or slightly worse than the default CCN. This observation can be attributed to CCNx implementing CS, PITCS and FIB as one logical data structure. This can hinder the implementation of efficient fast path transfers for handling priority content without significantly changing the implementation of the protocol.

  FIG. 11 shows an embodiment of a hybrid mode transfer implementation 1100 that may be used in an ICN (eg, CCN). The hybrid mode transfer implementation 1100 can use a stateful mode implementation 1110 and a stateless mode implementation 1120. Stateful mode operation 1110 may use a single mode transfer operation (eg, single mode transfer plane operation 100) at the end of the ICN or at the access portion of the network (at the end or access router). Thus, stateful mode implementation 1110 can transfer interest and data at the edge or periphery of the network using PIT operations as described above. Using PIT operations at the edge or network access region may be useful in suppressing denial of service (DOS) and / or distributed DOS (DDOS) attacks at the edge of the network. The stateless mode implementation 1120 may use a dual mode forwarding operation, such as the dual mode forwarding plane operation 300, at the core or backbone of the ICN (at the core or backbone router). Thus, the stateless mode implementation 1120 can transfer interest and data regarding conversational traffic in the network core area using FIB without using PIT and CS, thereby sharing as described above PIT scalability issues can be solved for conversational traffic. By using both a stateful mode implementation 1110 (single mode or non-priority (default) forwarding) and a stateless mode implementation 1120 (dual mode or preferred forwarding), the hybrid mode forwarding implementation 1100 is advantageous for PIT operation. There may be a compromise or balance between solving (at the network edge) and solving the PIT scalability problem (at the network core).

  FIG. 12 shows one embodiment of a hybrid mode transfer scenario 1200 in which the hybrid mode transfer implementation 1100 can be used in a network system such as ICN or CCN. The network system may comprise multiple networks (eg, ICN), such as one or more tier 1 networks, one or more tiers, similar to the network in the single mode transfer scenario 200, for example. 2 networks and one or more tier 3 networks may be included. Tier 1 and Tier 2 networks may correspond to the backbone portion of the network system. Tier 3 networks may correspond to the access portion of the network system and may be coupled to multiple content users (consumers) or subscribers. The tier network may comprise a plurality of content routers that may comprise a corresponding PIT (with corresponding CS and FIB), such as content router 101.

  Scenario 1200 illustrates multiple content routers, eg, edge routers, across a network system. Routers may include, for example, backbone routers between tier 1 and tier 2 networks and between tier 2 and tier 3 networks, and the scalability of PIT can be an issue (forwarded non-sharable When the number of conversational traffic is significantly high). To overcome this problem, the backbone router can use dual mode forwarding operation 300 (or stateless mode implementation 1120) to forward interest and data traffic. Specifically, as described above, conversational traffic can be forwarded in priority mode (in the backbone portion of the network system) using FIB, and content distribution traffic uses CS, PIT, and FIB. Can be transferred in non-priority mode. Routers can also include, for example, access routers between tier 3 networks and users, and network system security, such as for DOS, DDOS, or replay attacks, can be an issue. As such, the access router can use a single mode forwarding operation 100 (or stateful mode implementation 1110) to forward interest and data traffic. Specifically, as described above, content traffic may be forwarded (in the access portion of the network system) in default or non-priority mode using CS, PIT, and FIB.

  FIG. 13 illustrates one embodiment of a dual mode transfer method 1300 that can be used to transfer interest and data for both non-sharable conversational traffic and shareable content distribution traffic in an ICN. The dual mode transfer method 1300 can be implemented by a content router or node in the ICN, such as the content router 301. Method 1300 may begin at block 1310, where an interest / data PDU may be received. For example, a content router may receive an interest PDU similar to PDU format 400, or may receive a data PDU similar to PDU format 500, eg, in response to a previously received interest. At block 1320, the method 1300 may determine (at the content router) whether the interest / data PDU is being transferred using a priority mode or a non-priority mode. For example, to determine if a PDU is flagged to indicate that the PDU is being forwarded using priority mode (for conversational traffic) or using non-priority mode, the content router may The transfer mode field 420 in the PDU format 400 or the transfer mode field 520 in the data PDU format 500 may be checked. If the traffic is non-sharable or conversational traffic, the priority mode may be set. Otherwise, a non-priority mode can be used. If the condition at block 1320 is true, method 1300 may proceed to block 1330. Otherwise, the method 1300 may proceed to block 1340.

  At block 1330, interest / data PDUs may be processed using FIB without CS and PIT, for example, as described above for the priority mode in dual mode transfer plane operation 300. Thereafter, the method 1300 may proceed to block 1350. At block 1340, the interest / data PDU may be processed using CS, PIT, and FIB, for example, as described above for the default non-priority mode in general single mode transfer plane operation 100. In this case, at least part of the content (or payload) of the received data PDU may be cached in the content router (eg, in the CS). At block 1350, the interest / data PDU may be forwarded to the next hop in the network, for example. Thereafter, the method 1300 may end.

  FIG. 14 illustrates one embodiment of a network unit 1400 that may be any device that transports and processes data over a network. For example, the network unit 1400 may correspond to the content router 301 or may be located in any node within the content router or ICN. Network unit 1400 may also be configured to implement or support the schemes and methods described above. The network unit 1400 may comprise one or more ingress ports or units 1410 coupled to a receiver (Rx) 1412 for receiving signals and frames / data from other network components. The network unit 1400 may comprise a content aware unit 1420 for determining to which network component the content should be transmitted. Content aware unit 1420 may be implemented using hardware, software, or both. Network unit 1400 may also include one or more egress ports or units 1430 that are coupled to a transmitter (Tx) 1432 for transmitting signals and frames / data to other network components. Receiver 1412, content-aware unit 1420, and transmitter 1432 also implement at least some of the methods and methods disclosed above, which may be based on hardware, software, or both. It may be configured as follows. The components of the network unit 1400 may be arranged as shown in FIG.

  The content aware unit 1420 may also include a programmable content transfer plane block 1428 and one or more storage blocks 1422 that may be coupled to the programmable content transfer plane block 1428. Programmable content transfer plane block 1428 may be configured to perform content transfer and processing functions, such as in the application layer or L3, where content is content name or prefix, and possibly content to network traffic. May be transferred based on other content-related information that maps to. Such mapping information may be maintained in one or more content tables (eg, CS, PIT, and FIB) in content aware unit 1420 or network unit 1400. Programmable content transfer plane block 1428 can interpret user requests for content and fetch content accordingly from, for example, a network or other content router based on metadata and / or content name (prefix); The content can be stored in storage block 1422, for example, temporarily. Programmable content transfer plane block 1428 can then transfer the cached content to the user. Programmable content transfer plane block 1428 may be implemented using software, hardware, or both, and may operate on the IP layer or L2.

  Further, the programmable content transfer plane block 1428 may implement the dual mode transfer method or the hybrid mode transfer method described above. For the hybrid mode transfer scheme, the programmable content transfer plane block 1428 can implement the dual mode transfer scheme (without using PIT) when the network unit 1400 is located in the backbone of the network. Can be implemented (using PIT) if is located in the access part of the network. Storage block 1422 may include a cache 1424 for temporarily storing content, such as content requested by a subscriber. In addition, the storage block 1422 may comprise a long-term storage device 1426 for storing content, such as content posted by publishers, for a relatively long time. For example, cache 1424 and long-term storage 1426 may include dynamic random access memory (DRAM), solid state drive (SSD), hard disk, or a combination thereof.

  The network component described above may be in any general purpose network component, such as a computer or network component that has sufficient processing power, memory resources, and network throughput capability to handle the necessary workload imposed on it. May be implemented. FIG. 15 illustrates a general general network component 1500 suitable for implementing one or more embodiments of the components disclosed herein. The network component 1500 includes a secondary storage device 1504, a read only memory (ROM) 1506, a memory device including a random access memory (RAM) 1508, an input / output (I / O) device 1510, and a network connection device 1512. It includes a communicating processor 1502 (sometimes referred to as a central processing unit or CPU). The processor 1502 may be implemented as one or more CPU chips, or may be part of one or more application specific integrated circuits (ASICs).

  Secondary storage device 1504 typically consists of one or more disk drives or tape drives, and is large enough for non-volatile storage of data and for RAM 1508 to hold all working data. If not, it is used as an overflow data storage device. Secondary storage 1504 may be used to store programs that are loaded into RAM 1508 when selected for execution. ROM 1506 is used to store instructions and possibly data read during program execution. ROM 1506 is generally a non-volatile memory device having a small storage capacity compared to the larger storage capacity of secondary storage device 1504. RAM 1508 is used to store volatile data, possibly to store instructions. Access to both ROM 1506 and RAM 1508 is generally faster than secondary storage device 1504.

At least one embodiment is disclosed, and variations, combinations, and / or modifications of the embodiment (s) and / or embodiment (s) made by those skilled in the art are disclosed. Features are within the scope of this disclosure. Alternative embodiments resulting from combining, integrating, and / or omitting features of embodiment (s) are also within the scope of this disclosure. Where a numerical range or limit is explicitly stated, such explicit range or limit includes repetitive ranges or limits of similar magnitude that fall within the explicitly stated range or limit (E.g., about 1 to about 10 includes 2, 3, 4, etc., and greater than 0.10 includes 0.11, 0.12, 0.13, etc.). For example, regardless of whether a numerical range having a lower limit R ₁ and an upper limit R _u is disclosed, any number falling within that range is specifically disclosed. In particular, the following numbers within the range are specifically disclosed. R = R ₁ + k × (R _u −R ₁ ). Where k is a variable ranging from 1 percent to 100 percent and increments by 1 percent. That is, k is 1 percent, 2 percent, 3 percent, 4 percent,. . . , 7 percent,. . . , 70 percent, 71 percent, 72 percent,. . . 95 percent, 96 percent, 97 percent, 98 percent, 99 percent, or 100 percent. Furthermore, any numerical range defined by two R numbers as defined above is also specifically disclosed. Where the term “optionally” is used for any element in a claim, this means that the element is required or alternatively that element is required. Both options are within the scope of the claims. When broader terms are used, such as “comprises”, “includes”, and “having”, this is consisted of, essentially composed of And should be understood as providing support for narrower terms such as substantially composed of. Accordingly, the scope of protection is not limited by the description set forth above, but is defined by the following claims, which include all equivalents of the subject matter of the claims. All claims are hereby incorporated into the specification as further disclosure, and the claims are embodiments (s) of the disclosure. A discussion of a cited reference in this disclosure, particularly any reference that has a publication date later than the priority date of the present application, is not an admission that it is prior art. The disclosures of all patents, patent applications, and publications cited in this disclosure are hereby incorporated by reference to the extent that they provide exemplary, procedural, or other details that aid this disclosure. Incorporated into the book.

  While several embodiments have been provided in the present disclosure, it is understood that the disclosed systems and methods can be embodied in many other specific forms without departing from the spirit or scope of the present disclosure. It should be. The embodiments of the present invention are to be regarded as illustrative and not restrictive, and are not intended to be limited to the details given herein. For example, various elements or components may be combined or integrated into another system, or certain features may be omitted or not implemented.

  In addition, techniques, systems, subsystems, and methods described and illustrated as individual or separate in various embodiments are not limited to other systems, modules, techniques, or methods without departing from the scope of this disclosure. It may be combined or integrated with the method. Other items illustrated or described as being coupled or directly coupled or communicating with each other may be any interface, device, or device, regardless of whether it is electrical, mechanical, or otherwise It may be coupled or communicated indirectly through an intermediate component. Other examples of modifications, substitutions, and alternatives will be apparent to those skilled in the art and may be made without departing from the spirit and scope disclosed herein.

[Cross-reference of related applications]
This application is filed by Guo Qing Wang et al. On September 1, 2011, “A Generalized Dual-Mode Data Forwarding Plan-Centric Network” for information-centric networks. Claiming priority based on US Provisional Patent Application No. 61 / 530,288, entitled “Generalized Dual Mode Data Transfer for Information Centric Networks,” filed February 9, 2012 by Guo Qiang Wang et al. Entitled "Plain (A Generalized Dual-Mode Data Forwarding Plane For Information-Centric Network)" Claims priority to U.S. Provisional Patent Application No. 13/369763. These patent documents are incorporated by reference in their entirety.

Claims (20)

A network system,
Includes content store (CS), pending interest table (PIT), forwarding information base (FIB), and multiple interfaces to receive interest from one or more users and data from one or more applications A content router for an information centric network (ICN) configured to receive and transfer using a dual mode data transfer plane via the plurality of interfaces;
A plurality of next hop nodes of the ICN coupled to the content router and configured to forward the interest and data to the content router via the plurality of interfaces;
The dual-mode forwarding plane uses the FIB without the CS and PIT for conversational traffic and forwards the interest and data using the CS, PIT, and FIB for content distribution traffic , Network system.   The conversational traffic is distinguished from the content distribution traffic using interest protocol data units (PDUs) and data PDUs, and the interest PDU and the received PDU are each for conversational traffic. The network system according to claim 1, further comprising a transfer mode indicator set to a priority mode or set to a non-priority mode for content distribution traffic.   The network system according to claim 2, wherein the data PDU is set by an application, and the interest PDU is set by a user.   The network system of claim 1, wherein the interest and data relating to conversational traffic is transferred without caching or storing content data in the content router.   The network system according to claim 1, wherein the content router is an edge router located in a backbone portion of the network system.   The network of claim 5, wherein at least some of the next hop nodes are located in the backbone portion and are configured to transfer interest and data using the dual mode data transfer plane. system.   At least some of the next hop nodes are coupled to the user in the access portion of the network system to transfer interest and data using the PIT for both conversational traffic and content distribution traffic. The network system according to claim 5, which is configured as follows. A network component,
An interest protocol data unit (PDU) indicating a transfer mode and a transmitter / receiver (transmitter / receiver) configured to receive and transfer data PDUs;
A content store (CS) for caching content, a pending interest table (PIT) for tracking pending requests for content, and a forwarding information base (FIB) for associating content with one or more ports A memory provided;
Transferring the interest PDU and the data PDU relating to shareable content traffic in the non-priority mode using the PIT, and the interest PDU relating to non-shareable content traffic in the priority mode using the FIB without using the PIT, and the A network component comprising: a processor configured to transfer data PDUs.   The interest PDU includes a message type indicating the interest PDU, a transfer mode indicator set to a priority mode for non-sharable content traffic, or a non-priority mode for shareable content traffic, and a request. A source object name indicating an object, a destination object name indicating a requested object, a checksum value used to verify the integrity of the interest PDU, and a validity period (TTL) that determines the duration of the interest PDU A list of indicators, signatures used to verify the relationship between the destination object name and the interest PDU, nonces used to prevent replay attacks, and context-based parameters or arithmetic functions Meta-denotes It comprises a data array, the interest payload network element of claim 8.   The meta data array includes at least one self-certified alias used to authenticate a match between the data PDU and the interest PDU, a device type indicating the type of the request object, and the request A global positioning system (GPS) indicator indicating the geographical location of the object, a selector that enables the content router to perform one or more designated functions associated with the data PDU, and an access control policy 10. A network component according to claim 9, comprising: another value including a secured community identifier (ID) used to authenticate the.   The TTL indicator is valid to prevent forwarding loops in priority mode for non-sharable content traffic or how long the interest PDU is in non-priority mode for sharable content traffic in the PIT, CS, or both The TTL indicator is set as the maximum allowed hop count in priority mode or as a unit of time (TOD) in non-priority mode. Network components described in.   The non-sharable content traffic is routed using the source object name and the destination object name in preferred mode, and the sharable content traffic is forwarded using the destination object name in non-preferred forwarding mode. Item 10. The network component according to Item 9.   The network component according to claim 9, wherein the transfer mode indicator is temporarily set to a non-priority mode by a non-sharable application to enable content caching and to support seamless mobility of mobile devices.   To allow a seamless anchor point to cache data for the non-shareable application, and after the mobile device is re-anchored to a new point of attachment, the non-shareable application 14. The network element according to claim 13, wherein both the source object name and the destination object name are used for mobility control to enable searching the cached data.   The network component of claim 9, wherein the source object name and the destination object name are structured names having a hierarchical format.   The network component of claim 9, wherein the source object name and the destination object name are flat names having a digital format.   The data PDU includes a message type, a transfer mode indicator, a source object name, a destination object name, a checksum value, a TTL indicator, a signature, and a meta that are configured substantially similar to the corresponding components of the interest PDU. The network component of claim 9, comprising a data array and a data payload. A method implemented by a network component for transferring interest and data traffic in an information centric network (ICN) comprising:
Receiving content interest or data via a receiver;
Transferring the content interest or data via a transmitter using a pending interest table (PIT) if the content or interest data corresponds to content distribution traffic;
Transferring the content interest or data via the transmitter using a transfer information base (FIB) without using the PIT if the content or interest data corresponds to conversational traffic. Method.   19. The conversational traffic is routed using the FIB with a plurality of application prefixes issued by a plurality of requesters, and the content distribution traffic is forwarded using the PIT lookup. The method described in 1. Transferring the content or interest data corresponding to conversational traffic using the FIB without using the PIT if the network component is located in the backbone portion of the ICN;
19. The method of claim 18, further comprising: transferring the content or interest data corresponding to conversational traffic using the PIT if the network component is located within the access portion of the ICN.