[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01 02                                                      
RTG Working Group                                           K. Majumdar
Internet Draft                                                CommScope
Intended status: Informational                              U. Chunduri
Expires: April 30, 2021                                       L. Dunbar
                                                              Futurewei
                                                       October 31, 2020



           Extension of Transport Aware Mobility in Data Network
              draft-mcd-rtgwg-extension-tn-aware-mobility-00

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 in IP and Layer 2 Transport networks.The focus of that
   work is limited to the mobility domain and transport network
   characteristics till the UPF and doesn't go beyond the UPF to the
   Data Network.

   To maintain E2E transport network characteristics the framework
   needs to be extended beyond UPF. This document describes a framework
   for extending the mobility aware transport network characteristics
   from the UPF through the Data Network.

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





xxx, et al.             Expires April 30, 2021                 [Page 1]


Internet-Draft      Extension of TN Aware Mobility         October 2020


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

   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) 2020 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.............8
      5.2. Extend TN Aware Mobility for SR-PCE Controller...........12
      5.3. Extend TN Aware Mobility for SR-TE Controller............15
   6. Mapping of TN Characteristics on SD-WAN Edge Node.............17
   7. IANA Considerations...........................................20
   8. Security Considerations.......................................20
   9. References....................................................20
      9.1. Normative References.....................................20
      9.2. Informative References...................................20
   10. Acknowledgments..............................................21
   Authors' Addresses...............................................22



Majumdar, et al.        Expires April 30, 2021                 [Page 2]


Internet-Draft      Extension of TN Aware Mobility         October 2020


1. Introduction

   The [TN-AWARE-MOBILITY] draft defines the transport path
   characteristics in backhaul, midhaul, and fronthaul segments between
   the radio side network functions and user plane functions (UPF). It
   describes how various transport network underlay routing mechanisms
   apply to the framework laid out including RSVP-TE, SR, and also a
   data plane agnostic integrated routing and TE mechanism - Preferred
   Path Routing (PPR) to map the network slice properties into the
   IP/L2 transport network.

   The current [TN-AWARE-MOBILITY] draft doesn't extend the transport
   network characteristics from the UPF through the Data Network. If
   the user service termination happens in the data network, the
   Transport Path Network characteristics through the Data Network
   would be lost.

   This proposed Extension of Transport Aware Mobility in Data Network
   extends the mobility aware transport network characteristics from
   the UPF through the Data Network.

   The UPF can be placed on the edge of the network where it can
   perform entry or exit point to the Data Network. It can connect to a
   Provider Edge node as well and bring all the mobile connections in a
   distributed way to the Data Network.

   The UPF can as well connect to the SD-WAN edge node or L3 aggregator
   device and would try to bring all the 5G mobility connections for
   small, medium, and large enterprises. This would be a scenario for
   Enterprise 5G.

   The current draft proposes mechanisms on how mobility aware
   transport network characteristics to be mapped into SR-TE paths or
   Un-secure, Secure, Secure SR-TE paths based in the Data Network on
   different use cases scenarios.

2. Conventions used in this document

   BSID       - Binding SID

   DC         - Data Center


Majumdar, et al.        Expires April 30, 2021                 [Page 3]


Internet-Draft      Extension of TN Aware Mobility         October 2020


   DN         - Data Network (5G)

   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 solution focuses on the following areas:

  a) The Mobility packet transition in and out from the UPF to the C-PE
     Node maintaining the Transport Path Characteristics.

  b) On a PE node, based on the transport characteristics, use
     different methods of fetching SR-TE path segments from the SR-TE



Majumdar, et al.        Expires April 30, 2021                 [Page 4]


Internet-Draft      Extension of TN Aware Mobility         October 2020


     Controller and map the SR-TE segments with the mobility aware
     transport packets.

  c) On an SD-WAN CE Node, based on the transport characteristics,
     mapping of mobility aware transport packets to the secure and un-
     secure tunnel path.

  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 PE or C-PE (in SDWAN case) node, the Mobility
     Transport Characteristics need to be maintained in the Data
     Network. The current solution proposes a generic approach to how
     the mobility packet transition can happen in the Data Network
     maintaining the same transport characteristics. Whether the UPF
     would be co-located with the C-PE in the same device or sitting in
     a different device the approach would be the same.

     The current solution proposes to create a new encapsulation header
     at the UPF node carrying the original UDP header along with the
     Inner IP to get encapsulated with the outer IP header of the
     outgoing C-PE node IP address.

       . Format of the new Header from the UPF to the C-PE Node:
     Outer IP (C-PE Node Address) + Original UDP + Inner IP (UE Packet)

       . Format of the new Header from C-PE to the UPF Node:
     Outer IP (UPF Node Address) + Original UDP + Inner IP (UE Packet)

     There are two possible scenarios of how UPF would be connected to
     the C-PE node.

     In different edge networking deployment, the virtual UPF could be
     co-located with the C-PE node in the same device and that is
     captured under scenario 1. The other scenario is where UPF would
     be separated physically from the C-PE node over an IP network, and
     that is captured under Scenario 2.




