Internet Services over ICN in 5G LAN Environments

3.1. 5G Control Plane Services

We exemplify the need for chaining service functions at the level of a service name through a use case stemming from the current 3GPP Rel-16 work on Service Based Architecture (SBA) [TS29.500] [SBA-ENHANCEMENT]. In this work, mobile network control planes are proposed to be realized by replacing the traditional network function interfaces with a fully service-based one. HTTP/2 was chosen as the application layer protocol for exchanging suitable service requests [TS29.500]. With this in mind, the exchange between, say the 3GPP (Rel-15) defined Session Management Function (SMF) and the Access and Mobility management Function (AMF) in a 5G control plane is being described as a set of web service like requests which are in turn embedded into HTTP requests. Hence, interactions in a 5G control plane can be modelled based on service function chains where the relationship is between the specific service function endpoints that implement the necessary service endpoints in the SMF and AMF. The service functions are exposed through URIs with work ongoing to define the used naming conventions for such URIs.¶

This move from a network function model (in pre-Rel 15 systems of 3GPP) to a service-based model is motivated through the proliferation of data center operations for mobile network control plane services. In other words, typical IT-based methods to service provisioning, in particular that of virtualization of entire compute resources, are envisioned to being used in future operations of mobile networks. Hence, operators of such future mobile networks desire to virtualize service function endpoints and direct (control plane) traffic to the most appropriate current service instance in the most appropriate (local) data centre, such data centre envisioned as being interconnected through a software-defined wide area network (SD-WAN). 'Appropriate' here can be defined by topological or geographical proximity of the service initiator to the service function endpoint. Alternatively, network or service instance compute load can be used to direct a request to a more appropriate (in this case less loaded) instance to reduce possible latency of the overall request. Such data center centric operation is extended with the trend towards regionalization of load through a 'regional office' approach, where micro data centers provide virtualizable resources that can be used in the service execution, creating a larger degree of freedom when choosing the 'most appropriate' service endpoint for a particular incoming service request. This 5G control plane scenario capitalizes on the edge computing capabilities of ICN by allowing for fast redirections of HTTP-based transactions to the nearest control plane service realization within the distributed data centre of the 5G operator infrastructure.¶

3.2. HTTP-based Streaming

With the extensive use of "web technology", "distributed services" and availability of heterogeneous network, HTTP has effectively transitioned into the common transport or session layer for E2E and multi-hop communication across the web. Assume clients that are consuming the same content (such as a TV program) and that this content has for each block (typically segments worth 2 seconds of content) a set of outstanding requests from its clients. HTTP request and response used in media streaming services like HLS, use HTTP response for delivery of content. In such scenarios, where semi-synchronous access to the same resource occurs (such as watching prominent videos over Netflix or similar platforms or live TV over HTTP), traffic grows linearly with the number of viewers since the HTTP-based server will provide an HTTP response to each individual viewer. To mitigate the load impact, operators often utilize IP multicast underneath HTTP (for live TV) to create fewer, multicast, streams; though this comes with the high flow setup and management cost. This poses a significant burden on operators in terms of costs and on users in terms of likely degradation of quality.¶

This problem is not limited to traditional TV broadcasting. Consider a virtual reality use case where several users are joining a VR session at the same time, e.g., centered around a joint event. Hence, due to the temporal correlation of the VR sessions, we can assume that multiple requests are sent for the same content at any point, particularly when viewing angles of VR clients are similar or the same. Due to availability of virtual functions and cloud technology, the actual end point from where content is delivered may change. For this type of scenarios, the opportunistic multicast capability of ICN may be utilized to reduce overall load in the network, as well as on the server providing the HTTP responses. The latter also allows constrained resources to serve a higher volume of demands and therefore incur a higher impact on traffic distribution in the network.¶

4.1. Realization in SDN Transport Networks

