idnits 2.17.1 draft-mcd-rtgwg-extension-tn-aware-mobility-01.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 47 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 (May 11, 2021) is 1081 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'FLOWSPEC-PATH-REDIRECT' is mentioned on line 725, but not defined == Missing Reference: 'BGP-IPSEC-Discovery' is mentioned on line 888, but not defined == Unused Reference: 'RFC2119' is defined on line 1011, but no explicit reference was found in the text == Unused Reference: 'RFC5440' is defined on line 1016, but no explicit reference was found in the text == Unused Reference: 'Tunnel-Encap' is defined on line 1032, 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 (~~), 11 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 11, 2021 Intel 5 L. Dunbar 6 Futurewei 7 May 11, 2021 9 Extension of Transport Aware Mobility in Data Network 10 draft-mcd-rtgwg-extension-tn-aware-mobility-01 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 TN Aware Mobility for BGP FlowSpec Traffic Re- 76 direction.....................................................18 77 6. Mapping of TN Characteristics on SD-WAN Edge Node.............21 78 6.1. SD-WAN Hybrid Use Case with SR-TE Integration............23 79 7. IANA Considerations...........................................25 80 8. Security Considerations.......................................25 81 9. Contributors..................................................25 82 10. References...................................................25 83 10.1. Normative References....................................25 84 10.2. Informative References..................................26 85 11. Acknowledgments..............................................26 86 Authors' Addresses...............................................28 88 1. Introduction 90 The [TN-AWARE-MOBILITY] draft defines the transport path 91 characteristics in backhaul, midhaul, and fronthaul segments between 92 the radio side network functions and user plane functions (UPF). It 93 describes how various transport network underlay routing mechanisms 94 apply to the framework laid out including RSVP-TE, SR, and also a 95 data plane agnostic integrated routing and TE mechanism - Preferred 96 Path Routing (PPR) to map the network slice properties into the 97 IP/L2 transport network. 99 The current [TN-AWARE-MOBILITY] draft doesn't extend the transport 100 network characteristics from the UPF through the Data Network. If 101 the user service termination happens in the data network, the 102 Transport Path Network characteristics through the Data Network 103 would be lost. 105 This proposed Extension of Transport Aware Mobility in Data Network 106 extends the mobility aware transport network characteristics from 107 the UPF through the Data Network. 109 The UPF can be placed on the edge of the network where it can 110 perform entry or exit point to the Data Network. It can connect to a 111 Provider Edge node as well and bring all the mobile connections in a 112 distributed way to the Data Network. 114 The UPF can as well connect to the SD-WAN edge node or L3 aggregator 115 device and would try to bring all the 5G mobility connections for 116 small, medium, and large enterprises. This would be a scenario for 117 Enterprise 5G. 119 The current draft proposes mechanisms on how mobility aware 120 transport network characteristics to be mapped into SR-TE paths or 121 Un-secure, Secure, Secure SR-TE paths based in the Data Network on 122 different use cases scenarios. 124 2. Conventions used in this document 126 BSID - Binding SID 128 DC - Data Center 130 DN - Data Network (5G) 132 EMBB - enhanced Mobile Broadband (5G) 134 gNB - 5G NodeB 136 GTP-U - GPRS Tunneling Protocol - Userplane (3GPP) 138 MIOT - Massive IOT (5G) 140 PECP - Path Computation Element (PCE) Communication Protocol 142 SD-WAN - Software-Defined Wide Area Network 144 SID - Segment Identifier 146 SLA - Service Layer Agreement 148 SST - Slice and Service Types (5G) 150 SR - Segment Routing 152 SR-PCE - SR Path Computation Element 154 UE - User Equipment 156 UPF - User Plane Function (5G) 158 URLLC - Ultra reliable and low latency communications (5G) 160 3. Framework for Extension of Transport Network Aware Mobility 162 Architecture wise, the proposed Extension of Transport Aware 163 Mobility in the Data Network solution focuses on the following areas: 165 a) The Mobility packet transition in and out from the UPF to the C-PE 166 Node maintaining the Transport Path Characteristics. 168 b) On a PE node, based on the transport characteristics, use 169 different methods of fetching SR-TE path segments from the SR-TE 170 Controller and map the SR-TE segments with the mobility aware 171 transport packets. 173 c) On an SD-WAN CE Node, based on the transport characteristics, 174 mapping of mobility aware transport packets to the secure and un- 175 secure tunnel path. 177 Figure 1 captured under Section 4 provides the representation of a 178 network on how UE could be connected to the UPF and C-PE nodes in the 179 Data Network. The C-PE node represents a combined CE and PE node. In 180 some cases, UPF would be connected to the pure PE or CE node. 182 4. Mobility Packet Transition to the Data Network 184 As the Transport Aware Mobility packets transition in and out from 185 the UPF to the PE or C-PE (in SDWAN case) node, the Mobility 186 Transport Characteristics need to be maintained in the Data 187 Network. The current solution proposes a generic approach to how 188 the mobility packet transition can happen in the Data Network 189 maintaining the same transport characteristics. 191 There are two scenarios could happen here: 193 A) The UPF is not co-located with the C-PE in the same device. 194 Based on the local policy the proposed new header format for the 195 TN Aware Mobility Packets transitioning from the UPF to the C-PE 196 device and vice-versa is proposed below: 198 . From the UPF to the C-PE Node: 199 Inner IP Hdr (UE Packet) + New UDP Hdr (Original UDP Src Port) + 200 Outer IP (C-PE Node Address) 202 . From the C-PE to the UPF Node: 203 Outer IP (UPF Node Address) + Original UDP Hdr (Original UDP Src 204 Port) + Inner IP Hdr (UE Packet) 206 B) The UPF is co-located with the C-PE in the same device. Based on 207 the local policy the original UDP Source Port information can be 208 passed to the local C-PE node and no new header is needed here. 210 The current draft proposes to create a new encapsulation header in 211 scenario A. At the UPF node, the TN aware mobility UE packet 212 carrying the original UDP header Source Port information along 213 with the Inner IP packet to get encapsulated with the outer IP 214 header of the outgoing C-PE node IP address. 216 In below Figure 1, both scenarios are captured. Scenario A 217 captures the UPF is physically separated from the C-PE node over 218 an IP network. Scenario B captures the edge networking deployment. 219 In that case, the virtual UPF could be co-located with the 220 physical C-PE node in the same device. 222 Scenario A: 224 +-----------+ +-----+ +-----+ 225 | | | | | | 226 UE---------| gNB-CU(UP)|-------| UPF |-------| C-PE|------DN 227 | | | | | | 228 +-----------+ +-----+ +-- --+ 230 |--- N3 OR N9 ---||---- N6 ----| 232 |-------- Mobile Network -------||------ IP Network ------| 234 Scenario B: 236 +-----------+ +------+ 237 | | | | 238 UE---------| gNB-CU(UP)|------------------| UPF +|--------DN 239 | | | C-PE | 240 +-----------+ +------+ 242 |------- N3 OR N9 -------| 244 |-------------- Mobile Network -------------||-- IP Network--| 246 Figure 1: Mobile and IP Data Network for UE 248 The Figure 2 captures the TN Aware Mobility packet format under 249 the scenario A. 251 1. UE Packet format in the Mobile Network to the UPF: 253 +---------+----------+-------+------------+----------+ 254 | UE Data | Inner IP | GTP-U | UDP Header | Outer IP | 255 +---------+----------+-------+------------+----------+ 257 2. UE Packet format in the IP Network to the Ingress C-PE Node: 259 +---------+----------+----------------+------------+ 260 | UE Data | Inner IP | New UDP Header | C-PE Header| 261 +---------+----------+----------------+------------+ 263 Figure 2: UE Packet Transition from Mobile to IP Network 265 The source port in the original UDP header indicates the TN Aware 266 Mobility SST type. 268 5. Transport Network Characteristics Mapping to SR-TE Paths 270 With the 5G Mobile Networking, the UPF would be terminating the 271 mobile connection from the UE. In some Edge Networking scenarios, 272 the virtual UPF would be co-located with the C-PE or it would be 273 connected to the C-PE node over IP Network. 275 The 5G UE traffic coming to the UPF might be carrying Transport 276 Network Characteristics. In that scenario, there would be a need 277 to maintain the Transport Path Characteristic through the core of 278 the network so that end to end SLA can be maintained for the UE 279 traffic. 281 In scenarios, where ingress PE acting as SR-TE node, the mapping 282 of Transport Network Aware Mobility {5G UDP Src Port Range} to 283 {BGP SR-TE Policy, BSID} to be done at the ingress PE. Once this 284 mapping is done, the mobility Transport Path Characteristics can 285 be maintained in the data network. 287 On a PE node, based on the transport characteristics, the current 288 solution proposes different methods of applying SR-TE path 289 segments: 291 Scenario 1: In this scenario, the assumption is that the Ingress 292 PE node is connected to the BGP SR-TE Controller through the BGP 293 SR-TE Policy SAFI Session. This solution defines a mechanism to 294 map the BGP SR-TE Underlay Path Segments based on the Mobility 295 Transport Characteristics. 297 . This mechanism would require a new BGP Sub-TLV as part of the 298 existing SR Policy SAFI NLRI to download SR-TE Policies 299 corresponds to the mobility Transport Path characteristics. 300 If the TN aware mobility packet UDP Source Port value falls 301 within the UDP Src Port range value of this Sub-TLV, then the 302 pre-downloaded SR-TE Policy MUST be applied on the mobility 303 traffic to map to the correct network slice in the Data 304 Network. Once the Policy is fetched it would be cached by the 305 PE node for operating in line with the subsequent mobility TN 306 aware packets. 308 Scenario 2: In this scenario, the assumption is that the Ingress 309 PE node is connected to the SR-PCE (Path Compute Element) 310 Controller through the PCEP Session. This draft defines a 311 mechanism to map the SR-TE Underlay Segments based on the Mobility 312 Transport Path Characteristics. 314 . Currently, this mechanism does not require new encoding in 315 the PCEP based communication, though it needs local 316 Configuration in the PE node to request the SR-TE Paths from 317 the PCEP based Controller based on on-demand TN aware 318 mobility traffic metric types. 320 Scenario 3: In this scenario, the assumption is that the Ingress 321 PE node is connected to the SR-TE Controller over Restconf/ 322 Netconf or gRPC session. The existing mechanism would be used to 323 download the SR-TE Underlay Path Segments to the PE node based on 324 the Mobility Transport Path Characteristics. 326 . The Yang Data Model or Protobuf definition is required to 327 define a new Sub-TLV like Scenario 1. The SR-TE Controller 328 would pre-download the SR-TE Policies with the new Sub-TLV in 329 the Ingress PE using the existing session. Once the specific 330 SR-TE Policy is fetched, it would be cached by the Ingress PE 331 to apply for the mobility TN aware traffic in-line to 332 maintain the network characteristics in the Data Network. 334 Scenario 4: In this scenario, the assumption is that the Ingress 335 PE node is connected to the BGP SR FlowSpec Controller through the 336 BGP FlowSpec Session. This draft defines a mechanism to map the 337 FlowSpec redirect to indirection-id community-based SR Traffic 338 rules to the Mobility Transport Path Characteristics. 340 . Currently, this mechanism does not require any new encoding 341 in the BGP SR FlowSpec path redirect draft [FLOWSPEC-PATH- 342 REDIRECT], though it needs local Configuration in the Ingress 343 PE node that is acting as BGP FlowSpec Client to map the 344 Mobility traffic based on the SR FlowSpec traffic re- 345 direction rules. 347 5.1. Extend TN Aware Mobility for BGP SR-TE Policy 349 1) To integrate Transport Network Aware Mobility with BGP SR-TE 350 Policy at the Ingress PE UPF, the Class-map needs to be defined to 351 classify the incoming mobility traffic with different Transport 352 Path Characteristic. 354 2) The Ingress PE UPF is assumed to have a BGP SR-TE Policy SAFI 355 connection with the BGP SR-TE Controller. The Mobility traffic 356 destination would resolve in the BGP Peer Next Hop for which SR-TE 357 Policy to be applied to maintain the same network characteristics 358 beyond the mobility domain. 360 3) A new 5G Metadata Sub-TLV has been defined for existing SR-Policy 361 SAFI with the UDP Source Port Range to identify the SR-TE path 362 based on the Transport Path characteristics. 364 4) The BGP SR-TE Controller would be programmed with {5G UDP Src Port 365 Range}. That would create internal mapping Table for {5G UDP Src 366 Port Range} < -- > {BGP SR-TE Policy, BSID}. 368 5) The BGP SR-TE Controller would download the SR-TE Policy in the 369 Ingress PE through the existing BGP SR-Policy SAFI session, and 370 that the BGP update would include an additional 5G Metadata Sub- 371 TLV. The UDP Src Port range in the 5G Metadata Sub-TLV MUST fall 372 within the UDP Source Port range for the SSTs defined by the [TN- 373 AWARE-MOBILITY] draft. If the UDP Src Port range falls outside the 374 range defined by the [TN-AWARE-MOBILITY] draft, then the SR-TE 375 Policy SHOULD be ignored by the Ingress PE. 377 6) The SR-TE Policy-based traffic steering would be applied in the 378 Ingress PE and it would maintain the local mapping for the reverse 379 Mobility traffic to the UE. 381 The following class-map definition needs to be applied in the 382 headend PE for the incoming Transport Network aware mobility traffic 383 path: 385 Class-map type traffic match MIOT 387 Match UDP Src Port Range Xx - Xy 389 Class-map type traffic match URLLC 391 Match UDP Src Port Range Yx - Yy 393 Class-map type traffic match EMBB 395 Match UDP Src Port Range Zx - Zy 397 The class-map would help to identify the incoming mobility traffic 398 characteristics. Based on these characteristics the headend PE would 399 be able to map the Transport Network aware mobility traffic to the 400 appropriate BGP SR-TE Policy path over the Data Network to reach the 401 UE's destination. 403 The below figure tries to capture the overall topology, and how to 404 map the mobility traffic in the Ingress PE having BGP SR-Policy SAFI 405 connection with the BGP SR-TE Controller: 407 +-----------+ +----+{5G UDP Src Port Range} 408 | BGP SR-TE |-->| Map| <--> 409 | Controller| | DB |{BGP SR-TE Policy, BSID} 410 +-----------+ +----+ 411 / 412 / 413 / 414 / 415 / +--------+ 416 / BGP SR-TE Policy with |IOT Data| 417 / 5G Metadata Sub-TLV +--------+ 418 / /Public 419 / MIOT / Cloud 420 / / 421 +------+ Policy1: UDP Src Port Xx-Xy +------+ / 422 | A1------------------------------B1 |/ 423 | | Policy2: UDP Src Port Yx-Yy | | URLLC 424 UE------| UPF A2------------------------------B2 PE2 |------Internet 425 | +PE1 | Policy3: UDP Src Port Zx-Zy | | 426 | A3------------------------------B3 |\ 427 | | | | \ 428 +------+ +------+ \ 429 {UDP Src Port Num# <--> SR Policy N} EMBB \ 430 \ 431 +--------+ 432 | Content| 433 +--------+ 434 Private DC 435 ----------> 436 +------+----------+-------+-----+----------+ 437 | Data | Inner IP | GTP-U | UDP | Outer IP | 438 +------+----------+-------+-----+----------+ 440 ----------> 441 +------+----------+-----+--------------+ 442 | Data | Inner IP | GRE | SR-TE Header | 443 +------+----------+-----+--------------+ 445 Figure 3: TN Aware Mobility Traffic Mapping to BGP SR-TE Policy Path 447 Note that, in the above figure the GRE and SR-TE Header is shown as 448 an illustrative purpose and the actual outgoing packet format is 449 based on the SR-TE mechanism (SR-MPLS or SRv6) on the Ingress PE. 451 To support the Transport Network Mobility Traffic Mapping to BGP SR- 452 TE Policy Path in the headend PE, a new 5G Metadata Sub-TLV needs to 453 be supported. The proposed BGP SR Policy Encoding from the BGP SR-TE 454 Policy Controller to the headend PE node is defined below: 456 SR Policy SAFI NLRI: 457 Attributes: 458 Tunnel Encap Attr (23) 459 Tunnel Type: SR Policy 460 Existing Policy Sub-TLV 461 5G Metadata Sub-TLV 463 The draft [BGP-SR-TE-POLICY] defines BGP SR-TE Policy encodings. 464 There is no change in the existing encoding that is being used from 465 the BGP SR-TE Controller to the headend PE node. The current 466 solution proposes the new 5G Metadata Sub-TLV for BGP SR-TE 467 Controller to download the SR Policies to the headend PE and to 468 apply the SR-TE Policy-driven path for the Transport Network aware 469 mobility traffic. 471 The incoming TN aware mobility traffic with UDP Src port and BGP NH 472 to the traffic destination would be used as a key to find the BGP 473 SR-TE Policy. If the BGP Next Hop of the traffic matches with the SR 474 Policy SAFI NLRI Endpoint, and UDP Src Port value falls within the 475 UDP Src Port range defined by the 5G Metadata Sub-TLV, the SR Policy 476 would be applied to the mobility traffic to maintain the traffic 477 characteristics in the data network. The BGP SR-TE Controller would 478 be pre-provisioned with the 5G UDP SRC Port Range based on the [TN- 479 AWARE-MOBILITY] draft, and their corresponding BGP SR-TE Policy. 481 The 5G Metadata sub-TLV is optional and it MUST NOT appear more than 482 once in the SR-TE Policy. 484 The format of the new SR-TE 5G Metadata Sub-TLV is captured below: 486 0 1 2 3 487 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 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | Type | Sub-Type | Length | Flags | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | UDP Src Port Start Value | UDP Src Port End Value | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 5G Metadata Sub-TLV 495 where: 497 o Type: To be defined by IANA. 499 o Sub-Type: This field has one of the following values: 501 0: Reserved. 502 1: UDP Source Port Range. 503 2 - 255: Reserved for future use. 505 o Length: 6 octets. 507 o Flags: 1 octet of flags. None are defined at this stage. Flags 508 SHOULD be set to zero on transmission and MUST be ignored on 509 receipt. 511 o UDP Src Port Start Value: 2 octets value to define the staring of 512 the value of the UDP Src Port range. 514 o UDP Src Port End Value: 2 octets value to define the end value of 515 the UDP Src Port range. 517 5.2. Extend TN Aware Mobility for SR-PCE Controller 519 1) To integrate Transport Network Aware Mobility with SR-TE ODN based 520 PCE Controller at the Ingress PE UPF, the Class-map needs to be 521 defined to classify the incoming mobility traffic with different 522 Transport Path Characteristic. 524 2) The Ingress PE UPF is assumed to have PCEP based communication 525 with the SR-PCE Controller. 527 3) The Ingress PE would define the Policy-map to map the Transport 528 Path characteristics into SR-TE Color. 530 4) The Segment Routing TE Configuration for different Metric types 531 will associate the SR-TE Colors with their corresponding TE metric 532 type. 534 5) The existing SR-TE ODN based PCEP messages with TE metric type and 535 value MUST be used to associate the SR-TE Path corresponding to 536 the 5G UDP Src Port. 538 6) In this case, the mapping between {5G UDP Src Port} and {SR-TE 539 Policy} would be maintained by the Ingress PE. 541 7) Once the TN aware mobility traffic destination resolves into a 542 destination of BGP Peer Next Hop, the SR-TE ODN based traffic 543 steering MUST be applied based on the UDP Src Port value of the 544 incoming traffic. 546 The class-map definition to identify the incoming mobility traffic 547 characteristics is already defined in Section 5.1. The same class- 548 map definition applicable here as well. 550 The policy-map definition to associate SR-TE color with Transport 551 Path characteristics is defined below: 553 Policy-map type Transport-Network-Aware-Mobility 555 Class type traffic MIOT 557 Set color 559 Class type traffic URLLC 561 Set color 563 Class type traffic EMBB 565 Set color 567 The Segment Routing TE Configuration mechanism can associate the SR- 568 TE Colors with their corresponding metric type. That exists today, 569 and there is no change there. It is captured here to show how TN 570 aware mobility network characteristics get mapped to different TE 571 metrics through this mechanism. 573 Segment-routing traffic-eng 575 On-demand color dynamic 577 Metric 578 Type te 580 On-demand color dynamic 582 Metric 584 Type latency 586 On-demand color dynamic 588 Metric 590 Type igp 592 As a result, mobility Transport Network aware of different traffic 593 characteristics like MIOT, URLLC, or EMBB get to assigned 594 corresponding "te" metric types. To fetch the corresponding SR-TE 595 dynamic path from the SR-PCE Controller based on the "te" metric 596 types that exists today. 598 The below figure tries to capture the overall topology, and how to 599 map the mobility traffic in the headend PE having PCEP connection 600 with the SR-PCE Controller: 602 +-----------+ 603 | SR-PCE | 604 | Controller| 605 +-----------+ 606 / 607 / 608 PCReq Message / 609 with Metric Type/ 610 / +--------+ 611 / |IOT Data| 612 / PCRep Message +--------+ 613 / with Segment List /Public 614 / MIOT / Cloud 615 / / 616 +------+ Policy1: UDP Src Port Xx-Xy +-----+ / 617 | A1-----------------------------B1 |/ 618 | | Policy2: UDP Src Port Yx-Yy | | URLLC 619 UE------| UPF A2-----------------------------B2 PE2 |------Internet 620 | +PE1 | Policy3: UDP Src Port Zx-Zy | | 621 | A3-----------------------------B3 |\ 622 | | | | \ 623 +------+ +-----+ \ 624 {UDP Src Port Num# <--> SR Policy N} EMBB \ 625 \ 626 +--------+ 627 | Content| 628 +--------+ 629 Private DC 631 Figure 4: TN Aware Mobility Traffic Mapping to SR-TE Path 633 5.3. Extend TN Aware Mobility for RestConf/gRPC based SR-TE Controller 635 1) To integrate Transport Network Aware Mobility with SR-TE Policy at 636 the Ingress PE UPF, the Class-map needs to be defined to classify 637 the incoming mobility traffic with different Transport Path 638 Characteristic. 640 2) The Ingress PE UPF is assumed to have Restconf or gRPC connection 641 with the SR-TE Controller. The Mobility traffic destination would 642 resolve in the BGP Peer Next Hop for which SR-TE Policy to be 643 applied to maintain the same network characteristics beyond the 644 mobility domain. 646 3) A new 5G Metadata Yang data model and Protobuf to be defined for 647 SR-Policy SAFI with UDP Source Port Range to identify the SR-TE 648 path based on the Transport Path characteristics. 650 4) The SR-TE Controller would be programmed with {5G UDP Src Port 651 Range}. That would create internal mapping Table for {5G UDP Src 652 Port Range} < -- > {BGP SR-TE Policy, BSID}. 654 5) As the Headend PE sends the 5G metadata Yang data model or 655 Protobuf, the Controller will find a matching SR-TE Policy based 656 on the UDP Source Port. 658 6) The SR-TE Controller would download the SR-TE Policy in the 659 Ingress PE through the existing Restconf or gRPC session, and that 660 BGP update would include an additional 5G Metadata Sub-TLV. The 661 UDP Src Port range in the 5G Metadata Sub-TLV MUST fall within the 662 UDP Source Port range for the SSTs defined by the [TN-AWARE- 663 MOBILITY] draft. If the UDP Src Port range falls outside the range 664 defined by the [TN-AWARE-MOBILITY] draft, then the SR-TE Policy 665 SHOULD be ignored by the Ingress PE. 667 7) The SR-TE Policy-based traffic steering would be applied in the 668 Ingress PE UPF and it would maintain the local mapping for the 669 reverse Mobility traffic to the UE. 671 The class-map definition to identify the incoming mobility traffic 672 characteristics is already defined in Section 5.1. The same class- 673 map definition works here as well. 675 The below figure tries to capture the overall topology, and how to 676 map the mobility traffic in the headend PE having BGP SR-Policy SAFI 677 connection with the BGP SR-PCE Controller: 679 +-----------+ +----+{5G UDP Src Port Range} 680 | BGP SR-TE |-->| Map| <--> 681 | Controller| | DB |{BGP SR-TE Policy, BSID} 682 +-----------+ +----+ 683 / 684 / 685 / 686 Restconf or gRPC / 687 Session / +--------+ 688 / SR-Policy with |IOT Data| 689 / 5G Metadata Sub-TLV +--------+ 690 / /Public 691 / MIOT / Cloud 692 / / 693 +-------+ Policy1: UDP Src Port Xx-Xy +-----+ / 694 | A1------------------------------B1 |/ 695 | | Policy2: UDP Src Port Yx-Yy | | URLLC 696 UE------| UPF + A2------------------------------B2 PE2 |------Internet 697 | PE1 | Policy3: UDP Src Port Zx-Zy | | 698 | A3------------------------------B3 |\ 699 | | | | \ 700 +-------+ +-----+ \ 701 {UDP Src Port Num# <--> SR Policy N} EMBB \ 702 \ 703 +--------+ 704 | Content| 705 +--------+ 706 Private DC 708 Figure 5: TN Aware Mobility Traffic Mapping to SR-TE Path 710 5.4. Extend TN Aware Mobility for BGP FlowSpec Traffic Re-direction 712 1) To integrate Transport Network Aware Mobility with SR-TE Policy at 713 the Ingress PE UPF, the Class-map needs to be defined to classify 714 the incoming mobility traffic with different Transport Path 715 Characteristic. 717 2) The Ingress PE UPF that is acting as BGP FlowSpec Client is 718 assumed to have a BGP FlowSpec session with the FlowSpec 719 Controller. The Mobility traffic destination would resolve in the 720 BGP Peer Next Hop for which SR FlowSpec traffic re-direct policy 721 to be applied to maintain the same network characteristics in the 722 data network. 724 3) The current proposal tries to integrate FlowSpec Redirect to 725 Indirection ID [FLOWSPEC-PATH-REDIRECT] based traffic rules with 726 the TN aware mobility traffic based on the UDP Source Port range 727 at the FlowSpec Client Router/Ingress PE. 729 4) Based on the BGP FlowSpec RFC 8955 the BGP FlowSpec NLRI can carry 730 out the UDP Source Port range. The 5G SST specific UDP Source Port 731 range values can be pushed over a BGP FlowSpec session between the 732 FlowSpec Controller and the Ingress PE node. 734 5) There are no additional changes required on the BGP FlowSpec side 735 other than provisioning 5G SST specific UDP Source Port range at 736 the FlowSpec Controller along with the corresponding FlowSpec 737 Redirect to indirection-id. 739 6) The BGP FlowSpec Controller would be programmed with {5G UDP Src 740 Port Range} to map different SSTs defined in [TN-AWARE-MOBILITY] 741 draft to map the corresponding FlowSpec Redirect to Indirection- 742 id. That would create internal mapping Table for {5G UDP Src Port 743 Range} < -- > {BGP FlowSpec Generalized Indirection-ID}. 745 7) The BGP FlowSpec NLRI carrying 5G UDP Source Port Range along with 746 the corresponding Redirect to indirection-id Extended Community 747 can be pushed to the Ingress PE node. 749 8) The Mobility traffic coming from the UPF to the Ingress PE in the 750 Data Network carrying specific UDP Source Port from UE can be 751 classified based on the local Policy and apply the BGP FlowSpec 752 based re-direction rule based on the matching FlowSpec policy. 754 The class-map definition to identify the incoming mobility traffic 755 characteristics is already defined in Section 5.1. The same class- 756 map definition works here as well. 758 The below figure tries to capture the overall topology, and how to 759 map the mobility traffic in the Ingress PE acting as FlowSpec Client 760 having BGP FlowSpec SAFI connection with the BGP FlowSpec 761 Controller: 763 +-----------+ +----+{5G UDP Src Port Range} 764 | FlowSpec |-->| Map| <--> 765 | Controller| | DB |{Generalized Indirection-ID} 766 +-----------+ +----+ 767 / 768 / 769 / BGP FlowSpec NLRI with 5G 770 BGP FlowSpec / UDP Source Port Range 771 Session / +--------+ 772 / BGP FlowSpec Redirect |IOT Data| 773 / Indirection-ID Ext Comm +--------+ 774 / /Public 775 / MIOT / Cloud 776 / / 777 +-------+ Ind-ID1: UDP Src Port Xx-Xy +-----+ / 778 | A1------------------------------B1 |/ 779 | | Ind-ID2: UDP Src Port Yx-Yy | | URLLC 780 UE------| UPF + A2------------------------------B2 PE2 |------Internet 781 | PE1 | Ind-ID3: UDP Src Port Zx-Zy | | 782 | A3------------------------------B3 |\ 783 | | | | \ 784 +-------+ +-----+ \ 785 {UDP Src Port Num# <--> FlowSpec Indirection-ID#} EMBB \ 786 \ 787 +--------+ 788 | Content| 789 +--------+ 790 Private DC 792 ----------> 793 +------+----------+-------+-----+----------+ 794 | Data | Inner IP | GTP-U | UDP | Outer IP | 795 +------+----------+-------+-----+----------+ 797 ----------> 798 +------+----------+-----+--------------------------+ 799 | Data | Inner IP | GRE | FS Indirection-ID Header | 800 +------+----------+-----+--------------------------+ 802 Figure 6: TN Aware Mobility Traffic Mapping to FS Redirect Path 804 6. Mapping of TN Characteristics on SD-WAN Edge Node 806 On an SD-WAN CE Node, based on the mobility Transport Network 807 characteristics, mapping of mobility aware transport packets to 808 the secure and un-secure tunnel path needs to be achieved. 810 The [BGP-IPSEC-Discover] draft defines how SD-WAN Edge Node maps 811 the overlay/client routes to the underlay secure tunnel routes. 813 The current proposal specifies a generic approach on how SD-WAN 814 Edge Node maps the Mobility Transport Network aware traffic to the 815 Secure Tunnels, or Un-Secure TE Paths, or Secure SR-TE Tunnel 816 Paths. 818 The [SDWAN-BGP-USAGE] draft describes how BGP can be used as a 819 Control Plane for the SD-WAN network and defines the use case for 820 the Hybrid SD-WAN network. 822 In the case of a hybrid SD-WAN use case, UPF can run part of the 823 SD-WAN edge node or it could be connected to it over an IP 824 network. This would be a use case scenario for Enterprise 5G. 826 In that scenario, the Transport Path Characteristic for the 5G 827 mobile traffic need to be mapped to Secure (IPSec Tunnel) or Un- 828 secure path (could be MPLS based). 830 The existing [TN-AWARE-MOBILITY] draft is extended to support new 831 Transport Path Characteristics "Security" for the mobile traffic 832 where security is important for certain mobile traffic. 834 Based on the UDP Src Port characteristics coming from the mobile 835 network, the SD-WAN edge node would be able to decide what traffic 836 it needs to put in the secure tunnel vs. an un-secure tunnel where 837 low latency more important than security. 839 The below figure tries to capture the overall topology, and how to 840 map the mobility traffic in the SD-WAN Edge Device for Enterprise 841 5G cases: 843 +----------+ 844 | BGP RR | 845 +----|Controller|----+ 846 / +----------+ \ 847 / \ Internet 848 / \ / 849 / \ / 850 / \ URLLC/ 851 / \ / 852 / \ / 853 +-------+ MPLS Path: URLLC Traffic +------+ / 854 | A1---------------------------B1 |/ 855 | | Secure Path1: MIOT Traffic | | MIOT +--------+ 856 UE-----| UPF + A2---------------------------B2 C-PE2|------|IOT Data| 857 | C-PE1 | Secure Path2: EMBB Traffic | | +--------+ 858 | A3---------------------------B3 |\ Public 859 | | | | \ Cloud 860 +-------+ +------+ \ 861 {UDP Src Port X <--> MPLS} \ 862 {UDP Src Port Y:Security <--> IPSec SA Identifier} EMBB \ 863 \ +-------+ 864 \|Content| 865 +-------+ 866 Public 867 Cloud 868 ----------> 869 +------+----------+-------+-----+----------+ 870 | Data | Inner IP | GTP-U | UDP | Outer IP | 871 +------+----------+-------+-----+----------+ 873 ----------> 874 +------+----------+-----+------------+ 875 | Data | Inner IP | GRE | ESP Header | 876 +------+----------+-----+------------+ 878 Figure 7: Secure TN Aware Mobility Traffic Mapping in the SD-WAN Edge Device 880 Here in this diagram, the traffic coming from the mobility side with 881 Transport Network characteristics gets mapped to the underlay un- 882 secure or secure traffic path. 884 The SD-WAN Edge Node can map the URLLC traffic without any security 885 characteristics to the underlay MPLS path, whereas MIOT, and EMBB 886 traffic with security characteristics gets mapped to the underlay 887 Secure IPSec Tunnel path. The mapping between SD-WAN overlay and 888 underlay routes are described in the [BGP-IPSEC-Discovery] draft. 890 This solution extends it for Transport Network aware mobility 891 traffic. The SD-WAN Edge Node here identifies the incoming mobility 892 traffic characteristics using the class-map definition, and that is 893 already defined under Section 5.1. Based on the incoming traffic 894 characteristics, the Edge Node will be able to map the mobility 895 overlay traffic to the respective SD-WAN underlay tunnel. 897 6.1. SD-WAN Hybrid Use Case with SR-TE Integration 899 1) In the case of SD-WAN hybrid use cases, UPF can run part of the 900 SD-WAN edge node, or it could be connected to it over an IP 901 network. This would be a use case scenario for Enterprise 5G. 903 2) The SD-WAN edge node can act as an SR-TE Headend PE in some use 904 case scenarios that are described in [SDWAN-BGP-USAGE] draft. 906 3) In that case, the Headend PE could be connected with SR-TE Policy 907 Controller over the BGP SR-Policy SAFI session, or SR-PCE 908 Controller over the PCEP session, or SR-TE Controller over 909 Netconf/ Restconf, or GRPC session, or even SR FlowSpec Controller 910 over BGP FlowSpec session. 912 4) The SD-WAN edge node can map the "Un-secure" mobility traffic to 913 the SR-TE path the same way as described under PE acting as 914 ingress SR-TE headend. 916 5) Though the mapping for "Secure" mobility traffic to the SR-TE path 917 would be slightly different than "Un-secure" mobility traffic. 919 6) The mobility 5G UE client traffic with the Transport Path 920 Characteristics "Security" would be encapsulated with Tunnel mode 921 IPSec header between the two SD-WAN SAFI underlay endpoints 922 (belong to the same BGP AS domain). This encapsulated secure 923 traffic will become the new overlay for the SR-TE traffic. 925 7) The rest of the mechanism for the secure mobility traffic with SR- 926 TE traffic forwarding is the same as un-secure SR-TE based traffic 927 forwarding. 929 The below figure tries to capture the overall topology, and how to 930 map the mobility traffic in the SD-WAN Edge Device for SD-WAN 931 Hybrid Use Cases described above: 933 +-------------+ 934 | BGP SR-Based| 935 | Controller | 936 +-------------+ 937 / 938 / 939 / +----------+ 940 BGP SR-TE Policy with | BGP RR | 941 5G Metadata Sub-TLV +----|Controller|----+ 942 / / +----------+ \ 943 / / \ Internet 944 / / \ / 945 / / \ / 946 / / \ URLLC/ 947 / / \ / 948 / / \ / 949 +-------+ SR-Pol1: URLLC Traffic +------+ / 950 | A1---------------------------B1 |/ 951 | | SA1,SR-Pol2: MIOT Traffic | | MIOT +--------+ 952 UE-----| UPF + A2---------------------------B2 C-PE2|------|IOT Data| 953 | C-PE1 | SA2,SR-Pol3: EMBB Traffic | | +--------+ 954 | A3---------------------------B3 |\ Public 955 | | | | \ Cloud 956 +-------+ +------+ \ 957 {UDP Src Port Num X <--> SR Policy1} \ 958 {UDP Src Port: Security Y, Z <--> EMBB \ 959 IPSec SA 1,2; SR-TE Policy 2,3} \ +-------+ 960 \|Content| 961 +-------+ 962 Public 963 Cloud 964 ----------> 965 +------+----------+-------+-----+----------+ 966 | Data | Inner IP | GTP-U | UDP | Outer IP | 967 +------+----------+-------+-----+----------+ 969 ----------> 970 +------+----------+-----+------------+-----+--------------+ 971 | Data | Inner IP | GRE | ESP Header | GRE | SR-TE Header | 972 +------+----------+-----+------------+-----+--------------+ 974 Figure 8: Secure TN Aware Mobility Traffic Mapping for Hybrid SD-WAN Use Case 975 In Figure 8, the traffic coming from the mobility side with 976 Transport Network characteristics gets mapped to the underlay un- 977 secure or secure SR-TE path to maintain the traffic network 978 characteristics in the Data Network. 980 The SD-WAN Edge Node can map the URLLC traffic without any security 981 characteristics to the underlay SR-TE path without any IPSec 982 encapsulation. Whereas MIOT and EMBB traffic with the security 983 characteristics can be mapped to the underlay Secure IPSec Tunnel 984 path with the SR-TE encapsulation to the SD-WAN endpoints. 986 7. IANA Considerations 988 The newly defined 5G Metadata Sub-TLV would need an IANA code point 989 allocation for the Type field. A request for any IANA code point 990 allocation would be submitted. 992 8. Security Considerations 994 This document does not introduce any new security issues. 996 9. Contributors 998 The following people have contributed to this document. 1000 Dhruv Dhody 1001 Divyashree Techno Park, Whitefield 1002 Bangalore, Karnataka 560066 1003 India 1005 Email: dhruv.ietf@gmail.com 1007 10. References 1009 10.1. Normative References 1011 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1012 Requirement Levels", BCP 14, RFC 2119, March 1997. 1014 10.2. Informative References 1016 [RFC5440] JP. Vasseur, Ed., JL. Le Roux, Ed., "Path Computation 1017 Element (PCE) Communication Protocol (PCEP)", March 2009 1019 [TN-AWARE-MOBILITY] U. Chunduri, et al, "Transport Network aware 1020 Mobility for 5G", draft-clt-dmm-tn-aware-mobility-07, April 2021 1022 [BGP-SR-TE-POLICY] S. Previdi, et al, "Advertising Segment Routing 1023 Policies in BGP", draft-ietf-idr-segment-routing-te-policy-09, 1024 November 2020 1026 [SDWAN-BGP-USAGE] L. Dunber, et al, "BGP Usage for SDWAN Overlay 1027 Networks", draft-dunbar-bess-bgp-sdwan-usage-08, January 2021 1029 [BGP-IPSEC-Discover] L. Dunber, et al, "BGP UPDATE for SDWAN Edge 1030 Discovery", draft-dunbar-idr-sdwan-edge-discovery-00, January 2021 1032 [Tunnel-Encap] E. Rosen, et al "The BGP Tunnel Encapsulation 1033 Attribute", draft-ietf-idr-tunnel-encaps-19, March 2021. 1035 11. Acknowledgments 1037 TBD. 1039 This document was prepared using 2-Word-v2.0.template.dot. 1041 Authors' Addresses 1043 Kausik Majumdar 1044 CommScope 1045 350 W Java Drive, Sunnyvale, CA 94089 1047 Email: kausik.majumdar@commscope.com 1049 Uma Chunduri 1050 Intel 1051 2200 Mission College Blvd 1052 Santa Clara, CA 95052 1054 Email: umac.ietf@gmail.com 1056 Linda Dunbar 1057 Futurewei 1058 2330 Central Expressway 1059 Santa Clara, CA 95050 1061 Email: linda.dunbar@futurewei.com