rfc3219.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,493 行 · 第 1/5 页

   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.