Skip to main content

Status of this Memo
draft-mcd-rtgwg-extension-tn-aware-mobility-07

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Kausik Majumdar , Uma Chunduri , Linda Dunbar
Last updated 2023-07-24 (Latest revision 2023-07-10)
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-mcd-rtgwg-extension-tn-aware-mobility-07
RTG Working Group                                           K. Majumdar
Internet Draft                                                Microsoft
Intended status: Informational                              U. Chunduri
Expires: October 24, 2024                                         Intel
                                                              L. Dunbar
                                                              Futurewei
                                                         July 24, 2023
           Extension of Transport Aware Mobility in Data Network
              draft-mcd-rtgwg-extension-tn-aware-mobility-07

Abstract
   The existing Transport Network Aware Mobility for 5G [TN-AWARE-
   MOBILITY] draft specifies a framework for mapping the 5G mobile
   systems' Slice and Service Types (SSTs) to corresponding underlying
   network paths between gNBs (generalized Node-B) and UPFs (User Plane
   Functions).The focus of that work is limited to the 3GPP domain
   (i.e., gNB <-> UPFs) and doesn't cover the network between the UPFs
   and the services hosted in data centers.

   This document describes a framework for extending the mobility-aware
   transport network characteristics from the 3GPP domain through the
   IP Data Networks to the service destinations. Extending the
   framework to the data centers where the services are hosted becomes
   necessary to maintain the end-to-end transport network
   characteristics between UEs and their application servers.

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), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

xxx, et al.                                                    [Page 1]
Internet-Draft      Extension of TN Aware Mobility            July 2023

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on April 23, 2021.

Copyright Notice

   Copyright (c) 2023 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
   (http://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.

Table of Contents

   1. Introduction...................................................3
   2. Conventions used in this document..............................3
   3. Framework for Extension of Transport Network Aware Mobility....4
   4. Mobility Packet Transition to the Data Network.................5
   5. Transport Network Characteristics Mapping to SR-TE Paths.......7
      5.1. Extend TN Aware Mobility for BGP SR-TE Policy.............9
      5.2. Extend TN Aware Mobility for SR-PCE Controller...........13
      5.3. Extend TN Aware Mobility for RestConf/gRPC based SR-TE
      Controller....................................................15
      5.4. Extend BGP FlowSpec for TN Aware Mobility................17
   6. Mapping of TN Characteristics on SD-WAN Edge Node.............20
      6.1. SD-WAN Hybrid Use Case with SR-TE Integration............22
   7. IANA Considerations...........................................24
   8. Security Considerations.......................................24
   9. Contributors..................................................24
   10. References...................................................24
      10.1. Normative References....................................24
      10.2. Informative References..................................25
   11. Acknowledgments..............................................25
   Authors' Addresses...............................................27

Majumdar, et al.       Expires October15, 2024                 [Page 2]
Internet-Draft      Extension of TN Aware Mobility            July 2023

1. Introduction

   The [TN-AWARE-MOBILITY] draft defines the transport path
   characteristics in back-haul, mid-haul, and front-haul segments
   between UEs and user plane functions (UPF). It describes how 5G
   services are mapped to network slices built upon various transport
   network underlays, including RSVP-TE, SRv6, MPLS-TE, and Preferred
   Path Routing (PPR). The [TN-AWARE-MOBILITY] is limited to the 3GPP
   domain (i.e., gNB <-> UPFs) and doesn't cover the network between
   the UPFs and the services hosted in data centers.

   This draft extends the mobility-aware transport network
   characteristics from the UPFs through the data network to the
   service destinations to ensure the end-to-end service guarantee for
   the 5G services. As user services are handled by their corresponding
   servers in data centers through the IP network, maintaining the
   transport path network characteristics between UEs <-> UPFs is
   insufficient.

   A UPF can be connected to a C-PE node that ingresses to the IP
   network (the N6 Interface of the 3GPP domain) or embedded with the
   C-PE function. The C-PE node can be an SD-WAN edge node, L2/L3 VPN
   edge node, or SR-TE edge node. For the enterprise 5G scenario, the
   L3 aggregator function can be integrated with the UPFs for all the
   enterprise's 5G mobility connections.

   This draft proposes mechanisms for extending the 5G Service Slices
   mapping enforced within the 3GPP domain to various IP underlays from
   UPFs to 5G service destinations, including SR-TE paths, un-secure
   networks, or L2/L3 VPNs.

2. Conventions used in this document

   BSID       - Binding SID

   DC         - Data Center

   DN         - Data Network (5G)

Majumdar, et al.       Expires October15, 2024                 [Page 3]
Internet-Draft      Extension of TN Aware Mobility            July 2023

   EMBB       - enhanced Mobile Broadband (5G)

   gNB        - 5G NodeB

   GTP-U      - GPRS Tunneling Protocol - Userplane (3GPP)

   MIOT       - Massive IOT (5G)

   PECP       - Path Computation Element (PCE) Communication Protocol

   SD-WAN     - Software-Defined Wide Area Network

   SID        - Segment Identifier

   SLA        - Service Layer Agreement

   SST        - Slice and Service Types (5G)

   SR         - Segment Routing

   SR-PCE     - SR Path Computation Element

   UE         - User Equipment

   UPF        - User Plane Function (5G)

   URLLC      - Ultra reliable and low latency communications (5G)

3. Framework for Extension of Transport Network Aware Mobility

  Architecture-wise, the proposed extension of Transport Aware
  Mobility in the Data Network focuses on the following areas:

  a) The Mobility packets transition in and out from the UPFs to the C-
     PEs node maintaining the same Transport Path Characteristics.

  b) On a C-PE node, based on the transport characteristics, use
     different methods of fetching SR-TE path segments from the SR-TE
     Controller and map the SR-TE segments to the packets from UEs.

