WO2017004508A1

WO2017004508A1 - Reducing the end to end latency in an http-over-icn scenario

Info

Publication number: WO2017004508A1
Application number: PCT/US2016/040671
Authority: WO
Inventors: Dirk Trossen
Original assignee: Idac Holdings, Inc.
Priority date: 2015-07-02
Filing date: 2016-07-01
Publication date: 2017-01-05

Abstract

Systems and methods for reducing rendezvous (RVZ) delay are provided including receiving at a client network attachment point (cNAP) an indication of a forward path and an indication of a return path to a server network attachment point (sNAP). Systems and methods are provided for encapsulating a received hypertext transfer protocol (HTTP) request, the indication of the forward path, and the indication of the return path into an information-centric networking (ICN) packet and for publishing the ICN packet as an appropriately formed named information item. The cNAP may provide an internet protocol (IP) network interface toward an IP-only device. The formed named information item may contain content data corresponding to the received HTTP request. The sNAP may receive a publication message including information from the cNAP and locally perform an RVZ function in response to receiving the publication message. Systems and methods for proxying an HTTP response are also provided.

Description

REDUCING THE END TO END LATENCY IN AN HTTP-OVER-ICN

SCENARIO

CROSS REFERENCE TO RELATED APPLICATIONS

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

Application No. 62/188, 144 filed July 2, 2015 and U.S. Provisional Application No. 62/191,060 filed July 10, 2015, the contents of which are hereby incorporated by reference herein.

BACKGROUND

[0002] Information-centric networking (ICN) constitutes a new paradigm in which content is exchanged by means of information addressing, while connecting appropriate networked entities that are suitable to act as a source of information toward the networked entity that requested the content. Such content may include, but is not limited to, voice, data, image, video, messaging and broadcast content and the like.

[0003] Architectures have been proposed in this space, which may require the partial replacement of current network infrastructure in order to realize desired network-level functions. Migration scenarios have been proposed whereby architectures could be realized as an overlay over existing architectures, e.g., internet protocol (IP)-based or local Ethernet-based architectures.

SUMMARY

[0004] Systems and methods for reducing rendezvous (RVZ) delay are provided including receiving at a client network attachment point (cNAP) an indication of a forward path and an indication of a return path to a server network attachment point (sNAP). Systems and methods are further provided for encapsulating a received hypertext transfer protocol (HTTP) request, the indication of the forward path, and the indication of the return path into an information-centric networking (ICN) packet and for publishing the ICN packet as an appropriately formed named information item. The cNAP may provide an internet protocol (IP) network interface toward an IP-only device. Also, the formed named information item may contain content data corresponding to the received HTTP request.

[0005] Further, the sNAP may receive a publication message including information from the cNAP and locally perform an RVZ function in response to receiving the publication message. The information may include a node identifier that indicates node information suitable for a receiver of the response. The node identifier may be used to determine a suitable path for a response to the received request.

[0006] Systems and methods are also provided for a sNAP to receive a plurality of HTTP request messages after receiving a first HTTP request message. The sNAP may then send an HTTP response message in response to the first HTTP request message.

[0007] Systems and methods for proxying an HTTP response to the

HTTP request are also provided. A proxy-rule may be employed wherein a determination of which HTTP requests may be served by a single multicast HTTP response is the same as the rule used in standard HTTP web proxies when locally replying to incoming HTTP requests with a cached HTTP response.

BRIEF DESCRIPTION OF THE DRAWINGS

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

[0009] FIG. 1A is a system diagram of an example communications system in which one or more disclosed embodiments may be implemented;

[0010] 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; [0011] 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;

[0012] FIG. 2 is a message sequence diagram which illustrates example delays incurred through rendezvous (RVZ) and topology manager (TM) operations;

[0013] FIG. 3 is a system diagram which illustrates an example of a client and a server inside an information centric network (ICN) network;

[0014] FIG. 4 is a system diagram which illustrates an example of a client inside, or attached to, an ICN network and a server outside the ICN network;

[0015] FIG. 5 is message sequence diagram of an example corresponding to the system illustrated in FIG. 3;

[0016] FIG. 6 is message sequence diagram which illustrates an embodiment wherein several hypertext transfer protocol (HTTP) requests arrive in parallel at the server network attachment point (sNAP);

