\
[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
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]