Internet DRAFT - draft-jaehwoon-dmm-dyncast--mobility
draft-jaehwoon-dmm-dyncast--mobility
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]