[0017] FIG. 7 is a message sequence chart which illustrates an example of return path inclusion; and

[0018] FIG. 8 is a message sequence chart which illustrates an example of on-path caching.

DETAILED DESCRIPTION

[0019] 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.

[0020] 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.

[0021] 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.

[0022] 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.

[0023] 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).

[0024] 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 establish 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).

[0025] 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).

[0026] 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.

[0027] 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.

[0028] 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. [0029] 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.

[0030] 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 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.

[0031] 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 sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0032] 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 functionahty 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.

[0033] 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 hght signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.

[0034] 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.

[0035] 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 enabling the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.11, for example.

[0036] 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 hght-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 nonremovable 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).

[0037] 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.

[0038] 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.

[0039] 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.

[0040] 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.

[0041] The RAN 104 may include eNode-Bs 140a, 140b, 140c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 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 eNode-B 140a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.

[0042] Each of the eNode-Bs 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 eNode-Bs 140a, 140b, 140c may communicate with one another over an X2 interface.

[0043] 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.

[0044] The MME 142 may be connected to each of the eNode-Bs 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/de activation, 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.

[0045] The serving gateway 144 may be connected to each of the eNode

Bs 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-eNode B 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.

[0046] 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.

[0047] 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.

[0048] Procedures, methods and architectures for reducing the end-to- end latency in an hypertext transfer protocol (HTTP) over information centric network (ICN) (HTTP-over-ICN) scenario through removal of the necessity for domain-local rendezvous (RVZ) requests and optimizing the construction of suitable forwarding information are discussed herein. System, methods and procedures to enable the communication between two IP-only devices at the HTTP level, one connected to an ICN network while the other one is connected either to an ICN or IP network are further discussed herein.

[0049] Methods and procedures for an ICN network attachment point

(NAP) to remove unnecessary domain-local RVZ requests for HTTP responses toward an IP-only device, the requests and received via an ICN are discussed herein. Methods and procedures for an ICN Border Gateway (GW) (BGW) to remove unnecessary domain-local RVZ requests for HTTP responses toward an IP-only device via an ICN, the requests received via an IP network are further discussed herein.

[0050] Methods and procedures for a NAP or a border gateway (BGW) to issue path creation requests upon receiving an HTTP request in an effort to further reduce response latency are discussed herein. Methods and procedures for a NAP or a BGW to suppress path creation requests by utilizing an internal table with node identifiers and path/forwarding information are further discussed herein.

[0051] The systems, methods, and procedures disclosed herein may have system applicability to the L3, Application Layer. [0052] Information-centric networking (ICN) constitutes a new paradigm in which content is exchanged by means of information addressing, while connecting appropriate networked entities that are suitable to act as a source of information toward the networked entity that requested the content.

[0053] Architectures have been proposed in this space, which may require the partial replacement of current network infrastructure in order to realize desired network-level functions. Migration scenarios have been proposed whereby architectures could be realized as an overlay over existing architectures, e.g., IP -based or local Ethernet-based architectures. Such migration, however, would still require the transition of a WTRU to an ICN- based solution. With IP -based apphcations providing a broad range of Internet services in current use, transitioning all of these applications may be a more difficult task than the pure transition of the network -level functionality, e.g., protocol stack implementation, in the WTRU since it also requires the transition of the server-side components, e.g., e-shopping web-servers and alike. Hence, one must assume that IP-based services, and with it purely IP- based WTRUs, will continue to exist for some time to come.

[0054] The transition to ICN at the network level, on the other hand, may provide an increased efficiency via the usage of in-network caches and the spatial/temporal decoupling of the sender/receiver in general, the utilization of software defined networking (SDN) upgrades for better flow management, among others.

[0055] Co-pending International Application No. PCT/US2016/015713 and U.S. Provisional Application No. 62/110,210, hereby incorporated by reference in their entirety, disclose a method for providing HTTP-level services over an ICN network and mapping HTTP request and response methods into appropriate ICN packets published toward appropriate ICN names. The mapping may be performed at the NAP of the client and server, respectively, as well as at the BGW for cases of HTTP methods being sent to and received from peering networks. The implementation of the mapping at the NAP may come, however, with a drawback since the necessary ICN operations of both the RVZ function and the topology manager (TM) function may cause a delay in the overall functioning of the system. In this embodiment, the RVZ function allows for matching an HTTP client with a suitable server and the TM function allows for creating a suitable forwarding path from the client to the chosen server.

