idnits 2.17.1 draft-dunbar-6man-5g-edge-compute-sticky-service-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 7. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' 8. IANA Considerations' ) 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 (December 18, 2020) is 1226 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: '5GC' is mentioned on line 102, but not defined == Missing Reference: 'A-ER' is mentioned on line 219, but not defined == Unused Reference: 'RFC4364' is defined on line 627, but no explicit reference was found in the text == Unused Reference: '3GPP-EdgeComputing' is defined on line 641, but no explicit reference was found in the text == Unused Reference: 'RFC5521' is defined on line 652, but no explicit reference was found in the text == Unused Reference: 'BGP-SDWAN-Port' is defined on line 656, but no explicit reference was found in the text == Unused Reference: 'SDWAN-EDGE-Discovery' is defined on line 660, but no explicit reference was found in the text == Unused Reference: 'Tunnel-Encap' is defined on line 664, 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: 3 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: June 18, 2021 5 December 18, 2020 7 IPv6 Solution for 5G Edge Computing Sticky Service 8 draft-dunbar-6man-5g-edge-compute-sticky-service-01 10 Abstract 12 This draft describes an IPv6 solution that enables packets from an 13 application on a UE (User Equipment) sticking to the same application 14 server location when the UE moves from one 5G cell site to another. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. This document may not be modified, 23 and derivative works of it may not be created, except to publish it 24 as an RFC and to translate it into languages other than English. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html 42 This Internet-Draft will expire on April 7, 2021. 44 Internet-Draft IPv6 for 5G Edge Sticky Service 46 Copyright Notice 48 Copyright (c) 2020 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction.................................................. 3 64 1.1. 5G Edge Computing Background.......................... 3 65 1.2. Problem #1: ANYCAST in 5G EC Environment.............. 4 66 1.3. Problem #2: sticking to original App Server........... 5 67 1.4. Problem #3: Application Server Relocation............. 5 68 2. Conventions used in this document............................. 6 69 3. Sticky Egress node to an ANYCAST Server....................... 7 70 4. End-Node based Sticky Service Solution........................ 8 71 4.1. Sticky Egress Address Discovery....................... 9 72 4.2. Sticky-Dst-SubTLV in Destination Extension Header.... 10 73 4.3. Expected behavior at the UE.......................... 11 74 4.4. Processing at the Ingress router..................... 11 75 5. Tunnel based Sticky Service Solutions........................ 12 76 5.1. Ingress and Egress Routers Processing Behavior....... 12 77 5.2. Scenario 1: Without Communication with 5G system..... 14 78 5.3. Scenario 2: With communication with 5G system........ 14 79 6. Manageability Considerations................................. 15 80 7. Security Considerations...................................... 15 81 8. IANA Considerations.......................................... 15 82 9. References................................................... 15 83 9.1. Normative References................................. 15 84 9.2. Informative References............................... 16 85 10. Acknowledgments............................................. 16 86 Internet-Draft IPv6 for 5G Edge Sticky Service 88 1. Introduction 90 1.1. 5G Edge Computing Background 92 As described in [5G-EC-Metrics], one Application in 5G Edge Computing 93 environment can have multiple Application Servers hosted in different 94 Edge Computing data centers that are close in proximity. Those Edge 95 Computing (mini) data centers are usually very close to, or co- 96 located with, 5G base stations, with the goal to minimize latency and 97 optimize the user experience. 99 When a UE (User Equipment) initiates application packets using the 100 destination address from a DNS reply or from its own cache, the 101 packets from the UE are carried in a PDU session through 5G Core 102 [5GC] to the 5G UPF-PSA (User Plan Function - PDU Session Anchor). 103 The UPF-PSA decapsulate the 5G GTP outer header and forwards the 104 packets from the UEs to the Ingress router of the Edge Computing (EC) 105 Local Data Network (LDN). The LDN for 5G EC, which is the IP Networks 106 from 5GC perspective, is responsible for forwarding the packets to 107 the intended destinations. 109 When the UE moves out of coverage of its current gNB (next generation 110 Node B) (gNB1), handover procedures are initiated and the 5G SMF 111 (Session Management Function) also selects a new UPF-PSA. The 112 standard handover procedures described in 3GPP TS 23.501 and TS 113 23.502 are followed. When the handover process is complete, the UE 114 has a new IP address and the IP point of attachment is to the new 115 UPF-PSA. 5GC may maintain a path from the old UPF to new the UPF for 116 a short period of time for SSC [Session and Service Continuity] mode 117 3 to make the handover process more seamless. 119 Internet-Draft IPv6 for 5G Edge Sticky Service 121 +--+ 122 |UE|---\+---------+ +------------------+ 123 +--+ | 5G | +---------+ | S1: aa08::4450 | 124 +--+ | Site +--++---+ +----+ | 125 |UE|----| A |PSA| Ra| | R1 | S2: aa08::4460 | 126 +--+ | +---+---+ +----+ | 127 +---+ | | | | | S3: aa08::4470 | 128 |UE1|---/+---------+ | | +------------------+ 129 +---+ |IP Network | L-DN1 130 |(3GPP N6) | 131 | | | +------------------+ 132 | UE1 | | | S1: aa08::4450 | 133 | moves to | +----+ | 134 | Site B | | R3 | S2: aa08::4460 | 135 v | +----+ | 136 | | | S3: aa08::4470 | 137 | | +------------------+ 138 | | L-DN3 139 +--+ | | 140 |UE|---\+---------+ | | +------------------+ 141 +--+ | 5G | | | | S1: aa08::4450 | 142 +--+ | Site +--++-+--+ +----+ | 143 |UE|----| B |PSA| Rb | | R2 | S2: aa08::4460 | 144 +--+ | +--++----+ +----+ | 145 +--+ | | +-----------+ | S3: aa08::4470 | 146 |UE|---/+---------+ +------------------+ 147 +--+ L-DN2 148 Figure 1: App Servers in different edge DCs 150 1.2. Problem #1: ANYCAST in 5G EC Environment 152 Increasingly, ANYCAST is used extensively by various application 153 providers and CDNs because it is possible to dynamically load balance 154 across multiple locations of the same address based on network 155 conditions. BGP is an integral part in the way IP anycast usually 156 functions. Within BGP routing there are multiple routes for the same 157 IP address which are pointing to different locations. 159 Application Server location selection using Anycast address leverages 160 the proximity information present in the network (routing) layer and 161 eliminates the single point of failure and bottleneck at the DNS 162 resolvers and application layer load balancers. Another benefit of 163 using ANYCAST address is removing the dependency on UEs that use 165 Internet-Draft IPv6 for 5G Edge Sticky Service 167 their cached IP addresses instead of querying DNS when they move to a 168 new location. 170 But, having multiple locations for the same ANYCAST address in 5G 171 Edge Computing environment can be problematic because all those edge 172 computing Data Centers can be close in proximity. There might not be 173 any difference in the routing cost to reach the Application Servers 174 in different Edge DCs. Same routing cost to multiple ANYCAST 175 locations can cause packets from one flow to be forwarded to 176 different locations, which can cause service glitches. 178 1.3. Problem #2: sticking to original App Server 180 When a UE moves to a new location but continues the same application 181 flow, routers at the new location might choose the App Server closer 182 to the new location. As shown in the figure below, when the UE1 in 183 5G-site-A moves to the 5G-Site-B, the router directly connected to 5G 184 PSA2 might forward the packets destined towards the S1: aa08::4450 to 185 the server located in L-DN2 because L-DN2 has the lowest cost based 186 on routing. 188 This is not the desired behavior for some services, which are called 189 Sticky Services in this document. 191 Even for some advanced applications with built-in mechanisms to re- 192 sync the communications at the application layer after switching to a 193 new location, service glitches are very often experienced by users. 195 It worth noting that not all services need to be sticky. We assume 196 only a subset of services are, and the Network is informed of the 197 services that need to be sticky, usually by requests from application 198 developers or controllers. 200 This document describes an IPv6 based network layer solution to stick 201 the packets belonging to the same flow of a UE to its original App 202 Server location after the UE is anchored to a new UPF-PSA. 204 1.4. Problem #3: Application Server Relocation 206 When an Application Server is added to, moved, or deleted from a 5G 207 Edge Computing Data Center, the routing protocol has to propagate the 208 changes to 5G PSA or the PSA adjacent routers. After the change, the 209 cost associated with the site [5G-EC-Metrics] might change as well. 211 Note: for the ease of description, the Edge Computing Server, 212 Application Server, or App Server are used interchangeably throughout 213 this document. 215 Internet-Draft IPv6 for 5G Edge Sticky Service 217 2. Conventions used in this document 219 A-ER: Egress Router to an Application Server, [A-ER] is used 220 to describe the last router that the Application Server 221 is attached. For 5G EC environment, the A-ER can be the 222 gateway router to a (mini) Edge Computing Data Center. 224 Application Server: An application server is a physical or virtual 225 server that host the software system for the 226 application. 228 Application Server Location: Represent a cluster of servers at one 229 location serving the same Application. One application 230 may have a Layer 7 Load balancer, whose address(es) are 231 reachable from external IP network, in front of a set of 232 application servers. From IP network perspective, this 233 whole group of servers are considered as the Application 234 server at the location. 236 Edge Application Server: used interchangeably with Application Server 237 throughout this document. 239 EC: Edge Computing 241 Edge Hosting Environment: An environment providing support required 242 for Edge Application Server's execution. 244 NOTE: The above terminologies are the same as those used 245 in 3GPP TR 23.758 247 Edge DC: Edge Data Center, which provides the Edge Computing Hosting 248 Environment. It might be co-located with 5G Base Station 249 and not only host 5G core functions. 251 gNB next generation Node B 253 L-DN: Local Data Network 255 PSA: PDU Session Anchor (UPF) 257 SSC: Session and Service Continuity 259 Internet-Draft IPv6 for 5G Edge Sticky Service 261 UE: User Equipment 263 UPF: User Plane Function 265 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 266 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 267 "OPTIONAL" in this document are to be interpreted as described in BCP 268 14 [RFC2119] [RFC8174] when, and only when, they appear in all 269 capitals, as shown here. 271 3. Sticky Egress node to an ANYCAST Server 273 From Local Data Network perspective, achieving Sticky Service for a 274 flow from a UE to a specific ANYCAST server is same as delivering the 275 packets of the flow to the same egress router, e.g. R1 in Figure 1, 276 to which the ANYCAST Server is attached. The egress router, say R1 in 277 Figure 1, should deliver the packets destined towards the ANYCAST 278 address to its directly attached server even through the same address 279 is also reachable from other routers, unless the directly attached 280 server is no longer reachable due to Server or Link failure. 282 The egress router, e.g. R1, to which the Edge Computing server is 283 directly attached, is called the Sticky Egress node to the Edge 284 Computing Server at the location. The Sticky Egress node has a 285 unicast address. 287 When there are multiple Edge Computing Servers with the same ANYCAST 288 address located in different mini Edge Computing Data Centers, each 289 location is identified by its Sticky Egress nodes unicast 290 address(es). To the LDN's ingress routers, e.g. Ra or Rb in the 291 Figure 1, achieving sticky service is to send the packets belonging 292 to the same flow to the same Sticky Egress node's unicast address. 294 From Local Data Network perspective, the Sticky Egress nodes' unicast 295 addresses are the Next Hops (i.e. R1, R2, and R3) to reach the Edge 296 Computing server ANYCAST address. 298 The Flow Affinity feature, which is supported by most commercial 299 routers today, can ensure packets belonging to one flow be forwarded 300 along the same path to the same egress router which then delivers the 301 packets to the attached Edge Computing Server. 303 Editor's note: for IPv6 traffic, Flow Affinity can be supported by 304 the routers of the Local Data Network (LDN) forwarding the packets 305 with the same Flow Label in the packets' IPv6 Header along the same 307 Internet-Draft IPv6 for 5G Edge Sticky Service 309 path towards the same egress router. For IPv4 traffic, 5 tuples in 310 the IPv4 header can be used to achieve the Flow Affinity 312 The solution described in this document is to ensure a flow from a UE 313 to be forwarded to the same egress router of the App Server after the 314 UE moves to a new 5G Site which result in the UE being assigned a new 315 IP address and attached to a new access router. 317 4. End-Node based Sticky Service Solution 319 The End-Node based Sticky Service solution needs IPv6 end nodes to 320 insert Destination Option header to the IPv6 header. Section 5 321 describes a Sticky Service solution that do not require end nodes 322 performing anything. Here are some assumptions for the End-Node based 323 Sticky Service solution: 325 - There is an EdgeCompute-Controller that can exchange information 326 with the Edge Computing servers. 327 - Network is aware of the Sticky Services by the Sticky Service 328 Identifiers, which can be ANYCAST addresses or regular IP 329 addresses. If an Edge Computing service needs to be sticky in 330 the 5G Edge Computing environment, the service ID is registered 331 with the 5G Edge Computing controller. 333 Here is the overview of the End-Node based Sticky Service solution: 335 - Each ANYCAST Edge Computing server either learns or is informed 336 of the unicast Sticky Egress address (Section 3). The goal of 337 the network is to deliver packets belonging to one flow to the 338 same Sticky Egress address for the ANYCAST address. Section 4.1 339 describes how Edge Computing Servers discover their 340 corresponding Sticky Egress unicast addresses. 341 - When an Edge Computing server sends data packets to a UE (or 342 client), it inserts the Sticky-Dst-SubTLV (described in Section 343 4.2) into the packets' Destination Option Header. 344 - UE (or client) needs to copy the Destination Option Header from 345 the received packet to the next packet's Destination Header if 346 the next packet belongs to the same flow as the previous packet. 347 - If the following conditions are true, the ingress router 348 encapsulates the packet from the UE in a tunnel whose outer 349 destination address is set to the Sticky Egress Address 350 extracted from the packet's Sticky-Dst-SubTLV: 352 Internet-Draft IPv6 for 5G Edge Sticky Service 354 o The destination of the packet from the UE side matches 355 with one of the Sticky Service ACLs configured on the 356 ingress router of the LDN, 357 o the packet header has the Destination Option present with 358 Sticky-Dst-SubTLV. 360 - Else (i.e. one of the conditions above is not true), the ingress 361 node uses its own algorithm, such as the least cost as described 362 in [5G-EC-Metrics], to select the optimal Sticky Egress address 363 for forwarding the packet. 365 4.1. Sticky Egress Address Discovery 367 To an App server with ANYCAST address, the Sticky Egress address is 368 same as its default Gateway address. 370 To prevent malicious UEs (or clients) sending DDOS attacks to routers 371 within 5G EC LDN, e.g. the Sticky Egress address that is encoded in 372 the Destination option header in the packets sent back to the UEs (or 373 clients), a proxy Sticky Egress address can be encoded in the 374 Destination option header. The proxy Sticky Egress address is only 375 recognizable by the 5G EC LDN ingress nodes, i.e. the Ra and Rb in 376 the Figure 1, but not routable in other networks. The LDN ingress 377 routers can translate the proxy Sticky Egress to a routable address 378 for the Sticky Egress node after the source addresses of the packets 379 are authenticated. 381 Internet-Draft IPv6 for 5G Edge Sticky Service 383 4.2. Sticky-Dst-SubTLV in Destination Extension Header 385 A new Sticky-Dst-SubTLV is specified as below, which can be inserted 386 into the IPv6 Destination Options header. The IPv6 Destination Option 387 Header is specified by [RFC8200] as having a Next Header value of 60: 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Next Header | Hdr Ext Len | | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 392 | | 393 | Sticky-Dst-SubTLV | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 Sticky-Dst-SubTLV is specified as: 398 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 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | Sticky-Type | Len | AFI | Reserved | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 |Sticky Egress address (IPv4 or IPv6) for reaching the ANYCAST | 403 ~ ~ 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 Sticky-Type = 1: indicate the Sticky Egress unicast address at 407 encoded in the Sticky-Dst-SubTLV. 409 Internet-Draft IPv6 for 5G Edge Sticky Service 411 4.3. Expected behavior at the UE 413 For edge computing services that need sticky service while UEs move 414 across multiple 5G sites, the UEs (the TCP/IP layer of the UEs' OS to 415 be precise) need to extract the Destination Extension Header field 416 from packets received from the App Server and inserts the extracted 417 Destination Extension Header into the subsequent packets belonging to 418 the same flow. 420 Granted, it might take some time for IPv6 TCP/IP Layer to adopt the 421 practice of copying the IPv6 Destination Extension Header field from 422 the received packets to the subsequent packets belonging to the same 423 flow. However, once the egress routers and ingress routers for 5G 424 local data network support the feature, more and more Edge Computing 425 services would want to utilize this special feature by adding this 426 step. 428 Section 4 describes the network layer processing if UEs do not 429 perform the steps described here. 431 4.4. Processing at the Ingress router 433 - An Ingress router is configured with an ACL for filtering out 434 the applications that need sticky service. 436 Note, not all applications need sticky service. Using ACL can 437 greatly reduce the processing on the routers. 439 - When an Ingress router receives a packet from the 5G side that 440 matches the ACL, the Ingress router extracts the Sticky-Dst- 441 SubTLV from the packet IPv6 header if the field exists in the 442 packet header. 443 - Encapsulate the packet with the tunnel type that supported by 444 the original Sticky Egress node, using the extracted Sticky 445 Egress address in the destination field of the outer header, and 446 forward the packet. 448 Note: if the proxy Sticky Egress address is encoded in the 449 Sticky-Dst-SubTLV, the ingress router needs to translate 450 the proxy Sticky Egress address to a routable address. 452 If none of the above conditions are met, the ingress router uses 453 its own algorithm to select the optimal Sticky Egress node to 454 forward the packet. 456 Internet-Draft IPv6 for 5G Edge Sticky Service 458 5. Tunnel based Sticky Service Solutions 460 Before all UEs can change their processing behavior as described in 461 the Section 4, a Tunnel based Sticky Service solution can be used. 462 This solution doesn't depend on UE behavior, therefore, more 463 processing on the LDN ingress routers is needed. 464 5.1. Ingress and Egress Routers Processing Behavior 466 The solution assumes that both ingress routers and egress routers 467 support at least one type of tunnel and are configured with ACLs to 468 filter out packets whose destination or source addresses match with 469 the Sticky Service Identifier. The solution also assumes there are 470 only limited number of Sticky Services to be supported. 471 An ingress router needs to build a Sticky-Service-Table, with the 472 minimum following attributes. The Sticky-Service-Table is initialized 473 to be empty. 474 - Sticky Service ID 475 - Flow Label 476 - Sticky Egress address 477 - Timer 479 Editor's Note: 480 When a UE moves from one 5G Site to another, the same UE will have 481 a new IP address. "Flow Label + Sticky Service ID" stays the same 482 when a UE is anchored to a new PSA. Therefore, this solution use 483 "Flow Label + Sticky Service ID" to identify a sticky flow. Since 484 the chance of different UEs sending packets to the same ANYCAST 485 address using the same Flow Label is very low, it is with high 486 probability that "Flow Label + Sticky Service ID" can uniquely 487 identify a flow. When multiple UEs using the same Flow Label 488 sending packets to the same ANYCAST address, the solution described 489 in this section will stick the flows to the same ANYCAST server 490 attached to the Sticky Egress router. This behavior doesn't cause 491 any harm. 493 Each entry in the Sticky-Service-Table has a Timer because a sticky 494 service is no longer sticky if there are no packets of the same flow 495 destined towards the service ID for a period of time. The Timer 496 should be larger than a typical TCP session Timeout value. An entry 497 is automatically removed from the Sticky-Service-Table when its timer 498 expires. 500 Internet-Draft IPv6 for 5G Edge Sticky Service 502 Note: since there are only small number of Sticky services, the 503 Sticky-Service-Table is not very large. 504 When an ingress router receives a packet from a UE matching with one 505 of the Sticky Service ACLs and there is no entry in the Sticky- 506 Service-Table matching the Flow Label and the Sticky Service ID, the 507 ingress router considers the packet to be the first packet of the 508 flow. There is no need to sticking the packet to any location. The 509 ingress router uses its own algorithm to select the optimal egress 510 node as the Sticky Egress address for the ANYCAST address, 511 encapsulates the packet with a tunnel that is supported by the egress 512 node. The tunnel's destination address is set to the egress node 513 address. 515 When an egress router receives a packet from an attached host with 516 the packet's source address matching with one of the Sticky Service 517 IDs, the egress router encapsulates the packet with a tunnel that is 518 supported by the ingress router and the tunnel's destination address 519 is set to the ingress router address. An Egress router learns the 520 ingress router address for a UE IP address via BGP UPDATE messages. 522 When an ingress router receives a packet in a tunnel from any egress 523 router and the packet's source address matches with a Sticky Service 524 ID, the egress router address is set as the Sticky Egress address for 525 the Sticky Service ID. The ingress router adds the entry of "Sticky- 526 Service-ID + Flow Label + the associated Sticky Egress address + 527 Timer" to the Sticky-Service-Table if the entry doesn't exist yet in 528 the table. If the entry exists, the ingress router refreshes the 529 Timer of the entry in the table. 531 When the ingress router receives the subsequent packets of a flow 532 from the 5G side matching with an Sticky Service ID and the Sticky- 533 Service ID exists in the Sticky-Service-Table, the ingress router 534 uses the Sticky Egress address found in the Sticky-Service-Table to 535 encapsulate the packet and refresh the Timer of the entry. If the 536 Sticky-Service ID doesn't exist in the table, the ingress router 537 considers the packet as the first packet of a flow. 539 The subsequent sections describe how ingress nodes prorogate their 540 Sticky-Service-Table to their neighboring ingress nodes. The 541 propagation is for neighboring ingress nodes to be informed of the 542 Sticky Egress address to a sticky service if a UE moves to a new 543 neighboring 5G site resulting in anchoring to a new ingress node. 545 Internet-Draft IPv6 for 5G Edge Sticky Service 547 5.2. Scenario 1: Without Communication with 5G system 549 When a UE moves to a very far away 5G site, say a different 550 geographic region, the benefit of sticking to the original ANYCAST 551 server is out weighted by network delay. Then, there is no point 552 sending packets to the Sticky Egress node if the ingress router very 553 far away. Therefore, it is necessary for each ingress router to have 554 a group of neighboring ingress routers that are not too far away from 555 the potential Sticky Egress nodes selected by the ingress router. 556 This group of ingress routers is called the Neighboring Ingress 557 Group. Each ingress router can either automatically discover its 558 Neighboring Ingress Group by routing protocols or is configured by 559 its controller. It is out of the scope of this document on how 560 ingress nodes discover its Neighboring Ingress Group. 562 Each ingress node needs to periodically advertise its Sticky-Service- 563 Table to the routers within its Neighboring Ingress Group. 565 Upon receiving the Sticky-Service-Table from routers in its 566 Neighboring Ingress Group, each ingress router merges the entries 567 from the received Sticky-Service-Table to its own. 569 The ingress and the egress nodes perform the same actions as 570 described in Section 5.1. 572 5.3. Scenario 2: With communication with 5G system 574 In this scenario, there is communication with 5G System and network 575 get notified by a UE is anchored to a new PSA. 577 When a UE is re-anchoring from PSA1 to PSA2, 5GC EC management system 578 sends a notification to the router that is directly connected to 579 PSA1. The notification includes the address of the new PSA that the 580 UE is to be anchored, i.e. the PSA2, and the UE's new IP address. 582 In this scenario, the Sticky Service can be uniquely identified by 583 "Sticky Service ID" + "UE address". the Sticky-Service-Table should 584 include the following attributes: 586 - Sticky Service ID 587 - UE address 588 - Sticky Egress address 589 - Timer 591 Upon receiving the notification from the 5G EC management system, the 592 ingress router (i.e. the one directly connected to the old PSA) sends 593 the specific entry of the Sticky-Service Table, i.e. "Sticky Service 595 Internet-Draft IPv6 for 5G Edge Sticky Service 597 ID" + UE address + Sticky Egress + Timer to the router directly 598 connected to the new PSA. 600 Upon receiving the entry, the ingress router merges the entry into 601 its own Sticky-Service-Table. 603 The ingress and egress router processing are the same as described in 604 Section 5.1 except a flow is now uniquely identified by the "Sticky 605 Service ID" + "UE address" instead of "Sticky Service ID" + "Flow 606 Label". 608 6. Manageability Considerations 610 To be added. 612 7. Security Considerations 614 To be added. 616 8. IANA Considerations 618 To be added. 620 9. References 622 9.1. Normative References 624 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 625 Requirement Levels", BCP 14, RFC 2119, March 1997. 627 [RFC4364] E. rosen, Y. Rekhter, "BGP/MPLS IP Virtual Private networks 628 (VPNs)", Feb 2006. 630 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 631 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 632 2017, . 634 [RFC8200] s. Deering R. Hinden, "Internet Protocol, Version 6 (IPv6) 635 Specification", July 2017 637 Internet-Draft IPv6 for 5G Edge Sticky Service 639 9.2. Informative References 641 [3GPP-EdgeComputing] 3GPP TR 23.748, "3rd Generation Partnership 642 Project; Technical Specification Group Services and System 643 Aspects; Study on enhancement of support for Edge 644 Computing in 5G Core network (5GC)", Release 17 work in 645 progress, Aug 2020. 647 [5G-EC-Metrics] L. Dunbar, H. Song, J. Kaippallimalil, "IP Layer 648 Metrics for 5G Edge Computing Service", draft-dunbar-ippm- 649 5g-edge-compute-ip-layer-metrics-00, work-in-progress, Oct 650 2020. 652 [RFC5521] P. Mohapatra, E. Rosen, "The BGP Encapsulation Subsequent 653 Address Family Identifier (SAFI) and the BGP Tunnel 654 Encapsulation Attribute", April 2009. 656 [BGP-SDWAN-Port] L. Dunbar, H. Wang, W. Hao, "BGP Extension for SDWAN 657 Overlay Networks", draft-dunbar-idr-bgp-sdwan-overlay-ext- 658 03, work-in-progress, Nov 2018. 660 [SDWAN-EDGE-Discovery] L. Dunbar, S. Hares, R. Raszuk, K. Majumdar, 661 "BGP UPDATE for SDWAN Edge Discovery", draft-dunbar-idr- 662 sdwan-edge-discovery-00, work-in-progress, July 2020. 664 [Tunnel-Encap] E. Rosen, et al "The BGP Tunnel Encapsulation 665 Attribute", draft-ietf-idr-tunnel-encaps-10, Aug 2018. 667 10. Acknowledgments 669 Acknowledgements to Ron Bonica and Donald Eastlake for their review 670 and contributions. 672 This document was prepared using 2-Word-v2.0.template.dot. 674 Internet-Draft IPv6 for 5G Edge Sticky Service 676 Authors' Addresses 678 Linda Dunbar 679 Futurewei 680 Email: ldunbar@futurewei.com 682 John Kaippallimalil 683 Futurewei 684 Email: john.kaippallimalil@futurewei.com