WO2017070545A1 - Software-defined network enhancements enabling programmable information centric networking in edge networks - Google Patents

Abstract

Methods and apparatuses for metadata based routing and establishing weak sessions in a content routing network are described herein. A client application, ingress content router, or a serving content router may enter a default flow entry in a flow table to catch Information Centric Networking (ICN) requests. A local application may create a socket to listen on a port. When a packet of an unknown message is received, the packet may be matched to the default flow entry, and an indication may be sent to the local application that the packet was received. The local application may then determine whether the metadata in the received packet enables a routing decision, which may include determining whether enough payload of the message was received. If the routing decision is enabled, the appropriate routing decision may be determined based on metadata in the received packet, and the packet may then be routed.

Description

SOFTWARE-DEFINED NETWORK ENHANCEMENTS ENABLING PROGRAMMABLE INFORMATION CENTRIC NETWORKING IN EDGE

NETWORKS

CROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application

Serial No. 62/245,681 filed October 23, 2015, the contents of which are hereby incorporated by reference herein.

BACKGROUND

[0002] Information Centric Networking (ICN) is a networking paradigm where the primary abstraction at the network level is content name, rather than an end point identity. ICN may aim to optimize content delivery and may use any available context information in order to optimize content delivery for cost, expediency, or any suitable combination of criteria. This context sensitivity may lead to a new challenge: as illustrated by the large number of ICN architectures defined today (PURSUIT, CCN, Mobility First, etc.), it is unlikely that a one-size- fits-all technique would be optimal in all situations. One approach may be to therefore enable a number of ICN solutions to exist in different contexts, possibly in the same physical network.

[0003] The emergence of Edge Cloud technologies may leverage Software

Defined Networking (SDN) and cloud technologies to enable deployment of applications on clouds at the edge of the network. Mobile Edge Computing and Fog Computing concepts each may aim to enable edge clouds. The ETSI Mobile Edge Computing (MEC) initiative may enable virtual computing, storage, and network resources to be made available to applications on MEC servers located in a mobile operator's network, for example, at base stations. Research initiatives may aim to develop similar sharing of edge device resources for the benefit of applications serving Internet of Things (IoT) devices.

[0004] In view of the confluence of these trends, it may be desirable to develop a content-aware platform for edge clouds. SUMMARY

[0005] Methods and apparatuses for metadata based routing and establishing weak sessions in a content routing network are described herein. A client application, ingress content router, or a serving content router may enter a default flow entry in a flow table to catch Information Centric Networking (ICN) requests. A local application may create a socket to listen on a port. When a packet of an unknown message is received, the packet may be matched to the default flow entry, and an indication may be sent to the local application that the packet was received. The local application may then determine whether the metadata in the received packet enables a routing decision, which may include determining whether enough payload of the message was received. If the routing decision is enabled, the appropriate routing decision may be determined based on metadata in the received packet, and the packet may then be routed.

[0006] In another embodiment, a client application, ingress content router, or a serving content router, may determine whether a weak session should be established for a plurality of messages. The serving content router may determine a session identifier for the weak session. The serving content router may transmit, to the client application or ingress content router, the session ID. Each message or packet transmitted during the weak session may include the session ID in a header or metadata field. One or more intermediate content routers may determine whether to locally process or to forward the message or packet based on the session ID.

BRIEF DESCRIPTION OF THE DRAWINGS

[0007] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings wherein:

[0008] FIG. 1A is a system diagram of an example communications system in which one or more disclosed embodiments may be implemented; [0009] FIG. IB is a system diagram of an example wireless transmit/receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A;

[0010] FIG. 1C is a system diagram of an example radio access network and an example core network that may be used within the communications system illustrated in FIG. 1A;

[0011] FIG. 2 is a diagram of an example high-level architecture view of local content services;

[0012] FIG. 3 is a diagram of an example identifying where actors and components may reside within the system architecture of local content services;

[0013] FIG. 4 is a diagram of an example of the position of a generic

Content Networking Substrate (CNS) in an overall system;

[0014] FIG. 5 is an example of an overall view of a CNS System

Architecture;

[0015] FIG. 6 is another example of an overall view of a CNS System

Architecture;

[0016] FIG. 7 is a diagram of an example high level structure of a content object;

[0017] FIG. 8 is a diagram of an example internal representation of an object;

[0018] FIG. 9 is a diagram of an example CNS Architecture Stack;

[0019] FIG. 10 is a diagram of an example CNS intra-node architecture;

[0020] FIG. 11 is a flow diagram of an example life cycle of internal and backend objects;

[0021] FIG. 12 is a sequence diagram of an example processing of tasks and methods;

[0022] FIG. 13 is a flow diagram of an example policy task call;

[0023] FIG. 14 is a flow diagram of an example local content network system implementation using GET and POST to retrieve and publish local content; [0024] FIG. 15 is a flow diagram of another example local content network system implementation using the task:FETCH to retrieve an object from the network and its inner methods/tasks;

[0025] FIG. 16 is a flow diagram of an example procedure for implementing task#FETCH;

[0026] FIG. 17 is a flow diagram of yet another example local content network system implementation using various methods/tasks;

[0027] FIG. 18 is an example diagram of the packet encodings and the packet and message or object structure;

[0028] FIG. 19 is a diagram of an example flow of data in an SDN

Forwarding Element (FE) within a content router that enables optimized metadata-aware content networking (SDN-Enabled Metadata-Aware Routing);

[0029] FIG. 20 is a flow diagram of an example process for enabling optimized metadata-aware content networking (SDN-Enabled Metadata-Aware Routing);

[0030] FIG. 21 is a flow diagram of an example process for enabling a weak session;

[0031] FIG. 22 is a flow diagram of an example process for enabling a weak session mechanism inside the CNS Network; and

[0032] FIG. 23 is a flow diagram of an example process for establishing a weak session.

DETAILED DESCRIPTION

[0033] FIG. 1A is a diagram of an example communications system 100 in which one or more disclosed embodiments may be implemented. The communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), and the like.

[0034] As shown in FIG. 1A, the communications system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d may be configured to transmit and/or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, consumer electronics, and the like.

[0035] The communications systems 100 may also include a base station

114a and a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the core network 106, the Internet 110, and/or the other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.

[0036] The base station 114a may be part of the RAN 104, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a and/or the base station 114b may be configured to transmit and/or receive wireless signals within a particular geographic region, which may be referred to as a cell (not shown). The cell may further be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., one for each sector of the cell. In another embodiment, the base station 114a may employ multiple -input multiple-output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.

[0037] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).

[0038] More specifically, as noted above, the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 104 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may estabhsh the air interface 116 using wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink Packet Access (HSDPA) and/or High-Speed Uplink Packet Access (HSUPA).

[0039] In another embodiment, the base station 114a and the WTRUs

102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 116 using Long Term Evolution (LTE) and/or LTE-Advanced (LTE-A).

[0040] In other embodiments, the base station 114a and the WTRUs 102a,

102b, 102c may implement radio technologies such as IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.

[0041] The base station 114b in FIG. 1A may be a wireless router, Home

Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or femtocell. As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the core network 106.

[0042] The RAN 104 may be in communication with the core network 106, which may be any type of network configured to provide voice, data, applications, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. For example, the core network 106 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and/or perform high-level security functions, such as user authentication. Although not shown in FIG. 1A, it will be appreciated that the RAN 104 and/or the core network 106 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104, which may be utilizing an E-UTRA radio technology, the core network 106 may also be in communication with another RAN (not shown) employing a GSM radio technology.

[0043] The core network 106 may also serve as a gateway for the WTRUs

102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and/or other networks 112. The PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and the internet protocol (IP) in the TCP/IP internet protocol suite. The networks 112 may include wired or wireless communications networks owned and/or operated by other service providers. For example, the networks 112 may include another core network connected to one or more RANs, which may employ the same RAT as the RAN 104 or a different RAT.

[0044] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities, i.e., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers, transmitters, or receivers for communicating with different wireless networks over different wireless links. For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[0045] FIG. IB is a system diagram of an example WTRU 102. As shown in FIG. IB, the WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display /touchp ad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It will be appreciated that the WTRU 102 may include any subcombination of the foregoing elements while remaining consistent with an embodiment. [0046] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit/receive element 122. While FIG. IB depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0047] The transmit/receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over the air interface 116. For example, in one embodiment, the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals. In another embodiment, the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit/receive element 122 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.

[0048] In addition, although the transmit/receive element 122 is depicted in

FIG. IB as a single element, the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116. [0049] The transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 122 and to demodulate the signals that are received by the transmit/receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabhng the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.11, for example.

[0050] The processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker/microphone 124, the keypad 126, and/or the display /touchp ad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display /touchp ad 128. In addition, the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132. The non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[0051] The processor 118 may receive power from the power source 134, and may be configured to distribute and/or control the power to the other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.

[0052] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 116 from a base station (e.g., base stations 114a, 114b) and/or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.

[0053] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.

[0054] FIG. 1C is a system diagram of the RAN 104 and the core network

106 according to an embodiment. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the core network 106.

[0055] The RAN 104 may include eNodeBs (which may also be referred to as eNBs) 140a, 140b, 140c, though it will be appreciated that the RAN 104 may include any number of eNodeBs while remaining consistent with an embodiment. The eNodeBs 140a, 140b, 140c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the eNode-Bs 140a, 140b, 140c may implement MIMO technology. Thus, the eNodeB 140a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a. [0056] Each of the eNodeBs 140a, 140b, 140c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink and/or downlink, and the like. As shown in FIG. 1C, the eNodeBs 140a, 140b, 140c may communicate with one another over an X2 interface.

[0057] The core network 106 shown in FIG. 1C may include a mobility management entity gateway (MME) 142, a serving gateway 144, and a packet data network (PDN) gateway 146. While each of the foregoing elements are depicted as part of the core network 106, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

[0058] The MME 142 may be connected to each of the eNodeBs 140a, 140b,

140c in the RAN 104 via an Si interface and may serve as a control node. For example, the MME 142 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation/deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 142 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.

[0059] The serving gateway 144 may be connected to each of the eNodeBs

140a, 140b, 140c in the RAN 104 via the Si interface. The serving gateway 144 may generally route and forward user data packets to/from the WTRUs 102a, 102b, 102c. The serving gateway 144 may also perform other functions, such as anchoring user planes during inter-eNodeB handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.

[0060] The serving gateway 144 may also be connected to the PDN gateway

146, which may provide the WTRUs 102a, 102b, 102c with access to packet- switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. [0061] The core network 106 may facilitate communications with other networks. For example, the core network 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the core network 106 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the core network 106 and the PSTN 108. In addition, the core network 106 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.

[0062] Other network 112 may further be connected to an IEEE 802.11 based wireless local area network (WLAN) 160. The WLAN 160 may include an access router 165. The access router may contain gateway functionality. The access router 165 may be in communication with a plurality of access points (APs) 170a, 170b. The communication between access router 165 and APs 170a, 170b may be via wired Ethernet (IEEE 802.3 standards), or any type of wireless communication protocol. AP 170a is in wireless communication over an air interface with WTRU 102d.

[0063] The methods and apparatuses discussed herein may include SDN enhancements which may enable efficient transport and processing of data objects. A WTRU as used in the embodiments described herein and the associated Figures may include a UE; STA; mobile devices such as smart phones; client devices and devices running a client application as described herein; any end devices such as sensors, actuators, TV, and the like; or any other device configured to operate in a wireless communication system.

[0064] A Content Network Substrate (CNS) architecture is described herein. The CNS architecture may apply to an example use case that includes a local content service. Such a service may allow co-located users to enhance their experience through instantaneous (or substantially instantaneous or substantially real-time) sharing of content generated by other users in a venue, which may include the service provider itself. An example of such a localized shared experience may include a sports game, a mall, or a city tour.

[0065] Local content services may be consistent with classes of apphcations which involve a number of local publishers (e.g., crowd sensing) and/or consumers (e.g., video delivery and caching), which both may be major fields of apphcation envisioned for Edge Computing. Local content services therefore may be well suited for studying the need for future content apphcations.

[0066] Turning to a sports game use case, sports fans may purchase tickets to a sport event held in a stadium, for example. During the event, they may share content that they produce with each other. Such content may include photos, videos, as well as audio and text commentary, and the like, which may be typically produced using consumer-grade commercially available devices. While some of this content may be made available to the world outside of the sport stadium, making it available to others at the stadium is a primary concern.

[0067] Example operations which may need to be enabled may include permitting any authorized person to publish a content object (e.g., a photo); notifying end users when some content becomes available; and/or enabhng end users to be able to get a content object as long as they are authorized to get it. To enable these or other operations, end users such as WTRUs (e.g. smartphones or other devices as identified above) may use either a browser or a native application, or other suitable client apphcation.

[0068] Besides end users, other major actors may include Application

Providers and Content Network Providers. An Application Provider may provide the client application referred to herein and may be for example a third party, such as TWITTER or INSTAGRAM. A Content Network Provider typically may be the venue network operator or an access network operator. The Content Network Provider may make the operations discussed above (localized publication and consumption, notification, etc.) available to client apphcations (which may also be referred to herein as clients or application clients) running on end user devices or to application services running outside of the Content Network. The Content Network Provider may also provide caching capability, and network access.

[0069] From a business standpoint, the Content Network Provider may extract service fees from the Application Provider for Content-Management-as-a- Service. The Content Network Provider may add value in terms of being able to meet latency and throughput requirements that are burdensome or not possible with traditional cloud based solutions. However, the Application Providers may create services for which they may charge more money (or which may provide more opportunities for revenues from advertisement).

[0070] FIG. 2 is a diagram of an example high-level architecture view of local content services 200 in accordance with one embodiment, which may be used in combination with any of the embodiments described herein. As shown in the example of FIG. 2, there is a WTRU publisher 210, a WTRU consumer 211, a server 213, and an application service provider 214. The numbered arrows are an example sequence of steps, which describe the relationships between the entities. A WTRU may fulfill the role of either a publisher or consumer of content or may fill both roles over time. The WTRU publisher 210 may publish content 201 to the content network via the CNS System 212, which may then disseminate the content 202. Content may be advertised 203 by the application service provider 214 and content may be retrieved 204 by the WTRU consumer 211.

[0071] In an alternative use case, the application service provider 214 itself may be the publisher for all or some content. In this case, the server 213 may interact with the content network 205, as a complement with, or instead of the WTRU publisher 210.

