TRIP Tutorial

By: Cisco, November 2000

Main Capabilities of TRIP

TRIP (Telephony Routing over IP, RFC 3219) is a policy driven dynamic routing protocol for advertising the reachability of telephony destinations, and for advertising attributes of the routes to those destinations. TRIPs operation is independent of any signaling protocol, hence TRIP can serve as the telephony routing protocol for any signaling protocol.

TRIP is a routing protocol based on a well-known Internet routing protocol called BGP-4 that forms much of backbone of the Internet today. Like BGP-4, TRIP is a protocol that helps in exchange of routing information among various "TRIP Speakers". TRIP Speakers, also called Location Servers, exchange and store routing information for reachability of telephony prefixes. Session Protocols like H.323 can then query the Location Server for routes to reach a particular telephony prefix. It is possible that the session protocol might be located on an entity, typically a gateway or gatekeeper in case of H.323, while the Location Server may be running on a separate entity. In this case a RAS like protocol can query the Location Server (analogous to an LRQ-LCF exchange).

TRIP introduces a concept of IP Telephony Administrative Domains ( ITADs ). An ITAD is a set of resources consisting of gateways and at least one TRIP Location Server (among other VoIP elements ) that are controlled by a single authority. In an H.323 Network, an ITAD could consists of a set of H.323 gateways interested in advertising prefixes via the TRIP Speaker. Gateways interested in advertising the prefixes they terminate can "register" with the TRIP Speaker. Protocol for such registration is not specified. A RAS like protocol can be used for such purposes.

An ITAD can span multiple H.323 zones. On the other hand, an ITAD may or may not have the same boundaries as that of an Annex-G domain. A TRIP speaker communicates with other TRIP speakers, both within the same ITAD ( intra-domain ) and to speakers outside the ITAD ( inter-domain ).

TRIP Peers

A TRIP Speaker establishes intra-domain and inter-domain "peering sessions" with other TRIP Speakers to exchange routing information. The peering sessions are established to exchange routes to telephony destinations. Two peers update each other of new routes they learn. Each peer may in-turn learn about new routes from other peers or through gateways registering telephony prefixes to them or through a static configuration on the Location Servers. The peers also "withdraw" the routes they advertised to the other peer on learning about the unavailability of the routes. TRIP does not require periodic refresh of the routes. The speakers periodically exchange keep-alive messages to ensure that the peers are operational.

TRIP peering sessions use TCP for transport. Thus the reliability of information is ensured.

Apart from conveying the telephony destinations ( prefixes ) that a Location Server can reach, a routing update also carries some more information about that route, called the "attributes" associated with the route. As will be discussed later, these attributes are helpful in describing characteristics of the route as well as in correct operation of the protocol. They also help in enforcing policies and network design.

TRIP qualifies inter-domain sessions as running E-TRIP sessions ( External TRIP ) and intra-domain sessions as I-TRIP (internal TRIP ).Figure 1 shows two ITADs. ITAD 1 has two Location Servers. Gateways G1 and G2 register with LS2 and Gateways G3 and G4 register with LS1. LS1 and LS2 have I-TRIP peering. LS1 peers with LS3 in ITAD2 ( E-TRIP peering ).

Internal TRIP uses a link state mechanism to flood database updates over an arbitrary topology. An attempt is made to synchronize routing information among TRIP LSs within an ITAD to maintain a single unified view. To achieve internal synchronization, internal peer connections are configured between LSs of the same ITAD such that the resulting intra-domain Location Server topology is connected and sufficiently redundant. When an update is received from an internal peer, the routes in the update are checked to determine if they are newer than the version already in the database. Newer routes are then flooded to all other peers in the same ITAD.

While updates within an ITAD are flooded onto internal peers, External TRIP updates are point-to-point.

TRIP updates received by an ITAD X from ITAD Y can be passed on to ITAD Z with or without any modifications ( with X and Z not sharing any peering relation ). Thus a route "advertisement" might reach a peer after hopping through various TRIP Speakers in different ITADs. The list of ITADs through which an update traverses for a given route is recorded in an attribute associated with that route, called the AdvertismentPath. Each route also has a "NextHopServer" attribute associated with it. It signifies the address of the next signaling entity that needs to be contacted in order to setup a call. It is upto the LocationServer at the boundary of the ITAD if it wants to add a new signalling element in the signaling path for the route in question. For example, an LS could change the NextHopServer for all the routes that it is disseminating to point to a gatekeeper so that all the calls for destination prefixes in that ITAD land on the gatekeeper for billing purposes. In order to do this, the LS would overwrite the NextHopServer of the route ( with the address of this new signaling element ) before sending out the update to its peers. Thus, a signaling message ( like H.225 Setup ) for a given telephony destination shall only go through ITADs which have changed the NextHopServer attribute for the route in question. This list of ITADs is recorded in another attribute called RoutedPath.

