DMM Working Group Jaehwoon Lee Internet-Draft Dongguk University Intended status: Informational May 6, 2022 Expires: November 5, 2022 Network-based mobility management in Dyncast network environment draft-jaehwoon-dmm-dyncast--mobility-00 Abstract Dynamic anycast (Dyncast) network architecture is to choose the best edge computing server by considering both the network environment and available computing/storage resources of the edge computing server. This draft describes the mechanism in which service continuity is provided even when the client moves and connects to a new ingress Dyncast anycast Node (DAN) by using the PMIPv6-based mobility management method in the Dyncast-based edge computing networking environment. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on November 5, 2022. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Jaehwoon Lee Expires Nov. 5, 2022 [Page 1] Internet-Draft Mobility management in Dyncast network May 6, 2022 Table of Contents 1. Introduction.................................................2 2. Conventions and Terminology..................................3 2.1. Conventions used in this document........................3 2.2. Terminology ............................................3 3. Protocol Operation...........................................4 4. Security Considerations......................................6 5. IANA Considerations..........................................6 6. References....................................................6 Author's Address.................................................6 1. Introduction Cloud computing provides powerful computing and nearly unlimited storage resources to client devices connected over the Internet. However, if the number of client, such as Internet of Things (IoT) devices is quite large, traffic exchange between the client and the cloud computing server is also large and it can cause congestion over the Internet. When congestion occurs on the path between a client and the cloud computing server, the client transmitting service request may experience long response time in receiving the result of the service request, or the service request itself may be lost. In edge computing, even though edge computing server provides smaller computing and storage resources compared to the cloud computing server, multiple number of edge computing servers can be located near client devices and the client sending service request can benefit from shorter response time. In the edge computing environment, one way for a client to find a suitable edge computing server is to choose the nearest edge server based on the location of the client inferred from the client's source IP address. Another way is to choose one of the several edge servers by utilizing the round-robin method. However, in such cases, if the available resource in the chosen server is insufficient or congestion occurs on the path between the client and the chosen server, the client may experience longer response time or service request may be lost. Dynamic anycast (Dyncast) network architecture is proposed in choosing the best edge computing server by considering both the networking environment and available computing/storage resources of the edge computing server[1]. Here, a service is represented by an anycast IP address. Assume that there is a client trying to receive a service provided by a specific service instance. In this case ingress Dyncast anycast node (DAN) acts as a gateway for the client. In addition, egress DAN is connected to the edge computing server in which specific service instance is installed. Assume that there are Jaehwoon Lee Expires Nov. 5, 2022 [Page 2] Internet-Draft Mobility management in Dyncast network May 6, 2022 N edge servers providing a specific service. Each edge server is connected to a different egress DAN. The client transmits a service request message with anycast address as a destination IP address. Ingress DAN chooses the best egress DAN by using the combination of the network metric such as delay, and computing metric such as available computing/storage resource of edge servers. The ingress DAN establishes a tunnel with the chosen egress DAN and then transmits a service request through the tunnel. After which egress DAN transmits the service request to the service instance in the edge computing server. The result of the service request is in turn transmitted from the edge server to the client through the egress DAN and the ingress DAN. When a client transmits a service request and then moves to another network before receiving the service result, the client can no longer receive the result of the service request. Even when the client moves and connects to a new ingress DAN, host-based mobility management method such as Mobile IPv6 (MIPv6) can be used to maintain end-to-end connectivity[2]. In this case however, the destination IP address of the service request message sent by the client is the anycast IP address. Which means that the new ingress DAN cannot know the egress DAN connected to the edge server providing service to the client which uses the anycast IP address as the destination IP address. Therefore, host-based mobility management cannot be used in the Dyncast networking environment. That being said, network-based mobility management mechanism such as Proxy MIPv6 (PMIPv6) can be used in the Dyncast networking environment if the new ingress DAN knows the address of the egress DAN connected to the edge server providing service to the client[3]. In this case, service continuity is ensured for the client. This draft describes the mechanism in which service continuity is provided even when the client moves and connects to a new ingress DAN by using the PMIPv6-based mobility management method in the Dyncast- based edge computing networking environment. 2. Conventions and Terminology 2.1. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [4]. 2.2 Terminology TBD. Jaehwoon Lee Expires Nov. 5, 2022 [Page 3] Internet-Draft Mobility management in Dyncast network May 6, 2022 3. Protocol Operation Fig. 1 show the message exchange procedure to provide service continuity proactively when a client moves to another network in Dyncast networking environment. If the client transmits service request message with anycast address as a destination IP address, an ingress DAN (that is, old ingress DAN) chooses the best egress DAN by using the combination of the network metric and computing metric. The old ingress DAN establishes the tunnel with the chosen DAN and then transmits the service request message through the tunnel. The egress DAN transmits the service request message to the corresponding service instance in the edge computing server. When the old ingress DAN detects the movement of the client before completing transmission of all service results, it transmits the mobility notification message including the IP addresses of the client and the egress DAN to one or more candidate new ingress DANs that clients may connects to. The format of the mobility notification message is TBD. Here, how the old ingress DAN can know the movement of the client is out of scope. One method is to use the signal strength of the client. Moreover, how the old ingress DAN can know which is the new ingress DAN that the client moves and connects to is TBD. One method is for the old ingress DAN to broadcast the mobility notification message to neighbor ingress DANs. Another method is to find some candidate ingress DANs by using the GPS information of the client. A new ingress DAN having received mobility notification message establishes the tunnel with the old ingress DAN. Moreover, it establishes the tunnel with the egress DAN. When the client moves and connects to a new ingress DAN, the new ingress DAN transmits mobility indication message including the IP address of the client to the old ingress DAN and the egress DAN. The format of the mobility indication message is TBD. From now on, the old ingress DAN and the egress DAN transmit all services results to the client through the new ingress DAN. Fig. 2 show the message exchange procedure to provide service continuity reactively to the client. If the client moves and connects to a new ingress DAN, the new ingress DAN transmit mobility request message including the IP address of the client to the old ingress DAN. The format of the mobility request message is TBD. Here, how the new ingress DAN can know the address information of the old ingress DAN is TBD. Moreover, how the new ingress DAN can know whether the connected client needs service continuity or not is TBD. The old ingress DAN transmits the mobility notification message and establishes the tunnel with the new ingress DAN. The new ingress DAN transmits the mobility indication message to the egress DAN and establishes the tunnel with the egress DAN. From now on, the old ingress DAN and egress DAN transmit all service results to the client through the new ingress DAN. Jaehwoon Lee Expires Nov. 5, 2022 [Page 4] Internet-Draft Mobility management in Dyncast network May 6, 2022 Client old ingress DAN new ingress DAN egress DAN Service instance | | | | | |<--connect -->| | | | | |<===== est. tunnel ====>| | |-service req->| | | | | |------ service request --------->| | | | | |-service req ->| (movement) | | | | | (client move detection) | | | | |- notify msg ->| | | |<----- connect ---------->| | | | |<-- ind. msg --| | | | |<=est. tunnel=>| | | | | | |<- svc result--| | |<---- service result -----| | | |- svc result ->| | | |<--- svc result ----| | | | | |--- ind. msg --->| | | | |<= est. tunnel =>| | | | | |<- svc result--| | | |<-- svc result --| | |<--- svc result ----| | | Figure 1: Message exchange procecure - proactive method Client old ingress DAN new ingress DAN egress DAN Service instance | | | | | |<--connect -->| | | | | |<===== est. tunnel ====>| | |-service req->| | | | | |------ service request --------->| | | | | |-service req ->| (movement) | | | | |<----- connect ---------->| | | | |<-- req. msg --| | | | |- notify msg ->| | |<=est. tunnel=>| | | | | | |<- svc result--| | |<---- service result -----| | | |- svc result ->| | | |<--- svc result ----| | | | | |--- ind. msg --->| | | | |<= est. tunnel =>| | | | | |<- svc result--| | | |<-- svc result --| | |<--- svc result ----| | | Figure 2: Message exchange procecure - reactive method Jaehwoon Lee Expires Nov. 5, 2022 [Page 5] Internet-Draft Mobility management in Dyncast network May 6, 2022 4. Security Considerations TBD 5. IANA Considerations TBD 6. References [1] Y. LI, L. Iannone, D. Trossen, P. Liu and C. Li, "Dynamic- Anycast Architecture", draft-li-dyncast-architucture-03 (work in progress, Mar. 7, 2022. [2] D. Johnson, C. Perkins and J. Arkko, "Mobility Support in IPv6", IETF RFC 3775, June 2004. [3] S. Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury and B. Patil, "Proxy Mobile IPv6", IETF RFC 5213, Aug. 2008. [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Author's Address Jaehwoon Lee Dongguk University 30, Pildong-ro 1 gil, Jung-gu Seoul 04620, KOREA Email: jaehwoon@dongguk.edu Jaehwoon Lee Expires Nov. 5, 2022 [Page 6]