< draft-mcd-rtgwg-extension-tn-aware-mobility-03.txt   draft-mcd-rtgwg-extension-tn-aware-mobility-04.txt >
RTG Working Group K. Majumdar RTG Working Group K. Majumdar
Internet Draft CommScope Internet Draft CommScope
Intended status: Informational U. Chunduri Intended status: Informational U. Chunduri
Expires: October 14, 2022 Intel Expires: October 14, 2022 Intel
L. Dunbar L. Dunbar
Futurewei Futurewei
April 14, 2022 April 14, 2022
Extension of Transport Aware Mobility in Data Network Extension of Transport Aware Mobility in Data Network
draft-mcd-rtgwg-extension-tn-aware-mobility-03 draft-mcd-rtgwg-extension-tn-aware-mobility-04
Abstract Abstract
The existing Transport Network Aware Mobility for 5G [TN-AWARE- The existing Transport Network Aware Mobility for 5G [TN-AWARE-
MOBILITY] draft specifies a framework for mapping the 5G mobile MOBILITY] draft specifies a framework for mapping the 5G mobile
systems Slice and Service Types (SSTs) to corresponding underlying systems Slice and Service Types (SSTs) to corresponding underlying
network paths in IP and Layer 2 Transport networks.The focus of that network paths in IP and Layer 2 Transport networks.The focus of that
work is limited to the mobility domain and transport network work is limited to the mobility domain and transport network
characteristics till the UPF and doesn't go beyond the UPF to the characteristics till the UPF and doesn't go beyond the UPF to the
Data Network. Data Network.
skipping to change at page 2, line 14 skipping to change at page 2, line 14
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on April 23, 2021. This Internet-Draft will expire on April 23, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
skipping to change at page 5, line 39 skipping to change at page 5, line 39
maintaining the same transport characteristics. maintaining the same transport characteristics.
There are two scenarios could happen here: There are two scenarios could happen here:
A) The UPF is not co-located with the C-PE in the same device. A) The UPF is not co-located with the C-PE in the same device.
Based on the local policy the proposed new header format for the Based on the local policy the proposed new header format for the
TN Aware Mobility Packets transitioning from the UPF to the C-PE TN Aware Mobility Packets transitioning from the UPF to the C-PE
device and vice-versa is proposed below: device and vice-versa is proposed below:
. From the UPF to the C-PE Node: . From the UPF to the C-PE Node:
Inner IP Hdr (UE Packet) + New UDP Hdr (Original UDP Src Port) + Inner IP Hdr (UE Packet) + Transport Hdr (Carrying UDP Src Port) +
Outer IP (C-PE Node Address) Outer IP (C-PE Node Address)
. From the C-PE to the UPF Node: . From the C-PE to the UPF Node:
Outer IP (UPF Node Address) + Original UDP Hdr (Original UDP Src Outer IP (UPF Node Address) + Transport Hdr (Carrying UDP Src
Port) + Inner IP Hdr (UE Packet) Port) + Inner IP Hdr (UE Packet)
B) The UPF is co-located with the C-PE in the same device. Based on B) The UPF is co-located with the C-PE in the same device. Based on
the local policy the original UDP Source Port information can be the local policy the original UDP Source Port information can be
passed to the local C-PE node and no new header is needed here. passed to the local C-PE node and no new header is needed here.
The current draft proposes to create a new encapsulation header in The current draft proposes to create a new encapsulation header in
scenario A. At the UPF node, the TN aware mobility UE packet scenario A. At the UPF node, the TN aware mobility UE packet
carrying the original UDP header Source Port information along carrying the original UDP header Source Port information along
with the Inner IP packet to get encapsulated with the outer IP with the Inner IP packet to get encapsulated with the outer IP
skipping to change at page 7, line 13 skipping to change at page 7, line 13
the scenario A. the scenario A.
1. UE Packet format in the Mobile Network to the UPF: 1. UE Packet format in the Mobile Network to the UPF:
+---------+----------+-------+------------+----------+ +---------+----------+-------+------------+----------+
| UE Data | Inner IP | GTP-U | UDP Header | Outer IP | | UE Data | Inner IP | GTP-U | UDP Header | Outer IP |
+---------+----------+-------+------------+----------+ +---------+----------+-------+------------+----------+
2. UE Packet format in the IP Network to the Ingress C-PE Node: 2. UE Packet format in the IP Network to the Ingress C-PE Node:
+---------+----------+----------------+------------+ +---------+----------+------------------+------------+
| UE Data | Inner IP | New UDP Header | C-PE Header| | UE Data | Inner IP | Transport Header | C-PE Header|
+---------+----------+----------------+------------+ +---------+----------+------------------+------------+
Figure 2: UE Packet Transition from Mobile to IP Network Figure 2: UE Packet Transition from Mobile to IP Network
The source port in the original UDP header indicates the TN Aware The source port in the original UDP header indicates the TN Aware
Mobility SST type. Mobility SST type.
5. Transport Network Characteristics Mapping to SR-TE Paths 5. Transport Network Characteristics Mapping to SR-TE Paths
With the 5G Mobile Networking, the UPF would be terminating the With the 5G Mobile Networking, the UPF would be terminating the
mobile connection from the UE. In some Edge Networking scenarios, mobile connection from the UE. In some Edge Networking scenarios,
skipping to change at page 11, line 45 skipping to change at page 11, line 45
| Data | Inner IP | GTP-U | UDP | Outer IP | | Data | Inner IP | GTP-U | UDP | Outer IP |
+------+----------+-------+-----+----------+ +------+----------+-------+-----+----------+
----------> ---------->
+------+----------+-------------+ +------+----------+-------------+
| Data | Inner IP | SR Header | | Data | Inner IP | SR Header |
+------+----------+-------------+ +------+----------+-------------+
Figure 3: TN Aware Mobility Traffic Mapping to BGP SR-TE Policy Path Figure 3: TN Aware Mobility Traffic Mapping to BGP SR-TE Policy Path
[Note: if BSID is not present, traffic can take any 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
Note that, in the above figure the GRE and SR-TE Header is shown as mechanism (SR-MPLS or SRv6) on the Ingress PE. That could be SR-MPLS or
an illustrative purpose and the actual outgoing packet format is SRv6 Header. Though if the BSID is not present with the BGP SR-TE
based on the SR-TE mechanism (SR-MPLS or SRv6) on the Ingress PE. Policy, the local Ingress PE would 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- 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 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 be supported. The proposed BGP SR Policy Encoding from the BGP SR-TE
Policy Controller to the headend PE node is defined below: Policy Controller to the headend PE node is defined below:
SR Policy SAFI NLRI: <Distinguisher, Policy-Color, Endpoint> SR Policy SAFI NLRI: <Distinguisher, Policy-Color, Endpoint>
Attributes: Attributes:
Tunnel Encap Attr (23) Tunnel Encap Attr (23)
Tunnel Type: SR Policy Tunnel Type: SR Policy
skipping to change at page 15, line 4 skipping to change at page 15, line 12
TE Colors with their corresponding metric type. That exists today, TE Colors with their corresponding metric type. That exists today,
and there is no change there. It is captured here to show how TN and there is no change there. It is captured here to show how TN
aware mobility network characteristics get mapped to different TE aware mobility network characteristics get mapped to different TE
metrics through this mechanism. metrics through this mechanism.
Segment-routing traffic-eng Segment-routing traffic-eng
On-demand color <MIOT-10> dynamic On-demand color <MIOT-10> dynamic
Metric Metric
Type te
Type <MIOT>
On-demand color <URLLC-20> dynamic On-demand color <URLLC-20> dynamic
Metric Metric
Type latency Type <URLLC>
On-demand color <EMBB-30> dynamic On-demand color <EMBB-30> dynamic
Metric Metric
Type igp Type <EMBB>
As a result, mobility Transport Network aware of different traffic As a result, mobility Transport Network aware of different traffic
characteristics like MIOT, URLLC, or EMBB get to assigned characteristics like MIOT, URLLC, or EMBB get to assigned
corresponding "te" metric types. To fetch the corresponding SR-TE corresponding "te" metric types. To fetch the corresponding SR-TE
dynamic path from the SR-PCE Controller based on the "te" metric dynamic path from the SR-PCE Controller based on the newly defined
types that exists today. "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 The below figure tries to capture the overall topology, and how to
map the mobility traffic in the headend PE having PCEP connection map the mobility traffic in the headend PE having PCEP connection
with the SR-PCE Controller: with the SR-PCE Controller:
+-----------+ +-----------+
| SR-PCE | | SR-PCE |
| Controller| | Controller|
+-----------+ +-----------+
/ /
skipping to change at page 20, line 27 skipping to change at page 20, line 27
/ MIOT / Cloud / MIOT / Cloud
/ +------+ / +------+
+-------+ Ind-ID1: UDP Src Port Xx-Xy / +-------+ Ind-ID1: UDP Src Port Xx-Xy /
| A1-------------------------------+ | A1-------------------------------+
| | Ind-ID2: UDP Src Port Yx-Yy URLLC | | Ind-ID2: UDP Src Port Yx-Yy URLLC
UE------| UPF + A2-------------------------------------------- UE------| UPF + A2--------------------------------------------
| PE1 | Ind-ID3: UDP Src Port Zx-Zy | PE1 | Ind-ID3: UDP Src Port Zx-Zy
| A3-------------------------------+ | A3-------------------------------+
| | \EMBB | | \EMBB
+-------+ +-----+ +-------+ +-----+
{UDP Src Port Num# <--> FlowSpec Indirect-ID#->Transport Hd} \ {UDP Src Port Num# <--> FlowSpec Indirect-ID# ->Transport Hdr} \
\ \
+--------+ +--------+
| Content| | Content|
+--------+ +--------+
Private DC Private DC
----------> ---------->
+------+----------+-------+-----+----------+ +------+----------+-------+-----+----------+
| Data | Inner IP | GTP-U | UDP | Outer IP | | Data | Inner IP | GTP-U | UDP | Outer IP |
+------+----------+-------+-----+----------+ +------+----------+-------+-----+----------+
----------> ---------->
+------+----------+--------------------+ +------+----------+------------------+
| Data | Inner IP | Transport Header | | Data | Inner IP | Transport Header |
+------+----------+-----+--------------------------+ +------+----------+------------------+
Figure 6: TN Aware Mobility Traffic Mapping to FS Redirect Path Figure 6: TN Aware Mobility Traffic Mapping to FS Redirect Path
6. Mapping of TN Characteristics on SD-WAN Edge Node 6. Mapping of TN Characteristics on SD-WAN Edge Node
On an SD-WAN CE Node, based on the mobility Transport Network On an SD-WAN CE Node, based on the mobility Transport Network
characteristics, mapping of mobility aware transport packets to characteristics, mapping of mobility aware transport packets to
the secure and un-secure tunnel path needs to be achieved. the secure and un-secure tunnel path needs to be achieved.
The [BGP-IPSEC-Discover] draft defines how SD-WAN Edge Node maps The [BGP-IPSEC-Discover] draft defines how SD-WAN Edge Node maps
skipping to change at page 22, line 40 skipping to change at page 22, line 40
\|Content| \|Content|
+-------+ +-------+
Public Public
Cloud Cloud
----------> ---------->
+------+----------+-------+-----+----------+ +------+----------+-------+-----+----------+
| Data | Inner IP | GTP-U | UDP | Outer IP | | Data | Inner IP | GTP-U | UDP | Outer IP |
+------+----------+-------+-----+----------+ +------+----------+-------+-----+----------+
----------> ---------->
+------+----------+-----+------------+ +------+----------+--------------+
| Data | Inner IP | xxx | ESP Header | | Data | Inner IP | IPSec Header |
+------+----------+-----+------------+ +------+----------+--------------+
Figure 7: Secure TN Aware Mobility Traffic Mapping in the SD-WAN Edge Device 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 Here in this diagram, the traffic coming from the mobility side with
Transport Network characteristics gets mapped to the underlay un- Transport Network characteristics gets mapped to the underlay un-
secure or secure traffic path. secure or secure traffic path.
The SD-WAN Edge Node can map the URLLC traffic without any security The SD-WAN Edge Node can map the URLLC traffic without any security
characteristics to the underlay MPLS path, whereas MIOT, and EMBB characteristics to the underlay MPLS path, whereas MIOT, and EMBB
traffic with security characteristics gets mapped to the underlay traffic with security characteristics gets mapped to the underlay
skipping to change at page 24, line 46 skipping to change at page 24, line 46
\|Content| \|Content|
+-------+ +-------+
Public Public
Cloud Cloud
----------> ---------->
+------+----------+-------+-----+----------+ +------+----------+-------+-----+----------+
| Data | Inner IP | GTP-U | UDP | Outer IP | | Data | Inner IP | GTP-U | UDP | Outer IP |
+------+----------+-------+-----+----------+ +------+----------+-------+-----+----------+
----------> ---------->
+------+----------+-----+------------+-----+--------------+ +------+----------+--------------+-----------+
| Data | Inner IP | GRE | ESP Header | GRE | SR-TE Header | | Data | Inner IP | IPSec Header | SR Header |
+------+----------+-----+------------+-----+--------------+ +------+----------+--------------+-----------+
Figure 8: Secure TN Aware Mobility Traffic Mapping for Hybrid SD-WAN Use Case Figure 8: Secure TN Aware Mobility Traffic Mapping for Hybrid SD-WAN Use Case
In Figure 8, the traffic coming from the mobility side with In Figure 8, the traffic coming from the mobility side with
Transport Network characteristics gets mapped to the underlay un- Transport Network characteristics gets mapped to the underlay un-
secure or secure SR-TE path to maintain the traffic network secure or secure SR-TE path to maintain the traffic network
characteristics in the Data Network. characteristics in the Data Network.
The SD-WAN Edge Node can map the URLLC traffic without any security The SD-WAN Edge Node can map the URLLC traffic without any security
characteristics to the underlay SR-TE path without any IPSec characteristics to the underlay SR-TE path without any IPSec
encapsulation. Whereas MIOT and EMBB traffic with the security encapsulation. Whereas MIOT and EMBB traffic with the security
skipping to change at page 25, line 30 skipping to change at page 25, line 30
8. Security Considerations 8. Security Considerations
This document does not introduce any new security issues. This document does not introduce any new security issues.
9. Contributors 9. Contributors
The following people have contributed to this document. The following people have contributed to this document.
Dhruv Dhody Dhruv Dhody
Divyashree Techno Park, Whitefield Huawei Technologies
Bangalore, Karnataka 560066
India
Email: dhruv.ietf@gmail.com Email: dhruv.ietf@gmail.com
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
10.2. Informative References 10.2. Informative References
[RFC5440] JP. Vasseur, Ed., JL. Le Roux, Ed., "Path Computation [RFC5440] JP. Vasseur, Ed., JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", March 2009 Element (PCE) Communication Protocol (PCEP)", March 2009
[TN-AWARE-MOBILITY] U. Chunduri, et al, "Transport Network aware [TN-AWARE-MOBILITY] U. Chunduri, et al, "Transport Network aware
Mobility for 5G", draft-clt-dmm-tn-aware-mobility-07, April 2021 Mobility for 5G", draft-ietf-dmm-tn-aware-mobility-03, March 2022
[BGP-SR-TE-POLICY] S. Previdi, et al, "Advertising Segment Routing [BGP-SR-TE-POLICY] S. Previdi, et al, "Advertising Segment Routing
Policies in BGP", draft-ietf-idr-segment-routing-te-policy-09, Policies in BGP", draft-ietf-idr-segment-routing-te-policy-16, March
November 2020 2022
[SDWAN-BGP-USAGE] L. Dunber, et al, "BGP Usage for SDWAN Overlay [SDWAN-BGP-USAGE] L. Dunber, et al, "BGP Usage for SDWAN Overlay
Networks", draft-dunbar-bess-bgp-sdwan-usage-08, January 2021 Networks", draft-ietf-bess-bgp-sdwan-usage-04, October 2021
[BGP-IPSEC-Discover] L. Dunber, et al, "BGP UPDATE for SDWAN Edge [BGP-IPSEC-Discover] L. Dunber, et al, "BGP UPDATE for SDWAN Edge
Discovery", draft-dunbar-idr-sdwan-edge-discovery-00, January 2021 Discovery", draft-ietf-idr-sdwan-edge-discovery-01, March 2022
[Tunnel-Encap] E. Rosen, et al "The BGP Tunnel Encapsulation [RFC9012] K. Patel, et al, "The BGP Tunnel Encapsulation Attribute",
Attribute", draft-ietf-idr-tunnel-encaps-19, March 2021. April 2021.
11. Acknowledgments 11. Acknowledgments
TBD. TBD.
This document was prepared using 2-Word-v2.0.template.dot. This document was prepared using 2-Word-v2.0.template.dot.
Authors' Addresses Authors' Addresses
Kausik Majumdar Kausik Majumdar
CommScope CommScope
350 W Java Drive, Sunnyvale, CA 94089
Email: kausik.majumdar@commscope.com Email: kausik.majumdar@commscope.com
Uma Chunduri Uma Chunduri
Intel Intel Corporation
2200 Mission College Blvd
Santa Clara, CA 95052
Email: umac.ietf@gmail.com Email: umac.ietf@gmail.com
Linda Dunbar Linda Dunbar
Futurewei Futurewei
2330 Central Expressway
Santa Clara, CA 95050
Email: linda.dunbar@futurewei.com Email: linda.dunbar@futurewei.com
 End of changes. 24 change blocks. 
42 lines changed or deleted 38 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/