| < draft-kjsun-lisp-dyncast-01.txt | draft-kjsun-lisp-dyncast-02.txt > | |||
|---|---|---|---|---|
| Network Working Group K. Sun | Network Working Group K. Sun | |||
| Internet-Draft Y. Kim | Internet-Draft ETRI | |||
| Intended status: Informational Soongsil University | Intended status: Informational Y. Kim | |||
| Expires: 28 April 2022 25 October 2021 | Expires: 30 October 2022 Soongsil University | |||
| 28 April 2022 | ||||
| LISP Support for Dynamic Anycast Routing | LISP Support for Dynamic Anycast Routing | |||
| draft-kjsun-lisp-dyncast-01 | draft-kjsun-lisp-dyncast-02 | |||
| Abstract | Abstract | |||
| Dynamic Anycast (Dyncast) is a new routing approach to support | Dynamic Anycast (Dyncast) is a new routing approach to support | |||
| equivalent services running in distributed geolocations and connect | equivalent services running in distributed geolocations and connect | |||
| to them by considering both network-related metric and service- | to them by considering both network-related metric and service- | |||
| related metric. In LISP, it is possible to support anycast EIDs and/ | related metric. In LISP, it is possible to support anycast EIDs and/ | |||
| or anycast RLOCs without any modification, so it is suitable for | or anycast RLOCs without any modification, so it is suitable for | |||
| providing dyncast routing. In this document, it describes the LISP- | providing dyncast routing. In this document, it describes the LISP- | |||
| based dyncast architecture and related standard works to meet dyncast | based dyncast architecture and related standard works to meet dyncast | |||
| skipping to change at page 1, line 37 ¶ | skipping to change at page 1, line 38 ¶ | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on 28 April 2022. | This Internet-Draft will expire on 30 October 2022. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2021 IETF Trust and the persons identified as the | Copyright (c) 2022 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
| license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
| Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
| and restrictions with respect to this document. Code Components | and restrictions with respect to this document. Code Components | |||
| extracted from this document must include Simplified BSD License text | extracted from this document must include Revised BSD License text as | |||
| as described in Section 4.e of the Trust Legal Provisions and are | described in Section 4.e of the Trust Legal Provisions and are | |||
| provided without warranty as described in the Simplified BSD License. | provided without warranty as described in the Revised BSD License. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
| 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 3. Architecture Overview . . . . . . . . . . . . . . . . . . . . 3 | 3. Architecture Overview . . . . . . . . . . . . . . . . . . . . 3 | |||
| 4. Addressing Dyncast Requirements with LISP . . . . . . . . . . 7 | 4. Addressing Dyncast Requirements with LISP . . . . . . . . . . 6 | |||
| 4.1. Anycast-based Service Addressing . . . . . . . . . . . . 7 | 4.1. Anycast-based Service Addressing . . . . . . . . . . . . 6 | |||
| 4.2. Instance Affinity . . . . . . . . . . . . . . . . . . . . 8 | 4.2. Instance Affinity . . . . . . . . . . . . . . . . . . . . 7 | |||
| 4.3. Encoding and Signaling of Metric . . . . . . . . . . . . 9 | 4.3. Encoding and Signaling of Metric . . . . . . . . . . . . 8 | |||
| 4.4. Dynamic Routing Decisions based using Metrics . . . . . . 10 | 4.4. Dynamic Routing Decisions based using Metrics . . . . . . 9 | |||
| 4.5. Supporting Service Dynamism . . . . . . . . . . . . . . . 11 | 4.5. Supporting Service Dynamism . . . . . . . . . . . . . . . 10 | |||
| 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 | 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 | |||
| 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 | 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
| 6.1. Informative References . . . . . . . . . . . . . . . . . 11 | 6.1. Informative References . . . . . . . . . . . . . . . . . 10 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
| 1. Introduction | 1. Introduction | |||
| In an environment where equivalent services are distributed in | With emerging that multiple edge sites deployed at different | |||
| multiple geographic locations, Dynamic-Anycast (Dyncast) enables to | locations and had different capacity to provide a service with edge | |||
| perform resource-efficient anycast routing. To support dyncast | computing, when the clients requests service, there is a requirement | |||
| described in [draft-liu-dyncast-ps-usecases], a unique service | to make "best" decision to select edge node among requested service | |||
| identifier that can be assigned to multiple instances in multiple | running simultaneously on multiple edges. While distributing service | |||
| edge environments should be able to be mapped as an actual routable | requests to a specific service having multiple instances attached to | |||
| multiple edges, one of solution is to take into account computing as | ||||
| well as service-specific metrics in the distribution decision seen as | ||||
| dynamic anycast ("dyncast", for short). | ||||
| The main feature of the dyncast described in | ||||
| [draft-liu-dyncast-ps-usecases] is that a unique service identifier | ||||
| that can be assigned to multiple instances in multiple edge | ||||
| environments should be able to be mapped as an actual routable | ||||
| unicast address. Since this concept is similar to the Location/ID | unicast address. Since this concept is similar to the Location/ID | |||
| separation method already used in the LISP design basis, the LISP | separation method already used in the LISP design basis, the LISP | |||
| protocol can be considered as one of the candidate protocols that can | protocol can be considered as one of the candidate protocols that can | |||
| implement dyncast. This draft is proposed to design the LISP-based | implement dyncast. This draft is proposed to design the LISP-based | |||
| architecture for Dyncast and analyze the extension method of LISP to | architecture for Dyncast and analyze the extension method of LISP to | |||
| meet the requirements defined in [draft-liu-dyncast-reqs] for | meet the requirements defined in [draft-liu-dyncast-reqs] for | |||
| realizing dynamic anycasting between different LISP sites. | realizing dynamic anycasting between different LISP sites. | |||
| 2. Terminology | 2. Terminology | |||
| skipping to change at page 3, line 44 ¶ | skipping to change at page 3, line 44 ¶ | |||
| D-BID: Dyncast Binding D-Node, an address to reach a service instance | D-BID: Dyncast Binding D-Node, an address to reach a service instance | |||
| for a given DSEID. It is usually a unicast IP where service | for a given DSEID. It is usually a unicast IP where service | |||
| instances are attached. Different service instances provide the same | instances are attached. Different service instances provide the same | |||
| service identified through D-SID but with different Dyncast Binding | service identified through D-SID but with different Dyncast Binding | |||
| IDs. In the LISP architecture, D-BIDs of same service are replaced | IDs. In the LISP architecture, D-BIDs of same service are replaced | |||
| to RLOC-set of DSEID. | to RLOC-set of DSEID. | |||
| 3. Architecture Overview | 3. Architecture Overview | |||
| Figure 1 describes the Dyncast architecture based on LISP. In the | Figure 1 describes the LISP use-case for dynamic anycast. In the | |||
| LISP architecture [draft-ietf-lisp-introduction-13], each edge | LISP architecture [draft-ietf-lisp-introduction-13], each edge | |||
| network has one or more LISP routers deployed. For anycast address, | network has one or more LISP routers deployed. For anycast address, | |||
| [RFC6830] defines that anycast address can be assigned for both | [RFC6830] defines that anycast address can be assigned for both | |||
| Endpoint ID (EID) and Routing Locator (RLOC) within each of their | Endpoint ID (EID) and Routing Locator (RLOC) within each of their | |||
| address spaces. In this draft, we called EID for dynamic anycasting | address spaces. In this draft, we called EID for dynamic anycasting | |||
| as Dyncast Service Endpoint ID (DSEID), which is assigned to | as Dyncast Service Endpoint ID (DSEID), which is assigned to | |||
| equivalent services across the multiple LISP sites. Similar to the | equivalent services across the multiple LISP sites. Similar to the | |||
| common EID definition, the DSEID cannot be routed globally by itself, | common EID definition, the DSEID cannot be routed globally by itself, | |||
| and the same DSEID cannot be assigned to different services. In | and the same DSEID cannot be assigned to different services. In | |||
| order to forward a packet destined for a DSEID between LISP edges, | order to forward a packet destined for a DSEID between LISP edges, | |||
| skipping to change at page 4, line 22 ¶ | skipping to change at page 4, line 22 ¶ | |||
| assigned the same RLOC which is xTR of their LISP site. Map-server/ | assigned the same RLOC which is xTR of their LISP site. Map-server/ | |||
| resolver of the LISP control plane can manage mapping information for | resolver of the LISP control plane can manage mapping information for | |||
| DESID-to-RLOC-set mappings together with existing EID-to-RLOC | DESID-to-RLOC-set mappings together with existing EID-to-RLOC | |||
| mappings. | mappings. | |||
| For resource-efficient forwarding decisions across multiple service | For resource-efficient forwarding decisions across multiple service | |||
| instances, [draft-li-dyncast-architecture] defines Dyncast Metric | instances, [draft-li-dyncast-architecture] defines Dyncast Metric | |||
| Agent (D-MA) which collects metrics related network and service | Agent (D-MA) which collects metrics related network and service | |||
| instances. Actual packet forwarding is handled in the Dyncast Router | instances. Actual packet forwarding is handled in the Dyncast Router | |||
| (D-Router) based upon collected metrics with maintaining instance | (D-Router) based upon collected metrics with maintaining instance | |||
| affinity. In the LISP architecture, the D-Router function can be | affinity. In the LISP architecture, the D-Router and D-MA function | |||
| implemented on the LISP xTR, and the D-MA can be deployed as a | can be implemented on each LISP ETR, or can be deployed as separate | |||
| separate component within the edge for managing service instances, or | components within the edge for managing service instances. The LISP | |||
| it can be deployed in combination with the LISP xTR. The LISP | ||||
| control plane is logically centralized and it provides an interface | control plane is logically centralized and it provides an interface | |||
| with each LISP router to exchange mapping information. However, it | with each LISP router to exchange mapping information. However, it | |||
| does not mean that the LISP control plane is located in a single | does not mean that the LISP control plane is located in a single | |||
| physical location, several mechanisms for distributing the mapping | physical location, several mechanisms for distributing the mapping | |||
| system already have been defined. | system already have been defined. | |||
| LISP Edge 1 LISP Edge 2 | +------------------+ | |||
| '''''''''''''''' ''''''''''''''' | |LISP Control Plane| | |||
| ' +----------+ ' ' +----------+' | +------------------+ | |||
| ' | Service | ' ' | Service |' | | +--------+ +--------+ | |||
| ' | Instance | ' ' | Instance |' | | ___|LISP-ETR|---|Service1| DESID | |||
| ' | (DSEID) | ' ' | (DSEID) |' | ......... / +--------+ +--------+ | |||
| ' +----------+ ' ' +----------+' | .. .. | |||
| ' | ' +---------------------+ ' | ' | +------+ +--------+ : Core : +--------+ +--------+ | |||
| ' | ' | LISP Control Plane | ' | ' | |Client|--|LISP ITR|-: Network :---|LISP-ETR|---|Service1| DESID | |||
| ' +----------+"""'"""+---------------------+" ' | ' | +------+ +--------+ :(RLOC-space) : +--------+ +--------+ | |||
| ' | D-MA | '"" " " ' | ' | EID .. .. | |||
| ' +----------+ " " " ' | ' | ......... \ +--------+ +--------+ | |||
| ' | " ' " " ' +----------+' | \__|LISP-ETR|---|Service1| DESID | |||
| ' | " ' " " | D-MA |' | +--------+ +--------+ | |||
| ' +----------+ ' " +--------------------+ '" +----------+' | ||||
| ' | LISP-xTR |RLOC" | Core Network |RLOC' | LISP-xTR |' | ||||
| ' |(D-Router)|----"-| (RLOC-Space) |--------|(D-Router)|' | ||||
| ' +----------+ ' " +--------------------+ ' +----------+' | ||||
| ' | ' " '''''''''|''''''''''' | ||||
| ' | ' "' |RLOC ' ' | ' | ||||
| ' | ' '"+--------------------+ ' ' | ' | ||||
| ' | ' ' | LISP-xTR (D-Router)| ' ' | ' | ||||
| ' | ' ' +--------------------+ ' ' | ' | ||||
| ' +----------+ ' ' | ' ' +----------+' | ||||
| ' | Client | ' ' +----------+ ' ' | Client |' | ||||
| ' | (EID) | ' ' | Client | ' ' | (EID) |' | ||||
| ' +----------+ ' ' | (EID) | ' ' +----------+' | ||||
| ' ' ' +----------+ ' ' ' | ||||
| '''''''''''''' '''''''''''''''''' '''''''''''''' | ||||
| LISP Edge 3 | ||||
| Figure 1: LISP-based Dyncast Architecture | Figure 1: LISP use-case for Dynamic anycast | |||
| Figure 3 shows an example of LISP-based dyncast deployment where two | Figure 3 shows an example of LISP-based dyncast deployment where two | |||
| services each deployed two instances at different edges. In this | services each deployed two instances at different edges. In this | |||
| scenario, two services are assigned an RLOC according to the ETR | scenario, two services are assigned an RLOC according to the ETR | |||
| address of the LISP site. Both Service_A and Service_B instances | address of the LISP site. Both Service_A and Service_B instances | |||
| connected to ETR_2 are assigned RLOC2, which is the RLOC of ETR_2, as | connected to ETR_2 are assigned RLOC2, which is the RLOC of ETR_2, as | |||
| a binding ID. According this figure, DSEID-to-RLOC-set mappings can | a binding ID. According this figure, DSEID-to-RLOC-set mappings can | |||
| be configured as an example below. | be configured as an example below. | |||
| DSEID RLOC-set | DSEID RLOC-set | |||
| skipping to change at page 13, line 5 ¶ | skipping to change at page 12, line 5 ¶ | |||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", RFC 2119, March 1997, | Requirement Levels", RFC 2119, March 1997, | |||
| <https://datatracker.ietf.org/doc/rfc2119/>. | <https://datatracker.ietf.org/doc/rfc2119/>. | |||
| [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The | [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The | |||
| Locator/ID Separation Protocol (LISP)", RFC 6830, January | Locator/ID Separation Protocol (LISP)", RFC 6830, January | |||
| 2013, <https://datatracker.ietf.org/doc/rfc6830/>. | 2013, <https://datatracker.ietf.org/doc/rfc6830/>. | |||
| Authors' Addresses | Authors' Addresses | |||
| Kyoungjae Sun | Kyoungjae Sun | |||
| Soongsil University | ETRI | |||
| 369, Sangdo-ro, Dongjak-gu | 218, Gajeong-ro, Yuseung-gu | |||
| Seoul | Dajeon | |||
| 06978 | 34065 | |||
| Republic of Korea | Republic of Korea | |||
| Phone: +82 10 3643 5627 | Phone: +82 10 3643 5627 | |||
| Email: gomjae@dcn.ssu.ac.kr | Email: kjsun@etri.re.kr | |||
| Younghan Kim | Younghan Kim | |||
| Soongsil University | Soongsil University | |||
| 369, Sangdo-ro, Dongjak-gu | 369, Sangdo-ro, Dongjak-gu | |||
| Seoul | Seoul | |||
| 06978 | 06978 | |||
| Republic of Korea | Republic of Korea | |||
| Phone: +82 10 2691 0904 | Phone: +82 10 2691 0904 | |||
| Email: younghak@ssu.ac.kr | Email: younghak@ssu.ac.kr | |||
| End of changes. 15 change blocks. | ||||
| 68 lines changed or deleted | 58 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||