The Computer Communication Lab (236340)
Winter 2003-2004
Protocol Independent Multicasting – Sparse Mode (PIM-SM)
Submitted by:
Mahmoud Agbaria
Khalil Shalash
Tarek Elias
Tamim Nassar
smahmod1@t2
skhalils@t2
sadel@t2
stommy@t2
Content:
1. Introduction
2. General Layout and Overview
3. Modules
4. Estimated project timetable
1. Introduction
The purpose of this project is to simulate a network with routers that support PIMSM. This simulation gets from an ini-file the network architecture, and displays the
network. Routers can perform 'Join' 'Leave' and Data multicast. A router is connected
to a group of hosts. You will have to write a PIM-SM application over Layer 3, and to
implement a layer 3 maintenance application that can encapsulate multicast messages
as needed by PIM-SM.
PIM-SM Multicast Routing Protocol
Protocol Independent Multicast-Sparse Mode (PIM-SM) routes multicast packets to
multicast groups, and is designed to efficiently establish distribution trees across wide
area networks (WANs) where multicast groups are sparsely distributed. PIM-SM is called
“protocol independent” because it can use the route information that any routing protocol
enters into the multicast Routing Information Base (RIB) – in simple words because it is
a router-to-router protocol.
PIM-SM assumes that no host wants data unless it is explicitly requested. PIM does,
however, have a dense-mode counterpart (PIM-DM) that is interoperable with sparse
mode.
Source1
Source2
RP
R2
R1
R5
R6
R4
R7
R3
Host1
Host3
Host2
Host4
Group G
Generic Routing Encapsulation (GRE)
Theoretical overview:
Generic routing encapsulation (GRE) is a mechanism for encapsulating any network
layer protocol over any other network layer protocol.
In the general case, a network layer packet, called the payload packet, is encapsulated in
a GRE packet, which may also include source route information. The resulting GRE
packet is then encapsulated in some other network layer protocol, called the delivery
protocol, and then forwarded.
The Format of a packet with GRE encapsulation:
The only specific standard for GRE encapsulation is IP over IP and this is the standard
supported by the switch. GRE allows hosts in one private network to communicate with
hosts in other private IP network by effectively providing a tunnel between switches
across an internet. For example below, IP packets from the private IP network 2.2.20
destined for a host in the private IP network 4.4.4.0 are encapsulated by Switch A and
forwarded to switch B. Intermediate switches route the packets using addresses in the
delivery protocol header. Switch B extracts the original payload packet and routes it to
the appropriate destination within network 4.4.4.0.
The GRE packet header has the form:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|
Reserved0
| Ver |
Protocol Type
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Checksum (optional)
|
Reserved1 (Optional)
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1. Checksum Present (bit 0)
If the bit is set to one that means the Checksum and the
Reserved1 fields are present and the Checksum field contains
Valid Information.
2. Reserved0 (bits 1-12)
3. Version Number (bits 13-15)
The Version Number field MUST contain the value zero.
4. Protocol Type (2 octets)
The Protocol Type field contains the protocol type of the
Payload packet.
5. Checksum (2 octets)
The Checksum field contains the IP (one's complement) checksum
Sum of the all the 16 bit words in the GRE header and the
Payload packet.
6. Reserved1 (2 octets)
The Reserved1 field is reserved for future use.
In many network scenarios you will want to configure your network to use GRE tunnels
to send Protocol Independent Multicast (PIM) and multicast traffic between routers.
Typically, this occurs when the multicast source and receiver are separated by an IP
cloud which is not configured for IP multicast routing. In such network scenarios,
configuring a tunnel across an IP cloud with PIM enabled transports multicast packets
toward the receiver.
2. General Layout & Overview
PIM
Module
GRE sub-module
Network
Module
Router
Manager
Module
RAW
socket
GUI
Module
Graphics
Library
RAW sockets and IP channel override:
In our simulation of the PIM-SM protocol we simulate the protocol, that runs on a
network with several routers and hosts that have different IP addresses, on one computer
with one IP address. Therefore, we have a problem, which is, how to send packets to the
simulate routers while we have only one IP address. The solution of the problem is the
use of the RAW sockets. The purpose of using RAW sockets is to capture the messages
before they arrive to the IP layer while sending and receiving packets from/to the routers.
When a packet is intercepted, we send it to the MAC with a new destination IP address
(the real IP).
When the RAW socket receives the packet from the MAC, it extracts the IP packet from
the payload, then, it determines the “virtual IP” of the destination, and sends it to the
appropriate router process.
By achieving this, we can build routers in the application layer and give each router a
“virtual” IP according to its process id (PID) while using only one real IP address, to send
and receive packets.
Host1
Host2
R1
Host3
Source1
R2
R3
Manager
3. Modules
1. Network module
2. Manager module
3. PIM module
4. GUI module
Host4
Source2
R4
3.1. Network module:
The network is a continuous set of inter-connected routers. Our routers will run the PIMSM protocol to determine the flow of packets as a result of multicasting packets from a
set of sources to sets of groups of receivers; and also as a result of sending PIM-SM
control messages that maintain the SPT and RPT trees of the protocol. Each router will
run on a separate process, and will have a unique IP address mapped from its own
process ID (PID).
In addition, the router counts the number of packets that pass through it, acquiring
statistical data, that will be printed by the program.
The Router:
Attributes:




The list of the router’s interfaces.
The list of hosts connected to the router.
The routing table of the router.
Variables for statistical purposes.

receive_packet():
Functions:

Router receives a packet and calls the appropriate
PIM functions. This function runs an infinite loop,
and listens to incoming packets. When the router
receives a packet, it passes it over to the PIM
module, so that it would run the PIM protocol on
the packet.
send_packet(packet P, address Dst): Router sends the packet P to
destination address Dst.
3.2. Manager module:
This module runs on a separate process and is responsible for delivering the IP packets
that are sent from one router to another. The manager does this by intercepting the
packets that are sent by the routers and sending them in an IP packet to the same address
of the computer. When the packets return from the MAC, it extracts the IP packet from
the payload and sends the packets up to the right router in the right process. Another
function of the manager is to send join/leave/multicast messages randomly in order to
simulate traffic and topology changes in the network.
Also this module is responsible for initializing the system and for printing the statistical
results.
Functions:







host_join(host H, group G): Host H requests joining group G.
host_leave(host H, group G): Host H requests leaving group G.
multicast(host S, group G, message M): Source S wants to multicast
message M to group G.
encapsulate(packet P):
Encapsulates a packet with GRE.
De_encapsulate(packet P): De-encapsulates a packet.
Initialize(FILE* input):
Initialize the network.
Print_results():
Prints the statistics: Throughput, number of
packets sent by each router and other
statistics.
How does the Channel manager work?
Manager
Real IP of
computer
IPIP R1R2 S  G data
This IP packet is sent
over IP to self address
Multicast
packet
This way we intercept the packet that the application wants to send before it goes to the
IP layer, and then send it as data in an IP packet with our IP address; and intercept an
incoming packet, and determining by the virtual IP the PID we need to send the packet to.
3.3. PIM module:
This module is the “brain” of the PIM/SM protocol. It receives IP packets from the
Router and given the router’s routing tables and interfaces, this module returns a
processed IP packet to the router with a list of addresses for the packet to be sent to.
The PIM protocol determines what packet is to be sent or how it would look like(because
a packet can be encapsulated inside the PIM protocol for unicast sending) and the IP
addresses of the next routers on the path to the receivers. This information is received by
the PIM module.
After getting this information, the PIM module invokes the “send_packet” function of
the router, and sends the new packet to the IP addresses it received from the protocol.
Periodically, the PIM protocol wants to send control packets to the other routers in the
network. The router listens for these packets and uses the “send_packet” function of the
router to send them to the appropriate routers.
A sub-module of this module is the GRE sub-module.
The GRE design
This paper handles the GRE encapsulation/de-encapsulation inside the PIM/SM protocol,
and does not relate to the actual sending of packets by the routers.
Our implementation will be based on IP over IP, and is as follows:
Delivery Header
GRE Header
Payload (Original) Packet

IP Header
GRE Header
IP Header (Payload packet)
Payload (Payload packet)
The data structures:
1. IP header:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service|
Total Length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Identification
|Flags|
Fragment Offset
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live |
Protocol
|
Header Checksum
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Source Address
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Destination Address
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Assuming that the routers have LITTLE_ENDIAN CPUs:
typedef struct ip_hdr
{
unsigned char ip_ headlen:4,
ip_ ver:4
// IP version & length
unsigned char ip_tos;
// IP type of service
unsigned short ip_totallength;
// Total length
unsigned short ip_id;
// Unique identifier
unsigned short ip_offset;
// Fragment offset field
unsigned char ip_ttl;
// Time to live
unsigned char ip_protocol;
// Protocol(TCP, UDP, etc.)
unsigned short ip_checksum;
// IP checksum
unsigned int ip_srcaddr;
// Source address
unsigned int ip_destaddr;
// Destination address
} ip_hdr;
2. GRE header:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|
Reserved0
| Ver |
Protocol Type
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Checksum (optional)
|
Reserved1 (Optional)
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
typedef struct gre_hdr
{
unsigned short gre_flags;
unsigned short gre_proto;
unsigned short gre_checksum;
unsigned short gre_reserver1;
} gre_hdr;
3. IP packet:
typedef struct ip_packet
{
ip_hdr ip_header;
char* data
} ip_packet;
// Checksum present + Reserver0 + Version
// Protocol field
// GRE checksum field
// IP checksum
//The IP header
//The payload
The size of the packet can be obtained using the “ip_totallength” field from the IP header.
Note: A GRE packet is an IP packet, where the protocol specified in the Protocol field in
the IP header is IPPROTO_GRE, defined as 47 in [RFC1700].
Methods:
 ip_packet * encapsulate(ip_packet *packet);
This function encapsulates the given IP packet inside a GRE packet. The building of the
GRE packet is as follows:
encapsulated_packet = outer_ip_header || gre_header || inner_ip_header || payload
where:
outer_ip_header is a new IP header with the appropriate fields.
gre_header is the GRE header for the encapsulation.
inner_ip_header is the IP header of the packet that we want to encapsulate.
payload is data of the IP packet that we want to encapsulate.
 ip_packet * de_encapsulate(ip_packet *packet);
This function de-encapsulates a given packet, removing its outer IP header and GRE
header, returning the encapsulated IP packet (the inner IP header + the payload).
Sending the packets:
Since we are doing a simulation where all routers are processes in the same computer,
thus we have a problem of sending messages from one router to another, because we have
one IP for the computer, that includes all routers. Therefore, in order to send a packet
from one router to anther, we send the packet together with its IP header to the IP address
of our computer.
Using a raw socket, we can intercept the packet, retrieve the IP header, from which we
can find the right process to send the packet to.
3.4. GUI module:
The purpose of this module is to give a visual view of the PIM/SM protocol’s
functionality. The design of this module is not yet complete, however, it will be built of a
graphics library that would help us build the network graph, and represent the flow of the
algorithm.
Also this module will help us build random graphs, calculate routing tables and initialize
the PIM and Router modules.
4. Estimated project timetable:
27.11 - 10.12 (2 weeks)
Program Initializer (Manager module) + Data structures of
routers + GUI.
11.12 - 24.12 (2 weeks)
PIM implementation + GUI(cont.).
25.12 - 07.01 (2 weeks)
RAW socket + GRE encapsulation.
08.01 - 21.01 (2 weeks)
All is finished
25.01
Final report submission