An emerging technology for Layer 2 forwarding that suits the 5GLAN architecture in Figure 1 is that of Software-Defined networking (SDN) [SDN-DEFINITION], which allows for programmatically forwarding packets at Layer 2. Switch-based rules are being executed with such rules being populated by the SDN controller. Rules can act upon so-called matching fields, as defined by the OpenFlow protocol specification [OpenFlowSwitch]. Those fields include Ethernet MAC addresses, IPv4/6 source and destination addresses and other well-known Layer 3 and even 4 transport fields.¶

As shown in [Reed], efficient path-based forwarding can be realized in SDN networks by placing the aforementioned path identifiers into the IPv6 source/destination fields of a forwarded packet. Utilizing the IPv6 source/destination fields allows for natively supporting 256 links in a transport network. Larger topologies can be supported by extension schemes but are left out of this paper for brevity of the presentation. During network bootstrapping, each link at each switch is assigned a unique bitnumber in the bitfield. In order to forward based on such bitfield path information, the SDN controller is instructed to insert a suitable wildcard matching rule into the SDN switch. This wildcard at a given switch is defined by the bitnumber that has been assigned to a particular link at that switch during bootstrapping. Wildcard matching as a generalization of longest prefix matching is natively supported by SDN-based switches since the OpenFlow v1.3 specification, efficiently implemented through TCAM based operations. With that, SDN forwarding actions only depend on the switch-local number of output ports, while being able to transport any number of higher-layer flows over the same transport network without specific flow rules being necessary. This results in a constant forwarding table size while no controller-switch interaction is necessary for any flow setup; only changes in forwarding topology (resulting in a change of port to bit number assignment) will require suitable changes of forwarding rules in switches.¶

4.2. Realization in Other Transport Networks

Although we focus the methods in this draft on Layer 2 forwarding approaches and realization of Internet-over-ICN over a 5G LAN enabled network, path-based transport networks can also be established as an overlay over otherwise Layer 2 networks. For instance, the BIER (Bit Indexed Explicit Replication) [RFC8279] efforts within the Internet Engineer Task Force (IETF) establish such path-based forwarding transport as an overlay over existing, e.g., MPLS networks. The path-based forwarding identification is similar to the aforementioned SDN realization although the bitfield represents ingress/egress information rather than links along the path.¶

Yet another transport network example is presented in [Khalili], utilizing flow aggregation over SDN networks. The flow aggregation again results in a path representation that is independent from the specific flows traversing the network.¶

The proposed traffic engineering extensions to BIER, presented in [I-D.ietf-bier-te-arch], directly align with the SDN-based realization presented in Section 4.1, by proposing the same bitposition per transport link assignment being used, resulting in BIER bitstrings in which a dedicated forwarding path is encoded as a unique bitpattern containing said bitpositions of the chosen forwarding links. The BIER-TE controller plays a similar role as the northbound SDN controller application utilized for the solution in Section 4.1.¶

5.1. General Operations

The semantics of our name-based routing is that of a publish-subscribe system over a name. The intention to receive packets with a certain name is expressed through a subscription while sending packets to a name is expressed through a publication. The matching of a sender to a receiver is realized through NR in Figure 3. The exact nature of the matching is defined through the semantics of the service and, therefore, through the nature of the name provided. For instance, HTTP and raw Internet services are matched to exactly one subscriber only, providing an anycast capability, while IP multicast services are matched against any subscriber (with the IP multicast address being the name).¶

Structured names are used with the root specific to the (Internet) service name, such as URL, and therefore deriving the matching semantics directly from the name.¶

The subscription to a name is realized through a registration protocol between end device and NR. Hence, any end device exposing a certain Internet service registers the suitable name with the NR, which in turn stores reachability information that is suitable for path calculation between the ingress and egress L2 forwarders between which the communication eventually will take place. In our current realization, we utilize shortest paths only although other link weights can be utilized for, e.g., delay-constrained and other policies.¶

