idnits 2.17.1 draft-dunbar-6man-5g-edge-compute-sticky-service-03.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([APN6]), 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 29, 2021) is 1123 days in the past. Is this intentional? Checking references for intended status: Full Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'A-ER' is mentioned on line 281, but not defined == Missing Reference: 'RFC8799' is mentioned on line 393, but not defined == Unused Reference: 'RFC4364' is defined on line 761, but no explicit reference was found in the text == Unused Reference: '3GPP-EdgeComputing' is defined on line 774, but no explicit reference was found in the text == Unused Reference: 'RFC5521' is defined on line 791, but no explicit reference was found in the text == Unused Reference: 'BGP-SDWAN-Port' is defined on line 795, but no explicit reference was found in the text == Unused Reference: 'SDWAN-EDGE-Discovery' is defined on line 799, 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 ** Downref: Normative reference to an Proposed Standard RFC: RFC 4364 == Outdated reference: A later version (-02) exists of draft-dunbar-ippm-5g-edge-compute-ip-layer-metrics-00 == 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-10 Summary: 2 errors (**), 0 flaws (~~), 13 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group L. Dunbar 2 Internet Draft J. Kaippallimalil 3 Intended status: Standard Futurewei 4 Expires: September 29, 2021 5 March 29, 2021 7 IPv6 Solution for 5G Edge Computing Sticky Service 8 draft-dunbar-6man-5g-edge-compute-sticky-service-03 10 Abstract 12 This draft describes an IPv6 solution that can stick an 13 application flow originated from a mobile device to the same 14 ANYCAST server location when the mobile device moves from one 15 5G cell site to another. 17 The proposed solution expands the Application-aware ID and 18 Service-Para options specified by [APN6] by including the 19 ANYCAST Sticky Service location information in the IPv6 Hop-by- 20 Hop or Destination Optional Header. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. This document may not be 29 modified, and derivative works of it may not be created, except 30 to publish it as an RFC and to translate it into languages 31 other than English. 33 Internet-Drafts are working documents of the Internet 34 Engineering Task Force (IETF), its areas, and its working 35 groups. Note that other groups may also distribute working 36 documents as Internet-Drafts. 38 Internet-Drafts are draft documents valid for a maximum of six 39 months and may be updated, replaced, or obsoleted by other 40 documents at any time. It is inappropriate to use Internet- 41 Drafts as reference material or to cite them other than as 42 "work in progress." 44 Internet-Draft IPv6 for 5G Edge Sticky Service 46 The list of current Internet-Drafts can be accessed at 47 http://www.ietf.org/ietf/1id-abstracts.txt 49 The list of Internet-Draft Shadow Directories can be accessed 50 at http://www.ietf.org/shadow.html 52 This Internet-Draft will expire on April 7, 2021. 54 Copyright Notice 56 Copyright (c) 2021 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with 64 respect to this document. Code Components extracted from this 65 document must include Simplified BSD License text as described 66 in Section 4.e of the Trust Legal Provisions and are provided 67 without warranty as described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction.................................................. 3 72 1.1. 5G Edge Computing Background.......................... 3 73 1.2. 5G Edge Computing Network Properties.................. 4 74 1.3. Problem #1: ANYCAST in 5G EC Environment.............. 5 75 1.4. Problem #2: sticking to original App Server........... 6 76 1.5. Problem #3: Application Server Relocation............. 6 77 2. Conventions used in this document............................. 7 78 3. Sticky Egress node to an ANYCAST Server....................... 8 79 4. Solutions within a Limited Domain............................. 9 80 4.1. Use Case of 5G Edge Computing in a limited domain.... 10 81 4.2. End Node Based Sticky Service Solution............... 10 82 4.2.1. Solution based on SRH........................... 11 83 4.3. Sticky Egress Address Discovery...................... 11 84 4.4. Sticky-Dst-SubTLV in Destination Extension Header.... 12 85 4.5. Processing at the Ingress router..................... 12 86 5. Tunnel based Sticky Service Solutions........................ 13 87 Internet-Draft IPv6 for 5G Edge Sticky Service 89 5.1. Ingress and Egress Routers Processing Behavior....... 13 90 5.2. A Solution without the Communication with 5G system.. 15 91 5.3. A Solution that depends on the communication with 5G 92 system.................................................... 16 93 5.4. Solutions within a Limited Domain.................... 16 94 6. Expanding APN6 for Sticky Service information................ 17 95 6.1. Sticky Service ID encoded in the Application-aware ID 17 96 6.2. Sticky Service Sub-TLV encoded in APN6 Service-para 97 option.................................................... 17 98 7. Manageability Considerations................................. 17 99 8. Security Considerations...................................... 17 100 9. IANA Considerations.......................................... 18 101 10. References.................................................. 18 102 10.1. Normative References................................ 18 103 10.2. Informative References.............................. 18 104 11. Acknowledgments............................................. 19 106 1. Introduction 108 1.1. 5G Edge Computing Background 110 As described in [5G-EC-Metrics], one application in 5G Edge 111 Computing environment can have multiple application servers 112 hosted in different Edge Computing data centers close in 113 proximity. Those Edge Computing (mini) data centers are usually 114 very close to, or co-located with, 5G base stations, to 115 minimize latency and optimize the performances. 117 When a mobile device sends packets using the destination 118 address from a DNS reply or its own cache, the packets are 119 carried by a GTP tunnel from the 5G eNB to the 5G UPF-PSA (User 120 Plan Function - PDU Session Anchor). The UPF-PSA decapsulates 121 the 5G GTP outer header and forwards the packets from the 122 mobile devices to the Ingress router of the Edge Computing (EC) 123 Local Data Network (LDN). The LDN for 5G EC, the IP Networks, 124 is responsible for forwarding the packets to the intended 125 destinations. 127 When the mobile device moves out of coverage of its current gNB 128 (next-generation Node B) (gNB1), handover procedures are 129 initiated, and the 5G SMF (Session Management Function) selects 130 a new UPF-PSA. The standard handover procedures are described 131 in 3GPP TS 23.501 and TS 23.502. When the handover process is 132 complete, the mobile device might be anchored to a new UPF-PSA. 134 Internet-Draft IPv6 for 5G Edge Sticky Service 136 5G Session Management function (SMF) may maintain a path from 137 the old UPF to the new UPF for a short period of time for SSC 138 [Session and Service Continuity] mode 3 to make the handover 139 process more seamless. 141 1.2. 5G Edge Computing Network Properties 143 In this document, 5G Edge Computing Network refers to multiple 144 Local IP Data Networks (LDN) in one region that interconnect 145 the Edge Computing mini-data centers. Those IP LDN networks are 146 the N6 interfaces from 3GPP 5G perspective. 148 The ingress routers to the 5G Edge Computing Network are 149 directly connected to 5G UPFs. The egress routers to the 5G 150 Edge Computing Network are the routers that have a direct link 151 to the Edge Computing servers. The servers and the egress 152 routers are co-located. Some of those mini Edge Computing Data 153 centers may have Virtual switches or Top of Rack switches 154 between the egress routers and the servers. But transmission 155 delay between the egress routers and the Edge Computing servers 156 is very small, which is considered negligible in this document. 158 When one mini data center has multiple Edge Computing Servers 159 attached to one App Layer Load Balancer, only the App Layer 160 Load Balancer is visible to the 5G Edge Computing Network. How 161 the App Layer Load balancer manages the individual servers is 162 out of the scope of the document. 164 The Edge Computer Services are specially managed services that 165 need to utilize the network topology and balance among multiple 166 mini Edge Computing Data Centers with the same ANYCAST address. 167 A mobile device can access services that are not part of the 168 registered 5G Edge Computing Services. 170 Internet-Draft IPv6 for 5G Edge Sticky Service 172 +--+ 173 |MD|---\+---------+ +------------------+ 174 +--+ | 5G | +---------+ | S1: aa08::4450 | 175 +--+ | Site +--++---+ +----+ | 176 |MD|----| A |PSA| Ra| | R1 | S2: aa08::4460 | 177 +--+ | +---+---+ +----+ | 178 +---+ | | | | | S3: aa08::4470 | 179 |MD1|---/+---------+ | | +------------------+ 180 +---+ |IP Network | L-DN1 181 |(3GPP N6) | 182 | | | +------------------+ 183 | MB1 | | | S1: aa08::4450 | 184 | moves to | +----+ | 185 | Site B | | R3 | S2: aa08::4460 | 186 v | +----+ | 187 | | | S3: aa08::4470 | 188 | | +------------------+ 189 | | L-DN3 190 +--+ | | 191 |MD|---\+---------+ | | +------------------+ 192 +--+ | 5G | | | | S1: aa08::4450 | 193 +--+ | Site +--++-+--+ +----+ | 194 |MD|----| B |PSA| Rb | | R2 | S2: aa08::4460 | 195 +--+ | +--++----+ +----+ | 196 +--+ | | +-----------+ | S3: aa08::4470 | 197 |MD|---/+---------+ +------------------+ 198 +--+ L-DN2 199 Figure 1: App Servers in different edge DCs 201 1.3. Problem #1: ANYCAST in 5G EC Environment 203 Increasingly, ANYCAST is used extensively by various 204 application providers because it is possible to dynamically 205 load balance across multiple locations of the same address 206 based on network conditions. When multiple servers in different 207 locations have the same IP address (ANYCAST), routers see 208 multiple paths to the IP address. 210 Application Server location selection using Anycast address 211 leverages the proximity information present in the network 212 routing layer and eliminates the single point of failure and 214 Internet-Draft IPv6 for 5G Edge Sticky Service 216 bottleneck at the DNS resolvers and application layer load 217 balancers. Another benefit of using ANYCAST address is removing 218 the dependency on mobile devices that use their cached IP 219 addresses instead of querying DNS when they move to a new 220 location. 222 Having multiple locations for the same ANYCAST address in the 223 5G Edge Computing environment can be problematic because all 224 those edge computing Data Centers can be close in proximity. 225 There might not be any difference in the routing cost to reach 226 the Application Servers in different Edge DCs. The same 227 routing cost to multiple locations can cause packets from one 228 flow to be forwarded to different locations, which can cause 229 service glitches. 231 1.4. Problem #2: sticking to original App Server 233 When a mobile device moves to a new location but continues the 234 same application flow, routers at the new location might choose 235 the App Server closer to the new location. As shown in the 236 figure below, when the MD1 in 5G-site-A moves to the 5G-Site-B, 237 the router directly connected to 5G PSA2 might forward the 238 packets destined towards the S1: aa08::4450 to the server 239 located in L-DN2 because L-DN2 has the lowest cost based on 240 routing. This is not the desired behavior for some services, 241 which are called Sticky Services in this document. 243 Even for some advanced applications with built-in mechanisms to 244 re-sync the communications at the application layer after 245 switching to a new location, service glitches are often 246 experienced. 248 It worth noting that not all services need to be sticky. We 249 assume only a subset of services are, and the Network is 250 informed of the services that need to be sticky, usually by 251 requests from application developers or controllers. 253 This document describes an IPv6-based network layer solution to 254 stick the packets belonging to the same flow of a mobile device 255 to its original App Server location after the mobile device is 256 anchored to a new UPF-PSA. 258 1.5. Problem #3: Application Server Relocation 260 When an Application Server is added to, moved, or deleted from 261 a 5G Edge Computing Data Center, the routing protocol has to 262 propagate the changes to 5G PSA or the PSA adjacent routers. 264 Internet-Draft IPv6 for 5G Edge Sticky Service 266 After the change, the cost associated with the site [5G-EC- 267 Metrics] might change as well. 269 Note: for ease of description, the Edge Computing Server, 270 Application Server, or App Server are used interchangeably 271 throughout this document. 273 2. Conventions used in this document 275 APN6 Application aware network using IPv6. The term 276 "Application" has very broad meanings. In this 277 document the term "Application" refers to any 278 applications that use ANYCAST servers in the 5G 279 Edge Computing Environment. 281 A-ER: Egress Router to an Application Server, [A-ER] is 282 used to describe the last router that the 283 Application Server is attached. For 5G EC 284 environment, the A-ER can be the gateway router to 285 a (mini) Edge Computing Data Center. 287 Application Server: An application server is a physical or 288 virtual server that host the software system for 289 the application. 291 Application Server Location: Represent a cluster of servers at 292 one location serving the same Application. One 293 application may have a Layer 7 Load balancer, whose 294 address(es) are reachable from external IP network, 295 in front of a set of application servers. From IP 296 network perspective, this whole group of servers 297 are considered as the Application server at the 298 location. 300 Edge Application Server: used interchangeably with Application 301 Server throughout this document. 303 EC: Edge Computing 305 Internet-Draft IPv6 for 5G Edge Sticky Service 307 Edge Hosting Environment: An environment providing support 308 required for Edge Application Server's execution. 310 NOTE: The above terminologies are the same as those 311 used in 3GPP TR 23.758 313 Edge DC: Edge Data Center, which provides the Edge Computing 314 Hosting Environment. It might be co-located with or 315 very close to a 5G Base Station. 317 gNB next generation Node B 319 L-DN: Local Data Network 321 MD: Mobile Device, which is the same as the UE (User 322 Equipment) used in 3GPP. The term "mobile device" 323 is used instead of UE to emphasize on sticking 324 services originated from the devices that are 325 mobile to same server. 327 PSA: PDU Session Anchor (UPF) 329 SSC: Session and Service Continuity 331 UE: User Equipment. UE is same as a mobile device in 332 this document. 334 UPF: User Plane Function 336 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 337 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", 338 "MAY", and "OPTIONAL" in this document are to be interpreted as 339 described in BCP 14 [RFC2119] [RFC8174] when, and only when, 340 they appear in all capitals, as shown here. 342 3. Sticky Egress node to an ANYCAST Server 344 From Local Data Network perspective, achieving Sticky Service 345 for a flow from a mobile device to a specific ANYCAST server is 346 the same as delivering the packets of the flow to the same 347 egress router, e.g., R1 in Figure 1, to which the ANYCAST 348 Server is attached. The egress router, say R1 in Figure 1, 350 Internet-Draft IPv6 for 5G Edge Sticky Service 352 should deliver the packets destined towards the ANYCAST address 353 to its directly attached server even though the same address is 354 also reachable from other routers, unless the directly attached 355 server is no longer reachable due to Server or Link failure. 357 The egress router, e.g., R1, to which the Edge Computing server 358 is directly attached, is called the Sticky Egress node to the 359 Edge Computing Server at the location. The Sticky Egress node 360 has a unicast address. 362 When there are multiple Edge Computing Servers with the same 363 ANYCAST address located in different (small) Edge Computing 364 Data Centers, each location is identified by its Sticky Egress 365 nodes unicast address(es). To the LDN's ingress routers, e.g., 366 Ra or Rb in Figure 1, achieving sticky service is to send the 367 packets belonging to the same flow to the same Sticky Egress 368 node's unicast address. 370 From a Local Data Network perspective, the Sticky Egress nodes' 371 unicast addresses are the Next Hops (i.e., R1, R2, and R3) to 372 reach the Edge Computing server ANYCAST address. 374 The Flow Affinity feature, which most commercial routers 375 support today, can ensure packets belonging to one flow be 376 forwarded along the same path to the same egress router which 377 then delivers the packets to the attached Edge Computing 378 Server. 380 Editor's note: for IPv6 traffic, Flow Affinity can be supported 381 by the Local Data Network (LDN) routers forwarding the packets 382 with the same Flow Label in the packets' IPv6 Header along the 383 same path towards the same egress router. For IPv4 traffic, 5 384 tuples in the IPv4 header can be used to achieve the Flow 385 Affinity. 387 This document describes the solutions to stick a flow from a 388 mobile device to the same egress router of the App Server after 389 the mobile device moves to a new 5G Site. 391 4. Solutions within a Limited Domain 393 Within a limited domain [RFC8799], mobile devices, edge 394 servers, and network functions are under one administrative 395 domain. Therefore, it is feasible for mobile devices to perform 396 specific actions. 398 Internet-Draft IPv6 for 5G Edge Sticky Service 400 4.1. Use Case of 5G Edge Computing in a limited domain. 402 Some 5G Connected devices, such as drones for fighting natural 403 disasters or robots in Industry 4.0 environments, need ultra- 404 low latency responses from their analytic servers. To reach 405 ultra-low latency, those analytic functions can be hosted on 406 servers very close to radio towers. 408 All the functions (including networking and analytics) and 409 devices are administrated by one operator. Those functions 410 might be provided by different vendors, therefore needing 411 interoperable solutions. 413 4.2. End Node Based Sticky Service Solution 415 The End-Node-based Sticky Service solution needs IPv6 mobile 416 devices to insert the Destination Option header extracted from 417 the packet received from the network side to the IPv6 Header of 418 the next packet if the next packet belongs to the same flow. 419 This action dramatically simplifies the processing at the LDN's 420 Ingress routers. 422 Here are some assumptions for the End-Node based Sticky Service 423 solution: 425 - The mobile devices are under the same administrative 426 control as the Edge computing servers. 427 - If an Edge Computing service needs to be sticky in the 5G 428 Edge Computing environment, the corresponding service ID 429 is registered with the 5G Edge Computing controller. The 430 Sticky Service ID can be the IP address (unicast or 431 ANYCAST) of the server. 433 Here is the overview of the End-Node based Sticky Service 434 solution: 435 - Each ANYCAST Edge Computing server either learns or is 436 informed of the unicast Sticky Egress address (Section 3). 437 The goal is to deliver packets belonging to one flow to 438 the same Sticky Egress address for the ANYCAST address. 439 - When an Edge Computing server sends data packets back to a 440 client (or the mobile device), it inserts the Sticky-Dst- 441 SubTLV (described in Section 4.4) into the packets' 442 Destination Option Header. 444 Internet-Draft IPv6 for 5G Edge Sticky Service 446 - The client (or the mobile device) needs to copy the 447 Destination Option Header from the received packet to the 448 next packet's Destination Header if the next packet 449 belongs to the same flow as the previous packet. 450 - If the following conditions are true, the ingress router 451 encapsulates the packet from the client in a tunnel whose 452 outer destination address is set to the Sticky Egress 453 Address extracted from the packet's Sticky-Dst-SubTLV: 454 o The destination of the packet from the client-side 455 matches with one of the Sticky Service ACLs 456 configured on the ingress router of the LDN, 457 o the packet header has the Destination Option present 458 with Sticky-Dst-SubTLV. 459 - Else (i.e., one of the conditions above is not true), the 460 ingress node uses its algorithm, such as the least cost as 461 described in [5G-EC-Metrics], to select the optimal Sticky 462 Egress address for forwarding the packet. 464 4.2.1. Solution based on SRH. 466 To be added. 468 4.3. Sticky Egress Address Discovery 470 To an App server with ANYCAST address, the Sticky Egress 471 address is the same as its default Gateway address. 473 To prevent malicious entities sending DDOS attacks to routers 474 within 5G EC LDN, e.g., the Sticky Egress address that is 475 encoded in the Destination option header in the packets sent 476 back to the clients, a proxy Sticky Egress address can be 477 encoded in the Destination option header. The proxy Sticky 478 Egress address is only recognizable by the 5G EC LDN ingress 479 nodes, i.e., the Ra and Rb in Figure 1, but not routable in 480 other networks. The LDN ingress routers can translate the proxy 481 Sticky Egress to a routable address for the Sticky Egress node 482 after the source addresses of the packets are authenticated. 484 Internet-Draft IPv6 for 5G Edge Sticky Service 486 4.4. Sticky-Dst-SubTLV in Destination Extension Header 488 A new Sticky-Dst-SubTLV is specified as below, which can be 489 inserted into the IPv6 Destination Options header. The IPv6 490 Destination Option Header is specified by [RFC8200] as having a 491 Next Header value of 60: 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | Next Header | Hdr Ext Len | | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 496 | | 497 | Sticky-Dst-SubTLV | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 Sticky-Dst-SubTLV is specified as: 502 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 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | Sticky-Type | Len | AFI | Reserved | 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 |Sticky Egress address (IPv4 or IPv6) for reaching the ANYCAST | 507 ~ ~ 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 Sticky-Type = 1: indicate the Sticky Egress unicast address 511 at encoded in the Sticky-Dst-SubTLV. 513 4.5. Processing at the Ingress router 515 - An Ingress router is configured with an ACL for filtering 516 out the applications that need sticky service. 518 Note, not all applications need sticky service. Using ACL 519 can significantly reduce the processing on the routers. 521 - When an Ingress router receives a packet from the 5G side 522 that matches the ACL, the Ingress router extracts the 523 Sticky-Dst-SubTLV from the packet IPv6 header if the field 524 exists in the packet header. 526 Internet-Draft IPv6 for 5G Edge Sticky Service 528 - Encapsulate the packet with the tunnel type that are 529 supported by the original Sticky Egress node, using the 530 extracted Sticky Egress address in the destination field 531 of the outer Header, and forward the packet. 533 Note: if the proxy Sticky Egress address is encoded in the 534 Sticky-Dst-SubTLV, the ingress router needs to translate 535 the proxy Sticky Egress address to a routable address. 537 If none of the above conditions are met, the ingress router 538 uses its algorithm to select the optimal Sticky Egress node 539 to forward the packet. 541 5. Tunnel based Sticky Service Solutions 543 For environments that mobile devices cannot change their 544 processing behavior as described in the Section 4, a Tunnel 545 based Sticky Service solution can be used. This solution does 546 not depend on mobile device's behavior, therefore, more 547 processing on the LDN ingress routers is needed. 548 5.1. Ingress and Egress Routers Processing Behavior 550 The solution assumes that both ingress routers and egress 551 routers support at least one type of tunnel and are configured 552 with ACLs to filter out packets whose destination or source 553 addresses match with the Sticky Service Identifier. The 554 solution also assumes there are only limited number of Sticky 555 Services to be supported. 556 An ingress router needs to build a Sticky-Service-Table, with 557 the following minimum attributes. The Sticky-Service-Table is 558 initialized to be empty. 559 - Sticky Service ID 560 - Flow Label 561 - Sticky Egress address 562 - Timer 564 Editor's Note: 565 When a mobile device moves from one 5G Site to another, the 566 same mobile device will have a new IP address. "Flow Label + 567 Sticky Service ID" stays the same when a mobile device is 569 Internet-Draft IPv6 for 5G Edge Sticky Service 571 anchored to a new PSA. Therefore, this solution uses "Flow 572 Label + Sticky Service ID" to identify a sticky flow. Since 573 the chance of different mobile devices sending packets to the 574 same ANYCAST address using the same Flow Label is very low, 575 it is with high probability that "Flow Label + Sticky Service 576 ID" can uniquely identify a flow. When multiple mobile 577 devices using the same Flow Label sending packets to the same 578 ANYCAST address, the solution described in this section will 579 stick the flows to the same ANYCAST server attached to the 580 Sticky Egress router. This behavior doesn't cause any harm. 582 Each entry in the Sticky-Service-Table has a Timer because a 583 sticky service is no longer sticky if there are no packets of 584 the same flow destined towards the service ID for a period of 585 time. The Timer should be larger than a typical TCP session 586 Timeout value. An entry is automatically removed from the 587 Sticky-Service-Table when its timer expires. 588 Note: since there are only small number of Sticky services, the 589 Sticky-Service-Table is not very large. 590 When an ingress router receives a packet from a mobile device 591 matching with one of the Sticky Service ACLs and there is no 592 entry in the Sticky-Service-Table matching the Flow Label and 593 the Sticky Service ID, the ingress router considers the packet 594 to be the first packet of the flow. There is no need to 595 sticking the packet to any location. The ingress router uses 596 its own algorithm to select the optimal egress node as the 597 Sticky Egress address for the ANYCAST address, encapsulates the 598 packet with a tunnel that is supported by the egress node. The 599 tunnel's destination address is set to the egress node address. 601 When an egress router receives a packet from an attached host 602 with the packet's source address matching with one of the 603 Sticky Service IDs, the egress router encapsulates the packet 604 with a tunnel that is supported by the ingress router and the 605 tunnel's destination address is set to the ingress router 606 address. An Egress router learns the ingress router address for 607 a mobile device IP address via BGP UPDATE messages. 609 When an ingress router receives a packet in a tunnel from any 610 egress router and the packet's source address matches with a 611 Sticky Service ID, the egress router address is set as the 612 Sticky Egress address for the Sticky Service ID. The ingress 613 router adds the entry of "Sticky-Service-ID + Flow Label + the 615 Internet-Draft IPv6 for 5G Edge Sticky Service 617 associated Sticky Egress address + Timer" to the Sticky- 618 Service-Table if the entry doesn't exist yet in the table. If 619 the entry exists, the ingress router refreshes the Timer of the 620 entry in the table. 622 When the ingress router receives the subsequent packets of a 623 flow from the 5G side matching with an Sticky Service ID and 624 the Sticky-Service ID exists in the Sticky-Service-Table, the 625 ingress router uses the Sticky Egress address found in the 626 Sticky-Service-Table to encapsulate the packet and refresh the 627 Timer of the entry. If the Sticky-Service ID doesn't exist in 628 the table, the ingress router considers the packet as the first 629 packet of a flow. 631 The subsequent sections describe how ingress nodes prorogate 632 their Sticky-Service-Table to their neighboring ingress nodes. 633 The propagation is for neighboring ingress nodes to be informed 634 of the Sticky Egress address to a sticky service if a mobile 635 device moves to a new neighboring 5G site resulting in 636 anchoring to a new ingress node. 638 5.2. A Solution without the Communication with 5G system. 640 When a mobile device moves to a very far away 5G site, say a 641 different geographic region, the benefit of sticking to the 642 original ANYCAST server is out weighted by network delay. Then, 643 there is no point sending packets to the Sticky Egress node if 644 the ingress router very far away. Therefore, it is necessary 645 for each ingress router to have a group of neighboring ingress 646 routers that are not too far away from the potential Sticky 647 Egress nodes selected by the ingress router. This group of 648 ingress routers is called the Neighboring Ingress Group. Each 649 ingress router can either automatically discover its 650 Neighboring Ingress Group by routing protocols or is configured 651 by its controller. It is out of the scope of this document on 652 how ingress nodes discover its Neighboring Ingress Group. 654 Each ingress node needs to periodically advertise its Sticky- 655 Service-Table to the routers within its Neighboring Ingress 656 Group. 658 Upon receiving the Sticky-Service-Table from routers in its 659 Neighboring Ingress Group, each ingress router merges the 660 entries from the received Sticky-Service-Table to its own. 662 Internet-Draft IPv6 for 5G Edge Sticky Service 664 The ingress and the egress nodes perform the same actions as 665 described in Section 5.1. 667 5.3. A Solution that depends on the communication with 5G system 669 In this scenario, there is communication with 5G System and 670 network get notified by a mobile device is anchored to a new 671 PSA. 673 When a mobile device is re-anchoring from PSA1 to PSA2, 5GC EC 674 management system sends a notification to the router that is 675 directly connected to PSA1. The notification includes the 676 address of the new PSA that the mobile device is to be 677 anchored, i.e. the PSA2, and the mobile device's new IP 678 address. 680 In this scenario, the Sticky Service can be uniquely identified 681 by "Sticky Service ID" + "mobile device address". the Sticky- 682 Service-Table should include the following attributes: 684 - Sticky Service ID 685 - mobile device address 686 - Sticky Egress address 687 - Timer 689 Upon receiving the notification from the 5G EC management 690 system, the ingress router (i.e. the one directly connected to 691 the old PSA) sends the specific entry of the Sticky-Service 692 Table, i.e. "Sticky Service ID" + mobile device address + 693 Sticky Egress + Timer to the router directly connected to the 694 new PSA. 696 Upon receiving the entry, the ingress router merges the entry 697 into its own Sticky-Service-Table. 699 The ingress and egress router processing are the same as 700 described in Section 5.1 except a flow is now uniquely 701 identified by the "Sticky Service ID" + "mobile device address" 702 instead of "Sticky Service ID" + "Flow Label". 704 5.4. Solutions within a Limited Domain 706 Internet-Draft IPv6 for 5G Edge Sticky Service 708 6. Expanding APN6 for Sticky Service information 710 The Application-aware ID and Service-Para Option described 711 [APN6] can be expanded to include the sticky service 712 information. 714 6.1. Sticky Service ID encoded in the Application-aware ID 716 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 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 | Sticky Level |StickyServiceID| Reserved | Flow ID | 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 Sticky Level: represent how important for an application to 722 stick to its ANYCAST servers. Some applications may prefer one 723 flow sticking to the original ANYCAST server, but not required. 724 Some applications may require the stickiness. 726 StickyServiceID: the ANYCAST address of the application 727 servers. 729 The Reserved field can be used for future to identifier the 5G 730 access domain for the flow. 732 Flow ID: the identifier for the flow that needs to stick to a 733 specific ANYCAST server. 735 6.2. Sticky Service Sub-TLV encoded in APN6 Service-para option 737 The Sticky-Dst-SubTLV described in the Section 4.2 of this 738 document can be included in the Service-Para Sub-TLVs field. 740 7. Manageability Considerations 742 To be added. 744 8. Security Considerations 746 To be added. 748 Internet-Draft IPv6 for 5G Edge Sticky Service 750 9. IANA Considerations 752 To be added. 754 10. References 756 10.1. Normative References 758 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 759 Requirement Levels", BCP 14, RFC 2119, March 1997. 761 [RFC4364] E. rosen, Y. Rekhter, "BGP/MPLS IP Virtual Private 762 networks (VPNs)", Feb 2006. 764 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in 765 RFC 2119 Key Words", BCP 14, RFC 8174, DOI 766 10.17487/RFC8174, May 2017, . 769 [RFC8200] s. Deering R. Hinden, "Internet Protocol, Version 6 770 (IPv6) Specification", July 2017 772 10.2. Informative References 774 [3GPP-EdgeComputing] 3GPP TR 23.748, "3rd Generation 775 Partnership Project; Technical Specification Group 776 Services and System Aspects; Study on enhancement of 777 support for Edge Computing in 5G Core network (5GC)", 778 Release 17 work in progress, Aug 2020. 780 [5G-EC-Metrics] L. Dunbar, H. Song, J. Kaippallimalil, "IP 781 Layer Metrics for 5G Edge Computing Service", draft- 782 dunbar-ippm-5g-edge-compute-ip-layer-metrics-00, 783 work-in-progress, Oct 2020. 785 [APN6] Z. Li, et al, "Application-aware IPv6 Networking 786 (APN6) Encapsulation", draft-li-6man-app-aware-ipv6- 787 network-03, work-in-progress, Feb 2021. 789 Internet-Draft IPv6 for 5G Edge Sticky Service 791 [RFC5521] P. Mohapatra, E. Rosen, "The BGP Encapsulation 792 Subsequent Address Family Identifier (SAFI) and the 793 BGP Tunnel Encapsulation Attribute", April 2009. 795 [BGP-SDWAN-Port] L. Dunbar, H. Wang, W. Hao, "BGP Extension for 796 SDWAN Overlay Networks", draft-dunbar-idr-bgp-sdwan- 797 overlay-ext-03, work-in-progress, Nov 2018. 799 [SDWAN-EDGE-Discovery] L. Dunbar, S. Hares, R. Raszuk, K. 800 Majumdar, "BGP UPDATE for SDWAN Edge Discovery", 801 draft-dunbar-idr-sdwan-edge-discovery-00, work-in- 802 progress, July 2020. 804 [Tunnel-Encap] E. Rosen, et al "The BGP Tunnel Encapsulation 805 Attribute", draft-ietf-idr-tunnel-encaps-10, Aug 806 2018. 808 11. Acknowledgments 810 Acknowledgements to Jeffrey Zhang, Joel Halpern, Ron Bonica, 811 Donald Eastlake, and Eduard Vasilenko for their review and 812 contributions. 814 This document was prepared using 2-Word-v2.0.template.dot. 816 Authors' Addresses 818 Linda Dunbar 819 Futurewei 820 Email: ldunbar@futurewei.com 822 John Kaippallimalil 823 Futurewei 824 Email: john.kaippallimalil@futurewei.com