Project Progression Specification
Abstract
Having carried out an initial router based implementation of PGM in FreeBSD, there are now a number
of possible directions in which the project can progress. This document discusses the various options
available and the considerations that must be taken into account.
ABSTRACT ............................................................................................................................................ 1
UPDATE LOG ........................................................................................................................................ 3
1.
INTRODUCTION .......................................................................................................................... 3
2.
REFERENCES ............................................................................................................................... 3
3.
PROPOSALS .................................................................................................................................. 3
3.1
USER SPACE RPGM ................................................................................................................... 3
3.2
OPERATING SYSTEM INDEPENDENCE ........................................................................................ 4
3.3
CONVERSION TO OBJECT–ORIENTED LANGUAGE ...................................................................... 4
3.3.1 Speed And Efficiency ............................................................................................................ 4
3.3.2 Examples of Object Orientation in routers ........................................................................... 4
3.4
RELIABLE MULTICAST TRANSPORT AREA................................................................................. 4
APPENDIX A ......................................................................................................................................... 5
GLOSSARY............................................................................................................................................. 5
2
Update Log
Date
29-12-2001
Name
Manish
Change
First Draft
1. Introduction
Following the implementation of the router functionality of the Pragmatic General Multicast (PGM)
protocol, there are a number of different ways in which the current implementation can be extended to
include further functionality.
This document outlines the list of ideas brought up during group discussions, along with any
considerations that must be taken into account.
2. References
[1] J. Chesterfield, A. Diana, A. Greenhalgh, M. Lad, M. Lim. rPGM. A Router Implementation of
Pragmatic General Multicast. UCL. September 2000.
[2] The XORP Extensible Open Router Platform. ICSI Center for Open Networking (ICON).
International Computer Science Institute. http://www.xorp.org
[3] The Click Modular Router Project. MIT. http://www.pdos.lcs.mit.edu/click/
3. Proposals
3.1 User Space rPGM
The current rPGM implementation has been carried out within the kernel’s space. Although this is an
acceptable location for the PGM router functionality to be placed, it does place some constraints on the
implementation itself.
 Firstly, kernel space resources are limited and although PGM has been designed to require minimal
storage, it still requires state to be stored within a PGM capable router. This state is dependent
upon the number of active PGM sessions passing through the router. Heavy traffic and usage could
lead to instability within the router and packet loss due to lack of available kernel resources.
 Potential problems or bugs within the implementation, or external factors conflicting with the
implementation, could destabilise the kernel. This is clearly unacceptable.
A proposal has been made to move the rPGM implementation into user space thus allowing it to act as
a daemon process that can be loaded or unloaded as necessary without affecting the kernel or requiring
machine reboots. The main considerations that must be taken into account for such a task are:
 A situation may arise where a machine is required to act as both a PGM capable router and a PGM
host. In such circumstances, consideration must be given on how incoming packets can be filtered
to ensure that they are passed to the correct process. A firewall type mechanism has been proposed
as a possible solution to divert packets to the correct process given a set of rules. This requires
further investigation before proceeding.
 Although rPGM would run within a self-contained process, it will still need to pass packets to and
from the kernel for forwarding (of NAK/NCF and SPM packets). The question raised here is
whether kernel modifications will still be necessary. If such modifications are necessary, careful
consideration must be given to the interfacing between the two. However, with a self-contained
process, it should be possible to use standard system calls for such interfacing and make use of a
firewall type mechanism to divert packets appropriately.
3
3.2 Operating System Independence
The current rPGM implementation has been carried out as an addition to the FreeBSD kernel.
Therefore the implementation language of choice was C and although custom data structures have been
created for state storage, extensive use is made of the BSD mbuf mechanism for storing and passing
packet data in memory.
One of the future goals of the project is to allow rPGM to run over different operating systems such as
Linux. In order for this to be achieved, it will be necessary for any BSD-specific parts of the code to be
replaced with generic code. This will involve:
 removing the current mbuf usage
 re-architecturing packet processing, handling and passing mechanism
3.3 Conversion to Object–Oriented Language
The proposal has been made to convert the implementation into an object-oriented one using C++. The
main concerns here are:
3.3.1 Speed And Efficiency
It should be remembered that this is a router-based implementation and so an implicit goal would be to
ensure that speed is not compromised. The router should handle packets as quickly as possible. Object
Orientation may compromise this, imposing delays in processing and reduced efficiency.
However, it is our opinion that the difference in speed is small enough to warrant serious consideration
toward such a code conversion. The main hit in performance will result from the move from kernel
space into user space.
An object-oriented approach within user space will allow for a more modular implementation of a
daemon or loadable module. Furthermore, it would be possible to make use of libraries such as the
Standard Template Library (STL) for data structures (for state information).
3.3.2 Examples of Object Orientation in routers
The various flavors of Unix (including BSD and Linux) are implemented in C, as are most commercial
routing software. Having said this, there are examples of object-oriented router implementations with
the XORP Platform [2], and the Click Modular Router Project from MIT [3].
By converting rPGM to an object-oriented implementation, a concern is that it may introduce some
potential problems in areas where interfacing with the kernel is necessary. However, as mentioned in
section 3.1, by encapsulating the implementation within a daemon process, it should only be necessary
to make use of standard system calls in order to pass the outgoing and incoming packets to and from
the kernel space. Any packet decapsulation work carried out would remain the same.
3.4 Reliable Multicast Transport Area
It is currently understood that within the Reliable Multicast Transport (RMT) area, there will be a
number of different kinds of reliable multicast solutions with different levels of router support, but with
similar basic building blocks for handling NAK spooression, providing services such as DLR, grouping
recievers into subsets etc.
Careful consideration must be given to this, and it has been proposed that the rPGM implementation
should be considered as an architectural framework for Reliable Multicast Router Assistance. The first
“plugin” would be PGM, but the API should be designed such that it is easy to add others. Data
structures should also be sufficiently generic to aid future progress within the area.
4
Appendix A
Glossary
DLR
NAK
NCF
PGM
RMT
SPM
Designated Local Repairer
Negative Acknowledgement
NAK Confirmation
Pragmatic General Multicast
Reliable Multicast Transport
Source Path Message
5