RTG Working Group K. Majumdar
Internet Draft Microsoft
Intended status: Informational U. Chunduri
Expires: October 12, 2024 Intel
L. Dunbar
Futurewei
September 12, 2023
Extension of Transport Aware Mobility in Data Network
draft-mcd-rtgwg-extension-tn-aware-mobility-08
Abstract
The existing Transport Network Aware Mobility for 5G (TN-AWARE-
MOBILITY) specifies a framework for mapping the 5G mobile systems'
Slice and Service Types (SSTs) to corresponding underlying network
paths to ensure the desired QoS for the services.The focus of (TN-
AWARE-MOBILITY) is limited to the 3GPP domain and doesn't cover the
network for user plane traffic between the UPFs and the services
hosted in data centers.
This document describes the mechanisms to achieve the same QoS for
the mobility traffic from the 3GPP domain to the service
destinations over the IP Data Networks. Extending the QoS guarantee
for the SSTs to the data centers where the services are hosted
becomes necessary to maintain the end-to-end QoS for data plane
traffic between UEs and their corresponding service destinations.
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. [Page 1]
Internet-Draft Extension of TN Aware Mobility September 2023
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) 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. Extending 5G SSTs QoS to Data Network..........................4
4. Mobility Packets Transition to the Data Network................5
5. Transport Network Characteristics Mapping to TE Paths..........8
6. Extend TN Aware Mobility via BGP SR-TE Policy..................9
6.1. TN Aware Mobility Policy Encoding........................11
6.2. Operations of Applying the TN Aware Mobility Policy......12
7. TN Aware Mobility Policies Distribution via PCE Controller....12
8. TN Aware Mobility Policies via NETCONF/RestConf/gRPC..........13
9. Extend BGP FlowSpec for TN Aware Mobility.....................14
10. Mapping of TN Characteristics on SD-WAN Edge Node............14
11. IANA Considerations..........................................16
12. Security Considerations......................................16
13. Contributors.................................................16
14. References...................................................16
14.1. Normative References....................................16
Majumdar, et al. Expires October15, 2024 [Page 2]
Internet-Draft Extension of TN Aware Mobility September 2023
14.2. Informative References..................................17
15. Acknowledgments..............................................18
Authors' Addresses...............................................19
1. Introduction
The [TN-AWARE-MOBILITY] describes the mapping of 5G slices to IP or
Layer 2 transport network for both control plane and data plane
traffic across back-haul, mid-haul, and front-haul segments within
the 3GPP domain [TS.23.501-3GPP]. While the 5G control plane traffic
is end-to-end from UEs, gNB, to the 3GPP specified control functions
(such as Session Management function, Access and Mobility Management
Function, etc.), the data plane traffic management limited to UEs<->
gNB <-> UPFs (user plane functions) is not end-to-end.
As 5G services are processed by their corresponding servers in data
centers through the IP network, achieving the desired QoS for the
data plane traffic between gNBs <-> UPFs by mapping to the
appropriate underlay IP networks is insufficient to ensure the end-
to-end QoS. This draft describes the mechanisms for extending the 5G
Service Slices mapping enforced within the 3GPP domain to the
appropriate IP underlays from UPFs to 5G service destinations,
including RSVP-TE[RFC3209], SRv6[RFC8986], MPLS-TE[RFC3812], and
Preferred Path Routing (PPR) [RTG-PPR]. The goal is to ensure the
end-to-end QoS guarantee for the 5G service slices.
Note: even though the 3GPP domain has underlay data networks
connecting various 3GPP specified functions, the term Data Network
in this document represents the IP data network outside the 3GPP
domain, a.k.a. the N6 interface described in [UPlane-5G-ANA].
2. Conventions used in this document
BSID - Binding SID
DC - Data Center
DN - Data Network [TS.23.501-3GPP]
EMBB - enhanced Mobile Broadband [TS.23.501-3GPP]
Majumdar, et al. Expires October15, 2024 [Page 3]
Internet-Draft Extension of TN Aware Mobility September 2023
gNB - Next Generation NodeB [TS.23.501-3GPP]
GTP-U - GPRS Tunneling Protocol - User Plane [TS.23.501-3GPP]
MIOT - Massive IOT [TS.23.501-3GPP]
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 [TS.23.501-3GPP]
SR - Segment Routing
SR-PCE - SR Path Computation Element
UE - User Equipment
UPF - User Plane Function [TS.23.501-3GPP]
URLLC - Ultra reliable and low latency communications
[TS.23.501-3GPP]
3. Extending 5G SSTs QoS to Data Network
In actual deployment, a UPF can be connected to a C-PE node that
ingresses to the IP network (i.e., the N6 Interface of the 3GPP
domain) or embedded with the C-PE function. The C-PE node can be an
SD-WAN [NET2CLOUD] edge node, L2/L3 VPN [RFC4364] edge node, or SR-
TE [RFC8402] 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.
The proposed mechanisms to extend the 5G SSTs QoS in the Data
Network focuses on the following areas:
Majumdar, et al. Expires October15, 2024 [Page 4]
Internet-Draft Extension of TN Aware Mobility September 2023
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 TE (traffic engineered) path
segments from the IP network controller and map the TE path
segments to the packets from UEs.
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 under Section 4 depicts data from UEs through the UPFs and
C-PEs to the service destinations. In some cases, UPF is integrated
with the C-PE functions.
4. Mobility Packets Transition to the Data Network
As a mobility packet transitioning from the UPF to the C-PE node,
the GTP header is decapsulated, i.e., the UDP port number carried by
the GTP header as specified by the [TN-AWARE-MOBILITY] is no longer
present in the packet. Here are some approaches to classify the
mobility packets when transitioning to the Data Network so that the
appropriate policies can be applied to achieve the same QoS as the
3GPP domain:
A) When the UPF is connected to a C-PE via a direct link (Figure 1
below), the respective application controller needs to pass the
desired QoS policy information to the Data Network's management
system (DN Mgnt) and the 5G Management Plane (NSSMF) [TS.23.501-
3GPP]. In Some deployments, the application controller, 5G NSSMF,
and DN Mgnt belong to one operator. In some deployments, they are
separate entities, thus requiring contract binding for the desired
QoS.
The C-PE can encapsulate the mobility packet from the UPF with
another outer IP header, with the destination address of the outer
header set to the service destination hosted in a remote data center
and the source UDP port number set as [TN-AWARE-MOBILITY. Here is
the packet illustration:
- 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)
Majumdar, et al. Expires October15, 2024 [Page 5]
Internet-Draft Extension of TN Aware Mobility September 2023
- 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) When the 5G Core and the IP Data Network (N6 interface) are
managed by one operator, a UPF can have the embedded C-PE function
(Scenario B of Figure 1). Under this scenario, 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 6]
Internet-Draft Extension of TN Aware Mobility September 2023
Scenario A:
+--(AppCtrl)----+
| |
+--+-----+ +--+---+
| 3GPP | | IP DN|
| NSSMF | | Mgnt |
+----V---+ +--V--+
| |
+----+ +--+--+ +--+--+
UE-----| gNB|-------| UPF |-------| C-PE|------DN
+----+ +-----+ +-- --+
|--- N3 OR N9 -----||---- N6 -----
|------- Mobile Network--||---- IP Data Network ----|
Scenario B:
(AppCtrl)
|
+--------+------+
| 3GPP |IP DN |
| NSSMF | Mgnt |
+--------+------+
|
+-----------+ +--+---+
| | | |
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.
Majumdar, et al. Expires October15, 2024 [Page 7]
Internet-Draft Extension of TN Aware Mobility September 2023
- UE Packet format in the Mobile Network from gNB to the UPF:
+---------+----------+-------+------------+----------+
| UE Data | Inner IP | GTP-U | UDP Header | Outer IP |
+---------+----------+-------+------------+----------+
- 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
The source port in the original UDP header indicates the TN Aware
Mobility SST type.
5. Transport Network Characteristics Mapping to TE Paths
Within the 5G Core [TS.23.501-3GPP], UE traffic is carried by the
GTP tunnels terminated by the UPFs. [TN-AWARE-MOBILITY] specifies
using the GTP 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.
Here are some options in passing the corresponding policies:
Majumdar, et al. Expires October15, 2024 [Page 8]
Internet-Draft Extension of TN Aware Mobility September 2023
Option 1: Assume the ingress C-PE is connected to a BGP SR-TE
Controller through a BGP SR-TE Policy SAFI Session. Section 6
describes the mechanism to map mobility traffic to the BGP SR-TE
Underlay Path Segments based on the mobility transport
characteristics:
Option 2: Assume the ingress C-PE is connected to the PCE (Path
Compute Element) Controller through a PCEP Session, which can pass
the policy to map mobility traffic to the TE underlay paths
[RFC9168] based on the mobility transport characteristics.
Option 3: Assume the ingress C-PE is connected to the TE Controller
over NETCONF/Restconf/ Netconf or gRPC session. The existing
mechanism would be used to download the TE Underlay Path Segments to
the C-PE node based on the mobility transport characteristics.
Option 4: Assume the ingress C-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. [FLOWSPEC-TN-MOBILITY]
specifies BGP FlowSpec extension to disseminate the policies from 5G
mobile networks so that the 5G mobile systems slices and Service
Types (SSTs) can be mapped to optimal underlying network paths in
the data network.
6. Extend TN Aware Mobility via BGP SR-TE Policy
To integrate the 5G Core's transport aware mobility policies with
BGP SR-TE Policy at the Ingress C-PE UPF, a class map needs to be
defined to classify the incoming mobility traffic with different
transport path characteristics.
Assume that the ingress C-PE (embedded in UPF) support the BGP SR-TE
Policy SAFI [BGP-SR-TE-POLICY] and the BGP SR-TE Controller can
compute the SR segments that can satisfy the SLA for the transport
characteristics identified by the 5G UDP SRC Port Range based on the
[TN-AWARE-MOBILITY] draft.
The figure below captures the overall topology and how to map the
mobility traffic on the Ingress C-PE, which has the BGP SR-Policy
SAFI connection with the BGP SR-TE Controller:
Majumdar, et al. Expires October15, 2024 [Page 9]
Internet-Draft Extension of TN Aware Mobility September 2023
+-----------+ +----+{UDP Src Port Range}
| BGP SR-TE |-->| Map| <-->
| Controller| | DB |{BGP SR-TE Policy }
+-----------+ +----+
/
/
/
/
/ +--------+
/ BGP SR-TE Policy with |IOT Data|
/ Mobility-Policy-Transition +--------+
/ /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 |
+------+----------+-------+-----+----------+
---------->
+------+----------+-------------+
| Data | Inner IP | SR Header |
+------+----------+-------------+
Figure 3: TN Aware Mobility Traffic Mapping to BGP SR-TE Policy Path
Note that, the SR Header in the figure above is shown as an
illustrative purpose and the actual outgoing packet format is based
on the BGP SR-TE mechanism (SR-MPLS or SRv6). If the BSID is not
present with the BGP SR-TE Policy, the local ingress C-PE will map
the incoming traffic to the best effort policy map path in the
underlay.
Majumdar, et al. Expires October15, 2024 [Page 10]
Internet-Draft Extension of TN Aware Mobility September 2023
6.1. TN Aware Mobility Policy Encoding
Mobility-Policy-Transition Sub-TLV specified here is to maintain the
policy in the SR-TE network consistent with the 5G Core for the
selective mobility traffic. The Mobility-Policy-Transition Sub-TLV
is one of the Sub-TLVs under the Tunnel Type = 15 (SR Policy) under
the SR-TE Policy NLRI [BGP-SR-TE-POLICY] sent to the relevant
ingress C-PEs.
SR Policy SAFI NLRI: <Distinguisher, Policy-Color, Endpoint>
Attributes:
Tunnel Encapsulation Attribute (23)
Tunnel Type: SR Policy (15)
{other SR policies Sub-TLVs specified in [BGP-SR-TE-POLICY]
Mobility-Policy-Transition Sub-TLV
Suppose a mobility service has multiple instances reachable from
different SR egress routers. In that case, the SR-TE controller
might need to send multiple SR-TE policies, each with one of those
egress addresses in the "Endpoint" field.
The Mobility-Policy-Transition Sub-TLV is optional, only applicable
to the mobility traffic whose destinations match with the prefixes
in the SR Policy NLRI. It MUST NOT appear more than once in the SR-
TE Policy.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Mobility-Policy-Transition Sub-TLV
where:
- Type = Mobility-Policy-Transition: TBD1 by IANA.
- Sub-Type: This field has one of the following values:
0: Reserved.
1: UDP Source Port Range.
2 - 255: Reserved for future use.
- Length: 6 octets.
Majumdar, et al. Expires October15, 2024 [Page 11]
Internet-Draft Extension of TN Aware Mobility September 2023
- 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.
- UDP Src Port Start Value: 2 octets value to define the
staring of the value of the UDP Src Port range.
- UDP Src Port End Value: 2 octets value to define the end
value of the UDP Src Port range.
6.2. Operations of Applying the TN Aware Mobility Policy
The TN Aware Mobility Policy might be based on something other than
the destination or source addresses of the packets from/to UEs
because the 5G's Session Controller manages the UE traffic on a
finer granularity than the IP addresses. In this case, the BGP
UPDATE with the SR-TE Policy SAFI doesn't include the top-level NLRI
[RFC4271], which means that the policy specified by the Mobility-
Policy-Transition Sub-TLV applies to all the mobility traffic from
the 5G N6 Interface (i.e., from the UPFs).
When the TN Aware Mobility Policy is based on UE traffic's
destination addresses, the BGP UPDATE with the SR-TE Policy SAFI
includes the top-level NLRI [RFC4271], which means that the policy
specified by the Mobility-Policy-Transition Sub-TLV only applies to
the mobility traffic with destinations specified in the top-level
NLRI [RFC4271] from the 5G N6 Interface (i.e., from the UPFs).
The ingress nodes compare all the BGP UPDATE messages for the routes
and the SR-TE policies sent from the controller per procedure
described by [RFC9256].
7. TN Aware Mobility Policies Distribution via PCE Controller
To achieve the desired QoS for the mobility traffic via the PCE
Controller, the Ingress C-PE, standalone or embedded within the UPF,
is assumed to support the PCEP communication (PCEP) protocol with
the PCE Controller.
The PCE controller must have the mapping of the mobility traffic
from the GTP tunnels [TS.23.501-3GPP] with the desired transport
path characteristics.
Majumdar, et al. Expires October15, 2024 [Page 12]
Internet-Draft Extension of TN Aware Mobility September 2023
[RFC9168] specifies using the BGP's Flow Specification Rules for
IPv4 [RFC8955] and IPv6 [RFC8956] in PCE Communication Protocol
(PCEP). Section 9 of this document specifies the mechanism of using
UDP Source port filtering in the BGP FlowSpec.
8. TN Aware Mobility Policies via NETCONF/RestConf/gRPC
Assume that the Ingress C-PE UPF has Restconf or gRPC connection
with the TE Controller, the source UDP port YANG Data Model of the
[RFC8519] can be utilized to pass the allowed source UDP ports.
Here is an example using the [RFC8519] specified YANG Data Model:
<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<acls
xmlns="urn:ietf:params:xml:ns:yang:ietf-access-control-list">
<acl>
<name>sample-port-acl</name>
<type>ipv4-acl-type</type>
<aces>
<ace>
<name>rule1</name>
<matches>
<udp>
<source-port>
<lower-port>16384</lower-port>
<upper-port>16387</upper-port>
</source-port>
</udp>
</matches>
<actions>
<forwarding>[TE-Policy]</forwarding>
</actions>
</ace>
</aces>
</acl>
</acls>
</config>
Majumdar, et al. Expires October15, 2024 [Page 13]
Internet-Draft Extension of TN Aware Mobility September 2023
Note: Need to search TE YANG modules to find one that includes the
ACTION of selecting the specified "TE-Policy".
9. Extend BGP FlowSpec for TN Aware Mobility
[FlowSpec-TN-Aware] specifies a BGP Flow Specification (FlowSpec)
extension to disseminate the policies from 5G mobile networks so
that the 5G mobile systems slices and Service Types (SSTs) can be
mapped to optimal underlying network paths in the data network
outside the 5G UPFs which is the N6 interface in 3GPP 5G
Architecture [3GPP TR 23.501].
10. Mapping of TN Characteristics on SD-WAN Edge Node
This section specifies a generic approach for SD-WAN Edge Node to
map the mobility traffic to the appropriate IP data network paths
based on the policies passed from the 5G Core. The existing [TN-
AWARE-MOBILITY] draft is extended to support new Transport Path
Characteristics "Security" for the mobile traffic where security is
important for specific mobile traffic.
Based on the UDP Src Port characteristics from the mobile network,
the SD-WAN edge node can determine which traffic needs to be carried
by a secure tunnel or an un-secure tunnel where low latency is more
important than security.
Majumdar, et al. Expires October15, 2024 [Page 14]
Internet-Draft Extension of TN Aware Mobility September 2023
The below figure tries to capture the overall topology, and how to
map the mobility traffic for Enterprise 5G traffic:
+----------+
| BGP RR |
+----|Controller|--+
/ +----------+ \
/ \ Internet
/ \ |
/ \ |
/ \ URLLC|
/ \ |
/ \ /
+-------+ MPLS Path: URLLC Traffic +----+-+ /
| A1---------------------------B1 |/ MIOT
| | Secure Path1: MIOT Traffic | | +----+
UE-----| UPF + A2---------------------------B2 C-PE2|---|IOT |
| 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 on SD-WAN Edge
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
IPSec Tunnel path. The mapping between SD-WAN overlay and underlay
routes are described in the [BGP-SDWAN-Discovery] draft.
Majumdar, et al. Expires October15, 2024 [Page 15]
Internet-Draft Extension of TN Aware Mobility September 2023
The SD-WAN Edge identifies the incoming mobility traffic
characteristics using the class-map defined in Section 5.1 and
selects the appropriate SD-WAN underlay tunnel.
11. IANA Considerations
No IANA action is needed.
12. Security Considerations
This document does not introduce any new security issues.
13. Contributors
The following people have contributed to this document.
Dhruv Dhody
Huawei Technologies
Email: dhruv.ietf@gmail.com
14. References
14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3209] D. Awduche, et al, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC3209, Dec. 2001.
[RFC5440] JP. Vasseur, Ed., JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", March 2009.
[RFC9012] K. Patel, et al, "The BGP Tunnel Encapsulation Attribute",
April 2021.
Majumdar, et al. Expires October15, 2024 [Page 16]
Internet-Draft Extension of TN Aware Mobility September 2023
[RFC8986] c. Filsfils, et al, "Segment Routing over IPv6 (SRv6)
Network Programming", RFC8986, Feb. 2021.
[RFC9168] D. Dhody, A. Farrel, Z. Li, "Path Computation Element
Communication Protocol (PCEP) Extension for Flow
Specification", RFC9168, Jan. 2022.
14.2. Informative References
[FlowSpec-TN-Aware] L, Dunbar, K. Majumdar, U. Chunduri, "BGP
Dissemination of FlowSpec for Transport Aware Mobility", draft-dmc-
idr-flowspec-tn-aware-mobility-04, July 2023.
[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-23, July
2023
[SDWAN-BGP-USAGE] L. Dunber, et al, "BGP Usage for SDWAN Overlay
Networks", draft-ietf-bess-bgp-sdwan-usage-14, July 2023
[BGP-SDWAN-Discovery] L. Dunbar, 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.
[FLOWSPEC-TN-MOBILITY] L. Dunbar, K. Majumdar, U. Chunduri, "BGP
Dissemination of FlowSpec for Transport Aware Mobility",
draft-dmc-idr-flowspec-tn-aware-mobility-04. July 2023,
Majumdar, et al. Expires October15, 2024 [Page 17]
Internet-Draft Extension of TN Aware Mobility September 2023
[RTG-PPR] U. Chunduri, L. Contreras, M. Bhaskaran, J. Tantsura, and
P. Muley, "Preferred Path Routing Framework", Work in
Progress, draft-chunduri-rtgwg-preferred-path-routing-03,
Nov 2022.
[NET2CLOUD] L. Dunbar, et al, "Dynamic Networks to Hybrid Cloud DCs:
Problem Statement and Mitigation Practices", draft-ietf-
rtgwg-net2cloud-problem-statement-29, Aug. 2023.
[UPlane-Ana-5G] S. Homma, T. Miyasaka, S. Matsushima, and D. Voyer,
"User Plane Protocol and Architectural Analysis on 3GPP 5G
System", Work in Progress, draft-ietf-dmm-5g-
uplaneanalysis-04, 2 November 2020.
15. Acknowledgments
TBD.
This document was prepared using 2-Word-v2.0.template.dot.
Majumdar, et al. Expires October15, 2024 [Page 18]
Internet-Draft Extension of TN Aware Mobility September 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 19]