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