[0056] FIG. 2 is a message sequence diagram which illustrates example delays incurred through RVZ and TM operations. The example delays may be incurred through RVZ and TM operations according to U.S. Provisional Application No. 62/110,210. The area in the sohd rectangular box, including publication messages 217, 222 and 228, highlights the aforementioned RVZ 215 and TM 220 requests for sending back the HTTP response from the server 230 to the client 205. Given the necessary network transmissions as well as the operations in the RVZ 215 and TM 220 functions, for path computation, these delays may increase the overall response time in the order of 10 ms or more.

[0057] In one embodiment described herein, a system and method is provided which may minimize the delay incurred through the RVZ and TM operations when sending back HTTP responses for HTTP-over-ICN systems as outlined in U.S. Provisional Application No. 62/110,210.

[0058] In one embodiment, the NAP, such as client NAP (cNAP) 210, may provide a standard IP network interface toward the IP-enabled device, encapsulate any received HTTP request, such as request 206, into an appropriate ICN packet, and publish the ICN packet, such as packet 211, as an appropriately formed named information item. The server NAP (sNAP) 225 may subscribe 226 to an information item after receiving message 231 from the server 230. RVZ 215 may receive ICN packet 211 and send publication message 216 to TM 220, which may then send publication message 221 to cNAP 210. Then, cNAP 210 may send publication message 212 to sNAP 225, which will send message 227 to server 230. Conversely, the cNAP 210 may subscribe 213 to any appropriately formed named information items, where the information identifier represents any HTTP-exposed service that is exposed at any IP-level device locally connected to the NAP. Any received ICN packet may then be forwarded to the appropriate local IP device after being appropriately decapsulated, recovering the original HTTP request.

Additionally, the operation of a BGW, which may receive ICN packets from

NAPs in its network that are destined to HTTP-level service outside of its network, may forward these packets toward appropriate IP networks.

Conversely, any received HTTP request at the BGW may be forwarded to the appropriate IP -based device in its local ICN network. For example, the server

230 may send HTTP response 232 to sNAP 225, which may publish message

228 to RVZ 215. RVZ 215 may publish message 217 to TM 220, which may publish message 222 to sNAP 225. Then, sNAP 225 may publish response 229 to cNAP 210, which may, in turn, send response 214 to client 205.

[0059] FIG. 3 is a system diagram which illustrates an example of a client and a server inside the ICN network. FIG. 4 is a system diagram which illustrates an example of a chent inside, or attached to, an ICN network and a server located outside the ICN network. For purposes of illustration, the ICN network 310, 410, respectively of FIG. 3 and FIG. 4 also show the RVZ function, such as rendezvous point 320, 420, respectively, and TM function, such as topology manager, 330, 430 respectively, in this system, implemented in an embodiment as one or more dedicated servers for the domain. In an embodiment, these servers may or may not be load-balanced. The system of

FIG. 4 may include ICN BGWs 415, 470 and a remote network 460.

[0060] Methods and systems for reducing RVZ delay are discussed herein. The delay highlighted in FIG. 2 may be avoided in an embodiment by using the sNAP, 350, 450, respectively, of the system shown in FIG. 3 and

FIG. 4, respectively, and locally perform the RVZ function 320, 420, respectively, as a result of receiving additional information in a publication message from the cNAP, 340, 440. For this, the cNAP 340, 440 may provide suitable information to the sNAP 350, 450 by means of a node identifier. A node identifier may be assigned to each NAP in the system during the bootstrapping process of the system. The node identifier may indicate node information suitable for the receiver of the HTTP response. This information, in turn, may then be used to determine suitable path information by the sNAP

350, 450 for use in a response to the received request. In this embodiment, the provisioning of the path information may be handled by the TM function while the sNAP 350, 450 forwards the HTTP request to the locally attached server.

Alternatively, the sNAP 350, 450 may consult an internal node/forwarding table with path information entries along node identifiers. Such a table may be managed in response to receiving path information for particular node identifiers from the TM function 330, 430 in the aforementioned operation. In one embodiment, the local table may provide a cache of previous replies for path information toward particular node identifiers. If such an entry is found in the table, the request toward the TM function 330, 430 may be suppressed and the found path information may be used instead. Upon receiving the response from the HTTP server, the sNAP 350, 450 may use any response method to send the response along the provided path or may alternatively wait for the information to arrive from the TM function 330, 430.