Majumdar, et al.       Expires October15, 2024                 [Page 4]
Internet-Draft      Extension of TN Aware Mobility            July 2023

  c) On an SD-WAN CE Node, based on the transport characteristics,
     mapping of UP packets to the secure and un-secure tunnel paths
     based on 5G service policies.

  Figure 1 captured under Section 4 provides the representation of a
  network on how UE could be connected to the UPF and C-PE nodes in the
  Data Network. The C-PE node represents a combined CE and PE node. In
  some cases, UPF would be connected to the pure PE or CE node.

4. Mobility Packet Transition to the Data Network

   As the Transport Aware Mobility packets transition in and out from
   the UPF to the C-PE node, the Mobility Transport Characteristics
   need to be maintained in the Data Network. This draft proposes a
   generic approach to how the mobility packet transition can happen in
   the Data Network maintaining the same transport characteristics.

   There are two scenarios:

   A) The UPF is connected to a C-PE via a direct link (Figure 1
   below). Based on the local policy, the new outer header format for
   the TN Aware Mobility Packets transitioning from the UPF to the C-PE
   device is as below:

     . From the UPF to the C-PE Node:
   Inner IP Hdr (UE Packet) + Transport Hdr (Carrying UDP Src Port) +
   Outer IP (C-PE Node Address)

     . From the C-PE to the UPF Node:
   Outer IP (UPF Node Address) + Transport Hdr (Carrying UDP Src
   Port) + Inner IP Hdr (UE Packet)

   B)          The UPF has the embedded C-PE function (Figure 1). The original
     UDP Source Port information can be used to select the underlays
     for reaching the service destinations based on the local policy.

Majumdar, et al.       Expires October15, 2024                 [Page 5]
Internet-Draft      Extension of TN Aware Mobility            July 2023

     Scenario A:

                 +-----------+       +-----+       +-----+
                 |           |       |     |       |     |
      UE---------| gNB-CU(UP)|-------| UPF |-------| C-PE|------DN
                 |           |       |     |       |     |
                 +-----------+       +-----+       +-- --+

                      |--- N3 OR N9 -------||---- N6 -----

       |-------- Mobile Network ------------||------ IP Network ------|

     Scenario B:

          +-----------+      +------+
           |           |      |      |
      UE---| gNB-CU(UP)|------| UPF +|--------DN-------
           |           |      | C-PE |
           +-----------+      +------+

                   |- N3 OR N9 -||----N6 -------------|

      |------ Mobile Network ----||-- IP Network-------|

                  Figure 1: Mobile and IP Data Network for UE

     Figure 2 illustrates the TN Aware Mobility packet format under
     scenario A.

      1. UE Packet format in the Mobile Network to the UPF:

       +---------+----------+-------+------------+----------+
       | UE Data | Inner IP | GTP-U | UDP Header | Outer IP |
       +---------+----------+-------+------------+----------+

       2. UE Packet format in the IP Network to the Ingress C-PE Node:

       +---------+----------+------------------+------------+
       | UE Data | Inner IP | Transport Header | C-PE Header|
       +---------+----------+------------------+------------+

            Figure 2: UE Packet Transition from Mobile to IP Network

Majumdar, et al.       Expires October15, 2024                 [Page 6]
Internet-Draft      Extension of TN Aware Mobility            July 2023

   The source port in the original UDP header indicates the TN Aware
   Mobility SST type.

5. Transport Network Characteristics Mapping to SR-TE Paths

   Within the 5G Core [3GPP], UE traffic is carried by the GTP tunnels
   terminated by the UPFs. [TN-AWARE-MOBILITY] specifies using the
   outer header's source UDP port number to indicate the desired
   Transport Network Characteristics. The same Transport Network
   Characteristics should be carried through the IP data network to the
   destinations to maintain the end-to-end SLA for the UE traffic.

   3GPP specifies that the User Plane Function (UPF) decapsulates the
   GTP header and hands the inner payload to the N6 interface. As more
   and more deployments have integrated UPF with the ingress routing
   functions to the IP data network, it is relatively easy to carry the
   UDP port information from the GTP header into the IP data network,
   e.g.,

   - Carry the UDP port number in an extra IP encapsulation (VxLAN, GENEVE,
     etc.) to the IP network, or,
   - Assign an identifier in the header to the IP networks based on the UDP
     port number in the GTP header.

   In scenarios where the ingress PE acts as an SR-TE node, the mapping
   of Transport Network Aware Mobility {5G UDP Src Port Range} to {BGP
   SR-TE Policy, BSID} can be performed at the ingress PE. Once this
   mapping is done, the mobility Transport Path Characteristics can be
   maintained in the data network. Here are some options in selecting
   the SR-TE path segments:

   Option 1: Assume the ingress PE is connected to a BGP SR-TE
   Controller through a BGP SR-TE Policy SAFI Session. Here is a
   mechanism to map the BGP SR-TE Underlay Path Segments based on the
   Mobility Transport Characteristics:

     . Creating a new BGP Sub-TLV as part of the existing SR Policy
       SAFI NLRI to download SR-TE Policies corresponding to the
       mobility Transport Path characteristics. If the TN aware
       mobility packet UDP Source Port value falls within the UDP Src

