idnits 2.17.1 draft-allan-5g-fmc-encapsulation-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 (July 2019) is 1747 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'RFC2119' on line 132 -- Looks like a reference, but probably isn't: 'RFC2516' on line 233 == Unused Reference: '1' is defined on line 245, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 248, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 281, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 3 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: January 2020 David Woolley, Telstra 4 July 2019 6 5G Fixed Mobile Convergence User Plane Encapsulation 7 draft-allan-5g-fmc-encapsulation-00 9 Abstract 10 As part of providing wireline access to the 5G core, deployed 11 wireline networks carry user data between 5G residential gateways 12 and the 5G Access Gateway Function (AGF). The encapsulation used 13 needs to meet a variety of requirements including being able to 14 multiplex the traffic of multiple PDU sessions within a VLAN 15 delineated access circuit, to permit legacy equipment in the data 16 path to snoop certain packet fields, to carry 5G QoS information 17 associated with the data, and to be efficiently encoded. This memo 18 specifies an encapsulation that meets these requirements. 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 2020. 44 Copyright and License Notice 46 Copyright (c) 2019 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.....................................................3 64 2. Data Encapsulation Format......................................4 65 3. Acknowledgements...............................................5 66 4. Security Considerations........................................5 67 5. IANA Considerations............................................5 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 F-AGF in [5]) across deployed TR-101[6] 78 and TR-178[7] access networks. 80 The transport encapsulation used needs to meet a variety of 81 requirements including the following: 83 - The ability to multiplex multiple logical connections (PDU 84 sessions) within a VLAN identified p2p logical circuit between a 85 5G-RG and an F-AGF. 87 - To allow unmodified legacy equipment in the datapath to identify 88 the encapsulation and snoop specific fields in the payload. Some 89 access nodes in the data path between the 5G-RG and the F-AGF 90 (Such as DSLAMs and OLTs) currently snoop into packets identified 91 by specific ethertypes to identify protocols such as PPPoE, IP, 92 ARP and IGMP. This may be for the purpose of enhanced QoS, 93 policing of identifiers and other applications. Some deployments 94 are depended upon this snooping. Such devices are currently able 95 to do so for PPPoE or IPoE packet encodings but would be unable 96 to do so if a new encapsulation, or an existing encapsulation 97 using a new ethertype, were used. 99 - To carry per packet 5G QoS information. 101 - Fixed access is very sensitive to the complexity of residential 102 gateways, therefore encapsulation overhead and efficiency is an 103 important consideration. 105 A modified RFC 2516[3] PPPoE data encapsulation can address these 106 requirements. Currently deployed access nodes do not police the VER, 107 TYPE and CODE fields of an RFC 2516 header, and only perform limited 108 policing of stateful functions with respect to the procedures 109 documented in RFC 2516. Therefore these fields may be repurposed to: 111 - Identify that the mode of operation for packets encapsulated in 112 such a fashion uses control plane (NAS) based 5G FMC session 113 establishment and life cycle maintenance procedures as documented 114 in [4][5] instead of legacy PPP/PPPoE session establishment 115 procedures (i.e. PADI discipline, LCP, NCP etc.). 117 - Permit the session ID field to be used to identify the 5G PDU 118 session the encapsulated packet is part of. 120 - Communicate per-packet 5G QoS Flow Identifier (QFI) and Reverse 121 QoS Indication (RQI) information from the 5GC core to the 5G-RG. 123 The 8 byte RFC 2516 data packet header is the most frugal of the 124 encapsulations that are currently supported by legacy access 125 equipment that can also meet all the requirements. 127 1.1. Requirements Language 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in RFC 2119 [RFC2119]. 133 1.2. Acronyms 135 This document uses the following acronyms: 137 DSLAM Digital Subscriber Loop Access Multiplexer 138 F-AGF Fixed Network Access Gateway Function 139 FMC Fixed Mobile Convergence 140 IPoE IP over Ethernet 141 NAS Non-Access Stratum 142 OLT Optical Line Termination 143 PPPoE PPP over Ethernet 144 QFI QoS Flow Identifier 145 RG Residential Gateway 146 RQI Reverse QoS Indicator 148 2. Data Encapsulation Format 150 PPPoE data packet encapsulation is indicated in an IEEE 802[8] 151 Ethernet frame by an ethertype of 0x8864. The information following 152 that ethertype for the repurposing of the PPPoE data encapsulation 153 as the 5G FMC user plane encapsulation uses a value of 2 in the VER 154 field. The 5G FMC User Plane encapsulation is structured as follows: 156 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 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | VER | TYPE | QFI |R|0| SESSION_ID | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | LENGTH | PROTOCOL ID | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | DATA PAYLOAD ~ 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 165 The description of each field is as follows: 167 VER is the version. It MUST be set to 2. 169 TYPE is the message type. It MUST be set to 1. 171 QFI encodes the 3GPP 5G QoS Flow Identifier to be used for 172 mapping 173 5G QoS to IP DSCP/802.1 P-bits[9]. 175 R (short for RQI) encodes the one bit Reflective QoS Indicator 177 0 indicates the bit(s) MUST be set to zero 179 SESSION_ID is a 16-bit unsigned integer. It is used to 180 distinguish different PDU sessions that are in the VLAN 181 delineated multiplex. 183 LENGTH is the length in bytes of the data payload including 184 the initial Protocol ID. 186 PROTOCOL ID is the 16 bit identifier of the data payload type 187 encoded as per RFC 2516. The following values are valid in 188 this field for 5G FMC use: 190 0x0021: IPv4 192 0x0031: Ethernet (referred to in PPP as "bridging") 194 0x0057: IPv6 196 DATA PAYLOAD is encoded as per the protocol ID. 198 3. Acknowledgements 200 This memo is a result of comprehensive discussions by the Broadband 201 Forum"s Wireline Wireless Convergence Work Area. 203 The authors would also like to thank Joel Halpern for his detailed 204 review of this draft. 206 4. Security Considerations 208 5G NAS procedures used for session life cycle maintenance employ 209 ciphering and integrity protection therefore can be considered to be 210 a more secure session establishment discipline than existing RFC 211 2516 procedures, at least against man in the middle attacks. 213 The re-purposing of the RFC 2516 data encapsulation will not 214 circumvent existing anti-spoofing and other security procedures in 215 deployed equipment. The existing access equipment will be able to 216 identify fields that they normally process and police as per 217 existing RFC 2516 traffic. 219 Therefore the security of an access network will be equivalent or 220 superior to current practice. 222 5. IANA Considerations 224 IANA is requested to create a registry on the Point-to-Point (PPP) 225 Protocol Field Assignments IANA Web page as follows: 226 Registry Name: PPP Over Ethernet Versions 227 Registration Procedure: Expert Review 228 References: [RFC2516] [this document] 230 VER Description Reference 231 ----- ----------------------------- ----------- 232 0 reserved [this document] 233 1 Classic PPPoE [RFC2516] 234 2 5G FMC User Plane Encapsulation [this document] 235 3-15 unassigned [this document] 237 IANA is requested to add [this document] as an additional reference 238 for Ethertype 0x8864 in the Ethertypes table on the IANA "IEEE 802 239 Numbers" web page. 241 6. References 243 6.1. Normative References 245 [1] Bradner, S., "Key words for use in RFCs to Indicate 246 Requirement Levels", BCP 14, RFC 2119, March 1997. 248 [2] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 249 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 250 May 2017, . 252 [3] "A Method for Transmitting PPP Over Ethernet (PPPoE)", 253 IETF RFC 2516, February 1999 255 6.2. Informative References 257 [4] 3rd Generation Partnership Project; Technical 258 Specification Group Services and System Aspects; 259 Procedures for the 5G System (Release 16), 3GPP TS23.502 261 [5] 3rd Generation Partnership Project; Technical 262 Specification Group Services and System Aspects; Study on 263 the Wireless and Wireline Convergence for the 5G system 264 architecture (Release 16), 3GPP TR23.716, November 2018 266 [6] "Migrating to Ethernet Based Broadband Aggregation", 267 Broadband Forum Technical Report: TR-101 issue 2, July 268 2011 270 [7] "Multi-service Broadband Network Architecture and Nodal 271 Requirements", Broadband Forum Technical Report: TR-178, 272 September 2014 274 [8] 802, IEEE, "IEEE Standard for Local and Metropolitan 275 Networks: Overview and Architecture", IEEE Std 802-2014. 277 [9] 3rd Generation Partnership Project; Technical 278 Specification Group Radio Access Network; NG-RAN; PDU 279 Session User Plane Protocol (Release 15), 3GPP TS38.415 281 [10] "IANA Considerations for PPPoE", IETF RFC 4937, June 2007 283 7. Authors' Addresses 285 Dave Allan (editor) 286 Ericsson 287 2755 Augustine Drive 288 San Jose, CA 95054 USA 289 Email: david.i.allan@ericsson.com 291 Donald E. Eastlake 3rd 292 Futurewei Technologies 293 1424 Pro Shop Court 294 Davenport, FL 33896 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