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]