idnits 2.17.1 draft-dunbar-6man-5g-edge-compute-sticky-service-04.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 (April 1, 2021) is 1121 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 286, but not defined == Missing Reference: 'RFC8799' is mentioned on line 392, but not defined == Unused Reference: 'RFC4364' is defined on line 780, but no explicit reference was found in the text == Unused Reference: '3GPP-EdgeComputing' is defined on line 793, but no explicit reference was found in the text == Unused Reference: 'RFC5521' is defined on line 820, but no explicit reference was found in the text == Unused Reference: 'BGP-SDWAN-Port' is defined on line 824, but no explicit reference was found in the text == Unused Reference: 'SDWAN-EDGE-Discovery' is defined on line 828, but no explicit reference was found in the text == Unused Reference: 'Tunnel-Encap' is defined on line 833, 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 -- Unexpected draft version: The latest known version of draft-dunbar-lsr-5g-edge-compute-ospf-ext is -04, but you're referring to -05. == Outdated reference: A later version (-14) exists of draft-dunbar-idr-5g-edge-compute-app-meta-data-02 == 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 (~~), 14 warnings (==), 2 comments (--). 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: October 1, 2021 5 April 1, 2021 7 IPv6 Solution for 5G Edge Computing Sticky Service 8 draft-dunbar-6man-5g-edge-compute-sticky-service-04 10 Abstract 12 This draft describes the IPv6-based solutions 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: Discovery of Edge Application Server...... 5 75 1.4. Problem #2: sticking to original App Server........... 6 76 2. Conventions used in this document............................. 7 77 3. Stick a Flow to an ANYCAST Server............................. 9 78 4. Solutions within a Limited Domain............................. 9 79 4.1. Use Case of 5G Edge Computing in a limited domain.... 10 80 4.2. End Node Based Sticky Service Solution............... 10 81 4.2.1. Edge Controller Based Solution.................. 11 82 4.3. Sticky Egress Address Discovery...................... 12 83 4.4. Sticky-Dst-SubTLV in Destination Extension Header.... 12 84 4.5. Processing at the Ingress router..................... 13 85 5. Tunnel based Sticky Service Solution......................... 13 86 5.1. Desired functions by the Network Controller.......... 13 87 5.2. Ingress and Egress Routers Processing Behavior....... 13 88 5.3. A Solution without the Communication with 5G system.. 15 90 Internet-Draft IPv6 for 5G Edge Sticky Service 92 5.4. A Solution that depends on the communication with 5G 93 system.................................................... 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................................. 18 99 8. Security Considerations...................................... 18 100 9. IANA Considerations.......................................... 18 101 10. References.................................................. 18 102 10.1. Normative References................................ 18 103 10.2. Informative References.............................. 18 104 11. Acknowledgments............................................. 20 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. 133 5G Session Management function (SMF) may maintain a path from 134 the old UPF to the new UPF for a short period of time for SSC 136 Internet-Draft IPv6 for 5G Edge Sticky Service 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 multiple Edge Computing Servers attached to one App Layer 159 Load Balancer, only the App Layer Load Balancer address is 160 visible to the 5G Edge Computing Network. How the App Layer 161 Load balancer manages the individual servers is out of the 162 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: Discovery of Edge Application Server 203 Key Issue #1 identified by 3GPP Edge Computing Study [TR 204 23.748] is that one application service might be served by 205 multiple Edge Application Servers typically deployed in 206 different sites. These multiple Edge Application Server 207 instances that host same content or service may use a single IP 208 address (anycast address) or different IP addresses. 210 Key Issue #2 identified by 3GPP Edge Computing Study [TR 211 23.748] is Edge server relocation. 213 Internet-Draft IPv6 for 5G Edge Sticky Service 215 Application Server discovery and relocation can be achieved by 216 running IGP/BGP routing protocols among the routers in LDN. 218 Increasingly, ANYCAST is used extensively by various 219 application providers because it is possible to dynamically 220 load balance across multiple locations of the same address 221 based on network conditions. When multiple servers in different 222 locations have the same IP address (ANYCAST), the routers see 223 multiple paths to the IP address. The IGP/BGP routing protocols 224 can inform all the nodes where the servers are and when servers 225 move to new locations. 227 Application Server location selection using Anycast address 228 leverages the proximity information present in the network 229 routing layer and eliminates the single point of failure and 230 bottleneck at the DNS resolvers and application layer load 231 balancers. Another benefit of using ANYCAST address is removing 232 the dependency on mobile devices that use their cached IP 233 addresses instead of querying DNS when they move to a new 234 location. 236 However, having multiple locations for the same ANYCAST address 237 in the 5G Edge Computing environment can be problematic because 238 all those edge computing Data Centers can be close in 239 proximity. There might not be any difference in the routing 240 cost to reach the Application Servers in different Edge DCs. 241 The same routing cost to multiple locations can cause packets 242 from one flow to be forwarded to different locations, which can 243 cause service glitches. 245 1.4. Problem #2: sticking to original App Server 247 When a mobile device moves to a new location but continues the 248 same application flow, the router connected to the new UPF 249 might choose the App Server closer to the new location. As 250 shown in the figure below, when the MD1 in 5G-site-A moves to 251 the 5G-Site-B, the router directly connected to 5G PSA2 might 252 forward the packets destined towards the S1: aa08::4450 to the 253 server located in L-DN2 because L-DN2 has the lowest cost based 254 on routing. This is not the desired behavior for some services, 255 which are called Sticky Services in this document. 257 Even for some advanced applications with built-in mechanisms to 258 re-sync the communications at the application layer after 259 switching to a new location, service glitches are often 260 experienced. 262 Internet-Draft IPv6 for 5G Edge Sticky Service 264 It worth noting that not all services need to be sticky. We 265 assume only a subset of services are, and the Network is 266 informed of the services that need to be sticky, usually by 267 requests from application developers or controllers. 269 This document describes an IPv6-based network layer solution to 270 stick the packets belonging to the same flow of a mobile device 271 to its original App Server location after the mobile device is 272 anchored to a new nearby UPF-PSA. 274 Note: for ease of description, the Edge Computing Server, 275 Application Server, or App Server are used interchangeably 276 throughout this document. 278 2. Conventions used in this document 280 APN6 Application aware network using IPv6. The term 281 "Application" has very broad meanings. In this 282 document the term "Application" refers to any 283 applications that use ANYCAST servers in the 5G 284 Edge Computing Environment. 286 A-ER: Egress Router to an Application Server, [A-ER] is 287 used to describe the last router that the 288 Application Server is attached. For 5G EC 289 environment, the A-ER can be the gateway router to 290 a (mini) Edge Computing Data Center. 292 Application Server: An application server is a physical or 293 virtual server that host the software system for 294 the application. 296 Application Server Location: Represent a cluster of servers at 297 one location serving the same Application. One 298 application may have a Layer 7 Load balancer, whose 299 address(es) are reachable from external IP network, 300 in front of a set of application servers. From IP 301 network perspective, this whole group of servers 302 are considered as the Application server at the 303 location. 305 Internet-Draft IPv6 for 5G Edge Sticky Service 307 Edge Application Server: used interchangeably with Application 308 Server throughout this document. 310 EC: Edge Computing 312 Edge Hosting Environment: An environment providing support 313 required for Edge Application Server's execution. 315 NOTE: The above terminologies are the same as those 316 used in 3GPP TR 23.758 318 Edge DC: Edge Data Center, which provides the Edge Computing 319 Hosting Environment. It might be co-located with or 320 very close to a 5G Base Station. 322 gNB next generation Node B 324 L-DN: Local Data Network 326 MD: Mobile Device, which is the same as the UE (User 327 Equipment) used in 3GPP. The term "mobile device" 328 is used instead of UE to emphasize on sticking 329 services originated from the devices that are 330 mobile to same server. 332 PSA: PDU Session Anchor (UPF) 334 SSC: Session and Service Continuity 336 UE: User Equipment. UE is same as a mobile device in 337 this document. 339 UPF: User Plane Function 341 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 342 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", 343 "MAY", and "OPTIONAL" in this document are to be interpreted as 344 described in BCP 14 [RFC2119] [RFC8174] when, and only when, 345 they appear in all capitals, as shown here. 347 Internet-Draft IPv6 for 5G Edge Sticky Service 349 3. Stick a Flow to an ANYCAST Server 351 With multiple servers attached to different Egress Routers 352 having the same IP address, the routers in the LDN see multiple 353 paths to the IP address. The routers choose the lowest cost 354 path to forwarding packets destined toward the IP address. [5G- 355 EC-OSPF-EXT] and [5G-EC-BGP-EXT] describe the OSPF and BGP 356 extension to propagate additional attributes about the site 357 where the server is attached on top of the existing network 358 path costs to all the routers. 360 Sticking one flow to the same server is achieved by applying a 361 higher weight for its site preference. With the site preference 362 having a higher weight towards the total cost to reach the 363 server, routers in the LDN will continue choosing the path 364 towards the original server when the network cost becomes 365 slightly higher. 367 When the network cost is significantly different, such as the 368 mobile device moves to a very far away location or the extreme 369 case of link failure to the original server, another server 370 with the same IP address is selected. Flow sticking to one 371 server is not the same as flow nailing down to the same server. 373 The Egress nodes' unicast addresses are the Next Hops (i.e., 374 R1, R2, and R3) to reach the Edge Computing server ANYCAST 375 address. 377 The Flow Affinity feature, which most commercial routers 378 support today, can ensure packets belonging to one flow be 379 forwarded along the same path to the same egress router which 380 then delivers the packets to the attached Edge Computing 381 Server. 383 Editor's note: for IPv6 traffic, Flow Affinity can be supported 384 by the Local Data Network (LDN) routers forwarding the packets 385 with the same Flow Label in the packets' IPv6 Header along the 386 same path towards the same egress router. For IPv4 traffic, 5 387 tuples in the IPv4 header can be used to achieve the Flow 388 Affinity. 390 4. Solutions within a Limited Domain 392 Within a limited domain [RFC8799], mobile devices, edge 393 servers, and network functions are under one administrative 394 domain. Therefore, it is feasible for mobile devices to perform 395 specific actions. 397 Internet-Draft IPv6 for 5G Edge Sticky Service 399 4.1. Use Case of 5G Edge Computing in a limited domain. 401 Some 5G Connected devices, such as drones for fighting natural 402 disasters or robots in Industry 4.0 environments, need ultra- 403 low latency responses from their analytic servers. To reach 404 ultra-low latency, those analytic functions can be hosted on 405 servers very close to radio towers. 407 All the functions (including networking and analytics) and 408 devices are administrated by one operator. Those functions 409 might be provided by different vendors, therefore needing 410 interoperable solutions. 412 4.2. End Node Based Sticky Service Solution 414 The End-Node-based Sticky Service solution needs IPv6 mobile 415 devices to insert the Destination Option header extracted from 416 the packet received from the network side to the IPv6 Header of 417 the next packet if the next packet belongs to the same flow. 418 This action dramatically simplifies the processing at the LDN's 419 Ingress routers. 421 Here are some assumptions for the End-Node based Sticky Service 422 solution: 424 - The mobile devices are under the same administrative 425 control as the Edge computing servers. 426 - If an Edge Computing service needs to be sticky in the 5G 427 Edge Computing environment, the corresponding service ID 428 is registered with the 5G Edge Computing controller. The 429 Sticky Service ID can be the IP address (unicast or 430 ANYCAST) of the server. 432 Here is the overview of the End-Node based Sticky Service 433 solution: 434 - Each ANYCAST Edge Computing server either learns or is 435 informed of the unicast Sticky Egress address (Section 3). 436 The goal is to deliver packets belonging to one flow to 437 the same Sticky Egress address for the ANYCAST address. 438 - When an Edge Computing server sends data packets back to a 439 client (or the mobile device), it inserts the Sticky-Dst- 440 SubTLV (described in Section 4.4) into the packets' 441 Destination Option Header. 443 Internet-Draft IPv6 for 5G Edge Sticky Service 445 - The client (or the mobile device) needs to copy the 446 Destination Option Header from the received packet to the 447 next packet's Destination Header if the next packet 448 belongs to the same flow as the previous packet. 449 - If the following conditions are true, the ingress router 450 encapsulates the packet from the client in a tunnel whose 451 outer destination address is set to the Sticky Egress 452 Address extracted from the packet's Sticky-Dst-SubTLV: 453 o The destination of the packet from the client-side 454 matches with one of the Sticky Service ACLs 455 configured on the ingress router of the LDN, 456 o the packet header has the Destination Option present 457 with Sticky-Dst-SubTLV. 458 - Else (i.e., one of the conditions above is not true), the 459 ingress node uses its algorithm, such as the least cost as 460 described in [5G-EC-Metrics], to select the optimal Sticky 461 Egress address for forwarding the packet. 463 4.2.1. Edge Controller Based Solution. 465 To be added. 466 [Editor's note: can consider adding something along the 467 line of the following, which is suggested by the email: 468 say 5G/MEC control plane can tell the UE what address to 469 use, it does NOT mean a UE will query whenever it is 470 anchored to a new UPF. The initial query when it needs a 471 service will return the unicast address of a server based 472 on all kinds of information/constraints, including the 473 server load information talked about in draft-dunbar-idr- 474 5g-edge-compute-app-meta-data. After that, the server 475 won't change until new server is indeed needed (this is 476 what "sticky service" is about, right). When a server 477 change is indeed needed, the 5G/MEC control plane will 478 tell the UE the new unicast address to use and tell the 479 servers to move the corresponding application data when 480 necessary. 481 ] 483 Internet-Draft IPv6 for 5G Edge Sticky Service 485 4.3. Sticky Egress Address Discovery 487 To an App server with ANYCAST address, the Sticky Egress 488 address is the same as its default Gateway address. 490 To prevent malicious entities sending DDOS attacks to routers 491 within 5G EC LDN, e.g., the Sticky Egress address that is 492 encoded in the Destination option header in the packets sent 493 back to the clients, a proxy Sticky Egress address can be 494 encoded in the Destination option header. The proxy Sticky 495 Egress address is only recognizable by the 5G EC LDN ingress 496 nodes, i.e., the Ra and Rb in Figure 1, but not routable in 497 other networks. The LDN ingress routers can translate the proxy 498 Sticky Egress to a routable address for the Sticky Egress node 499 after the source addresses of the packets are authenticated. 501 4.4. Sticky-Dst-SubTLV in Destination Extension Header 503 A new Sticky-Dst-SubTLV is specified as below, which can be 504 inserted into the IPv6 Destination Options header. The IPv6 505 Destination Option Header is specified by [RFC8200] as having a 506 Next Header value of 60: 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 | Next Header | Hdr Ext Len | | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 511 | | 512 | Sticky-Dst-SubTLV | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 Sticky-Dst-SubTLV is specified as: 517 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 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | Sticky-Type | Len | AFI | Reserved | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 |Sticky Egress address (IPv4 or IPv6) for reaching the ANYCAST | 522 ~ ~ 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 Sticky-Type = 1: indicate the Sticky Egress unicast address 526 at encoded in the Sticky-Dst-SubTLV. 528 Internet-Draft IPv6 for 5G Edge Sticky Service 530 4.5. Processing at the Ingress router 532 - An Ingress router is configured with an ACL for filtering 533 out the applications that need sticky service. 535 Note, not all applications need sticky service. Using ACL 536 can significantly reduce the processing on the routers. 538 - When an Ingress router receives a packet from the 5G side 539 that matches the ACL, the Ingress router extracts the 540 Sticky-Dst-SubTLV from the packet IPv6 header if the field 541 exists in the packet header. 542 - Encapsulate the packet with the tunnel type that are 543 supported by the original Sticky Egress node, using the 544 extracted Sticky Egress address in the destination field 545 of the outer Header, and forward the packet. 547 Note: if the proxy Sticky Egress address is encoded in the 548 Sticky-Dst-SubTLV, the ingress router needs to translate 549 the proxy Sticky Egress address to a routable address. 551 If none of the above conditions are met, the ingress router 552 uses its algorithm to select the optimal Sticky Egress node 553 to forward the packet. 555 5. Tunnel based Sticky Service Solution 557 For environments that mobile devices cannot change their 558 processing behavior as described in Section 4, a Tunnel based 559 Sticky Service solution can be used. This solution does not 560 depend on mobile device's behavior. However, this solution does 561 require ingress routers to filter out the registered sticky 562 services and might need some level of assistance from the LDN 563 network controller. 565 5.1. Desired functions by the Network Controller 567 5.2. Ingress and Egress Routers Processing Behavior 569 The solution assumes that both ingress routers and egress 570 routers support at least one type of tunnel and are configured 571 with ACLs to filter out packets whose destination or source 573 Internet-Draft IPv6 for 5G Edge Sticky Service 575 addresses match with the Sticky Service Identifier. The 576 solution also assumes there are only limited number of Sticky 577 Services to be supported. 578 An ingress router needs to build a Sticky-Service-Table, with 579 the following minimum attributes. The Sticky-Service-Table is 580 initialized to be empty. 581 - Sticky Service ID 582 - Flow Label 583 - Sticky Egress address 584 - Timer 586 Editor's Note: 587 When a mobile device moves from one 5G Site to another, the 588 same mobile device will have a new IP address. "Flow Label + 589 Sticky Service ID" stays the same when a mobile device is 590 anchored to a new PSA. Therefore, this solution uses "Flow 591 Label + Sticky Service ID" to identify a sticky flow. Since 592 the chance of different mobile devices sending packets to the 593 same ANYCAST address using the same Flow Label is very low, 594 it is with high probability that "Flow Label + Sticky Service 595 ID" can uniquely identify a flow. When multiple mobile 596 devices using the same Flow Label sending packets to the same 597 ANYCAST address, the solution described in this section will 598 stick the flows to the same ANYCAST server attached to the 599 Sticky Egress router. This behavior doesn't cause any harm. 601 Each entry in the Sticky-Service-Table has a Timer because a 602 sticky service is no longer sticky if there are no packets of 603 the same flow destined towards the service ID for a period of 604 time. The Timer should be larger than a typical TCP session 605 Timeout value. An entry is automatically removed from the 606 Sticky-Service-Table when its timer expires. 607 Note: since there are only small number of Sticky services, the 608 Sticky-Service-Table is not very large. 609 When an ingress router receives a packet from a mobile device 610 matching with one of the Sticky Service ACLs and there is no 611 entry in the Sticky-Service-Table matching the Flow Label and 612 the Sticky Service ID, the ingress router considers the packet 613 to be the first packet of the flow. There is no need to 615 Internet-Draft IPv6 for 5G Edge Sticky Service 617 sticking the packet to any location. The ingress router uses 618 its own algorithm to select the optimal egress node as the 619 Sticky Egress address for the ANYCAST address, encapsulates the 620 packet with a tunnel that is supported by the egress node. The 621 tunnel's destination address is set to the egress node address. 623 When an egress router receives a packet from an attached host 624 with the packet's source address matching with one of the 625 Sticky Service IDs, the egress router encapsulates the packet 626 with a tunnel that is supported by the ingress router and the 627 tunnel's destination address is set to the ingress router 628 address. An Egress router learns the ingress router address for 629 a mobile device IP address via BGP UPDATE messages. 631 When an ingress router receives a packet in a tunnel from any 632 egress router and the packet's source address matches with a 633 Sticky Service ID, the egress router address is set as the 634 Sticky Egress address for the Sticky Service ID. The ingress 635 router adds the entry of "Sticky-Service-ID + Flow Label + the 636 associated Sticky Egress address + Timer" to the Sticky- 637 Service-Table if the entry doesn't exist yet in the table. If 638 the entry exists, the ingress router refreshes the Timer of the 639 entry in the table. 641 When the ingress router receives the subsequent packets of a 642 flow from the 5G side matching with an Sticky Service ID and 643 the Sticky-Service ID exists in the Sticky-Service-Table, the 644 ingress router uses the Sticky Egress address found in the 645 Sticky-Service-Table to encapsulate the packet and refresh the 646 Timer of the entry. If the Sticky-Service ID doesn't exist in 647 the table, the ingress router considers the packet as the first 648 packet of a flow. 650 The subsequent sections describe how ingress nodes prorogate 651 their Sticky-Service-Table to their neighboring ingress nodes. 652 The propagation is for neighboring ingress nodes to be informed 653 of the Sticky Egress address to a sticky service if a mobile 654 device moves to a new neighboring 5G site resulting in 655 anchoring to a new ingress node. 657 5.3. A Solution without the Communication with 5G system. 659 When a mobile device moves to a very far away 5G site, say a 660 different geographic region, the benefit of sticking to the 661 original ANYCAST server is out weighted by network delay. Then, 662 there is no point sending packets to the Sticky Egress node if 664 Internet-Draft IPv6 for 5G Edge Sticky Service 666 the ingress router very far away. Therefore, it is necessary 667 for each ingress router to have a group of neighboring ingress 668 routers that are not too far away from the potential Sticky 669 Egress nodes selected by the ingress router. This group of 670 ingress routers is called the Neighboring Ingress Group. Each 671 ingress router can either automatically discover its 672 Neighboring Ingress Group by routing protocols or is configured 673 by its controller. It is out of the scope of this document on 674 how ingress nodes discover its Neighboring Ingress Group. 676 Each ingress node needs to periodically advertise its Sticky- 677 Service-Table to the routers within its Neighboring Ingress 678 Group. 680 Upon receiving the Sticky-Service-Table from routers in its 681 Neighboring Ingress Group, each ingress router merges the 682 entries from the received Sticky-Service-Table to its own. 684 The ingress and the egress nodes perform the same actions as 685 described in Section 5.1. 687 5.4. A Solution that depends on the communication with 5G system 689 In this scenario, there is communication with 5G System and 690 network get notified by a mobile device is anchored to a new 691 PSA. 693 When a mobile device is re-anchoring from PSA1 to PSA2, 5GC EC 694 management system sends a notification to the router that is 695 directly connected to PSA1. The notification includes the 696 address of the new PSA that the mobile device is to be 697 anchored, i.e. the PSA2, and the mobile device's new IP 698 address. 700 In this scenario, the Sticky Service can be uniquely identified 701 by "Sticky Service ID" + "mobile device address". the Sticky- 702 Service-Table should include the following attributes: 704 - Sticky Service ID 705 - mobile device address 706 - Sticky Egress address 707 - Timer 709 Upon receiving the notification from the 5G EC management 710 system, the ingress router (i.e. the one directly connected to 711 the old PSA) sends the specific entry of the Sticky-Service 712 Table, i.e. "Sticky Service ID" + mobile device address + 714 Internet-Draft IPv6 for 5G Edge Sticky Service 716 Sticky Egress + Timer to the router directly connected to the 717 new PSA. 719 Upon receiving the entry, the ingress router merges the entry 720 into its own Sticky-Service-Table. 722 The ingress and egress router processing are the same as 723 described in Section 5.1 except a flow is now uniquely 724 identified by the "Sticky Service ID" + "mobile device address" 725 instead of "Sticky Service ID" + "Flow Label". 727 6. Expanding APN6 for Sticky Service information 729 The Application-aware ID and Service-Para Option described 730 [APN6] can be expanded to include the sticky service 731 information. 733 6.1. Sticky Service ID encoded in the Application-aware ID 735 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 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 | Sticky Level |StickyServiceID| Reserved | Flow ID | 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 Sticky Level: represent how important for an application to 741 stick to its ANYCAST servers. Some applications may prefer one 742 flow sticking to the original ANYCAST server, but not required. 743 Some applications may require the stickiness. 745 StickyServiceID: the ANYCAST address of the application 746 servers. 748 The Reserved field can be used for future to identifier the 5G 749 access domain for the flow. 751 Flow ID: the identifier for the flow that needs to stick to a 752 specific ANYCAST server. 754 6.2. Sticky Service Sub-TLV encoded in APN6 Service-para option 756 The Sticky-Dst-SubTLV described in the Section 4.2 of this 757 document can be included in the Service-Para Sub-TLVs field. 759 Internet-Draft IPv6 for 5G Edge Sticky Service 761 7. Manageability Considerations 763 To be added. 765 8. Security Considerations 767 To be added. 769 9. IANA Considerations 771 To be added. 773 10. References 775 10.1. Normative References 777 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 778 Requirement Levels", BCP 14, RFC 2119, March 1997. 780 [RFC4364] E. rosen, Y. Rekhter, "BGP/MPLS IP Virtual Private 781 networks (VPNs)", Feb 2006. 783 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in 784 RFC 2119 Key Words", BCP 14, RFC 8174, DOI 785 10.17487/RFC8174, May 2017, . 788 [RFC8200] s. Deering R. Hinden, "Internet Protocol, Version 6 789 (IPv6) Specification", July 2017 791 10.2. Informative References 793 [3GPP-EdgeComputing] 3GPP TR 23.748, "3rd Generation 794 Partnership Project; Technical Specification Group 795 Services and System Aspects; Study on enhancement of 796 support for Edge Computing in 5G Core network (5GC)", 797 Release 17 work in progress, Aug 2020. 799 Internet-Draft IPv6 for 5G Edge Sticky Service 801 [5G-EC-Metrics] L. Dunbar, H. Song, J. Kaippallimalil, "IP 802 Layer Metrics for 5G Edge Computing Service", draft- 803 dunbar-ippm-5g-edge-compute-ip-layer-metrics-00, 804 work-in-progress, Oct 2020. 806 [5G-EC-OSPF-EXT] L. Dunbar, H.Chen, A. Wang, "OSPF extension 807 for 5G Edge Computing Service", draft-dunbar-lsr-5g- 808 edge-compute-ospf-ext-05, work-in-progress, March 809 2021. 811 [5G-EC-BGP-EXT] L. Dunbar, K. Majumdar, H. Wang, "BGP NLRI App 812 Meta Data for 5G Edge Computing Service", draft- 813 dunbar-idr-5g-edge-compute-app-meta-data-02, work-in- 814 progress, March 2021. 816 [APN6] Z. Li, et al, "Application-aware IPv6 Networking 817 (APN6) Encapsulation", draft-li-6man-app-aware-ipv6- 818 network-03, work-in-progress, Feb 2021. 820 [RFC5521] P. Mohapatra, E. Rosen, "The BGP Encapsulation 821 Subsequent Address Family Identifier (SAFI) and the 822 BGP Tunnel Encapsulation Attribute", April 2009. 824 [BGP-SDWAN-Port] L. Dunbar, H. Wang, W. Hao, "BGP Extension for 825 SDWAN Overlay Networks", draft-dunbar-idr-bgp-sdwan- 826 overlay-ext-03, work-in-progress, Nov 2018. 828 [SDWAN-EDGE-Discovery] L. Dunbar, S. Hares, R. Raszuk, K. 829 Majumdar, "BGP UPDATE for SDWAN Edge Discovery", 830 draft-dunbar-idr-sdwan-edge-discovery-00, work-in- 831 progress, July 2020. 833 [Tunnel-Encap] E. Rosen, et al "The BGP Tunnel Encapsulation 834 Attribute", draft-ietf-idr-tunnel-encaps-10, Aug 835 2018. 837 Internet-Draft IPv6 for 5G Edge Sticky Service 839 11. Acknowledgments 841 Acknowledgements to Gyan Mishra, Jeffrey Zhang, Joel Halpern, 842 Ron Bonica, Donald Eastlake, and Eduard Vasilenko for their 843 review and contributions. 845 This document was prepared using 2-Word-v2.0.template.dot. 847 Authors' Addresses 849 Linda Dunbar 850 Futurewei 851 Email: ldunbar@futurewei.com 853 John Kaippallimalil 854 Futurewei 855 Email: john.kaippallimalil@futurewei.com