Internet Draft                                 Dave Engineering Task Force (IETF)                     D. Allan, Ed.
Request for Comments: 8822                                      Ericsson ed.
Intended status:
Category: Informational               Donald Eastlake,                                  D. Eastlake 3rd
ISSN: 2070-1721                                   Futurewei
Expires: August 2021                             David Woolley, Technologies
                                                              D. Woolley
                                                     Telstra
                                                          February Corporation
                                                              April 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 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 Point-to-Point Protocol over Ethernet (PPPoE)
   data packet encapsulation. encapsulation (RFC 2516).

Status of this This Memo

   This Internet-Draft document is submitted to IETF in full conformance
   with the provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents not 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 of six
   months the IETF community.  It has
   received public review and may be updated, replaced, or obsoleted has been approved for publication by other the
   Internet Engineering Steering Group (IESG).  Not all documents at
   approved by the IESG are candidates for any time.  It is inappropriate to use Internet-
   Drafts as reference material or to cite them other than as
   "work in progress".

   The list level of Internet
   Standard; see Section 2 of RFC 7841.

   Information about the current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list status of Internet-Draft Shadow Directories can this document, any errata,
   and how to provide feedback on it may be accessed obtained at http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 2021.
   https://www.rfc-editor.org/info/rfc8822.

Copyright and License Notice

   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...................................................2  Introduction
     1.1.  Requirements Language........................................4 Language
     1.2. Acronyms.....................................................4  Acronyms
   2.  Data Encapsulation Format......................................5 Format
   3. Acknowledgements...............................................6
   4.  Security Considerations........................................6
   5. Considerations
   4.  IANA Considerations............................................7
   6. References.....................................................7
   6.1. Considerations
   5.  References
     5.1.  Normative References.........................................7
   6.2. References
     5.2.  Informative References.......................................8
   7. References
   Acknowledgements
   Authors' Addresses.............................................8 Addresses

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 of
   requirements
   requirements, including the following:

   -

   *  The ability to multiplex multiple logical connections (Protocol
      Data Unit (PDU) Sessions sessions as defined by 3GPP) within a VLAN VLAN-
      identified point to point point-to-point logical circuit between a 5G-RG and a W-
     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 the W-
      AGF (Such 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
      the point to point protocol Point-to-Point Protocol over ethernet Ethernet (PPPoE), IP, ARP, and
      IGMP.  This may be for the purpose of enhanced QoS, the policing
      of
      identifiers identifiers, and other applications.  Some deployments are
      dependent upon this inspection.  Such devices are able to do this
      for PPPoE or IP over ethernet 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 per-packet 5G QoS information.

   -  Fixed

   *  An encapsulation that minimizes processing since fixed access
      residential gateways are sensitive to the complexity of packet processing, therefore an encapsulation that minimizes
     processing
      processing.  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 plane Encapsulation encapsulation or 5WE.  Currently
   deployed access nodes do not police the VER, TYPE
   and TYPE, or CODE fields of
   an RFC 2516 header, 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 uses non-access 5G WWC session establishment based on non-
      access stratum (NAS, a logical control interface between user
      equipment (UE) and 5GC a 5th Generation Core Network (5GC) as
      specified by 3GPP) based 5G WWC session establishment and life cycle life-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, NCP NCP, etc.).  In this scenario 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 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
   6-byte RFC 2516 data packet header followed by a 2 byte 2-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 is 1, 1 and PPPoE [RFC2516] is supported,
      process the frame further, else further; else, silently discard it.

   - if

   *  If the version number is 2 and 5WE is supported, process the frame
     further, else
      further; else, silently discard it.

   In both cases 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 Wireless 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
   WWC User Plane 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

   VER:     The version.  It MUST be set to 0x02.

      TYPE is the

   TYPE:    The message type.  It MUST be set to 0x01.

      QFI encodes

   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

   R:       (Short for Reflective QoS Indication [TS38415]) encodes Encodes the one
          bit
            one-bit RQI.  It is set by the network side network-side 5WE termination
            for downstream traffic and ignored by the network for
            upstream traffic.

      0 indicates

   0:       Indicates the bit(s) that MUST be sent as zero and ignored
            on receipt.

      SESSION_ID is a

   SESSION_ID:  A 16-bit unsigned integer in network byte order.  It is
            used to distinguish different PDU sessions that are in the
          VLAN delineated
            VLAN-delineated multiplex.  A value of 0xffff is reserved
            for future use and MUST NOT be used.

      LENGTH is the

   LENGTH:  The length in bytes of the data payload payload, including the
            initial Protocol ID.  It is 16 bits in network byte order.

   PROTOCOL ID is the 16 bit ID:  The 16-bit identifier of the data payload type encoded
            using values from the IANA PPP "PPP DLL protocol 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.

   DATA PAYLOAD is encoded PAYLOAD:  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 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 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 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.

   5WE encapsulated

   5WE-encapsulated traffic is used on what the 5GC considers to be
   trusted non-3GPP interfaces, therefore interfaces; 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

   IANA is requested to create a has created the following registry on the Point-to-Point "Point-to-Point (PPP)
   Protocol Field Assignments IANA Web page as follows: Assignments" page:

   Registry Name:  PPP Over Ethernet Versions

   Registration Procedure:  Specification Required

   References:  [RFC2516] [this document]

       +======+=================================+=================+
       | VER  | Description                     | Reference
         -----   -----------------------------      -----------       |
       +======+=================================+=================+
       | 0     reserved    | 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

   IANA is requested to add [this document] has added this document as an additional reference for Ethertype
   0x8864 in the Ethertypes 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.  References

6.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, March 1997. 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;
          Wireless  3GPP, "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-101 TR-101, issue 2, July
          2011 2011.

   [TR178]    Broadband Forum, "Multi-service Broadband Network
              Architecture and Nodal Requirements", Broadband Forum Technical Report: TR-178, issue 1,
              September 2014
[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 Services and System Aspects;
          Security Architecture  3GPP, "Security architecture and Procedures procedures for 5G System
          (Release 16), 3GPP TS33.501,
              System", Release 16, TS 33.501, December 2019

7. 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 this document.

Authors' Addresses

   Dave Allan (editor)
   Ericsson
   2455 Augustine Drive
   San Jose, CA 95054 USA
   United States of America

   Email: david.i.allan@ericsson.com

   Donald E. Eastlake 3rd
   Futurewei Technologies
   2386 Panoramic Circle
   Apopka, FL 32703 USA
   United States of America

   Phone: +1-508-333-2270
   Email: d3e3e3@gmail.com

   David Woolley
   Telstra Corporation
   242 Exhibition St
   Melbourne,
   Melbourne  3000
   Australia

   Email: david.woolley@team.telstra.com