[0072] FIG. 3 is a diagram of an example identifying where actors and components may reside within the system architecture of local content services 300 in accordance with another embodiment, which may be used in combination with any of the embodiments described herein. The end user 301, WTRU 302, and Content Network (CN) 303 may be typically located in the venue (e.g., a stadium, a mall, etc.). Some control function of the Content Network System 304 may reside in the Internet/cloud 305 or in the venue 306. A Sharing Application 305 may be able to provide features including local publication and retrieval (publication may be immediate, i.e., "push content" in the system, or it may be deferred, i.e., "pull content" where the system fetches the content from the device only when needed) subject to access control and may enable subscription-based advertisement of published content to users. The Sharing Application 308 may include a Sharing Application Service 307.

[0073] The CN 303 used by the Sharing Application 305 may include an interface with the Application Provider both on the client side and the network side. Some of the major features offered by the CN 303 may include offering a service application program interface (API) to Application Providers, (e.g., to Application Components on Clients or Servers). The CN 303 may provide functions including but not limited to the following:

[0074] (1) Reserving network resources (e.g., storage space, certain throughput, etc.).

[0075] (2) Ingesting content from publishers and disseminating it to local consumers;

[0076] (3) Including additional in-network processing on content (e.g., virus scanning, image processing, etc.).

[0077] (4) Supporting access control;

[0078] (5) Enabling association of metadata with content and enabling searches based on metadata.

[0079] (6) Implementing a policy framework that enables processing content in different ways depending on context/metadata information (e.g., application needs, local/temporal context, context from publisher and consumers). An example is a retention policy that would keep longer content based on popularity, and even upload in the cloud very popular content).

[0080] (7) Enabling the linking of content objects together using metadata

(e.g., to associate a thumbnail to an image). [0081] These exemplary general requirements may be implemented using a range of technologies, including ICN architectures such as PURSUIT, CCN, MOBILITY FIRST, etc. Such technologies may be at an experimental stage. Accordingly, implementing one such technology rather the others for deployment in a network should be done in a manner that can be reversed. Also, it may be appropriate to implement several parallel deployments, e.g., for evaluation purposes, or possibly for long term parallel usage, assuming that different ICN architectures may be found appropriate for different types of applications.

[0082] Software Defined Networking (SDN) was developed to enable innovation in the domain of networking. It may be appropriate to develop a CNS to enable innovation in the domain of content networking. A CNS may implement those characteristics that are shared by content networks, e.g., in order to enable concurrent rapid deployment and customization of ICN networks, and/or to facilitate interoperation between content networks and/or ICN networks if necessary.

[0083] The following terms are used herein:

[0084] Content Network (CN): a network dealing with dissemination of content (e.g., World Wide Web and ICN networks).

[0085] Information Centric Networking (ICN): a network paradigm where content name is a primary abstraction at the network level, aiming to optimize dissemination of content.

[0086] Content Network Substrate (CNS): a programmable platform which may run on content network nodes, which may provide support for developing Content Networks and distributed Content-Centric Applications.

[0087] Content Object or Object: a piece of data which may include content

(e.g., the encoding of a movie), a container, a policy, etc.

[0088] Content Router (CR): a network node that may forward, store and/or process content objects. [0089] Data Object: a particular type of object. A data object may hold information useful to third parties like end users or Application Providers, such as a multimedia file.

[0090] Object Types: categories of Objects, e.g., Container Objects, Data

Objects, Plugin Objects, etc.

[0091] Authoritative: a cache authoritative for a given object is a cache known to be holding a long-term copy of the object. There may be more than one authoritative cache for an object, e.g., for reliability.

[0092] RPC: Remote Procedure Call.

[0093] PaaS: Platform as a Service.

[0094] Subsystem: as used herein in some contexts, a subsystem may include a component of the CNS, which may offer a core function, such as storage or communication.

[0095] Workflow Subsystem: a subsystem that may be used to orchestrate operations involving subsystems and plugins.

[0096] Task: objects of type TASK may be loaded and run by the Workflow

Subsystem. A task may hold a sequence of operations. A task may be run on a target object.

[0097] Policy Task: a task that may be called by a subsystem or plugin at a specific stage, e.g. to check whether an action is authorized before proceeding. In terms of its implementation it otherwise may be a regular task. The execution of the subsystem or plugin may be affected by certain side effects of the policy task, e.g., return code or certain metadata values set by the policy task.

[0098] Plugin: objects of type Plugin may be loaded and run by the Plugin

Support Subsystem and may implement an API that may be accessed by the Workflow Subsystem through the Plugin Support Subsystem. Plugins may be used to implement application components and/or non-core CNS components.

[0099] Method: a function part of the programmatic API which may be provided by a plugin or by a subsystem. Methods may be called by tasks. Methods may implement detailed behavior (e.g., storage on disk, inter-node communication, caching algorithms, etc.). As with tasks, methods may be run on a target object.

Metadata Properties: may include individual properties of an object, e.g., content name, age, title, etc.

[0100] For convenience, a naming convention may be used herein for certain values, unless otherwise evident from the context. In general, the model naming convention appears as <type>#<NAME>. This naming convention may be used, for example, to avoid using a programming language type system, as those values may be carried between processes and nodes. The naming convention may also provide convenient navigation through code and documentation. Following this model, a task named "fetch" may be named task#FETCH; an object type "container" may be named type#CONTAINER; a method "name object" may be named method#NAME_OBJECT; a plugin "publication and retrieval" may be named plugin#PUB_RETRIEVAL; a subsystem "workflow" may be named subsystem#WORKFLOW; a return code of a method or task may be named code#ERROR, code#DONE, etc.

[0101] Further discussed herein are example architecture requirements for a CNS. ICN in Edge Networks may face a number of challenges. For example, a first challenge may be the presence of many flavors of ICN, which may need to be deployed in a same domain and may need to interoperate with each other. Further, edge networks may offer limited platform resources. Edge networks, especially in small cells, may have limited and/or variable network resources, and may be built over heterogeneous platforms. Edge networks typically may provide lower physical security than Cloud networks.

[0102] However, ICN in Edge Networks may also benefit from a number of opportunities. For example, edge networks may be in close proximity to end users, which may enable new classes of network applications (e.g., tactile Internet). Edge networks may have a high density and may overlap, possibly making in-network resource pooling a viable option. [0103] The following table summarizes the possible impact of these challenges and opportunities on various architecture requirements for CNS:

communication inside the Content Networking

Substrate

• Use container technology (e.g. Docker) to

Security encapsulate plugins, therefore enabling isolation and limiting or resource consumption.

Close proximity to end

• Enable Access Points as front end nodes.

users

• Enable distributed computing through

High density and

intercommunication between plugins on the same overlap

or different node.

[0104] The following table summarizes the possible impact of the functional requirements of a Content Network, which were listed in the previous section, on various architecture requirements for CNS:

Functional Requirement Architecture Requirements for a Content of a Content Network Networking Substrate (CNS)

• Front end nodes enable uploading/downloading content objects to/from IP clients, under the control of

Ingestion and

application plugins Dissemination APIs

• CNS deals with efficiently storing, retrieving and communicating content objects

Support general content-

• Enable processing services (e.g. image based processing (i.e. not

processing) to run on the CNS platform only dissemination)

• Front end nodes provide service APIs to IP clients and dispatch calls to plugins

Service APIs

• Certain service APIs may require to be served from the same instance as part of a session.

• Front end nodes enforce access control rules

Access Control based on specifications from the application provider

Associate metadata with • Content and metadata are efficiently content associated when stored and communicated

• Plugins can be used to implement policies

Support policies

• Objects and their metadata can be passed to policy evaluation functions

• Metadata associated with content can

Linking content objects

include identifiers of other objects

[0105] Various requirements of a CNS may be derived from challenges of

ICN in Edge Networks and/or from functional requirements of a Content Network built over this substrate.

[0106] FIG. 4 is a diagram of an example of the position of a CNS in an overall system 400 in accordance with another embodiment, which may be used in combination with any of the embodiments described herein. As shown in FIG. 4, the end user (WTRU) 401 may access the application client 402 and application provider 403, which provide access to local content services using a particular flavor of ICN protocol and algorithms 404. An SDN interface may provide access to the generic CNS 406. Other specialized content networks 405 may also be accessed.

[0107] SDN may be more prevalent today in deploying new networks, as may enable evolution of such networks over time to match new requirements, without requiring additional hardware investment. SDN may therefore be considered a possible underlying technology over which a Content Networking Substrate may be deployed.

[0108] One possible challenge for deploying CNS over SDN may be a difference in control granularity. For example, SDN may operate on a per-packet basis, while CNS (and more generally content and service layer processing) may operate on a per-message basis.

[0109] ICN and service-centric networks typically operate through messages carrying an object (e.g., a content object, or metadata) and typically a "verb", "command" or more generally an "operation ID" that may identify the operation to be carried out on this object. For example, a content request typically may be seen as a "GET" operation, along with a set of metadata, which may include the name of the object to retrieve. These messages may be referred to as Remote Procedure Calls (RPCs) or service or ICN messages. While RPCs may involve a request and a response, messages which follow different patterns (e.g., publish/subscribe (Pub/Sub), or simple indications without replies) may also be considered.

[0110] RPC/Service/ICN messages may carry large amounts of data, which may need to be either processed by intermediate nodes, or forwarded as efficiently as possible. In an example case, it may be unknown, before analysis by the intermediate node, whether the data object should be processed locally or forwarded. Receipt of the entire object before taking a decision however may not be a practical solution, as it may impose a delay at every hop.

[0111] One possible problem therefore may be to define a mechanism where the system (including its SDN substrate) may enable making the decision to process or forward messages as early as possible at each intermediate CR, while enabling the CNS platform software running on each CR to take into account any suitable object characteristic (e.g., metadata) in making its decision.

[0112] Earlier proposals for using SDN with ICN focus on using a packet format where the information needed for routing is present in a fixed packet header (e.g., Content ID, tag, priority, etc.) In contrast, with CNS, content objects may expose more information to the network, e.g., metadata information which is not designed to fit in a packet. This may lead to a more open system where content/service requests may be routed based on any metadata. This may require SDN to be enhanced to minimize the impact of such routing on end-to-end delay.

[0113] Further, in an example illustrative scenario, a client or client application (end user or service instance) may be assumed to have already obtained a response from a service instance in the content network. Typically, the next request may or may not be served by the same instance in the network. Nevertheless, it may be required, in some cases, for this client to specifically require service from the same network-side instance.

[0114] Another objective, therefore, may be to enable a "session-like" feature, where the client may have multiple requests to be served by the same service instance. There may be no need to provide any way to control which network-side instance serves the request, only that, once a first network-side instance is selected to serve a first request, the same instance is again selected for some designated following requests.

[0115] An embodiment that does not require additional signaling, does not require end-to-end connectivity (i.e., hop-by-hop forwarding only), and which does not further degrade security may be needed. It may be assumed that the content network nodes are trusted to forward traffic, as this may be a base requirement for CNS.

[0116] Such embodiments may enable "weak session" control by the client application, which may make it possible for any apphcation to take advantage of the server-side code mobility which may be offered by CNS, while maintaining sessions when needed. For example, a CNS-enabled video streaming client application may inform the CNS system that an initial exchange for login in the application should use the same server-side instance. Once the user is logged in, the client may stop using the weak session when downloading segments of a video, which may result in different server-side instances being used, (e.g., if the first serving CR becomes overloaded). In addition to a mechanism, APIs enabling this mechanism may also be defined.

[0117] FIG. 5 is an example of an overall view of a CNS System

Architecture 500 in accordance with another embodiment, which may be used in combination with any of the embodiments described herein. The example architecture has a single node type (Content Routers (CRs) 501a, 501b, 501c, 50 Id, 50 le, and 50 If) and external interfaces (for example DNS and HTTP). The lines between a CR and an application client 502a, 502b, and 502c or apphcation provider 503 or content network provider 504 represent IP connections 505a, 505b, 505c, 505d, and 505e terminated at each side, and may be HTTP(S) connections. The lines between CRs 501a, 501b, 501c, 501d, 501e, and 501f may be Content Network Links 506a, 506b, 506c, and 506d, over which Content Networking protocols (such as CCN, PURSUIT, or others) may be used along with CNS inter-node control protocol (such a protocol is further described herein using a Remote Procedure Call paradigm). In particular, the control protocol may be used to transfer code and other control plane tasks. The control protocol may also be used for data plane tasks, such as transferring content objects between nodes, although this type of traffic may also be communicated e.g., over CCN/PURSUIT/other Content Network Protocols. There may be several functions inside each CR 501a, 501b, 501c, 50 Id, 50 le, and 50 If, which may be active or inactive, and which may be configured differently between different CRs 501a, 501b, 501c, 501d, 501e, and 501f. In the example of FIG. 5, the DNS service is enabled in CRs 501a and 50 le as shown by DNS links 507a, 507b, 507c, 507d, and 507e. CRs 501a and 50 le may, for example, be the primary and secondary DNS servers of the network. Also, in this example different external actors may have different access rights, e.g., enabling access to different set of APIs.

[0118] FIG. 6 is another example of an overall view of a CNS System

Architecture 600 in accordance with another embodiment, which may be used in combination with any of the embodiments described herein. The example architecture has various node types including control node (CN) 601, CR 602, and front ends (FEs) 603a and 603b. CN 601 may be a CR with control node related features such as control APIs and a DNS server. FEs 603a and 603b may be CRs with front end features such as a web server and APIs to clients. CN 601 may have an external interface 609a to a network management user interface 605, which may have console interfaces 608a and 608b to application provider 607 and content provider 604, respectively. CN 601 also has a DNS links 611a, 611b, and 611c to application clients 606a, 606b, and 606c, respectively. CN 601 also has internal interfaces 610a and 610b to FE 603b and CR 602, respectively. FE 603b has external interfaces 609a and 609b to application clients 606a and 606b, respectively. CR 602 has internal interface 610c to FE 603a, which has external interface 609c to application client 606c. CR 602 may include cache and forward objects. FEs 603a and 603b may additionally terminate IP sessions with clients. CN 601 may or may not cache/forward but may host control functions, such as the DNS server.

[0119] The following table describes various components, nodes and interfaces that may be used in any of the embodiments described herein:

This node interacts with a WTRU for a given FQDN

(i.e. the WTRU can get content objects from the FE, and can publish content objects to the FE).

The FE node is an ICN router that is interconnected with other FE and CR nodes, forming an ICN network. Once a WTRU publishes a content object, the FE publishes the content object in the ICN network.

Front End Node

The FE allocates a content name to published content. A content object is named both in ICN and as a regular URL; both names can be related as to enable automatic translation from one to the other (though it is also possible to rely on some form of mapping service instead).

