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