RFC 3219
Telephony Routing over IP (TRIP)
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 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.
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.
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
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
-----------------------------------------------------------------
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
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.
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.
[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.
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.
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
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.