idnits 2.17.1 draft-dunbar-lsr-5g-edge-compute-05.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 18, 2022) is 830 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 335, but not defined == Missing Reference: 'RFC5305' is mentioned on line 352, but not defined == Missing Reference: 'RFC5308' is mentioned on line 353, but not defined == Missing Reference: 'RFC5120' is mentioned on line 357, but not defined == Missing Reference: 'RFC8920' is mentioned on line 391, but not defined ** Obsolete undefined reference: RFC 8920 (Obsoleted by RFC 9492) == Missing Reference: '5GC' is mentioned on line 491, but not defined == Unused Reference: 'RFC2328' is defined on line 426, but no explicit reference was found in the text == Unused Reference: 'RFC5521' is defined on line 428, but no explicit reference was found in the text == Unused Reference: 'RFC8200' is defined on line 436, but no explicit reference was found in the text == Unused Reference: 'RFC8326' is defined on line 439, but no explicit reference was found in the text == Unused Reference: 'RFC9012' is defined on line 443, but no explicit reference was found in the text == Unused Reference: '3GPP-EdgeComputing' is defined on line 450, but no explicit reference was found in the text == Unused Reference: '5G-StickyService' is defined on line 457, but no explicit reference was found in the text == Unused Reference: 'LSR-Flex-Algo' is defined on line 467, but no explicit reference was found in the text == Unused Reference: 'LSR-Flex-Algo-BW' is defined on line 470, but no explicit reference was found in the text == Unused Reference: 'SDWAN-EDGE-Discovery' is defined on line 474, 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 18, 2022 Aijun Wang 5 China Telecom 6 January 18, 2022 8 IGP Extension for 5G Edge Computing Service 9 draft-dunbar-lsr-5g-edge-compute-05 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............................... 9 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 is added to indicate a constrained SPF compute 291 method is needed for the prefix. 293 Flags: 295 0 1 2 3 4 5 6 7... 296 +-+-+-+-+-+-+-+-+... 297 |M|P| | ... 298 +-+-+-+-+-+-+-+-+... 300 P-flag: Site-Cost Metrics is included in deriving 301 Constrained IGP path to the prefix. 303 5. Minimum Interval for Aggregated Site Cost Advertisement 305 The aggregated site cost associated with a prefix (i.e., 306 ANYCAST prefix) can be a value configured on the router to 307 which the prefix is attached. The aggregated site cost can 308 be computed based on an algorithm configured on router for 309 specific prefixes. The detailed algorithm of computing the 310 aggregated site cost is out of the scope of document. 312 As the cost change can impact the path computation, there 313 is a Minimum Interval for Metrics Change Advertisement 315 Internet-Draft LSR Extension for 5G EC Service 317 which is configured on the routers to avoid route 318 oscillations. Default is 30s. 320 The aggregated site cost change rate is comparable with the 321 rate of adding or removing application instances at 322 locations to adapt to the workload distribution changes. 323 The rate of change could be in days or weeks. On rare 324 occasions, there might need rate changes in hours. 326 6. Aggregate Site Cost Advertisement in OSPF 328 - IPv4: OSPFv2 329 A new Aggregated Cost Sub-TLV needs to be added to 330 OSPFv2 Extended Prefix TLV [RFC7684] 332 - IPv6: OSPFv3 333 A new sub-TLV can be appended to the E-Intra-Area- 334 Prefix-LSA, E-Inter-Area-Prefix-LSA, E-AS-External- 335 LSA, and E-Type-7-LSA [RFC8362] to carry the 336 Aggregated Cost. 338 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 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 |AggCostSubTLV | Length | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | AggCost Attribute-1 to the Prefix | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 ~ ~ 345 | AggCost Attribute-i to the Prefix | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 Figure 1: Aggregated cost Advertisement in IS-IS 349 7. "Site-Cost" Advertisement in IS-IS 351 Aggregated Cost can be appended as subTLV to the Extended 352 IP Reachability TLV 135 for IPv4 [RFC5305] and 236 for IPv6 353 [RFC5308]. 355 For Multi-Topology with non-zero IDs, the Aggregated Cost 356 SubTLV can be carried by Multi-topology TLV 235 for IPv4 357 and 237 for IPv6 [RFC5120]. 359 Internet-Draft LSR Extension for 5G EC Service 361 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 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 |AggCostSubTLV | Length | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | AggCost Attribute-1 to the App Server | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 ~ ~ 368 | AggCost Attribute-i to the Prefix | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 Figure 2: Aggregated cost Advertisement in IS-IS 373 8. Alternative method for Distributing Aggregated Cost 375 Section 6 and Section 7 demonstrate different ways for 376 OSPFv2, OSPFv3, and ISIS to propagate the aggregated cost. 377 It would be better if the aggregated cost could be 378 advertised the same way, regardless of OSPFv2, OSPFv3, or 379 ISIS. 381 Draft [draft-wang-lsr-stub-link-attributes] introduces the 382 Stub-Link TLV for OSPFv2/v3 and ISIS protocol respectively. 383 Considering the interfaces on an edge router that connects 384 to the EC servers are normally configured as passive 385 interfaces, these IP-layer App-metrics can also be 386 advertised as the attributes of the passive/stub link. The 387 associated prefixes can then be advertised in the "Stub- 388 Link TLV" that is defined in [draft-wang-lsr-stub-link- 389 attributes]. All the associated prefixes share the same 390 characteristic of the link. Other link related sub-TLVs 391 defined in [RFC8920] can also be attached and applied to 392 the calculation of path to the associated prefixes." 394 Section 6 for the advertisement of AppMetaData Metric can 395 also utilize the Stub-Link TLV that defined in [draft-wang- 396 lsr-stub-link-attributes] 398 9. Manageability Considerations 400 To be added. 402 10. Security Considerations 403 Internet-Draft LSR Extension for 5G EC Service 405 To be added. 407 11. IANA Considerations 409 The following Sub-TLV types need to be added by IANA to 410 FlexAlgo. 412 - AggCostSubTLV Type for ISIS, OSPF (TBD1): IPv4 or IPv6 414 P-flag added to FAD Flags Sub-TLV to indicate that the 415 Site-Cost Metrics is included in deriving Constrained IGP 416 path to the prefix. 418 12. References 420 12.1. Normative References 422 [RFC2119] Bradner, S., "Key words for use in RFCs to 423 Indicate Requirement Levels", BCP 14, RFC 2119, 424 March 1997. 426 [RFC2328] J. Moy, "OSPF Version 2", RFC 2328, April 1998. 428 [RFC5521] P. Mohapatra, E. Rosen, "The BGP Encapsulation 429 Subsequent Address Family Identifier (SAFI) and 430 the BGP Tunnel Encapsulation Attribute", April 431 2009. 433 [RFC7684] P. Psenak, et al, "OSPFv2 Prefix/Link Attribute 434 Advertisement", RFC 7684, Nov. 2015. 436 [RFC8200] S. Deering R. Hinden, "Internet Protocol, Version 437 6 (IPv6) Specification", July 2017. 439 [RFC8326] A. Lindem, et al, "OSPFv3 Link State 440 advertisement (LSA0 Extensibility", RFC 8362, 441 April 2018. 443 [RFC9012] E. Rosen, et al "The BGP Tunnel Encapsulation 444 Attribute", April 2021. 446 Internet-Draft LSR Extension for 5G EC Service 448 12.2. Informative References 450 [3GPP-EdgeComputing] 3GPP TR 23.748, "3rd Generation 451 Partnership Project; Technical Specification 452 Group Services and System Aspects; Study on 453 enhancement of support for Edge Computing in 5G 454 Core network (5GC)", Release 17 work in progress, 455 Aug 2020. 457 [5G-StickyService] L. Dunbar, J. Kaippallimalil, "IPv6 458 Solution for 5G Edge Computing Sticky Service", 459 draft-dunbar-6man-5g-ec-sticky-service-00, work- 460 in-progress, Oct 2020. 462 [BGP-5G-AppMetaData] L. Dunbar, K. Majumdar, H. Wang, "BGP 463 App Metadata for 5G Edge Computing Service", 464 draft-dunbar-idr-5g-edge-compute-app-meta-data- 465 03, work-in-progress, Sept 2020. 467 [LSR-Flex-Algo] P. Psenak, et al, "IGP Flexible Algorithm", 468 draft-ietf-lsr-flex-algo-17, July 2021. 470 [LSR-Flex-Algo-BW] S. Hegde, et al, "Flexible Algorithms: 471 Bandwidth, Delay, Metrics and Constraints", 472 draft-ietf-lsr-flex-algo-bw-con-01, July 2021. 474 [SDWAN-EDGE-Discovery] L. Dunbar, S. Hares, R. Raszuk, K. 475 Majumdar, "BGP UPDATE for SDWAN Edge Discovery", 476 draft-dunbar-idr-sdwan-edge-discovery-00, work- 477 in-progress, July 2020. 479 Internet-Draft LSR Extension for 5G EC Service 481 13. Appendix A:5G Edge Computing Background 483 The network connecting the 5G EC servers with the 5G Base 484 stations consists of a small number of dedicated routers 485 that form the 5G Local Data Network (LDN) to enhance the 486 performance of the EC services. 488 When a User Equipment (UE) initiates application packets 489 using the destination address from a DNS reply or its 490 cache, the packets from the UE are carried in a PDU session 491 through 5G Core [5GC] to the 5G UPF-PSA (User Plan Function 492 - PDU Session Anchor). The UPF-PSA decapsulates the 5G GTP 493 outer header, performs NAT sometimes, before handing the 494 packets from the UEs to the adjacent router, also known as 495 the ingress router to the EC LDN, which is responsible for 496 forwarding the packets to the intended destinations. 498 When the UE moves out of coverage of its current gNB (next- 499 generation Node B) (gNB1), the handover procedure is 500 initiated, which includes the 5G SMF (Session Management 501 Function) selecting a new UPF-PSA [3GPP TS 23.501 and TS 502 23.502]. When the handover process is complete, the IP 503 point of attachment is to the new UPF-PSA. The UE's IP 504 address stays the same unless moving to different operator 505 domain. 5GC may maintain a path from the old UPF to the new 506 UPF for a short time for SSC [Session and Service 507 Continuity] mode 3 to make the handover process more 508 seamless. 510 Internet-Draft LSR Extension for 5G EC Service 512 +--+ 513 |UE|---\+---------+ +------------------+ 514 +--+ | 5G | +---------+ | S1: aa08::4450 | 515 +--+ | Site +--++---+ +----+ | 516 |UE|----| A |PSA| Ra| | R1 | S2: aa08::4460 | 517 +--+ | +---+---+ +----+ | 518 +---+ | | | | | S3: aa08::4470 | 519 |UE1|---/+---------+ | | +------------------+ 520 +---+ |IP Network | L-DN1 521 |(3GPP N6) | 522 | | | +------------------+ 523 | UE1 | | | S1: aa08::4450 | 524 | moves to | +----+ | 525 | Site B | | R3 | S2: aa08::4460 | 526 v | +----+ | 527 | | | S3: aa08::4470 | 528 | | +------------------+ 529 | | L-DN3 530 +--+ | | 531 |UE|---\+---------+ | | +------------------+ 532 +--+ | 5G | | | | S1: aa08::4450 | 533 +--+ | Site +--++-+--+ +----+ | 534 |UE|----| B |PSA| Rb | | R2 | S2: aa08::4460 | 535 +--+ | +--++----+ +----+ | 536 +--+ | | +-----------+ | S3: aa08::4470 | 537 |UE|---/+---------+ +------------------+ 538 +--+ L-DN2 539 Figure 10: App Servers in different edge DCs 541 13.1. Metrics to change traffic flow patterns 543 When UEs pattern changes, the Application controller can 544 instantiate more instances at certain locations to 545 accommodate higher demand. 547 However, network layer can offer a simpler solution. By 548 adjusting the site cost for the prefix at specific egress 549 routers, IGP distribution of those site cost plus the flex 550 algorithm can increase (or decrease) flows for the specific 551 prefixes towards the certain locations. 553 Internet-Draft LSR Extension for 5G EC Service 555 - Capacity Index: 556 a numeric number, configured on all A-ERs in the 557 domain consistently, is used to represent the capacity 558 of an EC server attached to an A-ER. The IP addresses 559 exposed to the A-ER can be the App Layer Load 560 balancers that have many instances attached. At other 561 sites, the IP address exposed is the server itself. 562 - Site preference index: 563 Is used to describe some sites are more preferred than 564 others. For example, a site with less leasing cost has 565 a higher preference value. Note: the preference value 566 is configured on all A-ERs in the domain consistently 567 by the Domain Controller. 569 13.2. Reason for using IGP Based Solution 571 Here are some benefits of using IGP to propagate the IP 572 Layer App-Metrics: 573 - Intermediate routers can utilize the aggregated cost to 574 reach the EC Servers attached to different egress edge 575 nodes, especially: 576 - The path to the optimal egress edge node can be 577 more accurate or shorter. 578 - Convergence is shorter when there is any failure 579 along the way towards the optimal ANYCAST server. 580 - When there is any failure at the intended ANYCAST 581 server, all the packets in transit can be optimally 582 forwarded to another App Server attached to a 583 different egress edge router. 584 - Doesn't need the ingress nodes to establish tunnels with 585 egress edge nodes. 587 There are limitations of using IGP too, such as: 589 - The IGP approach might not suit well to 5G EC LDN 590 operated by multiple ISPs. 591 For LDN operated by multiple IPSs, BGP should be used. 592 [BGP-5G-AppMetaData] describes the BGP UPDATE message to 593 propagate IP Layer App-Metrics crossing multiple ISPs. 595 Internet-Draft LSR Extension for 5G EC Service 597 13.3. Flow Affinity to an ANYCAST server 599 When multiple servers with the same IP address (ANYCAST) 600 are attached to different A-ERs, Flow Affinity means 601 routers sending the packets of the same flow to the same A- 602 ER even if the cost towards the A-ER is no longer optimal. 604 Many commercial routers support some forms of flow affinity 605 to ensure packets belonging to one flow be forwarded along 606 the same path. 608 Editor's note: for IPv6 traffic, Flow Affinity can be 609 achieved by routers forwarding the packets with the same 610 Flow Label extracted from the IPv6 Header along the same 611 path. 613 14. Acknowledgments 615 Acknowledgements to Peter Psenak, Les Ginsberg, Robert 616 Raszuk, Acee Lindem, Shraddha Hegde, Tony Li, Gyan Mishra, 617 Jeff Tantsura, and Donald Eastlake for their review and 618 suggestions. 620 This document was prepared using 2-Word-v2.0.template.dot. 622 Authors' Addresses 624 Linda Dunbar 625 Futurewei 626 Email: ldunbar@futurewei.com 628 Huaimo Chen 629 Futurewei 630 Email: huaimo.chen@futurewei.com 632 Aijun Wang 633 China Telecom 634 Email: wangaj3@chinatelecom.cn