[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02

Internet Draft                                 Dave Allan, Ericsson ed.
Intended status: Informational               Donald Eastlake, Futurewei
Expires: August 2020                             David Woolley, Telstra
                                                          February 2020


    5G Fixed Mobile Convergence User Plane Encapsulation (5FE)
                  draft-allan-5g-fmc-encapsulation-02


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 August 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 August 2020                   [Page 1]


Internet-Draft     draft-allan-5g-fmc-encapsulation       February 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 depended upon this snooping. Such devices are currently able
      to do so for PPPoE or IPoE packet encodings but would be unable


Allan et al.,           Expires February 2020                  [Page 2]


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


      to do 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 FMC user plane Encapsulation or 5FE) 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 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
     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 February 2020                  [Page 3]


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


   5FE   5G FMC Encapsulation
   5GC   5th Generation Core (network)
   DSLAM Digital Subscriber Loop Access Multiplexer
   FAGF  Fixed Network Access Gateway Function
   FMC   Fixed Mobile Convergence
   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

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 FMC user plane
   encapsulation (5FE). 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 sent as zero and ignored on
          receipt.



Allan et al.,           Expires February 2020                  [Page 4]


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


      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
          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 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 5FE 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


Allan et al.,           Expires February 2020                  [Page 5]


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


      Registration Procedure: Expert Review
      References: [RFC2516] [this document]

          VER     Description                        Reference
         -----   -----------------------------      -----------
            0     reserved                          [this document]
            1     Classic PPPoE                     [RFC2516]
            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
  [10]  "IANA Considerations for PPPoE", IETF RFC 4937, June 2007




Allan et al.,           Expires February 2020                  [Page 6]


Internet-Draft     draft-allan-5g-fmc-encapsulation       February 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 February 2020                  [Page 7]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/