Previous

Content

Next 

7.0.- A Reference Implementation using GateD

  
In this section, a report on the experience gained from implementing the issues specify in this document using the GateD environment is done.

The Gate Daemon (GateD) Program
GateD is a popular, public domain program that provides a platform for implementing routing protocols on hosts running the Unix operating system. The software distribution includes an implementation of the OSPF protocl.
All GateD processing is done within a single Unix process, and routing protocols are implemented as one or several tasks. GateD maintains a single routing table that contains routes discovered by all the active routing protocols. Multiple routes to the same destination are prioritized according to a set of rules and administrative preference and only a single route is active per destination. These routes are periodically downloaded in the host's kernel forwarding table.
Implementing the QoS Extensions of OSPF
Design Objetives and Scope
QoS extensions were localized to specific modules and their interaction with existing OSPF code was kept to a minimum. Some of the important assumtions/requirements were:
  1. Support for only hop-by-hop routing. The path structure is the QoS routing table only needs to store next hop information.
  2. Support for path pre-computation. A new separate QoS routing table was created with its associated path structure.
  3. Full integration of the QoS extensions into the GateD framework.
  4. Ability to allow experimentation with different approaches.
  5. Decoupling from local traffic and resource management components; i.e., packet classifiers and schedulers and local call admission.
  6. Interface to RSVP. RSVP is the mechanism used to request routes with specific QoS requeriments.
  

Some simplyfying assumptions were:
  1. The scope of QoS route computation was limited to a single area.
  2. All interfaces on a router were assumed to be QoS capable.

Architecture
The architecture is shown in the next figure:

it consists of three major components:
  1. A signaling component (RSVP in this case).
  2. A QoS routing component.
  3. A traffic manager.

The QoS routing component is further subdivided into the following modules:
  1. Update trigger module which determines when to advertise local link state updates. Implements a variety of triggering policies:
     
     
    1. Periodic triggering.
    2. Threshold based triggering.
    3. Class based triggering.
    		  

    Also implements a hold-down timer that enforce minimum spacing between two consecutive updates triggering from the same node.
     

  2. Pre-computation trigger module determines when to perform QoS path pre-computation.
     
  3. Path pre-computation module computes the QoS routing table based on the QoS specific link state information.
     
  4. Path selection and management module selects a path for a request with particular QoS requeriments, and manages it once selected, i.e., reacts to link reservation failure.
     
  5. QoS routing table module implements the QoS specific routing table, which is maintained independently of the other GateD routing tables.
     
  6. Tspec mapping module maps reques requirements expressed in the form of RSVP Tspecs and Rspecs into the bandwidth requeriments that QoS routing uses.

Major implementation issues
 
Previous

Content

Next