[0061] FIG. 5 is message sequence diagram of an example corresponding to the system illustrated in FIG. 3. An improved message sequence chart is shown in FIG. 5, and the details of the sequence chart are disclosed herein.

The initial message sequence shown in FIG. 5, such as messages 506, 531,

526, 511, 516 and 521, may be similar to that shown in FIG. 2, such as messages 206, 231, 226, 211, 216 and 221. When sending an encapsulated

HTTP request, such as request 506, from the client 505 to the sNAP 525, the cNAP 510 may include its node identifier, which may be assigned to the cNAP

510 during the bootstrapping of the ICN network, in the publication message

512 that is sent toward the sNAP 525. Upon receiving the encapsulated HTTP request, such as message 512, the sNAP 525 may decapsulate the HTTP request 512 and forward it 528 toward its locally attached server 530.

[0062] In an example, the information provided in publication message

512 from cNAP 510, such as the node identifier, may enable sNAP 525 to locally perform an RVZ function, instead of RVZ 515 performing the function. As a result, examples using the message sequence of FIG. 5 may not use a publication message analogous to publication message 217 of FIG. 2, at this stage of the sequence. The may result in reducing or entirely removing the delay for rendezvous at this stage.

[0063] Additionally, the sNAP 525 may consult an internal table with node identifiers and path/forwarding information. If the received node identifier is found in the table, the sNAP 525 may use the found path/forwarding information. If the received node identifier is not found in the table, the sNAP 525 may request appropriate path information from the TM function 520 by sending its own node identifier and the received node identifier 527 to the TM function 520. Upon receiving a response 522 from the TM 520, the sNAP 525 may insert the node identifier and the path/forwarding information in the internal table and use the path/forwarding information. Further, upon receiving an HTTP response 532 from the server 530, the sNAP may 525 use the path/forwarding information determined above to publish the encapsulated HTTP response 529 toward the cNAP 510. Alternatively, the sNAP 525 may wait for a response from the TM function 520, in case a request for path/forwarding information had been sent. In accordance with U.S. Provisional Application No. 62/110,210, the cNAP 510 may receive the HTTP response 529, decapsulate its content, and forward HTTP response 513 to the locally attached client 505.

[0064] The methods disclosed above may be realized similarly at the

BGW in scenarios where the server resides in a peering IP network, as shown in FIG. 4. In this embodiment, the server 530 may be replaced by a peering IP network, and the BGW may take the role of the sNAP 525. In this scenario, the described messaging associated with the sNAP 525 may be associated with the BGW. A similar exchange of roles may take place for network-external clients sending HTTP requests to a server residing in the ICN network. In this case, the BGW may take the role of the cNAP 510. In this scenario, the described messaging associated with the cNAP 510 may be associated with the GW. [0065] Methods and systems for improving network throughput through the use of coincidental multicast are discussed herein. In addition to reducing or entirely removing the delay for rendezvous, implicit subscription may be employed which may provide for improved network throughput by selectively sending a single HTTP response toward several clients that have previously sent an HTTP request. This embodiment, employing implicit subscription, may therefore also reduce latency for the response to individual clients.

[0066] FIG. 6 is message sequence diagram which illustrates an embodiment wherein several hypertext transfer protocol (HTTP) requests arrive in parallel at the sNAP. In an example shown in FIG. 6, several HTTP requests to the same HTTP resource may arrive in parallel at the sNAP 625 while the HTTP response, such as response 632, for the original request, such as publication message 612, is being generated.

[0067] The initial message sequence shown in FIG. 6, such as messages

606, 631, 626, 611, 616 and 621, may be similar to that shown in FIG. 2, such as messages 206, 231, 226, 211, 216 and 221 and to that shown in FIG. 5, such as messages 506, 531, 526, 511, 516 and 521. In addition, publication message

612 may be similar to publication message 512. Publication message 612 may similarly include a node identifier, which may enable sNAP 625 to locally perform an RVZ function, instead of RVZ 615 performing the function. Further, upon receiving the encapsulated HTTP request, such as message 612, the sNAP 625 may decapsulate the HTTP request 612 and forward it 628 towards its locally attached server 630.

