Network-based mobility management in CATS network environment
draft-jaehwoon-cats-mobility-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Author | Jaehwoon Lee | ||
| Last updated | 2023-04-30 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-jaehwoon-cats-mobility-00
CATS Working Group Jaehwoon Lee
Internet-Draft Dongguk University
Intended status: Informational May 1, 2023
Expires: October 31, 2023
Network-based mobility management in CATS network environment
draft-jaehwoon-cats-mobility-00
Abstract
Computing-Aware Traffic Steering (CATS) 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 CATS-Router by using the PMIPv6-based mobility management
method in the CATS-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 October 31, 2023.
Copyright Notice
Copyright (c) 2023 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 Oct. 31, 2023 [Page 1]
Internet-Draft Mobility management in CATS network May. 1, 2023
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..............................................7
4.1. CATS mobility notification and request messages..........7
4.2 CATS mobility indications message........................7
4.3 Mobile node anddes and CATS address options..............8
5. Security Considerations......................................9
6. IANA Considerations..........................................9
7. References....................................................9
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.
IETF CATS working group tries to standardize the mechanism to
choose 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
CATS Service ID (CS-ID). Assume that there is a client trying to
Jaehwoon Lee Expires Oct. 31, 2023 [Page 2]
Internet-Draft Mobility management in CATS network May. 1, 2023
receive a service provided by a specific service instance. In this
case, ingress CATS-Router acts as a gateway for the client. In
addition, egress CATS-Router 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. Moreover,
each edge server is assumed to be connected to a different egress
CATS-Router. The client transmits a service request message with
CS-ID as a destination IP address. Ingress CATS-Router chooses the
best egress CATS-Router 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 CATS-Router
transmits the service request sent by the client to the chosen
egress CATS-Router. After which egress CATS-Router 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 CATS-Router and the
ingress CATS-Router.
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. When the client moves and
connects to a new ingress CATS-Router, 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 CS-ID.
Which means that the new ingress CATS-Router cannot know the egress
CATS-Router connected to the edge server providing service to the
client which uses the CS-ID as the destination IP address. Therefore,
host-based mobility management cannot be used in the CATS networking
environment. That being said, network-based mobility management
mechanism such as Proxy MIPv6 (PMIPv6) can be used in the CATS
networking environment if the new ingress CATS-Router knows the
address of the egress CATS-Router connected to the edge server
providing service to the client[3]. In this case, service continuity
is ensured for the client. However, new ingress CATS-Router cannot
know the IP address of the egress CATS-Router only using the address
information of the IP packet sent by the client. The reason is that
the destination address of the IP packet indicates not a specific
destination but a specific service.
This draft describes the mechanism in which service continuity is
provided even when the client moves and connects to a new ingress
CATS-Router by using the PMIPv6-based mobility management method in
the CATS-based edge computing networking environment.
2. Conventions and Terminology
2.1. Conventions
Jaehwoon Lee Expires Oct. 31, 2023 [Page 3]
Internet-Draft Mobility management in CATS network May. 1, 2023
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.
3. Protocol Operation
When a client moves from an ingress CATS-Router to another ingress
CATS-Router before receiving all the service results, either
proactive method of reactive method can be utilized to provide
service continuity.
Fig. 1 shows the message exchange procedure to provide service
continuity proactively when a client moves to another network in
CATS networking environment. If the client transmits service
request message with CS-ID as a destination IP address, an ingress
CATS-Router (that is, old ingress CATS-Router) chooses the best
egress CATS-Router by using the combination of the network metric and
computing metric. The old ingress CATS-Router transmits the service
request to the chosen egress CATS-Router. The egress CATS-Router
transmits the service request message to the corresponding service
instance in the edge computing server. When the old ingress
CATS-Router detects the movement of the client before completing
transmission of all service results, it transmits the CATS mobility
notification message including the addresses of the client and the
chosen egress CATS-Router to one or more candidate new ingress
CATS-Router that client may connect to. The format of the CATS
mobility notification message is defined in Section 4.1. Here, how
the old ingress CATS-Router 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 CATS-Router can know which is the new
ingress CATS-Router that the client moves and connects to is TBD.
One method is for the old ingress CATS-Router to broadcast the CATS
mobility notification message to neighbor ingress CATS-Routers.
Another method is to find some candidate ingress CATS-Routers by
using the GPS information of the client. When the client moves and
connects to a new ingress CATS-Router, the new ingress CATS-Router
transmits the CATS mobility indication message having the IP address
of the client to the old ingress CATS-Router and establishes the
tunnnel with the old ingress CATS-Router. The format of the CATS
mobility indication message is defined in Section 4.2. The old
ingress CATS-Router having received the CATS mobility indication
message also establishes the tunnel with the new ingress CATS-Router.
Jaehwoon Lee Expires Oct. 31, 2023 [Page 4]
Internet-Draft Mobility management in CATS network May. 1, 2023
Client old ingress Router new ingress Router egress Router Service
instance
| | | | |
|<--connect -->| | | |
|-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 --->| |
| | | |<- svc result--|
| | |<-- svc result --| |
|<--- svc result ----| | |
Figure 1: Message exchange procecure - proactive method
Moreover, the new ingress CATS-Router transmits the CATS mobility
indication message having the client's IP address and the IP address
of the old ingress CATS-Router to the egress CATS-Router. From now
on, the old ingress CATS-Router and the egress CATS-Router can
transmit all services results to the client through the new ingress
CATS-Router.
Fig. 2 shows the message exchange procedure to provide service
continuity reactively to the client. If the client moves and connects
to a new ingress CATS-Router, the new ingress CATS-Router transmits
the CATS mobility request message including the IP address of the
client to the old ingress CATS-Router. The format of the CATS
mobility request message is defined in Section 4.1. Here, how the
new ingress CATS-Router can know the address information of the old
ingress CATS-Router is TBD. Moreover, how the new ingress CATS-Router
can know whether the connected client needs service continuity or not
is TBD. One method is to use a location server. When a client
connects to an old ingres CATS-Router, the old CATS-Router store the
IP and link layer addresses of the client and the IP address
information of the egress CATS-Router that the service request of the
client is transmitted. The information regarding the client can be
removed just after all service results are transmitted to the client.
When a client moves to a new ingress CATS-Router, then the new
ingress CATS-Router can know whether the client is a new client or
Jaehwoon Lee Expires Oct. 31, 2023 [Page 5]
Internet-Draft Mobility management in CATS network May. 1, 2023
Client old ingress Router new ingress Router egress Router Service
instance
| | | | |
|<--connect -->| | | |
|-service req->| | | |
| |------ service request --------->| |
| | | |-service req ->|
(movement) | | | |
|<----- connect ---------->| | |
| |<-- req. msg --| | |
| |- notify msg ->|
| |<=est. tunnel=>| | |
| | | |<- svc result--|
| |<---- service result -----| |
| |- svc result ->| | |
|<--- svc result ----| | |
| | |--- ind. msg --->| |
| | | |<- svc result--|
| | |<-- svc result --| |
|<--- svc result ----| | |
Figure 2: Message exchange procecure - reactive method
the client requiring service continuity by quering the information
stored in the server. Another method is to assign a network address
to CAT domain but different sub-network address is assigned to
different ingress CATS-Router. For example, assume that 10.0.0.0/8
network address is assigned to a CATS domain. Here, 10.0.0.0/16
sub-network address is assigned to the old ingress CATS-Router and
10.0.1.0/16 sub-network address is assigned to the new ingress
CATS-Router. Moreover, 10.0.0.1 IP address is assigned to the old
ingress CATS-Router and 10.0.1.1 IP address is assigned to the new
ingress CATS-Router. When a client connects to the old ingress
CATS-Router, the router advertises 10.0.0.0 network address by using
the Router Advertisement message. If the client transmits DHCP
request message requesting a new IP address, the router assigns one
of the IP addresses belonging to 10.0.0.0/16 sub-network address.
When the client moves and connects to the new ingress CATS-Router,
the router advertises 10.0.0.0/8 network address by using the Router
advertisement message. If the client transmits DHCP request message,
then the router considers that the client is the newly connected
client. Otherwise, the router can deduce the IP address of the old
ingress CATS-Router by using the source IP address of the packet
transmitted by the client. The old ingress CATS-Router having
received CATS mobility request message transmits the CATS mobility
notification message including the IP address of the egress
CATS-Router to the new ingress CATS-Router and establishes the tunnel
with the new ingress CATS-Router. The new ingress CATS-Router
transmits the CATS mobility indication message to the old ingress
Jaehwoon Lee Expires Oct. 31, 2023 [Page 6]
Internet-Draft Mobility management in CATS network May. 1, 2023
CATS-Router and establishes the tunnel with old ingress CATS-Router.
Moveover, it transmits the CATS mobility indication message to the
egress CATS-Router. From now on, the old ingress CATS-Router and the
egress CATS-Router can transmit all service results to the client
through the new ingress CATS-Router.
4. Message Formats
4.1 CATS 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 CATS 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|C|N| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C: CATS flag. This bit must be set to 1 in the CATS environment.
N: The flag must be set to 0 for CATS mobility notification message
must be set to 1 for CATS mobility request message.
The mobility option of the CATS notification message contains client
node address option and CATS address option defined in Section 4.3.
In this case, the address contained in the CATS address option is the
egress CATS-Router address. Moreover, the mobility option of the CATS
request message contains the client node address option.
4.2 CATS mobility indication message
In this draft, the proxy binding acknowledgment message defined in
the Proxy Mobile IPv6 protocol is used to define the CATS mobility
indication message [3]. The message format is as follows:
Jaehwoon Lee Expires Oct. 31, 2023 [Page 7]
Internet-Draft Mobility management in CATS network May. 1, 2023
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|C|Resrved|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C: CATS flag. This bit must be set to 1 in the CATS environment.
When the message is transmitted from the new ingress CATS-Router to
the old ingress CATS-Router, the client node address option is
included in the mobility option. Moreover, when the message is
transmitted from the new ingress CATS-Router the the egress
CATS-Router, the client node address and CATS address options are
included in the mobility options. In this case, the address included
in the CATS address option is the old ingress CATS-Router.
4.3 Mobile node address and CATS address options
In this draft, the mobility option defined in the Mobile IPv6
protocol is used to define the client node address and CATS 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 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Client node address option:
- Type : TBD
- The mobile node address is included in the Address field.
CATS address option:
- Type : TBD
- The CATS address is included in the address field.
Jaehwoon Lee Expires Oct. 31, 2023 [Page 8]
Internet-Draft Mobility management in CATS network May. 1, 2023
5. Security Considerations
TBD
6. IANA Considerations
TBD
7. References
[1] C. Li, Z. Du, M, Boucadair, L. M. Contreras, J. Drake, G. Huang
and G. Mishra, "A Framework for Computing-Aware Traffic
Steering (CATS)", draft-ldbc-cats-framework-01 (work in
progress, Mar. 10, 2023.
[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 Oct. 31, 2023 [Page 9]