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

4 ITU-T Focus Group IMT-2020 Deliverables

With that in mind, our main focus is the reduction of the delay incurred in the response path. The problem
here lies in the fact that the URL is likely different for every request (assuming some form of meaningful
service interaction between client and server). Hence, the channel semantic cannot be applied here, since
the corresponding rCID different for each publication from the sNAP to the cNAP. In order to remove the
delay, we will have to realize the RV and TM function in the sNAP, at least after an initial lookup. For this, we
propose to include the result of the RV function in the CID publication message sent by the cNAP, i.e., the
node information of the client to which the response needs to be published. With this, the sNAP can create
a relation between the incoming publication and the response publication without needing to contact the
domain-local RV. Furthermore, this node information can then be used at the sNAP to initiate the path
computation via the TM by utilizing its own NId (as the publisher of the response) and the NId of the client
(which it has received in the client’s request).
If the sNAP caches the response of this path computation, i.e., the mapping between client NId and FId, any
future response can be directly sent to the client without consulting the TM, therefore allowing for direct
client/server exchange after these initial lookups for the request and response path.

Figure 23 – Messaging for HTTP over ICN

10.2.5 Enabling HTTP Multicast Responses

A significant benefit of introducing the proposed latency improvements in the previous section is that of
spontaneous multicast group formation for the support of HTTP multicast responses. For this, we assume
situations where requests for the same HTTP resource (as identified in the URL) arrive at roughly the same
time at the sNAP. With the native multicast capability of the underlying ICN system, it is desirable that the
responses to such request could be sent to all requesting clients in an efficient multicast delivery instead of
the inefficient HTTP unicast delivery in an IP-routed system.
For this, it is crucial that we are able to spontaneously create multicast groups that are formed from the
clients that have quasi-synchronously requested the same response. Such spontaneous group formation is
enabled through an interesting characteristic of the underlying BF-based forwarding solution. BF identifiers,
FIds, that describe a path in the network (here from the sNAP to a specific cNAP) can be used to create joined
paths by simply ORing the individual BF identifiers into a new FId. This new, joined FId, now defines the
multicast path to clients previously described through the individual client paths. Hence, when ‘catching’
such possible responses, the sNAP will simply look up all FIds to the NIds that have outstanding subscriptions
to the same URL, then perform a binary OR over all FIds, and use this new BF in the response instead. Given
the simplicity of this FId joining, it can easily be performed at runtime and at individual response level. We
call this capability of our system co-incidental multicast.

282