[0068] The disclosed implicit subscription, shown in FIG. 6 as the second set of messages 613 from the cNAP 610 to the sNAP 625, may now aid in sending the HTTP response 632 as a multicast transmission. In one embodiment for operation in an sNAP 625, several incoming HTTP requests

613 may be treated as being 'multicast-capable'. A rule for which HTTP requests may indeed be served by a single multicast HTTP response may be the same as the rule used in standard HTTP web proxies when locally replying to incoming HTTP requests with a cached HTTP response. We refer to this rule as the 'proxy rule'. Examples for such a proxy rule include serving static content (such as resource URLs like www.foo.com/image.jpg or www.foo.com/video.3gp) in a single multicast response, while resource URLs (such as www.foo.com/index.html or www.foo.com/test.is) are served as unicast response. One reason for serving resource URLs as unicast responses is that many such resource URLs lead to 'personalized' responses where, user agent information from the HTTP request are used to respond differently depending on the nature of said user agent information. For instance, a request to www.facebook.com/index.html, such as one of requests 602 from one of clients 601, might be responded to with the content of the Facebook front page, while other responses might lead to a redirect response to rn.facebook.com, depending on whether the request includes user agent information for a mobile client or not. In other words, any HTTP request that would be served locally by a web proxy may be equally deemed suitable for a multicast response.

[0069] As a result of the above 'proxy rule', the sNAP 625 may bundle the appropriate HTTP requests 613, and the information pertaining to the HTTP request publications from the various cNAPs 610, into a request to the TM 620, such as in publication message 627, to form a multicast tree to these respective cNAPs 610. This multicast forwarding information, received from the TM 620, such as in publication message 622, may then be used for sending the published HTTP response 629 from the sNAP 625 to the various cNAPs 610. Then, cNAP 610 may send an HTTP response 614 to client 605.

[0070] In an alternative embodiment, the sNAP 625 may check if the node information for all the cNAPs 610, which the sNAP 625 may have determined based on the aforementioned 'proxy rule', exists in the internal table of node/forwarding identifiers. If these forwarding identifiers are LIPSIN Bloom filters, the sNAP 625 may suppress the message to the TM 620 for formation of the multicast delivery information and instead simply determine the multicast delivery information by OR'ing all individual forwarding information of the cNAPs 610 into a single multicast forwarding information to be used.

[0071] Methods for further reducing delay through return path inclusion are disclosed herein. In order to further reduce the possible delay shown in FIG. 5, which may be caused by return path computation at the sNAP when receiving a previously unknown node identifier, a further embodiment is disclosed. This embodiment provides for the return path to be computed at the client side in response to the original HTTP request.

[0072] FIG. 7 is a message sequence chart which illustrates an example of return path inclusion. The initial message sequence shown in FIG. 7, such as messages 706, 731, 726, 711, 716 and 721, may be similar to that shown in FIG. 2, such as messages 206, 231, 226, 211, 216 and 221 and to that shown in FIG. 5, such as messages 506, 531, 526, 511, 516 and 521. Also, this message sequence may be similar to that shown in FIG. 6. In addition, publication message 712 may be similar to publication messages 512, 612 and may similarly include a node identifier, which may enable sNAP 725 to locally perform an RVZ function, instead of RVZ 715 performing the function.

[0073] Further, upon receiving the encapsulated HTTP request, such as message 712, the sNAP 725 may decapsulate the HTTP request 712 and forward it 727 towards its locally attached server 730. Then, upon receiving an HTTP response 732 from the server 730, the sNAP may 725 use the path/forwarding information determined above to publish the encapsulated HTTP response 728 toward the cNAP 710. Upon receiving the HTTP response 728, the cNAP 710 may decapsulate its content and forward HTTP response 713 to the locally attached client 705.

[0074] In an embodiment shown in FIG. 7, the TM 720 response 721 to the cNAP 710 may include two forwarding identifiers, FIDreq and FIDres. The

FIDreq is the regular forward path for the request, while the TM 720 also provides the return path, FIDres, in the same response 721. Referring to FIG.