A TRIP Speaker on the boundary of the ITAD may optionally "aggregate" some routes before sending out a routing update to an external speaker. In Figure 1 we see LS1 aggregating routes from G1 ( 8581* through 8587* ) and G2 ( 8588* through 8580* ) before sending the ETRIP update to LS3 as a 858* route.

Thus TRIP can be used for inter-domain as well as intra-domain routing. It is also possible to use TRIP on a gateway as a registration protocol. When used in this way, the TRIP Protocol shall run on the gateway in a "send-only" mode, only sending routing information ( prefixes supported by the gateway ) to it's peer ( a Location Server ).

Routes and Route Selection

A route in TRIP is defined as the combination of (a) a telephony destination addresses, given by an address family indicator and an address ( telephony ) prefix and (b) an application protocol (e.g H.323, SIP, etc.). The transport address associated with this telephony destination is included in the "NextHopServer" attribute of the route. TRIP supports two address families: POTS numbers and Routing numbers. POTS numbers address family is a super set of all E.164 numbers, national numbers, local numbers and private numbers. The type of POTS number (private, local, national or international) can be deduced from the first few digits of the POTS prefix. Routing Numbers family is used to represent routing numbers used in conjunction with Number Portability. Routing Numbers are used to identify switches and line cards in the switches. It is possible to extend TRIP to support new address families if needed.

As mentioned earlier, TRIP is a general routing protocol that can be used for disseminating reachibility information of telephony destinations, irrespective of the application (signaling) protocol in use. The TRIP Location Server can be queried to fetch a route for a particular telephony prefix and application protocol combination.TRIP supports four application protocols: SIP, H.323-Q.931, H.323-RAS, and H.323-Annex-G. Thus TRIP can help in propagation of routes even when RAS or H.323-AnnexG is used ( For illustrative examples, please refer to the section "TRIP in an H.323 Network" )

A Route Selection algorithm runs on the Location Server. The purpose of this algorithm is to generate the best route for a given prefix (and application protocol) based on the information stored in the database. LS returns this as the route for a prefix when queried by an application protocol. The route thus obtained is also the one to be advertised by the LS to its peers, subject to policy configuration. The algorithm comes into play whenever some routing information changes because of new routing updates, introducing or withdrawing routes to certain prefixes. It bases it's decision on certain attributes associated with the routes that define the characteristics of the path associated with the route.

The notion of attributes in TRIP plays an important role in correct and efficient functioning of the protocol. The RoutedPath attribute is used to specify the intermediate ITADs to be taken by the signaling protocol to reach the destination prefix. RoutedPath may be used in selection of a route when multiple routes are present: An LS may prefer route with a lower number of ITADs in the RoutedPath attribute so that a signaling call has to go through minimal hops. An Advertisement Path traces the ITADs that a route advertisement ( update ) has traveled so far. AdvertisementPath is useful in detecting loops in the routes. Local Preference attribute helps in determining a particular LS's preference for a route. This can help divert intra-domain signaling traffic to a particular ETRIP peer when more than one route for a telephony destination is available. Diversion of traffic might be helpful if signaling elements in a certain neighboring ITAD have higher capacity to handle signaling traffic. TRIP also supports load balancing of traffic across two or more links between two ITADs. This is achieved by the use of an attribute called MultiExitDisc. Other attributes like Atomic Aggregate and Communities are also helpful in facilitating efficient routing. Thus attribute information can be very helpful in traffic engineering of networks.

The TRIP specification lends itself to extensibility by defining new attributes. For example attributes for defining cost and capacity could be added in the future. Codes for the new attributes can be obtained from IANA.

As mentioned earlier TRIP, like BGP, is a policy driven protocol. For a peering session, it is possible to define filters for incoming and outgoing routing information. For example, a Location Server may want to accept a routing update only if the attributes associated with the route suggests that the signaling protocol traffic will not traverse through certain ITADs. This can be ensured by checking the RoutedPath attribute for the prohibited ITADs as soon as the routing update is received on the ETRIP session.