Majumdar, et al.       Expires October15, 2024                 [Page 7]
Internet-Draft      Extension of TN Aware Mobility            July 2023

       Port range value of this Sub-TLV, then the pre-downloaded SR-TE
       Policy MUST be applied to the packet. The PE node cache the
       received policy to apply to the subsequent mobility TN-aware
       packets until a new BGP UPDATE for the same port range.

   Option 2: Assume the ingress PE is connected to the SR-PCE (Path
   Compute Element) Controller through a PCEP Session which can pass
   the policy to map Mobility Transport Path Characteristics to the SR-
   TE Underlay Segments .

   This mechanism does not require new encoding in the PCEP-based
   communication. However it needs local configuration on the PE to
   request the SR-TE Paths from the PCEP based Controller based on on-
   demand TN aware mobility traffic metric types.

   Option 3: Assume the ingress PE is connected to the SR-TE Controller
   over Restconf/ Netconf or gRPC session. The existing mechanism would
   be used to download the SR-TE Underlay Path Segments to the PE node
   based on the Mobility Transport Path Characteristics.

   The Yang Data Model or Protobuf definition is required to define a
   new Sub-TLV like Scenario 1. The SR-TE Controller would pre-download
   the SR-TE Policies with the new Sub-TLV in the Ingress PE using the
   existing session. Once the specific SR-TE Policy is fetched, it
   would be cached by the Ingress PE to apply for the mobility TN aware
   traffic in-line to maintain the network characteristics in the Data
   Network.

   Option 4: Assume the ingress PE is connected to the BGP SR FlowSpec
   Controller through a BGP FlowSpec session. The FlowSpec Redirect to
   indirection-id Extended community [FLOWSPEC-PATH-REDIRECT] can be
   used to map the Mobility Transport Path Characteristics to SR
   Traffic rules.

   . This mechanism does not require additional new encoding in the BGP
     SR FlowSpec path redirect draft [FLOWSPEC-PATH-REDIRECT]. However,
     it needs local configuration on the ingress PE acting as the BGP
     FlowSpec Client to map the Mobility traffic based on the SR
     FlowSpec traffic re-direction rules.

Majumdar, et al.       Expires October15, 2024                 [Page 8]
Internet-Draft      Extension of TN Aware Mobility            July 2023

5.1. Extend TN Aware Mobility for BGP SR-TE Policy

  1) To integrate Transport Network Aware Mobility with BGP SR-TE
     Policy at the Ingress PE UPF, the Class-map needs to be defined to
     classify the incoming mobility traffic with different Transport
     Path Characteristic.

  2) The ingress PE (embedded in UPF) is assumed to have a BGP SR-TE
     Policy SAFI connection with the BGP SR-TE Controller. The Mobility
     traffic destination would resolve in the BGP Peer Next Hop for
     which SR-TE Policy to be applied to maintain the same network
     characteristics beyond the mobility domain.

  3) A new 5G Metadata Sub-TLV has been defined for existing SR-Policy
     SAFI with the UDP Source Port Range to identify the SR-TE path
     based on the Transport Path characteristics.

  4) The BGP SR-TE Controller would be programmed with {5G UDP Src Port
     Range}. That would create internal mapping Table for {5G UDP Src
     Port Range} < -- > {BGP SR-TE Policy, BSID}.

  5) The BGP SR-TE Controller would download the SR-TE Policy in the
     ingress PE through the existing BGP SR-Policy SAFI session, and
     that the BGP update would include an additional 5G Metadata Sub-
     TLV. The UDP Src Port range in the 5G Metadata Sub-TLV MUST fall
     within the UDP Source Port range for the SSTs defined by the [TN-
     AWARE-MOBILITY] draft. If the UDP Src Port range falls outside the
     range defined by the [TN-AWARE-MOBILITY] draft, then the SR-TE
     Policy SHOULD be ignored by the Ingress PE.

  6) The SR-TE Policy-based traffic steering would be applied in the
     Ingress PE and it would maintain the local mapping for the reverse
     Mobility traffic to the UE.

   The following class-map definition needs to be applied in the
   headend PE for the incoming Transport Network aware mobility traffic
   path:

   Class-map type traffic match MIOT

        Match UDP Src Port Range Xx - Xy

   Class-map type traffic match URLLC

        Match UDP Src Port Range Yx - Yy

   Class-map type traffic match EMBB