In our realization, we use network domain unique host identifiers that are being assigned to end devices during the connectivity setup. Sending a packet of a given Internet service is realized through a discovery protocol, which returns a suitable pathID, i.e., the forwarding information between ingress and egress L2 forwarder, and the destination MAC address of the hosting end device. It is this pathID and MAC address that is being used in the general packet structure of Figure 2 to forward the packet to the destination.¶

To reduce latency in further communication, the forwarding information is locally cached at the end device, while the cached information is being maintained through path updates sent by the NR in case of hosting end devices having moved or de-registered, therefore avoiding stale forwarding information.¶

5.2. ICN API to Upper Layers

The operations of the ICN layer are exposed to upper layers in Figure 1 through the following API calls, being exemplary here for the further explanation of operations in the next sub-sections:¶

• conn = send(name, payload)¶
• send(conn, payload)¶
• conn = receive(name, &payload)¶
• receive(conn, &payload)¶

The first send() call is used for initiating a send operation to a name with a connection handle returned, while the second send() is used for return calls, using a connection parameters that is being received with the receive() call to an incoming connection or for subsequence outgoing calls after an initial request to a name has been made. A return send() is being received at the other (client) side through the second receive() call where the conn parameter is obtained by the corresponding send() call for the outgoing call. With these API functions, we provide means for providing name-based transactions with return responses association provided natively.¶

The conn parameter represents the bitfield used for path-based forwarding in the remote host case or the hash of the local MAC address in case of link-local connections.¶

5.3. HTTP over ICN

5.4. IP over ICN

For non-HTTP traffic, the service proxy uses the destination IP address of an incoming IP packet from an IP endpoint as the information identifier for the NR to find the suitable service proxy, which can reach the sought after IP endpoint. The usage of subnet masks and a longest prefix matching approach inside the NR is foreseen for this matching process. In a 5GLAN scenario, service proxies on UEs serve a single IP endpoint (i.e. the UE itself) and therefore are represented by a /32 subnet mask for its IP address inside the NR in the list of subsribers. Service proxies that serve an entire local domain the subnet configured on the LAN interface of the service proxy is being communicated to the NR for matching purposes. The service proxy that serves the public internet is represented as a wildcard match for any IP address that is not served within the operator's network.¶

5.5. Service Proxy Operations

The service proxy in Figure 3 serves the integration of legacy devices, i.e., with regular IP protocol stack, and the interconnection to IP-based peering networks. It registers suitable identifiers with the NR to ensure the reception of (ICN) packets, while providing suitable protocol termination for the various supported protocols. For instance, for HTTP, the service proxy towards the peering network will register a wildcard name to the NR to receive any HTTP request not destined to a network-locally registered FQDN, operating as an HTTP proxy towards the peering network. Service proxies also register to the IP subnet they have been assigned on their local IP-based interface(s). The assignment is envisaged through an out-of-band address assignment scheme, i.e. DHCP [RFC2131] [RFC8415].¶

5.6. Support for Transport Layer Security

With a vast amount of networking intense HTTP traffic being encrypted, supporting HTTP over Transport Layer Security (TLS) [RFC8446] is of paramount importance to continue offering the benefits of routing the internet over 5GLAN utilising the ICN principles outlined in this document, in particular the ability to transparently change the service endpoint handling a HTTP request per HTTP transaction.¶

After the TCP session has been established by the client with the server, which is transparently intercepted by the service proxy and mapped to an inter service proxy ICN flow, the client initiates a TLS handshake aiming to establish a secure connection. When the service proxy receives the ClientHello message from the client it has two choices: act as a TLS endpoint or act as a TLS proxy.¶

If the service proxy has the TLS certificate/key for the FQDN provided in the TLS ClientHello message, it acts as a transparent TLS endpoint by intercepting the TLS sessions and implementing the TLS procedures described in [RFC8446]. If the client eventually sends a HTTP request over the TLS session the service proxy can decrypt it to obtain the HTTP request in its entirety to perform the steps described above how to map HTTP over ICN (and vice versa). On the other side of the ICN flow the service proxy acts as a TLS client towards the actual IP service endpoint. One of the key benefits of service proxies acting as TLS endpoints is their ability to still offer opportunistic multicast, as TLS (similar to TCP) is fully intercepted at both edges of the ICN communication domain.¶

