Need your feedback on using IPv6 extension header to achieve 5G Edge Computing sticky services:

[Linda Dunbar <[e-mail]>]

IPv6 Experts:

https://datatracker.ietf.org/doc/draft-dunbar-6man-5g-edge-compute-sticky-service/ describes an IPv6 solution that enables packets from an application on a UE (User Equipment) sticking to the same application server location when the UE moves from one 5G cell site to another.

In a nutshell, the solution is achieved by the egress router (to which the App server is directly attached) inserting its own router ID in the IPv6 extension Header when the Egress router filters out packets from the App Servers that match the Sticky Service ID ACLs. With the Egress router ID extracted from the IPv6 Extension Header, the ingress routers can enforce the flow always go to the designated Egress router to reach the App server (assuming there are multiple App servers having the same ANYCAST address attached to different egress routers )
The draft suggests using IPv6 Destination Extension Header. Is there any problem of using Destination Extension Header?  Or Is the "Routing Extension header" more appropriate?


A little bit background:
In 5G Edge Computing environment, one Application can have multiple Application Servers hosted in different Edge Computing data centers that are close in proximity. Those Edge Computing (mini) data centers are usually very close to, or co-located with, 5G base stations, with the goal to minimize latency and optimize the user experience.

Increasingly, Anycast is used by various application providers and CDNs because it is possible to dynamically load balance across multiple locations of the same address based on network conditions.  Application Server location selection using Anycast address leverages the proximity information present in the network (routing) layer and eliminates the single point of failure and bottleneck at the DNS resolvers and application layer load balancers. Another benefit of using ANYCAST address is removing the dependency on UEs that use their cached IP addresses instead of querying DNS when they move to a new location.

When a UE moves to a new location but continues the same application flow, routers at the new location might choose the App Server closer to the new location. When the UE1 in 5G-site-A moves to the 5G-Site-B, the router directly connected to 5G PSA2 might forward the packets destined towards the S1: aa08::4450 to the instance located in L-DN2 because L-DN2 has the lowest cost based on routing.

+--+    |  5G     |    +---------+  |   S1: aa08::4450 |
+--+    | Site +--++---+         +----+                |
|UE|----|  A   |PSA| Ra|         | R1 | S2: aa08::4460 |
+--+    |      +---+---+         +----+                |
  +---+    |         |  |           |  |   S3: aa08::4470 |
  |UE1|---/+---------+  |           |  +------------------+
  +---+                 |IP Network |       L-DN1
                     |(3GPP N6)  |
  |                  |           |  +------------------+
  | UE1              |           |  |  S1: aa08::4450  |
  | moves to         |          +----+                 |
  | Site B           |          | R3 | S2: aa08::4460  |
  v                  |          +----+                 |
                     |           |  |  S3: aa08::4470  |
                     |           |  +------------------+
                     |           |      L-DN3
+--+                 |           |
|UE|---\+---------+  |           |  +------------------+
+--+    |  5G     |  |           |  |  S1: aa08::4450  |
+--+    | Site +--++-+--+        +----+                |
|UE|----|  B   |PSA| Rb |        | R2 | S2: aa08::4460 |
+--+    |      +--++----+        +----+                |

This is not the desired behavior for some services, which are called Sticky Services in this document.
Even for some advanced applications with built-in mechanisms to re-sync the communications at the application layer after switching to a new location, service glitches are very often experienced by users.

Your comments and feedback are greatly appreciated.
Thank you.
Linda Dunbar