idnits 2.17.1 draft-mcd-rtgwg-extension-tn-aware-mobility-00.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 23 instances of too long lines in the document, the longest one being 4 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 (October 31, 2020) is 1273 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'BGP-IPSEC-Discovery' is mentioned on line 760, but not defined == Unused Reference: 'RFC2119' is defined on line 783, but no explicit reference was found in the text == Unused Reference: 'RFC5440' is defined on line 788, but no explicit reference was found in the text == Unused Reference: 'Tunnel-Encap' is defined on line 804, 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: April 30, 2021 L. Dunbar 5 Futurewei 6 October 31, 2020 8 Extension of Transport Aware Mobility in Data Network 9 draft-mcd-rtgwg-extension-tn-aware-mobility-00 11 Abstract 13 The existing Transport Network Aware Mobility for 5G [TN-AWARE- 14 MOBILITY] draft specifies a framework for mapping the 5G mobile 15 systems Slice and Service Types (SSTs) to corresponding underlying 16 network paths in IP and Layer 2 Transport networks.The focus of that 17 work is limited to the mobility domain and transport network 18 characteristics till the UPF and doesn't go beyond the UPF to the 19 Data Network. 21 To maintain E2E transport network characteristics the framework 22 needs to be extended beyond UPF. This document describes a framework 23 for extending the mobility aware transport network characteristics 24 from the UPF through the Data Network. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six 37 months and may be updated, replaced, or obsoleted by other documents 38 at any time. It is inappropriate to use Internet-Drafts as 39 reference material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html 46 This Internet-Draft will expire on April 23, 2021. 48 Copyright Notice 50 Copyright (c) 2020 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with 58 respect to this document. Code Components extracted from this 59 document must include Simplified BSD License text as described in 60 Section 4.e of the Trust Legal Provisions and are provided without 61 warranty as described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction...................................................3 66 2. Conventions used in this document..............................3 67 3. Framework for Extension of Transport Network Aware Mobility....4 68 4. Mobility Packet Transition to the Data Network.................5 69 5. Transport Network Characteristics Mapping to SR-TE Paths.......7 70 5.1. Extend TN Aware Mobility for BGP SR-TE Policy.............8 71 5.2. Extend TN Aware Mobility for SR-PCE Controller...........12 72 5.3. Extend TN Aware Mobility for SR-TE Controller............15 73 6. Mapping of TN Characteristics on SD-WAN Edge Node.............17 74 7. IANA Considerations...........................................20 75 8. Security Considerations.......................................20 76 9. References....................................................20 77 9.1. Normative References.....................................20 78 9.2. Informative References...................................20 79 10. Acknowledgments..............................................21 80 Authors' Addresses...............................................22 82 1. Introduction 84 The [TN-AWARE-MOBILITY] draft defines the transport path 85 characteristics in backhaul, midhaul, and fronthaul segments between 86 the radio side network functions and user plane functions (UPF). It 87 describes how various transport network underlay routing mechanisms 88 apply to the framework laid out including RSVP-TE, SR, and also a 89 data plane agnostic integrated routing and TE mechanism - Preferred 90 Path Routing (PPR) to map the network slice properties into the 91 IP/L2 transport network. 93 The current [TN-AWARE-MOBILITY] draft doesn't extend the transport 94 network characteristics from the UPF through the Data Network. If 95 the user service termination happens in the data network, the 96 Transport Path Network characteristics through the Data Network 97 would be lost. 99 This proposed Extension of Transport Aware Mobility in Data Network 100 extends the mobility aware transport network characteristics from 101 the UPF through the Data Network. 103 The UPF can be placed on the edge of the network where it can 104 perform entry or exit point to the Data Network. It can connect to a 105 Provider Edge node as well and bring all the mobile connections in a 106 distributed way to the Data Network. 108 The UPF can as well connect to the SD-WAN edge node or L3 aggregator 109 device and would try to bring all the 5G mobility connections for 110 small, medium, and large enterprises. This would be a scenario for 111 Enterprise 5G. 113 The current draft proposes mechanisms on how mobility aware 114 transport network characteristics to be mapped into SR-TE paths or 115 Un-secure, Secure, Secure SR-TE paths based in the Data Network on 116 different use cases scenarios. 118 2. Conventions used in this document 120 BSID - Binding SID 122 DC - Data Center 123 DN - Data Network (5G) 125 EMBB - enhanced Mobile Broadband (5G) 127 gNB - 5G NodeB 129 GTP-U - GPRS Tunneling Protocol - Userplane (3GPP) 131 MIOT - Massive IOT (5G) 133 PECP - Path Computation Element (PCE) Communication Protocol 135 SD-WAN - Software-Defined Wide Area Network 137 SID - Segment Identifier 139 SLA - Service Layer Agreement 141 SST - Slice and Service Types (5G) 143 SR - Segment Routing 145 SR-PCE - SR Path Computation Element 147 UE - User Equipment 149 UPF - User Plane Function (5G) 151 URLLC - Ultra reliable and low latency communications (5G) 153 3. Framework for Extension of Transport Network Aware Mobility 155 Architecture wise, the proposed Extension of Transport Aware 156 Mobility in the Data Network solution focuses on the following areas: 158 a) The Mobility packet transition in and out from the UPF to the C-PE 159 Node maintaining the Transport Path Characteristics. 161 b) On a PE node, based on the transport characteristics, use 162 different methods of fetching SR-TE path segments from the SR-TE 163 Controller and map the SR-TE segments with the mobility aware 164 transport packets. 166 c) On an SD-WAN CE Node, based on the transport characteristics, 167 mapping of mobility aware transport packets to the secure and un- 168 secure tunnel path. 170 Figure 1 captured under Section 4 provides the representation of a 171 network on how UE could be connected to the UPF and C-PE nodes in the 172 Data Network. The C-PE node represents a combined CE and PE node. In 173 some cases, UPF would be connected to the pure PE or CE node. 175 4. Mobility Packet Transition to the Data Network 177 As the Transport Aware Mobility packets transition in and out from 178 the UPF to the PE or C-PE (in SDWAN case) node, the Mobility 179 Transport Characteristics need to be maintained in the Data 180 Network. The current solution proposes a generic approach to how 181 the mobility packet transition can happen in the Data Network 182 maintaining the same transport characteristics. Whether the UPF 183 would be co-located with the C-PE in the same device or sitting in 184 a different device the approach would be the same. 186 The current solution proposes to create a new encapsulation header 187 at the UPF node carrying the original UDP header along with the 188 Inner IP to get encapsulated with the outer IP header of the 189 outgoing C-PE node IP address. 191 . Format of the new Header from the UPF to the C-PE Node: 192 Outer IP (C-PE Node Address) + Original UDP + Inner IP (UE Packet) 194 . Format of the new Header from C-PE to the UPF Node: 195 Outer IP (UPF Node Address) + Original UDP + Inner IP (UE Packet) 197 There are two possible scenarios of how UPF would be connected to 198 the C-PE node. 200 In different edge networking deployment, the virtual UPF could be 201 co-located with the C-PE node in the same device and that is 202 captured under scenario 1. The other scenario is where UPF would 203 be separated physically from the C-PE node over an IP network, and 204 that is captured under Scenario 2. 206 In Scenario 1, the UDP source port information coming from the 207 mobility domain can be passed to the C-PE node locally through 208 some policy defined in the device. It doesn't require to form an 209 IP packet with the UDP source port info to send it to the 210 physically separated C-PE node. Figure 2 is applicable for 211 Scenario 2, where UPF needs to forward the IP packet with the 212 original UDP source port information to the physically separated 213 C-PE node. 215 Scenario 1: 217 +-----------+ +------+ 218 | | | | 219 UE---------| gNB-CU(UP)|------------------| UPF +|--------DN 220 | | | C-PE | 221 +-----------+ +------+ 223 |---- N3 OR N9 ----| 225 |----------- Mobile Network --------------||-- IP Network--| 227 Scenario 2: 229 +-----------+ +-----+ +-----+ 230 | | | | | | 231 UE---------| gNB-CU(UP)|-------| UPF |-------| C-PE|------DN 232 | | | | | | 233 +-----------+ +-----+ +-- --+ 235 |-- N3 OR N9 --| |-- N6--| 237 |------- Mobile Network--------||------ IP Network ------| 239 Figure 1: Mobile and IP Data Network for UE 241 1. UE Packet in the Mobile Network: 243 +---------+----------+-------+-----+----------+ 244 | UE Data | Inner IP | GTP-U | UDP | Outer IP | 245 +---------+----------+-------+-----+----------+ 247 2. UE Packet in the IP Network: 249 +---------+----------+--------------+---------+ 250 | UE Data | Inner IP | Original UDP | C-PE IP | 251 +---------+----------+--------------+---------+ 253 Figure 2: UE Packet Transition from Mobile to IP Network 255 5. Transport Network Characteristics Mapping to SR-TE Paths 257 With the 5G Mobile Networking, the UPF would be terminating the 258 mobile connection from the UE. In some Edge Networking scenarios, 259 the UPF would be co-located with the C-PE or it would be connected 260 to the C-PE node over IP Network. 262 The 5G UE traffic coming to the UPF might be carrying Transport 263 Network Characteristics. In that scenario, there would be a need 264 to maintain Transport Path Characteristic through the core of the 265 network so that end to end SLA can be maintained for the UE 266 traffic. 268 In scenarios where ingress PE acting as SR-TE node, the mapping of 269 Transport Network Aware Mobility {5G UDP Src Port Range} to {BGP 270 SR-TE Policy, BSID} to be done at the ingress PE. Once this 271 mapping is done, the mobility Transport Path Characteristics can 272 be maintained in the data network. 274 On a PE node, based on the transport characteristics, the current 275 solution proposes different methods of applying SR-TE path 276 segments: 278 Scenario 1: In this scenario, the assumption is that the Ingress 279 PE node is connected to the BGP SR-TE Controller through the BGP 280 SR-TE Policy SAFI Session, then this solution defines a mechanism 281 to map the BGP SR-TE Underlay Path Segments based on the Mobility 282 Transport Characteristics. 284 . This mechanism would require a new BGP Sub-TLV as part of the 285 existing SR Policy SAFI NLRI to download SR-TE Policies 286 corresponds to the mobility Transport Path characteristics. 287 If the TN aware mobility packet UDP Source Port value falls 288 within the UDP Src Port range value of this Sub-TLV, then the 289 pre-downloaded SR-TE Policy MUST be applied on the mobility 290 traffic to map to the correct network slice in the Data 291 Network. Once the Policy is fetched it would be cached by the 292 PE node for operating in-line for the subsequent mobility TN 293 aware packets. 295 Scenario 2: In this scenario, the assumption is that the Ingress 296 PE node is connected to the SR-PCE (Path Compute Element) 297 Controller through the PCEP Session, then this draft defines a 298 mechanism to map the SR-TE Underlay Segments based on the Mobility 299 Transport Characteristics. 301 . Currently, this mechanism does not require new encoding in 302 the PCEP based communication, though it needs local 303 Configuration in the PE node to request the SR-TE Paths from 304 the PCEP based Controller based on on-demand TN aware 305 mobility traffic. 307 Scenario 3: In this scenario, the assumption is that the Ingress 308 PE node is connected to the SR-TE Controller over Restconf/ 309 Netconf or gRPC session. The existing mechanism would be used to 310 download the SR-TE Underlay Path Segments to the PE node based on 311 the Mobility Transport Path Characteristics. 313 . The Yang Data Model or Protobuf definition is required to 314 define a new Sub-TLV like Scenario 1. The SR-TE Controller 315 would pre-download the SR-TE Policies with the new Sub-TLV in 316 the Ingress PE using the existing session. Once the specific 317 SR-TE Policy is fetched, it would be cached by the Ingress PE 318 to apply for the mobility TN aware traffic in-line to 319 maintain the network characteristics in the Data Network. 321 5.1. Extend TN Aware Mobility for BGP SR-TE Policy 323 1) To integrate Transport Network Aware Mobility with BGP SR-TE 324 Policy at the Ingress PE UPF, the Class-map needs to be defined to 325 classify the incoming mobility traffic with different Transport 326 Path Characteristic. 328 2) The Ingress PE UPF is assumed to have a BGP SR-TE Policy SAFI 329 connection with the BGP SR-TE Controller. The Mobility traffic 330 destination would resolve in the BGP Peer Next Hop for which SR-TE 331 Policy to be applied to maintain the same network characteristics 332 beyond the mobility domain. 334 3) A new 5G Metadata Sub-TLV has been defined for existing SR-Policy 335 SAFI with the UDP Source Port Range to identify the SR-TE path 336 based on the Transport Path characteristics. 338 4) The BGP SR-TE Controller would be programmed with {5G UDP Src Port 339 Range}. That would create internal mapping Table for {5G UDP Src 340 Port Range} < -- > {BGP SR-TE Policy, BSID}. 342 5) The BGP SR-TE Controller would download the SR-TE Policy in the 343 Ingress PE through the existing BGP SR-Policy SAFI session, and 344 that the BGP update would include an additional 5G Metadata Sub- 345 TLV. The UDP Src Port range in the 5G Metadata Sub-TLV MUST fall 346 within the UDP Source Port range for the SSTs defined by the [TN- 347 AWARE-MOBILITY] draft. If the UDP Src Port range falls outside the 348 range defined by the [TN-AWARE-MOBILITY] draft, then the SR-TE 349 Policy SHOULD be ignored by the Ingress PE. 351 6) The SR-TE Policy-based traffic steering would be applied in the 352 Ingress PE and it would maintain the local mapping for the reverse 353 Mobility traffic to the UE. 355 The following class-map definition needs to be applied in the 356 headend PE for the incoming Transport Network aware mobility traffic 357 path: 359 Class-map type traffic match MIOT 361 Match UDP Src Port Range Xx - Xy 363 Class-map type traffic match URLLC 365 Match UDP Src Port Range Yx - Yy 367 Class-map type traffic match EMBB 369 Match UDP Src Port Range Zx - Zy 371 The class-map would help to identify the incoming mobility traffic 372 characteristics. Based on these characteristics the headend PE would 373 be able to map the Transport Network aware mobility traffic to the 374 appropriate BGP SR-TE Policy path over the Data Network to reach the 375 UE's destination. 377 The below figure tries to capture the overall topology, and how to 378 map the mobility traffic in the Ingress PE having BGP SR-Policy SAFI 379 connection with the BGP SR-TE Controller: 381 +-----------+ +----+{5G UDP Src Port Range} 382 | BGP SR-TE |-->| Map| <--> 383 | Controller| | DB |{BGP SR-TE Policy, BSID} 384 +-----------+ +----+ 385 / 386 / 387 / 388 / 389 / +--------+ 390 / BGP SR-TE Policy with |IOT Data| 391 / 5G Metadata Sub-TLV +--------+ 392 / /Public 393 / MIOT / Cloud 394 / / 395 +------+ Policy1: UDP Src Port Xx-Xy +------+ / 396 | A1------------------------------B1 |/ 397 | | Policy2: UDP Src Port Yx-Yy | | URLLC 398 UE------| UPF A2------------------------------B2 PE2 |------Internet 399 | +PE1 | Policy3: UDP Src Port Zx-Zy | | 400 | A3------------------------------B3 |\ 401 | | | | \ 402 +------+ +------+ \ 403 {UDP Src Port Num# <--> SR Policy N} EMBB \ 404 \ 405 +--------+ 406 | Content| 407 +--------+ 408 ----------> Private DC 409 +------+----------+-------+-----+----------+ 410 | Data | Inner IP | GTP-U | UDP | Outer IP | 411 +------+----------+-------+-----+----------+ 413 ----------> 414 +------+----------+-----+--------------+ 415 | Data | Inner IP | GRE | SR-TE Header | 416 +------+----------+-----+--------------+ 418 Figure 3: TN Aware Mobility Traffic Mapping to BGP SR-TE Policy Path 420 Note that, in the above figure the GRE and SR-TE Header is shown as 421 an illustrative purposes and the actual outgoing packet format is 422 based on the SR-TE mechanism (SR-MPLS or SRv6) on the Ingress PE. 424 To support the Transport Network Mobility Traffic Mapping to BGP SR- 425 TE Policy Path in the headend PE, a new 5G Metadata Sub-TLV needs to 426 be supported. The proposed BGP SR Policy Encoding from the BGP SR-TE 427 Policy Controller to the headend PE node is defined below: 429 SR Policy SAFI NLRI: 430 Attributes: 431 Tunnel Encap Attr (23) 432 Tunnel Type: SR Policy 433 Existing Policy Sub-TLV 434 5G Metadata Sub-TLV 436 The draft [BGP-SR-TE-POLICY] defines BGP SR-TE Policy encodings. 437 There is no change in the existing encoding that is being used from 438 the BGP SR-TE Controller to the headend PE node. The current 439 solution proposes the new 5G Metadata Sub-TLV for BGP SR-TE 440 Controller to download the SR Policies to the headend PE and to 441 apply the SR-TE Policy-driven path for the Transport Network aware 442 mobility traffic. 444 The incoming TN aware mobility traffic with UDP Src port and BGP NH 445 to the traffic destination would be used as a key to find the BGP 446 SR-TE Policy. If the BGP Next Hop of the traffic matches with the SR 447 Policy SAFI NLRI Endpoint, and UDP Src Port value falls within the 448 UDP Src Port range defined by the 5G Metadata Sub-TLV, the SR Policy 449 would be applied to the mobility traffic to maintain the traffic 450 characteristics in the data network. The BGP SR-TE Controller would 451 be pre-provisioned with the 5G UDP SRC Port Range based on the [TN- 452 AWARE-MOBILITY] draft, and their corresponding BGP SR-TE Policy. 454 The 5G Metadata sub-TLV is optional and it MUST NOT appear more than 455 once in the SR-TE Policy. 457 The format of the new SR-TE 5G Metadata Sub-TLV is captured below: 459 0 1 2 3 460 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 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | Type | Sub-Type | Length | Flags | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | UDP Src Port Start Value | UDP Src Port End Value | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 5G Metadata Sub-TLV 468 where: 470 o Type: To be defined by IANA. 472 o Sub-Type: This field has one of the following values: 474 0: Reserved. 475 1: UDP Source Port Range. 476 2 - 255: Reserved for future use. 478 o Length: 6 octets. 480 o Flags: 1 octet of flags. None are defined at this stage. Flags 481 SHOULD be set to zero on transmission and MUST be ignored on 482 receipt. 484 o UDP Src Port Start Value: 2 octets value to define the staring of 485 the value of the UDP Src Port range. 487 o UDP Src Port End Value: 2 octets value to define the end value of 488 the UDP Src Port range. 490 5.2. Extend TN Aware Mobility for SR-PCE Controller 492 1) To integrate Transport Network Aware Mobility with SR-TE ODN based 493 PCE Controller at the Ingress PE UPF, the Class-map needs to be 494 defined to classify the incoming mobility traffic with different 495 Transport Path Characteristic. 497 2) The Ingress PE UPF is assumed to have PCEP based communication 498 with the SR-PCE Controller. 500 3) The Ingress PE would define the Policy-map to map the Transport 501 Path characteristics into SR-TE Color. 503 4) The Segment Routing TE Configuration for different Metric types 504 will associate the SR-TE Colors with their corresponding TE metric 505 type. 507 5) The existing SR-TE ODN based PCEP messages with TE metric type and 508 value MUST be used to associate the SR-TE Path corresponding to 509 the 5G UDP Src Port. 511 6) In this case, the mapping between {5G UDP Src Port} and {SR-TE 512 Policy} would be maintained by the Ingress PE. 514 7) Once the TN aware mobility traffic destination resolves into a 515 destination of BGP Peer Next Hop, the SR-TE ODN based traffic 516 steering MUST be applied based on the UDP Src Port value of the 517 incoming traffic. 519 The class-map definition to identify the incoming mobility traffic 520 characteristics is already defined in Section 5.1. The same class- 521 map definition applicable here as well. 523 The policy-map definition to associate SR-TE color with Transport 524 Path characteristics is defined below: 526 Policy-map type Transport-Network-Aware-Mobility 528 Class type traffic MIOT 530 Set color 532 Class type traffic URLLC 534 Set color 536 Class type traffic EMBB 538 Set color 540 The Segment Routing TE Configuration mechanism can associate the SR- 541 TE Colors with their corresponding metric type. That exists today, 542 and there is no change there. It is captured here to show how TN 543 aware mobility network characteristics get mapped to different TE 544 metrics through this mechanism. 546 Segment-routing traffic-eng 548 On-demand color dynamic 550 Metric 552 Type te 554 On-demand color dynamic 556 Metric 558 Type latency 560 On-demand color dynamic 562 Metric 564 Type igp 566 As a result, mobility Transport Network aware different traffic 567 characteristics like MIOT, URLLC, or EMBB get to assigned 568 corresponding "te" metric types. To fetch the corresponding SR-TE 569 dynamic path from the SR-PCE Controller based on the "te" metric 570 types exists today. 572 The below figure tries to capture the overall topology, and how to 573 map the mobility traffic in the headend PE having PCEP connection 574 with the SR-PCE Controller: 576 +-----------+ 577 | SR-PCE | 578 | Controller| 579 +-----------+ 580 / 581 / 582 PCReq Message / 583 with Metric Type/ 584 / +--------+ 585 / |IOT Data| 586 / PCRep Message +--------+ 587 / with Segment List /Public 588 / MIOT / Cloud 589 / / 590 +------+ Policy1: UDP Src Port Xx-Xy +-----+ / 591 | A1-----------------------------B1 |/ 592 | | Policy2: UDP Src Port Yx-Yy | | URLLC 593 UE------| UPF A2-----------------------------B2 PE2 |------Internet 594 | +PE1 | Policy3: UDP Src Port Zx-Zy | | 595 | A3-----------------------------B3 |\ 596 | | | | \ 597 +------+ +-----+ \ 598 {UDP Src Port Num# <--> SR Policy N} EMBB \ 599 \ 600 +--------+ 601 | Content| 602 +--------+ 603 Private DC 605 Figure 4: TN Aware Mobility Traffic Mapping to SR-TE Path 607 5.3. Extend TN Aware Mobility for SR-TE Controller 609 1) To integrate Transport Network Aware Mobility with SR-TE Policy at 610 the Ingress PE UPF, the Class-map needs to be defined to classify 611 the incoming mobility traffic with different Transport Path 612 Characteristic. 614 2) The Headend PE UPF is assumed to have Restconf or gRPC connection 615 with the SR-TE Controller. The Mobility traffic destination would 616 resolve in the BGP Peer Next Hop for which SR-TE Policy to be 617 applied to maintain the same network characteristics beyond the 618 mobility domain. 620 3) A new 5G Metadata Yang data model and Protobuf to be defined for 621 SR-Policy SAFI with UDP Source Port Range to identify the SR-TE 622 path based on the Transport Path characteristics. 624 4) The SR-TE Controller would be programmed with {5G UDP Src Port 625 Range}. That would create internal mapping Table for {5G UDP Src 626 Port Range} < -- > {BGP SR-TE Policy, BSID}. 628 5) As the Headend PE sends the 5G metadata Yang data model or 629 Protobuf, the Controller will find a matching SR-TE Policy based 630 on the UDP Source Port. 632 6) The SR-TE Controller would download the SR-TE Policy in the 633 Ingress PE through the existing Restconf or gRPC session, and that 634 BGP update would include an additional 5G Metadata Sub-TLV. The 635 UDP Src Port range in the 5G Metadata Sub-TLV MUST fall within the 636 UDP Source Port range for the SSTs defined by the [TN-AWARE- 637 MOBILITY] draft. If the UDP Src Port range falls outside the range 638 defined by the [TN-AWARE-MOBILITY] draft, then the SR-TE Policy 639 SHOULD be ignored by the Ingress PE. 641 7) The SR-TE Policy-based traffic steering would be applied in the 642 Ingress PE UPF and it would maintain the local mapping for the 643 reverse Mobility traffic to the UE. 645 The class-map definition to identify the incoming mobility traffic 646 characteristics is already defined in Section 5.1. The same class- 647 map definition works here as well. 649 The below figure tries to capture the overall topology, and how to 650 map the mobility traffic in the headend PE having BGP SR-Policy SAFI 651 connection with the BGP SR-PCE Controller: 653 +-----------+ +----+{5G UDP Src Port Range} 654 | BGP SR-TE |-->| Map| <--> 655 | Controller| | DB |{BGP SR-TE Policy, BSID} 656 +-----------+ +----+ 657 / 658 / 659 / 660 Restconf or gRPC / 661 Session / +--------+ 662 / SR-Policy with |IOT Data| 663 / 5G Metadata Sub-TLV +--------+ 664 / /Public 665 / MIOT / Cloud 666 / / 667 +-------+ Policy1: UDP Src Port Xx-Xy +-----+ / 668 | A1------------------------------B1 |/ 669 | | Policy2: UDP Src Port Yx-Yy | | URLLC 670 UE------| UPF + A2------------------------------B2 PE2 |------Internet 671 | PE1 | Policy3: UDP Src Port Zx-Zy | | 672 | A3------------------------------B3 |\ 673 | | | | \ 674 +-------+ +-----+ \ 675 {UDP Src Port Num# <--> SR Policy N} EMBB \ 676 \ 677 +--------+ 678 | Content| 679 +--------+ 680 Private DC 682 Figure 5: TN Aware Mobility Traffic Mapping to SR-TE Path 684 6. Mapping of TN Characteristics on SD-WAN Edge Node 686 On an SD-WAN CE Node, based on the mobility Transport Network 687 characteristics, mapping of mobility aware transport packets to 688 the secure and un-secure tunnel path needs to be achieved. 690 The [BGP-IPSEC-Discover] draft defines how SD-WAN Edge Node maps 691 the overlay/client routes to the underlay secure tunnel routes. 693 The current proposal specifies a generic approach on how SD-WAN 694 Edge Node maps the Mobility Transport Network aware traffic to the 695 Secure Tunnels, or Un-Secure TE Paths, or Secure SR-TE Tunnel 696 Paths. 698 The [SDWAN-BGP-USAGE] draft describes how BGP can be used as a 699 Control Plane for the SD-WAN network and defines the use case for 700 the Hybrid SD-WAN network. 702 In the case of a hybrid SD-WAN use case, UPF can run part of the 703 SD-WAN edge node or it could be connected to it over an IP 704 network. This would be a use case scenario for Enterprise 5G. 706 In that scenario, the Transport Path Characteristic for the 5G 707 mobile traffic need to be mapped to Secure (IPSec Tunnel) or Un- 708 secure path (could be MPLS based). 710 The existing [TN-AWARE-MOBILITY] draft needs to be extended to 711 support new Transport Path Characteristics "Security" for the 712 mobile traffic where security is important for certain mobile 713 traffic. 715 Based on the UDP Src Port characteristics coming from the mobile 716 network, the SD-WAN edge node would be able to decide what traffic 717 it needs to put in the secure tunnel vs. un-secure tunnel where 718 low latency more important than security. 720 The below figure tries to capture the overall topology, and how to 721 map the mobility traffic in the SD-WAN Edge Device for Enterprise 722 5G cases: 724 +----------+ 725 | BGP RR | 726 +----|Controller|----+ 727 / +----------+ \ 728 / \ Internet 729 / \ / 730 / \ / 731 / \ URLLC/ 732 / \ / 733 / \ / 734 +-------+ MPLS Path: URLLC Traffic +------+ / 735 | A1---------------------------B1 |/ 736 | | Secure Path1: MIOT Traffic | | MIOT +--------+ 737 UE-----| UPF + A2---------------------------B2 C-PE2|------|IOT Data| 738 | C-PE1 | Secure Path2: EMBB Traffic | | +--------+ 739 | A3---------------------------B3 |\ Public 740 | | | | \ Cloud 741 +-------+ +------+ \ 742 {UDP Src Port Num X <--> MPLS} \ 743 {UDP Src Port Num Y <--> IPSec SA Identifier} EMBB \ 744 \ +-------+ 745 \|Content| 746 +-------+ 747 Public 748 Cloud 750 Figure 6: TN Aware Mobility Traffic Mapping in the SD-WAN Edge Device 752 Here in this diagram, the traffic coming from the mobility side with 753 Transport Network characteristics gets mapped to the underlay un- 754 secure or secure traffic path. 756 The SD-WAN Edge Node can map the URLLC traffic without any security 757 characteristics to the underlay MPLS path, whereas MIOT, and EMBB 758 traffic with security characteristics gets mapped to the underlay 759 Secure IPSec Tunnel path. The mapping between SD-WAN overlay and 760 underlay routes are described in the [BGP-IPSEC-Discovery] draft. 762 This solution extends it for Transport Network aware mobility 763 traffic. The SD-WAN Edge Node here identifies the incoming mobility 764 traffic characteristics using the class-map definition, and that is 765 already defined under Section 5.1. Based on the incoming traffic 766 characteristics, the Edge Node will be able to map the mobility 767 overlay traffic with the SD-WAN underlay tunnel. 769 7. IANA Considerations 771 The newly defined 5G Metadata Sub-TLV would need an IANA code point 772 allocation for the Type field. A request for any IANA code point 773 allocation would be submitted. 775 8. Security Considerations 777 This document does not introduce any new security issues. 779 9. References 781 9.1. Normative References 783 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 784 Requirement Levels", BCP 14, RFC 2119, March 1997. 786 9.2. Informative References 788 [RFC5440] JP. Vasseur, Ed., JL. Le Roux, Ed., "Path Computation 789 Element (PCE) Communication Protocol (PCEP)", March 2009 791 [TN-AWARE-MOBILITY] U. Chunduri, et al, "Transport Network aware 792 Mobility for 5G", draft-clt-dmm-tn-aware-mobility-07, April 2021 794 [BGP-SR-TE-POLICY] S. Previdi, et al, "Advertising Segment Routing 795 Policies in BGP", draft-ietf-idr-segment-routing-te-policy-09, 796 November 2020 798 [SDWAN-BGP-USAGE] L. Dunber, et al, "BGP Usage for SDWAN Overlay 799 Networks", draft-dunbar-bess-bgp-sdwan-usage-08, January 2021 801 [BGP-IPSEC-Discover] L. Dunber, et al, "BGP UPDATE for SDWAN Edge 802 Discovery", draft-dunbar-idr-sdwan-edge-discovery-00, January 2021 804 [Tunnel-Encap] E. Rosen, et al "The BGP Tunnel Encapsulation 805 Attribute", draft-ietf-idr-tunnel-encaps-19, March 2021. 807 10. Acknowledgments 809 TBD. 811 This document was prepared using 2-Word-v2.0.template.dot. 813 Authors' Addresses 815 Kausik Majumdar 816 CommScope 817 350 W Java Drive, Sunnyvale, CA 94089 819 Email: kausik.majumdar@commscope.com 821 Uma Chunduri 822 Futurewei 823 2330 Central Expressway 824 Santa Clara, CA 95050 826 Email: umac.ietf@gmail.com 828 Linda Dunbar 829 Futurewei 830 2330 Central Expressway 831 Santa Clara, CA 95050 833 Email: linda.dunbar@futurewei.com