This ability to filter routes based on attributes ( for both incoming and outgoing updates ) can be very helpful in planning and optimizing network designs for capacity planning and fault-tolerance. It can also come handy in enforcing settlement rules between administrative domains.

Security in TRIP

Since TRIP LSs peer with each other to exchange routing information that is critical to the correct and efficient operation of an ITAD, it is important that TRIP safeguard itself from any unauthorized peering or "sniffing" of the information being exchanged. TRIP suggests the use of IPSec to secure information. IPSec is a standardized security mechanism available for IP networks.

TRIP also takes care of protecting TRIP Routes from being tempered by an unauthorized entity. In many situations, an LS receives a route, which has been originated by remote LS that is not a direct peer of the receiving LS. In addition, attributes may have been inserted or altered along the advertisement path. The receiving LSs may wish to authenticate the route by verifying both the originator of an attribute and fact that the contents of the attribute have not been altered by other intermediate LSs. The Authentication attribute carries a list of signatures so that a receiving LS may validate particular attributes.

TRIP in an H.323 Network

In this section, we address how TRIP can be incorporated into the H.323 world to offer a call routing solution. We first look at how the H.323 network would look like and then demonstrate using sample call flows, how TRIP can be used to route a call.

An Internet Telephony Administrative Domain (ITAD), as it applies to H.323, can be thought of as constituting one or more H.323 zones. An ITAD encompassing an H.323 network can have one or more TRIP Location Servers (LS), H.323 Gateways, one or more Gatekeepers and Annex G Border Element(s). These Location Servers could exist as stand-alone entities in the network or could be co-located with one of the H.323 network entities (for example, with a Gatekeeper)

When a call is to be placed, it is possible for any H.323 entity to query the TRIP LS to fetch the best route for that telephony prefix. The protocol to query a TRIP speaker is unspecified. A RAS-like protocol could be considered for this purpose. Also, the H.323 entity to interface with the TRIP LS should be determined based on the design of the H.323 network.

In response to a query, a TRIP LS could return a route specifying one of the following H.323 signaling protocols to be used to contact the Signaling Server on the next hop -- H.323-Q.931, H.323-RAS or H.323-AnnexG. This means that to progress with the call set up for that telephony prefix, the querying entity would be required to establish a session with the Signaling Server provided using the specified signaling protocol.

The rest of the document discusses some call scenarios demonstrating the use of TRIP in routing a call in an H.323 Network.

Call Flow with H.323-Q.931 in a TRIP route

Figure 2 shows ITADs ITAD1 and ITAD2, each having a TRIP Location Server. The gateways in each ITAD register the telephony prefixes that they can terminate with the corresponding LS. In addition, the gateways are setup to query the TRIP LS when a call is to be placed. We have a sample call flow demonstrated below, where a call from the PSTN is handled by querying TRIP by the gateway. The following are the steps taken to route a call in this scenario.

1. Gateway G3 in ITAD2 receives a call for prefix 619* from the PSTN
2. G3 queries LS2
3. LS2 returns a route {NextHop:G1, Signaling:H323-Q931}
4. G3 sends a Q.931 SETUP message to Gateway G1

Call Flow with H323-RAS in a TRIP route

In this case, we consider a topology similar to the previous case, but with the inclusion of Gatekeepers ( Figure 3 ). The network consists of two H.323 zones, with ITAD1 encompassing one zone and ITAD2 encompassing the other. Each zone has a gatekeeper that interacts with the Location Server in its ITAD. The gateways are setup to consult the gatekeeper for routing a call. In this sample call flow, we demonstrate use of a TRIP route that specifies use of H323-RAS to reach the next hop signaling point for a call received from the PSTN.

1. Gateway G3 in ITAD2 receives a call for prefix 619* from the PSTN
2. G3 sends an ARQ to GK2
3. GK2 sends a TRIP Query to LS2
4. LS2 returns a route {NextHop:GK1, Signaling:H323-RAS}
5. GK2 sends a RAS LRQ to GK1
6. GK1 responds with LCF with IP address of Gateway G1
7. GK2 sends an ACF to Gateway G3 with IP address of Gateway G1
8. G3 sends a Q.931 SETUP message to Gateway G1

The above call flows show a stand-alone TRIP LS in each ITAD. However, it is possible to have a TRIP LS co-locate with an H.323 gatekeeper.