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