Project Progression Specification



Download 26.15 Kb.
Date28.05.2018
Size26.15 Kb.
#51994



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.1User Space rPGM 3

3.2Operating System Independence 4

3.3Conversion to Object–Oriented Language 4



3.3.1Speed And Efficiency 4

3.3.2Examples of Object Orientation in routers 4

3.4Reliable Multicast Transport Area 4



Appendix A 5

Glossary 5




Update Log


Date

Name

Change

29-12-2001

Manish

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.


  1. 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/


  1. Proposals

    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.



    1. 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



    1. 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:

      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).

      1. 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.


    1. 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.

Appendix A

Glossary


DLR

Designated Local Repairer

NAK

Negative Acknowledgement

NCF

NAK Confirmation

PGM

Pragmatic General Multicast

RMT

Reliable Multicast Transport

SPM

Source Path Message






Download 26.15 Kb.

Share with your friends:



The database is protected by copyright ©ininet.org 2024
send message
    Main page
current implementation