IRTF MobOpts RG K. Mitani
Internet-Draft R. Shibui
Expires: August 22, 2005 K. Gogo
F. Teraoka
KEIO University
February 21, 2005
Unified L2 Abstractions for L3-Driven Fast Handover
draft-koki-mobopts-l2-abstractions-02.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
RFC 3668.
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 August 22, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This draft proposes unified L2 abstractions for L3-driven fast
handover. For efficient network communication, it is vital for a
protocol layer to know or utilize other layer's information such as
L2 triggers. However, in current operating systems, each protocol
layer is designed independently and information exchange between
Mitani, et al. Expires August 22, 2005 [Page 1]
Internet-Draft L2 Abstractions February 2005
protocol layers is not allowed. To solve the problem, this draft
defines nine kinds of L2 abstractions in the form of "Primitive".
This concept can be applied to L3-driven fast handover mechanism
using "Primitives".
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Primitives for L2 Abstractions . . . . . . . . . . . . . . . . 6
4. Definitions of Primitives . . . . . . . . . . . . . . . . . . 7
4.1 L2-LinkStatus (Type 1) . . . . . . . . . . . . . . . . . . 7
4.2 L2-PeerList (Type 1) . . . . . . . . . . . . . . . . . . . 7
4.3 L2-PeerFound (Type 2) . . . . . . . . . . . . . . . . . . 7
4.4 L2-PeerLost (Type 2) . . . . . . . . . . . . . . . . . . . 7
4.5 L2-LinkUp (Type 2) . . . . . . . . . . . . . . . . . . . . 8
4.6 L2-LinkDown (Type 2) . . . . . . . . . . . . . . . . . . . 8
4.7 L2-LinkToBeDown (Type 2) . . . . . . . . . . . . . . . . . 8
4.8 L2-LinkConnect (Type 3) . . . . . . . . . . . . . . . . . 8
4.9 L2-LinkDisconnect (Type 3) . . . . . . . . . . . . . . . . 8
5. Definitions of Static Parameters . . . . . . . . . . . . . . . 9
5.1 Network Interface ID . . . . . . . . . . . . . . . . . . . 9
6. Definitions of Dynamic Parameters . . . . . . . . . . . . . . 10
6.1 Peer . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.2 Condition . . . . . . . . . . . . . . . . . . . . . . . . 10
6.3 Peer List . . . . . . . . . . . . . . . . . . . . . . . . 10
6.4 Enable/Disable . . . . . . . . . . . . . . . . . . . . . . 10
6.5 Ack/Error . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11
A. Example Scenario . . . . . . . . . . . . . . . . . . . . . . . 13
B. Example Operation for FMIPv6 . . . . . . . . . . . . . . . . . 15
C. Example Mapping of Primitives and IEEE802.11 . . . . . . . . . 17
C.1 L2-LinkStatus . . . . . . . . . . . . . . . . . . . . . . 17
C.2 L2-PeerList . . . . . . . . . . . . . . . . . . . . . . . 17
C.3 L2-PeerFound . . . . . . . . . . . . . . . . . . . . . . . 17
Mitani, et al. Expires August 22, 2005 [Page 2]
Internet-Draft L2 Abstractions February 2005
C.4 L2-PeerLost . . . . . . . . . . . . . . . . . . . . . . . 17
C.5 L2-LinkUp . . . . . . . . . . . . . . . . . . . . . . . . 18
C.6 L2-LinkDown . . . . . . . . . . . . . . . . . . . . . . . 18
C.7 L2-LinkToBeDown . . . . . . . . . . . . . . . . . . . . . 18
C.8 L2-LinkConnect . . . . . . . . . . . . . . . . . . . . . . 18
C.9 L2-LinkDisconnect . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . 19
Mitani, et al. Expires August 22, 2005 [Page 3]
Internet-Draft L2 Abstractions February 2005
1. Introduction
In recent years, the environment around computers is not static and
changes dynamically. Especially, when a mobile node moves to a
different network, its environment considerably changes. For
example, in the case of wireless communication, parameters such as
radio strength changes widely depends on time or site.
For efficient network communication, it is vital for a protocol layer
to know or utilize other layer's information. There are several
proposals for seamless handovers in IPv6 network such as Fast
Handovers for Mobile IPv6 (FMIPv6) [1] and Hierarchical Mobile IPv6
(HMIPv6) [2]. In FMIPv6, the network layer must know the indication
of a handover from the link layer in advance to achieve seamless
handovers. However, each protocol layer is designed independently
and information exchange between protocol layers is not allowed.
For further handover enhancements, this document defines nine kinds
of L2 triggers in the form of "Primitive". This concept can be
applied to L3-driven fast handover mechanism using "Primitives".
Mitani, et al. Expires August 22, 2005 [Page 4]
Internet-Draft L2 Abstractions February 2005
2. Terminology
This document uses the following terms.
L3-Driven Fast Handover
The handover which is initiated by the network layer on a mobile
node. Since it allows L3 handover preparation during
communication, it can reduce packet loss during handover.
L3-driven fast handover mechanism requires L2 information as a
trigger of handover procedure.
Peer
The attachment point of a mobile node. (e.g., An access point in
IEEE 802.11 networks.)
Primitive
A unit of information which is sent from one layer to another.
There are four classes of primitives: Request, Confirm, Indication
and Response.
Mitani, et al. Expires August 22, 2005 [Page 5]
Internet-Draft L2 Abstractions February 2005
3. Primitives for L2 Abstractions
Each layer offers its services by the form of primitives. There are
four classes of primitives as shown in Figure 1: Request, Confirm,
Indication, and Response. The request is issued by the layer that
wants to get services or information from another layer, and the
confirm is the acknowledgment of the request. The indication is a
notification of information to the layer that requested the service,
and the response is the acknowledgment of the indication. In this
architecture, each layer can communicate evenly.
------------------------------------------------------
Request Response
|| /\ /\ ||
Layer N || || || ||
------------||------||----------||------||------------
|| || || ||
\/ || || \/
Layer N-m Confirm Indication
------------------------------------------------------
Figure 1: Primitives
The primitive consists of five fields: the protocol layer id to which
this primitive should be sent, the protocol id to which protocol
entity this primitive should be sent, the primitive class (i.e.,
request, confirm, indication, or response), the primitive name, and
parameters.
There are three different usages of "Primitives":
Type 1. To provide L2 information to upper layers immediately
A "Request" primitive is an acquisition request for L2
informaiton. As a "Confirm" primitive, L2 information
returns immediately.
Type 2. To notify upper layers of L2 events asynchronously
"Request" and "Confirm" primitives are used just for
registration. When an event occurs, an "Indication"
primitive is asynchronously delivered to an upper layer.
Type 3. To control L2 actions from upper layers
Mitani, et al. Expires August 22, 2005 [Page 6]
Internet-Draft L2 Abstractions February 2005
A "Request" primitive is a request for operation. Ack or
nack returns immediately as a "Confirm" primitive.
Mitani, et al. Expires August 22, 2005 [Page 7]
Internet-Draft L2 Abstractions February 2005
4. Definitions of Primitives
In order to obtain and change L2 information, some sorts of
Primitives described below are necessary. The following Primitives
are defined.
4.1 L2-LinkStatus (Type 1)
The L2-LinkStatus.request is sent to the link layer when an upper
layer needs the current information of a link. The
L2-LinkStatus.request primitive contains "Network Interface ID"
parameter. In response, the L2-LinkStatus.confirm returns. The
L2-LinkStatus.confirm primitive contains three parameters: "Network
Interface ID", "Peer" and "Condition". "Peer" and "Condition"
indicate the current status about the link between a mobile node and
a peer.
4.2 L2-PeerList (Type 1)
The L2-PeerList.request is sent to the link layer when an upper layer
needs a list of candidate peers. The L2-PeerList.request primitive
contains "Network Interface ID" parameter. In response, the
L2-PeerList.confirm returns with "Network Interface ID" parameter and
"Peer List" parameter. "Peer List" parameter is the list of
candidate peers.
4.3 L2-PeerFound (Type 2)
The L2-PeerFound.indication is asynchronously provided to an upper
layer when new peers are detected. This primitive carries "Network
Interface ID" parameter and "Peer List" parameter. "Peer List"
parameter contains the information of new peers detected by a mobile
node. In order to use this notification, the registration process
using L2-PeerFound.request and L2-PeerFound.confirm is needed in
advance. The L2-PeerFound.request primitive has two parameters:
"Network Interface ID" and "Enable/Disable". "Enable/Disable"
parameter shows whether this notification function is turned on.
When this registration succeeds, the L2-PeerFound.confirm returns
with "Network Interface ID" parameter and "Ack" parameter in
response.
4.4 L2-PeerLost (Type 2)
The L2-PeerLost.indication is asynchronously provided to an upper
layer when a peer included in the list of candidate peers is got
lost. This primitive carries "Network Interface ID" parameter and
"Peer List" parameter. "Peer List" parameter contains the
information of the peers which disappeared from the candidates list.
Mitani, et al. Expires August 22, 2005 [Page 8]
Internet-Draft L2 Abstractions February 2005
The registration process using the L2-PeerLost.request and the
L2-PeerLost.confirm is similar to the L2-PeerFound above.
4.5 L2-LinkUp (Type 2)
The L2-LinkUp.indication is asynchronously provided to an upper layer
when a new link is connected. This primitive carries "Network
Interface ID" parameter and "Peer" parameter. The L2-LinkUp.request
contains "Network Interface ID" parameter and "Enable/Disable"
parameter for registration. When the registration succeeds, the
L2-LinkUp.confirm with "Network Interface ID" parameter and "Ack"
parameter returns.
4.6 L2-LinkDown (Type 2)
The L2-LinkDown.indication is asynchronously provided to an upper
layer when an existing link is disconnected. The registration
processing is same as the L2-LinkUp above.
4.7 L2-LinkToBeDown (Type 2)
The L2-LinkToBeDown.indication is asynchronously provided to an upper
layer when an existing link is to be disconnected. This notification
contains two parameters: "Network Interface ID" and "Peer". "Peer"
parameter is the attachment point at which the link quality is
degrading. In the registration processing, the
L2-LinkToBeDown.request carries "Network Interface ID" parameter and
"Enable/Disable" parameter.
4.8 L2-LinkConnect (Type 3)
The L2-LinkConnect.request is sent to the link layer when an upper
layer has to change or create a new link to the specific "Peer".
This primitive carries "Network Interface ID" parameter and "Peer"
parameter. This operation begins after sending
L2-LinkConnect.confirm with "Ack" by the link layer.
4.9 L2-LinkDisconnect (Type 3)
The L2-LinkDisconnect.request is sent to the link layer when an upper
layer has to destroy an existing link to the specific "Peer". This
primitive carries "Network Interface ID" parameter and "Peer"
parameter. This operation begins after sending
L2-LinkConnect.confirm with "Ack" by the link layer.
Mitani, et al. Expires August 22, 2005 [Page 9]
Internet-Draft L2 Abstractions February 2005
5. Definitions of Static Parameters
This section lists static parameters. Once the values of static
parameters are configured, they do not change frequently during
communication. The following parameters are transferred as a part of
primitives.
5.1 Network Interface ID
"Network interface ID" parameter identifies uniquely the network
interface in a node. The identifier is an implementation-specific
consideration (e.g., name, index or unique address assigned to each
interface). This parameter also contains the network interface type
which indicates the kind of technology of the network interface
(e.g., IEEE802.11a/b/g, 3GPP, etc.). This parameter is required for
all the primitives.
Mitani, et al. Expires August 22, 2005 [Page 10]
Internet-Draft L2 Abstractions February 2005
6. Definitions of Dynamic Parameters
This section lists dynamic parameters. The values of dynamic
parameters change frequently during communication. The following
parameters are transferred as a part of primitives.
6.1 Peer
"Peer" parameter uniquely identifies the peer.
6.2 Condition
"Condition" parameter consists of the following sub-parameters:
available bandwidth and link quality level. These sub-parameters are
the abstracted information for considering current quality-of
service. The abstraction algorithms of sub-parameters depend on
hardware device and software implementation. The useful range of
link quality level is from one to five; VERY GOOD, GOOD, FAIR, BAD,
VERY BAD. Each GOOD and BAD level is calcurated as a high or low
watermark.
6.3 Peer List
"Peer List" parameter consists of arbitrary couples of two
sub-parameters: "Peer" and "Condition". This parameter shows a list
of peers and its condition.
6.4 Enable/Disable
"Enable/Disable" flag is used for turning event notification on/off.
When an upper layer needs notifications, the "Request" primitive with
"Enable" is sent to the link layer as registration. When an upper
layer needs no more notifications, the "Request" primitive with
"Disable" is sent.
6.5 Ack/Error
When an upper layer requests some notifications, the link layer
receives and confirms this "Request". If the "Request" is valid, the
"Confirm" primitive with "Ack" is sent. And if it is invalid, the
"Confirm" with "Error" is sent to the upper layer.
Mitani, et al. Expires August 22, 2005 [Page 11]
Internet-Draft L2 Abstractions February 2005
7. Security Considerations
It is recommended that the implementers consider the security
features to manage the L2 information.
8 References
[1] Koodli, R., Dommety, G., Malki, K., Khalil, M., Perkins, C.,
Soliman, H., Tsirtsis, G. and A. Yegin, "Fast Handovers for
Mobile IPv6", draft-ietf-mipshop-fast-mipv6-03 (work in
progress), October 2004.
[2] Soliman, H., Castelluccia, C., Malki, K. and L. Bellier,
"Hierarchical Mobile IPv6 mobility management (HMIPv6)",
draft-ietf-mipshop-hmipv6-02 (work in progress), June 2004.
Authors' Addresses
Koki Mitani
Graduate School of Science and Technology, KEIO University
3-14-1 Hiyoshi, Kohoku-ku
Yokohama, Kanagawa 223-8522
Japan
Phone: +81-45-566-1425
EMail: koki@tera.ics.keio.ac.jp
URI: http://www.tera.ics.keio.ac.jp/
Rie Shibui
Graduate School of Science and Technology, KEIO University
3-14-1 Hiyoshi, Kohoku-ku
Yokohama, Kanagawa 223-8522
Japan
Phone: +81-45-566-1425
EMail: shibrie@tera.ics.keio.ac.jp
URI: http://www.tera.ics.keio.ac.jp/
Mitani, et al. Expires August 22, 2005 [Page 12]
Internet-Draft L2 Abstractions February 2005
Kazutaka Gogo
Faculty of Science and Technology, KEIO University
3-14-1 Hiyoshi, Kohoku-ku
Yokohama, Kanagawa 223-8522
Japan
Phone: +81-45-566-1425
EMail: gogo@tera.ics.keio.ac.jp
URI: http://www.tera.ics.keio.ac.jp/
Fumio Teraoka
Graduate School of Science and Technology, KEIO University
3-14-1 Hiyoshi, Kohoku-ku
Yokohama, Kanagawa 223-8522
Japan
Phone: +81-45-566-1425
EMail: tera@ics.keio.ac.jp
URI: http://www.tera.ics.keio.ac.jp/
Mitani, et al. Expires August 22, 2005 [Page 13]
Internet-Draft L2 Abstractions February 2005
Appendix A. Example Scenario
For example, the picture below shows L3-driven fast handover
mechanism using the L2 triggers on MN.
L2 L3
| |
Low |
Signal-----LinkToBeDown.ind------->|
| |
| Handover
AP<---------PeerList.req------Preparation
Scan---------PeerList.cnf--------->|
| |
|<-------LinkConnect.req----L3 Handover
L2 Handover--LinkConnect.cnf-------->:
: :
: :
finish---------LinkUp.ind---------->:
| :
| finish
| |
L2: Link Layer on MN
L3: Network Layer on MN
req: Request
cnf: Confirm
ind: Indication
Figure 2: L3-Driven Fast Handover Mechanism
In the beginning of the L3-driven handover procedure, L2 detects
radio signal strength is going down. Then L2 sends
L2-LinkToBeDown.indication to L3. L3 prepares for handover (e.g.,
CoA generation, DAD, ND cache creation, and routing table setting)
and sends L2-PeerList.request to L2 if the list of access points is
needed.
If L3 decides to perform handover according to some rules, L3 sends
L2-LinkConnect.request with some parameters about candidate access
points to request L2 handover. L2 handover begins after sending
L2-LinkConnect.confirm to L3. When L2 handover finished, L2 sends
L2-LinkUp.indication to notify L3. At last, L3 performs handover
(e.g., sending BU).
One of the important features of L3-driven fast handover using
Primitives is that the L3 handover preparation can be done during
Mitani, et al. Expires August 22, 2005 [Page 14]
Internet-Draft L2 Abstractions February 2005
communication. So, it can reduce disruption time during handover.
Mitani, et al. Expires August 22, 2005 [Page 15]
Internet-Draft L2 Abstractions February 2005
Appendix B. Example Operation for FMIPv6
Figure 3 shows the predictive mode of FMIPv6 operation with L3-driven
link switching mechanism.
MN L2 MN L3 PAR L3
| | |
AP<---------PeerList.req----------| |
Scan---------PeerList.cnf--------->| |
| |---RtSolPr-->|
| |<--PrRtAdv---|
|---------PeerFound.ind--------->| |
| |---RtSolPr-->|
| |<--PrRtAdv---|
| | |
~ ~ ~
| | |
Low | |
Signal-----LinkToBeDown.ind------->| | NAR L3
| |-----FBU---->| |
| | |----HI---->|
| | |<--HAck----|
| |<----FBack---| |
|<-------LinkConnect.req---L3 Handover | |
L2 Handover--LinkConnect.cnf-------->: |
: : |
: : |
finish---------LinkUp.ind---------->: |
| :-----------FNA---------->|
| finish<======packets=========|
| | |
MN L2 : Link Layer on Mobile Node
MN L3 : Network Layer on Mobile Node
PAR L3 : Network Layer on Previous Access Router
NAR L3 : Network Layer on New Access Router
req : Request
cnf : Confirm
ind : Indication
RtSolPr : Router Solicitation for Proxy
PrRtAdv : Proxy Router Advertisement
FBU : Fast Binding Update
FBack : Fast Binding Acknowledgment
FNA : Fast Neighbor Advertisement
HI : Handover Initiate
HAck : Handover Acknowledge
Figure 3: L3-Driven Fast Handover Mechanism with FMIPv6
Mitani, et al. Expires August 22, 2005 [Page 16]
Internet-Draft L2 Abstractions February 2005
When the MN establishes link connectivity with the PAR, it performs
router discovery. Then, the MN can send RtSolPr message to the PAR
in order to resolve access point identifiers to subnet router
information. To send RtSolPr, a MN discovers one or more access
points by sending L2-PeerList.request to the link layer. As a
response to L2-PeerList.request, L2-PeerList.confirm returns with
"Peer List" parameter which contains identifiers and conditions of
nearby access points. After initial AP discovery,
L2-PeerFound.indication with "Peer List" is also sent from the link
layer when one or more access points are discovered.
When the link layer of the MN detects radio signal strength is going
down, it sends L2-LinkToBeDown.indication to the network layer.
Then, the MN sends FBU to PAR as the beginning of L3 handover
procedure. The NCoA required for FBU message is determined according
to the MN's policy database and received PrRtAdv message. As a
response to FBU, the MN receives FBack and then switches its link by
L2-LinkConnect.request with specific "Peer" parameter immediately.
The handover policy of the MN is outside the scope of this document.
After L2 handover, the link layer of the MN sends
L2-LinkUp.indication to the network layer. The MN sends FNA message
to NAR immediately. The NAR will send tunneled and buffered packets
to the MN.
Mitani, et al. Expires August 22, 2005 [Page 17]
Internet-Draft L2 Abstractions February 2005
Appendix C. Example Mapping of Primitives and IEEE802.11
This section shows examples of the mapping between "Primitives" and
IEEE802.11 parameters.
C.1 L2-LinkStatus
Most of parameters for L2-LinkStatus are related to the configuration
of network interface hardware. So, the operating system and the
device driver module can easily collect such information. However,
to create the "Condition" parameter, the MN should maintain
statistics and parameters related to current wireless environment.
There are two sub-parameters of the "Condition" parameter: available
bandwidth, link quality level. An available bandwidth of the current
peer can be obtained by maintaining transmission rate indication and
statistics of frame transmission at every time the frame transmission
occurs. A link quality level can be updated by maintaining the
following parameters and statistics at every time the frame reception
occurs: receive signal strength indication (RSSI), transmission/
reception rate indication, transmit/receive latency, bit error rate,
frame error rate and noise level. Some parameters can be managed by
setting threshold from software. When the parameters cross the
threshold, an interrupt is generated for the software.
C.2 L2-PeerList
In IEEE 802.11 networks, L2-PeerList returns all detected APs as peer
candidates (by "Peer List" parameter). Therefore, the MN should
always maintain the database of available access points according to
reception of beacon frame, probe response frame and all frames. This
AP database is managed in consideration of time, number of frames and
signal strength. There are some network interface hardwares that can
notify events to operating system only when the desired event occurs,
by setting threshold from software. Moreover, the MN can transmit
probe request frame for access point discovery, if needed.
C.3 L2-PeerFound
In IEEE 802.11 networks, L2-PeerFound is notified when new peers are
detected by listening beacons or scanning APs. If the received frame
(mainly beacon or probe response) is not in the AP database described
in Appendix C.2, then the link layer can create
L2-PeerFound.indication.
C.4 L2-PeerLost
In IEEE 802.11 networks, L2-PeerLost is notified when an AP included
Mitani, et al. Expires August 22, 2005 [Page 18]
Internet-Draft L2 Abstractions February 2005
in the list of candidate APs is got lost by listening beacons or
scanning APs. If the entry in the AP database described in Appendix
C.2 expires, or signal strength of the received frame (mainly beacon
or probe response) is under threshold, then the link layer can create
L2-PeerLost.indication.
C.5 L2-LinkUp
In IEEE 802.11 networks, L2-LinkUp is notified when association or
reassociation event occurs. When such event occurs, the MN receives
association response frame or reassociation response frame.
Immediately after receiving it, the link layer can create
L2-LinkUp.indication.
C.6 L2-LinkDown
In IEEE 802.11 networks, L2-LinkDown is notified when disassociation
event occurs. When such event occurs, the MN sends disassociation
frame to AP, or the entry of the specific AP is deleted from the AP
database described in Appendix C.2. By detecting such events, the
link layer can create L2-LinkDown.indication.
C.7 L2-LinkToBeDown
In IEEE 802.11 networks, L2-LinkToBeDown is notified when radio
signal strength of the connected AP is going down. By maintaining
parameters for a link quality level like the description in Appendix
C.1, the link layer can create L2-LinkToBeDown.indication.
C.8 L2-LinkConnect
In IEEE802.11 networks, each AP is identified by BSSID, the service
set of several APs is identified by SSID. When L2-LinkConnect is
used to connect specific AP or service set, the link layer should set
BSSID or SSID. Also, the channel should be set appropriately at the
same time by searching database described in Appendix C.2.
C.9 L2-LinkDisconnect
In IEEE802.11 networks, the MN sends disassociation message to the AP
for disconnection. When L2-LinkDisconnect is used for disconnection
from the current AP, the link layer should send disassociation
message to the appropriate AP, and stop data transmission.
Mitani, et al. Expires August 22, 2005 [Page 19]
Internet-Draft L2 Abstractions February 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.
Mitani, et al. Expires August 22, 2005 [Page 20]