Network Working Group I-D. Jang Internet Draft ETRI Expires: January 2006 T-W. You ETRI S-Y. Lee ETRI July 2005 Another Aspects of Address Selection in Multi6 draft-jang-shim6-address-selection-00 Status of this Memo 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. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 10, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract The address selection mechanisms have been suggested under the circumstance occurring link failure already. But this draft proposes Jang Expires - January 10, 2006 [Page 1] Another Aspects of Address Selection in Multi6 July 2005 various considerations to address selection such as load sharing without presenting address selection mechanism clearly. The goal of this document is merely referred various situation that have to consider when we make out address selection mechanism in the context of load sharing. Table of Contents 1. Introduction...................................................2 2. Goal and Non Goal..............................................3 2.1 Goal.......................................................3 2.2 Non Goal...................................................3 3. Consideration of Address selection for load sharing............3 3.1 What is target for load sharing?...........................4 3.1.1 Site exit router......................................4 3.1.2 End-to-end link or session............................4 3.2 Who offer the information for address change?..............5 3.2.1 End node..............................................5 3.2.2 Agent basis...........................................5 3.3 When does address selection considered?....................5 3.3.1 Session start time....................................5 3.3.2 After session establishment...........................6 3.4 What is situation to trigger address change process?.......6 3.4.1 When the performance bottleneck is occurred at current link..................................................6 3.4.2 When other address pair is good link status compare with current one?..........................................6 3.5 Are ingress and egress link equal?.........................7 3.5.1 symmetric path........................................7 3.5.2 Asymmetric path.......................................7 3.6 Anyone must achieve address change process?................8 3.6.1 Any one node..........................................8 3.6.2 Only one node whether source or destination node......8 4. An example of address selection scheme based on load sharing...8 4.1 Step 1: Monitoring.........................................9 4.2 Step 2: The best address pair selection....................9 4.3 Step 3: Change address pair................................9 5. Security Considerations.......................................10 6. IANA CONSIDERATIONS...........................................10 7. References....................................................10 Author's Addresses...............................................10 1. Introduction A site should be able to distribute both inbound and outbound traffic between multiple transit providers by multihoming [RFC3582]. Outbound traffic can be shared across ISPs using appropriate exit selection Jang Expires - January 10, 2006 [Page 2] Another Aspects of Address Selection in Multi6 July 2005 policies. Inbound traffic can be distributed using appropriate export policies designed to influence the exit selection of remote sites sending traffic back towards the multihomed site. At result, load sharing is one of advantages to get through multihoming. For load sharing in multi6, a site should distribute traffic load through the selection of appropriate address. The address selection mechanism have been suggested in [ID.SELECTION][ID.FAIL]. But, these mechanisms became discussion an address selection method only when occurs failure detection. In this draft, we discuss an address selection mechanism for load sharing. The draft is structured as follows: Section 2 describes goal with out of scope of this draft. Next, we explain various situations triggering address change process for load sharing in section 3. Finally, section 4 present approaches to solution of address change procedure considering load sharing. For the purposes of this draft, we arrange the considerations to define an address selection mechanism for load sharing. 2. Goal and Non Goal 2.1 Goal The goal of this memo is to arrange the requirements to consider the address selection for load sharing. And we proposed possible approaches to achieve address change process for load sharing. 2.2 Non Goal It is not the goal of this memo to define an address selection mechanism for load sharing to the explicit. This document was only referred various situation that have to consider when we make out address selection mechanism for load sharing. Therefore, it did not explain about mechanism to change primary address pair with solution for problems that happen in each situation. In addition, concretely, there are not refer to measurement method getting traffic load information about operational network path for load sharing such as active or positive measurement. 3. Considerations of Address selection for load sharing Multi-homing has the potential consideration of being able to distribute the total traffic load across a number of network paths beside session. Jang Expires - January 10, 2006 [Page 3] Another Aspects of Address Selection in Multi6 July 2005 Load sharing in multi-homing is achieved through address selection; in this address selection from multiple addresses pool implies a selection of one particular network path. The issue here is how does the local host make a selection of the "best" source locator supporting multi-homing goals, such as survivability, redundancy, and load sharing? And there are some obviously constrained by the current state of the topology of the network, and the primary objective of the selection process. In order to support to session resilience, the mechanism for address selection in hosts is to allow establishing new communications after an outage, as described in [ID.SELECTION][ID.FAIL]. In this chapter, we will describe diverse considerations to accomplish address selection for load sharing, and present some mechanisms to be performing at each environment. 3.1 What is target for load sharing? 3.1.1 Site exit router If address selection will be decided based on traffic load sharing within a multi-homing site, this procedure should be taken into account that amount of traffic to be loaded to site exit routers. When one site exit router is to be imposed overloaded traffic load not to handle ordinary, re-homing should be occurred using address change. In order to trigger address change, end node has to monitor traffic status within own site, and decide threshold value, which is calculated ratio of capacity of site exit router to amount of loaded traffic. However, an end node must monitor amount of generation traffic in multi-homing site at all the time, and also knows amount of loaded traffic to site exit routers. 3.1.2 End-to-end link or session If address selection process will be implicated end-to-end network paths, there is a consequent interaction between the address selection process and traffic engineering functions. An end node has to maintain addresses pools, as like Common Endpoint Locator Pools (CELP) [ID.FRAME], include available addresses, which are received from multiple ISP, and operation address pairs, which are combination with available addresses, and to maintain a table, which contains traffic load information for each possible path. Jang Expires - January 10, 2006 [Page 4] Another Aspects of Address Selection in Multi6 July 2005 Consequently, an end node to address selection for load balancing measure end-to-end traffic status, and then this information should be keep traffic load table. The address change process should be triggered, if the performance of current communication network path will be not good rather than other network path, which is to inside traffic load table. 3.2 Who offer the information for address change? 3.2.1 End node As mentioned before, an end node should manage address pools include available addresses and operational address pairs. However, in order to perform address selection for load balancing, an end node has to measure traffic load for network path represented operational address pairs, and must manage and monitor whole traffic load that happen in site, and overhead information that take to site exit router. Therefore, if these all actions were accomplished in the end node, more many overhead should be happened by address change mechanism for load balancing compare with achieve actual work that means to operate application. 3.2.2 Agent basis On the other hand, if there were to be considerations for end node's performance, it is better other some agent entrust the management of result of measurement about each possible network path, as like traffic measurement and administration of information table, such as traffic load table, than an end node managed one. However, by some agent, it has supply some methods to share to all nodes in site, at this point, part of security becomes weak. 3.3 When does address selection considered? 3.3.1 Session start time Address selection process can happen, when it is the session start time, or after the session has been establish already to change network path in timely manner. At the point to beginning the session, end node have address pool to receive from each ISP, and also have address pairs that is combination addresses using address pool. But, the traffic load table is not perfect status because it did not achieve traffic measurement Jang Expires - January 10, 2006 [Page 5] Another Aspects of Address Selection in Multi6 July 2005 about each network path yet. In this case, there are two approach methods. First, do to achieve traffic measurement about each available network path, which means operational address pairs, and to accomplish traffic load table. After that, the network path that performance is high, in other words, little loaded amount of traffic, is selected by measurement to send data packet. But in this case, the delay for session establish is grown, it can be bad in the whole performance side. Secondly approaches, in the beginning session establishment, select address pair to do random. When it is the session start time, we can speak that it is suitable in load sharing side to address selection randomly by random of meaning. 3.3.2 After session establishment After session has established already, traffic measurement is start up about available address pairs with network path to use present communication, and then traffic load table completes as a result. In this case, address change process is happens by comparison performance of traffic load table's address pairs and present connection link's performance. However, if a node has to change address dynamically among the communication, following situation should be considered. 3.4 What is situation to trigger address change process? 3.4.1 When the performance bottleneck is occurred at current link. As like [ID.SELECTION][ID.FAIL], when the current link's failure was detected, address change process has triggered clearly. In the above case, if we should consider load balancing, address change process has to occur to improve performance by selection path to better status. Therefore, an end node or some agent must monitor traffic load table, and find address pair that show the best performance currently. At last, address change process will be achieved with selected address pair using M6 functionally [ID.FUNC]. 3.4.2 When other address pair is good link status compare with current one? Jang Expires - January 10, 2006 [Page 6] Another Aspects of Address Selection in Multi6 July 2005 If communication session has been established, operational address pairs have been monitored. Therefore, it could compare with current link status and network path status in traffic load table, could find network path on aspect of performance better than present link status. In this case, we should consider as followings. At first, address change process should be achieved absolutely, if it find better network path than present link status. In this approach, whenever the path to good performance appears, address change mechanism is triggered. Even if the system performance is good in short period, the entire system performance can be reduced by address change's fluctuation. Secondly, address change process should be hold back by the some policy, which controlled node not to achieve address selection mechanism through comparison with arithmetic result of link status. For example, Instead of arithmetically compare measured performance between possibility address pairs in traffic load table with measured current link status, it could be achieved comparing the lastly calculated value that add the result, which measured traffic load about address pairs and the value that multiply the amount of generated traffic in present node by constant, which is represented by policy circumstance. Detailed example would be referring to chapter 5. Because it can compare with the result that add amount of traffic that is overloaded to selected address pair, this comparing method is could prevent phenomenon of this address change's fluctuation 3.5 Are ingress and egress link equal? 3.5.1 symmetric path Usually communication network path have symmetrical characteristics. That is, ingress path and egress path are same in communication session. In the symmetric path, If link failure or re-homing trigger occurred to load balancing aspect, an end node select best address pair by measurement information, and next time, after complete address pair change process, send confirm message to end of that to remote host announcing network path changed. Because, it could be prevent re- homing trigger additionally to remote node. 3.5.2Asymmetric path Jang Expires - January 10, 2006 [Page 7] Another Aspects of Address Selection in Multi6 July 2005 In the asymmetric path, at the same situation about re-homing trigger, the mutual end nodes can select address pair by individual basis. As a result, data packet are sent or received with ingress path and egress path different. Therefore confirm message need not to be sent to remote host. The other side, both end nodes are keep information of egress path at all the time regardless of own egress path. 3.6 Anyone must achieve address change process? 3.6.1 Any one node Each node has remote node's address pool as well as own. And also possibility communicational address pairs are managed. Therefore, address change process can achieve at source or destination node. In this case, it is more efficient, if communication path is asymmetric path. But in the symmetric environment, address change process procedure can collide. For instance, the problem of communication path, which include link failure and load balancing, has occurred, then both end nodes can sense all problems, and they will achieve address change process simultaneously. Consequently the process of way that send request message before address change process, and that send confirm message after address change process need. Additionally, the information of address pool and address pairs are managed identically at the both nodes. Therefore this information will be synchronized through some sharing mechanism. 3.6.2 Only one node whether source or destination node The other side, if it allow address change process in only one node, two nodes need not to keep information about addresses, and also collision to request for address change does not happen at the same time. But there is shortcoming, as followings. One node, which can not execute address change process, do not have to deal with the problem so quickly that happen in own side, and must wait until the other node achieve address change process after detect this problem. 4. An example of address selection scheme based on load sharing Jang Expires - January 10, 2006 [Page 8] Another Aspects of Address Selection in Multi6 July 2005 In this chapter, we make out address change procedure considering load balancing keeping in mind organized various kinds of consideration items in chapter 4. Address change trigger can be achieved by following step considering load sharing. 4.1 Step 1: Monitoring As like [ID.SELECTION][ID.FAIL], link failure is obviously situation of address pair change. But in multi-homing environment, there is the potential consideration of being able to distribute the total traffic load across as number of network paths. Therefore end node have to monitor traffic load situation about current communication link status and operational network path, which means operational address pairs as mentioned [ID.FAIL], as like traffic measurement manner. And measured result should be managed with operational address pairs. This document ordered that is traffic load table. This traffic load table should be consisted of fields such as GUID/Port number/Rtt/Measured result/Timeout and so on. 4.2 Step 2: The best address pair selection In this step, policy part is implicated. And we must solve the problem that refers to section 3.3 and 3.4. When we select best address pair, use calculated final value applying policy part without using measured result field in traffic load table simplicity. This value can be calculated as follows in example: V-Cal = R-measured + T-gen * C-pol Final calculated value (V-cal) that is compared with current link's traffic load status for address change trigger is represented by that added the value of measured result in traffic load table (R-measured) and the value of that amount of traffic to generate in present session (T-gen) times policy constant (C-pol). In section 3.4.2, the address change trigger is occurred comparing calculated value (V-cal) with traffic load status in the current link. For reference, policy constant (C-pol) could be established by appropriate value differently in each address pairs. 4.3 Step 3: Change address pair In this phase, as refer to section 3.5, when the address change procedure was happened, request and confirm message for address change was sent to source and destination node in the case of Jang Expires - January 10, 2006 [Page 9] Another Aspects of Address Selection in Multi6 July 2005 symmetric link. And it must decide threshold value to prevent fluctuation phenomenon by address change process frequently. For example, as like in section 3.4.1, whenever the performance degradation was happened, in only case of performance deterioration more than 40% of average performance occurred, address change process was operated clearly. The other case of section 3.4.2, the address change process was operated in case of that difference of performance happened more than any threshold value. 5. Security Considerations This document has no direct impact on Internet infrastructure security. 6. IANA Considerations This document has no IANA considerations. 7. References 7.1 Normative References [ID.FAIL] J. Arkko, "Failure Detection and Locator Selection in Multi6", draft-ietf-multi6-failure-detection-00, January 2005. [ID.FRAME] D. Crocker, A. Doria, "Framework for Common Endpoint Locator Pools", draft-crocker-celp-00, February 2004. [ID.FUNC] M. Bagnulo, J. Arkko, "Functional decomposition of the M6 protocol", draft-ietf-multi6-functional-dec-00, Desember 2004. 7.2 Informative References [RFC3582] J. Abley, B. Black, V. Gill, "Goals for IPv6 Site- Multihoming Architectures", RFC 3582, August 2003. [ID.SELECTION] C. Huitema, R. Draves, M. Bagnulo, "Address selection in multihomed environments", draft-huitema-multi6-addr-selection-00, October 2004. Author's Addresses Indong Jang ETRI/PEC Jang Expires - January 10, 2006 [Page 10] Another Aspects of Address Selection in Multi6 July 2005 161 Gajeong-Dong, Yuseong-Gu, Daejeon 305-350, Korea Tel : +82 42 860 4978 Fax : +82 42 861 5404 E-mail : indoi@etri.re.kr Taewan You ETRI/PEC 161 Gajeong-Dong, Yuseong-Gu, Daejeon 305-350, Korea Tel : +82 42 860 4996 Fax : +82 42 861 5404 E-mail : twyou@etri.re.kr Seungyun Lee ETRI/PEC 161 Gajeong-Dong, Yuseong-Gu, Daejeon 305-350, Korea Tel : +82 42 860 5508 Fax : +82 42 861 5404 E-mail : syl@etri.re.kr Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS Jang Expires - January 10, 2006 [Page 11] Another Aspects of Address Selection in Multi6 July 2005 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Jang Expires - January 10, 2006 [Page 12]