Tech-invite   3GPPspecs   IETFRFCs   SIP   Search in Tech-invite

in Index   Prev   Next
in Index   Prev   Next  Group: IPTEL

RFC 3219

Telephony Routing over IP (TRIP)

Pages: 79
Proposed STD
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.


   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

   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",
   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

   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

   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

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

   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

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.

                        Decision Process
                         ^      ^      |
                         |      |      |
                Adj-TRIBs-In    |      V
               (Internal LSs)   |   Adj-TRIBs-Out
                            ^        ^
                            |        |
                   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

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
      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

   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

   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. 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 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. 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

   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
   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. 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. 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. Attribute Flags and Route Aggregation

   Each attribute defines how it is to be handled during route

   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. 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. 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
Top   ToC   RFC3219 - Page 21 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. 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. 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. 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. 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. 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. 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. 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. 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. 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.

   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