idnits 2.17.00 (12 Aug 2021) /tmp/idnits42776/draft-jaehwoon-dmm-dyncast--mobility-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 40 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 2 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 196 has weird spacing: '... Client old ...' == Line 222 has weird spacing: '... Client old ...' == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (May 6, 2022) is 8 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- No information found for draft-li-dyncast-architucture - is the name correct? ** Obsolete normative reference: RFC 3775 (ref. '2') (Obsoleted by RFC 6275) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DMM Working Group Jaehwoon Lee 2 Internet-Draft Dongguk University 3 Intended status: Informational May 6, 2022 4 Expires: November 5, 2022 6 Network-based mobility management in Dyncast network environment 7 draft-jaehwoon-dmm-dyncast--mobility-00 9 Abstract 11 Dynamic anycast (Dyncast) network architecture is to choose the best 12 edge computing server by considering both the network environment and 13 available computing/storage resources of the edge computing server. 14 This draft describes the mechanism in which service continuity is 15 provided even when the client moves and connects to a new ingress 16 Dyncast anycast Node (DAN) by using the PMIPv6-based mobility 17 management method in the Dyncast-based edge computing networking 18 environment. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on November 5, 2022. 37 Copyright Notice 39 Copyright (c) 2022 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 44 license-info) in effect on the date of publication of this document. 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. Code Components 47 extracted from this document must include Revised BSD License text as 48 described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Revised BSD License. 51 Table of Contents 53 1. Introduction.................................................2 54 2. Conventions and Terminology..................................3 55 2.1. Conventions used in this document........................3 56 2.2. Terminology ............................................3 57 3. Protocol Operation...........................................4 58 4. Security Considerations......................................6 59 5. IANA Considerations..........................................6 60 6. References....................................................6 61 Author's Address.................................................6 63 1. Introduction 65 Cloud computing provides powerful computing and nearly unlimited 66 storage resources to client devices connected over the Internet. 67 However, if the number of client, such as Internet of Things (IoT) 68 devices is quite large, traffic exchange between the client and the 69 cloud computing server is also large and it can cause congestion over 70 the Internet. When congestion occurs on the path between a client and 71 the cloud computing server, the client transmitting service request 72 may experience long response time in receiving the result of the 73 service request, or the service request itself may be lost. 75 In edge computing, even though edge computing server provides smaller 76 computing and storage resources compared to the cloud computing 77 server, multiple number of edge computing servers can be located near 78 client devices and the client sending service request can benefit 79 from shorter response time. In the edge computing environment, one 80 way for a client to find a suitable edge computing server is to 81 choose the nearest edge server based on the location of the client 82 inferred from the client's source IP address. Another way is to 83 choose one of the several edge servers by utilizing the round-robin 84 method. However, in such cases, if the available resource in the 85 chosen server is insufficient or congestion occurs on the path 86 between the client and the chosen server, the client may experience 87 longer response time or service request may be lost. 89 Dynamic anycast (Dyncast) network architecture is proposed in 90 choosing the best edge computing server by considering both the 91 networking environment and available computing/storage resources of 92 the edge computing server[1]. Here, a service is represented by an 93 anycast IP address. Assume that there is a client trying to receive a 94 service provided by a specific service instance. In this case ingress 95 Dyncast anycast node (DAN) acts as a gateway for the client. In 96 addition, egress DAN is connected to the edge computing server in 97 which specific service instance is installed. Assume that there are 98 N edge servers providing a specific service. Each edge server is 99 connected to a different egress DAN. The client transmits a service 100 request message with anycast address as a destination IP address. 101 Ingress DAN chooses the best egress DAN by using the combination of 102 the network metric such as delay, and computing metric such as 103 available computing/storage resource of edge servers. The ingress DAN 104 establishes a tunnel with the chosen egress DAN and then transmits a 105 service request through the tunnel. After which egress DAN transmits 106 the service request to the service instance in the edge computing 107 server. The result of the service request is in turn transmitted from 108 the edge server to the client through the egress DAN and the ingress 109 DAN. 111 When a client transmits a service request and then moves to another 112 network before receiving the service result, the client can no longer 113 receive the result of the service request. Even when the client moves 114 and connects to a new ingress DAN, host-based mobility management 115 method such as Mobile IPv6 (MIPv6) can be used to maintain end-to-end 116 connectivity[2]. In this case however, the destination IP address of 117 the service request message sent by the client is the anycast IP 118 address. Which means that the new ingress DAN cannot know the 119 egress DAN connected to the edge server providing service to the 120 client which uses the anycast IP address as the destination IP 121 address. Therefore, host-based mobility management cannot be used in 122 the Dyncast networking environment. That being said, network-based 123 mobility management mechanism such as Proxy MIPv6 (PMIPv6) can be 124 used in the Dyncast networking environment if the new ingress DAN 125 knows the address of the egress DAN connected to the edge server 126 providing service to the client[3]. In this case, service continuity 127 is ensured for the client. 129 This draft describes the mechanism in which service continuity is 130 provided even when the client moves and connects to a new ingress DAN 131 by using the PMIPv6-based mobility management method in the Dyncast- 132 based edge computing networking environment. 134 2. Conventions and Terminology 136 2.1. Conventions 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in [4]. 142 2.2 Terminology 144 TBD. 146 3. Protocol Operation 148 Fig. 1 show the message exchange procedure to provide service 149 continuity proactively when a client moves to another network in 150 Dyncast networking environment. If the client transmits service 151 request message with anycast address as a destination IP address, an 152 ingress DAN (that is, old ingress DAN) chooses the best egress DAN by 153 using the combination of the network metric and computing metric. The 154 old ingress DAN establishes the tunnel with the chosen DAN and then 155 transmits the service request message through the tunnel. The egress 156 DAN transmits the service request message to the corresponding 157 service instance in the edge computing server. 159 When the old ingress DAN detects the movement of the client before 160 completing transmission of all service results, it transmits the 161 mobility notification message including the IP addresses of the 162 client and the egress DAN to one or more candidate new ingress DANs 163 that clients may connects to. The format of the mobility notification 164 message is TBD. Here, how the old ingress DAN can know the movement 165 of the client is out of scope. One method is to use the signal 166 strength of the client. Moreover, how the old ingress DAN can know 167 which is the new ingress DAN that the client moves and connects to is 168 TBD. One method is for the old ingress DAN to broadcast the mobility 169 notification message to neighbor ingress DANs. Another method is to 170 find some candidate ingress DANs by using the GPS information of the 171 client. A new ingress DAN having received mobility notification 172 message establishes the tunnel with the old ingress DAN. Moreover, it 173 establishes the tunnel with the egress DAN. When the client moves and 174 connects to a new ingress DAN, the new ingress DAN transmits mobility 175 indication message including the IP address of the client to the old 176 ingress DAN and the egress DAN. The format of the mobility indication 177 message is TBD. From now on, the old ingress DAN and the egress DAN 178 transmit all services results to the client through the new ingress 179 DAN. 181 Fig. 2 show the message exchange procedure to provide service 182 continuity reactively to the client. If the client moves and connects 183 to a new ingress DAN, the new ingress DAN transmit mobility request 184 message including the IP address of the client to the old ingress 185 DAN. The format of the mobility request message is TBD. Here, how the 186 new ingress DAN can know the address information of the old ingress 187 DAN is TBD. Moreover, how the new ingress DAN can know whether the 188 connected client needs service continuity or not is TBD. The old 189 ingress DAN transmits the mobility notification message and 190 establishes the tunnel with the new ingress DAN. The new ingress DAN 191 transmits the mobility indication message to the egress DAN and 192 establishes the tunnel with the egress DAN. From now on, the old 193 ingress DAN and egress DAN transmit all service results to the client 194 through the new ingress DAN. 196 Client old ingress DAN new ingress DAN egress DAN Service 197 instance 198 | | | | | 199 |<--connect -->| | | | 200 | |<===== est. tunnel ====>| | 201 |-service req->| | | | 202 | |------ service request --------->| | 203 | | | |-service req ->| 204 (movement) | | | | 205 | (client move detection) | | | 206 | |- notify msg ->| | | 207 |<----- connect ---------->| | | 208 | |<-- ind. msg --| | | 209 | |<=est. tunnel=>| | | 210 | | | |<- svc result--| 211 | |<---- service result -----| | 212 | |- svc result ->| | | 213 |<--- svc result ----| | | 214 | | |--- ind. msg --->| | 215 | | |<= est. tunnel =>| | 216 | | | |<- svc result--| 217 | | |<-- svc result --| | 218 |<--- svc result ----| | | 220 Figure 1: Message exchange procecure - proactive method 222 Client old ingress DAN new ingress DAN egress DAN Service 223 instance 224 | | | | | 225 |<--connect -->| | | | 226 | |<===== est. tunnel ====>| | 227 |-service req->| | | | 228 | |------ service request --------->| | 229 | | | |-service req ->| 230 (movement) | | | | 231 |<----- connect ---------->| | | 232 | |<-- req. msg --| | | 233 | |- notify msg ->| 234 | |<=est. tunnel=>| | | 235 | | | |<- svc result--| 236 | |<---- service result -----| | 237 | |- svc result ->| | | 238 |<--- svc result ----| | | 239 | | |--- ind. msg --->| | 240 | | |<= est. tunnel =>| | 241 | | | |<- svc result--| 242 | | |<-- svc result --| | 243 |<--- svc result ----| | | 245 Figure 2: Message exchange procecure - reactive method 247 4. Security Considerations 249 TBD 251 5. IANA Considerations 253 TBD 255 6. References 257 [1] Y. LI, L. Iannone, D. Trossen, P. Liu and C. Li, "Dynamic- 258 Anycast Architecture", draft-li-dyncast-architucture-03 (work in 259 progress, Mar. 7, 2022. 260 [2] D. Johnson, C. Perkins and J. Arkko, "Mobility Support in 261 IPv6", IETF RFC 3775, June 2004. 263 [3] S. Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury and 264 B. Patil, "Proxy Mobile IPv6", IETF RFC 5213, Aug. 2008. 266 [4] Bradner, S., "Key words for use in RFCs to Indicate 267 Requirement Levels", BCP 14, RFC 2119, March 1997. 269 Author's Address 271 Jaehwoon Lee 272 Dongguk University 273 30, Pildong-ro 1 gil, Jung-gu 274 Seoul 04620, KOREA 275 Email: jaehwoon@dongguk.edu