Browse Prior Art Database

Routing Services Platform Disclosure Number: IPCOM000014330D
Original Publication Date: 2001-Aug-09
Included in the Prior Art Database: 2003-Jun-19
Document File: 5 page(s) / 272K

Publishing Venue



1. Introduction

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 51% of the total text.

Page 1 of 5

Routing Services Platform

1. Introduction

The Routing Services Platform (RSP) is a framework for generic
services like Intrusion Detection, Traffic Engineering, Topology
etc., based on multi-protocol topology gathering
and analysis. RSP is divided into two main parts. The RSP kernel
provides routing-protocol independent topology information. This
information is then used by RSP service applications that provide
a broad range of services to the users. This document contains
some notes on the design of the RSP kernel. Service applications
are not discussed here.

The RSP kernel functions can be divided into functions that are
independent of specific routing protocols and into functions that
directly depend on a specific routing protocol. As such, it is
very similar to the UNIX file management subsystem, which
provides generic functions such as open, read, write, close on a
multitude of different file systems such as UFS, ISO-9660, VFAT,
FAT, NFS etc. Therefore, the design of the RSP kernel is done
using the same principles as the design of the UNIX file
management subsystem.

2. Architecture Overview

Figure 1 gives an overview of the Routing Services Platform. The
framework is divided into two parts called Topology Server (TS)
and Topology Feeder
(TF). Each TF executes a single routing
protocol engine, such as OSPF, PNNI, OSPFv6, etc. The TFs peer
with routers and switches in order to gather topology
information. As such, they execute only a fraction of the overall
routing protocol functions, such as the initial hello as well as
the database synchronization part. They do not contain topology
databases and they don't calculate routes or participate in the
peer group leader election process. The topology feeders
interface to the topology server using the Feeder/Server
(F/S interface).


Page 2 of 5

Figure 1: Routing Services Platform Overview

The TFs map topology information from its native format e.g.
PNNI PTSEs, OSPF LSAs, etc. to a generic, routing protocol
independent format called virtual Topology Information Element
(vTIE). vTIEs are generic enough to contain the relevant
topology information of all supported specific routing protocols.
vTIEs are the only information elements that are forwarded from
the TFs to the TS over the F/S interface.

The topology server stores vTIEs in topology databases. The
content of these databases is used to model a representation or
graph of the topology. Each TS creates a single topology graph,
even if multiple feeders provide topology information. In a
hierarchical network, for instance, a topology feeder could be


[This page contains 1 picture or other non-text object]

Page 3 of 5

placed in each routing area and feed vTIEs into various topology
servers. Thus, a topology server could collect topology
information steming from multiple topology feeders. The TS then
is able to create a single topology that provi...