idnits 2.17.1 draft-dunbar-ippm-5g-edge-compute-ip-layer-metrics-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (November 2, 2020) is 1264 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 109, but not defined == Missing Reference: 'A-ER' is mentioned on line 235, but not defined == Missing Reference: 'IPv6-StickyService' is mentioned on line 457, but not defined == Missing Reference: 'ISPF-EXT-EC' is mentioned on line 457, but not defined == Missing Reference: 'RFC4684' is mentioned on line 579, but not defined == Unused Reference: 'RFC4364' is defined on line 614, but no explicit reference was found in the text == Unused Reference: 'RFC8200' is defined on line 622, but no explicit reference was found in the text == Unused Reference: 'RFC5521' is defined on line 633, but no explicit reference was found in the text == Unused Reference: 'BGP-SDWAN-Port' is defined on line 639, but no explicit reference was found in the text == Unused Reference: 'SDWAN-EDGE-Discovery' is defined on line 643, but no explicit reference was found in the text == Unused Reference: 'Tunnel-Encap' is defined on line 648, 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 2, 2021 7 November 2, 2020 9 IP Layer Metrics for 5G Edge Computing Service 10 draft-dunbar-ippm-5g-edge-compute-ip-layer-metrics-01 12 Abstract 14 This draft describes the IP Layer metrics and methods to 15 measure the Edge Computing Servers running status and 16 environment for IP networks to select the optimal Edge 17 Computing server location in 5G Edge Computing (EC) 18 environment. Those measurements are for IP network to 19 dynamically optimize the forwarding of 5G edge computing 20 service without any knowledge above IP layer. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. This document may not be 29 modified, and derivative works of it may not be created, 30 except to publish it as an RFC and to translate it into 31 languages other than English. 33 Internet-Drafts are working documents of the Internet 34 Engineering Task Force (IETF), its areas, and its working 35 groups. Note that other groups may also distribute working 36 documents as Internet-Drafts. 38 Internet-Drafts are draft documents valid for a maximum of 39 six months and may be updated, replaced, or obsoleted by 40 other documents at any time. It is inappropriate to use 41 Internet-Drafts as reference material or to cite them other 42 than as "work in progress." 43 IP Layer Metrics for 5G Edge Computing Services 45 The list of current Internet-Drafts can be accessed at 46 http://www.ietf.org/ietf/1id-abstracts.txt 48 The list of Internet-Draft Shadow Directories can be accessed 49 at http://www.ietf.org/shadow.html 51 This Internet-Draft will expire on April 7, 2021. 53 Copyright Notice 55 Copyright (c) 2020 IETF Trust and the persons identified as 56 the document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date 61 of publication of this document. Please review these 62 documents carefully, as they describe your rights and 63 restrictions with respect to this document. Code Components 64 extracted from this document must include Simplified BSD 65 License text as described in Section 4.e of the Trust Legal 66 Provisions and are provided without warranty as described in 67 the Simplified BSD License. 69 Table of Contents 71 1. Introduction..............................................3 72 1.1. 5G Edge Computing Background.........................3 73 1.2. Problem 1: Selecting 5G Edge Application Location....4 74 1.3. Problem 2: UE mobility creates unbalanced anycast 75 distribution..............................................5 76 2. Conventions used in this document.........................7 77 3. IP-Layer Metrics Definitions for 5G EC services...........9 78 3.1. IP-Layer Application ID..............................9 79 3.2. IP-Layer metric for App Server Load Measurement......9 80 3.3. Capacity Index in the overall cost..................12 81 3.4. Site Preference Index in the overall cost...........12 82 3.5. RTT to an ANYCAST Address in 5G EC..................13 83 4. Algorithm in Selecting the optimal Target Location.......14 84 IP Layer Metrics for 5G Edge Computing Services 86 5. Scope of IP Layer Metrics Advertisement..................14 87 6. Manageability Considerations.............................15 88 7. Security Considerations..................................16 89 8. IANA Considerations......................................16 90 9. References...............................................16 91 9.1. Normative References................................16 92 9.2. Informative References..............................16 93 10. Acknowledgments.........................................17 95 1. Introduction 96 1.1. 5G Edge Computing Background 98 In 5G Edge Computing environment [3GPP-EdgeComputing], one 99 Application can have multiple Application Servers hosted in 100 different Edge Computing data centers that are close in 101 proximity. Those Edge Computing (mini) data centers are 102 usually very close to, or co-located with, 5G base stations, 103 with the goal to minimize latency and optimize the user 104 experience. 106 When a UE (User Equipment) initiates application packets 107 using the destination address from a DNS reply or from its 108 own cache, the packets from the UE are carried in a PDU 109 session through 5G Core [5GC] to the 5G UPF-PSA (User Plan 110 Function - PDU Session Anchor). The UPF-PSA decapsulate the 111 5G GTP outer header and forwards the packets from the UEs to 112 the Ingress router of the Edge Computing (EC) Local Data 113 Network (LDN). The LDN for 5G EC, which is the IP Networks 114 from 5GC perspective, is responsible for forwarding the 115 packets to the intended destinations. 117 Routers in the local IP network should be able to select the 118 "best" or "closest" application server location out of many. 119 However, simply using distance alone as a metric may not be 120 sufficient as there may be many locations in close proximity. 121 Moreover, one of the main aims of locating application 122 servers so close to the user is to provide lower latency. 123 When a user moves and attaches from another access router 124 (UPF), the local IP network should be able to continue 125 routing to the established application server. As a user 126 keeps moving further away, a closer application server maybe 127 able to serve the user better. Network measurements, 128 IP Layer Metrics for 5G Edge Computing Services 130 including latency of various paths are provided to the 131 application domain to assist in reselection. These problems 132 are outlined in sections 1.2, and 1.3. 134 1.2. Problem 1: Selecting 5G Edge Application Location 136 Having multiple locations closer to UEs to host one 137 Application server can greatly improve the user experience. 138 But selecting an optimal location for the application traffic 139 from a UE may not be that simple. 141 Using DNS to reply with the address of the Application Server 142 location closest to the requesting UE can encounter issues 143 like: 144 - UE can cache results indefinitely, when the UE moves to a 145 5G cell site very far away, the cached address may still 146 be used, which can incur large network delay. 147 - The Application Server at a specific location whose 148 address replied by the DNS might be heavily loaded 149 causing slow or no response, when there are available low 150 utilized Application Server, for the same application, at 151 different locations very close in proximity. 152 - No inherent leverage of proximity information present in 153 the network (routing) layer, resulting in loss of 154 performance 155 - Local DNS resolver become the unit of traffic management 157 Increasingly, Anycast is used extensively by various 158 application providers and CDNs because ANYCAST makes it 159 possible to dynamically load balance across locations that 160 host the Application server based on network conditions. 161 Application server location selection using Anycast address 162 leverages the proximity information present in the network 163 (routing) layer and eliminates the single point of failure 164 and bottleneck at the DNS resolvers and application layer 165 load balancers. Another benefit of using ANYCAST address is 166 removing the dependency on UEs that use their cached 167 destination IP addresses for extended period. 169 IP Layer Metrics for 5G Edge Computing Services 171 But selection of an ANYCAST location purely based on the 172 network condition can encounter issue of the location 173 selected by network routing information being overutilized 174 while there are available underutilized locations close by. 176 1.3. Problem 2: UE mobility creates unbalanced anycast 177 distribution 179 Another problem of using ANYCAST address for multiple 180 locations of an Application Server in 5G environment is that 181 UEs' frequent moving from one 5G site to another. The 182 frequent move of UEs can make it difficult to plan where 183 Application server should be hosted. When a large number of 184 UEs using a particular Application congregate together 185 unpredictably, the ANYCAST location selected based on routing 186 distance can be heavily utilized, while the same Application 187 Server at other locations close-by are underutilized. 189 IP Layer Metrics for 5G Edge Computing Services 191 +--+ 192 |UE|---\+---------+ +------------------+ 193 +--+ | 5G | +-----------+ | S1: aa08::4450 | 194 +--+ | Site A +----+ +----+ | 195 |UE|----| | Ra | | R1 | S2: aa08::4460 | 196 +--+ | +----+ +----+ | 197 +---+ | | | | | S3: aa08::4470 | 198 |UE1|---/+---------+ | | +------------------+ 199 +---+ |IP Network | L-DN1 200 |(3GPP N6) | 201 | | | +------------------+ 202 | | | | S1: aa08::4450 | 203 | | +----+ | 204 | | | R3 | S2: aa08::4460 | 205 v | +----+ | 206 | | | S3: aa08::4470 | 207 | | +------------------+ 208 | | L-DN3 209 +--+ | | 210 |UE|---\+---------+ | | +------------------+ 211 +--+ | 5G | | | | S1: aa08::4450 | 212 +--+ | Site B +----+ +----+ | 213 |UE|----| | Rb | | R2 | S2: aa08::4460 | 214 +--+ | +----+ +----+ | 215 +--+ | | +-----------+ | S3: aa08::4470 | 216 |UE|---/+---------+ +------------------+ 217 +--+ L-DN2 218 Figure 1: multiple ANYCAST instances in different edge DCs 220 This document describes the measurements at IP Layer that can 221 reflect the application server running status and environment at 222 the specific locations. This document also describes the method 223 of incorporating those measurements with IP routing cost to come 224 up with a more optimal criteria in selecting ANYCAST locations. 226 Note: for the ease of description, the Edge Application Server 227 and Application Server are used interchangeably throughout this 228 document. 230 IP Layer Metrics for 5G Edge Computing Services 232 2. Conventions used in this document 234 A-ER: Egress Router to an Application Server Instance, 235 [A-ER] is used to describe the last router that 236 the application instance is attached. For 5G EC 237 environment, the A-ER can be the gateway router 238 to the Edge Computing Data Center. 240 ANYCAST Instance: refer to the Application Server Gateway at 241 a specific location which is reachable by the 242 ANYCAST address. 244 Application Server: An application server is a physical or 245 virtual server that host the software system for 246 the application. 248 Application Server Location: Represent a cluster of servers 249 at one location serving the same Application. One 250 application may have a Layer 7 Load balancer, 251 whose address(es) are reachable from external IP 252 network, in front of a set of application 253 servers. From IP network perspective, this whole 254 group of servers are considered as the 255 Application server at the location. 257 EC: Edge Computing 259 Edge Application Server: used interchangeably with 260 Application Server throughout this document. 262 Edge Computing Hosting Environment: An environment, such as 263 psychical or virtual machines, providing support 264 required for Edge Application Server's execution. 266 NOTE: The above terminologies are the same as 267 those used in 3GPP TR 23.758 269 IP Layer Metrics for 5G Edge Computing Services 271 Edge DC: Edge Data Center, which provides the Edge Hosting 272 Environment. It might be co-located with 5G Base 273 Station and not only host 5G core functions, but 274 also host frequently used Edge server instances. 276 gNB next generation Node B 278 Instance: the term "Instance" if used in the context of 279 Application Server, is referring to one location 280 of an application server; if used in the ANYCAST 281 context, is referring to one location of the 282 Application server with the same ANYCAST address. 284 L-DN: Local Data Network 286 PSA: PDU Session Anchor (UPF) 288 RTT: Round Trip Time 290 RTT-ANYCAST: A list of Round trip times to a group of 291 routers that have the ANYCAST instances directly 292 attached. 294 SSC: Session and Service Continuity 296 UE: User Equipment 298 UPF: User Plane Function 300 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 301 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 302 RECOMMENDED", "MAY", and "OPTIONAL" in this document are to 303 be interpreted as described in BCP 14 [RFC2119] [RFC8174] 304 when, and only when, they appear in all capitals, as shown 305 here. 307 IP Layer Metrics for 5G Edge Computing Services 309 3. IP-Layer Metrics Definitions for 5G EC services 311 3.1. IP-Layer Application ID 313 From network perspective, an application server has an 314 Identifier, or IP Layer Application Server ID, which is 315 usually an ANYCAST address that can represent multiple 316 locations that host the application server. 318 3.2. IP-Layer metric for App Server Load Measurement 320 There are many network techniques and protocols to optimize 321 forwarding and ensuring QoS for applications, such as 322 DSCP/DiffServ, Traffic Engineered (TE) solutions, Segment 323 Routing, etc. But the reality is that most application 324 servers don't expose their internal logics to network 325 operators. Their communications are generally encrypted. Most 326 of them do not even respond to PING or ICMP messages 327 initiated by routers or network gears. 329 The proposed IP Layer Metrics and algorithms enable the IP 330 networks to dynamically optimize the forwarding of 5G edge 331 computing service without any knowledge above IP layer. 333 In a way, the proposed IP Layer Metrics and algorithm enable 334 the IP networks to be more aware of Application behavior 335 without dependency on getting information from Applications 336 themselves. Without knowledge of application internal 337 logics, network layer or IP Layer can monitor the traffic 338 patterns to/from the Application Server at each location to 339 gauge the running status of the application server at the 340 location. 342 First, the network needs to discover which router(s) has the 343 application server attached. Those routers are called 344 Application Server Egress Router, or A-ER for short. A-ER is 345 usually the Gateway Router to an Edge Computing Data Center. 346 To discover if a (Gateway) router is the A-ER for a specific 347 Edge Application Server, the (Gateway) router can 348 periodically send reverse ARP (IPv4) or Neighbor Discovery 349 scan with the address of the Application Server to discover 350 if the Application Servers are hosted in its edge computing 351 data center. If yes, the router or routers are identified as 352 the A-ER for the Application Server. For one Application 353 Server, there can be many A-ERs at different EC Data Centers. 355 IP Layer Metrics for 5G Edge Computing Services 357 For an Application Server at a specific location, which is 358 identified by the address of the application server at the IP 359 layer, the A-ER can measure the amount of traffic destined 360 towards the address & the amount of the traffic from the 361 specific address, such as: 363 - Total number of packets to the attached App Server 364 (ToPackets); 365 - Total number of packets from the attached App Server 366 (FromPackets); 367 - Total number of Bytes to the attached App Server 368 (ToBytes); 369 - Total number of bytes from the attached App Server 370 (FromBytes); 372 The actual load measurement to the App Server attached to an 373 A-ER can be based on one of the metrics above or including 374 all four metrics with different weights applied to each, such 375 as: 377 LoadIndex = 378 w1*ToPackets+w2*FromPackes+w3*ToBytes+w4*FromBytes 380 Where 0<= wi <=1 and w1+ w2+ w3+ w4 = 1. 382 The weights of each metric contributing to the load index of 383 the App Server attached to an A-ER can be configured or 384 learned by self-adjusting based on user feedbacks. 386 The raw measurement is useful when the A-ER routers cannot be 387 configured with a consistent algorithm to compute the 388 aggregated load index and the raw measurements are needed by 389 a central analytic system. 391 The A-ER can advertise either the aggregated Load Index or 392 the raw measurements periodically, by BGP UPDATE messages or 393 OSPF/ISIS Link statement Advertisements, to a group of 394 routers that have traffic destined towards the ANYCAST 395 addresses of those application servers. 397 IP Layer Metrics for 5G Edge Computing Services 399 Even though it would be better to have applications or their 400 controllers directly reporting their own workload running 401 status to network, it is not easy to have third party 402 applications to provide information to network operators in 403 addition to that applications servers can be running anywhere 404 and. 406 The IP-Layer Load Measurements provides an intelligent 407 estimate of the application server running status at a 408 specific location without requiring cooperation from third 409 party Applications or Application controllers. 411 IP Layer Metrics for 5G Edge Computing Services 413 3.3. Capacity Index in the overall cost 415 Given that different Edge Computing DCs may have different 416 capacity, the following metrics need to be included to gauge 417 an application Server's running status at a specific 418 location: 420 - Capacity Index: 421 Capacity Index is used to differentiate the running 422 environment of the application server. Some data centers 423 can have hundreds, or thousands, of servers behind an 424 Application Server's App Layer Load Balancer that is 425 reachable from external world. Other data centers can have 426 very small number of servers for the application server. 427 "Capacity Index", which is a numeric number, is used to 428 represent the capacity of the application server in a 429 specific location. 431 "Capacity Index" can be a configured value indicating the 432 capacity of a specific Application Server at a specific 433 location, e.g. an Edge Computing DC. The Capacity Index is 434 Application Server specific, meaning at one location, one 435 Application Server can have the Capacity Index to be 10 and 436 another server can be 2. 438 If the Application Server capacity configuration is not 439 available, a network analytics tool can use the historic 440 measurements as the basis to estimate the site capacity. If 441 an Application Server at a specific site has high volume 442 for extended period historically, the site capacity can be 443 considered as higher than the other site with historic low 444 volume. This is under the assumption that application 445 controllers monitor utilization of the application servers 446 at different locations. If an application server has 447 prolonged over-utilized servers at some locations, the 448 application controller will trigger manual intervention to 449 increase the computing powers at those locations. However, 450 the manual intervention cycles can be in weeks/months. That 451 is why the IP layer metrics and algorithms that can change 452 flows direction in minutes become very essential. 454 3.4. Site Preference Index in the overall cost 455 IP Layer Metrics for 5G Edge Computing Services 457 As described in [IPv6-StickyService] and [ISPF-EXT-EC], an 458 EC sticky service needs to connect a UE to the application 459 server that has been serving the UE before the UE moves to 460 a new 5G Site, unless there is failure to that location. 462 To achieve the goal of sticking a flow from one specific UE 463 to a specific site, a "site Preference Index" is created. 464 The value of the Site Preference Index can be manipulated 465 for packets of some flows to be steered towards an 466 application server location farther away in routing 467 distance. The "Site Preference Index" enables some sites to 468 be more preferred for handling the UE traffic to a 469 application server than others. 471 3.5. RTT to an ANYCAST Address in 5G EC 473 ANYCAST used in 5G Edge computing environment is slightly 474 different from the typical ANYCAST address being deployed. 475 Typical ANYCAST address is used to represent instances in 476 vast different geographical locations, such as different 477 continents. ANCAST address for "app.net" for Asia lead 478 packets to a server instance of "app.net" hosted in Asia. 479 Therefore, the RTT for "app.net" in Asia, is a single value 480 that represent the round time trip to the server in Asia 481 that host the "app.net". 483 5G Edge Computing environment can have one Application 484 server hosted in multiple Edge Computing DCs close in 485 proximity. Routers, i.e. the ingress router to 5G LDN 486 (Local Data Network), can forward packets for the ANYCAST 487 address of "app.net" to different egress routers that have 488 "app.net" servers attached. 490 If "app.net" is hosted in four different 5G Edge Computing 491 Data Centers. All those DCs have the same ANYCAST address 492 for the "app.net". The RTT to "app.net" ANYCAST address 493 need to be a group of values (instead of one RTT value to a 494 unicast address). The RTT group value should include the A- 495 ER router's specific unicast address (e.g. the loopback 496 address) to which the Application Server is attached. 498 RTT to "app.net" ANYCAST Address is represented as: 500 List of {Egress Router address, RTT value} 502 This list is called "RTT-ANYCAST". 504 IP Layer Metrics for 5G Edge Computing Services 506 In order to better optimize the ANYCAST traffic, each 507 router adjacent to 5G PSA needs to periodically measure RTT 508 to a list of A-ER routers that advertise the ANYCAST 509 address. The RTT to egress router at Site-i is considered 510 as the RTT to the ANYCAST instance at the Site-i. 512 4. Algorithm in Selecting the optimal Target Location 514 The goal of the algorithm is to equalize the traffic among 515 multiple locations of the same ANYCAST address. 517 The main benefit of using ANYCAST is to leverage the IP- 518 layer information to equalize the traffic among multiple 519 locations of the same Application Server, usually 520 identified by one or a group of ANYCAST addresses. 522 For 5G Edge Computing environment, the ingress router to 523 each LDN needs to be notified of the Load Index and 524 Capacity Index of the Application Servers at different EC 525 site to make the intelligent decision on where to forward 526 the traffic from UEs for an application. 528 The Algorithm needs to take the following attributes into 529 consideration: 531 - Load Measurement Index [Section 3.2], 532 - capacity index [Section 3.3], 533 - Preference Index [Section 3.4], and 534 - network delay [Section 3.5]. 536 Here is an algorithm for a router, e.g. the router directly 537 attached to the 5G PSA, to compare the cost to reach the 538 Application Server between the Site-i or Site-j: 540 Load-i * CP-j Pref-j * Delay-i 541 Cost-i=min(w *(----------------) + (1-w) *(------------------)) 542 Load-j * CP-i Pref-i * Delay-j 544 Load-i: Load Index at Site-i, it is the weighted 545 combination of the total packets and bytes sent to and 546 received from the Application Server at Site-i during a 547 fixed time period. 549 IP Layer Metrics for 5G Edge Computing Services 551 CP-i (Capacity-i) (lower value means higher capacity): 552 capacity index at the site i. 554 Delay-i: Network latency measurement (RTT) to the A-ER 555 that has the Application Server attached at the site-i. 557 Pref-i (Preference Index: lower value means higher 558 preference): Network Preference index for the site-I. 560 w: Weight for load and site information, which is a value 561 between 0 and 1. If smaller than 0.5, Network latency and 562 the site Preference have more influence; otherwise, Server 563 load and its capacity have more influence. 565 5. Scope of IP Layer Metrics Advertisement 567 Each Application Server might be used by a small group of 568 UEs. Therefore, it is not necessary for A-ER router to 569 advertise the IP layer metrics to all other routers in the 5G 570 LDN. Likewise, each EC Data Center may only host a small 571 number of application servers. 573 "Application Bound Group Routers" is used to refer a group of 574 routers that are interested in a group of specific ANYCAST 575 addresses. The IP Layer Metrics for an Application Server 576 should be advertised among the routers in the "Application 577 bound Group Routers". 579 BGP RT Constrained Distribution [RFC4684] can be used to form 580 the "Application Bound Group Routers". 582 Since there are much more Application Servers than the number 583 of routers in 5G LDN, a more practical way to form the 584 "Application Bound Group of Routers" is for each ingress 585 router to query a network controller upon receiving the first 586 packet to a specific ANYCAST address to be included in the 587 "Application Bound Group Routers". There should be a timer 588 associated with Ingress router, as the UE that uses the 589 Application Server might move away. Upon timer expires, the 590 Ingress Router is removed from the "Application Bound Group 591 of Routers". 593 6. Manageability Considerations 595 To be added. 597 IP Layer Metrics for 5G Edge Computing Services 599 7. Security Considerations 601 To be added. 603 8. IANA Considerations 605 To be added. 607 9. References 609 9.1. Normative References 611 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 612 Requirement Levels", BCP 14, RFC 2119, March 1997. 614 [RFC4364] E. rosen, Y. Rekhter, "BGP/MPLS IP Virtual Private 615 networks (VPNs)", Feb 2006. 617 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in 618 RFC 2119 Key Words", BCP 14, RFC 8174, DOI 619 10.17487/RFC8174, May 2017, . 622 [RFC8200] s. Deering R. Hinden, "Internet Protocol, Version 6 623 (IPv6) Specification", July 2017 625 9.2. Informative References 627 [3GPP-EdgeComputing] 3GPP TR 23.748, "3rd Generation 628 Partnership Project; Technical Specification Group 629 Services and System Aspects; Study on enhancement 630 of support for Edge Computing in 5G Core network 631 (5GC)", Release 17 work in progress, Aug 2020. 633 [RFC5521] P. Mohapatra, E. Rosen, "The BGP Encapsulation 634 Subsequent Address Family Identifier (SAFI) and the 635 BGP Tunnel Encapsulation Attribute", April 2009. 637 IP Layer Metrics for 5G Edge Computing Services 639 [BGP-SDWAN-Port] L. Dunbar, H. Wang, W. Hao, "BGP Extension 640 for SDWAN Overlay Networks", draft-dunbar-idr-bgp- 641 sdwan-overlay-ext-03, work-in-progress, Nov 2018. 643 [SDWAN-EDGE-Discovery] L. Dunbar, S. Hares, R. Raszuk, K. 644 Majumdar, "BGP UPDATE for SDWAN Edge Discovery", 645 draft-dunbar-idr-sdwan-edge-discovery-00, work-in- 646 progress, July 2020. 648 [Tunnel-Encap] E. Rosen, et al "The BGP Tunnel Encapsulation 649 Attribute", draft-ietf-idr-tunnel-encaps-10, Aug 650 2018. 652 10. Acknowledgments 654 Acknowledgements to Donald Eastlake for their review and 655 contributions. 657 This document was prepared using 2-Word-v2.0.template.dot. 659 IP Layer Metrics for 5G Edge Computing Services 661 Authors' Addresses 663 Linda Dunbar 664 Futurewei 665 Email: ldunbar@futurewei.com 667 HaoYu Song 668 Futurewei 669 Email: haoyu.song@futurewei.com 671 John Kaippallimalil 672 Futurewei 673 Email: john.kaippallimalil@futurewei.com