Network Working Group J. Macker, editor Internet-Draft NRL Expires: December 3, 2005 SMF. Design Team IETF June 2005 Simplified Multicast Forwarding for MANET draft-ietf-manet-smf-00.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 December 3, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes the Simplified Multicast Forwarding (SMF) protocol that provides a basic IP multicast forwarding capability within mobile ad-hoc networks. While it supports edge interoperability with a conventional IP multicast infrastructure, SMF is designed to have limited applicability as a forwarding mechanism for multiple hop multicast packets within MANET routing areas. SMF uses a simplified forwarding mechanism that delivers multicast Macker, editor & Design Team Expires December 3, 2005 [Page 1] Internet-Draft SMF for MANET June 2005 packets to all MANET multicast receivers within a MANET routing area. The core design does not use group and membership specific information in favor of reduced complexity and state maintenance within the mobile topology region. The design accounts for the unique nature and behavior of MANET interfaces and takes advantage of particular efficient relay set algorithms previously designed and applied in the MANET routing designs. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Overview of Applicability . . . . . . . . . . . . . . . . 3 2. SMF Design Considerations . . . . . . . . . . . . . . . . . . 5 2.1 Previous Related Work . . . . . . . . . . . . . . . . . . 6 2.2 Core Requirements of an SMF Implementation . . . . . . . . 6 3. SMF Packet Processing and Forwarding . . . . . . . . . . . . . 7 4. SMF Duplicate Packet Detection . . . . . . . . . . . . . . . . 9 4.1 SMF IPv4 Duplicate Packet Detection . . . . . . . . . . . 10 4.2 SMF IPv6 Duplicate Packet Detection . . . . . . . . . . . 11 4.3 IPv6 SMF-DPD Header Option Format . . . . . . . . . . . . 11 5. Efficient Relay Set Mechanisms . . . . . . . . . . . . . . . . 12 5.1 MPR Forwarding Operation . . . . . . . . . . . . . . . . . 12 5.2 E-CDS Forwarding Operation . . . . . . . . . . . . . . . . 13 6. SMF Multicast Border Gateway Considerations . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9.1 Normative References . . . . . . . . . . . . . . . . . . . 17 9.2 Informative References . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . 19 Macker, editor & Design Team Expires December 3, 2005 [Page 2] Internet-Draft SMF for MANET June 2005 1. Introduction Design and implementation progress has been made in developing and implementing more efficient ways to flood control packets within MANET wireless routing protocol designs. Example algorithms within [RFC3626] and [RFC3684] specify distributed methods of dynamically electing reduced relay sets for the purposes of optimized flooding of specific control packets to all MANET nodes. In this document, we specify the Simplified Multicast Forwarding (SMF) protocol. The main purpose of SMF is to adapt efficient flooding designs in MANET environments and apply such design mechanisms at the native multicast IP forwarding level. SMF makes a simple form of multicast forwarding available to user space data flows within a MANET routing area. This is applicable when efficient flooding is sufficient as compared to full, group and membership- based multicast routing. The SMF baseline design limits its scope to basic best effort multicast forwarding and its applicability is intended to be constrained within a MANET routing area. A multicast border gateway mechanism or configuration approach is needed to interoperate with other IP multicast routing in the wired world (e.g., PIM gateway). Although SMF may be extended or combined with other protocol layers to provide increased reliability and group specific forwarding state those methods will be discussed in other documents. 1.1 Terminology MANET : Mobile Ad hoc Networks SMF : Simplified Multicast Forwarding CF : Classical Flooding CDS : Connected Dominating Set MPR : Multi-point Relay 1.2 Overview of Applicability A basic packet forwarding service that reaches all destinations participating within a MANET environment can be a useful generic routing mechanism for an application layer. While the design requirements for such a forwarding mechanism are similar to those often needed in the control plane by many MANET unicast routing protocol layers, it is desirable to provide a more generic forwarding Macker, editor & Design Team Expires December 3, 2005 [Page 3] Internet-Draft SMF for MANET June 2005 function for use by other applications. There are a number of application areas that could take advantage of a simple, broadcast- type delivery service within a MANET routing region (e.g., multimedia streaming, peer-to-peer middleware multicasting, MANET auto- configuration, and discovery services). Macker, editor & Design Team Expires December 3, 2005 [Page 4] Internet-Draft SMF for MANET June 2005 2. SMF Design Considerations The simplest design often conceived and adapted for MANET packet flooding is something we designate as the classical flooding (CF) algorithm. In CF, each participating forwarder node is required to rebroadcast packets intended for dissemination once and only once. This approach is extremely simple and generally only requires some means of duplicate packet detection and a basic forwarding mechanism. However, it is well known that using CF results in a significant number of redundant transmissions often referred to as the broadcast storm problem [NTSC99]. For example, reducing unnecessary channel contention within a MANET significantly improves network performance. Unlike wired network hardware, direct contention and interference is experienced beyond the single hop physical interface. Therefore, reducing the number of required relay nodes is an important design goal for this environment. Unfortunately, reducing the number of relay nodes in a MANET environment may also decrease the robustness of overall packet delivery. There exists an interdependent design trade-off between relay efficiency and delivery robustness that is scenario and system dependent and should be considered carefully in any pragmatic design. If needed, additional reliability mechanisms MAY be considered for use with reduced relay sets. A design goal of SMF is support CF-based forwarding and to support reduced relay set algorithms for increased efficiency. At a theoretical level, work in the area of minimizing packet forwarders, or relay node sets, is often related to basic graph theory problems. In graph theory, a dominating set (DS) for a graph is a set of vertices whose neighbors, along with themselves, constitute all the vertices in the graph. A connected DS (CDS) is a DS forming a connected graph. A minimum CDS (MCDS) is a set such that the number of vertices is the minimum required to form a CDS. Finding a small dominating set is one of the most fundamental problems of traditional graph theory and is in theory often related to the problem of optimizing flooding algorithms in MANETs. Finding an MCDS in a given graph is known to be NP-hard [GJ79]. Beyond these basic static graph theoretic issues, MANET protocol designs require more distributed and dynamic operation. To better explain the design requirement, we formulated the following characteristics desired of an effective MANET flooding algorithm solution for use in SMF: 1. A resultant cover set that is small compared to the total number of nodes as the network scales in size and density. 2. A robust approach somewhat resilient to network mobility and link dynamics. Macker, editor & Design Team Expires December 3, 2005 [Page 5] Internet-Draft SMF for MANET June 2005 3. A cover set election/maintenance mechanism that is lightweight, distributed, and adaptive in nature. 2.1 Previous Related Work Previous novel work on MANET flooding and reduced relay set mechanisms has been done and this document borrows and builds off of previous work accomplished. In [WC02], a broad taxonomy of flooding algorithms for use in MANET environments was presented and the work examined performance issues related to various approaches. Other important work has developed distributed mechanisms that select and maintain reduced relay node sets. As we have already mentioned, the design trade-offs are further complicated by wireless contention, topological classes, and mobility scenarios as considerations. In addition, implementation of IP multicast forwarding based upon these flooding algorithms raises additional design trade-offs and issues. This includes maintenance of protocol state, duplicate packet detection mechanisms, and any possible protocol signaling support required by a mechanism. 2.2 Core Requirements of an SMF Implementation Here we outline the core requirements being targeted by the SMF specification. SMF is being designed to support both IPv4 and IPv6 MANET multicast forwarding capability. The fundamental requirements of the SMF implementation are: The SMF protocol MUST be capable of processing and potentially forwarding multicast packets both generated locally on a MANET node and those received on an active MANET interface. SMF MUST ignore multicast packets intended for link-local use. SMF MUST support a MANET duplicate packet detection scheme as defined in this document (see Section 4). SMF MUST support the ability to modify its forwarding status based upon relay set information that is received dynamically during operation. SMF SHOULD support alternative relay set approaches. These mechanisms are defined separately but some basic interface functionality is defined here. Macker, editor & Design Team Expires December 3, 2005 [Page 6] Internet-Draft SMF for MANET June 2005 3. SMF Packet Processing and Forwarding The SMF Packet Processing and Forwarding actions are conducted by two possible packet handling activities: 1. Interception of outbound, locally-generated multicast packets. 2. Reception of inbound packets on a specific network interface(s). In the case that sequence-based duplicate packet detection (see Section 4) is used, the purpose of intercepting outbound, locally- generated multicast packets would be to apply resequencing of the IPv4 ID header field or add options headers as needed (e.g. IPv6). In the case that resequencing is deemed necessary, it is RECOMMENDED that sequence numbering be applied such that a sequence number space per duple is used. While, for strict SMF purposes where no distinct routing for different IP multicast address destinations occurs, it might be sufficient to use sequence number spaces aggregated across all IP multicast destinations (or across all IP destinations for a source as is the default implementation of the IPv4 ID field in many operating systems), the possibility that different destinations may be routed differently suggests "per source/destination" numbering be used. It should be noted that the default global IPv4 ID sequence space may be sufficient for some SMF deployments and interception of outbound packets may not be required. And, in other cases, such as when IPSec headers have been applied to packets, other sequence information (perhaps even "per flow") may be available for the SMF process to leverage. Inbound multicast packets will be received by the SMF implementation and processed for possible forwarding. While an SMF implementation may be designed to forward only specific IP multicast groups, SMF SHOULD in general, be capable of forwarding all groups with the following exceptions: 1. Multicast packets with TTL <= 1 MUST NOT be forwarded. 2. IPv6 Link Local multicast packets MUST NOT be forwarded regardless of TTL. 3. Multicast packets with an IP source address matching one of those of the local host interface(s) MUST NOT be forwarded. 4. MAC frames with MAC source address matching the local host interface(s) MUST NOT be forwarded. Note that exception #3 is important because in wireless networks, a Macker, editor & Design Team Expires December 3, 2005 [Page 7] Internet-Draft SMF for MANET June 2005 local host may receive re-transmissions of its own packets when they are forwarded by neighboring nodes. This exception avoids unnecessary retransmission of locally-generated packets even when other forwarding decision rules would apply. Once these criteria have been met, the implementation should reference a forwarding decision algorithm, possibly in concert with duplicate packet detection, to determine the next step in packet processing. The forwarding behavior may be implicit if the SMF implementation is configured to perform classic flooding (CF) of IP multicast packets. Otherwise, the forwarding behavior may require additional decision input. Neighborhood discovery protocols coupled with the Multi-Point Relay (MPR) or other Connected Dominating Set (CDS) selection algorithms described in Section 5 MAY be used to determine the local host's status with respect to forwarding. For example, some algorithms may require a forwarding decision be based upon the previous hop (e.g. MPR forwarding), while others may designate a forwarder of all received packets (or at least those generated by known neighbors) within a 1-hop neighborhood broadcast topology (e.g. E-CDS). Duplicate packet detection is the most challenging and complex portion of the SMF forwarding process and thus, it is RECOMMENDED as a final step when possible. In general detection of received duplicate packets to avoid forwarding the same packet multiple times is necessary. However, in some cases (e.g., MPR), duplicate detection of some non-forwarded packets is also needed to maintain efficient forwarding. Details on different duplicate packet detection and forwarding rules for CF, MPR, and E-CDS algorithms are given later (TBD). The details for these classes of algorithms may also apply to other similar algorithms. Macker, editor & Design Team Expires December 3, 2005 [Page 8] Internet-Draft SMF for MANET June 2005 4. SMF Duplicate Packet Detection An important routing design difference between MANET interfaces and many wired network interfaces is that forwarding out the same physical interface a packet arrived on is normal operation. This operation is often disallowed or discouraged in wired multicast routing designs to avoid looping. Because of this MANET interface characteristic, a fairly common requirement in MANET packet flooding is that of duplicate packet detection. While this requires increased per packet processing, it is deemed necessary in MANET-specific multicasting. This section describes a basic SMF duplicate packet detection mechanism and some alternative operational options as considerations. Detecting duplicate packets is fundamentally important in a MANET packet flooding process. SMF SHOULD implement explicit detection of duplicate multicast packets by a temporal packet identification scheme. This is typically implemented by keeping a history of previous received and forwarded packet identifiers for comparison against recently forwarded multicast packets. Implementations SHOULD also timeout stale histories for entries where new, non-duplicate packets have not been recently received. Of course, the duplicate packet detection mechanism SHOULD avoid keeping unnecessary state for packet flows such as those that are locally generated or link local destinations that would not be considered for forwarding. There are various possible approaches to packet identification. Possibilities include unique markings within packet header fields, such as packet sequence numbering, or application of hash algorithms or similar techniques to compactly and uniquely describe the history of recently received packets. This document focuses on describing simple, sequence-based schemes that can be accomplished without additional (non-IP) encapsulation of packets and/or their content. While hash-type approaches may be supportable by this specification, early examination of these approaches indicated that computation complexity may be prohibitive for per-packet processing on many candidate MANET platforms (e.g., PDAs). Additionally, the unavoidable "cache-miss" rates, while low for some traffic scenarios, result in the potential penalty of false duplicate detection (and thus packet loss) rather than the more benign penalty of additional computation cycles as associated with most applications of hashing. Additional packet encapsulation is also desired to be avoided so that non-forwarding edge nodes within a MANET area may receive flooded content without any additional software beyond that of a typical IP stack. Macker, editor & Design Team Expires December 3, 2005 [Page 9] Internet-Draft SMF for MANET June 2005 4.1 SMF IPv4 Duplicate Packet Detection The following section describes a sequence-based mechanism and options for SMF IPv4 duplicate detection. IPv4 multicast packets from a particular source are assumed to be marked with a temporally unique identification number in the IPv4 header using the ID field [RFC0791]. Unfortunately, in present operating system networking kernels, this identification number (ID) for the IP header is not always generated or applied in a consistent manner. In order to build a working implementation without encapsulating packets, SMF SHOULD provide a sequence generation and marking module that can maintain and set a monotonically increasing IP ID field for locally- generated multicast packets with independent sequence number spaces applied on a basis. When needed on a local system or at a specific gateway this process will also recalculate and replace a proper IP header checksum for the formulated header. Note that the presence of IPSec for candidate packet flows may present the opportunity to leverage the additional, perhaps more consistent, sequencing information of the IPSec header for unique packet identification. To perform duplicate detection, SMF will check the IPSec header's "sequence" field, in the context of the packet's tuple against a cache history of received packet identifiers. The IPSec security association identifier is added to the tuple since IPSec sequencing is be applied on a "per flow" basis, rather than just a source/ destination basis. In general a packet is not forwarded if a duplicate entry is found. If a duplicate is not found it will add a new identification entry to the duplicate detection cache and send the packet on to the forwarding process. Note some forwarding algorithms may require that duplicates are marked when received from neighbor nodes, even when forwarding isn't applicable. Multiple interface semantics may also add some additional considerations to the forwarding process depending upon the algorithm. Although the use of the IPv4 ID field may be useful and practical for some near-term usage, its adoption for widespread packet duplication detection has some disadvantages. The main disadvantage is that the use and interpretation of the field is known to be non-consistent across operating systems. The ID field is also of limited size and may provide less robust detection for high bandwidth applications since 16-bit sequence wrap-around may occur relatively frequently if it is not possible to achieve "per source/destination" sequencing. As an alternative, the use of a header extension or encapsulated Macker, editor & Design Team Expires December 3, 2005 [Page 10] Internet-Draft SMF for MANET June 2005 header in future implementations may provide more flexibility and consistency (see Section 4.3). Another advantage of using a header extension (or other encapsulation, if determined absolutely necessary) is that it would be possible for MANET gateway nodes to assess whether packets entering a MANET area have already been properly sequenced to avoid unnecessary re-injection of packets from networks adjacent to the MANET area. We leave these design alternatives to be further defined and discussed in future work. A basic sequencing and marking design similar to the one we formulate here can be easily adapted to work with future approaches or can be bypassed when not needed. 4.2 SMF IPv6 Duplicate Packet Detection The following section describes the mechanism and options for SMF IPv6 duplicate detection. The core IPv6 header does not provide an explicit identification header option such as the IPv4 ID field that we can exploit for DPD. SMF defines two methods for IPv6use: a hop- by-hop (HBH) DPD options header and the use of IPSec sequencing when an IPSec header is present. SMF MUST provide a DPD "sequence" marking module that can insert the HBH IPv6 header option defined for locally generated MANET multicast. If the packet is not IPSEC encapsulated, SMF will evaluate the DPD "sequence" in the context of the packet's tuple from the IPv6 header against a cached history of received IPv6 packet identifiers. The use of IPSec may prevent the intermediate addition of a hop-by- hop options header. Fortunately, IPSec headers are sequenced on a basis. The SPI field identifies the security association (SA) to which the header applies. Thus, if the packet is IPSec encapsulated, SMF MUST use the context of the and leverage the or from the IPv6 IPSec header as a packet identification method. In either case, if a duplicate is not found SMF will add a new identification entry to the duplicate detection cache and send the packet on to the forwarding process. In general, the packet is not considered a candidate for forwarding if a duplicate is detected. But multiple interface semantics may add some additional considerations to the forwarding process depending upon the forwarding algorithm. 4.3 IPv6 SMF-DPD Header Option Format (TBD) Macker, editor & Design Team Expires December 3, 2005 [Page 11] Internet-Draft SMF for MANET June 2005 5. Efficient Relay Set Mechanisms As mentioned SMF MUST support CF-based forwarding as a baseline forwarding mechanism when optimized relay set information is not available. In CF mode, each node transmits a locally generated or newly received packet exactly once. No additional information is required for SMF to perform this function. The duplicate detection technique mentioned in the previous section is critical to proper operation and avoiding any "storms" of duplicate packet retransmissions. In the core requirements section, it was stated that SMF MUST support the ability to adapt its forwarding status based upon relay set information that is received dynamically during operation. In this way SMF can provide an enhanced capability beyond CF flooding and will reduce the level of contention and congestion within the MANET multicast area. In this section we define control mechanisms and interface primitives that allow SMF to support a variety of different relay set algorithms and approaches. 5.1 MPR Forwarding Operation There has been significant MANET work and experience in using the concept of the multi-point relay (MPR) as defined in [RFC3626] for providing efficient MANET flooding. The MPR flooding mechanism is based upon the well-known MPR technique and specifies that only selected MPRs are to retransmit packets received from upstream selector nodes. It is well-known that source-specific MPRs compose a connected dominating set and using S-MPR can significantly reduce redundant retransmission of packets, especially in dense network neighborhoods [JLMV02]. An implementation disadvantage of S-MPR is that previous hop identification is required to make a proper forwarding decision. This previous hop filtering requirement adds some additional state and complexity to the design, but such algorithm types should be supportable by SMF. Without some encapsulation method, the previous hop in an IP forwarding process is only identified by the MAC source address. To work with MPR type algorithm the SMF protocol MUST obtain an MPR selector list of MAC addresses and the current one-hop neighbor list. The selector list provides the previous hop upstream neighbors for which the SMF node has been selected as an MPR. The one-hop neighbor list is required to provide discrimination of transmissions from nearby nodes which, for whatever reason (e.g. poor or intermittent link quality) were not considered neighbors in the MPR selection process. In the MPR forwarding process, if a non-duplicate packet arrives from a selector, the SMF node would perform forwarding for that packet. The SMF node SHOULD not forward packets from non-selectors, although it MUST mark duplicate detection state for packets received from valid, Macker, editor & Design Team Expires December 3, 2005 [Page 12] Internet-Draft SMF for MANET June 2005 symmetric one-hop neighbors. This additional provision avoids unnecessary redundant (possibly significant) forwarding of traffic back across portions of the network when MPR selection by neighboring nodes results in differing MPR sets. An early prototype implementation of such a MPR-based SMF capability was documented in [MDC04]. For multiple interface implementations of MPR-based SMF, additional state must be kept with respect to which incoming interface(s) on which packets in the duplicate detection history arrived. This will be further addressed in future revisions of this document and is TBD for now. 5.2 E-CDS Forwarding Operation More recently there has been interest in adapting alternative CDS algorithms for MANET flooding that do not have the previous hop dependency of the MPR algorithm. Algorithms such as an extended-CDS (E-CDS) algorithm based upon [E-CDS] provide distributed, dynamic election of reduced relay sets creating shared, non-source-specific distribution trees. If elected as a forwarder in E-CDS, the SMF node MUST forward any non-duplicate, received multicast traffic. There is no need for an explicit previous network hop identifier or selector list as in the case of MPR forwarding. Here, this type of algorithm may simplify the forwarding and processing requirements per packet. This issue will be further examined in experimentation. Macker, editor & Design Team Expires December 3, 2005 [Page 13] Internet-Draft SMF for MANET June 2005 6. SMF Multicast Border Gateway Considerations TBD Macker, editor & Design Team Expires December 3, 2005 [Page 14] Internet-Draft SMF for MANET June 2005 7. Security Considerations Gratuitous use of option headers can cause problems in routers. Routers outside of MANET routing areas should ignore SMF header options if encountered. Authentication mechanisms to identify the source of an option header should be considered to reduce vulnerability to a variety of attacks. Additional security considerations TBD. Macker, editor & Design Team Expires December 3, 2005 [Page 15] Internet-Draft SMF for MANET June 2005 8. Acknowledgments Many of the concepts and mechanisms used and adopted by SMF resulted from many years of discussion of related work within the MANET Working Group. There are obviously many people that have contributed to past side discussions and related draft documents within the IETF. In particular, the document is largely a group product of an SMF design team within the IETF MANET Working Group. SMF Design Team Contributors Thomas Clausen Charles Perkins Brian Adamson Justin Dean Ian Chakeres Chris Dearlove Emmanual Baccelli Et al The RFC text was produced using Marshall Rose's xml2rfc tool. Macker, editor & Design Team Expires December 3, 2005 [Page 16] Internet-Draft SMF for MANET June 2005 9. References 9.1 Normative References [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. 9.2 Informative References [E-CDS] Ogier, R., "MANET Extension of OSPF Using CDS Flooding", Proceedings of the 62nd IETF , March 2005. [GJ79] Garey, M. and D. Johnson, "Computers and Intractability: A Guide to the Theory of NP-Completeness.", Freeman and Company , 1979. [JLMV02] Jacquet, P., Laouiti, V., Minet, P., and L. Viennot, "Performance of multipoint relaying in ad hoc mobile routing protocols", Networking , 2002. [MDC04] Macker, J., Dean, J., and W. Chao, "Simplified Multicast Forwarding in Mobile Ad hoc Networks", IEEE MILCOM 2004 Proceedings , 2004. [NTSC99] Ni, S., Tseng, Y., Chen, Y., and J. Sheu, "The Broadcast Storm Problem in Mobile Ad hoc Networks", Proceedings Of ACM Mobicom 99 , 1999. [RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing Protocol", 2003. [RFC3684] Ogier, R., Templin, F., and M. Lewis, "Topology Dissemination Based on Reverse-Path Forwarding", 2003. [WC02] Williams, B. and T. Camp, "Comparison of Broadcasting Techniques for Mobile Ad hoc Networks", Proceedings of ACM Mobihoc 2002 , 2002. Macker, editor & Design Team Expires December 3, 2005 [Page 17] Internet-Draft SMF for MANET June 2005 Authors' Addresses Joseph Macker NRL Code 5522 Washington, DC 20375 USA Email: macker@itd.nrl.navy.mil SMF Design Team IETF Email: Macker, editor & Design Team Expires December 3, 2005 [Page 18] Internet-Draft SMF for MANET June 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. Macker, editor & Design Team Expires December 3, 2005 [Page 19]