Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3219

Telephony Routing over IP (TRIP)

Pages: 79
Proposed Standard
Errata
Updated by:  8602
Part 1 of 3 – Pages 1 to 24
None   None   Next

Top   ToC   RFC3219 - Page 1
Network Working Group                                       J. Rosenberg
Request for Comments: 3219                                   dynamicsoft
Category: Standards Track                                      H. Salama
                                                           Cisco Systems
                                                               M. Squire
                                                       Hatteras Networks
                                                            January 2002


                    Telephony Routing over IP (TRIP)

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

This document presents the Telephony Routing over IP (TRIP). TRIP is a policy driven inter-administrative domain protocol for advertising the reachability of telephony destinations between location servers, and for advertising attributes of the routes to those destinations. TRIP's operation is independent of any signaling protocol, hence TRIP can serve as the telephony routing protocol for any signaling protocol. The Border Gateway Protocol (BGP-4) is used to distribute routing information between administrative domains. TRIP is used to distribute telephony routing information between telephony administrative domains. The similarity between the two protocols is obvious, and hence TRIP is modeled after BGP-4.

Table of Contents

1 Terminology and Definitions .............................. 3 2 Introduction ............................................. 4 3 Summary of Operation ..................................... 5 3.1 Peering Session Establishment and Maintenance ............ 5 3.2 Database Exchanges ....................................... 6 3.3 Internal Versus External Synchronization ................. 6 3.4 Advertising TRIP Routes .................................. 6
Top   ToC   RFC3219 - Page 2
   3.5  Telephony Routing Information Bases  ......................   7
   3.6  Routes in TRIP  ...........................................   9
   3.7  Aggregation  ..............................................   9
   4    Message Formats  ..........................................  10
   4.1  Message Header Format  ....................................  10
   4.2  OPEN Message Format  ......................................  11
   4.3  UPDATE Message Format  ....................................  15
   4.4  KEEPALIVE Message Format   ................................  22
   4.5  NOTIFICATION Message Format   .............................  23
   5    TRIP Attributes   .........................................  24
   5.1  WithdrawnRoutes  ..........................................  24
   5.2  ReachableRoutes  ..........................................  28
   5.3  NextHopServer   ...........................................  29
   5.4  AdvertisementPath   .......................................  31
   5.5  RoutedPath  ...............................................  35
   5.6  AtomicAggregate   .........................................  36
   5.7  LocalPreference   .........................................  37
   5.8  MultiExitDisc  ............................................  38
   5.9  Communities  ..............................................  39
   5.10 ITAD Topology    ..........................................  41
   5.11 ConvertedRoute  ...........................................  43
   5.12 Considerations for Defining New TRIP Attributes   .........  44
   6    TRIP Error Detection and Handling   .......................  44
   6.1  Message Header Error Detection and Handling   .............  45
   6.2  OPEN Message Error Detection and Handling   ...............  45
   6.3  UPDATE Message Error Detection and Handling   .............  46
   6.4  NOTIFICATION Message Error Detection and Handling   .......  48
   6.5  Hold Timer Expired Error Handling   .......................  48
   6.6  Finite State Machine Error Handling   .....................  48
   6.7  Cease   ...................................................  48
   6.8  Connection Collision Detection   ..........................  48
   7    TRIP Version Negotiation   ................................  49
   8    TRIP Capability Negotiation   .............................  50
   9    TRIP Finite State Machine   ...............................  50
   10   UPDATE Message Handling   .................................  55
   10.1 Flooding Process   ........................................  56
   10.2 Decision Process   ........................................  58
   10.3  Update-Send Process   ..................................... 62
   10.4  Route Selection Criteria   ................................ 67
   10.5  Originating TRIP Routes   ................................. 67
   11    TRIP Transport   .......................................... 68
   12    ITAD Topology   ........................................... 68
   13    IANA Considerations  ...................................... 68
   13.1  TRIP Capabilities   ....................................... 68
   13.2  TRIP Attributes    ........................................ 69
   13.3  Destination Address Families   ............................ 69
   13.4  TRIP Application Protocols   .............................. 69
   13.5  ITAD Numbers   ............................................ 70
Top   ToC   RFC3219 - Page 3
   14    Security Considerations   ................................. 70
   A1.   Appendix 1: TRIP FSM State Transitions and Actions   ...... 71
   A2.   Appendix 2: Implementation Recommendations   .............. 73
   Acknowledgments  ................................................ 75
   References  ..................................................... 75
   Intellectual Property Notice  ................................... 77
   Authors' Addresses  ............................................. 78
   Full Copyright Statement  ....................................... 79

