Page 287 - ITU-T Focus Group IMT-2020 Deliverables

ITU-T Focus Group IMT-2020 Deliverables 4

10.2.3.3 Handling HTTP Requests

At the client side, the ICN NAP acts as a web proxy towards the client UE, i.e., it terminates the HTTP session
at the HTTP level. The extracted HTTP request at the proxy level is then used to create an appropriate ICN
name for the request, named CID, as /http/hash(FQDN) and for the response, named rCID, as
7
/http/hash(URL), where the URL and FQDN are extracted from the HTTP request . Then, it encapsulates the
request and publishes the ICN information item towards the local ICN network under the CID name.
Furthermore, the NAP will subscribe to the information item named rCID, i.e., the response to the request,
towards the local ICN network.
In the case of a network-local server, the NAP at which the server is registered will receive the publication
(this is assured by the procedures described in the previous section). It will then de-capsulate the HTTP
request from the ICN packet and forward the HTTP request to the locally attached HTTP server via its own
local web proxy.
In the case of a network-external server, i.e., a server located beyond the ICN GW within a peering network,
the ICN rendezvous function will realize a default matching procedure, in which any request without matching
subscriber(s) will yield in matching the publication to a pre-defined wildcard name under the /http root
scope, with the designated default GW of the ICN network having subscribed to this wildcard. In addition,
any other possible GW in the network can subscribe to specific FQDNs, e.g., for realizing content-level peering
arrangement with large-scale content providers.

For network-external incoming HTTP requests, i.e., sent from network-external users to any network-internal
FQDNs, the ICN GWs are interpreted as a NAP to the peering network, realizing the same web proxy
termination and ICN publication of the request (with subscription to the response) as any other NAP in the
system.
10.2.3.4 Handling HTTP Responses

In the case of responses sent from servers in the local ICN network, the local ICN NAP will receive these
responses. It will then determine the appropriate ICN name for the response, i.e., rCID, as /http/hash(URL),
with the URL being extracted from the HTTP request. It will then publish the encapsulated response to rCID.
The corresponding ICN NAP (or GW in the case of a request sent from a network-external client), having
subscribed to this rCID in response to sending the original request CID, will then receive the response,
decapsulate the response and forward the HTTP response to the local client.

Any HTTP response from a server in the Internet will arrive at the corresponding ICN BGW with the same NAP
procedures being implemented at the GW.

10.2.4 Addressing Delay Challenges
Figure 23 shows the resulting messaging in the system of Figure 20 with requests being sent to the client-
side NAP, which in turn indicates the request availability to the RV function, which in turn triggers the path
computation towards the TM, finally providing the path information to the cNAP. After sending the data via
the path and subscribing to the response, the messaging on the return path is reversed for the response with
name rCID.

It is clear that such signalling is hardly conducive for low latency and high request throughput. We have
therefore introduced optimizations that will improve the overall request throughput and reduce any lookup
latency to the initial request and responses between client and server, similar to the initial DNS local lookup
in an IP system.
The first optimization is already supported by the underlying ICN system by providing a node-local caching
table that maps previously resolved CIDs to forwarding identifiers (FIds). This is similar to node-local DNS
caches and therefore reduces the request latency to this initial lookup, while any further request to the server
will re-use the previously provided FId, since the CID remains unchanged as a hash over the FQDN.

7 Our current proposal for HTTPS envisions the establishment of an interception proxy at the ingress and egress NAP
(or GW), requiring a certificate sharing agreement between operator and content providers.

281