idnits 2.17.00 (12 Aug 2021) /tmp/idnits41096/draft-liumin-multi6-loadsharing-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 453. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 430. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 437. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 443. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 14 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 10 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '6' on line 411 looks like a reference -- Missing reference section? '1' on line 392 looks like a reference -- Missing reference section? 'RFC2119' on line 110 looks like a reference -- Missing reference section? '3' on line 399 looks like a reference -- Missing reference section? '4' on line 403 looks like a reference -- Missing reference section? '2' on line 395 looks like a reference -- Missing reference section? '5' on line 407 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT Min Liu 2 ICT 3 Expires June, 2005 5 December, 2004 7 Load Sharing in Multihomed Host 8 draft-liumin-multi6-loadsharing-00.txt 9 Status of this memo 10 This document is an Internet-Draft and is subject to all provisions 11 of section 3 of RFC 3667. By submitting this Internet-Draft, each 12 author represents that any applicable patent or other IPR claims of 13 which he or she is aware have been or will be disclosed, and any of 14 which he or she become aware will be disclosed, in accordance with 15 RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on June, 2005. 35 Copyright Notice 36 Copyright (C) The Internet Society (2004). 38 Abstract 39 In order to reach the goal of load sharing and traffic engineering in 40 multihoming, there must be some mechanism for the local host to 41 make a selection of the "best" source locator to used. Obviously the 42 selection includes the objective to select a currently viable path. 43 What's more, it also includes the objective to select a path with 44 larger bandwidth, which is more difficult to judge than reachability. 45 In this memo, we propose a simple mechanism to determine the 46 availability and bandwidth condition between a multihomed host and 47 its ISP. It will help to share the load among multiple paths and 48 provide better performance for the host's traffic. This mechanism 49 could be part of traffic engineering functions, which could be used 50 as the basis of locator selection before initial session 51 establishment and aslo could be used to trigger locator swithes to 52 avoid loss of connectivity, long delay or large loss rate. 54 Table of Contents: 55 1 Introduction.....................................................4 56 2 Problem Statement................................................5 57 3 Scenario Description ............................................6 58 4 Solution Description ............................................7 59 4.1 Overview of the Procedure......................................7 60 4.1.1 Assumption...................................................8 61 4.1.2 List of Available ISP........................................8 62 4.1.3 Locator Selection............................................9 63 4.2 Idle Rate Estimation..........................................10 64 5 Security Consideration..........................................12 65 6 IANA Considerations ............................................12 66 References........................................................13 67 Authors' Addresses................................................13 68 Intellectual Property and Copyright Statements....................14 70 1. Introduction 71 Multiple access links could be used to improve the aggregate 72 bandwidth and the overall availability of Internet connectivity. When 73 the access links are subscribed from different ISPs, this approach is 74 called multihoming. Multihoming is a mechanism by which enterprises 75 can satisfy a number of high-level requirements. As described in [6], 76 with the advent of inexpensive and high-bandwidth broadband 77 connection technologies for home users, multihoming is poised to 78 emerge from a niche technique for large enterprises and become a 79 dominant technology that underlies the Internet connectivity 80 solutions for small to mid-sized businesses. 82 RFC 3582 [1] documents some goals that a multihoming approach should 83 attempt to address, among which load sharing and traffic engineering 84 are two important goals. Then the problem is how does the local host 85 make a selection of the "best" source locator to used? Obviously the 86 selection includes the objective to select a currently viable path. 87 What's more, it also includes the objective to select a path with 88 larger bandwidth, short delay or small loss rate, which is more 89 difficult to judge than reachability. At the conceptual level, a 90 multihoming load balancing/sharing system must be able to determine 91 the available bandwidth to a remote subnet through an access link, 92 assign incoming and outgoing Internet traffic to the available access 93 links, and detect failed access links and divert Internet traffic 94 around them. However, in practice, it is very difficult to obtain 95 such a clear picture of the Internet. Therefore, some compromises 96 must be made. 97 In this memo, we propose a simple mechanism to determine the 98 availability and bandwidth condition between a multihomed host and 99 its ISP. It will help to share the load among multiple paths and 100 provides better performance for the host's traffic in an efficient 101 fashion. This mechanism could be part of traffic engineering 102 functions, which could be used as the basis of locator selection 103 before initial session establishment and aslo could be used to 104 trigger locator swithes to avoid loss of connectivity, long delay or 105 large loss rate. 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in [RFC2119]. 111 2. Problem Statement 112 While multihoming to multiple providers is motivated primarily 113 by a need for link-level and provider-level fault tolerance, there 114 are other goals for subscribers to leverage multihoming. For example, 115 performance to different parts of the network may vary depending on 116 which upstream provider is used. In such situations, careful route 117 selection can significantly improve performance. 119 In this memo, we propose a simple mechanism to help the local host 120 make a selection of the "best" source locator to used before initial 121 session establishment and trigger locator swithes if necessary. This 122 mechanism will have the following characteristics: 124 o It is simple and easy to deployed. 126 o The goal of this mechanism is to help implement load sharing and 127 traffic engineering in multihoming. 129 o The mechanism could be implemented as a protocol element within 130 the host or at a site-exit router. 132 o The mechanism could determine the availability and bandwidth 133 condition between a multihomed host and its ISP. To decrease the 134 cost, end-to-end bandwidth condition will not be determined. 136 o The probing traffic is very little. The probing packets could also 137 be used as keep-alive traffic if there are some tunnles. 139 o The idle rate estimation function in the mechanism could reports a 140 test result per second, which could be used to estimate available 141 bandwidth and update the records. This time granularity could be 142 configured as needed. 144 o Host could configure the threshold of bandwidth to trigger locator 145 swithes. 147 o To provide the user or the application the ability to configure 148 different "Weight" to different transmission technology or access 149 network, for matters of cost, efficiency, politics, etc. 151 o After determining the "best" candidate source locator,in order to 152 verify that the locator is working, a Reachability Test exchange 153 is needed. The details of Reachability Test is out of the scope of 154 this draft. 156 3. Scenario Description 157 The scenario that we concerned in our solution is the simple multi- 158 homing environment showed in Figure 1( Figure 1 in [3]). 160 +------+ 161 |remote| 162 | host | 163 | R | 164 +------+ 165 | 166 + - - - - - - - - - - - + 167 | Internet Connectivity | 168 + - - - - - - - - - - - + 169 / \ 170 +---------+ +---------+ 171 | ISP A | | ISP B | 172 +---------+ +---------+ 173 | Path A | Path B 174 + - - - - - - - - - - - - - - - - - - - - + 175 | multi- | | | 176 homed +------+ +------+ 177 | site | site | | site | | 178 | exit | | exit | 179 | |router| |router| | 180 | A | | B | 181 | +------+ +------+ | 182 | | 183 | local site connectivity | 184 | 185 | +-----------+ | 186 | multihomed| 187 | | host | | 188 +-----------+ 189 + - - - - - - - - - - - - - - - - - - - - + 190 Figure 1. simple multihoming environment 192 The major characteristic of this scenario is that the address space 193 used by, and advertised as reachable by, ISP A is distinct from the 194 address space used by ISP B. 196 More complex scenarios such as the local multihomed host is 197 communicating with a remote multihomed host, and the local host 198 should have some discretion in the choice of a destination locator is 199 out of the scope of this draft. 201 4 Solution Description 202 Available bandwidth (avail-bw for short) is a crucial metric in 203 capacity provisioning, routing, traffic engineering, QoS management 204 and so on. At the conceptual level, it is also the basis for a 205 multihoming load balancing/sharing system. However, end-to-end 206 avail-bw estimation is a very challenging task, which often needs a 207 long measurement period and a large quantity of probing traffic. As a 208 result, currently, end-to-end avail-bw estimation still remain at the 209 theoretical research level and impractical for many actual 210 applications. Thus in multihoming environment, it is impossible to 211 determine the available bandwidth from a host to a remote subnet in 212 real time to make a selection of the "best" source locator to used 213 before initial session establishment or to trigger locator swithes 214 when necessary. 216 In the simple multihoming environment showed in Figure 1, when we 217 only consider the availability and bandwidth condition between a 218 multihomed host and its ISP, we can simplify the scenario and 219 estimate the network condition efficiently with low cost. 220 4.1 Overview of the Procedure 221 The procedure can be showed in Figure 2: 223 +------------------------------------------------+ 224 | +---------------+ +------------+ | 225 | | | | | | 226 | | Calculate |/-------| Packet |/------ 227 | | idle rate & |\-------| receiver |\------ 228 | | avail-bw | | | | recv packets 229 | +---------------+ +------------+ | 230 | | 231 | +---------------+ +------------+ | 232 | | | | | | 233 | | Random |------\ | Packet |-------\ 234 | | generator |------/ | composer |-------/ 235 | | | | | | 236 | +---------------+ +------------+ | send out packets 237 | /\ | for idle rate 238 | || | estimation 239 | + - - - - - + | 240 | | ISP List | | 241 | + - - - - - + | 242 | | 243 | + - - - - - + | 244 | | Target Add| | 245 | + - - - - - + | 246 | Multi-homed || | 247 | \/ | send out packets 248 | host +------------+ | for reachability 249 | | | | 250 | |Reachability|-------\ 251 | | Tester |-------/ 252 | | | | 253 | +------------+ | 254 +------------------------------------------------+ 256 Figure 2. solution procedure 257 4.1.1 Assumption 258 We assume that the capacity between a multihomed host and its ISP is 259 known. Generally, capacity is unchanged and could be known from ISP 260 or through some router inquiry software. Thus, if we could estimate 261 the idle rate of the path from the host to its ISP, the avail-bw 262 condition could be indicated to a certain extent. 264 4.1.2 List of Available ISP 266 For a multihomed host which has several upstream provider to choose 267 between, we could estimate the idle rate of the path from the host 268 to its each upstream provider in real time. For example, in Figure 269 1, we assume the capacity of Path A is C(A). We could estimate the 270 idle rate of Path A, which could be refered to as I(A). Then the 271 product of C(A) and I(A) could indicate the avail-bw condition of 272 Path A, which could be refered to as BW(A). Similarly, I(B) and BW(B) 273 could also be estimated. Each ISP and its corresponding capacity, 274 idle rate and avail-bw will be stored in the "list of available ISP". 275 Basically, each network path has different cost, performance, 276 access range, and reliability. The user or the application have the 277 ability to configure different "Weight" to different transmission 278 technology or access network. The item "Weight" will also be stored 279 in the "list of available ISP". 281 4.1.3 Locator Selection 283 Local attempts to initiate a communication with remote hosts 284 should take into account the current connectivity state in 285 undertaking locator selection and setting up initial locator 286 sets. Before initiate a new session, locator selection processor 287 should search the "list of available ISP" to do some load sharing. 288 When the session does not have specific requirement of bandwidth, the 289 locator selection processor could implement flexible load sharing 290 policy based on the items in "list of available ISP". However, if the 291 session has specific requirement of bandwidth, only ISPs with 292 sufficient avail-bw will be considered for load sharing. If no ISP 293 has sufficient avail-bw, different policies could be performed. For 294 example,one feedback could be sent to corresponding applications if 295 needed; the access control element could refuse the new session; or 296 the locator selection processor could choose the ISP with the largest 297 avail-bw as the candidate source locator. 299 After determining the "best" candidate source locator,in order to 300 verify that the locator is working, a Reachability Test exchange is 301 needed. This can be used to check if the locator that is chosen 302 is working properly. The design and implementation of Reachability 303 Test is out of the scope of this draft. 305 If the Reachability Test succeeds, the candidate source locator will 306 become the selected initial locator for this session. Because the 307 idle rate and avail-bw items in the "list of available ISP" are 308 updated in real time, the change of the network conditions could be 309 monitored in an assured time scope. Host could configure the 310 threshold for these metrics to trigger locator swithes, thus avoid 311 any loss of end-to-end connectivity or QoS on the selected initial 312 locator. 314 4.2 Idle Rate Estimation 315 In the procedure of locator selection described in last section, the 316 kernel problem is how to estimate the idle rate of the path from the 317 host to its ISP in real time. The fundamental idea in our proposal 318 is to send very small packets at random moment and calculate the 319 proportion of minimum delay in total test samples. 321 For one probing packet, if its queuing delay from the host to the ISP 322 is zero, we could consider the path is in idle state at the moment. 323 After sending a number of random probing packets, we can estimate the 324 idle rate in this period. 326 Probing packets could be ICMP echo request packets or UDP packets. 327 The measurement method is similar. The only difference is that 328 the measurement must adopt the C/S architecture when using UDP 329 probing packetsú¼while ICMP measurement could be implemented only in 330 the multihomed host, thus need no modification in the ISP. However, 331 this method relies on the routers in ISP handling ICMP packets and 332 timely delivery of acknowledgement. 334 In order to decrease the overhead of probing traffic, the probing 335 packet should be as small as possible. In addition, considering that 336 if the interval between probing packets is too short, the front 337 packet will has great influence on the latter one, the interval 338 should be large enough. 340 In fact, what we can measure is the transmission delay, not queuing 341 delay. The transmission delay is the sum of two components: a fixed 342 propagation delay and a variable queuing delay. We assume the 343 observed minimum delay in all probing packets as the propagation 344 delay. In other words, we assume the minimum delay indicate the path 345 is in idle state at the sending time. Certainly, such an assumption 346 may result in error in case of a very congestion network, where none 347 probing packet has been transmitted without queuing delay because the 348 avail-bw is zero. But we can take some action to eliminate such 349 error. For example, we can record the number of probing packets 350 received by the idle rate estimation function. When the avail-bw is 351 extremely small, there will be packet loss. So if the number of 352 accepted packets is significantly different from the prospective 353 value, we can draw the conclusion that the idle rate/avail-bw 354 approximates zero, thereby avoid the error in the assumption. 356 For each measurement, the transmission delay of each probing packet 357 will be saved in an array. When this measurement is over, the number 358 of accepted packets will be compared with the sending number. If the 359 number of accepted packets is significantly different from the 360 prospective value, the idle rate/avail-bw approximates zero. 361 Otherwise, search the array and find the minimum value, and calculate 362 the arisen times of this value. We can calculate the proportion of 363 the minimum result in total test samples and get the idle rate in the 364 measurement period. 366 The idle rate estimation function could reports a test result per 367 second, which could be used to estimate available bandwidth and 368 update the records in "list of available ISP". This time granularity 369 could be configured as needed. At the host startup, the function 370 calculates the avail-bw from all probe traffic. When the probe 371 traffic becomes more than 50 packets, the function calculates 372 avail-bw from the last 50 packets. The number of probing packets in 373 calculation could also be configured and modified. 375 The probing packets could be used as keep-alive traffic if there are 376 some tunnles between the host and its ISP. For this purpose, it needs 377 an estimate of the "lifetime" parameter used in the tunneling 378 technique. 380 5 Security Consideration 381 Because the idle rate estimation is implemented between host and its 382 ISP, it will not open up a host on either end of a communication to a 383 time-based attack. The authentication for host will follow the 384 specific ISP's security consideration and existing machenisms. Thus 385 the security considerations for this proposal should be the same as 386 described in [4]. 388 6 IANA Considerations 389 This document has no associated IANA actions. 391 Normative References 392 [1] Abley, J., Black, B. and V. Gill, "Goals for IPv6 393 Site-Multihoming Architectures", RFC 3582, August 2003. 394 Informative References 395 [2] Lear, E., "Things MULTI6 Developers should think about", 396 draft-ietf-multi6-things-to-think-about-00.txt(Work in 397 progress), June 2004. 399 [3] Huston, G., "Architectural Approaches to Multi-Homing for IPv6", 400 draft-ietf-multi6-architecture-02.txt(Work in progress), October 401 2004. 403 [4] Nordmark, E. and T. Li, "Threats relating to IPv6 multi-homing 404 solutions", draft-ietf-multi6-multihoming-threats-01.txt(Work in 405 progress), July 2004. 407 [5] Hinden, R., "IPv6 Host to Router Load Sharing", 408 draft-ietf-ipv6-host-load-sharing-02 (work in progress), May 409 2004. 411 [6] Guo, F. and Chen, J., et al. "Experiences in Building A 412 Multihoming Load Balancing System", INFOCOM 2004. 414 Authors' Addresses 415 Min Liu 416 Institute of Computing Technology 417 Chinese Academy of Sciences 418 Box 2704, Beijing, 100080 PRC 419 Email: liumin@ict.ac.cn 421 Intellectual Property Statement 423 The IETF takes no position regarding the validity or scope of any 424 Intellectual Property Rights or other rights that might be claimed to 425 pertain to the implementation or use of the technology described in 426 this document or the extent to which any license under such rights 427 might or might not be available; nor does it represent that it has 428 made any independent effort to identify any such rights. Information 429 on the procedures with respect to rights in RFC documents can be 430 found in BCP 78 and BCP 79. 432 Copies of IPR disclosures made to the IETF Secretariat and any 433 assurances of licenses to be made available, or the result of an 434 attempt made to obtain a general license or permission for the use of 435 such proprietary rights by implementers or users of this 436 specification can be obtained from the IETF on-line IPR repository at 437 http://www.ietf.org/ipr. 439 The IETF invites any interested party to bring to its attention any 440 copyrights, patents or patent applications, or other proprietary 441 rights that may cover technology that may be required to implement 442 this standard. Please address the information to the IETF at 443 ietf-ipr@ietf.org. 445 Disclaimer of Validity 447 This document and the information contained herein are provided on an 448 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 449 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 450 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 451 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 452 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 453 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 455 Copyright Statement 457 Copyright (C) The Internet Society (2004). This document is subject 458 to the rights, licenses and restrictions contained in BCP 78, and 459 except as set forth therein, the authors retain all their rights.