NLRI AppMetaData Path Attributefor

5G Edge Computing Service

draft-dunbar-idr-5g-edge-compute-app-meta-data-01

1

Linda Dunbar: ldunbar@Futurewei.comKausik Majumdar: kausik.majumdar@commscope.com

Haibo Wang: Rainsword.wang@Huawei.comNov 2020

Intention of the draft• Purpose:

– a new BGP Network Layer Reachability Information (BGP NLRI) Path Attribute: AppMetaData,

• To distribute the 5G Edge Computing App running status and environment,

• For other routers in the 5G Local Data Network to make intelligent decision on optimized forwarding of flows from UEs.

• The goal is to improve latency and performance for 5G Edge Computing services.

– We would like to hear your feedback.

2

5G Edge Computing (3GPP TR23.748)

Page 3

PSA1UE1

(IP-1)

PSA2

L-DN2

L-DN3

5G-site A

5G-site B

UE2(IP-2)

IP NETWORK(3GPP N6)

UE2(IP-2)UE2

(IP-2) UE2(IP-2)UE2

(IP-2)

UE1(IP-1)UE1

(IP-1)UE1(IP-1)UE1

(IP-1)

L-DN1S1: aa08::4450

S2: aa08::4460

S3: aa08::4470

S1: aa08::4450

S2: aa08::4460

S3: aa08::4470

R1Ra

S1: aa08::4450

S2: aa08::4460

S3: aa08::4470

Rb

R3

R2

SMFAMF NEF

NWDAF NRF OAM

5G System

One Application has multiple Application Servers located in Edge Computing DCsAF

DNSauthoritative

N3 / N5

Local Data Network (LDN) for 5G Edge Computing

Use Cases Unmanned Aerial Vehicles

(Drones) <-> Controller, Traffic Management, and App Servers

13 detailed use cases described in 3GPP TR22.829

Virtual concert

Virtual Interactive Conference

o Computing (e.g. the encoding, video stitching, compressing, etc.) can be processed by the server in the edge.

From IP Network Perspective…

LDN1 LDN3

LDN2

EAS-1

EAS-3

EAS-2

eBGP

eBGP eBGP

PSA1PSA3

PSA2

UE1IP-1

UE1IP-2

UE12IP-12

UE13IP-13

12

3

3

2

s1 2 3

B11

B21

s5

sb1 EAS: Edge Application Server

Many mini data centers can be close in proximity, making it difficult to differentiate in Routing Hops for App servers hosted in them,

Some data centers can have higher capacity than others,

Some sites may be more preferred when a UE anchored to a new 5G Site

ANYCAST: IP Layer Application ID -> multiple App serversBenefit of using ANYCAST: dynamically load balance across locations based on network conditions. 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. removes the dependency on UEs using their cached destination IP addresses for extended period

Problem 1: Selecting 5G Edge Application Location

Problem #3: Application Server Relocation

5G system

5G system

Problem #2: sticking to original App Server

Factors in selecting ANYCAST Server in 5G EC

• RTT to “app.net” ANYCAST S1:– List of {

- R1: RTT value- R2: RTT value- R3: RTT value

}

• Capacity• Site Preference

PSA1UE1

(IP-1)

PSA2

L-DN2

L-DN3

5G-site A

5G-site B

UE2(IP-2)

IP NETWORK(3GPP N6)

UE2(IP-2)UE2

(IP-2) UE2(IP-2)UE2

(IP-2)

UE1(IP-1)UE1

(IP-1)UE1(IP-1)UE1

(IP-1)

L-DN1S1: aa08::4450

S2: aa08::4460

S3: aa08::4470

S1: aa08::4450

S2: aa08::4460

S3: aa08::4470

R1Ra

S1: aa08::4450

S2: aa08::4460

S3: aa08::4470

Rb

R3

R2

RTT

Solution : a new BGP NLRI Path Attribute: AppMetaData

R1 R2

R3

R-PSA1

R-PSA2

R5

PSA1

PSA2IP networks by multiple ISPs

BGP UPDATE for its attached App Server ANYCAST address include:

Load Index, Capacity Index, and Site Preference

S1: aa08::4450

S2: aa08::4460

S3: aa08::4470

S1: aa08::4450

S2: aa08::4460

S3: aa08::4470

S1: aa08::4450

S2: aa08::4460

S3: aa08::4470S1: aa08::4450

S2: aa08::4460

S3: aa08::4470

NLRI BGP UPDATE:

Client route= S1: aa08::4450AppMetaData TLV

Load Measurement subTLVCapacity Index subTLVSite Preference subTLV

RR

analytics tool

Potentially to include Sub-TLVs for https://datatracker.ietf.org/doc/draft-mcd-rtgwg-extension-tn-aware-mobility/

Load Measurement Sub-TLVs

R1

S1: 10.1.2.x/24S2: 12.1.1.x/24S3: 11.1.1.x/24

R2

S1: 10.1.2.x/24S2: 12.1.1.x/24S3: 11.1.1.x/24

