Manet Working Group K. Kuladinithi INTERNET DRAFT N. A. Fikouras Expires: April 2004 C. G÷rg ComNets-ikom, Uni. Bremen October 2003 Filters for Mobile Ad hoc Networks (NOMADHOC) draft-nomadhoc-manet-filters-00.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 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. NOMADv6 Expires April 2004 1 Internet Draft Filters for Mobile Ad hoc Networks October 2003 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.........................8 3.2 DSR (Dynamic Source Routing)....................................9 4. NOMADHOC Extensions.............................................9 4.1 Behavior Aggregate Filters (BAF) Extension.....................10 4.2 Protocol Extension.............................................10 4.3 Source Port Extension..........................................10 4.4 Source Port Range Extension....................................11 4.5 Destination Port Extension.....................................11 4.6 Destination Port Range Extension...............................12 4.7 Control extensions.............................................12 References........................................................12 NOMADHOC Expires April 2004 2 Internet Draft Filters for Mobile Ad hoc Networks October 2003 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 seizes 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] 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. This draft further looks into ways of maintaining multiple routing paths where this feature is not supported, with minimal impact to the base specification of the respective ad hoc routing protocol 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 NOMADHOC Expires April 2004 3 Internet Draft Filters for Mobile Ad hoc Networks October 2003 zero. Destination As defined in (6) Filter (FL) As defined in (2) Filter Module (FM) As defined in (2) Filtering Route Request (FRREQ) AODV RREQ signaling with F bit on. Filtering Route Reply (FRREP) AODV RREP with the F bit on Filtering Route Reply Acknowledge(FRREP-ACK) AODV RREP-ACK with the F bit on 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 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, RREP, and RREP-ACK messages. It notifies all originator and destination AODV nodes that they should deploy the NOMADHOC extension. NOMADHOC Expires April 2004 4 Internet Draft Filters for Mobile Ad hoc Networks October 2003 The format of the RREQ 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 |J|R|G|D|U|F| Reserved | Hop Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RREQ ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originator IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originator Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 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 |R|A|F| Reserved |Prefix Sz| Hop Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originator IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ F When set, the originating node MUST process each RREP forwarded by different next hop as defined in 3.2.1.2. Both F & A bits MUST set together. The format of the RREP-ACK Control Message of AODV is as follows [6]: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |F| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ F When set, both the destination and the originating nodes SHOULD process filtering extensions attached as explained in section 3.1.3. NOMADHOC Expires April 2004 5 Internet Draft Filters for Mobile Ad hoc Networks October 2003 3.1.2 Enabling Multiple routing Paths This section explains only the changes made to the base specification of AODV protocol[6] 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 [6]. Intermediate node MUST process FRREQ as defined in [6]. 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 both F bit AND A 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 FRREP-ACK Filtering extensions MUST be attached on RREP-ACK with the F bit set (FRREP-ACK), in response to a FRREP . The originating node MUST unicast FRREP-ACK together with filtering extensions for each FRREP received from distinct nodes. Each intermediate node SHOULD process the RREP-ACK as defined in [6]. The destination node MUST process the filtering extensions as defined in section 3.1.3, when receiving FRREP-ACK. 3.1.3 Applying Filters An originating node receiving multiple FRREPs SHOULD send respond with a separate FRREP-ACK. Each FRREP-ACK May containing a different set of filtering extensions. Formats of the filtering extensions are defined in section 4. 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 FRREP-ACK sent by an originating node, it is required to associate the contained Filters with the acknowledged AODV path. Both originating and destination nodes NOMADHOC Expires April 2004 6 Internet Draft Filters for Mobile Ad hoc Networks October 2003 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. 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. 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 S | +-------+ | | +------+ | | | | | P | +--------+ | / | | T | | / | | / \ | | Q | | / U | | \ | |R \ | | \ | | \ V| | \ | | \ / | +------+ | \ / | | | W | | | | | | | X | | +--------+ | | +-------+ | | D Figure 1 Physical connections between S & D NOMADHOC Expires April 2004 7 Internet Draft Filters for Mobile Ad hoc Networks October 2003 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 FRREP-ACKs 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). 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 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 If the RREQ, RREP and RREP-ACK messages do not have the F flag set, the processing of the RREQ, RREP and RREP-ACK is same as [6]. NOMADHOC Expires April 2004 8 Internet Draft Filters for Mobile Ad hoc Networks October 2003 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. 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. 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. NOMADHOC Expires April 2004 9 Internet Draft Filters for Mobile Ad hoc Networks October 2003 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] 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 NOMADHOC Expires April 2004 10 Internet Draft Filters for Mobile Ad hoc Networks October 2003 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. 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. NOMADHOC Expires April 2004 11 Internet Draft Filters for Mobile Ad hoc Networks October 2003 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 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. NOMADHOC Expires April 2004 12 Internet Draft Filters for Mobile Ad hoc Networks October 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] J. Reynolds and J. Postel. Assigned Numbers. Request for Comments 1700, STD 2, IETF, October 1994. 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 NOMADHOC Expires April 2004 13 Internet Draft Filters for Mobile Ad hoc Networks October 2003 NOMADHOC Expires April 2004 14