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