Front End nodes typically have a storage capacity to cache content objects.

This node is similar to the Front End, except that it

Content Router Node

does not have an interface with a WTRU.

Interfaces Description/Comments

This is the interface through the DNS system between

DNS interface the WTRU and the Local Content Network Provider's

DNS server.

This is typically a set of REST APIs implemented by the FE or CN nodes and used by the client application on the WTRU, or by another user (e.g. Application Provider or Content Network Provider, through a Network Management System).

For example, one such API enables local publication and retrieval of content. Additionally there can be a long term connection component, such as a WebSocket connection, which can be used to enable deferred

External Interface

publication, where the client publishes the content without uploading it to the Local Content Network. Later on, if the content is needed the retrieval procedure may be triggered over this WebSocket connection.

Other APIs such as search and usage reporting are also available over this interface. Typically Application Providers/Content Network Providers will have access to some APIs while end users may have a more restricted access. This can be an ICN interface, including ICN user plane

(e.g. using CCNx protocol) and control plane (e.g. using

Internal Interface OSPFN protocol and possibly CNS-specific protocols).

Its purpose is to enable content publication and dissemination, but also management and control.

Application Providers and Content Network Providers may monitor and control the system through a Network Management System (NMS). This NMS can act as any other client apphcation and access APIs over the Internal interface, though with typically more access rights than most client applications.

Console Interface

The function of this interface includes configuring scope access policy (e.g. list of public scopes, pubhc key for signature verification, retention policy, etc.), as well as providing access to certain services such as search. Users of this interface can be internal (e.g. for the Local Content Network operator), through command line or web interface. Users of this interface can also be external such as the Apphcation Provider.

[0120] One example role of a Content Network is to present to outside world clients (e.g., client applications, Apphcation Providers, and End Users) a certain organization of the data it holds, including primary data objects such as photos and videos, as well as other sorts of objects which may be used to provide additional features (e.g., Queue objects which may be used by chents to subscribe to certain events) or to expose the system capabilities, and enable operations by clients. A general model for this may include a Representational State Transfer (REST) interface (for example, a Cloud Data Management Interface (CDMI) may provide a REST interface which may be extended to fit our purpose).

[0121] The CNS provider may typically offer management-hke APIs, e.g., to deploy a plugin in the network, for use by the network operator and possibly content network providers and other application providers. A Content Network provider (running its code over the CNS) may typically offer an API for publication and retrieval of content. Additionally, the CN provider may typically offer "hooks" enabhng its users (e.g., Application Providers) to pubhsh policies that specialize existing behavior. Policies may be considered as CNS objects which are published in the network and one type of Task Object. These policies may be invoked by the CN code, and based on the output of this invocation, the CN may behave differently. Application providers (e.g., users of the Content Network) may also publish code running on the CNS that may offer APIs. These APIs may be used by end users of the application, or other applications.

[0122] One possible challenge is to enable a single web server to dispatch requests to code which is not necessarily loaded at the time when the request is received. The same issue may exist with inter-node communication, which is typically not web based. To solve this problem, a CNS Virtual Filesystem (CVFS), may be defined, which may include a tree formed by the whole URL space, e.g., /domain. com/path/to/content,

/another. domain.org/path/to/another/content/object). Each node may hold an instance of CVFS. A plugin may be "mounted" in the CVFS tree of a node, at a certain position in the tree (e.g., "/" for global mounting, "/domain. com" for a plugin valid on a given domain, or "/domain. com/path 1" for a plugin valid on a subset of a domain). If a plugin is mounted, code entry points for this plugin (tasks and methods, as described later) may be registered at the mount point or at some level underneath, along with the identifier of the plugin/tasks. If the CNS on a node receives a request, it may first translate this request into a task name, and then may resolve this task name using the local CVFS state information, obtaining the identifier of the task to be invoked. If this task is not present, the CNS may make the decision to either drop the request (or reply accordingly) or to fetch and load the task. This decision may be local, centralized or distributed in the network.

[0123] The following table describes the effects of various functions that may be implemented over CNS, and their interactions with the outside world, such as end users and Application Providers:

Function Description and API (if any) of this Function

Local This feature offers clients (as well as other actors) the

Publication & possibility to upload and download content which is stored Retrieval locally, i.e. which typically does not transit through the backhaul link.

From the outside of the system, the visible side of this function is therefore the API itself, e.g. a REST API. The resources are hierarchically organized (e.g. /path/to/content where /path and /path/to are containers). Data and metadata can be retrieved separately. CDMI "results specification" feature can be used to implement retrieving parts of an object's metadata.

This feature set includes caching objects in various nodes, and disseminate objects across the network to enable all other functions (e.g. local publication and retrieval). This feature set

Caching, impacts the efficiency of the system.

Dissemination,

etc. From the outside of the system, the visible side of this function could be some form of control by setting certain metadata on certain objects (e.g. some form of priority). Configuration can be through policies.

The Client-Front End Association functions pairs end users with Front End at DNS request time.

Client-Front

The Application Provider may influence the association End Association

function (e.g. requesting a certain minimum number of Front Ends for a given domain), possibly through a domain management API.

The "Access Control" feature includes controlling access to an API offered by the system (e.g. the network operator grants access to the Application Provider for certain control APIs over the domains owned by this Application Provider; e.g. the Application Provider grants access to the publish/retrieval API over a given domain to certain end users). This feature also includes controlling access to certain objects inside a

Access Control domain, even if the client has access to the domain. Access

Control can extend inside the system, e.g. plugins from a certain Application Provider should not be able to process data from a domain owned by another Application Provider.

From the outside of the system, the visible side of this function should typically include attaching certain metadata to containers and other objects to influence access control.

This feature consists in providing a search function for clients

Search - to retrieve a list of links to wanted objects. It also includes General & Logs attaching to objects metadata that can be used for searching. For reference, see CDMI Query & logging queues and scope & results specification. Search can be enabled through the creation of Queue objects, for general query or for query through logs. The publication API should further enable setting and managing metadata on existing objects.

This feature enables clients and other users to register for user notification upon certain events, e.g. new objects added under a certain path. Notifications can be real time (e.g. over a long term connection) or soft real time via polling.

User

For reference, see CDMI notification queues and scope

Notification

specification. Notifications can be enabled through the creation of other types of Queue objects. Real time notifications may be enabled by adding a real time messaging feature (e.g. over WebSocket or XMPP) pointing to the relevant Queue object's URL.

This feature exposes the capabilities of the system for clients/application providers to learn and properly use these capabilities.

Capabilities For reference, see the CDMI capability object. Either a specific object type or a URI prefix-mounted API can be used to expose capabilities. Could also be used to set/unset capabilities on certain nodes, e.g. disable certain management operations on Front End nodes for security reasons.

This feature enables mounting/un-mounting a plugin. Mounting is an association between a plugin loaded in the system and a certain "place" in the CVFS space, such as a URI prefix (queries on URIs hierarchically under this resource will be processed through this plugin).

Plugin Mounting

From the outside of the system, the visible side of this function is on one side the mounting API(s), and other side the possibility to access a plugin-defined API from this mount point, or to experience the plugin functionality integrated in existing function.

This feature enables defining and deploying policies to adapt the behavior of certain other functionalities to the need of the user.

Management of

From the outside of the system, a visible side of this function Policy Objects

is an API to add/update/remove policies attached to specific events and conditions. Such policies will influence the processing of certain objects through specific functions in the CNS network. Another side of this function is the exposition of certain policy hooks by other CNS functions.

This feature enables the collection by system users of usage statistics collected by the system.

Usage Reporting

For reference, see CDMI domain object. In an example derived from this reference, one can get summary usage information on a domain by querying /cns_domain/<domain>/<subdomain>

This feature enables configuring of a domain by an authorized system user.

Domain For reference, see CDMI: domain management includes Management adding new subdomains. For configuration of access control:

domain access could be configured at a certain URI like /cns_domain/<domain>/access (e.g. set private key for signature verification, or set authorized IDs, IP blocks, etc.).

Context insertion can include setting certain contextual metadata on specified objects (e.g. link all objects published during an event with an object describing the event).

From the outside of the system, a visible aspect of this

Context

function is that clients may influence context insertion with Insertion

metadata (not clear at this time what an example would be though). Another clearer aspect is the configuration by application provider or clients, typically through a REST API, which internally produces policies which are used inside the network.

Examples of Features by Application Providers

An Application Provider such as Instagram could implement a plugin mounted at a certain URI. The chent can interact with

Image the Image Processing REST API using usual techniques (e.g. Processing the request can hold a JSON document with parameters). The

Application Provider has full control over the plugin in this case, and can upload a new version of it for example.

An Application Provider such as Instagram could implement commenting in multiple ways through CNS. For example through a REST API. Comments requests can simply refer to

Commenting an object. The plugin could for example ensure that a comment_list object is linked to in the object's metadata, and this comment_list object would contain the list of actual comment objects.

Examples of Extensions/Additional Features

This extension could include additional behavior (a plugin)

Copyright

which is invoked when content is published locally or check

Infringement

periodically new content. This plugin would rate the content's

Detection

risk in term of copyright infringement, and in certain cases could either run infringement detection algorithms locally, or in other cases would upload content to an over-the-top service.

The Application Provider may have some control over the plugin, e.g. to set further checking threshold. This could be enabled through a REST API.

In this extension, Application Providers could publish content in CNS like in a normal CDN. The content would be pulled on demand, and cached under constraints such as minimizing the backhaul traffic and fitting into the limited local storage space

Non-Local

shared with local content.

Content

Delivery

One way to turn this feature on/off could be a domain-wide flag (e.g. external.cns.myapp.com could be used for such content). A per-domain REST API could enable configuring the feature.

Analytics could be enabled by a plugin collecting objects'

Analytics metadata at various stages. Authorized users should be able to configure this collection through a REST API.

Serialization/deserialization may enable moving data to/from

Serialization

another cloud.

[0124] The basic unit of content in CNS is the object (which may also be referred to herein as the CNS Object). A CNS object may be typically mapped to a resource in the CNS REST API, but it also may have a physical presence in the CNS system. A CNS object may be the base unit for uploads, downloads from/to clients, and of transfer and storage inside CNS. There may be various types of objects. Each object type may be associated with a mime-type, except for data objects, which may have any mime-type. Some of those object types may be associated with a schema describing the data which they hold (e.g., containers may list children objects). The following table lists various example object types:

CDMI's queue objects can be a good base to implement a pub-

Queue sub mechanism between CNS and its external users (e.g. client applications).

Ca ability Holds capabilities of the system.

Represents a principal (e.g. end user) identified in the system

Principal

for access control.

Task A list of instructions defining a workflow.

Plugin An object holding a runnable plugin.

This object describes an API to interact with a plugin

Plugin

(alternatively such an object may be omitted or replaced with Declaration

some metadata in the plugin object).

Application Can be used to aggregate information about several domains Provider held by a single application provider.

Metadata An empty object used for its metadata only.

Reference Symbolic ("soft") and/or hard links.

Request Internal objects used to route requests to plugins.

3^rd party-

Object defined, for example, along with 3^rd party plugins defined

For example, ephemeral object created for the sole purpose of

Temporary

invoking a task

[0125] FIG. 7 is a diagram of an example high level structure of a content object 700 in accordance with another embodiment, which may be used in combination with any of the embodiments described herein. In general, objects, such as images, videos, code, etc., may have two major components: a body containing the "core" data for this object (e.g., encoded video may be core data contained in the body of a video data object), and metadata associated with this data. The content object 700 may include object data sections 701 and object metadata sections 702, which are the backend object 710 or long term portion of the content object 700.

[0126] The content object 700 may also include object internal metadata

703, which is the internal object 711 or short term portion of the content object 700. The internal object 711 representation inside a node may carry additional short term information, e.g., processing state.

[0127] There may be zero or more object data sections 701, each associated with a data type. For example, an image may have a single mime type image/jpeg. Complex objects may hold several object data sections 701. Typically, object data sections 701 may be stored and/or cached on a disk or other non- transitory computer readable medium, and/or communicated to other nodes.

[0128] Object metadata sections 702 may hold key-value pairs. There may typically be one or more object metadata sections 702 associated with any object 700. At least one (e.g., named "id") may be present to hold information such as content name. Typically, object metadata sections 702 may be stored and/or cached on a disk or other non-transitory computer readable medium, and/or communicated to other nodes. The CNS may be aware of the type/format of object metadata sections 702 (for example, in an exemplary CNS system all such metadata sections may be encoded using the same format, such as JSON). Accordingly, CNS (or a low level routing component built over CNS) may be able to use metadata to make decisions.

[0129] Object internal metadata 703 sections may be used to store information that is related to the present computation on the object. Typically internal metadata may not outlive the present computation job on the present node on the object. It may not be stored and in general may not be communicated to other nodes.

[0130] Only the backend object 710 (formed by object data sections 701 and object metadata sections 702) may be stored (e.g., on disk). For transport, an object 700 may, for example, be serialized using JAVASCRIPT OBJECT NOTATION (JSON) for the metadata sections and binary or base-64 encoding for the data sections. Typically, objects may be encoded for transmission as multipart HTTP resources, or an equivalent multipart representation, including metadata parts and data parts. Objects 700 may be partially transmitted, i.e., a subset of all metadata and data sections composing the objects may be transmitted. An additional header may list the types of the transmitted sections, or their type may be specified in the encoding of each part.

[0131] The decomposition of metadata and data in separate sections may be leveraged to enable partial communication and storage, e.g., for reasons of efficiency. Metadata may include a (possibly well-known) label, e.g., ID, CORE, CACHING, etc. The exact list of labels may be determined at detailed design time. The CORE metadata section may contain a bitmap hsting which metadata section exists for this object. Each metadata section may be associated with a hash value and/or other fields (e.g., lifetime, received time), which may help determine the freshness and validity of this group.

