idnits 2.17.1 draft-dunbar-lsr-5g-edge-compute-00.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 (July 12, 2021) is 1016 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 139, but not defined == Missing Reference: 'A-ER' is mentioned on line 243, but not defined == Missing Reference: 'RFC8174' is mentioned on line 302, but not defined == Missing Reference: 'IPv6-StickyService' is mentioned on line 374, but not defined == Missing Reference: 'RFC8919' is mentioned on line 466, but not defined ** Obsolete undefined reference: RFC 8919 (Obsoleted by RFC 9479) == Missing Reference: 'Figure 2' is mentioned on line 498, but not defined == Missing Reference: 'RFC8920' is mentioned on line 679, but not defined ** Obsolete undefined reference: RFC 8920 (Obsoleted by RFC 9492) == Unused Reference: 'RFC8200' is defined on line 861, but no explicit reference was found in the text == Unused Reference: 'RFC8326' is defined on line 864, but no explicit reference was found in the text == Unused Reference: '5G-StickyService' is defined on line 887, but no explicit reference was found in the text == Unused Reference: 'RFC5521' is defined on line 894, but no explicit reference was found in the text == Unused Reference: 'BGP-SDWAN-Port' is defined on line 899, but no explicit reference was found in the text == Unused Reference: 'SDWAN-EDGE-Discovery' is defined on line 904, but no explicit reference was found in the text == Unused Reference: 'Tunnel-Encap' is defined on line 909, but no explicit reference was found in the text ** Downref: Normative reference to an Proposed Standard RFC: RFC 7684 ** Downref: Normative reference to an Proposed Standard RFC: RFC 8362 (ref. 'RFC8326') == Outdated reference: A later version (-14) exists of draft-dunbar-idr-5g-edge-compute-app-meta-data-01 == Outdated reference: A later version (-02) exists of draft-dunbar-ippm-5g-edge-compute-ip-layer-metrics-01 -- No information found for draft-dunbar-6man-5g-ec-sticky-service - is the name correct? == 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: 4 errors (**), 0 flaws (~~), 20 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: January 12, 2022 Aijun Wang 5 China Telecom 6 July 12, 2021 8 IS-IS & OSPF extension for 5G Edge Computing Service 9 draft-dunbar-lsr-5g-edge-compute-00 11 Abstract 12 This draft describes an IS-IS and OSPF extension for 13 routers to advertise the running status and environment 14 (Site-Cost) for the directly attached 5G Edge Computing 15 servers. Routers in the 5G Local Data Network can use the 16 Site-Cost and the network condition to optimize forwarding 17 flows from UEs. The goal is to improve latency and 18 performance for 5G Edge Computing services. 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 OSPF 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) 2021 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. 5G Edge Computing Background...................... 3 71 1.2. Problem#1: ANYCAST in 5G EC Environment........... 5 72 1.3. Problem #2: Unbalanced Anycast Distribution due to 73 UE Mobility............................................ 6 74 1.4. Problem 3: Application Server Relocation.......... 6 75 2. Conventions used in this document...................... 6 76 3. Solution Overview...................................... 8 77 3.1. Flow Affinity to an ANYCAST server................ 8 78 3.2. IP Layer Metrics to Gauge App Server Running Status 79 ....................................................... 9 80 3.3. To Equalize traffic among Multiple ANYCAST 81 Locations............................................. 10 82 3.4. Reason for using IGP Based Solution.............. 11 83 4. IS-IS Extension....................................... 11 84 4.1. IS-IS extension for the Aggregated cost.......... 12 85 4.2. IS-IS extension for IP Layer App-Metrics 86 Advertisements........................................ 13 87 4.3. IS-IS App-Metrics SubTLVs for IPv6 attachment.... 13 88 4.4. IS-IS IP Layer App-Metrics for IPv4.............. 14 90 Internet-Draft OSPF Extension for 5G EC Service 92 5. Aggregated Cost Advertisement in OSPF................. 14 93 5.1. OSPFv3 LSA to carry the Aggregated Cost.......... 15 94 5.2. OSPFv2 LSA to carry the Aggregated Cost.......... 15 95 6. IP Layer App-Metrics Advertisements by OSPF........... 15 96 6.1. OSPFv3 Extension to carry the App-Metrics........ 16 97 6.2. OSPFv2 Extension to advertise the IP Layer App- 98 Metrics............................................... 17 99 6.3. IP Layer App-Metrics Sub-TLVs.................... 18 100 7. Manageability Considerations.......................... 20 101 8. Security Considerations............................... 20 102 9. IANA Considerations................................... 20 103 10. References........................................... 20 104 10.1. Normative References............................ 21 105 10.2. Informative References.......................... 21 106 11. Acknowledgments...................................... 22 108 1. Introduction 110 This document describes an IS-IS and OSPF extension to 111 advertise the indexes of the running environment, a.k.a. 112 Site-Cost, for the directly attached 5G Edge Computing 113 servers. The goal is for other routers in the 5G Local Data 114 Network (LDN) to optimize the forwarding of flows from UEs 115 and to improve latency and performance for 5G Edge 116 Computing services. 118 In a nutshell, one application can be instantiated on 119 multiple servers close in proximity. Those multiple server 120 instances can share one IP address (ANYCAST) so that 121 traffic can be forwarded in consideration of transient 122 network and load conditions. 124 1.1. 5G Edge Computing Background 126 As described in [3GPP-EdgeComputing], it is desirable for a 127 mission-critical application to be hosted on multiple 128 servers attached to different edge routers to minimize 129 latency and optimize the user experience. Those App Servers 130 are usually hosted very close to or co-located with 5G base 131 stations. 133 When a UE (User Equipment) initiates application packets 134 using the destination address from a DNS reply or its 136 Internet-Draft OSPF Extension for 5G EC Service 138 cache, the packets from the UE are carried in a PDU session 139 through 5G Core [5GC] to the 5G UPF-PSA (User Plan Function 140 - PDU Session Anchor). The UPF-PSA decapsulates the 5G GTP 141 outer header and forwards the packets from the UEs to the 142 Ingress router of the Edge Computing (EC) Local Data 143 Network (LDN), which is responsible for forwarding the 144 packets to the intended destinations. 146 When the UE moves out of coverage of its current gNB (next- 147 generation Node B) (gNB1), the handover procedure is 148 initiated, which includes the 5G SMF (Session Management 149 Function) selecting a new UPF-PSA [3GPP TS 23.501 and TS 150 23.502]. When the handover process is complete, the UE has 151 a new IP address, and the IP point of attachment is to the 152 new UPF-PSA. 5GC may maintain a path from the old UPF to 153 the new UPF for a short time for SSC [Session and Service 154 Continuity] mode 3 to make the handover process more 155 seamless. 157 Internet-Draft OSPF Extension for 5G EC Service 159 +--+ 160 |UE|---\+---------+ +------------------+ 161 +--+ | 5G | +---------+ | S1: aa08::4450 | 162 +--+ | Site +--++---+ +----+ | 163 |UE|----| A |PSA| Ra| | R1 | S2: aa08::4460 | 164 +--+ | +---+---+ +----+ | 165 +---+ | | | | | S3: aa08::4470 | 166 |UE1|---/+---------+ | | +------------------+ 167 +---+ |IP Network | L-DN1 168 |(3GPP N6) | 169 | | | +------------------+ 170 | UE1 | | | S1: aa08::4450 | 171 | moves to | +----+ | 172 | Site B | | R3 | S2: aa08::4460 | 173 v | +----+ | 174 | | | S3: aa08::4470 | 175 | | +------------------+ 176 | | L-DN3 177 +--+ | | 178 |UE|---\+---------+ | | +------------------+ 179 +--+ | 5G | | | | S1: aa08::4450 | 180 +--+ | Site +--++-+--+ +----+ | 181 |UE|----| B |PSA| Rb | | R2 | S2: aa08::4460 | 182 +--+ | +--++----+ +----+ | 183 +--+ | | +-----------+ | S3: aa08::4470 | 184 |UE|---/+---------+ +------------------+ 185 +--+ L-DN2 186 Figure 1: App Servers in different edge DCs 188 1.2. Problem#1: ANYCAST in 5G EC Environment 190 ANYCAST makes it possible to load balance across server 191 locations based on network conditions dynamically. With 192 multiple servers having the same ANYCAST address, it 193 eliminates the single point of failure and bottleneck at 194 the application layer load balancers. Another benefit of 195 using ANYCAST address is removing the dependency on how UEs 196 get the IP addresses for their Applications. Some UEs (or 197 clients) might use stale cached IP addresses for an 198 extended period. 200 But, having multiple locations of the same ANYCAST address 201 in the 5G Edge Computing environment can be problematic 203 Internet-Draft OSPF Extension for 5G EC Service 205 because all those edge computing Data Centers can be close 206 in proximity. There might be very little difference in the 207 routing distance to reach the Application Servers attached 208 to a different edge router, which can cause packets from 209 one flow to be forwarded to different locations, resulting 210 in service glitches. 212 1.3. Problem #2: Unbalanced Anycast Distribution due to UE 213 Mobility 215 UEs' frequent moving from one 5G site to another can make 216 it difficult to plan where the App Servers should be 217 hosted. When one App server is heavily utilized, other App 218 servers of the same address close by can be under-utilized. 219 The difference in the routing distance to reach multiple 220 Application Servers might be relatively small. The network 221 cost, the traffic load at the router where the App Server 222 is attached, and the site capacity, when combined, are more 223 significant from the latency and performance perspective. 225 Since the condition can be short-lived, it is difficult for 226 the application controller to anticipate the moving and 227 adjusting. 229 1.4. Problem 3: Application Server Relocation 231 When an Application Server is added to, moved, or deleted 232 from a 5G Edge Computing server site (mini-DC), not only 233 the reachability changes but also the utilization and 234 capacity for the site might change. 236 Note: for the ease of description, the Edge Computing 237 server, Application server, App server are used 238 interchangeably throughout this document. 240 2. Conventions used in this document 242 A-ER: Egress Edge Router to an Application Server, 243 [A-ER] is used to describe the last router that 244 the Application Server is attached. For 5G EC 245 environment, the A-ER can be the gateway router 246 to a (mini) Edge Computing Data Center. 248 Internet-Draft OSPF Extension for 5G EC Service 250 Application Server: An application server is a physical or 251 virtual server that hosts the software system 252 for the application. 254 Application Server Location: Represent a cluster of servers 255 at one location serving the same Application. 256 One application may have a Layer 7 Load 257 balancer, whose address(es) are reachable from 258 an external IP network, in front of a set of 259 application servers. From IP network 260 perspective, this whole group of servers is 261 considered as the Application server at the 262 location. 264 Edge Application Server: used interchangeably with 265 Application Server throughout this document. 267 EC: Edge Computing 269 Edge Hosting Environment: An environment providing the 270 support required for Edge Application Server's 271 execution. 273 NOTE: The above terminologies are the same as 274 those used in 3GPP TR 23.758 276 Edge DC: Edge Data Center, which provides the Edge 277 Computing Hosting Environment. It might be co- 278 located with 5G Base Station and not only host 279 5G core functions, but also host frequently 280 used Edge server instances. 282 gNB next generation Node B 284 LDN: Local Data Network 286 PSA: PDU Session Anchor (UPF) 288 SSC: Session and Service Continuity 290 UE: User Equipment 292 Internet-Draft OSPF Extension for 5G EC Service 294 UPF: User Plane Function 296 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 297 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 298 RECOMMENDED", "MAY", and "OPTIONAL" in this document are to 299 be interpreted as described in BCP 14 [RFC2119] [RFC8174] 300 when, and only when, they appear in all capitals, as shown 301 here. 303 3. Solution Overview 305 From IP Layer, the Application Servers are identified by 306 their IP (ANYCAST) addresses. To a router, having multiple 307 servers with the same (ANYCAST) address attached to 308 different egress edge routers (A-ER) is the same as having 309 multiple paths to reach the (ANYCAST) address. 311 The proposed solution is for the egress edge router (A-ER) 312 to which the Application Servers are attached to advertise 313 the "Site-Cost" [Section 3.2] to other routers in 5G EC 314 LDN. The routers in LDN can consider the "Site-Cost" in 315 computing the optimal path to the App Server directly 316 attached to the A-ER. 318 The solution assumes that the 5G Edge Computing controller 319 or management system is aware of the ANYCAST addresses that 320 need optimized forwarding. To minimize the processing, only 321 the applications that match with the ACLs configured by the 322 5G Edge Computing controller will have their Site-Cost 323 collected and advertised. 325 3.1. Flow Affinity to an ANYCAST server 327 In an environment where multiple servers with the same 328 (ANYCAST) address are attached to different A-ERs, Flow 329 Affinity means routers sending the packets of the same flow 330 to the same A-ER even if the cost towards the A-ER is no 331 longer optimal. 333 Today, many commercial routers support some forms of flow 334 affinity to ensure packets belonging to one flow be 335 forwarded along the same path. 337 Internet-Draft OSPF Extension for 5G EC Service 339 Editor's note: for IPv6 traffic, Flow Affinity can be 340 supported by the routers forwarding the packets with the 341 same Flow Label in the packets' IPv6 Header along the same 342 path towards the same egress edge router. 344 3.2. IP Layer Metrics to Gauge App Server Running Status 346 Most applications do not expose their internal logic to the 347 network. Their communications are generally encrypted. Most 348 of them do not even respond to PING or ICMP messages 349 initiated by routers or network gears. 351 [5G-EC-Metrics] describes the IP Layer Metrics that can 352 gauge the application servers running status and 353 environment: 355 - IP-Layer Metric for App Server Load Measurement: 356 The Load Measurement to an App Server is a weighted 357 combination of the number of packets/bytes to the App 358 Server and the number of packets/bytes from the App 359 Server which are collected by the A-ER that has the 360 direct connection to the App Server. 361 The A-ER is configured with an ACL that can filter out 362 the packets for the Application Server. 363 - Capacity Index: 364 Capacity Index is used to differentiate the running 365 environment of the attached application server. Some 366 data centers can have hundreds, or thousands, of 367 servers behind an application server's App Layer Load 368 Balancer. Other data centers can have a very small 369 number of servers for the application. "Capacity 370 Index", which is a numeric number, is used to 371 represent the capacity of the application server 372 attached to an A-ER. 373 - Site preference index: 374 [IPv6-StickyService] describes a scenario that some 375 sites are more preferred for handling an application 376 than others for flows from a specific UE. 378 For ease of description, those metrics with more to be 379 added later are called IP Layer Site-Cost throughout the 380 document. 382 Internet-Draft OSPF Extension for 5G EC Service 384 3.3. To Equalize traffic among Multiple ANYCAST Locations 386 The main benefit of using ANYCAST is to leverage the 387 network layer information to balance the traffic among 388 multiple Application Server locations. 390 For the 5G Edge Computing environment, the routers in the 391 LDN need to be notified of various measurements of the App 392 Servers attached to each A-ER to make the intelligent 393 decision on where to forward the traffic for the 394 application from UEs. 396 [5G-EC-Metrics] describes the algorithms that the routers 397 in LDN can use to compare the cost to reach the App Servers 398 between the Site-i or Site-j: 400 Load-i * CP-j Pref-j * Network-Delay-i 401 Cost-i=min(w *(----------------) + (1-w) *(-------------------------)) 402 Load-j * CP-i Pref-i * Network-Delay-j 404 Load-i: Load Index at Site-i, it is the weighted 405 combination of the total packets or/and bytes sent to 406 and received from the Application Server at Site-i 407 during a fixed time period. 409 CP-i: capacity index at site I, a higher value means 410 higher capacity. 412 Network Delay-i: Network latency measurement (RTT) to 413 the A-ER that has the Application Server attached at the 414 site-i. 415 Noted: Ingress nodes can easily measure RTT to all the 416 egress edge nodes by existing IPPM metrics. But it is 417 not so easy for ingress nodes to measure RTT to all the 418 App Servers. Therefore, "Network-Delay-i", a.k.a. 419 Network latency measurement (RTT), is between the 420 Ingress and egress edge nodes. The link cost between the 421 egress edge nodes to their attached servers is embedded 422 in the "capacity index". 424 Pref-i: Preference index for site-i, a higher value 425 means higher preference. 427 w: Weight for load and site information, which is a 428 value between 0 and 1. If smaller than 0.5, Network 429 latency and the site Preference have more influence; 431 Internet-Draft OSPF Extension for 5G EC Service 433 otherwise, Server load and its capacity have more 434 influence. 436 3.4. Reason for using IGP Based Solution 438 Here are some benefits of using IGP to propagate the IP 439 Layer App-Metrics: 440 - Intermediate routers can derive the aggregated cost to 441 reach the Application Servers attached to different 442 egress edge nodes, especially: 443 - The path to the optimal egress edge node can be 444 more accurate or shorter. 445 - Convergence is shorter when there is any failure 446 along the way towards the optimal ANYCAST server. 447 - When there is any failure at the intended ANYCAST 448 server, all the packets in transit can be optimally 449 forwarded to another App Server attached to a 450 different egress edge router. 451 - Doesn't need the ingress nodes to establish tunnels with 452 egress edge nodes. 454 There are limitations of using IGP too, such as: 456 - The IGP approach might not suit well to 5G EC LDN 457 operated by multiple ISPs. 458 For LDN operated by multiple IPSs, BGP should be used. 459 AppMetaData NLRI Path Attribute [5G-AppMetaData] 460 describes the BGP UPDATE message to propagate IP Layer 461 App-Metrics crossing multiple ISPs. 463 4. IS-IS Extension 465 The Application-Specific Link Attribute sub-TLV described 466 in [RFC8919] can be used to carry the "Site-Cost" for the 467 App server directly attached to the router. 469 When carrying the "Site-Cost" sub-sub TLVs, the App 470 specific Link Attribute sub-TLV can be included in TLV 22 471 (extended IS reachability), 23 (IS Neighbor Attribute), or 472 25(L2 bundle Member Attribute). 474 The Site-Cost bit is added to the Standard Applications Bit 475 Mask (SABM). 477 0 1 2 3 4 5 6 7 ... 478 +-+-+-+-+-+-+-+-+... 480 Internet-Draft OSPF Extension for 5G EC Service 482 |R|S|F|C| ... 483 +-+-+-+-+-+-+-+-+... 484 Figure 2: Extended Application Identifier Bit Mask 486 C-bit: set to specify the Site Cost related sub-sub TLVs, 487 described in the Section 3.2, are included in the App- 488 Specific Sub-TLV. 490 The R-bit, S-bit, F-bit are specified by the RFC8919. 492 The Extended App Specific Link Attributes Sub-TLV is as 493 following: 495 Type: 16 496 Length: (1 octet) 497 Value: 498 Extended Application Identifier Bit Mask [Figure 2] 499 Site-Cost sub-sub-TLVs - described in the following 500 sections. 502 4.1. IS-IS extension for the Aggregated cost 504 If egress edge routers to which the App Servers are 505 directly attached can get the aggregated cost, the 506 Aggregated cost sub-sub-TLV can be directly appended to the 507 App Specific Bit Mask. 509 The aggregated cost can be from App controller or from a 510 consistent algorithm that considers the Load Measurement, 511 Capacity value, and Preference value across all A-ERs. 513 Internet-Draft OSPF Extension for 5G EC Service 515 0 1 2 3 516 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 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 |AggCostSubTLV | Length | AggCost to the App Server | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | PrefixLength | PrefixOptions | 0 | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | Address Prefix | 523 | ... | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 Figure 3: Aggregated Cost to App Server 527 4.2. IS-IS extension for IP Layer App-Metrics Advertisements 529 This section describes the sub-sub TLVs that carry the 530 detailed IP Layer Metrics when the A-ERs in the domain do 531 not have a consistent algorithm to compute the aggregated 532 cost or the detailed IP Layer metrics for the App Servers 533 are needed for other purposes. 535 It worth noting that not all hosts (prefix) attached to an 536 A-ER are ANYCAST servers that need network optimization. 537 An A-ER only needs to advertise the site-Cost Metrics for 538 the ANYCAST addresses requested by the Controller. 540 Draft [draft-wang-lsr-passive-interface-attribute] 541 introduces the Stub-Link TLV for OSPFv2/v3 and ISIS 542 protocol respectively. Considering the interfaces on an 543 edge router that connects to the App servers are normally 544 configured as passive interfaces, these IP-layer App- 545 metrics can also be advertised as the attributes of the 546 passive/stub link. The associated prefixes can then be 547 advertised in the "Stub-Link Prefix Sub-TLV" that is 548 defined in [draft-wang-lsr-passive-interface-attribute]. 549 All the associated prefixes share the same characteristic 550 of the link. Other link related sub-TLVs defined in 551 [RFC8920] can also be attached and applied to the 552 calculation of path to the associated prefixes. 554 4.3. IS-IS App-Metrics SubTLVs for IPv6 attachment 556 For App Servers using IPv6, the App-Metrics subTLV is 557 encoded as below: 559 Internet-Draft OSPF Extension for 5G EC Service 561 0 1 2 3 562 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 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | App-Metrics IPv6 subTLV Type | Length | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | IPv6 AppServer (ANYCAST) address | 567 ~ ~ 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | Load measurement sub-TLV | 570 ~ ~ 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | Capability sub-TLV | 573 ~ ~ 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | Preference sub-TLV | 576 ~ ~ 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 Figure 3: IPv6 App Server App-Metrics Encoding 580 4.4. IS-IS IP Layer App-Metrics for IPv4 582 Here is the proposed encoding for App Servers using IPv4 583 addresses: 585 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 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 | App-Metrics IPv4 subTLV Type | Length | 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 | Address Prefix (variable) | 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 | Load Measurement Sub-TLV | 592 ~ ~ 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | capacity Index Sub-TLV | 595 ~ ~ 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | Site Preference Sub-TLV | 598 ~ ~ 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 Figure 4: App-Metrix Sub-TLVs for IPv4 602 5. Aggregated Cost Advertisement in OSPF 604 If all egress edge routers that have a direct connection to 605 the App Servers can get a periodic update of the aggregated 607 Internet-Draft OSPF Extension for 5G EC Service 609 cost to the App Servers or can be configured with a 610 consistent algorithm to compute an aggregated cost that 611 takes into consideration the Load Measurement, Capacity 612 value, and Preference value, this aggregated cost can be 613 considered as the Metric of the link to the App Server. 615 In this scenario, there is no protocol extension needed. 617 5.1. OSPFv3 LSA to carry the Aggregated Cost 619 If the App Servers use IPv6 ANYCAST address, the aggregated 620 cost computed by the egress edge routers can be encoded in 621 the Metric field [the interface cost] of Intra-Area-Prefix- 622 LSA specified by Section 3.7 of the [ RFC5340]. 624 0 1 2 3 625 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 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | 6 (Intra-Area Prefix) | TLV Length | 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 | 0 | Aggregated Cost to the App Server | 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 | PrefixLength | PrefixOptions | 0 | 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 | Address Prefix | 634 | ... | 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 Figure 5: Aggregated Cost to App Server 638 5.2. OSPFv2 LSA to carry the Aggregated Cost 640 For App Servers in IPv4 address, the Aggregated Cost can be 641 encoded in the "Metric" field of the Stub Link LSA [Link 642 type =3] specified by Section 12.4 of the [RFC2328]. 644 6. IP Layer App-Metrics Advertisements by OSPF 646 This section describes the OSPF extension that can carry 647 the detailed IP Layer Metrics when it is not possible for 648 all the egress edge routers to have a consistent algorithm 649 to compute the aggregated cost or some routers need all the 650 detailed IP Layer metrics for the App Servers for other 651 purposes. 653 Since only a subset of routers within an IGP domain need to 654 know those detailed metrics, it makes sense to use the 655 OSPFv2 Extended Prefix Opaque LSA for IPv4 and OSPFv3 657 Internet-Draft OSPF Extension for 5G EC Service 659 Extended LSA with Intra-Area-Prefix TLV to carry the 660 detailed sub-TLVs. For routers that don't care about those 661 metrics, they can ignore them very easily. 663 It worth noting that not all hosts (prefix) attached to an 664 A-ER are ANYCAST servers that need network optimization. 665 An A-ER only needs to advertise the App-Metrics for the 666 ANYCAST addresses that match with the configured ACLs. 668 Draft [draft-wang-lsr-passive-interface-attribute] 669 introduces the Stub-Link TLV for OSPFv2/v3 and ISIS 670 protocol respectively. Considering the interfaces on an 671 edge router that connects to the App servers are normally 672 configured as passive interfaces, these IP-layer App- 673 metrics can also be advertised as the attributes of the 674 passive/stub link. The associated prefixes can then be 675 advertised in the "Stub-Link Prefix Sub-TLV" that is 676 defined in [draft-wang-lsr-passive-interface-attribute]. 677 All the associated prefixes share the same characteristic 678 of the link. Other link related sub-TLVs defined in 679 [RFC8920] can also be attached and applied to the 680 calculation of path to the associated prefixes. 682 6.1. OSPFv3 Extension to carry the App-Metrics 684 For App Servers using IPv6, the OSPFv3 Extended LSA with 685 the Intra-Area-Prefix Address TLV specified by the Section 686 3.7 of RFC8362 can be used to carry the App-Metrics for the 687 attached App Servers. 689 Internet-Draft OSPF Extension for 5G EC Service 691 0 1 2 3 692 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 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 |7 (IPv6 Local-Local Address) | Length | 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 | IPv6 AppServer (ANYCAST) address | 697 ~ ~ 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 | Load measurement sub-TLV | 700 ~ ~ 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 | Capability sub-TLV | 703 ~ ~ 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 | Preference sub-TLV | 706 ~ ~ 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 Figure 6: IPv6 App Server App-Metrics Encoding 710 6.2. OSPFv2 Extension to advertise the IP Layer App-Metrics 712 For App Servers using IPv4 addresses, the OSPFv2 Extended 713 Prefix Opaque LSA with the extended Prefix TLV can be used 714 to carry the App Metrics sub-TLVs, as specified by the 715 Section 2.1 [RFC7684]. 717 Internet-Draft OSPF Extension for 5G EC Service 719 Here is the proposed encoding: 721 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 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 | Type | Length | 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 | Route Type | Prefix Length | AF | Flags | 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 | Address Prefix (variable) | 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 | Load Measurement Sub-TLV | 730 ~ ~ 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 | capacity Index Sub-TLV | 733 ~ ~ 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 | Site Preference Sub-TLV | 736 ~ ~ 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 Figure 7: App-Metrix Sub-TLVs in OSPFv2 Extended Prefix TLV 740 6.3. IP Layer App-Metrics Sub-TLVs 742 Two types of Load Measurement Sub-TLVs are specified: 744 a) The Aggregated Load Index based on a weighted 745 combination of the collected measurements; 746 b) The raw measurements of packets/bytes to/from the App 747 Server address. The raw measurement is useful when the 748 egress edge routers cannot be configured with a 749 consistent algorithm to compute the aggregated load 750 index or the raw measurements are needed by a central 751 analytic system. 753 The Aggregated Load Index Sub-TLV has the following format: 755 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 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 | Type (TBD2) | Length | 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 | Measurement Period | 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 | Aggregated Load Index to reach the App Server | 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 Figure 8: Aggregated Load Index Sub-TLV 765 Internet-Draft OSPF Extension for 5G EC Service 767 Type=TBD2 (to be assigned by IANA) indicates that the 768 sub-TLV carries the Aggregated Load Measurement Index 769 derived from the Weighted combination of bytes/packets 770 sent to/received from the App server: 772 Index=w1*ToPackets+w2*FromPackes+w3*ToBytes+w4*FromBytes 774 Where wi is a value between 0 and 1; w1+ w2+ w3+ w4 = 1. 776 The Raw Load Measurement sub-TLV has the following format: 778 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 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 | Type (TBD3) | Length | 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 | Measurement Period | 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 | total number of packets to the AppServer | 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 | total number of packets from the AppServer | 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 | total number of bytes to the AppServer | 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 | total number of bytes from the AppServer | 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 Figure 9: Raw Load Measurement Sub-TLV 794 Type= TBD3 (to be assigned by IANA) indicates that the 795 sub-TLV carries the Raw measurements of packets/bytes 796 to/from the App Server ANYCAST address. 798 Measurement Period: A user-specified period in seconds, 799 default is 3600 seconds. 801 The Capacity Index sub-TLV has the following format: 803 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 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 | Type (TBD3) | Length | 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 | Capacity Index | 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 Figure 10: Capacity Index Sub-TLV 811 Internet-Draft OSPF Extension for 5G EC Service 813 The Preference Index sub-TLV has the following format: 815 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 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 | Type (TBD4) | Length | 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 819 | Preference Index | 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 Figure 11: Preference Index Sub-TLV 823 Note: "Capacity Index" and "Site preference" can be more 824 stable for each site. If those values are configured to 825 nodes, they might not need to be included in every OSPF 826 LSA. 828 7. Manageability Considerations 830 To be added. 832 8. Security Considerations 834 To be added. 836 9. IANA Considerations 838 The following Sub-TLV types need to be added by IANA 839 to OSPFv4 Extended-LSA Sub-TLVs and OSPFv2 Extended 840 Link Opaque LSA TLVs Registry. 842 - Aggregated Load Index Sub-TLV type 843 - Raw Load Measurement Sub-TLV type 844 - Capacity Index Sub-TLV type 845 - Preference Index Sub-TLV type 847 10. References 848 Internet-Draft OSPF Extension for 5G EC Service 850 10.1. Normative References 852 [RFC2119] Bradner, S., "Key words for use in RFCs to 853 Indicate Requirement Levels", BCP 14, RFC 2119, 854 March 1997. 856 [RFC2328] J. Moy, "OSPF Version 2", RFC 2328, April 1998. 858 [RFC7684] P. Psenak, et al, "OSPFv2 Prefix/Link Attribute 859 Advertisement", RFC 7684, Nov. 2015. 861 [RFC8200] S. Deering R. Hinden, "Internet Protocol, Version 862 6 (IPv6) Specification", July 2017. 864 [RFC8326] A. Lindem, et al, "OSPFv3 Link State 865 advertisement (LSA0 Extensibility", RFC 8362, 866 April 2018. 868 10.2. Informative References 870 [3GPP-EdgeComputing] 3GPP TR 23.748, "3rd Generation 871 Partnership Project; Technical Specification 872 Group Services and System Aspects; Study on 873 enhancement of support for Edge Computing in 5G 874 Core network (5GC)", Release 17 work in progress, 875 Aug 2020. 877 [5G-AppMetaData] L. Dunbar, K. Majumdar, H. Wang, "BGP NLRI 878 App Meta Data for 5G Edge Computing Service", 879 draft-dunbar-idr-5g-edge-compute-app-meta-data- 880 01, work-in-progress, Nov 2020. 882 [5G-EC-Metrics] L. Dunbar, H. Song, J. Kaippallimalil, "IP 883 Layer Metrics for 5G Edge Computing Service", 884 draft-dunbar-ippm-5g-edge-compute-ip-layer- 885 metrics-01, work-in-progress, Nov 2020. 887 [5G-StickyService] L. Dunbar, J. Kaippallimalil, "IPv6 888 Solution for 5G Edge Computing Sticky Service", 889 draft-dunbar-6man-5g-ec-sticky-service-00, work- 890 in-progress, Oct 2020. 892 Internet-Draft OSPF Extension for 5G EC Service 894 [RFC5521] P. Mohapatra, E. Rosen, "The BGP Encapsulation 895 Subsequent Address Family Identifier (SAFI) and 896 the BGP Tunnel Encapsulation Attribute", April 897 2009. 899 [BGP-SDWAN-Port] L. Dunbar, H. Wang, W. Hao, "BGP Extension 900 for SDWAN Overlay Networks", draft-dunbar-idr- 901 bgp-sdwan-overlay-ext-03, work-in-progress, Nov 902 2018. 904 [SDWAN-EDGE-Discovery] L. Dunbar, S. Hares, R. Raszuk, K. 905 Majumdar, "BGP UPDATE for SDWAN Edge Discovery", 906 draft-dunbar-idr-sdwan-edge-discovery-00, work- 907 in-progress, July 2020. 909 [Tunnel-Encap] E. Rosen, et al "The BGP Tunnel 910 Encapsulation Attribute", draft-ietf-idr-tunnel- 911 encaps-10, Aug 2018. 913 11. Acknowledgments 915 Acknowledgements to Acee Lindem, Gyan Mishra, Jeff 916 Tantsura, and Donald Eastlake for their review and 917 suggestions. 919 This document was prepared using 2-Word-v2.0.template.dot. 921 Internet-Draft OSPF Extension for 5G EC Service 923 Authors' Addresses 925 Linda Dunbar 926 Futurewei 927 Email: ldunbar@futurewei.com 929 Huaimo Chen 930 Futurewei 931 Email: huaimo.chen@futurewei.com 933 Aijun Wang 934 China Telecom 935 Email: wangaj3@chinatelecom.cn