1. Terminology and Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. A framework for Telephony Routing over IP (TRIP) is described in [2]. We assume the reader is familiar with the framework and terminology of [2]. We define and use the following terms in addition to those defined in [2]. Telephony Routing Information Base (TRIB): The database of reachable telephony destinations built and maintained at an LS as a result of its participation in TRIP. IP Telephony Administrative Domain (ITAD): The set of resources (gateways, location servers, etc.) under the control of a single administrative authority. End users are customers of an ITAD. Less/More Specific Route: A route X is said to be less specific than a route Y if every destination in Y is also a destination in X, and X and Y are not equal. In this case, Y is also said to be more specific than X. Aggregation: Aggregation is the process by which multiple routes are combined into a single less specific route that covers the same set of destinations. Aggregation is used to reduce the size of the TRIB being synchronized with peer LSs by reducing the number of exported TRIP routes. Peers: Two LSs that share a logical association (a transport connection). If the LSs are in the same ITAD, they are internal peers. Otherwise, they are external peers. The logical association between two peer LSs is called a peering session.
Top   ToC   RFC3219 - Page 4
   Telephony Routing Information Protocol (TRIP): The protocol defined
   in this specification.  The function of TRIP is to advertise the
   reachability of telephony destinations, attributes associated with
   the destinations, as well as the attributes of the path towards those
   destinations.

   TRIP destination: TRIP can be used to manage routing tables for
   multiple protocols (SIP, H323, etc.).  In TRIP, a destination is the
   combination of (a) a set of addresses (given by an address family and
   address prefix), and (b) an application protocol (SIP, H323, etc).

2. Introduction

The gateway location and routing problem has been introduced in [2]. It is considered one of the more difficult problems in IP telephony. The selection of an egress gateway for a telephony call, traversing an IP network towards an ultimate destination in the PSTN, is driven in large part by the policies of the various parties along the path, and by the relationships established between these parties. As such, a global directory of egress gateways in which users look up destination phone numbers is not a feasible solution. Rather, information about the availability of egress gateways is exchanged between providers, and subject to policy, made available locally and then propagated to other providers in other ITADs, thus creating routes towards these egress gateways. This would allow each provider to create its own database of reachable phone numbers and the associated routes - such a database could be very different for each provider depending on policy. TRIP is an inter-domain (i.e., inter-ITAD) gateway location and routing protocol. The primary function of a TRIP speaker, called a location server (LS), is to exchange information with other LSs. This information includes the reachability of telephony destinations, the routes towards these destinations, and information about gateways towards those telephony destinations residing in the PSTN. The TRIP requirements are set forth in [2]. LSs exchange sufficient routing information to construct a graph of ITAD connectivity so that routing loops may be prevented. In addition, TRIP can be used to exchange attributes necessary to enforce policies and to select routes based on path or gateway characteristics. This specification defines TRIP's transport and synchronization mechanisms, its finite state machine, and the TRIP data. This specification defines the basic attributes of TRIP. The TRIP attribute set is extendible, so additional attributes may be defined in future documents.
Top   ToC   RFC3219 - Page 5
   TRIP is modeled after the Border Gateway Protocol 4 (BGP-4) [3] and
   enhanced with some link state features, as in the Open Shortest Path
   First (OSPF) protocol [4], IS-IS [5], and the Server Cache
   Synchronization Protocol (SCSP) [6].  TRIP uses BGP's inter-domain
   transport mechanism, BGP's peer communication, BGP's finite state
   machine, and similar formats and attributes as BGP.  Unlike BGP
   however, TRIP permits generic intra-domain LS topologies, which
   simplifies configuration and increases scalability in contrast to
   BGP's full mesh requirement of internal BGP speakers.  TRIP uses an
   intra-domain flooding mechanism similar to that used in OSPF [4],
   IS-IS [5], and SCSP [6].

   TRIP permits aggregation of routes as they are advertised through the
   network.  TRIP does not define a specific route selection algorithm.

   TRIP runs over a reliable transport protocol.  This eliminates the
   need to implement explicit fragmentation, retransmission,
   acknowledgment, and sequencing.  The error notification mechanism
   used in TRIP assumes that the transport protocol supports a graceful
   close, i.e., that all outstanding data will be delivered before the
   connection is closed.

   TRIP's operation is independent of any particular telephony signaling
   protocol.  Therefore, TRIP can be used as the routing protocol for
   any of these protocols, e.g., H.323 [7] and SIP [8].

   The LS peering topology is independent of the physical topology of
   the network.  In addition, the boundaries of an ITAD are independent
   of the boundaries of the layer 3 routing autonomous systems.  Neither
   internal nor external TRIP peers need to be physically adjacent.

3. Summary of Operation

This section summarizes the operation of TRIP. Details are provided in later sections.

3.1. Peering Session Establishment and Maintenance

Two peer LSs form a transport protocol connection between one another. They exchange messages to open and confirm the connection parameters, and to negotiate the capabilities of each LS as well as the type of information to be advertised over this connection. KeepAlive messages are sent periodically to ensure adjacent peers are operational. Notification messages are sent in response to errors or special conditions. If a connection encounters an error condition, a Notification message is sent and the connection is closed.
Top   ToC   RFC3219 - Page 6

3.2. Database Exchanges

