idnits 2.17.1 draft-kjsun-lisp-dyncast-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) 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 has text resembling RFC 2119 boilerplate text. -- The document date (9 August 2021) is 990 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 6830 (Obsoleted by RFC 9300, RFC 9301) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Sun 3 Internet-Draft Y. Kim 4 Intended status: Informational Soongsil University 5 Expires: 10 February 2022 9 August 2021 7 LISP Support for Dynamic Anycast Routing 8 draft-kjsun-lisp-dyncast-00 10 Abstract 12 This draft describes the LISP-based architecture and solutions for 13 supporting dynamic anycast (Dyncast) routing. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on 10 February 2022. 32 Copyright Notice 34 Copyright (c) 2021 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 39 license-info) in effect on the date of publication of this document. 40 Please review these documents carefully, as they describe your rights 41 and restrictions with respect to this document. Code Components 42 extracted from this document must include Simplified BSD License text 43 as described in Section 4.e of the Trust Legal Provisions and are 44 provided without warranty as described in the Simplified BSD License. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 49 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 50 3. Architecture Overview . . . . . . . . . . . . . . . . . . . . 2 51 4. Addressing Dyncast Requirements with LISP . . . . . . . . . . 6 52 4.1. Anycast-based Service Addressing . . . . . . . . . . . . 6 53 4.2. Instance Affinity . . . . . . . . . . . . . . . . . . . . 6 54 4.3. Encoding and Signaling of Metric . . . . . . . . . . . . 7 55 4.4. Dynamic Routing Decisions based using Metrics . . . . . . 7 56 4.5. Supporting Service Dynamism . . . . . . . . . . . . . . . 8 57 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 58 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 59 6.1. Informative References . . . . . . . . . . . . . . . . . 8 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 62 1. Introduction 64 In an environment where equivalent services are distributed in 65 multiple geographic locations, Dynamic-Anycast (Dyncast) enables to 66 perform resource-efficient anycast routing. To support Dyncast, 67 according to [draft-liu-dyncast-ps-usecases], a unique service 68 identifier that can be assigned to multiple instances in multiple 69 edge environments should be able to be mapped as an actual routable 70 unicast address. Since this concept is similar to the Location/ID 71 separation method already used in the LISP design basis, the LISP 72 protocol can be considered as one of the candidate protocols that can 73 implement Dyncast. This draft is proposed to design the LISP-based 74 architecture for Dyncast and analyze the extension method of LISP to 75 meet the requirements defined in [draft-liu-dyncast-reqs] for 76 realizing dynamic anycasting between different LISP sites. 78 2. Terminology 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document is to be interpreted as described in [RFC2119]. This 83 document uses the terminology described in [RFC6830], 84 [draft-liu-dyncast-ps-usecases], [draft-liu-dyncast-reqs]. 86 3. Architecture Overview 88 Figure 1 describes the Dyncast architecture based on LISP. In the 89 LISP architecture [draft-ietf-lisp-introduction-13], each edge 90 network has one or more LISP routers deployed. For anycast address, 91 [RFC6830] defines that anycast address can be assigned for both 92 Endpoint ID (EID) and Routing Locator (RLOC) within each of their 93 address spaces. In this draft, we called EID for dynamic anycasting 94 as Dyncast Service ID (DSID), which is assigned to equivalent 95 services across the multiple LISP sites. Similar to the common EID 96 definition, the DSID cannot be routed globally by itself, and the 97 same DSID cannot be assigned to different services. In order to 98 forward a packet destined for a DSID between LISP edges, the 99 addresses of the LISP Egress Tunnel Router (ETR) are used as RLOC, 100 which operates as a Dyncast Binding ID (DBID) from a Dyncast 101 perspective. Map-server/resolver of the LISP control plane can 102 manage mapping information for DSID-RLOC mappings together with 103 existing EID-RLOC mappings. Differences of DSID-RLOC from existing 104 EID-RLOC mapping table, it that a single DSID can be mapped with 105 multiple RLOCs from different edge sites together. 107 For resource-efficient forwarding decisions across multiple service 108 instances, [draft-li-dyncast-architecture] defines Dyncast Metric 109 Agent (D-MA) which collects metrics related network and service 110 instances. Actual packet forwarding is handled in the Dyncast Router 111 (D-Router) based upon collected metrics with maintaining instance 112 affinity. In the LISP architecture, the D-Router function can be 113 implemented on the LISP xTR, and the D-MA can be deployed as a 114 separate component within the edge for managing service instances, or 115 it can be deployed in combination with the LISP xTR. The LISP, 116 control plane is logically centralized and it provides an interface 117 with each LISP router to exchange mapping information. However, it 118 does not mean that the LISP control plane is located in a single 119 physical location, several mechanisms for distributing the mapping 120 system already have been defined. 122 LISP Edge LISP Edge 124 +----------+ +----------+ 125 | Service | | Service | 126 | Instance | | Instance | 127 | (DBID) | | (DBID) | 128 +----------+ +----------+ 129 | +---------------------+ | 130 | | LISP Control Plane | | 131 +----------+"""""+---------------------+" | 132 | D-MA | " " " | 133 +----------+ " " " | 134 | " " " +----------+ 135 | " " " | D-MA | 136 +----------+" " +--------------------+ "+----------+ 137 | LISP-xTR |DBID" | Core Network |DBID | LISP-xTR | 138 |(D-Router)|----"-| (RLOC-Space) |------|(D-Router)| 139 +----------+ " +--------------------+ +----------+ 140 | " |DBID | 141 | "+--------------------+ | 142 | | LISP-xTR (D-Router)| | 143 | +--------------------+ | 144 +----------+ | +----------+ 145 | Client | +----------+ | Client | 146 | (EID) | | Client | | (EID) | 147 +----------+ | (EID) | +----------+ 148 +----------+ 150 LISP Edge 152 Figure 1: LISP-based Dyncast Architecture 154 Figure 2 shows an example of LISP-based Dyncast deployment where two 155 services each deployed two instances at different edges. In this 156 scenario, two services are assigned an RLOC according to the ETR 157 address of the LISP site. Both Service_A and Service_B instances 158 connected to ETR_2 are assigned RLOC2, which is the RLOC of ETR_2, as 159 a binding ID. In the case of the edge where ETR_2 is located, as an 160 edge composed only of service instances, the LISP Router function can 161 be operated by being strongly coupled to the edge computing server. 162 In this case, the D-MA function can be implemented on the ETR to 163 insert service-instance-related metrics directly into the LISP 164 protocol packet. In case that a service instance and a client co- 165 exist like an edge where ETR_3 is located, the D-MA entity can be 166 independently deployed proximity of the service instance is running, 167 transparent from the LISP operation for clients. Mapping information 168 update for DSID is performed through the LISP protocol Map-Register 169 message, and service-instance-related metric can be delivered through 170 in the LISP protocol header or other methods. A method of inserting 171 service-instance-related metric information into the LISP protocol 172 will be discussed later. When the ITR_1 receives a packet destined 173 for the DSID of the service by service request from the Host_1, the 174 ITR can acquire the RLOC mapped to the requested DSID from the LISP 175 control-plane through the Map-Request message. At the control plane, 176 it may select an proper DBID address on the collected metric 177 information and return it to the ITR or return the DBID list of 178 multiple service instances with metric information to the ITR so the 179 ITR selects the proper DBID in the list. A method for determining an 180 appropriate DBID will be discussed later. 182 Service_A 183 +------+ 184 Map-Register D-Router +-|DSID_A| 185 (DSID_A, DBID2, ) +-------+------+ | +------+ 186 (DSID_B, DBID2, ,metric>) | ETR_2 | D-MA |-| 187 +-------+------+ | +------+ 188 | +-|DSID_B| 189 +------------------+ | RLOC2 +------+ 190 Host_1 D-Router | +--------------+ |--+(DBID2) Service_B 191 +--------+ +-------+ | | LISP | | 192 | EID_H1 |--| ITR_1 |----| | Control Plane| | 193 +--------+ +-------+ | +--------------+ | 194 RLOC1| RLOC-Space |--+ RLOC3 195 +------------------+ |(DBID3) 196 D-Router Host_2 197 Map-Register +-------+ +--------+ 198 (DSID_A, DBID3, ) | ETR_3 |---| EID_H2 | 199 (DSID_B, DBID3, ) +-------+ +--------+ 200 | 201 +------+ 202 | D-MA | 203 +------+ 204 | 205 +-----+-----+ 206 | | 207 +------+ +------+ 208 |DSID_A| |DSID_B| 209 +------+ +------+ 210 Service_A Service_B 212 Figure 2: LISP-based Dyncast Example Scenario 214 4. Addressing Dyncast Requirements with LISP 216 4.1. Anycast-based Service Addressing 218 To support Dyncast routing, the system must provide a method for 219 searching a service identifier allocated as an anycast address and 220 mapping it to a specific unicast address. From this point of view, 221 the LISP is a suitable protocol for separating ID/Location of service 222 and managing mapping information. When the system allocates the same 223 D-SID to each service instance for service equivalency, the LISP can 224 define an anycast address space for the DSID and assign it to service 225 instances created across multiple sites. Also, the DBID can be used 226 as an RLOC address of LISP xTR that can be routed between edges as 227 unicast. That is, it is necessary to define a separate space for 228 anycast address within the existing EID space and to allocate it in 229 advance so that it can be used in all edge networks where the service 230 instances are located. In the LISP definition, the EID assigned to 231 each service has a globally unique value and, in particular, 232 [RFC6830] defines that anycast address can be assigned within an EID 233 or RLOC block spaces. In each LISP site, same as the EID which is 234 defined to enable internal routing, the DSID can be able to be routed 235 without the DBID encapsulation process to the EID within a single 236 site. 238 4.2. Instance Affinity 240 For Dyncast routing, it is required that the system must set 241 "Instance Affinity" for one or several service requests to provide 242 routing to the same service instance for the same flow. In LISP, the 243 RLOC mapping information for the destination EID is stored in a local 244 cache called Map-cache in the ITR for a certain period of time, and 245 it is maintained for a set time-to-live (TTL) time. Therefore, 246 mapping information for a specific service once requested from a 247 client is generally maintained in the ITR until the corresponding 248 session expires and can be delivered to the RLOC stored in the map- 249 cache entry. However, in order to have a flexible selection of 250 service instances between different flows at the same point, it is 251 additionally required to assign different RLOCs for different flows 252 depending on metrics dynamically changed. For that, it is necessary 253 to enhance ITR Map-cache to maintain destination RLOC for each flow. 254 In addition, although the general TTL value in LISP ITR is defined as 255 24 hours, in Dyncast the system requires a shorter TTL time for 256 changing network path depending on dynamically updated network- 257 related and service-instance-related metrics. 259 4.3. Encoding and Signaling of Metric 261 In Dyncast routing, the one of most important requirements is that it 262 should be able to collect various metrics of service-instances- 263 related as well as network-related, and include them in-network 264 routing decisions. For that, it is necessary to define how to 265 collect these metrics and forward them, and also where to make a 266 decision. In the LISP environment, since that the entire EID-RLOC 267 mapping information is managed in the control plane, one possible 268 scenario is that the D-MA function which collects service-instance- 269 related metrics updates them to the DSID mapping entry in the LISP 270 control plane. For that, it can be used an encoding method proposed 271 in [draft-farinacci-lisp-name-encoding] that defines to insert 272 specific information such as parameters for a specific EID or RLOC 273 using an ASCII string. Using that, it is possible to encode a string 274 that is pre-defined of a specific metric to interpret in the control 275 plane and send a Map-Request message so that the control plane can 276 select an appropriate RLOC based on it. In order to insert service- 277 instance-related metrics, the D-MA must forward the DSID of the 278 requested service to the LISP ITR so that the metric can be inserted 279 into the header of the Map-Register message. This metric information 280 encoded into the Map-Register message can help the LISP control plane 281 to uses a mechanism to make a routing decision based on the metric 282 information of the requested or updated BSID. 284 4.4. Dynamic Routing Decisions based using Metrics 286 The Dyncast system is required that in must make routing decisions 287 for all service requests, and this must be done under an 288 understanding of all metrics. Routing decisions in the LISP can be 289 done in the control plane or ITR by specifying priority and weight 290 values for each RLOC. In case that routing decisions are made in the 291 control plane, the Map-Resolver dynamically sets the priority and 292 weight values of each mapped DBIDs collected from D-MAs, selects a 293 proper DBID based on them, and forward it to the requested ITR using 294 the Map-Reply message. However, since this centralized approach may 295 not be calculated based on point of requested ITR, the actual routing 296 path may not be optimal. In case that routing decision is determined 297 at the ITR, the LISP control plane may return one or more DBID values 298 for the requested DSID to the ITR, including priority and weight 299 values based on the collected metrics. After receiving multiple 300 DBIDs, the ITR stores them in map-cache entry and selects an 301 appropriate one to forward the data packet. For that, a mechanism 302 for estimating appropriate priority and weight values based on both 303 network-related and service-instance-related metrics is required for 304 the control plane or ITR. 306 In the Dyncast architecture described in 307 [draft-li-dyncast-architecture], the D-Router collects metrics by 308 exchanging metric information of the service identifier between 309 another edge D-Routers and make a decision itself. This approach can 310 minimize the signaling for routing decisions by decentralizing the 311 authority for the anycast routing decision to an entity in the actual 312 packet path, but the signaling for collecting metrics between each 313 D-Router is bound to increase. In contrast, when the LISP is used, 314 it can reduce effectively signaling of collecting metrics from the 315 ITR since that the mapping information for D-SID and D-BID can be 316 managed in a centralized control plane. 318 4.5. Supporting Service Dynamism 320 For service dynamism, the Dyncast system should support different 321 selections for each flow according to a dynamically changing metric 322 while considering various requirements in the selection of a service 323 instance. As mentioned in Section 4.2, if the map-cache can be 324 maintained for each flow, the forwarding path can be dynamically 325 changed to the different service instances by allocating target DBID 326 to the map-cache entry per-flow according to dynamic changes of 327 metrics. In order to refresh the DSID-DBID mapping upon changing 328 metric, the Solicit Map-Request message can be used to update so that 329 the ITR can update the weight and priority for the DBID which is 330 already received from the Map-server. Additionally, as proposed in 331 [draft-farinacci-lisp-telemetry], telemetry data can be collected 332 between Encapsulating/Decapsulating xTRs of the current flow, which 333 is expected to be used for dynamic service path reselection. 335 5. Security Considerations 337 TBD 339 6. References 341 6.1. Informative References 343 [draft-farinacci-lisp-name-encoding] 344 Farinacci, D., "LISP Distinguished Name Encoding", May 345 2021, . 348 [draft-farinacci-lisp-telemetry] 349 Farinacci, D., Ouissal, S., and E. Nordmark, "LISP Data- 350 Plane Telemetry", May 2021, 351 . 354 [draft-ietf-lisp-introduction-13] 355 Cabellos, A. and D. Saucez, "An Architectural Introduction 356 to the Locator/ID Separation Protocol (LISP)", April 2015, 357 . 360 [draft-li-dyncast-architecture] 361 Li, Y., Iannone, L., Trossen, D., and P. Liu, "Dynamic- 362 Anycast Architecture", February 2021, 363 . 366 [draft-liu-dyncast-ps-usecases] 367 Liu, P., Willis, P., and D. Trossen, "Dynamic-Anycast 368 (Dyncast) Use Cases & Problem Statement", February 2021, 369 . 372 [draft-liu-dyncast-reqs] 373 Liu, P., Willis, P., and D. Trossen, "Dynamic-Anycast 374 (Dyncast) Requirements", February 2021, 375 . 378 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 379 Requirement Levels", RFC 2119, March 1997, 380 . 382 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 383 Locator/ID Separation Protocol (LISP)", RFC 6830, January 384 2013, . 386 Authors' Addresses 388 Kyoungjae Sun 389 Soongsil University 390 369, Sangdo-ro, Dongjak-gu 391 Seoul 392 06978 393 Republic of Korea 395 Phone: +82 10 3643 5627 396 Email: gomjae@dcn.ssu.ac.kr 398 Younghan Kim 399 Soongsil University 400 369, Sangdo-ro, Dongjak-gu 401 Seoul 402 06978 403 Republic of Korea 405 Phone: +82 10 2691 0904 406 Email: younghak@ssu.ac.kr