Manet Working Group K. Kuladinithi INTERNET DRAFT N. A. Fikouras Expires: November 2004 C. Goerg ComNets-ikom, Uni. Bremen May 2004 Filters for Mobile Ad hoc Networks (NOMADHOC) draft-nomadhoc-manet-filters-01.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 obsolete 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. Abstract Filters for Mobile Ad hoc networks (NOMADHOC) introduces a set of extensions applicable to a range of on-demand ad hoc networking protocols that allow an ad hoc node to distribute its active flows across multiple routing paths. These extensions are based on the filter structure defined in NOMAD to enable a filtering behavior at the originator and the destination nodes. NOMADHOC Expires November 2004 1 Internet Draft Filters for Mobile Ad hoc Networks May 2004 Table of Contents 1 Introduction 3 2 Terminology 3 3 NOMADHOC Protocol Overview 4 3.1 Ad hoc On-Demand Distance Vector (AODV) routing protocol 4 3.1.1 AODV Control messages 4 3.1.3 Applying Filters 6 3.1.4 Model of operations 7 3.1.5 Backward compatibility with RFC 3561 and aodv-bis 8 3.2 DSR (Dynamic Source Routing) 9 4. NOMADHOC Extensions 9 4.1 Behavior Aggregate Filters (BAF) Extension 10 4.2 Protocol Extension 11 4.3 Source Port Extension 11 4.4 Source Port Range Extension 11 4.5 Destination Port Extension 12 4.6 Destination Port Range Extension 12 4.7 Control extensions 13 References 13 A. Changes from Previous Versions 14 Authors' Addresses 14 Intellectual Property Statement 14 NOMADHOC Expires November 2004 2 Internet Draft Filters for Mobile Ad hoc Networks May 2004 1 Introduction Filters for mobile ad hoc networks (NOMADHOC) enables the distribution of IP flows across multiple ad hoc paths with the help of a subset of NOMAD filters [2,3]. The proposed solution is general and as such, is applicable to a range of ad hoc routing protocols. Filters for mobile ad hoc networks (NOMADHOC) provides extensions that enable ad hoc nodes to associate flows with specific ad hoc paths during the route discovery process. In this manner, each flow will be routed over an ad hoc path until either the flow is terminated or the path ceases to exist. The association of flows and paths takes place with the help of Filters. The base specification of ad hoc routing protocols such as DSR[4] and TORA[5]) provide a built-in capability for the discovery of multiple routing paths. In contrast, AODV[6] or aodv-bis [9] keeps only a single routing path between the originator and the destination. This draft explains the way by which Filters can be associated with different discovered ad hoc paths between the originator and the destination, in order to distribute flows or packets of a flow among them. These Filters are composed by criteria predicates such as protocol number, port number, etc. that are meant to identify one or more flows. The rules by which an originating node decides on the set of Filters are considered beyond the scope of this document. It can be a consideration of parameters like number of hop counts, RTT etc. This draft introduces the `Fþ bit to the controlling messages of ad hoc protocols. This bit, when set, informs the originator and the destination that NOMADHOC extensions are applicable and to cater for holding distinct multiple routing paths between the end nodes and to distribute flows based on the defined filters. Section 3 of this document explains how filters for mobile ad hoc networks (NOMADHOC) is applied for different ad hoc protocols and section 4 explains the filtering extensions used. 2 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. This document uses the following terms: Default Filter (DF) A special Filter applicable for all flows not matching any other Filter. It is defined with the lowest index number of zero. Destination NOMADHOC Expires November 2004 3 Internet Draft Filters for Mobile Ad hoc Networks May 2004 As defined in (6) Filter (FL) As defined in (2) Filter Module (FM) As defined in (2) FRREQ AODV RREQ signaling with F bit on. FRREP AODV RREP with the F bit on Filter Request (FREQ) Message that has Filter declaration Originating node As defined in (6) Distinct routing Path Path between the originator and the destination without any common node 3 NOMADHOC Protocol Overview This section provides an overview of how filters for ad hoc networking protocols can be realized for various on-demand ad hoc routing protocols. 3.1 Ad hoc On-Demand Distance Vector (AODV) routing protocol NOMADHOC is applicable for AODV only when the originator maintains distinct multiple routing paths to the same destination. These routing paths can be maintained through one interface or through multiple interfaces at both originator and the destination. 3.1.1 AODV Control messages The `Fþ bit is introduced in the RREQ and RREP. It notifies all originator and destination AODV nodes that they should deploy the NOMADHOC extension. NOMADHOC Expires November 2004 4 Internet Draft Filters for Mobile Ad hoc Networks May 2004 The format of the RREQ Control Message of AODV is as follows [9]: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |D|G|F| Reserved | Hop Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RREQ ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originator IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originator Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Path Node IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Path Node Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Additional node ip address and seq. number pairs) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ F When set, the destination node MUST keep each reverse route to different next hops as defined in section 3.1.2.1. Both F & D bits MUST be set together. The format of the RREP Control Message of AODV is as follows [6]: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |A|F|Reser |APN Cnt |Prefix Sz| Hop Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originator IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Path Node IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Path Node Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Additional node ip address and seq. number pairs) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ F When set, the originating node MUST process each RREP forwarded by different next hop as defined in 3.2.1.2. NOMADHOC Expires November 2004 5 Internet Draft Filters for Mobile Ad hoc Networks May 2004 The format of the FILTER-REQUEST Message: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |F| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Filter Extensions | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ F When set, both the destination and the originating nodes SHOULD process filtering extensions attached as explained in section 3.1.3. FILTER-REQUEST is an unicast message over a discovered routing path 3.1.2 Enabling Multiple routing Paths This section explains only the changes made to the base specification of AODV protocol[9] during the route discovery process for the discovery of distinct multiple routing paths between the originator and the destination. 3.1.2.1 Processing of FRREQ The originator MUST set both F & D bits of RREQ (FRREQ). Then FRREQ is sent as defined in [9]. Intermediate node MUST process FRREQ as defined in [9]. The destination node MUST process FRREQ received by different previous hops separately. 3.1.2.4 Processing of FRREP The destination node MUST generate a RREP with F bit set (FRREP). If FRREQs come from different hops, the destination node generates multiple FRREPs that are in turn unicasted to the hop from which the FRREQ was received. Intermediate nodes receiving a FRREP MUST process them as defined in [6]. The originating node MUST process different FRREP received by different intermediate nodes separately. 3.1.2.5 Processing of FREQ When receiving FRREP, originating node MUST send FREQ with Filtering extensions. The originating node MUST unicast FREQ for each FRREP received from distinct nodes. Each intermediate node SHOULD forward over appropriate routing path to the destination node. The destination node MUST process the filtering extensions as defined in section 3.1.3, when receiving FREQ. 3.1.3 Applying Filters An originating node receiving multiple FRREPs SHOULD send respond with a separate FREQ. Each FREQ May containing a different set of filtering extensions. Formats of the filtering extensions are defined in section 4. NOMADHOC Expires November 2004 6 Internet Draft Filters for Mobile Ad hoc Networks May 2004 A Filter is consisted of one or more Filter Modules and is terminated by a Filter Control Extension. A Filter Module defines one single filtering criteria. There is an AND relationship between Filter Modules of the same Filter. In order for a flow to match a Filter, it is required to qualify for all of the Filter Modules contained in the Filter. Filter management is performed with the help of the Filter Control Extension. It contains a FilterËs Index and a Weight field. The Index identifies a Filter for a given node uniquely while the Weight field indicates the relative amount of traffic for which a Filter is applicable. When a destination is processing a FREQ sent by an originating node, it is required to associate the contained Filters with the acknowledged AODV path. Both originating and destination nodes SHOULD keep a routing entry associated with the filters defined in section 4. Filters are associated with the different next hops of each routing path. When sending a packet by an originating node or a destination node, it is required to identify whether the packet matches any of the Filters associated with the routing entry. If a matching routing entry is found, then the packet is forwarded to the respective next hop with respect to its Weight value. For a unique filter identified by an Index number, Weight value is irrelevant and whole of the flow is forwarded to the respective next hop. If filters refer to a single flow, then packets of the flow are distributed between the multiple routing paths with respect to the Weight value of each Filter. If no matching Filter is found then the packet is handled as indicated by the Default Filter. The Flows that are originated after setting filters and do not have matching filter also take the default routing path. Each Filter remains valid for the lifetime of the corresponding routing path. The Default Filter SHOULD always be defined with the index number of zero. Any source or originating node that maintain default filter extensions SHOULD always set one routing path as default. In case of invalidating the default routing path, the node SHOULD define a default filter for an existing valid path of the destination. 3.1.4 Model of operations Figure 1 illustrates an example of multiple physical paths between the originating and the destination nodes (S,D). In the beginning, node S initiates a route discovery process as defined in section 3.1.2 to determine available paths to D. Eventually two physically separated routing paths between S & D will be discovered. i.e, Path 1: via P & Q; Path 2: via T, R, W & X NOMADHOC Expires November 2004 7 Internet Draft Filters for Mobile Ad hoc Networks May 2004 S | +-------+ | | +------+ | | | | | P | +--------+ | / | | T | | / | | / \ | | Q | | / U | | \ | |R \ | | \ | | \ V| | \ | | \ / | +------+ | \ / | | | W | | | | | | | X | | +--------+ | | +-------+ | | D Figure 1 Physical connection between S & D In figure 1, initially S broadcasts a single FRREQ that propagates towards D over two physically different paths. Between nodes T and W exists an additional sub-path, which is ignored. D responds to the receipt of two identical FRREQs over nodes Q and W with the unicast transmission of two FRREPs to S. The receipt of two identical FRREPS at node S over P and T will acknowledge the existence of two physically different paths between S and D. Finally, S responds with the transmission of two unicast FREQs containing the Filters to be used for each path. The Filters will get applied at node S, who is also the initiator of the flows. When returning traffic the reverse Filters should be applied at the node D. Assuming that S maintains two active flows denoted with `aþ and `bþ. Figure 2 shows the flow distribution applied as requested by S. (S sends the flow `aþ over the shortest delay path of 1, while flow `bþ is sent over the other path of 2). This example shows the distribution of 2 flows, over the 2 distinct routing paths available. For the same example, a single flow MAY also be distributed with respect to the Weight value. The extensions presented in this document do not provide any restriction as to how many distinct routing paths that an originating node SHOULD maintain. 3.1.5 Backward compatibility with RFC 3561 and aodv-bis If the RREQ and RREP do not have the F flag set, the processing of the RREQ, RREP and RREP-ACK is same as [6] and [9]. NOMADHOC Expires November 2004 8 Internet Draft Filters for Mobile Ad hoc Networks May 2004 S |a aaa|bbb a+-------+b a| |b +------+ |b | P | +--------+ | a/ | | T | |a/ | | b/ \ | | Q | |b/ U | |a\ | |R \ | | a\ | |b\ V| | a\ | | b\ / | +------+ | b\ / | a| | W | a| | b| | a| | X | a| +--------+ a| |b a+-------+b aaa |bbb a| b| D Figure 2 distributions of flows 3.2 DSR (Dynamic Source Routing) As defined in [4], DSR has a built-in capability to keep multiple routing paths between the destination and the originating node in its routing cache. The filtering extensions defined in section 4 can be applied for DSR too to distinguish flows between available paths, when choosing the particular route. This can be done by sending FREQ after discovering distinct routing paths. 4. NOMADHOC Extensions In this section, the new NOMADHOC extensions required for the support of Filters for ad hoc networking are specified. To form a valid Filter, at least one of the extensions 1 to 6, termed as Filter Modules, must be included. Extension 7 must appear once in every Filter following all Filter Modules. In Filter modules, the leftmost bit of the Sub-Type field (I bit) is used to determine whether the rules included in the Filter Module are positive or negative. In the first case a flow is required to match exactly the Filter Module while in the second, the inverted (NOT) rule. Due to the †IË bit in the Sub-Type field, two different Sub- Type values are given. NOMADHOC Expires November 2004 9 Internet Draft Filters for Mobile Ad hoc Networks May 2004 1. Behavior Aggregate Filters Extension (BAF) Specifies to Filters data packets dependent of the content of the DSCP field. 2. Protocol Extension Specifies one or more protocols to be filtered. 3. Source Port Extension Specifies one or more source ports to be filtered. 4. Source Port Range Extension Specifies one or more ranges of source ports to be filtered. 5. Destination Port Extension Specifies one or more destination ports to be filtered. 6. Destination Port Range Extension Specifies one or more ranges of destination ports to be filtered. 7. Filter Control Extension It contains a FilterËs unique identifier, called the Index along with the FilterËs Weight factor. 4.1 Behavior Aggregate Filters (BAF) Extension 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |I| Sub-Type | DSCP |RSV| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type The type, which describes a collection of extensions having a common data type. (To Be Defined). Length (N+1), where N is the number of DSCP entries Sub-Type 0 for given predicates, 128 for inverted predicates. DSCP Differentiated Services Code Point [8] NOMADHOC Expires November 2004 10 Internet Draft Filters for Mobile Ad hoc Networks May 2004 4.2 Protocol Extension 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |I| Sub-Type | Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type The type, which describes a collection of extensions having a common data type. (To Be Defined). Length (N+1), where N is the number of Protocol fields Sub-Type 1 for given predicates, 129 for inverted predicates Protocol Identifies the next level protocol used in the data portion of the internet datagram. The values for various protocols are specified in [7]. 4.3 Source Port Extension 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |I| Sub-Type | Source Port +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Source Port | +-+-+-+-+-+-+-+-+ Type The type, which describes a collection of extensions having a common data type. (To Be Defined). Sub-Type 2 for given predicates, 130 for inverted predicates. Length (2*N +1), where N is the number of port entries. Source Port Identifies the source port number contained in the IP header of a packet. 4.4 Source Port Range Extension 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |I| Sub-Type |Source Port Min +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Cont | Source Port Max | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type The type, which describes a collection of extensions having a common data type. (To Be Defined). Sub-Type 3 for given predicates, 131 for inverted predicates. NOMADHOC Expires November 2004 11 Internet Draft Filters for Mobile Ad hoc Networks May 2004 Length (4*N+1), where N is the number of port range entries. Source Port Number Min Defines the start point of a range of source port numbers. Source Port Number Max Defines the end point of a range of source port Numbers. 4.5 Destination Port Extension 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |I| Sub-Type | Dest Port +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Continue | +-+-+-+-+-+-+-+-+ Type The type, which describes a collection of extensions having a common data type. (To Be Defined). Sub-Type 4 for given predicates, 132 for inverted predicates. Length (2*N+1), where N is the number of port entries Destination Port Identifies the destination port number contained in the IP header of a packet. 4.6 Destination Port Range Extension 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |I| Sub-Type | Dest. Port Min +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Cont | Dest. Port Max | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type The type, which describes a collection of extensions having a common data type. (To Be Defined). Sub-Type 5 for given predicates, 133 for inverted predicates. Length (4*N+1), where N is the number of port range entries Destination Port Number Min Defines the start point of a range of destination port numbers Destination Port Number Max Defines the end point of a range of destination port numbers NOMADHOC Expires November 2004 12 Internet Draft Filters for Mobile Ad hoc Networks May 2004 4.7 Control extensions 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Index | Weight | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type The type, which describes a collection of extensions having a common data type. (To Be Defined). Length 2. Index FilterËs index number Weight Relative amount of traffic for which forwarding Filter is applicable References [1] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. RFC 2119, IETF, March 1997. [2] N. A. Fikouras, A. Udugama, C. G•rg, W. Zirwas, and J. M. Eichinger. Filters for Mobile IP Bindings (NOMAD). Internet Draft, draft-nomad-mobileip-filters-04.txt, Work in Progress, July 2003. [3] K. Kuladinithi, N. A. Fikouras, and C. G•rg. Filters for Mobile IPv6 Bindings (NOMADv6). Internet Draft, draft-nomadv6- mobileip-filters-00.txt, Work in Progress, July 2003. [4] David B. Johnson, David A. Maltz and Yih-Chun Hu. The Dynamic Source Routing Protocol for Mobile Ad Hoc Networks (DSR). Internet Draft, draft-ietf-manet-dsr-09.txt, Work in Progress, April 2003. [5] V. D. Park and M. S. Corson, †A highly adaptive distributed routing algorithm for mobile wireless networks,÷ Proceedings of IEEE INFOCOMË97 Conf., April 1997. [6] C. Perkins, E. Belding-Royer and S. Das. Ad hoc On-Demand Distance Vector (AODV) Routing, RFC 3561, IETF, July 2003. [7] Postel, J. Internet Protocol. STD 5, RFC 791, IETF, September 1981. [8] K. Nichols, S. Blake, F. Baker, and D. Black. Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers. RFC 2474, IETF, December 1998. [9] C. Perkins, E. Belding-Royer and Ian D. Chakeres. Ad hoc On-Demand Distance Vector (AODV) Routing, draft-ietf-manet- aodvbis-00.txt, IETF, October 2003. [10] J. Reynolds and J. Postel. Assigned Numbers. Request for Comments 1700, STD 2, IETF, October 1994. NOMADHOC Expires November 2004 13 Internet Draft Filters for Mobile Ad hoc Networks May 2004 A. Changes from Previous Versions The following updates and changes were made in this version of the filters for Mobile Ad hoc networks draft, compared to earlier versions. A.1. Updates from version 00 Introduce Filter Request (FRREQ) format to attach filter extensions instead of piggybacked with RREP-ACK message. Now, threre is no need to set both `Fþ and `Aþ bits together. Change section 3.1 to cater for the aodv-bis draft. FREQ and FREP message formats have been changed. Clarify that which flows SHOULD take the default path as defined by default filter. Explain operations, when the path associated with the default filter is invalid. Editorial changes. Authors' Addresses Koojana Kuladinithi Department of Communication Networks (ComNets) Center for Information and Communication Technology (ikom) University of Bremen Phone: +49-421-218-8264 D-28219 Bremen, Germany Email: koo@comnets.uni-bremen.de Niko A. Fikouras Departmnt of Communication Networks (ComNets) Center for Information and Communication Technology (ikom) University of Bremen Phone: +49-421-218-3339 D-28219 Bremen, Germany Email: niko@comnets.uni-bremen.de Carmelita Goerg Department of Communication Networks (ComNets) Center for Information and Communication Technology (ikom) University of Bremen Phone: +49-421-218-2277 28219, Bremen, Germany Email: cg@comnets.uni-bremen.de Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and NOMADHOC Expires November 2004 14 Internet Draft Filters for Mobile Ad hoc Networks May 2004 standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION NOMADHOC Expires November 2004 15