pals Z. Zhang
Internet-Draft Juniper Networks
Intended status: Standards Track December 22, 2021
Expires: June 25, 2022
PW for IP/UDP Payload without IP/UDP Headers
draft-zzhang-pals-pw-for-ip-udp-payload-00
Abstract
This document describes a new flavor of PW to transport IP/UDP
payload only, without transporting IP/UDP headers, which are removed
by an ingress PE and re-added by an egress PE.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on June 25, 2022.
Copyright 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
(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.
Zhang Expires June 25, 2022 [Page 1]
Internet-Draft PW for IP/UDP Payload Only December 2021
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Specifications . . . . . . . . . . . . . . . . . . . . . . . 3
3. Security Considerations . . . . . . . . . . . . . . . . . . . 4
4. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Normative References . . . . . . . . . . . . . . . . . . 4
4.2. Informative References . . . . . . . . . . . . . . . . . 4
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
Consider the following 5G network:
gNB1 ---\
gNB2 ---- PE1 ----- PE2 --- UPF
gNB3 ---/ \
---- PE3 --- UPF2
Where gNB and UPF are 5G Network Function (NF) elements [3GPP
23.501]. They are IPv4 or IPv6 hosts connected via an IPVPN over an
IPv6 transport infrastructure (it is believed that only IPv6 can
scale to the requirements of 5G transport network but that's outside
the scope of this document).
Per 3GPP specifications, the gNBs and UPF communicate over GPRS
Tunnelling Protocol (GTP) tunnels, whose encapsulation includes (IP,
UDP, GTP) headers. Some operators prefer IPv6/SRv6 [RFC8986] data
plane instead of MPLS, so when PE1 receives the GTP traffic from
gNBx, by default it would impose another IPv6 header and send to PE2.
There have been proposals to replace GTP with SRv6 tunnels for the
following benefits:
o Traffic Engineering (TE) and Service Function Chaining (SFC)
capability provided by SRv6
o Bandwidth savings because UDP and GTP headers are no longer needed
While 3GPP has not adopted the proposal, and GTP can be transported
over SRv6 (instead of being replaced by SRv6), some operators still
prefer to replace GTP with SRv6 "under the hood". That is, while
RAN/UPF still use 3GPP signaling, the actual tunnel are no longer GTP
but SRv6 based on GTP parameters signaled per 3GPP specifications.
The SRv6 tunnel could be between two NFs, or a GW (e.g. PE1/PE2)
could be attached to an NF that still use traditional GTP and the GW
will convert GTP to/from SRv6. This is specified in
[I-D.ietf-dmm-srv6-mobile-uplane].
Zhang Expires June 25, 2022 [Page 2]
Internet-Draft PW for IP/UDP Payload Only December 2021
With that approach, the GTP information is encoded in SRv6
destination address and no additional IPv6 header is added by the PEs
either. It is important to point out that when the GW is used, the
original IP payload is reconstructed (UDP/GTP header removed or
added).
In this particular scenario, the reconstruction of IP payload is
acceptable to some operators because they control all the network/
host elements. With that premise, if an operator prefers MPLS data
plane, then some new flavors of Pseudo Wire (PW) [RFC3985] can
provide similar functions. Compared with SRv6 based approach, it is
even more bandwidth efficient (no need for a minimum 40-byte IPv6
header) and SR-MPLS can also provide TE/SFC capabilities.
For example, PE1 can advertise a PW label for some (source,
destination, IP/UDP payload type) tuple, with the local semantics
being that incoming PW payload will be encapsulated in an IP or
IP+UDP header and then routed out. When PE2 receives IP or IP+UDP
traffic from the UPF, if there is a label for the corresponding
(source, destination, IP/UDP payload type) tuple, it removes the IP
or IP/UDP headers and simply transport the remaining payload as PW
payload. In this 5G scenario, it is still GTP - just that the IP/UDP
headers are not present between PE1 and PE2.
The processing logic/burden and hardware requirement on PE1 and PE2
for the adding/removing of the IP/UDP header are not different from
the "endpoint behaviors" required in the SRv6 approach even though
they're not called "End.xyz".
While this is inspired by the 5G GTP use case, the solution is
generally applicable wherever it is acceptable to reconstruct the IP/
UDP payload.
2. Specifications
Detailed specification will be added later. The general idea is
described above, and signaling is roughly described as following.
PE1 signals an IP/UDP payload PW identified in the control plane by a
(route distinguisher, destination ip address, source ip address,
destination udp port, source udp port) tuple, referred to as (RD,
dst-ip, src-ip, dst-udp, src-udp). A label is also attached to
identify the PW in the forwarding plane.
The RD distinguishes the routing instance. The src-ip, dst-udp, src-
udp could all be wildcards.
Zhang Expires June 25, 2022 [Page 3]
Internet-Draft PW for IP/UDP Payload Only December 2021
Say PE2 and/or PE3 receives the signaling. Each of the PE1/PE2/P3
will set up corresponding forwarding state in the corresponding
routing instance as following.
If both dst-udp and src-udp are wildcards, then PE2/PE3 transports
only the IP payload of all matching (dst-ip, src-ip) traffic on the
PW. When PE1 receives the PW payload, it regenerates an IP packet.
If the src-ip is a wildcard in the signaling, then PE1 uses a locally
provisioned IP addresses as source address.
If dst-udp is not a wildcard, then PE2/PE3 transports only the UDP
payload of all matching (dst-ip, src-ip, dst-udp, src-udp) traffic on
the PW. PE1 regenerates a UDP packet with the received PW payload.
If the src-ip is a wildcard in the signaling, then PE1 uses a locally
provisioned IP addresses as source address. If the src-udp is a
wildcard, then PE1 uses a locally provisioned udp port number as the
source port.
3. Security Considerations
To be provided.
4. References
4.1. Normative References
[RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation
Edge-to-Edge (PWE3) Architecture", RFC 3985,
DOI 10.17487/RFC3985, March 2005,
<https://www.rfc-editor.org/info/rfc3985>.
4.2. Informative References
[I-D.ietf-dmm-srv6-mobile-uplane]
Matsushima, S., Filsfils, C., Kohno, M., Garvia, P. C.,
Voyer, D., and C. E. Perkins, "Segment Routing IPv6 for
Mobile User Plane", draft-ietf-dmm-srv6-mobile-uplane-17
(work in progress), October 2021.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/info/rfc8986>.
Zhang Expires June 25, 2022 [Page 4]
Internet-Draft PW for IP/UDP Payload Only December 2021
Author's Address
Zhaohui Zhang
Juniper Networks
Email: zzhang@juniper.net
Zhang Expires June 25, 2022 [Page 5]