R3 S1: 10.1.2.x/24S2: 12.1.1.x/24S3: 11.1.1.x/24

R-PSA1

R-PSA2

S1: 10.1.2.x/24S2: 12.1.1.x/24S3: 11.1.1.x/24

Attached client address

R5

PSA1

PSA2

Load measurement SubTLV: Type= TBD2: measurements of packets/bytes to/from the App Server address; Type =TBD3: Load Measurement Index Measure Period: BGP Update period or user specified period

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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Type (TBD2) | Length |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Measurement Period |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | total number of packets to the App Server |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | total number of packets from the App Server |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | total number of bytes to the App Server |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | total number of bytes from the App Server |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Rx

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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Type (TBD3) | Length |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Measurement Period |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Aggregated Load Index to reach the App Server |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Load Measurement Index: Weighted combination of bytes/packets sent to/received from the App server:Load Measurement Index = w1 * ToPackets + w2* FromPackes + w3*ToBytes + w4*FromBytesw1+ w2+ w3+ w4 = 1 & 0< =wi <=1;

Capacity Index and Site Preference Index

Page 8

Capacity Index can also be derived from historic data.

Type =TBD4: capacity Index subTLV;

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Type (TBD4) | Length |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Capacity Index |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type =TBD5: Site preference Index subTLV;

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Type (TBD5) | Length |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Preference Index |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Capacity index : larger value means higher capacity, 1-10. if absent, use default value 5. Site preference Index, which is also the network preference index: larger value means higher preference: 1-10. If absent, use default value 5.

AppMetaData Propagation Scope

BGP RT constrained distribution (RFC4684)- there are much more App Servers than the

number of routersCreate a AppServer-Bound-Group

- Static configuration- each ingress router to ask a network controller

upon receiving the first packet to a specific ANYCAST address to be included in the “Application Bound Group Routers”

9

R1

R2

R3

R-PSA1

R-PSAi

R5

PSA1

PSAi

IP networks by multiple ISPs

BGP UPDATE for its attached App Server ANYCAST address include:

Load Index, Capacity Index, and Site Preference

S1: aa08::4450

S2: aa08::4460

S3: aa08::4470

S1: aa08::4450

S2: aa08::4460

S3: aa08::4470

S1: aa08::4450

S2: aa08::4460

S3: aa08::4470S1: aa08::4450

S2: aa08::4460

S3: aa08::4470

RR

Many routers are not interested in the App Servers S1, S2, S3

AppServer ID Interested Routers Time To Live Other attributes

S1: aa08::4450 R-PSA1, R-PSA2

S2: aa08::4460 R-PSA1,

Soft Anchoring of an ANYCAST flow

Using a group of ANYCAST addresses to achieve the Soft Anchoring a flow to one ANYCAST Location

Page 11

R2

G4: 10.1.2.x/24L1: Cost = 10L2: Cost =1L3: Cost =10

R3

G4: 10.1.2.x/24L1: Cost =10L2: Cost =10L3: Cost = 1

R1

R-PSA1

R-PSA2

PSA1

PSA2

IP networks

UE1(IP-1)UE1

(IP-1)UE1(IP-1)UE1

(IP-1)UE1(IP-1)

UE2(IP-2)UE2

(IP-2)UE2(IP-2)UE2

(IP-2)UE2(IP-2)

UE1(IP-2)

E2: app.net E3: app.net

G4: 10.1.2.x/24L1: Cost =1L2: Cost =10L3: Cost = 10

E1: app.net

Different weight is represented as Site

Preference, and advertised by BGP UPDATE

TABLE 1: DNS configuration:// global FQDN: app.netapp.net 172800 IN A G-4app.net 172800 IN AAAA G-6

// FQDN: op1.app.netldn1.op1.app.net 172800 IN A L1ldn2.op1.app.net 172800 IN A L2ldn3.op1.app.net 172800 IN A L3

IP ROUTES 2: Route Injection from AF -> IP Controller:G-4 -> {E1, E2, E3}L1 -> E1 | {E2, E3} if E1 has failedL2 -> E2 | {E1, E3} if E2 has failedL3 -> E3 | {E1, E2} if E3 has failed

Background Information

Algorithm in Selecting the Optimal Target Location

To compare the cost to reach the Application Server between the Site-i or Site-j: Load-i * CP-j Pref-j * Delay-i

Cost-i=min(w *(----------------) + (1-w) *(------------------))Load-j * CP-i Pref-i * Delay-j

• Load-i: Load Index at Site-I = w1*ToPackets+w2*FromPackes+w3*ToBytes+w4*FromBytes0<= wi <=1 and w1+ w2+ w3+ w4 = 1.

• CP-i (Capacity-i) (higher value means higher capacity): capacity index at the site i. • Delay-i: Network latency measurement (RTT) to the A-ER that has the Application

Server attached at the site-i. • Pref-i (Preference Index: higher value means higher preference): Network Preference

index for the site-I.• w: Weight for load and site information,

– 0<= w <=1: If smaller than 0.5, Network latency and the site Preference have more influence; otherwise, Server load and its capacity have more influence.