idnits 2.17.1 draft-trossen-icnrg-internet-icn-5glan-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 30, 2019) is 1640 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.galis-anima-autonomic-slice-networking' is defined on line 852, but no explicit reference was found in the text == Unused Reference: 'I-D.muscariello-intarea-hicn' is defined on line 881, but no explicit reference was found in the text == Unused Reference: 'I-D.white-icnrg-ipoc' is defined on line 893, but no explicit reference was found in the text == Unused Reference: 'RFC7927' is defined on line 914, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-bier-multicast-http-response-01 == Outdated reference: A later version (-13) exists of draft-ietf-bier-te-arch-04 == Outdated reference: A later version (-12) exists of draft-irtf-icnrg-icn-lte-4g-04 == Outdated reference: A later version (-04) exists of draft-muscariello-intarea-hicn-03 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICNRG D. Trossen 3 Internet-Draft C. Wang 4 Intended status: Informational S. Robitzsch 5 Expires: May 2, 2020 InterDigital Inc. 6 M. Reed 7 M. Al-Naday 8 Essex University 9 J. Riihijarvi 10 RWTH Aachen 11 October 30, 2019 13 Internet Services over ICN in 5G LAN Environments 14 draft-trossen-icnrg-internet-icn-5glan-00 16 Abstract 18 In this draft, we provide architecture and operations for enabling 19 Internet services over ICN over (5G-enabled) LAN environments. 20 Operations include ICN API to upper layers, HTTP over ICN, Service 21 Proxy Operations, ICN Flow Management, Name Resolution, Mobility 22 Handling, and Dual Stack Device Support. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on May 2, 2020. 41 Copyright Notice 43 Copyright (c) 2019 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.1. 5G Control Plane Services . . . . . . . . . . . . . . . . 5 62 3.2. HTTP-based Streaming . . . . . . . . . . . . . . . . . . 6 63 4. 5GLAN in 5G Next Generation Core Network Architecture . . . . 7 64 4.1. Realization in SDN Transport Networks . . . . . . . . . . 10 65 4.2. Realization in Other Transport Networks . . . . . . . . . 10 66 5. Internet Services over ICN over 5GLAN . . . . . . . . . . . . 11 67 5.1. General Operations . . . . . . . . . . . . . . . . . . . 13 68 5.2. ICN API to Upper Layers . . . . . . . . . . . . . . . . . 14 69 5.3. HTTP over ICN . . . . . . . . . . . . . . . . . . . . . . 15 70 5.3.1. General Mapping Procedures . . . . . . . . . . . . . 15 71 5.3.2. Realizing Ad-Hoc Multicast Responses for HTTP . . . . 15 72 5.4. Service Proxy Operations . . . . . . . . . . . . . . . . 16 73 5.5. ICN Flow Management . . . . . . . . . . . . . . . . . . . 17 74 5.6. NR Operations . . . . . . . . . . . . . . . . . . . . . . 17 75 5.7. Mobility Handling . . . . . . . . . . . . . . . . . . . . 17 76 5.8. Dual Stack Device Support . . . . . . . . . . . . . . . . 17 77 6. Deployment Considerations . . . . . . . . . . . . . . . . . . 18 78 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 19 79 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 80 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 81 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 82 11. Informative References . . . . . . . . . . . . . . . . . . . 19 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 85 1. Introduction 87 As discussed in [I-D.ravi-icnrg-5gc-icn], Information-Centric 88 Networks (ICN) could be more easily implemented in a Local Area 89 Network (LAN) environment. In relation to 5G, this specifically 90 would realize an ICN deployment without requiring integration of ICN 91 capabilities into the 5G core network itself. 93 In the currently defined 5G core network, 5GLAN capabilities are 94 being introduced that provide a LAN abstraction to 5G endpoints, 95 allowing for Ethernet packets to be sent across a 5G network, 96 therefore extending the provisioning of LAN capabilities from fixed 97 and Wifi-based networks to cellular ones. 99 Utilizing such ICN realization over 5GLAN, the objective of this 100 draft is to propose an architecture to enable Internet services over 101 such ICN-over-LAN environment with the reference architectural 102 discussions in the 5G core network 3GPP specifications [TS23.501] 103 [TS23.502] forming the basis of our discussions. This draft also 104 complements work related to various ICN deployment opportunities 105 explored in [I-D.irtf-icnrg-deployment-guidelines], where 5G 106 technology is considered as one of the promising alternatives. In 107 that, ICN is used as an underlay technology to provide routing 108 capabilities to Internet services. 110 Through such replacement of IP routing with ICN routing, we 111 capitalize on several ICN capabilities: 113 o Edge Computing: Multi-access Edge Computing (MEC) is located at 114 the edge of the network and aids several latency sensitive 115 applications such as augmented and virtual reality (AR/VR), as 116 well as the ultra reliable and low latency class (URLLC) of 117 applications such as autonomous vehicles. Enabling edge computing 118 over an IP converged 5GC comes with the challenge of application 119 level reconfiguration required to re-initialize a session whenever 120 it is being served by a non-optimal service instance 121 topologically. In contrast, named-based networking, as considered 122 by ICN, naturally supports service-centric networking, which 123 minimizes network related configuration for applications and 124 allows fast resolution for named service instances. This 125 opportunity is realized by interpreting Internet services as 126 transactions over an ICN routed network with flexible routing to 127 the nearest execution point for said transaction. 129 o Edge Storage and Caching: A principal design feature of ICN is the 130 secured content (or named data) object, which allows location 131 independent data replication at strategic storage points in the 132 network, or data dissemination through ICN routers by means of 133 opportunistic caching. These features benefit both real-time and 134 non-real-time applications whenever there is spatial and temporal 135 correlation among content accessed by these users, thereby 136 advantageous to both high-bandwidth and low-latency applications 137 such as conferencing, AR/VR, and non-real time applications such 138 as Video-on-Demand (VOD) and IoT transactions. This opportunity 139 is realized by the transaction-based model of realizing Internet 140 service on top of an ICN routed network, where transaction results 141 can be retrieved from a number of network locations. 143 o Opportunistic Multicast: The vast majority of current Internet 144 traffic is due to unicast delivery of relatively immutable content 145 such as video or software to very large client groups. This has 146 resulted in large amount of redundancy in network traffic, as well 147 as creating capacity bottlenecks both in the core network as well 148 as the server infrastructure serving the content. Technologies 149 such as content delivery networks (CDNs) help to spread out the 150 network load, but are complex to manage, have inherent limits in 151 terms of how rapidly they can react to changing network and server 152 conditions, and cannot fundamentally reduce the network overhead 153 arising from redundant unicast streams. Furthermore, CDNs 154 traditionally only reach into Points-of-Presence (POP) within 155 customer networks, therefore not reducing the load of transfer 156 from said POP to the end customers in that edge network. In 157 contrast, ICN enables opportunistic multicast delivery of content. 158 We realize this opportunity by automatically delivering responses 159 to quasi-concurrent requests in a single lightweight multicast 160 transmission over the L2 customer network, extending the reach of 161 CDNs down to the end user. Unlike traditional IP multicast, no 162 setup time overhead is added and no per-flow state is required in 163 the network. 165 In this document, we first outline possible use cases, capitalizing 166 on the aforementioned ICN capabilities before discussing the proposed 167 extensions to 5G to support a cellular-based LAN connectivity before 168 outlining our proposal to support Internet services over an ICN- 169 routed LAN connectivity in such 5G environments. 171 2. Terminology 173 Following are terminologies relevant to this draft: 175 5G-NextGen Core (5GC): Refers to the new 5G core network 176 architecture being developed by 3GPP, we specifically refer to the 177 architectural discussions in [TS23.501] [TS23.502]. 179 5GLAN: Refers to the extensions to the new 5G core network 180 architecture that provide LAN connectivity to 5G devices connected 181 via, e.g., new 5G air interfaces. 183 User Plane Function (UPF): UPF is the generalized logical data 184 plane function with context of the UE PDU session. UPFs can play 185 many roles, such as, being a flow classifier, a PDU session 186 anchoring point, or a branching point. 188 Packet Data Network (PDN or DN): This refers to service networks 189 that belong to the operator or third party offered as a service to 190 the UE. 192 Unified Data Management (UDM): Realizes unified data management 193 for wireless, wireline and any other types of subscribers for M2M, 194 IOT applications, etc. UDM reports subscriber related vital 195 information e.g. virtual edge region, list of location visits, 196 sessions active etc. UDM works as a subscriber anchor point so 197 that means OSS/BSS systems will have centralized monitoring-of/ 198 access-to of the system to get/set subscriber information. 200 Authentication Server Function (AUSF): Provides mechanism for 201 unified authentication for subscribers related to wireless, 202 wireline and any other types of subscribers such as M2M and IOT 203 applications. The functions performed by AUSF are similar to HSS 204 with additional functionalities to related to 5G. 206 Session Management Function (SMF): Performs session management 207 functions for attached users equipment (UE) in the 5G Core. SMF 208 can thus be formed by leveraging the Control and User Plane 209 Separation (CUPS) feature with control plane session management. 211 Access Mobility Function (AMF): Perform access mobility management 212 for attached user equipment (UE) to the 5G core network. The 213 function includes, network access stratus (NAS) mobility functions 214 such as authentication and authorization. 216 Application Function (AF): Helps with influencing the user plane 217 routing state in 5GC considering service requirements. 219 Network Slicing: This conceptualizes the grouping for a set of 220 logical or physical network functions with its own or shared 221 control, data and service plane to meet specific service 222 requirements. 224 3. Use Cases 226 3.1. 5G Control Plane Services 228 We exemplify the need for chaining service functions at the level of 229 a service name through a use case stemming from the current 3GPP 230 Rel-16 work on Service Based Architecture (SBA) [TS29.500] 231 [SBA-ENHANCEMENT]. In this work, mobile network control planes are 232 proposed to be realized by replacing the traditional network function 233 interfaces with a fully service-based one. HTTP was chosen as the 234 application layer protocol for exchanging suitable service requests 235 [TS29.500]. With this in mind, the exchange between, say the 3GPP 236 (Rel-15) defined Session Management Function (SMF) and the Access and 237 Mobility management Function (AMF) in a 5G control plane is being 238 described as a set of web service like requests which are in turn 239 embedded into HTTP requests. Hence, interactions in a 5G control 240 plane can be modelled based on service function chains where the 241 relationship is between the specific service function endpoints that 242 implement the necessary service endpoints in the SMF and AMF. The 243 service functions are exposed through URIs with work ongoing to 244 define the used naming conventions for such URIs. 246 This move from a network function model (in pre-Rel 15 systems of 247 3GPP) to a service-based model is motivated through the proliferation 248 of data center operations for mobile network control plane services. 249 In other words, typical IT-based methods to service provisioning, in 250 particular that of virtualization of entire compute resources, are 251 envisioned to being used in future operations of mobile networks. 252 Hence, operators of such future mobile networks desire to virtualize 253 service function endpoints and direct (control plane) traffic to the 254 most appropriate current service instance in the most appropriate 255 (local) data centre, such data centre envisioned as being 256 interconnected through a software-defined wide area network (SD-WAN). 257 'Appropriate' here can be defined by topological or geographical 258 proximity of the service initiator to the service function endpoint. 259 Alternatively, network or service instance compute load can be used 260 to direct a request to a more appropriate (in this case less loaded) 261 instance to reduce possible latency of the overall request. Such 262 data center centric operation is extended with the trend towards 263 regionalization of load through a 'regional office' approach, where 264 micro data centers provide virtualizable resources that can be used 265 in the service execution, creating a larger degree of freedom when 266 choosing the 'most appropriate' service endpoint for a particular 267 incoming service request. This 5G control plane scenario capitalizes 268 on the edge computing capabilities of ICN by allowing for fast 269 redirections of HTTP-based transactions to the nearest control plane 270 service realization within the distributed data centre of the 5G 271 operator infrastructure. 273 3.2. HTTP-based Streaming 275 With the extensive use of "web technology", "distributed services" 276 and availability of heterogeneous network, HTTP has effectively 277 transitioned into the common transport or session layer for E2E and 278 multi-hop communication across the web. Assume clients that are 279 consuming the same content (such as a TV program) and that this 280 content has for each block (typically segments worth 2 seconds of 281 content) a set of outstanding requests from its clients. HTTP 282 request and response used in media streaming services like HLS, use 283 HTTP response for delivery of content. In such scenarios, where 284 semi-synchronous access to the same resource occurs (such as watching 285 prominent videos over Netflix or similar platforms or live TV over 286 HTTP), traffic grows linearly with the number of viewers since the 287 HTTP-based server will provide an HTTP response to each individual 288 viewer. To mitigate the load impact, operators often utilize IP 289 multicast underneath HTTP (for live TV) to create fewer, multicast, 290 streams; though this comes with the high flow setup and management 291 cost. This poses a significant burden on operators in terms of costs 292 and on users in terms of likely degradation of quality. 294 This problem is not limited to traditional TV broadcasting. Consider 295 a virtual reality use case where several users are joining a VR 296 session at the same time, e.g., centered around a joint event. 297 Hence, due to the temporal correlation of the VR sessions, we can 298 assume that multiple requests are sent for the same content at any 299 point, particularly when viewing angles of VR clients are similar or 300 the same. Due to availability of virtual functions and cloud 301 technology, the actual end point from where content is delivered may 302 change. For this type of scenarios, the opportunistic multicast 303 capability of ICN may be utilized to reduce overall load in the 304 network, as well as on the server providing the HTTP responses. The 305 latter also allows constrained resources to serve a higher volume of 306 demands and therefore incur a higher impact on traffic distribution 307 in the network. 309 4. 5GLAN in 5G Next Generation Core Network Architecture 311 In this section, for brevity purposes, we restrict the discussions to 312 the 5G extensions currently studied in 3GPP to facilitate a 313 distributed, cellular-based LAN connectivity to end users, based on 314 the 5G next generation core network architecture. For more 315 information on the latter, we refer to [TS23.501] [TS23.502] as well 316 as [I-D.ravi-icnrg-5gc-icn]. 318 +------+ +------+ +-----+ +-----+ +-----+ +-----+ 319 | NSSF | | NEF | | NRF | | PCF | | UDM | | AF | 320 +--o---+ +--o---+ +--o--+ +--o--+ +--o--+ +--o--+ 321 Nnssf| Nnef| Nnrf| Npcf| Nudm| Naf| 322 -----+-------+-+---------+--+------+-------+-+---------+--------- 323 Nausf| Namf| Nsmf| 324 +--o--+ +--o--+ +--o--+ 325 | AUSF| | AMF | | SMF | 326 +-----+ +-+-+-+ +--+--+ 327 / | | 328 +---------+ | | 329 N1 / |N2 N4| +-N9/Nx-+ 330 +------+ | | | | 331 / | | | V 332 +-+--+ +----+----+ N3 +-+--+-------+--+ N6 +----+ 333 | UE +----------------+ (R)AN +------+ UPF +----->+ DN | 334 +----+ +---------+ +---------------+ +----+ 336 Figure 1: 5G Core Network with Vertical_LAN (5GLAN) Extensions 338 Figure 1 shows the current 5G Core Network Architecture being 339 discussed within the scope of the normative work addressing 5GLAN 340 Type services in the 3GPP System Architecture Working Group 2 (3GPP 341 SA2), referred formally as "5GS Enhanced support of Vertical and LAN 342 Services" [SA2-5GLAN]. The goal of this work item is to provide 343 distributed LAN-based connectivity between two or more terminals or 344 User Equipment entities (UEs) connected to the 5G network. The SMF 345 (session management function) provides a registration and discovery 346 protocol that allows UEs wanting to communicate via a relevant 5GLAN 347 group towards one or more UEs also members of this 5GLAN group, to 348 determine the suitable forwarding information after each UE 349 previously registered suitable identifier information with the SMF 350 responsible to manage the paths across UEs in a 5GLAN group. UEs 351 register and discover (obtain) suitable identifiers during the 352 establishment of a Protocol Data Unit (PDU) Session or PDU Session 353 Modification procedure. Suitable identifier information, according 354 to [SA2-5GLAN], are Ethernet MAC addresses as well as IP addresses 355 (the latter is usually assigned during the session setup through the 356 SMF, i.e., the session management function). 358 The SMF that manages the path across UEs in a 5GLAN group, then 359 establishes the suitable procedures to ensure the forwarding between 360 the required UPFs (user plane functions) to ensure the LAN 361 connectivity between the UEs (user equipments) provided in the 362 original request to the SMF. When using the N9 interface to the UPF, 363 this forwarding will rely on a tunnel-based approach between the UPFs 364 along the path, while the Nx interface uses path-based forwarding 365 between UPFs, while LAN-based forwarding is utilized between the 366 final UPF and the UE (utilizing the N3 interface towards the 367 destination UE). 369 In the following, path-based forwarding is assumed, i.e., the usage 370 of the Nx interface and the utilization of a path identifier for the 371 end-to-end LAN communication. Here, the path between the source and 372 destination UPFs is encoded through a bitfield, provided in the 373 packet header. Each bit position in said bitfield represents a 374 unique link in the network. Upon receiving an incoming packet, each 375 UPF inspects said bitfield for the presence of any local link that is 376 being served by one of its output ports. Such presence check is 377 implemented via a simple binary AND and CMP operation. If no link is 378 being found, the packet is dropped. Such bitfield-based path 379 representation also allows for creating multicast relations in an ad 380 hoc manner by combining two or more path identifiers through a binary 381 OR operation. Note that due to the assignment of a bit position to a 382 link, path identifiers are bidirectional and can therefore be used 383 for request/response communication without incurring any need for 384 path computation on the return path. 386 For sending a packet from one Layer 2 device (UE) connected to one 387 UPF (via a RAN) to a device connected to another UPF, we provide the 388 MAC address of the destination and perform a header re-write by 389 providing the destination MAC address of the ingress UPF when sending 390 from source device to ingress and placing the end destination MAC 391 address in the payload. Upon arrival at the egress UPF, after having 392 applied the path-based forwarding between ingress and egress UPF, the 393 end destination address is restored while the end source MAC is 394 placed in the payload with the egress L2 forwarder one being used as 395 the L2 source MAC for the link-local transfer. At the end device (or 396 proxy device), the end source MAC address is restored as the source 397 MAC, providing an abstraction of a link-local L2 communication 398 between the end source and destination devices. 400 +---------+---------+----------+-----------+-----------+ 401 | Src MAC | Dst MAC | pathID | NAME_ID | Payload | 402 +---------+---------+----------------------+-----------+ 404 Figure 2: General Packet Structure 406 For this end-to-end transfer, the general packet structure of 407 Figure 2 is used. The Name_ID field is being used for the ICN 408 operations, while the payload contains the information related to the 409 transaction-based flow management described in Section 5.6 and the 410 PATH_ID is the bitfield-based path identifier for the path-based 411 forwarding. 413 4.1. Realization in SDN Transport Networks 415 An emerging technology for Layer 2 forwarding that suits the 5GLAN 416 architecture in Figure 1 is that of Software-Defined networking (SDN) 417 [SDN-DEFINITION], which allows for programmatically forwarding 418 packets at Layer 2. Switch-based rules are being executed with such 419 rules being populated by the SDN controller. Rules can act upon so- 420 called matching fields, as defined by the OpenFlow protocol 421 specification [OpenFlowSwitch]. Those fields include Ethernet MAC 422 addresses, IPv4/6 source and destination addresses and other well- 423 known Layer 3 and even 4 transport fields. 425 As shown in [Reed], efficient path-based forwarding can be realized 426 in SDN networks by placing the aforementioned path identifiers into 427 the IPv6 source/destination fields of a forwarded packet. Utilizing 428 the IPv6 source/destination fields allows for natively supporting 256 429 links in a transport network. Larger topologies can be supported by 430 extension schemes but are left out of this paper for brevity of the 431 presentation. During network bootstrapping, each link at each switch 432 is assigned a unique bitnumber in the bitfield. In order to forward 433 based on such bitfield path information, the SDN controller is 434 instructed to insert a suitable wildcard matching rule into the SDN 435 switch. This wildcard at a given switch is defined by the bitnumber 436 that has been assigned to a particular link at that switch during 437 bootstrapping. Wildcard matching as a generalization of longest 438 prefix matching is natively supported by SDN-based switches since the 439 OpenFlow v1.3 specification, efficiently implemented through TCAM 440 based operations. With that, SDN forwarding actions only depend on 441 the switch-local number of output ports, while being able to 442 transport any number of higher-layer flows over the same transport 443 network without specific flow rules being necessary. This results in 444 a constant forwarding table size while no controller-switch 445 interaction is necessary for any flow setup; only changes in 446 forwarding topology (resulting in a change of port to bit number 447 assignment) will require suitable changes of forwarding rules in 448 switches. 450 4.2. Realization in Other Transport Networks 452 Although we focus the methods in this draft on Layer 2 forwarding 453 approaches and realization of Internet-over-ICN over a 5G LAN enabled 454 network, path-based transport networks can also be established as an 455 overlay over otherwise Layer 2 networks. For instance, the BIER (Bit 456 Indexed Explicit Replication) [RFC8279] efforts within the Internet 457 Engineer Task Force (IETF) establish such path-based forwarding 458 transport as an overlay over existing, e.g., MPLS networks. The 459 path-based forwarding identification is similar to the aforementioned 460 SDN realization although the bitfield represents ingress/egress 461 information rather than links along the path. 463 Yet another transport network example is presented in [Khalili], 464 utilizing flow aggregation over SDN networks. The flow aggregation 465 again results in a path representation that is independent from the 466 specific flows traversing the network. 468 The proposed traffic engineering extensions to BIER, presented in 469 [I-D.ietf-bier-te-arch], directly align with the SDN-based 470 realization presented in Section 4.1, by proposing the same 471 bitposition per transport link assignment being used, resulting in 472 BIER bitstrings in which a dedicated forwarding path is encoded as a 473 unique bitpattern containing said bitpositions of the chosen 474 forwarding links. The BIER-TE controller plays a similar role as the 475 northbound SDN controller application utilized for the solution in 476 Section 4.1. 478 5. Internet Services over ICN over 5GLAN 479 +-------------------------------+ 480 | Forwarding Network | .... Control 481 | +--------------------------+ | 482 | | . NR . | | **** Data 483 | +-.----------------------.-+ | 484 +--------------+ | . . | +--------------+ 485 | App | | +-.---------+ +---------.-+ | | App | 486 +-----+----+---+ | | . ******* | | ******* . | | +--------------+ 487 |HTTP*|TCP*|IP.| | | . * UPF * | | * UPF * . | | |.IP|*TCP|*HTTP| 488 +----*+---*+--.+ | +-.-*-----*-+ +-*-----*-.-+ | +.--+*---+*----+ 489 |ICN * * .| | . * * * * . | |. * * ICN| 490 +----*----*---.+ +---+ . * ******** * . +---+ +.---*----*----+ 491 |L2 * * ....|RAN+.. * * ..+RAN|.... * * | 492 | ********************** ********************** | 493 +--------------+ +---+ . * * . +---+ +--------------+ 494 | . * * . | 495 | +-.-*-----+ +-----*-.+ | 496 +--| . * RAN|------|RAN * .|--+ 497 +-.-*-----+ +-----*-.+ 498 . * * . 499 . ******* ******* . 500 Legacy Service ....... * * ....... Service 501 Device Proxy . * * . Proxy 502 +-----+ +-------------------+ . * * . +-------------------+ 503 |APP *| | ********* | . * * . | ********** | 504 +----*+ +----*+ * | . * * . | * +*----+ 505 |HTTP*| |HTTP*|******* | . * * . | ********|*HTTP| 506 +----*+ +----*-+ * | . * * . | * +*----+ 507 |TCP *| |TCP * |****** | . * * . | *******| * TCP| 508 +----*+ +----*--+ +*------+ . * * . +-----*+ +---*----+ +-------+ 509 |IP *| |IP * |***|* ICN .| . * * . |.ICN *|***| * IP| | IP | 510 +----*+ +----*--+---+*-----.+ . * * . +.----*+---+---*----+ |Peering| 511 |L2 *| | * L2 * .... * * .... * * | |Network| 512 | ********* ************ *********** ************ | 513 +-----+ +-------------------+ +-------------------+ +-------+ 515 Figure 3: Internet Services over ICN over 5GLAN 517 Figure 3 shows the protocol layering for realizing Internet protocols 518 over an ICN over 5GLAN transport, assuming an end-to-end LAN 519 connectivity provided by solutions such as 5GLAN. 521 Note that such LAN connectivity can also be found in environments 522 such as localized LAN-based deployments in smart cities, enterprises 523 and others, with the UPF representing, e.g., an SDN switch (utilizing 524 the methods outlined in Section 4.1). Hence, the solutions described 525 in this section also applies to those deployments. 527 Key to the approach is that Internet services are being interpreted 528 as the main unit of transfer in the architecture shown in Figure 3. 529 For this, any Internet service is treated as a Named Service 530 Transaction (NST) which is in turn suitably routed over an ICN layer 531 in one or more other devices. As a result of this name-based 532 interpretation of any Internet service, the protocol stack in end 533 devices flattens to four layers with Internet services and ICN, with 534 ICN acting as a name-based routing layer for all IP protocols 535 implemented atop, with Layer 1 and 2 realizing the end-to-end packet 536 forwarding outlined in Section 4 (over a 5G environment) or a general 537 LAN environment provided through WiFi or fixed Ethernet technologies. 539 The general ICN operations are presented in Section 5.1 before 540 discussing the assumed (strawman) API to the ICN layer in 541 Section 5.2, which is used in turn to define the mapping of HTTP 542 transactions to operations at the ICN layer in Section 5.3 for the 543 example of HTTP. As explained in that section, the ICN layer uses an 544 interaction with the NR to register and discover HTTP-based services 545 for determining the suitable end-to-end packet forwarding 546 information. 548 Interfaces to legacy devices and peering networks are preserved 549 through service proxy devices, which terminate a traditional Internet 550 protocol stack communication and translate it into a resulting flat 551 protocol transaction. Termination here can be based on well-known 552 port numbers for specific Internet protocols, ultimately falling back 553 to the IP datagram service being the minimal service being mapped. 554 The operations of said service proxy devices is described in 555 Section 5.4. 557 An important aspect of the architecture is the mapping of the end-to- 558 end flow semantic established in many Internet services onto the flat 559 protocol stack. Section 5.5 outlines the flow management that exists 560 between the end devices. 562 The mapping of protocol identifiers onto ICN forwarding relations, 563 i.e., the operations of the name resolver (NR), shown in Figure 3, is 564 described in Section 5.6, followed by the procedures for handling 565 mobility of service providers and consumers in Section 5.7. Finally, 566 the support for dual-stack devices, not requiring a service proxy 567 device yet being able to also connect to existing IP routed networks, 568 is described in Section 5.8. 570 5.1. General Operations 572 The semantics of our name-based routing is that of a publish- 573 subscribe system over a name. The intention to receive packets with 574 a certain name is expressed through a subscription while sending 575 packets to a name is expressed through a publication. The matching 576 of a sender to a receiver is realized through NR in Figure 3. The 577 exact nature of the matching is defined through the semantics of the 578 service and, therefore, through the nature of the name provided. For 579 instance, HTTP and raw Internet services are matched to exactly one 580 subscriber only, providing an anycast capability, while IP multicast 581 services are matched against any subscriber (with the IP multicast 582 address being the name). 584 Structured names are used with the root specific to the (Internet) 585 service name, such as URL, and therefore deriving the matching 586 semantics directly from the name. 588 The subscription to a name is realized through a registration 589 protocol between end device and NR. Hence, any end device exposing a 590 certain Internet service registers the suitable name with the NR, 591 which in turn stores reachability information that is suitable for 592 path calculation between the ingress and egress L2 forwarders between 593 which the communication eventually will take place. In our current 594 realization, we utilize shortest paths only although other link 595 weights can be utilized for, e.g., delay-constrained and other 596 policies. 598 In our realization, we use network domain unique host identifiers 599 that are being assigned to end devices during the connectivity setup. 600 Sending a packet of a given Internet service is realized through a 601 discovery protocol, which returns a suitable pathID, i.e., the 602 forwarding information between ingress and egress L2 forwarder, and 603 the destination MAC address of the hosting end device. It is this 604 pathID and MAC address that is being used in the general packet 605 structure of Figure 2 to forward the packet to the destination. 607 To reduce latency in further communication, the forwarding 608 information is locally cached at the end device, while the cached 609 information is being maintained through path updates sent by the NR 610 in case of hosting end devices having moved or de-registered, 611 therefore avoiding stale forwarding information. 613 5.2. ICN API to Upper Layers 615 The operations of the ICN layer are exposed to upper layers in 616 Figure 1 through the following API calls, being exemplary here for 617 the further explanation of operations in the next sub-sections: 619 o conn = send(name, payload) 621 o send(conn, payload) 622 o conn = receive(name, &payload) 624 o receive(conn, &payload) 626 The first send() call is used for initiating a send operation to a 627 name with a connection handle returned, while the second send() is 628 used for return calls, using a connection parameters that is being 629 received with the receive() call to an incoming connection or for 630 subsequence outgoing calls after an initial request to a name has 631 been made. A return send() is being received at the other (client) 632 side through the second receive() call where the conn parameter is 633 obtained by the corresponding send() call for the outgoing call. 634 With these API functions, we provide means for providing name-based 635 transactions with return responses association provided natively. 637 The conn parameter represents the bitfield used for path-based 638 forwarding in the remote host case or the hash of the local MAC 639 address in case of link-local connections. 641 5.3. HTTP over ICN 643 5.3.1. General Mapping Procedures 645 To realize the flat device nature, Internet service layers, such as 646 the HTTP protocol stack or the TCP protocol stack, will need to be 647 adapted to run atop this new API, implementing the semantics of the 648 respective Internet protocol through suitable transactions at the 649 name level. In the example of HTTP, the standard operations of DNS 650 resolution for the server to be contacted and opening of a TCP socket 651 are altogether replaced by a single send(FQDN, HTTP request) call, 652 while the response will be sent by the server, which received the 653 request through a receive(FQDN, &payload) call, using the returned 654 conn parameter to send the response with the second send() API call. 655 Note that the use of bidirectional pathIDs, no NR lookup is performed 656 at the HTTP serving endpoint. 658 5.3.2. Realizing Ad-Hoc Multicast Responses for HTTP 660 The basis of a named service transaction allows to deliver the same 661 HTTP responses to several requestees in efficient multicast (see 662 [I-D.ietf-bier-multicast-http-response] for use cases in a BIER-based 663 transport network environment). 665 This opportunity is realized by sending the same payload (i.e., an 666 HTTP response to the same resource across a number of pending 667 requests) through a combination of several conn parameters received 668 in the incoming requests via the receive() function. 670 What is required in the HTTP stack implementation is a logic to 671 decide that two or more outstanding requests are possible to be 672 served by one response. For this, upon receiving an incoming 673 request, the HTTP stack determines any outstanding request to the 674 same resource. 'Same' here is defined as URI-specific combination of 675 the request URI and URI-specific header fields, such as browsing 676 agent or similar, called requestID in the following. 678 Once such determination is made that two requests are relating to the 679 same resource, i.e., are having the same request ID, the HTTP stack 680 maintains a temporary mapping of the request ID to the respective 681 conn parameters delivered by the receive() call. Upon receiving the 682 HTTP response from its application-level logic, the HTTP stack will 683 generate the suitable send(conn, payload) call where the provided 684 conn parameter is bitwise OR of all previously stored conn parameters 685 received in the receive() call. The ICN layer will recognize the use 686 of those ad-hoc created conn parameters and set the destination MAC 687 address in the general packet structure of Figure 2 to the Ethernet 688 broadcast MAC address as the destination address, leading to sending 689 the response to all end devices at the egress L2 forwarders to which 690 the response will be forwarded based on the combined conn parameter. 691 Alternatively, one could request IEEE assignment for a specific 692 Ethernet multicast address for this scheme instead of using the 693 broadcast address. For the local end device to determine the 694 relevance of the response received at the broadcast channel, the HTTP 695 stack of the serving endpoint includes the aforementioned requestID 696 into the payload of the packet (see Figure 2), while the originating 697 endpoint maintains an internal table with the requestID of pending 698 requests and its associated conn handle. If no matching requestID is 699 found, the packet is not being delivered to the ICN layer of the 700 incoming device. If a request is found, the ICN layer delivers the 701 response via the receive() call, using the conn handle stored in the 702 pending request table. Note that this filtering mechanism can easily 703 be implemented in hardware upon standardizing the appropriate payload 704 and header fields. 706 5.4. Service Proxy Operations 708 The service proxy in Figure 3 serves the integration of legacy 709 devices, i.e., with regular IP protocol stack, and the 710 interconnection to IP-based peering networks. It registers suitable 711 identifiers with the NR to ensure the reception of (ICN) packets, 712 while providing suitable protocol termination for the various 713 supported protocols. For instance, for HTTP, the service proxy 714 towards the peering network will register a wildcard name to the NR 715 to receive any HTTP request not destined to a network-locally 716 registered FQDN, operating as an HTTP proxy towards the peering 717 network. 719 5.5. ICN Flow Management 721 EDITOR NOTE: left for future draft updates. 723 5.6. NR Operations 725 The NR in Figure 3 combines the operations of the SMF and the PMF in 726 5GLAN (see Figure 1), by allowing for registering IP protocol 727 identifiers for discovery and subsequent path computation by 728 resolving the destination(s) to a suitable pathID and destination MAC 729 address for forwarding. This will require extensions to the 730 operations of the SMF to allow for such higher layer identifiers to 731 be registered (and discovered), in addition to the already supported 732 Ethernet and IP addresses. 734 5.7. Mobility Handling 736 EDITOR NOTE: left for future draft updates. 738 5.8. Dual Stack Device Support 740 Figure 3 outlines a protocol stack for the user equipment that 741 realizes Internet services on top of the proposed name-based routing 742 layer as a single stack device. However, [I-D.irtf-icnrg-icn-lte-4g] 743 outlines the possibility of supporting dual-stack devices for 4G LTE 744 networks by allowing IP as well as ICN protocol stacks to be deployed 745 with the operation of IP and ICN based applications. 746 [I-D.ravi-icnrg-5gc-icn] outlines the same dual-stack device 747 realization for a 5G ICN realization. For both environments, a 748 convergence layer is described that selects the appropriate data path 749 for each ICN or IP application, e.g., based on configuration per 750 application (similar to selecting network interfaces such as WiFi 751 over cellular). 753 As a possible data path selection, [I-D.irtf-icnrg-icn-lte-4g] and 754 [I-D.ravi-icnrg-5gc-icn] envision the realization of Internet-over- 755 ICN (Section 4.2 in [I-D.irtf-icnrg-icn-lte-4g]) in which the 756 convergence layer would realize similar mapping functions as 757 described in this draft. Hence, we foresee the utilization of such 758 dual-stack devices connected to an Internet services over ICN over 759 5GLAN environment. When utilizing the service proxy, IP applications 760 that are configured to use the IP data path only could still utilize 761 the ICN-based forwarding in the network. In that case, functionality 762 such as the opportunistic multicast in Section 5.3.2 would only reach 763 up to the service proxy with unicast traffic continuing along the 764 data path towards the user equipment. 766 6. Deployment Considerations 768 The work in [I-D.irtf-icnrg-deployment-guidelines] outlines a 769 comprehensive set of considerations related to the deployment of ICN. 770 We now relate the solutions proposed in this draft to the two main 771 aspects covered in the deployment considerations draft, namely the 772 'deployment configuration' (covered in Section 3 of 773 [I-D.irtf-icnrg-deployment-guidelines]) that is being realized and 774 the 'deployment migration paths' (covered in Section 4 of 775 [I-D.irtf-icnrg-deployment-guidelines]) that are being provided. 777 The solutions proposed in this draft relate to those "deployment 778 configuration" as follows: 780 o The realization of Internet service on top of an ICN routing 781 capabilities, as proposed in Section 5, follows the "ICN-as-an- 782 Underlay" categorization, interpreting the ICN routing as an 783 underlay to the Internet services with the path-based forwarding 784 being compatible with the 5GLAN forwarding capabilities currently 785 discussed in 3GPP and therefore providing an underlay integration 786 capability for the ICN forwarding used in the proposed solution. 788 o The deployment of 5GLAN based ICN capabilities can be realized 789 following the "ICN-as-a-Slice" deployment configuration, i.e., the 790 5GLAN connectivity is provided to a "vertical 5G customer" which 791 in turn provides the ICN capability over 5GLAN within said network 792 (and compute) slice at the endpoints of the 5GLAN connectivity, as 793 proposed in Section 3. 795 In relation of the 'deployment migration paths', the solutions in 796 this draft relate as follows: 798 o The integration with the 5GLAN capability, as proposed in 799 Section 5, facilitates "edge network migration" (interpreting the 800 cellular sub-system here as an edge network albeit a possibly 801 geographically large one. 803 o The single stack realization, as proposed in Figure 3, as well as 804 the dual-stack deployment, as proposed in Section 5.8, facilitate 805 "application and services migration" through not only supporting 806 ICN applications but also Internet applications through the 807 proposed Internet-over-ICN mapping in the terminal. 809 o The Internet over ICN over 5GLAN deployment, possibly combined 810 with an ICN-as-a-Slice deployment, facilitates the "content 811 delivery networks migration" through a deployment of Internet- 812 over-ICN-based 5GLAN connected CDN elements in (virtualized) edge 813 network nodes or POP locations in the customer (5G) network. 815 7. Conclusion 817 In this draft, we explored the feasibility of enabling Internet 818 services directly over ICN network over (5G)LAN environments. We 819 proposed the architecture and discussed corresponding operations of 820 mapping Internet services onto name-based transactions, with the 821 specific example of HTTP-based transactions. We described the flow 822 management, the realization of opportunistic multicast responses for 823 HTTP as well as the realization of dual-stack user equipment. Future 824 updates to the draft will provide more details to the flow management 825 in terms of reliable transport between Internet-overIP-ICN enabled 826 end-systems as well as mobility handling. We also described the 827 deployment scenario for supporting Internet services over ICN over 828 5GLAN. 830 8. IANA Considerations 832 This document requests no IANA actions. 834 9. Security Considerations 836 Editor Note: to be added in future drafts. 838 10. Acknowledgments 840 Work towards developing the solutions outlined in this draft have 841 been funded under grants of the [H2020POINT] and [H2020FLAME] 842 projects. 844 11. Informative References 846 [H2020FLAME] 847 H2020, "The FLAME Project", https://www.ict-flame.eu/ . 849 [H2020POINT] 850 H2020, "The POINT Project", https://www.point-h2020.eu/ . 852 [I-D.galis-anima-autonomic-slice-networking] 853 Galis, A., Makhijani, K., Yu, D., and B. Liu, "Autonomic 854 Slice Networking", draft-galis-anima-autonomic-slice- 855 networking-05 (work in progress), September 2018. 857 [I-D.ietf-bier-multicast-http-response] 858 Trossen, D., Rahman, A., Wang, C., and T. Eckert, 859 "Applicability of BIER Multicast Overlay for Adaptive 860 Streaming Services", draft-ietf-bier-multicast-http- 861 response-01 (work in progress), June 2019. 863 [I-D.ietf-bier-te-arch] 864 Eckert, T., Cauchie, G., and M. Menth, "Traffic 865 Engineering for Bit Index Explicit Replication (BIER-TE)", 866 draft-ietf-bier-te-arch-04 (work in progress), October 867 2019. 869 [I-D.irtf-icnrg-deployment-guidelines] 870 Rahman, A., Trossen, D., Kutscher, D., and R. Ravindran, 871 "Deployment Considerations for Information-Centric 872 Networking (ICN)", draft-irtf-icnrg-deployment- 873 guidelines-07 (work in progress), September 2019. 875 [I-D.irtf-icnrg-icn-lte-4g] 876 suthar, P., Stolic, M., Jangam, A., Trossen, D., and R. 877 Ravindran, "Native Deployment of ICN in LTE, 4G Mobile 878 Networks", draft-irtf-icnrg-icn-lte-4g-04 (work in 879 progress), September 2019. 881 [I-D.muscariello-intarea-hicn] 882 Muscariello, L., Carofiglio, G., Auge, J., and M. 883 Papalini, "Hybrid Information-Centric Networking", draft- 884 muscariello-intarea-hicn-03 (work in progress), October 885 2019. 887 [I-D.ravi-icnrg-5gc-icn] 888 Ravindran, R., suthar, P., Trossen, D., Wang, C., and G. 889 White, "Enabling ICN in 3GPP's 5G NextGen Core 890 Architecture", draft-ravi-icnrg-5gc-icn-04 (work in 891 progress), May 2019. 893 [I-D.white-icnrg-ipoc] 894 White, G., Shannigrahi, S., and C. Fan, "Internet Protocol 895 Tunneling over Content Centric Mobile Networks", draft- 896 white-icnrg-ipoc-02 (work in progress), June 2019. 898 [Khalili] Khalili, R., Poe, W., Despotovic, Z., and A. Hecker, 899 "Reducing State of SDN Switches in Mobile Core Networks by 900 Flow Rule Aggregation", IEEE ICCCN 2016, Hawaii, USA, 901 August 2016. 903 [OpenFlowSwitch] 904 Open Networking Foundation, available at 905 https://www.opennetworking.org/wp-content/uploads/2014/10/ 906 openflow-switch-v1.5.1.pdf, "OpenFlow Switch Specification 907 V1.5.1", 2018. 909 [Reed] Reed, M., AI-Naday, M., Thomos, N., Trossen, D., 910 Petropoulos, G., and S. Spirou, "Stateless Multicast 911 Switching in Software Defined Networks", IEEE ICC 2016, 912 Kuala Lumpur, Maylaysia, 2016. 914 [RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., 915 Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, 916 "Information-Centric Networking (ICN) Research 917 Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, 918 . 920 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 921 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 922 Explicit Replication (BIER)", RFC 8279, 923 DOI 10.17487/RFC8279, November 2017, 924 . 926 [SA2-5GLAN] 927 3gpp-5glan, "SP-181129, Work Item Description, 928 Vertical_LAN(SA2), 5GS Enhanced Support of Vertical and 929 LAN Services", 3GPP , 930 http://www.3gpp.org/ftp/tsg_sa/TSG_SA/TSGS_82/Docs/SP- 931 181120.zip. 933 [SBA-ENHANCEMENT] 934 3gpp-sba-enhancement, "S2-182904, New SID for Enhancements 935 to the Service-Based 5G System Architecture.", 3GPP , 936 February 2018 (http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/ 937 TSGS2_126_Montreal/Docs/S2-182904.zip). 939 [SDN-DEFINITION] 940 Open Networking Foundation, available at 941 https://www.opennetworking.org/sdn-definition/, "Software- 942 Defined Networking (SDN) Definition", 2018. 944 [TS23.501] 945 3gpp-23.501, "Technical Specification Group Services and 946 System Aspects; System Architecture for the 5G System; 947 Stage 2 (Rel.15)", 3GPP , December 2018. 949 [TS23.502] 950 3gpp-23.502, "Technical Specification Group Services and 951 System Aspects; Procedures for the 5G System; Stage 2 952 (Rel. 15)", 3GPP , January 2019. 954 [TS29.500] 955 3gpp-29.500, "Technical Realization of Service Based 956 Architecture.", 3GPP , January 2018. 958 Authors' Addresses 960 Dirk Trossen 961 InterDigital Inc. 962 64 Great Eastern Street, 1st Floor 963 London EC2A 3QR 964 United Kingdom 966 Email: Dirk.Trossen@InterDigital.com 967 URI: http://www.InterDigital.com/ 969 Chonggang Wang 970 InterDigital Inc. 971 1001 E Hector St, Suite 300 972 Conshohocken PA 19428 973 United States 975 Email: Chonggang.Wang@InterDigital.com 976 URI: http://www.InterDigital.com/ 978 Sebastian Robitzsch 979 InterDigital Inc. 980 64 Great Eastern Street, 1st Floor 981 London EC2A 3QR 982 United Kingdom 984 Email: Sebastian.Robitzsch@InterDigital.com 985 URI: http://www.InterDigital.com/ 987 Martin Reed 988 Essex University 989 Colchester 990 United Kingdom 992 Email: mjreed@essec.ac.uk 993 URI: https://www.essex.ac.uk/people/reedm58703/martin-reed 995 Mays Al-Naday 996 Essex University 997 Colchester 998 United Kingdom 1000 Email: mfhaln@essec.ac.uk 1001 URI: https://www.essex.ac.uk/people/alned81405/mays-al-naday 1002 Janne Riihijarvi 1003 RWTH Aachen 1004 Aachen 1005 Germany 1007 Email: jariihij@googlemail.com 1008 URI: https://www.inets.rwth-aachen.de/about-us/janne-riihijaervi/