doc: Add RFC documents

1 files changed, 4427 insertions, 0 deletions

diff --git a/doc/rfc/rfc3219.txt b/doc/rfc/rfc3219.txt
new file mode 100644
index 0000000..03745a5
--- /dev/null
+++ b/doc/rfc/rfc3219.txt
@@ -0,0 +1,4427 @@
+
+
+
+
+
+
+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
+
+
+
+Rosenberg, et. al.          Standards Track                     [Page 1]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+   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
+
+
+
+Rosenberg, et. al.          Standards Track                     [Page 2]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+   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.
+
+
+
+
+
+
+
+
+Rosenberg, et. al.          Standards Track                     [Page 3]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+   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.
+
+
+
+
+
+Rosenberg, et. al.          Standards Track                     [Page 4]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+   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.
+
+
+
+
+Rosenberg, et. al.          Standards Track                     [Page 5]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+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).
+
+
+
+
+
+
+Rosenberg, et. al.          Standards Track                     [Page 6]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+   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:
+
+
+
+
+
+
+
+Rosenberg, et. al.          Standards Track                     [Page 7]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+      -  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
+
+
+
+
+Rosenberg, et. al.          Standards Track                     [Page 8]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+   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.
+
+
+
+
+
+
+Rosenberg, et. al.          Standards Track                     [Page 9]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+   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
+
+
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 10]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+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.
+
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 11]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+   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.
+
+
+
+
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 12]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+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.
+
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 13]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+   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.
+
+
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 14]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+   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.
+
+
+
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 15]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+   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.
+
+
+
+
+
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 16]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+   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
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 17]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+   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).
+
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 18]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 19]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+    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.
+
+
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 20]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+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
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 21]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+   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.
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 22]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+   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.
+
+
+
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 23]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+   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).
+
+5. TRIP Attributes
+
+   This section provides details on the syntax and semantics of each
+   TRIP UPDATE attribute.
+
+5.1. WithdrawnRoutes
+
+   Conditional Mandatory: False.
+   Required Flags: Well-known.
+   Potential Flags: Link-State Encapsulation (when flooding).
+   TRIP Type Code: 1
+
+   The WithdrawnRoutes specifies a set of routes that are to be removed
+   from service by the receiving LS(s).  The set of routes MAY be empty,
+   indicated by a length field of zero.
+
+
+
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 24]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+5.1.1. Syntax of WithdrawnRoutes
+
+   The WithdrawnRoutes Attribute encodes a sequence of routes in its
+   value field.  The format for individual routes is given in Section
+   5.1.1.1.  The WithdrawnRoutes Attribute lists the individual routes
+   sequentially with no padding as shown in Figure 11.  Each route
+   includes a length field so that the individual routes within the
+   attribute can be delineated.
+
+            +---------------------+---------------------+...
+            |  WithdrawnRoute1... |  WithdrawnRoute2... |...
+            +---------------------+---------------------+...
+
+                 Figure 11: WithdrawnRoutes Format
+
+5.1.1.1. Generic TRIP Route Format
+
+   The generic format for a TRIP route is given in Figure 12.
+
+    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
+   +---------------+---------------+--------------+----------------+
+   |       Address Family          |      Application Protocol     |
+   +---------------+---------------+--------------+----------------+
+   |            Length             |       Address (variable)     ...
+   +---------------+---------------+--------------+----------------+
+
+                Figure 12: Generic TRIP Route Format
+
+   Address Family:
+   The address family field gives the type of address for the route.
+   Three address families are defined in this Section:
+
+            Code              Address Family
+            1                 Decimal Routing Numbers
+            2                 PentaDecimal Routing Numbers
+            3                 E.164 Numbers
+
+   This document reserves address family code 0.  This document reserves
+   address family codes 32768-65535 for vendor-specific applications
+   (these are the codes with the first bit of the code value equal to
+   1).  Additional address families may be defined in the future.
+   Assignment of address family codes is controlled by IANA.  See
+   Section 13 for IANA considerations.
+
+
+
+
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 25]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+   Application Protocol:
+   The application protocol gives the protocol for which this routing
+   table is maintained.  The currently defined application protocols
+   are:
+
+            Code              Protocol
+            1                 SIP
+            2                 H.323-H.225.0-Q.931
+            3                 H.323-H.225.0-RAS
+            4                 H.323-H.225.0-Annex-G
+
+   This document reserves application protocol code 0.  This document
+   reserves application protocol codes 32768-65535 for vendor-specific
+   applications (these are the codes with the first bit of the code
+   value equal to 1).  Additional application protocols may be defined
+   in the future.  Assignment of application protocol codes is
+   controlled by IANA.  See Section 13 for IANA considerations.
+
+   Length:
+   The length of the address field, in bytes.
+
+   Address:
+   This is an address (prefix) of the family type given by Address
+   Family.  The octet length of the address is variable and is
+   determined by the length field of the route.
+
+5.1.1.2. Decimal Routing Numbers
+
+   The Decimal Routing Numbers address family is a super set of all
+   E.164 numbers, national numbers, local numbers, and private numbers.
+   It can also be used to represent the decimal routing numbers used in
+   conjunction with Number Portability in some countries/regions.  A set
+   of telephone numbers is specified by a Decimal Routing Number prefix.
+   Decimal Routing Number prefixes are represented by a string of
+   digits, each digit encoded by its ASCII character representation.
+   This routing object covers all phone numbers starting with this
+   prefix.  The syntax for the Decimal Routing Number prefix is:
+
+      Decimal-routing-number  = *decimal-digit
+      decimal-digit           = DECIMAL-DIGIT
+      DECIMAL-DIGIT           = "0"|"1"|"2"|"3"|"4"|"5"|"6"|"7"|"8"|"9"
+
+   This DECIMAL Routing Number prefix is not bound in length.  This
+   format is similar to the format for a global telephone number as
+   defined in SIP [8] without visual separators and without the "+"
+   prefix for international numbers.  This format facilitates efficient
+   comparison when using TRIP to route SIP or H323, both of which use
+   character based representations of phone numbers.  The prefix length
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 26]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+   is determined from the length field of the route.  The type of
+   Decimal Routing Number (private, local, national, or international)
+   can be deduced from the first few digits of the prefix.
+
+5.1.1.3. PentaDecimal Routing Numbers
+
+   This address family is used to represent PentaDecimal Routing Numbers
+   used in conjunction with Number Portability in some
+   countries/regions.  PentaDecimal Routing Number prefixes are
+   represented by a string of digits, each digit encoded by its ASCII
+   character representation.  This routing object covers all routing
+   numbers starting with this prefix.  The syntax for the PentaDecimal
+   Routing Number prefix is:
+
+      PentaDecimal-routing-number   = *pentadecimal-digit
+      pentadecimal-routing-digit    = PENTADECIMAL-DIGIT
+      PENTADECIMAL-DIGIT            = "0"|"1"|"2"|"3"|"4"|"5"|"6"|"7"|
+                                      "8"|"9"|"A"|"B"|"C"|"D"|"E"
+
+   Note the difference in alphabets between Decimal Routing Numbers and
+   PentaDecimal Routing Numbers.  A PentaDecimal Routing Number prefix
+   is not bound in length.
+
+   Note that the address family, which suits the routing numbers of a
+   specific country/region depends on the alphabets used for routing
+   numbers in that country/region.  For example, North American routing
+   numbers SHOULD use the Decimal Routing Numbers address family,
+   because their alphabet is limited to the digits "0" through "9".
+   Another example, in most European countries routing numbers use the
+   alphabet "0" through "9" and "A" through "E", and hence these
+   countries SHOULD use the PentaDecimal Routing Numbers address family.
+
+5.1.1.4. E.164 Numbers
+
+   The E.164 Numbers address family is dedicated to fully qualified
+   E.164 numbers.  A set of telephone numbers is specified by a E.164
+   prefix.  E.164 prefixes are represented by a string of digits, each
+   digit encoded by its ASCII character representation.  This routing
+   object covers all phone numbers starting with this prefix.  The
+   syntax for the E.164 prefix is:
+
+      E164-number          = *e164-digit
+      E164-digit           = E164-DIGIT
+      E164-DIGIT           = "0"|"1"|"2"|"3"|"4"|"5"|"6"|"7"|"8"|"9"
+
+
+
+
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 27]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+   This format facilitates efficient comparison when using TRIP to route
+   SIP or H323, both of which use character based representations of
+   phone numbers.  The prefix length is determined from the length field
+   of the route.
+
+   The E.164 Numbers address family and the Decimal Routing Numbers
+   address family have the same alphabet.  The E.164 Numbers address
+   family SHOULD be used whenever possible.  The Decimal Routing Numbers
+   address family can be used in case of private numbering plans or
+   applications that do not desire to advertise fully expanded, fully
+   qualified telephone numbers.  If Decimal Routing Numbers are used to
+   advertise non-fully qualified prefixes, the prefixes may have to be
+   manipulated (e.g. expanded) at the boundary between ITADs.  This adds
+   significant complexity to the ITAD-Border LS, because, it has to map
+   the prefixes from the format used in its own ITAD to the format used
+   in the peer ITAD.
+
+5.2. ReachableRoutes
+
+   Conditional Mandatory: False.
+   Required Flags: Well-known.
+   Potential Flags: Link-State Encapsulation (when flooding).
+   TRIP Type Code: 2
+
+   The ReachableRoutes attribute specifies a set of routes that are to
+   be added to service by the receiving LS(s).  The set of routes MAY be
+   empty, as indicated by setting the length field to zero.
+
+5.2.1. Syntax of ReachableRoutes
+
+   The ReachableRoutes Attribute has the same syntax as the
+   WithdrawnRoutes Attribute.  See Section 5.1.1.
+
+5.2.2. Route Origination and ReachableRoutes
+
+   Routes are injected into TRIP by a method outside the scope of this
+   specification.  Possible methods include a front-end protocol, an
+   intra-domain routing protocol, or static configuration.
+
+5.2.3. Route Selection and ReachableRoutes
+
+   The routes in ReachableRoutes are necessary for route selection.
+
+5.2.4. Aggregation and ReachableRoutes
+
+   To aggregate multiple routes, the set of ReachableRoutes to be
+   aggregated MUST combine to form a less specific set.
+
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 28]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+   There is no mechanism within TRIP to communicate that a particular
+   address prefix is not used 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.
+
+   If an LS advertises an aggregated route, it MUST include the
+   AtomicAggregate attribute.
+
+5.2.5. Route Dissemination and ReachableRoutes
+
+   The ReachableRoutes attribute is recomputed at each LS except where
+   flooding is being used (e.g., within a domain).  It is therefore
+   possible for an LS to change the Application Protocol field of a
+   route before advertising that route to an external peer.
+
+   If an LS changes the Application Protocol of a route it advertises,
+   it MUST include the ConvertedRoute attribute in the UPDATE message.
+
+5.2.6. Aggregation Specifics for Decimal Routing Numbers, E.164 Numbers,
+       and PentaDecimal Routing Numbers
+
+   An LS that has routes to all valid numbers in a specific prefix
+   SHOULD advertise that prefix as the ReachableRoutes, even if there
+   are more specific prefixes that do not actually exist on the PSTN.
+   Generally, it takes 10 Decimal Routing/E.164 prefixes, or 15
+   PentaDecimal Routing prefixes, of length n to aggregate into a prefix
+   of length n-1.  However, if an LS is aware that a prefix is an
+   invalid Decimal Routing/E.164 prefix, or PentaDecimal Routing prefix,
+   then the LS MAY aggregate by skipping this prefix.  For example, if
+   the Decimal Routing prefix 19191 is known not to exist, then an LS
+   can aggregate to 1919 without 19191.  A prefix representing an
+   invalid set of PSTN destinations is sometimes referred to as a
+   "black-hole."  The method by which an LS is aware of black-holes is
+   not within the scope of TRIP, but if an LS has such knowledge, it can
+   use the knowledge when aggregating.
+
+5.3. NextHopServer
+
+   Conditional Mandatory: True (if ReachableRoutes and/or
+   WithdrawnRoutes attribute is present).
+   Required Flags: Well-known.
+   Potential Flags: None.
+   TRIP Type Code: 3.
+
+
+
+
+
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 29]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+   Given a route with application protocol A and destinations D, the
+   NextHopServer indicates to the next-hop that messages of protocol A
+   destined for D should be sent to it.  This may or may not represent
+   the ultimate destination of those messages.
+
+5.3.1. NextHopServer Syntax
+
+   For generality, the address of the next-hop server may be of various
+   types (domain name, IPv4, IPv6, etc).  The NextHopServer attribute
+   includes the ITAD number of next-hop server, a length field, and a
+   next-hop name or address.
+
+   The syntax for the NextHopServer is given in Figure 13.
+
+    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
+   +---------------+---------------+--------------+----------------+
+   |                         Next Hop ITAD                         |
+   +---------------+---------------+--------------+----------------+
+   |             Length            |         Server (variable)    ...
+   +---------------+---------------+--------------+----------------+
+
+                  Figure 13: NextHopServer Syntax
+
+   The Next-Hop ITAD indicates the domain of the next-hop.  Length field
+   gives the number of octets in the Server field, and the Server field
+   contains the name or address of the next-hop server.  The server
+   field is represented as a string of ASCII characters.  It is defined
+   as follows:
+
+   Server  = host [":" port ]
+   host    = <   A legal Internet host domain name
+              or an IPv4 address using the textual representation
+                 defined in Section 2.1 of RFC 1123 [9]
+              or an IPv6 address using the textual representation
+                 defined in Section 2.2 of RFC 2373 [10].  The IPv6
+                 address MUST be enclosed in "[" and "]"
+                 characters.>
+   port    = *DIGIT
+
+   If the port is empty or not given, the default port is assumed (e.g.,
+   port 5060 if the application protocol is SIP).
+
+5.3.2. Route Origination and NextHopServer
+
+   When an LS originates a routing object into TRIP, it MUST include a
+   NextHopServer within its domain.  The NextHopServer could be an
+   address of the egress gateway or of a signaling proxy.
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 30]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+5.3.3. Route Selection and NextHopServer
+
+   LS policy may prefer certain next-hops or next-hop domains over
+   others.
+
+5.3.4. Aggregation and NextHopServer
+
+   When aggregating multiple routing objects into a single routing
+   object, an LS MUST insert a new signaling server from within its
+   domain as the new NextHopServer unless all of the routes being
+   aggregated have the same next-hop.
+
+5.3.5. Route Dissemination and NextHopServer
+
+   When propagating routing objects to peers, an LS may choose to insert
+   a signaling proxy within its domain as the new next-hop, or it may
+   leave the next-hop unchanged.  Inserting a new next-hop will cause
+   the signaling messages to be sent to that address, and will provide
+   finer control over the signaling path.  Leaving the next-hop
+   unchanged will yield a more efficient signaling path (fewer hops).
+   It is a local policy decision of the LS to decide whether to
+   propagate or change the NextHopServer.
+
+5.4. AdvertisementPath
+
+   Conditional Mandatory: True (if ReachableRoutes and/or
+   WithdrawnRoutes attribute is present).
+   Required Flags: Well-known.
+   Potential Flags: None.
+   TRIP Type Code: 4.
+
+   This attribute identifies the ITADs through which routing information
+   carried in an advertisement has passed.  The AdvertisementPath
+   attribute is analogous to the AS_PATH attribute in BGP.  The
+   attributes differ in that BGP's AS_PATH also reflects the path to the
+   destination.  In TRIP, not every domain need modify the next-hop, so
+   the AdvertisementPath may include many more hops than the actual path
+   to the destination.  The RoutedPath attribute (Section 5.5) reflects
+   the actual signaling path to the destination.
+
+5.4.1. AdvertisementPath Syntax
+
+   AdvertisementPath is a variable length attribute that is composed of
+   a sequence of ITAD path segments.  Each ITAD path segment is
+   represented by a type-length-value triple.
+
+   The path segment type is a 1-octet long field with the following
+   values defined:
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 31]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+      Value      Segment Type
+      1          AP_SET: unordered set of ITADs a route in the
+                 advertisement message has traversed
+      2          AP_SEQUENCE: ordered set of ITADs a route in
+                 the advertisement message has traversed
+
+   The path segment length is a 1-octet long field containing the number
+   of ITADs in the path segment value field.
+
+   The path segment value field contains one or more ITAD numbers, each
+   encoded as a 4-octets long field.  ITAD numbers uniquely identify an
+   Internet Telephony Administrative Domain, and must be obtained from
+   IANA.  See Section 13 for procedures to obtain an ITAD number from
+   IANA.
+
+5.4.2. Route Origination and AdvertisementPath
+
+   When an LS originates a route then:
+
+      -  The originating LS shall include its own ITAD number in the
+         AdvertisementPath attribute of all advertisements sent to LSs
+         located in neighboring ITADs.  In this case, the ITAD number of
+         the originating LS's ITAD will be the only entry in the
+         AdvertisementPath attribute.
+      -  The originating LS shall include an empty AdvertisementPath
+         attribute in all advertisements sent to LSs located in its own
+         ITAD.  An empty AdvertisementPath attribute is one whose length
+         field contains the value zero.
+
+5.4.3. Route Selection and AdvertisementPath
+
+   The AdvertisementPath may be used for route selection.  Possible
+   criteria to be used are the number of hops on the path and the
+   presence or absence of particular ITADs on the path.
+
+   As discussed in Section 10, the AdvertisementPath is used to prevent
+   routing information from looping.  If an LS receives a route with its
+   own ITAD already in the AdvertisementPath, the route MUST be
+   discarded.
+
+5.4.4. Aggregation and AdvertisementPath
+
+   The rules for aggregating AdvertisementPath attributes are given in
+   the following sections, where the term "path" used in Section 5.4.4.1
+   and 5.4.4.2 is understood to mean AdvertisementPath.
+
+
+
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 32]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+5.4.4.1. Aggregating Routes with Identical Paths
+
+   If all routes to be aggregated have identical path attributes, then
+   the aggregated route has the same path attribute as the individual
+   routes.
+
+5.4.4.2. Aggregating Routes with Different Paths
+
+   For the purpose of aggregating path attributes we model each ITAD
+   within the path as a pair <type, value>, where "type" identifies a
+   type of the path segment (AP_SEQUENCE or AP_SET), and "value" is the
+   ITAD number.  Two ITADs are said to be the same if their
+   corresponding <type, value> are the same.
+
+   If the routes to be aggregated have different path attributes, then
+   the aggregated path attribute shall satisfy all of the following
+   conditions:
+
+      -  All pairs of the type AP_SEQUENCE in the aggregated path MUST
+         appear in all of the paths of routes to be aggregated.
+      -  All pairs of the type AP_SET in the aggregated path MUST appear
+         in at least one of the paths of the initial set (they may
+         appear as either AP_SET or AP_SEQUENCE types).
+      -  For any pair X of the type AP_SEQUENCE that precedes pair Y in
+         the aggregated path, X precedes Y in each path of the initial
+         set that contains Y, regardless of the type of Y.
+      -  No pair with the same value shall appear more than once in the
+         aggregated path, regardless of the pair's type.
+
+   An implementation may choose any algorithm that conforms to these
+   rules.  At a minimum, a conformant implementation MUST be able to
+   perform the following algorithm that meets all of the above
+   conditions:
+
+      -  Determine the longest leading sequence of tuples (as defined
+         above) common to all the paths of the routes to be aggregated.
+         Make this sequence the leading sequence of the aggregated path.
+      -  Set the type of the rest of the tuples from the paths of the
+         routes to be aggregated to AP_SET, and append them to the
+         aggregated path.
+      -  If the aggregated path has more than one tuple with the same
+         value (regardless of tuple's type), eliminate all but one such
+         tuple by deleting tuples of the type AP_SET from the aggregated
+         path.
+
+   An implementation that chooses to provide a path aggregation
+   algorithm that retains significant amounts of path information may
+   wish to use the procedure of Section 5.4.4.3.
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 33]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+5.4.4.3. Example Path Aggregation Algorithm
+
+   An example algorithm to aggregate two paths works as follows:
+
+      -  Identify the ITADs (as defined in Section 5.4.1) within each
+         path attribute that are in the same relative order within both
+         path attributes.  Two ITADs, X and Y, are said to be in the
+         same order if either X precedes Y in both paths, or if Y
+         precedes X in both paths.
+      -  The aggregated path consists of ITADs identified in (a) in
+         exactly the same order as they appear in the paths to be
+         aggregated.  If two consecutive ITADs identified in (a) do not
+         immediately follow each other in both of the paths to be
+         aggregated, then the intervening ITADs (ITADs that are between
+         the two consecutive ITADs that are the same) in both attributes
+         are combined into an AP_SET path segment that consists of the
+         intervening ITADs from both paths; this segment is then placed
+         in between the two consecutive ITADs identified in (a) of the
+         aggregated attribute.  If two consecutive ITADs identified in
+         (a) immediately follow each other in one attribute, but do not
+         follow in another, then the intervening ITADs of the latter are
+         combined into an AP_SET path segment; this segment is then
+         placed in between the two consecutive ITADs identified in (a)
+         of the aggregated path.
+
+   If as a result of the above procedure a given ITAD number appears
+   more than once within the aggregated path, all but the last instance
+   (rightmost occurrence) of that ITAD number should be removed from the
+   aggregated path.
+
+5.4.5. Route Dissemination and AdvertisementPath
+
+   When an LS propagates a route which it has learned from another LS,
+   it shall modify the route's AdvertisementPath attribute based on the
+   location of the LS to which the route will be sent.
+
+      -  When a LS advertises a route to another LS located in its own
+         ITAD, the advertising LS MUST NOT modify the AdvertisementPath
+         attribute associated with the route.
+      -  When a LS advertises a route to an LS located in a neighboring
+         ITAD, then the advertising LS MUST update the AdvertisementPath
+         attribute as follows:
+
+
+
+
+
+
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 34]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+         *  If the first path segment of the AdvertisementPath is of
+            type AP_SEQUENCE, the local system shall prepend its own
+            ITAD number as the last element of the sequence (put it in
+            the leftmost position).
+
+         *  If the first path segment of the AdvertisementPath is of
+            type AP_SET, the local system shall prepend a new path
+            segment of type AP_SEQUENCE to the AdvertisementPath,
+            including its own ITAD number in that segment.
+
+5.5. RoutedPath
+
+   Conditional Mandatory: True
+   (if ReachableRoutes attribute is present).
+   Required Flags: Well-known.
+   Potential Flags: None.
+   TRIP Type Code: 5.
+
+   This attribute identifies the ITADs through which messages sent using
+   this route would pass.  The ITADs in this path are a subset of those
+   in the AdvertisementPath.
+
+5.5.1. RoutedPath Syntax
+
+   The syntax of the RoutedPath attribute is the same as that of the
+   AdvertisementPath attribute.  See Section 5.4.1.
+
+5.5.2. Route Origination and RoutedPath
+
+   When an LS originates a route it MUST include the RoutedPath
+   attribute.
+
+      -  The originating LS shall include its own ITAD number in the
+         RoutedPath attribute of all advertisements sent to LSs located
+         in neighboring ITADs.  In this case, the ITAD number of the
+         originating LS's ITAD will be the only entry in the RoutedPath
+         attribute.
+      -  The originating LS shall include an empty RoutedPath attribute
+         in all advertisements sent to LSs located in its own ITAD.  An
+         empty RoutedPath attribute is one whose length field contains
+         the value zero.
+
+5.5.3. Route Selection and RoutedPath
+
+   The RoutedPath MAY be used for route selection, and in most cases is
+   preferred over the AdvertisementPath for this role.  Some possible
+   criteria to be used are the number of hops on the path and the
+   presence or absence of particular ITADs on the path.
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 35]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+5.5.4. Aggregation and RoutedPath
+
+   The rules for aggregating RoutedPath attributes are given in Section
+   5.4.4.1 and 5.4.4.2, where the term "path" used in Section 5.4.4.1
+   and 5.4.4.2 is understood to mean RoutedPath.
+
+5.5.5. Route Dissemination and RoutedPath
+
+   When an LS propagates a route that it learned from another LS, it
+   modifies the route's RoutedPath attribute based on the location of
+   the LS to which the route is sent.
+
+      -  When an LS advertises a route to another LS located in its own
+         ITAD, the advertising LS MUST NOT modify the RoutedPath
+         attribute associated with the route.
+      -  If the LS has not changed the NextHopServer attribute, then the
+         LS MUST NOT change the RoutedPath attribute.
+      -  Otherwise, the LS changed the NextHopServer and is advertising
+         the route to an LS in another ITAD.  The advertising LS MUST
+         update the RoutedPath attribute as follows:
+
+         *  If the first path segment of the RoutedPath is of type
+            AP_SEQUENCE, the local system shall prepend its own ITAD
+            number as the last element of the sequence (put it in the
+            leftmost position).
+
+         *  If the first path segment of the RoutedPath is of type
+            AP_SET, the local system shall prepend a new path segment of
+            type AP_SEQUENCE to the RoutedPath, including its own ITAD
+            number in that segment.
+
+5.6. AtomicAggregate
+
+   Conditional Mandatory: False.
+   Required Flags: Well-known.
+   Potential Flags: None.
+   TRIP Type Code: 6.
+
+   The AtomicAggregate attribute indicates that a route may traverse
+   domains not listed in the RoutedPath.  If an LS, when presented with
+   a set of overlapping routes from a peer LS, selects the less specific
+   route without selecting the more specific route, then the LS includes
+   the AtomicAggregate attribute with the routing object.
+
+5.6.1. AtomicAggregate Syntax
+
+   This attribute has length zero (0); the value field is empty.
+
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 36]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+5.6.2. Route Origination and AtomicAggregate
+
+   Routes are never originated with the AtomicAggregate attribute.
+
+5.6.3. Route Selection and AtomicAggregate
+
+   The AtomicAggregate attribute may be used in route selection - it
+   indicates that the RoutedPath may be incomplete.
+
+5.6.4. Aggregation and AtomicAggregate
+
+   If any of the routes to aggregate has the AtomicAggregate attribute,
+   then so MUST the resultant aggregate.
+
+5.6.5. Route Dissemination and AtomicAggregate
+
+   If an LS, when presented with a set of overlapping routes from a peer
+   LS, selects the less specific route (see Section 0) without selecting
+   the more specific route, then the LS MUST include the AtomicAggregate
+   attribute with the routing object (if it is not already present).
+
+   An LS receiving a routing object with an AtomicAggregate attribute
+   MUST NOT make the set of destinations more specific when advertising
+   it to other LSs, and MUST NOT remove the attribute when propagating
+   this object to a peer LS.
+
+5.7. LocalPreference
+
+   Conditional Mandatory: False.
+   Required Flags: Well-known.
+   Potential Flags: None.
+   TRIP Type Code: 7.
+
+   The LocalPreference attribute is only used intra-domain, it indicates
+   the local LS's preference for the routing object to other LSs within
+   the same domain.  This attribute MUST NOT be included when
+   communicating to an LS in another domain, and MUST be included over
+   intra-domain links.
+
+5.7.1. LocalPreference Syntax
+
+   The LocalPreference attribute is a 4-octet unsigned numeric value.  A
+   higher value indicates a higher preference.
+
+
+
+
+
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 37]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+5.7.2. Route Origination and LocalPreference
+
+   Routes MUST NOT be originated with the LocalPreference attribute to
+   inter-domain peers.  Routes to intra-domain peers MUST be originated
+   with the LocalPreference attribute.
+
+5.7.3. Route Selection and LocalPreference
+
+   The LocalPreference attribute allows one LS in a domain to calculate
+   a preference for a route, and to communicate this preference to other
+   LSs within the domain.
+
+5.7.4. Aggregation and LocalPreference
+
+   The LocalPreference attribute is not affected by aggregation.
+
+5.7.5. Route Dissemination and LocalPreference
+
+   An LS MUST include the LocalPreference attribute when communicating
+   with peer LSs within its own domain.  An LS MUST NOT include the
+   LocalPreference attribute when communicating with LSs in other
+   domains.  LocalPreference attributes received from inter-domain peers
+   MUST be ignored.
+
+5.8. MultiExitDisc
+
+   Conditional Mandatory: False.
+   Required Flags: Well-known.
+   Potential Flags: None.
+   TRIP Type Code: 8.
+
+   When two ITADs are connected by more than one set of peers, the
+   MultiExitDisc attribute may be used to specify preferences for routes
+   received over one of those links versus routes received over other
+   links.  The MultiExitDisc parameter is used only for route selection.
+
+5.8.1. MultiExitDisc Syntax
+
+   The MultiExitDisc attribute carries a 4-octet unsigned numeric value.
+   A higher value represents a more preferred routing object.
+
+5.8.2. Route Origination and MultiExitDisc
+
+   Routes originated to intra-domain peers MUST NOT be originated with
+   the MultiExitDisc attribute.  When originating a route to an inter-
+   domain peer, the MultiExitDisc attribute may be included.
+
+
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 38]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+5.8.3. Route Selection and MultiExitDisc
+
+   The MultiExitDisc attribute is used to express a preference when
+   there are multiple links between two domains.  If all other factors
+   are equal, then a route with a higher MultiExitDisc attribute is
+   preferred over a route with a lower MultiExitDisc attribute.
+
+5.8.4. Aggregation and MultiExitDisc
+
+   Routes with differing MultiExitDisc parameters MUST NOT be
+   aggregated.  Routes with the same value in the MultiExitDisc
+   attribute MAY be aggregated and the same MultiExitDisc attribute
+   attached to the aggregated object.
+
+5.8.5. Route Dissemination and MultiExitDisc
+
+   If received from a peer LS in another domain, an LS MAY propagate the
+   MultiExitDisc to other LSs within its domain.  The MultiExitDisc
+   attribute MUST NOT be propagated to LSs in other domains.
+
+   An LS may add the MultiExitDisc attribute when propagating routing
+   objects to an LS in another domain.  The inclusion of the
+   MultiExitDisc attribute is a matter of policy, as is the value of the
+   attribute.
+
+5.9. Communities
+
+   Conditional Mandatory: False.
+   Required Flags: Not Well-Known, Independent Transitive.
+   Potential Flags: None.
+   TRIP Type Code: 9.
+
+   A community is a group of destinations that share some common
+   property.
+
+   The Communities attribute is used to group destinations so that the
+   routing decision can be based on the identity of the group.  Using
+   the Communities attribute should significantly simplify the
+   distribution of routing information by providing an administratively
+   defined aggregation unit.
+
+   Each ITAD administrator may define the communities to which a
+   particular route belongs.  By default, all routes belong to the
+   general Internet Telephony community.
+
+   As an example, the Communities attribute could be used to define an
+   alliance between a group of Internet Telephony service providers for
+   a specific subset of routing information.  In this case, members of
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 39]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+   that alliance would accept only routes for destinations in this group
+   that are advertised by other members of the alliance.  Other
+   destinations would be more freely accepted.  To achieve this, a
+   member would tag each route with a designated Community attribute
+   value before disseminating it.  This relieves the members of such an
+   alliance, from the responsibility of keeping track of the identities
+   of all other members of that alliance.
+
+   Another example use of the Communities attribute is with aggregation.
+   It is often useful to advertise both the aggregate route and the
+   component more-specific routes that were used to form the aggregate.
+   These information components are only useful to the neighboring TRIP
+   peer, and perhaps the ITAD of the neighboring TRIP peer, so it is
+   desirable to filter out the component routes.  This can be achieved
+   by specifying a Community attribute value that the neighboring peers
+   will match and filter on.  That way it can be assured that the more
+   specific routes will not propagate beyond their desired scope.
+
+5.9.1. Syntax of Communities
+
+   The Communities attribute is of variable length.  It consists of a
+   set of 8-octet values, each of which specifies a community.  The
+   first 4 octets of the Community value are the Community ITAD Number
+   and the next 4 octets are the Community ID.
+
+   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
+   +---------------+---------------+--------------+----------------+
+   |                       Community ITAD Number 1                 |
+   +---------------+---------------+--------------+----------------+
+   |                         Community ID 1                        |
+   +---------------+---------------+--------------+----------------+
+   |                       . . . . . . . . .
+   +---------------+---------------+--------------+----------------+
+
+                    Figure 14: Communities Syntax
+
+   For administrative assignment, the following assumptions may be made:
+
+      The Community attribute values starting with a Community ITAD
+      Number of 0x00000000 are hereby reserved.
+
+   The following communities have global significance and their
+   operation MUST be implemented in any Community attribute-aware TRIP
+   LS.
+
+
+
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 40]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+      -  NO_EXPORT (Community ITAD Number = 0x00000000 and Community ID
+         = 0xFFFFFF01).  Any received route with a community attribute
+         containing this value MUST NOT be advertised outside of the
+         receiving TRIP ITAD.
+
+   Other community values MUST be encoded using an ITAD number in the
+   four most significant octets.  The semantics of the final four octets
+   (the Community ID octets) may be defined by the ITAD (e.g., ITAD 690
+   may define research, educational, and commercial community IDs that
+   may be used for policy routing as defined by the operators of that
+   ITAD).
+
+5.9.2. Route Origination and Communities
+
+   The Communities attribute is not well-known.  If a route has a
+   Communities attribute associated with it, the LS MUST include that
+   attribute in the advertisement it originates.
+
+5.9.3. Route Selection and Communities
+
+   The Communities attribute may be used for route selection.  A route
+   that is a member of a certain community may be preferred over another
+   route that is not a member of that community.  Likewise, routes
+   without a certain community value may be excluded from consideration.
+
+5.9.4. Aggregation and Communities
+
+   If a set of routes is to be aggregated and the resultant aggregate
+   does not carry an Atomic_Aggregate attribute, then the resulting
+   aggregate should have a Communities attribute that contains the union
+   of the Community attributes of the aggregated routes.
+
+5.9.5. Route Dissemination and Communities
+
+   An LS may manipulate the Communities attribute before disseminating a
+   route to a peer.  Community attribute manipulation may include adding
+   communities, removing communities, adding a Communities attribute (if
+   none exists), deleting the Communities attribute, etc.
+
+5.10. ITAD Topology
+
+   Conditional Mandatory: False.
+   Required Flags: Well-known, Link-State encapsulated.
+   Potential Flags: None.
+   TRIP Type Code: 10.
+
+
+
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 41]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+   Within an ITAD, each LS must know the status of other LSs so that LS
+   failure can be detected.  To do this, each LS advertises its internal
+   topology to other LSs within the domain.  When an LS detects that
+   another LS is no longer active, the information sourced by that LS
+   can be deleted (the Adj-TRIB-In for that peer may be cleared).  The
+   ITAD Topology attribute is used to communicate this information to
+   other LSs within the domain.
+
+   An LS MUST send a topology update each time it detects a change in
+   its internal peer set.  The topology update may be sent in an UPDATE
+   message by itself or it may be piggybacked on an UPDATE message which
+   includes ReachableRoutes and/or WithdrawnRoutes information.
+
+   When an LS receives a topology update from an internal LS, it MUST
+   recalculate which LSs are active within the ITAD via a connectivity
+   algorithm on the topology.
+
+5.10.1. ITAD Topology Syntax
+
+   The ITAD Topology attribute indicates the LSs with which the LS is
+   currently peering.  The attribute consists of a list of the TRIP
+   Identifiers with which the LS is currently peering, the format is
+   given in  Figure 15.  This attribute MUST use the link-state
+   encapsulation as defined in Section 4.3.2.4.
+
+    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
+   +---------------+---------------+--------------+----------------+
+   |                        TRIP Identifier 1                      |
+   +---------------+---------------+--------------+----------------+
+   |                        TRIP Identifier 2 ...                  |
+   +---------------+---------------+--------------+----------------+
+
+                   Figure 15: ITAD Topology Syntax
+
+5.10.2. Route Origination and ITAD Topology
+
+   The ITAD Topology attribute is independent of any routes in the
+   UPDATE.  Whenever the set of internal peers of an LS changes, it MUST
+   create an UPDATE with the ITAD Topology Attribute included listing
+   the current set of internal peers.  The LS MUST include this
+   attribute in the first UPDATE it sends to a peer after the peering
+   session is established.
+
+
+
+
+
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 42]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+5.10.3. Route Selection and ITAD Topology
+
+   This attribute is independent of any routing information in the
+   UPDATE.  When an LS receives an UPDATE with an ITAD Topology
+   attribute, it MUST compute the set of LSs currently active in the
+   domain by performing a connectivity test on the ITAD topology as
+   given by the set of originated ITAD Topology attributes.  The LS MUST
+   locally purge the Adj-TRIB-In for any LS that is no longer active in
+   the domain.  The LS MUST NOT propagate this purging information to
+   other LSs as they will make a similar decision.
+
+5.10.4. Aggregation and ITAD Topology
+
+   This information is not aggregated.
+
+5.10.5. Route Dissemination and ITAD Topology
+
+   An LS MUST ignore the attribute if received from a peer in another
+   domain.  An LS MUST NOT send this attribute to an inter-domain peer.
+
+5.11. ConvertedRoute
+
+   Conditional Mandatory: False.
+   Required Flags: Well-known.
+   Potential Flags: None.
+   TRIP Type Code: 12.
+
+   The ConvertedRoute attribute indicates that an intermediate LS has
+   altered the route by changing the route's Application Protocol.  For
+   example, if an LS receives a route with Application Protocol X and
+   changes the Application Protocol to Y before advertising the route to
+   an external peer, the LS MUST include the ConvertedRoute attribute.
+   The attribute is an indication that the advertised application
+   protocol will not be used end-to-end, i.e., the information
+   advertised about this route is not complete.
+
+5.11.1. ConvertedRoute Syntax
+
+   This attribute has length zero (0); the value field is empty.
+
+5.11.2. Route Origination and ConvertedRoute
+
+   Routes are never originated with the ConvertedRoute attribute.
+
+
+
+
+
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 43]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+5.11.3. Route Selection and ConvertedRoute
+
+   The ConvertedRoute attribute may be used in route selection - it
+   indicates that advertised routing information is not complete.
+
+5.11.4. Aggregation and ConvertedRoute
+
+   If any of the routes to aggregate has the ConvertedRoute attribute,
+   then so MUST the resultant aggregate.
+
+5.11.5. Route Dissemination and ConvertedRoute
+
+   If an LS changes the Application Protocol of a route before
+   advertising the route to an external peer, the LS MUST include the
+   ConvertedRoute attribute.
+
+5.12. Considerations for Defining New TRIP Attributes
+
+   Any proposal for defining new TRIP attributes should specify the
+   following:
+
+      -  the use of this attribute,
+      -  the attribute's flags,
+      -  the attribute's syntax,
+      -  how the attribute works with route origination,
+      -  how the attribute works with route aggregation, and
+      -  how the attribute works with route dissemination and the
+         attribute's scope (e.g., intra-domain only like
+         LocalPreference)
+
+   IANA will manage the assignment of TRIP attribute type codes to new
+   attributes.
+
+6. TRIP Error Detection and Handling
+
+   This section describes errors to be detected and the actions to be
+   taken while processing TRIP messages.
+
+   When any of the conditions described here are detected, a
+   NOTIFICATION message with the indicated Error Code, Error Subcode,
+   and Data fields MUST be sent, and the TRIP connection MUST be closed.
+   If no Error Subcode is specified, then a zero Subcode MUST be used.
+
+   The phrase "the TRIP connection is closed" means that the transport
+   protocol connection has been closed and that all resources for that
+   TRIP connection have been de-allocated.  If the connection was
+   inter-domain, then routing table entries associated with the remote
+   peer MUST be marked as invalid.  Routing table entries MUST NOT be
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 44]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+   marked as invalid if an internal peering session is terminated.  The
+   fact that the routes have been marked as invalid is passed to other
+   TRIP peers before the routes are deleted from the system.
+
+   Unless specified explicitly, the Data field of the NOTIFICATION
+   message that is sent to indicate an error MUST be empty.
+
+6.1. Message Header Error Detection and Handling
+
+   All errors detected while processing the Message Header are indicated
+   by sending the NOTIFICATION message with the Error Code Message
+   Header Error.  The Error Subcode elaborates on the specific nature of
+   the error.  The error checks in this section MUST be performed by
+   each LS upon receipt of every message.
+
+   If the Length field of the message header is less than 3 or greater
+   than 4096, or if the Length field of an OPEN message is less than the
+   minimum length of the OPEN message, or if the Length field of an
+   UPDATE message is less than the minimum length of the UPDATE message,
+   or if the Length field of a KEEPALIVE message is not equal to 3, or
+   if the Length field of a NOTIFICATION message is less than the
+   minimum length of the NOTIFICATION message, then the Error Subcode
+   MUST be set to Bad Message Length.  The Data field contains the
+   erroneous Length field.
+
+   If the Type field of the message header is not recognized, then the
+   Error Subcode MUST be set to "Bad Message Type."  The Data field
+   contains the erroneous Type field.
+
+6.2. OPEN Message Error Detection and Handling
+
+   All errors detected while processing the OPEN message are indicated
+   by sending the NOTIFICATION message with the Error Code "OPEN Message
+   Error."  The Error Subcode elaborates on the specific nature of the
+   error.  The error checks in this section MUST be performed by each LS
+   upon receipt of every OPEN message.
+
+   If the version number contained in the Version field of the received
+   OPEN message is not supported, then the Error Subcode MUST be set to
+   "Unsupported Version Number."  The Data field is a 1-octet unsigned
+   integer, which indicates the largest locally supported version
+   number, which is less than the version of the remote TRIP peer bid
+   (as indicated in the received OPEN message).
+
+   If the ITAD field of the OPEN message is unacceptable, then the Error
+   Subcode MUST be set to "Bad Peer ITAD."  The determination of
+   acceptable ITAD numbers is outside the scope of this protocol.
+
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 45]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+   If the Hold Time field of the OPEN message is unacceptable, then the
+   Error Subcode MUST be set to "Unacceptable Hold Time."  An
+   implementation MUST reject Hold Time values of one or two seconds.
+   An implementation MAY reject any proposed Hold Time.  An
+   implementation that accepts a Hold Time MUST use the negotiated value
+   for the Hold Time.
+
+   If the TRIP Identifier field of the OPEN message is not valid, then
+   the Error Subcode MUST be set to "Bad TRIP Identifier."  A TRIP
+   identifier is 4-octets in length and can take any value.  An LS
+   considers the TRIP Identifier invalid if it already has an open
+   connection with another peer LS that has the same ITAD and TRIP
+   Identifier.
+
+   Any two LSs within the same ITAD MUST NOT have equal TRIP Identifier
+   values.  This restriction does not apply to LSs in different ITADs
+   since the purpose is to uniquely identify an LS using its TRIP
+   Identifier and its ITAD number.
+
+   If one of the Optional Parameters in the OPEN message is not
+   recognized, then the Error Subcode MUST be set to "Unsupported
+   Optional Parameters."
+
+   If the Optional Parameters of the OPEN message include Capability
+   Information with an unsupported capability (unsupported in either
+   capability type or value), then the Error Subcode MUST be set to
+   "Unsupported Capability," and the entirety of the unsupported
+   capabilities MUST be listed in the Data field of the NOTIFICATION
+   message.
+
+   If the Optional Parameters of the OPEN message include Capability
+   Information which does not match the receiving LS's capabilities,
+   then the Error Subcode MUST be set to "Capability Mismatch," and the
+   entirety of the mismatched capabilities MUST be listed in the Data
+   field of the NOTIFICATION message.
+
+6.3. UPDATE Message Error Detection and Handling
+
+   All errors detected while processing the UPDATE message are indicated
+   by sending the NOTIFICATION message with the Error Code "UPDATE
+   Message Error."  The Error Subcode elaborates on the specific nature
+   of the error.  The error checks in this section MUST be performed by
+   each LS upon receipt of every UPDATE message.  These error checks
+   MUST occur before flooding procedures are invoked with internal
+   peers.
+
+
+
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 46]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+   If any recognized attribute has Attribute Flags that conflict with
+   the Attribute Type Code, then the Error Subcode MUST be set to
+   "Attribute Flags Error."  The Data field contains the erroneous
+   attribute (type, length and value).
+
+   If any recognized attribute has an Attribute Length that conflicts
+   with the expected length (based on the attribute type code), then the
+   Error Subcode MUST be set to "Attribute Length Error."  The Data
+   field contains the erroneous attribute (type, length and value).
+
+   If any of the mandatory (i.e., conditional mandatory attribute and
+   the conditions for including it in the UPDATE message are fulfilled)
+   well-known attributes are not present, then the Error Subcode MUST be
+   set to "Missing Well-known Mandatory Attribute."  The Data field
+   contains the Attribute Type Code of the missing well-known
+   conditional mandatory attributes.
+
+   If any of the well-known attributes are not recognized, then the
+   Error Subcode MUST be set to "Unrecognized Well-known Attribute."
+   The Data field contains the unrecognized attribute (type, length and
+   value).
+
+   If any attribute has a syntactically incorrect value, or an undefined
+   value, then the Error Subcode is set to "Invalid Attribute."  The
+   Data field contains the incorrect attribute (type, length and value).
+   Such a NOTIFICATION message is sent, for example, when a
+   NextHopServer attribute is received with an invalid address.
+
+   The information carried by the AdvertisementPath attribute is checked
+   for ITAD loops.  ITAD loop detection is done by scanning the full
+   AdvertisementPath, and checking that the ITAD number of the local
+   ITAD does not appear in the AdvertisementPath.  If the local ITAD
+   number appears in the AdvertisementPath, then the route MAY be stored
+   in the Adj-TRIB-In.  However unless the LS is configured to accept
+   routes with its own ITAD in the advertisement path, the route MUST
+   not be passed to the TRIP Decision Process.  The operation of an LS
+   that is configured to accept routes with its own ITAD number in the
+   advertisement path are outside the scope of this document.
+
+   If the UPDATE message was received from an internal peer and either
+   the WithdrawnRoutes, ReachableRoutes, or ITAD Topology attribute does
+   not have the Link-State Encapsulation flag set, then the Error
+   Subcode is set to "Invalid Attribute" and the data field contains the
+   attribute.  Likewise, the attribute is invalid if received from an
+   external peer and the Link-State Flag is set.
+
+   If any attribute appears more than once in the UPDATE message, then
+   the Error Subcode is set to "Malformed Attribute List."
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 47]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+6.4. NOTIFICATION Message Error Detection and Handling
+
+   If a peer sends a NOTIFICATION message, and there is an error in that
+   message, there is unfortunately no means of reporting this error via
+   a subsequent NOTIFICATION message.  Any such error, such as an
+   unrecognized Error Code or Error Subcode, should be noticed, logged
+   locally, and brought to the attention of the administration of the
+   peer.  The means to do this, however, are outside the scope of this
+   document.
+
+6.5. Hold Timer Expired Error Handling
+
+   If a system does not receive successive messages within the period
+   specified by the negotiated Hold Time, then a NOTIFICATION message
+   with a "Hold Timer Expired" Error Code MUST be sent and the TRIP
+   connection MUST be closed.
+
+6.6. Finite State Machine Error Handling
+
+   An error detected by the TRIP Finite State Machine (e.g., receipt of
+   an unexpected event) MUST result in sending a NOTIFICATION message
+   with the Error Code "Finite State Machine Error" and the TRIP
+   connection MUST be closed.
+
+6.7. Cease
+
+   In the absence of any fatal errors (that are indicated in this
+   section), a TRIP peer MAY choose at any given time to close its TRIP
+   connection by sending the NOTIFICATION message with the Error Code
+   "Cease."  However, the Cease NOTIFICATION message MUST NOT be used
+   when a fatal error indicated by this section exists.
+
+6.8. Connection Collision Detection
+
+   If a pair of LSs try simultaneously to establish a transport
+   connection to each other, then two parallel connections between this
+   pair of speakers might well be formed.  We refer to this situation as
+   connection collision.  Clearly, one of these connections must be
+   closed.
+
+   Based on the value of the TRIP Identifier, a convention is
+   established for detecting which TRIP connection is to be preserved
+   when a collision occurs.  The convention is to compare the TRIP
+   Identifiers of the peers involved in the collision and to retain only
+   the connection initiated by the LS with the higher-valued TRIP
+   Identifier.
+
+
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 48]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+   Upon receipt of an OPEN message, the local LS MUST examine all of its
+   connections that are in the OpenConfirm state.  An LS MAY also
+   examine connections in an OpenSent state if it knows the TRIP
+   Identifier of the peer by means outside of the protocol.  If among
+   these connections there is a connection to a remote LS, whose TRIP
+   Identifier equals the one in the OPEN message, then the local LS MUST
+   perform the following collision resolution procedure:
+
+   The TRIP Identifier and ITAD of the local LS is compared to the TRIP
+   Identifier and ITAD of the remote LS (as specified in the OPEN
+   message).  TRIP Identifiers are treated as 4-octet unsigned integers
+   for comparison.
+
+   If the value of the local TRIP Identifier is less than the remote
+   one, or if the two TRIP Identifiers are equal and the value of the
+   ITAD of the local LS is less than value of the ITAD of the remote LS,
+   then the local LS MUST close the TRIP connection that already exists
+   (the one that is already in the OpenConfirm state), and accept the
+   TRIP connection initiated by the remote LS:
+
+      1. Otherwise, the local LS closes the newly created TRIP
+         connection and continues to use the existing one (the one that
+         is already in the OpenConfirm state).
+      2. If a connection collision occurs with an existing TRIP
+         connection that is in the Established state, then the LS MUST
+         unconditionally close off the newly created connection.  Note
+         that a connection collision cannot be detected with connections
+         in Idle, Connect, or Active states.
+      3. To close the TRIP connection (that results from the collision
+         resolution procedure), an LS MUST send a NOTIFICATION message
+         with the Error Code "Cease" and the TRIP connection MUST be
+         closed.
+
+7. TRIP Version Negotiation
+
+   Peer LSs may negotiate the version of the protocol by making multiple
+   attempts to open a TRIP connection, starting with the highest version
+   number each supports.  If an open attempt fails with an Error Code
+   "OPEN Message Error" and an Error Subcode "Unsupported Version
+   Number," then the LS has available the version number it tried, the
+   version number its peer tried, the version number passed by its peer
+   in the NOTIFICATION message, and the version numbers that it
+   supports.  If the two peers support one or more common versions, then
+   this will allow them to rapidly determine the highest common version.
+   In order to support TRIP version negotiation, future versions of TRIP
+   must retain the format of the OPEN and NOTIFICATION messages.
+
+
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 49]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+8. TRIP Capability Negotiation
+
+   An LS MAY include the Capabilities Option in its OPEN message to a
+   peer to indicate the capabilities supported by the LS.  An LS
+   receiving an OPEN message MUST NOT use any capabilities that were not
+   included in the OPEN message of the peer when communicating with that
+   peer.
+
+9. TRIP Finite State Machine
+
+   This section specifies TRIP operation in terms of a Finite State
+   Machine (FSM).  Following is a brief summary and overview of TRIP
+   operations by state as determined by this FSM.  A condensed version
+   of the TRIP FSM is found in Appendix 1.  There is one TRIP FSM per
+   peer and these FSMs operate independently.
+
+   Idle state:
+   Initially TRIP is in the Idle state for each peer.  In this state,
+   TRIP refuses all incoming connections.  No resources are allocated to
+   the peer.  In response to the Start event (initiated by either the
+   system or the operator), the local system initializes all TRIP
+   resources, starts the ConnectRetry timer, initiates a transport
+   connection to the peer, starts listening for a connection that may be
+   initiated by the remote TRIP peer, and changes its state to Connect.
+   The exact value of the ConnectRetry timer is a local matter, but
+   should be sufficiently large to allow TCP initialization.
+
+   If an LS detects an error, it closes the transport connection and
+   changes its state to Idle.  Transitioning from the Idle state
+   requires generation of the Start event.  If such an event is
+   generated automatically, then persistent TRIP errors may result in
+   persistent flapping of the LS.  To avoid such a condition, Start
+   events MUST NOT be generated immediately for a peer that was
+   previously transitioned to Idle due to an error.  For a peer that was
+   previously transitioned to Idle due to an error, the time between
+   consecutive Start events, if such events are generated automatically,
+   MUST exponentially increase.  The value of the initial timer SHOULD
+   be 60 seconds, and the time SHOULD be at least doubled for each
+   consecutive retry up to some maximum value.
+
+   Any other event received in the Idle state is ignored.
+
+   Connect State:
+   In this state, an LS is waiting for a transport protocol connection
+   to be completed to the peer, and is listening for inbound transport
+   connections from the peer.
+
+
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 50]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+   If the transport protocol connection succeeds, the local LS clears
+   the ConnectRetry timer, completes initialization, sends an OPEN
+   message to its peer, sets its Hold Timer to a large value, and
+   changes its state to OpenSent.  A Hold Timer value of 4 minutes is
+   suggested.
+
+   If the transport protocol connect fails (e.g., retransmission
+   timeout), the local system restarts the ConnectRetry timer, continues
+   to listen for a connection that may be initiated by the remote LS,
+   and changes its state to Active state.
+
+   In response to the ConnectRetry timer expired event, the local LS
+   cancels any outstanding transport connection to the peer, restarts
+   the ConnectRetry timer, initiates a transport connection to the
+   remote LS, continues to listen for a connection that may be initiated
+   by the remote LS, and stays in the Connect state.
+
+   If the local LS detects that a remote peer is trying to establish a
+   connection to it and the IP address of the peer is not an expected
+   one, then the local LS rejects the attempted connection and continues
+   to listen for a connection from its expected peers without changing
+   state.
+
+   If an inbound transport protocol connection succeeds, the local LS
+   clears the ConnectRetry timer, completes initialization, sends an
+   OPEN message to its peer, sets its Hold Timer to a large value, and
+   changes its state to OpenSent.  A Hold Timer value of 4 minutes is
+   suggested.
+
+   The Start event is ignored in the Connect state.
+
+   In response to any other event (initiated by either the system or the
+   operator), the local system releases all TRIP resources associated
+   with this connection and changes its state to Idle.
+
+   Active state:
+   In this state, an LS is listening for an inbound connection from the
+   peer, but is not in the process of initiating a connection to the
+   peer.
+
+   If an inbound transport protocol connection succeeds, the local LS
+   clears the ConnectRetry timer, completes initialization, sends an
+   OPEN message to its peer, sets its Hold Timer to a large value, and
+   changes its state to OpenSent.  A Hold Timer value of 4 minutes is
+   suggested.
+
+
+
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 51]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+   In response to the ConnectRetry timer expired event, the local system
+   restarts the ConnectRetry timer, initiates a transport connection to
+   the TRIP peer, continues to listen for a connection that may be
+   initiated by the remote TRIP peer, and changes its state to Connect.
+
+   If the local LS detects that a remote peer is trying to establish a
+   connection to it and the IP address of the peer is not an expected
+   one, then the local LS rejects the attempted connection and continues
+   to listen for a connection from its expected peers without changing
+   state.
+
+   Start event is ignored in the Active state.
+
+   In response to any other event (initiated by either the system or the
+   operator), the local system releases all TRIP resources associated
+   with this connection and changes its state to Idle.
+
+   OpenSent state:
+   In this state, an LS has sent an OPEN message to its peer and is
+   waiting for an OPEN message from its peer.  When an OPEN message is
+   received, all fields are checked for correctness.  If the TRIP
+   message header checking or OPEN message checking detects an error
+   (see Section 6.2) or a connection collision (see Section 6.8), the
+   local system sends a NOTIFICATION message and changes its state to
+   Idle.
+
+   If there are no errors in the OPEN message, TRIP sends a KEEPALIVE
+   message and sets a KeepAlive timer.  The Hold Timer, which was
+   originally set to a large value (see above), is replaced with the
+   negotiated Hold Time value (see Section 4.2).  If the negotiated Hold
+   Time value is zero, then the Hold Time timer and KeepAlive timers are
+   not started.  If the value of the ITAD field is the same as the local
+   ITAD number, then the connection is an "internal" connection;
+   otherwise, it is "external" (this will affect UPDATE processing).
+   Finally, the state is changed to OpenConfirm.
+
+   If the local LS detects that a remote peer is trying to establish a
+   connection to it and the IP address of the peer is not an expected
+   one, then the local LS rejects the attempted connection and continues
+   to listen for a connection from its expected peers without changing
+   state.
+
+   If a disconnect notification is received from the underlying
+   transport protocol, the local LS closes the transport connection,
+   restarts the ConnectRetry timer, continues to listen for a connection
+   that may be initiated by the remote TRIP peer, and goes into the
+   Active state.
+
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 52]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+   If the Hold Timer expires, the local LS sends a NOTIFICATION message
+   with the Error Code "Hold Timer Expired" and changes its state to
+   Idle.
+
+   In response to the Stop event (initiated by either system or
+   operator) the local LS sends a NOTIFICATION message with the Error
+   Code "Cease" and changes its state to Idle.
+
+   The Start event is ignored in the OpenSent state.
+
+   In response to any other event the local LS sends a NOTIFICATION
+   message with the Error Code "Finite State Machine Error" and changes
+   its state to Idle.
+
+   Whenever TRIP changes its state from OpenSent to Idle, it closes the
+   transport connection and releases all resources associated with that
+   connection.
+
+   OpenConfirm state:
+   In this state, an LS has sent an OPEN to its peer, received an OPEN
+   from its peer, and sent a KEEPALIVE in response to the OPEN.  The LS
+   is now waiting for a KEEPALIVE or NOTIFICATION message in response to
+   its OPEN.
+
+   If the local LS receives a KEEPALIVE message, it changes its state to
+   Established.
+
+   If the Hold Timer expires before a KEEPALIVE message is received, the
+   local LS sends NOTIFICATION message with the Error Code "Hold Timer
+   Expired" and changes its state to Idle.
+
+   If the local LS receives a NOTIFICATION message, it changes its state
+   to Idle.
+
+   If the KeepAlive timer expires, the local LS sends a KEEPALIVE
+   message and restarts its KeepAlive timer.
+
+   If a disconnect notification is received from the underlying
+   transport protocol, the local LS closes the transport connection,
+   restarts the ConnectRetry timer, continues to listen for a connection
+   that may be initiated by the remote TRIP peer, and goes into the
+   Active state.
+
+   In response to the Stop event (initiated by either the system or the
+   operator) the local LS sends NOTIFICATION message with the Error Code
+   "Cease" and changes its state to Idle.
+
+   The Start event is ignored in the OpenConfirm state.
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 53]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+   In response to any other event the local LS sends a NOTIFICATION
+   message with the Error Code "Finite State Machine Error" and changes
+   its state to Idle.
+
+   Whenever TRIP changes its state from OpenConfirm to Idle, it closes
+   the transport connection and releases all resources associated with
+   that connection.
+
+   Established state:
+   In the Established state, an LS can exchange UPDATE, NOTIFICATION,
+   and KEEPALIVE messages with its peer.
+
+   If the negotiated Hold Timer is zero, then no procedures are
+   necessary for keeping a peering session alive.  If the negotiated
+   Hold Time value is non-zero, the procedures of this paragraph apply.
+   If the Hold Timer expires, the local LS sends a NOTIFICATION message
+   with the Error Code "Hold Timer Expired" and changes its state to
+   Idle.  If the KeepAlive Timer expires, then the local LS sends a
+   KeepAlive message and restarts the KeepAlive Timer.  If the local LS
+   receives an UPDATE or KEEPALIVE message, then it restarts its Hold
+   Timer.  Each time the LS sends an UPDATE or KEEPALIVE message, it
+   restarts its KeepAlive Timer.
+
+   If the local LS receives a NOTIFICATION message, it changes its state
+   to Idle.
+
+   If the local LS receives an UPDATE message and the UPDATE message
+   error handling procedure (see Section6.3) detects an error, the local
+   LS sends a NOTIFICATION message and changes its state to Idle.
+
+   If a disconnect notification is received from the underlying
+   transport protocol, the local LS changes its state to Idle.
+
+   In response to the Stop event (initiated by either the system or the
+   operator), the local LS sends a NOTIFICATION message with the Error
+   Code "Cease" and changes its state to Idle.
+
+   The Start event is ignored in the Established state.
+
+   In response to any other event, the local LS sends a NOTIFICATION
+   message with Error Code "Finite State Machine Error" and changes its
+   state to Idle.
+
+   Whenever TRIP changes its state from Established to Idle, it closes
+   the transport connection and releases all resources associated with
+   that connection.  Additionally, if the peer is an external peer, the
+   LS deletes all routes derived from that connection.
+
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 54]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+10. UPDATE Message Handling
+
+   An UPDATE message may be received only in the Established state.
+   When an UPDATE message is received, each field is checked for
+   validity as specified in Section 6.3.  The rest of this section
+   presumes that the UPDATE message has passed the error-checking
+   procedures of Section 6.3.
+
+   If the UPDATE message was received from an internal peer, the
+   flooding procedures of Section 10.1 MUST be applied.  The flooding
+   process synchronizes the Loc-TRIBs of all LSs within the domain.
+   Certain routes within the UPDATE may be marked as old or duplicates
+   by the flooding process and are ignored during the rest of the UPDATE
+   processing.
+
+   If the UPDATE message contains withdrawn routes, then the
+   corresponding previously advertised routes shall be removed from the
+   Adj-TRIB-In.  This LS MUST rerun its Decision Process since the
+   previously advertised route is no longer available for use.
+
+   If the UPDATE message contains a route, then the route MUST be placed
+   in the appropriate Adj-TRIB-In, and the following additional actions
+   MUST be taken:
+
+      1. If its destinations are identical to those of a route currently
+         stored in the Adj-TRIB-In, then the new route MUST replace the
+         older route in the Adj-TRIB-In, thus implicitly withdrawing the
+         older route from service.  The LS MUST rerun its Decision
+         Process since the older route is no longer available for use.
+      2. If the new route is more specific than an earlier route
+         contained in the Adj-TRIB-In and has identical attributes, then
+         no further actions are necessary.
+      3. If the new route is more specific than an earlier route
+         contained in the Adj-TRIB-In but does not have identical
+         attributes, then the LS MUST run its Decision Process since the
+         more specific route has implicitly made a portion of the less
+         specific route unavailable for use.
+      4. If the new route has destinations that are not present in any
+         of the routes currently stored in the Adj-TRIB-In, then the LS
+         MUST run its Decision Process.
+      5. If the new route is less specific than an earlier route
+         contained in the Adj-TRIB-In, the LS MUST run its Decision
+         Process on the set of destinations that are described only by
+         the less specific route.
+
+
+
+
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 55]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+10.1. Flooding Process
+
+   When an LS receives an UPDATE message from an internal peer, the LS
+   floods the new information from that message to all of its other
+   internal peers.  Flooding is used to efficiently synchronize all of
+   the LSs within a domain without putting any constraints on the
+   domain's internal topology.  The flooding mechanism is based on the
+   techniques used in OSPF [4] and SCSP [6].  One may argue that TRIP's
+   flooding process is in reality a controlled broadcast mechanism.
+
+10.1.1. Database Information
+
+   The LS MUST maintain the sequence number and originating TRIP
+   identifier for each link-state encapsulated attribute in an internal
+   Adj-TRIB-In.  These values are included with the route in the
+   ReachableRoutes, WithdrawnRoutes, and ITAD Topology attributes.  The
+   originating TRIP identifier gives the internal LS that originated
+   this route into the ITAD, the sequence number gives the version of
+   this route at the originating LS.
+
+10.1.2. Determining Newness
+
+   For each route in the ReachableRoutes or WithdrawnRoutes field, the
+   LS decides if the route is new or old.  This is determined by
+   comparing the Sequence Number of the route in the UPDATE with the
+   Sequence Number of the route saved in the Adj-TRIB-In.  The route is
+   new if either the route does not exist in the Adj-TRIB-In for the
+   originating LS, or if the route does exist in the Adj-TRIB-In but the
+   Sequence Number in the UPDATE is greater than the Sequence Number
+   saved in the Adj-TRIBs-In.  Note that the newness test is
+   independently applied to each link-state encapsulated attribute in
+   the UPDATE (WithdrawnRoutes or ReachableRoutes or ITAD Topology).
+
+10.1.3. Flooding
+
+   Each route in the ReachableRoutes or WithdrawnRoutes field that is
+   determined to be old is ignored in further processing.  If the route
+   is determined to be new then the following actions occur.
+
+   If the route is being withdrawn, then the LS MUST flood the withdrawn
+   route to all other internal peers, and MUST mark the route as
+   withdrawn.  An LS MUST maintain routes marked as withdrawn in its
+   databases for MaxPurgeTime seconds.
+
+   If the route is being updated, then the LS MUST update the route in
+   the Adj-TRIB-In and MUST flood it to all other internal peers.
+
+
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 56]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+   If these procedures result in changes to the Adj-TRIB-In, then the
+   route is also made available for local route processing as described
+   early in Section 10.
+
+   To implement flooding, the following is recommended.  All routes
+   received in a single UPDATE message that are determined to be new
+   should be forwarded to all other internal peers in a single UPDATE
+   message.  Other variations of flooding are possible, but the local LS
+   MUST ensure that each new route (and any associated attributes)
+   received from an internal peer get forwarded to every other internal
+   peer.
+
+10.1.4. Sequence Number Considerations
+
+   The Sequence Number is used to determine when one version of a Route
+   is newer than another version of a route.  A larger Sequence Number
+   indicates a newer version.  The Sequence Number is assigned by the LS
+   originating the route into the local ITAD.  The Sequence Number is an
+   unsigned 4-octet integer in the range of 1 thru 2^31-1 MinSequenceNum
+   thru MaxSequenceNum).  The value 0 is reserved.  When an LS first
+   originates a route (including when the LS restarts/reboots) into its
+   ITAD, it MUST originate it with a Sequence Number of MinSequenceNum.
+   Each time the route is updated within the ITAD by the originator, the
+   Sequence Number MUST be increased.
+
+   If it is ever the case that the sequence number is MaxSequenceNum-1
+   and it needs to be increased, then the TRIP module of the LS MUST be
+   disabled for a period of TripDisableTime so that all routes
+   originated by this LS with high sequence numbers can be removed.
+
+10.1.5. Purging a Route Within the ITAD
+
+   To withdraw a route that it originated within the ITAD, an LS
+   includes the route in the WithdrawnRoutes field of an UPDATE message.
+   The Sequence Number MUST be greater than the last valid version of
+   the route.  The LS MAY choose to use a sequence number of
+   MaxSequenceNum when withdrawing routes within its ITAD, but this is
+   not required.
+
+   After withdrawing a route, an LS MUST mark the route as "withdrawn"
+   in its database, and maintain the withdrawn route in its database for
+   MaxPurgeTime seconds.  If the LS needs to re-originate a route that
+   had been purged but is still in its database, it can either re-
+   originate the route immediately using a Sequence Number that is
+   greater than that used in the withdraw, or the LS may wait until
+   MaxPurgeTime seconds have expired since the route was withdrawn.
+
+
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 57]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+10.1.6. Receiving Self-Originated Routes
+
+   It is common for an LS to receive UPDATES for routes that it
+   originated within the ITAD via the flooding procedure.  If the LS
+   receives an UPDATE for a route that it originated that is newer (has
+   a higher sequence number) than the LSs current version, then special
+   actions must be taken.  This should be a relatively rare occurrence
+   and indicates that a route still exists within the ITAD since the LSs
+   last restart/reboot.
+
+   If an LS receives a self-originated route update that is newer than
+   the current version of the route at the LS, then the following
+   actions MUST be taken.  If the LS still wishes to advertise the
+   information in the route, then the LS MUST increase the Sequence
+   Number of the route to a value greater than that received in the
+   UPDATE and re-originate the route.  If the LS does not wish to
+   continue to advertise the route, then it MUST purge the route as
+   described in Section 10.1.5.
+
+10.1.7. Removing Withdrawn Routes
+
+   An LS SHOULD ensure that routes marked as withdrawn are removed from
+   the database in a timely fashion after the MaxPurgeTime has expired.
+   This could be done, for example, by periodically sweeping the
+   database, and deleting those entries that were withdrawn more than
+   MaxPurgeTime seconds ago.
+
+10.2. Decision Process
+
+   The Decision Process selects routes for subsequent advertisement by
+   applying the policies in the local Policy Information Base (PIB) to
+   the routes stored in its Adj-TRIBs-In.  The output of the Decision
+   process is the set of routes that will be advertised to all peers;
+   the selected routes will be stored in the local LS's Adj-TRIBs-Out.
+
+   The selection process is formalized by defining a function that takes
+   the attributes of a given route as an argument and returns a non-
+   negative integer denoting the degree of preference for the route.
+   The function that calculates the degree of preference for a given
+   route shall not use as its inputs any of the following:  the
+   existence of other routes, the non-existence of other routes, or the
+   attributes of other routes.  Route selection then consists of an
+   individual application of the degree of preference function to each
+   feasible route, followed by the choice of the one with the highest
+   degree of preference.
+
+
+
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 58]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+   All internal LSs in an ITAD MUST run the Decision Process and apply
+   the same decision criteria, otherwise it will not be possible to
+   synchronize their Loc-TRIBs.
+
+   The Decision Process operates on routes contained in each Adj-TRIBs-
+   In, and is responsible for:
+
+      -  selection of routes to be advertised to internal peers
+      -  selection of routes to be advertised to external peers
+      -  route aggregation and route information reduction
+
+   The Decision Process takes place in three distinct phases, each
+   triggered by a different event:
+
+      -  Phase 1 is responsible for calculating the degree of preference
+         for each route received from an external peer.
+      -  Phase 2 is invoked on completion of phase 1.  It is responsible
+         for choosing the best route out of all those available for each
+         distinct destination, and for installing each chosen route into
+         the Loc-TRIB.
+      -  Phase 3 is invoked after the Loc-TRIB has been modified.  It is
+         responsible for disseminating routes in the Loc-TRIB to each
+         external peer, according to the policies contained in the PIB.
+         Route aggregation and information reduction can optionally be
+         performed within this phase.
+
+10.2.1. Phase 1: Calculation of Degree of Preference
+
+   The Phase 1 decision function shall be invoked whenever the local LS
+   receives from a peer an UPDATE message that advertises a new route, a
+   replacement route, or a withdrawn route.
+
+   The Phase 1 decision function is a separate process that is completed
+   when it has no further work to do.
+
+   The Phase 1 decision function shall lock an Adj-TRIB-In prior to
+   operating on any route contained within it, and shall unlock it after
+   operating on all new or replacement routes contained within it.
+
+   The local LS MUST determine a degree of preference for each newly
+   received or replacement route.  If the route is learned from an
+   internal peer, the value of the LocalPreference attribute MUST be
+   taken as the degree of preference.  If the route is learned from an
+   external peer, then the degree of preference MUST be computed based
+   on pre-configured policy information and used as the LocalPreference
+   value in any intra-domain TRIP advertisement.  The exact nature of
+   this policy information and the computation involved is a local
+   matter.
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 59]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+   The output of the degree of preference determination process is the
+   local preference of a route.  The local LS computes the local
+   preference of routes learned from external peers or originated
+   internally at that LS.  The local preference of a route learned from
+   an internal peer is included in the LocalPreference attribute
+   associated with that route.
+
+10.2.2. Phase 2: Route Selection
+
+   The Phase 2 decision function shall be invoked on completion of Phase
+   1.  The Phase 2 function is a separate process that completes when it
+   has no further work to do.  Phase 2 consists of two sub-phases: 2a
+   and 2b.  The same route selection function is applied in both sub-
+   phases, but the inputs to each phase are different.  The Phase 2a
+   process MUST consider as inputs all external routes, that are present
+   in the Adj-TRIBs-In of external peers, and all local routes.  The
+   output of Phase 2a is inserted into the Ext-TRIB.  The Phase 2b
+   process shall be invoked upon completion of Phase 2a and it MUST
+   consider as inputs all routes in the Ext-TRIB and all routes that are
+   present in the Adj-TRIBs-In of internal LSs.  The output of Phase 2b
+   is stored in the Loc-TRIB.
+
+   The Phase 2 decision function MUST be blocked from running while the
+   Phase 3 decision function is in process.  The Phase 2 function MUST
+   lock all Adj-TRIBs-In and the Ext-TRIB prior to commencing its
+   function, and MUST unlock them on completion.
+
+   If the LS determines that the NextHopServer listed in a route is
+   unreachable, then the route MAY be excluded from the Phase 2 decision
+   function.  The means by which such a determination is made is not
+   mandated here.
+
+   For each set of destinations for which one or more routes exist, the
+   local LS's route selection function MUST identify the route that has:
+
+      -  the highest degree of preference, or
+      -  is selected as a result of the tie breaking rules specified in
+         10.2.2.1.
+
+   Withdrawn routes MUST be removed from the Loc-TRIB, Ext-TRIB, and the
+   Adj-TRIBs-In.
+
+10.2.2.1. Breaking Ties (Phase 2)
+
+   Several routes to the same destination that have the same degree of
+   preference may be input to the Phase 2 route selection function.  The
+   local LS can select only one of these routes for inclusion in the
+
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 60]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+   associated Ext-TRIB (Phase 2a) or Loc-TRIB (Phase 2b).  The local LS
+   considers all routes with the same degrees of preference.  The
+   following algorithm shall be used to break ties.
+
+      -  If the local LS is configured to use the MultiExitDisc
+         attribute to break ties, and candidate routes received from the
+         same neighboring ITAD differ in the value of the MultiExitDisc
+         attribute, then select the route that has the larger value of
+         MultiExitDisc.
+      -  If at least one of the routes was originated by an internal LS,
+         select the route route that was advertised by the internal LS
+         that has the lowest TRIP ID.
+      -  Otherwise, select the route that was advertised by the neighbor
+         domain that has the lowest ITAD number.
+
+10.2.3. Phase 3: Route Dissemination
+
+   The Phase 3 decision function MUST be invoked upon completion of
+   Phase 2 if Phase 2 results in changes to the Loc-TRIB or when a new
+   LS-to-LS peer session is established.
+
+   The Phase 3 function is a separate process that is completed when it
+   has no further work to do.  The Phase 3 routing decision function
+   MUST be blocked from running while the Phase 2 decision function is
+   in process.
+
+   All routes in the Loc-TRIB shall be processed into a corresponding
+   entry in the associated Adj-TRIBs-Out.  Route aggregation and
+   information reduction techniques (see 10.3.4) MAY optionally be
+   applied.
+
+   When the updating of the Adj-TRIBs-Out is complete, the local LS MUST
+   run the external update process of 10.3.2.
+
+10.2.4. Overlapping Routes
+
+   When overlapping routes are present in the same Adj-TRIB-In, the more
+   specific route shall take precedence, in order, from most specific to
+   least specific.
+
+   The set of destinations described by the overlap represents a portion
+   of the less specific route that is feasible, but is not currently in
+   use.  If a more specific route is later withdrawn, the set of
+   destinations described by the more specific route will still be
+   reachable using the less specific route.
+
+
+
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 61]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+   If an LS receives overlapping routes, the Decision Process MUST take
+   into account the semantics of the overlapping routes.  In particular,
+   if an LS accepts the less specific route while rejecting the more
+   specific route from the same peer, then the destinations represented
+   by the overlap may not forward along the domains listed in the
+   AdvertisementPath attribute of that route.  Therefore, an LS has the
+   following choices:
+
+      1. Install both the less and the more specific routes
+      2. Install the more specific route only
+      3. Install the non-overlapping part of the less specific route
+         only (that implies disaggregation of the less-specific route)
+      4. Aggregate the two routes and install the aggregated route
+      5. Install the less specific route only
+      6. Install neither route
+
+   If an LS chooses 5), then it SHOULD add AtomicAggregate attribute to
+   the route.  A route that carries AtomicAggregate attribute MUST NOT
+   be de-aggregated.  That is, the route cannot be made more specific.
+   Forwarding along such a route does not guarantee that route traverses
+   only domains listed in the RoutedPath of the route.  If an LS chooses
+   1), then it MUST NOT advertise the less specific route without the
+   more specific route.
+
+10.3. Update-Send Process
+
+   The Update-Send process is responsible for advertising UPDATE
+   messages to all peers.  For example, it distributes the routes chosen
+   by the Decision Process to other LSs that may be located in either
+   the same ITAD or a neighboring ITAD.  Rules for information exchange
+   between peer LSs located in different ITADs are given in 10.3.2;
+   rules for information exchange between peer LSs located in the same
+   ITAD are given in 10.3.1.
+
+   Before forwarding routes to peers, an LS MUST determine which
+   attributes should be forwarded along with that route.  If a not
+   well-known non-transitive attribute is unrecognized, it is quietly
+   ignored.  If a not well-known dependent-transitive attribute is
+   unrecognized, and the NextHopServer attribute has been changed by the
+   LS, the unrecognized attribute is quietly ignored.  If a not well-
+   known dependent-transitive attribute is unrecognized, and the
+   NextHopServer attribute has not been modified by the LS, the Partial
+   bit in the attribute flags octet is set to 1, and the attribute is
+   retained for propagation to other TRIP speakers.  Similarly, if an
+   not well-known independent-transitive attribute is unrecognized, the
+   Partial bit in the attribute flags octet is set to 1, and the
+   attribute is retained for propagation to other TRIP speakers.
+
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 62]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+   If a not well-known attribute is recognized, and has a valid value,
+   then, depending on the type of the not well-known attribute, it is
+   updated, if necessary, for possible propagation to other TRIP
+   speakers.
+
+10.3.1. Internal Updates
+
+   The Internal update process is concerned with the distribution of
+   routing information to internal peers.
+
+   When an LS receives an UPDATE message from another TRIP LS located in
+   its own ITAD, it is flooded as described in Section 10.1.
+
+   When an LS receives a new route from an LS in a neighboring ITAD, or
+   if a local route is injected into TRIP, the LS determines the
+   preference of that route.  If the new route has the highest degree of
+   preference for all external routes and local routes to a given
+   destination (or if the route was selected via a tie-breaking
+   procedure as specified in 10.3.1.1), the LS MUST insert that new
+   route into the Ext-TRIB database and the LS MUST advertise that route
+   to all other LSs in its ITAD by means of an UPDATE message.  The LS
+   MUST advertise itself as the Originator of that route within the
+   ITAD.
+
+   When an LS receives an UPDATE message with a non-empty
+   WithdrawnRoutes attribute from an external peer, or if a local route
+   is withdrawn from TRIP, the LS MUST remove from its Adj-TRIB-In all
+   routes whose destinations were carried in this field.  If the
+   withdrawn route was previously selected into the Ext-TRIB, the LS
+   MUST take the following additional steps:
+
+      -  If a new route is selected for advertisement for those
+         destinations, then the LS MUST insert the replacement route
+         into Ext-TRIB to replace the withdrawn route and advertise it
+         to all internal LSs.
+      -  If a replacement route is not available for advertisement, then
+         the LS MUST include the destinations of the route in the
+         WithdrawnRoutes attribute of an UPDATE message, and MUST send
+         this message to each internal peer.  The LS MUST also remove
+         the withdrawn route from the Ext-TRIB.
+
+10.3.1.1. Breaking Ties (Routes Received from External Peers)
+
+   If an LS has connections to several external peers, there will be
+   multiple Adj-TRIBs-In associated with these peers.  These databases
+   might contain several equally preferable routes to the same
+
+
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 63]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+   destination, all of which were advertised by external peers.  The
+   local LS shall select one of these routes according to the following
+   rules:
+
+      -  If the LS is configured to use the MultiExitDisc attribute to
+         break ties, and the candidate routes differ in the value of the
+         MultiExitDisc attribute, then select the route that has the
+         lowest value of MultiExitDisc, else
+      -  Select the route that was advertised by the external LS that
+         has the lowest TRIP Identifier.
+
+10.3.2. External Updates
+
+   The external update process is concerned with the distribution of
+   routing information to external peers.  As part of the Phase 3 route
+   selection process, the LS has updated its Adj-TRIBs-Out.  All newly
+   installed routes and all newly unfeasible routes for which there is
+   no replacement route MUST be advertised to external peers by means of
+   UPDATE messages.
+
+   Any routes in the Loc-TRIB marked as withdrawn MUST be removed.
+   Changes to the reachable destinations within its own ITAD SHALL also
+   be advertised in an UPDATE message.
+
+10.3.3. Controlling Routing Traffic Overhead
+
+   The TRIP protocol constrains the amount of routing traffic (that is,
+   UPDATE messages) in order to limit both the link bandwidth needed to
+   advertise UPDATE messages and the processing power needed by the
+   Decision Process to digest the information contained in the UPDATE
+   messages.
+
+10.3.3.1. Frequency of Route Advertisement
+
+   The parameter MinRouteAdvertisementInterval determines the minimum
+   amount of time that must elapse between advertisements of routes to a
+   particular destination from a single LS.  This rate limiting
+   procedure applies on a per-destination basis, although the value of
+   MinRouteAdvertisementInterval is set on a per LS peer basis.
+
+   Two UPDATE messages sent from a single LS that advertise feasible
+   routes to some common set of destinations received from external
+   peers MUST be separated by at least MinRouteAdvertisementInterval.
+   Clearly, this can only be achieved precisely by keeping a separate
+   timer for each common set of destinations.  This would be unwarranted
+   overhead.  Any technique which ensures that the interval between two
+   UPDATE messages sent from a single LS that advertise feasible routes
+
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 64]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+   to some common set of destinations received from external peers will
+   be at least MinRouteAdvertisementInterval, and will also ensure that
+   a constant upper bound on the interval is acceptable.
+
+   Two UPDATE messages, sent from a single LS to an external peer, that
+   advertise feasible routes to some common set of destinations received
+   from internal peers MUST be separated by at least
+   MinRouteAdvertisementInterval.
+
+   Since fast convergence is needed within an ITAD, this rate limiting
+   procedure does not apply to routes received from internal peers and
+   being broadcast to other internal peers.  To avoid long-lived black
+   holes, the procedure does not apply to the explicit withdrawal of
+   routes (that is, routes whose destinations explicitly withdrawn by
+   UPDATE messages).
+
+   This procedure does not limit the rate of route selection, but only
+   the rate of route advertisement.  If new routes are selected multiple
+   times while awaiting the expiration of MinRouteAdvertisementInterval,
+   the last route selected shall be advertised at the end of
+   MinRouteAdvertisementInterval.
+
+10.3.3.2. Frequency of Route Origination
+
+   The parameter MinITADOriginationInterval determines the minimum
+   amount of time that must elapse between successive advertisements of
+   UPDATE messages that report changes within the advertising LS's own
+   ITAD.
+
+10.3.3.3. Jitter
+
+   To minimize the likelihood that the distribution of TRIP messages by
+   a given LS will contain peaks, jitter should be applied to the timers
+   associated with MinITADOriginationInterval, KeepAlive, and
+   MinRouteAdvertisementInterval.  A given LS shall apply the same
+   jitter to each of these quantities regardless of the destinations to
+   which the updates are being sent; that is, jitter will not be applied
+   on a "per peer" basis.
+
+   The amount of jitter to be introduced shall be determined by
+   multiplying the base value of the appropriate timer by a random
+   factor that is uniformly distributed in the range from 0.75 to 1.0.
+
+
+
+
+
+
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 65]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+10.3.4. Efficient Organization of Routing Information
+
+   Having selected the routing information that it will advertise, a
+   TRIP speaker may use methods to organize this information in an
+   efficient manner.  These methods are discussed in the following
+   sections.
+
+10.3.4.1. Information Reduction
+
+   Information reduction may imply a reduction in granularity of policy
+   control - after information has collapsed, the same policies will
+   apply to all destinations and paths in the equivalence class.
+
+   The Decision Process may optionally reduce the amount of information
+   that it will place in the Adj-TRIBs-Out by any of the following
+   methods:
+
+      -  ReachableRoutes: A set of destinations can be usually
+         represented in compact form.  For example, a set of E.164 phone
+         numbers can be represented in more compact form using E.164
+         prefixes.
+      -  AdvertisementPath: AdvertisementPath information can be
+         represented as ordered AP_SEQUENCEs or unordered AP_SETs.
+         AP_SETs are used in the route aggregation algorithm described
+         in Section 5.4.4.  They reduce the size of the AP_PATH
+         information by listing each ITAD number only once, regardless
+         of how many times it may have appeared in multiple
+         advertisement paths that were aggregated.
+
+   An AP_SET implies that the destinations advertised in the UPDATE
+   message can be reached through paths that traverse at least some of
+   the constituent ITADs.  AP_SETs provide sufficient information to
+   avoid route looping; however their use may prune potentially feasible
+   paths, since such paths are no longer listed individually as in the
+   form of AP_SEQUENCEs.  In practice this is not likely to be a
+   problem, since once a call arrives at the edge of a group of ITADs,
+   the LS at that point is likely to have more detailed path information
+   and can distinguish individual paths to destinations.
+
+10.3.4.2. Aggregating Routing Information
+
+   Aggregation is the process of combining the characteristics of
+   several different routes in such a way that a single route can be
+   advertised.  Aggregation can occur as part of the decision process to
+   reduce the amount of routing information that is placed in the Adj-
+   TRIBs-Out.
+
+
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 66]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+   Aggregation reduces the amount of information an LS must store and
+   exchange with other LSs.  Routes can be aggregated by applying the
+   following procedure separately to attributes of like type.
+
+   Routes that have the following attributes shall not be aggregated
+   unless the corresponding attributes of each route are identical:
+   MultiExitDisc, NextHopServer.
+
+   Attributes that have different type codes cannot be aggregated.
+   Attributes of the same type code may be aggregated.  The rules for
+   aggregating each attribute MUST be provided together with attribute
+   definition.  For example, aggregation rules for TRIP's basic
+   attributes, e.g., ReachableRoutes and AdvertisementPath, are given in
+   Section 5.
+
+10.4. Route Selection Criteria
+
+   Generally speaking, additional rules for comparing routes among
+   several alternatives are outside the scope of this document.  There
+   are two exceptions:
+
+      -  If the local ITAD appears in the AdvertisementPath of the new
+         route being considered, then that new route cannot be viewed as
+         better than any other route.  If such a route were ever used, a
+         routing loop could result (see Section 6.3).
+      -  In order to achieve successful distributed operation, only
+         routes with a likelihood of stability can be chosen.  Thus, an
+         ITAD must avoid using unstable routes, and it must not make
+         rapid spontaneous changes to its choice of route.  Quantifying
+         the terms "unstable" and "rapid" in the previous sentence will
+         require experience, but the principle is clear.
+
+10.5. Originating TRIP Routes
+
+   An LS may originate local routes by injecting routing information
+   acquired by some other means (e.g. via an intra-domain routing
+   protocol or through manual configuration or some dynamic registration
+   mechanism/protocol) into TRIP.  An LS that originates TRIP routes
+   shall assign the degree of preference to these routes by passing them
+   through the Decision Process (see Section 10.2).  To TRIP, local
+   routes are identical to external routes and are subjected to the same
+   two phase route selection mechanism.  A local route which is selected
+   into the Ext-TRIB MUST be advertised to all internal LSs.  The
+   decision whether to distribute non-TRIP acquired routes within an
+   ITAD via TRIP or not depends on the environment within the ITAD (e.g.
+   type of intra-domain routing protocol) and should be controlled via
+   configuration.
+
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 67]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+11. TRIP Transport
+
+   This specification defines the use of TCP as the transport layer for
+   TRIP.  TRIP uses TCP port 6069.  Running TRIP over other transport
+   protocols is for further study.
+
+12. ITAD Topology
+
+   There are no restrictions on the intra-domain topology of TRIP LSs.
+   For example, LSs in an ITAD can be configured in a full mesh, star,
+   or any other connected topology.  Similarly, there are no
+   restrictions on the topology of TRIP ITADs.  For example, the ITADs
+   can be organized in a flat topology (mesh or ring) or in multi-level
+   hierarchy or any other topology.
+
+   The border between two TRIP ITADs may be located either on the link
+   between two TRIP LSs or it may coincide on a TRIP LS.  In the latter
+   case, the same TRIP LS will be member in more than one ITAD, and it
+   appears to be an internal peer to LSs in each ITAD it is member of.
+
+13. IANA Considerations
+
+   This document creates a new IANA registry for TRIP parameters.  The
+   following TRIP parameters are included in the registry:
+
+      - TRIP Capabilities
+      - TRIP Attributes
+      - TRIP Address Families
+      - TRIP Application Protocols
+      - TRIP ITAD Numbers
+
+   Protocol parameters are frequently initialized/reset to 0.  This
+   document reserves the value 0 of each of the above TRIP parameters in
+   order to clearly distinguish between an unset parameter and any other
+   registered values for that parameter.
+
+   The sub-registries for each of the above parameters are discussed in
+   the sections below.
+
+13.1. TRIP Capabilities
+
+   Requests to add TRIP capabilities other than those defined in Section
+   4.2.1.1 must be submitted to iana@iana.org.  Following the assigned
+   number policies outlined in [11], Capability Codes in the range
+   32768-65535 are reserved for Private Use (these are the codes with
+   the first bit of the code value equal to 1).  This document reserves
+   value 0.  Capability Codes 1 and 2 have been assigned in Section
+   4.2.1.1.  Capability Codes in the range 2-32767 are controlled by
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 68]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+   IANA, and are allocated subject to the Specification Required (IETF
+   RFC or equivalent) condition.  The specification MUST include a
+   description of the capability, the possible values it may take, and
+   what constitutes a capability mismatch.
+
+13.2. TRIP Attributes
+
+   This document reserves Attribute Type Codes 224-255 for Private Use
+   (these are the codes with the first three bits of the code equal to
+   1).  This document reserves the value 0.  Attribute Type Codes 1
+   through 11 have already been allocated by this document.  Attribute
+   Type Codes 1 through 11 are defined in Sections 5.1 through 5.11.
+
+   Attribute Type Codes in the range 12-223 are controlled by IANA, and
+   require a Specification document (RFC or equivalent).  The
+   specification MUST provide all information required in Section 5.12
+   of this document.
+
+   Attribute Type Code registration requests must be sent to
+   iana@iana.org.  In addition to the specification requirement, the
+   request MUST include an indication of who has change control over the
+   attribute and contact information (postal and email address).
+
+13.3. Destination Address Families
+
+   This document reserves address family 0. Requests to add TRIP address
+   families other than those defined in Section 5.1.1.1 ( address
+   families 1, 2, and 3), i.e., in the range 4-32767, must be submitted
+   to iana@iana.org.  The request MUST include a brief description of
+   the address family, its alphabet, and special processing rules and
+   guidelines, such as guidelines for aggregation, if any.  The requests
+   are subject to Expert Review.  This document reserves the address
+   family codes 32768-65535 for vendor-specific applications.
+
+13.4. TRIP Application Protocols
+
+   This document creates a new IANA registry for TRIP application
+   protocols.  This document reserves the application protocol code 0.
+   Requests to add TRIP application protocols other than those defined
+   in Section 5.1.1.1 (application protocols 1 through 4), i.e., in the
+   range 5-32767, must be submitted to iana@iana.org.  The request MUST
+   include a brief background on the application protocol, and a
+   description of how TRIP can be used to advertise routes for that
+   protocol.  The requests are subject to Expert Review.  This document
+   reserves the application protocol codes 32768-65535 for vendor-
+   specific applications.
+
+
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 69]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+13.5. ITAD Numbers
+
+   This document reserves the ITAD number 0.  ITAD numbers in the range
+   1-255 are designated for Private Use.  ITAD numbers in the range from
+   256 to (2**32)-1 are allocated by IANA on a First-Come-First-Serve
+   basis.  Requests for ITAD numbers must be submitted to iana@iana.org.
+   The requests MUST include the following:
+
+      -  Information about the organization that will administer the
+         ITAD.
+      -  Contact information (postal and email address).
+
+14. Security Considerations
+
+   This section covers security between peer TRIP LSs when TRIP runs
+   over TCP in an IP environment.
+
+   A security mechanism is clearly needed to prevent unauthorized
+   entities from using the protocol defined in this document for setting
+   up unauthorized peer sessions with other TRIP LSs or interfering with
+   authorized peer sessions.  The security mechanism for the protocol,
+   when transported over TCP in an IP network, is IPsec [12].  IPsec
+   uses two protocols to provide traffic security: Authentication Header
+   (AH) [13] and Encapsulating Security Payload (ESP) [14].
+
+   The AH header affords data origin authentication, connectionless
+   integrity and optional anti-replay protection of messages passed
+   between the peer LSs.  The ESP header provides origin authentication,
+   connectionless integrity, anti-replay protection, and confidentiality
+   of messages.
+
+   Implementations of the protocol defined in this document employing
+   the ESP header SHALL comply with section 5 of [14], which defines a
+   minimum set of algorithms for integrity checking and encryption.
+   Similarly, implementations employing the AH header SHALL comply with
+   section 5 of [13], which defines a minimum set of algorithms for
+   integrity checking using manual keys.
+
+   Implementations SHOULD use IKE [15] to permit more robust keying
+   options.  Implementations employing IKE SHOULD support authentication
+   with RSA signatures and RSA public key encryption.
+
+   A Security Association (SA) [12] is a simplex "connection" that
+   affords security services to the traffic carried by it.  Security
+   services are afforded to a SA by the use of AH, or ESP, but not both.
+   Two types of SAs are defined: transport mode and tunnel mode [12].  A
+   transport mode SA is a security association between two hosts, and is
+   appropriate for protecting the TRIP session between two peer LSs.
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 70]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+A1. Appendix 1: TRIP FSM State Transitions and Actions
+
+   This Appendix discusses the transitions between states in the TRIP
+   FSM in response to TRIP events.  The following is the list of these
+   states and events when the negotiated Hold Time value is non-zero.
+
+   TRIP States:
+      1 - Idle
+      2 - Connect
+      3 - Active
+      4 - OpenSent
+      5 - OpenConfirm
+      6 - Established
+
+   TRIP Events:
+      1 - TRIP Start
+      2 - TRIP Stop
+      3 - TRIP Transport connection open
+      4 - TRIP Transport connection closed
+      5 - TRIP Transport connection open failed
+      6 - TRIP Transport fatal error
+      7 - ConnectRetry timer expired
+      8 - Hold Timer expired
+      9 - KeepAlive timer expired
+      10 - Receive OPEN message
+      11 - Receive KEEPALIVE message
+      12 - Receive UPDATE messages
+      13 - Receive NOTIFICATION message
+
+   The following table describes the state transitions of the TRIP FSM
+   and the actions triggered by these transitions.
+
+   Event                Actions              Message Sent    Next State
+   --------------------------------------------------------------------
+   Idle (1)
+    1            Initialize resources            none             2
+                 Start ConnectRetry timer
+                 Initiate a transport connection
+    others               none                    none             1
+
+   Connect(2)
+    1                    none                    none             2
+    3            Complete initialization         OPEN             4
+                 Clear ConnectRetry timer
+    5            Restart ConnectRetry timer      none             3
+    7            Restart ConnectRetry timer      none             2
+                 Initiate a transport connection
+    others       Release resources               none             1
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 71]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+   Active (3)
+    1                    none                    none             3
+    3            Complete initialization         OPEN             4
+                 Clear ConnectRetry timer
+    5            Close connection                                 3
+                 Restart ConnectRetry timer
+    7            Restart ConnectRetry timer      none             2
+                 Initiate a transport connection
+    others       Release resources               none             1
+
+   OpenSent(4)
+    1                    none                    none             4
+    4            Close transport connection      none             3
+                 Restart ConnectRetry timer
+    6            Release resources               none             1
+   10            Process OPEN is OK            KEEPALIVE          5
+                 Process OPEN failed           NOTIFICATION       1
+   others        Close transport connection    NOTIFICATION       1
+                 Release resources
+
+   OpenConfirm (5)
+    1                   none                     none             5
+    4            Release resources               none             1
+    6            Release resources               none             1
+    9            Restart KeepAlive timer       KEEPALIVE          5
+   11            Complete initialization         none             6
+                 Restart Hold Timer
+   13            Close transport connection                       1
+                 Release resources
+   others        Close transport connection    NOTIFICATION       1
+                 Release resources
+
+   Established (6)
+    1                   none                     none             6
+    4            Release resources               none             1
+    6            Release resources               none             1
+    9            Restart KeepAlive timer       KEEPALIVE          6
+   11            Restart Hold Timer              none             6
+   12            Process UPDATE is OK          UPDATE             6
+                 Process UPDATE failed         NOTIFICATION       1
+   13            Close transport connection                       1
+                 Release resources
+   others        Close transport connection    NOTIFICATION       1
+                 Release resources
+   -----------------------------------------------------------------
+
+
+
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 72]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+   The following is a condensed version of the above state transition
+   table.
+
+   Events| Idle | Connect | Active | OpenSent | OpenConfirm | Estab
+         | (1)  |   (2)   |  (3)   |    (4)   |     (5)     |   (6)
+         |----------------------------------------------------------
+    1    |  2   |    2    |   3    |     4    |      5      |    6
+         |      |         |        |          |             |
+    2    |  1   |    1    |   1    |     1    |      1      |    1
+         |      |         |        |          |             |
+    3    |  1   |    4    |   4    |     1    |      1      |    1
+         |      |         |        |          |             |
+    4    |  1   |    1    |   1    |     3    |      1      |    1
+         |      |         |        |          |             |
+    5    |  1   |    3    |   3    |     1    |      1      |    1
+         |      |         |        |          |             |
+    6    |  1   |    1    |   1    |     1    |      1      |    1
+         |      |         |        |          |             |
+    7    |  1   |    2    |   2    |     1    |      1      |    1
+         |      |         |        |          |             |
+    8    |  1   |    1    |   1    |     1    |      1      |    1
+         |      |         |        |          |             |
+    9    |  1   |    1    |   1    |     1    |      5      |    6
+         |      |         |        |          |             |
+   10    |  1   |    1    |   1    |  1 or 5  |      1      |    1
+         |      |         |        |          |             |
+   11    |  1   |    1    |   1    |     1    |      6      |    6
+         |      |         |        |          |             |
+   12    |  1   |    1    |   1    |     1    |      1      | 1 or 6
+         |      |         |        |          |             |
+   13    |  1   |    1    |   1    |     1    |      1      |    1
+         |      |         |        |          |             |
+         --------------------------------------------------------------
+
+A2. Appendix 2: Implementation Recommendations
+
+   This section presents some implementation recommendations.
+
+A.2.1: Multiple Networks Per Message
+
+   The TRIP protocol allows for multiple address prefixes with the same
+   advertisement path and next-hop server to be specified in one
+   message.  Making use of this capability is highly recommended.  With
+   one address prefix per message there is a substantial increase in
+   overhead in the receiver.  Not only does the system overhead increase
+   due to the reception of multiple messages, but the overhead of
+   scanning the routing table for updates to TRIP peers is incurred
+   multiple times as well.  One method of building messages containing
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 73]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+   many address prefixes per advertisement path and next hop from a
+   routing table that is not organized per advertisement path is to
+   build many messages as the routing table is scanned.  As each address
+   prefix is processed, a message for the associated advertisement path
+   and next hop is allocated, if it does not exist, and the new address
+   prefix is added to it.  If such a message exists, the new address
+   prefix is just appended to it.  If the message lacks the space to
+   hold the new address prefix, it is transmitted, a new message is
+   allocated, and the new address prefix is inserted into the new
+   message.  When the entire routing table has been scanned, all
+   allocated messages are sent and their resources released.  Maximum
+   compression is achieved when all the destinations covered by the
+   address prefixes share the same next hop server and common
+   attributes, making it possible to send many address prefixes in one
+   4096-byte message.
+
+   When peering with a TRIP implementation that does not compress
+   multiple address prefixes into one message, it may be necessary to
+   take steps to reduce the overhead from the flood of data received
+   when a peer is acquired or a significant network topology change
+   occurs.  One method of doing this is to limit the rate of updates.
+   This will eliminate the redundant scanning of the routing table to
+   provide flash updates for TRIP peers.  A disadvantage of this
+   approach is that it increases the propagation latency of routing
+   information.  By choosing a minimum flash update interval that is not
+   much greater than the time it takes to process the multiple messages,
+   this latency should be minimized.  A better method would be to read
+   all received messages before sending updates.
+
+A.2.2: Processing Messages on a Stream Protocol
+
+   TRIP uses TCP as a transport mechanism.  Due to the stream nature of
+   TCP, all the data of a received message does not necessarily arrive
+   at the same time.  This can make it difficult to process the data as
+   messages, especially on systems where it is not possible to determine
+   how much data has been received but not yet processed.
+
+   One method that can be used in this situation is to first try to read
+   just the message header.  For the KEEPALIVE message type, this is a
+   complete message; for other message types, the header should first be
+   verified, in particular the total length.  If all checks are
+   successful, the specified length, minus the size of the message
+   header is the amount of data left to read.  An implementation that
+   would "hang" the routing information process while trying to read
+   from a peer could set up a message buffer (4096 bytes) per peer and
+   fill it with data as available until a complete message has been
+   received.
+
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 74]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+A.2.3: Reducing Route Flapping
+
+   To avoid excessive route flapping an LS which needs to withdraw a
+   destination and send an update about a more specific or less specific
+   route SHOULD combine them into the same UPDATE message.
+
+A.2.4: TRIP Timers
+
+   TRIP employs seven timers: ConnectRetry, Hold Time, KeepAlive,
+   MaxPurgeTime, TripDisableTime, MinITADOriginationInterval, and
+   MinRouteAdvertisementInterval.  The suggested value for the
+   ConnectRetry timer is 120 seconds.  The suggested value for the Hold
+   Time is 90 seconds.  The suggested value for the KeepAlive timer is
+   30 seconds.  The suggested value for the MaxPurgeTime timer is 10
+   seconds.  The suggested value for the TripDisableTime timer is 180
+   seconds.  The suggested value for the MinITADOriginationInterval is
+   30 seconds.  The suggested value for the
+   MinRouteAdvertisementInterval is 30 seconds.
+
+   An implementation of TRIP MUST allow these timers to be configurable.
+
+A.2.5: AP_SET Sorting
+
+   Another useful optimization that can be done to simplify this
+   situation is to sort the ITAD numbers found in an AP_SET.  This
+   optimization is entirely optional.
+
+Acknowledgments
+
+   We wish to thank Dave Oran for his insightful comments and
+   suggestions.
+
+References
+
+   [1]   Bradner, S., "Keywords for use in RFCs to Indicate Requirement
+         Levels", BCP 14, RFC 2119, March 1997.
+
+   [2]   Rosenberg, J. and H. Schulzrinne, "A Framework for a Gateway
+         Location Protocol", RFC 2871, June 2000.
+
+   [3]   Rekhter, Y. and T. Li, "Border Gateway Protocol 4 (BGP-4)," RFC
+         1771, March 1995.
+
+   [4]   Moy, J., "Open Shortest Path First Version 2", STD 54, RFC
+         2328, April 1998.
+
+
+
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 75]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+   [5]   "Intermediate System to Intermediate System Intra-Domain
+         Routing Exchange Protocol for use in Conjunction with the
+         Protocol for Providing the Connectionless-mode Network Service
+         (ISO 8473)," ISO DP 10589, February 1990.
+
+   [6]   Luciani, J., Armitage, G., Halpern, J. and N. Doraswamy,
+         "Server Cache Synchronization Protocol (SCSP)", RFC 2334, April
+         1998.
+
+   [7]   International Telecommunication Union, "Packet-Based Multimedia
+         Communication Systems," Recommendation H.323, Version 3
+         Telecommunication Standardization Sector of ITU, Geneva,
+         Switzerland, November 2000.
+
+   [8]   Handley, H., Schulzrinne, H., Schooler, E. and J. Rosenberg,
+         "SIP:  Session Initiation Protocol", RFC 2543, March 1999.
+
+   [9]   Braden, R., "Requirements for Internet Hosts -- Application and
+         Support", STD 3, RFC 1123, October 1989.
+
+   [10]  Hinden, R. and S. Deering, "IP Version 6 Addressing
+         Architecture", RFC 2373, July 1998.
+
+   [11]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
+         Considerations Section in RFCs", BCP 26, RFC 2434, October
+         1998.
+
+   [12]  Kent, S. and R. Atkinson, "Security Architecture for the
+         Internet Protocol", RFC 2401, November 1998.
+
+   [13]  Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
+         November 1998.
+
+   [14]  Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
+         (ESP)", RFC 2406, November 1998.
+
+   [15]  Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
+         RFC 2409, November 1998.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 76]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+Intellectual Property Notice
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; neither does it represent that it
+   has made any effort to identify any such rights.  Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP 11.  Copies of
+   claims of rights made available for publication and any assurances of
+   licenses to be made available, or the result of an attempt made to
+   obtain a general license or permission for the use of such
+   proprietary rights by implementers or users of this specification can
+   be obtained from the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard.  Please address the information to the IETF Executive
+   Director.
+
+   The IETF has been notified of intellectual property rights claimed in
+   regard to some or all of the specification contained in this
+   document.  For more information consult the online list of claimed
+   rights.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 77]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+Authors' Addresses
+
+   Jonathan Rosenberg
+   dynamicsoft
+   72 Eagle Rock Avenue
+   First Floor
+   East Hanover, NJ 07936
+
+   Phone: 973-952-5000
+   EMail: jdrosen@dynamicsoft.com
+
+
+   Hussein F. Salama
+   Cisco Systems
+   170 W. Tasman Drive
+   San Jose, CA 95134
+
+   Phone: 408-527-7147
+   EMail: hsalama@cisco.com
+
+
+   Matt Squire
+   Hatteras Networks
+   639 Davis Drive
+   Suite 200
+   Durham, NC 27713
+
+   EMail: mattsquire@acm.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 78]
+
+RFC 3219            Telephony Routing over IP (TRIP)        January 2002
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg, et. al.          Standards Track                    [Page 79]
+