RFC 3219
Telephony Routing over IP (TRIP)
Network Working Group J. Rosenberg Request for Comments: 3219 dynamicsoft Category: Standards Track H. Salama Cisco Systems M. Squire Hatteras Networks January 2002 Telephony Routing over IP (TRIP) Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved.Abstract
This document presents the Telephony Routing over IP (TRIP). TRIP is a policy driven inter-administrative domain protocol for advertising the reachability of telephony destinations between location servers, and for advertising attributes of the routes to those destinations. TRIP's operation is independent of any signaling protocol, hence TRIP can serve as the telephony routing protocol for any signaling protocol. The Border Gateway Protocol (BGP-4) is used to distribute routing information between administrative domains. TRIP is used to distribute telephony routing information between telephony administrative domains. The similarity between the two protocols is obvious, and hence TRIP is modeled after BGP-4.Table of Contents
1 Terminology and Definitions .............................. 3 2 Introduction ............................................. 4 3 Summary of Operation ..................................... 5 3.1 Peering Session Establishment and Maintenance ............ 5 3.2 Database Exchanges ....................................... 6 3.3 Internal Versus External Synchronization ................. 6 3.4 Advertising TRIP Routes .................................. 6
3.5 Telephony Routing Information Bases ...................... 7 3.6 Routes in TRIP ........................................... 9 3.7 Aggregation .............................................. 9 4 Message Formats .......................................... 10 4.1 Message Header Format .................................... 10 4.2 OPEN Message Format ...................................... 11 4.3 UPDATE Message Format .................................... 15 4.4 KEEPALIVE Message Format ................................ 22 4.5 NOTIFICATION Message Format ............................. 23 5 TRIP Attributes ......................................... 24 5.1 WithdrawnRoutes .......................................... 24 5.2 ReachableRoutes .......................................... 28 5.3 NextHopServer ........................................... 29 5.4 AdvertisementPath ....................................... 31 5.5 RoutedPath ............................................... 35 5.6 AtomicAggregate ......................................... 36 5.7 LocalPreference ......................................... 37 5.8 MultiExitDisc ............................................ 38 5.9 Communities .............................................. 39 5.10 ITAD Topology .......................................... 41 5.11 ConvertedRoute ........................................... 43 5.12 Considerations for Defining New TRIP Attributes ......... 44 6 TRIP Error Detection and Handling ....................... 44 6.1 Message Header Error Detection and Handling ............. 45 6.2 OPEN Message Error Detection and Handling ............... 45 6.3 UPDATE Message Error Detection and Handling ............. 46 6.4 NOTIFICATION Message Error Detection and Handling ....... 48 6.5 Hold Timer Expired Error Handling ....................... 48 6.6 Finite State Machine Error Handling ..................... 48 6.7 Cease ................................................... 48 6.8 Connection Collision Detection .......................... 48 7 TRIP Version Negotiation ................................ 49 8 TRIP Capability Negotiation ............................. 50 9 TRIP Finite State Machine ............................... 50 10 UPDATE Message Handling ................................. 55 10.1 Flooding Process ........................................ 56 10.2 Decision Process ........................................ 58 10.3 Update-Send Process ..................................... 62 10.4 Route Selection Criteria ................................ 67 10.5 Originating TRIP Routes ................................. 67 11 TRIP Transport .......................................... 68 12 ITAD Topology ........................................... 68 13 IANA Considerations ...................................... 68 13.1 TRIP Capabilities ....................................... 68 13.2 TRIP Attributes ........................................ 69 13.3 Destination Address Families ............................ 69 13.4 TRIP Application Protocols .............................. 69 13.5 ITAD Numbers ............................................ 70
14 Security Considerations ................................. 70 A1. Appendix 1: TRIP FSM State Transitions and Actions ...... 71 A2. Appendix 2: Implementation Recommendations .............. 73 Acknowledgments ................................................ 75 References ..................................................... 75 Intellectual Property Notice ................................... 77 Authors' Addresses ............................................. 78 Full Copyright Statement ....................................... 791. Terminology and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. A framework for Telephony Routing over IP (TRIP) is described in [2]. We assume the reader is familiar with the framework and terminology of [2]. We define and use the following terms in addition to those defined in [2]. Telephony Routing Information Base (TRIB): The database of reachable telephony destinations built and maintained at an LS as a result of its participation in TRIP. IP Telephony Administrative Domain (ITAD): The set of resources (gateways, location servers, etc.) under the control of a single administrative authority. End users are customers of an ITAD. Less/More Specific Route: A route X is said to be less specific than a route Y if every destination in Y is also a destination in X, and X and Y are not equal. In this case, Y is also said to be more specific than X. Aggregation: Aggregation is the process by which multiple routes are combined into a single less specific route that covers the same set of destinations. Aggregation is used to reduce the size of the TRIB being synchronized with peer LSs by reducing the number of exported TRIP routes. Peers: Two LSs that share a logical association (a transport connection). If the LSs are in the same ITAD, they are internal peers. Otherwise, they are external peers. The logical association between two peer LSs is called a peering session.
Telephony Routing Information Protocol (TRIP): The protocol defined in this specification. The function of TRIP is to advertise the reachability of telephony destinations, attributes associated with the destinations, as well as the attributes of the path towards those destinations. TRIP destination: TRIP can be used to manage routing tables for multiple protocols (SIP, H323, etc.). In TRIP, a destination is the combination of (a) a set of addresses (given by an address family and address prefix), and (b) an application protocol (SIP, H323, etc).2. Introduction
The gateway location and routing problem has been introduced in [2]. It is considered one of the more difficult problems in IP telephony. The selection of an egress gateway for a telephony call, traversing an IP network towards an ultimate destination in the PSTN, is driven in large part by the policies of the various parties along the path, and by the relationships established between these parties. As such, a global directory of egress gateways in which users look up destination phone numbers is not a feasible solution. Rather, information about the availability of egress gateways is exchanged between providers, and subject to policy, made available locally and then propagated to other providers in other ITADs, thus creating routes towards these egress gateways. This would allow each provider to create its own database of reachable phone numbers and the associated routes - such a database could be very different for each provider depending on policy. TRIP is an inter-domain (i.e., inter-ITAD) gateway location and routing protocol. The primary function of a TRIP speaker, called a location server (LS), is to exchange information with other LSs. This information includes the reachability of telephony destinations, the routes towards these destinations, and information about gateways towards those telephony destinations residing in the PSTN. The TRIP requirements are set forth in [2]. LSs exchange sufficient routing information to construct a graph of ITAD connectivity so that routing loops may be prevented. In addition, TRIP can be used to exchange attributes necessary to enforce policies and to select routes based on path or gateway characteristics. This specification defines TRIP's transport and synchronization mechanisms, its finite state machine, and the TRIP data. This specification defines the basic attributes of TRIP. The TRIP attribute set is extendible, so additional attributes may be defined in future documents.
TRIP is modeled after the Border Gateway Protocol 4 (BGP-4) [3] and enhanced with some link state features, as in the Open Shortest Path First (OSPF) protocol [4], IS-IS [5], and the Server Cache Synchronization Protocol (SCSP) [6]. TRIP uses BGP's inter-domain transport mechanism, BGP's peer communication, BGP's finite state machine, and similar formats and attributes as BGP. Unlike BGP however, TRIP permits generic intra-domain LS topologies, which simplifies configuration and increases scalability in contrast to BGP's full mesh requirement of internal BGP speakers. TRIP uses an intra-domain flooding mechanism similar to that used in OSPF [4], IS-IS [5], and SCSP [6]. TRIP permits aggregation of routes as they are advertised through the network. TRIP does not define a specific route selection algorithm. TRIP runs over a reliable transport protocol. This eliminates the need to implement explicit fragmentation, retransmission, acknowledgment, and sequencing. The error notification mechanism used in TRIP assumes that the transport protocol supports a graceful close, i.e., that all outstanding data will be delivered before the connection is closed. TRIP's operation is independent of any particular telephony signaling protocol. Therefore, TRIP can be used as the routing protocol for any of these protocols, e.g., H.323 [7] and SIP [8]. The LS peering topology is independent of the physical topology of the network. In addition, the boundaries of an ITAD are independent of the boundaries of the layer 3 routing autonomous systems. Neither internal nor external TRIP peers need to be physically adjacent.3. Summary of Operation
This section summarizes the operation of TRIP. Details are provided in later sections.3.1. Peering Session Establishment and Maintenance
Two peer LSs form a transport protocol connection between one another. They exchange messages to open and confirm the connection parameters, and to negotiate the capabilities of each LS as well as the type of information to be advertised over this connection. KeepAlive messages are sent periodically to ensure adjacent peers are operational. Notification messages are sent in response to errors or special conditions. If a connection encounters an error condition, a Notification message is sent and the connection is closed.
3.2. Database Exchanges
Once the peer connection has been established, the initial data flow is a dump of all routes relevant to the new peer (In the case of an external peer, all routes in the LS's Adj-TRIB-Out for that external peer. In the case of an internal peer, all routes in the Ext-TRIB and all Adj-TRIBs-In). Note that the different TRIBs are defined in Section 3.5. Incremental updates are sent as the TRIP routing tables (TRIBs) change. TRIP does not require periodic refresh of the routes. Therefore, an LS must retain the current version of all routing entries. If a particular ITAD has multiple LSs and is providing transit service for other ITADs, then care must be taken to ensure a consistent view of routing within the ITAD. When synchronized the TRIP routing tables, i.e., the Loc-TRIBs, of all internal peers are identical.3.3. Internal Versus External Synchronization
As with BGP, TRIP distinguishes between internal and external peers. Within an ITAD, internal TRIP uses link-state mechanisms to flood database updates over an arbitrary topology. Externally, TRIP uses point-to-point peering relationships to exchange database information. To achieve internal synchronization, internal peer connections are configured between LSs of the same ITAD such that the resulting intra-domain LS topology is connected and sufficiently redundant. This is different from BGP's approach that requires all internal peers to be connected in a full mesh topology, which may result in scaling problems. When an update is received from an internal peer, the routes in the update are checked to determine if they are newer than the version already in the database. Newer routes are then flooded to all other peers in the same domain.3.4. Advertising TRIP Routes
In TRIP, a route is defined as the combination of (a) a set of destination addresses (given by an address family indicator and an address prefix), and (b) an application protocol (e.g. SIP, H323, etc.). Generally, there are additional attributes associated with each route (for example, the next-hop server).
TRIP routes are advertised between a pair of LSs in UPDATE messages.
The destination addresses are included in the ReachableRoutes
attribute of the UPDATE, while other attributes describe things like
the path or egress gateway.
If an LS chooses to advertise a TRIP route, it may add to or modify
the attributes of the route before advertising it to a peer. TRIP
provides mechanisms by which an LS can inform its peer that a
previously advertised route is no longer available for use. There
are three methods by which a given LS can indicate that a route has
been withdrawn from service:
- Include the route in the WithdrawnRoutes Attribute in an UPDATE
message, thus marking the associated destinations as being no
longer available for use.
- Advertise a replacement route with the same set of destinations
in the ReachableRoutes Attribute.
- For external peers where flooding is not in use, the LS-to-LS
peer connection can be closed, which implicitly removes from
service all routes which the pair of LSs had advertised to each
other over that peer session. Note that terminating an
internal peering session does not necessarily remove the routes
advertised by the peer LS as the same routes may have been
received from multiple internal peers because of flooding. If
an LS determines that another internal LS is no longer active
(from the ITAD Topology attributes of the UPDATE messages from
other internal peers), then it MUST remove all routes
originated into the LS by that LS and rerun its decision
process.
3.5. Telephony Routing Information Bases
A TRIP LS processes three types of routes:
- External routes: An external route is a route received from an
external peer LS
- Internal routes: An internal route is a route received from an
internal LS in the same ITAD.
- Local routes: A local route is a route locally injected into
TRIP, e.g. by configuration or by route redistribution from
another routing protocol.
The Telephony Routing Information Base (TRIB) within an LS consists
of four distinct parts:
- Adj-TRIBs-In: The Adj-TRIBs-In store routing information that
has been learned from inbound UPDATE messages. Their contents
represent TRIP routes that are available as an input to the
Decision Process. These are the "unprocessed" routes received.
The routes from each external peer LS and each internal LS are
maintained in this database independently, so that updates from
one peer do not affect the routes received from another LS.
Note that there is an Adj-TRIB-In for every LS within the
domain, even those with which the LS is not directly peered.
- Ext-TRIB: There is only one Ext-TRIB database per LS. The LS
runs the route selection algorithm on all external routes
(stored in the Adj-TRIBs-In of the external peers) and local
routes (may be stored in an Adj-TRIB-In representing the local
LS) and selects the best route for a given destination and
stores it in the Ext-TRIB. The use of Ext-TRIB will be
explained further in Section 10.3.1
- Loc-TRIB: The Loc-TRIB contains the local TRIP routing
information that the LS has selected by applying its local
policies to the routing information contained in its Adj-
TRIBs-In of internal LSs and the Ext-TRIB.
- Adj-TRIBs-Out: The Adj-TRIBs-Out store the information that
the local LS has selected for advertisement to its external
peers. The routing information stored in the Adj-TRIBs-Out
will be carried in the local LS's UPDATE messages and
advertised to its peers.
Figure 1 illustrates the relationship between the four parts of the
routing information base.
Loc-TRIB
^
|
Decision Process
^ ^ |
| | |
Adj-TRIBs-In | V
(Internal LSs) | Adj-TRIBs-Out
|
|
|
Ext-TRIB
^ ^
| |
Adj-TRIB-In Local Routes
(External Peers)
Figure 1: TRIB Relationships
Although the conceptual model distinguishes between Adj-TRIBs-In, Ext-TRIB, Loc-TRIB, and Adj-TRIBs-Out, this neither implies nor requires that an implementation must maintain four separate copies of the routing information. The choice of implementation (for example, 4 copies of the information vs. 1 copy with pointers) is not constrained by the protocol.3.6. Routes in TRIP
A route in TRIP specifies a range of numbers by being a prefix of those numbers (the exact definition & syntax of route are in 5.1.1). Arbitrary ranges of numbers are not atomically representable by a route in TRIP. A prefix range is the only type of range supported atomically. An arbitrary range can be accomplished by using multiple prefixes in a ReachableRoutes attribute (see Section 5.1 & 5.2). For example, 222-xxxx thru 999-xxxx could be represented by including the prefixes 222, 223, 224,...,23,24,...,3,4,...,9 in a ReachableRoutes attribute.3.7. Aggregation
Aggregation is a scaling enhancement used by an LS to reduce the number of routing entries that it has to synchronize with its peers. Aggregation may be performed by an LS when there is a set of routes {R1, R2, ...} in its TRIB such that there exists a less specific route R where every valid destination in R is also a valid destination in {R1, R2, ...} and vice-versa. Section 5 includes a description of how to combine each attribute (by type) on the {R1, R2, ...} routes into an attribute for R. Note that there is no mechanism within TRIP to communicate that a particular address prefix is not used or valid within a particular address family, and thus that these addresses could be skipped during aggregation. LSs may use methods outside of TRIP to learn of invalid prefixes that may be ignored during aggregation. An LS is not required to perform aggregation, however it is recommended whenever maintaining a smaller TRIB is important. An LS decides based on its local policy whether or not to aggregate a set of routes into a single aggregate route. Whenever an LS aggregates multiple routes where the NextHopServer is not identical in all aggregated routes, the NextHopServer attribute of the aggregate route must be set to a signalling server in the aggregating LS's domain.
When an LS resets the NextHopServer of any route, and this may be performed because of aggregation or other reasons, it has the effect of adding another signalling server along the signalling path to these destinations. The end result is that the signalling path between two destinations may consist of multiple signalling servers across multiple domains.4. Message Formats
This section describes message formats used by TRIP. Messages are sent over a reliable transport protocol connection. A message MUST be processed only after it is entirely received. The maximum message size is 4096 octets. All implementations MUST support this maximum message size. The smallest message that MAY be sent consists of a TRIP header without a data portion, or 3 octets.4.1. Message Header Format
Each message has a fixed-size header. There may or may not be a data portion following the header, depending on the message type. The layout of the header fields is shown in Figure 2. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +--------------+----------------+---------------+ | Length | Type | +--------------+----------------+---------------+ Figure 2: TRIP Header Length: This 2-octet unsigned integer indicates the total length of the message, including the header, in octets. Thus, it allows one to locate, in the transport-level stream, the beginning of the next message. The value of the Length field must always be at least 3 and no greater than 4096, and may be further constrained depending on the message type. No padding of extra data after the message is allowed, so the Length field must have the smallest value possible given the rest of the message. Type: This 1-octet unsigned integer indicates the type code of the message. The following type codes are defined: 1 - OPEN 2 - UPDATE 3 - NOTIFICATION 4 - KEEPALIVE
4.2. OPEN Message Format
After a transport protocol connection is established, the first message sent by each side is an OPEN message. If the OPEN message is acceptable, a KEEPALIVE message confirming the OPEN is sent back. Once the OPEN is confirmed, UPDATE, KEEPALIVE, and NOTIFICATION messages may be exchanged. The minimum length of the OPEN message is 17 octets (including message header). OPEN messages not meeting this minimum requirement are handled as defined in Section 6.2. In addition to the fixed-size TRIP header, the OPEN message contains the following fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+--------------+----------------+ | Version | Reserved | Hold Time | +---------------+---------------+--------------+----------------+ | My ITAD | +---------------+---------------+--------------+----------------+ | TRIP Identifier | +---------------+---------------+--------------+----------------+ | Optional Parameters Len |Optional Parameters (variable)... +---------------+---------------+--------------+----------------+ Figure 3: TRIP OPEN Header Version: This 1-octet unsigned integer indicates the protocol version of the message. The current TRIP version number is 1. Hold Time: This 2-octet unsigned integer indicates the number of seconds that the sender proposes for the value of the Hold Timer. Upon receipt of an OPEN message, an LS MUST calculate the value of the Hold Timer by using the smaller of its configured Hold Time and the Hold Time received in the OPEN message. The Hold Time MUST be either zero or at least three seconds. An implementation MAY reject connections on the basis of the Hold Time. The calculated value indicates the maximum number of seconds that may elapse between the receipt of successive KEEPALIVE and/or UPDATE messages by the sender. This 4-octet unsigned integer indicates the ITAD number of the sender. The ITAD number must be unique for this domain within this confederation of cooperating LSs.
ITAD numbers are assigned by IANA as specified in Section 13. This document reserves ITAD number 0. ITAD numbers from 1 to 255 are designated for private use. TRIP Identifier: This 4-octet unsigned integer indicates the TRIP Identifier of the sender. The TRIP Identifier MUST uniquely identify this LS within its ITAD. A given LS MAY set the value of its TRIP Identifier to an IPv4 address assigned to that LS. The value of the TRIP Identifier is determined on startup and MUST be the same for all peer connections. When comparing two TRIP identifiers, the TRIP Identifier is interpreted as a numerical 4-octet unsigned integer. Optional Parameters Length: This 2-octet unsigned integer indicates the total length of the Optional Parameters field in octets. If the value of this field is zero, no Optional Parameters are present. Optional Parameters: This field may contain a list of optional parameters, where each parameter is encoded as a <Parameter Type, Parameter Length, Parameter Value> triplet. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+--------------+----------------+ | Parameter Type | Parameter Length | +---------------+---------------+--------------+----------------+ | Parameter Value (variable)... +---------------+---------------+--------------+----------------+ Figure 4: Optional Parameter Encoding Parameter Type: This is a 2-octet field that unambiguously identifies individual parameters. Parameter Length: This is a 2-octet field that contains the length of the Parameter Value field in octets. Parameter Value: This is a variable length field that is interpreted according to the value of the Parameter Type field.
4.2.1. Open Message Optional Parameters
This document defines the following Optional Parameters for the OPEN message.4.2.1.1. Capability Information
Capability Information uses Optional Parameter type 1. This is an optional parameter used by an LS to convey to its peer the list of capabilities supported by the LS. This permits an LS to learn of the capabilities of its peer LSs. Capability negotiation is defined in Section 8. The parameter contains one or more triples <Capability Code, Capability Length, Capability Value>, where each triple is encoded as shown below: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+--------------+----------------+ | Capability Code | Capability Length | +---------------+---------------+--------------+----------------+ | Capability Value (variable)... +---------------+---------------+--------------+----------------+ Figure 5: Capability Optional Parameter Capability Code: Capability Code is a 2-octet field that unambiguously identifies individual capabilities. Capability Length: Capability Length is a 2-octet field that contains the length of the Capability Value field in octets. Capability Value: Capability Value is a variable length field that is interpreted according to the value of the Capability Code field. Any particular capability, as identified by its Capability Code, may appear more than once within the Optional Parameter. This document reserves Capability Codes 32768-65535 for vendor- specific applications (these are the codes with the first bit of the code value equal to 1). This document reserves value 0. Capability Codes (other than those reserved for vendor specific use) are controlled by IANA. See Section 13 for IANA considerations.
The following Capability Codes are defined by this specification:
Code Capability
1 Route Types Supported
2 Send Receive Capability
4.2.1.1.1. Route Types Supported
The Route Types Supported Capability Code lists the route types
supported in this peering session by the transmitting LS. An LS MUST
NOT use route types that are not supported by the peer LS in any
particular peering session. If the route types supported by a peer
are not satisfactory, an LS SHOULD terminate the peering session.
The format for a Route Type is:
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+--------------+----------------+
| Address Family | Application Protocol |
+---------------+---------------+--------------+----------------+
Figure 6: Route Types Supported Capability
The Address Family and Application Protocol are as defined in Section
5.1.1. Address Family gives the address family being routed (within
the ReachableRoutes attribute). The application protocol lists the
application for which the routes apply. As an example, a route type
for TRIP could be <E.164, SIP>, indicating a set of E.164
destinations for the SIP protocol.
The Route Types Supported Capability MAY contain multiple route types
in the capability. The number of route types within the capability
is the maximum number that can fit given the capability length. The
Capability Code is 1 and the length is variable.
4.2.1.1.2. Send Receive Capability
This capability specifies the mode in which the LS will operate with
this particular peer. The possible modes are: Send Only mode,
Receive Only mode, or Send Receive mode. The default mode is Send
Receive mode.
In Send Only mode, an LS transmits UPDATE messages to its peer, but
the peer MUST NOT transmit UPDATE messages to that LS. If an LS in
Send Only mode receives an UPDATE message from its peer, it MUST
discard that message, but no further action should be taken.
The UPDATE messages sent by an LS in Send Only mode to its intra-
domain peer MUST include the ITAD Topology attribute whenever the
topology changes. A useful application of an LS in Send Only mode
with an external peer is to enable gateway registration services.
If a service provider terminates calls to a set of gateways it owns,
but never initiates calls, it can set its LSs to operate in Send Only
mode, since they only ever need to generate UPDATE messages, not
receive them. If an LS in Send Receive mode has a peering session
with a peer in Send Only mode, that LS MUST set its route
dissemination policy such that it does not send any UPDATE messages
to its peer.
In Receive Only mode, the LS acts as a passive TRIP listener. It
receives and processes UPDATE messages from its peer, but it MUST NOT
transmit any UPDATE messages to its peer. This is useful for
management stations that wish to collect topology information for
display purposes.
The behavior of an LS in Send Receive mode is the default TRIP
operation specified throughout this document.
The Send Receive capability is a 4-octet unsigned numeric value. It
can only take one of the following three values:
1 - Send Receive mode
2 - Send only mode
3 - Receive Only mode
A peering session MUST NOT be established between two LSs if both of
them are in Send Only mode or if both of them are in Receive Only
mode. If a peer LS detects such a capability mismatch when
processing an OPEN message, it MUST respond with a NOTIFICATION
message and close the peer session. The error code in the
NOTIFICATION message must be set to "Capability Mismatch."
An LS MUST be configured in the same Send Receive mode for all peers.
4.3. UPDATE Message Format
UPDATE messages are used to transfer routing information between LSs.
The information in the UPDATE packet can be used to construct a graph
describing the relationships between the various ITADs. By applying
rules to be discussed, routing information loops and some other
anomalies can be prevented.
An UPDATE message is used to both advertise and withdraw routes from service. An UPDATE message may simultaneously advertise and withdraw TRIP routes. In addition to the TRIP header, the TRIP UPDATE contains a list of routing attributes as shown in Figure 7. There is no padding between routing attributes. +------------------------------------------------+--... | First Route Attribute | Second Route Attribute | ... +------------------------------------------------+--... Figure 7: TRIP UPDATE Format The minimum length of an UPDATE message is 3 octets (there are no mandatory attributes in TRIP).4.3.1. Routing Attributes
A variable length sequence of routing attributes is present in every UPDATE message. Each attribute is a triple <attribute type, attribute length, attribute value> of variable length. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+--------------+----------------+ | Attr. Flags |Attr. Type Code| Attr. Length | +---------------+---------------+--------------+----------------+ | Attribute Value (variable) | +---------------+---------------+--------------+----------------+ Figure 8: Routing Attribute Format Attribute Type is a two-octet field that consists of the Attribute Flags octet followed by the Attribute Type Code octet. The Attribute Type Code defines the type of attribute. The basic TRIP-defined Attribute Type Codes are discussed later in this section. Attributes MUST appear in the UPDATE message in numerical order of the Attribute Type Code. An attribute MUST NOT be included more than once in the same UPDATE message. Attribute Flags are used to control attribute processing when the attribute type is unknown. Attribute Flags are further defined in Section 4.3.2.
This document reserves Attribute Type Codes 224-255 for vendor- specific applications (these are the codes with the first three bits of the code equal to 1). This document reserves value 0. Attribute Type Codes (other than those reserved for vendor specific use) are controlled by IANA. See Section 13 for IANA considerations. The third and the fourth octets of the route attribute contain the length of the attribute value field in octets. The remaining octets of the attribute represent the Attribute Value and are interpreted according to the Attribute Flags and the Attribute Type Code. The basic supported attribute types, their values, and their uses are defined in this specification. These are the attributes necessary for proper loop free operation of TRIP, both inter-domain and intra-domain. Additional attributes may be defined in future documents.4.3.2. Attribute Flags
It is clear that the set of attributes for TRIP will evolve over time. Hence it is essential that mechanisms be provided to handle attributes with unrecognized types. The handling of unrecognized attributes is controlled via the flags field of the attribute. Recognized attributes should be processed according to their specific definition. The following are the attribute flags defined by this specification: Bit Flag 0 Well-Known Flag 1 Transitive Flag 2 Dependent Flag 3 Partial Flag 4 Link-state Encapsulated Flag The high-order bit (bit 0) of the Attribute Flags octet is the Well- Known Bit. It defines whether the attribute is not well-known (if set to 1) or well-known (if set to 0). Implementations are not required to support not well-known attributes, but MUST support well-known attributes. The second high-order bit (bit 1) of the Attribute Flags octet is the Transitive bit. It defines whether a not well-known attribute is transitive (if set to 1) or non-transitive (if set to 0). For well- known attributes, the Transitive bit MUST be zero on transmit and MUST be ignored on receipt. The third high-order bit (bit 2) of the Attribute Flags octet is the Dependent bit. It defines whether a transitive attribute is
dependent (if set to 1) or independent (if set to 0). For well-known attributes and for non-transitive attributes, the Dependent bit is irrelevant, and MUST be set to zero on transmit and MUST be ignored on receipt. The fourth high-order bit (bit 3) of the Attribute Flags octet is the Partial bit. It defines whether the information contained in the not well-known transitive attribute is partial (if set to 1) or complete (if set to 0). For well-known attributes and for non-transitive attributes the Partial bit MUST be set to 0 on transmit and MUST be ignored on receipt. The fifth high-order bit (bit 4) of the Attribute Flags octet is the Link-state Encapsulation bit. This bit is only applicable to certain attributes (ReachableRoutes and WithdrawnRoutes) and determines the encapsulation of the routes within those attributes. If this bit is set, link-state encapsulation is used within the attribute. Otherwise, standard encapsulation is used within the attribute. The Link-state Encapsulation technique is described in Section 4.3.2.4. This flag is only valid on the ReachableRoutes and WithdrawnRoutes attributes. It MUST be cleared on transmit and MUST be ignored on receipt for all other attributes. The other bits of the Attribute Flags octet are unused. They MUST be zeroed on transmit and ignored on receipt.4.3.2.1. Attribute Flags and Route Selection
Any recognized attribute can be used as input to the route selection process, although the utility of some attributes in route selection is minimal.4.3.2.2. Attribute Flags and Route Dissemination
TRIP provides for two variations of transitivity due to the fact that intermediate LSs need not modify the NextHopServer when propagating routes. Attributes may be non-transitive, dependent transitive, or independent transitive. An attribute cannot be both dependent transitive and independent transitive. Unrecognized independent transitive attributes may be propagated by any intermediate LS. Unrecognized dependent transitive attributes MAY only be propagated if the LS is NOT changing the next-hop server. The transitivity variations permit some unrecognized attributes to be carried end-to-end (independent transitive), some to be carried between adjacent next-hop servers (dependent transitive), and other to be restricted to peer LSs (non-transitive).
An LS that passes an unrecognized transitive attribute to a peer MUST set the Partial flag on that attribute. Any LS along a path MAY insert a transitive attribute into a route. If any LS except the originating LS inserts a new independent transitive attribute into a route, then it MUST set the Partial flag on that attribute. If any LS except an LS that modifies the NextHopServer inserts a new dependent transitive attribute into a route, then it MUST set the Partial flag on that attribute. The Partial flag indicates that not every LS along the relevant path has processed and understood the attribute. For independent transitive attributes, the "relevant path" is the path given in the AdvertisementPath attribute. For dependent transitive attributes, the relevant path consists only of those domains thru which this object has passed since the NextHopServer was last modified. The Partial flag in an independent transitive attribute MUST NOT be unset by any other LS along the path. The Partial flag in a dependent transitive attribute MUST be reset whenever the NextHopServer is changed, but MUST NOT be unset by any LS that is not changing the NextHopServer. The rules governing the addition of new non-transitive attributes are defined independently for each non-transitive attribute. Any attribute MAY be updated by an LS in the path.4.3.2.3. Attribute Flags and Route Aggregation
Each attribute defines how it is to be handled during route aggregation. The rules governing the handling of unknown attributes are guided by the Attribute Flags. Unrecognized transitive attributes are dropped during aggregation. There should be no unrecognized non-transitive attributes during aggregation because non-transitive attributes must be processed by the local LS in order to be propagated.4.3.2.4. Attribute Flags and Encapsulation
Normally attributes have the simple format as described in Section 4.3.1. If the Link-state Encapsulation Flag is set, then the two additional fields are added to the attribute header as shown in Figure 9.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+--------------+----------------+ | Attr. Flags |Attr. Type Code| Attr. Length | +---------------+---------------+--------------+----------------+ | Originator TRIP Identifier | +---------------+---------------+--------------+----------------+ | Sequence Number | +---------------+---------------+--------------+----------------+ | Attribute Value (variable) | +---------------+---------------+--------------+----------------+ Figure 9: Link State Encapsulation The Originator TRIP ID and Sequence Number are used to control the flooding of routing updates within a collection of servers. These fields are used to detect duplicate and old routes so that they are not further propagated to other LSs. The use of these fields is defined in Section 10.1.4.3.3. Mandatory Attributes
There are no Mandatory attributes in TRIP. However, there are Conditional Mandatory attributes. A conditional mandatory attribute is an attribute, which MUST be included in an UPDATE message if another attribute is included in that message. For example, if an UPDATE message includes a ReachableRoutes attribute, it MUST include an AdvertisementPath attribute as well. The three base attributes in TRIP are WithdrawnRoutes, ReachableRoutes, and ITAD Topology. Their presence in an UPDATE message is entirely optional and independent of any other attributes.4.3.4. TRIP UPDATE Attributes
This section summarizes the attributes that may be carried in an UPDATE message. Attributes MUST appear in the UPDATE message in increasing order of the Attribute Type Code. Additional details are provided in Section 5.4.3.4.1. WithdrawnRoutes
This attribute lists a set of routes that are being withdrawn from service. The transmitting LS has determined that these routes should no longer be advertised, and is propagating this information to its peers.
4.3.4.2. ReachableRoutes
This attribute lists a set of routes that are being added to service. These routes will have the potential to be inserted into the Adj- TRIBs-In of the receiving LS and the route selection process will be applied to them.4.3.4.3. NextHopServer
This attribute gives the identity of the entity to which messages should be sent along this routed path. It specifies the identity of the next hop server as either a host domain name or an IP address. It MAY optionally specify the UDP/TCP port number for the next hop signaling server. If not specified, then the default port SHOULD be used. The NextHopServer is specific to the set of destinations and application protocol defined in the ReachableRoutes attribute. Note that this is NOT necessarily the address to which media (voice, video, etc.) should be transmitted, it is only for the application protocol as given in the ReachableRoutes attribute.4.3.4.4. AdvertisementPath
The AdvertisementPath is analogous to the AS_PATH in BGP4 [3]. The attribute records the sequence of domains through which this advertisement has passed. The attribute is used to detect when the routing advertisement is looping. This attribute does NOT reflect the path through which messages following this route would traverse. Since the next-hop need not be modified by each LS, the actual path to the destination might not have to traverse every domain in the AdvertisementPath.4.3.4.5. RoutedPath
The RoutedPath attribute is analogous to the AdvertisementPath attribute, except that it records the actual path (given by the list of domains) *to* the destinations. Unlike AdvertisementPath, which is modified each time the route is propagated, RoutedPath is only modified when the NextHopServer attribute changes. Thus, it records the subset of the AdvertisementPath which signaling messages following this particular route would traverse.4.3.4.6. AtomicAggregate
The AtomicAggregate attribute indicates that a route may actually include domains not listed in the RoutedPath. If an LS, when presented with a set of overlapping routes from a peer LS, selects a less specific route without selecting the more specific route, then the LS MUST include the AtomicAggregate attribute with the route. An
LS receiving a route with an AtomicAggregate attribute MUST NOT make the set of destinations more specific when advertising it to other LSs.4.3.4.7. LocalPreference
The LocalPreference attribute is an intra-domain attribute used to inform other LSs of the local LS's preference for a given route. The preference of a route is calculated at the ingress to a domain and passed as an attribute with that route throughout the domain. Other LSs within the same ITAD use this attribute in their route selection process. This attribute has no significance between domains.4.3.4.8. MultiExitDisc
There may be more than one LS peering relationship between neighboring domains. The MultiExitDisc attribute is used by an LS to express a preference for one link between the domains over another link between the domains. The use of the MultiExitDisc attribute is controlled by local policy.4.3.4.9. Communities
The Communities attribute is not a well-known attribute. It is used to facilitate and simplify the control of routing information by grouping destinations into communities.4.3.4.10. ITAD Topology
The ITAD topology attribute is an intra-domain attribute that is used by LSs to indicate their intra-domain topology to other LSs in the domain.4.3.4.11. ConvertedRoute
The ConvertedRoute attribute indicates that an intermediate LS has altered the route by changing the route's Application Protocol.4.4. KEEPALIVE Message Format
TRIP does not use any transport-based keep-alive mechanism to determine if peers are reachable. Instead, KEEPALIVE messages are exchanged between peers often enough as not to cause the Hold Timer to expire. A reasonable maximum time between KEEPALIVE messages would be one third of the Hold Time interval. KEEPALIVE messages MUST NOT be sent more than once every 3 seconds. An implementation SHOULD adjust the rate at which it sends KEEPALIVE messages as a function of the negotiated Hold Time interval.
If the negotiated Hold Time interval is zero, then periodic KEEPALIVE messages MUST NOT be sent. The KEEPALIVE message consists of only a message header and has a length of 3 octets.4.5. NOTIFICATION Message Format
A NOTIFICATION message is sent when an error condition is detected. The TRIP transport connection is closed immediately after sending a NOTIFICATION message. In addition to the fixed-size TRIP header, the NOTIFICATION message contains the following fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+--------------+----------------+ | Error Code | Error Subcode | Data... (variable) +---------------+---------------+--------------+----------------+ Figure 10: TRIP NOTIFICATION Format Error Code: This 1-octet unsigned integer indicates the type of NOTIFICATION. The following Error Codes have been defined: Error Code Symbolic Name Reference 1 Message Header Error Section 6.1 2 OPEN Message Error Section 6.2 3 UPDATE Message Error Section 6.3 4 Hold Timer Expired Section 6.5 5 Finite State Machine Error Section 6.6 6 Cease Section 6.7 Error Subcode: This 1-octet unsigned integer provides more specific information about the nature of the reported error. Each Error Code may have one or more Error Subcodes associated with it. If no appropriate Error Subcode is defined, then a zero (Unspecific) value is used for the Error Subcode field. Message Header Error Subcodes: 1 - Bad Message Length. 2 - Bad Message Type.
OPEN Message Error Subcodes:
1 - Unsupported Version Number.
2 - Bad Peer ITAD.
3 - Bad TRIP Identifier.
4 - Unsupported Optional Parameter.
5 - Unacceptable Hold Time.
6 - Unsupported Capability.
7 - Capability Mismatch.
UPDATE Message Error Subcodes:
1 - Malformed Attribute List.
2 - Unrecognized Well-known Attribute.
3 - Missing Well-known Mandatory Attribute.
4 - Attribute Flags Error.
5 - Attribute Length Error.
6 - Invalid Attribute.
Data:
This variable-length field is used to diagnose the reason for the
NOTIFICATION. The contents of the Data field depend upon the Error
Code and Error Subcode.
Note that the length of the data can be determined from the message
length field by the formula:
Data Length = Message Length - 5
The minimum length of the NOTIFICATION message is 5 octets (including
message header).
(page 24 continued on part 2)
