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 ....................................... 79
1. 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 RFC2119 [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).
5. TRIP Attributes
This section provides details on the syntax and semantics of each
TRIP UPDATE attribute.
5.1. WithdrawnRoutes
Conditional Mandatory: False.
Required Flags: Well-known.
Potential Flags: Link-State Encapsulation (when flooding).
TRIP Type Code: 1
The WithdrawnRoutes specifies a set of routes that are to be removed
from service by the receiving LS(s). The set of routes MAY be empty,
indicated by a length field of zero.
5.1.1. Syntax of WithdrawnRoutes
The WithdrawnRoutes Attribute encodes a sequence of routes in its
value field. The format for individual routes is given in Section
5.1.1.1. The WithdrawnRoutes Attribute lists the individual routes
sequentially with no padding as shown in Figure 11. Each route
includes a length field so that the individual routes within the
attribute can be delineated.
+---------------------+---------------------+...
WithdrawnRoute1... WithdrawnRoute2... ...
+---------------------+---------------------+...
Figure 11: WithdrawnRoutes Format
5.1.1.1. Generic TRIP Route Format
The generic format for a TRIP route is given in Figure 12.
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
+---------------+---------------+--------------+----------------+
Address Family Application Protocol
+---------------+---------------+--------------+----------------+
Length Address (variable) ...
+---------------+---------------+--------------+----------------+
Figure 12: Generic TRIP Route Format
Address Family:
The address family field gives the type of address for the route.
Three address families are defined in this Section:
Code Address Family
1 Decimal Routing Numbers
2 PentaDecimal Routing Numbers
3 E.164 Numbers
This document reserves address family code 0. This document reserves
address family codes 32768-65535 for vendor-specific applications
(these are the codes with the first bit of the code value equal to
1). Additional address families may be defined in the future.
Assignment of address family codes is controlled by IANA. See
Section 13 for IANA considerations.
Application Protocol:
The application protocol gives the protocol for which this routing
table is maintained. The currently defined application protocols
are:
Code Protocol
1 SIP
2 H.323-H.225.0-Q.931
3 H.323-H.225.0-RAS
4 H.323-H.225.0-Annex-G
This document reserves application protocol code 0. This document
reserves application protocol codes 32768-65535 for vendor-specific
applications (these are the codes with the first bit of the code
value equal to 1). Additional application protocols may be defined
in the future. Assignment of application protocol codes is
controlled by IANA. See Section 13 for IANA considerations.
Length:
The length of the address field, in bytes.
Address:
This is an address (prefix) of the family type given by Address
Family. The octet length of the address is variable and is
determined by the length field of the route.
5.1.1.2. Decimal Routing Numbers
The Decimal Routing Numbers address family is a super set of all
E.164 numbers, national numbers, local numbers, and private numbers.
It can also be used to represent the decimal routing numbers used in
conjunction with Number Portability in some countries/regions. A set
of telephone numbers is specified by a Decimal Routing Number prefix.
Decimal Routing Number prefixes are represented by a string of
digits, each digit encoded by its ASCII character representation.
This routing object covers all phone numbers starting with this
prefix. The syntax for the Decimal Routing Number prefix is:
Decimal-routing-number = *decimal-digit
decimal-digit = DECIMAL-DIGIT
DECIMAL-DIGIT = "0""1""2""3""4""5""6""7""8""9"
This DECIMAL Routing Number prefix is not bound in length. This
format is similar to the format for a global telephone number as
defined in SIP [8] without visual separators and without the "+"
prefix for international numbers. This format facilitates efficient
comparison when using TRIP to route SIP or H323, both of which use
character based representations of phone numbers. The prefix length
is determined from the length field of the route. The type of
Decimal Routing Number (private, local, national, or international)
can be deduced from the first few digits of the prefix.
5.1.1.3. PentaDecimal Routing Numbers
This address family is used to represent PentaDecimal Routing Numbers
used in conjunction with Number Portability in some
countries/regions. PentaDecimal Routing Number prefixes are
represented by a string of digits, each digit encoded by its ASCII
character representation. This routing object covers all routing
numbers starting with this prefix. The syntax for the PentaDecimal
Routing Number prefix is:
PentaDecimal-routing-number = *pentadecimal-digit
pentadecimal-routing-digit = PENTADECIMAL-DIGIT
PENTADECIMAL-DIGIT = "0""1""2""3""4""5""6""7"
"8""9""A""B""C""D""E"
Note the difference in alphabets between Decimal Routing Numbers and
PentaDecimal Routing Numbers. A PentaDecimal Routing Number prefix
is not bound in length.
Note that the address family, which suits the routing numbers of a
specific country/region depends on the alphabets used for routing
numbers in that country/region. For example, North American routing
numbers SHOULD use the Decimal Routing Numbers address family,
because their alphabet is limited to the digits "0" through "9".
Another example, in most European countries routing numbers use the
alphabet "0" through "9" and "A" through "E", and hence these
countries SHOULD use the PentaDecimal Routing Numbers address family.
5.1.1.4. E.164 Numbers
The E.164 Numbers address family is dedicated to fully qualified
E.164 numbers. A set of telephone numbers is specified by a E.164
prefix. E.164 prefixes are represented by a string of digits, each
digit encoded by its ASCII character representation. This routing
object covers all phone numbers starting with this prefix. The
syntax for the E.164 prefix is:
E164-number = *e164-digit
E164-digit = E164-DIGIT
E164-DIGIT = "0""1""2""3""4""5""6""7""8""9"
This format facilitates efficient comparison when using TRIP to route
SIP or H323, both of which use character based representations of
phone numbers. The prefix length is determined from the length field
of the route.
The E.164 Numbers address family and the Decimal Routing Numbers
address family have the same alphabet. The E.164 Numbers address
family SHOULD be used whenever possible. The Decimal Routing Numbers
address family can be used in case of private numbering plans or
applications that do not desire to advertise fully expanded, fully
qualified telephone numbers. If Decimal Routing Numbers are used to
advertise non-fully qualified prefixes, the prefixes may have to be
manipulated (e.g. expanded) at the boundary between ITADs. This adds
significant complexity to the ITAD-Border LS, because, it has to map
the prefixes from the format used in its own ITAD to the format used
in the peer ITAD.
5.2. ReachableRoutes
Conditional Mandatory: False.
Required Flags: Well-known.
Potential Flags: Link-State Encapsulation (when flooding).
TRIP Type Code: 2
The ReachableRoutes attribute specifies a set of routes that are to
be added to service by the receiving LS(s). The set of routes MAY be
empty, as indicated by setting the length field to zero.
5.2.1. Syntax of ReachableRoutes
The ReachableRoutes Attribute has the same syntax as the
WithdrawnRoutes Attribute. See Section 5.1.1.
5.2.2. Route Origination and ReachableRoutes
Routes are injected into TRIP by a method outside the scope of this
specification. Possible methods include a front-end protocol, an
intra-domain routing protocol, or static configuration.
5.2.3. Route Selection and ReachableRoutes
The routes in ReachableRoutes are necessary for route selection.
5.2.4. Aggregation and ReachableRoutes
To aggregate multiple routes, the set of ReachableRoutes to be
aggregated MUST combine to form a less specific set.
There is no mechanism within TRIP to communicate that a particular
address prefix is not used 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.
If an LS advertises an aggregated route, it MUST include the
AtomicAggregate attribute.
5.2.5. Route Dissemination and ReachableRoutes
The ReachableRoutes attribute is recomputed at each LS except where
flooding is being used (e.g., within a domain). It is therefore
possible for an LS to change the Application Protocol field of a
route before advertising that route to an external peer.
If an LS changes the Application Protocol of a route it advertises,
it MUST include the ConvertedRoute attribute in the UPDATE message.
5.2.6. Aggregation Specifics for Decimal Routing Numbers, E.164 Numbers,
and PentaDecimal Routing Numbers
An LS that has routes to all valid numbers in a specific prefix
SHOULD advertise that prefix as the ReachableRoutes, even if there
are more specific prefixes that do not actually exist on the PSTN.
Generally, it takes 10 Decimal Routing/E.164 prefixes, or 15
PentaDecimal Routing prefixes, of length n to aggregate into a prefix
of length n-1. However, if an LS is aware that a prefix is an
invalid Decimal Routing/E.164 prefix, or PentaDecimal Routing prefix,
then the LS MAY aggregate by skipping this prefix. For example, if
the Decimal Routing prefix 19191 is known not to exist, then an LS
can aggregate to 1919 without 19191. A prefix representing an
invalid set of PSTN destinations is sometimes referred to as a
"black-hole." The method by which an LS is aware of black-holes is
not within the scope of TRIP, but if an LS has such knowledge, it can
use the knowledge when aggregating.
5.3. NextHopServer
Conditional Mandatory: True (if ReachableRoutes and/or
WithdrawnRoutes attribute is present).
Required Flags: Well-known.
Potential Flags: None.
TRIP Type Code: 3.
Given a route with application protocol A and destinations D, the
NextHopServer indicates to the next-hop that messages of protocol A
destined for D should be sent to it. This may or may not represent
the ultimate destination of those messages.
5.3.1. NextHopServer Syntax
For generality, the address of the next-hop server may be of various
types (domain name, IPv4, IPv6, etc). The NextHopServer attribute
includes the ITAD number of next-hop server, a length field, and a
next-hop name or address.
The syntax for the NextHopServer is given in Figure 13.
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
+---------------+---------------+--------------+----------------+
Next Hop ITAD
+---------------+---------------+--------------+----------------+
Length Server (variable) ...
+---------------+---------------+--------------+----------------+
Figure 13: NextHopServer Syntax
The Next-Hop ITAD indicates the domain of the next-hop. Length field
gives the number of octets in the Server field, and the Server field
contains the name or address of the next-hop server. The server
field is represented as a string of ASCII characters. It is defined
as follows:
Server = host [":" port ]<