InternetDraft DaveEngineering Task Force (IETF) D. Allan, Ed. Request for Comments: 8822 Ericssoned. Intended status:Category: InformationalDonald Eastlake,D. Eastlake 3rd ISSN: 2070-1721 FutureweiExpires: August 2021 David Woolley,Technologies D. Woolley TelstraFebruaryCorporation April 2021 5G Wireless Wireline Convergence User Plane Encapsulation (5WE)draft-allan-5g-fmc-encapsulation-08Abstract As part of providing wireline access to the 5G Core (5GC), deployed wireline networks carry user data between 5G residential gateways and the 5G Access Gateway Function (AGF). The encapsulation method specified in this document supports the multiplexing of traffic for multiple PDU sessions within aVLAN delineatedVLAN-delineated access circuit, permits legacy equipment in the data path to inspect certain packet fields, carries 5G QoS information associated with the packet data, and provides efficient encoding. It achieves this by specific points of similarity with theRFC 2516 PPPoEPoint-to-Point Protocol over Ethernet (PPPoE) data packetencapsulation.encapsulation (RFC 2516). Status ofthisThis Memo ThisInternet-Draftdocument issubmitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documentsnot an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force(IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum(IETF). It represents the consensus ofsix monthsthe IETF community. It has received public review andmay be updated, replaced, or obsoletedhas been approved for publication byotherthe Internet Engineering Steering Group (IESG). Not all documentsatapproved by the IESG are candidates for anytime. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress". The listlevel of Internet Standard; see Section 2 of RFC 7841. Information about the currentInternet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The liststatus ofInternet-Draft Shadow Directories canthis document, any errata, and how to provide feedback on it may beaccessedobtained athttp://www.ietf.org/shadow.html. This Internet-Draft will expire on January 2021.https://www.rfc-editor.org/info/rfc8822. Copyrightand LicenseNotice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents(http://trustee.ietf.org/license-info)(https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1.Introduction...................................................2Introduction 1.1. RequirementsLanguage........................................4Language 1.2.Acronyms.....................................................4Acronyms 2. Data EncapsulationFormat......................................5Format 3.Acknowledgements...............................................6 4.SecurityConsiderations........................................6 5.Considerations 4. IANAConsiderations............................................7 6. References.....................................................7 6.1.Considerations 5. References 5.1. NormativeReferences.........................................7 6.2.References 5.2. InformativeReferences.......................................8 7.References Acknowledgements Authors'Addresses.............................................8Addresses 1. Introduction Converged 5G ("fifth generation") wireline networks carry user data between 5G residential gateways(5G-RG)(5G-RGs) and the 5G Access Gateway Function (identified as a Wireline-AGF (W-AGF) by 3GPP in [TS23316]) across deployed access networks based on Broadband Forum [TR101] and [TR178]. This form of wireline access is considered to be trusted non-3GPP access by the 5G system. The transport encapsulation used needs to meet a variety ofrequirementsrequirements, including the following:-* The ability to multiplex multiple logical connections (Protocol Data Unit (PDU)Sessionssessions as defined by 3GPP) within aVLANVLAN- identifiedpoint to pointpoint-to-point logical circuit between a 5G-RG and aW- AGF. -W-AGF. * To allow unmodified legacy equipment in the data path to identify the encapsulation and inspect specific fields in the payload. Some access nodes in the data path between the 5G-RG and theW- AGF (SuchW-AGF (such as digital subscriber loop access multiplexers (DSLAMs) and optical line terminations (OLTs)) currently inspect packets identified by specific Ethertypes to identify protocols such as thepoint to point protocolPoint-to-Point Protocol overethernetEthernet (PPPoE), IP, ARP, and IGMP. This may be for the purpose of enhanced QoS, the policing ofidentifiersidentifiers, and other applications. Some deployments are dependent upon this inspection. Such devices are able to do this for PPPoE orIP over ethernetIP-over-Ethernet (IPoE) packet encodings but would be unable to do so if a completely new encapsulation, or an existing encapsulation using a new Ethertype, were used.-* To carryper packetper-packet 5G QoS information.- Fixed* An encapsulation that minimizes processing since fixed access residential gateways are sensitive to the complexity of packetprocessing, therefore an encapsulation that minimizes processingprocessing. While not a strict requirement, this is an important consideration. A data encapsulation that uses a common Ethertype and has certain fields appearing at the same offset as the PPPoE[RFC2516]data encapsulation [RFC2516] can address these requirements. This data encapsulation is referred to as the 5G WWC user planeEncapsulationencapsulation or 5WE. Currently deployed access nodes do not police the VER,TYPE andTYPE, or CODE fields of an RFC 2516header,PPPoE header and only perform limited policing of stateful functions with respect to the procedures documented in RFC 2516. Therefore, these fields have a different definition for 5WE and are used to:-* Identify that the mode of operation for packets encapsulated in such a fashion usesnon-access5G WWC session establishment based on non- access stratum (NAS, a logical control interface between user equipment (UE) and5GCa 5th Generation Core Network (5GC) as specified by 3GPP)based 5G WWC session establishmentandlife cyclelife-cycle maintenance procedures as documented in[TS23502][TS23316][TS23502] and [TS23316] instead of legacy PPP/PPPoE session establishment procedures(i.e.[RFC2516] (i.e., PADI discipline, LCP,NCPNCP, etc.). In thisscenarioscenario, "discovery" is performed by means outside the scope of this document.-* Permit the session ID field to be used to identify the 5G PDU session the encapsulated packet is part of.-* Communicate per-packet 5G QoS Flow Identifier (QFI) and Reflective QoS Indication (RQI) information from the 5GC to the 5G-RG. This5G specific5G-specific redesign of fields not inspected by deployed equipment results in an encapsulation uniquely applicable to the requirements for the communication of PDU session traffic between the subscriber premises and the 5G system over wireline networks. The6 byte6-byte RFC 2516 data packet header followed by a2 byte2-byte PPP protocol ID is also the most frugal of the encapsulations that are currently supported by legacy access equipment that could be adapted to meet these requirements. This encapsulation is expected to be used in environments where RFC 2516 is deployed. Therefore, implementations MUST examine the version number:- if* If the version number is1,1 and PPPoE [RFC2516] is supported, process the framefurther, elsefurther; else, silently discard it.- if* If the version number is 2 and 5WE is supported, process the framefurther, elsefurther; else, silently discard it. In bothcasescases, frames for the supported version number should have session IDs corresponding to established sessions for the respective protocol models. A 5WE frame with an unrecognized session ID MUST be silently discarded. This encapsulation may have MTU issues when used for Ethernet multiplexing in networks where the underlying Ethernet payload is limited to 1500 bytes. This encapsulation is not suitable for other network environments, e.g., general use over the public Internet. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.2. Acronyms This document uses the following acronyms: 3GPP 3rd Generation Partnership Project 5WE 5GWWCWireless Wireline Convergence User Plane Encapsulation 5GC 5th Generation Core (network) DSLAM Digital Subscriber Loop Access Multiplexer W-AGF Wireline Access Gateway Function IPoE IP over Ethernet NAS Non-Access Stratum OLT Optical Line Termination PDU Protocol Data Unit PPPoE PPP over Ethernet QFI QoS Flow Identifier QoS Quality of Service RG Residential Gateway RQI Reflective QoS Indicator WWC Wireless Wireline Convergence 2. Data Encapsulation Format The Ethernet payload [IEEE802] for PPPoE [RFC2516] is indicated by an Ethertype of 0x8864. The information following that Ethertype uses a value of 2 in the VER field for the repurposing of the PPPoE data encapsulation as the 5G WWC user plane encapsulation (5WE). The 5G WWCUser Planeuser plane encapsulation is structured as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VER | TYPE | QFI |R|0| SESSION_ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LENGTH | PROTOCOL ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DATA PAYLOAD ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- The description of each field is as follows:VER is theVER: The version. It MUST be set to 0x02.TYPE is theTYPE: The message type. It MUST be set to 0x01.QFI encodesQFI: Encodes the 3GPP 5G QoS Flow Identifier [TS38415] to be used for mapping 5G QoS to IP DSCP/802.1 P-bits [IEEE802].R (shortR: (Short for Reflective QoS Indication [TS38415])encodesEncodes theone bitone-bit RQI. It is set by thenetwork sidenetwork-side 5WE termination for downstream traffic and ignored by the network for upstream traffic.0 indicates0: Indicates the bit(s) that MUST be sent as zero and ignored on receipt.SESSION_ID is aSESSION_ID: A 16-bit unsigned integer in network byte order. It is used to distinguish different PDU sessions that are in theVLAN delineatedVLAN-delineated multiplex. A value of 0xffff is reserved for future use and MUST NOT be used.LENGTH is theLENGTH: The length in bytes of the datapayloadpayload, including the initial Protocol ID. It is 16 bits in network byte order. PROTOCOLID is the 16 bitID: The 16-bit identifier of the data payload type encoded using values from the IANAPPP"PPP DLLprotocol numbers registry. (https://www.iana.org/assignments/ppp-numbers/ppp- numbers.xhtml#ppp-numbers-2)Protocol Numbers" registry <https://www.iana.org/assignments/ppp-numbers>. The following values are valid in this field for 5G WWC use: * 0x0021: IPv4 * 0x0031:Ethernet (referred to in PPP as "bridging")Bridging PDU (Ethernet) * 0x0057: IPv6 Packets received that do not contain one of the above protocol IDs are silently discarded. DATAPAYLOAD is encodedPAYLOAD: Encoded as per the protocol ID.4.3. Security Considerations 5G NAS procedures used for sessionlife cyclelife-cycle maintenance employ ciphering and integrity protection [TS23502]. They can be consideredto bea more secure session establishment discipline than existing RFC 2516 procedures, at least againston pathon-path attackers. The design of the 5WE encapsulation will not circumvent existing anti-spoofing and other security procedures in deployed equipment. The existing access equipment will be able to identify fields that they normally process andpolicedpolice as per existing RFC 2516 traffic. Therefore, the security of a fixed access network using 5WE will be equivalent or superior to current practice.5WE encapsulated5WE-encapsulated traffic is used on what the 5GC considers to be trusted non-3GPPinterfaces, thereforeinterfaces; therefore, it is not ciphered. 5WE is not suitable for use over an untrusted non-3GPP interface. The security requirements of the 5G system are documented in[TS33501] 5.[TS33501]. 4. IANA Considerations IANAis requested to create ahas created the following registry on thePoint-to-Point"Point-to-Point (PPP) Protocol FieldAssignments IANA Web page as follows:Assignments" page: Registry Name: PPP Over Ethernet Versions Registration Procedure: Specification Required References: [RFC2516] [this document] +======+=================================+=================+ | VER | Description | Reference----- ----------------------------- -----------| +======+=================================+=================+ | 0reserved| Reserved | [this document] | +------+---------------------------------+-----------------+ | 1 | PPPoE | [RFC2516] | +------+---------------------------------+-----------------+ | 2 | 5G WWC User Plane Encapsulation | [this document] | +------+---------------------------------+-----------------+ | 3-15 | unassigned[this document]| | +------+---------------------------------+-----------------+ Table 1: PPP Over Ethernet Versions IANAis requested to add [this document]has added this document as an additional reference for Ethertype 0x8864 in theEthertypes table"Ether Types" registry on the IANA "IEEE 802 Numbers"web page.(https://www.iana.org/assignments/ieee-802- numbers/ieee-802-numbers.xhtml#ieee-802-numbers-1) 6.page <https://www.iana.org/assignments/ieee-802-numbers>. 5. References6.1.5.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March1997.1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., and R. Wheeler, "A Method for Transmitting PPP Over Ethernet (PPPoE)", RFC 2516, DOI 10.17487/RFC2516, February 1999, <https://www.rfc-editor.org/info/rfc2516>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.[RFC2516] "A Method for Transmitting PPP Over Ethernet (PPPoE)", IETF RFC 2516, February 1999 [TS38415] 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; NG-RAN; PDU Session User Plane Protocol (Release 15), 3GPP TS38.415 [TS23502] 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Procedures for the 5G System (Release 16), 3GPP TS23.502[TS23316]3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Wireless3GPP, "Wireless and wireline convergence access support for the 5G System(5GS) (Release 16), 3GPP TS23.316, November 2018 6.2.(5GS)", Release 16, TS 23.316, December 2018. [TS23502] 3GPP, "Procedures for the 5G System (5GS)", Release 15, TS 23.502, December 2016. [TS38415] 3GPP, "NG-RAN; PDU session user plane protocol", Release 15, TS 38.415, March 2018. 5.2. Informative References [IEEE802] IEEE, "IEEE Standard for Local and Metropolitan Networks: Overview and Architecture", Std 802-2014, DOI 10.1109/IEEESTD.2014.6847097, June 2014, <https://doi.org/10.1109/IEEESTD.2014.6847097>. [TR101] Broadband Forum, "Migration to Ethernet Based Broadband Aggregation",Broadband Forum Technical Report: TR-101TR-101, issue 2, July20112011. [TR178] Broadband Forum, "Multi-service Broadband Network Architecture and Nodal Requirements",Broadband Forum Technical Report:TR-178, issue 1, September2014 [IEEE802] 802, IEEE, "IEEE Standard for Local and Metropolitan Networks: Overview and Architecture", IEEE Std 802-2014.2014. [TS33501]3rd Generation Partnership Project; Technical Specification Group Services3GPP, "Security architecture andSystem Aspects; Security Architecture and Proceduresprocedures for 5GSystem (Release 16), 3GPP TS33.501,System", Release 16, TS 33.501, December2019 3.2019. Acknowledgements This memo is a result of comprehensive discussions by the Broadband Forum's Wireline Wireless Convergence Work Area. The authors would also like to thank Joel Halpern and Dirk Von Hugo for their detailed review of thisdraft. 7.document. Authors' Addresses Dave Allan (editor) Ericsson 2455 Augustine Drive San Jose, CA 95054USAUnited States of America Email: david.i.allan@ericsson.com Donald E. Eastlake 3rd Futurewei Technologies 2386 Panoramic Circle Apopka, FL 32703USAUnited States of America Phone: +1-508-333-2270 Email: d3e3e3@gmail.com David Woolley Telstra Corporation 242 Exhibition StMelbourne,Melbourne 3000 Australia Email: david.woolley@team.telstra.com