INTERNET-DRAFT Philippe Jacquet
IETF MANET Working Group Pascale Minet
Expiration: 21 April 2002 Anis Laouiti
Laurent Viennot
Thomas Clausen
Cedric Adjih
INRIA Rocquencourt, France
21 November 2001
Multicast Optimized Link State Routing
draft-jacquet-olsr-molsr-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026 except that the right to
produce derivative works is not granted.
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.
1. Abstract
This document describes the Multicast extension for the Optimized
Link State Routing protocol(MOLSR). MOLSR is designed for mobile
routers, and works in a heterogenous network composed of simple OLSR
routers, MOLSR routers and hosts. In the last part of this document
we introduce also a Wireless Internet Group Management Protocol
(WIGMP). It offers the possibility for OLSR nodes (without multicast
capabilities) to join multicast groups and receive multicast data.
Jacquet, Minet, Laouiti, Viennot, Clausen and Adjih [Page 1]
INTERNET-DRAFT Multicast Optimized Link State Routing 4 August 2001
Table of Contents
1. Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. MC_router_table . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. MC_tree_table . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.3. Multicast_routing_table . . . . . . . . . . . . . . . . . . . . 7
5. Message format . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. MC_CLAIM message . . . . . . . . . . . . . . . . . . . . . . . 8
5.2. SOURCE_CLAIM message . . . . . . . . . . . . . . . . . . . . . 8
5.3. CONFIRM_PARENT and LEAVE messages . . . . . . . . . . . . . . . 9
6. Detailed operation . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.2. Advertisement of multicast routers . . . . . . . . . . . . . . 10
6.3. Advertisement of multicast sources . . . . . . . . . . . . . . 10
6.4. Tree building . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.4.1. SOURCE_CLAIM message processing . . . . . . . . . . . . . . . 11
6.4.2. CONFIRM_PARENT message processing . . . . . . . . . . . . . . 11
6.5. Tree maintenance . . . . . . . . . . . . . . . . . . . . . . . 12
6.6. Detachement of a multicast tree . . . . . . . . . . . . . . . . 13
7. Sources without multicast capabilities . . . . . . . . . . . . . 13
7.1. SOURCE_CLAIM generation and processing . . . . . . . . . . . . 13
7.2. COMFIRM_PARENT message generation . . . . . . . . . . . . . . . 14
7.3. The computation of the next hop to reach the source . . . . . . 14
8. Proposed values for the constants . . . . . . . . . . . . . . . . 14
9. WIGMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.2. WIGMP overview . . . . . . . . . . . . . . . . . . . . . . . . 15
9.3. WIGMP router . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.3.1. Elimination procedure . . . . . . . . . . . . . . . . . . . . 17
9.3.2. The router designation procedure . . . . . . . . . . . . . . 17
9.3.3. Interaction between WIGMP and MOLSR . . . . . . . . . . . . . 18
9.4. The host behaviour . . . . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
Jacquet, Minet, Laouiti, Viennot, Clausen and Adjih [Page 2]
INTERNET-DRAFT Multicast Optimized Link State Routing 4 August 2001
2. Introduction
The Multicast Optimized Link State Routing (MOLSR) Protocol takes
benefit of the topology knowledge gathered by the OLSR protocol with
its Topology Control messages exchange to build multicast trees.
MOLSR is developed as an extension to OLSR. It works even when not
all nodes are multicast capable provided that multicast nodes offer
the minimal connectivity between the sources and the members of the
multicast group. A multicast tree is built and maintained for any
tuple (source, multicast group) in a distributed manner without any
central entity and provides shortest routes from the source to the
multicast group members. The trees are updated whenever a topology
change is detected.
2.1. Changes
This is the first revision of this draft.
Major changes from version 00 to version 01
- The WIGMP has been improved to keep unchanged the host part of
IGMP.
- Sources which are not multicast routers are considered too.
2.2. Terminology
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [2]. The
terms "connection", "holding time" "multipoint relay", "MPR", "multi-
point relay selector", "MPR selector", "MS", "node" and "symmetric
link" as well as other terms relating to the functionality of OLSR
are to be interpreted as described in draft-ietf-olsr-05.txt [1].
Additionally, the following terms are used throughout this document:
Multicast router
A node with multicast capabilities which can be used as
router to build multicast trees.
Jacquet, Minet, Laouiti, Viennot, Clausen and Adjih [Page 3]
INTERNET-DRAFT Multicast Optimized Link State Routing 4 August 2001
Designated multicast router
A multicast router which has been designated to forward multi-
cast data to a host in its neighborhood.
Multicast source
A host or a router which wants to send data to a multicast
group.
Multicast group member
A node which wants to receive data multicast to group G.
Participant
A node which belongs to a multicast tree. It may be a member
of the group.
Multicast tree
A tree whose root is the source of the multicast data and
whose nodes are multicast routers needed to forward data to
all multicast group members. There is one multicast tree per
tuple (source, multicast group).
Parent
A parent of a node is a multicast router which can relay mul-
ticast packets coming from the source to that node. A parent
has one or more downstream links (one per son) in the associ-
ated multicast tree.
Son
A node which has an upstream link to its parent in the associ-
ated multicast tree.
3. Protocol Overview
The multicast optimized link state routing protocol (MOLSR) belongs
Jacquet, Minet, Laouiti, Viennot, Clausen and Adjih [Page 4]
INTERNET-DRAFT Multicast Optimized Link State Routing 4 August 2001
to the source based family. It maintains one multicast tree per tuple
(source, multicast group). Those trees are only composed of multicast
capable nodes. Three steps are distinguished: the tree building, the
tree maintenance, and the tree detachement.
Tree building
Multicast routers declare themselves to the entire network by
broadcasting a MC_CLAIM message (using the optimized flooding tech-
nique of OLSR). Such nodes will disseminate this information peri-
odically.
Once a source wants to send data to a specific multicast group G,
it sends a SOURCE_CLAIM message enabling nodes which are members of
this group to detect its presence and to attach themselves to the
associated multicast tree.
This message is flooded within the ad hoc network using the opti-
mized flooding technique of OLSR. Branches are built in a backward
manner: group members which do not know yet about this source try
to attach themselves to the corresponding tree.
More specifically, when a group member receives a SOURCE_CLAIM mes-
sage and it is not already a participant of this (source, multicast
group) tree, it attaches itself to the (source, multicast group)
tree:
- it looks into the multicast routing table for the next
hop to reach the source (the multicast routing table pro-
vides shortest routes to all the multicast capable
nodes). This next hop becomes its parent in the multicast
tree.
- Then it sends a CONFIRM_PARENT message to its parent
node.
- The parent node receiving this message attaches itself to
the (source, multicast group) tree, if it is not already
a participant to this tree.
This message is handled hop by hop, by intermediate multicast
routers which build the corresponding branch.
Tree maintenance
Jacquet, Minet, Laouiti, Viennot, Clausen and Adjih [Page 5]
INTERNET-DRAFT Multicast Optimized Link State Routing 4 August 2001
The trees are periodically refreshed, by means of the SOURCE_CLAIM
message and the CONFIRM_PARENT message. Notice that topology
changes are still detected by the exchange of topology control mes-
sages which is done naturally by OLSR. Thus, trees updates are
triggered by the detection of topology changes.
Tree detachement
If a node wants to leave the multicast tree and it is a leaf, it
detaches itself from the tree: it just sends a LEAVE message to its
parent in this multicast tree. If its parent becomes a leaf, and
this parent is not a group member, it detaches itself from the tree
on its turn.
This message is processed hop by hop and unused branches are
deleted automatically.
4. Tables
MOLSR uses the information stored and handled by OLSR. Additional
information are kept in three different tables: MC_router_table,
MC_tree_table, and Multicast_routing_table.
4.1. MC_router_table
This table contains all the nodes with multicast capabilities. Each
entry contains the MM_addr and the MM_time. MM_addr stands for the
node address and MM_time specifies the time at which this record
expires.
4.2. MC_tree_table
This table contains the information dealing with different multicast
groups that this node is participating in. The table stores one entry
per tuple (source, multicast group). Each entry has the following
information:
Source_tree_info
consists of the address of the source_tree (MT_source_addr)
and the time to live for this entry (MT_source_tree_time).
Jacquet, Minet, Laouiti, Viennot, Clausen and Adjih [Page 6]
INTERNET-DRAFT Multicast Optimized Link State Routing 4 August 2001
Multicast_Group_addr
The address of the multicast goup (MT_group_addr).
Parent address
The address of the next node towards the source (MT_par-
ent_addr).
Sons information
List of the sons. For each son, its address (MT_son_addr) and
a time to live for it (MT_son_time) are recorded.
4.3. Multicast_routing_table
The multicast_routing_table provides the shortest routes to all the
multicast capable nodes in the network using only the multicast
routers. The calculations are done in the same way as they are done
for OLSR routing table. Each entry has the following information:
MR_dest
the destination multicast capable node
MR_next
The next hop multicast router in the route to MC_destination.
MR_dist
The estimated number of hops to reach the MC_destination.
The multicast_routing_table is updated whenever the OLSR routing
table is recalculated or when a new multicast node is discovered, or
it disappears.
5. Message format
Four new messages are needed to handle the multicast trees:
Jacquet, Minet, Laouiti, Viennot, Clausen and Adjih [Page 7]
INTERNET-DRAFT Multicast Optimized Link State Routing 4 August 2001
MC_CLAIM message
used to declare the multicast capabilities of a node (i.e this
node supports MOLSR extension).
SOURCE_CLAIM message
used by the sources to declare themselves in a multicast
group.
CONFIRM_PARENT message
used to attach a node to its parent in a multicast tree.
LEAVE message
used to leave a multicast tree or to change the parent of a
node.
The different messages use the uniform message format for OLSR. Each
new message will be assigned a new type of message in the message
header (see the section Proposed values for the constants).
5.1. MC_CLAIM message
The MC_CLAIM message does not carry a specific information. It is
only needed to flood a message header with the corresponding type of
message.
5.2. SOURCE_CLAIM message
The SOURCE_CLAIM is flooded by the source node, root of the multicast
trees. The address of this source is specified in the message header.
The source asks for members in the specified multicast groups.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MULTICAST GROUP ADDRESS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MULTICAST GROUP ADDRESS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .......... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Jacquet, Minet, Laouiti, Viennot, Clausen and Adjih [Page 8]
INTERNET-DRAFT Multicast Optimized Link State Routing 4 August 2001
MULTICAST GROUP ADDRESS
The multicast group address to which the source will multicast
data.
5.3. CONFIRM_PARENT and LEAVE messages
Those two messages have the same message format. To distinguish
between them,the message type of the header has to be checked.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PARENT ADDRESS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MULTICAST GROUP ADDRESS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MULTICAST SOURCE ADDRESS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PARENT ADDRESS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MULTICAST GROUP ADDRESS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MULTICAST SOURCE ADDRESS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .......... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This message has several fields:
PARENT ADDRESS
The address of the next node toward the source of the multi-
cast tree.
MULTICAST GROUP ADDRESS
The multicast group address for which the message is desti-
nated.
MULTICAST SOURCE ADDRESS
The address of the multicast source. This address combined
with the multicast group address identifies the multicast
Jacquet, Minet, Laouiti, Viennot, Clausen and Adjih [Page 9]
INTERNET-DRAFT Multicast Optimized Link State Routing 4 August 2001
tree.
6. Detailed operation
We describe here the functioning of the multicast extension and how
the different messages are processed.
6.1. Requirements
The calculation of the MPR set as done in OLSR must be modified. The
MPR set must be calculated in such a way that, 2-hop multicast capa-
ble nodes are covered by 1-hop multicast capable nodes when it is
possible. Nodes with multicast capabilities will be chosen preferably
to the other nodes. And, of course, this set should be minimal and
must cover all the 2-hop nodes.
6.2. Advertisement of multicast routers
Each node with multicast capabilities declares itself by sending a
MC_CLAIM to all the other nodes in the network. With this information
the other nodes can calculate routes to different sources in the same
way as the regular OLSR routing calculation. The routes are composed
only with multicast routers. The MC_CLAIM message is flooded each
MC_CLAIM_PERIOD seconds. Since this information does not change in
time, the MC_CLAIM_PERIOD should have a value as big as possible.
This information is kept in the MC_router_table for MC_HOLD_TIME sec-
onds.
6.3. Advertisement of multicast sources
The source declares itself by sending a SOURCE_CLAIM message. This
message is first generated whenever a node wants to send data to mul-
ticast group G. This SOURCE_CLAIM message will be flooded in the
entire network.
6.4. Tree building
A tree is associated with any tuple (source, multicast group). This
tree is built in a backward manner automatically without any central
entity from the different multicast group members to the source.
Branches are constructed hop by hop. The tree building is started
when a multicast router receives a SOURCE_CLAIM message for a group
in which it is participating. Branches are attached to the multicast
Jacquet, Minet, Laouiti, Viennot, Clausen and Adjih [Page 10]
INTERNET-DRAFT Multicast Optimized Link State Routing 4 August 2001
tree by means of the CONFIRM_PARENT message.
6.4.1. SOURCE_CLAIM message processing
When a participant receives a SOURCE_CLAIM it does the following
operations:
IF there is no entry corresponding to that group and source
THEN
1 create a new one.
2 set the MT_source_addr to the originator of the message.
3 set the MT_source_tree_time to the SOURCE_HOLD_TIME.
4 set the MT_group_addr to MULTICAST GROUP ADDRESS.
5 set parent and sons information fields to NULL.
6 Send a CONFIRM_PARENT message to its parent. The parent is the
corresponding MR_next in the multicast_routing_table to reach
the source.
ELSE update the MT_source_tree_time.
IF the node is a MPR of the sender, THEN it relays the SOURCE_CLAIM
message.
6.4.2. CONFIRM_PARENT message processing
The CONFIRM_PARENT message is sent by a node M to its parent. Upon
receiving such a message, a node has to do the following operations:
IF a corresponding entry to that group and source tree does not exist
in the MC_tree_table,
THEN
1 create a new one.
2 set the MT_source_addr to the originator of the message.
3 set the MT_source_tree_time to the SOURCE_HOLD_TIME.
Jacquet, Minet, Laouiti, Viennot, Clausen and Adjih [Page 11]
INTERNET-DRAFT Multicast Optimized Link State Routing 4 August 2001
4 set the MT_group_addr to MULTICAST GROUP ADDRESS.
5 set parent and sons information fields to NULL.
IF the son address does not exist in the sons list,
THEN
1 create a new record for this son.
2 set MT_son_addr to the originator address of the CONFIRM_PAR-
ENT message (found in the header of the message).
3 set MT_son_time to current time + SON_HOLD_TIME.
ELSE update MT_son_time to current time + SON_HOLD_TIME.
IF the parent address is equal to NULL,
THEN
1 set the MT_parent_addr to the next hop (MR_next) in the multi-
cast routing table of the current node to reach the source.
2 send a CONFIRM_PARENT message to the MR_next.
6.5. Tree maintenance
Each source periodically sends a SOURCE_CLAIM message to the whole
network. In this way, new multicast group members can join the corre-
sponding multicast tree. Upon a receipt of this message the nodes in
the specific tree will update their time to live field
MT_source_tree_time in the MC_tree_table.
The multicast_routing_table is recalculated whenever the neighborhood
or topology changes. If the next hop node (MR_next) towards the
source changes, the node (the group member or a participant node in
the tree) must generate a new CONFIRM_PARENT message to inform the
new parent. Then, it MAY generate a LEAVE message to disable the old
route (of course if the neighbor is still reachable). No message is
sent if the next hop does not change.
Each participant will send periodically a CONFIRM_PARENT message to
its parents in order to refresh the corresponding timeout each CON-
FIRM_PERIOD seconds. Those messages may be grouped in a single one
as allowed by the message format.
Jacquet, Minet, Laouiti, Viennot, Clausen and Adjih [Page 12]
INTERNET-DRAFT Multicast Optimized Link State Routing 4 August 2001
6.6. Detachement of a multicast tree
A LEAVE message is generated by a leaf node which wants to leave a
multicast tree, or by another intermediate node which has received
such a message and this participant is not a multicast group member.
A node can leave a group or a specific tree. Leaving a specific tree
may occur when the topology changes and a participant finds a new
route to the corresponding source. To leave a specific tree a node
may send a LEAVE message to its parent. If this parent becomes a
leaf, and if it is not a group member it will send on its turn a
LEAVE message to its parent.
Leaving a group means that the node leaves all the trees associated
with this group.
Leaving a multicast group means that a node is no more interested in
that group. In this case, and if this node has no son, all the unused
branches are eliminated. To leave the group a node may broadcast a
LEAVE message to its parents.
A participant will also send a LEAVE message to its parents when it
has no more sons (e.g timed out) and it is not itself a multicast
group member. This procedure eliminates quickly the unused branches
in the network.
7. Sources without multicast capabilities
In this section we deal with the sources which are not multicast
routers. As usual such sources send multicast data to multicast
groups. In that case, the following MOLSR procedures are modified:
- The SOURCE_CLAIM generation and processing.
- The CONFIRM_PARENT generation for the source neighbors.
- The computation of the next hop to reach the source.
7.1. SOURCE_CLAIM generation and processing
The designated multicast router (see next section) of this source is
in charge of generating a SOURCE_CLAIM message on behalf of this
source. In that case, the first field of the SOURCE_CLAIM message
contains the individual address of the source. The following fields
specify the multicast group addresses to which the source sends data.
Notice that it is easy to distinguish a multicast address from the
Jacquet, Minet, Laouiti, Viennot, Clausen and Adjih [Page 13]
INTERNET-DRAFT Multicast Optimized Link State Routing 4 August 2001
individual address of the host.
The SOURCE_CLAIM message is processed as previously described except
that the MT_source_addr is set to the first field of the SOURCE_CLAIM
message.
The SOURCE_CLAIM message is periodically sent by the designated
router to refresh the corresponding entry in the MC_tree_table.
7.2. COMFIRM_PARENT message generation
The source neighbors do not send a CONFIRM_PARENT message, because
the source is not able to process them.
7.3. The computation of the next hop to reach the source
In order to compute the next hop to the source, the multicast routers
which are not source neighbors, select the next hop to one of the
MPRs with multicast capabilities of the source giving the shortest
distance.
8. Proposed values for the constants
MC_CLAIM_PERIOD = 30 sec
MC_HOLD_TIME = 3 x MC_CLAIM_PERIOD
SOURCE_CLAIM = 15 sec
SOURCE_HOLD_TIME = 3 x SOURCE_CLAIM
CONFIRM_PERIOD = 10 sec
SON_HOLD_TIME = 3 x CONFIRM_PERIOD
CONFIRM_DELAY = 1 sec
The message types of this extension are given by the following table
Mnemonic Value Extension
------------------------------------------------------------
MC_CLAIM 7 Multicast
SOURCE_CLAIM 8 Multicast
Jacquet, Minet, Laouiti, Viennot, Clausen and Adjih [Page 14]
INTERNET-DRAFT Multicast Optimized Link State Routing 4 August 2001
CONFIRM_PARENT 9 Multicast
LEAVE 10 Multicast
9. WIGMP
9.1. Motivation
The Internet Group Management Protocol (IGMP) is used by hosts to
report their multicast group membership to neighboring multicast
routers. It is also used by multicast routers to discover group mem-
bers. According to IGMPv2 (RFC 2236) and IGMPv3, IGMP is required to
be implemented by any host wishing to receive IP multicasts. However
in a wireless context like MANET, the use of IGMP may lead to some
inconsistencies. More precisely, the elimination procedure of queries
as described in IGMP is problematic in a wireless context:
- The elimination procedure eliminates too many queriers, as
illustrated by this example.
Example :
R1 R2 H
A host H has only one neighbor router R2. Router R1 and router R2
are neighbors. Initially both routers R1 and R2 are queriers. When
router R2 receives the query of router R1 with a smaller address,
router R2 becomes non querier. Router R1 is the only querier. As
host H can only be heard by R2, router R1 does not receive the
unsolicited report of H for group G. Hence no router will forward
IP multicast packets for group G to H.
To cope with this problem we propose to modify the behaviour of IGMP
in the routers.
9.2. WIGMP overview
WIGMP is a Wireless IGMP. It is only concerned with the exchanges
between hosts and routers to determine group membership. The goals of
WIGMP are:
Jacquet, Minet, Laouiti, Viennot, Clausen and Adjih [Page 15]
INTERNET-DRAFT Multicast Optimized Link State Routing 4 August 2001
(i) to enable any multicast router to know whether at least
one host in its neighborhood is member of a multicast group;
(ii) to enable a multicast router to know whether it must for-
ward multicast data to a host in its neighborhood.
On a multicast router, WIGMP coexists with a multicast routing proto-
col. The multicast routing protocol is in charge of building and
maintaining a multicast structure (e.g. a tree between a source and
all the multicast routers participants of a multicast group) enabling
any member of a multicast group G to receive IP multicast data desti-
nated to G.
Notice that, in WIGMP there is no new messages added to the IGMP
ones, we keep the same messages specified as in IGMPv3. The host IGMP
is kept as it is also.
The major change is in the router IGMP, by modifying the behaviour of
the router when sending and receiving those messages.
First :
The rule for multicast routers elimination is modified.
Second:
For each host H, a multicast router in H neighborhood is des-
ignated to forward multicast data.
Third :
A multicast router, member of a multicast group, plays the
only role of IGMP router.
Whenever a host H wants to join a multicast group G, it sends an IGMP
report which is called Unsolicited Report to reach neighbor multicast
routers. MOLSR routers do not send this kind of messages. If a MOLSR
router wants to join a group it builds simply and immediately a route
to the sources of the requested group. A multicast router is desig-
nated to forward multicast data to H (see the designation procedure
in the next section).
Multicast routers that have not been eliminated (see the elimination
procedure in the next section), periodically send general queries to
their neighbors.
Jacquet, Minet, Laouiti, Viennot, Clausen and Adjih [Page 16]
INTERNET-DRAFT Multicast Optimized Link State Routing 4 August 2001
9.3. WIGMP router
9.3.1. Elimination procedure
The elimination procedure is modified in such a way that IGMP is a
particular case of WIGMP. The role of this procedure is to select a
multicast router in charge of the host queries in the neighborhood.
However, any host must be queried by a multicast router. In IGMPv2
and v3, if two multicast routers hear each other, only the one with
the smallest address is elected as a querier. In WIGMP, the follow-
ing rule is applied:
Let Ri and Rj, be any two multicast routers, and OneHop(Ri) be the
one hop neighborhood of Ri
IF OneHop(Ri) U {Ri} = OneHop(Rj) U {Rj}
THEN the router Rj with the highest address is eliminated
ELSE IF OneHop(Ri) U {Ri} is included in OneHop(Rj) U {Rj}
THEN the router Ri is eliminated.
9.3.2. The router designation procedure
The router designation procedure enables the designation of the mul-
ticast router in charge of forwarding multicast data to a host.
When a multicast router receives an Unsolicited Report from a host H
its checks its neighbor table to see whether it has the lowest IP
address among the multicast routers neighbors of H. In fact, with
OLSR, each node has a two hop neighbors table which provides all
links in the neighborhood. In this way, the multicast router with the
lowest IP address designates itself as a router to this host.
If the host H moved or a link breaks with this router, another multi-
cast router having detected the presence of H, is designated as a
multicast router for H. It builds a branch to the multicast group (if
it does not exist), and forwards the corresponding multicast data.
Jacquet, Minet, Laouiti, Viennot, Clausen and Adjih [Page 17]
INTERNET-DRAFT Multicast Optimized Link State Routing 4 August 2001
9.3.3. Interaction between WIGMP and MOLSR
Each time there is a change of group G membership, WIGMP notifies its
local multicast routing protocol when:
- either an unsolicited report has been received from a new mem-
ber,
- or a previous member has left.
9.4. The host behaviour
The host which is not a multicast router behaves according to IGMP as
in the wired network. When it wants to join a multicast group, it
starts sending its unsolicited Report, and, then normal reports upon
receiving queries from multicast routers. In case of the presence of
multiple multicast routers sending their query messages in the neigh-
borhood, the host bundles multiples multicast group reports as in
IGMPv3 and its reports are addressed to all multicast routers in its
neighborhood.
10. References
1 Philippe Jacquet, Amir Qayyum, Thomas H. Clausen, Anis
Laouiti, Laurent Viennot, Pascale Minet and Paul Muhlethaler.
Optimized Link State Routing Protocol. Internet-Draft, draft-
ietf-manet-olsr-05.txt, November 2001. Work in progress.
2 S. Bradner. Key words for use in RFCs to Indicate Requirement
Levels. Request for Comments (Best Current Practice) 2119,
Internet Engineering Task Force, March 1997.
3 Fred Baker. Requirements for IP Version 4 Routers. Request for
Comments (standard track), Internet Engineering Task Force,
June 1995.
4 William C. Fenner. Internet Group Management Protocol, Version
2. Request for Comments 2236, Internet Engineering Task
Force, November 1997.
Jacquet, Minet, Laouiti, Viennot, Clausen and Adjih [Page 18]
INTERNET-DRAFT Multicast Optimized Link State Routing 4 August 2001
11. Authors' Addresses
Philippe Jacquet Project HIPERCOM INRIA Rocquencourt BP 105 78153 Le
Chesnay Cedex, France Phone: +33 1 3963 5263 Email:
Philippe.Jacquet@inria.fr
Anis Laouiti Project HIPERCOM INRIA Rocquencourt BP 105 78153 Le
Chesnay Cedex, France Phone: +33 1 3963 5088 Email:
Anis.Laouiti@inria.fr
Pascale Minet Project HIPERCOM INRIA Rocquencourt BP 105 78153 Le
Chesnay Cedex, France Phone: +33 1 3963 5233 Email: Pas-
cale.Minet@inria.fr
Laurent Viennot Project HIPERCOM INRIA Rocquencourt BP 105 78153 Le
Chesnay Cedex, France Phone: +33 1 3963 5225 Email: Laurent.Vien-
not@inria.fr
Thomas Heide Clausen Project HIPERCOM INRIA Rocquencourt BP 105 78153
Le Chesnay Cedex, France Phone: +33 1 3963 5133 Email:
Thomas.Clausen@inria.fr
Cedric Adjih Project HIPERCOM INRIA Rocquencourt BP 105 78153 Le
Chesnay Cedex, France Phone: +33 1 3963 5215 Email:
Cedric.Adjih@inria.fr
Jacquet, Minet, Laouiti, Viennot, Clausen and Adjih [Page 19]