idnits 2.17.1 draft-ravi-icnrg-5gc-icn-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 55 instances of too long lines in the document, the longest one being 43 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 29, 2017) is 2372 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC7927' is defined on line 842, but no explicit reference was found in the text == Unused Reference: 'VSER' is defined on line 871, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-rahman-icnrg-deployment-guidelines-04 == Outdated reference: A later version (-04) exists of draft-suthar-icnrg-icn-lte-4g-03 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICNRG R. Ravindran 3 Internet-Draft Huawei 4 Intended status: Informational P. Suthar 5 Expires: May 2, 2018 Cisco 6 G. Wang 7 Huawei 8 October 29, 2017 10 Enabling ICN in 3GPP's 5G NextGen Core Architecture 11 draft-ravi-icnrg-5gc-icn-00 13 Abstract 15 The proposed 3GPP's 5G core nextgen architecture (5GC) offers 16 flexibility to introduce new user and control plane function within 17 the context of network slicing that allows greater flexibility to 18 handle heterogeneous devices and applications. In this draft, we 19 provide a short description of the proposed 5GC, followed by 20 extensions to 5GC's control and user plane to support packet data 21 unit (PDU) sessions from information-centric networks. The value of 22 enabling ICN in 5GC is discussed using two service scenarios which 23 include mobile edge computing and support for seamless mobility for 24 ICN sessions. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on May 2, 2018. 43 Copyright Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. 5G NextGen Core Design Principles . . . . . . . . . . . . . . 5 63 4. 5G NextGen Core Architecture . . . . . . . . . . . . . . . . 6 64 5. 5GC Architecture with ICN Support . . . . . . . . . . . . . . 8 65 5.1. Control Plane Extensions . . . . . . . . . . . . . . . . 10 66 5.1.1. Normative Interface Extensions . . . . . . . . . . . 12 67 5.2. User Plane Extensions . . . . . . . . . . . . . . . . . . 12 68 5.2.1. Normative Interface Extensions . . . . . . . . . . . 13 69 6. ICN Deployement Use Case Scenarios . . . . . . . . . . . . . 14 70 6.1. Mobile Edge Computing . . . . . . . . . . . . . . . . . . 14 71 6.1.1. IP-MEC Scenario . . . . . . . . . . . . . . . . . . . 14 72 6.1.2. ICN-MEC Scenario . . . . . . . . . . . . . . . . . . 15 73 6.2. ICN Session Mobility . . . . . . . . . . . . . . . . . . 16 74 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 18 75 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 76 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 77 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 78 11. Informative References . . . . . . . . . . . . . . . . . . . 18 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 81 1. Introduction 83 The objective of this draft is to propose an architecture to enable 84 information-centric networking (ICN) in the proposed 5G Next- 85 generation Core network architecture (5GC) by leveraging its 86 flexibility to allow new user and associated control plane functions. 87 The reference architectural discussions in three core 3GPP 88 specifications [TS23.501][TS23.502][TS23.799] form the basis of our 89 discussions. This draft also complements the discussions related to 90 various ICN deployment opportunities explored in 91 [I-D.rahman-icnrg-deployment-guidelines], where 5G technology is 92 considered as one of the promising alternatives. 94 Though ICN is a general networking technology, it would benefit 5G 95 particularly from the perspective of mobile edge computing (MEC). 96 Following ICN features shall benefit MEC deployments in 5G: 98 o Edge Computing: Multi-access Edge Computing (MEC) is located at 99 edge of network and aids several latency sensitive applications 100 such as augmented and virtual reality (AR/VR) and ultra reliable 101 and low latency class (URLLC) of applications such as autonomous 102 vehicles. Enabling edge computing over an IP converged 5GC comes 103 with the challenge of application level reconfiguration required 104 to re-initialize a session whenever it is being served by a non- 105 optimal service instance. In contrast, named-based networking, as 106 considered by ICN, naturally supports service-centric networking, 107 which minimizes network related configuration for applications and 108 allows fast resolution for named service instances. 110 o Edge Storage and Caching : The principal entity for ICN is the 111 secured content (or named-data) object, which allows location 112 independent data replication at strategic storage points in the 113 network, or data dissemination through ICN routers by means of 114 opportunistic caching. These features benefit both realtime and 115 non-realtime applications, where a set of users share the same 116 content, thereby advantageous to both high-bandwidth and/or low- 117 latency applications such as Video-on-Demand (VOD), AR/VR or low 118 bandwidth IoT applications. 120 o Session Mobility: Existing long-term evolution (LTE) deployments 121 handle session mobility using IP anchor points at Packet Data 122 Network Gateway (PDN-GW) and service anchor point called Access 123 Point Name (APN) functionality hosted in PDN-GW, and uses a tunnel 124 between radio edge (eNodeB) and PDN-GW for each mobile device 125 attached to network. This design fails when service instances are 126 replicated close to radio access network (RAN) instances, 127 requiring new techniques to handle session mobility. In contrast, 128 application-bound identifier and name resolution split principle 129 considered for the ICN is shown to handle host mobility quite 130 efficiently [mas]. 132 To summarize the draft, we first discuss 5GC's design principals that 133 allows the support of new network architectures. Then we summarily 134 discuss the 5GC proposal, followed by control and user plane 135 extensions required to support ICN PDU sessions. We then discuss 136 specific network services enabled using ICN data networks, 137 specifically MEC and ICN session mobility with aid from 5GC control 138 plane. 140 2. Terminology 142 Following are terminologies relevant to this draft: 144 5G-NextGen Core (5GC) : Refers to the new 5G core network 145 architecture being developed by 3GPP, we specifically refer to the 146 architectural discussions in [TS23.501][TS23.502]. 148 5G-New Radio (5G-NR): This refers to the new radio access 149 interface developed to support 5G wireless interface [TS-5GNR]. 151 User Plane Function (UPF): UPF is the generalized logical data 152 plane function with context of the UE PDU session. UPFs can play 153 many role, such as, being an flow classifier (UL-CL) (defined 154 next), a PDU session anchoring point, or a branching point. 156 Uplink Classifier (UL-CL): This is a functionality supported by an 157 UPF that aims at diverting traffic (locally) to local data 158 networks based on traffic matching filters applied to the UE 159 traffic. 161 Packet Data Network (PDN or DN): This refers to service networks 162 that belong to the operator or third party offered as a service to 163 the UE. 165 Unified Data Management (UDM): Manages unified data management for 166 wireless, wireline and any other types of subscribers for M2M, IOT 167 application etc. UDM report subscriber related vital information 168 e.g. virtual edge region, list of location visits, sessions active 169 etc. UDM work as subscriber anchor point that means OSS/BSS 170 systems will have central monitoring/access of the system to get/ 171 set subscriber information. 173 Authentication Server Function (AUSF): Provides mechanism for 174 unified authentication for subscribers related to wireless, 175 wireline and any other types of subscribers such as M2M and IOT 176 applications. The functions performed by AUSF are similar to HSS 177 with additional functionalities to related to 5G. 179 Session Management Function (SMF): Perform session management 180 functions for attached users equipment (UE) in 5G Core. SMF can 181 thus be formed by leveraging the CUPS (discussed in the next 182 section) feature with control plane session management. 184 Access Mobility Function (AMF): Perform access mobility management 185 for attached user equipment (UE) to the 5G core network. The 186 function includes, network access stratus (NAS) mobility functions 187 such as authentication and authorization. 189 Application Function (AF): Helps with influencing the user plane 190 routing state in 5GC considering service requirements. 192 Network Slicing: This conceptualizes the grouping for a set of 193 logical or physical network functions with its own or shared 194 control, data and service plane to meet specific service 195 requirements. 197 3. 5G NextGen Core Design Principles 199 The 5GC architecture is based on the following design principles that 200 allow it to support new service networks like ICN efficiently 201 compared to LTE networks:. 203 o Control and User plane split (CUPS): This design principle moves 204 away from LTE's vertically integrated control/user plane design 205 (i.e., Serving Gateway, S-GW, and Packet Data Network Gateway, 206 P-GW) to one espousing an NFV framework with network functions 207 separated from the hardware for service-centricity, flexibility 208 and programmability. In doing so, network functions can be 209 implemented both physically and virtually, while allowing each to 210 be customized and scaled based on their individual requirements, 211 also allowing the realization of multi-slice co-existence. This 212 feature also allows the introduction of new user plane functions 213 (UPF). UPFs can play many roles, such as, being an uplink flow 214 classifier (UL-CL), a PDU session anchor point, a branching point 215 function, or one based on new network architectures like ICN with 216 new control functions, or re-using/extending the existing ones to 217 manage the new user plane realizations. 219 o Decoupling of RAT and Core Network : Unlike LTE's unified control 220 plane for access and the core, 5GC offers control plane separation 221 of the RAN from the core network. This allows the introduction of 222 new radio access technologies (RAT) along with slices based on new 223 network architectures, offering the ability to map heterogeneous 224 RAN flows to arbitrary core network slices based on service 225 requirements. 227 o Non-IP PDU Session Support : A PDU session is defined as the 228 logical connection between the UE and the data network (DN). 5GC 229 offers a scope to support both IP and non-IP PDU (termed as 230 "unstructured" payload), and this feature can potentially allow 231 the support for ICN PDUs by extending or re-using the existing 232 control functions. 234 o Service Centric Design: 5GC's service orchestration and control 235 functions, such as naming, addressing, registration/authentication 236 and mobility, will utilize cloud based service APIs. Doing so 237 enables opening up interfaces for authorized service function 238 interaction and creating service level extensions to support new 239 network architectures. These APIs include the well accepted Get/ 240 Response and Pub/Sub approaches, while not precluding the use of 241 procedural approach between functional units (where necessary). 243 4. 5G NextGen Core Architecture 245 In this section, for brevity purposes, we restrict the discussions to 246 the control and user plane functions relevant to an ICN deployment. 247 More exhaustive discussions on the various architecture functions, 248 such as registration, connection and subscription management, can be 249 found in[TS23.501][TS23.502]. 251 +---------+ +--------+ 252 +--------+ | PCF/UDM | +------+ | AF-2 | 253 | NSSF | | | | AF-1 | +-----+--+ 254 +---+----+ +-----+---+ +--+---+ | 255 | | | +--+--------+ 256 +---+------------+-+ +-----+------+ | | 257 | |N11| | | SMF-2 | 258 | AMF +---+ SMF-1 | | | 259 | | | | +---------+-+ 260 +--------+-+-------+ +----+-------+ | 261 | | |-----------------------------------+ 262 +------------------+ | | |N4 |N4 263 N1 | |N2 |N4 | +--------+-----------+ 264 | | | +---------+ UPF | N6 +------+ 265 +-------------+-+ +----------+------+ +---+-----------+ | | |(PDU Session Anchor)+----+ DN | 266 | | | | | | N9 | | | | | | 267 | UE | | RAN | N3 | UL-CL +----+ | +--------------------+ +------+ 268 | +-------+ +-----+ | | 269 | | | | | +----+ +-----------------+ 270 +---------------+ +-----------------+ +---------------+ N9 | | 271 | +----------+---------+ 272 +---------+ | +--------+ 273 | UPF | N6 | DN | 274 |(PDU Session Anchor)+----+ | 275 | | +--------+ 276 +--------------------+ 278 Figure 1: 5G Next Generation Core Architecture 280 In Figure 1, we show one variant of a 5GC architecture from 281 [TS23.501], for which the functions of UPF's branching point and PDU 282 session anchoring are used to support inter-connection between a UE 283 and the related service or packet data networks (or PDNs) managed by 284 the signaling interactions with control plane functions. In 5GC, 285 control plane functions can be categorized as follows: 287 o Common control plane functions that are common to all slices and 288 which include the Authentication and Mobility Function (AMF), 289 Network Slice and Selection Function (NSSF), Policy Control 290 Function (PCF), and Unified Data Management (UDM) among others. 292 o Shared or slice specific control functions, which include the 293 Session and Management Function (SMF) and the Application Function 294 (AF). 296 AMF serves multiple purposes: (i) device authentication and 297 authorization; (ii) security and integrity protection to non-access 298 stratum (NAS) signaling; (iii) tracking UE registration in the 299 operator's network and mobility management functions as the UE moves 300 among different RANs, each of which might be using different radio 301 access technologies (RAT). 303 NSSF handles the selection of a particular slice for the PDU session 304 request from the user entity (UE) using the Network Slice Selection 305 Assistance Information (NSSAI) parameters provided by the UE and the 306 configured user subscription policies in PCF and UDM functions. 307 Compared to LTE's evolved packet core (EPC), where PDU session states 308 in RAN and core are synchronized with respect to management, 5GC 309 decouples this using NSSF by allowing PDU sessions to be defined 310 prior to a PDU session request by a UE (for other differences see 311 [lteversus5g] ). This de-coupling allows policy based inter- 312 connection of RAN flows with slices provisioned in the core network. 314 SMF handles session management functions including IP address 315 assignment functionality, policy and service capabilities. 316 Furthermore, it manages the data plane state in the user plane 317 through PDU session establishment, modification and termination, and 318 management of RAN (through the AMF) and UPF states related to a 319 particular service or slice. 321 In the data plane, UE's PDUs are sent to the RAN using the 5G RAN 322 protocol [TS-5GNR]. From the RAN, the PDU's five tuple header 323 information (IP source/destination, port, protocol etc.) is used to 324 map the flow to an appropriate tunnel from RAN to UPF. The UPF in 325 this case also offers flexibility as a flow classifier and a 326 branching point interconnecting PDUs from diverse services (within 327 UEs) to their respective DNs. Though [TS23.501] follows LTE on using 328 GTP tunnel from NR to the UPF to carry data PDU and another one for 329 the control messages to serve the control plane functions; there are 330 ongoing discussions to arrive upon efficient alternatives to GTP. 332 5. 5GC Architecture with ICN Support 334 In this section, we focus on control and user plane enhancements 335 required to enable ICN within 5GC, and identify the interfaces that 336 require extensions to support ICN PDU sessions. Explicit support for 337 ICN PDU sessions within access and 5GC networks will enable 338 applications to leverage the core ICN features while offering it as a 339 service to 5G users. 341 +------------+ 342 | 5G | 343 | Services | 344 | (NEF) | +----------------+ 345 +-------+----+ | ICN | 346 | +----------+ Service | 347 | | | Orchestrator | 348 | | +-----------+----++ 349 +-------+ +---------+ Npcf++/Nudm++ ++------+ | 350 | NSSF | | PCF/UDM +---------------------------------+ ICN-AF| | 351 +----+--+ | | | | +---+--------------+ 352 | +--+------+ +---+---+ | ICN | 353 | | | +------+ Service/Network | 354 +-+--------+--+ +---------------+ +------+-------+ | | Controller | 355 | | N11++ | |Naf++ | +----+ +------------+-----+ 356 | AMF++ +-----------+ SMF++ +------+ ICN-SMF | | 357 | | | | | | | 358 +------+-+----+ +----+-----+----+ +------------+-+ | 359 | | | | NIcn | 360 +-----------------+ | | +----------+ | 361 | | | | | 362 | +------+ N4 | | | 363 N1++ | | | | | 364 | | N2 | +------------+-+ +----+-----+ 365 | | | +----------+ | | | 366 | | | | N9 | ICN-AP +--------+ ICN-DN | 367 | | +-----+-----+ | | + UPF | N6 | | 368 +------+--+ +---------+--+ | | | +---+----------+ +----------+ 369 | | |RAN | | UL-CL/ +-----+ 370 | ICN-UE +-------------+ +-----------+ Branching | 371 | | | +-------+ | N3 | Point +-----+ +------------+ 372 +---------+ | | UL-CL | | +-----------+ | | Local | 373 | +-------+ | | N9 | ICN-DN | 374 +------------+ +-----------+ | 375 +------------+ 377 Figure 2: 5G Next Generation Core Architecture with ICN support 379 For an ICN-enabled 5GC network, the assumption is that the UE may 380 have applications that can run over ICN or IP, for instance, UE's 381 operating system offering applications to operate over ICN [Jacobson] 382 or IP-based networking sockets. There may also be cases where UE is 383 exclusively based on ICN. In either case, we identify an ICN enabled 384 UE as ICN-UE. Different options exist to implement ICN in UE as 385 described in [I-D.suthar-icnrg-icn-lte-4g] which is also applicable 386 for 5G UE to enable formal ICN session handling, such as, using a 387 transport convergence layer above 5G-NR, through IP address 388 assignment from 5GC or using 5GC provision of using unstructured PDU 389 session mode during the PDU session establishment process. 5G UE can 390 also be non-mobile devices or an IOT device using radio specification 391 which can operate based on [TS-5GNR]. 393 5GC will take advantage of network slicing function to instantiate 394 heterogeneous slices, the same framework can be extended to create 395 ICN slices as well [Ravindran]. This discussion also borrows ideas 396 from[TS23.799], which offers a wide range of architectural 397 discussions and proposals on enabling slices and managing multiple 398 PDU sessions with local networks (with MEC) and its associated 399 architectural support (in the service, control and data planes) and 400 procedures within the context of 5GC. 402 Figure 2 shows the proposed ICN-enabled 5GC architecture. In the 403 figure, new/modified functional components are identified to 404 interconnect an ICN-DN with 5GC. The interfaces and functions that 405 require extensions to enable ICN as a service in 5GC can be 406 identified in the figure with a '++' symbol. We next summarize the 407 control, user plane and normative interface extensions that help with 408 the formal ICN support. 410 5.1. Control Plane Extensions 412 To support interconnection between ICN UEs and the appropriate ICN DN 413 instances, we require five additional control plane extensions, which 414 are discussed as follows. 416 o Authentication and Mobility Function (AMF++) : Applications in the 417 UEs have to be authorized to access ICN DNs. For this purpose, as 418 in[TS23.501], operator enables ICN as a service-DN to support ICN 419 PDU session flows. As a network service, ICN-UE should also be 420 subscribed to it and this is imposed using the PCF and User Data 421 and Management (UDM) functions, which may interface with the ICN 422 Application Function (ICN-AF) for policy management of ICN PDU 423 sessions. Hence, if the UE policy profile in the UDM doesn't 424 enable this feature, then the ICN applications in the UE will not 425 be allowed to connect to ICN DNs. To enable ICN stack in the UE, 426 AMF function has to be modified to understand ICN type UE 427 registration request and handle authentication and registration 428 requests. AMF++ will support ICN specific bootstrapping and 429 forwarding functions (such as naming and security) to configure 430 UE's ICN applications. With appropriate enhancements, it should 431 also support forwarding rules for the name prefixes that bind the 432 flows to appropriate 5G-NR logical tunnel or slice interfaces. 433 These functions can also be handled by the ICN-AF after setting 434 PDU session state in 5GC. Here, we are not recommending 435 modification of 5G UE attach procedures but use existing attach 436 procedures messages to carry ICN capabilities extensions in 437 addition to supporting existing IP based services. 5G UE can 438 request authentication for attaching to 5GC either in ICN, IP or 439 dual-stack (IP and ICN) modes. 441 o Session Management Function (SMF++) : Once a UE is authenticated 442 to access ICN service in network, SMF manages to connect UE's ICN 443 PDU sessions to the ICN DN. SMF++ capabilities should be able to 444 manage both IP, ICN or dual stack UE with IP and ICN capabilities. 445 SMF++ creates appropriate PDU session policies in the UPF, which 446 include UL-CL and ICN anchor point (ICN-AP). For centrally 447 delivered services, ICN-AP could also be an IP anchor point for IP 448 applications. If MEC is enabled, these two functions would be 449 distributed, as the UL-CL will re-route the flow to a local ICN- 450 DN. SMF++ interfaces with AMF over N11++ to enable ICN specific 451 user plane function, which includes IP address configuration and 452 associated traffic filter policy to inter-connect UE with the 453 appropriate radio slice. Furthermore, AMF++ sets appropriate 454 state in the RAN that directs ICN flows to chosen ICN UL-CL. 456 o ICN Session Management Function (ICN-SMF) : ICN-SMF serves as 457 control plane for the ICN state managed in ICN-AP. This function 458 interacts with SMF++ to obtain and also push ICN PDU session 459 management information for the creation, modification and deletion 460 of ICN PDU sessions in ICN-AP. For instance, when new ICN slices 461 are provisioned by the ICN service orchestrator, ICN-SMF requests 462 a new PDU session to the SMF++ that extends to the RAN and UE. 463 While SMF++ manages the tunnels to interconnect ICN-AP to UL-CL, 464 ICN-SMF creates the appropriate forwarding state in ICN (using the 465 forwarding information base or FIB) to enable ICN flows over 466 appropriate tunnel interfaces managed by the SMF++. 468 o ICN Application Function (ICN-AF) : ICN-AF represents the 469 application controller function that interfaces with ICN-SMF and 470 user data management (UDM) function in 5GC. In addition to 471 transferring ICN forwarding rules to ICN-SMF, ICN-AF also 472 interfaces with UDM to transfer user profile and subscription 473 policies required to map UE's ICN PDU session request to an 474 appropriate ICN slice through NSSF. ICN-AF is an extension of the 475 ICN service orchestration function, which can influence both ICN- 476 SMF and UPF to steer traffic based on UE (or changing service) 477 requirements. ICN-AP can also interact with the northbound 5G 478 operator's service functions, such as network exposure function 479 (NEF) that exposes network capabilities, for e.g. location based 480 services, that can be used by ICN-AF for proactive ICN PDU session 481 and slice management and offer additional capabilities to UE. 483 5.1.1. Normative Interface Extensions 485 o N1++/N11++: This extension enables ICN specific control extensions 486 to support ICN programmability at the UE via AMF++, and also 487 impose QoS requirements to ICN PDU session in 5GC based on service 488 requirements. 490 o NIcn: This extension shall support two functions: (i) control 491 plane programmability to enable ICN PDU sessions applicable to 5GC 492 to map to name based forwarding rules in ICN-AP; (ii)control plane 493 extensions to enable ICN mobility anchoring at ICN-AP, in which 494 case it also acts as POA for ICN flows. Features such as ICN 495 mobility as a service can be supported with this extension [mas]. 497 o Naf++: This extensions shall support 5GC control functions such as 498 (i.e. naming, addressing, registration/authentication and 499 mobility) for ICN UE and PDU sessions respectively with 500 interaction with the PCF and UDM functions. The PCF and UDM 501 functions interacts with ICN-AF function for service or slice 502 specific configuration. 504 o Npcf++/Nudm++: This extension creates an interface to push ICN PDU 505 session requirement to PCF and UDM functions, which is enforced 506 during ICN application registration, authentication, during ICN 507 slice mapping, and provisioning of resources for these PDU 508 sessions in the UPFs. 510 5.2. User Plane Extensions 512 As explained in detail in [TS23.501], UPFs are service agnostic 513 functions, hence extensions are not required to operate an ICN-DN. 514 The inter-connection of UE to ICN-DN comprises of two segments, one 515 from RAN to UL-CL and the other from UL-CL to ICN-AP. These segments 516 use IP tunneling constructs, where the service semantic check at UL- 517 CL and ICN-AP is performed using IP's five tuples to determine both 518 UL and DL tunnel mappings. We summarize the relevant UPFs and the 519 interfaces for handling ICN PDU sessions as follows. 521 o ICN Anchor Point (ICN-AP): ICN-AP shall host the 5GC PDU sessions 522 and offer inter-connection to the ICN-DNs. It manages multiple 523 logical interfaces with ICN capable UE and relays ICN packets to 524 the appropriate ICN PDU session instances in the DL. ICN-AP shall 525 be logical service anchor point and it should be capable of 526 serving different ICN services. ICN-AP also manages the mobility 527 state of ICN-UE after session is established such as in the case 528 of handover or roaming. 530 o ICN Packet Data Network (ICN-(P)DN) : ICN-DN represents a set of 531 ICN nodes used for ICN networking and with heterogeneous service 532 resources such as storage and computing points. An ICN network 533 enables both network and application services, with network 534 services including caching, mobility, multicast, multi-path 535 routing (and possibly network layer computing), and application 536 services including network resources (such as cache, storage, 537 network state resources) dedicated to the application. This UPF 538 requires service, control and data plane mechanisms to understand 539 the application requirements and translate them to control 540 signaling to provision the required state in the data plane. 542 o Uplink Classifier (UL-CL) :UL-CL enables classification of flows 543 based on source or destination IP address and steers the traffic 544 to an appropriate network or service function anchor point. 545 Within the current context, with the assumption that ICN-AP is 546 identified based on service IP address associated with the UE's 547 flows, UL-CL checks the source or destination address to direct 548 traffic to an appropriate ICN-AP. As UL-CL is a logical function, 549 it can also reside in RAN, as shown in Figure 2, where traffic 550 classification rules can be applied to forward the ICN payload 551 towards the next ICN-AP, as an extension classification can also 552 be performed over 5G-NR or ICN protocol to determine the next 553 logical hop. For native ICN UE, ICN shall be deployed on layer-2 554 MAC, hence there may not be any IP association; for such packet 555 flow, new classification schema shall be required. 557 5.2.1. Normative Interface Extensions 559 o N3: Though the current architecture supports heterogeneous service 560 PDU handling, future extensions can include user plane interface 561 extensions to offer explicit support to ICN PDU session traffic, 562 for instance, an incremental caching and computing function in RAN 563 or UL-CL to aid with content distribution. 565 o N9: Extensions to this interface can consider UPFs to enable 566 richer service functions, for instance to aid context processing. 567 In addition extensions to enable ICN specific encapsulation to 568 piggyback ICN specific attributes such as traffic characteristics 569 between the UPF branching point and the ICN-AP. The intermediate 570 nodes between the UL-CL and the ICN-AP can also be other caching 571 points. 573 o N6: This interface is established between the ICN-AP and the ICN- 574 DN, whose networking elements in this segment can be deployed as 575 an overlay or as a native Layer-3 network. 577 6. ICN Deployement Use Case Scenarios 579 Here we discuss two relevant network services enabled using ICN in 580 5G. 582 6.1. Mobile Edge Computing 584 We consider here a radio edge service requiring low latency, high 585 capacity and strict quality of service. For the discussion in this 586 draft, we analyze connected vehicle scenario, where the car's 587 navigation system (CNS) uses data from the edge traffic monitoring 588 (TM-E) service instance to offer rich and critical insights on the 589 road conditions (such as real-time congestion assisted with media 590 feeds). This is aided using traffic sensing (TS) information 591 collected through vehicle-to-vehicle (V2V) communication over 592 dedicated short-range communications (DSRC) radio by the TS-E, or 593 using road-side sensor units (RSU) from which this information can be 594 obtained. The TS-E instances then push this information to a central 595 traffic sensing instance (TS-C). This information is used by the 596 central traffic monitoring service (TM-C) to generate useable 597 navigation information, which can then be periodically pushed to or 598 pulled by the edge traffic monitoring service (TM-E) to respond to 599 requests from vehicle's CNS. For this scenario, our objective is to 600 compare advantages of offering this service over an IP based MEC 601 versus one based on ICN. We can generalize the following discussion 602 to other MEC applications as well. 604 6.1.1. IP-MEC Scenario 606 Considering the above scenario, when a vehicle's networking system 607 comes online, it first undergoes an attachment process with the 5G- 608 RAN, which includes authentication, IP address assignment and DNS 609 discovery. The attachment process is followed by PDU session 610 establishment, which is managed by SMF signaling to UL-CL and the UPF 611 instance. When the CNS application initializes, it assumes this IP 612 address as its own ID and tries to discover the closest service 613 instance. Local DNS then resolves the service name to a local MEC 614 service instance. Accordingly, CNS learns the IP service point 615 address and uses that to coordinate between traffic sensing and 616 monitoring applications. 618 CNS is a mission critical application requiring instant actions which 619 is accurate and reliable all the time. Delay of microsecond or non- 620 response could result in fatalities. Following are main challenges 621 with the IP-MEC design: 623 o At the CNS level, non-standardization of the naming schema results 624 in introducing an application level gateway to adapt the sensing 625 data obtained from DSRC system to IP networks, which becomes 626 mandatory if the applications are from different vendors. 628 o As the mobility results in handover between RAN instances, 629 service-level or 5GC networking-level mechanisms need to be 630 initiated to discover a better TM-E instance, which may affect the 631 service continuity and result in session reestablishment that 632 introduces additional control/user plane overheads. 634 o Data confidentiality among multiple CNS attached 5G RAN, 635 authentication and privacy control are offered through an SSL/TLS 636 mechanism over the transport channel, which has to be re- 637 established whenever the network layer attributes are reset. 639 6.1.2. ICN-MEC Scenario 641 If the CNS application is developed over ICN either natively or as an 642 overlay over IP, ICN shall allows the same named data logic to 643 operate over heterogeneous interfaces (such as DSRC radio, and IP 644 transport-over-5G, unlicensed radio over WiFi etc. link), thereby 645 avoiding the need for application layer adaptations. 647 We can list the advantages of using ICN-based MEC as follows: 649 o As vehicles within a single road segment are likely to seek the 650 same data, ICN-based MEC allows to leverage opportunistic caching 651 and storage enabled at ICN-AP, thereby avoiding service level 652 unicast transmissions. 654 o Processed and stored traffic data can be easily contextualized to 655 different user requirements. 657 o Appropriate mobility handling functions can be used depending on 658 mobility type (as consumer or producer), specifically, when an 659 ICN-UE moves from one RAN instance to another, the next IP hop, 660 which identifies the ICN-AP function, has to be re-discovered. 661 Unlike the IP-MEC scenario, this association is not exposed to the 662 applications. As discussed earlier, control plane extensions to 663 AMF and SMF can enable re-programmability of the ICN layer in the 664 vehicle to direct it towards a new ICN-AP, or to remain with the 665 same ICN-AP, based on optimization requirements. 667 o As ICN offers content-based security, produced content can be 668 consumed while authenticating it at the same time (i.e., allowing 669 any data produced to diffuse to its point of use through named 670 data networking). 672 6.2. ICN Session Mobility 674 Mobility scenario assumes a general ICN-UE handover from S-RAN to 675 T-RAN, where each of them is served by different UPFs, i.e., UL-CL-1 676 and UL-CL-2. We also assume that UL-CL-1 and UL-CL-2 use different 677 ICN-APs as gateways, referred to as ICN-AP-1 and ICN-AP-2. From an 678 ICN perspective, we discuss here the producer mobility case, which 679 can be handled in multiple ways, one of which is proposed in 680 [mas].However, the details of the ICN mobility solution are 681 orthogonal to this discussion. Here, ICN-UE refers to an application 682 producer (e.g., video conferencing application, from which ICN 683 consumers request real-time content. Here we also assume the absence 684 of any direct physical interface, Xn, between the two RANs. The 685 current scenario follows the handover procedures discussed in 686 [TS23.502], with focus here on integrating it with an ICN-AP and ICN- 687 DN, where mobility state of the ICN sessions are handled. 689 The overall signaling overhead to handle seamless mobility also 690 depends on the deployment models discussed in Section 4. Here we 691 consider the case when RAN, UL-CL and ICN-AP are physically disjoint; 692 however in the case where RAN and UL-CL are co-located then a part of 693 the signaling to manage the tunnel state between the RAN and UL-CL is 694 localized, which then improves the overall signaling efficiency. 695 This can be further extended to the case when ICN-APs are co-located 696 with the RAN and UL-CL, leading to further simplification of the 697 mobility signaling. 699 Next, we discuss the high-level steps involved during handover. 701 o Step 1: When the ICN-UE decides to handover from S-RAN to T-RAN, 702 ICN-UE signals the S-RAN with a handover-request indicating the 703 new T-RAN it is willing to connect. This message includes the 704 affected PDU session IDs from the 5GC perspective, along with the 705 ICN names that require mobility support. 707 o Step 2: S-RAN then signals the AMF serving the ICN-UE about the 708 handover request. The request includes the T-RAN details, along 709 with the affected ICN PDU sessions. 711 o Step 3: Here, when SMF receives the ICN-UE's and the T-RAN 712 information, it identifies UL-CL-2 as the better candidate to 713 handle the ICN PDU sessions to T-RAN. In addition, it also 714 identifies ICN-AP-2 as the appropriate gateway for the affected 715 ICN PDU sessions. 717 o Step 4: SMF signals the details of the affected PDU sessions along 718 with the traffic filter rules to switch the UL traffic from UL- 719 CL-2 to ICN-AP-2 and DL flows from UL-CL-2 to T-RAN. 721 o Step 5: SMF then signals ICN-SMF about the PDU session mobility 722 change along with the information on UL-CL-2 for it to provision 723 the tunnel between ICN-AP-2 and UL-CL-2. 725 o Step 6: Based on the signaling received on the ICN PDU session, 726 ICN-SMF identifies the affected gateways, i.e., ICN-AP-1 and ICN- 727 AP-2: (i) ICN-SMF signals ICN-AP-2 about the affected PDU session 728 information to update its DL tunnel information to UL-CL-2. Then, 729 based on the ICN mobility solution, appropriate ICN mobility state 730 to switch the future incoming Interests from ICN-AP-1 to UL-CL-2; 731 (ii) ICN-SMF also signals ICN-AP-1 with the new forwarding 732 label[mas] to forward the incoming Interest traffic to ICN-AP-2. 733 This immediately causes the new Interest payload for the ICN-UE to 734 be send to the new ICN gateway in a proactive manner. 736 o Step 7: ICN-SMF then acknowledges SMF about the successful 737 mobility update. Upon this, the SMF then acknowledges AMF about 738 the state changes related to mobility request along with the 739 tunnel information that is required to inter-connect T-RAN with 740 UL-CL-2. 742 o Step 8: AMF then updates the T-RAN PDU session state in order to 743 tunnel ICN-UE's PDU sessions from T-RAN to UL-CL-2. This is 744 followed by initiating the RAN resource management functions to 745 reserve appropriate resources to handle the new PDU session 746 traffic from the ICN-UE. 748 o Step 9: AMF then signals the handover-ack message to the UE, 749 signaling it to handover to the T-RAN. 751 o Step 10: UE then issues a handover-confirm message to T-RAN. At 752 this point, all the states along the new path comprising the 753 T-RAN, UL-CL-2 and ICN-AP-2 is set to handle UL-DL traffic between 754 the ICN-UE and the ICN-DN. 756 o Step 11: T-RAN then signals the AMF on its successful connection 757 to the ICN-UE. AMF then signals S-RAN to remove the allocated 758 resources to the PDU session from the RAN and the tunnel state 759 between S-RAN and UL-CL-1. 761 o Step 12: AMF then signals SMF about the successful handover, upon 762 which SMF removes the tunnel states from UL-CL-1. SMF then 763 signals the ICN-SMF, which then removes the ICN mobility state 764 related to the PDU session from ICN-AP-1. Also at this point, 765 ICN-SMF can signal the ICN-NRS (directly or through ICN-AP-2) to 766 update the UE-ID resolution information, which now points to ICN- 767 AP-2 [mas]. 769 Note that, inter-RAN handover mapping to the same UL-CL represents a 770 special case of the above scenario. 772 7. Conclusion 774 In this draft, we explore the feasibility of realizing future 775 networking architectures like ICN within the proposed 3GPP's 5GC 776 architecture. Towards this, we summarized the design principles that 777 offer 5GC the flexibility to enable new network architectures. We 778 then discuss 5GC architecture along with the user/control plane 779 extensions required to handle ICN PDU sessions formally. We then 780 apply the proposed architecture to two relevant services that ICN 781 networks can enable: first, mobile edge computing over ICN versus the 782 traditional IP approach considering a connected car scenario, and 783 argue based on architectural benefits; second, handling ICN PDU 784 session mobility in ICN-DN rather than using IP anchor points, with 785 minimal support from 5GC. 787 8. IANA Considerations 789 This document requests no IANA actions. 791 9. Security Considerations 793 This draft proposes extensions to support ICN in 5G's next generation 794 core architecture. ICN being name based networking opens up new 795 security and privacy considerations which have to be studied in the 796 context of 5GC. This is in addition to other security considerations 797 of 5GC for IP or non-IP based services considered in [TS33.899]. 799 10. Acknowledgments 801 ... 803 11. Informative References 805 [I-D.rahman-icnrg-deployment-guidelines] 806 Rahman, A., Trossen, D., Kutscher, D., and R. Ravindran, 807 "Deployment Considerations for Information-Centric 808 Networking (ICN)", draft-rahman-icnrg-deployment- 809 guidelines-04 (work in progress), October 2017. 811 [I-D.suthar-icnrg-icn-lte-4g] 812 suthar, P., Stolic, M., Jangam, A., and D. Trossen, 813 "Native Deployment of ICN in LTE, 4G Mobile Networks", 814 draft-suthar-icnrg-icn-lte-4g-03 (work in progress), 815 September 2017. 817 [IEEE_Communications] 818 Trossen, D. and G. Parisis, "Designing and Realizing an 819 Information-Centric Internet", Information-Centric 820 Networking, IEEE Communications Magazine Special Issue, 821 2012. 823 [Jacobson] 824 Jacobson, V. and et al., "Networking Named Content", 825 Proceedings of ACM Context, , 2009. 827 [lteversus5g] 828 Kim, J., Kim, D., and S. Choi, "3GPP SA2 architecture and 829 functions for 5G mobile communication system.", ICT 830 Express 2017, 2017. 832 [mas] Azgin, A., Ravidran, R., Chakraborti, A., and G. Wang, 833 "Seamless Producer Mobility as a Service in Information 834 Centric Networks.", 5G/ICN Workshop, ACM ICN Sigcomm 2016, 835 2016. 837 [Ravindran] 838 Ravindran, R., Chakraborti, A., Amin, S., Azgin, A., and 839 G. Wang, "5G-ICN : Delivering ICN Services over 5G using 840 Network Slicing", IEEE Communication Magazine, May, 2016. 842 [RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., 843 Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, 844 "Information-Centric Networking (ICN) Research 845 Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, 846 . 848 [TS-5GNR] 3GPP-38-xxx, "Technical Specification series on 5G-NR 849 (Rel.15)", 3GPP , 2017. 851 [TS23.501] 852 3gpp-23.501, "Technical Specification Group Services and 853 System Aspects; System Architecture for the 5G System 854 (Rel.15)", 3GPP , 2017. 856 [TS23.502] 857 3gpp-23.502, "Technical Specification Group Services and 858 System Aspects; Procedures for the 5G System(Rel. 15)", 859 3GPP , 2017. 861 [TS23.799] 862 3gpp-23.799, "3rd Generation Partnership Project; 863 Technical Specification Group Services and System Aspects; 864 Study on Architecture for Next Generation System (Rel. 865 14)", 3GPP , 2017. 867 [TS33.899] 868 3gpp-33.899, "Study on the security aspects of the next 869 generation system", 3GPP , 2017. 871 [VSER] Ravindran, R., Liu, X., Chakraborti, A., Zhang, X., and G. 872 Wang, "Towards software defined ICN based edge-cloud 873 services", CloudNetworking(CloudNet), IEEE Internation 874 Conference on, IEEE Internation Conference on 875 CloudNetworking(CloudNet), 2013. 877 Authors' Addresses 879 Ravi Ravindran 880 Huawei Research Center 881 2330 Central Expressway 882 Santa Clara 95050 883 USA 885 Email: ravi.ravindran@huawei.com 886 URI: http://www.Huawei.com/ 888 Prakash Suthar 889 Cisco Systems 890 9501 Technology Blvd. 891 Rosemont 50618 892 USA 894 Email: psuthar@cisco.com 895 URI: http://www.cisco.com/ 897 Guoqiang Wang 898 Huawei Research Center 899 2330 Central Expressway 900 Santa Clara, CA 95050 901 USA 903 Email: gq.wang@huawei.com