[0132] The internal object 711 representation may be incomplete. For example, a subsystem may create an "empty" object having only an ID section (i.e., no other metadata and data sections), and then may invoke a "FETCH" task which may get the object from somewhere in the network. Some form of "object state" information may therefore be used and may for example hold a bitmap indicating which pieces of the object are present and another bitmap indicating which pieces are missing (e.g., bit 0 = data section #1, bit 1 = ID, bit 2 = CORE metadata group, etc.). The backend object 710 metadata may typically hold a bitmap indicating which parts are globally defined for the object 700. Additionally, the internal object 711 may also hold other processing related information, for example internal data structures used by functions and libraries used to implement the CNS.

[0133] FIG. 8 is a diagram of an example internal representation of an object 800 in accordance with another embodiment, which may be used in combination with any of the embodiments described herein. The backend object 804 component may be shared among several concurrent processing tasks. Thus, each internal object 801 may point to 803 a backend object 804. Internal object 801 may be temporarily stored as 802 an internal object ID in the in-memory internal object cache 808, where internal objects may be removed after use. Tasks and methods may be given a handle to an internal object 801, which may point to 803 the appropriate backend object 804 for this operation. Backend object 804 may be temporarily stored as 805 an FQID in the in-memory backend object cache, where unused backend objects may be cleaned up. It is possible that the backend object 804 to which the internal objects 801 point may change during the course of the processing (e.g., at first the object ID is not known, but it may be determined later on, and a backend object 804 for this object ID may already be present in memory). The backend object 804 may be locally stored and retrieved to/from 806 storage 807.

[0134] FIG. 9 is a diagram of an example CNS Architecture Stack 900 in accordance with another embodiment, which may be used in combination with any of the embodiments described herein. The example of FIG. 9 illustrates a summary of the CNS architecture components organized as a stack 900. This stack 900 may be implemented across the network, i.e., any node in the network may implement the content networking substrate and additionally may hold some of the upper layer components. Each component in FIG. 9 may focus on a narrow set of functions, and may implement these functions by adding plugins, adding or updating policies/tasks, and/or possibly adding new metadata properties and new object types. The stack 900 may include examples of third party applications components (Plugins) 901, which may include policies for core behavior functions (e.g. access control, authoritative caching, dynamic context insertion, etc.) 911. The examples of third party applications components (plugins) 901 may also include commenting (plugin object types, policies, etc.) 912 and image processing (plugin, object types, policies, etc.) 913.

[0135] Local content services core components (plugins) 902 may include, but are not limited to the following:

[0136] Metadata, object types, tasks, plugins & policies for other features

921;

[0137] Object placement (per-object type) 922;

[0138] Publication & retrieval 923;

[0139] Best effort local caching 924;

[0140] Context insertion 925;

[0141] Logging & charging 926;

[0142] Authoritative caching 927;

[0143] Subscriptions & notifications 928; [0144] Client -front end pairing 929; and

[0145] Search 930.

[0146] Plugins extending local content services 903 may include copyright infringement detection 931, non-local content delivery 932, analytics 933, and serialization 934.

[0147] The content network substrate 904 may include access control 940, external transport 941, workflow 942, storage 943, internal transport 944, virtual filesystem 945, plugin support 946, DNS service 947, inter subsystem communication 948, and object 949 sub -components.

[0148] The network substrate 905 may include network virtu alization technology 950, SDN 951, hardware (switches, caches, servers) 952, and legacy IP -based technologies 953.

[0149] The object placement 922 component may include one or more plugins configured to determine the authoritative CRs for an object. Different object types may require different strategies, which may be implemented in different plugins.

[0150] The publication and retrieval 923 component may implement local publication and retrieval of objects.

[0151] The client -front end pairing 929 component may implement the mapping between front ends and clients, and may configure the DNS server. The client-front end pairing 929 component may use information collected by logging/charging.

[0152] The best effort local caching 924 component may implement in-path caching for all objects passing through the node. Different object types may require different strategies.

[0153] The context insertion 925 component may implement insertion of metadata to published content. The context insertion 925 component may generate certain contextual information (e.g., a link to other content from the same publisher), and may obtain other contextual information from external actors through an API. [0154] The substrate (e.g. its Workflow component) may maintain counters associated with tasks it runs, which may be collected by the logging and charging 926 plugin. The amount of space taken in storage and the transmission time related to a given domain may be recorded by different subsystems and may be collected by the logging and charging 926 plugin as well.

[0155] The authoritative caching 927 component may implement authoritative caching, which may store a copy of an object to make it available for other nodes. Its functions may include synchronization between authoritative copies.

[0156] The subscriptions and notifications 928 component may include a plugin that provides a subscription/notification API to external clients. This component may internally subscribe for events from the CVFS subsystem (e.g., new content added under a certain path).

[0157] The search component 930 may provide a search API or it may actually simply use the existing subscription/notification API, and also include supporting function in the network, e.g., to collect metadata.

[0158] Other components may include certain extensions (e.g., copyright infringement detection 931, non-local content delivery 932, analytics 933, and serialization 934) and third-party provided components (commenting 912, image processing 913) as briefly described above.

[0159] FIG. 10 is a diagram of an example CNS intra-node architecture

1000 in accordance with another embodiment, which may be used in combination with any of the embodiments described herein. A subsystem-based architecture may be used in the CNS intra-node architecture 1000 to enable decoupling between components, as well as extensibility. Each component in FIG. 10 may focus on a narrow set of functions, and may implement these functions by adding plugins, adding or updating policies/tasks, and/or possibly adding new metadata properties and new object types. As shown in FIG. 10, clients (end users) 1001 may interact with CNS Node 1003 via DNS link with DNS service 1004 of CNS Node 1003 or via REST API link with external transport (web server, WebSocket) 1005 of CNS Node 1003. Other CNS node's internal API transport 1002 may access the CNS node 1003 via a socket-based link with internal transport (e.g. using ZeroMQ) 1007. The CNS node 1003 may include other components including but not limited to access control 1006, CNS virtual filesystem 1008, storage 1009, plugin support 1010, workflow 1011, all objects 1012, plugin objects 1013, and task objects 1014.

[0160] The external transport subsystem as identified above may handle the HTTP(S) interface with the outside world (e.g., client apphcations and Application Provider). Upon receipt of an HTTP request (e.g., GET, POST, etc.) the external transport subsystem may create a request object and may invoke the RX task, which may route the request to the proper subsystem or plugin. A response object may be returned, which may be sent back to the requester.

[0161] The internal transport subsystem as identified above may handle communication with other CNS nodes. The identity of remote nodes may be decided by other subsystems/plugins. For example, the content placement plugin may decide where to pull a content object from.

[0162] The storage subsystem as identified above may handle low level storage, e.g., STORE/DELETE/GET. The storage subsystem may be object based with no apparent structure (the subsystem may internally structure storage in any suitable way). Any replacement policy may be handled by relevant plugins, and not by the storage subsystem.

[0163] The storage subsystem as identified above may provide some classification (e.g., store #1, #2, etc.) and querying capabilities (e.g., oldest/least used object ID in store #2, size of store #3, etc.). These capabilities may facilitate the implementation of plugins for managing this storage space.

[0164] The access control subsystem as identified above may use certain metadata found in an object (e.g., a Request Object should be processed only if the original sender is authorized to make this request) to determine if a principal is authorized to obtain a certain service from the system. This may imply a user- based access control system. Other models may be supported, possibly concurrently (e.g., location based, device-type based, etc.).

[0165] The external transport subsystem as identified above may be the primary "gate" to enter the system. The external transport subsystem may create or retrieve an existing "Principal Object" when an end user connects the first time to this node. All Request Objects created by external transport may then be linked to this Principal. The first step performed by external transport prior to dispatch the request with the RX task, may be to call an "Authorize" task that may invoke the Access Control subsystem.

[0166] The CNS virtual file system, or CVFS subsystem, as identified above may maintain a representation of the CVFS tree, which is further described herein, along with its primary use for mounting and resolving methods and tasks.

[0167] The CVFS subsystem may also manage inheritance of metadata from parents to children. Inherited metadata may be marked in some way (e.g., CDMI uses a trailing '*') to enable future re-evaluation of the inheritance if a parent is updated. It is noted that in addition to inheritance, metadata may also be included from linked objects. This may be used, for example, to efficiently manage metadata that applies to many different objects located at various places in the CVFS tree.

[0168] The CVFS subsystem may also be used to manage subscriptions and publications of certain events. For example, a task may be subscribed for any addition or deletion of a data object under a certain URI prefix, resulting in this task being called upon these events. It is noted that this "pubsub" mechanism may alternatively be implemented in a separate subsystem.

[0169] A DNS service subsystem as identified above may be included in a

CNS, or may be implemented as an external service. The DNS service subsystem may include the DNS server itself, and may be a component facilitating the configuration of an external server. The DNS service subsystem may be configured dynamically (e.g., with a configuration request stating which front end should be used for a certain fully-qualified domain name (FQDN) when the request comes from a given IP block) and may also provide statistics on demand. The logic to determine the client -front end pairing may not be placed in the DNS service subsystem. It is noted that from an implementation stand point, the DNS server may include an external program, in addition to some code inside the substrate program which controls the configuration of the DNS server.

[0170] An Object Workflow subsystem may be a core component whose purpose is to orchestrate the object lifecycle through the various subsystems in a CNS node. A core aspect of this subsystem may be to load a set of task objects, which each may contain the code of a single task function. A task function may take an object as input and may produce a return code as output. The object may be modified in the process. A task function may typically require certain metadata fields and/or the object's data to be present in the input object. An object taken as input may have a structure as illustrated in the examples of FIG. 7 and FIG. 8 (i.e., the task may be given a handle to an internal object which points to a backend object). Each process (or task) may operate on one object.

[0171] FIG. 11 is a flow diagram of an example life cycle of internal and backend objects 1100 in accordance with another embodiment, which may be used in combination with any of the embodiments described herein. The example of FIG. 11 illustrates the life cycle of internal and backend objects through the execution of two tasks, which in this example process the same backend object (e.g. a video file). Each task may be running in its own thread of execution. Referring to FIG. 11, an event may trigger thread- 1 creation 1101, which has timehne 1102. Thread 1 may create 1104 internal object 1 1105, and backend object A 1106 is created and that may be then read from disk. FIG. 11 also shows the lifetime of object 1 1110 and the lifetime of backend object A 1112. Another event (e.g. message from remote node) may trigger thread-2 creation 1107, which has timeline 1108. Thread 2 may create internal object 2 1114 with lifetime of object 2 1111, and have object 2 1114 point to the same backend object A 1106, which has the effect to extend its lifetime 1112 even after Object 1 1105 is destroyed. Also shown in FIG. 11, thread- 1 may destroy its internal object when it is done processing 1103, thread-2 may destroy its internal object when it is done processing 1109, and background memory management may decide to unload the backend object 1113.

[0172] Each task may be described using the following example specifications: a task unique name, input requirements, and output requirements. An example task unique name may be task#FETCH. Input requirements may include, e.g., that the object must have its content name (e.g., meta.id.fqid) set. Output requirements may include, e.g., that if the task returns code#FOUND, the object has been retrieved from the network (from a remote or local node) and the internal object points to it. The backend object pointed to by the internal object may be physically the same during the whole process (updated with data/metadata obtained from the network) or it may change during the process (e.g., the backend object wanted was already in memory, the internal object was changed to point to it). Output requirements also may include, e.g., that if the task returns code#NOT_FOUND, the object was not found in the network but no error occurred. The internal and/or backend object may have been modified, e.g., some metadata may have been added, such as the identifiers of authoritative caches for this object. Output requirements also may include, that if the task returns code#ERROR, the state of the object is not guaranteed to be valid. It is possible to have several implementations for the same specifications, resulting in interchangeable tasks.

[0173] Tasks may be invoked upon reception of a client request (e.g. an

HTTP request from an IP client), or upon reception of a request from another CNS node. A task called in this way may be referred to as a main task. An internal object may be created for the main task, as well as a new thread of execution. The main task may call other tasks in the same thread of execution (e.g., task#FETCH may be called as a main task or may be called as a non-main task by a main task such as task#RX, as illustrated below). Tasks may be orchestrators of processing. Thus another type of lower level function may be necessary, which may be implemented by different subsystems or plugins. Such functions may be referred to as methods.

[0174] The two types of high level functions defined in CNS, tasks and methods, are summarized as follows, adding some further example constraints which may simplify implementation while keeping the system general enough to implement the system.

[0175] Tasks may handle high level processing of an object, calling methods/tasks, and logic structure based on object's state and methods/tasks returned code. Tasks may be loaded and/or controlled by the Workflow subsystem and may typically run in a CNS daemon process. Tasks may be run as a main task, i.e., in their own thread, or may run in the thread of a local calling task or method. Tasks may have no persistent state across invocations, and may call other tasks and methods (without spawning a new thread).

[0176] Methods may handle implementation of a detailed operation, e.g., storing a file on disk, communicating with other nodes, performing complex computations on data or metadata, communication with a 3^rd party service, etc. Methods may be implemented by a subsystem or by a plugin, and may typically run in a plugin process. Methods may be local to a particular network node, and may call a task but may not call a method. Several methods may share some common persistent state (e.g., methods to advertise a route and to perform actual routing may share a common routing table). Methods may be described using the same specifications as tasks (e.g., name, input and output).

[0177] FIG. 12 is a sequence diagram of an example processing of tasks and methods 1200 in accordance with another embodiment, which may be used in combination with any of the embodiments described herein. In the example of FIG. 12, an external event triggers the execution of a main task, which calls a method (in this case, method#RX), which calls a task (in this case, task#PUSH), etc.

[0178] Referring to FIG. 12, external API 1201 may receive POST from a

WTRU 1208. External API 1201 may create an empty data object (new internal object and new or reused backend object) and set its CVFS name based on the HTTP request 1209. External API 1201 may then create an independent procedure thread 1210. External API 1201 may then call task#RX 1211. Workflow 1203 may respond by calling method#RX 1212. Publish Plugin 1202 may process POST 1213 and build data object 1214. Publish Plugin 1202 may then call task#PUSH 1215, 1216. Placement 1205 may decide which cache is authoritative for this object (NO) 1217 and responds 1218 to workflow 1203 with a decision. Workflow 1203 may trigger 1219 local caching 1204 to cache locally 1220, which responds 1230 to workflow 1203. Workflow 1203 may then trigger 1231 internal API 1206 to push the object to an authoritative node 1235 and trigger a RPC for task#PUSH_LOCAL 1232 at remote node 1207. Remote node 1207 may execute action 1233, which may then trigger 1234, 1236 workflow 1203 to return from task#PUSH 1237. Publish plugin 1202 may then return from method#RX 1238 and workflow 1203 may then return from task#RX 1239. External API 1201 may then send a reply back to the WTRU 1240 and destroy the internal object thread 1241.

[0179] Methods and tasks have in common that they may use a programmatic API to the substrate. The API may support various functionality, including calling tasks and/or methods; manipulating metadata; obtaining identities or peer nodes; calling tasks on peer nodes; obtaining HTTP request/response handles; obtaining CVFS location of object; getting local configuration key-values; some additional helpers, such as support for send messages or event publication/subscription, etc.

[0180] Note that some of the API functions described herein may be available to methods only, tasks only, or both.

[0181] Plugins may include packaged implementations of one or more methods. A plugin may typically run as a single process, may be separated from the CNS daemon and may run in its own application container (e.g., for resource constraint and/or isolation). Methods of a plugin may be invoked through a plugin support subsystem, whose role may be to route method calls to/from plugins, and may also facilitate the proper plugin object to be present locally, to load the plugin in such way that its methods may be invoked, and to make the object of the invocation available to the plugin code. A plugin may support the interface imposed by the plugin support system, to enable loading it. This may include, for example, support for the appropriate Inter-Process Communication used by the plugin support component of the CNS daemon. Otherwise, plugins may implement a set of methods (e.g., "method#RX", "method#LOCAL_STORE", etc.) that may be exposed through the plugin subsystem. Methods of a plugin may take an object as input, and may perform any computation such as accessing the object's data and metadata, storing the object, waiting, modifying the object, sending and receiving traffic, etc.

[0182] FIG. 13 is a flow diagram of an example policy task call 1300, which may be used in combination with any of the embodiments described herein. Policies may control certain aspects of a Content Network, e.g., whether to accept a content upload or a content request, how long an object should be retained in storage before being purged, etc. The mechanism used for tasks may be reused to enable such policies. Policies, in CNS, may be otherwise regular tasks which differ only by their usage. Policies may be referred to as policy tasks (e.g., task#POLICY_INGESTION called by a task or method implementing the ingestion of user provided content). The base implementation (in the given example, the ingestion code) may effectively define the policy purpose by calling the policy task 1301 and determining actions to take based on this return code 1302. For example, the return code of the task may be, for example, code#ALLOW or code#DENY, and the calling ingestion code may use this return code to decide whether or not to ingest the content object. The specifications of the policy tasks may be made known to a user, e.g., a content network administrator. The content network administrator may then publish the policy task actions 1303, such as, e.g. publishing one or more implementations of task#POLICY_INGESTION policy tasks describing which content to allow or deny in the network. If there are different implementations, they may be "mounted" at different points in the "URL space" (or "CVFS tree" as described herein), resulting in content under a first mount point (e.g. example.com/videos) to be allowed/disallowed for upload through a first implementation on the pohcy, and in content under a second mount point (e.g. example.com/images) to be allowed/disallowed for upload through another implementation of this policy.

[0183] One possible difference between a policy and a regular task is that some pohcies may have a default behavior that apphes when the pohcy task is not locally present on the node. In an example implementation, an API call may be provided to call a task "if it exists" and return "code#DOESNT_EXIST" otherwise. The caller may then apply a reasonable default in this case.

[0184] The following example code, which is written in the Go programming language (although such code may be expressed in any other suitable programming language) demonstrates how a policy task call may appear:

// Check ingestion pohcy

var codePolicylngestion string

if codePolicylngestion, retText = pobj.CnsCallTaskmtExists("task#POLICY_INGESTION");

codePolicylngestion == "code#ERROR" {

err = fmt.Errorf(retText)

return

}

// Default behavior

if codePohcylngestion == "code#DOESNT_EXIST" {

codePolicylngestion = "code#ALLOW"

}

// code#DENY

if codePohcylngestion != "code#ALLOW" {

// No error, operation is disallowed, so we return now (we already answered a 403 to user)

return

}

// continue since we got code# ALLOW... [0185] A simple policy task may run without invoking other subsystems.

For example, a policy task may return a "code#DENY' code for certain object types. The calling subsystem may check this return value to determine what to do next, e.g., whether drop the object or continue processing. More complex policy tasks may, for example, invoke a method implemented by a plugin. For example, a policy for videos may run some heuristics or invoke an external third party service to check for copyright infringement.

[0186] An external actor may author and publish tasks, plugins and policies. The Content Network Provider typically may originate the core plugins defining the system. The Application Provider typically may originate policies to specialize the network for their purpose, and plugins to augment the network with new functionalities. The end user also may be granted the right to upload policies or plugins in the system. The Content Network Provider may provide an interface (e.g., a web page or REST API) to Application Providers and/or end users to do this in a secure manner.

[0187] CNS may implement a web server. If CNS receives an HTTP request from a client, it may create an internal object, may fill the internal object using any information in the request, and may call a task (e.g., task#RX), which in turn may call a method (e.g., method#RX). Therefore, all APIs to the Content Network clients, e.g., to the Apphcation Provider and/or client application, may be implemented as method (e.g., method#RX) instances. Plugins belonging to different applications may implement a method with the same name (e.g., method#RX). A mechanism to multiplex a web API between plugins belonging to different applications is further discussed herein.

[0188] In an example embodiment, the CNS platform may include a daemon service running on each node. Plugins may be run as separate processes running in containers (i.e., resource-constrained isolated environments within the same Operating System).

[0189] The CNS daemon may be in charge of all communications between plugins on the same host, as well as communication with other CNS daemon on other nodes and with IP clients. The general computation model is that any call from an external entity may spawn a new thread executing a given task on an object. This task starting its own thread may be referred to as an independent task. The object may be created (i.e., populated and named based on context) by CNS before starting the independent task. All independent task threads may run on the daemon itself. If a task needs to call a method of a local plugin, the CNS may communicate the method call to the plugin using an inter-process communication (IPC) mechanism (e.g., a message queue), and the calling thread may then wait until the method completes (or times out). Similarly, if the task needs to call a task on a remote node, the task is called using an RPC mechanism (e.g., RPC message over messaging library) and the calling thread may wait until the remote node replies or for a time out. A task may call another local task, in which case the called task may be run within the calling thread in the daemon process.

[0190] Local calls may be implemented using zero-copy IPC mechanism

(e.g., in Linux, kdbus using memfd) in order to transfer the object around without incurring inefficiency due to copying a potentially large objects. Remote calls may be optimized by leveraging the object structure based on data and metadata sections. Tasks may expose their input and output specifications, which consist in a list of data and/or metadata sections required for input, and data and/or metadata sections produced as output. The RPC call may therefore be optimized to transport a close-to minimum amount of data and metadata needed for remote execution. Upon reception of the response, the specified output data and metadata sections are merged back into the original object, which is demonstrated by the following example code:

CnsCallRemoteTask(remote, taskName, mergeCtlTx, mergeCtlRx) mergeCtlTx controls what is sent to the remote node. There are 4 types of data units:

- data itself (e.g. a picture) - global metadata groups, e.g. meta#id or meta#core, which should have the same meaning anywhere in the network

- local metadata groups, with the prefix meta#local, which are stored locally alongside the data and global metadata but usually are not transferred to remote peers.

- internal metadata groups, with the prefix meta#internal, which hold temporary state specific to the present computation. They are not stored, and usually not transferred to remote peers.

[0191] While internal and local metadata are usually not transferred, there are situations where it is needed to do so. The control parameters therefore enable the transfer of individual local or internal groups, which may be demonstrated by the following example code:

Examples:

{} (i.e. empty): send all global metadata and data

{"+"}: same as above

{"-"}: no data, no metadata

{"-data"}: send all metadata, no data

{"-", "+local"}: send all local metadata (but rename them as internal: internal. <peer> .local...

{"-", "=local"}: send all local metadata (no renaming)

{"+meta#id","-"}: send group id but nothing else

{"+meta#internal. group 1","-"}: send internal group named "internal. group 1" and nothing else

{"+meta#local.group2","-"}: send local group named "local. group2" as "internal.<peer>.local.group2"

{"+meta#core","+meta#id","+data","-"}: send groups core, id and also data, but no other metdata

mergeCtlRx follows the same rules. It is used to control the return path back from the remote.

Groups mentioned in mergeCtlRx may include the string <peer> that will be replaced with each peer ID.

Example:

{"+meta#something.<peer>","+meta#id","-"}: send groups

"something.1.2.3.4", and "id"

[0192] RPC messages may include, but is not limited to, the following: header information to reach the destination (e.g., when using CNS over IP) or next hop (e.g., when using CNS over ICN); the type of computation (e.g., task#PROCESS_IMAGE); the context/resource of the computation (e.g., domain.org/path/to/resource); and/or relevant metadata and/or data sections, which may be used as input by the computation.

[0193] An RPC response may include, but is not limited to, the following: header information to reach the destination (e.g., when using CNS over IP) or next hop (e.g., when using CNS over ICN) on the way back to the original sender of the request; a status code (e.g., code#DONE, code#ERROR, or an HTTP-like number); and/or relevant metadata and/or data sections, as output of the computation.

[0194] Objects may be long-term objects, such as movies or images, or may be short-term objects created for and used only within one independent task. Independent tasks may be attached to one object only. The object to which an independent task is attached may be known from the beginning of the task (e.g., an uploaded content object), or it may be unknown and empty at first, and populated later in the process (e.g., a request for a content object by name).

[0195] During the processing of an object in an independent procedure, there may be a need to apply a task to a second temporary or existing object; e.g. during the processing of an uploaded content object, there may be a need to find and manipulate an object representing a directory or collection of content objects. For this the CNS may provide functionality to start a new independent procedure from within a task. The caller may have the capability to wait for the independent procedure to complete, if needed.

[0196] RPCs may, moreover, be directed towards more than one node. In this case, besides the existing parameters specifying the data and metadata sections for input and output, an additional parameter, which may be called for example "mcastCtl", may indicate how to handle responses. For example, it may be possible to merge back into the original object the first non-error response and ignore other responses, resuming execution as soon as the first non-error is received. It may also be possible to merge all non-error responses back into the original object, and stop immediately upon the first error, etc. The following example code demonstrates the "mcastCtl" parameter:

CnsCallRemoteTaskMcast(remote, taskName, mergeCtlTx, mergeCtlRx, mcastCtl) mcastCtl is an array of strings, each encoded as: [code#ABC]:[m][!][r | w][l- 9]

[code#ABC] is optional (empty string means: by default, else this is the return code for which

the following flags apply. Examples: code#ERROR, code#DONE, or an empty string.

[m] is the optional letter 'm'. If present: merge the returned object with the local object,

else ignore the returned object and leave the local object as-is.

[!] is the optional letter '!'. If present: after receiving the current object, stop merging

any other objects returned, even if they otherwise should be.

[r I w] is either the letter 'r' or 'w'. 'r' means 'return the control to the caller', while 'w' means 'wait for more responses'. Keep in mind that all receptions of remote task execution responses are made in a separate goroutine (i.e. 'thread', sort-of) while the caller is blocked. The reception goroutine can unblock the caller thread at any time, especially it has an opportunity to do so after receiving each response.

[1-9] is a priority number from 1 (lowest priority) to 9 (highest priority), which is used to determine which return code to select as representing the overall multicast task call. Return codes with priority 9 will be chosen over return codes with priority 1.

If no default is given, ":m f is used as default.

'!' is implicit with ¥, i.e. once flow control is returned to the caller, no object gets merged

even if more responses are received. The reason is that the caller may destroy the object at any time, so it is not safe to access the object after this point.

For example, in the case where the called task can only return code#DONE and code#ERROR, a typical mcastCtl can be: {":mrl"} -> case 1: we are only interested in the first response (may be error or no error)

{"code#DONE:mwl", ":mr2"} -> case 2: we want all responses, unless there is an error (in this

case stop immediatly with code#ERROR). This can work well if each node fills a metadata group "meta#<peer>" or "meta#something.<peer>". In this case these groups will all be present at the end of the call (unless an error occurred).

{"code#DONE:mw2", ":wl"} -> case 3: wait for all responses. Ignore errors unless there are only errors.

{"code#DONE:mrl", ":rl"}— > case 4: in all cases return after the first reply.

[0197] The following table describes several examples of tasks and methods:

I return code#ALLOW or code#DENY.

[0198] FIG. 14 is a flow diagram of an example local content network system implementation using GET and POST to retrieve and publish local content 1400 in accordance with another embodiment, which may be used in combination with any of the embodiments described herein. In this example, elements (except for the first two of the GET and POST, i.e., Client Request and Create empty object, which are creating and preparing the internal object) are either a task or a method. Tasks begin at the circles marked Task: RX, Task: FETCH, Task: FETCH_LOCAL, and Task: PUSH_LOCAL. The example of FIG. 14 demonstrates how the response to an external event may be implemented (in this example, a client sends a GET or a POST to retrieve or publish local content). The system is further decomposed into finer grained tasks and methods. An example local content network publish/retrieve functionality is described wherein each content object is named using a hash of its data, and wherein a primary "authoritative node" is elected from among all nodes based on the content name. Furthermore, nodes opportunistically may cache all or any content passing through them. Referring to FIG. 14, the process starts with an HTTP handler dispatching a client request to task#RX, and the client request such as GET or POST implemented in extransport.go 1401 may be received, which may trigger a creation of an empty object with CVFS location from URL 1402 and may call task:RX 1403. Task:RX 1404 may then trigger method:RX 1405, which may execute resulting in code:DONE 1410. If there is an error (code:ERROR 1407) resulting in preparing HTTP Response 505, Internal Server Error 1408. If there is no method:RX found 1406, then Response 404 Not Found is prepared 1409.

[0199] Method:RX implementation in pubretrieval2.go 1411 may then be triggered. If the request is GET 1413, task: NAME_OBJECT 1415 and Task: FETCH may be triggered. If the result is code: NOT_FOUND 1423, HTTP Response 404 is returned 1425. If the result is code: FOUND 1424, HTTP Response 200 is returned with the object's data as the body 1426.

[0200] If the request is POST 1412, the multipart request nay be parsed

(filling the object's data and client provided metadata) 1414. Task: POLICY_INGESTION 1416 may be run, which results in the code being denied 1417 or allowed 1418. If allowed, the object type is set to data 1419, task: NAME_OBJECT 1420 is run, task: PUSH 1421 is run, and HTTP Response 200 is returned 1422.

[0201] FIG. 15 is a flow diagram of another example local content network system implementation using the task:FETCH to retrieve an object from the network and its inner methods/tasks 1500 in accordance with another embodiment, which may be used in combination with any of the embodiments described herein. Task:FETCH implemented in task.FETCH.lua 1545 may be triggered when an object is retrieved from the network. Task: FETCH_LOCAL 1507 may then be triggered and may then run task: FETCH_LOCAL, implemented in taskFETCH_LOCAL.lua 1525. Method: LOCAL_GET 1526 may then run. If the code is found 1527, code:FOUND is returned 1528. If the code is not found 1529, code:NOT_FOUND is returned 1530.

[0202] If method: LOCAL_GET implemented in storage. go executes 1531, it may read metadata and data files whose filepath is derived from FQID 1532. If any of the metadata or data file is found 1535, code:FOUND is returned 1536. If no metadata or data file is found 1533, code:NOT_FOUND is returned 1534.

[0203] The procedure may end if code is found 1508 and returns code:

FOUND 1509. If code: NOT_FOUND is returned 1510, method:LOCATE may be triggered 1511. If method: LOCATE implemented in pluginOBJECT_PLACEMENT.lua 1501 is executed, the first 4 digits of the FQID body (i.e. excluding the scheme part, cnshash/ABCD1234 -> ABCD in hex) 1502 may be retrieved, all peers from the configuration may be retrieved 1503, and an objected may then be allocated to a peer based on equal linear allocation of the 4 digits space between peers 1504, which may then be stored in meta. cache. authoritative 1505 resulting in code:FOUND 1506.

[0204] If there is no authoritative node 1512, code: NOT_FOUND 1513 is returned. If a remote node is authoritative 1514, remote invocation on a first authoritative node, task: FETCH_LOCAL may be run 1516. If the code is not found, code:NOT_FOUND is returned 1517. If code is found 1519, task: PUSH_LOCAL 1520 is run. The code:FOUND 1521 may then be run.

[0205] Task: PUSH_LOCAL 1522 implemented in taskPUSH_LOCAL.lua may then run. Method: LOCAL_STORE 1523 may then run and the code: STORED 1524. Method: LOCAL_STORE implemented in storage.go 1537 may run. If the object has no data 1539, the metadata is stored in the file, whose filepath is derived from the FQID 1543 and code: STORED 1544 is returned. If the object has data 1538, data is stored in the file, whose filepath is derived from FQID 1542. The mime-type of the file is guessed and meta. core. mime-type may then be set 1541, the metadata may be stored in the file, whose filepath may be derived from the FQID 1543 and code: STORED 1544 may be returned. If the meta. core. mime-type is already set 1541, the metadata may be stored in the file, whose filepath may be derived from the FQID 1543 and code: STORED 1544 may be returned.

[0206] FIG. 16 is a flow diagram of an example procedure for implementing task#FETCH 1600 in accordance with another embodiment, which may be used in combination with any of the embodiments described herein. An empty object may be created 1601. The object may then be fetched from local storage 1602. If it is fetched from local storage, the result may be returned 1603. If it is not in local storage, the object may be fetched from the network 1604, and the result may be returned 1605.

[0207] The following example code demonstrates an example implementation of the task#FETCH above, shown in the Lua programming language: - Task FETCH retrieves an object from the network (internal or remote storage)

- Predefined constants: TASK = "task#FETCH" and OID = internal object ID

local codeFetchLocal, textFetchLocal = cnsCallTask(OID, "task#FETCH_LOCAL")

- Exit now if object was found locally

cnsReturnIf(codeFetchLocal == "code#FOUND", "code#FOUND", "Object was found in local storage")

- Catch any error

cnsFailIf(codeFetchLocal ~= "code#NOT_FOUND", "Local task#FETCH_LOCAL failed with code=%s - text=%s", codeFetchLocal, textFetchLocal)

- Since it is not found locally, then attempt to get the object from another node...

- First, let's locate the authoritative node

local codeLocate, textLocate = cnsCallMethod(OID, "method#LOCATE") cnsFailIf(codeLocate ~= "code#FOUND", "code#ERROR",

"method#LOCATE failed with code=%s - text=%s", codeLocate, textLocate)

method#LOCATE placed authoritative node(s) in meta#cache#authoritative, let's get the first one

local authNode, ok = cnsGetObjectMetadata(OID,

"meta#cache#authoritative")

cnsFailIf(ok == false, "code#ERROR", "method#LOCATE failed to set meta#cache#authoritative")

- If we are authoritative, and if we don't have it, it's not in the network cnsReturnIf(cnsIsPeerRemote(authNode) == false, "code#NOT_FOUND", "Object was not found locally, although local node is authoritative...")

- A remote node is authoritative, let's fetch object from there

codeRemoteFetchLocal, textRemoteFetchLocal = cnsCallRemoteTask(OID, authNode, "task#FETCH_LOCAL", {"-", "+meta#id"}, {"+"})

cnsFailIf(codeRemoteFetchLocal == "code#ERROR", "Failed to retrieve object from authoritative remote node %s - text=%s", authNode, textRemoteFetchLocal)

- Exit now if the object was not found remotely

cnsReturnIf(codeRemoteFetchLocal ~= "code#FOUND",

"code#NOT_FOUND", "Object was not found on authoritative remote node %s", authNode)

- Since we got it, let's store it locally but we don't care if the operation succeeds or not. local codePushLocal, textPushLocal cnsCallTask(OID, "task#PUSH_LOCAL") cnsReturn("code#FOUND", "Object was found on remote node %s", authNode)

[0208] FIG. 17 is a flow diagram of yet another example local content network system implementation using various methods/tasks 1700 in accordance with another embodiment, which may be used in combination with any of the embodiments described herein. When task: POLICY_INGESTION implemented in taskPOLICYJNGESTION.lua 1701 is run, metadata may be checked 1702. If the check is satisfactory 1703, code: ALLOW 1704 may be returned. If the check is not satisfactory 1705, code: DENY 1706 may be returned.

[0209] When task: NAME_OBJECT implemented in taskNAME_OBJECT.lua 1707 is run, method: NAME_OBJECT 1708 may be run 1708 and code: DONE 1709 may be returned.

[0210] Method: NAME_OBJECT implemented in pubretrieval2.go may then be run 1710. A hash from the CVFS may be calculated 1711 and the FQID may be set to the cnshashn/,hash. 1712 and code: DONE 1713 may be returned.

[0211] When task: PUSH implemented in taskPUSH.lua is run 1714, task:

PUSH_LOCAL 1715 and method: LOCATE 1716 may be triggered. If the remote node is authoritative 1717, code: STORED 1718 may be returned. If a remote node is authoritative 1719, remote invocation on a 1^st authoritative node, task: PUSH_LOCAL is run 1720 may be run and code: STORED 1721 may be returned.

[0212] The following example source code is for an example implementation of an example task#POLICY_INGESTION:

- Predefined constants: TASK = "task#POLICY_INGESTION" and OID = internal object ID

val, ok = cnsGetObjectMetadata(OID,

"meta#clientprovided#somesecuritytoken")

cnsReturnIf(not ok, "code#DENY", "%s requires meta#chentprovided#somesecuritytoken", TASK)

cnsReturn("code#ALLOW", "") [0213] The following example source code is for an example implementation of an example task#NAME_OBJECT, which may call the local method method#NAME_OBJECT, and succeeds by returning code#DONE only if the method returns code#DONE:

- Predefined constants: TASK = "task#NAME_OBJECT" and OID = internal object ID

codeNamingNameObject, textNamingNameObject = cnsCallMethod(OID, "method#NAME_OBJECT")

cnsFailIf(codeNamingNameObject ~= "code#DONE",

"method#NAME_OBJECT returned code=%s - text=%s", codeNamingNameObject, textNamingNameObject)

cnsReturn("code#DONE", "Object meta#id#fqid is now set")

[0214] The following example source code for an example method#NAME_OBJECT, implemented in the Go programming language. In the below example code, "pobj" is a "plugin object", i.e., the handle of the object the method applies to. This example function calculates a hash value on the object's data and then sets the object "fully qualified ID" metadata using this value.

// methodlmplementationNameObject implements

method#NAME_OBJECT

func methodImplementationNameObject(pobj *pluginapi.PluginObject_t) (retCode string, retText string) { fqdn, path := pobj.CnsGetObjectCvfsLocationO var err error

var hashName string if hashName, err = pobj.CnsCalculateHash(fmt.Sprintf("%s@%s", fqdn, path)); err != nil {

return "code#ERROR", fmt.Sprintf("Failed to calculate hash - err=%+v", err)

}

if err = pobj.CnsSetObjectFqid(fmt.Sprintf("cnshashn/%s", hashName)); err != nil {

return "code#ERROR", fmt.Sprintf("Failed to set fqid - err=%+v", err) }

return "code#DONE", ""

}

[0215] Enabling optimized metadata-aware content networking (which may also be referred to herein as SDN-enabled metadata-aware routing) addresses some of the challenges identified above in the CNS system architecture described herein. As discussed above, SDN may be considered to be a possible underlying networking technology for CNS deployment. Accordingly, solutions may be based on SDN enhancements, including but not limited to enabling intermediate nodes to make routing decisions to forward or process messages/objects locally after accumulating only a few packets. For example, once a decision to forward is made, the accumulated packets may be forwarded immediately, and future packets of the same message may also be forwarded based on the previous routing decision. It is noted that the method and apparatus described herein for enabling optimized metadata-aware content networking does not imply that the CNS be implemented using a hop -by-hop forwarding/processing decision. For example, it may also be possible to use CNS to implement content and service networks where such forwarding/processing decisions occur at specific nodes only (e.g., ingress nodes, or dedicated request routing nodes). The outcome of the forwarding/processing decision may be to mark the packet, or to communicate with a controller that may configure the SDN network. In any case, as long as at least one CNS node performs a local forwarding/processing decision, the method and apparatus described herein for enabling optimized metadata-aware content networking may enable forwarding/processing, while minimizing impacts on end- to-end delay.

[0216] The method and apparatus described herein for enabling optimized metadata-aware content networking, may apply local and remote task calls to messages or objects that are structured with data and metadata sections. To enable caching and distributed processing, the RPC/ICN/service messages may be sent hop-by-hop. CNS may be aware of the format of the metadata sections, and therefore may use metadata values to make forwarding or local processing decisions. For example, one task is for the CRs to quickly make a decision between, local processing and forwarding. Accordingly, a CR may make a routing decision without the need to reassemble a full content object or message. Moreover, in the event that the decision is made to forward a message, this forwarding operation would be able to be done as efficiently as possible and in particular would not require copying data more often than necessary.

[0217] In an example ICN network, the objects or messages may be individually exposed to the network. The ability to efficiently add specific flow entries may be relevant for large objects or messages sent using several packets, e.g., to avoid incurring undue per-hop latency. However, determining how to configure these flow entries may require accessing metadata included in the object/message. Accordingly, the method and apparatus described herein for enabling optimized metadata-aware content networking combines both efficiency and metadata awareness.

[0218] The method and apparatus described herein for enabling optimized metadata-aware content networking is illustrated using the examples described below, which for exemplary purposes include various assumptions. It may be assumed, for example, that messages/objects may be identified by SDN flow entries: e.g., matching a hash value field for specific messages/objects; e.g., each packet which is a component of a message may have a fixed length header which includes a message/object ID which is unique within the network for a long enough duration (by itself or when combined with other fields).

[0219] It may also be assumed, for example, that a more general flow entry

(or set of flow entries), e.g., matching a protocol number, may be used to match all other messages/objects by default.

[0220] In order to avoid the indefinite growth of flow tables, individual message/object flow entries may need to be added dynamically when needed, and later removed. This may be made possible in OPENFLOW specifications, by associating a time-out value with an entry (e.g., an inactivity time out).

[0221] Large objects/messages may be fragmented (e.g., by the source and/or intermediate network elements). In this case, the payload may be gradually reassembled in a CR, until enough of the message/object is present to hold the metadata needed to take a routing decision. Alternatively, such large objects may be segmented by the source. In this case, the object and its metadata may be packaged into individual messages sent in different packets. Initial segments may contain the metadata needed to determine a routing decision. Hybrid solutions mixing segmentation and fragmentation are also possible.

[0222] FIG. 18 is an example diagram of the packet encodings and the packet and message or object structure 1800 that may be used in an embodiment of the method and apparatus for enabling optimized metadata-aware content networking (SDN-Enabled Metadata-Aware Routing), which may be used in combination with any of the embodiments described herein. As shown in FIG. 18, each message or object 1803 may include packets 1802 that each include a packet header 1801. The message or object 1803 may also include a message/object header 1804 and a message/object fixed header 1805. Each packet payload 1812a, 1812b, and 1812c may include portions of the message object header 1814 and message object 1813. The message object header 1814 may include a fixed header 1816 and metadata sections 1815. The fixed header 1816 may include a length of metadata sections 1817.

[0223] Using the packet encodings and the packet and message or object structure 1800, the SDN/OpenFlow flow entries may be matched at the packet level, e.g., by using a field or set of fields in the packet headers 1811a, 1811b, and 1811c to uniquely identify the message and/or content object, which in this example is the message/object ID 1810. The local network stack may reassemble packet payloads 1812a, 1812b, and 1812c until enough information is available for the local network stack to make a decision on whether to forward the packets or locally process the packets. For example, the CNS daemon, or a socket from which it reads, may perform this reassembly. The message/object fixed header 1805, holding a length of metadata sections 1817 attribute, may be used to learn the number of bytes required to enable CNS to make a decision. This may be especially so if variable metadata section lengths are supported. Otherwise, CNS may simply accumulate a fixed number of bytes before using the buffered contents to make a routing decision. In this example, CNS would accumulate either the full message/object header 1803 or a given number of metadata sections from the message/object header 1803 in a local buffer in order to perform a routing decision.

[0224] FIG. 19 is a diagram of an example flow of data 1900 in an SDN

Forwarding Element (FE) within a content router that enables optimized metadata-aware content networking (SDN-Enabled Metadata-Aware Routing) in accordance with the embodiments described herein. The FE 1901 may include flow tables 1903, a local application 1904, and a processor or other entity configured to execute actions 1905. The FE is also in communication with an SDN controller 1902 in the network via the OPENFLOW protocol.

[0225] In the example of FIG. 19, arrows indicate general data flow direction (i.e., not a specific sequence of actions) and various communication paths within the FE. Received packets 1906 may be processed through the flow tables 1903, and actions may be decided for each received packet 1906. The actions (e.g., forwarding, dropping, etc.) then may be executed 1905. Supported actions may include forwarding on the local port 1909, which may be used to communicate with the local application 1904 (e.g., the CNS daemon). Packets which are not matched in the flow tables 1903 may be sent to the SDN controller 1902 for a decision. The SDN controller 1902 may respond, e.g., to add a new flow entry forwarding the new flow's packets.

[0226] However, instead of having the SDN controller 1902 make a routing decision, the FE 1901 may enable a CNS forwarding/processing decision by sending an inquiry when no match is found 1907 in the flow tables 1903 to the local application 1904 (e.g., the CNS daemon) to make the routing decision. The local application 1904 may need to receive more than one packet on that particular message/object in order to have enough information to make a routing decision. Once a decision is made, a response 1908 may be returned from the local application 1904 to the flow tables 1903 (e.g., including an indication to add a new flow entry to the flow tables 1903 matching this particular message/object). Accordingly, the local apphcation 1904 (e.g., the CNS daemon) may act both as a control plane entity (e.g., to make the routing decision and communicate over the interfaces provided in this embodiment) and a data plane entity (e.g., when receiving from the local port 1909). The local apphcation 1904 (e.g., the CNS daemon), when used as a data plane entity, may, for example, pass the data flow up to an application specific plugin in charge of processing the data object.

[0227] FIG. 20 is a flow diagram of an example process 2000 for enabling optimized metadata-aware content networking (SDN-Enabled Metadata-Aware Routing), which may be performed by a network node including but not limited to the content router described above and which may be used in combination with any of the embodiments described herein. The process 2000 of FIG. 20 may be performed to minimize the number of packets that need to be received before a network node can make a routing decision. While each step of the process 2000 in FIG. 20 is shown and described separately, multiple steps may be executed in a different order than what is shown, in parallel with each other, or concurrently with each other. Referring to FIG. 20, the network node (e.g. content router), which may include the FE as described above, may enter a default flow entry in a flow table in the FE to catch all ICN requests 2001 and match all messages/objects which were not previously matched on a per-message/object basis. This flow entry may match certain criteria of the packet, e.g., UDP port, CCN packet type, RPC, etc. This flow entry may point to a new LOCAL_CONTROLLER port (which may be proposed as a new reserved port in the OpenFlow specifications) with a given port number.

[0228] The LOCAL_CONTROLLER port may act like the CONTROLLER port, except it may be attached to a local port. LOCAL_CONTROLLER may be associated with a local port number used for control plane, and LOCAL may be associated with a local port number used for data plane.

[0229] An alternative implementation may use only the LOCAL port. In this case, the LOCAL port may be used as a data plane port, i.e., the packets may be forwarded to this port (i.e., no "Packet In" message). The local application may otherwise act similarly to what is described in this algorithm.

[0230] LOCAL_CONTROLLER may clearly separate the data path and control path roles of the local application and may enable reuse of the existing OpenFlow protocol over this port. The LOCAL_CONTROLLER approach may also enable a more efficient "reinjection" of packets already received for forwarding. While the packets transferred over the LOCAL port may need to be copied when sent back to the FE function, this operation may not involve a copy when using LOCAL_CONTROLLER, since a reference to a buffer holding the packet may be passed back and forth in OpenFlow messages. The LOCAL_CONTROLLER approach may avoid out-of-order packets when later reinjecting packets to be forwarded. The operation to re-inject packet and forward any new packets may be atomic and may ensure that all re-injected packets are forwarded before any new packets are forwarded. In contrast, if packets are reinjected after setting the new forwarding rule, a race condition may occur.

[0231] Therefore, in the remaining description of the example process 2000 of FIG. 20, a separate LOCAL_CONTROLLER+LOCAL port solution is described. It is understood that "Packet In" messages may be replaced with sending the packet over the LOCAL port, and "Packet Out" messages may be replaced with sending the packet back over a data plane socket.

[0232] Referring to FIG. 20, the network node may then run a local application (e.g., CNS daemon) that may create a socket to listen 2002 on the control plane and/or data plane port.

[0233] On a condition that a packet from an unknown message/object is received, the network node may match the packet to the default flow entry 2003. This may include the FE engine sending a Packet In message to the LOCAL_CONTROLLER port.

[0234] The network node may send an indication, such as a Packet In message, to the local application 2004 indicating that the packet was received. The local application may then access the content of the packet (through its buffer ID or the Packet In message) and may determine whether metadata in the packet enables a routing decision 2005. As described above, this may include determining whether a fixed number of bytes has been accumulated or determining whether enough payload has been received in order to make a routing decision based on the metadata in the payload.

[0235] For example, the content router may determine, via the local application, whether a given number of bytes (which may be referred to as min_bytes_for_routing_decision) has been received or whether the whole object/message has been received. The given number of bytes, min_bytes_for_routing_decision, may be known a priori based on the message encoding. For example, it may be prescribed that the RPC message or object encoding include all relevant metadata within the first 5 kilobytes of the message. In another example the given number of bytes, min_bytes_for_routing_decision may be obtained from a header which may be present in the initial packet or initial X bytes of a message (where X is a known constant).

[0236] If not enough payload or other information was received, the local application may buffer the information and wait for more packets. In case of an error, such as a time out, an action may be taken (e.g., drop and report to a controller).

[0237] On a condition that a routing decision is enabled, the network node may determine a routing decision 2006 based on metadata in the received packet or other information. This may include the local application extracting the metadata present at least partially in the received payload to make a decision based on the extracted metadata. As discussed above, the extracted metadata may be present in packets forming the beginning of the message/object. The routing decision may include but is not limited to forwarding to one or more nodes, processing locally, dropping the message/object, or a combination of decisions. When determining a routing decision 2006, the local application (e.g., CNS daemon) may involve remote entities to assist in making the routing decision. Also, if applicable, the local application may send Packet Out messages for each packet that it already received for this object/message, e.g., to indicate that these messages should be forwarded. The network node may then route the packet based on the routing decision 2007, which as described above may include forwarding to one or more nodes, processing locally, dropping the message/object, or a combination of decisions.

[0238] The local application may also interact with the local SDN stack accordingly, such as by re-injecting packets, adding new entries to the flow tables of the FE, etc. For example, the local application may send an OFPC_ADD message to the FE, adding an entry matching the packets for the message/object associated with the appropriate action(s). This new entry may typically be associated with a time out, e.g., as enabled by OpenFlow specifications, so that the entry may be removed when the message/object transmission is completed. The local application may also send an OFPC_ADD message to the FE, adding an entry matching the (future) response object/message to be forwarded back, e.g., to the next hop towards the original requester. These messages may be sent in various ways (e.g., over a socket connection to the local FE, over local function calls, etc.). These commands may be sent separately or may be collapsed into a single message OFPC_REINJECT (re-injected packet IDs, new rule(s)). Upon reception, the FE engine may add the new rule(s), re-inject the packets in the stack, while buffering any incoming packet matching one of the new rules until all re-injected packets have been fully processed by the FE engine. As discussed above, this mechanism may avoid out-of-order packets when new packets are received during this re-configuration/injection. [0239] An alternative to the process 2000 described above may be performed when there is enough information received to make the routing decision and when the decision is to process locally. For example, the local application (i.e. CNS daemon) may not send packet-out messages for each of the packets already received but instead may transfer the packets already received to its data plane component in charge of processing the object (e.g., by transferring ownership of the existing receive buffer used for the routing decision). Message(s) to add entry(ies) in the SDN FE function may still be sent to enable proper forwarding (to local CNS daemon) or request and/or response.

[0240] It is noted that the process 2000 described above may be applied to a content or processing request. Various techniques may be used to ensure that the response is properly sent back to the initial requester. Such techniques may include, for symmetrical request/response paths, "bread crumbs" (i.e., the state is maintained on intermediate nodes, such as a flow entry, as described in the algorithm above), "source routing" (i.e., intermediate hops are recorded in the request and reused in the response). If asymmetrical path is acceptable, and if a protocol such as IP is used, the IP address of the original requester may be provided in the request, and used as a destination of the response (i.e. in this case the request is to be routed through the CRs as discussed above, and the response may be routed using IP routing).

[0241] The CNS architecture discussed herein may enable hop-by-hop transport of content and processing requests. As illustrated above, each CR may make a local decision to process locally or forward a request, which may not provide a guarantee that the same CR will be serving the response of two similar requests. However, in some cases it may be necessary for several requests to be processed by the same serving CR (e.g., as part of an application-level transaction). Some weak form of session may therefore be necessary.

[0242] FIG. 21 is a flow diagram of an example process 2100 for enabling a weak session in accordance with one embodiment, which may be used in combination with any of the embodiments described herein. While each step of the process 2100 in FIG. 21 is shown and described separately, multiple steps may be executed in a different order than what is shown, in parallel with each other, or concurrently with each other. The term "weak session" is used herein in the sense that a guarantee that the same network-side instance will handle a requested message, but beyond this, any actual session state may be under the responsibility of the service/application itself and may be out of the scope of this mechanism. The weak session is a session-like feature where the same network- side service instance may serve multiple requests from the same client, if the client requests it. The weak session methods and apparatuses described herein may also mitigate some possible security issues.

[0243] Referring to FIG. 21, one of the two end points (requester or serving

CR) may receive a request for a weak session 2101. Alternatively or additionally, one of the two end points (requester or serving CR) may initiate the weak session. The initial request and/or response for the weak session 2101 may be used to carry the session ID. Alternatively the request for the weak session may include only a flag requesting a session from the serving CR.

[0244] The requester or serving CR may then generate a session ID 2102, and add this session ID to the packet headers or metadata 2103 exchanged within this session. Regardless of whether the serving CR initiated or received a request for the weak session, a response may include the session ID. The requester or serving CR may then send the session ID using a header field or metadata 2104 attached to the object/message to the other end point. In the following, it may be assumed that the session ID is set in a packet header field, which makes it possible for SDN devices to match each packet. If metadata is used to store the session ID, the weak session mechanism described below may be combined with the metadata-based mechanism described above to obtain a similar result. Each CR traversed by the response may therefore set its internal state to enable forwarding of upstream and downstream packets of this session (e.g., a flow entry). From this point on, the original requester and the original serving CR may mark packets with this session ID (e.g., may set the session ID in a packet header field) to enable 2-way communication between them.

[0245] From the standpoint of the chent application, which may be connected to a front-end node, signahng between client and front end may support a weak session feature, such that the actual client application may be in control of the weak session (e.g., providing a way to request a session ID, and providing a way to set the session ID) and may receive information from the serving CR (e.g., the session ID). The actual decision to request a weak session, use a session ID to maintain the weak session, and then stop using it, may be part of the application logic. The chent application typically may be CNS aware, may use weak sessions as a tool to minimize the coupling between client and server, and may allow CNS to move server instances when needed. A programmatic API (e.g., a JavaScript library) may be used to insulate the client - front-end communication details from the client application code.

[0246] Weak sessions may not be CNS specific and may be useful in any

ICN network. In the context of an ICN network different from CNS (e.g., without the concept of a front-end, i.e., where end points are CRs or directly connected to CRs) a similar programmatic API may be provided to enable applications to control weak sessions.

[0247] The weak session mechanism may run in each CR of the content network and as described above may enable session IDs to be requested, generated, and used to ensure that the same serving CR is reached by requests with the same session ID. This may be generally applicable to ICN networks. The API offered by the CNS front ends to chent applications may enable using weak sessions in CNS, as well as a higher level programmatic API for weak session control and may be apphcable to CNS or more generally ICN programs.

[0248] FIG. 22 is a flow diagram of an example process 2200 for enabling a weak session mechanism inside the CNS Network, which may be implemented by a CR on the path of the response message in a weak session and which may be used in combination with any of the embodiments described herein. While each step of the process 2200 in FIG. 22 is shown and described separately, multiple steps may be executed in a different order than what is shown, in parallel with each other, or concurrently with each other. A weak session may be enabled between a requester CR and a serving CR. The requester CR typically may be a front end CR, which may provide a REST API to IP clients and may form a bridge between the IP network and the CNS content network. The serving CR may be the CR running the requested service task for the requester.

[0249] The packet format may include a session ID information element, which may be required to be present in messages. For example this may be a fixed header field holding a session ID, or a header extension (e.g., an optional IPv6 extension header), or be encoded as a metadata information element (e.g., HTTP header field). An intermediate SDN device (e.g., OpenFlow Forwarding Element) may be able to access the value of such session ID field. It may be expected that the extent of match fields supported by OpenFlow, for example, will continue to grow. Moreover, it may also be expected that SDN will evolve to support more flexible definitions of match fields, which may enable support for new protocols without requiring new releases of the OpenFlow protocol.

[0250] The SDN forwarding mechanism may include an assumption that the CNS platform (CNS daemon program) is running on an SDN Forwarding Element. The SDN forwarding may or may not be used for non-session messages, in particular it may not be assumed that the mechanism described above regarding SDN-enabled metadata-aware routing is used, though these mechanisms should be compatible.

[0251] For purposes of the following, the same "send to

LOCAL_CONTROLLER" action as described regarding SDN-enabled metadata- aware routing may be assumed. Similarly, a LOCAL port also may be used alternatively.

[0252] The end point algorithm as described above to enable session IDs to be requested, generated, and used may include a first case, where a client may decide to initiate a weak session by setting a flag (in packet header, message header or object/message metadata). The serving CR may decide to accept or refuse the weak session. If the serving CR refuses, it may communicate the reason for refusal in a packet/message field or metadata. In a second case, a client may send a message/object as usual. The serving CR may decide to set up a weak session.

[0253] In either case, assuming the serving CR decides to setup the session, it may generate the session ID, or use the provided session ID in accordance with the any of the methods described herein. This may be a unique session ID (by itself or in combination with other information elements of the response). This session ID may be set in each packet sent as part of the session and may be renewed periodically by the serving CR. For example, if the serving CR is about to send a response with a session ID that is older than 5 seconds, it may regenerate a new session ID to replace it. Upon reception, the client may update the old session ID with the new one in its internal state, for future use. The role of this renewal may be to reduce the impact of denial of service attacks that would target a fixed session ID.

[0254] The session ID may also have to be unique in the network, for a certain amount of time. Accordingly, for this reason and/or as other possible security concerns, it may be assumed that the client should not generate the session ID. The session ID generation method may concatenate a node ID, an incremental ID and a random component, to obtain an ID which is both unique and difficult to guess by attackers.

[0255] Referring to FIG. 22, the CR may set a default flow entry (or set of entries) to match all content/processing request and response packets that have a non-zero session ID field in the header and associate it with a local port 2201. For example, the default flow entry may be associated with a "send to LOCAL_CONTROLLER" action (with a given local port specification, e.g., protocol and port number). Other specific rules may be added, and this default flow entry may be a "catch-all". An example order of flow entry processing may be: [0256] (1) For flow entries that match a fixed session ID, (a) requests with a fixed session ID may be forwarded upstream (see below how the forwarding destination is determined), and (b) responses with a fixed session ID may be forwarded upstream (see below how the forwarding destination is determined).

[0257] (2) For one or more flow entries that match any unknown non-zero session ID associated with a "send to LOCAL_CONTROLLER" action, typically a single entry matching both non-zero session ID and "response" message types may be used. Possibly, multiple entries may be needed if several message types were eligible to hold the initial session ID (e.g., responses and indication messages).

[0258] (3) Flow entries that match non-session messages, if any.

[0259] The CR may run a local application (e.g. CNS daemon program) that listens on the specified local port 2202. On a condition that a packet is received that matches the unknown non-zero session ID flow entry, the CR may send an indication, such as a Packet In message, to the local application 2203 indicating that the packet was received. For example, the CR may send a "Packet In" message to the LOCAL_CONTROLLER port. The Packet In message may include the received packet or a reference to a buffer where it is stored locally. Alternative mechanisms may be used to communicate the packet to the CNS daemon (e.g., forward over the LOCAL port). Typically, this action may be restricted to responses objects/messages. Unknown session IDs in requests may be considered erroneous and dropped/logged.

[0260] Upon reception of the Packet In message, the CNS daemon may check for authorization for the session ID 2204. Checking for authorization for the session ID 2204 may include using information such as object/message type, object's CVFS path, object's domain name, method or task name, signature, etc., and local policy. The local policy may include an access list white/blacklisting domains and/or associating domain names with cryptographic keys enabling verification of a signature of the session ID by the serving CR. Objects/messages holding unauthorized sessions may be dropped and logged, or other actions like communicating with a controller may be performed to further check authorization.

[0261] The CR may then determine a routing decision of the packet based on its internal state and/or flow entries 2205. This may include the local application (e.g. CNS daemon program) inspecting its internal state and/or the existing flow entries to determine where the packet P referred by the Packet In should be forwarded.

[0262] As described above regarding SDN-enabled metadata-aware routing, routing of responses may be based on various techniques, such as breadcrumbs, source routing, asymmetrical routing, and symmetrical cases. Using breadcrumbs, (i.e., response routing state is maintained in intermediate routers while routing the request) the local application (e.g. CNS daemon program) may retrieve this information locally (e.g., from a "pending interest table" or equivalent table). Using source routing, (i.e., response routing state is maintained in the packet) the local application (e.g. CNS daemon program) may retrieve this information from the packet itself. Using symmetrical routing, (e.g., response uses IP routing while requested used hop-by-hop interest routing) routing information may be retrieved from the packet and/or the router (e.g., IP address and routing table). In symmetrical cases, the local application (e.g. CNS daemon program) may now be aware of next hops for all requests and response packets using this session ID.

[0263] The local application (e.g. CNS daemon program) may use this next hop information to enter new flow entries matching session ID and other packet fields (e.g., message type), and forwarding the packet towards the next hop. For example, the CNS daemon may add an entry matching packet with "type = response" and with given session ID, forwarding towards next hop identified for the current response packet. Alternatively or additionally, the CNS daemon may add an entry matching packet with "type = request" and with given session ID, forwarding on ingress port of current response packet. If the current response packet was locally generated (i.e., this CR is the serving CR), then the flow entry may forward on LOCAL port, where the CNS daemon listens for data plane packets.

[0264] The CNS daemon also may send a Packet Out to the FE control function so that the current response packet is appropriately forwarded

[0265] A similar procedure may be used in the case where routing of requests and responses is asymmetrical (e.g., IP routing is used for responses). A single CR may run this procedure for the asymmetrical case for a given response. Typically, an egress CR (i.e., egress point of the content/service network) may be used for this. The CR may not modify its own FE configuration. Instead, it may communicate with a controller, which may then define a path between the ingress CR(s) and the serving CR and then may configure all required CR/FEs with the appropriate rules matching only requests with the given session ID. The requests may be forwarded towards the Serving CR, which may be known, e.g., as holding the source IP address of the response message. Alternatively, some form of packet tagging/marking may be performed by the CR instead of modifying the network configuration through a controller.

[0266] Various security concerns may arise. For example, a malicious client or group of clients may attempt to reuse session IDs as a form of DoS attack. Front end nodes may maintain a mapping between session IDs and clients and may filter out packets using unknown session IDs. Even if this measure is not used, renewal of session IDs may ensure that a reused session ID becomes obsolete rapidly.

[0267] Security issues may also be introduced by a malicious CR. Like any

ICN network, CNS may rely on hop-by-hop forwarding and processing of messages. A malicious CR may simply drop requests or may reply with erroneous data. Addressing these concerns may include establishing trust between CRs before enabling cooperation between them. The impact of using session IDs may not increase the risk.

[0268] The mechanism described above enables a weak session between a requester CR, typically a front end node, and a serving CR. From the application standpoint, the end points of the weak session may include, on one side, the task running on the serving CR, and on the other side, the client application running on the IP device connected to the front end node. This connection typically may be over hypertext transfer protocol (HTTP) or HTTP Secure (HTTPS).

[0269] The font-end node may therefore provide an API, such as the exemplary API described below, which uses HTTP headers.

[0270] In this example API, requests may use "Weak-Session: 0" to request a weak session from the CNS network front-end. The request may be used as follows:

[0271] (1) Source: Client Application.

[0272] (2) Reason for use: the client application wishes several future requests to be handled by the same server-side application instance (e.g., for login).

[0273] (3) Destination: Front-End node\Action: set weak session ID to 0 in request packets sent into the content network, as per the mechanism described in the previous section.

[0274] Replies from the CNS network front-end may include "Weak-

Session: ID" where the ID is an identifier different from '0' (e.g., composed of a combination of letters and numbers). The replies may be used as follows:

[0275] (1) Source: Front-End node.

[0276] (2) Reason for use: the front end node may have received a response from the content network, including the given session ID. It is noted that this header may be returned even if a weak-session ID was not requested (i.e., it can be spontaneously set by the server-side instance). In any case it may be the responsibility of the client application to use this ID or not later.

[0277] (3) Destination: Client Application.

[0278] (4) Action: keep the session ID for future use (e.g., typically a CNS client JavaScript library may do this).

[0279] Another example request to use "Weak-Session: ID" with an ID different from '0' may be used as follows: [0280] (1) Source: Client Application.

[0281] (2) Reason for use: the client application may wish for this request to be handled by the same server-side application instance as other requests with the same session ID (including the request which includes weak-session ID '0' which returned this session ID).

[0282] (3) Destination: Front-End node.

[0283] (4) Action: set the ID in request packets sent into the content network, as per the mechanism described in the previous section.

[0284] Alternative equivalent APIs may be used, including for example using separate messages over HTTP (e.g., POST /weaksession/startsession to start a weak session and POST /weaksession/stopsession to go back to usual session-less behavior).

[0285] Application code may be running in the front-end to have explicit support for weak sessions, because the URL space of the application may be used for those control requests. For example, URLs under http://myapp.com/weaksession may be used for handling the weak session. For this reason, the more transparent use of an HTTP header may be needed.

[0286] The programmatic API for client applications may include mirroring this communication API. The following is sample JavaScript code for sending

GET requests, and it is noted that the code listed below is not a complete program. In particular, the code which ties the call to DoActionlO, DoAction20 and DoAction30 to events such as clicking on a button is not included, but may use various techniques. Similarly the code processing the response is not of interest here and is omitted.

var xmlHttp = null;

var weakSessionld = null;

// We want action 1 and action 2 to be processed by the same server-side instance // Action 3 may be processed by any server-side instance

Function DoActionlO

{

xmlHttp = new XMLHttpRequestO;

xmlHttp.initiateWeakSessionldO; //initiates a weak session

xmlHttp. xmlHttp.o en( "GET", "/some/application/url", true ); // true for 'asynchronous'

xmlHttp.send( null );

}

// This function processes the response from the front-end node function ProcessRequestlO

{

if ( xmlHttp.readyState == 4 && xmlHttp. status == 200 )

{

// (...) process the response

weakSessionId = xmlHttp. weakSessionId; // non-0 if session ID was set

}

}

Function DoAction20

{

xmlHttp = new XMLHttpRequestO;

xmlHttp. weakSessionId = weakSessionId; // same weak session as for action 1

xmlHttp.

xmlHttp. open( "GET", "/some/application/url2", true );

xmlHttp. send( null );

}

// This function processes the response from the front-end node function ProcessRequest20

{

// (...) process the response

}

Function DoAction30

{

xmlHttp = new XMLHttpRequestO;

// weakSessionId is not set: any server-side instance may process the request

xmlHttp.

xmlHttp. open( "GET", "/some/application/url3", true );

xmlHttp. send( null );

}

// This function processes the response from the front-end node function ProcessRequest30

{

// (...) process the response

} [0287] As described in this code sample, the XMLHttpRequest object (a standard JavaScript object) may be enhanced with an additional method initiateWeakSessionldO, (which caused the browser to add a "WeakSession: 0" header in the request) and/or an additional property weaksessionid, which may be set to a value prior to sending the request. This may have the effect of adding a "WeakSession: n" header in the request, where n is the value of the weaksessionid property. This may be set by the browser to the value of the "WeakSession:" header present in the reply, if any (the browser should set the property to null if no such header is present).

[0288] FIG. 2300 is a flow diagram of an example process 2300 for establishing a weak session, which may use the example weak session API described above and which may be used in combination with any of the embodiments described herein. While each step of the process 2300 in FIG. 23 is shown and described separately, multiple steps may be executed in a different order than what is shown, in parallel with each other, or concurrently with each other. Further, in FIG. 23 arrows may represent multiple messages at different times.

[0289] The example of FIG. 23 includes the WTRU running the client application 2301, the front end node 2302, and serving nodes 2303 and 2304. When the client initiates the first request (Action 1 in the example code above), the WTRU running the client application 2301 may send HTTP GET with header "WeakSession: 0" (2311). The front end node 2302 may include a weak session ID in the packets it forwards to the next hop, e.g., inside an IPv6 extension header (2312). The packet may be forwarded through the content network, based on forwarding/processing logic implemented over CNS (2313, 2314). The serving node 2303 (e.g a CR as described above) may process the request, generate a session ID, and send a response including the weak session ID (2315). Along the way, the intermediate CRs, including the front end node 2302, configure their flow table as described above (2316, 2317). The front end node 2302 may generate an HTTP response based on the response from the CNS serving CR, and including "WeakSession: n" where n is the weak session ID value from the packets transporting this response (2318). Upon reception the WTRU running the client application 2301 may save the weak session ID for later use.

[0290] The WTRU running the client application 2301 may then send another request (Action 2 in the example code above). The WTRU running the client application 2301 may send HTTP GET with header "WeakSession: n", where n is the weak session ID saved from earlier (2301). The front end node 2302 may forward the request setting the Weak Session ID inside the packets. Intermediate CRs may forward the packets based on this weak session ID (2312, 2313, 2314) The response may be sent back similarly to the previous case (2315, 2316, 2317, 2318).

[0291] The WTRU running the client application 2301 may then send another request (Action 3 in the example code above). This time, no weak session HTTP header is set, and therefore no weak session ID is set in packets transporting the request and response inside the content network. As a result, a different serving node 2304 CR may be selected. The full path in this example is 2312, 2313, 2319, 2320 for the request, and 2321, 2322, 2316, 2317, and 2318 for the response.

[0292] Although features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer- readable media include electronic signals (transmitted over wired or wireless connections) and computer-readable storage media. Examples of computer- readable storage media include, but are not hmited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

^• * *

Claims

CLAIMS What is claimed is:

1. A method for use in a network node, the method comprising:

entering a default flow entry in a flow table to catch Information Centric

Networking (ICN) requests;

creating, via a local apphcation, a socket to hsten on a port associated with the local application for packets;

on a condition that a packet of an unknown message is received, matching the packet to the default flow entry;

sending an indication to the local application that the packet was received; determining, via the local application, whether metadata in the packet enables a routing decision;

on a condition that the routing decision is enabled, determining the routing decision based on the metadata in the received packet; and

routing the packet based on the routing decision.

2. The method of claim 1, wherein the routing decision is to forward the packet to another network node.

3. The method of claim 1, wherein the routing decision is to process the packet locally.

4. The method of claim 1, wherein the routing decision is to drop the packet.

5. The method of claim 1, further comprising:

updating the flow table with the routing decision.

6. The method of claim 1, further comprising: receiving a request for a weak session;

generating a session ID; and

adding the session ID to a packet header in the received packet.

7. The method of claim 6, further comprising:

checking authorization for the session ID.

8. The method of claim 1, further comprising:

receiving a request for a weak session;

generating a session ID; and

adding the session ID to the metadata in the received packet.

9. The method of claim 8, further comprising:

checking authorization for the session ID.

10. The method of claim 1, wherein the network node is a content router.

11. The method of claim 1, wherein the port associated with the local application is used for a control plane and data plane.

12. A network node comprising:

a processor configured to enter a default flow entry in a flow table to catch Information Centric Networking (ICN) requests;

a local application configured to create a socket to listen on a port associated with the local application for packets;

a receiver configured to receive incoming packets;

on a condition that a packet of an unknown message is received, the processor further configured to match the packet to the default flow entry; a transmitter configured to send an indication to the local application that the packet was received;

the local application further configured to determine whether metadata in the packet enables a routing decision;

on a condition that the routing decision is enabled, the processor further configured to determine the routing decision based on metadata in the received packet; and

the transmitter further configured to route the packet based on the routing decision.

13. The network node of claim 12, wherein the routing decision is to forward the packet to another network node.

14. The network node of claim 12, wherein the routing decision is to process the packet locally.

15. The network node of claim 12, wherein the routing decision is to drop the packet.

16. The network node of claim 12, further comprising:

the processor further configured to update the flow table with the routing decision.

17. The network node of claim 12, further comprising:

the receiver further configured to receive a request for a weak session; the processor further configured to generate a session ID; and

the processor further configured to add the session ID to a packet header in the received packet.

18. The network node of claim 17, further comprising: the processor further configured to check authorization for the session ID.

19. The network node of claim 12, further comprising:

the receiver further configured to receive a request for a weak session; the processor further configured to generate a session ID; and

the processor further configured to add the session ID to the metadata in the received packet.

20. The network node of claim 19, further comprising:

the processor further configured to check authorization for the session ID.

21. The network node of claim 12, wherein the network node is a content router.

22. The network node of claim 12, wherein the port associated with the local application is used for a control plane and data plane.

23. A method for use in a network node, the method comprising:

entering a default flow entry in a flow table to match request and response packets that have non-zero session ID;

creating, via a local application, a socket and hsten on a port associated with the local application;

on a condition that a packet is received that matches the non-zero session ID default flow entry, sending an indication to the local application that the packet was received;

determining, via the local application, whether the session ID is authorized; and

on a condition that the session ID is authorized, determining a routing decision.

24. The method of claim 23, wherein the network node is a content router.