Once the peer connection has been established, the initial data flow is a dump of all routes relevant to the new peer (In the case of an external peer, all routes in the LS's Adj-TRIB-Out for that external peer. In the case of an internal peer, all routes in the Ext-TRIB and all Adj-TRIBs-In). Note that the different TRIBs are defined in Section 3.5. Incremental updates are sent as the TRIP routing tables (TRIBs) change. TRIP does not require periodic refresh of the routes. Therefore, an LS must retain the current version of all routing entries. If a particular ITAD has multiple LSs and is providing transit service for other ITADs, then care must be taken to ensure a consistent view of routing within the ITAD. When synchronized the TRIP routing tables, i.e., the Loc-TRIBs, of all internal peers are identical.

3.3. Internal Versus External Synchronization

As with BGP, TRIP distinguishes between internal and external peers. Within an ITAD, internal TRIP uses link-state mechanisms to flood database updates over an arbitrary topology. Externally, TRIP uses point-to-point peering relationships to exchange database information. To achieve internal synchronization, internal peer connections are configured between LSs of the same ITAD such that the resulting intra-domain LS topology is connected and sufficiently redundant. This is different from BGP's approach that requires all internal peers to be connected in a full mesh topology, which may result in scaling problems. 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 domain.

3.4. Advertising TRIP Routes

In TRIP, a route is defined as the combination of (a) a set of destination addresses (given by an address family indicator and an address prefix), and (b) an application protocol (e.g. SIP, H323, etc.). Generally, there are additional attributes associated with each route (for example, the next-hop server).
Top   ToC   RFC3219 - Page 7
   TRIP routes are advertised between a pair of LSs in UPDATE messages.
   The destination addresses are included in the ReachableRoutes
   attribute of the UPDATE, while other attributes describe things like
   the path or egress gateway.

   If an LS chooses to advertise a TRIP route, it may add to or modify
   the attributes of the route before advertising it to a peer.  TRIP
   provides mechanisms by which an LS can inform its peer that a
   previously advertised route is no longer available for use.  There
   are three methods by which a given LS can indicate that a route has
   been withdrawn from service:

      -  Include the route in the WithdrawnRoutes Attribute in an UPDATE
         message, thus marking the associated destinations as being no
         longer available for use.
      -  Advertise a replacement route with the same set of destinations
         in the ReachableRoutes Attribute.
      -  For external peers where flooding is not in use, the LS-to-LS
         peer connection can be closed, which implicitly removes from
         service all routes which the pair of LSs had advertised to each
         other over that peer session.  Note that terminating an
         internal peering session does not necessarily remove the routes
         advertised by the peer LS as the same routes may have been
         received from multiple internal peers because of flooding.  If
         an LS determines that another internal LS is no longer active
         (from the ITAD Topology attributes of the UPDATE messages from
         other internal peers), then it MUST remove all routes
         originated into the LS by that LS and rerun its decision
         process.

3.5. Telephony Routing Information Bases

A TRIP LS processes three types of routes: - External routes: An external route is a route received from an external peer LS - Internal routes: An internal route is a route received from an internal LS in the same ITAD. - Local routes: A local route is a route locally injected into TRIP, e.g. by configuration or by route redistribution from another routing protocol. The Telephony Routing Information Base (TRIB) within an LS consists of four distinct parts:
Top   ToC   RFC3219 - Page 8
      -  Adj-TRIBs-In: The Adj-TRIBs-In store routing information that
         has been learned from inbound UPDATE messages.  Their contents
         represent TRIP routes that are available as an input to the
         Decision Process.  These are the "unprocessed" routes received.
         The routes from each external peer LS and each internal LS are
         maintained in this database independently, so that updates from
         one peer do not affect the routes received from another LS.
         Note that there is an Adj-TRIB-In for every LS within the
         domain, even those with which the LS is not directly peered.
      -  Ext-TRIB: There is only one Ext-TRIB database per LS.  The LS
         runs the route selection algorithm on all external routes
         (stored in the Adj-TRIBs-In of the external peers) and local
         routes (may be stored in an Adj-TRIB-In representing the local
         LS) and selects the best route for a given destination and
         stores it in the Ext-TRIB.  The use of Ext-TRIB will be
         explained further in Section 10.3.1
      -  Loc-TRIB: The Loc-TRIB contains the local TRIP routing
         information that the LS has selected by applying its local
         policies to the routing information contained in its Adj-
         TRIBs-In of internal LSs and the Ext-TRIB.
      -  Adj-TRIBs-Out:  The Adj-TRIBs-Out store the information that
         the local LS has selected for advertisement to its external
         peers.  The routing information stored in the Adj-TRIBs-Out
         will be carried in the local LS's UPDATE messages and
         advertised to its peers.

   Figure 1 illustrates the relationship between the four parts of the
   routing information base.

                            Loc-TRIB
                                ^
                                |
                        Decision Process
                         ^      ^      |
                         |      |      |
                Adj-TRIBs-In    |      V
               (Internal LSs)   |   Adj-TRIBs-Out
                                |
                                |
                                |
                             Ext-TRIB
                            ^        ^
                            |        |
                   Adj-TRIB-In      Local Routes
               (External Peers)

                     Figure 1: TRIB Relationships
Top   ToC   RFC3219 - Page 9
   Although the conceptual model distinguishes between Adj-TRIBs-In,
   Ext-TRIB, Loc-TRIB, and Adj-TRIBs-Out, this neither implies nor
   requires that an implementation must maintain four separate copies of
   the routing information.  The choice of implementation (for example,
   4 copies of the information vs. 1 copy with pointers) is not
   constrained by the protocol.

3.6. Routes in TRIP

A route in TRIP specifies a range of numbers by being a prefix of those numbers (the exact definition & syntax of route are in 5.1.1). Arbitrary ranges of numbers are not atomically representable by a route in TRIP. A prefix range is the only type of range supported atomically. An arbitrary range can be accomplished by using multiple prefixes in a ReachableRoutes attribute (see Section 5.1 & 5.2). For example, 222-xxxx thru 999-xxxx could be represented by including the prefixes 222, 223, 224,...,23,24,...,3,4,...,9 in a ReachableRoutes attribute.

3.7. Aggregation

Aggregation is a scaling enhancement used by an LS to reduce the number of routing entries that it has to synchronize with its peers. Aggregation may be performed by an LS when there is a set of routes {R1, R2, ...} in its TRIB such that there exists a less specific route R where every valid destination in R is also a valid destination in {R1, R2, ...} and vice-versa. Section 5 includes a description of how to combine each attribute (by type) on the {R1, R2, ...} routes into an attribute for R. Note that there is no mechanism within TRIP to communicate that a particular address prefix is not used or valid within a particular address family, and thus that these addresses could be skipped during aggregation. LSs may use methods outside of TRIP to learn of invalid prefixes that may be ignored during aggregation. An LS is not required to perform aggregation, however it is recommended whenever maintaining a smaller TRIB is important. An LS decides based on its local policy whether or not to aggregate a set of routes into a single aggregate route. Whenever an LS aggregates multiple routes where the NextHopServer is not identical in all aggregated routes, the NextHopServer attribute of the aggregate route must be set to a signalling server in the aggregating LS's domain.
Top   ToC   RFC3219 - Page 10
   When an LS resets the NextHopServer of any route, and this may be
   performed because of aggregation or other reasons, it has the effect
   of adding another signalling server along the signalling path to
   these destinations.  The end result is that the signalling path
   between two destinations may consist of multiple signalling servers
   across multiple domains.

4. Message Formats

This section describes message formats used by TRIP. Messages are sent over a reliable transport protocol connection. A message MUST be processed only after it is entirely received. The maximum message size is 4096 octets. All implementations MUST support this maximum message size. The smallest message that MAY be sent consists of a TRIP header without a data portion, or 3 octets.

4.1. Message Header Format

Each message has a fixed-size header. There may or may not be a data portion following the header, depending on the message type. The layout of the header fields is shown in Figure 2. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +--------------+----------------+---------------+ | Length | Type | +--------------+----------------+---------------+ Figure 2: TRIP Header Length: This 2-octet unsigned integer indicates the total length of the message, including the header, in octets. Thus, it allows one to locate, in the transport-level stream, the beginning of the next message. The value of the Length field must always be at least 3 and no greater than 4096, and may be further constrained depending on the message type. No padding of extra data after the message is allowed, so the Length field must have the smallest value possible given the rest of the message. Type: This 1-octet unsigned integer indicates the type code of the message. The following type codes are defined: 1 - OPEN 2 - UPDATE 3 - NOTIFICATION 4 - KEEPALIVE
Top   ToC   RFC3219 - Page 11

4.2. OPEN Message Format

After a transport protocol connection is established, the first message sent by each side is an OPEN message. If the OPEN message is acceptable, a KEEPALIVE message confirming the OPEN is sent back. Once the OPEN is confirmed, UPDATE, KEEPALIVE, and NOTIFICATION messages may be exchanged. The minimum length of the OPEN message is 17 octets (including message header). OPEN messages not meeting this minimum requirement are handled as defined in Section 6.2. In addition to the fixed-size TRIP header, the OPEN message contains the following fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+--------------+----------------+ | Version | Reserved | Hold Time | +---------------+---------------+--------------+----------------+ | My ITAD | +---------------+---------------+--------------+----------------+ | TRIP Identifier | +---------------+---------------+--------------+----------------+ | Optional Parameters Len |Optional Parameters (variable)... +---------------+---------------+--------------+----------------+ Figure 3: TRIP OPEN Header Version: This 1-octet unsigned integer indicates the protocol version of the message. The current TRIP version number is 1. Hold Time: This 2-octet unsigned integer indicates the number of seconds that the sender proposes for the value of the Hold Timer. Upon receipt of an OPEN message, an LS MUST calculate the value of the Hold Timer by using the smaller of its configured Hold Time and the Hold Time received in the OPEN message. The Hold Time MUST be either zero or at least three seconds. An implementation MAY reject connections on the basis of the Hold Time. The calculated value indicates the maximum number of seconds that may elapse between the receipt of successive KEEPALIVE and/or UPDATE messages by the sender. This 4-octet unsigned integer indicates the ITAD number of the sender. The ITAD number must be unique for this domain within this confederation of cooperating LSs.
Top   ToC   RFC3219 - Page 12
   ITAD numbers are assigned by IANA as specified in Section 13.  This
   document reserves ITAD number 0.  ITAD numbers from 1 to 255 are
   designated for private use.

   TRIP Identifier:
   This 4-octet unsigned integer indicates the TRIP Identifier of the
   sender.  The TRIP Identifier MUST uniquely identify this LS within
   its ITAD.  A given LS MAY set the value of its TRIP Identifier to an
   IPv4 address assigned to that LS.  The value of the TRIP Identifier
   is determined on startup and MUST be the same for all peer
   connections.  When comparing two TRIP identifiers, the TRIP
   Identifier is interpreted as a numerical 4-octet unsigned integer.

   Optional Parameters Length:
   This 2-octet unsigned integer indicates the total length of the
   Optional Parameters field in octets.  If the value of this field is
   zero, no Optional Parameters are present.

   Optional Parameters:
   This field may contain a list of optional parameters, where each
   parameter is encoded as a <Parameter Type, Parameter Length,
   Parameter Value> triplet.

       0                   1                   2
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +---------------+---------------+--------------+----------------+
      |       Parameter Type          |       Parameter Length        |
      +---------------+---------------+--------------+----------------+
      |                  Parameter Value (variable)...
      +---------------+---------------+--------------+----------------+

                    Figure 4: Optional Parameter Encoding

   Parameter Type:
   This is a 2-octet field that unambiguously identifies individual
   parameters.

   Parameter Length:
   This is a 2-octet field that contains the length of the Parameter
   Value field in octets.

   Parameter Value:
   This is a variable length field that is interpreted according to the
   value of the Parameter Type field.
Top   ToC   RFC3219 - Page 13

4.2.1. Open Message Optional Parameters

This document defines the following Optional Parameters for the OPEN message.
4.2.1.1. Capability Information
Capability Information uses Optional Parameter type 1. This is an optional parameter used by an LS to convey to its peer the list of capabilities supported by the LS. This permits an LS to learn of the capabilities of its peer LSs. Capability negotiation is defined in Section 8. The parameter contains one or more triples <Capability Code, Capability Length, Capability Value>, where each triple is encoded as shown below: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+--------------+----------------+ | Capability Code | Capability Length | +---------------+---------------+--------------+----------------+ | Capability Value (variable)... +---------------+---------------+--------------+----------------+ Figure 5: Capability Optional Parameter Capability Code: Capability Code is a 2-octet field that unambiguously identifies individual capabilities. Capability Length: Capability Length is a 2-octet field that contains the length of the Capability Value field in octets. Capability Value: Capability Value is a variable length field that is interpreted according to the value of the Capability Code field. Any particular capability, as identified by its Capability Code, may appear more than once within the Optional Parameter. This document reserves Capability Codes 32768-65535 for vendor- specific applications (these are the codes with the first bit of the code value equal to 1). This document reserves value 0. Capability Codes (other than those reserved for vendor specific use) are controlled by IANA. See Section 13 for IANA considerations.
Top   ToC   RFC3219 - Page 14
   The following Capability Codes are defined by this specification:

      Code           Capability
      1              Route Types Supported
      2              Send Receive Capability

4.2.1.1.1. Route Types Supported
The Route Types Supported Capability Code lists the route types supported in this peering session by the transmitting LS. An LS MUST NOT use route types that are not supported by the peer LS in any particular peering session. If the route types supported by a peer are not satisfactory, an LS SHOULD terminate the peering session. The format for a Route Type is: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+--------------+----------------+ | Address Family | Application Protocol | +---------------+---------------+--------------+----------------+ Figure 6: Route Types Supported Capability The Address Family and Application Protocol are as defined in Section 5.1.1. Address Family gives the address family being routed (within the ReachableRoutes attribute). The application protocol lists the application for which the routes apply. As an example, a route type for TRIP could be <E.164, SIP>, indicating a set of E.164 destinations for the SIP protocol. The Route Types Supported Capability MAY contain multiple route types in the capability. The number of route types within the capability is the maximum number that can fit given the capability length. The Capability Code is 1 and the length is variable.
4.2.1.1.2. Send Receive Capability
This capability specifies the mode in which the LS will operate with this particular peer. The possible modes are: Send Only mode, Receive Only mode, or Send Receive mode. The default mode is Send Receive mode. In Send Only mode, an LS transmits UPDATE messages to its peer, but the peer MUST NOT transmit UPDATE messages to that LS. If an LS in Send Only mode receives an UPDATE message from its peer, it MUST discard that message, but no further action should be taken.
Top   ToC   RFC3219 - Page 15
   The UPDATE messages sent by an LS in Send Only mode to its intra-
   domain peer MUST include the ITAD Topology attribute whenever the
   topology changes.  A useful application of an LS in Send Only mode
   with an external peer is to enable gateway registration services.

   If a service provider terminates calls to a set of gateways it owns,
   but never initiates calls, it can set its LSs to operate in Send Only
   mode, since they only ever need to generate UPDATE messages, not
   receive them.  If an LS in Send Receive mode has a peering session
   with a peer in Send Only mode, that LS MUST set its route
   dissemination policy such that it does not send any UPDATE messages
   to its peer.

   In Receive Only mode, the LS acts as a passive TRIP listener.  It
   receives and processes UPDATE messages from its peer, but it MUST NOT
   transmit any UPDATE messages to its peer.  This is useful for
   management stations that wish to collect topology information for
   display purposes.

   The behavior of an LS in Send Receive mode is the default TRIP
   operation specified throughout this document.

   The Send Receive capability is a 4-octet unsigned numeric value.  It
   can only take one of the following three values:

      1 - Send Receive mode
      2 - Send only mode
      3 - Receive Only mode

   A peering session MUST NOT be established between two LSs if both of
   them are  in Send Only mode or if both of them are in Receive Only
   mode.  If a peer LS detects such a capability mismatch when
   processing an OPEN message, it MUST respond with a NOTIFICATION
   message and close the peer session.  The error code in the
   NOTIFICATION message must be set to "Capability Mismatch."

   An LS MUST be configured in the same Send Receive mode for all peers.

4.3. UPDATE Message Format

UPDATE messages are used to transfer routing information between LSs. The information in the UPDATE packet can be used to construct a graph describing the relationships between the various ITADs. By applying rules to be discussed, routing information loops and some other anomalies can be prevented.
Top   ToC   RFC3219 - Page 16
   An UPDATE message is used to both advertise and withdraw routes from
   service.  An UPDATE message may simultaneously advertise and withdraw
   TRIP routes.

   In addition to the TRIP header, the TRIP UPDATE contains a list of
   routing attributes as shown in Figure 7.  There is no padding between
   routing attributes.

         +------------------------------------------------+--...
         | First Route Attribute | Second Route Attribute |  ...
         +------------------------------------------------+--...

                    Figure 7: TRIP UPDATE Format

   The minimum length of an UPDATE message is 3 octets (there are no
   mandatory attributes in TRIP).

4.3.1. Routing Attributes

A variable length sequence of routing attributes is present in every UPDATE message. Each attribute is a triple <attribute type, attribute length, attribute value> of variable length. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+--------------+----------------+ | Attr. Flags |Attr. Type Code| Attr. Length | +---------------+---------------+--------------+----------------+ | Attribute Value (variable) | +---------------+---------------+--------------+----------------+ Figure 8: Routing Attribute Format Attribute Type is a two-octet field that consists of the Attribute Flags octet followed by the Attribute Type Code octet. The Attribute Type Code defines the type of attribute. The basic TRIP-defined Attribute Type Codes are discussed later in this section. Attributes MUST appear in the UPDATE message in numerical order of the Attribute Type Code. An attribute MUST NOT be included more than once in the same UPDATE message. Attribute Flags are used to control attribute processing when the attribute type is unknown. Attribute Flags are further defined in Section 4.3.2.
Top   ToC   RFC3219 - Page 17
   This document reserves Attribute Type Codes 224-255 for vendor-
   specific applications (these are the codes with the first three bits
   of the code equal to 1).  This document reserves value 0.  Attribute
   Type Codes (other than those reserved for vendor specific use) are
   controlled by IANA.  See Section 13 for IANA considerations.

   The third and the fourth octets of the route attribute contain the
   length of the attribute value field in octets.

   The remaining octets of the attribute represent the Attribute Value
   and are interpreted according to the Attribute Flags and the
   Attribute Type Code.  The basic supported attribute types, their
   values, and their uses are defined in this specification.  These are
   the attributes necessary for proper loop free operation of TRIP, both
   inter-domain and intra-domain.  Additional attributes may be defined
   in future documents.

4.3.2. Attribute Flags

It is clear that the set of attributes for TRIP will evolve over time. Hence it is essential that mechanisms be provided to handle attributes with unrecognized types. The handling of unrecognized attributes is controlled via the flags field of the attribute. Recognized attributes should be processed according to their specific definition. The following are the attribute flags defined by this specification: Bit Flag 0 Well-Known Flag 1 Transitive Flag 2 Dependent Flag 3 Partial Flag 4 Link-state Encapsulated Flag The high-order bit (bit 0) of the Attribute Flags octet is the Well- Known Bit. It defines whether the attribute is not well-known (if set to 1) or well-known (if set to 0). Implementations are not required to support not well-known attributes, but MUST support well-known attributes. The second high-order bit (bit 1) of the Attribute Flags octet is the Transitive bit. It defines whether a not well-known attribute is transitive (if set to 1) or non-transitive (if set to 0). For well- known attributes, the Transitive bit MUST be zero on transmit and MUST be ignored on receipt. The third high-order bit (bit 2) of the Attribute Flags octet is the Dependent bit. It defines whether a transitive attribute is
Top   ToC   RFC3219 - Page 18
   dependent (if set to 1) or independent (if set to 0).  For well-known
   attributes and for non-transitive attributes, the Dependent bit is
   irrelevant, and MUST be set to zero on transmit and MUST be ignored
   on receipt.

   The fourth high-order bit (bit 3) of the Attribute Flags octet is the
   Partial bit.  It defines whether the information contained in the not
   well-known transitive attribute is partial (if set to 1) or complete
   (if set to 0).  For well-known attributes and for non-transitive
   attributes the Partial bit MUST be set to 0 on transmit and MUST be
   ignored on receipt.

   The fifth high-order bit (bit 4) of the Attribute Flags octet is the
   Link-state Encapsulation bit.  This bit is only applicable to certain
   attributes (ReachableRoutes and WithdrawnRoutes) and determines the
   encapsulation of the routes within those attributes.  If this bit is
   set, link-state encapsulation is used within the attribute.
   Otherwise, standard encapsulation is used within the attribute.  The
   Link-state Encapsulation technique is described in Section 4.3.2.4.
   This flag is only valid on the ReachableRoutes and WithdrawnRoutes
   attributes.  It MUST be cleared on transmit and MUST be ignored on
   receipt for all other attributes.

   The other bits of the Attribute Flags octet are unused.  They MUST be
   zeroed on transmit and ignored on receipt.

4.3.2.1. Attribute Flags and Route Selection
Any recognized attribute can be used as input to the route selection process, although the utility of some attributes in route selection is minimal.
4.3.2.2. Attribute Flags and Route Dissemination
TRIP provides for two variations of transitivity due to the fact that intermediate LSs need not modify the NextHopServer when propagating routes. Attributes may be non-transitive, dependent transitive, or independent transitive. An attribute cannot be both dependent transitive and independent transitive. Unrecognized independent transitive attributes may be propagated by any intermediate LS. Unrecognized dependent transitive attributes MAY only be propagated if the LS is NOT changing the next-hop server. The transitivity variations permit some unrecognized attributes to be carried end-to-end (independent transitive), some to be carried between adjacent next-hop servers (dependent transitive), and other to be restricted to peer LSs (non-transitive).
Top   ToC   RFC3219 - Page 19
   An LS that passes an unrecognized transitive attribute to a peer MUST
   set the Partial flag on that attribute.  Any LS along a path MAY
   insert a transitive attribute into a route.  If any LS except the
   originating LS inserts a new independent transitive attribute into a
   route, then it MUST set the Partial flag on that attribute.  If any
   LS except an LS that modifies the NextHopServer inserts a new
   dependent transitive attribute into a route, then it MUST set the
   Partial flag on that attribute.  The Partial flag indicates that not
   every LS along the relevant path has processed and understood the
   attribute.  For independent transitive attributes, the "relevant
   path" is the path given in the AdvertisementPath attribute.  For
   dependent transitive attributes, the relevant path consists only of
   those domains thru which this object has passed since the
   NextHopServer was last modified.  The Partial flag in an independent
   transitive attribute MUST NOT be unset by any other LS along the
   path.  The Partial flag in a dependent transitive attribute MUST be
   reset whenever the NextHopServer is changed, but MUST NOT be unset by
   any LS that is not changing the NextHopServer.

   The rules governing the addition of new non-transitive attributes are
   defined independently for each non-transitive attribute.  Any
   attribute MAY be updated by an LS in the path.

4.3.2.3. Attribute Flags and Route Aggregation
Each attribute defines how it is to be handled during route aggregation. The rules governing the handling of unknown attributes are guided by the Attribute Flags. Unrecognized transitive attributes are dropped during aggregation. There should be no unrecognized non-transitive attributes during aggregation because non-transitive attributes must be processed by the local LS in order to be propagated.
4.3.2.4. Attribute Flags and Encapsulation
Normally attributes have the simple format as described in Section 4.3.1. If the Link-state Encapsulation Flag is set, then the two additional fields are added to the attribute header as shown in Figure 9.
Top   ToC   RFC3219 - Page 20
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +---------------+---------------+--------------+----------------+
   |  Attr. Flags  |Attr. Type Code|          Attr. Length         |
   +---------------+---------------+--------------+----------------+
   |                  Originator TRIP Identifier                   |
   +---------------+---------------+--------------+----------------+
   |                        Sequence Number                        |
   +---------------+---------------+--------------+----------------+
   |                   Attribute Value (variable)                  |
   +---------------+---------------+--------------+----------------+

                 Figure 9: Link State Encapsulation

   The Originator TRIP ID and Sequence Number are used to control the
   flooding of routing updates within a collection of servers.  These
   fields are used to detect duplicate and old routes so that they are
   not further propagated to other LSs.  The use of these fields is
   defined in Section 10.1.

4.3.3. Mandatory Attributes

There are no Mandatory attributes in TRIP. However, there are Conditional Mandatory attributes. A conditional mandatory attribute is an attribute, which MUST be included in an UPDATE message if another attribute is included in that message. For example, if an UPDATE message includes a ReachableRoutes attribute, it MUST include an AdvertisementPath attribute as well. The three base attributes in TRIP are WithdrawnRoutes, ReachableRoutes, and ITAD Topology. Their presence in an UPDATE message is entirely optional and independent of any other attributes.

4.3.4. TRIP UPDATE Attributes

This section summarizes the attributes that may be carried in an UPDATE message. Attributes MUST appear in the UPDATE message in increasing order of the Attribute Type Code. Additional details are provided in Section 5.
4.3.4.1. WithdrawnRoutes
This attribute lists a set of routes that are being withdrawn from service. The transmitting LS has determined that these routes should no longer be advertised, and is propagating this information to its peers.
Top   ToC   RFC3219 - Page 21
4.3.4.2. ReachableRoutes
This attribute lists a set of routes that are being added to service. These routes will have the potential to be inserted into the Adj- TRIBs-In of the receiving LS and the route selection process will be applied to them.
4.3.4.3. NextHopServer
This attribute gives the identity of the entity to which messages should be sent along this routed path. It specifies the identity of the next hop server as either a host domain name or an IP address. It MAY optionally specify the UDP/TCP port number for the next hop signaling server. If not specified, then the default port SHOULD be used. The NextHopServer is specific to the set of destinations and application protocol defined in the ReachableRoutes attribute. Note that this is NOT necessarily the address to which media (voice, video, etc.) should be transmitted, it is only for the application protocol as given in the ReachableRoutes attribute.
4.3.4.4. AdvertisementPath
The AdvertisementPath is analogous to the AS_PATH in BGP4 [3]. The attribute records the sequence of domains through which this advertisement has passed. The attribute is used to detect when the routing advertisement is looping. This attribute does NOT reflect the path through which messages following this route would traverse. Since the next-hop need not be modified by each LS, the actual path to the destination might not have to traverse every domain in the AdvertisementPath.
4.3.4.5. RoutedPath
The RoutedPath attribute is analogous to the AdvertisementPath attribute, except that it records the actual path (given by the list of domains) *to* the destinations. Unlike AdvertisementPath, which is modified each time the route is propagated, RoutedPath is only modified when the NextHopServer attribute changes. Thus, it records the subset of the AdvertisementPath which signaling messages following this particular route would traverse.
4.3.4.6. AtomicAggregate
The AtomicAggregate attribute indicates that a route may actually include domains not listed in the RoutedPath. If an LS, when presented with a set of overlapping routes from a peer LS, selects a less specific route without selecting the more specific route, then the LS MUST include the AtomicAggregate attribute with the route. An
Top   ToC   RFC3219 - Page 22
   LS receiving a route with an AtomicAggregate attribute MUST NOT make
   the set of destinations more specific when advertising it to other
   LSs.

4.3.4.7. LocalPreference
The LocalPreference attribute is an intra-domain attribute used to inform other LSs of the local LS's preference for a given route. The preference of a route is calculated at the ingress to a domain and passed as an attribute with that route throughout the domain. Other LSs within the same ITAD use this attribute in their route selection process. This attribute has no significance between domains.
4.3.4.8. MultiExitDisc
There may be more than one LS peering relationship between neighboring domains. The MultiExitDisc attribute is used by an LS to express a preference for one link between the domains over another link between the domains. The use of the MultiExitDisc attribute is controlled by local policy.
4.3.4.9. Communities
The Communities attribute is not a well-known attribute. It is used to facilitate and simplify the control of routing information by grouping destinations into communities.
4.3.4.10. ITAD Topology
The ITAD topology attribute is an intra-domain attribute that is used by LSs to indicate their intra-domain topology to other LSs in the domain.
4.3.4.11. ConvertedRoute
The ConvertedRoute attribute indicates that an intermediate LS has altered the route by changing the route's Application Protocol.

4.4. KEEPALIVE Message Format

TRIP does not use any transport-based keep-alive mechanism to determine if peers are reachable. Instead, KEEPALIVE messages are exchanged between peers often enough as not to cause the Hold Timer to expire. A reasonable maximum time between KEEPALIVE messages would be one third of the Hold Time interval. KEEPALIVE messages MUST NOT be sent more than once every 3 seconds. An implementation SHOULD adjust the rate at which it sends KEEPALIVE messages as a function of the negotiated Hold Time interval.
Top   ToC   RFC3219 - Page 23
   If the negotiated Hold Time interval is zero, then periodic KEEPALIVE
   messages MUST NOT be sent.

   The KEEPALIVE message consists of only a message header and has a
   length of 3 octets.

4.5. NOTIFICATION Message Format

A NOTIFICATION message is sent when an error condition is detected. The TRIP transport connection is closed immediately after sending a NOTIFICATION message. In addition to the fixed-size TRIP header, the NOTIFICATION message contains the following fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+--------------+----------------+ | Error Code | Error Subcode | Data... (variable) +---------------+---------------+--------------+----------------+ Figure 10: TRIP NOTIFICATION Format Error Code: This 1-octet unsigned integer indicates the type of NOTIFICATION. The following Error Codes have been defined: Error Code Symbolic Name Reference 1 Message Header Error Section 6.1 2 OPEN Message Error Section 6.2 3 UPDATE Message Error Section 6.3 4 Hold Timer Expired Section 6.5 5 Finite State Machine Error Section 6.6 6 Cease Section 6.7 Error Subcode: This 1-octet unsigned integer provides more specific information about the nature of the reported error. Each Error Code may have one or more Error Subcodes associated with it. If no appropriate Error Subcode is defined, then a zero (Unspecific) value is used for the Error Subcode field. Message Header Error Subcodes: 1 - Bad Message Length. 2 - Bad Message Type.
Top   ToC   RFC3219 - Page 24
   OPEN Message Error Subcodes:
      1  - Unsupported Version Number.
      2  - Bad Peer ITAD.
      3  - Bad TRIP Identifier.
      4  - Unsupported Optional Parameter.
      5  - Unacceptable Hold Time.
      6  - Unsupported Capability.
      7  - Capability Mismatch.

   UPDATE Message Error Subcodes:
      1 - Malformed Attribute List.
      2 - Unrecognized Well-known Attribute.
      3 - Missing Well-known Mandatory Attribute.
      4 - Attribute Flags Error.
      5 - Attribute Length Error.
      6 - Invalid Attribute.

   Data:
   This variable-length field is used to diagnose the reason for the
   NOTIFICATION.  The contents of the Data field depend upon the Error
   Code and Error Subcode.

   Note that the length of the data can be determined from the message
   length field by the formula:

            Data Length = Message Length - 5

   The minimum length of the NOTIFICATION message is 5 octets (including
   message header).



(page 24 continued on part 2)

Next Section