Majumdar, et al.       Expires October15, 2024                 [Page 9]
Internet-Draft      Extension of TN Aware Mobility            July 2023

        Match UDP Src Port Range Zx - Zy

   The class-map would help to identify the incoming mobility traffic
   characteristics. Based on these characteristics the headend PE would
   be able to map the Transport Network aware mobility traffic to the
   appropriate BGP SR-TE Policy path over the Data Network to reach the
   UE's destination.

   The below figure tries to capture the overall topology, and how to
   map the mobility traffic in the Ingress PE having BGP SR-Policy SAFI
   connection with the BGP SR-TE Controller:

                         +-----------+   +----+{5G UDP Src Port Range}
                         | BGP SR-TE |-->| Map|       <-->
                         | Controller|   | DB |{BGP SR-TE Policy, BSID}
                         +-----------+   +----+
                           /
                          /
                         /
                        /
                       /                                    +--------+
                      / BGP SR-TE Policy with               |IOT Data|
                     /  5G Metadata Sub-TLV                 +--------+
                    /                                           /Public
                   /                                      mIoT / Cloud
                  /                                    +------+
             +------+  Policy1: UDP Src Port Xx-Xy    /
             |      A1-------------------------------+
             |      |  Policy2: UDP Src Port Yx-Yy    URLLC
     UE------| UPF  A2-----------------------------------------
             | +PE1 |  Policy3: UDP Src Port Zx-Zy
             |      A3------------------------------+
             |      |                                \
             +------+                                 +-------+
     {UDP Src Port Num# <--> SR Policy N}                 eMBB \
                                                                \
                                                              +--------+
                                                              | Content|
                                                              +--------+
                                                               Private DC
                  ---------->
       +------+----------+-------+-----+----------+
       | Data | Inner IP | GTP-U | UDP | Outer IP |
       +------+----------+-------+-----+----------+

                                      ---------->

Majumdar, et al.       Expires October15, 2024                [Page 10]
Internet-Draft      Extension of TN Aware Mobility            July 2023

                     +------+----------+-------------+
                     | Data | Inner IP |   SR Header |
                     +------+----------+-------------+

       Figure 3: TN Aware Mobility Traffic Mapping to BGP SR-TE Policy Path

Note that, in the above figure SR Header is shown as an illustrative
purpose and the actual outgoing packet format is based on the BGP SR-TE
mechanism (SR-MPLS or SRv6) on the Ingress PE. That could be SR-MPLS or
SRv6 Header. If the BSID is not present with the BGP SR-TE Policy, the
local ingress PE will map the incoming traffic to the best effort
policy map path in the underlay.

  To support the Transport Network Mobility Traffic Mapping to BGP SR-
  TE Policy Path on the ingress PE, a new 5G Metadata Sub-TLV needs to
  be specified. The proposed BGP SR Policy Encoding from the BGP SR-TE
  Policy Controller to the headend PE node is defined below:

   SR Policy SAFI NLRI: <Distinguisher, Policy-Color, Endpoint>
      Attributes:
         Tunnel Encap Attr (23)
           Tunnel Type: SR Policy
             Existing Policy Sub-TLV
             5G Metadata Sub-TLV

   The draft [BGP-SR-TE-POLICY] defines BGP SR-TE Policy encodings.
   There is no change in the existing encoding that is being used from
   the BGP SR-TE Controller to the headend PE node. The current
   solution proposes the new 5G Metadata Sub-TLV for BGP SR-TE
   Controller to download the SR Policies to the headend PE and to
   apply the SR-TE Policy-driven path for the Transport Network aware
   mobility traffic.

   The incoming TN aware mobility traffic with UDP Src port and BGP NH
   to the traffic destination would be used as a key to find the BGP
   SR-TE Policy. If the BGP Next Hop of the traffic matches with the SR
   Policy SAFI NLRI Endpoint, and UDP Src Port value falls within the
   UDP Src Port range defined by the 5G Metadata Sub-TLV, the SR Policy
   would be applied to the mobility traffic to maintain the traffic
   characteristics in the data network. The BGP SR-TE Controller would
   be pre-provisioned with the 5G UDP SRC Port Range based on the [TN-
   AWARE-MOBILITY] draft, and their corresponding BGP SR-TE Policy.

Majumdar, et al.       Expires October15, 2024                [Page 11]
Internet-Draft      Extension of TN Aware Mobility            July 2023

    The 5G Metadata sub-TLV is optional and it MUST NOT appear more than
   once in the SR-TE Policy.

   The format of the new SR-TE 5G Metadata Sub-TLV is captured below:

   0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |    Sub-Type   |     Length    |     Flags     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    UDP Src Port Start Value   |    UDP Src Port End Value     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                          5G Metadata Sub-TLV

    where:

    o  Type: To be defined by IANA.

   o  Sub-Type: This field has one of the following values:

         0: Reserved.
         1: UDP Source Port Range.
         2 - 255: Reserved for future use.

   o  Length: 6 octets.

   o  Flags: 1 octet of flags.  None are defined at this stage.  Flags
      SHOULD be set to zero on transmission and MUST be ignored on
      receipt.

  o  UDP Src Port Start Value: 2 octets value to define the staring of
     the value of the UDP Src Port range.

  o  UDP Src Port End Value: 2 octets value to define the end value of
     the UDP Src Port range.

Majumdar, et al.       Expires October15, 2024                [Page 12]
Internet-Draft      Extension of TN Aware Mobility            July 2023

5.2. Extend TN Aware Mobility for SR-PCE Controller

  1) To integrate Transport Network Aware Mobility with SR-TE ODN based
     PCE Controller at the Ingress PE UPF, the Class-map needs to be
     defined to classify the incoming mobility traffic with different
     Transport Path Characteristic.

  2) The Ingress PE UPF is assumed to have PCEP based communication
     with the SR-PCE Controller.

  3) The Ingress PE would define the Policy-map to map the Transport
     Path characteristics into SR-TE Color.

  4) The Segment Routing TE Configuration for different Metric types
     will associate the SR-TE Colors with their corresponding TE metric
     type.

  5) The existing SR-TE ODN based PCEP messages with TE metric type and
     value MUST be used to associate the SR-TE Path corresponding to
     the 5G UDP Src Port.

  6) In this case, the mapping between {5G UDP Src Port} and {SR-TE
     Policy} would be maintained by the Ingress PE.

  7) Once the TN aware mobility traffic destination resolves into a
     destination of BGP Peer Next Hop, the SR-TE ODN based traffic
     steering MUST be applied based on the UDP Src Port value of the
     incoming traffic.

   The class-map definition to identify the incoming mobility traffic
   characteristics is already defined in Section 5.1. The same class-
   map definition applicable here as well.

   The policy-map definition to associate SR-TE color with Transport
   Path characteristics is defined below:

   Policy-map type Transport-Network-Aware-Mobility

       Class type traffic MIOT

           Set color <MIOT-10>

       Class type traffic URLLC

           Set color <URLLC-20>

