James Lee
Columbia University
New York, NY
USA
jl1341@columbia.edu
Amit Kaul
Columbia University
New York, NY
USA
ak946@columbia.edu
TRIP, Telephony Routing over IP, is a protocol for advertising between telephony destinations, the reachable routes in a domain. TRIP is based on the Border Gateway Protocol (BGP-4) for the exchanging of routing information between location servers. In this project, we have implemented TRIP, based on the specification of the protocol. We demonstrate that the location servers implemented communicates with other LS's and advertises routing information through the TRIP protocol.
In this project, we demonstrate the implementations of TRIP and the LS servers that advertises reachable routes to one another. The LS define in the project closely follows the specifications for TRIP. It includes a finite state machine consists of six states, Idle, Connect, Active, OpenSent, OpenConfirm, Established. The first three states concerns about the connection of LS's with its peers. Different events, e.g. Start, expired timer, causes states to change from one another. OpenSent is the state when an Open message is sent over the connection to the peers. If all Open messages are received, in OpenConfirm state, a KEEPALIVE message is awaited in response to the OPEN message. If everything is successful, in the Established state, the LS will be able to exchange UPDATE, NOTIFICATION and KEEPALIVE messages.
Four types of messages supported are OPEN, UPDATE, NOTIFICATION, and KEEPALIVE. Open messages advertise the TRIP information of an LS to its peer when a connection is made. An UPDATE message is sent to update its routing information at the peer. A NOTIFICATION message is sent in case an error is encountered once the connections are established. Finally, the KEEPALIVE messages are sent in response to OPEN messages to determine if the peer LS is still reachable.
In the project, we show the implementation of TRIP stack, which the location servers uses. The finite state machine of the LS's are designed as above. A parser in the TRIP core parses the different messages that are received from the peer LS. The parser is able to parse off the header fields of these message and checks its validity. Location servers also can be executed in three different type of sessions, send only, receive only, send/receive. Routes exchange will occur only in send/receive sessions for obvious reasons.
Finally, this project will use testing tool to demonstrate the running of the LS's.
TRIP was designed to address the problem of locating gateways and routing in IP telephony. Because it may not be possible to keep a global directory for destinations, since different policies exist along one IP path of many different nodes. TRIP address this by allow the destination routing information and the locations of gateways to be held and exchange between each location servers. This is done by connecting each LS's with numbers of peers and exchange the local information between them.
The implementation is based on Jonathan Rosenberg, et. al's draft of the TRIP protocol. In this work, a detailed mechanisms and workings of TRIP and the LS's finite state machine is given. The internet draft [1] are of November of 2000.
The TRIP architecture spans several modules. The 4 main modules (packages) that this implementation is build on are the utility module, TRIP core, LS functions, and testing module. The language chosen for the implementation is C++.
The utility module provides the tools, such as making connections between hosts, spawning new threads for these connections, tools for timeouts when it occurs, and read/write operations on sockets. These tools are used by the LS's for these specific purposes.
The TRIP core is the module responsible for the handling of different messages that are exchangeable between each LS servers. The 4 messages defined in this module are OPEN, KEEPALIVE, UPDATE, and NOTIFICATION. Each is discussed in detail in the TRIP specifications. Headers that exists in each of these types of messages needs to be parsed into relevant fields once a LS receives these messages. The parsing of these headers and messages, in general, also exists in this module. Diagrams below show the structures of the OPEN and UPDATE messages:
Figure1. TRIP Open Message
Figure 2. TRIP Update Message
The LS functions describes the functionalities in a location server. An LS contains a finite state machine, which defines the set of states that it could be in. These states are defined in this module. The set of actions that takes place in these states are also defined in this module, e.g. connect retry, keep alive, ... etc.
The testing module contains all the tools for the tests conducted in implementing TRIP. These test include peer session testing, update messaging testing, LS locating, and TRIP id testing. The peer session testing examines the connection for two peer LS's and their communication.
Besides the 4 main modules, the implementation also contains make utilities for building the executables in both Solaris and Linux operating systems.
The link to the program documentation can be found here.
Tests has been conducted to examine the workings of the protocol. The peer session testing reveals that a LS is able to connect with its peers (both opening the connection to a peer and accepting the requesting connections) and update it's states upon a trigger event. The update message test examines the sending and receiving of an update message and the correct updates that are done at the location servers that receive the updates. The LS locator help locate an running LS and the TRIP ID test checks a location server by its TRIP ID.