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: 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]