Majumdar, et al.       Expires October15, 2024                [Page 13]
Internet-Draft      Extension of TN Aware Mobility            July 2023

       Class type traffic EMBB

           Set color <EMBB-30>

   The Segment Routing TE Configuration mechanism can associate the SR-
   TE Colors with their corresponding metric type. That exists today,
   and there is no change there. It is captured here to show how TN
   aware mobility network characteristics get mapped to different TE
   metrics through this mechanism.

   Segment-routing traffic-eng

     On-demand color <MIOT-10> dynamic

        Metric

          Type <MIOT>

     On-demand color <URLLC-20> dynamic

        Metric

          Type <URLLC>

     On-demand color <EMBB-30> dynamic

        Metric

          Type <EMBB>

   As a result, mobility Transport Network aware of different traffic
   characteristics like MIOT, URLLC, or EMBB get to assigned
   corresponding "te" metric types. To fetch the corresponding SR-TE
   dynamic path from the SR-PCE Controller based on the newly defined
   "te" metric types <MIOT>, <URLLC> or <EMBB> needs to be extended in
   the PCEP RFC [RFC5440].

   The below figure tries to capture the overall topology, and how to
   map the mobility traffic in the headend PE having PCEP connection
   with the SR-PCE Controller:

Majumdar, et al.       Expires October15, 2024                [Page 14]
Internet-Draft      Extension of TN Aware Mobility            July 2023

                         +-----------+
                         | SR-PCE    |
                         | Controller|
                         +-----------+
                            /
                           /
           PCReq Message  /
         with Metric Type/
                        /                                   +--------+
                       /                                    |IOT Data|
                      /  PCRep Message                      +--------+
                     /   with Segment List                     /Public
                    /                                    MIOT / Cloud
                   /                                  +----- +
             +------+  Policy1: UDP Src Port Xx-Xy   /
             |      A1------------------------------+
             |      |  Policy2: UDP Src Port Yx-Yy    URLLC
     UE------| UPF  A2--------------------------------------------
             | +PE1 |  Policy3: UDP Src Port Zx-Zy
             |      A3-------------------------------+
             |      |                                 \
             +------+                                  +-----+
     {UDP Src Port Num# <--> SR Policy N}                EMBB \
                                                               \
                                                            +--------+
                                                            | Content|
                                                            +--------+
                                                             Private DC

            Figure 4: TN Aware Mobility Traffic Mapping to SR-TE Path

5.3. Extend TN Aware Mobility for RestConf/gRPC based SR-TE Controller

  1) To integrate Transport Network Aware Mobility with SR-TE Policy at
     the Ingress PE UPF, the Class-map needs to be defined to classify
     the incoming mobility traffic with different Transport Path
     Characteristic.

  2) The Ingress PE UPF is assumed to have Restconf or gRPC connection
     with the SR-TE Controller. The Mobility traffic destination would
     resolve in the BGP Peer Next Hop for which SR-TE Policy to be
     applied to maintain the same network characteristics beyond the
     mobility domain.

Majumdar, et al.       Expires October15, 2024                [Page 15]
Internet-Draft      Extension of TN Aware Mobility            July 2023

  3) A new 5G Metadata YANG data model and Protobuf to be defined for
     SR-Policy SAFI with UDP Source Port Range to identify the SR-TE
     path based on the Transport Path characteristics.

  4) The SR-TE Controller would be programmed with {5G UDP Src Port
     Range}. That would create internal mapping Table for {5G UDP Src
     Port Range} < -- > {BGP SR-TE Policy, BSID}.

  5) As the Headend PE sends the 5G metadata Yang data model or
     Protobuf, the Controller will find a matching SR-TE Policy based
     on the UDP Source Port.

  6) The SR-TE Controller would download the SR-TE Policy in the
     Ingress PE through the existing Restconf or gRPC session, and that
     BGP update would include an additional 5G Metadata Sub-TLV. The
     UDP Src Port range in the 5G Metadata Sub-TLV MUST fall within the
     UDP Source Port range for the SSTs defined by the [TN-AWARE-
     MOBILITY] draft. If the UDP Src Port range falls outside the range
     defined by the [TN-AWARE-MOBILITY] draft, then the SR-TE Policy
     SHOULD be ignored by the Ingress PE.

  7) The SR-TE Policy-based traffic steering would be applied in the
     Ingress PE UPF and it would maintain the local mapping for the
     reverse Mobility traffic to the UE.

   The class-map definition to identify the incoming mobility traffic
   characteristics is already defined in Section 5.1. The same class-
   map definition works here as well.

   The below figure tries to capture the overall topology, and how to
   map the mobility traffic in the headend PE having BGP SR-Policy SAFI
   connection with the BGP SR-PCE Controller:

