idnits 2.17.1 draft-defoy-nvo3-5g-datacenter-interconnection-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (Jan 24, 2019) is 1916 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-bernardos-sfc-fog-ran-04 == Outdated reference: A later version (-06) exists of draft-ietf-nvo3-evpn-applicability-01 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. de Foy 3 Internet-Draft U. Olvera-Hernandez 4 Intended status: Informational InterDigital Communications 5 Expires: July 28, 2019 Jan 24, 2019 7 5G-Datacenter Interconnection Use Case 8 draft-defoy-nvo3-5g-datacenter-interconnection-00 10 Abstract 12 Interconnection between 5G networks and datacenter networks provide a 13 new use case for NVO3 and for the 3rd Generation Partnership Project 14 (3GPP) "5GLAN" feature. This document describes how layer-2 and 15 layer-3 datacenter VPN technology can interoperate with anchor User 16 Plane Functions (UPF) to interconnect 5G devices and datacenter 17 servers over a virtual LAN. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on July 28, 2019. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. About the 5GLAN Feature . . . . . . . . . . . . . . . . . 2 55 1.2. Interaction between 5GLAN and Virtual Networks . . . . . 3 56 1.3. Goals of this Document . . . . . . . . . . . . . . . . . 3 57 2. New Use Case for NVO3 and 5GLAN: 5G/Datacenter 58 Interconnection . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Architecture Overview . . . . . . . . . . . . . . . . . . . . 4 60 4. Major Features of a 5G/Datacenter Interconnection . . . . . . 6 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 63 7. Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 8. Informative References . . . . . . . . . . . . . . . . . . . 9 65 Appendix A. 5GLAN Background Information . . . . . . . . . . . . 10 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 68 1. Introduction 70 1.1. About the 5GLAN Feature 72 In an ongoing work, 3GPP is seeking to enable LAN-like virtual 73 networking between groups of end devices. Appendix A provides 74 references and additional details relative to the 5GLAN work. 76 5GLAN requirements, defined in [_3GPP.22.261] can be shortly 77 summarized as: 79 A selected set of end devices can communicate with each other as 80 if over a LAN, including over Ethernet or over IP, using a private 81 addressing scheme. 83 Unicast and multicast/broadcast communication is enabled between 84 end devices, in some cases with a required latency (e.g. 180ms), 85 or more generally a given consistent QoE. 87 End device mobility is supported. 89 General concepts and use cases were described in [_3GPP.23.734]. 91 In home and enterprise deployments, a goal of 5GLAN is to 92 facilitate interworking with, and sometimes replacing, existing 93 infrastructure, composed of fixed and wireless LANs. 95 In enterprise deployments, 5GLAN will also provide a VPN-like 96 service integrating mobile devices with enterprise networks. 98 In industrial automation deployments, 5GLAN can enable low- 99 latency, reliable and deterministic LAN traffic in manufacturing, 100 machine control, packaging and printing use cases. 102 1.2. Interaction between 5GLAN and Virtual Networks 104 5GLAN connectivity does not have to be confined entirely within a 5G 105 network domain. The conclusion of the 5GLAN study [_3GPP.23.734] 106 states that the standardized solution will include interconnection 107 with (external) data networks. Data networks can be physical or 108 virtual networks. 110 Within the context of edge computing, 5GLAN will make it possible to 111 have 5G devices share a common IP address space with servers deployed 112 in a mini/micro-datacenter. While a similar result could be achieved 113 using an overlay solution terminated on the 5G device, using 5GLAN in 114 this case makes it possible to benefit from 5G network features such 115 as session continuity support, fine-grained QoS support, user and 116 device authentication, and to make a more efficient use of the air 117 interface. 119 1.3. Goals of this Document 121 The goals of this document are to describe: 123 New use cases for NVO3 and 5GLAN, related to interconnections 124 between 5G networks and datacenters. 126 A more detailed discussion of the architecture and requirements of 127 this interconnection. 129 Our primary scenario will be a virtual network domain located outside 130 of the 5G domain (a "data network" in 3GPP terminology), that can be 131 joined by 5G devices. It is NOT a goal of the present document to 132 cover inter-UPF connectivity inside the 5G domain, which 3GPP intends 133 to standardize in 2019. 135 2. New Use Case for NVO3 and 5GLAN: 5G/Datacenter Interconnection 137 In addition to already known base 5GLAN use cases (see Section 1.1), 138 interconnection of 5GLAN with datacenters will enable new scenarios. 140 Support for Virtualization on 5G End Devices: 5G devices may be used 141 as servers in a "mobile data center", or to extend a traditional/ 142 fixed data center. This involves VM hosting on 5G devices, and VM 143 mobility between 5G devices, or between 5G devices and DC servers 144 and enables, for example: 146 Transparent mobility of Fog RAN [I-D.bernardos-sfc-fog-ran] 147 components between 5G devices and micro-datacenters, 149 Transparent offloading of application tasks towards the distant 150 or edge cloud, or towards other 5G devices. 152 As discussed in Section 4, VM hosting on 5G devices under the 153 control of a NVO3 network operator can bring new requirements on 154 5G networks interface with the datacenter data networks, including 155 exposing a "tenant system interface" identity and state 156 information, supporting adding/removing addresses, and supporting 157 hot VM migration. 159 End-to-End Redundancy: 5G devices may connect to a 5GLAN virtual 160 network over several paths, using active-active or active-passive 161 configurations. For example, a 5G device running a critical 162 application may use both WLAN and a cellular link to increase 163 availability. Today, this type of connection are defined in 5G 164 but are using a same anchor UPF for both links, which limits the 165 scope of redundancy to the 5G network. Instead, path redundancy 166 could be prolonged beyond the 5G network (e.g. using a different 167 anchor for each path), into the datacenter. 169 3. Architecture Overview 171 A high level architecture view of the system is represented in 172 Figure 1 (based on our interpretation of the conclusions of 173 [_3GPP.23.734]). 175 In the data plane, the end device (user equipment) is connected 176 point-to-point to an anchor gateway (UPF), through the radio access 177 network and possibly through intermediate UPFs (not shown here). 178 This point-to-point connection is called PDU session in 5G. In usual 179 non-5GLAN communication use cases, IP or Ethernet packets are carried 180 over a tunnel between the end device and the anchor UPF, decapsulated 181 by the UPF and forwarded over a data network. In the 5GLAN case, the 182 decapsulated packet should be tunneled/forwarded from the anchor UPF 183 towards a remote virtualization edge, or another anchor UPF, which 184 decapsulates and forwards the packet towards its destination end 185 device. (Except in the simpler case where source and destination end 186 devices are served by the same UPF.) 188 The section of network between anchor UPFs in the diagram is a 189 datacenter VPN domain ("L2/L3 VPN domain"), with its own control and 190 data plane. Anchor UPFs may be directly interconnected inside the 5G 191 network as well, for internal 5GLAN traffic (although it is not 192 represented here). 194 In the control plane, 5G end device connectivity is today supported 195 by the Access and Mobility Management Function (AMF) and Session 196 Management Function (SMF). 5GLAN specific control plane support for 197 a given 5GLAN network (e.g. to configure UPFs, and perform access 198 control) will be implemented inside a single SMF. 200 There should be an interconnection between the 5G network and the L2/ 201 L3 VPN domain, in the control and/or management plane. 203 In the data plane, an edge function collocated or interconnected with 204 the UPF is acting as a gateway between the 3GPP and L2/L3 VPN domain. 205 This edge function corresponds to "provider edge" device in VPN 206 terminology. 208 +---+ +------------------------------------------+ +---+ 209 |AMF+----+ SMF including 5GLAN Control Plane +-----+AMF| 210 +-+-+ ++-------------------+--------------------++ +-+-+ 211 | | 3GPP Domain : | | 212 | | +-----------------+------------------+ | | 213 | | | L2/L3 VPN Domain | | | 214 | | | | | | 215 +---+--+ +-+------+ +----------+ +------+-+ +---+--+ 216 |Device+--+UPF|Edge+-------+Underlying+-------+Edge|UPF+--+Device| 217 +------+ ^+--------+ | Network | +--------+ ^+------+ 218 : | +----------+ | : 219 : | | | | : 220 PDU Session | +---------+ +---------+ | PDU Session 221 | | Gateway | | Edge | | 222 | +-+-------+ +----+----+ | 223 +------------------------------------+ 224 | | 225 +-------------+--------------+ +---+----+ 226 | Other L2/L3 VPN Domain | | Tenant | 227 | e.g. data center or | | System | 228 | other mobile network | +--------+ 229 +----------------------------+ 231 Figure 1: 5GLAN Network Interconnected with a L2/L3 VPN Domain 233 We will focus on NVO3 as the datacenter VPN technology. 234 Nevertheless, applicability of other virtualization technologies to 235 5GLAN may be studied as well in future revisions of this document. 237 The 5GLAN architecture can be made to integrate with the NVO3 238 architecture [RFC8014], where: 240 A 5G end device corresponds to an end device in NVO3. 242 A 5G edge/UPF corresponds to an external NVE in NVO3 (the edge/UPF 243 can encapsulate packets in network virtualization headers, as does 244 the external NVE in NVO3, to avoid carrying those extra headers 245 over the wireless link). 247 The PDU session in 5G corresponds to the VLAN connection between 248 an end device and an external NVE (i.e. both are point-to-point 249 connections). 251 An overview of the integration of NVO3 and the 5G network for 5GLAN 252 is displayed in Figure 2 254 +---+ +------------------------------------------+ +---+ 255 |AMF+----+ SMF including 5GLAN Control Plane +-----+AMF| 256 +-+-+ ++-------------------+--------------------++ +-+-+ 257 | | 3GPP Domain : | | 258 | | +------------------------------------+ | | 259 | | | NVO3 domain : | | | 260 | | | +---+---+ | | | 261 | | | | NVA | | | | 262 | | | +---+---+ | | | 263 | | | | | | | 264 +---+--+ +-+------+ +----+-----+ +------+-+ +---+--+ 265 |Device+--+UPF|NVE +-------+ IP +-------+NVE |UPF+--+Device| 266 +------+ ^---------+ | Underlay | +--------+ ^-------+ 267 : | +----------+ | : 268 : | | | | : 269 PDU Session | +---------+ +---------+ | PDU Session 270 | | Gateway | | NVE | | 271 | +-+-------+ +----+----+ | 272 +------------------------------------+ 273 | | 274 +-------------+--------------+ +---+----+ 275 | Other L2/L3 VPN Domain | | Tenant | 276 | e.g. data center or | | System | 277 | other mobile network | +--------+ 278 +----------------------------+ 280 Figure 2: 5GLAN Network Interconnected with a NVO3 Domain 282 4. Major Features of a 5G/Datacenter Interconnection 284 The following discusses VPN-5G interconnection functionalities. 286 L2/L3 VPN: To support both IP-based and Ethernet-based 5GLANs, the 287 L2/L3 VPN domain should provide L2 and L3 VPN services between 288 provider edges. NVO3 can support L2 and L3 VPNs over an IP 289 overlay. For example, EVPN may be used in L2 case, as described 290 in [I-D.ietf-nvo3-evpn-applicability]. 292 VM Hosting and VM Mobility: The goal of this feature is to have the 293 NVO3 network operator control connectivity for all VMs, including 294 VMs hosted on 5G devices. Based on an analysis of End Device-to- 295 NVE Control Protocol requirements [RFC8394] in the context of 5G 296 LANs, here is a summary of potential requirements on 5G-NVO3 297 interfaces: 299 The concept of tenant system interface (TSI) identifies the 300 connection to a single VM (e.g. it corresponds to a single VLAN 301 tag on hypervisor-NVE connection in NVO3). This concept may also 302 be useful to support VM migration. 5GLAN could for example 303 restrict traffic to/from a single tenant system (e.g. a VM) to a 304 single PDU session, and associate a TSI identifier to the 305 connection, exposed to the L2/L3 VPN domain. 307 End Devices can communicate tenant system interface state 308 information (associated and activated), which corresponds to 309 different phases of a VM lifetime. Such information may therefore 310 be carried over a PDU session to enable similar operations in 311 5GLAN. 313 A tenant system (e.g. VM) can add/remove IP/MAC addresses 314 dynamically even after End Device-to-NVE connection is made for 315 this tenant system. 317 The external NVE (i.e. edge/UPF in 5GLAN context) can dynamically 318 initiate the deactivation or de-association of a MAC/IP address. 320 Hot and cold VM mobility may be supported. The 5G network should 321 indicate when an event is caused by a hot VM migration event. 323 Active-active and active-passive redundant path to a 5G device 324 (through multiple edge/UPFs) may be supported, to provide end-to- 325 end path redundancy. To support this, the 5G network should 326 expose reachability information towards a given IP or MAC address 327 through multiple UPFs. Priority information may be exposed as 328 well, to enable active-passive redundancy. 330 End Device Mobility and Session Continuity: End device mobility 331 between anchor UPFs may be similar to hot VM migration events, 332 although they occur more often and affect all hosted VMs on a 333 device. They may also have more stringent requirements in term of 334 packet loss and latency since, as opposed to the VM migration 335 case, end device mobility requires no transfer of state. 337 Mobility requirements can vary: for example 5G devices using a 338 fixed anchor ("session continuity mode (SSC) 1") will not expose 339 any mobility event to the L2/L3 VPN domain. Nevertheless, in 340 cases where mobility and low latency are required, break-before- 341 make (in SSC mode 2) or make-before-break mobility (in SSC mode 3) 342 events may be exposed to the L2/L3 VPN domain. 344 QoS: 5GLAN networks can be applied a wide range of QoS inside the 5G 345 network, including ultra-low latency. Nevertheless, the level of 346 QoS depends on the application, and therefore the level of QoS to 347 apply to traffic to/from 5G devices in the L2/L3 VPN is not known 348 at this time. 350 QoS mechanisms to be supported in the L2/L3 VPN domain can include 351 best-effort, differentiated services, traffic engineered links, 352 deterministic networking. Some form of coordination may be 353 therefore needed between 5G and the L2/L3 VPN domain in control 354 and/or management plane, e.g. to setup proper traffic engineering 355 associated with NVO3 overlay networks (e.g. create/modify/release 356 underlying TE paths when an end device changes its attachment 357 point from one edge/UPF to another). 359 Privacy: Privacy is required for communication between end devices. 360 The L2/L3 VPN, including the edge/UPF, should therefore support a 361 secure protocol over the VPN domain (e.g. including encryption). 362 Encryption of NVO3 traffic over the underlying network (e.g. using 363 IPSec between NVEs) is mentioned in [RFC8014]. 365 Access Control: Access control of end devices can be performed by 366 the 3GPP domain (e.g. at network registration and later when 367 creating the PDU session). Some form of cooperation between the 368 5G network and the L2/L3 VPN domain may be needed to authenticate 369 the 5G subscription in the L2/L3 VPN domain (e.g. through the 370 exposition of a subscription identifier). 372 Other Remarks: As already mentioned, UPFs can be directly 373 interconnected with each other for internal 5GLAN communication. 374 LAN communication between 5G devices may therefore entirely bypass 375 the L2/L3 VPN. 377 Similarly, although device-to-device communication is currently 378 not defined in 3GPP for 5GLAN, in the future it may also be 379 leveraged to bypass the L2/L3 VPN for direct communication between 380 devices. 382 A 5G device can become inactive, and may be paged/awaken when 383 there is outstanding traffic for this device. This will be 384 handled entirely in the 3GPP system (traffic will be buffered at 385 UPF and device will be paged). 387 5. IANA Considerations 389 This document requests no IANA actions. 391 6. Security Considerations 393 From the 5G operator perspective, traffic sent over the L2/L3 VPN 394 domain should be secured against being misdelivered, being modified, 395 or having its content exposed to an inappropriate third party. This 396 requirement is also found in NVO3. 398 Additionally, 5G devices wishing to join a virtual network deployed 399 in the L2/L3 VPN domain will need to be authenticated and authorized 400 for joining. Mutual authentication and authorization between 5G 401 devices and virtual networks may be needed and may be supported 402 through coordination between the 5G network, which authenticated the 403 5G device, and the L2/L3 VPN domains. 405 7. Next Steps 407 We would like to propose this use case for further discussion and 408 possibly adoption in a RTG working group such as NVO3 or RTGWG, as a 409 new use case for datacenter networking. 411 At this time we do not expect a change in NVO3 protocols. On the 412 other side, discussions at the IETF can provide valuable input to 413 justify and drive any future enhancement to 5G networks, and align 414 with IETF datacenter protocols (e.g. what information and operations 415 should be made available to datacenter networks). 417 8. Informative References 419 [_3GPP.22.261] 420 3GPP, "Service requirements for next generation new 421 services and markets", 3GPP TS 22.261, 422 . 424 [_3GPP.22.821] 425 3GPP, "Feasibility Study on LAN Support in 5G", 3GPP 426 TR 22.821, 427 . 429 [_3GPP.23.501] 430 3GPP, "System Architecture for the 5G System", 3GPP 431 TS 23.501, 432 . 434 [_3GPP.23.734] 435 3GPP, "Study on enhancement of 5GS for Vertical and LAN 436 Services", 3GPP TR 23.734, 437 . 439 [_3GPP.33.819] 440 3GPP, "Study on security enhancements of 5GS for vertical 441 and Local Area Network (LAN) services", 3GPP TR 33.819, 442 . 444 [I-D.bernardos-sfc-fog-ran] 445 Bernardos, C., Rahman, A., and A. Mourad, "Service 446 Function Chaining Use Cases in Fog RAN", draft-bernardos- 447 sfc-fog-ran-04 (work in progress), September 2018. 449 [I-D.ietf-nvo3-evpn-applicability] 450 Rabadan, J., Bocci, M., Boutros, S., and A. Sajassi, 451 "Applicability of EVPN to NVO3 Networks", draft-ietf-nvo3- 452 evpn-applicability-01 (work in progress), October 2018. 454 [RFC8014] Black, D., Hudson, J., Kreeger, L., Lasserre, M., and T. 455 Narten, "An Architecture for Data-Center Network 456 Virtualization over Layer 3 (NVO3)", RFC 8014, 457 DOI 10.17487/RFC8014, December 2016, 458 . 460 [RFC8394] Li, Y., Eastlake 3rd, D., Kreeger, L., Narten, T., and D. 461 Black, "Split Network Virtualization Edge (Split-NVE) 462 Control-Plane Requirements", RFC 8394, 463 DOI 10.17487/RFC8394, May 2018, 464 . 466 Appendix A. 5GLAN Background Information 468 The 5G architecture is defined by 3GPP in [_3GPP.23.501], currently 469 as part of release 15. 471 5GLAN is a new feature developed as part of release 16. Its 472 requirements are currently being specified in [_3GPP.22.261] (based 473 on results from an earlier study on requirements in [_3GPP.22.821]). 475 The architecture of 5GLAN has been studied in [_3GPP.23.734], along 476 with other subjects. A specification phase for the 5GLAN 477 architecture will likely follow. Conclusions of the study included 478 the following: 480 5GLAN traffic (IP or Ethernet traffic between a restricted set of 481 "5GLAN group member" devices) will be transported between 5G 482 devices and their anchor UPF. Anchor UPFs will forward this 483 traffic, as applicable, to/from (1) a data network, (2) another 484 anchor UPF, or (3) other devices using local forwarding through 485 the anchor UPF, when devices are connected to the same anchor. In 486 case (2), direct traffic between anchor UPFs will be encapsulated 487 in per-5GLAN group tunnels. 489 In the control plane, a single SMF will handle connectivity of all 490 devices connected to the same 5GLAN. 492 The user plane can be centralized (single anchor UPF involved in a 493 single 5GLAN) or distributed (multiple anchor UPFs involved in a 494 single 5GLAN). 496 Security aspects related to 5GLAN are currently studied in 497 [_3GPP.33.819]. 499 Authors' Addresses 501 Xavier de Foy 502 InterDigital Communications, LLC 503 1000 Sherbrooke West 504 Montreal H3A 3G4 505 Canada 507 Email: Xavier.Defoy@InterDigital.com 509 Ulises Olvera-Hernandez 510 InterDigital Communications, LLC 511 64 Great Eastern Street 512 London EC2A 3QR 513 England 515 Email: Ulises.Olvera-Hernandez@InterDigital.com