Internet DRAFT - draft-allan-5g-fmc-encapsulation

draft-allan-5g-fmc-encapsulation



Internet Draft                                 Dave Allan, Ericsson ed.          
Intended status: Informational               Donald Eastlake, Futurewei         
Expires: January 2020                            David Woolley, Telstra 
                                                              July 2019 
             
         5G Fixed Mobile Convergence User Plane Encapsulation 
                  draft-allan-5g-fmc-encapsulation-00 
 
Abstract 
   As part of providing wireline access to the 5G core, 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 January 2020. 

Copyright and License Notice 

   Copyright (c) 2019 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) in effect on the date of 

 
Allan et al.,            Expires January 2020                  [Page 1] 
 
Internet-Draft     draft-allan-5g-fmc-encapsulation           July 2019 
 

   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 F-AGF in [5]) across deployed TR-101[6] 
   and TR-178[7] access networks.  
    
   The transport encapsulation used needs to meet a variety of 
   requirements including the following: 
    
   -  The ability to multiplex multiple logical connections (PDU 
     sessions) within a VLAN identified p2p logical circuit between a 
     5G-RG and an F-AGF. 
    
   - To allow unmodified legacy equipment in the datapath to identify 
      the encapsulation and snoop specific fields in the payload. Some 
      access nodes in the data path between the 5G-RG and the F-AGF 
      (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 depended upon this snooping. Such devices are currently able 
      to do so for PPPoE or IPoE packet encodings but would be unable 
      to do so if a new encapsulation, or an existing encapsulation 
      using a new ethertype, were used. 

 
Allan et al.,            Expires January 2020                  [Page 2] 
 
Internet-Draft     draft-allan-5g-fmc-encapsulation           July 2019 
 

    
   -  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 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 control plane (NAS) based 5G FMC 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 Reverse 
     QoS Indication (RQI) information from the 5GC core 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 RFC 2119 [RFC2119]. 
 
1.2. Acronyms 

   This document uses the following acronyms: 

   DSLAM Digital Subscriber Loop Access Multiplexer 
   F-AGF Fixed Network Access Gateway Function 
   FMC   Fixed Mobile Convergence 
   IPoE  IP over Ethernet 
   NAS   Non-Access Stratum 
   OLT   Optical Line Termination 
 
Allan et al.,            Expires January 2020                  [Page 3] 
 
Internet-Draft     draft-allan-5g-fmc-encapsulation           July 2019 
 

   PPPoE PPP over Ethernet 
   QFI   QoS Flow Identifier 
   RG    Residential Gateway 
   RQI   Reverse QoS Indicator 
    

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 for the repurposing of the PPPoE data encapsulation 
   as the 5G FMC user plane encapsulation uses a value of 2 in the VER 
   field. The 5G FMC 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 set to zero 
    
      SESSION_ID is a 16-bit unsigned integer. 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. 
    
      PROTOCOL ID is the 16 bit identifier of the data payload type  
          encoded as per RFC 2516. The following values are valid in   

 
Allan et al.,            Expires January 2020                  [Page 4] 
 
Internet-Draft     draft-allan-5g-fmc-encapsulation           July 2019 
 

          this field for 5G FMC 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 for his detailed 
   review of this draft. 

4. Security Considerations 

   5G NAS procedures used for session life cycle maintenance employ 
   ciphering and integrity protection therefore 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 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 an access network 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: 
      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] 

 
Allan et al.,            Expires January 2020                  [Page 5] 
 
Internet-Draft     draft-allan-5g-fmc-encapsulation           July 2019 
 

            2     5G FMC 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 


 
Allan et al.,            Expires January 2020                  [Page 6] 
 
Internet-Draft     draft-allan-5g-fmc-encapsulation           July 2019 
 

  [10]  "IANA Considerations for PPPoE", IETF RFC 4937, June 2007 

7. Authors' Addresses 

   Dave Allan (editor) 
   Ericsson 
   2755 Augustine Drive 
   San Jose, CA  95054 USA 
   Email: david.i.allan@ericsson.com  
    
    
   Donald E. Eastlake 3rd 
   Futurewei Technologies 
   1424 Pro Shop Court 
   Davenport, FL 33896 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 January 2020                  [Page 7]