Skip to main content

5G Wireless Wireline Convergence User Plane Encapsulation (5WE)
draft-allan-5g-fmc-encapsulation-08

The information below is for an old version of the document that is already published as an RFC.
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 2021-04-17 (Latest revision 2021-02-09)
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Informational
Formats
Reviews
Stream WG state (None)
Document shepherd Barbara Stark
Shepherd write-up Show Last changed 2020-10-01
IESG IESG state Became RFC 8822 (Informational)
Action Holders
(None)
Consensus boilerplate Yes
Telechat date (None)
Responsible AD Erik Kline
Send notices to bs7652@att.com
IANA IANA review state IANA OK - Actions Needed
IANA action state RFC-Ed-Ack
IANA expert review state Expert Reviews OK
draft-allan-5g-fmc-encapsulation-08
Internet Draft                                 Dave Allan, Ericsson ed.          
Intended status: Informational               Donald Eastlake, Futurewei         
Expires: August 2021                             David Woolley, Telstra 
                                                          February 2021 
             
 
    5G Wireless Wireline Convergence User Plane Encapsulation (5WE) 
                  draft-allan-5g-fmc-encapsulation-08 
 
 
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 method  
   specified in this document supports the multiplexing of traffic for 
   multiple PDU sessions within a VLAN 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 the RFC 2516 PPPoE data packet encapsulation. 
    
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 January 2021. 
    
Copyright and License Notice 
    
   Copyright (c) 2021 IETF Trust and the persons identified as the 
   document authors.  All rights reserved. 
    

 
Allan et al.,            Expires August 2021                   [Page 1] 
 

Internet-Draft     draft-allan-5g-fmc-encapsulation       February 2021 
 

   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........................................4 
   1.2. Acronyms.....................................................4 
   2. Data Encapsulation Format......................................5 
   3. Acknowledgements...............................................6 
   4. Security Considerations........................................6 
   5. IANA Considerations............................................7 
   6. References.....................................................7 
   6.1. Normative References.........................................7 
   6.2. Informative References.......................................8 
   7. Authors' Addresses.............................................8 
    
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 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 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 point to point logical circuit between a 5G-RG and a 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 the W-
      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 

 
Allan et al.,             Expires April 2021                   [Page 2] 
 

Internet-Draft     draft-allan-5g-fmc-encapsulation       February 2021 
 

      the point to point protocol over ethernet (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 inspection. Such devices are able to do this 
      for PPPoE or IP 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 carry per packet 5G QoS information.  
    
   -  Fixed access residential gateways are sensitive to the complexity 
     of packet processing, therefore an encapsulation that minimizes 
     processing 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 can address these requirements. This data 
   encapsulation is referred to as the 5G WWC user plane Encapsulation 
   or 5WE. 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 have a different 
   definition for 5WE and are used to: 
       
   -  Identify that the mode of operation for packets encapsulated in 
     such a fashion uses non-access stratum (NAS, a logical control 
     interface between user equipment (UE) and 5GC as specified by 
     3GPP) based 5G WWC session establishment and life cycle 
     maintenance procedures as documented in [TS23502][TS23316] instead 
     of legacy PPP/PPPoE session establishment procedures (i.e. PADI 
     discipline, LCP, NCP etc.). In this scenario "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. 
      
   This 5G 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.  
   The 6 byte RFC 2516 data packet header followed by a 2 byte PPP 
   protocol ID is also the most frugal of the encapsulations that are 

 
Allan et al.,             Expires April 2021                   [Page 3] 
 

Internet-Draft     draft-allan-5g-fmc-encapsulation       February 2021 
 

   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 the version number is 1, and PPPoE [RFC2516] is supported,    
     process the frame further, else silently discard it. 
    
   - if the version number is 2 and 5WE is supported, process the frame  
     further, else silently discard it. 
    
   In both cases 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   5G WWC 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 
 
Allan et al.,             Expires April 2021                   [Page 4] 
 

Internet-Draft     draft-allan-5g-fmc-encapsulation       February 2021 
 

   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 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 0x02. 
 
      TYPE is the message type. It MUST be set to 0x01.    
    
      QFI encodes the 3GPP 5G QoS Flow Identifier [TS38415] to be used  
          for mapping 5G QoS to IP DSCP/802.1 P-bits [IEEE802]. 
    
      R (short for Reflective QoS Indication [TS38415]) encodes the one  
          bit RQI. It is set by the network side 5WE termination for  
          downstream traffic and ignored by the network for upstream  
          traffic. 
    
      0 indicates the bit(s) MUST be sent as zero and ignored on  
          receipt. 
    
      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. A value of 0xffff is reserved for     
          future use and MUST NOT be used. 
    
      LENGTH is the length in bytes of the data payload including 

 
Allan et al.,             Expires April 2021                   [Page 5] 
 

Internet-Draft     draft-allan-5g-fmc-encapsulation       February 2021 
 

          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. (https://www.iana.org/assignments/ppp-numbers/ppp-
          numbers.xhtml#ppp-numbers-2) 

          The following values are valid in this field for 5G  
          WWC use: 
    
               0x0021: IPv4 
    
               0x0031: Ethernet (referred to in PPP as "bridging") 
    
               0x0057: IPv6 
    
          Packets received that do not contain one of the above  
          protocol IDs are silently discarded. 
    
      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 [TS23502]. They can be considered 
   to be a more secure session establishment discipline than existing 
   RFC 2516 procedures, at least against on 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 and policed 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 encapsulated traffic is used on what the 5GC considers to be 
   trusted non-3GPP interfaces, therefore is not ciphered. 5WE is not 
   suitable for use over an untrusted non-3GPP interface. 
    

 
Allan et al.,             Expires April 2021                   [Page 6] 
 

Internet-Draft     draft-allan-5g-fmc-encapsulation       February 2021 
 

   The security requirements of the 5G system are documented in 
   [TS33501] 
    
    
5. IANA Considerations 
    
   IANA is requested to create a registry on the Point-to-Point (PPP) 
   Protocol Field Assignments IANA Web page as follows: 
    
      Registry Name: PPP Over Ethernet Versions 
      Registration Procedure: Specification Required 
      References: [RFC2516] [this document] 
    
          VER     Description                        Reference 
         -----   -----------------------------      ----------- 
            0     reserved                          [this document] 
            1     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.(https://www.iana.org/assignments/ieee-802-
   numbers/ieee-802-numbers.xhtml#ieee-802-numbers-1) 
    
6. References  
    
6.1. Normative References  
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate        
          Requirement Levels", BCP 14, RFC 2119, March 1997. 
[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;      
          Wireless and wireline convergence access support  
          for the 5G System (5GS) (Release 16), 3GPP TS23.316,  
          November 2018 
 

 
Allan et al.,             Expires April 2021                   [Page 7] 
 

Internet-Draft     draft-allan-5g-fmc-encapsulation       February 2021 
 

         
         
6.2. Informative References 
[TR101]   "Migration to Ethernet Based Broadband Aggregation",  
          Broadband Forum Technical Report: TR-101 issue 2, July  
          2011 
[TR178]   "Multi-service Broadband Network Architecture and Nodal  
          Requirements", Broadband Forum Technical Report: TR-178,  
          September 2014 
[IEEE802] 802, IEEE, "IEEE Standard for Local and Metropolitan  
          Networks: Overview and Architecture", IEEE Std 802-2014. 
[TS33501] 3rd Generation Partnership Project; Technical 
          Specification Group Services and System Aspects;      
          Security Architecture and Procedures for 5G System   
          (Release 16), 3GPP TS33.501, December 2019 
         
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 April 2021                   [Page 8]