ICNRG D. Trossen Internet-Draft C. Wang Intended status: Informational S. Robitzsch Expires: December 8, 2019 InterDigital Inc. M. Reed M. Al-Naday Essex University J. Riihijarvi RWTH Aachen June 6, 2019 IP-based Services over ICN in 5G LAN Environments draft-trossen-icnrg-ip-icn-5glan-00 Abstract In this draft, we provide architecture and operations for enabling IP services over ICN over (5G-enabled) LAN environments. Operations include ICN API to upper layers, HTTP over ICN, Service Proxy Operations, ICN Flow Management, Name Resolution, Mobility Handling, and Dual Stack Device Support. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 8, 2019. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of Trossen, et al. Expires December 8, 2019 [Page 1]
Internet-Draft IP over ICN in 5GLAN June 2019 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. 5G Control Plane Services . . . . . . . . . . . . . . . . 5 3.2. HTTP-based Streaming . . . . . . . . . . . . . . . . . . 6 4. 5GLAN in 5G Next Generation Core Network Architecture . . . . 7 4.1. Realization in SDN Transport Networks . . . . . . . . . . 10 4.2. Realization in Other Transport Networks . . . . . . . . . 10 5. IP-based Services over ICN over 5GLAN . . . . . . . . . . . . 11 5.1. General Operations . . . . . . . . . . . . . . . . . . . 13 5.2. ICN API to Upper Layers . . . . . . . . . . . . . . . . . 14 5.3. HTTP over ICN . . . . . . . . . . . . . . . . . . . . . . 15 5.3.1. General Mapping Procedures . . . . . . . . . . . . . 15 5.3.2. Realizing Ad-Hoc Multicast Responses for HTTP . . . . 15 5.4. Service Proxy Operations . . . . . . . . . . . . . . . . 16 5.5. ICN Flow Management . . . . . . . . . . . . . . . . . . . 17 5.6. NR Operations . . . . . . . . . . . . . . . . . . . . . . 17 5.7. Mobility Handling . . . . . . . . . . . . . . . . . . . . 17 5.8. Dual Stack Device Support . . . . . . . . . . . . . . . . 17 6. Deployment Considerations . . . . . . . . . . . . . . . . . . 18 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 19 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 11. Informative References . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 1. Introduction As discussed in [I-D.ravi-icnrg-5gc-icn], Information-Centric Networks (ICN) could be more easily implemented in a Local Area Network (LAN) environment. In relation to 5G, this specifically would realize an ICN deployment without requiring integration of ICN capabilities into the 5G core network itself. In the currently defined 5G core network, 5GLAN capabilities are being introduced that provide a LAN abstraction to 5G endpoints, allowing for Ethernet packets to be sent across a 5G network, Trossen, et al. Expires December 8, 2019 [Page 2]
Internet-Draft IP over ICN in 5GLAN June 2019 therefore extending the provisioning of LAN capabilities from fixed and Wifi-based networks to cellular ones. Utilizing such ICN realization over 5GLAN, the objective of this draft is to propose an architecture to enable IP-based services over such ICN-over-LAN environment with the reference architectural discussions in the 5G core network 3GPP specifications [TS23.501] [TS23.502] forming the basis of our discussions. This draft also complements work related to various ICN deployment opportunities explored in [I-D.irtf-icnrg-deployment-guidelines], where 5G technology is considered as one of the promising alternatives. In that, ICN is used as an underlay technology to provide routing capabilities to IP-based services. Through such replacement of IP routing with ICN routing, we capitalize on several ICN capabilities: o Edge Computing: Multi-access Edge Computing (MEC) is located at the edge of the network and aids several latency sensitive applications such as augmented and virtual reality (AR/VR), as well as the ultra reliable and low latency class (URLLC) of applications such as autonomous vehicles. Enabling edge computing over an IP converged 5GC comes with the challenge of application level reconfiguration required to re-initialize a session whenever it is being served by a non-optimal service instance topologically. In contrast, named-based networking, as considered by ICN, naturally supports service-centric networking, which minimizes network related configuration for applications and allows fast resolution for named service instances. This opportunity is realized by interpreting IP-based services as transactions over an ICN routed network with flexible routing to the nearest execution point for said transaction. o Edge Storage and Caching: A principal design feature of ICN is the secured content (or named data) object, which allows location independent data replication at strategic storage points in the network, or data dissemination through ICN routers by means of opportunistic caching. These features benefit both real-time and non-real-time applications whenever there is spatial and temporal correlation among content accessed by these users, thereby advantageous to both high-bandwidth and low-latency applications such as conferencing, AR/VR, and non-real time applications such as Video-on-Demand (VOD) and IoT transactions. This opportunity is realized by the transaction-based model of realizing IP-based service on top of an ICN routed network, where transaction results can be retrieved from a number of network locations. Trossen, et al. Expires December 8, 2019 [Page 3]
Internet-Draft IP over ICN in 5GLAN June 2019 o Opportunistic Multicast: The vast majority of current Internet traffic is due to unicast delivery of relatively immutable content such as video or software to very large client groups. This has resulted in large amount of redundancy in network traffic, as well as creating capacity bottlenecks both in the core network as well as the server infrastructure serving the content. Technologies such as content delivery networks (CDNs) help to spread out the network load, but are complex to manage, have inherent limits in terms of how rapidly they can react to changing network and server conditions, and cannot fundamentally reduce the network overhead arising from redundant unicast streams. Furthermore, CDNs traditionally only reach into Points-of-Presence (POP) within customer networks, therefore not reducing the load of transfer from said POP to the end customers in that edge network. In contrast, ICN enables opportunistic multicast delivery of content. We realize this opportunity by automatically delivering responses to quasi-concurrent requests in a single lightweight multicast transmission over the L2 customer network, extending the reach of CDNs down to the end user. Unlike traditional IP multicast, no setup time overhead is added and no per-flow state is required in the network. In this document, we first outline possible use cases, capitalizing on the aforementioned ICN capabilities before discussing the proposed extensions to 5G to support a cellular-based LAN connectivity before outlining our proposal to support IP-based services over an ICN- routed LAN connectivity in such 5G environments. 2. Terminology Following are terminologies relevant to this draft: 5G-NextGen Core (5GC): Refers to the new 5G core network architecture being developed by 3GPP, we specifically refer to the architectural discussions in [TS23.501] [TS23.502]. 5GLAN: Refers to the extensions to the new 5G core network architecture that provide LAN connectivity to 5G devices connected via, e.g., new 5G air interfaces. User Plane Function (UPF): UPF is the generalized logical data plane function with context of the UE PDU session. UPFs can play many roles, such as, being a flow classifier, a PDU session anchoring point, or a branching point. Packet Data Network (PDN or DN): This refers to service networks that belong to the operator or third party offered as a service to the UE. Trossen, et al. Expires December 8, 2019 [Page 4]
Internet-Draft IP over ICN in 5GLAN June 2019 Unified Data Management (UDM): Realizes unified data management for wireless, wireline and any other types of subscribers for M2M, IOT applications, etc. UDM reports subscriber related vital information e.g. virtual edge region, list of location visits, sessions active etc. UDM works as a subscriber anchor point so that means OSS/BSS systems will have centralized monitoring-of/ access-to of the system to get/set subscriber information. Authentication Server Function (AUSF): Provides mechanism for unified authentication for subscribers related to wireless, wireline and any other types of subscribers such as M2M and IOT applications. The functions performed by AUSF are similar to HSS with additional functionalities to related to 5G. Session Management Function (SMF): Performs session management functions for attached users equipment (UE) in the 5G Core. SMF can thus be formed by leveraging the Control and User Plane Separation (CUPS) feature with control plane session management. Access Mobility Function (AMF): Perform access mobility management for attached user equipment (UE) to the 5G core network. The function includes, network access stratus (NAS) mobility functions such as authentication and authorization. Application Function (AF): Helps with influencing the user plane routing state in 5GC considering service requirements. Network Slicing: This conceptualizes the grouping for a set of logical or physical network functions with its own or shared control, data and service plane to meet specific service requirements. 3. Use Cases 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 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 Trossen, et al. Expires December 8, 2019 [Page 5]
Internet-Draft IP over ICN in 5GLAN June 2019 plane can be modelled based on service function chains where the relationship is between the specific (IP-based) 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 Trossen, et al. Expires December 8, 2019 [Page 6]
Internet-Draft IP over ICN in 5GLAN June 2019 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. 5GLAN in 5G Next Generation Core Network Architecture In this section, for brevity purposes, we restrict the discussions to the 5G extensions currently studied in 3GPP to facilitate a distributed, cellular-based LAN connectivity to end users, based on the 5G next generation core network architecture. For more information on the latter, we refer to [TS23.501] [TS23.502] as well as [I-D.ravi-icnrg-5gc-icn]. Trossen, et al. Expires December 8, 2019 [Page 7]
Internet-Draft IP over ICN in 5GLAN June 2019 +------+ +------+ +-----+ +-----+ +-----+ +-----+ | NSSF | | NEF | | NRF | | PCF | | UDM | | AF | +--o---+ +--o---+ +--o--+ +--o--+ +--o--+ +--o--+ Nnssf| Nnef| Nnrf| Npcf| Nudm| Naf| -----+-------+-+---------+--+------+-------+-+---------+--------- Nausf| Namf| Nsmf| +--o--+ +--o--+ +--o--+ | AUSF| | AMF | | SMF | +-----+ +-+-+-+ +--+--+ / | | +---------+ | | N1 / |N2 N4| +-N9/Nx-+ +------+ | | | | / | | | V +-+--+ +----+----+ N3 +-+--+-------+--+ N6 +----+ | UE +----------------+ (R)AN +------+ UPF +----->+ DN | +----+ +---------+ +---------------+ +----+ Figure 1: 5G Core Network with Vertical_LAN (5GLAN) Extensions Figure 1 shows the current 5G Core Network Architecture being discussed within the scope of the normative work addressing 5GLAN Type services in the 3GPP System Architecture Working Group 2 (3GPP SA2), referred formally as "5GS Enhanced support of Vertical and LAN Services" [SA2-5GLAN]. The goal of this work item is to provide distributed LAN-based connectivity between two or more terminals or User Equipment entities (UEs) connected to the 5G network. The SMF (session management function) provides a registration and discovery protocol that allows UEs wanting to communicate via a relevant 5GLAN group towards one or more UEs also members of this 5GLAN group, to determine the suitable forwarding information after each UE previously registered suitable identifier information with the SMF responsible to manage the paths across UEs in a 5GLAN group. UEs register and discover (obtain) suitable identifiers during the establishment of a Protocol Data Unit (PDU) Session or PDU Session Modification procedure. Suitable identifier information, according to [SA2-5GLAN], are Ethernet MAC addresses as well as IP addresses (the latter is usually assigned during the session setup through the SMF, i.e., the session management function). The SMF that manages the path across UEs in a 5GLAN group, then establishes the suitable procedures to ensure the forwarding between the required UPFs (user plane functions) to ensure the LAN connectivity between the UEs (user equipments) provided in the original request to the SMF. When using the N9 interface to the UPF, this forwarding will rely on a tunnel-based approach between the UPFs along the path, while the Nx interface uses path-based forwarding Trossen, et al. Expires December 8, 2019 [Page 8]
Internet-Draft IP over ICN in 5GLAN June 2019 between UPFs, while LAN-based forwarding is utilized between the final UPF and the UE (utilizing the N3 interface towards the destination UE). In the following, path-based forwarding is assumed, i.e., the usage of the Nx interface and the utilization of a path identifier for the end-to-end LAN communication. Here, the path between the source and destination UPFs is encoded through a bitfield, provided in the packet header. Each bit position in said bitfield represents a unique link in the network. Upon receiving an incoming packet, each UPF inspects said bitfield for the presence of any local link that is being served by one of its output ports. Such presence check is implemented via a simple binary AND and CMP operation. If no link is being found, the packet is dropped. Such bitfield-based path representation also allows for creating multicast relations in an ad hoc manner by combining two or more path identifiers through a binary OR operation. Note that due to the assignment of a bit position to a link, path identifiers are bidirectional and can therefore be used for request/response communication without incurring any need for path computation on the return path. For sending a packet from one Layer 2 device (UE) connected to one UPF (via a RAN) to a device connected to another UPF, we provide the MAC address of the destination and perform a header re-write by providing the destination MAC address of the ingress UPF when sending from source device to ingress and placing the end destination MAC address in the payload. Upon arrival at the egress UPF, after having applied the path-based forwarding between ingress and egress UPF, the end destination address is restored while the end source MAC is placed in the payload with the egress L2 forwarder one being used as the L2 source MAC for the link-local transfer. At the end device (or proxy device), the end source MAC address is restored as the source MAC, providing an abstraction of a link-local L2 communication between the end source and destination devices. +---------+---------+----------+-----------+-----------+ | Src MAC | Dst MAC | pathID | NAME_ID | Payload | +---------+---------+----------------------+-----------+ Figure 2: General Packet Structure For this end-to-end transfer, the general packet structure of Figure 2 is used. The Name_ID field is being used for the ICN operations, while the payload contains the information related to the transaction-based flow management described in Section 5.6 and the Trossen, et al. Expires December 8, 2019 [Page 9]
Internet-Draft IP over ICN in 5GLAN June 2019 PATH_ID is the bitfield-based path identifier for the path-based forwarding. 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 IP-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 Trossen, et al. Expires December 8, 2019 [Page 10]
Internet-Draft IP over ICN in 5GLAN June 2019 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. 5. IP-based Services over ICN over 5GLAN Trossen, et al. Expires December 8, 2019 [Page 11]
Internet-Draft IP over ICN in 5GLAN June 2019 +-------------------------------+ | Forwarding Network | .... Control | +--------------------------+ | | | . NR . | | **** Data | +-.----------------------.-+ | +--------------+ | . . | +--------------+ | App | | +-.---------+ +---------.-+ | | App | +-----+----+---+ | | . ******* | | ******* . | | +--------------+ |HTTP*|TCP*|IP.| | | . * UPF * | | * UPF * . | | |.IP|*TCP|*HTTP| +----*+---*+--.+ | +-.-*-----*-+ +-*-----*-.-+ | +.--+*---+*----+ |ICN * * .| | . * * * * . | |. * * ICN| +----*----*---.+ +---+ . * ******** * . +---+ +.---*----*----+ |L2 * * ....|RAN+.. * * ..+RAN|.... * * | | ********************** ********************** | +--------------+ +---+ . * * . +---+ +--------------+ | . * * . | | +-.-*-----+ +-----*-.+ | +--| . * RAN|------|RAN * .|--+ +-.-*-----+ +-----*-.+ . * * . . ******* ******* . Legacy Service ....... * * ....... Service Device Proxy . * * . Proxy +-----+ +-------------------+ . * * . +-------------------+ |APP *| | ********* | . * * . | ********** | +----*+ +----*+ * | . * * . | * +*----+ |HTTP*| |HTTP*|******* | . * * . | ********|*HTTP| +----*+ +----*-+ * | . * * . | * +*----+ |TCP *| |TCP * |****** | . * * . | *******| * TCP| +----*+ +----*--+ +*------+ . * * . +-----*+ +---*----+ +-------+ |IP *| |IP * |***|* ICN .| . * * . |.ICN *|***| * IP| | IP | +----*+ +----*--+---+*-----.+ . * * . +.----*+---+---*----+ |Peering| |L2 *| | * L2 * .... * * .... * * | |Network| | ********* ************ *********** ************ | +-----+ +-------------------+ +-------------------+ +-------+ Figure 3: IP-based Services over ICN over 5GLAN Figure 3 shows the protocol layering for realizing IP-based protocols over an ICN over 5GLAN transport, assuming an end-to-end LAN connectivity provided by solutions such as 5GLAN. Note that such LAN connectivity can also be found in environments such as localized LAN-based deployments in smart cities, enterprises and others, with the UPF representing, e.g., an SDN switch (utilizing the methods outlined in Section 4.1). Hence, the solutions described in this section also applies to those deployments. Trossen, et al. Expires December 8, 2019 [Page 12]
Internet-Draft IP over ICN in 5GLAN June 2019 Key to the approach is that Internet services are being interpreted as the main unit of transfer in the architecture shown in Figure 3. For this, any Internet service is treated as a Named Service Transaction (NST) which is in turn suitably routed over an ICN layer in one or more other devices. As a result of this name-based interpretation of any Internet service, the protocol stack in end devices flattens to four layers with Internet services and ICN, with ICN acting as a name-based routing layer for all IP protocols implemented atop, with Layer 1 and 2 realizing the end-to-end packet forwarding outlined in Section 4 (over a 5G environment) or a general LAN environment provided through WiFi or fixed Ethernet technologies. The general ICN operations are presented in Section 5.1 before discussing the assumed (strawman) API to the ICN layer in Section 5.2, which is used in turn to define the mapping of HTTP transactions to operations at the ICN layer in Section 5.3 for the example of HTTP. As explained in that section, the ICN layer uses an interaction with the NR to register and discover HTTP-based services for determining the suitable end-to-end packet forwarding information. Interfaces to legacy devices and peering networks are preserved through service proxy devices, which terminate a traditional Internet protocol stack communication and translate it into a resulting flat protocol transaction. Termination here can be based on well-known port numbers for specific Internet protocols, ultimately falling back to the IP datagram service being the minimal service being mapped. The operations of said service proxy devices is described in Section 5.4. An important aspect of the architecture is the mapping of the end-to- end flow semantic established in many Internet services onto the flat protocol stack. Section 5.5 outlines the flow management that exists between the end devices. The mapping of protocol identifiers onto ICN forwarding relations, i.e., the operations of the name resolver (NR), shown in Figure 3, is described in Section 5.6, followed by the procedures for handling mobility of service providers and consumers in Section 5.7. Finally, the support for dual-stack devices, not requiring a service proxy device yet being able to also connect to existing IP routed networks, is described in Section 5.8. 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 Trossen, et al. Expires December 8, 2019 [Page 13]
Internet-Draft IP over ICN in 5GLAN June 2019 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 IP 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: o conn = send(name, payload) o send(conn, payload) Trossen, et al. Expires December 8, 2019 [Page 14]
Internet-Draft IP over ICN in 5GLAN June 2019 o conn = receive(name, &payload) o 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.3.1. General Mapping Procedures To realize the flat device nature, Internet service layers, such as the HTTP protocol stack or the TCP protocol stack, will need to be adapted to run atop this new API, implementing the semantics of the respective Internet protocol through suitable transactions at the name level. In the example of HTTP, the standard operations of DNS resolution for the server to be contacted and opening of a TCP socket are altogether replaced by a single send(FQDN, HTTP request) call, while the response will be sent by the server, which received the request through a receive(FQDN, &payload) call, using the returned conn parameter to send the response with the second send() API call. Note that the use of bidirectional pathIDs, no NR lookup is performed at the HTTP serving endpoint. 5.3.2. Realizing Ad-Hoc Multicast Responses for HTTP The basis of a named service transaction allows to deliver the same HTTP responses to several requestees in efficient multicast (see [I-D.ietf-bier-multicast-http-response] for use cases in a BIER-based transport network environment). This opportunity is realized by sending the same payload (i.e., an HTTP response to the same resource across a number of pending requests) through a combination of several conn parameters received in the incoming requests via the receive() function. Trossen, et al. Expires December 8, 2019 [Page 15]
Internet-Draft IP over ICN in 5GLAN June 2019 What is required in the HTTP stack implementation is a logic to decide that two or more outstanding requests are possible to be served by one response. For this, upon receiving an incoming request, the HTTP stack determines any outstanding request to the same resource. 'Same' here is defined as URI-specific combination of the request URI and URI-specific header fields, such as browsing agent or similar, called requestID in the following. Once such determination is made that two requests are relating to the same resource, i.e., are having the same request ID, the HTTP stack maintains a temporary mapping of the request ID to the respective conn parameters delivered by the receive() call. Upon receiving the HTTP response from its application-level logic, the HTTP stack will generate the suitable send(conn, payload) call where the provided conn parameter is bitwise OR of all previously stored conn parameters received in the receive() call. The ICN layer will recognize the use of those ad-hoc created conn parameters and set the destination MAC address in the general packet structure of Figure 2 to the Ethernet broadcast MAC address as the destination address, leading to sending the response to all end devices at the egress L2 forwarders to which the response will be forwarded based on the combined conn parameter. Alternatively, one could request IEEE assignment for a specific Ethernet multicast address for this scheme instead of using the broadcast address. For the local end device to determine the relevance of the response received at the broadcast channel, the HTTP stack of the serving endpoint includes the aforementioned requestID into the payload of the packet (see Figure 2), while the originating endpoint maintains an internal table with the requestID of pending requests and its associated conn handle. If no matching requestID is found, the packet is not being delivered to the ICN layer of the incoming device. If a request is found, the ICN layer delivers the response via the receive() call, using the conn handle stored in the pending request table. Note that this filtering mechanism can easily be implemented in hardware upon standardizing the appropriate payload and header fields. 5.4. 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. Trossen, et al. Expires December 8, 2019 [Page 16]
Internet-Draft IP over ICN in 5GLAN June 2019 5.5. ICN Flow Management EDITOR NOTE: left for future draft updates. 5.6. 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.7. Mobility Handling EDITOR NOTE: left for future draft updates. 5.8. Dual Stack Device Support Figure 3 outlines a protocol stack for the user equipment that realizes IP-based 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.ravi-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.ravi-icnrg-5gc-icn] envision the realization of IP-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 IP-based 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. Trossen, et al. Expires December 8, 2019 [Page 17]
Internet-Draft IP over ICN in 5GLAN June 2019 6. Deployment Considerations The work in [I-D.irtf-icnrg-deployment-guidelines] outlines a comprehensive set of considerations related to the deployment of ICN. We now relate the solutions proposed in this draft to the two main aspects covered in the deployment considerations draft, namely the 'deployment configuration' (covered in Section 3 of [I-D.irtf-icnrg-deployment-guidelines]) that is being realized and the 'deployment migration paths' (covered in Section 4 of [I-D.irtf-icnrg-deployment-guidelines]) that are being provided. The solutions proposed in this draft relate to those "deployment configuration" as follows: o The realization of IP-based service on top of an ICN routing capabilities, as proposed in Section 5, follows the "ICN-as-an- Underlay" categorization, interpreting the ICN routing as an underlay to the IP services with the path-based forwarding being compatible with the 5GLAN forwarding capabilities currently discussed in 3GPP and therefore providing an underlay integration capability for the ICN forwarding used in the proposed solution. o The deployment of 5GLAN based ICN capabilities can be realized following the "ICN-as-a-Slice" deployment configuration, i.e., the 5GLAN connectivity is provided to a "vertical 5G customer" which in turn provides the ICN capability over 5GLAN within said network (and compute) slice at the endpoints of the 5GLAN connectivity, as proposed in Section 3. In relation of the 'deployment migration paths', the solutions in this draft relate as follows: o The integration with the 5GLAN capability, as proposed in Section 5, facilitates "edge network migration" (interpreting the cellular sub-system here as an edge network albeit a possibly geographically large one. o The single stack realization, as proposed in Figure 3, as well as the dual-stack deployment, as proposed in Section 5.8, facilitate "application and services migration" through not only supporting ICN applications but also IP-based applications through the proposed IP-over-ICN mapping in the terminal. o The IP over ICN over 5GLAN deployment, possibly combined with an ICN-as-a-Slice deployment, facilitates the "content delivery networks migration" through a deployment of IP-over-ICN-based 5GLAN connected CDN elements in (virtualized) edge network nodes or POP locations in the customer (5G) network. Trossen, et al. Expires December 8, 2019 [Page 18]
Internet-Draft IP over ICN in 5GLAN June 2019 7. Conclusion In this draft, we explored the feasibility of enabling IP services directly over ICN network over (5G)LAN environments. We proposed the architecture and discussed corresponding operations of mapping IP- based services onto name-based transactions, with the specific example of HTTP-based transactions. We described the flow management, the realization of opportunistic multicast responses for HTTP as well as the realization of dual-stack user equipment. Future updates to the draft will provide more details to the flow management in terms of reliable transport between IP-over-ICN enabled end- systems as well as mobility handling. We also described the deployment scenario for supporting IP services over ICN over 5GLAN. 8. IANA Considerations This document requests no IANA actions. 9. Security Considerations Editor Note: to be added in future drafts. 10. Acknowledgments Work towards developing the solutions outlined in this draft have been funded under grants of the [H2020POINT] and [H2020FLAME] projects. 11. Informative References [H2020FLAME] H2020, "The FLAME Project", https://www.ict-flame.eu/ . [H2020POINT] H2020, "The POINT Project", https://www.point-h2020.eu/ . [I-D.galis-anima-autonomic-slice-networking] Galis, A., Makhijani, K., Yu, D., and B. Liu, "Autonomic Slice Networking", draft-galis-anima-autonomic-slice- networking-05 (work in progress), September 2018. [I-D.ietf-bier-multicast-http-response] Purkayastha, D., Rahman, A., Trossen, D., and T. Eckert, "Applicability of BIER Multicast Overlay for Adaptive Streaming Services", draft-ietf-bier-multicast-http- response-00 (work in progress), February 2019. Trossen, et al. Expires December 8, 2019 [Page 19]
Internet-Draft IP over ICN in 5GLAN June 2019 [I-D.irtf-icnrg-deployment-guidelines] Rahman, A., Trossen, D., Kutscher, D., and R. Ravindran, "Deployment Considerations for Information-Centric Networking (ICN)", draft-irtf-icnrg-deployment- guidelines-06 (work in progress), May 2019. [I-D.irtf-icnrg-icn-lte-4g] suthar, P., Stolic, M., Jangam, A., Trossen, D., and R. Ravindran, "Native Deployment of ICN in LTE, 4G Mobile Networks", draft-irtf-icnrg-icn-lte-4g-03 (work in progress), March 2019. [I-D.muscariello-intarea-hicn] Muscariello, L., Carofiglio, G., Auge, J., and M. Papalini, "Hybrid Information-Centric Networking", draft- muscariello-intarea-hicn-01 (work in progress), December 2018. [I-D.ravi-icnrg-5gc-icn] Ravindran, R., suthar, P., Trossen, D., Wang, C., and G. White, "Enabling ICN in 3GPP's 5G NextGen Core Architecture", draft-ravi-icnrg-5gc-icn-04 (work in progress), May 2019. [I-D.white-icnrg-ipoc] White, G., Shannigrahi, S., and C. Fan, "Internet Protocol Tunneling over Content Centric Mobile Networks", draft- white-icnrg-ipoc-01 (work in progress), June 2018. [Khalili] Khalili, R., Poe, W., Despotovic, Z., and A. Hecker, "Reducing State of SDN Switches in Mobile Core Networks by Flow Rule Aggregation", IEEE ICCCN 2016, Hawaii, USA, August 2016. [OpenFlowSwitch] Open Networking Foundation, available at https://www.opennetworking.org/wp-content/uploads/2014/10/ openflow-switch-v1.5.1.pdf, "OpenFlow Switch Specification V1.5.1", 2018. [Reed] Reed, M., AI-Naday, M., Thomos, N., Trossen, D., Petropoulos, G., and S. Spirou, "Stateless Multicast Switching in Software Defined Networks", IEEE ICC 2016, Kuala Lumpur, Maylaysia, 2016. Trossen, et al. Expires December 8, 2019 [Page 20]
Internet-Draft IP over ICN in 5GLAN June 2019 [RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, "Information-Centric Networking (ICN) Research Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, <https://www.rfc-editor.org/info/rfc7927>. [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., Przygienda, T., and S. Aldrin, "Multicast Using Bit Index Explicit Replication (BIER)", RFC 8279, DOI 10.17487/RFC8279, November 2017, <https://www.rfc-editor.org/info/rfc8279>. [SA2-5GLAN] 3gpp-5glan, "SP-181129, Work Item Description, Vertical_LAN(SA2), 5GS Enhanced Support of Vertical and LAN Services", 3GPP , http://www.3gpp.org/ftp/tsg_sa/TSG_SA/TSGS_82/Docs/ SP-181120.zip. [SBA-ENHANCEMENT] 3gpp-sba-enhancement, "S2-182904, New SID for Enhancements to the Service-Based 5G System Architecture.", 3GPP , February 2018 (http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSG S2_126_Montreal/Docs/S2-182904.zip). [SDN-DEFINITION] Open Networking Foundation, available at https://www.opennetworking.org/sdn-definition/, "Software- Defined Networking (SDN) Definition", 2018. [TS23.501] 3gpp-23.501, "Technical Specification Group Services and System Aspects; System Architecture for the 5G System; Stage 2 (Rel.15)", 3GPP , December 2018. [TS23.502] 3gpp-23.502, "Technical Specification Group Services and System Aspects; Procedures for the 5G System; Stage 2 (Rel. 15)", 3GPP , January 2019. [TS29.500] 3gpp-29.500, "Technical Realization of Service Based Architecture.", 3GPP , January 2018. Trossen, et al. Expires December 8, 2019 [Page 21]
Internet-Draft IP over ICN in 5GLAN June 2019 Authors' Addresses Dirk Trossen InterDigital Inc. 64 Great Eastern Street, 1st Floor London EC2A 3QR United Kingdom Email: Dirk.Trossen@InterDigital.com URI: http://www.InterDigital.com/ Chonggang Wang InterDigital Inc. 1001 E Hector St, Suite 300 Conshohocken PA 19428 United States Email: Chonggang.Wang@InterDigital.com URI: http://www.InterDigital.com/ Sebastian Robitzsch InterDigital Inc. 64 Great Eastern Street, 1st Floor London EC2A 3QR United Kingdom Email: Sebastian.Robitzsch@InterDigital.com URI: http://www.InterDigital.com/ Martin Reed Essex University Colchester United Kingdom Email: mjreed@essec.ac.uk URI: https://www.essex.ac.uk/people/reedm58703/martin-reed Mays Al-Naday Essex University Colchester United Kingdom Email: mfhaln@essec.ac.uk URI: https://www.essex.ac.uk/people/alned81405/mays-al-naday Trossen, et al. Expires December 8, 2019 [Page 22]
Internet-Draft IP over ICN in 5GLAN June 2019 Janne Riihijarvi RWTH Aachen Aachen Germany Email: jariihij@googlemail.com URI: https://www.inets.rwth-aachen.de/about-us/janne-riihijaervi/ Trossen, et al. Expires December 8, 2019 [Page 23]