idnits 2.17.1 draft-dunbar-idr-5g-edge-compute-app-meta-data-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 : ---------------------------------------------------------------------------- No issues found here. 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 (November 2, 2020) is 1271 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 128, but not defined == Missing Reference: 'A-ER' is mentioned on line 352, but not defined == Missing Reference: 'IPv6-StickyService' is mentioned on line 347, but not defined == Missing Reference: 'Section 5' is mentioned on line 558, but not defined == Unused Reference: 'RFC4364' is defined on line 681, but no explicit reference was found in the text == Unused Reference: 'RFC8200' is defined on line 689, but no explicit reference was found in the text == Unused Reference: '3GPP-EdgeComputing' is defined on line 694, but no explicit reference was found in the text == Unused Reference: '5G-StickyService' is defined on line 707, but no explicit reference was found in the text == Unused Reference: 'RFC5521' is defined on line 712, but no explicit reference was found in the text == Unused Reference: 'BGP-SDWAN-Port' is defined on line 716, but no explicit reference was found in the text == Unused Reference: 'SDWAN-EDGE-Discovery' is defined on line 720, but no explicit reference was found in the text == Unused Reference: 'Tunnel-Encap' is defined on line 725, 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 -- No information found for draft-dunbar-6man-5g-ec-sticky-service - is the name correct? == 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: 1 error (**), 0 flaws (~~), 17 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 Futurewei 3 Intended status: Standard K. Majumdar 4 Expires: May 2, 2021 5 CommScope 6 H. Wang 7 Huawei 9 November 2, 2020 11 BGP NLRI App Meta Data for 5G Edge Computing Service 12 draft-dunbar-idr-5g-edge-compute-app-meta-data-01 14 Abstract 16 This draft describes a new BGP Network Layer Reachability 17 Information (BGP NLRI) Path Attribute, AppMetaData, that can 18 distribute the 5G Edge Computing App running status and 19 environment, so that other routers in the 5G Local Data 20 Network can make intelligent decision on optimized forwarding 21 of flows from UEs. The goal is to improve latency and 22 performance for 5G Edge Computing services. 24 The extension enables a feature, called soft anchoring, which 25 makes one Edge Computing Server at one specific location to be 26 more preferred than others for the same application to receive 27 packets from a specific source (UE). 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. This document may not be 36 modified, and derivative works of it may not be created, 37 except to publish it as an RFC and to translate it into 38 languages other than English. 40 Internet-Drafts are working documents of the Internet 41 Engineering Task Force (IETF), its areas, and its working 42 groups. Note that other groups may also distribute working 43 documents as Internet-Drafts. 45 Internet-Draft AppMetaData NLRI for 5G EC Service 47 Internet-Drafts are draft documents valid for a maximum of six 48 months and may be updated, replaced, or obsoleted by other 49 documents at any time. It is inappropriate to use Internet- 50 Drafts as reference material or to cite them other than as 51 "work in progress." 53 The list of current Internet-Drafts can be accessed at 54 http://www.ietf.org/ietf/1id-abstracts.txt 56 The list of Internet-Draft Shadow Directories can be accessed 57 at http://www.ietf.org/shadow.html 59 This Internet-Draft will expire on April 7, 2021. 61 Copyright Notice 63 Copyright (c) 2020 IETF Trust and the persons identified as 64 the document authors. All rights reserved. 66 This document is subject to BCP 78 and the IETF Trust's Legal 67 Provisions Relating to IETF Documents 68 (http://trustee.ietf.org/license-info) in effect on the date 69 of publication of this document. Please review these documents 70 carefully, as they describe your rights and restrictions with 71 respect to this document. Code Components extracted from this 72 document must include Simplified BSD License text as described 73 in Section 4.e of the Trust Legal Provisions and are provided 74 without warranty as described in the Simplified BSD License. 76 Table of Contents 78 1. Introduction.............................................. 3 79 1.1. 5G Edge Computing Background......................... 3 80 1.2. Problem#1: ANYCAST in 5G EC Environment.............. 5 81 1.3. Problem #2: Unbalanced Anycast Distribution due to UE 82 Mobility.................................................. 6 84 Internet-Draft AppMetaData NLRI for 5G EC Service 86 1.4. Problem 3: Application Server Relocation............. 6 87 2. Conventions used in this document......................... 7 88 3. Usage of App Meta Data for 5G Edge Computing.............. 8 89 3.1. Overview............................................. 8 90 3.2. IP Layer Metrics to Gauge Application Behavior....... 9 91 3.3. To Equalize among Multiple ANYCAST Locations........ 10 92 3.4. BGP Protocol Extension to advertise Load & Capacity. 10 93 4. The NLRI Path Attribute for App Meta Data................ 11 94 4.1. Load Measurement sub-TLV format..................... 13 95 4.2. Capacity Index sub-TLV format....................... 14 96 4.3. The Site Preference Index sub-TLV format............ 14 97 5. Soft Anchoring of an ANYCAST Flow........................ 15 98 6. Manageability Considerations............................. 17 99 7. Security Considerations.................................. 17 100 8. IANA Considerations...................................... 17 101 9. References............................................... 17 102 9.1. Normative References................................ 17 103 9.2. Informative References.............................. 17 104 10. Acknowledgments......................................... 18 106 1. Introduction 108 This document describes a new BGP Network Layer Reachability 109 Information (BGP NLRI) Path Attribute, AppMetaData, that can 110 distribute the 5G Edge Computing App running status and 111 environment, so that other routers in the 5G Local Data 112 Network can make intelligent decision on optimized forwarding 113 of flows from UEs. The goal is to improve latency and 114 performance for 5G Edge Computing services. 116 1.1. 5G Edge Computing Background 118 As described in [5G-EC-Metrics], one Application can have 119 multiple Application Servers hosted in different Edge 120 Computing data centers that are close in proximity. Those Edge 121 Computing (mini) data centers are usually very close to, or 122 co-located with, 5G base stations, with the goal to minimize 123 latency and optimize the user experience. 125 When a UE (User Equipment) initiates application packets using 126 the destination address from a DNS reply or from its own 127 cache, the packets from the UE are carried in a PDU session 128 through 5G Core [5GC] to the 5G UPF-PSA (User Plan Function - 130 Internet-Draft AppMetaData NLRI for 5G EC Service 132 PDU Session Anchor). The UPF-PSA decapsulate the 5G GTP outer 133 header and forwards the packets from the UEs to the Ingress 134 router of the Edge Computing (EC) Local Data Network (LDN). 135 The LDN for 5G EC, which is the IP Networks from 5GC 136 perspective, is responsible for forwarding the packets to the 137 intended destinations. 139 When the UE moves out of coverage of its current gNB (next 140 generation Node B) (gNB1), handover procedures are initiated 141 and the 5G SMF (Session Management Function) also selects a 142 new UPF-PSA. The standard handover procedures described in 143 3GPP TS 23.501 and TS 23.502 are followed. When the handover 144 process is complete, the UE has a new IP address and the IP 145 point of attachment is to the new UPF-PSA. 5GC may maintain a 146 path from the old UPF to new the UPF for a short period of 147 time for SSC [Session and Service Continuity] mode 3 to make 148 the handover process more seamless. 150 Internet-Draft AppMetaData NLRI for 5G EC Service 152 +--+ 153 |UE|---\+---------+ +------------------+ 154 +--+ | 5G | +---------+ | S1: aa08::4450 | 155 +--+ | Site +--++---+ +----+ | 156 |UE|----| A |PSA| Ra| | R1 | S2: aa08::4460 | 157 +--+ | +---+---+ +----+ | 158 +---+ | | | | | S3: aa08::4470 | 159 |UE1|---/+---------+ | | +------------------+ 160 +---+ |IP Network | L-DN1 161 |(3GPP N6) | 162 | | | +------------------+ 163 | UE1 | | | S1: aa08::4450 | 164 | moves to | +----+ | 165 | Site B | | R3 | S2: aa08::4460 | 166 v | +----+ | 167 | | | S3: aa08::4470 | 168 | | +------------------+ 169 | | L-DN3 170 +--+ | | 171 |UE|---\+---------+ | | +------------------+ 172 +--+ | 5G | | | | S1: aa08::4450 | 173 +--+ | Site +--++-+--+ +----+ | 174 |UE|----| B |PSA| Rb | | R2 | S2: aa08::4460 | 175 +--+ | +--++----+ +----+ | 176 +--+ | | +-----------+ | S3: aa08::4470 | 177 |UE|---/+---------+ +------------------+ 178 +--+ L-DN2 179 Figure 1: App Servers in different edge DCs 181 1.2. Problem#1: ANYCAST in 5G EC Environment 183 Increasingly, Anycast is used extensively by various 184 application providers and CDNs because ANYCAST makes it 185 possible to dynamically load balance across server locations 186 based on network conditions. 188 Application Server location selection using Anycast address 189 leverages the proximity information present in the network 190 (routing) layer and eliminates the single point of failure and 191 bottleneck at the DNS resolvers and application layer load 192 balancers. Another benefit of using ANYCAST address is 194 Internet-Draft AppMetaData NLRI for 5G EC Service 196 removing the dependency on UEs. Some UEs (or clients) might 197 use their cached IP addresses instead of querying DNS for 198 extended period. 200 But, having multiple locations of the same ANYCAST address in 201 5G Edge Computing environment can be problematic because all 202 those edge computing Data Centers can be close in proximity. 203 There might be very little difference in the routing cost to 204 reach the Application Servers in different Edge DCs. 206 BGP is an integral part in the way IP Anycast usually 207 functions. Within BGP routing there are multiple routes for 208 the same IP address which are pointing to different locations. 210 This draft describes the BGP UPDATE extension to allow the App 211 Servers Running status and environment to be included in the 212 BGP UPDATE messages, so that other routers can select more 213 optimal ANYCAST location based on the combination of network 214 delay, the App Server load index, the location capacity index 215 and the location preference. 217 1.3. Problem #2: Unbalanced Anycast Distribution due to UE 218 Mobility 220 Another problem of using ANYCAST address for multiple 221 Application Servers of the same application in 5G environment 222 is that UEs' frequent moving from one 5G site to another, 223 which can make it difficult to plan where the App Server 224 should be hosted. When one App server is heavily utilized, 225 other App servers of the same address close-by can be very 226 underutilized. Since the condition can be short lived, it is 227 difficult for the application controller to anticipate the 228 move and adjust. 230 1.4. Problem 3: Application Server Relocation 232 When an Application Server is added to, moved, or deleted from 233 a 5G Edge Computing Data Center, the routing protocol needs to 234 propagate the changes to 5G PSA or the PSA adjacent routers. 235 After the change, the cost associated with the site [5G-EC- 236 Metrics] might change as well. 238 Internet-Draft AppMetaData NLRI for 5G EC Service 240 Note: for the ease of description, the Edge Application Server 241 and Application Server are used interchangeably throughout 242 this document. 244 2. Conventions used in this document 246 A-ER: Egress Router to an Application Server, [A-ER] is 247 used to describe the last router that the 248 Application Server is attached. For 5G EC 249 environment, the A-ER can be the gateway router to 250 a (mini) Edge Computing Data Center. 252 Application Server: An application server is a physical or 253 virtual server that host the software system for 254 the application. 256 Application Server Location: Represent a cluster of servers at 257 one location serving the same Application. One 258 application may have a Layer 7 Load balancer, 259 whose address(es) are reachable from external IP 260 network, in front of a set of application servers. 261 From IP network perspective, this whole group of 262 servers are considered as the Application server 263 at the location. 265 Edge Application Server: used interchangeably with Application 266 Server throughout this document. 268 EC: Edge Computing 270 Edge Hosting Environment: An environment providing support 271 required for Edge Application Server's execution. 273 NOTE: The above terminologies are the same as 274 those used in 3GPP TR 23.758 276 Internet-Draft AppMetaData NLRI for 5G EC Service 278 Edge DC: Edge Data Center, which provides the Edge 279 Computing Hosting Environment. It might be co- 280 located with 5G Base Station and not only host 5G 281 core functions, but also host frequently used Edge 282 server instances. 284 gNB next generation Node B 286 L-DN: Local Data Network 288 PSA: PDU Session Anchor (UPF) 290 SSC: Session and Service Continuity 292 UE: User Equipment 294 UPF: User Plane Function 296 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 297 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 298 RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 299 interpreted as described in BCP 14 [RFC2119] [RFC8174] when, 300 and only when, they appear in all capitals, as shown here. 302 3. Usage of App Meta Data for 5G Edge Computing 304 3.1. Overview 306 From IP Layer, the Application Servers are identified by their 307 IP (ANYCAST) addresses. The 5G Edge Computing controller or 308 management system is aware of the ANYCAST addresses of the 309 Applications that need optimized forwarding in 5G EC 310 environment. The 5G Edge Computing controller or management 311 system can configure the ACLs to filter out those applications 312 on the routers adjacent to the 5G PSA and the routers to which 313 the Application Servers are directly attached. 315 The proposed solution is for the routers, i.e. A-ER, that have 316 direct links to the Application Servers to collect various 317 measurements about the Servers' running status [5G-EC-Metrics] 318 and advertise the metrics to other routers in 5G EC LDN (Local 319 Data Network). 321 Internet-Draft AppMetaData NLRI for 5G EC Service 323 3.2. IP Layer Metrics to Gauge Application Behavior 325 [5G-EC-Metrics] describes the IP Layer Metrics that can gauge 326 the application servers running status and environment: 328 - IP-Layer Metric for App Server Load Measurement: 329 The Load Measurement to an App Server is a weighted 330 combination of the number of packets/bites to the App Server 331 and the number of packets/bytes from the App Server which 332 are collected by the A-ER to which the App Server is 333 directly attached. 334 The A-ER is configured with an ACL that can filter out the 335 packets for the Application Server. 336 - Capacity Index 337 Capacity Index is used to differentiate the running 338 environment of the application server. Some data centers can 339 have hundreds, or thousands, of servers behind an 340 Application Server's App Layer Load Balancer that is 341 reachable from external world. Other data centers can have 342 very small number of servers for the application server. 343 "Capacity Index", which is a numeric number, is used to 344 represent the capacity of the application server in a 345 specific location. 346 - Site preference index: 347 [IPv6-StickyService] describes a scenario that some sites 348 are more preferred for handling an application server than 349 others for flows from a specific UE. 351 In this document, the term "Application Server Egress Router" 352 [A-ER] is used to describe the last router that an Application 353 Server is attached. For 5G EC environment, the A-ER can be the 354 gateway router to the EC DC where multiple Application 355 servers' instance are hosted. 357 From IP Layer, an Application Server is identified by its IP 358 (ANYCAST) Address. Those IP addresses are called the 359 Application Server IDs throughout this document. 361 Internet-Draft AppMetaData NLRI for 5G EC Service 363 3.3. To Equalize among Multiple ANYCAST Locations 365 The main benefit of using ANYCAST is to leverage the network 366 layer information to equalize the traffic among multiple 367 Application Server locations of the same Application, which is 368 identified by its ANYCAST addresses. 370 For 5G Edge Computing environment, the ingress routers to the 371 LDN needs to be notified of the Load Index and Capacity Index 372 of the App Servers at different EC data centers to make the 373 intelligent decision on where to forward the traffic for the 374 application from UEs. 376 [5G-EC-Metrics] describes the algorithms that can be used by 377 the routers directly attached to the 5G PSA to compare the 378 cost to reach the App Servers between the Site-i or Site-j: 380 Load-i * CP-j Pref-j * Delay-i 381 Cost-i=min(w *(----------------) + (1-w) *(------------------)) 382 Load-j * CP-i Pref-i * Delay-j 384 Load-i: Load Index at Site-i, it is the weighted 385 combination of the total packets or/and bytes sent to and 386 received from the Application Server at Site-i during a 387 fixed time period. 389 CP-i: capacity index at the site I, higher value means 390 higher capacity. 392 Delay-i: Network latency measurement (RTT) to the A-ER that 393 has the Application Server attached at the site-i. 395 Pref-i: Preference index for the site-i, higher value means 396 higher preference. 398 w: Weight for load and site information, which is a value 399 between 0 and 1. If smaller than 0.5, Network latency and 400 the site Preference have more influence; otherwise, Server 401 load and its capacity have more influence. 403 3.4. BGP Protocol Extension to advertise Load & Capacity 405 Goal of the protocol extension: 407 Internet-Draft AppMetaData NLRI for 5G EC Service 409 - Propagate the Load Measurement Index for the attached App 410 Servers to other routers in the LDN. 412 - Propagate the Capacity Index & 414 - Propagate Site Preference Index. 416 The BGP extension is to add the Load Index Sub-TLV, Capacity 417 Sub-TLV, and the Site Preference Sub-TLV in the NLRI 418 associated with the routes. 420 4. The NLRI Path Attribute for App Meta Data 422 The App Meta Data attribute is an optional transitive BGP Path 423 attribute to carry application specific data, such as running 424 status, capacity and site preference. Will need IANA to 425 assign a value as the type code of the attribute. The 426 attribute is composed of a set of Type-Length-Value (TLV) 427 encodings. Each TLV contains information corresponding to 428 metrics to a specific Application Server. An App Meta Data 429 TLV, is structured as shown in Figure 1: 431 0 1 2 3 432 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 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | AppMetaData Type (2 Octets) | Length (2 Octets) | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | | 437 | Value | 438 | | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 Figure 2: App Meta Data TLV Value Field 442 AppMetaData Type (2 octets): identifies a type of Application 443 related metadata. The field contains values from the IANA 444 Registry "BGP AppMetaData Types". To be added. 446 o Length (2 octets): the total number of octets of the 447 value field. 449 o Value (variable): comprised of multiple sub-TLVs. 451 Internet-Draft AppMetaData NLRI for 5G EC Service 453 Each sub-TLV consists of three fields: a 1-octet type, a 1- 454 octet or 2-octet length field (depending on the type), and 455 zero or more octets of value. A sub-TLV is structured as 456 shown in Figure 2: 458 +--------------------------------+ 459 | Sub-TLV Type (1 Octet) | 460 +--------------------------------+ 461 | Sub-TLV Length (1 or 2 Octets) | 462 +--------------------------------+ 463 | Sub-TLV Value (Variable) | 464 +--------------------------------+ 466 Figure 3: App Metadata Sub-TLV Value Field 468 o Sub-TLV Type (1 octet): each sub-TLV type defines a 469 certain property about the AppMetaData TLV that contains 470 this sub-TLV. The field contains values from the IANA 471 Registry "BGP AppMetaData Attribute Sub-TLVs". 473 o Sub-TLV Length (1 or 2 octets): the total number of 474 octets of the sub-TLV value field. The Sub-TLV Length field 475 contains 1 octet if the Sub-TLV Type field contains a value 476 in the range from 0-127. The Sub-TLV Length field contains 477 two octets if the Sub-TLV Type field contains a value in the 478 range from 128-255. 480 o Sub-TLV Value (variable): encodings of the value field 481 depend on the sub-TLV type as enumerated above. The 482 following sub-sections define the encoding in detail. 484 Internet-Draft AppMetaData NLRI for 5G EC Service 486 4.1. Load Measurement sub-TLV format 488 Two types of Load Measurement Sub-TLVs are specified. One is 489 to carry the aggregated cost Index based on weighted 490 combination of the collected measurements; another one is to 491 carry the raw measurements of packets/bytes to/from the App 492 Server address. The raw measurement is useful when the egress 493 routers cannot be configured with a consistent algorithm to 494 compute the aggregated load index and the raw measurements are 495 needed by a central analytic system. 497 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 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | Type (TBD2) | Length | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | Measurement Period | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | Aggregated Load Index to reach the App Server | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 Figure 4: Aggregated Load Index Sub-TLV 507 Load Measurement sub-TLV has the following format: 509 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 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | Type (TBD3) | Length | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | Measurement Period | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | total number of packets to the AppServer | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | total number of packets from the AppServer | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | total number of bytes to the AppServer | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | total number of bytes from the AppServer | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 Figure 5: Raw Load Measurement Sub-TLV 525 Type =TBD2: Aggregated Load Measurement Index derived from 526 the Weighted combination of bytes/packets sent to/received 527 from the App server: 529 Index=w1*ToPackets+w2*FromPackes+w3*ToBytes+w4*FromBytes 531 Where w1+ w2+ w3+ w4 = 1 and 0< wi <1; 533 Internet-Draft AppMetaData NLRI for 5G EC Service 535 Type= TBD3: Raw measurements of packets/bytes to/from the 536 App Server address; 538 Measure Period: BGP Update period or user specified period 540 4.2. Capacity Index sub-TLV format 542 The Capacity Index sub-TLV has the following format: 544 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 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | Type (TBD4) | Length | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | Capacity Index | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 Note: "Capacity Index" can be more stable for each site. If 552 those values are configured to nodes, they might not need to 553 be included in every BGP UPDATE. 555 4.3. The Site Preference Index sub-TLV format 557 The site Preference Index is used to achieve Soft Anchoring 558 [Section 5] an application flow from a UE to a specific 559 location when the UE moves from one 5G site to another. 561 The Preference Index sub-TLV has the following format: 563 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 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | Type (TBD5) | Length | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | Preference Index | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 Note: "Site Preference Index" can be more stable for each 571 site. If those values are configured to nodes, they might not 572 need to be included in every BGP UPDATE. 574 Internet-Draft AppMetaData NLRI for 5G EC Service 576 5. Soft Anchoring of an ANYCAST Flow 577 "Sticky Service" in the 3GPP Edge Computing specification 578 (3GPP TR 23.748) requires a UE to a specific ANYCAST location 579 when the UE moves from one 5G Site to another. 581 "Soft Anchoring" is referring to forwarding the Application 582 flow from the UE to the a preferred location for the ANYCAST 583 address, when the preferred location is in good condition. 584 But if there is any failure at the preferred location, the 585 Application flow from the UE need to be forwarded to another 586 location that host the same application. 588 This section describes a solution that can softly anchor an 589 application flow from a UE to a preferred location. 591 Lets' assume one application "App.net" is instantiated on 592 four servers that are attached to four different routers R1, 593 R2, R3, and R4 respectively. It is desired for packets to the 594 "App.net" from UE-1 to stick with one server, say the App 595 Server attached to R1, even when the UE moves from one 5G 596 site to another. When there is failure at R1 or the 597 Application Server attached to R1, the packets of the flow 598 "App.net" from UE-1 need to be forwarded to the Application 599 Server attached to R2, R3, or R4. 601 We call this kind of sticky service "Soft Anchoring", meaning 602 that anchoring to the site of R1 is preferred, but other 603 sites can be chosen when the preferred site encounters 604 failure. 606 Here is details of this solution: 608 - Assign a group of ANYCAST addresses to one application. 609 For example, "App.net" is assigned with 4 ANYCAST 610 addresses, L1, L2, L3, and L4. L1/L2/L3/L4 represents 611 the location preferred ANYCAST addresses. 612 - For the App.net Server attached to a router, the router 613 has four Stub links to the same Server, L1, L2, L3, and 614 L4 respectively. The cost to L1, L2, L3 and L4 is 615 assigned differently for different routers. For example, 616 o When attached to R1, the L1 has the lowest cost, 617 say 10, when attached to R2, R3, and R4, the L1 can 618 have higher cost, say 30. 620 Internet-Draft AppMetaData NLRI for 5G EC Service 622 o ANYCAST L2 has the lowest cost when attached to R2, 623 higher cost when attached to R1, R3, R4 624 respectively. 625 o ANYCAST L3 has the lowest cost when attached to R3, 626 higher cost when attached to R1, R2, R4 627 respectively, and 628 o ANYCAST L4 has the lowest cost when attached to R4, 629 higher cost when attached to R1, R2, R3 630 respectively 631 - When a UE queries for the "App.net" for the first time, 632 the DNS replies the location preferred ANYCAST address, 633 say L1, based on where the query is initiated. 634 - When the UE moves from one 5G site-A to Site-B, UE 635 continues sending packets of the "App.net" to ANYCAST 636 address L1. The routers will continue sending packets to 637 R1 because the total cost for the App.net instance for 638 ANYCAST L1 is lowest at R1. If any failure occurs making 639 R1 not reachable, the packets of the "App.net" from UE-1 640 will be sent to R2, R3, or R4 (depending on the total 641 cost to reach each of them). 643 If the Application Server supports the HTTP redirect, more 644 optimal forwarding can be achieved. 646 - When a UE queries for the "App.net" for the first time, 647 the global DNS replies the ANYCAST address G1, which has 648 the same cost regardless where the Application Servers 649 are attached. 650 - When the UE initiates the communication to G1, the 651 packets from the UE will be sent to the Application 652 Server that has the lowest cost, say the Server attached 653 to R1. The Application server is instructed with HTTPs 654 Redirect to respond back a location specific URL, say 655 App.net-Loc1. The client on the UE will query the DNS 656 for App.net-Loc1 and get the response of ANYCAST L1. The 657 subsequent packets from the UE-1 for App.net are sent to 658 L1. 660 Internet-Draft AppMetaData NLRI for 5G EC Service 662 6. Manageability Considerations 664 To be added. 666 7. Security Considerations 668 To be added. 670 8. IANA Considerations 672 To be added. 674 9. References 676 9.1. Normative References 678 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 679 Requirement Levels", BCP 14, RFC 2119, March 1997. 681 [RFC4364] E. rosen, Y. Rekhter, "BGP/MPLS IP Virtual Private 682 networks (VPNs)", Feb 2006. 684 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in 685 RFC 2119 Key Words", BCP 14, RFC 8174, DOI 686 10.17487/RFC8174, May 2017, . 689 [RFC8200] s. Deering R. Hinden, "Internet Protocol, Version 6 690 (IPv6) Specification", July 2017 692 9.2. Informative References 694 [3GPP-EdgeComputing] 3GPP TR 23.748, "3rd Generation 695 Partnership Project; Technical Specification Group 696 Services and System Aspects; Study on enhancement of 697 support for Edge Computing in 5G Core network 698 (5GC)", Release 17 work in progress, Aug 2020. 700 Internet-Draft AppMetaData NLRI for 5G EC Service 702 [5G-EC-Metrics] L. Dunbar, H. Song, J. Kaippallimalil, "IP 703 Layer Metrics for 5G Edge Computing Service", draft- 704 dunbar-ippm-5g-edge-compute-ip-layer-metrics-00, 705 work-in-progress, Oct 2020. 707 [5G-StickyService] L. Dunbar, J. Kaippallimalil, "IPv6 708 Solution for 5G Edge Computing Sticky Service", 709 draft-dunbar-6man-5g-ec-sticky-service-00, work-in- 710 progress, Oct 2020. 712 [RFC5521] P. Mohapatra, E. Rosen, "The BGP Encapsulation 713 Subsequent Address Family Identifier (SAFI) and the 714 BGP Tunnel Encapsulation Attribute", April 2009. 716 [BGP-SDWAN-Port] L. Dunbar, H. Wang, W. Hao, "BGP Extension 717 for SDWAN Overlay Networks", draft-dunbar-idr-bgp- 718 sdwan-overlay-ext-03, work-in-progress, Nov 2018. 720 [SDWAN-EDGE-Discovery] L. Dunbar, S. Hares, R. Raszuk, K. 721 Majumdar, "BGP UPDATE for SDWAN Edge Discovery", 722 draft-dunbar-idr-sdwan-edge-discovery-00, work-in- 723 progress, July 2020. 725 [Tunnel-Encap] E. Rosen, et al "The BGP Tunnel Encapsulation 726 Attribute", draft-ietf-idr-tunnel-encaps-10, Aug 727 2018. 729 10. Acknowledgments 731 Acknowledgements to Donald Eastlake for their review and 732 contributions. 734 This document was prepared using 2-Word-v2.0.template.dot. 736 Internet-Draft AppMetaData NLRI for 5G EC Service 738 Authors' Addresses 740 Linda Dunbar 741 Futurewei 742 Email: ldunbar@futurewei.com 744 Kausik Majumdar 745 CommScope 746 350 W Java Drive, Sunnyvale, CA 94089 747 Email: kausik.majumdar@commscope.com 749 Haibo Wang 750 Huawei 751 Email: rainsword.wang@huawei.com