6.7. Cease
In the absence of any fatal errors (that are indicated in this
section), a TRIP peer MAY choose at any given time to close its TRIP
connection by sending the NOTIFICATION message with the Error Code
"Cease." However, the Cease NOTIFICATION message MUST NOT be used
when a fatal error indicated by this section exists.
6.8. Connection Collision Detection
If a pair of LSs try simultaneously to establish a transport
connection to each other, then two parallel connections between this
pair of speakers might well be formed. We refer to this situation as
connection collision. Clearly, one of these connections must be
closed.
Based on the value of the TRIP Identifier, a convention is
established for detecting which TRIP connection is to be preserved
when a collision occurs. The convention is to compare the TRIP
Identifiers of the peers involved in the collision and to retain only
the connection initiated by the LS with the higher-valued TRIP
Identifier.
Upon receipt of an OPEN message, the local LS MUST examine all of its
connections that are in the OpenConfirm state. An LS MAY also
examine connections in an OpenSent state if it knows the TRIP
Identifier of the peer by means outside of the protocol. If among
these connections there is a connection to a remote LS, whose TRIP
Identifier equals the one in the OPEN message, then the local LS MUST
perform the following collision resolution procedure:
The TRIP Identifier and ITAD of the local LS is compared to the TRIP
Identifier and ITAD of the remote LS (as specified in the OPEN
message). TRIP Identifiers are treated as 4-octet unsigned integers
for comparison.
If the value of the local TRIP Identifier is less than the remote
one, or if the two TRIP Identifiers are equal and the value of the
ITAD of the local LS is less than value of the ITAD of the remote LS,
then the local LS MUST close the TRIP connection that already exists
(the one that is already in the OpenConfirm state), and accept the
TRIP connection initiated by the remote LS:
1. Otherwise, the local LS closes the newly created TRIP
connection and continues to use the existing one (the one that
is already in the OpenConfirm state).
2. If a connection collision occurs with an existing TRIP
connection that is in the Established state, then the LS MUST
unconditionally close off the newly created connection. Note
that a connection collision cannot be detected with connections
in Idle, Connect, or Active states.
3. To close the TRIP connection (that results from the collision
resolution procedure), an LS MUST send a NOTIFICATION message
with the Error Code "Cease" and the TRIP connection MUST be
closed.
7. TRIP Version Negotiation
Peer LSs may negotiate the version of the protocol by making multiple
attempts to open a TRIP connection, starting with the highest version
number each supports. If an open attempt fails with an Error Code
"OPEN Message Error" and an Error Subcode "Unsupported Version
Number," then the LS has available the version number it tried, the
version number its peer tried, the version number passed by its peer
in the NOTIFICATION message, and the version numbers that it
supports. If the two peers support one or more common versions, then
this will allow them to rapidly determine the highest common version.
In order to support TRIP version negotiation, future versions of TRIP
must retain the format of the OPEN and NOTIFICATION messages.
8. TRIP Capability Negotiation
An LS MAY include the Capabilities Option in its OPEN message to a
peer to indicate the capabilities supported by the LS. An LS
receiving an OPEN message MUST NOT use any capabilities that were not
included in the OPEN message of the peer when communicating with that
peer.
9. TRIP Finite State Machine
This section specifies TRIP operation in terms of a Finite State
Machine (FSM). Following is a brief summary and overview of TRIP
operations by state as determined by this FSM. A condensed version
of the TRIP FSM is found in Appendix 1. There is one TRIP FSM per
peer and these FSMs operate independently.
Idle state:
Initially TRIP is in the Idle state for each peer. In this state,
TRIP refuses all incoming connections. No resources are allocated to
the peer. In response to the Start event (initiated by either the
system or the operator), the local system initializes all TRIP
resources, starts the ConnectRetry timer, initiates a transport
connection to the peer, starts listening for a connection that may be
initiated by the remote TRIP peer, and changes its state to Connect.
The exact value of the ConnectRetry timer is a local matter, but
should be sufficiently large to allow TCP initialization.
If an LS detects an error, it closes the transport connection and
changes its state to Idle. Transitioning from the Idle state
requires generation of the Start event. If such an event is
generated automatically, then persistent TRIP errors may result in
persistent flapping of the LS. To avoid such a condition, Start
events MUST NOT be generated immediately for a peer that was
previously transitioned to Idle due to an error. For a peer that was
previously transitioned to Idle due to an error, the time between
consecutive Start events, if such events are generated automatically,
MUST exponentially increase. The value of the initial timer SHOULD
be 60 seconds, and the time SHOULD be at least doubled for each
consecutive retry up to some maximum value.
Any other event received in the Idle state is ignored.
Connect State:
In this state, an LS is waiting for a transport protocol connection
to be completed to the peer, and is listening for inbound transport
connections from the peer.
If the transport protocol connection succeeds, the local LS clears
the ConnectRetry timer, completes initialization, sends an OPEN
message to its peer, sets its Hold Timer to a large value, and
changes its state to OpenSent. A Hold Timer value of 4 minutes is
suggested.
If the transport protocol connect fails (e.g., retransmission
timeout), the local system restarts the ConnectRetry timer, continues
to listen for a connection that may be initiated by the remote LS,
and changes its state to Active state.
In response to the ConnectRetry timer expired event, the local LS
cancels any outstanding transport connection to the peer, restarts
the ConnectRetry timer, initiates a transport connection to the
remote LS, continues to listen for a connection that may be initiated
by the remote LS, and stays in the Connect state.
If the local LS detects that a remote peer is trying to establish a
connection to it and the IP address of the peer is not an expected
one, then the local LS rejects the attempted connection and continues
to listen for a connection from its expected peers without changing
state.
If an inbound transport protocol connection succeeds, the local LS
clears the ConnectRetry timer, completes initialization, sends an
OPEN message to its peer, sets its Hold Timer to a large value, and
changes its state to OpenSent. A Hold Timer value of 4 minutes is
suggested.
The Start event is ignored in the Connect state.
In response to any other event (initiated by either the system or the
operator), the local system releases all TRIP resources associated
with this connection and changes its state to Idle.
Active state:
In this state, an LS is listening for an inbound connection from the
peer, but is not in the process of initiating a connection to the
peer.
If an inbound transport protocol connection succeeds, the local LS
clears the ConnectRetry timer, completes initialization, sends an
OPEN message to its peer, sets its Hold Timer to a large value, and
changes its state to OpenSent. A Hold Timer value of 4 minutes is
suggested.
In response to the ConnectRetry timer expired event, the local system
restarts the ConnectRetry timer, initiates a transport connection to
the TRIP peer, continues to listen for a connection that may be
initiated by the remote TRIP peer, and changes its state to Connect.
If the local LS detects that a remote peer is trying to establish a
connection to it and the IP address of the peer is not an expected
one, then the local LS rejects the attempted connection and continues
to listen for a connection from its expected peers without changing
state.
Start event is ignored in the Active state.
In response to any other event (initiated by either the system or the
operator), the local system releases all TRIP resources associated
with this connection and changes its state to Idle.
OpenSent state:
In this state, an LS has sent an OPEN message to its peer and is
waiting for an OPEN message from its peer. When an OPEN message is
received, all fields are checked for correctness. If the TRIP
message header checking or OPEN message checking detects an error
(see Section 6.2) or a connection collision (see Section 6.8), the
local system sends a NOTIFICATION message and changes its state to
Idle.
If there are no errors in the OPEN message, TRIP sends a KEEPALIVE
message and sets a KeepAlive timer. The Hold Timer, which was
originally set to a large value (see above), is replaced with the
negotiated Hold Time value (see Section 4.2). If the negotiated Hold
Time value is zero, then the Hold Time timer and KeepAlive timers are
not started. If the value of the ITAD field is the same as the local
ITAD number, then the connection is an "internal" connection;
otherwise, it is "external" (this will affect UPDATE processing).
Finally, the state is changed to OpenConfirm.
If the local LS detects that a remote peer is trying to establish a
connection to it and the IP address of the peer is not an expected
one, then the local LS rejects the attempted connection and continues
to listen for a connection from its expected peers without changing
state.
If a disconnect notification is received from the underlying
transport protocol, the local LS closes the transport connection,
restarts the ConnectRetry timer, continues to listen for a connection
that may be initiated by the remote TRIP peer, and goes into the
Active state.
If the Hold Timer expires, the local LS sends a NOTIFICATION message
with the Error Code "Hold Timer Expired" and changes its state to
Idle.
In response to the Stop event (initiated by either system or
operator) the local LS sends a NOTIFICATION message with the Error
Code "Cease" and changes its state to Idle.
The Start event is ignored in the OpenSent state.
In response to any other event the local LS sends a NOTIFICATION
message with the Error Code "Finite State Machine Error" and changes
its state to Idle.
Whenever TRIP changes its state from OpenSent to Idle, it closes the
transport connection and releases all resources associated with that
connection.
OpenConfirm state:
In this state, an LS has sent an OPEN to its peer, received an OPEN
from its peer, and sent a KEEPALIVE in response to the OPEN. The LS
is now waiting for a KEEPALIVE or NOTIFICATION message in response to
its OPEN.
If the local LS receives a KEEPALIVE message, it changes its state to
Established.
If the Hold Timer expires before a KEEPALIVE message is received, the
local LS sends NOTIFICATION message with the Error Code "Hold Timer
Expired" and changes its state to Idle.
If the local LS receives a NOTIFICATION message, it changes its state
to Idle.
If the KeepAlive timer expires, the local LS sends a KEEPALIVE
message and restarts its KeepAlive timer.
If a disconnect notification is received from the underlying
transport protocol, the local LS closes the transport connection,
restarts the ConnectRetry timer, continues to listen for a connection
that may be initiated by the remote TRIP peer, and goes into the
Active state.
In response to the Stop event (initiated by either the system or the
operator) the local LS sends NOTIFICATION message with the Error Code
"Cease" and changes its state to Idle.
The Start event is ignored in the OpenConfirm state.
In response to any other event the local LS sends a NOTIFICATION
message with the Error Code "Finite State Machine Error" and changes
its state to Idle.
Whenever TRIP changes its state from OpenConfirm to Idle, it closes
the transport connection and releases all resources associated with
that connection.
Established state:
In the Established state, an LS can exchange UPDATE, NOTIFICATION,
and KEEPALIVE messages with its peer.
If the negotiated Hold Timer is zero, then no procedures are
necessary for keeping a peering session alive. If the negotiated
Hold Time value is non-zero, the procedures of this paragraph apply.
If the Hold Timer expires, the local LS sends a NOTIFICATION message
with the Error Code "Hold Timer Expired" and changes its state to
Idle. If the KeepAlive Timer expires, then the local LS sends a
KeepAlive message and restarts the KeepAlive Timer. If the local LS
receives an UPDATE or KEEPALIVE message, then it restarts its Hold
Timer. Each time the LS sends an UPDATE or KEEPALIVE message, it
restarts its KeepAlive Timer.
If the local LS receives a NOTIFICATION message, it changes its state
to Idle.
If the local LS receives an UPDATE message and the UPDATE message
error handling procedure (see Section6.3) detects an error, the local
LS sends a NOTIFICATION message and changes its state to Idle.
If a disconnect notification is received from the underlying
transport protocol, the local LS changes its state to Idle.
In response to the Stop event (initiated by either the system or the
operator), the local LS sends a NOTIFICATION message with the Error
Code "Cease" and changes its state to Idle.
The Start event is ignored in the Established state.
In response to any other event, the local LS sends a NOTIFICATION
message with Error Code "Finite State Machine Error" and changes its
state to Idle.
Whenever TRIP changes its state from Established to Idle, it closes
the transport connection and releases all resources associated with
that connection. Additionally, if the peer is an external peer, the
LS deletes all routes derived from that connection.
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.
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.
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.
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.
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.
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
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.
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.
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
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
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.
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.
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.
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
IANA, and are allocated subject to the Specification Required (IETF
RFCor 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 (RFCor 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.
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