Majumdar, et al.       Expires October15, 2024                [Page 16]
Internet-Draft      Extension of TN Aware Mobility            July 2023

                            +-----------+   +----+{5G UDP Src Port Range}
                            | BGP SR-TE |-->| Map|       <-->
                            | Controller|   | DB |{BGP SR-TE Policy, BSID}
                            +-----------+   +----+
                              /
                             /
                            /
          Restconf or gRPC /
             Session      /                                    +--------+
                         / SR-Policy with                      |IOT Data|
                        /  5G Metadata Sub-TLV                 +--------+
                       /                                         /Public
                      /                                    MIOT / Cloud
                     /                                  +------+
             +-------+  Policy1: UDP Src Port Xx-Xy    /
             |       A1------------------------------ +
             |       |  Policy2: UDP Src Port Yx-Yy     URLLC
     UE------| UPF + A2-------------------------------------------
             | PE1   |  Policy3: UDP Src Port Zx-Zy
             |       A3------------------------------ -+
             |       |                                  \
             +-------+                                   +-----+
     {UDP Src Port Num# <--> SR Policy N}                  EMBB \
                                                                 \
                                                               +--------+
                                                               | Content|
                                                               +--------+
                                                                Private DC

             Figure 5: TN Aware Mobility Traffic Mapping to SR-TE Path

5.4. Extend BGP FlowSpec for TN Aware Mobility

  1) To integrate Transport Network Aware Mobility with SR-TE Policy at
     the ingress PE UPF, the Class-map needs to be defined to classify
     the incoming mobility traffic with different Transport Path
     Characteristic.

  2) The ingress PE UPF acting as BGP FlowSpec Client is assumed to
     have a BGP FlowSpec session with the FlowSpec Controller. The
     Mobility traffic destination would resolve in the BGP Peer Next
     Hop for which SR FlowSpec traffic re-direct policy to be applied
     to maintain the same network characteristics in the data network.

Majumdar, et al.       Expires October15, 2024                [Page 17]
Internet-Draft      Extension of TN Aware Mobility            July 2023

  3) The current proposal tries to integrate FlowSpec Redirect to
     Indirection ID [FLOWSPEC-PATH-REDIRECT] based traffic rules with
     the TN aware mobility traffic based on the UDP Source Port range
     at the FlowSpec Client Router/Ingress PE.

  4) Based on the BGP FlowSpec RFC 8955 the BGP FlowSpec NLRI can carry
     out the UDP Source Port range. The 5G SST specific UDP Source Port
     range values can be pushed over a BGP FlowSpec session between the
     FlowSpec Controller and the Ingress PE node.

  5) No additional changes are required on the BGP FlowSpec side other
     than provisioning 5G SST specific UDP Source Port range at the
     FlowSpec Controller along with the corresponding FlowSpec Redirect
     to indirection-id.

  6) The BGP FlowSpec Controller would be programmed with {5G UDP Src
     Port Range} to map different SSTs defined in [TN-AWARE-MOBILITY]
     draft to map the corresponding FlowSpec Redirect to Indirection-
     id. That would create internal mapping Table for {5G UDP Src Port
     Range} < -- > {BGP FlowSpec Generalized Indirection-ID}.

  7) The BGP FlowSpec NLRI carrying 5G UDP Source Port Range along with
     the corresponding Redirect to indirection-id Extended Community
     can be pushed to the Ingress PE node.

  8) The Mobility traffic coming from the UPF to the ingress PE in the
     Data Network carrying a specific UDP Source Port from UE can be
     classified based on the local Policy and apply the BGP FlowSpec
     based re-direction rule based on the matching FlowSpec policy.

   The class-map definition to identify the incoming mobility traffic
   characteristics is already defined in Section 5.1. The same class-
   map definition works here as well.

   The below figure tries to capture the overall topology, and how to
   map the mobility traffic in the Ingress PE acting as FlowSpec Client
   having BGP FlowSpec SAFI connection with the BGP FlowSpec
   Controller:

