idnits 2.17.1 draft-trossen-icnrg-internet-icn-5glan-03.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 1, 2020) is 1293 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 1033, but no explicit reference was found in the text == Unused Reference: 'I-D.muscariello-intarea-hicn' is defined on line 1061, but no explicit reference was found in the text == Unused Reference: 'I-D.white-icnrg-ipoc' is defined on line 1067, but no explicit reference was found in the text == Unused Reference: 'RFC7927' is defined on line 1092, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-bier-multicast-http-response-04 == Outdated reference: A later version (-13) exists of draft-ietf-bier-te-arch-08 == Outdated reference: A later version (-04) exists of draft-irtf-icnrg-5gc-icn-03 == Outdated reference: A later version (-12) exists of draft-irtf-icnrg-icn-lte-4g-08 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 Huawei 4 Intended status: Informational S. Robitzsch 5 Expires: April 4, 2021 InterDigital Inc. 6 M. Reed 7 M. Al-Naday 8 Essex University 9 J. Riihijarvi 10 RWTH Aachen 11 October 1, 2020 13 Internet Services over ICN in 5G LAN Environments 14 draft-trossen-icnrg-internet-icn-5glan-03 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 April 4, 2021. 41 Copyright Notice 43 Copyright (c) 2020 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. IP over ICN . . . . . . . . . . . . . . . . . . . . . . . 16 73 5.5. Service Proxy Operations . . . . . . . . . . . . . . . . 17 74 5.6. Support for Transport Layer Security . . . . . . . . . . 17 75 5.7. ICN Flow Management . . . . . . . . . . . . . . . . . . . 18 76 5.8. NR Operations . . . . . . . . . . . . . . . . . . . . . . 21 77 5.9. Mobility Handling . . . . . . . . . . . . . . . . . . . . 21 78 5.10. Dual Stack Device Support . . . . . . . . . . . . . . . . 21 79 6. Deployment Considerations . . . . . . . . . . . . . . . . . . 21 80 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 22 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 82 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 83 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 84 11. Informative References . . . . . . . . . . . . . . . . . . . 23 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 87 1. Introduction 89 As discussed in [I-D.irtf-icnrg-5gc-icn], Information-Centric 90 Networks (ICN) could be more easily implemented in a Local Area 91 Network (LAN) environment. In relation to 5G, this specifically 92 would realize an ICN deployment without requiring integration of ICN 93 capabilities into the 5G core network itself. 95 In the currently defined 5G core network, 5GLAN capabilities are 96 being introduced that provide a LAN abstraction to 5G endpoints, 97 allowing for Ethernet packets to be sent across a 5G network, 98 therefore extending the provisioning of LAN capabilities from fixed 99 and Wifi-based networks to cellular ones. 101 Utilizing such ICN realization over 5GLAN, the objective of this 102 draft is to propose an architecture to enable Internet services over 103 such ICN-over-LAN environment with the reference architectural 104 discussions in the 5G core network 3GPP specifications [TS23.501] 105 [TS23.502] forming the basis of our discussions. This draft also 106 complements work related to various ICN deployment opportunities 107 explored in [RFC8763], where 5G technology is considered as one of 108 the promising alternatives. In that, ICN is used as an underlay 109 technology to provide routing capabilities to Internet services. 111 Through such replacement of IP routing with ICN routing, we 112 capitalize on several ICN capabilities: 114 o Edge Computing: Multi-access Edge Computing (MEC) is located at 115 the edge of the network and aids several latency sensitive 116 applications such as augmented and virtual reality (AR/VR), as 117 well as the ultra reliable and low latency class (URLLC) of 118 applications such as autonomous vehicles. Enabling edge computing 119 over an IP converged 5GC comes with the challenge of application 120 level reconfiguration required to re-initialize a session whenever 121 it is being served by a non-optimal service instance 122 topologically. In contrast, named-based networking, as considered 123 by ICN, naturally supports service-centric networking, which 124 minimizes network related configuration for applications and 125 allows fast resolution for named service instances. This 126 opportunity is realized by interpreting Internet services as 127 transactions over an ICN routed network with flexible routing to 128 the nearest execution point for said transaction. 130 o Edge Storage and Caching: A principal design feature of ICN is the 131 secured content (or named data) object, which allows location 132 independent data replication at strategic storage points in the 133 network, or data dissemination through ICN routers by means of 134 opportunistic caching. These features benefit both real-time and 135 non-real-time applications whenever there is spatial and temporal 136 correlation among content accessed by these users, thereby 137 advantageous to both high-bandwidth and low-latency applications 138 such as conferencing, AR/VR, and non-real time applications such 139 as Video-on-Demand (VOD) and IoT transactions. This opportunity 140 is realized by the transaction-based model of realizing Internet 141 service on top of an ICN routed network, where transaction results 142 can be retrieved from a number of network locations. 144 o Opportunistic Multicast: The vast majority of current Internet 145 traffic is due to unicast delivery of relatively immutable content 146 such as video or software to very large client groups. This has 147 resulted in large amount of redundancy in network traffic, as well 148 as creating capacity bottlenecks both in the core network as well 149 as the server infrastructure serving the content. Technologies 150 such as content delivery networks (CDNs) help to spread out the 151 network load, but are complex to manage, have inherent limits in 152 terms of how rapidly they can react to changing network and server 153 conditions, and cannot fundamentally reduce the network overhead 154 arising from redundant unicast streams. Furthermore, CDNs 155 traditionally only reach into Points-of-Presence (POP) within 156 customer networks, therefore not reducing the load of transfer 157 from said POP to the end customers in that edge network. In 158 contrast, ICN enables opportunistic multicast delivery of content. 159 We realize this opportunity by automatically delivering responses 160 to quasi-concurrent requests in a single lightweight multicast 161 transmission over the L2 customer network, extending the reach of 162 CDNs down to the end user. Unlike traditional IP multicast, no 163 setup time overhead is added and no per-flow state is required in 164 the network. 166 In this document, we first outline possible use cases, capitalizing 167 on the aforementioned ICN capabilities before discussing the proposed 168 extensions to 5G to support a cellular-based LAN connectivity before 169 outlining our proposal to support Internet services over an ICN- 170 routed LAN connectivity in such 5G environments. 172 2. Terminology 174 Following are terminologies relevant to this draft: 176 5G-NextGen Core (5GC): Refers to the new 5G core network 177 architecture being developed by 3GPP, we specifically refer to the 178 architectural discussions in [TS23.501] [TS23.502]. 180 5GLAN: Refers to the extensions to the new 5G core network 181 architecture that provide LAN connectivity to 5G devices connected 182 via, e.g., new 5G air interfaces. 184 User Plane Function (UPF): UPF is the generalized logical data 185 plane function with context of the UE PDU session. UPFs can play 186 many roles, such as, being a flow classifier, a PDU session 187 anchoring point, or a branching point. 189 Packet Data Network (PDN or DN): This refers to service networks 190 that belong to the operator or third party offered as a service to 191 the UE. 193 Unified Data Management (UDM): Realizes unified data management 194 for wireless, wireline and any other types of subscribers for M2M, 195 IOT applications, etc. UDM reports subscriber related vital 196 information e.g. virtual edge region, list of location visits, 197 sessions active etc. UDM works as a subscriber anchor point so 198 that means OSS/BSS systems will have centralized monitoring-of/ 199 access-to of the system to get/set subscriber information. 201 Authentication Server Function (AUSF): Provides mechanism for 202 unified authentication for subscribers related to wireless, 203 wireline and any other types of subscribers such as M2M and IOT 204 applications. The functions performed by AUSF are similar to HSS 205 with additional functionalities to related to 5G. 207 Session Management Function (SMF): Performs session management 208 functions for attached users equipment (UE) in the 5G Core. SMF 209 can thus be formed by leveraging the Control and User Plane 210 Separation (CUPS) feature with control plane session management. 212 Access Mobility Function (AMF): Perform access mobility management 213 for attached user equipment (UE) to the 5G core network. The 214 function includes, network access stratus (NAS) mobility functions 215 such as authentication and authorization. 217 Application Function (AF): Helps with influencing the user plane 218 routing state in 5GC considering service requirements. 220 Network Slicing: This conceptualizes the grouping for a set of 221 logical or physical network functions with its own or shared 222 control, data and service plane to meet specific service 223 requirements. 225 3. Use Cases 227 3.1. 5G Control Plane Services 229 We exemplify the need for chaining service functions at the level of 230 a service name through a use case stemming from the current 3GPP 231 Rel-16 work on Service Based Architecture (SBA) [TS29.500] 232 [SBA-ENHANCEMENT]. In this work, mobile network control planes are 233 proposed to be realized by replacing the traditional network function 234 interfaces with a fully service-based one. HTTP/2 was chosen as the 235 application layer protocol for exchanging suitable service requests 236 [TS29.500]. With this in mind, the exchange between, say the 3GPP 237 (Rel-15) defined Session Management Function (SMF) and the Access and 238 Mobility management Function (AMF) in a 5G control plane is being 239 described as a set of web service like requests which are in turn 240 embedded into HTTP requests. Hence, interactions in a 5G control 241 plane can be modelled based on service function chains where the 242 relationship is between the specific service function endpoints that 243 implement the necessary service endpoints in the SMF and AMF. The 244 service functions are exposed through URIs with work ongoing to 245 define the used naming conventions for such URIs. 247 This move from a network function model (in pre-Rel 15 systems of 248 3GPP) to a service-based model is motivated through the proliferation 249 of data center operations for mobile network control plane services. 250 In other words, typical IT-based methods to service provisioning, in 251 particular that of virtualization of entire compute resources, are 252 envisioned to being used in future operations of mobile networks. 253 Hence, operators of such future mobile networks desire to virtualize 254 service function endpoints and direct (control plane) traffic to the 255 most appropriate current service instance in the most appropriate 256 (local) data centre, such data centre envisioned as being 257 interconnected through a software-defined wide area network (SD-WAN). 258 'Appropriate' here can be defined by topological or geographical 259 proximity of the service initiator to the service function endpoint. 260 Alternatively, network or service instance compute load can be used 261 to direct a request to a more appropriate (in this case less loaded) 262 instance to reduce possible latency of the overall request. Such 263 data center centric operation is extended with the trend towards 264 regionalization of load through a 'regional office' approach, where 265 micro data centers provide virtualizable resources that can be used 266 in the service execution, creating a larger degree of freedom when 267 choosing the 'most appropriate' service endpoint for a particular 268 incoming service request. This 5G control plane scenario capitalizes 269 on the edge computing capabilities of ICN by allowing for fast 270 redirections of HTTP-based transactions to the nearest control plane 271 service realization within the distributed data centre of the 5G 272 operator infrastructure. 274 3.2. HTTP-based Streaming 276 With the extensive use of "web technology", "distributed services" 277 and availability of heterogeneous network, HTTP has effectively 278 transitioned into the common transport or session layer for E2E and 279 multi-hop communication across the web. Assume clients that are 280 consuming the same content (such as a TV program) and that this 281 content has for each block (typically segments worth 2 seconds of 282 content) a set of outstanding requests from its clients. HTTP 283 request and response used in media streaming services like HLS, use 284 HTTP response for delivery of content. In such scenarios, where 285 semi-synchronous access to the same resource occurs (such as watching 286 prominent videos over Netflix or similar platforms or live TV over 287 HTTP), traffic grows linearly with the number of viewers since the 288 HTTP-based server will provide an HTTP response to each individual 289 viewer. To mitigate the load impact, operators often utilize IP 290 multicast underneath HTTP (for live TV) to create fewer, multicast, 291 streams; though this comes with the high flow setup and management 292 cost. This poses a significant burden on operators in terms of costs 293 and on users in terms of likely degradation of quality. 295 This problem is not limited to traditional TV broadcasting. Consider 296 a virtual reality use case where several users are joining a VR 297 session at the same time, e.g., centered around a joint event. 298 Hence, due to the temporal correlation of the VR sessions, we can 299 assume that multiple requests are sent for the same content at any 300 point, particularly when viewing angles of VR clients are similar or 301 the same. Due to availability of virtual functions and cloud 302 technology, the actual end point from where content is delivered may 303 change. For this type of scenarios, the opportunistic multicast 304 capability of ICN may be utilized to reduce overall load in the 305 network, as well as on the server providing the HTTP responses. The 306 latter also allows constrained resources to serve a higher volume of 307 demands and therefore incur a higher impact on traffic distribution 308 in the network. 310 4. 5GLAN in 5G Next Generation Core Network Architecture 312 In this section, for brevity purposes, we restrict the discussions to 313 the 5G extensions currently studied in 3GPP to facilitate a 314 distributed, cellular-based LAN connectivity to end users, based on 315 the 5G next generation core network architecture. For more 316 information on the latter, we refer to [TS23.501] [TS23.502] as well 317 as [I-D.irtf-icnrg-5gc-icn]. 319 +------+ +------+ +-----+ +-----+ +-----+ +-----+ 320 | NSSF | | NEF | | NRF | | PCF | | UDM | | AF | 321 +--o---+ +--o---+ +--o--+ +--o--+ +--o--+ +--o--+ 322 Nnssf| Nnef| Nnrf| Npcf| Nudm| Naf| 323 -----+-------+-+---------+--+------+-------+-+---------+--------- 324 Nausf| Namf| Nsmf| 325 +--o--+ +--o--+ +--o--+ 326 | AUSF| | AMF | | SMF | 327 +-----+ +-+-+-+ +--+--+ 328 / | | 329 +---------+ | | 330 N1 / |N2 N4| +-N9/Nx-+ 331 +------+ | | | | 332 / | | | V 333 +-+--+ +----+----+ N3 +-+--+-------+--+ N6 +----+ 334 | UE +----------------+ (R)AN +------+ UPF +----->+ DN | 335 +----+ +---------+ +---------------+ +----+ 337 Figure 1: 5G Core Network with Vertical LAN (5GLAN) Extensions 339 Figure 1 shows the current 5G Core Network Architecture being 340 discussed within the scope of the normative work addressing 5GLAN 341 Type services in the 3GPP System Architecture Working Group 2 (3GPP 342 SA2), referred formally as "5GS Enhanced support of Vertical and LAN 343 Services" [SA2-5GLAN]. The goal of this work item is to provide 344 distributed LAN-based connectivity between two or more terminals or 345 User Equipment entities (UEs) connected to the 5G network. The SMF 346 (session management function) provides a registration and discovery 347 protocol that allows UEs wanting to communicate via a relevant 5GLAN 348 group towards one or more UEs also members of this 5GLAN group, to 349 determine the suitable forwarding information after each UE 350 previously registered suitable identifier information with the SMF 351 responsible to manage the paths across UEs in a 5GLAN group. UEs 352 register and discover (obtain) suitable identifiers during the 353 establishment of a Protocol Data Unit (PDU) Session or PDU Session 354 Modification procedure. Suitable identifier information, according 355 to [SA2-5GLAN], are Ethernet MAC addresses as well as IP addresses 356 (the latter is usually assigned during the session setup through the 357 SMF, i.e., the session management function). 359 The SMF that manages the path across UEs in a 5GLAN group, then 360 establishes the suitable procedures to ensure the forwarding between 361 the required UPFs (user plane functions) to ensure the LAN 362 connectivity between the UEs (user equipments) provided in the 363 original request to the SMF. When using the N9 interface to the UPF, 364 this forwarding will rely on a tunnel-based approach between the UPFs 365 along the path, while the Nx interface uses path-based forwarding 366 between UPFs, while LAN-based forwarding is utilized between the 367 final UPF and the UE (utilizing the N3 interface towards the 368 destination UE). 370 In the following, path-based forwarding is assumed, i.e., the usage 371 of the Nx interface and the utilization of a path identifier for the 372 end-to-end LAN communication. Here, the path between the source and 373 destination UPFs is encoded through a bitfield, provided in the 374 packet header. Each bit position in said bitfield represents a 375 unique link in the network. Upon receiving an incoming packet, each 376 UPF inspects said bitfield for the presence of any local link that is 377 being served by one of its output ports. Such presence check is 378 implemented via a simple binary AND and CMP operation. If no link is 379 being found, the packet is dropped. Such bitfield-based path 380 representation also allows for creating multicast relations in an ad 381 hoc manner by combining two or more path identifiers through a binary 382 OR operation. Note that due to the assignment of a bit position to a 383 link, path identifiers are bidirectional and can therefore be used 384 for request/response communication without incurring any need for 385 path computation on the return path. 387 For sending a packet from one Layer 2 device (UE) connected to one 388 UPF (via a RAN) to a device connected to another UPF, we provide the 389 MAC address of the destination and perform a header re-write by 390 providing the destination MAC address of the ingress UPF when sending 391 from source device to ingress and placing the end destination MAC 392 address in the payload. Upon arrival at the egress UPF, after having 393 applied the path-based forwarding between ingress and egress UPF, the 394 end destination address is restored while the end source MAC is 395 placed in the payload with the egress L2 forwarder one being used as 396 the L2 source MAC for the link-local transfer. At the end device (or 397 proxy device), the end source MAC address is restored as the source 398 MAC, providing an abstraction of a link-local L2 communication 399 between the end source and destination devices. 401 +---------+---------+----------+-----------+-----------+ 402 | Src MAC | Dst MAC | pathID | NAME_ID | Payload | 403 +---------+---------+----------------------+-----------+ 405 Figure 2: General Packet Structure 407 For this end-to-end transfer, the general packet structure of 408 Figure 2 is used. The Name_ID field is being used for the ICN 409 operations, while the payload contains the information related to the 410 transaction-based flow management described in Section 5.8 and the 411 PATH_ID is the bitfield-based path identifier for the path-based 412 forwarding. 414 4.1. Realization in SDN Transport Networks 416 An emerging technology for Layer 2 forwarding that suits the 5GLAN 417 architecture in Figure 1 is that of Software-Defined networking (SDN) 418 [SDN-DEFINITION], which allows for programmatically forwarding 419 packets at Layer 2. Switch-based rules are being executed with such 420 rules being populated by the SDN controller. Rules can act upon so- 421 called matching fields, as defined by the OpenFlow protocol 422 specification [OpenFlowSwitch]. Those fields include Ethernet MAC 423 addresses, IPv4/6 source and destination addresses and other well- 424 known Layer 3 and even 4 transport fields. 426 As shown in [Reed], efficient path-based forwarding can be realized 427 in SDN networks by placing the aforementioned path identifiers into 428 the IPv6 source/destination fields of a forwarded packet. Utilizing 429 the IPv6 source/destination fields allows for natively supporting 256 430 links in a transport network. Larger topologies can be supported by 431 extension schemes but are left out of this paper for brevity of the 432 presentation. During network bootstrapping, each link at each switch 433 is assigned a unique bitnumber in the bitfield. In order to forward 434 based on such bitfield path information, the SDN controller is 435 instructed to insert a suitable wildcard matching rule into the SDN 436 switch. This wildcard at a given switch is defined by the bitnumber 437 that has been assigned to a particular link at that switch during 438 bootstrapping. Wildcard matching as a generalization of longest 439 prefix matching is natively supported by SDN-based switches since the 440 OpenFlow v1.3 specification, efficiently implemented through TCAM 441 based operations. With that, SDN forwarding actions only depend on 442 the switch-local number of output ports, while being able to 443 transport any number of higher-layer flows over the same transport 444 network without specific flow rules being necessary. This results in 445 a constant forwarding table size while no controller-switch 446 interaction is necessary for any flow setup; only changes in 447 forwarding topology (resulting in a change of port to bit number 448 assignment) will require suitable changes of forwarding rules in 449 switches. 451 4.2. Realization in Other Transport Networks 453 Although we focus the methods in this draft on Layer 2 forwarding 454 approaches and realization of Internet-over-ICN over a 5G LAN enabled 455 network, path-based transport networks can also be established as an 456 overlay over otherwise Layer 2 networks. For instance, the BIER (Bit 457 Indexed Explicit Replication) [RFC8279] efforts within the Internet 458 Engineer Task Force (IETF) establish such path-based forwarding 459 transport as an overlay over existing, e.g., MPLS networks. The 460 path-based forwarding identification is similar to the aforementioned 461 SDN realization although the bitfield represents ingress/egress 462 information rather than links along the path. 464 Yet another transport network example is presented in [Khalili], 465 utilizing flow aggregation over SDN networks. The flow aggregation 466 again results in a path representation that is independent from the 467 specific flows traversing the network. 469 The proposed traffic engineering extensions to BIER, presented in 470 [I-D.ietf-bier-te-arch], directly align with the SDN-based 471 realization presented in Section 4.1, by proposing the same 472 bitposition per transport link assignment being used, resulting in 473 BIER bitstrings in which a dedicated forwarding path is encoded as a 474 unique bitpattern containing said bitpositions of the chosen 475 forwarding links. The BIER-TE controller plays a similar role as the 476 northbound SDN controller application utilized for the solution in 477 Section 4.1. 479 5. Internet Services over ICN over 5GLAN 480 +-------------------------------+ 481 | Forwarding Network | .... Control 482 | +--------------------------+ | 483 | | . NR . | | **** Data 484 | +-.----------------------.-+ | 485 +--------------+ | . . | +--------------+ 486 | App | | +-.---------+ +---------.-+ | | App | 487 +-----+----+---+ | | . ******* | | ******* . | | +--------------+ 488 |HTTP*|TCP*|IP.| | | . * UPF * | | * UPF * . | | |.IP|*TCP|*HTTP| 489 +----*+---*+--.+ | +-.-*-----*-+ +-*-----*-.-+ | +.--+*---+*----+ 490 |ICN * * .| | . * * * * . | |. * * ICN| 491 +----*----*---.+ +---+ . * ******** * . +---+ +.---*----*----+ 492 |L2 * * ....|RAN+.. * * ..+RAN|.... * * | 493 | ********************** ********************** | 494 +--------------+ +---+ . * * . +---+ +--------------+ 495 | . * * . | 496 | +-.-*-----+ +-----*-.+ | 497 +--| . * RAN|------|RAN * .|--+ 498 +-.-*-----+ +-----*-.+ 499 . * * . 500 . ******* ******* . 501 Legacy Service ....... * * ....... Service 502 Device Proxy . * * . Proxy 503 +-----+ +-------------------+ . * * . +-------------------+ 504 |APP *| | ********* | . * * . | ********** | 505 +----*+ +----*+ * | . * * . | * +*----+ 506 |HTTP*| |HTTP*|******* | . * * . | ********|*HTTP| 507 +----*+ +----*-+ * | . * * . | * +*----+ 508 |TCP *| |TCP * |****** | . * * . | *******| * TCP| 509 +----*+ +----*--+ +*------+ . * * . +-----*+ +---*----+ +-------+ 510 |IP *| |IP * |***|* ICN .| . * * . |.ICN *|***| * IP| | IP | 511 +----*+ +----*--+---+*-----.+ . * * . +.----*+---+---*----+ |Peering| 512 |L2 *| | * L2 * .... * * .... * * | |Network| 513 | ********* ************ *********** ************ | 514 +-----+ +-------------------+ +-------------------+ +-------+ 516 Figure 3: Internet Services over ICN over 5GLAN 518 Figure 3 shows the protocol layering for realizing Internet protocols 519 over an ICN over 5GLAN transport, assuming an end-to-end LAN 520 connectivity provided by solutions such as 5GLAN. 522 Note that such LAN connectivity can also be found in environments 523 such as localized LAN-based deployments in smart cities, enterprises 524 and others, with the UPF representing, e.g., an SDN switch (utilizing 525 the methods outlined in Section 4.1). Hence, the solutions described 526 in this section also applies to those deployments. 528 Key to the approach is that Internet services are being interpreted 529 as the main unit of transfer in the architecture shown in Figure 3. 530 For this, any Internet service is treated as a Named Service 531 Transaction (NST) which is in turn suitably routed over an ICN layer 532 in one or more other devices. As a result of this name-based 533 interpretation of any Internet service, the protocol stack in end 534 devices flattens to four layers with Internet services and ICN, with 535 ICN acting as a name-based routing layer for all IP protocols 536 implemented atop, with Layer 1 and 2 realizing the end-to-end packet 537 forwarding outlined in Section 4 (over a 5G environment) or a general 538 LAN environment provided through WiFi or fixed Ethernet technologies. 540 The general ICN operations are presented in Section 5.1 before 541 discussing the assumed (strawman) API to the ICN layer in 542 Section 5.2, which is used in turn to define the mapping of HTTP 543 transactions to operations at the ICN layer in Section 5.3 for the 544 example of HTTP. As explained in that section, the ICN layer uses an 545 interaction with the NR to register and discover HTTP-based services 546 for determining the suitable end-to-end packet forwarding 547 information. 549 Interfaces to legacy devices and peering networks are preserved 550 through service proxy devices, which terminate a traditional Internet 551 protocol stack communication and translate it into a resulting flat 552 protocol transaction. Termination here can be based on well-known 553 port numbers for specific Internet protocols, ultimately falling back 554 to the IP datagram service being the minimal service being mapped. 555 The operations of said service proxy devices is described in 556 Section 5.5. 558 An important aspect of the architecture is the mapping of the end-to- 559 end flow semantic established in many Internet services onto the flat 560 protocol stack. Section 5.7 outlines the flow management that exists 561 between the end devices. 563 The mapping of protocol identifiers onto ICN forwarding relations, 564 i.e., the operations of the name resolver (NR), shown in Figure 3, is 565 described in Section 5.8, followed by the procedures for handling 566 mobility of service providers and consumers in Section 5.9. Finally, 567 the support for dual-stack devices, not requiring a service proxy 568 device yet being able to also connect to existing IP routed networks, 569 is described in Section 5.10. 571 5.1. General Operations 573 The semantics of our name-based routing is that of a publish- 574 subscribe system over a name. The intention to receive packets with 575 a certain name is expressed through a subscription while sending 576 packets to a name is expressed through a publication. The matching 577 of a sender to a receiver is realized through NR in Figure 3. The 578 exact nature of the matching is defined through the semantics of the 579 service and, therefore, through the nature of the name provided. For 580 instance, HTTP and raw Internet services are matched to exactly one 581 subscriber only, providing an anycast capability, while IP multicast 582 services are matched against any subscriber (with the IP multicast 583 address being the name). 585 Structured names are used with the root specific to the (Internet) 586 service name, such as URL, and therefore deriving the matching 587 semantics directly from the name. 589 The subscription to a name is realized through a registration 590 protocol between end device and NR. Hence, any end device exposing a 591 certain Internet service registers the suitable name with the NR, 592 which in turn stores reachability information that is suitable for 593 path calculation between the ingress and egress L2 forwarders between 594 which the communication eventually will take place. In our current 595 realization, we utilize shortest paths only although other link 596 weights can be utilized for, e.g., delay-constrained and other 597 policies. 599 In our realization, we use network domain unique host identifiers 600 that are being assigned to end devices during the connectivity setup. 601 Sending a packet of a given Internet service is realized through a 602 discovery protocol, which returns a suitable pathID, i.e., the 603 forwarding information between ingress and egress L2 forwarder, and 604 the destination MAC address of the hosting end device. It is this 605 pathID and MAC address that is being used in the general packet 606 structure of Figure 2 to forward the packet to the destination. 608 To reduce latency in further communication, the forwarding 609 information is locally cached at the end device, while the cached 610 information is being maintained through path updates sent by the NR 611 in case of hosting end devices having moved or de-registered, 612 therefore avoiding stale forwarding information. 614 5.2. ICN API to Upper Layers 616 The operations of the ICN layer are exposed to upper layers in 617 Figure 1 through the following API calls, being exemplary here for 618 the further explanation of operations in the next sub-sections: 620 o conn = send(name, payload) 622 o send(conn, payload) 623 o conn = receive(name, &payload) 625 o receive(conn, &payload) 627 The first send() call is used for initiating a send operation to a 628 name with a connection handle returned, while the second send() is 629 used for return calls, using a connection parameters that is being 630 received with the receive() call to an incoming connection or for 631 subsequence outgoing calls after an initial request to a name has 632 been made. A return send() is being received at the other (client) 633 side through the second receive() call where the conn parameter is 634 obtained by the corresponding send() call for the outgoing call. 635 With these API functions, we provide means for providing name-based 636 transactions with return responses association provided natively. 638 The conn parameter represents the bitfield used for path-based 639 forwarding in the remote host case or the hash of the local MAC 640 address in case of link-local connections. 642 5.3. HTTP over ICN 644 5.3.1. General Mapping Procedures 646 To realize the flat device nature, Internet service layers, such as 647 the HTTP protocol stack or the TCP protocol stack, will need to be 648 adapted to run atop this new API, implementing the semantics of the 649 respective Internet protocol through suitable transactions at the 650 name level. In the example of HTTP, the standard operations of DNS 651 resolution for the server to be contacted and opening of a TCP (for 652 HTTP/1.1 or HTTP/2) or UDP (for HTTP/3) socket are altogether 653 replaced by a single send(FQDN, HTTP request) call; but the response 654 will be sent by the server, which received the request through a 655 receive(FQDN, &payload) call, using the returned conn parameter to 656 send the response with the second send() API call. Note that the use 657 of bidirectional pathIDs, no NR lookup is performed at the HTTP 658 serving endpoint. 660 In the light of HTTP/3, the same mappings apply as already described 661 above with the exception that the service proxy intercepts incoming 662 UDP traffic only if it carries an HTTP/3 payload. If the payload is 663 not HTTP/3, the mappings as described in Section Section 5.4 apply. 665 5.3.2. Realizing Ad-Hoc Multicast Responses for HTTP 667 The basis of a named service transaction allows to deliver the same 668 HTTP responses to several requestees in efficient multicast (see 669 [I-D.ietf-bier-multicast-http-response] for use cases in a BIER-based 670 transport network environment). 672 This opportunity is realized by sending the same payload (i.e., an 673 HTTP response to the same resource across a number of pending 674 requests) through a combination of several conn parameters received 675 in the incoming requests via the receive() function. 677 What is required in the HTTP stack implementation is a logic to 678 decide that two or more outstanding requests are possible to be 679 served by one response. For this, upon receiving an incoming 680 request, the HTTP stack determines any outstanding request to the 681 same resource. 'Same' here is defined as URI-specific combination of 682 the request URI and URI-specific header fields, such as browsing 683 agent or similar, called requestID in the following. 685 Once such determination is made that two requests are relating to the 686 same resource, i.e., are having the same request ID, the HTTP stack 687 maintains a temporary mapping of the request ID to the respective 688 conn parameters delivered by the receive() call. Upon receiving the 689 HTTP response from its application-level logic, the HTTP stack will 690 generate the suitable send(conn, payload) call where the provided 691 conn parameter is bitwise OR of all previously stored conn parameters 692 received in the receive() call. The ICN layer will recognize the use 693 of those ad-hoc created conn parameters and set the destination MAC 694 address in the general packet structure of Figure 2 to the Ethernet 695 broadcast MAC address as the destination address, leading to sending 696 the response to all end devices at the egress L2 forwarders to which 697 the response will be forwarded based on the combined conn parameter. 698 Alternatively, one could request IEEE assignment for a specific 699 Ethernet multicast address for this scheme instead of using the 700 broadcast address. For the local end device to determine the 701 relevance of the response received at the broadcast channel, the HTTP 702 stack of the serving endpoint includes the aforementioned requestID 703 into the payload of the packet (see Figure 2), while the originating 704 endpoint maintains an internal table with the requestID of pending 705 requests and its associated conn handle. If no matching requestID is 706 found, the packet is not being delivered to the ICN layer of the 707 incoming device. If a request is found, the ICN layer delivers the 708 response via the receive() call, using the conn handle stored in the 709 pending request table. Note that this filtering mechanism can easily 710 be implemented in hardware upon standardizing the appropriate payload 711 and header fields. 713 5.4. IP over ICN 715 For non-HTTP traffic, the service proxy uses the destination IP 716 address of an incoming IP packet from an IP endpoint as the 717 information identifier for the NR to find the suitable service proxy, 718 which can reach the sought after IP endpoint. The usage of subnet 719 masks and a longest prefix matching approach inside the NR is 720 foreseen for this matching process. In a 5GLAN scenario, service 721 proxies on UEs serve a single IP endpoint (i.e. the UE itself) and 722 therefore are represented by a /32 subnet mask for its IP address 723 inside the NR in the list of subsribers. Service proxies that serve 724 an entire local domain the subnet configured on the LAN interface of 725 the service proxy is being communicated to the NR for matching 726 purposes. The service proxy that serves the public internet is 727 represented as a wildcard match for any IP address that is not served 728 within the operator's network. 730 5.5. Service Proxy Operations 732 The service proxy in Figure 3 serves the integration of legacy 733 devices, i.e., with regular IP protocol stack, and the 734 interconnection to IP-based peering networks. It registers suitable 735 identifiers with the NR to ensure the reception of (ICN) packets, 736 while providing suitable protocol termination for the various 737 supported protocols. For instance, for HTTP, the service proxy 738 towards the peering network will register a wildcard name to the NR 739 to receive any HTTP request not destined to a network-locally 740 registered FQDN, operating as an HTTP proxy towards the peering 741 network. Service proxies also register to the IP subnet they have 742 been assigned on their local IP-based interface(s). The assignment 743 is envisaged through an out-of-band address assignment scheme, i.e. 744 DHCP [RFC2131] [RFC8415]. 746 5.6. Support for Transport Layer Security 748 With a vast amount of networking intense HTTP traffic being 749 encrypted, supporting HTTP over Transport Layer Security (TLS) 750 [RFC8446] is of paramount importance to continue offering the 751 benefits of routing the internet over 5GLAN utilising the ICN 752 principles outlined in this document, in particular the ability to 753 transparently change the service endpoint handling a HTTP request per 754 HTTP transaction. 756 After the TCP session has been established by the client with the 757 server, which is transparently intercepted by the service proxy and 758 mapped to an inter service proxy ICN flow, the client initiates a TLS 759 handshake aiming to establish a secure connection. When the service 760 proxy receives the ClientHello message from the client it has two 761 choices: act as a TLS endpoint or act as a TLS proxy. 763 If the service proxy has the TLS certificate/key for the FQDN 764 provided in the TLS ClientHello message, it acts as a transparent TLS 765 endpoint by intercepting the TLS sessions and implementing the TLS 766 procedures described in [RFC8446]. If the client eventually sends a 767 HTTP request over the TLS session the service proxy can decrypt it to 768 obtain the HTTP request in its entirety to perform the steps 769 described above how to map HTTP over ICN (and vice versa). On the 770 other side of the ICN flow the service proxy acts as a TLS client 771 towards the actual IP service endpoint. One of the key benefits of 772 service proxies acting as TLS endpoints is their ability to still 773 offer opportunistic multicast, as TLS (similar to TCP) is fully 774 intercepted at both edges of the ICN communication domain. 776 If the TLS certificate/key for the FQDN in the TLS ClientHello 777 message is not available to the service proxy, TLS control messages 778 between client and servers are left intact and routed to the most 779 suitable service proxy that is subscribd to the FQDN. However, as 780 the service proxy is not able to see HTTP transactions routing 781 benefits of the decsribed steps such as opportunistic multicast and 782 transparent interruption-free re-routing of HTTP transactiosn to a 783 more suitable IP servce endpoint are not feasible. In such scenario, 784 the TLS session must be restablished between the client and the 785 server and service continuity cannot be offered. However, it is 786 important to mention that the TLS proxy mode still improves over a 787 plain TCP connection, as for the latter the IP address provided by a 788 DNS is being used to determine the destined service proxy and not the 789 FQDN of the HTTP request. 791 5.7. ICN Flow Management 793 For all protocol mappings described in this section, the payload 794 taken from the (intercepted) layer is send as payload of the ICN 795 packet, as illustrated in Figure 2. It can be observed that two 796 resource management regimes are present, i.e. the application to 797 service proxy communication (IP) and the inter service proxy (ICN) 798 one. In the IP resource management regime, TCP friendliness governs 799 the various transport protocols in use allowing a per flow fair usage 800 of the available networking resources. However, the resource regime 801 between service proxies does not have such requirement; thus, the 802 corresponding ICN flow management and error control allows an 803 independent improved resource regime that must not be TCP friendly. 805 For an independent inter service proxy resource management scheme 806 that treats each *-over-ICN mapping equally, the notion of HTTP, TCP 807 and IP transactions are being introduced with the goal to treat them 808 equally and therefore ensuring resource fairness among them with the 809 benefit of long lasting ICN flow relationships among service proxies. 811 +--------------+ +-------+ 812 __ |Ad-Hoc Service| |Flow | 813 / |Proxy Flow | |Control| 814 | +--------------+ +-------+ 815 +--------+ | | | 816 | IP/UDP | | | | 817 |Datagram|--------------| | +--------------+ +-------+ 818 +--------+ | | |Service Proxy |----|Flow | 819 | | | Flow | |Control| 820 +--------+ | \ +--------------+ +-------+ 821 |TCP/TLS |---------| | \ | 822 |Stream | | | \ | 823 +--------+ | | \ | 824 +-----------+ +--------------+ +-------+ 825 | IP |---------|Service Proxy |----|Error | 826 |Translation| |Translation | |Control| 827 +-----------+ +--------------+ +-------+ 828 +-------------+ | | 829 |HTTP Request |----| | 830 +-------------+ | 831 | 832 +-------------+ | 833 |HTTP Response|---------| 834 +-------------+ 836 Figure 4: Mapping of IP Transactions onto Service Proxy Transactions 837 and Flows 839 Figure 4 illustrates the ICN flow management for inter service proxy 840 communication. As it shows, all traffic from IP endpoints are 841 translated into a unified IP transaction and mapped to a service 842 proxy transaction. The resulting service proxy flow constitutes a 843 long-term relationship between two service proxies. For each service 844 proxy flow, there exists a flow-specific flow control relationship, 845 which maintains flow parameters such as send credits, timers for 846 round-trip time (RTT) dependent mechanisms, error rate information 847 and others. Such serivce proxy flow between two service proxies 848 represent the edge-to-edge resource management regime desribed above. 849 Each service proxy flow consists of one or more service proxy 850 transactions, each of which comes with its own error control 851 relationship that maintains information such as sequence numbers, 852 outstanding packets, segmentation/reassembly information and others. 853 For retransmissions, the error control relies on service proxy flow- 854 specific flow control information, such as timers, RTT information 855 etc. With such mapping from IP transactions onto a service proxy 856 transaction that has its own error control mechanism, it has been 857 achieved that the data originating from and destined to end-to-edge 858 resource management regimes can be reliably transferred over the 859 service proxy-to-service proxy network. Combining all transactions 860 under a single resource management relationship, represented by the 861 combined flow control mechanism for a single flow between the service 862 proxies, now establishes the inter service proxy resource management 863 scheme. Any competition for resources among service proxies is now 864 governed by said scheme between flows. Given that all transactions 865 between specific service proxies are mapped into a single service 866 proxy flow, fair resource sharing among all transactions can be 867 ensured. 869 One crucial aspect of the HTTP-over-ICN mapping is the possibility of 870 so-called ad-hoc multicast relations, i.e., the ability to send 871 responses from one IP applications to more than one other IP 872 application and therefore to more than one service proxy. In this 873 case, the specific IP transaction (e.g. an HTTP response) is mapped 874 onto a service proxy transaction that in turn is realized over more 875 than one service proxy-to-service proxy flow. This flow is called 876 ad-hoc service proxy flow. For those cases, the flow control for the 877 ad-hoc service proxy flow will utilize parameters across the various 878 involved service proxy flows, resulting in an one-to-many 879 relationship between the specific flow control for the ad-hoc serivce 880 proxy flow and the flow control(s) of the involved serivce proxy 881 flow(s). Such combined parameters might be the maximum RTT timer or 882 the lowest credit value, representing the least common dominator of 883 the resources across all involved flows. 885 As mentioned before, a service proxy flow constitutes a long-term 886 relationship between two service proxies. This relationship can 887 established in multiple ways: an explicit setup might be used akin to 888 that of TCP's three-way handshake. Alternatevely, an implicit 889 transaction-based flow establishment might be used; in this case, the 890 sending of an initial transaction between two service proxies results 891 in the creation of an service proxy flow context between those two 892 service proxies, which is being reused for any future transfer 893 between those two service proxies, i.e., constituting a service proxy 894 flow. Flow termination can be explicit based on a handshake 895 protocol, where one service proxy, wishing to terminate the flow, 896 signals this to the corresponding service proxy. Other embodiments 897 foresee the destruction of the service proxy flow via timeout, e.g., 898 removing any internal service proxy flow context information upon 899 firing of an inactivity timeout. Combining this with an implicit 900 transaction-based flow establishment would make the notion of a 901 service proxy flow entirely that of an internal (service proxy flow 902 context) data structure, which is created upon sending the first 903 transaction to a service proxy which had previously not been 904 contacted, while destroying said data structure upon the firing of 905 the aforementioned inactivity timeout. 907 5.8. NR Operations 909 The NR in Figure 3 combines the operations of the SMF and the PMF in 910 5GLAN (see Figure 1), by allowing for registering IP protocol 911 identifiers for discovery and subsequent path computation by 912 resolving the destination(s) to a suitable pathID and destination MAC 913 address for forwarding. This will require extensions to the 914 operations of the SMF to allow for such higher layer identifiers to 915 be registered (and discovered), in addition to the already supported 916 Ethernet and IP addresses. 918 5.9. Mobility Handling 920 EDITOR NOTE: left for future draft updates. 922 5.10. Dual Stack Device Support 924 Figure 3 outlines a protocol stack for the user equipment that 925 realizes Internet services on top of the proposed name-based routing 926 layer as a single stack device. However, [I-D.irtf-icnrg-icn-lte-4g] 927 outlines the possibility of supporting dual-stack devices for 4G LTE 928 networks by allowing IP as well as ICN protocol stacks to be deployed 929 with the operation of IP and ICN based applications. 930 [I-D.irtf-icnrg-5gc-icn] outlines the same dual-stack device 931 realization for a 5G ICN realization. For both environments, a 932 convergence layer is described that selects the appropriate data path 933 for each ICN or IP application, e.g., based on configuration per 934 application (similar to selecting network interfaces such as WiFi 935 over cellular). 937 As a possible data path selection, [I-D.irtf-icnrg-icn-lte-4g] and 938 [I-D.irtf-icnrg-5gc-icn] envision the realization of Internet-over- 939 ICN (Section 4.2 in [I-D.irtf-icnrg-icn-lte-4g]) in which the 940 convergence layer would realize similar mapping functions as 941 described in this draft. Hence, we foresee the utilization of such 942 dual-stack devices connected to an Internet services over ICN over 943 5GLAN environment. When utilizing the service proxy, IP applications 944 that are configured to use the IP data path only could still utilize 945 the ICN-based forwarding in the network. In that case, functionality 946 such as the opportunistic multicast in Section 5.3.2 would only reach 947 up to the service proxy with unicast traffic continuing along the 948 data path towards the user equipment. 950 6. Deployment Considerations 952 The work in [RFC8763] outlines a comprehensive set of considerations 953 related to the deployment of ICN. We now relate the solutions 954 proposed in this draft to the two main aspects covered in the 955 deployment considerations draft, namely the 'deployment 956 configuration' (covered in Section 3 of [RFC8763]) that is being 957 realized and the 'deployment migration paths' (covered in Section 4 958 of [RFC8763]) that are being provided. 960 The solutions proposed in this draft relate to those "deployment 961 configuration" as follows: 963 o The realization of Internet service on top of an ICN routing 964 capabilities, as proposed in Section 5, follows the "ICN-as-an- 965 Underlay" categorization, interpreting the ICN routing as an 966 underlay to the Internet services with the path-based forwarding 967 being compatible with the 5GLAN forwarding capabilities currently 968 discussed in 3GPP and therefore providing an underlay integration 969 capability for the ICN forwarding used in the proposed solution. 971 o The deployment of 5GLAN based ICN capabilities can be realized 972 following the "ICN-as-a-Slice" deployment configuration, i.e., the 973 5GLAN connectivity is provided to a "vertical 5G customer" which 974 in turn provides the ICN capability over 5GLAN within said network 975 (and compute) slice at the endpoints of the 5GLAN connectivity, as 976 proposed in Section 3. 978 In relation of the 'deployment migration paths', the solutions in 979 this draft relate as follows: 981 o The integration with the 5GLAN capability, as proposed in 982 Section 5, facilitates "edge network migration" (interpreting the 983 cellular sub-system here as an edge network albeit a possibly 984 geographically large one. 986 o The single stack realization, as proposed in Figure 3, as well as 987 the dual-stack deployment, as proposed in Section 5.10, facilitate 988 "application and services migration" through not only supporting 989 ICN applications but also Internet applications through the 990 proposed Internet-over-ICN mapping in the terminal. 992 o The Internet over ICN over 5GLAN deployment, possibly combined 993 with an ICN-as-a-Slice deployment, facilitates the "content 994 delivery networks migration" through a deployment of Internet- 995 over-ICN-based 5GLAN connected CDN elements in (virtualized) edge 996 network nodes or POP locations in the customer (5G) network. 998 7. Conclusion 1000 In this draft, we explored the feasibility of enabling Internet 1001 services directly over ICN network over (5G)LAN environments. We 1002 proposed the architecture and discussed corresponding operations of 1003 mapping Internet services onto name-based transactions, with the 1004 specific example of HTTP-based transactions. We described the flow 1005 management, the realization of opportunistic multicast responses for 1006 HTTP as well as the realization of dual-stack user equipment. Future 1007 updates to the draft will provide more details to mobility handling. 1008 We also described the deployment scenario for supporting Internet 1009 services over ICN over 5GLAN. 1011 8. IANA Considerations 1013 This document requests no IANA actions. 1015 9. Security Considerations 1017 Editor Note: to be added in future drafts. 1019 10. Acknowledgments 1021 Work towards developing the solutions outlined in this draft have 1022 been funded under grants of the [H2020POINT] and [H2020FLAME] 1023 projects. 1025 11. Informative References 1027 [H2020FLAME] 1028 H2020, "The FLAME Project", https://www.ict-flame.eu/ . 1030 [H2020POINT] 1031 H2020, "The POINT Project", https://www.point-h2020.eu/ . 1033 [I-D.galis-anima-autonomic-slice-networking] 1034 Galis, A., Makhijani, K., Yu, D., and B. Liu, "Autonomic 1035 Slice Networking", draft-galis-anima-autonomic-slice- 1036 networking-05 (work in progress), September 2018. 1038 [I-D.ietf-bier-multicast-http-response] 1039 Trossen, D., Rahman, A., Wang, C., and T. Eckert, 1040 "Applicability of BIER Multicast Overlay for Adaptive 1041 Streaming Services", draft-ietf-bier-multicast-http- 1042 response-04 (work in progress), July 2020. 1044 [I-D.ietf-bier-te-arch] 1045 Eckert, T., Cauchie, G., and M. Menth, "Tree Engineering 1046 for Bit Index Explicit Replication (BIER-TE)", draft-ietf- 1047 bier-te-arch-08 (work in progress), July 2020. 1049 [I-D.irtf-icnrg-5gc-icn] 1050 Ravindran, R., suthar, P., Trossen, D., Wang, C., and G. 1051 White, "Enabling ICN in 3GPP's 5G NextGen Core 1052 Architecture", draft-irtf-icnrg-5gc-icn-03 (work in 1053 progress), July 2020. 1055 [I-D.irtf-icnrg-icn-lte-4g] 1056 suthar, P., Stolic, M., Jangam, A., Trossen, D., and R. 1057 Ravindran, "Native Deployment of ICN in LTE, 4G Mobile 1058 Networks", draft-irtf-icnrg-icn-lte-4g-08 (work in 1059 progress), July 2020. 1061 [I-D.muscariello-intarea-hicn] 1062 Muscariello, L., Carofiglio, G., Auge, J., Papalini, M., 1063 and M. Sardara, "Hybrid Information-Centric Networking", 1064 draft-muscariello-intarea-hicn-04 (work in progress), May 1065 2020. 1067 [I-D.white-icnrg-ipoc] 1068 White, G., Shannigrahi, S., and C. Fan, "Internet Protocol 1069 Tunneling over Content Centric Mobile Networks", draft- 1070 white-icnrg-ipoc-02 (work in progress), June 2019. 1072 [Khalili] Khalili, R., Poe, W., Despotovic, Z., and A. Hecker, 1073 "Reducing State of SDN Switches in Mobile Core Networks by 1074 Flow Rule Aggregation", IEEE ICCCN 2016, Hawaii, USA, 1075 August 2016. 1077 [OpenFlowSwitch] 1078 Open Networking Foundation, available at 1079 https://www.opennetworking.org/wp-content/uploads/2014/10/ 1080 openflow-switch-v1.5.1.pdf, "OpenFlow Switch Specification 1081 V1.5.1", 2018. 1083 [Reed] Reed, M., AI-Naday, M., Thomos, N., Trossen, D., 1084 Petropoulos, G., and S. Spirou, "Stateless Multicast 1085 Switching in Software Defined Networks", IEEE ICC 2016, 1086 Kuala Lumpur, Maylaysia, 2016. 1088 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1089 RFC 2131, DOI 10.17487/RFC2131, March 1997, 1090 . 1092 [RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., 1093 Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, 1094 "Information-Centric Networking (ICN) Research 1095 Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, 1096 . 1098 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 1099 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 1100 Explicit Replication (BIER)", RFC 8279, 1101 DOI 10.17487/RFC8279, November 2017, 1102 . 1104 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 1105 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 1106 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 1107 RFC 8415, DOI 10.17487/RFC8415, November 2018, 1108 . 1110 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1111 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1112 . 1114 [RFC8763] Rahman, A., Trossen, D., Kutscher, D., and R. Ravindran, 1115 "Deployment Considerations for Information-Centric 1116 Networking (ICN)", RFC 8763, DOI 10.17487/RFC8763, April 1117 2020, . 1119 [SA2-5GLAN] 1120 3gpp-5glan, "SP-181129, Work Item Description, 1121 Vertical_LAN(SA2), 5GS Enhanced Support of Vertical and 1122 LAN Services", 3GPP , 1123 http://www.3gpp.org/ftp/tsg_sa/TSG_SA/TSGS_82/Docs/SP- 1124 181120.zip. 1126 [SBA-ENHANCEMENT] 1127 3gpp-sba-enhancement, "S2-182904, New SID for Enhancements 1128 to the Service-Based 5G System Architecture.", 3GPP , 1129 February 2018 (http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/ 1130 TSGS2_126_Montreal/Docs/S2-182904.zip). 1132 [SDN-DEFINITION] 1133 Open Networking Foundation, available at 1134 https://www.opennetworking.org/sdn-definition/, "Software- 1135 Defined Networking (SDN) Definition", 2018. 1137 [TS23.501] 1138 3gpp-23.501, "Technical Specification Group Services and 1139 System Aspects; System Architecture for the 5G System; 1140 Stage 2 (Rel.15)", 3GPP , December 2018. 1142 [TS23.502] 1143 3gpp-23.502, "Technical Specification Group Services and 1144 System Aspects; Procedures for the 5G System; Stage 2 1145 (Rel. 15)", 3GPP , January 2019. 1147 [TS29.500] 1148 3gpp-29.500, "Technical Realization of Service Based 1149 Architecture.", 3GPP , January 2018. 1151 Authors' Addresses 1153 Dirk Trossen 1154 Huawei Technologies Duesseldorf GmbH 1155 205 Hansallee 1156 Duesseldorf 40549 1157 Germany 1159 Email: dirk.trossen@huawei.com 1160 URI: http://huawei-dialog.de/ 1162 Sebastian Robitzsch 1163 InterDigital Inc. 1164 64 Great Eastern Street, 1st Floor 1165 London EC2A 3QR 1166 United Kingdom 1168 Email: Sebastian.Robitzsch@InterDigital.com 1169 URI: http://www.InterDigital.com/ 1171 Martin Reed 1172 Essex University 1174 Colchester 1175 United Kingdom 1177 Email: mjreed@essec.ac.uk 1178 URI: https://www.essex.ac.uk/people/reedm58703/martin-reed 1180 Mays Al-Naday 1181 Essex University 1183 Colchester 1184 United Kingdom 1186 Email: mfhaln@essec.ac.uk 1187 URI: https://www.essex.ac.uk/people/alned81405/mays-al-naday 1188 Janne Riihijarvi 1189 RWTH Aachen 1191 Aachen 1192 Germany 1194 Email: jariihij@googlemail.com 1195 URI: https://www.inets.rwth-aachen.de/about-us/janne-riihijaervi/