One document matched: draft-deng-mip6-ha-loadbalance-01.txt
Differences from draft-deng-mip6-ha-loadbalance-00.txt
Hui Deng
INTERNET-DRAFT Hitachi (China)Investment Ltd.
<draft-deng-mip6-ha-loadbalance-01.txt> Rong Zhang
China Telecom
Xiaolong Huang
University of California at Los Angeles
Kai Zhang
Tsinghua University
Expires: October 2004 April 2004
Load Balance for Distributed Home Agents in Mobile IPv6
draft-deng-mip6-ha-loadbalance-01.txt
Status of this memo
This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026.
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
This document specifies the dynamical load balance of mechanism
which take account of not only the mobile node registration
information but also data the tunneled data traffic information to
effectively release and prevent the formation of the traffic
bottleneck at the home agent.
TABLE OF CONTENTS
1. Introduction........................................... 3
2. Terminology............................................ 3
3. Previous work.......................................... 4
4. Multiple Home Agents................................... 5
5. Modified Home Agents List.............................. 6
6. Modified Router Advertisement Message.................. 7
Deng, Zhang, Huang, Zhang Expires: October 2004 [Page 1]
INTERNET-DRAFT draft-deng-mip6-ha-loadbalance-01.txt April 2004
7. New Load Balance Information Option Format............. 8
8. Home Agent Reassignment................................ 9
9. Prevention of Duplicate Home Agent Assignment..........11
10. IANA Considerations....................................12
11. Security Considerations................................13
12. Acknowledgements.......................................13
References.............................................14
Authors' Addresses.....................................14
A. Changes from Previous Version of the Draft.............14
Intellectual Property and Copyright Statements..........15
Deng, Zhang, Huang, Zhang Expires: October 2004 [Page 2]
INTERNET-DRAFT draft-deng-mip6-ha-loadbalance-01.txt April 2004
1. Introduction
In Mobile IPv6 [1], home agents are responsible for the registration
of mobile nodes in the home network, and tunneling the data
packets to the mobile nodes when the mobile nodes are not reachable
through its home IP addresses tentativly. but it will cause that
the traffic bottleneck could be formed at a home agent. When the home
agent experiences high intensity of the tunneled traffic and the
mobile node registration information. DHAAD has been specified in
base Mobile IPv6 protocol, but it can be only used for stationary
load balance among multiple home agents. This protocol defines a
hybrid load balance mechanism which takes account of not only the
mobile node registration information but also the tunneled data
traffic information to effectively release and prevent the formation
of the traffic bottleneck at the home agent.
Specific flow state establishment methods and the related service
models are out of scope for this specification, but the generic
requirements enabling co-existence of different methods in IPv6 nodes
are set forth in section 4.
2 Terminology
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].
Following terms are not re-defined. They are included for the
convenience of the readers.
IP
Internet Protocol Version 6 (IPv6).[2]
Mobile IPv6
Mobile IP for IPv6 [3]
Home Agent (HA)
A router on a MN's home link with which the MN has registered
its current Care-of address. While the MN is away from home,
the HA intercepts packets on the home link destined to the
MN's home address, encapsulates them, and tunnels them to the
MN's registered Care-of address.
Mobile Node (MN)
A node that can change its point of attachment from one link to
another, while still being reachable via its home address.
Correspondent Node (CN)
A peer node with which a mobile node is communicating. The
correspondent node may be either mobile or stationary.
Deng, Zhang, Huang, Zhang Expires: October 2004 [Page 3]
INTERNET-DRAFT draft-deng-mip6-ha-loadbalance-01.txt April 2004
Security Association (SA)
An IPsec security association is a cooperative relationship formed
by the sharing of cryptographic keying material and associated
context. Security associations are simplex. That is, two
security associations are needed to protect bidirectional traffic
between two nodes, one for each direction.
Dynamic Home Agent Address Discovery (DHAAD)
A protocol which describes how a home agent can help mobile nodes to
discover the addresses of the home agents [3]. The home agent keeps
track of the other home agents on the same link, and responds to
queries sent by the mobile node.
Home Agents List
Home agents need to know which other home agents are on the same
link. This information is stored in the Home Agents List, as
described in more detail in Section 10.1. The list is used for
informing mobile nodes during dynamic home agent address discovery.
3. Previous Work
The document [4] has described the problem related to switch the
service from the failed home agent to another functional home agent,
and propose some guideline for possible solution. Load balance of
multple home agents also has been illustrated.
In document [5], Virtual Home Agent Reliability Protocol has been
proposed to solve the realibility problem of home agent. The
solution is transparent to mobile node. Principally, this solution
is quite similar to VRRPv6 [6]. Even for VRRP solution which is
related to dynamically assigns responsibility for a virtual router
to one of VRRP routers on a LAN, different vendor has different
solution, some vendors provide layer 3 solution VIP (Virtual IP), and
other vendors can provide layer 2 solution VMAC(Virtual MAC). Besides
VRRP, some other proprietary protocol such as heart-beat can also be
used for avoding reliability problem of home agent. So that will be
inefficient to making a standard about home agent reliability, and
not only vendors, but also carrier/SIP will be quite diffcult to
handle this issue. Furthermore, home agent list and DHAAD have not
been considered in this document yet, but DHAAD have been originally
designed to handle multiple home agents in base Mobile IPv6 protocol.
Besides that, this protocol only has one active home agent to keep
the transparent to mobile node, so it mightbe quite diffculty to do
load balance based on this mechanism. Problem of sequence number in
security assocation have not yet been considered.
Deng, Zhang, Huang, Zhang Expires: October 2004 [Page 4]
INTERNET-DRAFT draft-deng-mip6-ha-loadbalance-01.txt April 2004
Inter Home Agents Protocol (HAHA) [7] has been proposed to provide
multiple home agent redundancy and load-balancing for both Mobile
IPv6 protocol and Nemo basic support protocol. Because HAHA protocl
allows multiple home agents to be placed at different links, it can
prevent home link failure from Mobile IPv6. How to optimize the
synchronizing binding message among multiple link home agents will be
the most important, but this problem has been omited in the document.
Furthermore synchronizing binding of only one particular MN to
multiple home agents simultaneously has been described. Suppose there
are more than 0.1 million users, such kind of synchronizing signal
will be a heavy burdern for network. Considering the reliability of
home agent, if Primary Home Agent is failed, and one CN want to start
communicate with MN, but based on the HAHA protocol, it will be quite
diffcult for CN to find the where is MN because in the home network
even other home agent existed and has been synchronizd. Another issue
related to HAHA is that if all outgoing packets from MN will be
always tunneled through primary home agent, realiability and load
balance will have some problems. Finally network and signaling based
on HAHA is complicatd, but carrier/ISP expect simple deployment of
network architecuture, anyway this solution will be quite useful in
the case of NEMO.
4. Multiple Home Agents
The following Figure gives the topology layout to deploy this
protocol for distributed home agents
|------------------------------| |----------
| | | |
|---| |---| |---| |---|
|HA | |HA | |HA | |FA |
|---| |---| |---| |---|
\
/\ \ /\
/MN\ ------------------- /MN\
/----\ / /----\
/
In this protocol, the home network is composed of multiple Mobile
IPv6 home agents and multiple mobile nodes. Each home agent in the
home network is attached with an access router. When the mobile
nodes reside in the home network, the home agents do not execute any
home agent tasks.
The home agent assignment of the mobile nodes in the home network
can be either evenly assigned among the multiple HAs or unevenly
assigned. Whether the home agent assignment is even or not would
neither arbitrarily affect the original traffic burden problem nor
affect the performance of this protocol.
Deng, Zhang, Huang, Zhang Expires: October 2004 [Page 5]
INTERNET-DRAFT draft-deng-mip6-ha-loadbalance-01.txt April 2004
5. Modified Home Agents List
Each home agent maintains a separate Home Agents List for each link
on which it is serving as a home agent. A new entry is created or an
existing entry is updated in response to receipt of a valid Router
Advertisement in which the Home Agent (H) bit is set. Each Home
Agents List entry conceptually contains the following fields:
o The link-local IP address of a home agent on the link. This
address is learned through the Source Address of the Router
Advertisements [8] received from the router.
o One or more global IP addresses for this home agent. Global
addresses are learned through Prefix Information options with the
Router Address (R) bit set, received in Router Advertisements from
this link-local address. Global addresses for the router in a
Home Agents List entry MUST be deleted once the prefix associated
with that address is no longer valid [8].
o The remaining lifetime of this Home Agents List entry. If a Home
Agent Information Option is present in a Router Advertisement
received from a home agent, the lifetime of the Home Agents List
entry representing that home agent is initialized from the Home
Agent Lifetime field in the option (if present); otherwise, the
lifetime is initialized from the Router Lifetime field in the
received Router Advertisement. If Home Agents List entry lifetime
reaches zero, the entry MUST be deleted from the Home Agents List.
o The preference for this home agent; higher values indicate a more
preferable home agent. The preference value is taken from the
Home Agent Preference field in the received Router Advertisement,
if the Router Advertisement contains a Home Agent Information
Option, and is otherwise set to the default value of 0. A home
agent uses this preference in ordering the Home Agents List when
it sends an ICMP Home Agent Address Discovery message.
Here we extend Home Agents List to support load balance mechanism,
so it can share the traffic information among the home agents
in the home network to make decisions of home agent Reassignment.
To do so, Home Agents List has been extended to indicate the traffic
load level of all home agents in the home network.
The entry has been added to Home Agent Lists related to traffic load
information is:
A. Queue Size
The traffic load indicates the buffer size at a home agent. When
the buffer size of a home agent is lower than a threshold, the
buffer size is considered to be LIGHT.
Deng, Zhang, Huang, Zhang Expires: October 2004 [Page 6]
INTERNET-DRAFT draft-deng-mip6-ha-loadbalance-01.txt April 2004
B. Registered MN Number at a HA
The home agent should monitor its queue size and the registered
mobile node number. Each home agent periodically broadcasts its
traffic load information to all the other home agents in the home
network throuth the router advertisement.
6. Modified Router Advertisement message
Here we extend the Unsolicited Router Advertisement Messages to
include traffic load information. A new option - called traffic
load - is embedded into the Option field of Unsolicited Router
Advertisement Messages.
Routers send out Router Advertisement message periodically, or in
response to a Router Solicitation.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cur Hop Limit |M|O|H|L| Res. | Router Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reachable Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retrans Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
ICMP Fields:
L 1-bit "Load Balance" flag. When set, Load Balance
information will be broadcasted based on Router
Advertisement message, Load Balance information
option will be included in the options.
Res.(Reserved) Reduced from 5-bit to 4-bit unused field. It MUST
be initialized to zero by the sender and MUST be
ignored by the receiver.
Router Lifetime
16-bit unsigned integer. The lifetime associated
with the default router in units of seconds. The
maximum value corresponds to 18.2 hours. A
Lifetime of 0 indicates that the router is not a
default router and SHOULD NOT appear on the default
router list. The Router Lifetime applies only to
Deng, Zhang, Huang, Zhang Expires: October 2004 [Page 7]
INTERNET-DRAFT draft-deng-mip6-ha-loadbalance-01.txt April 2004
the router's usefulness as a default router; it
does not apply to information contained in other
message fields or options. Options that need time
limits for their information include their own
lifetime fields.
Prefix Information
These options specify the prefixes that are on-link
and/or are used for address autoconfiguration. A
router SHOULD include all its on-link prefixes
(except the link-local prefix) so that multihomed
hosts have complete prefix information about on-
link destinations for the links to which they
attach. If complete information is lacking, a
multihomed host may not be able to choose the
correct outgoing interface when sending traffic to
its neighbors.
In the Prefix Information option for use in Router Advertisement
1-bit router address flag Must be set to guarantee Prefix field
containing a complete a global IPv6 address of this home agent.
of The added Option field in the router advertisement should be as
follows.
7 New Load Balance Information Option Format
Load Balance among multiple home agents defines a new Load Balance
Information option, used in Router Advertisements sent by a home
agent to advertise information specific to this router's
functionality as a home agent. The format of the Load Balance
Information option is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Queue Size | Registered MN Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
8
Length
8-bit unsigned integer. The length of the option (including the
type and length fields) in units of 8 octets. The value of this
field MUST be 1.
Deng, Zhang, Huang, Zhang Expires: October 2004 [Page 8]
INTERNET-DRAFT draft-deng-mip6-ha-loadbalance-01.txt April 2004
Reserved
This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
Queue Size (2 byte):
A coarse parameter for the Queue Size in the router's TLT
Registered MN Number (2 byte):
Registered MN number. If more than 256 MN could register a HA,
the field should be a coarse paramter for the MN number in the
router's TLT
Unsolicited Router Advertisement messages should be sent at time
uniformly distributed within [MinRtrAdvInterval, MaxRtrAdvInterval]
according to [8].
To make the traffic information more effective, the Unisolicited
Router Advertisement message with the Traffic Load information
should be sent at time uniformly distributed with in
[MinRtrAdvInterval, MinRtrAdvInterval + IntervalTLTExtention].
IntervalTLTExtention = 2 * MinRtrAdvInterval
Upon receiving the Router Advertisement with the Traffic Load
Information from other home agent, a home agent should record
the traffic load into the its extended Home Agents List. The home
agent keeps the Home Agents List sorted in a non-ascending order
of the traffic load field, unless the traffic load is LIGHT.
For the LIGHT home agent, the Home Agents List is sorted in a
non-ascending order of the registered mobile node number.
In this protocol, the Queue Size field is used to make decisions for
home agent reassignment to release the traffic burden, while the
registered mobile node number field is used to prevent the formation
of the traffic burden.
Home agents MAY include this option in their Router Advertisements.
This option MUST be silently ignored for other Neighbor Discovery
messages.
8. Home Agent Reassignments
In this protocol, at each home agent, a timer is attached for each
entry in the binding update cache. When the timer is time out, the
mobile node corresponding to the entry is considered to be eligible
for home agent reassignment. The timeout time is called RegTIMEOUT.
Deng, Zhang, Huang, Zhang Expires: October 2004 [Page 9]
INTERNET-DRAFT draft-deng-mip6-ha-loadbalance-01.txt April 2004
RegTIMEOUT = MinRtrAdvInterval / Queue Size Indicator
Queue Size Indicator is a paramter indicating the traffic load.
The home agent may select a new home agent in the Home Agents List
for the timeout mobile node according to our home agent reassignment
algorithm. If a new home agent is assigned to the timeout mobile
node, the home agent actively sends out an ICMP Reply message to the
mobile node without the reception of any ICMP Request message.
Different from the standard ICMP reply packet, the ICMP here should
only contain one home agent in the home agent list, which is the
newly selected home agent, other than contains a list home agent.
By receiving this ICMP message, the timeout mobile node should
compare the indicated home agent with its old home agent. If the
indicated home agent in the ICMP Reply message is different from the
old home agent, the mobile node should modify its home agent field
and register at the new home agent by sending a binding update
message to the new home agent IP address.
By using the ICMP messages in the DHAAD mechanism, this protocol can
be implemented in the IETF Mobile IPv6 draft without any changing of
the protocols of the communication between home agents and mobile
nodes.
The frequency of selecting a new home agent for the mobile node is a
tradeoff between the home agent handoff frequency and the load
balance performance. The home agent should not frequently select a
new home agent for the registered mobile node, because the home
agent handoff induces extra control traffic and delays the traffic
forwarding to the mobile nodes. Thus only a very busy home agent or
a potentially very busy home agent should proceed to the home agent
handoff.
When selecting a new home agent, the new home agent should be one of
the most released home agents in the Traffic Load Table. There are
two fields in the traffic load table should be considered in the
home agent selection algorithm. One is the Queue Size field, which
indicates the current traffic load. Another one is the registered
mobile node number, which indicates the potential traffic load in
the future. The home agent should prevent from having too many
registered mobile nodes, so that the future traffic burden formed by
the tunneled traffic for the registered mobile nodes could be prevented.
The new HA Reassignment algorithm is as follows.
Algorithm. HA Reassignment
IF (Self Queue Size > LIGHT) THEN
IF (Other HA Queue Size < LIGHT) THEN
Randomly select a HA with LIGHT Queue.
ELSE IF (Self Queue Size is top 10% in the traffic table) THEN
Randomly select a bottom 10% home agent in the traffic table
END
Deng, Zhang, Huang, Zhang Expires: October 2004 [Page 10]
INTERNET-DRAFT draft-deng-mip6-ha-loadbalance-01.txt April 2004
ELSE THEN
IF (my registered MN number is top 10% in the traffic table) THEN
Randomly select a bottom 10% home agent in the traffic table.
END
END
In the home agent reassignment, only one of the most busy home
agents can select a new home agent for its registered mobile node.
Thus the new home agent assignment does not take place frequently.
In Mobile IPv6, a mobile node only needs the home agent to tunnel
the data traffic before the Correspondent Binding Update Procedure
take place, when the mobile node is moving from one network to
another network. Thus a home agent who has more number of registered
mobile nodes is more likely to experience tunnel traffic because
more mobile nodes potentially will move from one network to another
network. This protocol can force a home agent to start the new home
agent assignment even though the home agent does not experience much
traffic, so that the future traffic burden could be prevented
statistically.
9. Prevention of Duplicate Home Agent Assignments
The home agent reassignment may induce duplicate home agent
assignments. When a mobile node subsequently sends more than one
binding updates to the old home agent, the home agent may have
different decisions on selecting the new home agent for the same
mobile node. When the duplicate home agent assignment occurs, only
the last new home agent is regarded as the new home agent of the
mobile node. The mobile node will only process its Mobile IPv6
tasks with the latest assigned new home agent, while other
duplicate home agents assigned to the mobile node still sit in the
home network without further updates from the mobile node. This
situation is not allowed to happen, because the duplicate home
agents cannot correctly forward the traffic to the mobile node
without the updates from the mobile node.
To uniquely assign a home agent for the mobile node, the home
agent should maintain a Home Agent Handoff Table. The Handoff
Table is used to record whether a mobile node has been handed over
to another HA in a quite recent time. And if that is the case, it
should discover which HA is the last HA assigned to the mobile
node. Thus the last assigned HA will still be the HA assigned for
the mobile node this time. An entry of the Handoff Table has
following fields.
Mobile Node Address This field represents the IP
address of a registered mobile
node, which sends binding updates
to the home agent periodically.
Deng, Zhang, Huang, Zhang Expires: October 2004 [Page 11]
INTERNET-DRAFT draft-deng-mip6-ha-loadbalance-01.txt April 2004
Handing Off (true/false) This field represents whether a
mobile node has been handed over
to another HA in a quite recent
time. If that is the case, the
mobile node should be assigned to
the same home agent as last
assignment.
New Home Agent Address This field records the last home
agent assigned to a registered
mobile node. It avoids duplicate
home agent assignments.
Handoff Expire Time This field represents whether the
Handing Off field of this entry is
valid. If the handoff timer has
expired, the handing off field of
this entry is invalid.
Before the home agent select a home agent for the registering
mobile node, the home agent should check the Home Agent Handoff
Table.
If anyone of the following conditions is true, the mobile node
should be regarded as eligible to select a new home agent.
1. There is no entry for the mobile node in the handoff table.
2. Handing off field is false. Thus the mobile node has not been
handed over to another HA in a quite recent time.
3. Handoff expire time is before the current time.
If the mobile node is eligible to be assigned a new home agent,
the home agent selects a new home agent and writes an entry for
the mobile node into the Home Agent Handoff Table. The handing off
field should be set true, and expire time should cover the
subsequent several binding updates of the mobile nodes.
If the mobile node is illegible to a new home agent assignment,
the home agent assigned to the mobile node should be the new home
agent address in the Home Agent Handoff Table, or the home agent
itself in case of no entry being found.
10. IANA Considerations
This document defines one new Neighbor Discovery [8] options,
which must be assigned Option Type values within the option numbering
space for Neighbor Discovery messages:
o The Load Balance information option
Deng, Zhang, Huang, Zhang Expires: October 2004 [Page 12]
INTERNET-DRAFT draft-deng-mip6-ha-loadbalance-01.txt April 2004
11. Security Considerations
Security Considerations have not been discussed in this draft.
Acknowledgements
The authors would like to thank Hidenori Inouchi, Shiro Tanabe of
Hitachi Central Research Lab. for their comments and suggestions.
References
[1] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] R. Hinden and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[3] D. Johnson, C. Perkins, and J. Arkko, "Mobility Support in
IPv6," draft-ietf-mobileip-ipv6-24 (work in progress),
June 2003.
[4] J. Faizan, H. El-Rewini, and M. Khalil, "Problem Statement:
Home Agent Reliability", draft-jfaizan-mip6-ha-reliability-01
(work in progress), February 2004.
[5] J. Faizan, H. El-Rewini, and M. Khalil, "Virtual Home Agent
Reliability Protocol", draft-jfaizan-mipv6-vhar-01 (work in
progress), February 2004.
[6] R. Hinden, "Virtual Router Redundancy Protocol",
draft-ietf-vrrp-spec-v2-10 (work in progress), February 2004.
[7] R. Wakikawa, V. Devarapalli, and P. Thubert, "Inter Home Agents
Protocol", draft-wakikawa-mip6-nemo-haha-01 (work in progress),
February 2004.
[8] T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.
[9] J. Arkko, V. Devarapalli, and F. Dupont, "Using IPsec to Protect
Mobile IPv6 Signaling between Mobile Nodes and Home Agents",
draft-ietf-mobileip-mipv6-ha-ipsec-06 (work in progress),
June 2003.
[10] D. Maughan, M. Schertler, M. Schneider, and J. Turner,
"Internet Security Association and Key Management Protocol
(ISAKMP)", RFC 2408, November 1998.
[11] A. Conta and S. Deering, "Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification", RFC 2463, December 1998.
Deng, Zhang, Huang, Zhang Expires: October 2004 [Page 13]
INTERNET-DRAFT draft-deng-mip6-ha-loadbalance-01.txt April 2004
Authors' Addresses
Hui Deng
Research & Development Center
Hitachi (China), Investment Ltd.
Beijing Fortune Bldg. 1701, 5 Dong San Huan Bei-Lu
Chao Yang District, Beijing 100004, China
E-mail: hdeng@hitachi.cn
Rong Zhang
Network Technology Research Division
Guangzhou Research and Development Center
China Telecom
Guangzhou, 510630, China
Email: zhangr@gsta.com
Xiaolong Huang
Department of Electrical Engineering
Engineering IV Building
University of California at Los Angeles
Los Angeles, CA 90023, USA
Email: todhuang@ee.ucla.edu
Kai Zhang
Network Theory Laboratory.
Department of Electronic Engineering
Tsinghua University
Beijing 100084, China
Email: zhangkai98@mails.tsinghua.edu.cn
Appendix A. Changes from Previous Version of the Draft
This appendix briefly lists some of the major changes in this draft
relative to the previous version of this same draft,
draft-deng-mip6-ha-loadbalance-00.txt:
o A home agnet list has been extended to replace traffic load table.
o A new flag has been added to support load balance information
in Router Advertisement Message.
IPR Notices
The IETF takes no position regarding the validity or scope of
any intellectual property 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; neither does
Deng, Zhang, Huang, Zhang Expires: October 2004 [Page 14]
INTERNET-DRAFT draft-deng-mip6-ha-loadbalance-01.txt April 2004
it represent that it has made any effort to identify any such
rights. Information on the IETF's procedures with respect to
rights in standards-track and standards-related documentation
can be found in BCP-11. Copies of claims of rights made
available for publication 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 implementors or users of this
specification can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its
attention any copyrights, patents or patent applications, or
other proprietary rights which may cover technology that may be
required to practice this standard. Please address the
information to the IETF Executive Director.
Copyright Notice
Copyright (C) The Internet Society (date). All Rights
Reserved.
This document and translations of it may be copied and
furnished to others, and derivative works that comment on or
otherwise explain it or assist in its implementation may be
prepared, copied, published and distributed, in whole or in
part, without restriction of any kind, provided that the above
copyright notice and this paragraph are included on all such
copies and derivative works. However, this document itself may
not be modified in any way, such as by removing the copyright
notice or references to the Internet Society or other Internet
organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or
as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will
not be revoked by the Internet Society or its successors or
assigns.
This document and the information contained herein is provided
on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS 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."
Deng, Zhang, Huang, Zhang Expires: October 2004 [Page 15]
| PAFTECH AB 2003-2026 | 2026-04-23 11:27:22 |