Network-based mobility management in Dyncast network environment
draft-jaehwoon-dmm-dyncast--mobility-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]