idnits 2.17.1 draft-mcd-rtgwg-extension-tn-aware-mobility-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 40 instances of too long lines in the document, the longest one being 11 characters in excess of 72. ** The abstract seems to contain references ([TN-AWARE-MOBILITY]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 12, 2021) is 1017 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'FLOWSPEC-PATH-REDIRECT' is mentioned on line 729, but not defined == Missing Reference: 'BGP-IPSEC-Discovery' is mentioned on line 892, but not defined == Unused Reference: 'RFC2119' is defined on line 1015, but no explicit reference was found in the text == Unused Reference: 'Tunnel-Encap' is defined on line 1036, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-clt-dmm-tn-aware-mobility-07 == Outdated reference: A later version (-26) exists of draft-ietf-idr-segment-routing-te-policy-09 == Outdated reference: A later version (-04) exists of draft-dunbar-idr-sdwan-edge-discovery-00 == Outdated reference: A later version (-22) exists of draft-ietf-idr-tunnel-encaps-19 Summary: 2 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 RTG Working Group K. Majumdar 2 Internet Draft CommScope 3 Intended status: Informational U. Chunduri 4 Expires: October 12, 2022 Intel 5 L. Dunbar 6 Futurewei 7 July 12, 2021 9 Extension of Transport Aware Mobility in Data Network 10 draft-mcd-rtgwg-extension-tn-aware-mobility-02 12 Abstract 14 The existing Transport Network Aware Mobility for 5G [TN-AWARE- 15 MOBILITY] draft specifies a framework for mapping the 5G mobile 16 systems Slice and Service Types (SSTs) to corresponding underlying 17 network paths in IP and Layer 2 Transport networks.The focus of that 18 work is limited to the mobility domain and transport network 19 characteristics till the UPF and doesn't go beyond the UPF to the 20 Data Network. 22 To maintain E2E transport network characteristics the framework 23 needs to be extended beyond UPF. This document describes a framework 24 for extending the mobility aware transport network characteristics 25 from the UPF through the Data Network. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six 38 months and may be updated, replaced, or obsoleted by other documents 39 at any time. It is inappropriate to use Internet-Drafts as 40 reference material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html 47 This Internet-Draft will expire on April 23, 2021. 49 Copyright Notice 51 Copyright (c) 2021 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with 59 respect to this document. Code Components extracted from this 60 document must include Simplified BSD License text as described in 61 Section 4.e of the Trust Legal Provisions and are provided without 62 warranty as described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction...................................................3 67 2. Conventions used in this document..............................4 68 3. Framework for Extension of Transport Network Aware Mobility....4 69 4. Mobility Packet Transition to the Data Network.................5 70 5. Transport Network Characteristics Mapping to SR-TE Paths.......7 71 5.1. Extend TN Aware Mobility for BGP SR-TE Policy.............9 72 5.2. Extend TN Aware Mobility for SR-PCE Controller...........13 73 5.3. Extend TN Aware Mobility for RestConf/gRPC based SR-TE 74 Controller....................................................16 75 5.4. Extend BGP FlowSpec for TN Aware Mobility................18 76 6. Mapping of TN Characteristics on SD-WAN Edge Node.............21 77 6.1. SD-WAN Hybrid Use Case with SR-TE Integration............23 78 7. IANA Considerations...........................................25 79 8. Security Considerations.......................................25 80 9. Contributors..................................................25 81 10. References...................................................25 82 10.1. Normative References....................................25 83 10.2. Informative References..................................26 84 11. Acknowledgments..............................................26 85 Authors' Addresses...............................................28 87 1. Introduction 89 The [TN-AWARE-MOBILITY] draft defines the transport path 90 characteristics in backhaul, midhaul, and fronthaul segments between 91 the radio side network functions and user plane functions (UPF). It 92 describes how various transport network underlay routing mechanisms 93 apply to the framework laid out including RSVP-TE, SR, and also a 94 data plane agnostic integrated routing and TE mechanism - Preferred 95 Path Routing (PPR) to map the network slice properties into the 96 IP/L2 transport network. 98 The current [TN-AWARE-MOBILITY] draft doesn't extend the transport 99 network characteristics from the UPF through the Data Network. If 100 the user service termination happens in the data network, the 101 Transport Path Network characteristics through the Data Network 102 would be lost. 104 This proposed Extension of Transport Aware Mobility in Data Network 105 extends the mobility aware transport network characteristics from 106 the UPF through the Data Network. 108 The UPF can be placed on the edge of the network where it can 109 perform entry or exit point to the Data Network. It can connect to a 110 Provider Edge node as well and bring all the mobile connections in a 111 distributed way to the Data Network. 113 The UPF can as well connect to the SD-WAN edge node or L3 aggregator 114 device and would try to bring all the 5G mobility connections for 115 small, medium, and large enterprises. This would be a scenario for 116 Enterprise 5G. 118 The current draft proposes mechanisms on how mobility aware 119 transport network characteristics to be mapped into SR-TE paths or 120 Un-secure, Secure, Secure SR-TE paths based in the Data Network on 121 different use cases scenarios. 123 2. Conventions used in this document 125 BSID - Binding SID 127 DC - Data Center 129 DN - Data Network (5G) 131 EMBB - enhanced Mobile Broadband (5G) 133 gNB - 5G NodeB 135 GTP-U - GPRS Tunneling Protocol - Userplane (3GPP) 137 MIOT - Massive IOT (5G) 139 PECP - Path Computation Element (PCE) Communication Protocol 141 SD-WAN - Software-Defined Wide Area Network 143 SID - Segment Identifier 145 SLA - Service Layer Agreement 147 SST - Slice and Service Types (5G) 149 SR - Segment Routing 151 SR-PCE - SR Path Computation Element 153 UE - User Equipment 155 UPF - User Plane Function (5G) 157 URLLC - Ultra reliable and low latency communications (5G) 159 3. Framework for Extension of Transport Network Aware Mobility 161 Architecture wise, the proposed Extension of Transport Aware 162 Mobility in the Data Network solution focuses on the following areas: 164 a) The Mobility packet transition in and out from the UPF to the C-PE 165 Node maintaining the Transport Path Characteristics. 167 b) On a PE node, based on the transport characteristics, use 168 different methods of fetching SR-TE path segments from the SR-TE 169 Controller and map the SR-TE segments with the mobility aware 170 transport packets. 172 c) On an SD-WAN CE Node, based on the transport characteristics, 173 mapping of mobility aware transport packets to the secure and un- 174 secure tunnel path. 176 Figure 1 captured under Section 4 provides the representation of a 177 network on how UE could be connected to the UPF and C-PE nodes in the 178 Data Network. The C-PE node represents a combined CE and PE node. In 179 some cases, UPF would be connected to the pure PE or CE node. 181 4. Mobility Packet Transition to the Data Network 183 As the Transport Aware Mobility packets transition in and out from 184 the UPF to the PE or C-PE (in SDWAN case) node, the Mobility 185 Transport Characteristics need to be maintained in the Data 186 Network. The current solution proposes a generic approach to how 187 the mobility packet transition can happen in the Data Network 188 maintaining the same transport characteristics. 190 There are two scenarios could happen here: 192 A) The UPF is not co-located with the C-PE in the same device. 193 Based on the local policy the proposed new header format for the 194 TN Aware Mobility Packets transitioning from the UPF to the C-PE 195 device and vice-versa is proposed below: 197 . From the UPF to the C-PE Node: 198 Inner IP Hdr (UE Packet) + Transport Hdr (Carrying UDP Src Port) + 199 Outer IP (C-PE Node Address) 201 . From the C-PE to the UPF Node: 202 Outer IP (UPF Node Address) + Transport Hdr (Carrying UDP Src 203 Port) + Inner IP Hdr (UE Packet) 205 B) The UPF is co-located with the C-PE in the same device. Based on 206 the local policy the original UDP Source Port information can be 207 passed to the local C-PE node and no new header is needed here. 209 The current draft proposes to create a new encapsulation header in 210 scenario A. At the UPF node, the TN aware mobility UE packet 211 carrying the original UDP header Source Port information along 212 with the Inner IP packet to get encapsulated with the outer IP 213 header of the outgoing C-PE node IP address. 215 In below Figure 1, both scenarios are captured. Scenario A 216 captures the UPF is physically separated from the C-PE node over 217 an IP network. Scenario B captures the edge networking deployment. 218 In that case, the virtual UPF could be co-located with the 219 physical C-PE node in the same device. 221 Scenario A: 223 +-----------+ +-----+ +-----+ 224 | | | | | | 225 UE---------| gNB-CU(UP)|-------| UPF |-------| C-PE|------DN 226 | | | | | | 227 +-----------+ +-----+ +-- --+ 229 |--- N3 OR N9 ---||---- N6 ----| 231 |-------- Mobile Network -------||------ IP Network ------| 233 Scenario B: 235 +-----------+ +------+ 236 | | | | 237 UE---| gNB-CU(UP)|------| UPF +|--------DN------- 238 | | | C-PE | 239 +-----------+ +------+ 241 |- N3 OR N9 -||----N6 -------------| 243 |------ Mobile Network ----||-- IP Network-------| 245 Figure 1: Mobile and IP Data Network for UE 247 The Figure 2 captures the TN Aware Mobility packet format under 248 the scenario A. 250 1. UE Packet format in the Mobile Network to the UPF: 252 +---------+----------+-------+------------+----------+ 253 | UE Data | Inner IP | GTP-U | UDP Header | Outer IP | 254 +---------+----------+-------+------------+----------+ 256 2. UE Packet format in the IP Network to the Ingress C-PE Node: 258 +---------+----------+------------------+------------+ 259 | UE Data | Inner IP | Transport Header | C-PE Header| 260 +---------+----------+------------------+------------+ 262 Figure 2: UE Packet Transition from Mobile to IP Network 264 The source port in the original UDP header indicates the TN Aware 265 Mobility SST type. 267 5. Transport Network Characteristics Mapping to SR-TE Paths 269 With the 5G Mobile Networking, the UPF would be terminating the 270 mobile connection from the UE. In some Edge Networking scenarios, 271 the virtual UPF would be co-located with the C-PE or it would be 272 connected to the C-PE node over IP Network. 274 The 5G UE traffic coming to the UPF might be carrying Transport 275 Network Characteristics. In that scenario, there would be a need 276 to maintain the Transport Path Characteristic through the core of 277 the network so that end to end SLA can be maintained for the UE 278 traffic. 280 In scenarios, where ingress PE acting as SR-TE node, the mapping 281 of Transport Network Aware Mobility {5G UDP Src Port Range} to 282 {BGP SR-TE Policy, BSID} to be done at the ingress PE. Once this 283 mapping is done, the mobility Transport Path Characteristics can 284 be maintained in the data network. 286 On a PE node, based on the transport characteristics, the current 287 solution proposes different methods of applying SR-TE path 288 segments: 290 Scenario 1: In this scenario, the assumption is that the Ingress 291 PE node is connected to the BGP SR-TE Controller through the BGP 292 SR-TE Policy SAFI Session. This solution defines a mechanism to 293 map the BGP SR-TE Underlay Path Segments based on the Mobility 294 Transport Characteristics. 296 . This mechanism would require a new BGP Sub-TLV as part of the 297 existing SR Policy SAFI NLRI to download SR-TE Policies 298 corresponds to the mobility Transport Path characteristics. 299 If the TN aware mobility packet UDP Source Port value falls 300 within the UDP Src Port range value of this Sub-TLV, then the 301 pre-downloaded SR-TE Policy MUST be applied on the mobility 302 traffic to map to the correct network slice in the Data 303 Network. Once the Policy is fetched it would be cached by the 304 PE node for operating in line with the subsequent mobility TN 305 aware packets. 307 Scenario 2: In this scenario, the assumption is that the Ingress 308 PE node is connected to the SR-PCE (Path Compute Element) 309 Controller through the PCEP Session. This draft defines a 310 mechanism to map the SR-TE Underlay Segments based on the Mobility 311 Transport Path Characteristics. 313 . Currently, this mechanism does not require new encoding in 314 the PCEP based communication, though it needs local 315 Configuration in the PE node to request the SR-TE Paths from 316 the PCEP based Controller based on on-demand TN aware 317 mobility traffic metric types. 319 Scenario 3: In this scenario, the assumption is that the Ingress 320 PE node is connected to the SR-TE Controller over Restconf/ 321 Netconf or gRPC session. The existing mechanism would be used to 322 download the SR-TE Underlay Path Segments to the PE node based on 323 the Mobility Transport Path Characteristics. 325 . The Yang Data Model or Protobuf definition is required to 326 define a new Sub-TLV like Scenario 1. The SR-TE Controller 327 would pre-download the SR-TE Policies with the new Sub-TLV in 328 the Ingress PE using the existing session. Once the specific 329 SR-TE Policy is fetched, it would be cached by the Ingress PE 330 to apply for the mobility TN aware traffic in-line to 331 maintain the network characteristics in the Data Network. 333 Scenario 4: In this scenario, the assumption is that the Ingress 334 PE node is connected to the BGP SR FlowSpec Controller through the 335 BGP FlowSpec Session. This draft defines a mechanism to map the 336 FlowSpec redirect to indirection-id community-based SR Traffic 337 rules to the Mobility Transport Path Characteristics. 339 . Currently, this mechanism does not require any new encoding 340 in the BGP SR FlowSpec path redirect draft [FLOWSPEC-PATH- 341 REDIRECT], though it needs local Configuration in the Ingress 342 PE node that is acting as BGP FlowSpec Client to map the 343 Mobility traffic based on the SR FlowSpec traffic re- 344 direction rules. 346 5.1. Extend TN Aware Mobility for BGP SR-TE Policy 348 1) To integrate Transport Network Aware Mobility with BGP SR-TE 349 Policy at the Ingress PE UPF, the Class-map needs to be defined to 350 classify the incoming mobility traffic with different Transport 351 Path Characteristic. 353 2) The Ingress PE UPF is assumed to have a BGP SR-TE Policy SAFI 354 connection with the BGP SR-TE Controller. The Mobility traffic 355 destination would resolve in the BGP Peer Next Hop for which SR-TE 356 Policy to be applied to maintain the same network characteristics 357 beyond the mobility domain. 359 3) A new 5G Metadata Sub-TLV has been defined for existing SR-Policy 360 SAFI with the UDP Source Port Range to identify the SR-TE path 361 based on the Transport Path characteristics. 363 4) The BGP SR-TE Controller would be programmed with {5G UDP Src Port 364 Range}. That would create internal mapping Table for {5G UDP Src 365 Port Range} < -- > {BGP SR-TE Policy, BSID}. 367 5) The BGP SR-TE Controller would download the SR-TE Policy in the 368 Ingress PE through the existing BGP SR-Policy SAFI session, and 369 that the BGP update would include an additional 5G Metadata Sub- 370 TLV. The UDP Src Port range in the 5G Metadata Sub-TLV MUST fall 371 within the UDP Source Port range for the SSTs defined by the [TN- 372 AWARE-MOBILITY] draft. If the UDP Src Port range falls outside the 373 range defined by the [TN-AWARE-MOBILITY] draft, then the SR-TE 374 Policy SHOULD be ignored by the Ingress PE. 376 6) The SR-TE Policy-based traffic steering would be applied in the 377 Ingress PE and it would maintain the local mapping for the reverse 378 Mobility traffic to the UE. 380 The following class-map definition needs to be applied in the 381 headend PE for the incoming Transport Network aware mobility traffic 382 path: 384 Class-map type traffic match MIOT 386 Match UDP Src Port Range Xx - Xy 388 Class-map type traffic match URLLC 390 Match UDP Src Port Range Yx - Yy 392 Class-map type traffic match EMBB 394 Match UDP Src Port Range Zx - Zy 396 The class-map would help to identify the incoming mobility traffic 397 characteristics. Based on these characteristics the headend PE would 398 be able to map the Transport Network aware mobility traffic to the 399 appropriate BGP SR-TE Policy path over the Data Network to reach the 400 UE's destination. 402 The below figure tries to capture the overall topology, and how to 403 map the mobility traffic in the Ingress PE having BGP SR-Policy SAFI 404 connection with the BGP SR-TE Controller: 406 +-----------+ +----+{5G UDP Src Port Range} 407 | BGP SR-TE |-->| Map| <--> 408 | Controller| | DB |{BGP SR-TE Policy, BSID} 409 +-----------+ +----+ 410 / 411 / 412 / 413 / 414 / +--------+ 415 / BGP SR-TE Policy with |IOT Data| 416 / 5G Metadata Sub-TLV +--------+ 417 / /Public 418 / MIoT / Cloud 419 / +------+ 420 +------+ Policy1: UDP Src Port Xx-Xy / 421 | A1-------------------------------+ 422 | | Policy2: UDP Src Port Yx-Yy URLLC 423 UE------| UPF A2----------------------------------------- 424 | +PE1 | Policy3: UDP Src Port Zx-Zy 425 | A3------------------------------+ 426 | | \ 427 +------+ +-------+ 428 {UDP Src Port Num# <--> SR Policy N} eMBB \ 429 \ 430 +--------+ 431 | Content| 432 +--------+ 433 Private DC 434 ----------> 435 +------+----------+-------+-----+----------+ 436 | Data | Inner IP | GTP-U | UDP | Outer IP | 437 +------+----------+-------+-----+----------+ 439 ----------> 440 +------+----------+-------------+ 441 | Data | Inner IP | SR Header | 442 +------+----------+-------------+ 444 Figure 3: TN Aware Mobility Traffic Mapping to BGP SR-TE Policy Path 446 Note that, in the above figure SR Header is shown as an illustrative 447 purpose and the actual outgoing packet format is based on the BGP SR-TE 448 mechanism (SR-MPLS or SRv6) on the Ingress PE. That could be SR-MPLS or 449 SRv6 Header. Though if the BSID is not present with the BGP SR-TE 450 Policy, the local Ingress PE would map the incoming traffic to the best 451 effort policy map path in the underlay. 453 To support the Transport Network Mobility Traffic Mapping to BGP SR- 454 TE Policy Path in the headend PE, a new 5G Metadata Sub-TLV needs to 455 be supported. The proposed BGP SR Policy Encoding from the BGP SR-TE 456 Policy Controller to the headend PE node is defined below: 458 SR Policy SAFI NLRI: 459 Attributes: 460 Tunnel Encap Attr (23) 461 Tunnel Type: SR Policy 462 Existing Policy Sub-TLV 463 5G Metadata Sub-TLV 465 The draft [BGP-SR-TE-POLICY] defines BGP SR-TE Policy encodings. 466 There is no change in the existing encoding that is being used from 467 the BGP SR-TE Controller to the headend PE node. The current 468 solution proposes the new 5G Metadata Sub-TLV for BGP SR-TE 469 Controller to download the SR Policies to the headend PE and to 470 apply the SR-TE Policy-driven path for the Transport Network aware 471 mobility traffic. 473 The incoming TN aware mobility traffic with UDP Src port and BGP NH 474 to the traffic destination would be used as a key to find the BGP 475 SR-TE Policy. If the BGP Next Hop of the traffic matches with the SR 476 Policy SAFI NLRI Endpoint, and UDP Src Port value falls within the 477 UDP Src Port range defined by the 5G Metadata Sub-TLV, the SR Policy 478 would be applied to the mobility traffic to maintain the traffic 479 characteristics in the data network. The BGP SR-TE Controller would 480 be pre-provisioned with the 5G UDP SRC Port Range based on the [TN- 481 AWARE-MOBILITY] draft, and their corresponding BGP SR-TE Policy. 483 The 5G Metadata sub-TLV is optional and it MUST NOT appear more than 484 once in the SR-TE Policy. 486 The format of the new SR-TE 5G Metadata Sub-TLV is captured below: 488 0 1 2 3 489 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 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | Type | Sub-Type | Length | Flags | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | UDP Src Port Start Value | UDP Src Port End Value | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 5G Metadata Sub-TLV 497 where: 499 o Type: To be defined by IANA. 501 o Sub-Type: This field has one of the following values: 503 0: Reserved. 504 1: UDP Source Port Range. 505 2 - 255: Reserved for future use. 507 o Length: 6 octets. 509 o Flags: 1 octet of flags. None are defined at this stage. Flags 510 SHOULD be set to zero on transmission and MUST be ignored on 511 receipt. 513 o UDP Src Port Start Value: 2 octets value to define the staring of 514 the value of the UDP Src Port range. 516 o UDP Src Port End Value: 2 octets value to define the end value of 517 the UDP Src Port range. 519 5.2. Extend TN Aware Mobility for SR-PCE Controller 521 1) To integrate Transport Network Aware Mobility with SR-TE ODN based 522 PCE Controller at the Ingress PE UPF, the Class-map needs to be 523 defined to classify the incoming mobility traffic with different 524 Transport Path Characteristic. 526 2) The Ingress PE UPF is assumed to have PCEP based communication 527 with the SR-PCE Controller. 529 3) The Ingress PE would define the Policy-map to map the Transport 530 Path characteristics into SR-TE Color. 532 4) The Segment Routing TE Configuration for different Metric types 533 will associate the SR-TE Colors with their corresponding TE metric 534 type. 536 5) The existing SR-TE ODN based PCEP messages with TE metric type and 537 value MUST be used to associate the SR-TE Path corresponding to 538 the 5G UDP Src Port. 540 6) In this case, the mapping between {5G UDP Src Port} and {SR-TE 541 Policy} would be maintained by the Ingress PE. 543 7) Once the TN aware mobility traffic destination resolves into a 544 destination of BGP Peer Next Hop, the SR-TE ODN based traffic 545 steering MUST be applied based on the UDP Src Port value of the 546 incoming traffic. 548 The class-map definition to identify the incoming mobility traffic 549 characteristics is already defined in Section 5.1. The same class- 550 map definition applicable here as well. 552 The policy-map definition to associate SR-TE color with Transport 553 Path characteristics is defined below: 555 Policy-map type Transport-Network-Aware-Mobility 557 Class type traffic MIOT 559 Set color 561 Class type traffic URLLC 563 Set color 565 Class type traffic EMBB 567 Set color 569 The Segment Routing TE Configuration mechanism can associate the SR- 570 TE Colors with their corresponding metric type. That exists today, 571 and there is no change there. It is captured here to show how TN 572 aware mobility network characteristics get mapped to different TE 573 metrics through this mechanism. 575 Segment-routing traffic-eng 577 On-demand color dynamic 579 Metric 581 Type 583 On-demand color dynamic 585 Metric 587 Type 589 On-demand color dynamic 591 Metric 593 Type 595 As a result, mobility Transport Network aware of different traffic 596 characteristics like MIOT, URLLC, or EMBB get to assigned 597 corresponding "te" metric types. To fetch the corresponding SR-TE 598 dynamic path from the SR-PCE Controller based on the newly defined 599 "te" metric types , or needs to be extended in 600 the PCEP RFC [RFC5440]. 602 The below figure tries to capture the overall topology, and how to 603 map the mobility traffic in the headend PE having PCEP connection 604 with the SR-PCE Controller: 606 +-----------+ 607 | SR-PCE | 608 | Controller| 609 +-----------+ 610 / 611 / 612 PCReq Message / 613 with Metric Type/ 614 / +--------+ 615 / |IOT Data| 616 / PCRep Message +--------+ 617 / with Segment List /Public 618 / MIOT / Cloud 619 / +----- + 620 +------+ Policy1: UDP Src Port Xx-Xy / 621 | A1------------------------------+ 622 | | Policy2: UDP Src Port Yx-Yy URLLC 623 UE------| UPF A2-------------------------------------------- 624 | +PE1 | Policy3: UDP Src Port Zx-Zy 625 | A3-------------------------------+ 626 | | \ 627 +------+ +-----+ 628 {UDP Src Port Num# <--> SR Policy N} EMBB \ 629 \ 630 +--------+ 631 | Content| 632 +--------+ 633 Private DC 635 Figure 4: TN Aware Mobility Traffic Mapping to SR-TE Path 637 5.3. Extend TN Aware Mobility for RestConf/gRPC based SR-TE Controller 639 1) To integrate Transport Network Aware Mobility with SR-TE Policy at 640 the Ingress PE UPF, the Class-map needs to be defined to classify 641 the incoming mobility traffic with different Transport Path 642 Characteristic. 644 2) The Ingress PE UPF is assumed to have Restconf or gRPC connection 645 with the SR-TE Controller. The Mobility traffic destination would 646 resolve in the BGP Peer Next Hop for which SR-TE Policy to be 647 applied to maintain the same network characteristics beyond the 648 mobility domain. 650 3) A new 5G Metadata Yang data model and Protobuf to be defined for 651 SR-Policy SAFI with UDP Source Port Range to identify the SR-TE 652 path based on the Transport Path characteristics. 654 4) The SR-TE Controller would be programmed with {5G UDP Src Port 655 Range}. That would create internal mapping Table for {5G UDP Src 656 Port Range} < -- > {BGP SR-TE Policy, BSID}. 658 5) As the Headend PE sends the 5G metadata Yang data model or 659 Protobuf, the Controller will find a matching SR-TE Policy based 660 on the UDP Source Port. 662 6) The SR-TE Controller would download the SR-TE Policy in the 663 Ingress PE through the existing Restconf or gRPC session, and that 664 BGP update would include an additional 5G Metadata Sub-TLV. The 665 UDP Src Port range in the 5G Metadata Sub-TLV MUST fall within the 666 UDP Source Port range for the SSTs defined by the [TN-AWARE- 667 MOBILITY] draft. If the UDP Src Port range falls outside the range 668 defined by the [TN-AWARE-MOBILITY] draft, then the SR-TE Policy 669 SHOULD be ignored by the Ingress PE. 671 7) The SR-TE Policy-based traffic steering would be applied in the 672 Ingress PE UPF and it would maintain the local mapping for the 673 reverse Mobility traffic to the UE. 675 The class-map definition to identify the incoming mobility traffic 676 characteristics is already defined in Section 5.1. The same class- 677 map definition works here as well. 679 The below figure tries to capture the overall topology, and how to 680 map the mobility traffic in the headend PE having BGP SR-Policy SAFI 681 connection with the BGP SR-PCE Controller: 683 +-----------+ +----+{5G UDP Src Port Range} 684 | BGP SR-TE |-->| Map| <--> 685 | Controller| | DB |{BGP SR-TE Policy, BSID} 686 +-----------+ +----+ 687 / 688 / 689 / 690 Restconf or gRPC / 691 Session / +--------+ 692 / SR-Policy with |IOT Data| 693 / 5G Metadata Sub-TLV +--------+ 694 / /Public 695 / MIOT / Cloud 696 / +------+ 697 +-------+ Policy1: UDP Src Port Xx-Xy / 698 | A1------------------------------ + 699 | | Policy2: UDP Src Port Yx-Yy URLLC 700 UE------| UPF + A2------------------------------------------- 701 | PE1 | Policy3: UDP Src Port Zx-Zy 702 | A3------------------------------ -+ 703 | | \ 704 +-------+ +-----+ 705 {UDP Src Port Num# <--> SR Policy N} EMBB \ 706 \ 707 +--------+ 708 | Content| 709 +--------+ 710 Private DC 712 Figure 5: TN Aware Mobility Traffic Mapping to SR-TE Path 714 5.4. Extend BGP FlowSpec for TN Aware Mobility 716 1) To integrate Transport Network Aware Mobility with SR-TE Policy at 717 the Ingress PE UPF, the Class-map needs to be defined to classify 718 the incoming mobility traffic with different Transport Path 719 Characteristic. 721 2) The Ingress PE UPF that is acting as BGP FlowSpec Client is 722 assumed to have a BGP FlowSpec session with the FlowSpec 723 Controller. The Mobility traffic destination would resolve in the 724 BGP Peer Next Hop for which SR FlowSpec traffic re-direct policy 725 to be applied to maintain the same network characteristics in the 726 data network. 728 3) The current proposal tries to integrate FlowSpec Redirect to 729 Indirection ID [FLOWSPEC-PATH-REDIRECT] based traffic rules with 730 the TN aware mobility traffic based on the UDP Source Port range 731 at the FlowSpec Client Router/Ingress PE. 733 4) Based on the BGP FlowSpec RFC 8955 the BGP FlowSpec NLRI can carry 734 out the UDP Source Port range. The 5G SST specific UDP Source Port 735 range values can be pushed over a BGP FlowSpec session between the 736 FlowSpec Controller and the Ingress PE node. 738 5) There are no additional changes required on the BGP FlowSpec side 739 other than provisioning 5G SST specific UDP Source Port range at 740 the FlowSpec Controller along with the corresponding FlowSpec 741 Redirect to indirection-id. 743 6) The BGP FlowSpec Controller would be programmed with {5G UDP Src 744 Port Range} to map different SSTs defined in [TN-AWARE-MOBILITY] 745 draft to map the corresponding FlowSpec Redirect to Indirection- 746 id. That would create internal mapping Table for {5G UDP Src Port 747 Range} < -- > {BGP FlowSpec Generalized Indirection-ID}. 749 7) The BGP FlowSpec NLRI carrying 5G UDP Source Port Range along with 750 the corresponding Redirect to indirection-id Extended Community 751 can be pushed to the Ingress PE node. 753 8) The Mobility traffic coming from the UPF to the Ingress PE in the 754 Data Network carrying specific UDP Source Port from UE can be 755 classified based on the local Policy and apply the BGP FlowSpec 756 based re-direction rule based on the matching FlowSpec policy. 758 The class-map definition to identify the incoming mobility traffic 759 characteristics is already defined in Section 5.1. The same class- 760 map definition works here as well. 762 The below figure tries to capture the overall topology, and how to 763 map the mobility traffic in the Ingress PE acting as FlowSpec Client 764 having BGP FlowSpec SAFI connection with the BGP FlowSpec 765 Controller: 767 +-----------+ +----+{5G UDP Src Port Range} 768 | FlowSpec |-->| Map| <--> 769 | Controller| | DB |{Generalized Indirection-ID} 770 +-----------+ +----+ 771 / 772 / 773 / BGP FlowSpec NLRI with 5G 774 BGP FlowSpec / UDP Source Port Range 775 Session / +--------+ 776 / BGP FlowSpec Redirect |IOT Data| 777 / Indirection-ID Ext Comm +--------+ 778 / /Public 779 / MIOT / Cloud 780 / +------+ 781 +-------+ Ind-ID1: UDP Src Port Xx-Xy / 782 | A1-------------------------------+ 783 | | Ind-ID2: UDP Src Port Yx-Yy URLLC 784 UE------| UPF + A2-------------------------------------------- 785 | PE1 | Ind-ID3: UDP Src Port Zx-Zy 786 | A3-------------------------------+ 787 | | \EMBB 788 +-------+ +-----+ 789 {UDP Src Port Num# <--> FlowSpec Indirect-ID# ->Transport Hdr} \ 790 \ 791 +--------+ 792 | Content| 793 +--------+ 794 Private DC 796 ----------> 797 +------+----------+-------+-----+----------+ 798 | Data | Inner IP | GTP-U | UDP | Outer IP | 799 +------+----------+-------+-----+----------+ 801 ----------> 802 +------+----------+------------------+ 803 | Data | Inner IP | Transport Header | 804 +------+----------+------------------+ 806 Figure 6: TN Aware Mobility Traffic Mapping to FS Redirect Path 808 6. Mapping of TN Characteristics on SD-WAN Edge Node 810 On an SD-WAN CE Node, based on the mobility Transport Network 811 characteristics, mapping of mobility aware transport packets to 812 the secure and un-secure tunnel path needs to be achieved. 814 The [BGP-IPSEC-Discover] draft defines how SD-WAN Edge Node maps 815 the overlay/client routes to the underlay secure tunnel routes. 817 The current proposal specifies a generic approach on how SD-WAN 818 Edge Node maps the Mobility Transport Network aware traffic to the 819 Secure Tunnels, or Un-Secure TE Paths, or Secure SR-TE Tunnel 820 Paths. 822 The [SDWAN-BGP-USAGE] draft describes how BGP can be used as a 823 Control Plane for the SD-WAN network and defines the use case for 824 the Hybrid SD-WAN network. 826 In the case of a hybrid SD-WAN use case, UPF can run part of the 827 SD-WAN edge node or it could be connected to it over an IP 828 network. This would be a use case scenario for Enterprise 5G. 830 In that scenario, the Transport Path Characteristic for the 5G 831 mobile traffic need to be mapped to Secure (IPSec Tunnel) or Un- 832 secure path (could be MPLS based). 834 The existing [TN-AWARE-MOBILITY] draft is extended to support new 835 Transport Path Characteristics "Security" for the mobile traffic 836 where security is important for certain mobile traffic. 838 Based on the UDP Src Port characteristics coming from the mobile 839 network, the SD-WAN edge node would be able to decide what traffic 840 it needs to put in the secure tunnel vs. an un-secure tunnel where 841 low latency more important than security. 843 The below figure tries to capture the overall topology, and how to 844 map the mobility traffic in the SD-WAN Edge Device for Enterprise 845 5G cases: 847 +----------+ 848 | BGP RR | 849 +----|Controller|----+ 850 / +----------+ \ 851 / \ Internet 852 / \ / 853 / \ / 854 / \ URLLC/ 855 / \ / 856 / \ / 857 +-------+ MPLS Path: URLLC Traffic +------+ / 858 | A1---------------------------B1 |/ 859 | | Secure Path1: MIOT Traffic | | MIOT +--------+ 860 UE-----| UPF + A2---------------------------B2 C-PE2|------|IOT Data| 861 | C-PE1 | Secure Path2: EMBB Traffic | | +--------+ 862 | A3---------------------------B3 |\ Public 863 | | | | \ Cloud 864 +-------+ +------+ \ 865 {UDP Src Port X <--> MPLS} \ 866 {UDP Src Port Y:Security <--> IPSec SA Identifier} EMBB \ 867 \ +-------+ 868 \|Content| 869 +-------+ 870 Public 871 Cloud 872 ----------> 873 +------+----------+-------+-----+----------+ 874 | Data | Inner IP | GTP-U | UDP | Outer IP | 875 +------+----------+-------+-----+----------+ 877 ----------> 878 +------+----------+--------------+ 879 | Data | Inner IP | IPSec Header | 880 +------+----------+--------------+ 882 Figure 7: Secure TN Aware Mobility Traffic Mapping in the SD-WAN Edge Device 884 Here in this diagram, the traffic coming from the mobility side with 885 Transport Network characteristics gets mapped to the underlay un- 886 secure or secure traffic path. 888 The SD-WAN Edge Node can map the URLLC traffic without any security 889 characteristics to the underlay MPLS path, whereas MIOT, and EMBB 890 traffic with security characteristics gets mapped to the underlay 891 Secure IPSec Tunnel path. The mapping between SD-WAN overlay and 892 underlay routes are described in the [BGP-IPSEC-Discovery] draft. 894 This solution extends it for Transport Network aware mobility 895 traffic. The SD-WAN Edge Node here identifies the incoming mobility 896 traffic characteristics using the class-map definition, and that is 897 already defined under Section 5.1. Based on the incoming traffic 898 characteristics, the Edge Node will be able to map the mobility 899 overlay traffic to the respective SD-WAN underlay tunnel. 901 6.1. SD-WAN Hybrid Use Case with SR-TE Integration 903 1) In the case of SD-WAN hybrid use cases, UPF can run part of the 904 SD-WAN edge node, or it could be connected to it over an IP 905 network. This would be a use case scenario for Enterprise 5G. 907 2) The SD-WAN edge node can act as an SR-TE Headend PE in some use 908 case scenarios that are described in [SDWAN-BGP-USAGE] draft. 910 3) In that case, the Headend PE could be connected with SR-TE Policy 911 Controller over the BGP SR-Policy SAFI session, or SR-PCE 912 Controller over the PCEP session, or SR-TE Controller over 913 Netconf/ Restconf, or GRPC session, or even SR FlowSpec Controller 914 over BGP FlowSpec session. 916 4) The SD-WAN edge node can map the "Un-secure" mobility traffic to 917 the SR-TE path the same way as described under PE acting as 918 ingress SR-TE headend. 920 5) Though the mapping for "Secure" mobility traffic to the SR-TE path 921 would be slightly different than "Un-secure" mobility traffic. 923 6) The mobility 5G UE client traffic with the Transport Path 924 Characteristics "Security" would be encapsulated with Tunnel mode 925 IPSec header between the two SD-WAN SAFI underlay endpoints 926 (belong to the same BGP AS domain). This encapsulated secure 927 traffic will become the new overlay for the SR-TE traffic. 929 7) The rest of the mechanism for the secure mobility traffic with SR- 930 TE traffic forwarding is the same as un-secure SR-TE based traffic 931 forwarding. 933 The below figure tries to capture the overall topology, and how to 934 map the mobility traffic in the SD-WAN Edge Device for SD-WAN 935 Hybrid Use Cases described above: 937 +-------------+ 938 | BGP SR-Based| 939 | Controller | 940 +-------------+ 941 / 942 / 943 / +----------+ 944 BGP SR-TE Policy with | BGP RR | 945 5G Metadata Sub-TLV +----|Controller|----+ 946 / / +----------+ \ 947 / / \ Internet 948 / / \ / 949 / / \ / 950 / / \ URLLC/ 951 / / \ / 952 / / \ / 953 +-------+ SR-Pol1: URLLC Traffic +------+ / 954 | A1---------------------------B1 |/ 955 | | SA1,SR-Pol2: MIOT Traffic | | MIOT +--------+ 956 UE-----| UPF + A2---------------------------B2 C-PE2|------|IOT Data| 957 | C-PE1 | SA2,SR-Pol3: EMBB Traffic | | +--------+ 958 | A3---------------------------B3 |\ Public 959 | | | | \ Cloud 960 +-------+ +------+ \ 961 {UDP Src Port Num X <--> SR Policy1} \ 962 {UDP Src Port: Security Y, Z <--> EMBB \ 963 IPSec SA 1,2; SR-TE Policy 2,3} \ +-------+ 964 \|Content| 965 +-------+ 966 Public 967 Cloud 968 ----------> 969 +------+----------+-------+-----+----------+ 970 | Data | Inner IP | GTP-U | UDP | Outer IP | 971 +------+----------+-------+-----+----------+ 973 ----------> 974 +------+----------+--------------+-----------+ 975 | Data | Inner IP | IPSec Header | SR Header | 976 +------+----------+--------------+-----------+ 978 Figure 8: Secure TN Aware Mobility Traffic Mapping for Hybrid SD-WAN Use Case 979 In Figure 8, the traffic coming from the mobility side with 980 Transport Network characteristics gets mapped to the underlay un- 981 secure or secure SR-TE path to maintain the traffic network 982 characteristics in the Data Network. 984 The SD-WAN Edge Node can map the URLLC traffic without any security 985 characteristics to the underlay SR-TE path without any IPSec 986 encapsulation. Whereas MIOT and EMBB traffic with the security 987 characteristics can be mapped to the underlay Secure IPSec Tunnel 988 path with the SR-TE encapsulation to the SD-WAN endpoints. 990 7. IANA Considerations 992 The newly defined 5G Metadata Sub-TLV would need an IANA code point 993 allocation for the Type field. A request for any IANA code point 994 allocation would be submitted. 996 8. Security Considerations 998 This document does not introduce any new security issues. 1000 9. Contributors 1002 The following people have contributed to this document. 1004 Dhruv Dhody 1005 Divyashree Techno Park, Whitefield 1006 Bangalore, Karnataka 560066 1007 India 1009 Email: dhruv.ietf@gmail.com 1011 10. References 1013 10.1. Normative References 1015 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1016 Requirement Levels", BCP 14, RFC 2119, March 1997. 1018 10.2. Informative References 1020 [RFC5440] JP. Vasseur, Ed., JL. Le Roux, Ed., "Path Computation 1021 Element (PCE) Communication Protocol (PCEP)", March 2009 1023 [TN-AWARE-MOBILITY] U. Chunduri, et al, "Transport Network aware 1024 Mobility for 5G", draft-clt-dmm-tn-aware-mobility-07, April 2021 1026 [BGP-SR-TE-POLICY] S. Previdi, et al, "Advertising Segment Routing 1027 Policies in BGP", draft-ietf-idr-segment-routing-te-policy-09, 1028 November 2020 1030 [SDWAN-BGP-USAGE] L. Dunber, et al, "BGP Usage for SDWAN Overlay 1031 Networks", draft-dunbar-bess-bgp-sdwan-usage-08, January 2021 1033 [BGP-IPSEC-Discover] L. Dunber, et al, "BGP UPDATE for SDWAN Edge 1034 Discovery", draft-dunbar-idr-sdwan-edge-discovery-00, January 2021 1036 [Tunnel-Encap] E. Rosen, et al "The BGP Tunnel Encapsulation 1037 Attribute", draft-ietf-idr-tunnel-encaps-19, March 2021. 1039 11. Acknowledgments 1041 TBD. 1043 This document was prepared using 2-Word-v2.0.template.dot. 1045 Authors' Addresses 1047 Kausik Majumdar 1048 CommScope 1049 350 W Java Drive, Sunnyvale, CA 94089 1051 Email: kausik.majumdar@commscope.com 1053 Uma Chunduri 1054 Intel 1055 2200 Mission College Blvd 1056 Santa Clara, CA 95052 1058 Email: umac.ietf@gmail.com 1060 Linda Dunbar 1061 Futurewei 1062 2330 Central Expressway 1063 Santa Clara, CA 95050 1065 Email: linda.dunbar@futurewei.com