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]