If the TLS certificate/key for the FQDN in the TLS ClientHello message is not available to the service proxy, TLS control messages between client and servers are left intact and routed to the most suitable service proxy that is subscribd to the FQDN. However, as the service proxy is not able to see HTTP transactions routing benefits of the decsribed steps such as opportunistic multicast and transparent interruption-free re-routing of HTTP transactiosn to a more suitable IP servce endpoint are not feasible. In such scenario, the TLS session must be restablished between the client and the server and service continuity cannot be offered. However, it is important to mention that the TLS proxy mode still improves over a plain TCP connection, as for the latter the IP address provided by a DNS is being used to determine the destined service proxy and not the FQDN of the HTTP request.¶

5.7. ICN Flow Management

For all protocol mappings described in this section, the payload taken from the (intercepted) layer is send as payload of the ICN packet, as illustrated in Figure 2. It can be observed that two resource management regimes are present, i.e. the application to service proxy communication (IP) and the inter service proxy (ICN) one. In the IP resource management regime, TCP friendliness governs the various transport protocols in use allowing a per flow fair usage of the available networking resources. However, the resource regime between service proxies does not have such requirement; thus, the corresponding ICN flow management and error control allows an independent improved resource regime that must not be TCP friendly.¶

For an independent inter service proxy resource management scheme that treats each *-over-ICN mapping equally, the notion of HTTP, TCP and IP transactions are being introduced with the goal to treat them equally and therefore ensuring resource fairness among them with the benefit of long lasting ICN flow relationships among service proxies.¶

                                      +--------------+    +-------+
                                   __ |Ad-Hoc Service|    |Flow   |
                                  /   |Proxy Flow    |    |Control|
                                 |    +--------------+    +-------+
+--------+                       |           |                |
| IP/UDP |                       |           |                |
|Datagram|--------------|        |    +--------------+    +-------+
+--------+              |        |    |Service Proxy |----|Flow   |
                        |        |    |    Flow      |    |Control|
+--------+              |         \   +--------------+    +-------+
|TCP/TLS |---------|    |          \         |
|Stream  |         |    |           \        |
+--------+         |    |            \       |
                +-----------+         +--------------+    +-------+
                |    IP     |---------|Service Proxy |----|Error  |
                |Translation|         |Translation   |    |Control|
                +-----------+         +--------------+    +-------+
+-------------+    |    |
|HTTP Request |----|    |
+-------------+         |
                        |
+-------------+         |
|HTTP Response|---------|
+-------------+

Figure 4 illustrates the ICN flow management for inter service proxy communication. As it shows, all traffic from IP endpoints are translated into a unified IP transaction and mapped to a service proxy transaction. The resulting service proxy flow constitutes a long-term relationship between two service proxies. For each service proxy flow, there exists a flow-specific flow control relationship, which maintains flow parameters such as send credits, timers for round-trip time (RTT) dependent mechanisms, error rate information and others. Such serivce proxy flow between two service proxies represent the edge-to-edge resource management regime desribed above. Each service proxy flow consists of one or more service proxy transactions, each of which comes with its own error control relationship that maintains information such as sequence numbers, outstanding packets, segmentation/reassembly information and others. For retransmissions, the error control relies on service proxy flow-specific flow control information, such as timers, RTT information etc. With such mapping from IP transactions onto a service proxy transaction that has its own error control mechanism, it has been achieved that the data originating from and destined to end-to-edge resource management regimes can be reliably transferred over the service proxy-to-service proxy network. Combining all transactions under a single resource management relationship, represented by the combined flow control mechanism for a single flow between the service proxies, now establishes the inter service proxy resource management scheme. Any competition for resources among service proxies is now governed by said scheme between flows. Given that all transactions between specific service proxies are mapped into a single service proxy flow, fair resource sharing among all transactions can be ensured.¶

