idnits 2.17.1 draft-dunbar-lsr-5g-edge-compute-07.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 (January 25, 2022) is 821 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: 'LSR-FlexAlgo' is mentioned on line 133, but not defined == Missing Reference: 'A-ER' is mentioned on line 200, but not defined == Missing Reference: 'RFC8174' is mentioned on line 257, but not defined == Missing Reference: 'RFC8362' is mentioned on line 340, but not defined == Missing Reference: 'RFC5305' is mentioned on line 357, but not defined == Missing Reference: 'RFC5308' is mentioned on line 358, but not defined == Missing Reference: 'RFC5120' is mentioned on line 364, but not defined == Missing Reference: 'RFC8920' is mentioned on line 396, but not defined ** Obsolete undefined reference: RFC 8920 (Obsoleted by RFC 9492) == Missing Reference: '5GC' is mentioned on line 497, but not defined == Unused Reference: 'RFC2328' is defined on line 432, but no explicit reference was found in the text == Unused Reference: 'RFC5521' is defined on line 434, but no explicit reference was found in the text == Unused Reference: 'RFC8200' is defined on line 442, but no explicit reference was found in the text == Unused Reference: 'RFC8326' is defined on line 447, but no explicit reference was found in the text == Unused Reference: 'RFC9012' is defined on line 451, but no explicit reference was found in the text == Unused Reference: '3GPP-EdgeComputing' is defined on line 456, but no explicit reference was found in the text == Unused Reference: '5G-StickyService' is defined on line 463, but no explicit reference was found in the text == Unused Reference: 'LSR-Flex-Algo' is defined on line 473, but no explicit reference was found in the text == Unused Reference: 'LSR-Flex-Algo-BW' is defined on line 476, but no explicit reference was found in the text == Unused Reference: 'SDWAN-EDGE-Discovery' is defined on line 480, but no explicit reference was found in the text ** Downref: Normative reference to an Proposed Standard RFC: RFC 5521 ** Downref: Normative reference to an Proposed Standard RFC: RFC 7684 ** Downref: Normative reference to an Proposed Standard RFC: RFC 8362 (ref. 'RFC8326') ** Downref: Normative reference to an Proposed Standard RFC: RFC 9012 -- No information found for draft-dunbar-6man-5g-ec-sticky-service - is the name correct? == Outdated reference: A later version (-14) exists of draft-dunbar-idr-5g-edge-compute-app-meta-data-03 == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-17 == Outdated reference: A later version (-10) exists of draft-ietf-lsr-flex-algo-bw-con-01 == Outdated reference: A later version (-04) exists of draft-dunbar-idr-sdwan-edge-discovery-00 Summary: 5 errors (**), 0 flaws (~~), 25 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: July 25, 2022 Aijun Wang 5 China Telecom 6 January 25, 2022 8 IGP Extension for 5G Edge Computing Service 9 draft-dunbar-lsr-5g-edge-compute-07 11 Abstract 12 This draft describes using additional site capacity and 13 preference related metrics to influence the SPF and using 14 Flexible Algorithms to indicate the topologies those 15 metrics are applied. The purpose is to differentiate 16 multiple paths with similar routing distance to one 17 destination in 5G Local Data Network (LDN)to achieve 18 optimal performance. 20 Status of this Memo 21 This Internet-Draft is submitted in full conformance with 22 the provisions of BCP 78 and BCP 79. 24 This Internet-Draft is submitted in full conformance with 25 the provisions of BCP 78 and BCP 79. This document may not 26 be modified, and derivative works of it may not be created, 27 except to publish it as an RFC and to translate it into 28 languages other than English. 30 Internet-Drafts are working documents of the Internet 31 Engineering Task Force (IETF), its areas, and its working 32 groups. Note that other groups may also distribute working 33 documents as Internet-Drafts. 35 Internet-Drafts are draft documents valid for a maximum of 36 six months and may be updated, replaced, or obsoleted by 37 other documents at any time. It is inappropriate to use 38 Internet-Drafts as reference material or to cite them other 39 than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt 44 Internet-Draft LSR Extension for 5G EC Service 46 The list of Internet-Draft Shadow Directories can be 47 accessed at http://www.ietf.org/shadow.html 49 This Internet-Draft will expire on April 7, 2021. 51 Copyright Notice 53 Copyright (c) 2022 IETF Trust and the persons identified as 54 the document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's 57 Legal Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the 59 date of publication of this document. Please review these 60 documents carefully, as they describe your rights and 61 restrictions with respect to this document. Code Components 62 extracted from this document must include Simplified BSD 63 License text as described in Section 4.e of the Trust Legal 64 Provisions and are provided without warranty as described 65 in the Simplified BSD License. 67 Table of Contents 69 1. Introduction........................................... 3 70 1.1. Unbalanced Distribution due to UE Mobility........ 4 71 1.2. ANYCAST in 5G EC Environment...................... 4 72 1.3. Scope of the Document............................. 4 74 2. Conventions used in this document...................... 5 76 3. Solution Overview...................................... 6 78 4. New Flags added to FAD Flags Sub-TLV................... 7 80 5. Minimum Interval for Aggregated Site Cost Advertisement 7 82 6. Aggregate Site Cost Advertisement in OSPF.............. 8 84 7. "Site-Cost" Advertisement in IS-IS..................... 8 86 Internet-Draft LSR Extension for 5G EC Service 88 8. Alternative method for Distributing Aggregated Cost.... 9 90 9. Manageability Considerations........................... 9 92 10. Security Considerations.............................. 10 94 11. IANA Considerations.................................. 10 96 12. References........................................... 10 97 12.1. Normative References............................ 10 98 12.2. Informative References.......................... 11 100 13. Appendix A:5G Edge Computing Background.............. 12 101 13.1. Metrics to change traffic flow patterns......... 13 102 13.2. Reason for using IGP Based Solution............. 14 103 13.3. Flow Affinity to an ANYCAST server.............. 15 105 14. Acknowledgments...................................... 15 107 1. Introduction 109 In 5G Edge Computing (EC) environment, it is common for an 110 application that needs low latency to be instantiated on 111 multiple servers close in proximity to UEs (User 112 Equipment). Those applications instances can be behind one 113 or multiple application-layer load balancers. When they 114 have relatively short flows that can go to any instance, 115 having the cluster of them at different locations share the 116 same IP address can minimize the impact to DNS and achieve 117 optimal forwarding that leverages network conditions. E.g., 118 Kubernetes for data center networking uses one single 119 Virtual IP address for a cluster of instances of 120 microservices so that the network can forward via multiple 121 paths towards one single destination. 123 This draft describes using additional site costs to 124 influence the shortest path computation for a specific set 125 of prefixes. The site costs can be a group of metrics, or 126 one aggregated cost computed based on a configured 127 algorithm. As there are a small number of egress routers 128 having those prefixes (or destinations) that need to 129 incorporate site costs in SPF computation, Flexible 131 Internet-Draft LSR Extension for 5G EC Service 133 Algorithms [LSR-FlexAlgo] is used to indicate the need for 134 the site costs to be considered for the specific 135 topologies. Flexible algorithms provide mechanisms for 136 topologies to use different IGP path algorithms. 138 1.1. Unbalanced Distribution due to UE Mobility 140 UEs' frequent moving from one 5G site to another can make 141 it difficult to plan where the App Servers should be 142 hosted. When a group of App servers at one location, which 143 can be behind an application-layer load balancer, are 144 heavily utilized, the instances for the same application at 145 another location can be under-utilized. The difference in 146 the routing distance to reach multiple sites where the 147 application instances are instantiated might be relatively 148 small in 5G LDN environment. The site capacity and 149 preferences can be more significant than the routing 150 distance from the application's latency and performance 151 perspective. 153 Since the condition can change in days or weeks, it is 154 difficult for the application controller to anticipate the 155 moving and adjusting relocation of application instances. 157 1.2. ANYCAST in 5G EC Environment 159 ANYCAST is assigning the same IP address for multiple 160 instances at different locations. Using ANYCAST can 161 eliminate the single point of failure and bottleneck at 162 load balancers or DNS. Another benefit is removing the 163 dependency on how UEs resolve IP addresses for their 164 applications. Some UEs (or clients) might use stale cached 165 IP addresses for an extended period. 167 But having the same IP address at multiple locations of the 168 5G Edge Computing environment can be problematic because 169 all those locations can be close in proximity. There might 170 be a tiny difference in the routing distance to reach an 171 application instance attached to a different edge router. 173 1.3. Scope of the Document 175 The draft is for scenarios where applications or micro 176 services are instantiated at multiple locations behind one 177 or multiple application layer load balancers. They have 178 relative short flows that can go to any instances. 180 Internet-Draft LSR Extension for 5G EC Service 182 Under this scenario, multiple instances for the same type 183 of services can be assigned with the same IP address, so 184 that network condition can be utilized to achieve optimal 185 forwarding. 187 From IP network perspective, application layer load 188 balancers and app servers all appear as IP addresses. 189 Throughout this document, the term "app server" can 190 represent the load balancer in front of a cluster of app 191 server instances, app server instances, or app server. 193 Note: for the ease of description, the EC (Edge Computing) 194 server, Application server, App server are used 195 interchangeably throughout this document. 197 2. Conventions used in this document 199 A-ER: Egress Edge Router to an Application Server, 200 [A-ER] is used to describe the last router that 201 the Application Server is attached. For 5G EC 202 environment, the A-ER can be the gateway router 203 to a (mini) Edge Computing Data Center. 205 Application Server: An application server is a physical or 206 virtual server that hosts the software system 207 for the application. 209 Application Server Location: Represent a cluster of servers 210 at one location serving the same Application. 211 One application may have a Layer 7 Load 212 balancer, whose address(es) are reachable from 213 an external IP network, in front of a set of 214 application servers. From IP network 215 perspective, this whole group of servers is 216 considered as the Application server at the 217 location. 219 Edge Application Server: used interchangeably with 220 Application Server throughout this document. 222 EC: Edge Computing 224 Internet-Draft LSR Extension for 5G EC Service 226 Edge Hosting Environment: An environment providing the 227 support required for Edge Application Server's 228 execution. 230 NOTE: The above terminologies are the same as 231 those used in 3GPP TR 23.758 233 Edge DC: Edge Data Center, which provides the Edge 234 Computing Hosting Environment. It might be co- 235 located with 5G Base Station and not only host 236 5G core functions, but also host frequently 237 used Edge server instances. 239 gNB next generation Node B 241 LDN: Local Data Network 243 PSA: PDU Session Anchor (UPF) 245 SSC: Session and Service Continuity 247 UE: User Equipment 249 UPF: User Plane Function 251 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 252 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 253 RECOMMENDED", "MAY", and "OPTIONAL" in this document are to 254 be interpreted as described in BCP 14 [RFC2119] [RFC8174] 255 when, and only when, they appear in all capitals, as shown 256 here. 258 3. Solution Overview 260 The proposed solution is for the egress edge router (A-ER) 261 with the application instances directly attached to 263 - advertise the aggregated site cost via IP prefix 264 reachability TLV associated with the (anycast) prefix. 265 [note: the aggregated cost in this version of the 266 draft is one value. Some deployment scenarios could 267 have a set of values as the site cost.] 269 Internet-Draft LSR Extension for 5G EC Service 271 - use a Flag in the Flexible Algorithm TLV to indicate 272 that the aggregated site cost needs to influence the 273 SPF to reach the Prefix. 275 The aggregated site cost associated with a prefix (i.e., 276 ANYCAST prefix) is computed based on the Capacity Index, 277 the Preference Index, and other constraints by a consistent 278 algorithm across all A-ERs. The capacity and preference 279 indexes are configured to the egress routers to which the 280 prefix is attached. 282 The solution assumes that the 5G EC controller or 283 management system is aware of the ANYCAST addresses that 284 need optimized forwarding. Only the addresses that match 285 with the ACLs configured by the 5G EC controller will have 286 their aggregated site cost advertised. 288 4. New Flags added to FAD Flags Sub-TLV 290 A New flag (P-flag) is added to indicate that the 291 aggregated site cost needs to be considered for the SPF to 292 the prefix for a specific topology. One specific topology 293 can consist of a subset of routers within one single IGP 294 domain. 296 Flags: 298 0 1 2 3 4 5 6 7... 299 +-+-+-+-+-+-+-+-+... 300 |M|P| | ... 301 +-+-+-+-+-+-+-+-+... 303 The detailed algorithm of integrating the routing distance 304 and the aggregated site cost for the shortest path is out 305 of the scope of this document. 307 5. Minimum Interval for Aggregated Site Cost Advertisement 309 The aggregated site cost associated with a prefix (e.g., an 310 ANYCAST prefix) can be a value or a set of values 311 configured on the router to which the prefix is attached. 312 The aggregated site cost can be computed based on an 313 algorithm configured on router for specific prefixes. The 315 Internet-Draft LSR Extension for 5G EC Service 317 detailed algorithm of computing the aggregated site cost is 318 out of the scope of document. 320 As the cost change can impact the path computation, there 321 must be a Minimum Interval for Metrics Change Advertisement 322 which is configured on the routers to avoid route 323 oscillations. Default is 30s. 325 The aggregated site cost change rate is comparable with the 326 rate of adding or removing application instances at 327 locations to adapt to the workload distribution changes. 328 The rate of change could be in days or weeks. On rare 329 occasions, there might need rate changes in hours. 331 6. Aggregate Site Cost Advertisement in OSPF 333 - IPv4: OSPFv2 334 A new Aggregated Cost Sub-TLV needs to be added to 335 OSPFv2 Extended Prefix TLV [RFC7684] 337 - IPv6: OSPFv3 338 A new sub-TLV can be appended to the E-Intra-Area- 339 Prefix-LSA, E-Inter-Area-Prefix-LSA, E-AS-External- 340 LSA, and E-Type-7-LSA [RFC8362] to carry the 341 Aggregated Cost. 343 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 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 |AggCostSubTLV | Length | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | AggCost Attribute-1 to the Prefix | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 ~ ~ 350 | AggCost Attribute-i to the Prefix | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 Figure 1: Aggregated cost Advertisement in OSPF 354 7. "Site-Cost" Advertisement in IS-IS 356 Aggregated Cost can be appended as subTLV to the Extended 357 IP Reachability TLV 135 for IPv4 [RFC5305] and 236 for IPv6 358 [RFC5308]. 360 Internet-Draft LSR Extension for 5G EC Service 362 For Multi-Topology with non-zero IDs, the Aggregated Cost 363 SubTLV can be carried by Multi-topology TLV 235 for IPv4 364 and 237 for IPv6 [RFC5120]. 366 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 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 |AggCostSubTLV | Length | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | AggCost to the App Server | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 ~ ~ 373 | AggCost Attribute-i to the Prefix | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 Figure 2: Aggregated cost Advertisement in IS-IS 378 8. Alternative method for Distributing Aggregated Cost 380 Section 6 and Section 7 demonstrate different ways for 381 OSPFv2, OSPFv3, and ISIS to propagate the aggregated cost. 382 It would be better if the aggregated cost could be 383 advertised the same way, regardless of OSPFv2, OSPFv3, or 384 ISIS. 386 Draft [draft-wang-lsr-stub-link-attributes] introduces the 387 Stub-Link TLV for OSPFv2/v3 and ISIS protocol respectively. 388 Considering the interfaces on an edge router that connects 389 to the EC servers are normally configured as passive 390 interfaces, these IP-layer App-metrics can also be 391 advertised as the attributes of the passive/stub link. The 392 associated prefixes can then be advertised in the "Stub- 393 Link TLV" that is defined in [draft-wang-lsr-stub-link- 394 attributes]. All the associated prefixes share the same 395 characteristic of the link. Other link related sub-TLVs 396 defined in [RFC8920] can also be attached and applied to 397 the calculation of path to the associated prefixes." 399 The aggregated site cost metric can also be carried by the 400 Stub-Link TLV defined in [draft-wang-lsr-stub-link- 401 attributes] 403 9. Manageability Considerations 405 To be added. 407 Internet-Draft LSR Extension for 5G EC Service 409 10. Security Considerations 411 To be added. 413 11. IANA Considerations 415 The following Sub-TLV types need to be added by IANA to 416 FlexAlgo. 418 - AggCostSubTLV Type for ISIS, OSPF (TBD1): IPv4 or IPv6 420 P-flag added to FAD Flags Sub-TLV to indicate that the 421 Site-Cost Metrics is included in deriving Constrained IGP 422 path to the prefix. 424 12. References 426 12.1. Normative References 428 [RFC2119] Bradner, S., "Key words for use in RFCs to 429 Indicate Requirement Levels", BCP 14, RFC 2119, 430 March 1997. 432 [RFC2328] J. Moy, "OSPF Version 2", RFC 2328, April 1998. 434 [RFC5521] P. Mohapatra, E. Rosen, "The BGP Encapsulation 435 Subsequent Address Family Identifier (SAFI) and 436 the BGP Tunnel Encapsulation Attribute", April 437 2009. 439 [RFC7684] P. Psenak, et al, "OSPFv2 Prefix/Link Attribute 440 Advertisement", RFC 7684, Nov. 2015. 442 [RFC8200] S. Deering R. Hinden, "Internet Protocol, Version 443 6 (IPv6) Specification", July 2017. 445 Internet-Draft LSR Extension for 5G EC Service 447 [RFC8326] A. Lindem, et al, "OSPFv3 Link State 448 advertisement (LSA0 Extensibility", RFC 8362, 449 April 2018. 451 [RFC9012] E. Rosen, et al "The BGP Tunnel Encapsulation 452 Attribute", April 2021. 454 12.2. Informative References 456 [3GPP-EdgeComputing] 3GPP TR 23.748, "3rd Generation 457 Partnership Project; Technical Specification 458 Group Services and System Aspects; Study on 459 enhancement of support for Edge Computing in 5G 460 Core network (5GC)", Release 17 work in progress, 461 Aug 2020. 463 [5G-StickyService] L. Dunbar, J. Kaippallimalil, "IPv6 464 Solution for 5G Edge Computing Sticky Service", 465 draft-dunbar-6man-5g-ec-sticky-service-00, work- 466 in-progress, Oct 2020. 468 [BGP-5G-AppMetaData] L. Dunbar, K. Majumdar, H. Wang, "BGP 469 App Metadata for 5G Edge Computing Service", 470 draft-dunbar-idr-5g-edge-compute-app-meta-data- 471 03, work-in-progress, Sept 2020. 473 [LSR-Flex-Algo] P. Psenak, et al, "IGP Flexible Algorithm", 474 draft-ietf-lsr-flex-algo-17, July 2021. 476 [LSR-Flex-Algo-BW] S. Hegde, et al, "Flexible Algorithms: 477 Bandwidth, Delay, Metrics and Constraints", 478 draft-ietf-lsr-flex-algo-bw-con-01, July 2021. 480 [SDWAN-EDGE-Discovery] L. Dunbar, S. Hares, R. Raszuk, K. 481 Majumdar, "BGP UPDATE for SDWAN Edge Discovery", 482 draft-dunbar-idr-sdwan-edge-discovery-00, work- 483 in-progress, July 2020. 485 Internet-Draft LSR Extension for 5G EC Service 487 13. Appendix A:5G Edge Computing Background 489 The network connecting the 5G EC servers with the 5G Base 490 stations consists of a small number of dedicated routers 491 that form the 5G Local Data Network (LDN) to enhance the 492 performance of the EC services. 494 When a User Equipment (UE) initiates application packets 495 using the destination address from a DNS reply or its 496 cache, the packets from the UE are carried in a PDU session 497 through 5G Core [5GC] to the 5G UPF-PSA (User Plan Function 498 - PDU Session Anchor). The UPF-PSA decapsulates the 5G GTP 499 outer header, performs NAT sometimes, before handing the 500 packets from the UEs to the adjacent router, also known as 501 the ingress router to the EC LDN, which is responsible for 502 forwarding the packets to the intended destinations. 504 When the UE moves out of coverage of its current gNB (next- 505 generation Node B) (gNB1), the handover procedure is 506 initiated, which includes the 5G SMF (Session Management 507 Function) selecting a new UPF-PSA [3GPP TS 23.501 and TS 508 23.502]. When the handover process is complete, the IP 509 point of attachment is to the new UPF-PSA. The UE's IP 510 address stays the same unless moving to different operator 511 domain. 5GC may maintain a path from the old UPF to the new 512 UPF for a short time for SSC [Session and Service 513 Continuity] mode 3 to make the handover process more 514 seamless. 516 Internet-Draft LSR Extension for 5G EC Service 518 +--+ 519 |UE|---\+---------+ +------------------+ 520 +--+ | 5G | +---------+ | S1: aa08::4450 | 521 +--+ | Site +--++---+ +----+ | 522 |UE|----| A |PSA| Ra| | R1 | S2: aa08::4460 | 523 +--+ | +---+---+ +----+ | 524 +---+ | | | | | S3: aa08::4470 | 525 |UE1|---/+---------+ | | +------------------+ 526 +---+ |IP Network | L-DN1 527 |(3GPP N6) | 528 | | | +------------------+ 529 | UE1 | | | S1: aa08::4450 | 530 | moves to | +----+ | 531 | Site B | | R3 | S2: aa08::4460 | 532 v | +----+ | 533 | | | S3: aa08::4470 | 534 | | +------------------+ 535 | | L-DN3 536 +--+ | | 537 |UE|---\+---------+ | | +------------------+ 538 +--+ | 5G | | | | S1: aa08::4450 | 539 +--+ | Site +--++-+--+ +----+ | 540 |UE|----| B |PSA| Rb | | R2 | S2: aa08::4460 | 541 +--+ | +--++----+ +----+ | 542 +--+ | | +-----------+ | S3: aa08::4470 | 543 |UE|---/+---------+ +------------------+ 544 +--+ L-DN2 545 Figure 10: App Servers in different edge DCs 547 13.1. Metrics to change traffic flow patterns 549 When UEs pattern changes, the Application controller can 550 instantiate more instances at certain locations to 551 accommodate higher demand. 553 However, network layer can offer a simpler solution. By 554 adjusting the site cost for the prefix at specific egress 555 routers, IGP distribution of those site cost plus the flex 556 algorithm can increase (or decrease) flows for the specific 557 prefixes towards the certain locations. 559 Internet-Draft LSR Extension for 5G EC Service 561 - Capacity Index: 562 a numeric number, configured on all A-ERs in the 563 domain consistently, is used to represent the capacity 564 of an EC server attached to an A-ER. The IP addresses 565 exposed to the A-ER can be the App Layer Load 566 balancers that have many instances attached. At other 567 sites, the IP address exposed is the server itself. 568 - Site preference index: 569 Is used to describe some sites are more preferred than 570 others. For example, a site with less leasing cost has 571 a higher preference value. Note: the preference value 572 is configured on all A-ERs in the domain consistently 573 by the Domain Controller. 575 13.2. Reason for using IGP Based Solution 577 IGP provides stable underlay reachability within the IGP 578 coverage area (including hierarchy). Even through IGP has 579 been extended to carry underlay TE or SR information, IGP 580 has been within the core transport. IGP traditionally 581 doesn't carry any service information. 582 In the networks where traditional IGP has been deployed, 583 different addresses are for different end points. But for 584 the 5G edge computing environment, one entity can have 585 multiple addresses and one prefix "A" can be attached to 586 multiple routers. E.g., one entity EAS-1 can have 3 587 addresses (E1/E2/E3). By adjusting the site cost for E1 on 588 the E1 attached router (R1) for the Topology-Red, traffic 589 destined towards E1 from the routers in the Topology-Red 590 can be led to (or away from) to the R1. While the traffic 591 destined towards E2/E3 stay the same. 592 Here are some benefits of using IGP to propagate the IP 593 Layer App-Metrics: 594 - Intermediate routers can utilize the aggregated cost to 595 reach the same prefix attached to different egress edge 596 nodes, especially: 597 - The path to the optimal egress edge node can be 598 more accurate or shorter. 600 Internet-Draft LSR Extension for 5G EC Service 602 - Convergence is shorter when there is any failure 603 along the way towards the optimal egress for the 604 prefix. 605 - When there is any failure at the intended instance 606 of the prefix, all the packets in transit can be 607 optimally forwarded to another instance of the same 608 prefix attached to a different egress router. 609 - Doesn't need the ingress nodes to establish tunnels with 610 egress edge nodes. 612 There are limitations of using IGP too, such as: 614 - The IGP approach might not suit well to 5G EC LDN 615 operated by multiple ISPs. 616 For LDN operated by multiple ISPs, BGP should be used. 617 [BGP-5G-AppMetaData] describes the BGP UPDATE message to 618 propagate IP Layer App-Metrics crossing multiple ISPs. 620 13.3. Flow Affinity to an ANYCAST server 622 When multiple servers with the same IP address (ANYCAST) 623 are attached to different A-ERs, Flow Affinity means 624 routers sending the packets of the same flow to the same A- 625 ER even if the cost towards the A-ER is no longer optimal. 627 Many commercial routers support some forms of flow affinity 628 to ensure packets belonging to one flow be forwarded along 629 the same path. 631 Editor's note: for IPv6 traffic, Flow Affinity can be 632 achieved by routers forwarding the packets with the same 633 Flow Label extracted from the IPv6 Header along the same 634 path. 636 14. Acknowledgments 638 Acknowledgements to Peter Psenak, Les Ginsberg, Robert 639 Raszuk, Acee Lindem, Shraddha Hegde, Tony Li, Gyan Mishra, 640 Jeff Tantsura, and Donald Eastlake for their review and 641 suggestions. 643 This document was prepared using 2-Word-v2.0.template.dot. 645 Internet-Draft LSR Extension for 5G EC Service 647 Authors' Addresses 649 Linda Dunbar 650 Futurewei 651 Email: ldunbar@futurewei.com 653 Huaimo Chen 654 Futurewei 655 Email: huaimo.chen@futurewei.com 657 Aijun Wang 658 China Telecom 659 Email: wangaj3@chinatelecom.cn