Internet DRAFT - draft-vasaka-xcast-sim
draft-vasaka-xcast-sim
Internet Draft Vasaka Visoottiviseth
Expiration Date: January 2002 NAIST / WIDE Project
Yosuke Takahashi
Noritoshi Demizu
WaterSprings.ORG
July 2001
Sender Initiated Multicast (SIM)
<draft-vasaka-xcast-sim-00.txt>
Status of this Memo
This document is an Internet-Draft and is subject to 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 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.
Abstract
Sender Initiated Multicast (SIM) is a point-to-multipoint multicast
mechanism. The members of a receiver group are specified by a
sender, instead of receivers. A group is identified by the
combination of sender's unicast address in the source address field
and a multicast address in the destination address field. A sender
always (in list mode) or periodically (in preset mode) attaches a
receiver list to packets in order to specify the members of a
receiver group. Each packet is forwarded along unicast paths to each
receiver and is duplicated at the branching router. Routers on the
paths maintain SIM Forwarding Information Base (FIB) as specified by
the flags in the receiver list. In preset mode, SIM can decrease
Vasaka, et al. [Page 1]
Internet Draft draft-vasaka-xcast-sim-00.txt July 2001
number of routers that have to maintain SIM FIB by automatically
created SIM Tunnel between two SIM branching routers.
In this document, we describe SIM including its delivery models, SIM
FIB operations, the formats, and security considerations.
Table of Contents
1. Introduction
2. Acronyms and Terminology
3. Overview
4. Characteristics of SIM
5. Creating a multicast session
6. SIM Forwarding Procedure
7. SIM Basic Rules
8. SIM Forwarding Information Base (FIB)
9. SIM FIB Operations
10. SIM Tunnel
11. SIM Routers
12. Header Format
13. Interoperability with Existing Protocols
14. Security Considerations
Changes
- re-organized the chapters
- filled out the terminology
- changed usage of bit map and receiver list
- changed IPPROTO_SIM header format
- changed SIM packet format and added its figure
- added packet format for SIM message control
- added security considerations
1. Introduction
Since multicast efficiently sends data to a group of receivers, it
has been considered important for multi-party applications such as
video conferencing and data distribution.
The ordinary IP Multicast mechanism is based on "Host Group Model".
Receivers are responsible for joining/leaving a multicast group.
Control messages are passed among upstream routers to establish or
tear down multicast paths according to receivers' requests. As a
result, a sender can send packets to all the joining receivers
without any knowledge of the receivers.
Vasaka, et al. [Page 2]
Internet Draft draft-vasaka-xcast-sim-00.txt July 2001
The advantages of "Host Group Model" are:
- Receivers can start receiving data without disturbing senders.
- Any nodes can send data to all nodes that has a particular role
without any knowledge except a group address.
The drawbacks of "Host Group Model" are:
- Routers on multicast trees have to maintain states for each
multicast group to forward packets.
- Control messages have to be exchanged among routers on multicast
trees to establish, keep or tear down multicast paths.
- It is necessary to deploy a global multicast address space
administration mechanism. [MALLOC]
To avoid allocating a global multicast address, Perlman has proposed
Simple Multicast (SM) [SM]. SM identifies a group by using both C
(the core router address) and M (the multicast address). This
eliminates the need to have unique multicast addresses and coordinate
multicast addresses across the Internet. That means that every core
router in the Internet can assign the full 28 bits worth of multicast
addresses.
Recently, Source Specific Multicast (SSM) [SSM] is proposed. SSM
uses a similar technique as in SM. But instead of using core router
address, it identifies a group by the combination of source address
and destination multicast address. For IPv4, the address range of
232/8 has been assigned by IANA for SSM. That means that every
source can have 2^24 multicast groups. For IPv6, a source-specific
multicast address can be specified by setting both the prefix length
field and the prefix field to zero. Thus IPv6 allows for 2^32 SSM
addresses per scope for every source.
On the contrary, Explicit Multicast (xcast) mechanism is proposed
[SDBM][CLM][MDO6][SGM][DCM][ERM]. In this mechanism, instead of
using a multicast address, a receiver list is attached to each packet
and no additional control message is exchanged among routers.
Routers on multicast trees just forward packets to all downstream
routers for all receivers in receiver lists.
The advantages of xcast are:
- Routers on multicast trees basically do not need to maintain
states for each multicast group.
- Basically, no control message is exchanged among routers.
The drawbacks of xcast are:
- It is relatively heavy to forward xcast packets compared to
ordinary multicast packets. Xcast packets might go through slow
paths in high speed routers.
- Data area in each packet becomes slightly smaller, especially in
Vasaka, et al. [Page 3]
Internet Draft draft-vasaka-xcast-sim-00.txt July 2001
the IPv6 case, since a receiver list is attached.
Sender Initiated Multicast (SIM) is a point-to-multipoint (p2mp)
multicast mechanism. The members of a receiver group are specified
by a sender, instead of receivers, similarly to xcast. A group is
identified by the combination of sender's unicast address in the
source address field and a multicast address in the destination
address field similar to SM ans SSM. Therefore, each source can
assign full 28 bits of group address. A sender always (in list mode)
or periodically (in preset mode) attaches a receiver list to packets
in order to specify the members of a receiver group. Each packet is
forwarded along unicast paths to each receiver and is duplicated at
the branching router. Routers on the paths maintain SIM Forwarding
Information Base (FIB) as specified by the flags in the receiver
list.
In this document, we describe SIM including its delivery models, SIM
FIB operations, the formats, and security considerations.
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.
2. Acronyms and Terminology
Acronyms and Abbreviations
mp2mp = Multi-Point to Multi-Point
p2mp = Point to Multi-Point
SIM = Sender Initiated Multicast
SIM FIB = SIM Forwarding Information Base
Terminology
SIM = Sender Initiated Multicast
SIM Basic Rules = SIM Delivery Models
SIM FIB = SIM forwarding information base
SIM Hello = SIM control message
SIM Host = SIM capable host
SIM Node = SIM capable node
SIM router = SIM capable router
SIM branching router = a SIM router that acts as a multicast
branching point
SIM Packet = packet that has SIM related headers
SIM related headers = IPPROTO_SIM in the IPv4
SIM Ridirect = SIM control message to make a SIM Tunnel
SIM Router = SIM capable router
SIM Tunnel = a tunnel between two SIM branching routers
list mode = SIM mode that the sender attaches the receiver list
Vasaka, et al. [Page 4]
Internet Draft draft-vasaka-xcast-sim-00.txt July 2001
to all packets
preset mode = SIM mode that the sender periodically attaches the
receiver list to packets
3. Overview
SIM is a point-to-multipoint (p2mp) multicast mechanism for small
groups. SIM is designed to aim the following.
- Less cost in maintaining states information
- Simple and less-costly packet forwarding mechanism
- Simple to deploy and support existing applications on receiver
side
SIM is not intended to be replaced with the existing multicast
protocols, but it is more like a subset of other protocols. Contrary
to the traditional multicast model which supports many-to-many group
communications, SIM is designed to support mostly a one-to-many small
group communications like other xcast protocols. To avoid collision
of group addresses, a group is identified by the combination of
sender's unicast address in the source address field and a multicast
address in the destination address field. Multipoint-to-multipoint
(mp2mp) multicast can be achieved by combining multiple p2mp
multicast.
The members of a receiver group are explicitly specified by a sender,
instead of receivers. SIM has two modes, "list mode" and "preset
mode", according to how it maintains the forwarding table. In list
mode, the sender always attaches a receiver list to all packets, and
the forwarding table can be cached and discarded at any time.
Contrary, in preset mode, it only periodically attaches a receiver
list to packets and the forwarding table will be registerd for
forwarding following packets. List mode is designed for a short data
flow. On the other hand, preset mode is designed for a long data
flow. Swiching between these two modes can be done by changing a
"preset flag" in SIM header.
Each packet is forwarded along unicast paths to each receiver. When
a router receives a packet with a receiver list, the router groups
receivers by their next hop nodes. Then, the router duplicates the
packets, changes flags in the bit map field according to each next
hop node, and then sends the packets for each next hop node. Each
duplicated packet contains the same receiver list, while the router
forwards packets according to the flags in the bit map field. By
performing this procedure on the routers on unicast paths, a packet
with a receiver list can be delivered to all receivers in the
receiver list. Because a packet is duplicated only at branching
Vasaka, et al. [Page 5]
Internet Draft draft-vasaka-xcast-sim-00.txt July 2001
routers, bandwidth can be used efficiently.
Routers on the paths register the next hop nodes for each multicast
group in SIM Forwarding Table (FIB) in the following form:
( src(UC), dst(MC), gen_count ) --> ( coming-from, next-hop-list )
In the case of "list mode", a receiver list is attached to all
packets in a flow. A SIM FIB entry can be registered as a cache to
decrease the number of lookups. Caches can be discarded any time,
for example, when memory is full. In the case of "preset mode", a
receiver list is periodically attached to packets in a flow. A
registered SIM FIB entry is used to forward following packets that do
not have receiver lists. Except packets with receiver lists, the
forwarding processing cost for SIM might be close to the cost for SM
and SSM. In both modes, a SIM FIB entry will be removed if a router
does not observe a corresponding receiver list for a certain period
of time (i.e. soft state).
If the procedure briefly described above was performed at every
router on paths, all routers on multicast trees had to maintain
states for each multicast group. To decrease the number of routers
that need to maintain states, following optimization mechanisms are
introduced. First, if the receiver list for a next hop node consists
of only one receiver, SIM header will be detached and the destination
address field of the packet forwarded to the next hop node is filled
with the receiver's address. The source address field is filled with
the sender's address. By this mechanisms, routers beyond last
branching point of a multicast tree do not have to maintain states
for the multicast group.
Second, if an AS has high speed backbone links, the ingress routers
of the AS may group the receivers in a receiver list by the egress
routers of the AS instead of next hop routers, and send duplicated
packets to each egress router by using a mechanism like tunneling
called "SIM Tunnel". By this mechanism, the core routers of the AS
do not need to maintain states for multicast groups nor to process
SIM packets. In other words, multicast trees are made simple by
allowing duplicated packets to be flow over the same high speed
links.
Third, only in the case of preset mode, branching routers exchange
redirect messages in order to skip non-branching router by using SIM
Tunnel. By this mechanism, only branching routers of a multicast
tree need to maintain states for the multicast group and to process
SIM packets. By combining all optimization mechanisms described in
this paragraph, both the number of routers that need to maintain
states and the average number of states in each router can be
Vasaka, et al. [Page 6]
Internet Draft draft-vasaka-xcast-sim-00.txt July 2001
decreased.
In order to increase the number of existing unicast and multicast
applications that can be used as receivers of SIM mechanism, SIM has
the following features. First, the destination address field of a
SIM packet will be replaced with receiver's unicast address when the
packet reaches at each receiver. When this feature is used in list
mode, SIM routers act like xcast routers. Second, SIM related
headers can be stripped off from a SIM packet when the packet reaches
at each receiver. Third, any part of upper-layer protocols, such as
checksums and port numbers, can be substituted with specified data
for each receiver when the packet reaches at receivers.
4. Characteristics of SIM
We now discuss some characteristics of Sender Initiated Multicast.
(1) Only branching routers maintain states in preset mode
In the case of preset mode, only branching routers of a
multicast tree need to maintain states for the multicast group
and to process SIM packets. This is accomplished by redirect
message exchanges exchanged among SIM routers in order to skip
non-branching router by using SIM Tunnel.
(2) Conversion to Unicast Packet
SIM related headers of a SIM packet MUST be stripped off at the
last SIM branching router before the packet reaches the
destination host. The destination address field of a SIM packet
MUST be replaced with receiver's address when the packet reaches
at each receiver.
(3) Partial Substitution of Upper Layer Protocol
Any part of upper-layer protocols, such as checksums and port
numbers, MUST be substituted with specified data for each
receiver when the packet reaches at receivers. Substitution
rules are specified with the offset from the top of upper-layer
protocol, the length of substitution data and substitution data
for each receiver. Substitution data are stored in a SIM option
header in the order of a receiver list. Substitution data for
invalidated receivers in the bitmap MUST also be appeared.
The fields that will be substituted in the upper-layer protocol
MUST be zero.
5. Creating a multicast session
Now we describe the design of SIM and its basic operations in detail.
Vasaka, et al. [Page 7]
Internet Draft draft-vasaka-xcast-sim-00.txt July 2001
5.1 Allocating a multicast address
SIM uses the two tuple of (sender unicast address, multicast address)
to identify a multicast session. Therefore, the multicast address
does not need to be unique. That means every senders can assign the
full 28 bits worth of multicast addresses. Each sender may assign
the multicast group address randomly. A multicast session will
contain of one sender and multiple receivers. For many-to-many
communication such as video conferencing can be acheived by creating
multiple multicast sessions.
5.2 Membership
Because each sender control the access seperately, senders need to
notify the receivers about the multicast session. That is, they have
to notify the sender unicast address and the multicast address. These
can be deployed through several possible membership management system
depening on the communication models.
For one-to-many group communication such as file distributing, the
sender itself can hold the membership management system. It may send
a Join-Inviation message to each receivers. And after receiving
Join-Acceptance message from receivers, it can begin sending
multicast data.
On the other hand, for many-to-many group communication such as video
conferencing, it is not convenient to maintain the same receiver list
on all nodes. It would be better to have only one node acts as a
group membership management server that will centrally maintain the
receiver list. This node may be one of a group member or the third
part node. Each member have to register to this membership
management server, and share the list before beginning the
conference. Multicast membership management can be implemented in
application layer.
6. SIM Forwarding Procedure
SIM forwards the packet as the following.
(1) The sender sends SIM packets to the nearest SIM router.
(2) The SIM router will find out the receiver list from packet header,
and look up unicast routing table to find out the next hop nodes
for each receiver.
(3) If the packet for all receiver in the list is going to be
forwarded to the same next hope node, and that node is also a SIM
router, the packet will be forwarded to the next SIM router
Vasaka, et al. [Page 8]
Internet Draft draft-vasaka-xcast-sim-00.txt July 2001
without any modification.
(4) Else if the packet is going to be forwarded to multiple next hop
nodes, the packet will be duplicated. Flag in the bit map field
in SIM header will be rewritten according to the receivers.
- If there is only one receiver on the list, the packet header
will be rewritten as if it is a unicast packets.
- If the next hope router is not SIM-aware router, and it is
assumed that there is no SIM-aware router on the network path
to the receivers, the packet will be send separately to each
receiver. The source and destination field in packet header
will be rewritten as if they are unicast packets.
(5) The packets will be forwarded by using rules 2-4 as described
above until they reach all the receivers.
7. Delivery Models
Several delivery models are taken into account in SIM. Three intra-
AS models are described in 7.1, 7.2 and 7.3. Administrators may
choose any model for their networks. One inter-AS model and one
last-hop model are described in 7.4 and 7.5, respectively.
7.1 Island Model
- Assumptions
- SIM capable routers and hosts are placed only around and
behind slow links in order to save bandwidth. This model
may be widely chosen at the first stage of SIM deployment.
- Behaviors
- At first, before sending or forwarding a SIM packet with a
receiver list, a SIM capable node determines the "next hop
nodes" for each receiver in a receiver list by looking up
the unicast routing table.
- If a "next hop node" is SIM capable, the SIM capable node
sends or forwards the SIM packet to the "next hop node"
by using SIM Basic Rules.
- If a "next hop node" is not SIM capable, the packet is
duplicated and sent to each receiver by filling the
destination address field with each receiver's address.
7.2 Continent Model
- Assumptions
- In an AS or in user networks, all routers and hosts are SIM
capable. This model may be applied to campuses, LANs, small
ISPs, etc.
Vasaka, et al. [Page 9]
Internet Draft draft-vasaka-xcast-sim-00.txt July 2001
- Behaviors
- The "next hop node" for each receiver is determined by
looking up in the unicast routing table at each router.
- All routers except egress routers forward SIM packets by
using SIM Basic Rules. All hosts send and receive SIM
packets by using SIM Basic Rules.
- Behaviors of egress routers SHOULD follow an inter-AS model.
- Notes
- SIM packets are forwarded along optimal paths and are
duplicated only at branching routers.
- All routers on multicast trees need to maintain states for
each multicast group and have to process all SIM packets
unless optimization mechanisms run.
7.3 Edge-Core Model
- Assumptions
- In an AS, ingress and egress routers are SIM capable but
core routers are not SIM capable. All SIM packets come in
through ingress routers. This model may be applied to large
ISPs, etc.
- Behaviors
- If a NOC is also a branching point in the topology of an AS,
a designated branching router for the NOC may be chosen to
save bandwidth.
- Procedure at ingress routers are:
1. Determine "next hop nodes" by looking egress routers up
for all receivers in a receiver list. If a designated
branching router exists on a path from the ingress router
to an egress router for a receiver, the receiver's "next
hop node" can be the designated branching router in order
to save bandwidth.
2. Duplicate the SIM packet for each "next hop node", and
modify flags in the bit map field according to the receiver
list for each packet.
3. If there is only one receiver for a "next hop node", send
the packet by filling its destination address field with
the receiver's address. Otherwise, if a next hop node is
a neighbor, send the packet by using SIM Basic Rules. If
a next hop node is not a neighbor, send the packet to the
"next hop node" by using SIM tunnel.
- Egress routers SHOULD follow an inter-AS model.
- Notes
- In this model, routing table entries of both ingress routers
and designated branching routers need to contain both egress
routers and next designated branching routers in addition to
next hop routers for each destination.
Vasaka, et al. [Page 10]
Internet Draft draft-vasaka-xcast-sim-00.txt July 2001
- Core routers do not have to maintain states for each
multicast group nor to process SIM packets. However, there
is a possibility that packets are duplicated before real
branching points.
7.4 Inter-AS Model
- Assumptions
- An egress router of an AS is SIM capable and forwards
SIM packets to another ASes or user networks.
- Behaviors
- An egress router determines the "next hop node" for each
receiver of an SIM packet as an ingress router for the
downstream AS or user networks. An ingress router may have
a designated ingress router. In such case, the "next hop
node" is the designated ingress router.
- If the "next hop node" is SIM capable, the egress router
forwards the SIM packet by using SIM Basic Rules.
- If the "next hop node" is not SIM capable, the egress router
duplicates and sends to to each receiver by filling the
destination address with each receiver's address.
7.5 Last hop Model
- Assumptions
- A SIM capable node is sending or forwarding a SIM packet to
a receiver.
- Behaviors
- If the receiver is not SIM capable, the node removes SIM
related headers and sends the packet as an ordinary
multicast or unicast packet.
7.6 How to adapt SIM Basic Rules
To support all models described in this section, SIM forwarding rules
is defined as following:
1. In the case where a receiver list needs to be parsed, a SIM node
looks "next hop nodes" up according to its delivery model.
Otherwise, a SIM node looks "next hop nodes" up in SIM FIB.
2. The SIM node sends/forwards the SIM packet to each "next hop
node" by using the following rules:
1. If a "next hop node" is a neighboring SIM router,
the SIM node sends/forwards the SIM packet by using SIM
Basic Rules. (e.g. island model, continent model, inter-AS
Vasaka, et al. [Page 11]
Internet Draft draft-vasaka-xcast-sim-00.txt July 2001
model)
2. If a "next hop node" is a non-neighboring SIM router,
the SIM node sends/forwards the SIM packet by using SIM
tunnel. (e.g. ingress routers of edge-core model)
3. Otherwise, the SIM node duplicates and sends to each
"next hop node" by filling the destination address with
each receiver's address. (e.g. inter-AS model, edge node)
8. SIM Forwarding Information Base (FIB)
Basically, many xcast protocols also attach the receiver list to each
packet, and forward the packets along the unicast paths. However,
because these protocols maintain forwarding state on per-receiver
basis at routers that can handle these protocols, the number of look-
ups on forwarding table is usually more than once. It is relatively
heavy to forward the packets compared to the ordinary IP multicast
mechanism. In contrast, this problem is alleviated with SIM. Each
group is identified by a two-tuple, the sender's unicast address and
a multicast address. When the router received a SIM packet, it will
use this two-tuple as a key to look up the SIM forwarding table or
SIM FIB. This technique will reduce the number of look-ups to once,
and gracefully cut off the overhead on forwarding packets.
A SIM FIB entry is recorded as following.
( src(UC), dst(MC), gen_count ) --> ( coming-from, next-hop-list )
"gen_count" is generation counter of SIM FIB.
"coming-from" are one of:
incoming-I/F
previous branching router (when SIM tunnel is used)
each "next hop" is associated with:
forwarding mode: direct-unicast / direct-multicast / sim-tunnel
- direct-unicast .... last hop addr + ptr to routing entry
- direct-multicast .. ptr to outgoing-I/F
- sim-tunnel ........ tunnel egress addr + ptr to routing entry
Coming-from field at right hand side is to detect changes of unicast
routing. If a packet comes from a different incoming-I/F or a
different previous branching router, the SIM FIB entry SHOULD be
discarded and a new SIM FIB entry SHOULD be created.
9. SIM FIB Operations
Vasaka, et al. [Page 12]
Internet Draft draft-vasaka-xcast-sim-00.txt July 2001
SIM routers maintain SIM FIB entries for each multicast group as
specified by three flags in receiver lists. "Preset flag" specifies
the operation mode: list mode or preset mode. A receiver list is
attached to all packets of a flow in list mode, while a receiver list
is attached periodically in preset mode.
The other two flags are "Temporary flag" and "Delete flag".
"Temporary flag" is set when a flow consists of only a few packets,
or the members of a receiver list of a flow are temporary changed
only for a few packets. If "Temporary flag" is set for a SIM packet,
SIM routers MUST use the attached receiver list to forward the packet
even if a corresponding SIM FIB entry exists. SIM routers MUST NOT
create nor update a corresponding SIM FIB entry. If a corresponding
SIM FIB entry already exists for this flow, the entry SHOULD be kept.
"Delete flag" SHOULD be set for the last packet of a flow in order to
ask SIM routers to remove a corresponding SIM FIB entry. If a SIM
router receives such SIM packet, the SIM router SHOULD remove the
entry after SIM_FIB_AGING time. If "Temporary flag" is not set on
the packet and a SIM FIB entry exists for the flow, the router MAY
use the entry to forward the packet.
For some reasons, a sender may happen to have to change the members
of receivers of a flow. Since a multicast group is identified by the
combination of sender's address and multicast address in SIM, SIM has
generation count field in order to enable routers on a multicast tree
to detect member changes. When members are changed, generation count
MUST be incremented by random value. Initial value of generation
count SHOULD be random. A receiver list MUST NOT be changed for the
same combination of source address, destination address and
generation count for SIM_FIB_TIMEOUT time. A SIM FIB entry of old
generation count SHOULD be kept for SIM_FIB_AGING time.
If a SIM router does not receive a receiver list for a flow for
SIM_FIB_TIMEOUT time, the corresponding SIM FIB entry MUST be
removed.
The details of SIM FIB operations are described in this section.
9.1 SIM FIB Operation for List Mode
List mode is designed for relatively short flows. In this mode, a
receiver list is attached to all packets in a flow. "Preset flags"
are not set for any packets.
If the members of a receiver list of a flow are not fixed at all, or
if a flow consists of only a limited number of packets, "Temporary
flag" of SIM packets SHOULD be set. In this case, routers on paths
Vasaka, et al. [Page 13]
Internet Draft draft-vasaka-xcast-sim-00.txt July 2001
MUST NOT create a SIM FIB entry as a cache.
If the members of receivers of a flow are almost constant and a flow
consists of numbers of packets, neither "Temporary flag" nor "Delete
flag" is set for packets with regular members, except the last packet
of the flow. Routers on the multicast tree MAY create a SIM FIB
entry as a cache to optimize forwarding processing. When the sender
sends a SIM packet temporary to different members, "Temporary flag"
MUST be set. When the sender sends the last packet of a flow,
"Delete flag" SHOULD be set.
9.2 SIM FIB Operation for Preset Mode
Preset mode is designed for relatively long flows, such as real time
traffic. In this mode, a receiver list is periodically attached to
packets in a flow. "Preset flags" are set for all packets.
When a sender sends initial SIM packets of a flow, a receiver list is
attached to the packet and neither "Temporary flag" nor "Delete flag"
is set. SIM routers on paths SHOULD create an SIM FIB entry for the
flow and forward the packet. This entry SHOULD be used to forward
following SIM packets whose number of receivers is zero. A sender
SHOULD periodically attach a receiver list to SIM packets in order to
refresh SIM FIB entries on SIM routers on the multicast tree. The
interval time of sending such packets is SIM_FIB_INTERVAL time. If
there is no appropriate packet to attach a receiver list at the time
just before the timer expiration, a SIM packet without upper-layer
protocol MAY be sent.
When a sender wants to change the members of a receiver list, the new
receiver list MUST be attached to a SIM packet and generation count
MUST be incremented by random value. A SIM router receives such
packet, the SIM router MUST create a new SIM FIB entry for the
multicast group of the new generation count. A SIM FIB entry of the
old generation count SHOULD be kept for SIM_FIB_AGING time.
A sender SHOULD set "Delete flag" for the last packet of a flow. SIM
routers on a multicast tree MUST remove the corresponding SIM FIB
entry after SIM_FIB_AGING time. If a SIM FIB entry exists for the
flow on a router, the router SHOULD use the entry to forward the
packet.
In preset mode, a multicast tree is simplified by removing all non-
branching routers from the tree by using following procedure: When a
sender sends a SIM packet, previous-hop field MUST be filled with
sender's address and skip count field MUST be set to zero. If a non-
branching router receives a SIM packet, the router MUST increment the
Vasaka, et al. [Page 14]
Internet Draft draft-vasaka-xcast-sim-00.txt July 2001
skip count by one and forward to next hop router. A SIM FIB entry
for this flow SHOULD be created and kept for SIM_FIB_AGING time as a
fallback for losses of SIM Redirect messages. If a branching-router
receives a SIM packet and skip count is not zero, the router sends an
SIM Redirect message to the previous branching router. Before the
branching router forwards the packet, previous-hop field MUST be
filled with the address of branching router and skip count field MUST
be set to zero. When a branching router finds that a multicast tree
has been changed due to member changes, the router SHOULD send a SIM
packet with "Delete flag" to remove unused downstream branching
routers.
10. SIM Tunnel
In preset mode, SIM can automatically create a SIM Tunnel between a
two branching router in order to decrease the number of routers that
need to maintain states, i.e. SIM FIB. SIM Tunnel will be used to
skip non-branching router. This automatic SIM tunnel is one of the
significant features of SIM. It can be created by using Jump flag on
SIM header.
Whenever the packets forwarded to non-branching router, the jump flag
will be set. When the packets reach the next SIM branching router
and the Jump flag is set, that SIM router will send a "Redirect
Message" to the previous SIM branching router.
Because the source address of outer IP header will be changed only
when the packets forwarded from the SIM branching router, SIM router
can know the previous SIM branching router from this source address
of the packets. When the SIM router received the redirect message,
it will put the next SIM branching router to the destination address
field instead of the neighbor SIM non-branching router. And, this
will create a SIM Tunnel during two SIM branching routers. The non-
branching routers have no need to maintain the SIM FIB entries. This
mechanism accelerates the forwarding process, and also reduces the
number of FIB maintained on SIM routers.
11. SIM Routers
A SIM router advertises its state to neighboring SIM routers by
multicasting SIM Hello message to local links. The interval time of
sending SIM Hello message is defined as SIM_HELLO_INTERVAL time. The
destination multicast address of a SIM Hello message is the assigned
class D address for all SIM routers (not yet assigned). A SIM
capable host also listen to SIM Hello messages to recognize SIM
routers.
Vasaka, et al. [Page 15]
Internet Draft draft-vasaka-xcast-sim-00.txt July 2001
In Edge-Core Model described in 7.3, edge SIM routers advertise their
states to each other by using interior gateway protocol or some other
protocols. If a branching router has a designated branching router,
the branching router advertises its designated branching router with
its state to edge SIM routers.
In Inter-AS Model described in 7.4, an ingress SIM router may
advertise its designated ingress router to the edge routers of
neighboring ASes by using exterior gateway protocol or some other
protocols.
All SIM routers maintain following states for neighboring SIM routers
or egress SIM routers in the same AS.
- RUNNING:
- This state means the SIM router is running perfectly.
- Any packet both in list mode and in preset mode can be
forwarded to this SIM router.
- FULL:
- This state means the SIM FIB table is full and no more SIM
FIB entry can be added for a while.
- Packets in list mode can be forwarded to this SIM router.
- Packets in preset mode cannot be forwarded to this SIM
router. So packets have to be duplicated for each receiver.
- DOWN:
- This state means the SIM router is down now.
- No packet can be forwarded to this SIM router. Packets have
to be duplicated for each receiver if possible.
12. Header Format
In the case of IPv4 packet, a SIM header (IPPROTO_SIM) is inserted
between the outer IPv4 header and the inner IPv4 header as in Figure
1. For the outer IPv4 header, the source address field is filled
with the sender adress or the previous SIM branching router (the
ingress router of SIM tunnel), and the destination address field
filled with the next hop SIM router or the egress router of SIM
tunnel. On the other hand, for the inner IPv4 header, the source
address field is filled with the original sender address, and the
destination field is filled with the group identification. When some
fields of the uppper-layer protocol such as port number and checksum
are different for each receivers, the SIM option header will be used.
SIM option header will come just after the SIM header. SIM routers
that act as the last branching point will use the information in SIM
option header to convert SIM packet to unicast packet, and send to
Vasaka, et al. [Page 16]
Internet Draft draft-vasaka-xcast-sim-00.txt July 2001
each receiver as described above.
+----------+-------------+-------------------+----------+------------+
| Outer_IP | IPPROTO_SIM | SIM_OPTS (if any) | Inner_IP | Upper Layer|
+----------+-------------+-------------------+----------+------------+
Figure 1
In the case of IPv6 packet, SIM information is embedded in Routing
Header. Here, we do not use IP tunnel as in IPv4, because it will
cause a big packet overhead. Instead of specifying sender address
and IP multicast address in the inner IP header, we put them in SIM
header. While forwarding along SIM routers, the source address field
and the destination address field in IPv6 Header will be rewritten in
the same way as the outer IP header in IPv4.
+--------------+-------------+-------------------+--------------+
| IPv6 Header | IPPROTO_SIM | SIM_OPTS (if any) | Upper Layer |
+--------------+-------------+-------------------+--------------+
Figure 2
The details of SIM header for both IPv4 and IPv6 packets are
described in Appendix A.
13. Interoperability with Existing Protocols
In the case where SIM is used with RSVP and IPv4, the order of
headers is: IPv4, RSVP, SIM, upper-layer headers. RSVP identifies a
flow by source address and multicast address of a SIM packet. If
port numbers are not zero, i.e. not substituted, they are also used
to identify a flow. If a SIM related headers are stripped off, a
flow is identified with normal RSVP rules.
In the case where SIM is used with Diffserv in an AS, if DSCPs for
receivers of a SIM packet are the same, just use the DSCP in the AS.
Otherwise, there are two options:
Option A) chose the bast DSCP if "the best" can be defined.
Option B) duplicate the SIM packet for each DSCP.
To use SIM with Header Compression [RFC2507] mechanism, compression
method for SIM related headers has to be defined.
14. Security Considerations
14.1 SIM FIB Attacks
Vasaka, et al. [Page 17]
Internet Draft draft-vasaka-xcast-sim-00.txt July 2001
It is possible for malicious nodes to send a SIM packet with a bad
receiver list in order to make confusion of SIM FIB management. It
is possible for malicious nodes to send a SIM packet with "Delete
flag" in order to schedule to remove a valid SIM FIB entry. Because
the malicious nodes may be able to receive packets or may be disturb
valid receivers to receive packets, some protection mechanisms need
to be deployed to protect valid SIM FIB entries from malicious nodes.
Strict update rules for SIM FIB entry might be a candidate. An
example of such rules is to prohibit updating a SIM FIB entry except
when routing change is detected. However, this rule might make
things worse because malicious nodes could send illegal SIM packets
with various generation counts before valid SIM packets are sent.
Another solution can be held in the same way that TCP generates the
initial sequence number, that is to generate the initial generation
counter randomly.
14.2 Using SIM as DoS attacks
As discussed in "Security Framework for Explicit Multicast" [SFEM]
some forms of DoS attackers can take advantage of the multicast
characteristics to increase their effects. Such an attack is the
smurf attack, which uses ICMP Echo request (ping) sending to a
multicast address with a source address that is the target of the
attack. The traditional multicast, which uses multicast address for
the destination address, deals with this problem by setting up a
router or a host not to reply ICMP requests with a multicast address.
In xcast model, the DoS effect is greatly diminished because of the
small number of members in a multicast group. However, the attacker
can use multiple multicast groups in order to create a DoS attack as
effectively as in the traditional multicast model. It will be more
difficult to deal with this problem, because the destination may not
recognize that it is the xcast traffic. One strategy they proposed in
"Security Framework for Explicit Multicast", is to use IPsec for
securing explicit multicast traffic. However, it only provides
confidentiality and/or authentication between sender and receivers.
It cannot restrict nodes that can forward packets to xcast routers.
Thus, it may not be a good solution to stop smurfing DoS attacks.
In the case of SIM, the same smurfing DoS attacks may be occurred.
The attacker may attack a host by using SIM packets to send ICMP Echo
request. However, similar to xcast protocols, SIM supports only small
group multicast, so we also can say that the smurfing DoS attacks may
not be effective. Even though, detection for this DoS attack will
probably be provided on SIM routers. Basically, at the last SIM
branching router, the source and destination fields of the packets
will be replaced with the sender unicast address and the receiver
Vasaka, et al. [Page 18]
Internet Draft draft-vasaka-xcast-sim-00.txt July 2001
address. Therefore, a receiver cannot distinguish the receiving ICMP
Echo request, whether it was originally SIM packet or was traditional
unicast packet. However, the last SIM branching router should know
the answer. Thus, the detection of this type of DoS attack should be
deployed on the SIM routers. When the last branching SIM router
duplicates a packet for each receiver, it should check "Protocol"
field of IP header for IP version 4. This "Protocol" field indicates
the next level protocol type. And, as assigned in RFC1700, ICMP has
the protocol number "2". Thus, SIM router should not forward the
packet and should discard it, if it detects that protocol field is
"2". In this strategy, all SIM branching routers have to check all
of the SIM packets. Thus it may generate more overheads on SIM
router. Moreover, this strategy can only alleviate the effect of
smurfing DoS attack, the strategy to deal with other kinds of DoS
attack needs more considertion.
14.3 Using IPsec with SIM
In this section, we focus on the possibility to providing secure
multicast traffic by using IPsec with SIM. To use IPsec [RFC2401],
we have to consider two issues: key distributing and packet encoding.
First we discuss about key distributing issue. Normally in case of
unicast traffic, the destination side of Security Association (SA) is
in charge of choosing a Security Parameter Index (SPI) for each
connection. However, in traditional multicast model, there are
multiple destination nodes and probably are multiple sources per
multicast group. As discussing in "Security Architecture for the
Internet Protocol" [RFC 2401] and in "Secure IP Multicast: Problem
are as, Framework, and Building Blocks" [SMUG], some mechanisms are
required to select an unique SPI for each multicast group. They may
be a Group Controller (GC) and Key Controller (KC) to create key
parameters, such as an SPI for a multicast group. In the case of
SIM, the size of group is small, the receivers can set their own SA
and choose a SPI, and send it the sender. However, they can have a
special node that will act as the SA and KC, and distribute the key
to each receivers in the group.
For packet encoding, IPsec uses two protocols to provide traffic
security, Authentication Header (AH) [RFC2402] and Encapsulating
Security Payload (ESP) [RFC2406]. AH is is used to provide
connectionless integrity and data origin authentication for IP
datagrams, and to provide protection against replays. ESP is used to
provide confidentiality, data origin authentication, connectionless
integrity, an anti-replay service, and limited traffic flow
confidentiality. Each protocol supports two modes of use: transport
mode and tunnel mode. In transport mode the protocols provide
Vasaka, et al. [Page 19]
Internet Draft draft-vasaka-xcast-sim-00.txt July 2001
protection primarily for upper layer protocols, while in tunnel mode,
the protocols are applied to whole tunneled IP packets. Moreover,
the primary difference between the authentication provided by ESP and
AH is that ESP does not protect any IP header fields unless those
fields are encapsulated by ESP in tunnel mode.
Now we discuss using AH and ESP respectively in both transport mode
and tunnel mode.
In transport mode, AH is applicable only to host implementations and
provides protection for upper layer protocols, and some selected IP
header fields. It is specified in RFC2402 that AH has to be inserted
after the IP header and before an upper layer protocol. If we apply
AH in transport mode to SIM, the packet header will be as following.
[Outer IP] [AH] [SIM Header] [Inner IP] [ Payload ]
In this way, SIM header will be covered by AH and cannot be modified
at each branching points. Therefore, SIM cannot be used with AH in
transport mode.
Contrary, in tunnel mode, AH protects the entire inner IP packet,
including the entire inner IP header. In this way, we still can
modify SIM packet header without giving bad effect to the original
AH. However, the receiver list in SIM header cannot be protected by
AH.
[Outer IP] [SIM Header] [AH] [Inner IP] [ Payload ]
Now we consider about applying SP to SIM. It is specified in RFC2406
that the ESP header is inserted after the IP header and before the
upper layer protocol header while in transport mode, or before an
encapsulated IP header in tunnel mode. If we applied ESP to SIM in
transport mode, ESP will be inserted to packet header as following.
[Outer IP] [ESP] [SIM Header] [Inner IP] [ Payload ]
In this way, SIM header will be encrypted, and SIM routers has to
decrypted it in order to access and modify the receiver list. Thus,
this ESP transport mode is infeasible.
Contrary, in tunnel mode, ESP will be located between SIM header and
inner IP header, therefore SIM routers still can access the receiver
list and modified it.
[OuterIP] [SIM Hdr] [ESP] [InnerIP] [Payload] [ESP Trailer][ESP Auth]
In concluding, SIM can be used with IPsec only in tunnel mode. That
Vasaka, et al. [Page 20]
Internet Draft draft-vasaka-xcast-sim-00.txt July 2001
means we have to deploy AH or ESP, encrypt and decrypt the packets on
every SIM routers. These procecure will cause more overhead and
should not work well. Moreover, even we can use IPsec to provide
confidentiality, data origin authentication, connectionless
integrity, an anti-replay service, and limited traffic flow
confidentiality, we still cannot unrevealed the receiver list and the
bitmap field in the SIM header. Some attacks still can be done by
spoofing the receiver list and modify flags in the bit map field for
malicious use.
Acknowledgments
The authors would like to thank Takuya Mogami and Yoshikuni Taki for
their valuable technical discussions. And, also Prof. Youki
Kadobayashi for his encouragement and insightful remarks.
References
[CLM] D. Ooms, W. Livens, "Connectionless Multicast",
<draft-ooms-cl-multicast-02.txt>, Apr 2000
[DCM] L. Blazevic, J. Le Boudec,
"Distributed Core Multicast (DCM): a routing protocol for many
small groups with application to mobile IP telephony",
<draft-blazevic-dcm-mobility-01.txt>, Jun 2000
[DCM99] L. Blazevic, J. Le Boudec, "Distributed Core Multicast (DCM):
a multicast routing protocol for many groups with few receivers",
ACM CCR Vol.29, No.5, Oct 1999
[ERM] J. Bion, D. Farinacci, M. Shand, A. Tweedly,
"Explicit Route Multicast (ERM)", <draft-shand-erm-00.txt>,
Jun 2000
[EXPRESS99] H.W. Holbrook, D.R. Cheriton, "IP Multicast Channels:
EXPRESS Support for Large-Scale Single-Source Applications",
SIGCOMM'99
[MALLOC] D. Thaler, M. Handley, D. Estrin, "The Internet Multicast
Address Allocation Architecture", RFC2908, Sep 2000
[MDO6] Y. Imai, "Multiple Destination option on IPv6(MDO6)",
<draft-imai-mdo6-02.txt>, Sep 2000
[RFC1700] J. Postel, "Assigned Numbers J. Reynolds", Oct 1994
[RFC2401] S. Kent, R. Atkinson, "Security Architecture for the Internet
Protocol", Nov 1998
[RFC2402] S. Kent, R. Atkinson, "IP Authentication Header", Nov 1998
[RFC2406] S. Kent, R. Atkinson, "IP Encapsulating Security Payload
(ESP)", Nov 1998
[RFC2507] M. Degermark, B. Nordgren, S. Pink,
"IP Header Compression", RFC2507, Feb 1999
[SDBM] C. Graff, "IPv4 Option for Sender Directed Multi-Destination
Vasaka, et al. [Page 21]
Internet Draft draft-vasaka-xcast-sim-00.txt July 2001
Delivery", RFC1770, Mar 1995
[SFEM] O. Paridaens, et. al., "Security Framework for Explicit
Multicast", <draft-paridaens-xcast-sec-framework-01.txt>,
Nov 2000
[SGM] R. Boivie, N. Feldman, "Small Group Multicast",
<draft-boivie-sgm-02.txt>, Feb 2001
[SM] R. Perlman, et. al., "Simple Multicast: A Design for Simple,
Low-Overhead Multicast", <draft-perlman-simple-multicast-03.txt>,
Oct 1999
[SMUG] T. Hardjono, et. al., "Secure IP Multicast: Problem areas,
Framework, and Building Blocks",
<draft-irtf-smug-framework-01.txt>, Sep 2000
[SSM] S. Bhattacharyya, et. al., An Overview of Source-Specific
Multicast (SSM) Deployment, <draft-ietf-ssm-overview-00.txt>,
May 2001
Authors Information
Vasaka Visoottiviseth
WIDE Project
c/o Graduate School of Information Science,
Nara Institute of Science and Technology (NAIST)
8916-5 Takayama, Ikoma, Nara 630-0101, Japan
E-mail: vasaka@wide.ad.jp
Yosuke Takahashi
WaterSprings.ORG / WIDE Project
1-6-11-501, Honjo, Sumida-ku, Tokyo, 130-0004, Japan
E-mail: t-yosuke@mtj.biglobe.ne.jp
Noritoshi Demizu
WaterSprings.ORG
1-6-11-501, Honjo, Sumida-ku, Tokyo, 130-0004, Japan
EMail: demizu@dd.iij4u.or.jp
Appendix A: Format
A-1. IPv4 receiver list
- IPv4 header:
- Destination address field = multicast address
- Protocol field = IPPROTO_SIM (to be assigned)
- DF bit = on
- IPPROTO_SIM:
Vasaka, et al. [Page 22]
Internet Draft draft-vasaka-xcast-sim-00.txt July 2001
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P|T|D|J|1| Res | gen_count | ndest | Bitmap |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Bitmap //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Receiver's Addresses //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// (Options if any) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- flags
- P: Preset flag
0: list mode
1: preset mode
- T: Temporary flag
1: members are temporary
- D: Delete flag
1: schedule to delete the SIM FIB entry
- J: Jump flag
1: the packet has passed non-branching routers
- 1: One receiver flag
1: there is only one receiver in the list
- Res: (Reserved)
- gen_count:
In the case where the members of receiver list
has been changed for the same combination of
source address and destination multicast address,
gen_count MUST be incremented by random value.
Initial vlaue SHOULD be random.
- ndest
Number of receivers
- Bitmap:
Appears only when B-flag is on.
Valid receiver's bit is set to 1
Length: 4 * (1 + (n-1)/32)
- Protocol: (8bit)
Upper layer protocol number
- Length: (8bit)
Length of SIM header / 4
- Checksum: (16bit)
One's complement
- Multicast Address
The same multicast address with initial destination address
- Receiver's Addresses
List of receivers
- options
See A-3.
Vasaka, et al. [Page 23]
Internet Draft draft-vasaka-xcast-sim-00.txt July 2001
A-2. IPv6 receiver list
- IPv6 header:
- Destination address field = multicast address
- Routing Header
- The difference between IPPROTO_SIM is that Protocol, Length
and Checksum fields are not in this header. Other fields
have the same meaning with IPPROTO_SIM.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Type=SIM | Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P|T|D|J|1| Res | gen_count | ndest | Bitmap |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Bitmap //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Receiver's Addresses //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Sender Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Previous hop (if P-flag is set set) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// (Options if any) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A-3. Options
- Partial Substitution Option:
- The fields that will be substituted in the upper-layer
protocol MUST be zero.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option type | Option length | Offset | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Data //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A-4. Control messages
- SIM Hello
Vasaka, et al. [Page 24]
Internet Draft draft-vasaka-xcast-sim-00.txt July 2001
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Status | (Padding) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Message Type:
Type of SIM control message
- SIM HELLO: 0
- SIM Redirect: 1
- Status:
Status of SIM router
- RUNNING: 0
- FULL: 1
- DOWN: 2
- SIM Redirect
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | ( Padding ) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next branching router IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Appendix B: Constants
SIM_FIB_INTERVAL: 10 seconds
SIM_FIB_AGING: 10 seconds
SIM_FIB_TIMEOUT: 60 seconds
SIM_HELLO_INTERVAL: 30 seconds
Vasaka, et al. [Page 25]
