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

4 ITU-T Focus Group IMT-2020 Deliverables

Information elements are published and subscribed to. The semantics are realized by the Rendezvous (RV),
Topology Management (TM) and Forwarding (FN) functions. RV matches requests and information elements.
The TM then creates a communication path to the subscriber and the FN forwards the information along
path. The path is identified by a forwarding identifier (FID) that represents the path information as a bitfield
information in which each bit signifies a specific link in the overall network. With that, a simple AND and
COMPARE operation at each forwarding node (e.g., SDN switch) is performed to test the membership of the
node’s output port (identified through a specific bit position in the bit field).

Recent developments (Reed, et al. 2016) have shown that the aforementioned ICN forwarding can be directly
implemented in OpenFlow controlled SDN switches. This realization relies upon the fact that SDN switches,
from OpenFlow v1.2 (ONF 2011), can implement flow-rule matching using an arbitrary bit-mask accross a
number of header fields, including IPv6 addresses and Ethernet MAC addresses. Such arbitrary bit-mask
matching is directly equivalent to the necessary AND and COMPARE operation when considering a bit-mask
with only the specific output port’s bitposition set. Consequently, it is possible to implement the ICN
forwarding using SDN switches if the FId is inserted into arbitrary match capable fields such as the IPv6
addresses and/or the Ethernet MAC addresses. This allows a FId length of 256-bits if the IPv6 header is used
or 352-bits if using both IPv6 and MAC headers, while solutions have been developed to overcome this size
limitation in larger networks. Through the use of a unique Ethernet VLAN ID it is possible to separate the ICN
encoded traffic from conventional Etherenet/IPv6 traffic and thus integration with existing deployments is
possible.

7.2 InterDigital Solution: IP over ICN
The intention of our system is to preserve the perception of an IP-based autonomous system towards any
connected peering network through standard IP-based protocols, while exposing an IP-based interface to
attached user devices as well as service providers. With this, our architecture does not impose any changes
to existing user and server (as well as data centre) equipment, while enabling the full application base of
today’s Internet. Nonetheless, the provided network attachment points can expose native ICN interfaces that
would enable native ICN applications for future ICN use cases.

The translation of IP-based communication, either directly at the IP or the HTTP level, is realized at the
Network Attachment POINT (NAP) placed towards the user or server equipment (both denoted as UE), while
the ICN Gateway provides a translation towards peering IP networks, if required. Annex A provides more
detail as regards to the operations for translating HTTP exchanges into an ICN-compliant message exchange
with lowest delay possible. In general, the request-response protocol of HTTP is translated into a publication
of the encapsulated HTTP request at the client-facing NAP towards the fully qualified domain name (FQDN)
of the HTTP server, while the client subscribes to the response URL in full. The server-facing NAP, in turn, will
have subscribed to all FQDNs exposed at its local IP interfaces, therefore receiving any request as intended.
As a consequence, it will receive any such publication and forward the HTTP request to the locally connected
server. Upon receiving a response from the server, it is published by the server-facing NAP, in turn being
received by the client-facing NAP. The optimizations realized in our solutions allow for such operations akin
to HTTP request exchanges, i.e., with initial (domain-local) DNS-like resolution followed by efficient direct
path exchanges between client and server, while enabling the possibility to form multicast responses for
requests for the same resource and arriving at the quasi-same time. More information can be found in the
mentioned Annex.

7.3 Benefits of InterDigital ICN solution

The PoC highlights two quantitative benefits of our solution. The first one is that of introducing the capability
to delivery HTTP responses via multicast to a number of clients. We appreciate that the nature of such
multicast delivery is likely to change from request to request due to the unsynchronized nature of the HTTP
requests – nonetheless, our solution specifically supports this aspect by allowing to form multicast groups in
an ad-hoc manner solely at the sNAP and based on the path information of the individual clients only. No
specific signalling is required for the multicast support since a mere binary OR operation over all member of
the multicast group suffices – such operation can easily be done for another set of multicast responses in the
case of another request, again at no additional costs for signalling.

270