Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3219

Telephony Routing over IP (TRIP)

Pages: 79
Proposed Standard
Errata
Updated by:  8602
Part 3 of 3 – Pages 55 to 79
First   Prev   None

Top   ToC   RFC3219 - Page 55   prevText

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