One document matched: draft-chakeres-manet-arch-00.txt
MANET Autoconfiguration (AUTOCONF) I. Chakeres
Internet-Draft Boeing
Expires: January 30, 2007 J. Macker
Naval Research Laboratory
T. Clausen
LIX, Ecole Polytechnique
July 29, 2006
Mobile Ad Hoc Network Architecture
draft-chakeres-manet-arch-00
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 30, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document discusses Mobile Ad hoc NETworks (MANETs). It
discusses some basic MANET architectural concepts, related
taxonomies, and MANETs' relationship to the Internet architecture.
It also discusses the relevant node, interface, and network
characteristics that influence Internet protocol development in
Chakeres, et al. Expires January 30, 2007 [Page 1]
Internet-Draft MANET Architecture July 2006
MANETs.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. MANET Motivation Discussion . . . . . . . . . . . . . . . . . 6
4. Challenges and Design Considerations . . . . . . . . . . . . . 7
4.1. Wireless Interface . . . . . . . . . . . . . . . . . . . . 7
4.2. Neighbors and Neighborhoods . . . . . . . . . . . . . . . 8
4.3. Dynamic Network Topology . . . . . . . . . . . . . . . . . 9
5. Architectural Issues . . . . . . . . . . . . . . . . . . . . . 10
5.1. Local Connectivity . . . . . . . . . . . . . . . . . . . . 10
5.2. MANET Membership . . . . . . . . . . . . . . . . . . . . . 10
5.3. Border Connectivity . . . . . . . . . . . . . . . . . . . 11
6. Deployment Taxonomy . . . . . . . . . . . . . . . . . . . . . 11
6.1. Infrastructure . . . . . . . . . . . . . . . . . . . . . . 11
6.2. Number of Peer MANET Routers . . . . . . . . . . . . . . . 12
6.3. Heterogeneity . . . . . . . . . . . . . . . . . . . . . . 13
6.4. Example Deployments . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
10. Informative References . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 17
Chakeres, et al. Expires January 30, 2007 [Page 2]
Internet-Draft MANET Architecture July 2006
1. Introduction
A Mobile Ad hoc NETwork (MANET) is made up from a set of MANET
routers (MRs). These MRs organize and maintain a routing structure
among themselves over dynamic wireless interfaces. As any IP router,
a MR may have an attached set of nodes. These nodes access the MANET
via the MR to which they are attached.
Due, in part, to relative movements of MR and, in part, to
environmental effects (especially wireless characteristics), the
network topology and communication links in a MANET may change state
more frequently than in fixed wired or fixed wireless networks.
These attributes and others influence Internet Protocol (IP) design
for MANETs. This document elaborates on the many important
properties and their impact.
2. Terminology
This document employs the following definitions:
Node
any device (router or host) which implements IP.
Router
a node that forwards IP packets not explicitly addressed to
itself.
MANET Router (MR)
a router that engages in a MANET routing protocol. In certain
scenarios a MR may forward packets only for itself (and its
attached nodes).
Host
any node that is not a router, i.e. it does not forward packets
addressed to others.
Link
A communication facility on a layer below IP, over which nodes
exchange IP packets. In a MANET, links may change quality on
short time scales, present unique views of their local
neighborhood, and have other challenging properties.
Neighbor
Two nodes are neighbors if and only if their links intersect, i.e.
data may be propagated between them without relying on assistance
of any forwarding node.
Chakeres, et al. Expires January 30, 2007 [Page 3]
Internet-Draft MANET Architecture July 2006
Interface
A node's point of attachment to a link.
Broadcast Interface (BI)
An interface supporting many (more than two) attached routers,
together with the capability to address a single physical message
to all of the attached routers (broadcast). The set of nodes
receiving a given physical broadcast message are the neighbors of
the node originating the message; this set of receiving nodes will
themselves be neighbors with one another. An ethernet segment is
an example of a broadcast interface.
Wireless Broadcast Interface (WBI)
A broadcast interface that communicates over a wireless channel.
Compared to traditional broadcast interfaces, a wireless broadcast
interface has additional complexity: each device may have a unique
local view of its local network. The set of nodes receiving a
given physical broadcast message are neighbors of the node
originating the message; this set of receiving nodes will,
however, not necessarily be neighbors with one another. An IEEE
802.11 interface is an example of a wireless broadcast interface.
Autonomous System (AS)
An Autonomous System (AS) is a network topology that consists of a
collection of routers and their subnetworks (with hosts attached)
interconnected by a set of routes. The subnetworks and the
routers are expected to be under the control of a single
operations and maintenance (O&M) organization. Within an AS,
routers use the same routing protocol. An AS is expected to
present to other ASs the appearance of a coherent interior routing
plan, and a consistent picture of the reachable nodes.
MANET
A MANET is an AS made up of affiliated/associated MRs (and their
connected nodes) that maintain a routing structure in arbitrarily
dynamic network topologies, as illustrated in Figure 1.
Chakeres, et al. Expires January 30, 2007 [Page 4]
Internet-Draft MANET Architecture July 2006
/----------------------\ /----------------------\
| MANET | | MANET |
| +---+ +---+ +---+ | | +---+ +---+ +---+ |
| |RT1+-+RT2+-+RT3| | | |RT1+-+RT2+-+RT3| |
| +-+-+ +---+ +---+ | | +---+ +---+ +-+-+ |
| | | | | |
| +-+-+ | Change | +-+-+ |
| |RT4+ | in | |RT7| |
| +---+\ | Time | +---+ |
| \+---+ | \----------------------/
| +RT5+ | /----------------------\
| /+---+\ | | MANET |
| +---+/ \+---+ | | +---+ +-+-+ +---+ |
| |RT6+ +RT7| | | |RT6+--+RT4+--+RT5+ |
| +---+ +---+ | | +---+ +---+ +---+ |
\----------------------/ \----------------------/
Figure 1: MANET(s)
MANET Border Router (MBR)
A MANET border router is a MR that connects to two or more ASs, as
illustrated in Figure 2. A MBR presents a consistent picture of
the nodes reachable through itself to connected ASs. A MBR
chooses the routing information to propagate between ASs.
/------\ /------\
| | +---+ | |
| AS +--+MBR+--+ AS |
| | +---+ | |
\------/ \------/
Figure 2: MBR
Flooding
The process of forwarding information to MRs throughout a MANET.
Much of this terminology was borrowed from existing documents, to
list a few [RFC1812], [RFC2453], [RFC2460], [RFC2328], [RFC3513],
[RFC3753], [I-D.thaler-autoconf-multisubnet-manets], and
[I-D.templin-autoconf-dhcp]. Note that the original text for the
terms was modified, though we have attempted to maintain the same
meaning. In the future, terms defined elsewhere will likely be cited
instead of included.
Chakeres, et al. Expires January 30, 2007 [Page 5]
Internet-Draft MANET Architecture July 2006
3. MANET Motivation Discussion
The Internet Protocol (IP) core design tenets -- connectionless
networking and packet-based forwarding -- are ideally suited for use
in highly dynamic contexts, such as MANETs. Yet, some additional
functionality is required to meet the unique challenges and
opportunities present in MANETs.
The initial motivation for MANETs was called Packet Radio (PR)
networking [FL01]. In PR, each router is equipped with a single
wireless broadcast interface (the simplest MR configuration). Each
router may be mobile, and the routers may be or may become spatially
distributed such that all routers cannot communicate directly. That
is, two routers might require one or more other intermediate routers
to forward (route) packets on their behalf. In the example shown in
Figure 3, for RT1 to send packets to RT3, the intermediary RT2 must
relay the packets. This implies that RT2 must receive the packet
from RT1 on its interface and determine that it must retransmit the
packet over the same interface as the one where the packet was
received, in order for the packet to reach RT3. This example also
illustrates how WBIs differ from BIs: from the point of view of RT2,
both RT1 and RT3 are neighbors, whereas RT1 and RT2 are not
themselves neighbors with one another.
Communication
Range
<~~~~~~+~~~~~~> <~~~~~~+~~~~~~>
Single | <~~~~~~+~~~~~~> |
Wireless +-|-+ +-|-+ +-|-+
Interface |RT1| |RT2| |RT3|
+---+ +---+ +---+
Figure 3: Basic MANET Network
The attachment of PR networks to the fixed ARPANET stimulated early
introduction of the first Internet architecture approaches and
designs enabling heterogeneous interconnection. The taxonomy of
scenarios in which MANETs may be deployed is rich, making it
important to develop flexible MANET protocols and discuss
architectural approaches that cover a set of deployment scenarios
reasonably well.
The two characteristics having the largest impact on MANET protocol
design are:
Chakeres, et al. Expires January 30, 2007 [Page 6]
Internet-Draft MANET Architecture July 2006
o wireless interface characteristics and
o frequent topological change.
One more important point to emphasize is that the fundamental MANET
design motivation is the same as existing IP intra-domain routing
goals, except MANET protocols account for more challenging
topological conditions and wireless interface behaviors. These
challenging conditions often require new protocols or extensions.
4. Challenges and Design Considerations
As mentioned in Section 3, the wireless interface characteristics and
the frequently changing topology present challenges, under which
MANET protocols must be developed. These challenges are detailed
further in this section.
4.1. Wireless Interface
Wireless interface characteristics differ from wired interface
characteristics in several ways:
Shared resource
In wireless networks since the physical channel resources are
shared between many devices, the transmission on each wireless
interface influences the resources available to all nearby devices
often including nodes multiple hops away. Therefore, the overhead
of signaling, message exchange, and control plane flooding often
induced by protocol designs needs special consideration to reduce
channel contention and congestion. In some cases, underlying
lower layer protocols may change the shared resource in dynamic
ways, and these mechanism also contribute to changing topological
and quality conditions.
High loss statistics
In comparison to wired interfaces, wireless interfaces experience
loss statistics which can be several orders of magnitude higher
than in wired environments. Furthermore, the losses can vary
temporally and dramatically dependent upon the environment
scenario and type of wireless technology. Therefore, signaling
and message exchange may be unreliable, and this fact must be
accommodated in MANET protocols.
Time varying interface performance
In comparison to wired interfaces, wireless interfaces experience
significant changes in performance over time. The capacity, loss,
delay, jitter, and other metrics of neighbor quality may vary by
Chakeres, et al. Expires January 30, 2007 [Page 7]
Internet-Draft MANET Architecture July 2006
several orders of magnitude at large and small time scales. Some
of these characteristics can be quantified by the position and
distance between devices, but more often these characteristics are
unpredictable and related to environmental effects and must be
included in higher layer protocol design decisions.
Stochastic neighborhoods
Given the variance associated with wireless interfaces mentioned
above, from an IP perspective the neighbor relationships may
change state often. Handling the rapid insertion, deletion, and
symmetric variability of wireless channels is a challenge.
Wireless broadcast
A wireless broadcast/multicast packet reaches only nodes that are
neighbors to the node which transmitted the broadcast packet, as
described for wireless broadcast interfaces. Given that each MR
can be located in a different arbitrary position, or may have
unique antenna characteristics, each MR may have a unique set of
neighbors. Therefore, a MR may be required to forward a packet
out the same logical interface upon which the packet was received
to reach another MR. Logically, each MRs' wireless interface may
communicate with a unique set of neighboring MR, since no other MR
may have the same logical connectivity. This fact and its impact
will be discussed further in Section 4.2.
Other characteristics
There are numerous other factors related to wireless interfaces
and MANET routing, but these factors will not be elaborated upon
here. For more information on wireless interfaces and other MANET
performance characteristics please see [RFC2501].
4.2. Neighbors and Neighborhoods
Given a wireless interface and spatially distributed MRs, each device
may have a different unique partial view of the MANET. That is, each
MR may have a different set of adjacent MRs, and this set may change
over time.
Chakeres, et al. Expires January 30, 2007 [Page 8]
Internet-Draft MANET Architecture July 2006
Communication
Range
<~~~~~~+~~~~~~> <~~~~~~+~~~~~~>
Single | <~~~~~~+~~~~~~> |
Wireless +-|-+ +-|-+ +-|-+
Interface |RT1| |RT2| |RT3|
+---+ +---+ +---+
RT1 RT2 RT3
-------------------------
Neighbors * RT2 RT1 RT2
* RT3
Figure 4: Wireless Broadcast Interface (WBI) Neighbors
The possibly unique set of adjacent MRs requires MRs to forward
packets in and out the same wireless interface. The act of
forwarding packets in and out of the same interface, while reaching a
new subset of MRs, results in duplicate IP messaging being received
at MR with more than one neighboring MR. For unicast traffic, the
next-hop designation in each packet ensures that such traffic is
simply ignored by routers, other than the designated next hop router,
as in all other IP networks. For non-link-local multicast and
broadcast traffic, recognition of this duplicate reception needs to
be accounted for explicitly in protocol designs. Present MANET
routing protocol designs that employ flooding techniques for control
traffic meet this requirement.
Due to MANETs wireless nature, communication between MRs can be
asymmetric: MR X may receive traffic from MR Y, whereas MR Y does not
receive traffic from MR X. In other words, the MRs X and Y links
provides for unidirectional communication from MR Y to MR X. This is
also an example showing that each MR may have its own unique view of
the local topology. Generally, MANET routers should use only
bidirectional communication links between routing peers. One reason
to prefer bidirectional communication between routing pairs is that
some common L2 protocols (e.g. IEEE 802.11) employ positive
acknowledgments for unicast data traffic and simply won't work
otherwise. The mechanisms for sensing and maintaining bidirectional
communication are important to the design of MANET routing protocols.
4.3. Dynamic Network Topology
In the typical use case scenario, MRs are assumed to be mobile and
communicating over wireless interfaces, both of these properties
create a dynamic arbitrary network topology with varying adjacency
statistics. The local topology, as seen by a given MR, is expected
Chakeres, et al. Expires January 30, 2007 [Page 9]
Internet-Draft MANET Architecture July 2006
to change rapidly and unpredictably. Existing protocols for wired
networks are typically not designed or able to manage wireless links
and converge on a time-scale appropriate for MANETs. However, MANET
extensions for existing wired routing protocols such as OSPF have
been developed and are being further explored within the IETF.
Another outcome of the dynamic operation requirement is that MANET
protocols must be able to operate effectively without strict network
wide convergence.
5. Architectural Issues
The topology within a MANET is expected to change, and the routing
protocol should operate effectively given arbitrary dynamic changes.
Changes can happen at three different levels: local connectivity,
MANET membership, and MANET border connectivity.
5.1. Local Connectivity
Locally topology changes are the result of either addition or loss of
neighbors. That is, two or more MRs are either connected and can
communicate (i.e. their links intersect) or they are disconnected and
can not communicate. The detection and determination of local
connectivity is outside the scope of this document.
MRs may need to be aware of these local connectivity changes and
handle them appropriately.
There are several possible logical local connectivity states that may
exist between a pair of MRs:
Disconnected
The two MRs links do not intersect.
Connected
The two MRs links intersect.
Other
The two MRs links might intersect. The MRs are not sure whether
their links intersect or not. Given wireless interfaces it may be
difficult to classify two MR as connected or disconnected.
Note that when local connectivity changes, MANET membership and
border connectivity may also be change.
5.2. MANET Membership
The membership within a MANET may change based on changes to the
Chakeres, et al. Expires January 30, 2007 [Page 10]
Internet-Draft MANET Architecture July 2006
local connectivity between MRs. A MANET may partition into multiple
separate smaller MANETs when two MRs which used to be connected
becomes disconnected. Alternatively, when two MANETs collide, i.e.
at least one MR from each MANET becomes connected, the two MANETs can
merge and form a single, large MANET. These membership events can
happen between any pair of MRs. The detection and determination of
MANET membership is outside the scope of this document.
The following membership events may occur:
Partition
Loss of a neighbor can cause a MANET to partition into multiple
smaller MANETs. Partitioning may also decrease each new MANETs
border connectivity.
Merge
Connection to a new neighboring MR can cause multiple MANETs to
merge into a single larger MANET. This new MANET may have
additional border connectivity, via now reachable MBR.
Note that MANET membership events may happen more quickly than MANET
wide communication can occur. This fact is important since a part of
a MANET may become its own MANET, while another part of the MANET may
merge with another MANET.
5.3. Border Connectivity
MANET border routers (MBR) hide the details of the internal MANET
topology from other ASs. There may be multiple external connections
to a MANET, via one or more MBR. A MBR may disseminate routing
information about other connected ASs, to each connected AS.
A local connectivity or MANET membership change may result in changed
MBR connectivity.
6. Deployment Taxonomy
The present and future proliferation of inexpensive wireless
interfaces continues to stimulate technical interest and developments
in the area of MANET for a wide variety of deployment scenarios. In
this section, we present several key characteristics for describing
expected MANET deployments.
6.1. Infrastructure
We define infrastructure as the assumed availability of services,
devices, and resources . This axis of the taxonomy falls into
Chakeres, et al. Expires January 30, 2007 [Page 11]
Internet-Draft MANET Architecture July 2006
several broad categories:
Infrastructure is always available
Infrastructure is sometimes available
Infrastructure is never available
When describing a deployment scenario, it is important to specify the
expected infrastructure connection constraints and expectations,
especially whether the infrastructure resides in the MANET or behind
a MBR. Different frameworks for autoconfiguration, network
management, and fundamental services can be developed based upon the
expected constraints and operating conditions.
6.2. Number of Peer MANET Routers
The number of peer MRs in a MANET is an important consideration.
This number is not the complete number of nodes in a MANET (since MRs
may support an arbitrary number of connected nodes) but a measure of
the number of peer MR participating as a cohesive flat routing area.
While the number of MRs does not define scalability of a MANET
protocol, it is often useful discuss the number of peer MR to get a
feel for maturity of typical deployment solutions. For simplicity we
define the following network sizes to aid in discussion:
Small
2-30 MANET peers
Moderate
30-100 MANET peers
Large
100-1000 MANET peers
Very large
Larger than 1000 MANET peers
At the time of writing, small and moderate size peer MANET routing
scenarios have matured and have reasonable testing and deployment
experience. These sizes can perform reasonably well in many cases
without hierarchy. MANET architectures can, of course, support
routing hierarchies to improve scaling. Large and very large MANET
routing areas that are flat are still a topic of active research and
are not considered here. Existing MANET routing developments, such
as SMF [I-D.ietf-manet-smf], have shown significant performance
improvements and capabilities even in small peer router size
deployments and experiments.
Chakeres, et al. Expires January 30, 2007 [Page 12]
Internet-Draft MANET Architecture July 2006
6.3. Heterogeneity
The Internet Protocol provides a least common denominator for
heterogeneous network interconnection. It allows devices independent
of lower layer connectivity properties to inter-operate and
communicate seamlessly. This document has concentrated on the
architectural description in which MANET technology provides Internet
layer routing and possibly between heterogeneous interfaces, although
variants of IETF MANET routing solutions have been implemented or
adapted at lower layers below IP. Within IP-based MANETs, while a
single wireless broadcast interface may be used to support multi-hop
IP routing, we allow for the possibility of several different types
of lower layer link technologies to be used within the same MANET.
Developing MANET routing protocols at the IP layer seamlessly enables
lower layer heterogeneity. Also, the initial term MANET was
developed by a group of engineers doing this work at the IP layer and
envisioning heterogeneity support.
6.4. Example Deployments
Here we provide a short list of example deployment scenarios:
Wireless mesh networks
Disaster relief
Sensor networks
Range extension
Military communication
Automotive networks
7. Security Considerations
TBD
8. IANA Considerations
This is an informational document. IANA requirements for MANET
related protocols will be developed within the protocol
specifications for MANET protocols.
Chakeres, et al. Expires January 30, 2007 [Page 13]
Internet-Draft MANET Architecture July 2006
9. Acknowledgments
Discussions and developments concepts and architectural issues have
evolved over many years of discussion of related work within the
MANET WG. There are obviously many people that have contributed to
past discussions and related draft documents within the WG that have
influenced the development of these concepts that deserve
acknowledgment. The authors would like to thank all contributors to
the MANET and AUTOCONF WG efforts and those that have helped in the
review and content process.
While not entirely complete the authors would like to in
particular thank the following individuals for there discussions
and contributions:
Fred Templin
Christopher Dearlove
Charles Perkins
Justin Dean
Subhranshu Singh
Thomas Henderson
Emmanuel Baccelli
Dave Thaler
Jari Akko
Thomas Nartan
The RFC text was produced using Marshall Rose's xml2rfc tool.
10. Informative References
[FL01] Freebersyser, J. and B. Leiner, "A DoD perspective on
mobile ad hoc networks", Addison Wesley C. E. Perkin, Ed.,
2001, pp. 29--51, July 2001.
[I-D.ietf-manet-smf]
Macker, J., "Simplified Multicast Forwarding for MANET",
draft-ietf-manet-smf-02 (work in progress), March 2006.
[I-D.templin-autoconf-dhcp]
Chakeres, et al. Expires January 30, 2007 [Page 14]
Internet-Draft MANET Architecture July 2006
Templin, F., "MANET Autoconfiguration using DHCP",
draft-templin-autoconf-dhcp-01 (work in progress),
June 2006.
[I-D.thaler-autoconf-multisubnet-manets]
Thaler, D., "Multi-Subnet MANETs",
draft-thaler-autoconf-multisubnet-manets-00 (work in
progress), February 2006.
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers",
RFC 1812, June 1995.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453,
November 1998.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking
(MANET): Routing Protocol Performance Issues and
Evaluation Considerations", RFC 2501, January 1999.
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004.
Chakeres, et al. Expires January 30, 2007 [Page 15]
Internet-Draft MANET Architecture July 2006
Authors' Addresses
Ian Chakeres
Boeing
The Boeing Company
P.O. Box 3707 Mailcode 7L-49
Seattle, WA 98124-2207
USA
Email: ian.chakeres@gmail.com
Joe Macker
Naval Research Laboratory
Washington, DC 20375
USA
Email: macker@itd.nrl.navy.mil
Thomas Heide Clausen
LIX, Ecole Polytechnique
91128 Palaiseau CEDEX
France
Email: T.Clausen@computer.org
URI: http://www.lix.polytechnique.fr/Labo/Thomas.Clausen/
Chakeres, et al. Expires January 30, 2007 [Page 16]
Internet-Draft MANET Architecture July 2006
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 (2006). 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.
Chakeres, et al. Expires January 30, 2007 [Page 17]
| PAFTECH AB 2003-2026 | 2026-04-23 08:48:32 |