< 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/