idnits 2.17.1 draft-dunbar-lsr-5g-edge-compute-ospf-ext-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 date (November 2, 2020) is 1270 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 119, but not defined == Missing Reference: 'A-ER' is mentioned on line 360, but not defined == Missing Reference: 'IPv6-StickyService' is mentioned on line 353, but not defined == Missing Reference: 'RFC3630' is mentioned on line 512, but not defined == Missing Reference: 'RFC2328' is mentioned on line 615, but not defined == Unused Reference: 'RFC4364' is defined on line 741, but no explicit reference was found in the text == Unused Reference: 'RFC8200' is defined on line 751, but no explicit reference was found in the text == Unused Reference: '3GPP-EdgeComputing' is defined on line 756, but no explicit reference was found in the text == Unused Reference: '5G-StickyService' is defined on line 773, but no explicit reference was found in the text == Unused Reference: 'RFC5521' is defined on line 778, but no explicit reference was found in the text == Unused Reference: 'BGP-SDWAN-Port' is defined on line 783, but no explicit reference was found in the text == Unused Reference: 'SDWAN-EDGE-Discovery' is defined on line 790, but no explicit reference was found in the text == Unused Reference: 'Tunnel-Encap' is defined on line 795, but no explicit reference was found in the text ** Downref: Normative reference to an Proposed Standard RFC: RFC 4364 == Outdated reference: A later version (-14) exists of draft-dunbar-idr-5g-edge-compute-app-meta-data-01 == Outdated reference: A later version (-02) exists of draft-dunbar-ippm-5g-edge-compute-ip-layer-metrics-01 -- 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 (~~), 18 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 H. Chen 3 Intended status: Standard Futurewei 4 Expires: May 2, 2021 6 November 2, 2020 8 OSPF extension for 5G Edge Computing Service 9 draft-dunbar-lsr-5g-edge-compute-ospf-ext-01 11 Abstract 13 This draft describes an OSPF extension that can distribute 14 the 5G Edge Computing App running status and environment, 15 so that other routers in the 5G Local Data Network can make 16 intelligent decision on optimized forwarding of flows from 17 UEs. The goal is to improve latency and performance for 5G 18 Edge Computing services. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with 23 the provisions of BCP 78 and BCP 79. 25 This Internet-Draft is submitted in full conformance with 26 the provisions of BCP 78 and BCP 79. This document may not 27 be modified, and derivative works of it may not be created, 28 except to publish it as an RFC and to translate it into 29 languages other than English. 31 Internet-Drafts are working documents of the Internet 32 Engineering Task Force (IETF), its areas, and its working 33 groups. Note that other groups may also distribute working 34 documents as Internet-Drafts. 36 Internet-Drafts are draft documents valid for a maximum of 37 six months and may be updated, replaced, or obsoleted by 38 other documents at any time. It is inappropriate to use 39 Internet-Drafts as reference material or to cite them other 40 than as "work in progress." 42 Internet-Draft OSPF Extension for 5G EC Service 44 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/ietf/1id-abstracts.txt 47 The list of Internet-Draft Shadow Directories can be 48 accessed at http://www.ietf.org/shadow.html 50 This Internet-Draft will expire on April 7, 2021. 52 Copyright Notice 54 Copyright (c) 2020 IETF Trust and the persons identified as 55 the document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's 58 Legal Provisions Relating to IETF Documents 59 (http://trustee.ietf.org/license-info) in effect on the 60 date of publication of this document. Please review these 61 documents carefully, as they describe your rights and 62 restrictions with respect to this document. Code Components 63 extracted from this document must include Simplified BSD 64 License text as described in Section 4.e of the Trust Legal 65 Provisions and are provided without warranty as described 66 in the Simplified BSD License. 68 Table of Contents 70 1. Introduction........................................... 3 71 1.1. 5G Edge Computing Background...................... 3 72 1.2. Problem#1: ANYCAST in 5G EC Environment........... 4 73 1.3. Problem #2: Unbalanced Anycast Distribution due to 74 UE Mobility............................................ 5 75 1.4. Problem 3: Application Server Relocation.......... 6 76 2. Conventions used in this document...................... 6 77 3. OSPF Extension for 5G EC............................... 7 78 3.1. Solution Overview................................. 7 79 3.2. IP Layer Metrics to Gauge Application Behavior.... 9 80 3.3. To Equalize among Multiple ANYCAST Locations..... 10 81 3.4. OSPF Protocol Extension to advertise Load & 82 Capacity.............................................. 11 83 3.5. Reason for using IGP Based Solution:............. 11 84 3.6. OSPF Extension Using TE Stub Link................ 12 85 3.7. Aggregated Link Cost Solution.................... 15 86 4. Soft Anchoring of an ANYCAST Flow..................... 16 88 Internet-Draft OSPF Extension for 5G EC Service 90 5. Manageability Considerations.......................... 18 91 6. Security Considerations............................... 18 92 7. IANA Considerations................................... 18 93 8. References............................................ 18 94 8.1. Normative References............................. 18 95 8.2. Informative References........................... 19 96 9. Acknowledgments....................................... 20 98 1. Introduction 100 This document describes an OSPF extension that can 101 distribute the 5G Edge Computing App running status and 102 environment, so that other routers in the 5G Local Data 103 Network can make intelligent decision on optimized 104 forwarding of flows from UEs. The goal is to improve 105 latency and performance for 5G Edge Computing services.. 107 1.1. 5G Edge Computing Background 109 As described in [5G-EC-Metrics], one Application can have 110 multiple Application Servers hosted in different Edge 111 Computing data centers that are close in proximity. Those 112 Edge Computing (mini) data centers are usually very close 113 to, or co-located with, 5G base stations, with the goal to 114 minimize latency and optimize the user experience. 116 When a UE (User Equipment) initiates application packets 117 using the destination address from a DNS reply or from its 118 own cache, the packets from the UE are carried in a PDU 119 session through 5G Core [5GC] to the 5G UPF-PSA (User Plan 120 Function - PDU Session Anchor). The UPF-PSA decapsulates 121 the 5G GTP outer header and forwards the packets from the 122 UEs to the Ingress router of the Edge Computing (EC) Local 123 Data Network (LDN). The LDN for 5G EC, which is the IP 124 Networks from 5GC perspective, is responsible for 125 forwarding the packets to the intended destinations. 127 When the UE moves out of coverage of its current gNB (next 128 generation Node B) (gNB1), handover procedures are 129 initiated and the 5G SMF (Session Management Function) also 130 selects a new UPF-PSA. The standard handover procedures 132 Internet-Draft OSPF Extension for 5G EC Service 134 described in 3GPP TS 23.501 and TS 23.502 are followed. 135 When the handover process is complete, the UE has a new IP 136 address and the IP point of attachment is to the new UPF- 137 PSA. 5GC may maintain a path from the old UPF to new the 138 UPF for a short period of time for SSC [Session and Service 139 Continuity] mode 3 to make the handover process more 140 seamless. 141 +--+ 142 |UE|---\+---------+ +------------------+ 143 +--+ | 5G | +---------+ | S1: aa08::4450 | 144 +--+ | Site +--++---+ +----+ | 145 |UE|----| A |PSA| Ra| | R1 | S2: aa08::4460 | 146 +--+ | +---+---+ +----+ | 147 +---+ | | | | | S3: aa08::4470 | 148 |UE1|---/+---------+ | | +------------------+ 149 +---+ |IP Network | L-DN1 150 |(3GPP N6) | 151 | | | +------------------+ 152 | UE1 | | | S1: aa08::4450 | 153 | moves to | +----+ | 154 | Site B | | R3 | S2: aa08::4460 | 155 v | +----+ | 156 | | | S3: aa08::4470 | 157 | | +------------------+ 158 | | L-DN3 159 +--+ | | 160 |UE|---\+---------+ | | +------------------+ 161 +--+ | 5G | | | | S1: aa08::4450 | 162 +--+ | Site +--++-+--+ +----+ | 163 |UE|----| B |PSA| Rb | | R2 | S2: aa08::4460 | 164 +--+ | +--++----+ +----+ | 165 +--+ | | +-----------+ | S3: aa08::4470 | 166 |UE|---/+---------+ +------------------+ 167 +--+ L-DN2 168 Figure 1: App Servers in different edge DCs 170 1.2. Problem#1: ANYCAST in 5G EC Environment 172 Increasingly, Anycast is used extensively by various 173 application providers and CDNs because ANYCAST makes it 175 Internet-Draft OSPF Extension for 5G EC Service 177 possible to dynamically load balance across server 178 locations based on network conditions. 180 Application Server location selection using Anycast address 181 leverages the proximity information present in the network 182 (routing) layer and eliminates the single point of failure 183 and bottleneck at the DNS resolvers and application layer 184 load balancers. Another benefit of using ANYCAST address is 185 removing the dependency on UEs. Some UEs (or clients) might 186 use their cached IP addresses instead of querying DNS for 187 extended period. 189 But, having multiple locations of the same ANYCAST address 190 in 5G Edge Computing environment can be problematic because 191 all those edge computing Data Centers can be close in 192 proximity. There might be very little difference in the 193 routing cost to reach the Application Servers in different 194 Edge DCs. 196 BGP is an integral part in the way IP Anycast usually 197 functions. Within BGP routing there are multiple routes for 198 the same IP address which are pointing to different 199 locations. When many Edge DCs are within one IGP domain, 200 there could be no routing cost differentiation by BGP. Same 201 routing cost to multiple ANYCAST locations can cause 202 packets from one flow to be forwarded to different 203 locations, which can cause service glitches. 205 1.3. Problem #2: Unbalanced Anycast Distribution due to UE 206 Mobility 208 Another problem of using ANYCAST address for multiple 209 Application Servers of the same application in 5G 210 environment is that UEs' frequent moving from one 5G site 211 to another, which can make it difficult to plan where the 212 App Server should be hosted. When one App server is heavily 213 utilized, other App servers of the same address close-by 214 can be very underutilized. Since the condition can be short 215 lived, it is difficult for the application controller to 216 anticipate the move and adjust. 218 Internet-Draft OSPF Extension for 5G EC Service 220 1.4. Problem 3: Application Server Relocation 222 When an Application Server is added to, moved, or deleted 223 from a 5G Edge Computing Data Center, the routing protocol 224 has to propagate the changes to 5G PSA or the PSA adjacent 225 routers. After the change, the cost associated with the 226 site [5G-EC-Metrics] might change as well. 228 Note: for the ease of description, the Edge Application 229 Server and Application Server are used interchangeably 230 throughout this document. 232 2. Conventions used in this document 234 A-ER: Egress Router to an Application Server, [A-ER] 235 is used to describe the last router that the 236 Application Server is attached. For 5G EC 237 environment, the A-ER can be the gateway router 238 to a (mini) Edge Computing Data Center. 240 Application Server: An application server is a physical or 241 virtual server that host the software system 242 for the application. 244 Application Server Location: Represent a cluster of servers 245 at one location serving the same Application. 246 One application may have a Layer 7 Load 247 balancer, whose address(es) are reachable from 248 external IP network, in front of a set of 249 application servers. From IP network 250 perspective, this whole group of servers are 251 considered as the Application server at the 252 location. 254 Edge Application Server: used interchangeably with 255 Application Server throughout this document. 257 EC: Edge Computing 259 Internet-Draft OSPF Extension for 5G EC Service 261 Edge Hosting Environment: An environment providing support 262 required for Edge Application Server's 263 execution. 265 NOTE: The above terminologies are the same as 266 those used in 3GPP TR 23.758 268 Edge DC: Edge Data Center, which provides the Edge 269 Computing Hosting Environment. It might be co- 270 located with 5G Base Station and not only host 271 5G core functions, but also host frequently 272 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", 287 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 288 RECOMMENDED", "MAY", and "OPTIONAL" in this document are to 289 be interpreted as described in BCP 14 [RFC2119] [RFC8174] 290 when, and only when, they appear in all capitals, as shown 291 here. 293 3. OSPF Extension for 5G EC 295 3.1. Solution Overview 297 From IP Layer, the Application Servers are identified by 298 their IP (ANYCAST) addresses. The 5G Edge Computing 299 controller or management system is aware of the ANYCAST 300 addresses of the Applications that need optimized 301 forwarding in 5G EC environment. The 5G Edge Computing 302 controller or management system can configure the ACLs to 304 Internet-Draft OSPF Extension for 5G EC Service 306 filter out those applications on routers, especially the 307 routers adjacent to the 5G PSA and the routers to which the 308 Application Servers are directly attached. 310 The proposed solution is for the routers, i.e. A-ER, that 311 have direct links, i.e. the stub links as described in 312 RFC2328, to the Application Servers to collect various 313 measurements about the Servers' running status [5G-EC- 314 Metrics] and advertise the metrics to other routers in 5G 315 EC LDN (Local Data Network). 317 Internet-Draft OSPF Extension for 5G EC Service 319 3.2. IP Layer Metrics to Gauge Application Behavior 321 There are many available network techniques and protocols 322 to optimize forwarding or ensuring QoS for applications, 323 such as DSCP/DiffServ, Traffic Engineered (TE) solutions, 324 Segment Routing, etc. But the reality is that most 325 application servers don't expose their internal logics to 326 network operators. Their communications are generally 327 encrypted. Most of them do not even respond to PING or ICMP 328 messages initiated by routers or network gears. 330 [5G-EC-Metrics] describes the IP Layer Metrics that can 331 gauge the application servers running status and 332 environment: 334 - IP-Layer Metric for App Server Load Measurement: 335 The Load Measurement to an App Server is a weighted 336 combination of the number of packets/bites to the App 337 Server and the number of packets/bytes from the App 338 Server which are collected by the A-ER to which the App 339 Server is directly attached. 340 The A-ER is configured with an ACL that can filter out 341 the packets for the Application Server. 342 - Capacity Index 343 Capacity Index is used to differentiate the running 344 environment of the application server. Some data centers 345 can have hundreds, or thousands, of servers behind an 346 Application Server's App Layer Load Balancer that is 347 reachable from external world. Other data centers can 348 have very small number of servers for the application 349 server. "Capacity Index", which is a numeric number, is 350 used to represent the capacity of the application server 351 in a specific location. 352 - Site preference index: 353 [IPv6-StickyService] describes a scenario that some 354 sites are more preferred for handling an application 355 server than others for flows from a specific UE. 357 Internet-Draft OSPF Extension for 5G EC Service 359 In this document, the term "Application Server Egress 360 Router" [A-ER] is used to describe the last router that an 361 Application Server is attached. For 5G EC environment, the 362 A-ER can be the gateway router to the EC DC where multiple 363 Application servers' instance are hosted. 365 From IP Layer, an Application Server is identified by its 366 IP (ANYCAST) Address. Those IP addresses are called the 367 Application Server IDs throughout this document. 369 3.3. To Equalize among Multiple ANYCAST Locations 371 The main benefit of using ANYCAST is to leverage the 372 network layer information to equalize the traffic among 373 multiple Application Server locations of the same 374 Application, which is identified by its ANYCAST addresses. 376 For 5G Edge Computing environment, the ingress routers to 377 the LDN needs to be notified of the Load Index and Capacity 378 Index of the App Servers at different EC data centers to 379 make the intelligent decision on where to forward the 380 traffic for the application from UEs. 382 [5G-EC-Metrics] describes the algorithms that can be used 383 by the routers directly attached to the 5G PSA to compare 384 the cost to reach the App Servers between the Site-i or 385 Site-j: 387 Load-i * CP-j Pref-j * Delay-i 388 Cost-i=min(w *(----------------) + (1-w) *(------------------)) 389 Load-j * CP-i Pref-i * Delay-j 391 Load-i: Load Index at Site-i, it is the weighted 392 combination of the total packets or/and bytes sent to 393 and received from the Application Server at Site-i 394 during a fixed time period. 396 CP-i: capacity index at the site I, higher value means 397 higher capacity. 399 Delay-i: Network latency measurement (RTT) to the A-ER 400 that has the Application Server attached at the site-i. 402 Internet-Draft OSPF Extension for 5G EC Service 404 Pref-i: Preference index for the site-i, higher value 405 means higher preference. 407 w: Weight for load and site information, which is a 408 value between 0 and 1. If smaller than 0.5, Network 409 latency and the site Preference have more influence; 410 otherwise, Server load and its capacity have more 411 influence. 413 3.4. OSPF Protocol Extension to advertise Load & Capacity 415 Goal of the protocol extension: 416 - Propagate the Load Measurement Index for the attached App 417 Servers to other routers in the LDN. 419 - Propagate the Capacity Index, and 421 - Propagate the Site Preference Index to other routers in 422 the LDN. 424 The OSPF extension takes the approach of TE solution: 426 - Each mini-DC gateway router announces the stub networks 427 of the attached Server addresses with the Load Index Sub- 428 TLV. 429 Only need to advertise the addresses for the applications 430 that needs the network to optimize the forwarding. 431 Therefore, A-ER do not need to advertise all attached 432 subnets. 433 - Load Index and Capacity Index are encoded in a Sub-TLV 434 added to the LSA. 436 3.5. Reason for using IGP Based Solution: 438 For scenario of multiple mini data centers within one AS 439 domain, there are benefits of using IGP approach: 440 - Intermediate routers can forward packets optimally as 441 they can derive the load status for the Application 443 Internet-Draft OSPF Extension for 5G EC Service 445 Servers at different data centers by the IGP protocol, 446 especially: 447 - the path to the expected destination can be more 448 accurate or shorter 449 - Can quickly converge on faulty links and routers 450 - When a mini data center has failures, all the 451 packets in the fly can be optimally forwarded to an 452 App Server in another DC. 453 - Doesn't need ingress node to establish tunnels with 454 egress nodes. 455 - The operations in this approach from users' point of view 456 may be simpler. 458 Drawback of using IGP: 460 - This approach might not suit well to 5G EC LDN operated 461 by multiple ISPs networks. 462 Using BGP, as specified in AppMetaData NLRI Path 463 Attribute [5G-AppMetaData], App Server related metrics 464 can be easily propagated crossing multiple ISPs. 466 3.6. OSPF Extension Using TE Stub Link 468 A new link type in Link TLV of TE LSA is defined for the 469 stub links, in addition to the existing P2P and Multi- 470 Access link types. A Stub Link is the address of the 471 Application Server attached. 473 For a stub link, a Link TLV comprises a Link Type sub-TLV 474 with stub link type, a Link ID sub-TLV with the address of 475 the attached App Server (stub-link), Link Data Sub-TLV and 476 some new sub-TLVs, such as, Load measurement sub-TLV, 477 Capacity sub-TLV and Preference sub-TLV. 479 An example of Link TLV for a stub link is illustrated 480 below: 482 Internet-Draft OSPF Extension for 5G EC Service 484 0 1 2 3 485 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 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | Type = 2 | Length | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | Link type sub-TLV for stub link | 490 ~ ~ 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | Link ID sub-TLV for the AppServer address | 493 ~ ~ 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | Link data sub-TLV for the mask of the AppServer address | 496 ~ ~ 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | Load measurement sub-TLV | 499 ~ ~ 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | Capability sub-TLV | 502 ~ ~ 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | Preference sub-TLV | 505 ~ ~ 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 Figure 2: A new link type in Link TLV of TE LSA 509 The Type value of the Link Type sub-TLV for the stub link: 510 3 (to be assigned by IANA). 512 Note: [RFC3630] has specified: Type=1 for P2P and Type=2 513 used for Multiaccess. 515 The Link Data Sub-TLV for the stub network is defined as: 517 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 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | Type (TBD1) | Length | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | AppServer IP address mask | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 Figure 2: The Link Data Sub-TLV 525 Internet-Draft OSPF Extension for 5G EC Service 527 Two types of Load Measurement Sub-TLVs are specified. One 528 is to carry the aggregated cost Index based on weighted 529 combination of the collected measurements; another one is 530 to carry the raw measurements of packets/bytes to/from the 531 App Server address. The raw measurement is useful when the 532 egress routers cannot be configured with a consistent 533 algorithm to compute the aggregated load index and the raw 534 measurements are needed by a central analytic system. 536 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 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | Type (TBD2) | Length | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | Measurement Period | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | Aggregated Load Index to reach the App Server | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 Figure 3: Aggregated Load Index Sub-TLV 546 Raw Load Measurement sub-TLV has the following format: 548 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 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | Type (TBD3) | Length | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | Measurement Period | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | total number of packets to the AppServer | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | total number of packets from the AppServer | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | total number of bytes to the AppServer | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | total number of bytes from the AppServer | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 Figure 5: Raw Load Measurement Sub-TLV 564 Type =TBD2: Aggregated Load Measurement Index derived 565 from the Weighted combination of bytes/packets sent 566 to/received from the App server: 568 Index=w1*ToPackets+w2*FromPackes+w3*ToBytes+w4*FromBytes 570 Where wi is a value between 0 and 1; w1+ w2+ w3+ w4 = 1; 572 Internet-Draft OSPF Extension for 5G EC Service 574 Type= TBD3: Raw measurements of packets/bytes to/from the 575 App Server address; 577 Measurement Period: A user specified period in seconds, 578 default is 3600 seconds. 580 The Capacity Index sub-TLV has the following format: 582 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 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | Type (TBD3) | Length | 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | Capacity Index | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 Figure 6: Capacity Index Sub-TLV 590 The Preference Index sub-TLV has the following format: 592 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 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | Type (TBD4) | Length | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | Preference Index | 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 Figure 7: Preference Index Sub-TLV 600 Note: "Capacity Index" and "Site preference" can be more 601 stable for each site. If those values are configured to 602 nodes, they might not need to be included in every OSPF 603 LSA. 605 3.7. Aggregated Link Cost Solution 607 Another solution is to reuse the field for link cost of a 608 stub link, if all the egress routers to which the App 609 Servers are attacjed can have one consistent algorithm to 610 compute the Aggregated Cost based on the App Server's Load 611 Index, the Capacity Index and Site Preference Index. 613 For a router with an Application Server directly attached, 614 its router LSA can contain a stub link for the App Server's 615 address [RFC2328]. This solution is using a formula to 617 Internet-Draft OSPF Extension for 5G EC Service 619 calculate the aggregated cost value to the directly 620 attached App Server and assigned the cost value to the 621 Metric field of the stub link in the LSA in RFC2328. 622 The cost to the attached Application Server plays a 623 significant role on where the flows should be routed. See 624 Section 4 for soft anchoring a flow to a specific location 625 when the UEs move. 626 In this solution, the values of the Link ID, Link data and 627 link cost for the stub link are as follows: 629 - The Link ID is the IP address of the Application 630 Server, 631 - The Link Data is the network mask of the 632 Application Server address, 633 - The Link cost is the aggregated cost reach the 634 attached Application Server. 636 In this solution, every router connected to an Application 637 Server MUST use the same formula to compute the cost of the 638 Application Server. 639 No new protocol code point is needed. 641 4. Soft Anchoring of an ANYCAST Flow 642 This section describes a solution that can anchor an 643 application flow from a UE to a specific ANYCAST Server 644 location even when the UE moves from one 5G Site to 645 another. This is called "Sticky Service" in the 3GPP Edge 646 Computing specification. 648 Lets' assume one application "App.net" is instantiated on 649 four servers that are attached to four different routers 650 R1, R2, R3, and R4 respectively. It is desired for packets 651 to the "App.net" from UE-1 to stick with one server, say 652 the App Server attached to R1, even when the UE moves from 653 one 5G site to another. When there is failure at R1 or the 654 Application Server attached to R1, the packets of the flow 655 "App.net" from UE-1 need to be forwarded to the 656 Application Server attached to R2, R3, or R4. 658 We call this kind of sticky service "Soft Anchoring", 659 meaning that anchoring to the site of R1 is preferred, but 661 Internet-Draft OSPF Extension for 5G EC Service 663 other sites can be chosen when the preferred site 664 encounters failure. 666 Here is details of this solution: 668 - Assign a group of ANYCAST addresses to one 669 application. For example, "App.net" is assigned with 670 4 ANYCAST addresses, L1, L2, L3, and L4. L1/L2/L3/L4 671 represents the location preferred ANYCAST addresses. 672 - For the App.net Server attached to a router, the 673 router has four Stub links to the same Server, L1, 674 L2, L3, and L4 respectively. The cost to L1, L2, L3 675 and L4 is assigned differently for different routers. 676 For example, 677 o When attached to R1, the L1 has the lowest cost, 678 say 10, when attached to R2, R3, and R4, the L1 679 can have higher cost, say 30. 680 o ANYCAST L2 has the lowest cost when attached to 681 R2, higher cost when attached to R1, R3, R4 682 respectively. 683 o ANYCAST L3 has the lowest cost when attached to 684 R3, higher cost when attached to R1, R2, R4 685 respectively, and 686 o ANYCAST L4 has the lowest cost when attached to 687 R4, higher cost when attached to R1, R2, R3 688 respectively 689 - When a UE queries for the "App.net" for the first 690 time, the DNS replies the location preferred ANYCAST 691 address, say L1, based on where the query is 692 initiated. 693 - When the UE moves from one 5G site-A to Site-B, UE 694 continues sending packets of the "App.net" to ANYCAST 695 address L1. The routers will continue sending packets 696 to R1 because the total cost for the App.net instance 697 for ANYCAST L1 is lowest at R1. If any failure occurs 698 making R1 not reachable, the packets of the "App.net" 699 from UE-1 will be sent to R2, R3, or R4 (depending on 700 the total cost to reach each of them). 702 Internet-Draft OSPF Extension for 5G EC Service 704 If the Application Server supports the HTTP redirect, more 705 optimal forwarding can be achieved. 707 - When a UE queries for the "App.net" for the first 708 time, the global DNS replies the ANYCAST address G1, 709 which has the same cost regardless where the 710 Application Servers are attached. 711 - When the UE initiates the communication to G1, the 712 packets from the UE will be sent to the Application 713 Server that has the lowest cost, say the Server 714 attached to R1. The Application server is instructed 715 with HTTPs Redirect to respond back a location 716 specific URL, say App.net-Loc1. The client on the UE 717 will query the DNS for App.net-Loc1 and get the 718 response of ANYCAST L1. The subsequent packets from 719 the UE-1 for App.net are sent to L1. 721 5. Manageability Considerations 723 To be added. 725 6. Security Considerations 727 To be added. 729 7. IANA Considerations 731 To be added. 733 8. References 735 8.1. Normative References 737 [RFC2119] Bradner, S., "Key words for use in RFCs to 738 Indicate Requirement Levels", BCP 14, RFC 2119, 739 March 1997. 741 [RFC4364] E. rosen, Y. Rekhter, "BGP/MPLS IP Virtual 742 Private networks (VPNs)", Feb 2006. 744 Internet-Draft OSPF Extension for 5G EC Service 746 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase 747 in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 748 10.17487/RFC8174, May 2017, . 751 [RFC8200] s. Deering R. Hinden, "Internet Protocol, Version 752 6 (IPv6) Specification", July 2017 754 8.2. Informative References 756 [3GPP-EdgeComputing] 3GPP TR 23.748, "3rd Generation 757 Partnership Project; Technical Specification 758 Group Services and System Aspects; Study on 759 enhancement of support for Edge Computing in 5G 760 Core network (5GC)", Release 17 work in progress, 761 Aug 2020. 763 [5G-AppMetaData] L. Dunbar, K. Majumdar, H. Wang, "BGP NLRI 764 App Meta Data for 5G Edge Computing Service", 765 draft-dunbar-idr-5g-edge-compute-app-meta-data- 766 01, work-in-progress, Nov 2020. 768 [5G-EC-Metrics] L. Dunbar, H. Song, J. Kaippallimalil, "IP 769 Layer Metrics for 5G Edge Computing Service", 770 draft-dunbar-ippm-5g-edge-compute-ip-layer- 771 metrics-01, work-in-progress, Nov 2020. 773 [5G-StickyService] L. Dunbar, J. Kaippallimalil, "IPv6 774 Solution for 5G Edge Computing Sticky Service", 775 draft-dunbar-6man-5g-ec-sticky-service-00, work- 776 in-progress, Oct 2020. 778 [RFC5521] P. Mohapatra, E. Rosen, "The BGP Encapsulation 779 Subsequent Address Family Identifier (SAFI) and 780 the BGP Tunnel Encapsulation Attribute", April 781 2009. 783 [BGP-SDWAN-Port] L. Dunbar, H. Wang, W. Hao, "BGP Extension 784 for SDWAN Overlay Networks", draft-dunbar-idr- 785 bgp-sdwan-overlay-ext-03, work-in-progress, Nov 786 2018. 788 Internet-Draft OSPF Extension for 5G EC Service 790 [SDWAN-EDGE-Discovery] L. Dunbar, S. Hares, R. Raszuk, K. 791 Majumdar, "BGP UPDATE for SDWAN Edge Discovery", 792 draft-dunbar-idr-sdwan-edge-discovery-00, work- 793 in-progress, July 2020. 795 [Tunnel-Encap] E. Rosen, et al "The BGP Tunnel 796 Encapsulation Attribute", draft-ietf-idr-tunnel- 797 encaps-10, Aug 2018. 799 9. Acknowledgments 801 Acknowledgements to Donald Eastlake for their review and 802 contributions. 804 This document was prepared using 2-Word-v2.0.template.dot. 806 Authors' Addresses 808 Linda Dunbar 809 Futurewei 810 Email: ldunbar@futurewei.com 812 HuaiMo Chen 813 Futurewei 814 Email: huaimo.chen@futurewei.com