5G Fixed Mobile Convergence User Plane Encapsulation
draft-allan-5g-fmc-encapsulation-00
The information below is for an old version of the document.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | David Allan , Donald E. Eastlake 3rd , David Woolley | ||
| Last updated | 2019-07-21 | ||
| Stream | (None) | ||
| Formats | plain text htmlized pdfized bibtex | ||
| Reviews |
GENART Last Call review
(of
-07)
Almost Ready
GENART Last Call review
(of
-04)
Almost Ready
TSVART Last Call review
(of
-04)
Ready with Issues
OPSDIR Last Call Review
Incomplete, due 2020-07-27
|
||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-allan-5g-fmc-encapsulation-00
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]