One crucial aspect of the HTTP-over-ICN mapping is the possibility of so-called ad-hoc multicast relations, i.e., the ability to send responses from one IP applications to more than one other IP application and therefore to more than one service proxy. In this case, the specific IP transaction (e.g. an HTTP response) is mapped onto a service proxy transaction that in turn is realized over more than one service proxy-to-service proxy flow. This flow is called ad-hoc service proxy flow. For those cases, the flow control for the ad-hoc service proxy flow will utilize parameters across the various involved service proxy flows, resulting in an one-to-many relationship between the specific flow control for the ad-hoc serivce proxy flow and the flow control(s) of the involved serivce proxy flow(s). Such combined parameters might be the maximum RTT timer or the lowest credit value, representing the least common dominator of the resources across all involved flows.¶

As mentioned before, a service proxy flow constitutes a long-term relationship between two service proxies. This relationship can established in multiple ways: an explicit setup might be used akin to that of TCP's three-way handshake. Alternatevely, an implicit transaction-based flow establishment might be used; in this case, the sending of an initial transaction between two service proxies results in the creation of an service proxy flow context between those two service proxies, which is being reused for any future transfer between those two service proxies, i.e., constituting a service proxy flow. Flow termination can be explicit based on a handshake protocol, where one service proxy, wishing to terminate the flow, signals this to the corresponding service proxy. Other embodiments foresee the destruction of the service proxy flow via timeout, e.g., removing any internal service proxy flow context information upon firing of an inactivity timeout. Combining this with an implicit transaction-based flow establishment would make the notion of a service proxy flow entirely that of an internal (service proxy flow context) data structure, which is created upon sending the first transaction to a service proxy which had previously not been contacted, while destroying said data structure upon the firing of the aforementioned inactivity timeout.¶

5.8. NR Operations

The NR in Figure 3 combines the operations of the SMF and the PMF in 5GLAN (see Figure 1), by allowing for registering IP protocol identifiers for discovery and subsequent path computation by resolving the destination(s) to a suitable pathID and destination MAC address for forwarding. This will require extensions to the operations of the SMF to allow for such higher layer identifiers to be registered (and discovered), in addition to the already supported Ethernet and IP addresses.¶

5.9. Mobility Handling

EDITOR NOTE: left for future draft updates.¶

5.10. Dual Stack Device Support

Figure 3 outlines a protocol stack for the user equipment that realizes Internet services on top of the proposed name-based routing layer as a single stack device. However, [I-D.irtf-icnrg-icn-lte-4g] outlines the possibility of supporting dual-stack devices for 4G LTE networks by allowing IP as well as ICN protocol stacks to be deployed with the operation of IP and ICN based applications. [I-D.irtf-icnrg-5gc-icn] outlines the same dual-stack device realization for a 5G ICN realization. For both environments, a convergence layer is described that selects the appropriate data path for each ICN or IP application, e.g., based on configuration per application (similar to selecting network interfaces such as WiFi over cellular).¶

As a possible data path selection, [I-D.irtf-icnrg-icn-lte-4g] and [I-D.irtf-icnrg-5gc-icn] envision the realization of Internet-over-ICN (Section 4.2 in [I-D.irtf-icnrg-icn-lte-4g]) in which the convergence layer would realize similar mapping functions as described in this draft. Hence, we foresee the utilization of such dual-stack devices connected to an Internet services over ICN over 5GLAN environment. When utilizing the service proxy, IP applications that are configured to use the IP data path only could still utilize the ICN-based forwarding in the network. In that case, functionality such as the opportunistic multicast in Section 5.3.2 would only reach up to the service proxy with unicast traffic continuing along the data path towards the user equipment.¶