5G Wireless Wireline Convergence User Plane Encapsulation (5WE)
draft-allan-5g-fmc-encapsulation-04
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 8822.
|
|
---|---|---|---|
Authors | David Allan , Donald E. Eastlake 3rd , David Woolley | ||
Last updated | 2020-07-17 (Latest revision 2020-05-04) | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Formats | |||
Reviews |
GENART Last Call review
(of
-07)
by Russ Housley
Almost ready
GENART Last Call review
by Russ Housley
Almost ready
TSVART Last Call review
by David Black
Ready w/issues
|
||
Stream | WG state | (None) | |
Document shepherd | Erik Kline | ||
Shepherd write-up | Show Last changed 2020-06-27 | ||
IESG | IESG state | Became RFC 8822 (Informational) | |
Consensus boilerplate | Unknown | ||
Telechat date | (None) | ||
Responsible AD | Erik Kline | ||
Send notices to | (None) | ||
IANA | IANA review state | IANA OK - Actions Needed |
draft-allan-5g-fmc-encapsulation-04
Internet Draft Dave Allan, Ericsson ed. Intended status: Informational Donald Eastlake, Futurewei Expires: September 2020 David Woolley, Telstra May 2020 5G Wireless Wireline Convergence User Plane Encapsulation (5WE) draft-allan-5g-fmc-encapsulation-04 Abstract 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 used needs to meet a variety of requirements including being able to multiplex the traffic of multiple PDU sessions within a VLAN delineated access circuit, to permit legacy equipment in the data path to snoop certain packet fields, to carry 5G QoS information associated with the data, and to be efficiently encoded. This memo specifies an encapsulation that meets these requirements. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents 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 of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 2020. Copyright and License Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. Allan et al., Expires November 2020 [Page 1] Internet-Draft draft-allan-5g-fmc-encapsulation May 2020 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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...................................................2 1.1. Requirements Language........................................3 1.2. Acronyms.....................................................3 2. Data Encapsulation Format......................................4 3. Acknowledgements...............................................5 4. Security Considerations........................................5 5. IANA Considerations............................................5 6. References.....................................................6 6.1. Normative References.........................................6 6.2. Informative References.......................................6 7. Authors' Addresses.............................................7 1. Introduction Converged 5G ("fifth generation") wireline networks carry user data between 5G residential gateways (5G-RG) and the 5G Access Gateway Function (identified as an Fixed-AGF (FAGF) by 3GPP in [5]) across deployed access networks based on BBF TR-101[6] and TR-178[7]. The transport encapsulation used needs to meet a variety of requirements including the following: - The ability to multiplex multiple logical connections (Protocol Data Unit (PDU) Sessions as defined by 3GPP) within a VLAN identified p2p logical circuit between a 5G-RG and an FAGF. - To allow unmodified legacy equipment in the data path to identify the encapsulation and snoop specific fields in the payload. Some access nodes in the data path between the 5G-RG and the FAGF (Such as DSLAMs and OLTs) currently snoop into packets identified by specific Ethertypes to identify protocols such as PPPoE, IP, ARP, and IGMP. This may be for the purpose of enhanced QoS, policing of identifiers and other applications. Some deployments are dependent upon this snooping. Such devices are able to do this for PPPoE or IPoE packet encodings but would be unable to do Allan et al., Expires November 2020 [Page 2] Internet-Draft draft-allan-5g-fmc-encapsulation May 2020 so if a new encapsulation, or an existing encapsulation using a new Ethertype, were used. - To carry per packet 5G QoS information. - Fixed access is very sensitive to the complexity of residential gateways, therefore encapsulation overhead and efficiency is an important consideration. A modified RFC 2516[3] PPPoE data encapsulation (referred to as the 5G WWC user plane Encapsulation or 5WE) can address these requirements. Currently deployed access nodes do not police the VER, TYPE and CODE fields of an RFC 2516 header, and only perform limited policing of stateful functions with respect to the procedures documented in RFC 2516. Therefore, these fields may be repurposed to: - Identify that the mode of operation for packets encapsulated in such a fashion uses non-access stratum (NAS, a logical control interface between UE and 5GC as specified by 3GPP) based 5G WWC session establishment and life cycle maintenance procedures as documented in [4][5] instead of legacy PPP/PPPoE session establishment procedures (i.e. PADI discipline, LCP, NCP etc.). - 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. The 8 byte RFC 2516 data packet header is the most frugal of the encapsulations that are currently supported by legacy access equipment that can also meet all the requirements. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [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 Allan et al., Expires November 2020 [Page 3] Internet-Draft draft-allan-5g-fmc-encapsulation May 2020 5WE 5G WWC Encapsulation 5GC 5th Generation Core (network) DSLAM Digital Subscriber Loop Access Multiplexer FAGF Fixed Network 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 PPPoE data packet encapsulation is indicated in an IEEE 802[8] Ethernet frame 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 WWC User 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 the version. It MUST be set to 2. TYPE is the message type. It MUST be set to 1. QFI encodes the 3GPP 5G QoS Flow Identifier to be used for mapping 5G QoS to IP DSCP/802.1 P-bits[9]. R (short for RQI) encodes the one bit Reflective QoS Indicator. 0 indicates the bit(s) MUST be sent as zero and ignored on receipt. Allan et al., Expires November 2020 [Page 4] Internet-Draft draft-allan-5g-fmc-encapsulation May 2020 SESSION_ID is a 16-bit unsigned integer in network byte order. It is used to distinguish different PDU sessions that are in the VLAN delineated multiplex. LENGTH is the length in bytes of the data payload including the initial Protocol ID. It is 16 bits in network byte order. PROTOCOL ID is the 16 bit identifier of the data payload type encoded using values from the IANA PPP DLL protocol numbers registry. The following values are valid in this field for 5G WWC use: 0x0021: IPv4 0x0031: Ethernet (referred to in PPP as "bridging") 0x0057: IPv6 DATA PAYLOAD is encoded as per the protocol ID. 3. 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 this draft. 4. Security Considerations 5G NAS procedures used for session life cycle maintenance employ ciphering and integrity protection. They can be considered to be a more secure session establishment discipline than existing RFC 2516 procedures, at least against man in the middle attacks. The document"s re-purposing of the RFC 2516 data 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 and police as per existing RFC 2516 traffic. Therefore, the security of a fixed access network using 5WE will be equivalent or superior to current practice. 5. IANA Considerations IANA is requested to create a registry on the Point-to-Point (PPP) Protocol Field Assignments IANA Web page as follows: Allan et al., Expires November 2020 [Page 5] Internet-Draft draft-allan-5g-fmc-encapsulation May 2020 Registry Name: PPP Over Ethernet Versions Registration Procedure: Expert Review References: [RFC2516] [this document] VER Description Reference ----- ----------------------------- ----------- 0 reserved [this document] 1 Classic PPPoE [RFC2516] 2 5G WWC User Plane Encapsulation [this document] 3-15 unassigned [this document] IANA is requested to add [this document] as an additional reference for Ethertype 0x8864 in the Ethertypes table on the IANA "IEEE 802 Numbers" web page. 6. References 6.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] 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>. [3] "A Method for Transmitting PPP Over Ethernet (PPPoE)", IETF RFC 2516, February 1999 6.2. Informative References [4] 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Procedures for the 5G System (Release 16), 3GPP TS23.502 [5] 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Study on the Wireless and Wireline Convergence for the 5G system architecture (Release 16), 3GPP TR23.716, November 2018 [6] "Migrating to Ethernet Based Broadband Aggregation", Broadband Forum Technical Report: TR-101 issue 2, July 2011 [7] "Multi-service Broadband Network Architecture and Nodal Requirements", Broadband Forum Technical Report: TR-178, September 2014 [8] 802, IEEE, "IEEE Standard for Local and Metropolitan Networks: Overview and Architecture", IEEE Std 802-2014. [9] 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; NG-RAN; PDU Session User Plane Protocol (Release 15), 3GPP TS38.415 [10] "IANA Considerations for PPPoE", IETF RFC 4937, June 2007 Allan et al., Expires November 2020 [Page 6] Internet-Draft draft-allan-5g-fmc-encapsulation May 2020 7. Authors' Addresses Dave Allan (editor) Ericsson 2455 Augustine Drive San Jose, CA 95054 USA Email: david.i.allan@ericsson.com Donald E. Eastlake 3rd Futurewei Technologies 2386 Panoramic Circle Apopka, FL 32703 USA Phone: +1-508-333-2270 Email: d3e3e3@gmail.com David Woolley Telstra Corporation 242 Exhibition St Melbourne, 3000 Australia Email: david.woolley@team.telstra.com Allan et al., Expires November 2020 [Page 7]