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. Grg, 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. Grg. 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