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

4 ITU-T Focus Group IMT-2020 Deliverables

10.2.3 Further details: HTTP Mapping Operations

10.2.3.1 Naming Conventions
In order to realize the desired HTTP-based request & response semantics, we map HTTP onto an ICN
namespace as illustrated in Figure 22. The request is named through a hash over the fully qualified domain
name (FQDN) of the server, while the response is named through a hash over the full URL of the request. A
unique root identifier is chosen in our system and is subject to future standardization.

Figure 22 – HTTP-over-ICN Namespace

As in any hashing operation, the appropriate choice for the hashing the FQDN is crucial to avoid conflicts. The
underlying ICN ID space is large enough to avoid conflicts when hashing an FQDN. For the response hash
(over URLs), the implicit subscription model that is being utilized for delay improvements (see annex)
provides a simple resolution due to the request/response association (with the original request being already
provided in the request to which the implicit subscription will be associated).

10.2.3.2 Registering HTTP Services
For any HTTP-based service to be exposed in our network, the ICN NAP (see Figure 20) – to which the HTTP-
based server is attached – registers the FQDN of the service by subscribing to /http/hash(FQDN) in our
namespace. We provide several registration triggers through a NAP-internal registration interface. For
instance, DNS registrations of the server can be used to trigger such a registration, while others might use
static configurations or a proprietary management console of the network operator for registered services
provided in the network. Furthermore, dynamic DNS could be realized through a dynDNS-compliant client.
Alternatively, we also envision the registration to be triggered by a surrogate service endpoint management
system. Here, the envisioned management system would ‘activate’ a server with the registration and
therefore change the server's state from purely ‘booted’ to ‘connected’.
After the registration subscription, the NAP publishes the current list of local FQDN registrations under a well-
known ICN root scope /DNSlocal. All ICN NAPs, as well as the ICN BGW, within the local ICN network subscribe
to this name, hence they will receive any updated FQDN registrations. Upon receiving such an updated list,
each ICN NAP searches its internal FQDN DB for a row with a matching FQDN column. If such a row is found,
the receiving NAP/GW will initiate an update of any forwarding information related to the FQDN by removing
any existing path information to the FQDN. This will lead to a new RV/TM interaction when a new request
will be sent to the FQDN, which in turn will lead to an updated FId that reflects the new availability of the
FQDN. As a consequence, this procedure ensures that new surrogate servers are utilized in future requests,
leading to the possibility to implement surrogate service endpoints with lower service latency.
It is clear that storing the FQDN DB at each NAP places a burden on the NAP in terms of storage requirements
but enables the utilization of newer, possibly better choices for HTTP service endpoints.

280