MANET Autoconfiguration (AUTOCONF) T. Clausen Internet-Draft J. Garnier Expires: January 12, 2006 LIX, Ecole Polytechnique, France S. Singh Samsung AIT, South Korea Chris. Christopher Baesystems, UK July 11, 2005 Evaluation Criteria for MANET Autoconf Mechanisms draft-clausen-autoconf-criteria-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 12, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document gives a general set of objective criteria to evaluate an autoconfiguration mechanism in a MANET environment. All criteria are important to outline an evaluation of an autoconfiguration mechanism. These criteria have been grouped into three classes: Clausen, et al. Expires January 12, 2006 [Page 1] Internet-Draft AUTOCONFCRITERIA July 2005 functional criteria, performance criteria and usability criteria. For each of the criteria, a description is outlined, hints are given on how to perform an adequate measure of the criterium, and an evaluation features the importance of the criterium in the full evaluation of a mechanism. Clausen, et al. Expires January 12, 2006 [Page 2] Internet-Draft AUTOCONFCRITERIA July 2005 1. Introduction This document gives a general set of objective criteria to evaluate an autoconfiguration mechanism in a MANET environment. All criteria are important to outline an evaluation of an autoconfiguration mechanism. These criteria have been grouped into three classes: functional criteria, performance criteria and usability criteria. For each of the criteria, a description is outlined, hints are given on how to perform an adequate measure of the criterium, and an evaluation features the importance of the criterium in the full evaluation of a mechanism. Clausen, et al. Expires January 12, 2006 [Page 3] Internet-Draft AUTOCONFCRITERIA July 2005 2. Functional Criteria This section describes functionalities that a mechanism must aim at featuring. Besides Duplicate Address Avoidance, DAA, an autoconfiguration mechanism implements at least one of these functionalities. These address issues result from the MANET environment in addition to usual issues of autoconfiguration. The more functionalities a system implements, the better it should be evaluated provided that these functionalities are correctly designed and that overall network performance does not suffer from this variety. 2.1 Duplicate Address Avoidance 2.1.1 Presentation This functionality is mandatory in an autoconfiguration mechanism. It consists of making all functionalities assign addresses only after checking their uniqueness. This principle must be the core of any design of an autoconfiguration mechanism. It is consequently crucial to test the efficiency of these functionalities from this point of view. A mechanism often assigning duplicate addresses should be disregarded quickly, for instance. 2.1.2 Measurement Experimental evaluation could consist in counting misassignments, i.e. assignments of already used addresses. Weak DAD is the result of the application of this principle to all mechanisms involving address assignments. Simple scenarios testing the functionalities of a mechanism are sufficient to assess these misassignments. 2.1.3 Evaluation This functionality is the only mandatory functionality in an autoconfiguration mechanism, as it reflects the assumption of uniqueness upon which the routing protocol is based. 2.2 Duplicate Address Detection 2.2.1 Presentation Duplicate Address Detection, DAD consists in mechanisms aiming to detect address collisions and solve them through address reassignment. Draconian ways of doing so involve reconfiguration of all the conflicting interfaces whereas more subtle mechanisms keep one interface up and reconfigure the others. Evaluation should prefer the latter way, since it allows more preservation of ongoing connections. Such DAD mechanisms are in fact ways of enforcing the Clausen, et al. Expires January 12, 2006 [Page 4] Internet-Draft AUTOCONFCRITERIA July 2005 principle of uniqueness of address for each interface, if failures happen, and should be evaluated the same way. Strong DAD may be an idealization of such a mechanism. 2.2.2 Measurement Simulations and experiments can easily be staged showing duplicate addresses. Mechanisms can be tested and evaluated according to their ability to handle such scenarios. 2.2.3 Evaluation Duplicate address detection allows the adaptative approach to strong DAD, i.e. a flexible way of controlling address uniqueness. Therefore, it is a very important criterium. 2.3 Address Assignment for Incomming Nodes 2.3.1 Presentation A mechanism in charge of assigning an address to an incoming node in a network is a base for almost all other more complex functionalities. It is also the first functionality expected from an autoconfiguration mechanism. 2.3.2 Measurement Simulations and experiments can be put up to test this functionality. Simple simulations or experiments with an already configured network and incoming nodes are sufficient. The number of incoming nodes, their location and the frequency of appearance can vary to thoroughly test the mechanism. 2.3.3 Evaluation This criterium is about a functionality that is a basis to more complex mechanisms. It is therefore central and must be evaluated in depth. The widespread use of address assignment mechanism, the DHCP protocol, shows the need for such a functionality. Absent an address assignment mechanism, other functionalities involving reconfiguration of nodes cannot properly be performed without a mechanism to reconfigure the node. Duplicate address detection cannot result in solutions to collisions. Clausen, et al. Expires January 12, 2006 [Page 5] Internet-Draft AUTOCONFCRITERIA July 2005 2.4 Full network configuration from scratch 2.4.1 Presentation This functionality, also called bootstrap capability, is the ability of unconfigured nodes to form a whole functional network, without any user intervention. 2.4.2 Measurement Simulations and experiments can be put up to test this functionality, using adequate scenarios, i.e. sets of scattered unconfigured nodes with various topology will be sufficient to test this functionality. 2.4.3 Evaluation This functionality is one among the several final goals of the design of an autoconfiguration mechanism. A particular attention must be paid to the prerequisites such a mechanism. 2.5 Network merger treatment 2.5.1 Presentation This functionality consists in uniting or reuniting more than one independent network in a way that preserves address uniqueness. The most important here is to specify the situations in which it is applicable. This can be done using a negotiation between the several networks or a direct merger followed by an address collision detection to eliminate the duplicate addresses. 2.5.2 Measurement Simulations and experiments can be put up to easily test this functionality, using scenarios showing two or more network of various relative importance. This notion of relative importance, which is basically the relative difference of size between the protagonists is a significant parameter. For instance, the situation of two networks of the same size showing as many conflicts as their number of nodes is likely to be more difficult to handle than the case when one is much bigger than the other. The structure of the network can indeed be highly perturbed during the response to the merger. Clausen, et al. Expires January 12, 2006 [Page 6] Internet-Draft AUTOCONFCRITERIA July 2005 2.5.3 Evaluation This functionality is complex because it involves the resolution of a large possible number of concurrent address collisions. A MANET lacking this functionality has a restrained mobility as this MANET cannot handle any encounter with a similar network. 2.6 Network partitioning treatment 2.6.1 Presentation An autoconfiguration mechanism implementing treatment of network mergers should be able to handle network partitioning as what causes difficulties in these situations is the merger after the partitioning. However, if the merger mechanism involves reconfiguring all the nodes of one of the 2 networks, this can be a source of inefficiency especially in the case of partitioning due to a lack of information diffusion. 2.6.2 Measurement Simulations and experiments can here again be put up to easily test this functionality, using adequate scenarios from the point of view of the mobility of nodes. Groups of variable relative size must be staged with motions leading to a splitting, followed by a merger. To test the functionality properly, additional nodes must have been added between the partitioning and the merger to simulate what the issue really consists in. 2.6.3 Evaluation Even though this functionality seems to highly depend on the treatment of network mergers, it can be a separate problem in mechanisms where networks can be discriminated. A MANET that cannot handle partitionings does not profit from the mobility of the nodes that constitute it. 2.7 Service Discovery 2.7.1 Presentation Service discovery is not always mentioned in the required functionalities of an autoconfiguration system. However, autoconfiguration rmechanisms should advertise the required information within the network. Furthermore, as forming a network is about sharing resources, integrated systems can profit from more general advertisement of such services. Clausen, et al. Expires January 12, 2006 [Page 7] Internet-Draft AUTOCONFCRITERIA July 2005 2.7.2 Measurement Simulations and experiments to test this functionality must show the behaviour of the mechanism with one or several service providers, of one or different nature. A theoretical evaluation must also take into account the ability to append additional information to the advertisement service, including description or other parameters for instance. 2.7.3 Evaluation This criterium is not often mentioned as a important functionality. As a secondary criterium, it can be left aside. However a treatment of this problem indicates a complete mechanism. Clausen, et al. Expires January 12, 2006 [Page 8] Internet-Draft AUTOCONFCRITERIA July 2005 3. Performance Criteria All MANET environments share a set of characteristics that are specific to this sort of networks. A MANET autoconfiguration mechanism must take these characteristics into account to achieve properly their task. In this section are outlined criteria to evaluate the compliance of autoconfiguration mechanisms to the limitation of MANETs. 3.1 Nodes with Limited Ressources 3.1.1 Presentation A mobile node in a MANET environment has finite resources. Power can be limited by battery capacities, computation capabilities can be low and memory can be scarce. Therefore, a mechanism should be highly optimized to ensure it can be functional without using huge storage structures and without the need of large amounts of computations. 3.1.2 Measurement To evaluate this, one could measure the additional memory used by the autoconfiguration mechanism and compare it with the memory used by the single routing protocol at the same time. The same comparison should be made as regards the computation time. Battery consumption can be derived from the combination of these measures with the lifetime of the node. Simulators such as NS2 can also give a direct access to the power consumption. 3.1.3 Evaluation This criterium is essential in MANET since one of the main assumption as regards MANETs is the mobility, that implies compact nodes and the use of batteries as power supply. A mechanism that would not take such limitations into account is likely not to be adaptable to real mobile networks. 3.2 Medium Overhead 3.2.1 Presentation The medium on which the nodes can exchange packets suffers from several limitations. As the nodes can only emit within a finite range, the medium cannot be considered as unique. Any node A can be within range from any other two nodes B and C that cannot listen to each other. If both nodes decide to send a message at the same time, A can not receive any of them. Such situations are called collisions. They are very likely to occur in saturated networks with many nodes and Clausen, et al. Expires January 12, 2006 [Page 9] Internet-Draft AUTOCONFCRITERIA July 2005 many control messages to transmit, or in very dynamic networks, which are networks with a quickly changing topology which must be continually updated. The ideal bandwidth is already limitted without such effects. Two types of overhead must be studied: Local overhead is the load of messages that are not forwarded but occupy the medium around an active node during a local negociation for instance. If the traffic is disturbed in the neighbourhood of a point where something related to autoconfiguration is happening, it can result in global problems, if the control messages intended to go through this zone are not relayed, neither in the zone nor further. Global overhead is the overhead induced by flooding procedures. As flooding operation result in much traffic throughout the network, such procedures should be avoided as much as possible. 3.2.2 Measurement The overhead induced by the autoconfiguration must be studied both theoretically through the count of the messages that must be sent in any situation, and experimentally. Simulators give an immediate access to the packets that were exchanged. The count is therefore possible in simulations. 3.2.3 Evaluation This criterium also reflects a key assumption and can be applied to even more situations than the previous one. In fact, it is often considered that the limitation of the medium is drastically more constraining than the limitation of the abilities of the nodes. Saturating the medium often leads to a collapse of the network as information cannot be exchanged any more. 3.3 Tolerance to information losses 3.3.1 Presentation Proactive protocols are based on knowledge of full and up-to-date topological description of the network by each node. As pointed out in the previous subsection, information diffusion is not guarantied. On the contrary, information incompleteness should be considered as a possibility. Therefore, any autoconfiguration mechanism should provide lightweight though efficient backup systems to solve the problems induced by information losses. Clausen, et al. Expires January 12, 2006 [Page 10] Internet-Draft AUTOCONFCRITERIA July 2005 3.3.2 Measurement This evaluation is primarily theoretic because the presence of such systems can be checked at this level. Information lacks must not make the whole system collapse. An experimental analysis of this can be performed assigning probabilities to transmissions so that packet diffusion is randomly perturbated. The backup mechanisns can also be tested by staging the situations resulting from such failures. 3.3.3 Evaluation This criterium must not be neglected as it is based upon an important characteristics of MANETs. A mechanism not tolerating information losses would be exposed to many failures during its functioning time. This must be prevented. 3.4 Convergence Time 3.4.1 Presentation An address autoconfiguration mechanism aims at performing automatic management of addresses in a network. The goal is to react as quickly as possible to any changes and provide a solution to a new situation. This is intended to ease the access to shared resources within a MANET. Here, what is referred to as convergence is the fact that after a change, there is a period during which the network detects the change and reacts to it. An event concerning autoconfiguration triggers possible changes in the configuration of interfaces, information diffusion. Convergence is achieved when all nodes are informed of the new status and have adapted their configuration accordingly. A possibly good indicator can be the amount of additional messages induced by the event. When the emission of such messages ceases, one can consider convergence is reached. Convergence time is the time between the event and convergence. If this time is infinite, convergence is never reached. In some cases, this could induce instability or even collapse of the network. 3.4.2 Measurement More practically, as the evaluated mechanism must adapt the routing protocol to the changing environment, the responding times of the autoconfiguration mechanism must be shorter than the characteristic times for network changes, whatever their nature, for instance topology changes or incoming new nodes. Measures must take into Clausen, et al. Expires January 12, 2006 [Page 11] Internet-Draft AUTOCONFCRITERIA July 2005 account different characteristic times. For instance, the configuration of a network from scratch matches the lifetime of a network and the convergence time should be much shorter than the lifetime. The configuration of a new incoming node can be considered as an event regarding topology. The time of this process must not exceed much the time needed by topology information sharing, i.e. a few control messages. All needed times must be measured and compared to their expected value: bootstrap time, address assignment time, merger time and address conflict resolution time for instance. 3.4.3 Evaluation This criterium is relevant for all functionalities and is of prime importance. A system with an infinite or very long convergence time is at best useless and can even be harmful in some cases. 3.5 Address Space Usage 3.5.1 Presentation In the stateful case, a network is mostly assigned a specific address space among which addresses can be picked and assigned to nodes. As the number of available addresses can be little larger than the number of possible nodes, it is important that no possible addresses should be wasted. Wasted addresses are addresses that have not been assigned and that cannot be assigned to requesting nodes due to the design of the evaluated mechanism. From this point of view, two different approaches can be used to assign addresses to incoming nodes. Address ranges can be assigned to different consistent parts of the network, each one responsible for its own address domain. This will be called local responsability. The other approach is to keep addresses common. Each new node must upon configuration advertise its choice to the whole network. This is global responsability. Global responsability implies a good information exchange. Local responsability requires an additional system to exchange addresses should an important need be felt in a part of the network. 3.5.2 Measurement This criterium must be evaluated mainly theoretically especially in the case of local responsibility: idle addresses must not be blocked by some nodes while other nodes lack addresses. It is relevant for all functionalities and must be evaluated in each of them. It can be detected in simulations and experiments through an analysis of the Clausen, et al. Expires January 12, 2006 [Page 12] Internet-Draft AUTOCONFCRITERIA July 2005 addresses that nodes can get hold on and assign. This is more difficult an evaluation. 3.5.3 Evaluation This criterium is important in networks that are assigned a short range of addresses, as well as in large and dense networks. If too many addresses are wasted by the autoconfiguration mechanism, such that all idle and accessible addresses are in use, an incoming node cannot be granted an address. This invalidates many of the functionalities. 3.6 Saturation point: multiple concurrent conflicts 3.6.1 Presentation Usual mechanisms are primarily designed to handle one situation at once. For instance, the traditional situation for duplicate addresses is one case at a time with several nodes bearing the same address. But cases with several concurrent conflict are likely to occur. Hence the need to assess the performance of the functionalities of an autoconfiguration mechanism in situations where several conflicts occur concurrently. A merger of two networks of the same size with as many collision as the number of nodes in both is a complex case as it also involves the possible destruction of the whole structure of the network through reconfiguration for instance. 3.6.2 Measurement Theoretically, the mechanism must be conceived so that multiple concurrent problems can be resolved. Experiments and simulations are good approaches to evaluate this criterium. Scenarios with several concurrent conflicts can be staged directly. Saturation point must be determined using the fact that around this point, either convergence time becomes infinite, or large, or odd phenomena occur. 3.6.3 Evaluation This criterium allows a good evaluation of mechanisms. Solving more complex situations with several conflicts indicates a well designed mechanism. Moreover, concurrent conflicts are very likely to occur and must therefore be treated by an autoconfiguration mechanism. 3.7 Saturation point: conflict size Clausen, et al. Expires January 12, 2006 [Page 13] Internet-Draft AUTOCONFCRITERIA July 2005 3.7.1 Presentation The symmetric of the previous criterium is the size of conflicts. Usual address collisions concern 2 nodes bearing the same address. However, cases with more colliding nodes can occur. Usual mergers involve 2 networks. However larger problems can happen with 3 or more independent networks. Mobility for instance can make more than two networks reunite at the same time with possibly big conflicts involving at least as many protagonists as the number of connecting networks. Therefore, a serious mechanism must handle larger problems than the basic 2 protagonist problem. 3.7.2 Measurement Theoretically, the mechanism must be conceived so that multiple protagonist problems can be resolved. Experiments and simulations are a good approach to evaluate this criterium. Scenarios with large conflicts can be staged directly. The saturation point must be determined using the fact that around this point, either convergence time becomes infinite, or large, or odd phenomena occur. 3.7.3 Evaluation This criterium allows a very efficient evaluation of mechanisms. Solving situations with big conflicts indicates a well designed mechanism. Big conflicts can happen and if a network is blocked in such a case, this will cause problems. 3.8 Scalability 3.8.1 Presentation An ideal autoconfiguration mechanism should be applicable to networks of any size. However, as such a mechanism generates overhead to the nodes as well as to the medium, scalability limitations should be evaluated. Information diffusion also suffers from a large size as the diffusion delay can increase such that information arrives at a node from distant parts of the network with a long delay. In such cases, DAA and DAD become uncertain processes if timeout times are not adapted. 3.8.2 Measurement The limit of the autoconfiguration mechanism is the number of nodes Clausen, et al. Expires January 12, 2006 [Page 14] Internet-Draft AUTOCONFCRITERIA July 2005 beyond which either the network collapses or the mechanism becomes so slow it is not functional anymore. This limit can be a range of values according to situations. The higher the limit, the better the mechanism can be considered. As routing protocols have similar limits, if the limits of the autoconfiguration mechanism and of the routing protocol are approximately the same, one can consider the autoconfiguration mechanism is well designed. This matter can be decided theoretically mainly through an analysis of the induced medium overhead. It can be evaluated experimentally and through simulations. To achieve this, scenarios with various sizes and various densities must be tested to determine the domain of correct functioning. 3.8.3 Evaluation Scalability is one of the most important criteria. A comprehensive mechanism applicable to ten nodes at most is mostly not preferred. The domain of correct functioning is a premiere feature of a mechanism. Clausen, et al. Expires January 12, 2006 [Page 15] Internet-Draft AUTOCONFCRITERIA July 2005 4. Usability Criteria Usability criteria aim at characterizing the way the mechanism will be adapted to its use. This means the adaptability to the whole environment including users and other protocols. 4.1 Simple Prerequisites 4.1.1 Presentation All mechanisms are based on assumptions that must be specified and should aim at being as general as possible to allow a widespread implementation. 4.1.2 Measurement This criterium consists in a theoretical assessment of the assumptions upon which the mechanism is based. 4.1.3 Evaluation This criterium indicates whether a mechanism is useful, i.e. whether it is worth implementing. If the prerequisites are too strict, interest is greatly diminished. 4.2 User Interventions 4.2.1 Presentation As an autoconfiguration system aims at automatically managing and configuring addresses, its design must make it user independent, i.e. should allow its correct functioning without any user intervention. There should never be situations when nodes are blocked without any access to the network. Errors should be handled automatically. 4.2.2 Measurement This criterium can be theoretically evaluated. If a situation has no adequate specified treatment, unresolved problems can occur. Simulations and experiments with detection of unresolved problems can also be very helpful to perform the evaluation of a mechanism through this criterium. This approach assumes the definition of a problem detection system especially in a simulation environment. Clausen, et al. Expires January 12, 2006 [Page 16] Internet-Draft AUTOCONFCRITERIA July 2005 4.2.3 Evaluation This criterium is based on the assumption that the user will want to have to perform as few maintenance operations as possible. This is not always the case. However, a mechanism allowing a very low user intervention can have modes with additional controls available and therefore be adaptable to all degrees of wishes from the point of view of user intervention. 4.3 Interoperability 4.3.1 Presentation In fact, an ideal autoconfiguration system should both allow user- free configuration and manual configuration. An autoconfiguration system should also be able to comply to different environments such as networks totally lacking infrastructure and more centralized networks, with servers providing a stable resource. For instance, a DHCP server or a gateway to the internet. An autoconfiguration system should be able to carry out all the address management tasks while tolerating user interventions. For instance, an autoconfiguration mechanism designed to assign addresses to incoming nodes in a network should additionaly be able to handle manually configured nodes. Adaptability is the key goal here. Additionally, it can be required of an autoconfiguration mechanism that it allows the use of completely different mechanisms such as stateless IPv6 autoconfiguration mechanism. 4.3.2 Measurement Scenarios with mixed nodes, implementing several protocols can be staged to test such a criterium. 4.3.3 Evaluation Interoperability can be the key to a successful deployment of such a mechanism as the MANETs implementing it are likely to encounter environments implementing different protocols. 4.4 Independence from the routing protocol 4.4.1 Presentation A good autoconfiguration mechanism should be based on as few assumptions as possible, allowing its applicability on a large variety of routing protocols. An autoconfiguration Clausen, et al. Expires January 12, 2006 [Page 17] Internet-Draft AUTOCONFCRITERIA July 2005 mechanism should consist in a series of guidelines applicable to a whole class of routing protocols. Implementations would slightly differ due to differences between protocols but those differences should not be more than optimizations. 4.4.2 Measurement This criterium has a theoretic basis. If a mechanism uses features of a routing protocol as its core, it cannot be adapted easily to another routing protocol. 4.4.3 Evaluation This criterium is not essential. However it characterizes a degree of universality of the considered mechanism. This is to be taken into account when comparing 2 different mechanisms. It is obvious that a mechanism well rated according to all other criteria but limited in its use to one single routing protocol will not be as widely used as the one complying to this particular criterium. 4.5 Simplicity 4.5.1 Presentation To ensure an actual implementation of a mechanism can be performed simplicity remains a key criterium. Algorithms must not be too complex, nor involve computations whose termination is not guarantied. Complex semantic analyses should not be necessary to efficiently fulfill the goal of an autoconfiguration mechanism. 4.5.2 Measurement Specifications should fit in a few pages and the mechanism must be easy to test and deploy. 4.5.3 Evaluation Non terminating algorithms are useless in real systems and too complicated a specification makes it difficult to properly implement and even evaluate a mechanism. Clausen, et al. Expires January 12, 2006 [Page 18] Internet-Draft AUTOCONFCRITERIA July 2005 Authors' Addresses Thomas Heide Clausen LIX, Ecole Polytechnique, France Phone: +33 6 6058 9349 Email: T.Clausen@computer.org URI: http://www.lix.polytechnique.fr/Labo/Thomas.Clausen/ Julien Garnier LIX, Ecole Polytechnique, France Email: Julien.Garnier@polytechnique.org Shubhranshu Singh Samsung AIT, South Korea Phone: +82 10 2799 8296 Email: shubranshu@gmail.com Christopher Baesystems, UK Email: chris.dearlove@computer.org Clausen, et al. Expires January 12, 2006 [Page 19] Internet-Draft AUTOCONFCRITERIA 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. Clausen, et al. Expires January 12, 2006 [Page 20]