idnits 2.17.00 (12 Aug 2021) /tmp/idnits13894/draft-zzhang-pals-pw-for-ip-udp-payload-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (4 March 2022) is 71 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 3985 == Outdated reference: A later version (-21) exists of draft-ietf-dmm-srv6-mobile-uplane-18 Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 pals Z. Zhang 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track K. Patel 5 Expires: 5 September 2022 Arrcus 6 4 March 2022 8 PW for IP/UDP Payload without IP/UDP Headers 9 draft-zzhang-pals-pw-for-ip-udp-payload-01 11 Abstract 13 This document describes a new flavor of PW to transport IP/UDP 14 payload only, without transporting IP/UDP headers, which are removed 15 by an ingress PE and re-added by an egress PE. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on 5 September 2022. 34 Copyright Notice 36 Copyright (c) 2022 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 41 license-info) in effect on the date of publication of this document. 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. Code Components 44 extracted from this document must include Revised BSD License text as 45 described in Section 4.e of the Trust Legal Provisions and are 46 provided without warranty as described in the Revised BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Specifications . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Security Considerations . . . . . . . . . . . . . . . . . . . 4 53 4. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 4.1. Normative References . . . . . . . . . . . . . . . . . . 4 55 4.2. Informative References . . . . . . . . . . . . . . . . . 4 56 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 58 1. Introduction 60 Consider the following 5G network [_3GPP-23.501]: 62 gNB1 ---\ 63 gNB2 ---- PE1 ----- PE2 --- UPF 64 gNB3 ---/ \ 65 ---- PE3 --- UPF2 67 Where gNB and UPF are 5G Network Function (NF) elements [3GPP- 68 23.501]. They are IPv4 or IPv6 hosts connected via an IPVPN over an 69 IPv6 transport infrastructure (it is believed that only IPv6 can 70 scale to the requirements of 5G transport network but that's outside 71 the scope of this document). 73 Per 3GPP specifications, the gNBs and UPF communicate over GPRS 74 Tunnelling Protocol (GTP) tunnels, whose encapsulation includes (IP, 75 UDP, GTP) headers. Some operators prefer IPv6/SRv6 [RFC8986] data 76 plane instead of MPLS, so when PE1 receives the GTP traffic from 77 gNBx, by default it would impose another IPv6 header and send to PE2. 79 There have been proposals to replace GTP with SRv6 tunnels for the 80 following benefits: 82 * Traffic Engineering (TE) and Service Function Chaining (SFC) 83 capability provided by SRv6 85 * Bandwidth savings because UDP and GTP headers are no longer needed 87 While 3GPP has not adopted the proposal, and GTP can be transported 88 over SRv6 (instead of being replaced by SRv6), some operators still 89 prefer to replace GTP with SRv6 "under the hood". That is, while 90 RAN/UPF still use 3GPP signaling, the actual tunnel are no longer GTP 91 but SRv6 based on GTP parameters signaled per 3GPP specifications. 92 The SRv6 tunnel could be between two NFs, or a GW (e.g. PE1/PE2) 93 could be attached to an NF that still use traditional GTP and the GW 94 will convert GTP to/from SRv6. This is specified in 95 [I-D.ietf-dmm-srv6-mobile-uplane]. 97 With that approach, the GTP information is encoded in SRv6 98 destination address and no additional IPv6 header is added by the PEs 99 either. It is important to point out that when the GW is used, the 100 original IP payload is reconstructed (UDP/GTP header removed or 101 added). 103 In this particular scenario, the reconstruction of IP payload is 104 acceptable to some operators because they control all the network/ 105 host elements. With that premise, if an operator prefers MPLS data 106 plane, then some new flavors of Pseudo Wire (PW) [RFC3985] can 107 provide similar functions. Compared with SRv6 based approach, it is 108 even more bandwidth efficient (no need for a minimum 40-byte IPv6 109 header) and SR-MPLS can also provide TE/SFC capabilities. 111 For example, PE1 can advertise a PW label for some (source, 112 destination, IP/UDP payload type) tuple, with the local semantics 113 being that incoming PW payload will be encapsulated in an IP or 114 IP+UDP header and then routed out. When PE2 receives IP or IP+UDP 115 traffic from the UPF, if there is a label for the corresponding 116 (source, destination, IP/UDP payload type) tuple, it removes the IP 117 or IP/UDP headers and simply transport the remaining payload as PW 118 payload. In this 5G scenario, it is still GTP - just that the IP/UDP 119 headers are not present between PE1 and PE2. 121 The processing logic/burden and hardware requirement on PE1 and PE2 122 for the adding/removing of the IP/UDP header are not different from 123 the "endpoint behaviors" required in the SRv6 approach even though 124 they're not called "End.xyz". 126 While this is inspired by the 5G GTP use case, the solution is 127 generally applicable wherever it is acceptable to reconstruct the IP/ 128 UDP payload. 130 2. Specifications 132 Detailed specification will be added later. The general idea is 133 described above, and signaling is roughly described as following. 135 PE1 signals an IP/UDP payload PW identified in the control plane by a 136 (route distinguisher, destination ip address, source ip address, 137 destination udp port, source udp port) tuple, referred to as (RD, 138 dst-ip, src-ip, dst-udp, src-udp). A label is also attached to 139 identify the PW in the forwarding plane. 141 The RD distinguishes the routing instance. The src-ip, dst-udp, src- 142 udp could all be wildcards. 144 Say PE2 and/or PE3 receives the signaling. Each of the PE1/PE2/P3 145 will set up corresponding forwarding state in the corresponding 146 routing instance as following. 148 If both dst-udp and src-udp are wildcards, then PE2/PE3 transports 149 only the IP payload of all matching (dst-ip, src-ip) traffic on the 150 PW. When PE1 receives the PW payload, it regenerates an IP packet. 151 If the src-ip is a wildcard in the signaling, then PE1 uses a locally 152 provisioned IP addresses as source address. 154 If dst-udp is not a wildcard, then PE2/PE3 transports only the UDP 155 payload of all matching (dst-ip, src-ip, dst-udp, src-udp) traffic on 156 the PW. PE1 regenerates a UDP packet with the received PW payload. 157 If the src-ip is a wildcard in the signaling, then PE1 uses a locally 158 provisioned IP addresses as source address. If the src-udp is a 159 wildcard, then PE1 uses a locally provisioned udp port number as the 160 source port. 162 3. Security Considerations 164 To be provided. 166 4. References 168 4.1. Normative References 170 [RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation 171 Edge-to-Edge (PWE3) Architecture", RFC 3985, 172 DOI 10.17487/RFC3985, March 2005, 173 . 175 4.2. Informative References 177 [I-D.ietf-dmm-srv6-mobile-uplane] 178 Matsushima, S., Filsfils, C., Kohno, M., Garvia, P. C., 179 Voyer, D., and C. E. Perkins, "Segment Routing IPv6 for 180 Mobile User Plane", Work in Progress, Internet-Draft, 181 draft-ietf-dmm-srv6-mobile-uplane-18, 18 February 2022, 182 . 185 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 186 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 187 (SRv6) Network Programming", RFC 8986, 188 DOI 10.17487/RFC8986, February 2021, 189 . 191 [_3GPP-23.501] 192 "System architecture for the 5G System (5GS), V17.3.0", 193 December 2021. 195 Authors' Addresses 197 Zhaohui Zhang 198 Juniper Networks 199 Email: zzhang@juniper.net 201 Keyur Patel 202 Arrcus 203 Email: keyur@arrcus.com