Internet DRAFT - draft-cui-mobopts-hcf-wlan
draft-cui-mobopts-hcf-wlan
MOBOPTS Y. Cui
Internet-Draft K. Xu
Expires: January 12, 2006 J. Wu
CERNET
H. Deng
Hitachi
July 11, 2005
Handover Control Function Based Handover for Mobile IPv6
draft-cui-mobopts-hcf-wlan-00.txt
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 12, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document propose a scheme to support MIP6 deployment based on
Wireless LAN by extending HMIPv6. The HCF (Handover Control
Function) described in this document should record all APs's MAC
address, backend AR's address and network prefix of those APs. All
MNs will periodically report all AP's MAC address and signal strength
Cui, et al. Expires January 12, 2006 [Page 1]
Internet-Draft HCF Based Handover for MIPv6 July 2005
information to HCF which MN can probe, then HCF should decide whether
or which AP MN shall associate with and notify MN about the new AP/
AR's information, meanwhile, a bi-cast mechanism shall be applied to
further improve handover performance by reducing the packet loss
during handover. This mechanism can be used in the nationwide
university Wireless LAN based MIP6 network deployment to support VoIP
and Video Telephony.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Deployment Scenario of HCF Based Handover . . . . . . . . . . 5
4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 7
4.1 Mobile Node Operation . . . . . . . . . . . . . . . . . . 8
4.2 Handover Control Function Operation . . . . . . . . . . . 8
4.3 Home Agent Operation . . . . . . . . . . . . . . . . . . . 8
4.4 Access Router Operation . . . . . . . . . . . . . . . . . 9
4.5 Correspondent Node Operation . . . . . . . . . . . . . . . 9
5. Mobile IPv6 Extension . . . . . . . . . . . . . . . . . . . . 10
5.1 HCFReq message . . . . . . . . . . . . . . . . . . . . . . 10
5.1.1 AP info options . . . . . . . . . . . . . . . . . . . 11
5.2 HCFRep message . . . . . . . . . . . . . . . . . . . . . . 11
5.2.1 Acess Router information option . . . . . . . . . . . 13
6. HCF Bicast Traffic . . . . . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1 Normative References . . . . . . . . . . . . . . . . . . . 18
9.2 Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . 20
Cui, et al. Expires January 12, 2006 [Page 2]
Internet-Draft HCF Based Handover for MIPv6 July 2005
1. Introduction
There are many proposals trying to give the solution for Mobile IPv6
deployment for Wireless LAN network. Especially there are some
nationwide Wireless LAN network for the universities and research
institutes, they would like to deploy VoIP and Video Telephone based
on Mobile IPv6. One important issue is that they can not modify
current Access Routers to support Fast handover even just small part
of Access Routers. In order to considering VoIP and Video Telephone,
the performance of fast handover have to be achieved.
This document propose a scheme to support MIP6 deployment based on
Wireless LAN by extending HMIPv6. The HCF (Handover Control
Function) described in this document should record all APs's MAC
address, backend AR's address and network prefix of those APs. All
MNs will periodically report all AP's MAC address and signal strength
information to HCF which MN can probe, then HCF should decide whether
or which AP MN shall associate with and notify MN about the new AP/
AR's information, meanwhile, a bi-cast mechanism shall be applied to
further improve handover performance by reducing the packet loss
during handover.
Before MN handover the new AP/AR, HCF shall notify MN about the new
AP/AR's information such as AP's MAC address, AR interface address,
and network prefix. Then, MN will configure its new CoA before
moving to the new AP. After handover, Layer 2 trigger may be used to
support the handover. This protocol defines two mobility options to
support communication between MN and HCF.
Since HCF decide which AR's interface MN will move to, so the new
network prefix of MN will be notified by HCF through HCFRep message.
If MN's address is computed using interface indentifier, like EUI64,
Duplicated Address Detection can be omitted during handover.
Furthermore, recent study reveals that DAD is not _applicable_ to
Wireless LAN environment. Therefore, In this protocol, HCF will know
MN's new CoA according to MN's old CoA and MN's new network prefix.
Under this situation, a bi-casting mechanism can also be applied to
further improve handover performance. HCF will act as a extention of
MAP in HMIPv6 which shall begin to bi-cast to both MN's old CoA and
new CoA after sending HCFRep to MN in order to reduce packet loss
during handover.
This protocol can be used in the nationwide university Wireless LAN
based MIP6 network deployment to support VoIP and Video Telephony.
Cui, et al. Expires January 12, 2006 [Page 3]
Internet-Draft HCF Based Handover for MIPv6 July 2005
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].
In addition, new terms are defined below::
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.
Handover Control Function (HCF)
A extension of MAP in HMIPv6 which should record all APs's MAC
address, backend AR's address and network prefix of those APs.
HCF should decide whether or which AP MN shall associate with and
notify MN about the new AP/AR's information. Meanwhile, HCF shall
split a bi-cast stream to both MN's new CoA and old CoA.
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.
Access Point (AP)
A Layer 2 device connected to an IP subnet that offers wireless
connectivity to a MN. An Access Point Identifier (AP-ID) refers
the AP's L2 address. Sometimes, AP-ID is also referred to as a
Base Station Subsystem ID (BSSID).
Access Router (AR)
The MN's default router
Handover
A process of terminating existing connectivity and obtaining new
IP connectivity.
Bicasting
The splitting of a stream of packets destined for a MN via its
current HCF(the MAP) into two streams, and the simultaneous
transmission of thestreams to old CoA and new CoA.
Cui, et al. Expires January 12, 2006 [Page 4]
Internet-Draft HCF Based Handover for MIPv6 July 2005
3. Deployment Scenario of HCF Based Handover
The following Figure gives the topology layout about how to deploy
this protocol (HCF Based handover for Mobile IPv6) for nationwide
Mobile IPv6 network deployment based on Wireless LAN.
|------------------------------| |----------
| | | |
|---| |---| |---| |---|
|HA | |HA | |HA | |CN |
|---| |---| |---| |---|
|-------------------------------------------------------|
| |
| Internet |
| |
|-------------------------------------------------------|
| |
|----| |----|
|HCF1| |HCF2|
|----| |----|
/ \ / \
/ \ / \
/ \ / \
/ \ / \
|---| |---| |---| |---|
|AR1| |AR2| |AR3| |AR4|
|---| |---| |---| |---|
/\ | /\ |
/ \ | / \ |
/ \ | / \ |
| | | | | |
|---| |---| |---| |---| |---| |---|
|AP1| |AP2| |AP3| |AP4| |AP5| |AP6|
|---| |---| |---| |---| |---| |---|
/ \
/ \
/ \
/\ /\
/MN\ ------------> /MN\
/----\ /----\
Figure 1: Network Scenario of HCF based handover
In this network scenario, there might one AR will connect to multiple
APs, those APs might have same network prefix or different network
prefix.
Cui, et al. Expires January 12, 2006 [Page 5]
Internet-Draft HCF Based Handover for MIPv6 July 2005
When MN move from AP2 to AP3, the attached Access Router also change
from AR1 to AR2 as well. HCF will has administrative network domain,
which can cover many ARs and APs.
There are some network deployment scenarios such as University.
There are might have one or multiple HCF in one university. If there
are more than one HCF in each university, the inter-connection
between different HCF will be out of the scope of this document.
Cui, et al. Expires January 12, 2006 [Page 6]
Internet-Draft HCF Based Handover for MIPv6 July 2005
4. Protocol Operation
MN HCF HA
| | |
|------------------- BU ------------------>|
| | |
|<------------------ BA -------------------|
| | |
|------HCFReq-------->| |
| | |
|<-----HCFRep---------| |
| | |
Config New CoA | |
....Handover | |
Layer 2 trigger | |
| | |
|------- BU --------->| |
|<------ BA ----------| |
| |------- BU -------->|
| |<------ BA ---------|
|<====================== deliver packets
| |
Figure 2: Protocol for HCF based handover
1. When MN register to HA first time, it will send Bingding Update
message to HA, and HA will response with Binding Acknowledgement.
2. After MN probes all Neighbor AP's information, and MinWlanTime is
up, MN shall send HCFReq message directly to HCF to report the
information of its neighbor AP.
3. After HCF receive the MAPReq message, it will decide whether or
which AR/AP MN shall associate with.
4. Detail algorithm for HCF judgement of MN handover mostly is based
on the signal strenth MN received from neighbor APs and HCF's
network administraing policy.
5. HCF judge MN in some sense which also can help load balance among
different ARs and APs, if the number of registered MNs in one AR
or AP have over more than the threshold, HCF will not approve MN
move to that network.
6. After HCF make decision which AR/AP MN will move to, HCF will
notify MN about new AR/AP's information such as link prefix and
Cui, et al. Expires January 12, 2006 [Page 7]
Internet-Draft HCF Based Handover for MIPv6 July 2005
AR's address. Those information will help MN make a new CoA
before it handover. This address also has been known by HCF
since new CoA is made based on EUI-64.
7. After MN receive the HCFReq message, it knows which AR/AP it will
associate with and will configure its new CoA based on HCFReq
message information about new AP/AR.
8. When MN moves from AP2 to AP3, the attached Access Router also
change from AR1 to AR2. MN will intensively deassociate with AP2
and associate with AP3.
9. HCF works as an extension of MAP, and will send bicast traffic
from HCF to both MN's old CoA and new CoA. Once MN attach AP3/
AR2, those traffic will go directly to MN's new CoA. After
receving the new binding update from new CoA, HCF will remove
traffic going to old coA.
4.1 Mobile Node Operation
Mobile Node will periodically report all neighbor's AP information to
HCF by using HCFReq message, and modify its configuration based on
informaiton transferred by HCFRep message. And also Mobile Node
shall support layer 2 trigger and optimized DAD to support fast
handover.
4.2 Handover Control Function Operation
HCF should collect all AP's MAC address, and AR's address and network
prefix et al. It can be done by network administrators manualy or
other solution which is out the scope of this protocol. HCF create a
database inside or using LDAP to record those information in other
network entities.
HCF will decide whether which AP/AR MN will associate with, and will
notify the related information of next AR/AP to MN.
HCF will be responsible for authenticate and authorize the MN in
order to reduce signal burdern in the access network,
The HCF acts as a extension of MAP in hierarchical Mobile IPv6, it
will bicast the traffic from CN to both old CoA and new CoA.
4.3 Home Agent Operation
Home agent will work as Mobile IPv6 specificaiton, it will also
accept the registration from HCF as a extension of MAP in HMIPv6.
Cui, et al. Expires January 12, 2006 [Page 8]
Internet-Draft HCF Based Handover for MIPv6 July 2005
4.4 Access Router Operation
There are no specific security association requirement between MN and
AR, which shall save signal overhead in the access network side.
Meanwhile there exist some scenario, for example, in the university
network, access routers are not expected to do any authentication.
4.5 Correspondent Node Operation
Correspondent Node will work as Mobile IPv6 specification.
Cui, et al. Expires January 12, 2006 [Page 9]
Internet-Draft HCF Based Handover for MIPv6 July 2005
5. Mobile IPv6 Extension
MN will probe its neighor all AP's information and send these
information to HCF using HCFReq message. HCF will select an AP based
on those information together with AR's information, and respond a
HCFRep message including the MAC address of suggested AP along with
some backend AR's information in that link, like network prefix and
router address.
HCF is an indenpendent entity as MAP in HMIPv6. Messages between HCF
and MN are introduced above as HCFReq and HCFRep. These two messages
are implemented here as an extension to Mobile IPv6, the format of
two new Mobility Messagesare defined as following:
5.1 HCFReq message
The HCF Request message uses the MH Type value MH_HCFREQ_TYPE. When
this value is indicated in the MH Type field, the format of the
Message Data field in the Mobility Header is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AP info 1 |
. .
| AP info 2 |
. .
. .
. .
| AP info n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
These fields are unused. They MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
Sequence #
A 16-bit unsigned integer used by the receiving node to sequence
the HCFReq message and also by the sending node to match a
returned HCFRep message with the HCFReq. An outdated HCFRep may
be helpless for Mobile Node, and SHOULD be ignored by the Mobile
Node which sent out the HCFReq message.
Cui, et al. Expires January 12, 2006 [Page 10]
Internet-Draft HCF Based Handover for MIPv6 July 2005
Number
A 8-bit unsigned integer to indicate the number of AP info that
are attached below in this message. This field MUST be equal to
the actual number of AP info in message, otherwise HCF MUST ignore
this HCFReq message. The value of this field MUST be at least 1,
or more than one.
AP info
A HCFReq message could contain more than one AP info options.
Detailed description of one AP info option is defined in next
subsection:
5.1.1 AP info options
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD | Strength | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TBD
TBD, consider reserved
Strength
The field is current signal strength received by Mobile Node from
this AP. This is a 8-bits unsigned integer which can represent
strength level from 0 to 255. Any special computation scheme MAY
be used as long as all AP are treated equally. Selection of a
particular computation scheme is out of scope of this draft.
MAC Address
This field is the 48-bits MAC address of the AP. Which is the
unique identification of AP known by Mobile Node.
5.2 HCFRep message
The HCF Reply message uses the MH Type value MH_HCFREP_TYPE. When
this value is indicated in the MH Type field, the format of the
Message Data field in the Mobility Header is as follows:
Cui, et al. Expires January 12, 2006 [Page 11]
Internet-Draft HCF Based Handover for MIPv6 July 2005
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Status | Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AR info 1 |
. .
| AR info 2 |
. .
. .
. .
| AR info n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
These fields are unused. They MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
Sequence #
A 16-bit unsigned integer. The Sequence Number in the HCFRep is
copied from the Sequence Number field in the HCFReq. It is used
by the Mobile Node in matching this HCFRep with an outstanding
HCFReq message.
Status
8-bit unsigned integer indicating the disposition of the HCFReq
message. The following Status values are currently defined:
Number
A 8-bit unsigned integer to indicate the number of Access Router
info that are attached below in this message. This field MUST be
equal to the actual number of AR info in message, otherwise HCF
MUST ignore this HCFReq message. The value of this field MUST be
at least 1, or more than one.
AR info
A HCFRep message could contain more than one Acess Router info
options. Detailed description of one AP info option is define in
next subsection:
Cui, et al. Expires January 12, 2006 [Page 12]
Internet-Draft HCF Based Handover for MIPv6 July 2005
5.2.1 Acess Router information option
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Preference | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MAC Address
This field is the 48-bits MAC address of the AP that HCF
suggested.
Preference
This field is a 8-bits unsigned integer indicating the preference
level of AP suggested by HCF.
Prefix Length
A 8-bits unsigned integer. The value of this field MUST NOT be
more than 128, therefore the first bit of this field MUST be 0.
This is prefix lenth of access router on the same link with the
suggested AP.
Prefix
A 128-bits IPv6 address prefix of the access router on the same
link with the suggested AP.
Cui, et al. Expires January 12, 2006 [Page 13]
Internet-Draft HCF Based Handover for MIPv6 July 2005
Address
A 128-bits IPv6 address of the access router on the same link with
the suggested AP.
Cui, et al. Expires January 12, 2006 [Page 14]
Internet-Draft HCF Based Handover for MIPv6 July 2005
6. HCF Bicast Traffic
Here HCF work as a extension of MAP in HMIPv6. After HCF send out
HCFRep message, it will trigger MAP to Bi-cast traffic for the MN for
a short period to its current location and to new location where HCF
suggest MN moving to shortly.
HCF Bicasting traffic also removes the timing ambiguity regarding
when to start sending traffic for the MN to its new point of
attachment followng a Fast Handover. It also saves the MN periods of
service disruption in the case of ping-pong movement.
Here we refer to the Bi-cast/N-cast draft [7] lifetime mechanism, the
HCF MUST create a new binding cache sub-entry (linked to the original
entry for the old CoA) for the MN's new CoA. This sub-entry contains
the same fields as normal binding cache entries but it MUST not
replace any existing entries for the MN. The new sub-entry will have
two lifetimes instead of one: the normal new CoA BU lifetime (sent in
the BA) and a Bicasting lifetime set to SHORT_BINDING_LIFETIME (sent
in the BA sub-option). The new CoA lifetime runs in parallel with
the Bicasting lifetime. Until the Bicasting lifetime expires, the
HCF MUST send a copy of the data destined for the MN to the old CoA
and to the new CoA in the linked binding cache sub-entry or sub-
entries. When the Bicasting lifetime expires, the HCF MUST remove
the bicasting lifetime field and replace the old binding cache entry
for the old CoA with the new CoA sub-entry. As a result, the HCF
will end up with one entry for the MN's new CoA with the remaining
new CoA lifetime.
The default value for SHORT_BINDING_LIFETIME is 2s. This parameter
MUST be configurable as it my vary depending on the type of radio
link in the system.
After HCF received BU from new CoA, old CoA binding is deleted, and
new CoA binding kept alive after that
There are also two issues similar to [7]: 1. Multiple copies of
packets received at AR. 2. Reception of multiple copies in the MN.
In this version, Multiple-Casting has not yet been considered. It
will be analysized in the future.
Cui, et al. Expires January 12, 2006 [Page 15]
Internet-Draft HCF Based Handover for MIPv6 July 2005
7. IANA Considerations
This document updates the IANA Registry for Mobile IPv6 Mobility
Header Types.
A new MH type MH_HCFREQ_TYPE is define in section 5.1 of this
document to identify new HCFReq message in Mobile IPv6 protocol.
A new MH type MH_HCFREP_TYPE is define in section 5.2 of this
document to identify new HCFRep message in Mobile IPv6 protocol.
Cui, et al. Expires January 12, 2006 [Page 16]
Internet-Draft HCF Based Handover for MIPv6 July 2005
8. Security Considerations
HCF does not introduce any more security problems than Mobile IPv6
and Hierarchical Mobile IPv6. Same IPSec protection used in Mobile
IPv6 signals MUST be used to protect two new messages, HCFReq,
HCFRep, in this solution.
All messages between MN and HCF MUST be authenticated. This means
that the mobile host has to share an authentication key (private or
public) with all HCFs it may visit. These keys can be pre-installed
manually or obtained dynamically via IKE or AAA servers.
Since HCF is an extension to Mobile Anchor Point in HMIPv6. These
authentication key SHOULD be the key between MN and MAP as specified
in HMIPv6.
Cui, et al. Expires January 12, 2006 [Page 17]
Internet-Draft HCF Based Handover for MIPv6 July 2005
9. References
9.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
9.2 Informative References
[4] McCann, P., "Mobile IPv6 Fast Handovers for 802.11 Networks",
draft-ietf-mipshop-80211fh-04 (work in progress), April 2005.
[5] Koodli, R., "Fast Handovers for Mobile IPv6",
draft-ietf-mipshop-fast-mipv6-03 (work in progress),
October 2004.
[6] Soliman, H., Castelluccia, C., Malki, K., and L. Bellier,
"Hierarchical Mobile IPv6 mobility management (HMIPv6)",
draft-ietf-mipshop-hmipv6-04 (work in progress), December 2004.
[7] Malki, K. and H. Soliman, "Simultaneous Bindings for Mobile IPv6
Fast Handovers", draft-elmalki-mobileip-bicasting-v6-05 (work in
progress), November 2003.
[8] Jung, H., "Fast Handover for Hierarchical MIPv6 (F-HMIPv6)",
draft-jung-mobopts-fhmipv6-00 (work in progress), April 2005.
[9] Kempf, J., "Problem Statement for IP Local Mobility",
draft-kempf-netlmm-nohost-ps-00 (work in progress), June 2005.
Authors' Addresses
Yong Cui
CERNET
Department of Computer Science and Technology
Tsinghua University
Beijing 100084
China
Email: yong@csnet1.cs.tsinghua.edu.cn
Cui, et al. Expires January 12, 2006 [Page 18]
Internet-Draft HCF Based Handover for MIPv6 July 2005
Ke Xu
CERNET
Department of Computer Science and Technology
Tsinghua University
Beijing 100084
China
Email: xuke@csnet1.cs.tsinghua.edu.cn
Jianping Wu
CERNET
Department of Computer Science and Technology
Tsinghua University
Beijing 100084
China
Email: jianping@cernet.edu.cn
Hui Deng
Hitachi
Beijing Fortune Bldg. 1701
5 Dong San Huan Bei-Lu
Chao Yang District
Beijing 100004
China
Email: hdeng@hitachi.cn
Cui, et al. Expires January 12, 2006 [Page 19]
Internet-Draft HCF Based Handover for MIPv6 July 2005
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
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.
Cui, et al. Expires January 12, 2006 [Page 20]