Majumdar, et al.       Expires October15, 2024                [Page 18]
Internet-Draft      Extension of TN Aware Mobility            July 2023

                            +-----------+   +----+{5G UDP Src Port Range}
                            |  FlowSpec |-->| Map|       <-->
                            | Controller|   | DB |{Generalized Indirection-ID}
                            +-----------+   +----+
                              /
                             /
                            / BGP FlowSpec NLRI with 5G
              BGP FlowSpec /   UDP Source Port Range
                Session   /                                    +--------+
                         / BGP FlowSpec Redirect               |IOT Data|
                        / Indirection-ID Ext Comm              +--------+
                       /                                         /Public
                      /                                    MIOT / Cloud
                     /                                  +------+
             +-------+ Ind-ID1: UDP Src Port Xx-Xy     /
             |       A1-------------------------------+
             |       | Ind-ID2: UDP Src Port Yx-Yy            URLLC
     UE------| UPF + A2--------------------------------------------
             | PE1   | Ind-ID3: UDP Src Port Zx-Zy
             |       A3-------------------------------+
             |       |                                 \EMBB
             +-------+                                  +-----+
 {UDP Src Port Num# <--> FlowSpec Indirect-ID# ->Transport Hdr} \
                                                                \
                                                               +--------+
                                                               | Content|
                                                               +--------+
                                                                Private DC

                  ---------->
       +------+----------+-------+-----+----------+
       | Data | Inner IP | GTP-U | UDP | Outer IP |
       +------+----------+-------+-----+----------+

                                      ---------->
                     +------+----------+------------------+
                     | Data | Inner IP | Transport Header |
                     +------+----------+------------------+

           Figure 6: TN Aware Mobility Traffic Mapping to FS Redirect Path

Majumdar, et al.       Expires October15, 2024                [Page 19]
Internet-Draft      Extension of TN Aware Mobility            July 2023

6. Mapping of TN Characteristics on SD-WAN Edge Node

     On an SD-WAN CE Node, based on the mobility Transport Network
     characteristics, mapping of mobility aware transport packets to
     the secure and un-secure tunnel path needs to be achieved.

     The [BGP-SDWAN-Discover] draft defines how SD-WAN Edge Node maps
     the overlay/client routes to the underlay secure tunnel routes.

     The current proposal specifies a generic approach on how SD-WAN
     Edge Node maps the Mobility Transport Network aware traffic to the
     Secure Tunnels, or Un-Secure TE Paths, or Secure SR-TE Tunnel
     Paths.

     The [SDWAN-BGP-USAGE] draft describes how BGP can be used as a
     Control Plane for the SD-WAN network and defines the use case for
     the Hybrid SD-WAN network.

     In the case of a hybrid SD-WAN use case, UPF can run part of the
     SD-WAN edge or it could be connected to it over an IP network.
     This would be a use case scenario for Enterprise 5G.

     In that scenario, the Transport Path Characteristic for the 5G
     mobile traffic need to be mapped to Secure (IPSec Tunnel) or Un-
     secure path (could be MPLS based).

     The existing [TN-AWARE-MOBILITY] draft is extended to support new
     Transport Path Characteristics "Security" for the mobile traffic
     where security is important for certain mobile traffic.

     Based on the UDP Src Port characteristics coming from the mobile
     network, the SD-WAN edge node would be able to decide what traffic
     it needs to put in the secure tunnel vs. an un-secure tunnel where
     low latency more important than security.

Majumdar, et al.       Expires October15, 2024                [Page 20]
Internet-Draft      Extension of TN Aware Mobility            July 2023

     The below figure tries to capture the overall topology, and how to
     map the mobility traffic in the SD-WAN Edge Device for Enterprise
     5G cases:

                                 +----------+
                                 |  BGP RR  |
                            +----|Controller|----+
                           /     +----------+     \
                          /                        \           Internet
                         /                          \           /
                        /                            \         /
                       /                              \  URLLC/
                      /                                \     /
                     /                                  \   /
            +-------+  MPLS Path: URLLC Traffic   +------+ /
            |       A1---------------------------B1      |/
            |       |  Secure Path1: MIOT Traffic |      | MIOT +--------+
     UE-----| UPF + A2---------------------------B2 C-PE2|------|IOT Data|
            | C-PE1 |  Secure Path2: EMBB Traffic |      |      +--------+
            |       A3---------------------------B3      |\      Public
            |       |                             |      | \     Cloud
            +-------+                             +------+  \
     {UDP Src Port X <--> MPLS}                              \
     {UDP Src Port Y:Security <--> IPSec SA Identifier}  EMBB \
                                                               \ +-------+
                                                                \|Content|
                                                                 +-------+
                                                                    Public
                                                                    Cloud
                  ---------->
       +------+----------+-------+-----+----------+
       | Data | Inner IP | GTP-U | UDP | Outer IP |
       +------+----------+-------+-----+----------+

                                           ---------->
                         +------+----------+--------------+
                         | Data | Inner IP | IPSec Header |
                         +------+----------+--------------+

    Figure 7: Secure TN Aware Mobility Traffic Mapping in the SD-WAN Edge Device

   Here in this diagram, the traffic coming from the mobility side with
   Transport Network characteristics gets mapped to the underlay un-
   secure or secure traffic path.

Majumdar, et al.       Expires October15, 2024                [Page 21]
Internet-Draft      Extension of TN Aware Mobility            July 2023

   The SD-WAN Edge Node can map the URLLC traffic without any security
   characteristics to the underlay MPLS path, whereas MIOT, and EMBB
   traffic with security characteristics gets mapped to the underlay
   Secure IPSec Tunnel path. The mapping between SD-WAN overlay and
   underlay routes are described in the [BGP-SDWAN-Discovery] draft.

   This solution extends it for Transport Network aware mobility
   traffic. The SD-WAN Edge Node here identifies the incoming mobility
   traffic characteristics using the class-map definition, and that is
   already defined under Section 5.1. Based on the incoming traffic
   characteristics, the Edge Node will be able to map the mobility
   overlay traffic to the respective SD-WAN underlay tunnel.

6.1. SD-WAN Hybrid Use Case with SR-TE Integration

  1) In the case of SD-WAN hybrid use cases, UPF can run part of the
     SD-WAN edge node, or it could be connected to it over an IP
     network. This would be a use case scenario for Enterprise 5G.

  2) The SD-WAN edge node can act as an SR-TE Headend PE in some use
     case scenarios that are described in [SDWAN-BGP-USAGE] draft.

  3) In that case, the Headend PE could be connected with SR-TE Policy
     Controller over the BGP SR-Policy SAFI session, or SR-PCE
     Controller over the PCEP session, or SR-TE Controller over
     Netconf/ Restconf, or GRPC session, or even SR FlowSpec Controller
     over BGP FlowSpec session.

  4) The SD-WAN edge node can map the "Un-secure" mobility traffic to
     the SR-TE path the same way as described under PE acting as
     ingress SR-TE headend.

  5) Though the mapping for "Secure" mobility traffic to the SR-TE path
     would be slightly different than "Un-secure" mobility traffic.

  6) The mobility 5G UE client traffic with the Transport Path
     Characteristics "Security" would be encapsulated with Tunnel mode
     IPSec header between the two SD-WAN SAFI underlay endpoints
     (belong to the same BGP AS domain). This encapsulated secure
     traffic will become the new overlay for the SR-TE traffic.

  7) The rest of the mechanism for the secure mobility traffic with SR-
     TE traffic forwarding is the same as un-secure SR-TE based traffic
     forwarding.

