DMM Working Group Jaehwoon Lee Internet-Draft Dongguk University Intended status: Informational September 16, 2022 Expires: March 15, 2023 Network-based mobility management in Dyncast network environment draft-jaehwoon-dmm-dyncast--mobility-01 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 March 15, 2023. 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 Mar. 15, 2023 [Page 1] Internet-Draft Mobility management in Dyncast network Sep. 16, 2022 Table of Contents 1. Introduction.................................................2 2. Conventions and Terminology..................................3 2.1. Conventions used in this document........................3 2.2. Terminology ............................................4 3. Protocol Operation...........................................4 4. Message Formats..............................................6 4.1. DAN mobility notification and request messages...........6 4.2 DAN mobility indications message.........................7 4.3 Mobile node anddes and DAN address options...............7 5. Security Considerations......................................8 6. IANA Considerations..........................................8 7. References....................................................8 Author's Address.................................................9 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 Jaehwoon Lee Expires Mar. 15, 2023 [Page 2] Internet-Draft Mobility management in Dyncast network Sep. 16, 2022 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 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]. Jaehwoon Lee Expires Mar. 15, 2023 [Page 3] Internet-Draft Mobility management in Dyncast network Sep. 16, 2022 2.2 Terminology TBD. 3. Protocol Operation Fig. 1 shows 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 egress 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 DAN mobility notification message including the IP addresses of the client and the chosen egress DAN to one or more candidate new ingress DANs that client may connect to. The format of the DAN mobility notification message is defined in Section 4.1. 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 DAN mobility notification message to neighbor ingress DANs. Another method is to find some candidate ingress DANs by using the GPS information of the client. When the client moves and connects to a new ingress DAN, the new ingress DAN transmits the DAN mobility indication message having the IP address of the client to the old ingress DAN and establishes the tunnnel with the old ingress DAN. The format of the DAN mobility indication message is defined in Section 4.2. The old ingress DAN having received the DAN mobility indication message also establishes the tunnel with the new ingress DAN. Moreover, the new ingress DAN transmits the DAN mobility indication message having the client's IP address and the IP address of the old ingress DAN to the egress DAN and then establishes the tunnel with the egress DAN. The egress DAN having received the DAN mobility indication message establishes the tunnel for the client with the new ingress DAN. From now on, the old ingress DAN and the egress DAN can transmit all services results to the client through the new ingress DAN. Fig. 2 shows the message exchange procedure to provide service continuity reactively to the client. If the client moves and connects Jaehwoon Lee Expires Mar. 15, 2023 [Page 4] Internet-Draft Mobility management in Dyncast network Sep. 16, 2022 to a new ingress DAN, the new ingress DAN transmits the DAN mobility request message including the IP address of the client to the old ingress DAN. The format of the mobility request message is defined in Section 4.1. 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 DAN mobility notification message including the IP address of the egress DAN to the new ingress DAN and establishes the tunnel with the new ingress DAN. The new ingress DAN transmits the DAN mobility indication message to the old ingress DAN and establishes the tunnel with old ingress DAN. Moveover, it transmits the DAN mobility indication message to the egress egress DAN and establishes the tunnel with the egress DAN. From now on, the old ingress DAN and egress DAN can transmit all service results to the client through the new ingress DAN. 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 ->| Jaehwoon Lee Expires Mar. 15, 2023 [Page 5] Internet-Draft Mobility management in Dyncast network Sep. 16, 2022 (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 4. Message Formats 4.1 DAN mobility notification and request messages In this draft, the proxy binding update message defined in the Proxy Mobile IPv6 protocol is used to define the DAN mobility notification and request messages [3]. The message format is as follows: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|L|K|M|R|P|D|N| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ D: DAN flag. This bit must be set to 1 in the DAN environment. N: The flag must be set to 0 for DAN mobility notification message must be set to 1 for DAN mobility request message. The mobility option of the DAN notification message contains client node address option and DAN address option defined in Section 4.3. In this case, the address contained in the DAN address option is the egress DAN address. Moreover, the mobility option of the DAN request message contains the client node address option. Jaehwoon Lee Expires Mar. 15, 2023 [Page 6] Internet-Draft Mobility management in Dyncast network Sep. 16, 2022 4.2 DAN mobility indication message In this draft, the proxy binding acknowledgment message defined in the Proxy Mobile IPv6 protocol is used to define the DAN mobility indication message [3]. The message format is as follows: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status |K|R|P|D|Resrved| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ D: DAN flag. This bit must be set to 1 in the DAN environment. When the message is transmitted from the new ingress DAN to the old ingress DAN, the client node address option is included in the mobility option. Moreover, when the message is transmitted from the new ingress DAN the the egress DAN, the client node address and DAN address options are included in the mobility options. In this case, the address include in the DAN address option is the old ingress DAN. 4.3 Mobile node address and DAN address options In this draft, the mobility option defined in the Mobile IPv6 protocol is used to define the client node address and DAN address options [2]. The option format is as follow: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length = 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Jaehwoon Lee Expires Mar. 15, 2023 [Page 7] Internet-Draft Mobility management in Dyncast network Sep. 16, 2022 Client node address option: - Type : TBD - The mobile node address is included in the Address field. DAN address option: - Type : TBD - The DAN address is included in the address field. 5. Security Considerations TBD 6. IANA Considerations TBD 7. 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 Mar. 15, 2023 [Page 8]