idnits 2.17.00 (12 Aug 2021) /tmp/idnits16027/draft-allan-5g-fmc-encapsulation-08.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 (February 2021) is 453 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Dave Allan, Ericsson ed. 2 Intended status: Informational Donald Eastlake, Futurewei 3 Expires: August 2021 David Woolley, Telstra 4 February 2021 6 5G Wireless Wireline Convergence User Plane Encapsulation (5WE) 7 draft-allan-5g-fmc-encapsulation-08 9 Abstract 11 As part of providing wireline access to the 5G Core (5GC), deployed 12 wireline networks carry user data between 5G residential gateways 13 and the 5G Access Gateway Function (AGF). The encapsulation method 14 specified in this document supports the multiplexing of traffic for 15 multiple PDU sessions within a VLAN delineated access circuit, 16 permits legacy equipment in the data path to inspect certain packet 17 fields, carries 5G QoS information associated with the packet data, 18 and provides efficient encoding. It achieves this by specific points 19 of similarity with the RFC 2516 PPPoE data packet encapsulation. 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance 24 with the provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet 27 Engineering Task Force (IETF), its areas, and its working 28 groups. Note that other groups may also distribute working 29 documents as Internet-Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six 32 months and may be updated, replaced, or obsoleted by other 33 documents at any time. It is inappropriate to use Internet- 34 Drafts as reference material or to cite them other than as 35 "work in progress". 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed 41 at http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on January 2021. 45 Copyright and License Notice 47 Copyright (c) 2021 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with 55 respect to this document. Code Components extracted from this 56 document must include Simplified BSD License text as described 57 in Section 4.e of the Trust Legal Provisions and are provided 58 without warranty as described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction...................................................2 63 1.1. Requirements Language........................................4 64 1.2. Acronyms.....................................................4 65 2. Data Encapsulation Format......................................5 66 3. Acknowledgements...............................................6 67 4. Security Considerations........................................6 68 5. IANA Considerations............................................7 69 6. References.....................................................7 70 6.1. Normative References.........................................7 71 6.2. Informative References.......................................8 72 7. Authors' Addresses.............................................8 74 1. Introduction 76 Converged 5G ("fifth generation") wireline networks carry user data 77 between 5G residential gateways (5G-RG) and the 5G Access Gateway 78 Function (identified as a Wireline-AGF (W-AGF) by 3GPP in [TS23316]) 79 across deployed access networks based on Broadband Forum [TR101] and 80 [TR178]. This form of wireline access is considered to be trusted 81 non-3GPP access by the 5G system. 83 The transport encapsulation used needs to meet a variety of 84 requirements including the following: 86 - The ability to multiplex multiple logical connections (Protocol 87 Data Unit (PDU) Sessions as defined by 3GPP) within a VLAN 88 identified point to point logical circuit between a 5G-RG and a W- 89 AGF. 91 - To allow unmodified legacy equipment in the data path to identify 92 the encapsulation and inspect specific fields in the payload. 93 Some access nodes in the data path between the 5G-RG and the W- 94 AGF (Such as digital subscriber loop access multiplexers (DSLAMs) 95 and optical line terminations (OLTs)) currently inspect packets 96 identified by specific Ethertypes to identify protocols such as 97 the point to point protocol over ethernet (PPPoE), IP, ARP, and 98 IGMP. This may be for the purpose of enhanced QoS, policing of 99 identifiers and other applications. Some deployments are 100 dependent upon this inspection. Such devices are able to do this 101 for PPPoE or IP over ethernet (IPoE) packet encodings but would 102 be unable to do so if a completely new encapsulation, or an 103 existing encapsulation using a new Ethertype, were used. 105 - To carry per packet 5G QoS information. 107 - Fixed access residential gateways are sensitive to the complexity 108 of packet processing, therefore an encapsulation that minimizes 109 processing is an important consideration. 111 A data encapsulation that uses a common Ethertype and has certain 112 fields appearing at the same offset as the PPPoE [RFC2516] data 113 encapsulation can address these requirements. This data 114 encapsulation is referred to as the 5G WWC user plane Encapsulation 115 or 5WE. Currently deployed access nodes do not police the VER, TYPE 116 and CODE fields of an RFC 2516 header, and only perform limited 117 policing of stateful functions with respect to the procedures 118 documented in RFC 2516. Therefore, these fields have a different 119 definition for 5WE and are used to: 121 - Identify that the mode of operation for packets encapsulated in 122 such a fashion uses non-access stratum (NAS, a logical control 123 interface between user equipment (UE) and 5GC as specified by 124 3GPP) based 5G WWC session establishment and life cycle 125 maintenance procedures as documented in [TS23502][TS23316] instead 126 of legacy PPP/PPPoE session establishment procedures (i.e. PADI 127 discipline, LCP, NCP etc.). In this scenario "discovery" is 128 performed by means outside the scope of this document. 130 - Permit the session ID field to be used to identify the 5G PDU 131 session the encapsulated packet is part of. 133 - Communicate per-packet 5G QoS Flow Identifier (QFI) and 134 Reflective QoS Indication (RQI) information from the 5GC to the 135 5G-RG. 137 This 5G specific redesign of fields not inspected by deployed 138 equipment results in an encapsulation uniquely applicable to the 139 requirements for the communication of PDU session traffic between 140 the subscriber premises and the 5G system over wireline networks. 141 The 6 byte RFC 2516 data packet header followed by a 2 byte PPP 142 protocol ID is also the most frugal of the encapsulations that are 143 currently supported by legacy access equipment that could be adapted 144 to meet these requirements. 146 This encapsulation is expected to be used in environments where RFC 147 2516 is deployed. Therefore, implementations MUST examine the 148 version number: 150 - if the version number is 1, and PPPoE [RFC2516] is supported, 151 process the frame further, else silently discard it. 153 - if the version number is 2 and 5WE is supported, process the frame 154 further, else silently discard it. 156 In both cases frames for the supported version number should have 157 session IDs corresponding to established sessions for the respective 158 protocol models. A 5WE frame with an unrecognized session ID MUST be 159 silently discarded. 161 This encapsulation may have MTU issues when used for Ethernet 162 multiplexing in networks where the underlying Ethernet payload is 163 limited to 1500 bytes. 165 This encapsulation is not suitable for other network environments, 166 e.g., general use over the public Internet. 168 1.1. Requirements Language 170 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 171 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", 172 "MAY", and "OPTIONAL" in this document are to be interpreted as 173 described in BCP 14 [RFC2119] [RFC8174] when, and only when, they 174 appear in all capitals, as shown here. 176 1.2. Acronyms 178 This document uses the following acronyms: 180 3GPP 3rd Generation Partnership Project 181 5WE 5G WWC Encapsulation 182 5GC 5th Generation Core (network) 183 DSLAM Digital Subscriber Loop Access Multiplexer 184 W-AGF Wireline Access Gateway Function 185 IPoE IP over Ethernet 186 NAS Non-Access Stratum 187 OLT Optical Line Termination 188 PDU Protocol Data Unit 189 PPPoE PPP over Ethernet 190 QFI QoS Flow Identifier 191 QoS Quality of Service 192 RG Residential Gateway 193 RQI Reflective QoS Indicator 194 WWC Wireless Wireline Convergence 196 2. Data Encapsulation Format 198 The Ethernet payload [IEEE802] for PPPoE [RFC2516] is indicated by 199 an Ethertype of 0x8864. The information following that Ethertype 200 uses a value of 2 in the VER field for the repurposing of the PPPoE 201 data encapsulation as the 5G WWC user plane encapsulation (5WE). The 202 5G WWC User Plane encapsulation is structured as follows: 204 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | VER | TYPE | QFI |R|0| SESSION_ID | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | LENGTH | PROTOCOL ID | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | DATA PAYLOAD ~ 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 213 The description of each field is as follows: 215 VER is the version. It MUST be set to 0x02. 217 TYPE is the message type. It MUST be set to 0x01. 219 QFI encodes the 3GPP 5G QoS Flow Identifier [TS38415] to be used 220 for mapping 5G QoS to IP DSCP/802.1 P-bits [IEEE802]. 222 R (short for Reflective QoS Indication [TS38415]) encodes the one 223 bit RQI. It is set by the network side 5WE termination for 224 downstream traffic and ignored by the network for upstream 225 traffic. 227 0 indicates the bit(s) MUST be sent as zero and ignored on 228 receipt. 230 SESSION_ID is a 16-bit unsigned integer in network byte order. It 231 is used to distinguish different PDU sessions that are in the 232 VLAN delineated multiplex. A value of 0xffff is reserved for 233 future use and MUST NOT be used. 235 LENGTH is the length in bytes of the data payload including 236 the initial Protocol ID. It is 16 bits in network byte order. 238 PROTOCOL ID is the 16 bit identifier of the data payload type 239 encoded using values from the IANA PPP DLL protocol numbers 240 registry. (https://www.iana.org/assignments/ppp-numbers/ppp- 241 numbers.xhtml#ppp-numbers-2) 243 The following values are valid in this field for 5G 244 WWC use: 246 0x0021: IPv4 248 0x0031: Ethernet (referred to in PPP as "bridging") 250 0x0057: IPv6 252 Packets received that do not contain one of the above 253 protocol IDs are silently discarded. 255 DATA PAYLOAD is encoded as per the protocol ID. 257 3. Acknowledgements 259 This memo is a result of comprehensive discussions by the Broadband 260 Forum's Wireline Wireless Convergence Work Area. 261 The authors would also like to thank Joel Halpern and Dirk Von Hugo 262 for their detailed review of this draft. 264 4. Security Considerations 266 5G NAS procedures used for session life cycle maintenance employ 267 ciphering and integrity protection [TS23502]. They can be considered 268 to be a more secure session establishment discipline than existing 269 RFC 2516 procedures, at least against on path attackers. 270 The design of the 5WE encapsulation will not circumvent existing 271 anti-spoofing and other security procedures in deployed equipment. 272 The existing access equipment will be able to identify fields that 273 they normally process and policed as per existing RFC 2516 traffic. 275 Therefore, the security of a fixed access network using 5WE will be 276 equivalent or superior to current practice. 278 5WE encapsulated traffic is used on what the 5GC considers to be 279 trusted non-3GPP interfaces, therefore is not ciphered. 5WE is not 280 suitable for use over an untrusted non-3GPP interface. 282 The security requirements of the 5G system are documented in 283 [TS33501] 285 5. IANA Considerations 287 IANA is requested to create a registry on the Point-to-Point (PPP) 288 Protocol Field Assignments IANA Web page as follows: 290 Registry Name: PPP Over Ethernet Versions 291 Registration Procedure: Specification Required 292 References: [RFC2516] [this document] 294 VER Description Reference 295 ----- ----------------------------- ----------- 296 0 reserved [this document] 297 1 PPPoE [RFC2516] 298 2 5G WWC User Plane Encapsulation [this document] 299 3-15 unassigned [this document] 301 IANA is requested to add [this document] as an additional reference 302 for Ethertype 0x8864 in the Ethertypes table on the IANA "IEEE 802 303 Numbers" web page.(https://www.iana.org/assignments/ieee-802- 304 numbers/ieee-802-numbers.xhtml#ieee-802-numbers-1) 306 6. References 308 6.1. Normative References 309 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 310 Requirement Levels", BCP 14, RFC 2119, March 1997. 311 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 312 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 313 May 2017, . 314 [RFC2516] "A Method for Transmitting PPP Over Ethernet (PPPoE)", 315 IETF RFC 2516, February 1999 316 [TS38415] 3rd Generation Partnership Project; Technical 317 Specification Group Radio Access Network; NG-RAN; PDU 318 Session User Plane Protocol (Release 15), 3GPP TS38.415 319 [TS23502] 3rd Generation Partnership Project; Technical 320 Specification Group Services and System Aspects; 321 Procedures for the 5G System (Release 16), 3GPP TS23.502 322 [TS23316] 3rd Generation Partnership Project; Technical 323 Specification Group Services and System Aspects; 324 Wireless and wireline convergence access support 325 for the 5G System (5GS) (Release 16), 3GPP TS23.316, 326 November 2018 328 6.2. Informative References 329 [TR101] "Migration to Ethernet Based Broadband Aggregation", 330 Broadband Forum Technical Report: TR-101 issue 2, July 331 2011 332 [TR178] "Multi-service Broadband Network Architecture and Nodal 333 Requirements", Broadband Forum Technical Report: TR-178, 334 September 2014 335 [IEEE802] 802, IEEE, "IEEE Standard for Local and Metropolitan 336 Networks: Overview and Architecture", IEEE Std 802-2014. 337 [TS33501] 3rd Generation Partnership Project; Technical 338 Specification Group Services and System Aspects; 339 Security Architecture and Procedures for 5G System 340 (Release 16), 3GPP TS33.501, December 2019 342 7. Authors' Addresses 343 Dave Allan (editor) 344 Ericsson 345 2455 Augustine Drive 346 San Jose, CA 95054 USA 347 Email: david.i.allan@ericsson.com 349 Donald E. Eastlake 3rd 350 Futurewei Technologies 351 2386 Panoramic Circle 352 Apopka, FL 32703 USA 353 Phone: +1-508-333-2270 354 Email: d3e3e3@gmail.com 356 David Woolley 357 Telstra Corporation 358 242 Exhibition St 359 Melbourne, 3000 360 Australia 361 Email: david.woolley@team.telstra.com