Internet DRAFT - draft-jang-shim6-address-selection

draft-jang-shim6-address-selection





   Network Working Group                                      I-D. Jang 
   Internet Draft                                                  ETRI 
   Expires: April 2006                                         T-W. You 
                                                                   ETRI 
                                                               S-Y. Lee 
                                                                   ETRI 
                                                           October 2005 
                                                                         
    
              Another Aspects of Address Selection in Multi6 
                   draft-jang-shim6-address-selection-01 
                                      
    
    
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 April 24, 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 - April, 24 2006               [Page 1] 

            Another Aspects of Address Selection in Multi6October 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 - April 24, 2006               [Page 2] 

            Another Aspects of Address Selection in Multi6October 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 - April 24, 2006               [Page 3] 

            Another Aspects of Address Selection in Multi6October 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.2End-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 - April 24, 2006               [Page 4] 

            Another Aspects of Address Selection in Multi6October 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 - April 24, 2006               [Page 5] 

            Another Aspects of Address Selection in Multi6October 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 - April 24, 2006               [Page 6] 

            Another Aspects of Address Selection in Multi6October 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.2 Asymmetric path 
    
 
 
Jang                   Expires - April 24, 2006               [Page 7] 

            Another Aspects of Address Selection in Multi6October 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 - April 24, 2006               [Page 8] 

            Another Aspects of Address Selection in Multi6October 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 - April 24, 2006               [Page 9] 

            Another Aspects of Address Selection in Multi6October 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 - April 24, 2006              [Page 10] 

            Another Aspects of Address Selection in Multi6October 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 - April 24, 2006              [Page 11] 

            Another Aspects of Address Selection in Multi6October 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 - April 24, 2006              [Page 12]