Versions Compared

Version Old Version 22 New Version Current
Changes made by

LJ Illuzzi

Nadathur Sundar

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Development Process: Should we move the current 5GFF API implementation into an open environment, where all folks can contribute? Or possibly reimplement the APIs in an open forum?
  • MEC Cluster Selection Criteria:  Need to add K8s version of target cluster? (See KubeCon talk on x-cloud db migration.)
    • Need to consider application compatibility with target MEC cluster. In the EMCO relocation intent, we can state the range of K8s versions that the app is compatible with.
    • Latitude-Longitude is one way of measuring the cost/latency of a UE – MEC cluster pair. The general problem formulation would involve a bipartite graph of cells and MEC clusters, where nodes may be added/deleted and edge weights may be dynamically updated.
  • Step A: Should Step A be done in EMCO or in a workflow? EMCO could be an AF in the 5GC architecture. RBAC considerations?
    • Can subscribe to any event coming from AMF. 3p like EMCO can subscribe. 
  • Relocation Decision: Since the UE needs to start a new connection and not cache previous DNS lookups, how do we know whether the UE will do that? IOW, in Step B, how do we decide which UE or which PDU session can be subjected to relocation?
    • Consider service continuity at 2 levels: PDU session (nw level) and app level (TCP reconnection). App level may be outside our scope? We can focus on network level alone.
  • DNS: Today we update the app's DNS record in PowerDNS. That has 2 problems:
    • A DNS update for the app implies that all UEs will be diverted to the relocated app. That is not desirable. We want to divert specific UEs to the relocated app while other UEs continue to connect to the existing app.
    • Assuming DNS updates are ok: PowerDNS will not let a new entry take effect while the old entry exists. IOW, the old app instance has to die before the new entry will take effect. How do we handle that?
  • Traffic Steering: How do we ensure new TCP connections in the same PDU session are directed towards the relocated app?
    • For Scenario B, one option is to set up a DNS cache in the TSC for each PDU session.
    • For scenario A, we should investigate whether we can program the I-UPF to update a PDU session such that existing TCP connections stay unaffected while new TCP connections are forwarded to the relocated app. Ideally, this should be implementation-independent. There is some doubt whether Free5GC supports modification of an existing PDU session.
  • Connectivity across clusters. Submariner (already done by Orange) vs Cilium vs others. Does it offer a better solution than TSC?
  • Load Balancer-based approach: where would that fit in a multi-provide rmodel?

MEETING MINUTES

Please see Edge Relocation WG Meeting Minutes.

...

You may be asked to register for the meeting. If so, you , must register to join.


To keep this meeting secure, do not share this link!

...