Network Working Group K. Kim, Ed.
Internet-Draft Ajou University
Expires: January 18, 2006 S. Daniel Park, Ed.
SAMSUNG Electronics
G. Montenegro
Microsoft Corporation
S. Yoo
Ajou University
July 15, 2005
6LoWPAN Ad Hoc On-Demand Distance Vector Routing (LOAD)
draft-daniel-6lowpan-load-adhoc-routing-01.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 18, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
6LoWPAN Ad Hoc On-Demand Distance Vector Routing (LOAD) is intended
for use by IEEE 802.15.4 devices in a 6LoWPAN. It is a simplified
on-demand routing protocol based on AODV.
Kim, et al. Expires January 18, 2006 [Page 1]
Internet-Draft LOAD July 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 6
5.1 Routing Table Entry . . . . . . . . . . . . . . . . . . . 6
5.2 Route Request Table Entry . . . . . . . . . . . . . . . . 6
5.3 Message Format . . . . . . . . . . . . . . . . . . . . . . 7
5.3.1 Route Request (RREQ) . . . . . . . . . . . . . . . . . 7
5.3.2 Route Reply (RREP) . . . . . . . . . . . . . . . . . . 8
5.3.3 Route Error (RERR) . . . . . . . . . . . . . . . . . . 9
6. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1 Generating Route Request . . . . . . . . . . . . . . . . . 10
6.2 Processing and Forwarding Route Request . . . . . . . . . 10
6.3 Generating Route Reply . . . . . . . . . . . . . . . . . . 10
6.4 Receiving and Forwarding Route Reply . . . . . . . . . . . 10
6.5 Local Repair and RERR . . . . . . . . . . . . . . . . . . 11
7. Configuration Parameters . . . . . . . . . . . . . . . . . . . 12
8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. Acknowledgments . . .. . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1 Normative Reference . . . . . . . . . . . . . . . . . . . 12
11.2 Informative Reference . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . 15
Kim, et al. Expires January 18, 2006 [Page 2]
Internet-Draft LOAD July 2005
1. Introduction
The IEEE 802.15.4 standard [ieee802.15.4] targets low power personal
area networks. The "IPv6 over IEEE 802.15.4" document
[I-D.montenegro-lowpan-ipv6-over-802.15.4] defines basic
functionality required to carry IPv6 packets over IEEE 802.15.4
networks (including an adaptation layer, header compression, etc).
Likewise, the functionality required for packet delivery in IEEE
802.15.4 meshes is defined, as mesh topologies are expected to be
common in LoWPAN networks. However, neither the IEEE 802.15.4
standard nor the "IPv6 over IEEE 802.15.4" specification provide any
information as to how such a mesh topology could be obtained and
maintained.
The 6LoWPAN Ad hoc Routing Protocol (LOAD) is a simplified on-demand
routing protocol based on AODV[RFC3561] for 6LoWPAN. Besides the main
AODV specification [RFC3561], several efforts aim at simplifications
of the protocol, as in the AODVjr proposal [AODVjr] or the TinyAODV
implementation [TinyAODV]. Similarly, DyMO allows for minimalist
implementation leaving non-essential functionality as optional
[I-D.ietf-manet-dymo]. LOAD enables multihop routing between IEEE
802.15.4 devices to establish and maintain routing routes in 6LoWPAN.
This document defines the message formats, the data structures
and the operations of LOAD.
2. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Overview
This section describes the distinctive features of LOAD compared to
AODV. LOAD is defined to be operating on top of the adaptation layer
instead of the transport layer. That is, it creates a mesh network
topology underneath and unbeknownst to IPv6 network layer. IPv6
sees a 6LoWPAN as a single link. This is similar to how other
technologies regularly create complex structures underneath IP (e.g.,
ethernet spanning tree bridges, token ring source routing, ATM, etc).
LOAD control packets use the encapsulation defined in [I-D.montenegro
-lowpan-ipv6-over-802.15.4]. All LOAD control packets shall use the
prot_type value TBD (suggested value of 4).
LOAD assumes the use of either one of the two different addresses for
routing: the EUI-64 address and the 16 bit short address of the
6LoWPAN device.
Kim, et al. Expires January 18, 2006 [Page 3]
Internet-Draft LOAD July 2005
LOAD makes use of broadcast in its route discovery. It does so in
order to propagate the Route Request (RREQ) messages. In this
specification, such broadcast packets are obtained by setting the PAN
id to the broadcast PAN (0xffff) and by setting the destination
address to the broadcast short address (0xffff).
LOAD doesn't use the destination sequence number to reduce the size
of the control messages and simplify the route discovery process.
For ensuring loop freedom, only the destination of a route SHOULD
generate a RREP in reply. The intermediate nodes SHOULD not responds
with a RREP. By the same reason, LOAD does not use the "Gratuitous
RREP".
LOAD MAY use the local repair for a link break during a data delivery.
In a local repair, only the destination generates a RREP in reply
because of no use of the destination sequence number.
If a local repair fails, LOAD MAY generate a Route Error (RERR)
message toward the originator of the data delivery to notify that the
destination is no longer reachable by way of the broken link. The
format of RERR is simplified to include only one unreachable
destination while the RERR of AODV MAY include multiple ones.
LOAD does not use the "precursor list" of AODV to simplify the routing
table structure. Notice that AODV uses the precursors for forwarding
RERR messages in the event of detection of the loss of the next hop
link. In LOAD, RERR is forwarded only to the originator of the failed
data delivery, thus no requring to use the precursor list.
LOAD MAY use the route cost, which is the accumulated link cost from
the originator to the destination, as a metric of routing. For this,
LOAD utilizes the Link Quality Indicator (LQI) of the 6LoWPAN PHY
layer in the routing decision in addition to the hop distance. This
implies that LOAD MAY prefer a route of better link quality to a route
of shorter hop distance.
LOAD SHOULD utilize the acknowledged transmission option at the
6LoWPAN MAC layer for keeping track of the connectivity of a route.
LOAD does use neither the passive acknowledgements nor the HELLO
messages of AODV.
The basic operations of LOAD are route discovery, managing data
structures and maintaining local connections. For these operations,
LOAD maintains the following two tables: the routing table and the
route request table. The routing table stores route information such
as destination, next hop node, and status. The route request table
stores the temporary route information used in the route discovery
process.
Kim, et al. Expires January 18, 2006 [Page 4]
Internet-Draft LOAD July 2005
There are two different types of 6LoWPAN devices: the reduced
function device(RFD) and the full function device (FFD). LOAD SHOULD
utilize only FFD for mesh routing. Thus, A FFD SHOULD implement the
operations of LOAD and maintain the data structures of LOAD.
4. Terminology
This section defines the terminology of LOAD that is not defined in
[RFC3753] and [RFC3561].
destination
A node to which data packets are to be transmitted. Same as
"destination node".
forward route
A route set up to send data packets from the originator to its
destination.
link cost
A Link Quality (LQ) between a node and its neighbor node.
link quality indicator (LQI)
A mechanism to measure the Link Quality (LQ) in IEEE 802.15.4
PHY layer [ieee802.15.4]. It measures LQ by receiving the
signal energy level. A high LQ value implies the good quality
of communication (i.e. low link cost).
originator
A node that initiates a route discovery process. Same as
"originating node"
route cost
An accumulated link cost as a LOAD control message (RREQ or
RREP) passes through the nodes on the route. The accumulation
mechanism is TBD.
reverse route
A route set up to forward a RREP back to the originator
from the destination. Same as "reverse route" in
[RFC3561].
Kim, et al. Expires January 18, 2006 [Page 5]
Internet-Draft LOAD July 2005
5. Data Structures
A FFD in 6LoWPAN SHOULD maintain a routing table and a route request
table. This section describes the tables and the message formats.
5.1 Routing Table Entry
The routing table of LOAD includes the following fields:
destination address
The 16 bit short or EUI-64 link layer address of the final
destination of a route
next hop address
The 16 bit short or EUI-64 link layer addresses of the next hop
node to the destination.
status
The status of a route. It includes the following states: VALID,
INVALID, ROUTE_DISCOVERY, etc.
life time
The valid time in milliseconds before the expiration or the
deletion of a route.
5.2 Route Request Table Entry
Route request table is used for discovering routes. It stores the
following route request information until a route is discovered.
route request ID
a sequence number uniquely identifying the particular RREQ when
taken in conjunction with the originator
originator address
The 16 bit short or EUI-64 link layer address of the node which
originates RREQs.
reverse route address
The 16 bit short or EUI-64 link layer address of the next hop
node on the reverse route to the originator.
Kim, et al. Expires January 18, 2006 [Page 6]
Internet-Draft LOAD July 2005
forward route cost
The accumulated link cost along the forward route from the
originator to the current node through which a RREQ is
forwarded.
reverse route cost
The accumulated link cost along the reverse route from the final
destination to the current node through which a RREP is
forwarded.
valid time
The time of the expiration or deletion of a route in
milliseconds.
5.3 Message Format
5.3.1 Route Request (RREQ)
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 |R|D|O|Reserved | RREQ ID | Route cost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Layer Destination Address /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Layer Originator Address /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<Fig. 1. RREQ message format>
The RREQ message format is shown in Fig. 1 and contains the following
fields:
Type 1 for indicating a RREQ message.
R 1 Local Repair.
D 1 for the 16 bit address of the destination,
0 for the EUI-64 address of the destination.
O 1 for the 16 bit address of the originator,
0 for the EUI-64 address of the originator.
Route cost The accumulated link cost of the reverse route from
the originator to the sender of the RREQ.
Kim, et al. Expires January 18, 2006 [Page 7]
Internet-Draft LOAD July 2005
RREQ ID A sequence number uniquely identifying the particular
RREQ when taken in conjunction with the originator.
Reserved 0; ignored on reception.
Link layer Destination Address
The 16 bit short or EUI-64 link layer address of the
destination for which a route is supplied.
Link layer Originator Address
The 16 bit short or EUI-64 link layer address of the
node which originated the Route Request.
5.3.2 Route Reply (RREP)
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 |R|D|O|Reserved | RREQ ID | Route cost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link layer Destination Address /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link layer Originator Address /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<Fig. 2. RREP message format>
The RREP message format is shown in Fig. 2 and contains the following
fields:
Type 2 for indicating a RREP message.
R 1 Local Repair.
D 1 for the 16 bit address of the destination,
0 for the EUI-64 address of the destination.
O 1 for the 16 bit address of the originator,
0 for the EUI-64 address of the originator.
Reserved 0; ignored on reception.
Route cost The accumulated link cost of the route from
the destination to the sender of the RREP.
RREQ ID A sequence number uniquely identifying the particular
RREQ when taken in conjunction with the originator.
Kim, et al. Expires January 18, 2006 [Page 8]
Internet-Draft LOAD July 2005
Link layer Destination Address
The 16 bit short or EUI-64 link layer address of the
destination for which a route is supplied.
Link layer Originator Address
The 16 bit short or EUI-64 link layer address of the
node which originated the Route Request.
5.3.3 Route Error (RERR)
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 |D| Reserved | Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreachable Link Layer Destination Address /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<Fig. 3. RERR message format>
The RERR message format is shown in Fig. 3 and contains the following
fields:
Type 3 for indicating a RERR message.
D 1 for the 16 bit address of the destination,
0 for the EUI-64 address of the destination.
Reserved 0; ignored on reception.
Error Code Numeric value for describing error.
0x00 = No available route
0x01 = Low battery
0x02 - 0xff = reserved (TBD)
Unreachable Link Layer Destination Address
The 16 bit short or EUI-64 link layer address of the
final destination that has become unreachable due to a
link break.
Kim, et al. Expires January 18, 2006 [Page 9]
Internet-Draft LOAD July 2005
6. Operation
6.1 Generating Route Request
The basic operations of LOAD include route discovery, managing data
structures and maintaining local connections. A node maintains
the following two tables for routing: the routing table and the
routing request table.
During the discovery period, an originator, a node that requests a
route discovery, generates a Route Request (RREQ) message with the
RREQ ID which was incremented by one from the previous RREQ ID value.
A node SHOULD NOT originate more than RREQ_RATELIMIT RREQs per second.
After brocasting a RREQ, a node waits for a RREP. If a route is not
discovered within NET_TRAVERSAL_TIME milliseconds, the node MAY try
again the discovery process a maximum of RREQ_RETRIES times.
6.2 Processing and Forwarding Route Request
Upon receiving a RREQ, an intermediate node tries to find the entry
of the same originator address and RREQ ID pair in the route request
table. If the entry is found, the node just discards the RREQ.
Otherwise, the node creates a reverse route to the originator in the
routing table and a RREQ entry in the route request table. Then,
the node forwards the RREQ.
6.3 Generating Route Reply
When the destination receives a RREQ, it tries to find the entry of
the same originator address and RREQ ID pair in the route request
table. If the entry is found, the destination compares the route cost
of the RREQ with the forward route cost of the entry. If the cost of
the RREQ is better than (i.e. less than) that of the entry, the
destination updates the reverse route to the originator in the routing
table and generates a RREP in reply. If the cost of the RREQ is not
less than that of the entry, the destination just discards the RREQ.
6.4 Receiving and Forwarding Route Reply
Upen receiving a RREP, an intermediate node checks whether it has a
route entry for the destination of the RREP (i.e. the originator of
the corresponding RREQ). If it does not have the route entry, it
just discards the RREP. Otherwise, it also checks for the existence
of the corresponding RREQ entry (which has the same RREQ ID and
originator address pair as that of the RREP) in the route request
table. If there is no such entry, then it just discards the RREP. If
Kim, et al. Expires January 18, 2006 [Page 10]
Internet-Draft LOAD July 2005
there is such an entry and the entry has worse reverse route cost
(i.e. higher value) than the route cost of the RREP, the node updates
the entry with the information of the RREP and forwards it to the
previous hop node toward the destination of the RREP. If the entry
has better reverse route cost (i.e. lower value) than that of the
RREP, the node just discards the RREP.
During the delivery of the RREP to the originator, the route cost
value of the RREP is accumulated on the reverse route from the
destination to the originator. The accumulation mechanism is TBD (if
necessary in this document).
6.5 Local Repair and Route Error (RERR) Messages
If a link break occurs or a device fails during the delivery of data
packets, the upstream node of the link break MAY repair the route
locally. To repair a route, the node disseminates a RREQ with the
originator address set to its own address and the destination address
set to the data packet's destination address. In this case, the 'R
flag' of the RREQ is set to 1. The data packet is buffered during the
route discovery period. If the destination node receives the RREQ for
a route repair, it responds with a RREP of which the 'R flag' is also
set to 1.
If the repairing node cannot receive a RREP from the final destination
until the end of the route discovery period, it unicasts a RERR with
an error code that indicates the reason of the repair failure to the
originator. A repairing node SHOULD NOT generate more than
RERR_RATELIMIT RERRs per second. Then, the buffered data packet is
discarded. If the originator that sends a data packet receives the
RERR, it MAY try to reinitiate route discovery.
When the repairing node receives a RREP from the destination during
the route discovery period, it updates the routing table entry
information from the RREP. Then the node transmits the buffered data
packet to the destination through the new route.
Kim, et al. Expires January 18, 2006 [Page 11]
Internet-Draft LOAD July 2005
7. Configuration Parameters
This section describes the default values for some important
parameters associated with LOAD operations.
Parameter Name Value
--------------------- -------------
NET_TRAVERSAL_TIME TBD
RREQ_RETRIES 3
RREQ_RATELIMIT 2
RERR_RATELIMIT 2
8. IANA Consideration
This document needs an additional IANA registry for the prot_type
value that indicates the LOAD format.
9. Security Considerations
The security considerations of the [RFC3561] are applicable to this
document. As described in the charter of the 6lowpan w.g., LOAD will
also try to reuse existing security considerations related to Ad hoc
routing protocols. Further considerations will be studied in the next
version.
10. Acknowledgments
Thanks to the authors of RFC 3753 and RFC 3561, as parts of this
document are patterned after theirs. Thanks to Nandakishore
Kushalnagar, Byeong-Hee Roh, Myung-ho Jung, Dae-hong Son, and Minho
Lee for their useful discussions and supports for writing this
document.
11. References
11.1 Normative Reference
[EUI64] "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64)
REGISTRATION AUTHORITY", IEEE http://standards.ieee.org/
regauth/oui/tutorials/EUI64.html.
[I-D.montenegro-lowpan-ipv6-over-802.15.4]
Montenegro, G., "Transmission of IPv6 Packets over IEEE
802.15.4 Networks",
draft-montenegro-lowpan-ipv6-over-802.15.4-02 (work in
progress), February 2005.
Kim, et al. Expires January 18, 2006 [Page 12]
Internet-Draft LOAD July 2005
[I-D.ietf-ipv6-rfc2462bis]
Thomson, S., "IPv6 Stateless Address Autoconfiguration",
draft-ietf-ipv6-rfc2462bis-08 (work in progress),
May 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On-
Demand Distance Vector (AODV) Routing", RFC 3561,
July 2003.
[RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004.
[ieee802.15.4]
IEEE Compure Society, "IEEE Std. 802.15.4-2003", IEEE Std.
802.15.4-2003, October 2003.
11.2 Informative Reference
[RFC1884] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 1884, December 1995.
[I-D.kushalnagar-lowpan-goals-assumptions]
Kushalnagar, N. and G. Montenegro, "6LoWPAN: Overview,
Assumptions, Problem Statement and Goals",
draft-kushalnagar-lowpan-goals-assumptions-00 (work in
progress), February 2005.
[AODVjr] Chakeres, Ian and Klein-Berndt, Luke, "AODVjr, AODV
Simplified", ACM SIGMOBILE Mobile Computing and
Communications Review pp. 100-101, July 2002.
[I-D.ietf-manet-dymo]
Chakeres, I., "Dynamic MANET On-demand (DYMO) Routing",
draft-ietf-manet-dymo-02 (work in progress), June 2005.
[TinyAODV]
"TinyAODV Implementation", TinyOS Source Code Repository h
ttp://cvs.sourceforge.net/viewcvs.py/tinyos/tinyos-1.x/
contrib/hsn/.
Kim, et al. Expires January 18, 2006 [Page 13]
Internet-Draft LOAD July 2005
Authors' Addresses
Ki-Hyung Kim, Editor
Ajou University
San 5 Wonchun-dong, Yeongtong-gu
Suwon-si, Gyeonggi-do 442-749
KOREA
Phone: +82 31 219 2433
Email: kkim86@ajou.ac.kr
Soohong Daniel Park, Editor
Mobile Platform Laboratory, SAMSUNG Electronics
416 Maetan-3dong, Yeongtong-gu
Suwon-si, Gyeonggi-do 442-742
KOREA
Phone: +82 31 200 4508
Email: soohong.park@samsung.com
Gabriel Montenegro
Microsoft Corporation
US
Email: gabriel_montenegro_2000@yahoo.com
Seung Wha Yoo
Ajou University
San 5 Wonchun-dong, Yeongtong-gu
Suwon-si, Gyeonggi-do 442-749
KOREA
Phone: +82 31 219 1603
Email: swyoo@ajou.ac.kr
Kim, et al. Expires January 18, 2006 [Page 14]
Internet-Draft LOAD 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.
Kim, et al. Expires January 18, 2006 [Page 15]