Internet DRAFT - draft-zzhang-pals-pw-for-ip-udp-payload

draft-zzhang-pals-pw-for-ip-udp-payload







pals                                                            Z. Zhang
Internet-Draft                                          Juniper Networks
Intended status: Standards Track                                K. Patel
Expires: 5 September 2022                                         Arrcus
                                                            4 March 2022


              PW for IP/UDP Payload without IP/UDP Headers
               draft-zzhang-pals-pw-for-ip-udp-payload-01

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 5 September 2022.

Copyright Notice

   Copyright (c) 2022 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 Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.





Zhang & Patel           Expires 5 September 2022                [Page 1]

Internet-Draft         PW for IP/UDP Payload Only             March 2022


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
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Introduction

   Consider the following 5G network [_3GPP-23.501]:

        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:

   *  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
   [I-D.ietf-dmm-srv6-mobile-uplane].



Zhang & Patel           Expires 5 September 2022                [Page 2]

Internet-Draft         PW for IP/UDP Payload Only             March 2022


   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 & Patel           Expires 5 September 2022                [Page 3]

Internet-Draft         PW for IP/UDP Payload Only             March 2022


   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", Work in Progress, Internet-Draft,
              draft-ietf-dmm-srv6-mobile-uplane-18, 18 February 2022,
              <https://www.ietf.org/archive/id/draft-ietf-dmm-srv6-
              mobile-uplane-18.txt>.

   [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 & Patel           Expires 5 September 2022                [Page 4]

Internet-Draft         PW for IP/UDP Payload Only             March 2022


   [_3GPP-23.501]
              "System architecture for the 5G System (5GS), V17.3.0",
              December 2021.

Authors' Addresses

   Zhaohui Zhang
   Juniper Networks
   Email: zzhang@juniper.net


   Keyur Patel
   Arrcus
   Email: keyur@arrcus.com





































Zhang & Patel           Expires 5 September 2022                [Page 5]