7, this TM response message 721 is labeled Publish (FIDreq, FID_res). The additional computation required in the TM 720 may cause only a minor additional delay since the forward path must be computed anyway. This delay may be minor since only the path information for return links, rather than forward links, needs to be compiled. In embodiments where link identification is bidirectional (i.e., the identifier being used for the forward direction from one node to the next is the same for the reverse direction), the forward and return path may be the same and there may be no delay for additional computation. In such cases, an alternative embodiment may only include the forward path information while configuring the sNAP in such a manner to use the provided forwarding path information as the return path for the provided node identifier without requiring the explicit inclusion of the return path identifier in the Publish_iSub() 712 message. Furthermore, if the cNAP 710 stores the path information for both the forward and return paths linked to the node identifier of the server, future TM 720 requests may become unnecessary. Upon receiving the revised Publish_iSub() 712 message at the sNAP 725, there is no need for return path computation and the HTTP response 728 may be sent without further delay.

[0075] FIG. 8 is a message sequence chart which illustrates an example of on-path caching. Methods for providing on-path caching for further improvement are discussed herein. The inclusion of the return path 828, as shown in FIG. 8, allows the opportunity for further HTTP improvement. In this embodiment, the use of on-path caching in forwarding elements throughout the network may be provided. This use of on-path caching may or may not be uniformly provided in all network elements. Some HTTP responses, such as the retrieval of static objects like images, videos, or portions of video, as well as information such as sensor information, tagged with appropriate HTTP headers such as eTag, may be cached as implemented in a similar fashion by state-of-the-art proxies.

[0076] The initial message sequence shown in FIG. 8, such as messages

806, 831, 826, 811, 816 and 821, may be similar to that shown in FIG. 2, such as messages 206, 231, 226, 211, 216 and 221 and to that shown in FIG. 5, such as messages 506, 531, 526, 511, 516 and 521. Also, this message sequence may be similar to that shown in FIG. 6 and to that shown in FIG. 7. In addition, publication message 812 may be similar to publication messages 512, 612, 712 and may similarly include a node identifier, which may enable sNAP 825 to locally perform an RVZ function, instead of RVZ 815 performing the function.

[0077] For supporting such proxy-like caching along the path of delivery, examples shown in FIG. 7 may be extended to the message sequence chart of

FIG. 8 through the inclusion of a cached option in the forward Publish_iSub() message, such as Publish_iSub() message 812. Upon receiving a

Publish_iSub() message 812 at an intermediary forwarding element, not shown in Figure 8, the message may be checked for a set cached field. If the cached field is set and the forwarding element supports caching, the

Publish_iSub() message may 812 be first internally delivered to the caching element at the forwarding node. Upon receiving the Publish_iSub() message

812 at the caching element, its payload may be investigated with respect to corresponding responses being cached at the caching element. For this embodiment, for instance, similar proxy rules may apply as in the multicast delivery embodiment. The caching element may check the appropriate request headers in the Publish_iSub() message 812 and determine if a matching response exists for these headers. In one embodiment, checking the appropriate request headers may include checking the URL of the request. If a matching response is not found, the message may be internally sent back to the forwarding element for sending further along the forward path toward the sNAP 825. If a matching response is found, an appropriate response message, such as message 828, may be created in accordance with the return path information of the Publish_iSub() 812 message and the cached response.

[0078] If a Publish_iSub() message 812 is received at the sNAP 825 and includes the cached flag, any response to the cNAP 810 may include an indication of the flag with its original value. Upon receiving the response at an intermediary forwarding element that supports caching operations, the message may be forwarded to the caching element and the appropriate operations for inserting the response into the cache may be performed. For instance, a simple first-in first-out (FIFO) or last-recently-used (LRU) queuing mechanism may be implemented for such insertion.

[0079] Further, upon receiving the encapsulated HTTP request, such as message 812, the sNAP 825 may decapsulate the HTTP request 812 and forward it 827 towards its locally attached server 830. Then, upon receiving an HTTP response 832 from the server 830, the sNAP may 825 use the path/forwarding information determined above to publish the encapsulated HTTP response 828 toward the cNAP 810. Upon receiving the HTTP response 828, the cNAP 810 may decapsulate its content and forward HTTP response 813 to the locally attached client 805.

