idnits 2.17.1 draft-allan-5g-fmc-encapsulation-05.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 (July 2020) is 1381 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4937' is defined on line 296, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 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: September 2020 David Woolley, Telstra 4 July 2020 6 5G Wireless Wireline Convergence User Plane Encapsulation (5WE) 7 draft-allan-5g-fmc-encapsulation-05 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 snoop certain packet 17 fields, carries 5G QoS information associated with the packet data, 18 and provides efficient encoding. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance 23 with the provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet 26 Engineering Task Force (IETF), its areas, and its working 27 groups. Note that other groups may also distribute working 28 documents as Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six 31 months and may be updated, replaced, or obsoleted by other 32 documents at any time. It is inappropriate to use Internet- 33 Drafts as reference material or to cite them other than as 34 "work in progress". 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed 40 at http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on January 2021. 44 Copyright and License Notice 46 Copyright (c) 2020 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with 54 respect to this document. Code Components extracted from this 55 document must include Simplified BSD License text as described 56 in Section 4.e of the Trust Legal Provisions and are provided 57 without warranty as described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction...................................................2 62 1.1. Requirements Language........................................3 63 1.2. Acronyms.....................................................4 64 2. Data Encapsulation Format......................................4 65 3. Acknowledgements...............................................5 66 4. Security Considerations........................................5 67 5. IANA Considerations............................................6 68 6. References.....................................................6 69 6.1. Normative References.........................................6 70 6.2. Informative References.......................................6 71 7. Authors' Addresses.............................................7 73 1. Introduction 75 Converged 5G ("fifth generation") wireline networks carry user data 76 between 5G residential gateways (5G-RG) and the 5G Access Gateway 77 Function (identified as an Fixed-AGF (FAGF) by 3GPP in [TS23716]) 78 across deployed access networks based on Broadband Forum [TR101] and 79 [TR178]. 81 The transport encapsulation used needs to meet a variety of 82 requirements including the following: 84 - The ability to multiplex multiple logical connections (Protocol 85 Data Unit (PDU) Sessions as defined by 3GPP) within a VLAN 86 identified point to point logical circuit between a 5G-RG and an 87 FAGF. 89 - To allow unmodified legacy equipment in the data path to identify 90 the encapsulation and snoop specific fields in the payload. Some 91 access nodes in the data path between the 5G-RG and the FAGF 92 (Such as digital subscriber loop access multiplexers (DSLAMs) and 93 optical line terminations (OLTs)) currently snoop into packets 94 identified by specific Ethertypes to identify protocols such as 95 the point to point protocol over ethernet (PPPoE), IP, ARP, and 96 IGMP. This may be for the purpose of enhanced QoS, policing of 97 identifiers and other applications. Some deployments are 98 dependent upon this snooping. Such devices are able to do this 99 for PPPoE or IP over ethernet (IPoE) packet encodings but would 100 be unable to do so if a new encapsulation, or an existing 101 encapsulation using a new Ethertype, were used. 103 - To carry per packet 5G QoS information. 105 - Fixed access is very sensitive to the complexity of residential 106 gateways, therefore encapsulation overhead and efficiency is an 107 important consideration. 109 A modified [RFC2516] PPPoE data encapsulation (referred to as the 5G 110 WWC user plane Encapsulation or 5WE) can address these requirements. 111 Currently deployed access nodes do not police the VER, TYPE and CODE 112 fields of an RFC 2516 header, and only perform limited policing of 113 stateful functions with respect to the procedures documented in RFC 114 2516. Therefore, these fields may be repurposed to: 116 - Identify that the mode of operation for packets encapsulated in 117 such a fashion uses non-access stratum (NAS, a logical control 118 interface between user equipment (UE) and 5GC as specified by 119 3GPP) based 5G WWC session establishment and life cycle 120 maintenance procedures as documented in [TS23502][TS23716] instead 121 of legacy PPP/PPPoE session establishment procedures (i.e. PADI 122 discipline, LCP, NCP etc.). 124 - Permit the session ID field to be used to identify the 5G PDU 125 session the encapsulated packet is part of. 127 - Communicate per-packet 5G QoS Flow Identifier (QFI) and 128 Reflective QoS Indication (RQI) information from the 5GC to the 129 5G-RG. 131 This 5G specific repurposing of fields results in an encapsulation 132 uniquely applicable to the requirements for the communication of PDU 133 session traffic between the subscriber premises and the 5G system 134 over wireline networks. The 8 byte RFC 2516 data packet header is 135 also the most frugal of the encapsulations that are currently 136 supported by legacy access equipment that could be adapted to meet 137 these requirements. This encapsulation is not suitable for other 138 network environments, e.g., general use over the public Internet. 140 1.1. Requirements Language 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 142 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", 143 "MAY", and "OPTIONAL" in this document are to be interpreted as 144 described in BCP 14 [RFC2119] [RFC8174] when, and only when, they 145 appear in all capitals, as shown here. 147 1.2. Acronyms 149 This document uses the following acronyms: 151 3GPP 3rd Generation Partnership Project 152 5WE 5G WWC Encapsulation 153 5GC 5th Generation Core (network) 154 DSLAM Digital Subscriber Loop Access Multiplexer 155 FAGF Fixed Network Access Gateway Function 156 IPoE IP over Ethernet 157 NAS Non-Access Stratum 158 OLT Optical Line Termination 159 PDU Protocol Data Unit 160 PPPoE PPP over Ethernet 161 QFI QoS Flow Identifier 162 QoS Quality of Service 163 RG Residential Gateway 164 RQI Reflective QoS Indicator 165 WWC Wireless Wireline Convergence 167 2. Data Encapsulation Format 169 The Ethernet payload [IEEE802] for PPPoE [RFC2516] is indicated by 170 an Ethertype of 0x8864. The information following that Ethertype 171 uses a value of 2 in the VER field for the repurposing of the PPPoE 172 data encapsulation as the 5G WWC user plane encapsulation (5WE). The 173 5G WWC User Plane encapsulation is structured as follows: 175 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 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | VER | TYPE | QFI |R|0| SESSION_ID | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | LENGTH | PROTOCOL ID | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | DATA PAYLOAD ~ 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 184 The description of each field is as follows: 186 VER is the version. It MUST be set to 2. 188 TYPE is the message type. It MUST be set to 1. 190 QFI encodes the 3GPP 5G QoS Flow Identifier[TS38415] to be used 191 for mapping 5G QoS to IP DSCP/802.1 P-bits[IEEE802]. 193 R (short for RQI) encodes the one bit Reflective QoS Indicator. 195 0 indicates the bit(s) MUST be sent as zero and ignored on 196 receipt. 198 SESSION_ID is a 16-bit unsigned integer in network byte order. It 199 is used to distinguish different PDU sessions that are in the 200 VLAN delineated multiplex. 202 LENGTH is the length in bytes of the data payload including 203 the initial Protocol ID. It is 16 bits in network byte order. 205 PROTOCOL ID is the 16 bit identifier of the data payload type 206 encoded using values from the IANA PPP DLL protocol numbers 207 registry. (https://www.iana.org/assignments/ppp-numbers/ppp- 208 numbers.xhtml#ppp-numbers-2) 210 The following values are valid in this field for 5G 211 WWC use: 213 0x0021: IPv4 215 0x0031: Ethernet (referred to in PPP as "bridging") 217 0x0057: IPv6 219 DATA PAYLOAD is encoded as per the protocol ID. 221 3. Acknowledgements 223 This memo is a result of comprehensive discussions by the Broadband 224 Forum's Wireline Wireless Convergence Work Area. 225 The authors would also like to thank Joel Halpern and Dirk Von Hugo 226 for their detailed review of this draft. 228 4. Security Considerations 230 5G NAS procedures used for session life cycle maintenance employ 231 ciphering and integrity protection. They can be considered to be a 232 more secure session establishment discipline than existing RFC 2516 233 procedures, at least against man in the middle attacks. 235 The document's re-purposing of the RFC 2516 data encapsulation will 236 not circumvent existing anti-spoofing and other security procedures 237 in deployed equipment. The existing access equipment will be able to 238 identify fields that they normally process and police as per 239 existing RFC 2516 traffic. 241 Therefore, the security of a fixed access network using 5WE will be 242 equivalent or superior to current practice. 244 5. IANA Considerations 246 IANA is requested to create a registry on the Point-to-Point (PPP) 247 Protocol Field Assignments IANA Web page as follows: 249 Registry Name: PPP Over Ethernet Versions 250 Registration Procedure: Expert Review 251 References: [RFC2516] [this document] 253 VER Description Reference 254 ----- ----------------------------- ----------- 255 0 reserved [this document] 256 1 Classic PPPoE [RFC2516] 257 2 5G WWC User Plane Encapsulation [this document] 258 3-15 unassigned [this document] 260 IANA is requested to add [this document] as an additional reference 261 for Ethertype 0x8864 in the Ethertypes table on the IANA "IEEE 802 262 Numbers" web page.(https://www.iana.org/assignments/ieee-802- 263 numbers/ieee-802-numbers.xhtml#ieee-802-numbers-1) 265 6. References 267 6.1. Normative References 268 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 269 Requirement Levels", BCP 14, RFC 2119, March 1997. 270 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 271 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 272 May 2017, . 273 [RFC2516] "A Method for Transmitting PPP Over Ethernet (PPPoE)", 274 IETF RFC 2516, February 1999 275 [TS38415] 3rd Generation Partnership Project; Technical 276 Specification Group Radio Access Network; NG-RAN; PDU 277 Session User Plane Protocol (Release 15), 3GPP TS38.415 279 6.2. Informative References 280 [TS23502] 3rd Generation Partnership Project; Technical 281 Specification Group Services and System Aspects; 282 Procedures for the 5G System (Release 16), 3GPP TS23.502 283 [TS23716] 3rd Generation Partnership Project; Technical 284 Specification Group Services and System Aspects; Study 285 on the Wireless and Wireline Convergence for the 5G 286 system architecture (Release 16), 3GPP TR23.716, 287 November 2018 288 [TR101] "Migrating to Ethernet Based Broadband Aggregation", 289 Broadband Forum Technical Report: TR-101 issue 2, July 290 2011 291 [TR178] "Multi-service Broadband Network Architecture and Nodal 292 Requirements", Broadband Forum Technical Report: TR-178, 293 September 2014 294 [IEEE802] 802, IEEE, "IEEE Standard for Local and Metropolitan 295 Networks: Overview and Architecture", IEEE Std 802-2014. 296 [RFC4937] "IANA Considerations for PPPoE", IETF RFC 4937, June 297 2007 299 7. Authors' Addresses 300 Dave Allan (editor) 301 Ericsson 302 2455 Augustine Drive 303 San Jose, CA 95054 USA 304 Email: david.i.allan@ericsson.com 306 Donald E. Eastlake 3rd 307 Futurewei Technologies 308 2386 Panoramic Circle 309 Apopka, FL 32703 USA 310 Phone: +1-508-333-2270 311 Email: d3e3e3@gmail.com 313 David Woolley 314 Telstra Corporation 315 242 Exhibition St 316 Melbourne, 3000 317 Australia 318 Email: david.woolley@team.telstra.com