Majumdar, et al.        Expires April 30, 2021                 [Page 5]


Internet-Draft      Extension of TN Aware Mobility         October 2020


     In Scenario 1, the UDP source port information coming from the
     mobility domain can be passed to the C-PE node locally through
     some policy defined in the device. It doesn't require to form an
     IP packet with the UDP source port info to send it to the
     physically separated C-PE node. Figure 2 is applicable for
     Scenario 2, where UPF needs to forward the IP packet with the
     original UDP source port information to the physically separated
     C-PE node.



     Scenario 1:

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

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

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



     Scenario 2:

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

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

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

                  Figure 1: Mobile and IP Data Network for UE











Majumdar, et al.        Expires April 30, 2021                 [Page 6]


Internet-Draft      Extension of TN Aware Mobility         October 2020


       1. UE Packet in the Mobile Network:

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

       2. UE Packet in the IP Network:

       +---------+----------+--------------+---------+
       | UE Data | Inner IP | Original UDP | C-PE IP |
       +---------+----------+--------------+---------+

            Figure 2: UE Packet Transition from Mobile to IP Network



5. Transport Network Characteristics Mapping to SR-TE Paths

     With the 5G Mobile Networking, the UPF would be terminating the
     mobile connection from the UE. In some Edge Networking scenarios,
     the UPF would be co-located with the C-PE or it would be connected
     to the C-PE node over IP Network.

     The 5G UE traffic coming to the UPF might be carrying Transport
     Network Characteristics. In that scenario, there would be a need
     to maintain Transport Path Characteristic through the core of the
     network so that end to end SLA can be maintained for the UE
     traffic.

     In scenarios where ingress PE acting as SR-TE node, the mapping of
     Transport Network Aware Mobility {5G UDP Src Port Range} to {BGP
     SR-TE Policy, BSID} to be done at the ingress PE. Once this
     mapping is done, the mobility Transport Path Characteristics can
     be maintained in the data network.

     On a PE node, based on the transport characteristics, the current
     solution proposes different methods of applying SR-TE path
     segments:

     Scenario 1: In this scenario, the assumption is that the Ingress
     PE node is connected to the BGP SR-TE Controller through the BGP
     SR-TE Policy SAFI Session, then this solution defines a mechanism
     to map the BGP SR-TE Underlay Path Segments based on the Mobility
     Transport Characteristics.





Majumdar, et al.        Expires April 30, 2021                 [Page 7]


Internet-Draft      Extension of TN Aware Mobility         October 2020


       . This mechanism would require a new BGP Sub-TLV as part of the
          existing SR Policy SAFI NLRI to download SR-TE Policies
          corresponds to the mobility Transport Path characteristics.
          If the TN aware mobility packet UDP Source Port value falls
          within the UDP Src Port range value of this Sub-TLV, then the
          pre-downloaded SR-TE Policy MUST be applied on the mobility
          traffic to map to the correct network slice in the Data
          Network. Once the Policy is fetched it would be cached by the
          PE node for operating in-line for the subsequent mobility TN
          aware packets.

     Scenario 2: In this scenario, the assumption is that the Ingress
     PE node is connected to the SR-PCE (Path Compute Element)
     Controller through the PCEP Session, then this draft defines a
     mechanism to map the SR-TE Underlay Segments based on the Mobility
     Transport Characteristics.

       . Currently, this mechanism does not require new encoding in
          the PCEP based communication, though it needs local
          Configuration in the PE node to request the SR-TE Paths from
          the PCEP based Controller based on on-demand TN aware
          mobility traffic.

     Scenario 3: In this scenario, the assumption is that the Ingress
     PE node 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.


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



Majumdar, et al.        Expires April 30, 2021                 [Page 8]


Internet-Draft      Extension of TN Aware Mobility         October 2020


     classify the incoming mobility traffic with different Transport
     Path Characteristic.

  2) The Ingress PE 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

        Match UDP Src Port Range Zx - Zy




Majumdar, et al.        Expires April 30, 2021                 [Page 9]


