idnits 2.17.1 draft-dunbar-ippm-5g-edge-compute-ip-layer-metrics-02.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 (February 3, 2022) is 810 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 108, but not defined == Missing Reference: 'A-ER' is mentioned on line 234, but not defined == Missing Reference: 'IPv6-StickyService' is mentioned on line 456, but not defined == Missing Reference: 'ISPF-EXT-EC' is mentioned on line 456, but not defined == Missing Reference: 'RFC4684' is mentioned on line 578, but not defined == Unused Reference: 'RFC4364' is defined on line 613, but no explicit reference was found in the text == Unused Reference: 'RFC8200' is defined on line 621, but no explicit reference was found in the text == Unused Reference: 'RFC5521' is defined on line 632, but no explicit reference was found in the text == Unused Reference: 'BGP-SDWAN-Port' is defined on line 638, but no explicit reference was found in the text == Unused Reference: 'SDWAN-EDGE-Discovery' is defined on line 642, but no explicit reference was found in the text == Unused Reference: 'Tunnel-Encap' is defined on line 647, but no explicit reference was found in the text ** Downref: Normative reference to an Proposed Standard RFC: RFC 4364 == 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 (~~), 15 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group L. Dunbar 2 Internet Draft H. Song 3 J. Kaippallimalil 4 Intended status: Standard Futurewei 5 Expires: May 16, 2021 6 February 3, 2022 8 IP Layer Metrics for 5G Edge Computing Service 9 draft-dunbar-ippm-5g-edge-compute-ip-layer-metrics-02 11 Abstract 13 This draft describes the IP Layer metrics and methods to 14 measure the Edge Computing Servers running status and 15 environment for IP networks to select the optimal Edge 16 Computing server location in 5G Edge Computing (EC) 17 environment. Those measurements are for IP network to 18 dynamically optimize the forwarding of 5G edge computing 19 service without any knowledge above IP layer. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. This document may not be 28 modified, and derivative works of it may not be created, 29 except to publish it as an RFC and to translate it into 30 languages other than English. 32 Internet-Drafts are working documents of the Internet 33 Engineering Task Force (IETF), its areas, and its working 34 groups. Note that other groups may also distribute working 35 documents as Internet-Drafts. 37 Internet-Drafts are draft documents valid for a maximum of 38 six months and may be updated, replaced, or obsoleted by 39 other documents at any time. It is inappropriate to use 40 Internet-Drafts as reference material or to cite them other 41 than as "work in progress." 42 IP Layer Metrics for 5G Edge Computing Services 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 accessed 48 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 Legal 58 Provisions Relating to IETF Documents 59 (http://trustee.ietf.org/license-info) in effect on the date 60 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 in 66 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: Selecting 5G Edge Application Location....4 73 1.3. Problem 2: UE mobility creates unbalanced anycast 74 distribution..............................................5 75 2. Conventions used in this document.........................7 76 3. IP-Layer Metrics Definitions for 5G EC services...........9 77 3.1. IP-Layer Application ID..............................9 78 3.2. IP-Layer metric for App Server Load Measurement......9 79 3.3. Capacity Index in the overall cost..................12 80 3.4. Site Preference Index in the overall cost...........12 81 3.5. RTT to an ANYCAST Address in 5G EC..................13 82 4. Algorithm in Selecting the optimal Target Location.......14 83 5. Scope of IP Layer Metrics Advertisement..................14 84 6. Manageability Considerations.............................15 85 7. Security Considerations..................................16 86 8. IANA Considerations......................................16 87 IP Layer Metrics for 5G Edge Computing Services 89 9. References...............................................16 90 9.1. Normative References................................16 91 9.2. Informative References..............................16 92 10. Acknowledgments.........................................17 94 1. Introduction 95 1.1. 5G Edge Computing Background 97 In 5G Edge Computing environment [3GPP-EdgeComputing], one 98 Application can have multiple Application Servers hosted in 99 different Edge Computing data centers that are close in 100 proximity. Those Edge Computing (mini) data centers are 101 usually very close to, or co-located with, 5G base stations, 102 with the goal to minimize latency and optimize the user 103 experience. 105 When a UE (User Equipment) initiates application packets 106 using the destination address from a DNS reply or from its 107 own cache, the packets from the UE are carried in a PDU 108 session through 5G Core [5GC] to the 5G UPF-PSA (User Plan 109 Function - PDU Session Anchor). The UPF-PSA decapsulate the 110 5G GTP outer header and forwards the packets from the UEs to 111 the Ingress router of the Edge Computing (EC) Local Data 112 Network (LDN). The LDN for 5G EC, which is the IP Networks 113 from 5GC perspective, is responsible for forwarding the 114 packets to the intended destinations. 116 Routers in the local IP network should be able to select the 117 "best" or "closest" application server location out of many. 118 However, simply using distance alone as a metric may not be 119 sufficient as there may be many locations in close proximity. 120 Moreover, one of the main aims of locating application 121 servers so close to the user is to provide lower latency. 122 When a user moves and attaches from another access router 123 (UPF), the local IP network should be able to continue 124 routing to the established application server. As a user 125 keeps moving further away, a closer application server maybe 126 able to serve the user better. Network measurements, 127 including latency of various paths are provided to the 128 application domain to assist in reselection. These problems 129 are outlined in sections 1.2, and 1.3. 131 IP Layer Metrics for 5G Edge Computing Services 133 1.2. Problem 1: Selecting 5G Edge Application Location 135 Having multiple locations closer to UEs to host one 136 Application server can greatly improve the user experience. 137 But selecting an optimal location for the application traffic 138 from a UE may not be that simple. 140 Using DNS to reply with the address of the Application Server 141 location closest to the requesting UE can encounter issues 142 like: 143 - UE can cache results indefinitely, when the UE moves to a 144 5G cell site very far away, the cached address may still 145 be used, which can incur large network delay. 146 - The Application Server at a specific location whose 147 address replied by the DNS might be heavily loaded 148 causing slow or no response, when there are available low 149 utilized Application Server, for the same application, at 150 different locations very close in proximity. 151 - No inherent leverage of proximity information present in 152 the network (routing) layer, resulting in loss of 153 performance 154 - Local DNS resolver become the unit of traffic management 156 Increasingly, Anycast is used extensively by various 157 application providers and CDNs because ANYCAST makes it 158 possible to dynamically load balance across locations that 159 host the Application server based on network conditions. 160 Application server location selection using Anycast address 161 leverages the proximity information present in the network 162 (routing) layer and eliminates the single point of failure 163 and bottleneck at the DNS resolvers and application layer 164 load balancers. Another benefit of using ANYCAST address is 165 removing the dependency on UEs that use their cached 166 destination IP addresses for extended period. 168 But selection of an ANYCAST location purely based on the 169 network condition can encounter issue of the location 170 selected by network routing information being overutilized 171 while there are available underutilized locations close by. 173 IP Layer Metrics for 5G Edge Computing Services 175 1.3. Problem 2: UE mobility creates unbalanced anycast 176 distribution 178 Another problem of using ANYCAST address for multiple 179 locations of an Application Server in 5G environment is that 180 UEs' frequent moving from one 5G site to another. The 181 frequent move of UEs can make it difficult to plan where 182 Application server should be hosted. When a large number of 183 UEs using a particular Application congregate together 184 unpredictably, the ANYCAST location selected based on routing 185 distance can be heavily utilized, while the same Application 186 Server at other locations close-by are underutilized. 188 IP Layer Metrics for 5G Edge Computing Services 190 +--+ 191 |UE|---\+---------+ +------------------+ 192 +--+ | 5G | +-----------+ | S1: aa08::4450 | 193 +--+ | Site A +----+ +----+ | 194 |UE|----| | Ra | | R1 | S2: aa08::4460 | 195 +--+ | +----+ +----+ | 196 +---+ | | | | | S3: aa08::4470 | 197 |UE1|---/+---------+ | | +------------------+ 198 +---+ |IP Network | L-DN1 199 |(3GPP N6) | 200 | | | +------------------+ 201 | | | | S1: aa08::4450 | 202 | | +----+ | 203 | | | R3 | S2: aa08::4460 | 204 v | +----+ | 205 | | | S3: aa08::4470 | 206 | | +------------------+ 207 | | L-DN3 208 +--+ | | 209 |UE|---\+---------+ | | +------------------+ 210 +--+ | 5G | | | | S1: aa08::4450 | 211 +--+ | Site B +----+ +----+ | 212 |UE|----| | Rb | | R2 | S2: aa08::4460 | 213 +--+ | +----+ +----+ | 214 +--+ | | +-----------+ | S3: aa08::4470 | 215 |UE|---/+---------+ +------------------+ 216 +--+ L-DN2 217 Figure 1: multiple ANYCAST instances in different edge DCs 219 This document describes the measurements at IP Layer that can 220 reflect the application server running status and environment at 221 the specific locations. This document also describes the method 222 of incorporating those measurements with IP routing cost to come 223 up with a more optimal criteria in selecting ANYCAST locations. 225 Note: for the ease of description, the Edge Application Server 226 and Application Server are used interchangeably throughout this 227 document. 229 IP Layer Metrics for 5G Edge Computing Services 231 2. Conventions used in this document 233 A-ER: Egress Router to an Application Server Instance, 234 [A-ER] is used to describe the last router that 235 the application instance is attached. For 5G EC 236 environment, the A-ER can be the gateway router 237 to the Edge Computing Data Center. 239 ANYCAST Instance: refer to the Application Server Gateway at 240 a specific location which is reachable by the 241 ANYCAST address. 243 Application Server: An application server is a physical or 244 virtual server that host the software system for 245 the application. 247 Application Server Location: Represent a cluster of servers 248 at one location serving the same Application. One 249 application may have a Layer 7 Load balancer, 250 whose address(es) are reachable from external IP 251 network, in front of a set of application 252 servers. From IP network perspective, this whole 253 group of servers are considered as the 254 Application server at the location. 256 EC: Edge Computing 258 Edge Application Server: used interchangeably with 259 Application Server throughout this document. 261 Edge Computing Hosting Environment: An environment, such as 262 psychical or virtual machines, providing support 263 required for Edge Application Server's execution. 265 NOTE: The above terminologies are the same as 266 those used in 3GPP TR 23.758 268 IP Layer Metrics for 5G Edge Computing Services 270 Edge DC: Edge Data Center, which provides the Edge Hosting 271 Environment. It might be co-located with 5G Base 272 Station and not only host 5G core functions, but 273 also host frequently used Edge server instances. 275 gNB next generation Node B 277 Instance: the term "Instance" if used in the context of 278 Application Server, is referring to one location 279 of an application server; if used in the ANYCAST 280 context, is referring to one location of the 281 Application server with the same ANYCAST address. 283 L-DN: Local Data Network 285 PSA: PDU Session Anchor (UPF) 287 RTT: Round Trip Time 289 RTT-ANYCAST: A list of Round trip times to a group of 290 routers that have the ANYCAST instances directly 291 attached. 293 SSC: Session and Service Continuity 295 UE: User Equipment 297 UPF: User Plane Function 299 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 300 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 301 RECOMMENDED", "MAY", and "OPTIONAL" in this document are to 302 be interpreted as described in BCP 14 [RFC2119] [RFC8174] 303 when, and only when, they appear in all capitals, as shown 304 here. 306 IP Layer Metrics for 5G Edge Computing Services 308 3. IP-Layer Metrics Definitions for 5G EC services 310 3.1. IP-Layer Application ID 312 From network perspective, an application server has an 313 Identifier, or IP Layer Application Server ID, which is 314 usually an ANYCAST address that can represent multiple 315 locations that host the application server. 317 3.2. IP-Layer metric for App Server Load Measurement 319 There are many network techniques and protocols to optimize 320 forwarding and ensuring QoS for applications, such as 321 DSCP/DiffServ, Traffic Engineered (TE) solutions, Segment 322 Routing, etc. But the reality is that most application 323 servers don't expose their internal logics to network 324 operators. Their communications are generally encrypted. Most 325 of them do not even respond to PING or ICMP messages 326 initiated by routers or network gears. 328 The proposed IP Layer Metrics and algorithms enable the IP 329 networks to dynamically optimize the forwarding of 5G edge 330 computing service without any knowledge above IP layer. 332 In a way, the proposed IP Layer Metrics and algorithm enable 333 the IP networks to be more aware of Application behavior 334 without dependency on getting information from Applications 335 themselves. Without knowledge of application internal 336 logics, network layer or IP Layer can monitor the traffic 337 patterns to/from the Application Server at each location to 338 gauge the running status of the application server at the 339 location. 341 First, the network needs to discover which router(s) has the 342 application server attached. Those routers are called 343 Application Server Egress Router, or A-ER for short. A-ER is 344 usually the Gateway Router to an Edge Computing Data Center. 345 To discover if a (Gateway) router is the A-ER for a specific 346 Edge Application Server, the (Gateway) router can 347 periodically send reverse ARP (IPv4) or Neighbor Discovery 348 scan with the address of the Application Server to discover 349 if the Application Servers are hosted in its edge computing 350 data center. If yes, the router or routers are identified as 351 the A-ER for the Application Server. For one Application 352 Server, there can be many A-ERs at different EC Data Centers. 354 IP Layer Metrics for 5G Edge Computing Services 356 For an Application Server at a specific location, which is 357 identified by the address of the application server at the IP 358 layer, the A-ER can measure the amount of traffic destined 359 towards the address & the amount of the traffic from the 360 specific address, such as: 362 - Total number of packets to the attached App Server 363 (ToPackets); 364 - Total number of packets from the attached App Server 365 (FromPackets); 366 - Total number of Bytes to the attached App Server 367 (ToBytes); 368 - Total number of bytes from the attached App Server 369 (FromBytes); 371 The actual load measurement to the App Server attached to an 372 A-ER can be based on one of the metrics above or including 373 all four metrics with different weights applied to each, such 374 as: 376 LoadIndex = 377 w1*ToPackets+w2*FromPackes+w3*ToBytes+w4*FromBytes 379 Where 0<= wi <=1 and w1+ w2+ w3+ w4 = 1. 381 The weights of each metric contributing to the load index of 382 the App Server attached to an A-ER can be configured or 383 learned by self-adjusting based on user feedbacks. 385 The raw measurement is useful when the A-ER routers cannot be 386 configured with a consistent algorithm to compute the 387 aggregated load index and the raw measurements are needed by 388 a central analytic system. 390 The A-ER can advertise either the aggregated Load Index or 391 the raw measurements periodically, by BGP UPDATE messages or 392 OSPF/ISIS Link statement Advertisements, to a group of 393 routers that have traffic destined towards the ANYCAST 394 addresses of those application servers. 396 IP Layer Metrics for 5G Edge Computing Services 398 Even though it would be better to have applications or their 399 controllers directly reporting their own workload running 400 status to network, it is not easy to have third party 401 applications to provide information to network operators in 402 addition to that applications servers can be running anywhere 403 and. 405 The IP-Layer Load Measurements provides an intelligent 406 estimate of the application server running status at a 407 specific location without requiring cooperation from third 408 party Applications or Application controllers. 410 IP Layer Metrics for 5G Edge Computing Services 412 3.3. Capacity Index in the overall cost 414 Given that different Edge Computing DCs may have different 415 capacity, the following metrics need to be included to gauge 416 an application Server's running status at a specific 417 location: 419 - Capacity Index: 420 Capacity Index is used to differentiate the running 421 environment of the application server. Some data centers 422 can have hundreds, or thousands, of servers behind an 423 Application Server's App Layer Load Balancer that is 424 reachable from external world. Other data centers can have 425 very small number of servers for the application server. 426 "Capacity Index", which is a numeric number, is used to 427 represent the capacity of the application server in a 428 specific location. 430 "Capacity Index" can be a configured value indicating the 431 capacity of a specific Application Server at a specific 432 location, e.g. an Edge Computing DC. The Capacity Index is 433 Application Server specific, meaning at one location, one 434 Application Server can have the Capacity Index to be 10 and 435 another server can be 2. 437 If the Application Server capacity configuration is not 438 available, a network analytics tool can use the historic 439 measurements as the basis to estimate the site capacity. If 440 an Application Server at a specific site has high volume 441 for extended period historically, the site capacity can be 442 considered as higher than the other site with historic low 443 volume. This is under the assumption that application 444 controllers monitor utilization of the application servers 445 at different locations. If an application server has 446 prolonged over-utilized servers at some locations, the 447 application controller will trigger manual intervention to 448 increase the computing powers at those locations. However, 449 the manual intervention cycles can be in weeks/months. That 450 is why the IP layer metrics and algorithms that can change 451 flows direction in minutes become very essential. 453 3.4. Site Preference Index in the overall cost 454 IP Layer Metrics for 5G Edge Computing Services 456 As described in [IPv6-StickyService] and [ISPF-EXT-EC], an 457 EC sticky service needs to connect a UE to the application 458 server that has been serving the UE before the UE moves to 459 a new 5G Site, unless there is failure to that location. 461 To achieve the goal of sticking a flow from one specific UE 462 to a specific site, a "site Preference Index" is created. 463 The value of the Site Preference Index can be manipulated 464 for packets of some flows to be steered towards an 465 application server location farther away in routing 466 distance. The "Site Preference Index" enables some sites to 467 be more preferred for handling the UE traffic to a 468 application server than others. 470 3.5. RTT to an ANYCAST Address in 5G EC 472 ANYCAST used in 5G Edge computing environment is slightly 473 different from the typical ANYCAST address being deployed. 474 Typical ANYCAST address is used to represent instances in 475 vast different geographical locations, such as different 476 continents. ANCAST address for "app.net" for Asia lead 477 packets to a server instance of "app.net" hosted in Asia. 478 Therefore, the RTT for "app.net" in Asia, is a single value 479 that represent the round time trip to the server in Asia 480 that host the "app.net". 482 5G Edge Computing environment can have one Application 483 server hosted in multiple Edge Computing DCs close in 484 proximity. Routers, i.e. the ingress router to 5G LDN 485 (Local Data Network), can forward packets for the ANYCAST 486 address of "app.net" to different egress routers that have 487 "app.net" servers attached. 489 If "app.net" is hosted in four different 5G Edge Computing 490 Data Centers. All those DCs have the same ANYCAST address 491 for the "app.net". The RTT to "app.net" ANYCAST address 492 need to be a group of values (instead of one RTT value to a 493 unicast address). The RTT group value should include the A- 494 ER router's specific unicast address (e.g. the loopback 495 address) to which the Application Server is attached. 497 RTT to "app.net" ANYCAST Address is represented as: 499 List of {Egress Router address, RTT value} 501 This list is called "RTT-ANYCAST". 503 IP Layer Metrics for 5G Edge Computing Services 505 In order to better optimize the ANYCAST traffic, each 506 router adjacent to 5G PSA needs to periodically measure RTT 507 to a list of A-ER routers that advertise the ANYCAST 508 address. The RTT to egress router at Site-i is considered 509 as the RTT to the ANYCAST instance at the Site-i. 511 4. Algorithm in Selecting the optimal Target Location 513 The goal of the algorithm is to equalize the traffic among 514 multiple locations of the same ANYCAST address. 516 The main benefit of using ANYCAST is to leverage the IP- 517 layer information to equalize the traffic among multiple 518 locations of the same Application Server, usually 519 identified by one or a group of ANYCAST addresses. 521 For 5G Edge Computing environment, the ingress router to 522 each LDN needs to be notified of the Load Index and 523 Capacity Index of the Application Servers at different EC 524 site to make the intelligent decision on where to forward 525 the traffic from UEs for an application. 527 The Algorithm needs to take the following attributes into 528 consideration: 530 - Load Measurement Index [Section 3.2], 531 - capacity index [Section 3.3], 532 - Preference Index [Section 3.4], and 533 - network delay [Section 3.5]. 535 Here is an algorithm for a router, e.g. the router directly 536 attached to the 5G PSA, to compare the cost to reach the 537 Application Server between the Site-i or Site-j: 539 Load-i * CP-j Pref-j * Delay-i 540 Cost-i=min(w *(----------------) + (1-w) *(------------------)) 541 Load-j * CP-i Pref-i * Delay-j 543 Load-i: Load Index at Site-i, it is the weighted 544 combination of the total packets and bytes sent to and 545 received from the Application Server at Site-i during a 546 fixed time period. 548 IP Layer Metrics for 5G Edge Computing Services 550 CP-i (Capacity-i) (higher value means higher capacity): 551 capacity index at the site i. 553 Delay-i: Network latency measurement (RTT) to the A-ER 554 that has the Application Server attached at the site-i. 556 Pref-i (Preference Index: higher value means higher 557 preference): Network Preference index for the site-I. 559 w: Weight for load and site information, which is a value 560 between 0 and 1. If smaller than 0.5, Network latency and 561 the site Preference have more influence; otherwise, Server 562 load and its capacity have more influence. 564 5. Scope of IP Layer Metrics Advertisement 566 Each Application Server might be used by a small group of 567 UEs. Therefore, it is not necessary for A-ER router to 568 advertise the IP layer metrics to all other routers in the 5G 569 LDN. Likewise, each EC Data Center may only host a small 570 number of application servers. 572 "Application Bound Group Routers" is used to refer a group of 573 routers that are interested in a group of specific ANYCAST 574 addresses. The IP Layer Metrics for an Application Server 575 should be advertised among the routers in the "Application 576 bound Group Routers". 578 BGP RT Constrained Distribution [RFC4684] can be used to form 579 the "Application Bound Group Routers". 581 Since there are much more Application Servers than the number 582 of routers in 5G LDN, a more practical way to form the 583 "Application Bound Group of Routers" is for each ingress 584 router to query a network controller upon receiving the first 585 packet to a specific ANYCAST address to be included in the 586 "Application Bound Group Routers". There should be a timer 587 associated with Ingress router, as the UE that uses the 588 Application Server might move away. Upon timer expires, the 589 Ingress Router is removed from the "Application Bound Group 590 of Routers". 592 6. Manageability Considerations 594 To be added. 596 IP Layer Metrics for 5G Edge Computing Services 598 7. Security Considerations 600 To be added. 602 8. IANA Considerations 604 To be added. 606 9. References 608 9.1. Normative References 610 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 611 Requirement Levels", BCP 14, RFC 2119, March 1997. 613 [RFC4364] E. rosen, Y. Rekhter, "BGP/MPLS IP Virtual Private 614 networks (VPNs)", Feb 2006. 616 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in 617 RFC 2119 Key Words", BCP 14, RFC 8174, DOI 618 10.17487/RFC8174, May 2017, . 621 [RFC8200] s. Deering R. Hinden, "Internet Protocol, Version 6 622 (IPv6) Specification", July 2017 624 9.2. Informative References 626 [3GPP-EdgeComputing] 3GPP TR 23.748, "3rd Generation 627 Partnership Project; Technical Specification Group 628 Services and System Aspects; Study on enhancement 629 of support for Edge Computing in 5G Core network 630 (5GC)", Release 17 work in progress, Aug 2020. 632 [RFC5521] P. Mohapatra, E. Rosen, "The BGP Encapsulation 633 Subsequent Address Family Identifier (SAFI) and the 634 BGP Tunnel Encapsulation Attribute", April 2009. 636 IP Layer Metrics for 5G Edge Computing Services 638 [BGP-SDWAN-Port] L. Dunbar, H. Wang, W. Hao, "BGP Extension 639 for SDWAN Overlay Networks", draft-dunbar-idr-bgp- 640 sdwan-overlay-ext-03, work-in-progress, Nov 2018. 642 [SDWAN-EDGE-Discovery] L. Dunbar, S. Hares, R. Raszuk, K. 643 Majumdar, "BGP UPDATE for SDWAN Edge Discovery", 644 draft-dunbar-idr-sdwan-edge-discovery-00, work-in- 645 progress, July 2020. 647 [Tunnel-Encap] E. Rosen, et al "The BGP Tunnel Encapsulation 648 Attribute", draft-ietf-idr-tunnel-encaps-10, Aug 649 2018. 651 10. Acknowledgments 653 Acknowledgements to Donald Eastlake for their review and 654 contributions. 656 This document was prepared using 2-Word-v2.0.template.dot. 658 IP Layer Metrics for 5G Edge Computing Services 660 Authors' Addresses 662 Linda Dunbar 663 Futurewei 664 Email: ldunbar@futurewei.com 666 HaoYu Song 667 Futurewei 668 Email: haoyu.song@futurewei.com 670 John Kaippallimalil 671 Futurewei 672 Email: john.kaippallimalil@futurewei.com