[0080] Implementation and operational model examples are disclosed herein. In one embodiment, an additional message may be introduced to the protocol defined in U.S. Provisional Application No. 62/110,210, including the node identifier in a new Publish_iSub() message. The reception of this new message at the sNAP would implement the steps outlined in the previous section.

[0081] In another embodiment, it may be assumed that that no internal table of node identifiers and path/forwarding information may exist, leading to a computation of suitable forwarding information with every incoming request. Such an embodiment may provide for accommodating more frequent path/forwarding changes in the ICN system.

[0082] 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 limited 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 client network attachment point (cNAP) for enabling hypertext transfer protocol (HTTP) communication between an internet protocol (IP)-only device and an information-centric networking (ICN) device, the method comprising:

providing an IP network interface toward the IP-only device;

receiving an HTTP request;

encapsulating the received HTTP request into an ICN packet; and publishing the ICN packet as a named information item.

2. The method according to claim 1, wherein the named information item contains content data corresponding to the received HTTP request.

3. The method according to claim 1, further comprising:

subscribing to one or more named information items, wherein the one or more named information items comprise an information identifier representing an HTTP-exposed service that is exposed to the IP-only device.

4. The method according to claim 1, further comprising:

receiving a second ICN packet at the cNAP;

decapsulating the received second ICN packet; and

forwarding the second ICN packet to the IP-only device.

5. The method according to claim 1, further comprising:

sending the ICN packet to a border gateway (BGW) for transmission toward an IP network.

6. The method according to claim 5, wherein any HTTP request received at the BGW is forwarded to the IP-only device in a local ICN network to the BGW.

7. The method according to claim 1, wherein the named information item is an appropriately formed named information item.

8. A method for use in a server network attachment point (sNAP) for reducing rendezvous (RVZ) delay, the method comprising:

receiving a publication message including information from a client network attachment point (cNAP); and

locally performing an RVZ function in response to receiving the publication message.

9. The method of claim 8, wherein the information includes a node identifier that indicates node information suitable for a receiver of the response.

10. The method of claim 9, wherein the node identifier is assigned to the network attachment point during a bootstrap process of the sNAP or information-centric network (ICN).

11. The method of claim 9, wherein the node identifier is used to determine a suitable path for a response to the received request.

12. The method according to claim 11, wherein the path is provisioned by a topology management server while the sNAP forwards an hypertext transfer protocol (HTTP) request to a locally attached server.

13. The method according to claim 11, the method further comprising: consulting a node/forwarding table comprising a path information entry corresponding to the node identifier, wherein the node/forwarding table is internal to the sNAP.

14. The method according to claim 13, wherein the node/forwarding table is managed in response to receiving the path information for particular node identifiers from a topology management server.

15. The method according to claim 14, wherein if an entry is found in the node/forwarding table, a request toward a topology management server is suppressed and the found path information is used.

16. The method according to claim 11, wherein the response is a single response sent to a plurality of clients.

17. The method according to claim 11, wherein a proxy-rule is employed wherein a determination of which HTTP requests may be served by a single multicast HTTP response is the same as the rule used in standard HTTP web proxies when locally replying to incoming HTTP requests with a cached HTTP response.

18. A method for use in a client network attachment point (cNAP) for enabling hypertext transfer protocol (HTTP) communication between an internet protocol (IP)-only device and a server device, the method comprising: providing an IP network interface toward the IP-only device;

receiving an indication of a forward path and an indication of a return path to a server network attachment point (sNAP);

encapsulating a received HTTP request into an ICN packet, wherein the ICN packet includes the HTTP request, the indication of the forward path, and the indication of the return path; and

publishing the ICN packet as a named information item.

19. The method according to claim 18, wherein the indication of the forward path and the indication of the return path are stored in a non-volatile memory component of the cNAP.

20. The method according to claim 18, wherein the indication of the return path is used to receive a response message.

21. The method according to claim 18, wherein the ICN packet is published to a forwarding node.

22. The method according to claim 21, wherein the forwarding node is a proxy server.

23. The method according to claim 22, wherein the proxy server checks a set cached field to determine if a matching response exists local to the proxy server.

24. The method according to claim 21, wherein the forwarding node employs a first-in first-out (FIFO) or last-recently-used (LRU) queuing mechanism.

25. The method according to claim 18, wherein the named information item is an appropriately formed named information item.