PW for IP/UDP Payload without IP/UDP Headers

Consider the following 5G network :

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 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: Traffic Engineering (TE) and Service Function Chaining (SFC) capability provided by SRv6 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 . 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) 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.

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