tech-invite   World Map
3GPP     Specs     Glossaries     UICC       IETF     RFCs     Groups     SIP     ABNFs       T+       Search     Home

RFC 3219

 
 
 

Telephony Routing over IP (TRIP)

Part 3 of 3, p. 55 to 79
Prev RFC Part

 


prevText      Top      Up      ToC       Page 55 
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.

Top      Up      ToC       Page 56 
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.

Top      Up      ToC       Page 57 
   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.

Top      Up      ToC       Page 58 
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.

Top      Up      ToC       Page 59 
   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.

Top      Up      ToC       Page 60 
   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

Top      Up      ToC       Page 61 
   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.

Top      Up      ToC       Page 62 
   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.

Top      Up      ToC       Page 63 
   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

Top      Up      ToC       Page 64 
   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

Top      Up      ToC       Page 65 
   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.

Top      Up      ToC       Page 66 
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.

Top      Up      ToC       Page 67 
   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.

Top      Up      ToC       Page 68 
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

Top      Up      ToC       Page 69 
   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.

Top      Up      ToC       Page 70 
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.

Top      Up      ToC       Page 71 
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

Top      Up      ToC       Page 72 
   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
   -----------------------------------------------------------------

Top      Up      ToC       Page 73 
   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

Top      Up      ToC       Page 74 
   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.

Top      Up      ToC       Page 75 
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.

Top      Up      ToC       Page 76 
   [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.

Top      Up      ToC       Page 77 
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.

Top      Up      ToC       Page 78 
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

Top      Up      ToC       Page 79 
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.