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
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.
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  and SCSP . 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).
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.
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
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
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.
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
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.
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
- 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
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
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
Withdrawn routes MUST be removed from the Loc-TRIB, Ext-TRIB, and the
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
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
- 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
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
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
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.
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
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.
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
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
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
destination, all of which were advertised by external peers. The
local LS shall select one of these routes according to the following
- 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
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
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
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
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
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
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
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.
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
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
- 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
- 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-
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:
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
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
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
184.108.40.206 must be submitted to firstname.lastname@example.org. Following the assigned
number policies outlined in , 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
220.127.116.11. Capability Codes in the range 2-32767 are controlled by
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
email@example.com. 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 18.104.22.168 ( address
families 1, 2, and 3), i.e., in the range 4-32767, must be submitted
to firstname.lastname@example.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 22.214.171.124 (application protocols 1 through 4), i.e., in the
range 5-32767, must be submitted to email@example.com. 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-
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 firstname.lastname@example.org.
The requests MUST include the following:
- Information about the organization that will administer the
- 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 . IPsec
uses two protocols to provide traffic security: Authentication Header
(AH)  and Encapsulating Security Payload (ESP) .
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
Implementations of the protocol defined in this document employing
the ESP header SHALL comply with section 5 of , which defines a
minimum set of algorithms for integrity checking and encryption.
Similarly, implementations employing the AH header SHALL comply with
section 5 of , which defines a minimum set of algorithms for
integrity checking using manual keys.
Implementations SHOULD use IKE  to permit more robust keying
options. Implementations employing IKE SHOULD support authentication
with RSA signatures and RSA public key encryption.
A Security Association (SA)  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 . A
transport mode SA is a security association between two hosts, and is
appropriate for protecting the TRIP session between two peer LSs.
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.
1 - Idle
2 - Connect
3 - Active
4 - OpenSent
5 - OpenConfirm
6 - Established
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
1 Initialize resources none 2
Start ConnectRetry timer
Initiate a transport connection
others none none 1
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
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
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
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.
We wish to thank Dave Oran for his insightful comments and
 Bradner, S., "Keywords for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
 Rosenberg, J. and H. Schulzrinne, "A Framework for a Gateway
Location Protocol", RFC 2871, June 2000.
 Rekhter, Y. and T. Li, "Border Gateway Protocol 4 (BGP-4)," RFC
1771, March 1995.
 Moy, J., "Open Shortest Path First Version 2", STD 54, RFC
2328, April 1998.
 "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.
 Luciani, J., Armitage, G., Halpern, J. and N. Doraswamy,
"Server Cache Synchronization Protocol (SCSP)", RFC 2334, April
 International Telecommunication Union, "Packet-Based Multimedia
Communication Systems," Recommendation H.323, Version 3
Telecommunication Standardization Sector of ITU, Geneva,
Switzerland, November 2000.
 Handley, H., Schulzrinne, H., Schooler, E. and J. Rosenberg,
"SIP: Session Initiation Protocol", RFC 2543, March 1999.
 Braden, R., "Requirements for Internet Hosts -- Application and
Support", STD 3, RFC 1123, October 1989.
 Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
 Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October
 Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
 Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
 Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998.
 Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
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
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
72 Eagle Rock Avenue
East Hanover, NJ 07936
Hussein F. Salama
170 W. Tasman Drive
San Jose, CA 95134
639 Davis Drive
Durham, NC 27713
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
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.
Funding for the RFC Editor function is currently provided by the