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, . 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, . 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]