idnits 2.17.1 draft-allan-5g-fmc-encapsulation-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 2020) is 1532 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'RFC2119' on line 138 -- Looks like a reference, but probably isn't: 'RFC8174' on line 138 -- Looks like a reference, but probably isn't: 'RFC2516' on line 244 == Unused Reference: '1' is defined on line 255, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 257, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 282, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). 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 2020 David Woolley, Telstra 4 February 2020 6 5G Fixed Mobile Convergence User Plane Encapsulation (5FE) 7 draft-allan-5g-fmc-encapsulation-02 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 used 14 needs to meet a variety of requirements including being able to 15 multiplex the traffic of multiple PDU sessions within a VLAN 16 delineated access circuit, to permit legacy equipment in the data 17 path to snoop certain packet fields, to carry 5G QoS information 18 associated with the data, and to be efficiently encoded. This memo 19 specifies an encapsulation that meets these requirements. 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 August 2020. 45 Copyright and License Notice 47 Copyright (c) 2020 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........................................3 64 1.2. Acronyms.....................................................3 65 2. Data Encapsulation Format......................................4 66 3. Acknowledgements...............................................5 67 4. Security Considerations........................................5 68 5. IANA Considerations............................................5 69 6. References.....................................................6 70 6.1. Normative References.........................................6 71 6.2. Informative References.......................................6 72 7. Authors' Addresses.............................................7 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 an Fixed-AGF (FAGF) by 3GPP in [5]) across 79 deployed access networks based on BBF TR-101[6] and TR-178[7]. 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 p2p logical circuit between a 5G-RG and an FAGF. 88 - To allow unmodified legacy equipment in the data path to identify 89 the encapsulation and snoop specific fields in the payload. Some 90 access nodes in the data path between the 5G-RG and the FAGF 91 (Such as DSLAMs and OLTs) currently snoop into packets identified 92 by specific Ethertypes to identify protocols such as PPPoE, IP, 93 ARP, and IGMP. This may be for the purpose of enhanced QoS, 94 policing of identifiers and other applications. Some deployments 95 are depended upon this snooping. Such devices are currently able 96 to do so for PPPoE or IPoE packet encodings but would be unable 97 to do so if a new encapsulation, or an existing encapsulation 98 using a new Ethertype, were used. 100 - To carry per packet 5G QoS information. 102 - Fixed access is very sensitive to the complexity of residential 103 gateways, therefore encapsulation overhead and efficiency is an 104 important consideration. 106 A modified RFC 2516[3] PPPoE data encapsulation (referred to as the 107 5G FMC user plane Encapsulation or 5FE) can address these 108 requirements. Currently deployed access nodes do not police the VER, 109 TYPE and CODE fields of an RFC 2516 header, and only perform limited 110 policing of stateful functions with respect to the procedures 111 documented in RFC 2516. Therefore, these fields may be repurposed 112 to: 114 - Identify that the mode of operation for packets encapsulated in 115 such a fashion uses non-access stratum(NAS, a logical control 116 interface between UE and 5GC as specified by 3GPP) based 5G FMC 117 session establishment and life cycle maintenance procedures as 118 documented in [4][5] instead of legacy PPP/PPPoE session 119 establishment procedures (i.e. PADI discipline, LCP, NCP etc.). 121 - Permit the session ID field to be used to identify the 5G PDU 122 session the encapsulated packet is part of. 124 - Communicate per-packet 5G QoS Flow Identifier (QFI) and 125 Reflective QoS Indication (RQI) information from the 5GC to the 126 5G-RG. 128 The 8 byte RFC 2516 data packet header is the most frugal of the 129 encapsulations that are currently supported by legacy access 130 equipment that can also meet all the requirements. 132 1.1. Requirements Language 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in [RFC2119] [RFC8174] 137 when, and only when, they appear in all capitals, as shown here. 139 1.2. Acronyms 141 This document uses the following acronyms: 143 3GPP 3rd Generation Partnership Project 144 5FE 5G FMC Encapsulation 145 5GC 5th Generation Core (network) 146 DSLAM Digital Subscriber Loop Access Multiplexer 147 FAGF Fixed Network Access Gateway Function 148 FMC Fixed Mobile Convergence 149 IPoE IP over Ethernet 150 NAS Non-Access Stratum 151 OLT Optical Line Termination 152 PDU Protocol Data Unit 153 PPPoE PPP over Ethernet 154 QFI QoS Flow Identifier 155 QoS Quality of Service 156 RG Residential Gateway 157 RQI Reflective QoS Indicator 159 2. Data Encapsulation Format 161 PPPoE data packet encapsulation is indicated in an IEEE 802[8] 162 Ethernet frame by an Ethertype of 0x8864. The information following 163 that Ethertype uses a value of 2 in the VER field for the 164 repurposing of the PPPoE data encapsulation as the 5G FMC user plane 165 encapsulation (5FE). The 5G FMC User Plane encapsulation is 166 structured as follows: 168 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 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | VER | TYPE | QFI |R|0| SESSION_ID | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | LENGTH | PROTOCOL ID | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | DATA PAYLOAD ~ 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 177 The description of each field is as follows: 179 VER is the version. It MUST be set to 2. 181 TYPE is the message type. It MUST be set to 1. 183 QFI encodes the 3GPP 5G QoS Flow Identifier to be used for 184 mapping 5G QoS to IP DSCP/802.1 P-bits[9]. 186 R (short for RQI) encodes the one bit Reflective QoS Indicator. 188 0 indicates the bit(s) MUST be sent as zero and ignored on 189 receipt. 191 SESSION_ID is a 16-bit unsigned integer. It is used to 192 distinguish different PDU sessions that are in the VLAN 193 delineated multiplex. 195 LENGTH is the length in bytes of the data payload including 196 the initial Protocol ID. 198 PROTOCOL ID is the 16 bit identifier of the data payload type 199 encoded as per RFC 2516. The following values are valid in 200 this field for 5G FMC use: 202 0x0021: IPv4 204 0x0031: Ethernet (referred to in PPP as "bridging") 206 0x0057: IPv6 208 DATA PAYLOAD is encoded as per the protocol ID. 210 3. Acknowledgements 212 This memo is a result of comprehensive discussions by the Broadband 213 Forum"s Wireline Wireless Convergence Work Area. 214 The authors would also like to thank Joel Halpern and Dirk Von Hugo 215 for their detailed review of this draft. 217 4. Security Considerations 219 5G NAS procedures used for session life cycle maintenance employ 220 ciphering and integrity protection. They can be considered to be a 221 more secure session establishment discipline than existing RFC 2516 222 procedures, at least against man in the middle attacks. 223 The document"s re-purposing of the RFC 2516 data encapsulation will 224 not circumvent existing anti-spoofing and other security procedures 225 in deployed equipment. The existing access equipment will be able to 226 identify fields that they normally process and police as per 227 existing RFC 2516 traffic. 229 Therefore, the security of a fixed access network using 5FE will be 230 equivalent or superior to current practice. 232 5. IANA Considerations 234 IANA is requested to create a registry on the Point-to-Point (PPP) 235 Protocol Field Assignments IANA Web page as follows: 237 Registry Name: PPP Over Ethernet Versions 238 Registration Procedure: Expert Review 239 References: [RFC2516] [this document] 241 VER Description Reference 242 ----- ----------------------------- ----------- 243 0 reserved [this document] 244 1 Classic PPPoE [RFC2516] 245 2 5G FMC User Plane Encapsulation [this document] 246 3-15 unassigned [this document] 248 IANA is requested to add [this document] as an additional reference 249 for Ethertype 0x8864 in the Ethertypes table on the IANA "IEEE 802 250 Numbers" web page. 252 6. References 254 6.1. Normative References 255 [1] Bradner, S., "Key words for use in RFCs to Indicate 256 Requirement Levels", BCP 14, RFC 2119, March 1997. 257 [2] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 258 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 259 May 2017, . 260 [3] "A Method for Transmitting PPP Over Ethernet (PPPoE)", 261 IETF RFC 2516, February 1999 263 6.2. Informative References 264 [4] 3rd Generation Partnership Project; Technical 265 Specification Group Services and System Aspects; 266 Procedures for the 5G System (Release 16), 3GPP TS23.502 267 [5] 3rd Generation Partnership Project; Technical 268 Specification Group Services and System Aspects; Study on 269 the Wireless and Wireline Convergence for the 5G system 270 architecture (Release 16), 3GPP TR23.716, November 2018 271 [6] "Migrating to Ethernet Based Broadband Aggregation", 272 Broadband Forum Technical Report: TR-101 issue 2, July 273 2011 274 [7] "Multi-service Broadband Network Architecture and Nodal 275 Requirements", Broadband Forum Technical Report: TR-178, 276 September 2014 277 [8] 802, IEEE, "IEEE Standard for Local and Metropolitan 278 Networks: Overview and Architecture", IEEE Std 802-2014. 279 [9] 3rd Generation Partnership Project; Technical 280 Specification Group Radio Access Network; NG-RAN; PDU 281 Session User Plane Protocol (Release 15), 3GPP TS38.415 282 [10] "IANA Considerations for PPPoE", IETF RFC 4937, June 2007 284 7. Authors' Addresses 285 Dave Allan (editor) 286 Ericsson 287 2455 Augustine Drive 288 San Jose, CA 95054 USA 289 Email: david.i.allan@ericsson.com 291 Donald E. Eastlake 3rd 292 Futurewei Technologies 293 2386 Panoramic Circle 294 Apopka, FL 32703 USA 295 Phone: +1-508-333-2270 296 Email: d3e3e3@gmail.com 298 David Woolley 299 Telstra Corporation 300 242 Exhibition St 301 Melbourne, 3000 302 Australia 303 Email: david.woolley@team.telstra.com