Majumdar, et al.       Expires October15, 2024                [Page 22]
Internet-Draft      Extension of TN Aware Mobility            July 2023

     The below figure tries to capture the overall topology, and how to
     map the mobility traffic in the SD-WAN Edge Device for SD-WAN
     Hybrid Use Cases described above:

                    +-------------+
                    | BGP SR-Based|
                    | Controller  |
                    +-------------+
                         /
                        /
                       /         +----------+
     BGP SR-TE Policy with       |  BGP RR  |
     5G Metadata Sub-TLV    +----|Controller|----+
                     /     /     +----------+     \
                    /     /                        \           Internet
                   /     /                          \           /
                  /     /                            \         /
                 /     /                              \  URLLC/
                /     /                                \     /
               /     /                                  \   /
            +-------+  SR-Pol1: URLLC Traffic     +------+ /
            |       A1---------------------------B1      |/
            |       | SA1,SR-Pol2: MIOT Traffic   |      | MIOT +--------+
     UE-----| UPF + A2---------------------------B2 C-PE2|------|IOT Data|
            | C-PE1 | SA2,SR-Pol3: EMBB Traffic   |      |      +--------+
            |       A3---------------------------B3      |\      Public
            |       |                             |      | \     Cloud
            +-------+                             +------+  \
     {UDP Src Port Num X <--> SR Policy1}                    \
     {UDP Src Port: Security Y, Z <-->                   EMBB \
                    IPSec SA 1,2; SR-TE Policy 2,3}            \ +-------+
                                                                \|Content|
                                                                 +-------+
                                                                    Public
                                                                    Cloud
                  ---------->
       +------+----------+-------+-----+----------+
       | Data | Inner IP | GTP-U | UDP | Outer IP |
       +------+----------+-------+-----+----------+

                                     ---------->
         +------+----------+--------------+-----------+
         | Data | Inner IP | IPSec Header | SR Header |
         +------+----------+--------------+-----------+

   Figure 8: Secure TN Aware Mobility Traffic Mapping for Hybrid SD-WAN Use Case

Majumdar, et al.       Expires October15, 2024                [Page 23]
Internet-Draft      Extension of TN Aware Mobility            July 2023

   In Figure 8, the traffic coming from the mobility side with
   Transport Network characteristics gets mapped to the underlay un-
   secure or secure SR-TE path to maintain the traffic network
   characteristics in the Data Network.

   The SD-WAN Edge Node can map the URLLC traffic without any security
   characteristics to the underlay SR-TE path without any IPSec
   encapsulation. Whereas MIOT and EMBB traffic with the security
   characteristics can be mapped to the underlay Secure IPSec Tunnel
   path with the SR-TE encapsulation to the SD-WAN endpoints.

7. IANA Considerations

   The newly defined 5G Metadata Sub-TLV would need an IANA code point
   allocation for the Type field. A request for any IANA code point
   allocation would be submitted.

8. Security Considerations

    This document does not introduce any new security issues.

9. Contributors

   The following people have contributed to this document.

   Dhruv Dhody
   Huawei Technologies

   Email: dhruv.ietf@gmail.com

10. References

10.1. Normative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

Majumdar, et al.       Expires October15, 2024                [Page 24]
Internet-Draft      Extension of TN Aware Mobility            July 2023

10.2. Informative References

   [RFC5440] JP. Vasseur, Ed., JL. Le Roux, Ed., "Path Computation
   Element (PCE) Communication Protocol (PCEP)", March 2009

   [TN-AWARE-MOBILITY] U. Chunduri, et al, "Transport Network aware
   Mobility for 5G", draft-ietf-dmm-tn-aware-mobility-07, July 2023

   [BGP-SR-TE-POLICY] S. Previdi, et al, "Advertising Segment Routing
   Policies in BGP", draft-ietf-idr-segment-routing-te-policy-16, March
   2022

   [SDWAN-BGP-USAGE] L. Dunber, et al, "BGP Usage for SDWAN Overlay
   Networks", draft-ietf-bess-bgp-sdwan-usage-14, July 2023

   [BGP-SDWAN-Discover] L. Dunber, et al, "BGP UPDATE for SDWAN Edge
   Discovery", draft-ietf-idr-sdwan-edge-discovery-10, June 2023

   [FLOWSPEC-PATH-REDIRECT] G. Van de Velde, K. Patel, Z.Li, "Flowspec
             Indirection-id Redirect", draft-ietf-idr-flowspec-path-
             redirect-12, Nov. 2022.

   [RFC9012] K. Patel, et al, "The BGP Tunnel Encapsulation Attribute",
             April 2021.

11. Acknowledgments

   TBD.

   This document was prepared using 2-Word-v2.0.template.dot.

Majumdar, et al.       Expires October15, 2024                [Page 25]
Internet-Draft      Extension of TN Aware Mobility            July 2023

Majumdar, et al.       Expires October15, 2024                [Page 26]
Internet-Draft      Extension of TN Aware Mobility            July 2023

Authors' Addresses

   Kausik Majumdar
   Microsoft

   Email: kmajumdar@microsoft.com

   Uma Chunduri
   Intel Corporation

   Email: umac.ietf@gmail.com

   Linda Dunbar
   Futurewei

   Email: linda.dunbar@futurewei.com

Majumdar, et al.       Expires October15, 2024                [Page 27]