Internet-Draft      Extension of TN Aware Mobility         October 2020


   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------------------------------B1     |/
             |      |  Policy2: UDP Src Port Yx-Yy  |      | URLLC
     UE------| UPF  A2------------------------------B2 PE2 |------Internet
             | +PE1 |  Policy3: UDP Src Port Zx-Zy  |      |
             |      A3------------------------------B3     |\
             |      |                               |      | \
             +------+                               +------+  \
     {UDP Src Port Num# <--> SR Policy N}                 EMBB \
                                                                \
                                                              +--------+
                                                              | Content|
                                                              +--------+
           ---------->                                         Private DC
       +------+----------+-------+-----+----------+
       | Data | Inner IP | GTP-U | UDP | Outer IP |
       +------+----------+-------+-----+----------+

                                      ---------->
                     +------+----------+-----+--------------+
                     | Data | Inner IP | GRE | SR-TE Header |
                     +------+----------+-----+--------------+

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



Majumdar, et al.        Expires April 30, 2021                [Page 10]


Internet-Draft      Extension of TN Aware Mobility         October 2020




  Note that, in the above figure the GRE and SR-TE Header is shown as
  an illustrative purposes and the actual outgoing packet format is
  based on the SR-TE mechanism (SR-MPLS or SRv6) on the Ingress PE.

  To support the Transport Network Mobility Traffic Mapping to BGP SR-
  TE Policy Path in the headend PE, a new 5G Metadata Sub-TLV needs to
  be supported. 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.


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








Majumdar, et al.        Expires April 30, 2021                [Page 11]


Internet-Draft      Extension of TN Aware Mobility         October 2020


   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.


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.


Majumdar, et al.        Expires April 30, 2021                [Page 12]


Internet-Draft      Extension of TN Aware Mobility         October 2020


  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>

       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


Majumdar, et al.        Expires April 30, 2021                [Page 13]


Internet-Draft      Extension of TN Aware Mobility         October 2020


   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 te

     On-demand color <URLLC-20> dynamic

        Metric

          Type latency

     On-demand color <EMBB-30> dynamic

        Metric

          Type igp

   As a result, mobility Transport Network aware 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 "te" metric
   types exists today.

   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 April 30, 2021                [Page 14]


Internet-Draft      Extension of TN Aware Mobility         October 2020


                         +-----------+
                         | 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-----------------------------B1     |/
             |      |  Policy2: UDP Src Port Yx-Yy  |     | URLLC
     UE------| UPF  A2-----------------------------B2 PE2 |------Internet
             | +PE1 |  Policy3: UDP Src Port Zx-Zy  |     |
             |      A3-----------------------------B3     |\
             |      |                               |     | \
             +------+                               +-----+  \
     {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 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 Headend 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 April 30, 2021                [Page 15]


Internet-Draft      Extension of TN Aware Mobility         October 2020


  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 April 30, 2021                [Page 16]


Internet-Draft      Extension of TN Aware Mobility         October 2020


                            +-----------+   +----+{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------------------------------B1     |/
             |       |  Policy2: UDP Src Port Yx-Yy   |     | URLLC
     UE------| UPF + A2------------------------------B2 PE2 |------Internet
             | PE1   |  Policy3: UDP Src Port Zx-Zy   |     |
             |       A3------------------------------B3     |\
             |       |                                |     | \
             +-------+                                +-----+  \
     {UDP Src Port Num# <--> SR Policy N}                  EMBB \
                                                                 \
                                                               +--------+
                                                               | Content|
                                                               +--------+
                                                                Private DC


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



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



Majumdar, et al.        Expires April 30, 2021                [Page 17]


Internet-Draft      Extension of TN Aware Mobility         October 2020


     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 node 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 needs to be 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. un-secure tunnel where
     low latency more important than security.




























Majumdar, et al.        Expires April 30, 2021                [Page 18]


Internet-Draft      Extension of TN Aware Mobility         October 2020


     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 Num X <--> MPLS}                          \
     {UDP Src Port Num Y <--> IPSec SA Identifier}       EMBB \
                                                               \ +-------+
                                                                \|Content|
                                                                 +-------+
                                                                    Public
                                                                    Cloud

       Figure 6: 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.

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



Majumdar, et al.        Expires April 30, 2021                [Page 19]


Internet-Draft      Extension of TN Aware Mobility         October 2020


   characteristics, the Edge Node will be able to map the mobility
   overlay traffic with the SD-WAN underlay tunnel.

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


9.1. Normative References

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


9.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-clt-dmm-tn-aware-mobility-07, April 2021



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



   [SDWAN-BGP-USAGE] L. Dunber, et al, "BGP Usage for SDWAN Overlay
   Networks", draft-dunbar-bess-bgp-sdwan-usage-08, January 2021




Majumdar, et al.        Expires April 30, 2021                [Page 20]


Internet-Draft      Extension of TN Aware Mobility         October 2020


   [BGP-IPSEC-Discover] L. Dunber, et al, "BGP UPDATE for SDWAN Edge
   Discovery", draft-dunbar-idr-sdwan-edge-discovery-00, January 2021



   [Tunnel-Encap] E. Rosen, et al "The BGP Tunnel Encapsulation
             Attribute", draft-ietf-idr-tunnel-encaps-19, March 2021.



10. Acknowledgments

   TBD.

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































Majumdar, et al.        Expires April 30, 2021                [Page 21]


Internet-Draft      Extension of TN Aware Mobility         October 2020


Authors' Addresses

   Kausik Majumdar
   CommScope
   350 W Java Drive, Sunnyvale, CA 94089

   Email: kausik.majumdar@commscope.com

   Uma Chunduri
   Futurewei
   2330 Central Expressway
   Santa Clara, CA  95050

   Email: umac.ietf@gmail.com


   Linda Dunbar
   Futurewei
   2330 Central Expressway
   Santa Clara, CA  95050

   Email: linda.dunbar@futurewei.com
























Majumdar, et al.        Expires April 30, 2021                [Page 22]