RFC 3219
Telephony Routing over IP (TRIP)
RFC 3219: Telephony Routing over IP (TRIP) 📞✨
okay bestie, this is RFC 3219, and it's a Standards Track doc from the Network Working Group 🎀 dated January 2002. The authors are J. Rosenberg (dynamicsoft), H. Salama (Cisco Systems), and M. Squire (Hatteras Networks). The title block doesn't list anything it obsoletes or updates, so it doesn't replace or change any earlier RFC. 💅
Status of This Memo 📋
this one is an Internet standards track protocol for the Internet community 🌸 and it's asking for discussion and suggestions to make it better. for the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). and the distribution of this memo is unlimited, so share it with everyone 💜
Copyright Notice ©️
Copyright (C) The Internet Society (2002). All Rights Reserved. 🦋
Abstract ✨
so TRIP (Telephony Routing over IP) is a policy driven inter-administrative domain protocol 👑 that location servers use to advertise where telephony destinations can be reached. it also advertises the attributes of the routes that lead to those destinations. the really iconic part is that TRIP runs independently of any signaling protocol, so it can be the telephony routing protocol for any signaling protocol 🔥
the Border Gateway Protocol (BGP-4) already moves routing info between administrative domains, and TRIP moves telephony routing info between telephony administrative domains. the two are obviously similar, so TRIP is modeled after BGP-4 🫶 (it's giving family resemblance 😭)
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 BCP 14 key words in this doc are: "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL". they're to be read as described in RFC 2119 [1] 💖
the framework for TRIP is described in [2], and we assume you already know that framework and its terminology 🧚 we define and use the following extra terms on top of those in [2] ✨
Telephony Routing Information Base (TRIB): the database of reachable telephony destinations that an LS builds and maintains because it takes part 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: route X is less specific than route Y if every destination in Y is also a destination in X, and X and Y are not equal. in that case, Y is also more specific than X 🦋
Aggregation: aggregation is when multiple routes get combined into a single less specific route that covers the same set of destinations. it's used to shrink the TRIB that gets synchronized with peer LSs, by cutting down 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're internal peers. otherwise they're 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. TRIP's job is to advertise the reachability of telephony destinations, the attributes associated with those destinations, and the attributes of the path toward them 💜
TRIP destination: TRIP can 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 ✨
okay so the gateway location and routing problem was first introduced in [2], and it's honestly one of the trickiest parts of IP telephony 😭. picking an egress gateway for a call that travels across an IP network toward a final destination in the PSTN depends a LOT on the policies of everyone along the path and on how those parties are related to each other. so a single global directory where users look up phone numbers is NOT a realistic option 🙅♀️. instead, providers swap info about which egress gateways are available, that info gets filtered by policy, it's made available locally, and then it's passed along to providers in other ITADs. that's how routes to those gateways get built 🛣️✨. the end result is that each provider gets its own database of reachable phone numbers and routes, and it can look really different from one provider to the next depending on their policy 💅.
TRIP is an inter-domain (aka inter-ITAD) gateway location and routing protocol 🎀. its main job is handled by a TRIP speaker called a location server (LS), which swaps info with other LSs. that info covers which telephony destinations are reachable, the routes to them, and info about the gateways that lead to those destinations in the PSTN 📞. the TRIP requirements are laid out in [2] 🌸.
LSs trade enough routing info to build a graph of ITAD connectivity, so routing loops can get prevented 🔁. TRIP can also carry attributes used to enforce policies and to pick routes based on path or gateway characteristics 🧚. this spec defines TRIP's transport and synchronization mechanisms, its finite state machine, and the TRIP data, plus the basic attributes. the attribute set is extendible, so new attributes can show up in future documents 🦋.
TRIP is modeled after BGP-4 [3] and gets some link-state features from OSPF [4], IS-IS [5], and SCSP [6], which is giving "best of all worlds" energy 🌈. it borrows BGP's inter-domain transport, BGP's peer communication, BGP's finite state machine, and formats and attributes that look a lot like BGP's 💜. the big difference is that TRIP allows generic intra-domain LS topologies, which keeps configuration simpler and scales better than BGP's full mesh of internal BGP speakers 🙌. TRIP's intra-domain flooding works like the flooding in OSPF [4], IS-IS [5], and SCSP [6] 🌊.
TRIP can aggregate routes as they get advertised through the network 🧩. it does NOT define a specific route selection algorithm, so that part is up to the implementer 🤷♀️.
TRIP runs over a reliable transport protocol, which means no explicit fragmentation, retransmission, acknowledgment, or sequencing needs to be implemented, and honestly that's such a relief 😮💨✨. the error notification mechanism in TRIP assumes the transport supports a graceful close, meaning all outstanding data gets delivered before the connection closes 🎁.
TRIP's operation doesn't depend on any particular telephony signaling protocol, so it can be the routing protocol for things like H.323 [7] and SIP [8] 📱💖.
The LS peering topology doesn't have to match the physical topology of the network 🗺️. also, ITAD boundaries are independent from layer 3 routing autonomous system boundaries, and neither internal nor external TRIP peers have to be physically adjacent 🫶.
3. Summary of Operation 🎀
this section gives you the quick recap of how TRIP works, and the full details show up in later sections 📖.
3.1. Peering Session Establishment and Maintenance 🤝
two peer LSs set up a transport protocol connection between each other. they swap messages to open and confirm the connection parameters, and to negotiate each LS's capabilities and the kind of info that gets advertised over the connection 💬.
KeepAlive messages get sent periodically to make sure adjacent peers are still operational 💓. Notification messages go out when there are errors or special conditions 🚨. if a connection runs into an error condition, a Notification message is sent and then the connection closes 🔒.
3.2. Database Exchanges 📚
once the peer connection is up, the first data flow is a dump of all routes relevant to the new peer. for an external peer, that's all routes in the LS's Adj-TRIB-Out for that peer. for an internal peer, it's all routes in the Ext-TRIB and all Adj-TRIBs-In. (the different TRIBs are defined in Section 3.5, so peek there if you need a refresher 👀.)
incremental updates get sent whenever the TRIP routing tables (TRIBs) change 🔄. TRIP doesn't need periodic refresh of routes, so an LS has to keep the current version of all its routing entries 🗂️.
if an ITAD has multiple LSs and is providing transit service for other ITADs, care is needed to keep the view of routing consistent inside that ITAD 🧠. once synchronized, the TRIP routing tables (the Loc-TRIBs) of all internal peers are identical 👯♀️.
3.3. Internal Versus External Synchronization 🔀
just like BGP, TRIP splits peers into internal and external ones 💅. inside an ITAD, internal TRIP uses link-state mechanisms to flood database updates across an arbitrary topology 🌐. outside the ITAD, TRIP uses point-to-point peering to exchange database info 🤝.
to get internal synchronization, internal peer connections are set up between LSs of the same ITAD so that the resulting intra-domain LS topology is connected and sufficiently redundant 🕸️. this is different from BGP, which needs every internal peer in a full mesh, and that can cause scaling problems 😩. when an update comes in from an internal peer, the routes in it are checked to see if they're newer than the version already in the database. newer routes then get flooded to all other peers in the same domain 🌊✨.
3.4. Advertising TRIP Routes 📣
in TRIP, a route is the combination of (a) a set of destination addresses (given by an address family indicator and an address prefix) and (b) an application protocol, like SIP or H323 🎯. there are usually extra attributes attached to each route too, like the next-hop server 🧾.
TRIP routes are advertised between a pair of LSs in UPDATE messages 📬. the destination addresses go in the ReachableRoutes attribute of the UPDATE, and the other attributes describe things like the path or egress gateway 🛤️.
if an LS decides to advertise a TRIP route, it can add to or modify the route's attributes before sending it to a peer ✏️. TRIP gives an LS ways to tell its peer that a route it previously advertised is no longer usable 🙅♀️. there are three ways an 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.wait, I have to be super careful here because I'm pulling those bullets out of the spec, so the exact wording matters 🙈. the important bit: if an LS decides another internal LS is no longer active, 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 handles 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 one that gets injected into TRIP locally, for example by configuration or by redistribution from another routing protocol 🛠️.
the Telephony Routing Information Base (TRIB) inside an LS has four distinct parts 💖:
- Adj-TRIBs-In: these store routing info learned from inbound UPDATE messages 📥. their contents are TRIP routes that are available as input to the Decision Process, so they're the "unprocessed" routes that came in 🥡. routes from each external peer LS and each internal LS are kept in this database separately, so an update from one peer doesn't change the routes from another 🙅♀️. and yes, there's an Adj-TRIB-In for every LS in the domain, even the ones the LS isn't directly peered with 👀.
- Ext-TRIB: there's only one Ext-TRIB per LS 👑. the LS runs the route selection algorithm on all external routes (kept in the Adj-TRIBs-In of the external peers) and local routes (which may be kept in an Adj-TRIB-In representing the local LS), picks the best route for each destination, and stores it in the Ext-TRIB 🏆. Section 10.3.1 explains the Ext-TRIB further 📖.
- Loc-TRIB: the Loc-TRIB holds the local TRIP routing info the LS has selected by applying its local policies to the info in its Adj-TRIBs-In of internal LSs and the Ext-TRIB 🧠.
- Adj-TRIBs-Out: these store the info the local LS has selected for advertisement to its external peers 📤. the routing info in the Adj-TRIBs-Out gets carried in the local LS's UPDATE messages and advertised to its peers 💌.
Figure 1 shows how the four parts of the routing information base relate to each other 🗺️.
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 Relationshipsand here's the kicker: even though the conceptual model separates Adj-TRIBs-In, Ext-TRIB, Loc-TRIB, and Adj-TRIBs-Out, that doesn't mean an implementation has to keep four separate copies of the routing info 🤯. the choice is up to the implementation (for example, 4 copies vs. 1 copy with pointers), and the protocol doesn't constrain it 💅✨.
3.6. Routes in TRIP 🎀
okay so a route in TRIP covers a range of numbers by being a prefix of those numbers 💅 (the exact definition and syntax of a route are in 5.1.1). Arbitrary ranges of numbers are NOT something a single route can represent atomically 🙈 A prefix range is the only type that works atomically. If you want an arbitrary range, you use multiple prefixes inside 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. it's giving puzzle-solving energy 🧩
3.7. Aggregation 🦋
Aggregation is a scaling enhancement that an LS uses to reduce the number of routing entries it has to synchronize with its peers. an LS may aggregate when there's 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 explains how to combine each attribute (by type) on the {R1, R2, ...} routes into an attribute for R. so cute, the math checks out 🌸
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. ngl this is a gap, but LSs may use methods outside of TRIP to learn about invalid prefixes that can 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. main character energy for that signalling server 👑✨
When an LS resets the NextHopServer of any route (this may happen 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 the 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. tiny but mighty 🧚
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 HeaderLength: This 2-octet unsigned integer indicates the total length of the message, including the header, in octets. Thus, it lets you find the beginning of the next message in the transport-level stream 🦋 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. no extra fluff allowed, bestie 💅
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 - KEEPALIVE4.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 handshake is giving choreography 💃
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 HeaderVersion: 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. When an OPEN message is received, 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. the timers are a whole mood ⏱️
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. zero means nothing, no drama 🙃
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 EncodingParameter 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 an LS uses to tell its peer the list of capabilities it supports. That lets an LS learn about the capabilities of its peer LSs. Capability negotiation is defined in Section 8. peer-to-peer hype 🫶
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 ParameterCapability 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 Capability4.2.1.1.1. Route Types Supported 🎀
okay so the Route Types Supported Capability Code lists the route types that the transmitting LS supports in this peering session 💅 An LS MUST NOT use route types that the peer LS doesn't support in any particular peering session. If the route types a peer supports aren't 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 CapabilityThe 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 iconic 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 modeA 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 FormatThe 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 FormatAttribute 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 FlagThe 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 💌
okay so TRIP has two flavors of transitivity 🦋 because intermediate LSs don't have to change the NextHopServer when they pass a route along. Attributes can be non-transitive, dependent transitive, or independent transitive. An attribute cannot be both dependent transitive and independent transitive at the same time 🙅♀️
Unrecognized independent transitive attributes can be propagated by any intermediate LS ✨ Unrecognized dependent transitive attributes MAY only be propagated if the LS is NOT changing the next-hop server 💅 This is the part that gets me: the three flavors let some unrecognized attributes travel end-to-end (independent transitive) 🌍, some only between adjacent next-hop servers (dependent transitive) 🤝, and others only between 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 🌸
So the Partial flag basically means "not every LS on the relevant path has processed and understood this attribute" 👀 For independent transitive attributes, the "relevant path" is the path given in the AdvertisementPath attribute. For dependent transitive attributes, the relevant path is only the domains the object has passed through 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 for adding new non-transitive attributes are defined separately for each non-transitive attribute, so there's no one-size-fits-all rule 🎀 And any attribute MAY be updated by an LS in the path 🦋
4.3.2.3. Attribute Flags and Route Aggregation
Every attribute spells out how it gets handled during route aggregation 📦
The Attribute Flags are what guide the rules for unknown attributes 🚦 Unrecognized transitive attributes get dropped during aggregation 🗑️ There should be no unrecognized non-transitive attributes during aggregation, because non-transitive attributes must be processed by the local LS before they can be propagated 🧠
4.3.2.4. Attribute Flags and Encapsulation
Normally attributes use the simple format described in Section 4.3.1 💅 If the Link-state Encapsulation Flag is set, then two extra fields get 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 EncapsulationThe Originator TRIP ID and Sequence Number are the fields that control flooding of routing updates within a collection of servers 🌊 They're how servers spot duplicate and old routes so those don't keep getting passed on to other LSs 🙈 The details for using these fields are in Section 10.1 📖
4.3.3. Mandatory Attributes
There are no Mandatory attributes in TRIP 🙌 BUT there are Conditional Mandatory attributes 👀 A conditional mandatory attribute is one that MUST be included in an UPDATE message if another attribute is included in that same 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 gives a quick summary of the attributes that can be carried in an UPDATE message ✨ Attributes MUST appear in the UPDATE message in increasing order of the Attribute Type Code 🔢 More details are in Section 5 📚
4.3.4.1. WithdrawnRoutes
This attribute lists routes that are being withdrawn from service 🚫 The transmitting LS has decided these routes should no longer be advertised, and it's telling its peers 📢
4.3.4.2. ReachableRoutes
This attribute lists routes that are being added to service 🌈 These routes have the potential to be inserted into the Adj-TRIBs-In of the receiving LS, and the route selection process gets applied to them 🎯
4.3.4.3. NextHopServer
This attribute tells you who messages should be sent to along this routed path 📬 It identifies the next hop server by 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 the port isn't 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 where media (voice, video, etc.) should be sent 📹 It's only for the application protocol given in the ReachableRoutes attribute 💅
4.3.4.4. AdvertisementPath
The AdvertisementPath is basically the BGP4 [3] AS_PATH's cousin 👯 This attribute records the sequence of domains the advertisement has passed through 🗺️ It's used to detect when a routing advertisement is looping 🔁 This attribute does NOT reflect the path that messages following this route would take 🙅♀️ Since the next-hop doesn't have to be modified by each LS, the actual path to the destination might not go through every domain in the AdvertisementPath 🤷♀️
4.3.4.5. RoutedPath
RoutedPath is like AdvertisementPath, except it records the actual path (the list of domains) to the destinations 🛣️ AdvertisementPath gets modified every time the route is propagated, but RoutedPath is only modified when the NextHopServer attribute changes 💫 So it records the subset of the AdvertisementPath that signaling messages following this particular route would go through 🦋
4.3.4.6. AtomicAggregate
The AtomicAggregate attribute says that a route might include domains that aren't listed in the RoutedPath 👀 If an LS gets a set of overlapping routes from a peer LS and picks a less specific route without picking the more specific one, then the LS MUST include the AtomicAggregate attribute with the route 🚨 An LS that receives 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
LocalPreference is an intra-domain attribute that tells other LSs what the local LS prefers for a given route 🎀 The preference is calculated at the ingress to a domain, then passed along as an attribute with that route throughout the domain 🏠 Other LSs within the same ITAD use it in their route selection process 🧠 It has no significance between domains 🙅♀️
4.3.4.8. MultiExitDisc
Neighboring domains can have more than one LS peering relationship between them 🔀 The MultiExitDisc attribute lets an LS express a preference for one link between the domains over another 🛤️ How it gets used is controlled by local policy 📋
4.3.4.9. Communities
Communities is NOT a well-known attribute 🙈 It's there to help control routing information more easily by grouping destinations into communities 🏘️
4.3.4.10. ITAD Topology
The ITAD Topology attribute is intra-domain, and LSs use it to show their intra-domain topology to other LSs in the domain 🗺️🫶
4.3.4.11. ConvertedRoute
The ConvertedRoute attribute tells you an intermediate LS has changed the route by swapping out its Application Protocol 🔄✨
4.4. KEEPALIVE Message Format
TRIP doesn't use any transport-based keep-alive mechanism to check whether peers are reachable 🙅♀️ Instead, KEEPALIVE messages get exchanged between peers often enough that the Hold Timer never expires ⏰ 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 how often it sends KEEPALIVE messages based on the negotiated Hold Time interval 💅
If the negotiated Hold Time interval is zero, then periodic KEEPALIVE messages MUST NOT be sent 🛑
The KEEPALIVE message is just a message header, and it's 3 octets long 🦋
4.5. NOTIFICATION Message Format ✨
okay so a NOTIFICATION message gets sent whenever something goes wrong 😭 and the second it's sent, the TRIP transport connection gets closed immediately. no sticking around, we're leaving the chat 💅
on top of the fixed-size TRIP header, the NOTIFICATION has these 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 FormatError Code is a 1-octet unsigned integer that tells you what type of drama happened 🍓 These are the Error Codes that 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.7Error Subcode is also a 1-octet unsigned integer, and it gets specific about what went wrong 🔍 Each Error Code can have one or more Subcodes hanging off it. If there's no Subcode that fits, you just use zero (Unspecific) 🫶
Here are the Message Header Error Subcodes:
1- Bad Message Length.2- Bad Message Type.
Here are the 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.
Here are the 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 is a variable-length field used to diagnose why the NOTIFICATION was sent 🧚 What goes in it depends on the Error Code and Error Subcode.
The length of the Data can be figured out from the message length field with this formula:
Data Length = Message Length - 5The minimum length of a NOTIFICATION message is 5 octets, and that includes the message header 💜
5. TRIP Attributes 🦋
this section is all about the syntax and semantics of each TRIP UPDATE attribute. it's the nitty-gritty, bestie 🤓
5.1. WithdrawnRoutes
- Conditional Mandatory: False.
- Required Flags: Well-known.
- Potential Flags: Link-State Encapsulation (when flooding).
- TRIP Type Code: 1
WithdrawnRoutes is how you tell the receiving LS(s) which routes to pull from service 🚫 The set of routes MAY be empty, and you show that with a length field of zero 🌸
5.1.1. Syntax of WithdrawnRoutes
The WithdrawnRoutes Attribute packs a sequence of routes into its value field. The format for each individual route is in Section 5.1.1.1. The routes are listed one after another with no padding 🙅♀️ Each route has its own length field, so the receiver can tell where one ends and the next begins.
+---------------------+---------------------+...
| WithdrawnRoute1... | WithdrawnRoute2... |...
+---------------------+---------------------+...
Figure 11: WithdrawnRoutes Format5.1.1.1. Generic TRIP Route Format
Here's the generic format for a TRIP route 🎀
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 FormatAddress Family tells you what kind of address the route is. Three address families are defined in this Section:
Code Address Family
1 Decimal Routing Numbers
2 PentaDecimal Routing Numbers
3 E.164 NumbersThis document reserves address family code 0 🔒 It also reserves address family codes 32768-65535 for vendor-specific stuff (the codes where the first bit is equal to 1). More address families might show up in the future. IANA controls who gets to assign address family codes, and you can check Section 13 for the IANA considerations ✨
Application Protocol tells you which protocol this routing table is kept for. The ones defined right now 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-GThis document reserves application protocol code 0 🔒 It reserves application protocol codes 32768-65535 for vendor-specific applications (again, the codes where the first bit is equal to 1). More application protocols may be defined later. IANA controls the assignment of application protocol codes too, and Section 13 has the IANA details 🌈
Length is the length of the address field, in bytes 📏
Address is an address (prefix) of the family type given by Address Family 🗺️ Its octet length is variable, and the route's length field is what tells you how long it is.
5.1.1.2. Decimal Routing Numbers
The Decimal Routing Numbers address family is a superset of all E.164 numbers, national numbers, local numbers, and private numbers 📞 It can also represent the decimal routing numbers used with Number Portability in some countries/regions. A set of telephone numbers is specified by a Decimal Routing Number prefix. These prefixes are strings of digits, where each digit is encoded as its ASCII character 🔤 A prefix covers every phone number that starts with it. The syntax is:
Decimal-routing-number = *decimal-digit
decimal-digit = DECIMAL-DIGIT
DECIMAL-DIGIT = "0"|"1"|"2"|"3"|"4"|"5"|"6"|"7"|"8"|"9"This prefix is not bound in length. The format looks like a global telephone number as defined in SIP [8], minus the visual separators and minus the "+" for international numbers 💅 It's built this way so comparisons are efficient when TRIP is routing SIP or H323, since both use character-based phone numbers. The prefix length comes from the route's length field. You can tell what kind of Decimal Routing Number it is (private, local, national, or international) by looking at the first few digits of the prefix 👀
5.1.1.3. PentaDecimal Routing Numbers
This address family represents PentaDecimal Routing Numbers, which are used with Number Portability in some countries/regions 🌍 PentaDecimal Routing Number prefixes are strings of digits, each encoded as its ASCII character. A prefix covers every routing number that starts with it. The syntax 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 alphabet difference between Decimal Routing Numbers and PentaDecimal Routing Numbers 🧐 A PentaDecimal Routing Number prefix isn't bound in length either.
The address family you pick depends on the alphabet that a country/region uses for its routing numbers 🗺️ 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: most European countries use "0" through "9" and "A" through "E" for routing numbers, so those 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 an E.164 prefix. These are strings of digits, each encoded as its ASCII character, and a prefix covers every phone number starting with it. The syntax is:
E164-number = *e164-digit
E164-digit = E164-DIGIT
E164-DIGIT = "0"|"1"|"2"|"3"|"4"|"5"|"6"|"7"|"8"|"9"This format makes comparisons efficient when TRIP routes SIP or H323, since both use character-based phone numbers ✨ The prefix length is determined from the length field of the route.
The E.164 Numbers and Decimal Routing Numbers address families have the same alphabet 🧃 The E.164 Numbers family SHOULD be used whenever possible. Decimal Routing Numbers can be used for private numbering plans, or for applications that don't want to advertise fully expanded, fully qualified phone numbers 🎀 If Decimal Routing Numbers advertise prefixes that aren't fully qualified, those prefixes might need to be manipulated (for example, expanded) at the boundary between ITADs. That adds real complexity to the ITAD-Border LS, because it has to map 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
ReachableRoutes specifies the routes that the receiving LS(s) should add to service 🚀 The set of routes MAY be empty, which you indicate 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 get injected into TRIP through a method that's 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 being aggregated MUST combine to form a less specific set 🧩
There's no mechanism inside TRIP for communicating that a particular address prefix isn't used, so those addresses could be skipped during aggregation. LSs MAY use methods outside of TRIP to learn about invalid prefixes that can be ignored during aggregation 🕵️♀️
If an LS advertises an aggregated route, it MUST include the AtomicAggregate attribute 💅
5.2.5. Route Dissemination and ReachableRoutes ✨
okay so the ReachableRoutes attribute gets recomputed at each LS, EXCEPT where flooding is being used (like inside a domain) 💅 which means an LS can literally change the Application Protocol field of a route before it advertises 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 🎀
this one is a cute little numbers puzzle 🧮 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 don't 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. BUT if an LS is aware that a prefix is an invalid Decimal Routing/E.164 prefix, or an invalid PentaDecimal Routing prefix, then the LS MAY aggregate by skipping that 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 called a "black-hole" 🕳️ how an LS knows about black-holes is not within the scope of TRIP, but if an LS does have that knowledge, it can use it 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 tells the next-hop that messages of protocol A destined for D should be sent to it 📬 this may or may not be the ultimate destination of those messages, so don't get it twisted 😭
5.3.1. NextHopServer Syntax 🌸
okay so for generality, the address of the next-hop server can be a bunch of different types (domain name, IPv4, IPv6, etc.) 🌈 the NextHopServer attribute includes the ITAD number of the next-hop server, a length field, and a next-hop name or address 🍓
the syntax is shown 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 tells you the domain of the next-hop 🗺️ the Length field gives the number of octets in the Server field, and the Server field holds the name or address of the next-hop server 💅 the Server field is a string of ASCII characters, defined like this:
Server = host [":" port ]
host = < A legal Internet host domain name
or an IPv4 address using the textual representation
defined in Section 2.1 of RFC 1123 [9]
or an IPv6 address using the textual representation
defined in Section 2.2 of RFC 2373 [10]. The IPv6
address MUST be enclosed in "[" and "]"
characters.>
port = *DIGITif the port is empty or not given, the default port is assumed (e.g., port 5060 if the application protocol is SIP) 🧚♀️
5.3.2. Route Origination and NextHopServer 🦋
when an LS originates a routing object into TRIP, it MUST include a NextHopServer within its domain 🏠 the NextHopServer could be the address of the egress gateway or of a signaling proxy 🚪
5.3.3. Route Selection and NextHopServer 💭
LS policy may prefer certain next-hops or next-hop domains over others 🎀
5.3.4. Aggregation and NextHopServer 🧩
when aggregating multiple routing objects into one routing object, an LS MUST insert a new signaling server from within its domain as the new NextHopServer, UNLESS all of the routes being aggregated have the same next-hop 🫶
5.3.5. Route Dissemination and NextHopServer 🚀
when propagating routing objects to peers, an LS may choose to insert a signaling proxy within its domain as the new next-hop, or it may leave the next-hop unchanged 🔁 inserting a new next-hop sends the signaling messages to that address and gives you finer control over the signaling path 🎯 leaving the next-hop unchanged gives you a more efficient signaling path (fewer hops) ⚡ whether to propagate or change the NextHopServer is a local policy decision of the LS 👑
5.4. AdvertisementPath 🌟
Conditional Mandatory: True (if ReachableRoutes and/or
WithdrawnRoutes attribute is present).
Required Flags: Well-known.
Potential Flags: None.
TRIP Type Code: 4.this attribute identifies the ITADs that the routing information in an advertisement has travelled through 🛣️ it's basically the BGP AS_PATH attribute's cousin 💕 the difference is that BGP's AS_PATH also reflects the path to the destination 🙃 in TRIP, not every domain has to modify the next-hop, so the AdvertisementPath can include way more hops than the actual path to the destination 😭 the RoutedPath attribute (Section 5.5) is the one that reflects the actual signaling path to the destination 🧭
5.4.1. AdvertisementPath Syntax 🎀
okay so AdvertisementPath is a variable length attribute made of a sequence of ITAD path segments 🧶 each ITAD path segment is a type-length-value triple 🍬
the path segment type is a 1-octet field with these values:
Value Segment Type
1 AP_SET: unordered set of ITADs a route in the
advertisement message has traversed
2 AP_SEQUENCE: ordered set of ITADs a route in
the advertisement message has traversedthe path segment length is a 1-octet field containing the number of ITADs in the path segment value field 🔢 the path segment value field holds one or more ITAD numbers, each encoded as a 4-octet field 💜 ITAD numbers uniquely identify an Internet Telephony Administrative Domain, and they must be obtained from IANA 🏛️ see Section 13 for how to get an ITAD number from IANA 📋
5.4.2. Route Origination and AdvertisementPath 🌸
when an LS originates a route:
- the originating LS shall include its own ITAD number in the AdvertisementPath attribute of all advertisements sent to LSs located in neighboring ITADs ✨ in this case, the ITAD number of the originating LS's ITAD is the only entry in the AdvertisementPath attribute 🦋
- the originating LS shall include an empty AdvertisementPath attribute in all advertisements sent to LSs located in its own ITAD 🏡 an empty AdvertisementPath attribute is one whose length field contains the value zero 0️⃣
5.4.3. Route Selection and AdvertisementPath 🧠
the AdvertisementPath may be used for route selection 🎯 possible criteria are the number of hops on the path and whether particular ITADs are present or absent on the path 🔍
as Section 10 explains, the AdvertisementPath is used to stop routing information from looping 🔄 if an LS receives a route with its own ITAD already in the AdvertisementPath, the route MUST be discarded 🗑️ no loops allowed, bestie 🙅♀️
5.4.4. Aggregation and AdvertisementPath 🧩
the rules for aggregating AdvertisementPath attributes are in the sections below 📖 wherever Section 5.4.4.1 and 5.4.4.2 say "path," it means AdvertisementPath 💅
5.4.4.1. Aggregating Routes with Identical Paths 🎀
if all the routes being aggregated have identical path attributes, then the aggregated route has the same path attribute as the individual routes 🫶
5.4.4.2. Aggregating Routes with Different Paths 🌈
okay this is the fun part 🤓 for aggregating path attributes, we model each ITAD within the path as a pair <type, value>, where "type" is the path segment type (AP_SEQUENCE or AP_SET) and "value" is the ITAD number 🧩 two ITADs are said to be the same if their <type, value> pairs are the same 👯
if the routes being aggregated have different path attributes, then the aggregated path attribute shall satisfy all of the following conditions:
- all pairs of the type AP_SEQUENCE in the aggregated path MUST appear in all of the paths of the routes being aggregated 💖
- all pairs of the type AP_SET in the aggregated path MUST appear in at least one of the paths of the initial set (they may appear as either AP_SET or AP_SEQUENCE types) 🫧
- for any pair X of the type AP_SEQUENCE that precedes pair Y in the aggregated path, X precedes Y in each path of the initial set that contains Y, regardless of the type of Y 🧚
- no pair with the same value shall appear more than once in the aggregated path, regardless of the pair's type 🙅♀️
an implementation can choose any algorithm that follows these rules 💅 but at a minimum, a conformant implementation MUST be able to perform this algorithm that meets all of the above conditions:
- determine the longest leading sequence of tuples (as defined above) that's common to all the paths of the routes being aggregated, and make it the leading sequence of the aggregated path 🥇
- set the type of the rest of the tuples from the paths of the routes being aggregated to AP_SET, and append them to the aggregated path 🧁
- if the aggregated path has more than one tuple with the same value (regardless of the tuple's type), eliminate all but one of them by deleting the AP_SET tuples from the aggregated path 🧹
an implementation that wants to keep a significant amount of path information in its path aggregation algorithm may wish to use the procedure in Section 5.4.4.3 🌟
5.4.4.3. Example Path Aggregation Algorithm
okay so here's an example way to squish two paths into one 🧩 ✨
- Find the ITADs (from Section 5.4.1) that show up in the same relative order in both path attributes 👯♀️ Two ITADs, X and Y, count as being in the same order if X comes before Y in both paths, or if Y comes before X in both paths. Matching order is the whole vibe 💅
- The aggregated path keeps the ITADs from step (a) in exactly the same order they show up in the paths you're aggregating. If two consecutive ITADs from (a) are not right next to each other in both paths, then the ITADs stuck between them in both attributes get bundled into an AP_SET path segment made of the in-between ITADs from both paths. That segment goes between those two consecutive ITADs from (a) in the aggregated attribute 🫶 If two consecutive ITADs from (a) are right next to each other in one attribute but not the other, then the in-between ITADs from the second attribute get bundled into an AP_SET segment too, and that segment goes between the two ITADs in the aggregated path 🎀
If, after all that, a given ITAD number shows up more than once in the aggregated path, then every instance except the last one (the rightmost occurrence) should be removed from the aggregated path 🙈 Only the rightmost one keeps its spot, bestie 👑
5.4.5. Route Dissemination and AdvertisementPath
when an LS passes along a route it learned from another LS, it shall tweak the route's AdvertisementPath attribute based on where the receiving LS lives 🦋
- when an LS advertises a route to another LS inside its own ITAD, the advertising LS MUST NOT modify the AdvertisementPath attribute associated with the route 🌸
- when an LS advertises a route to an LS in a neighboring ITAD, the advertising LS MUST update the AdvertisementPath attribute like this 💖
- if the first path segment of the AdvertisementPath is of type AP_SEQUENCE, the local system shall prepend its own ITAD number as the last element of the sequence (put it in the leftmost position) ✨
- if the first path segment of the AdvertisementPath is of type AP_SET, the local system shall prepend a new path segment of type AP_SEQUENCE to the AdvertisementPath, with its own ITAD number inside that segment 🧚
5.5. RoutedPath
Here's the little metadata card for this attribute 🗂️
Conditional Mandatory: True
(if ReachableRoutes attribute is present).
Required Flags: Well-known.
Potential Flags: None.
TRIP Type Code: 5.This attribute tells you which ITADs the messages sent using this route will pass through 🛣️ The ITADs in this path are a subset of the ones in the AdvertisementPath, so it's like a more zoomed-in version 🔍
5.5.1. RoutedPath Syntax
The RoutedPath attribute has the exact same syntax as the AdvertisementPath attribute, so just go read Section 5.4.1 and you're set 📖
5.5.2. Route Origination and RoutedPath
when an LS originates a route, it MUST include the RoutedPath attribute 🌱
- the originating LS shall include its own ITAD number in the RoutedPath attribute of all advertisements sent to LSs in neighboring ITADs 🌍 In this case, the ITAD number of the originating LS's ITAD is the only entry in the RoutedPath attribute 💅
- the originating LS shall include an empty RoutedPath attribute in all advertisements sent to LSs in its own ITAD 🏠 An empty RoutedPath attribute is one whose length field contains the value zero 🫧
5.5.3. Route Selection and RoutedPath
the RoutedPath MAY be used for route selection, and honestly in most cases it's preferred over the AdvertisementPath for this job 🏆 Some possible criteria are the number of hops on the path and whether particular ITADs are on the path or not 🔥
5.5.4. Aggregation and RoutedPath
the rules for aggregating RoutedPath attributes live in Section 5.4.4.1 and 5.4.4.2, and wherever you see "path" in those sections, just read it as RoutedPath 🧠✨
5.5.5. Route Dissemination and RoutedPath
when an LS passes along a route it learned from another LS, it updates the route's RoutedPath attribute based on where the receiving LS is 🦋
- when an LS advertises a route to another LS inside its own ITAD, the advertising LS MUST NOT modify the RoutedPath attribute associated with the route 🌸
- if the LS has not changed the NextHopServer attribute, then the LS MUST NOT change the RoutedPath attribute 🙅♀️
- otherwise, the LS changed the NextHopServer and is advertising the route to an LS in another ITAD. The advertising LS MUST update the RoutedPath attribute like this 💫
- if the first path segment of the RoutedPath is of type AP_SEQUENCE, the local system shall prepend its own ITAD number as the last element of the sequence (put it in the leftmost position) ✨
- if the first path segment of the RoutedPath is of type AP_SET, the local system shall prepend a new path segment of type AP_SEQUENCE to the RoutedPath, with its own ITAD number inside that segment 🧚
5.6. AtomicAggregate
Conditional Mandatory: False.
Required Flags: Well-known.
Potential Flags: None.
TRIP Type Code: 6.the AtomicAggregate attribute says that a route might travel through domains that aren't listed in the RoutedPath 👀 If an LS, when it's handed a set of overlapping routes from a peer LS, picks the less specific route without picking the more specific one, then the LS adds the AtomicAggregate attribute to the routing object 🎀
5.6.1. AtomicAggregate Syntax
this attribute has length zero (0), so the value field is empty 🫙
5.6.2. Route Origination and AtomicAggregate
routes are never originated with the AtomicAggregate attribute 🚫✨
5.6.3. Route Selection and AtomicAggregate
the AtomicAggregate attribute may be used in route selection. It's basically a heads-up that the RoutedPath might be incomplete 👀💅
5.6.4. Aggregation and AtomicAggregate
if any of the routes being aggregated has the AtomicAggregate attribute, then the resulting aggregate MUST have it too 🫶
5.6.5. Route Dissemination and AtomicAggregate
if an LS, when handed a set of overlapping routes from a peer LS, selects the less specific route (see Section 0) without selecting the more specific route, then the LS MUST include the AtomicAggregate attribute with the routing object (if it isn't already there) 🌈
an LS that receives a routing object carrying an AtomicAggregate attribute MUST NOT make the set of destinations more specific when advertising it to other LSs 🙅♀️ It also MUST NOT remove the attribute when passing this object along to a peer LS 🔒
5.7. LocalPreference
Conditional Mandatory: False.
Required Flags: Well-known.
Potential Flags: None.
TRIP Type Code: 7.the LocalPreference attribute is only used inside a domain 🏡 It shows how much the local LS prefers the routing object compared to other LSs in the same domain. This attribute MUST NOT be included when talking to an LS in another domain, and it MUST be included over intra-domain links 💜
5.7.1. LocalPreference Syntax
the LocalPreference attribute is a 4-octet unsigned numeric value. A higher value means a higher preference 📈
5.7.2. Route Origination and LocalPreference
routes MUST NOT be originated with the LocalPreference attribute to inter-domain peers 🚧 Routes to intra-domain peers MUST be originated with the LocalPreference attribute 💖
5.7.3. Route Selection and LocalPreference
the LocalPreference attribute lets one LS in a domain work out a preference for a route, and then share that preference with the other LSs in the same domain 🤝
5.7.4. Aggregation and LocalPreference
the LocalPreference attribute isn't affected by aggregation at all 🙌
5.7.5. Route Dissemination and LocalPreference
an LS MUST include the LocalPreference attribute when talking to peer LSs in its own domain 🏠 An LS MUST NOT include the LocalPreference attribute when talking to LSs in other domains 🚫 LocalPreference attributes received from inter-domain peers MUST be ignored 🙈
5.8. MultiExitDisc
Conditional Mandatory: False.
Required Flags: Well-known.
Potential Flags: None.
TRIP Type Code: 8.when two ITADs are connected by more than one set of peers, the MultiExitDisc attribute can be used to say which links you like better 🛤️ It lets you set preferences for routes that come in over one link versus routes that come in over the others. The MultiExitDisc parameter is only used for route selection 🎯
5.8.1. MultiExitDisc Syntax
the MultiExitDisc attribute carries a 4-octet unsigned numeric value. A higher value means a more preferred routing object 📊
5.8.2. Route Origination and MultiExitDisc
routes originated to intra-domain peers MUST NOT be originated with the MultiExitDisc attribute 🙅♀️ When originating a route to an inter-domain peer, the MultiExitDisc attribute may be included 🌟
5.8.3. Route Selection and MultiExitDisc
the MultiExitDisc attribute is how you express a preference when there are multiple links between two domains 🔗 If everything else is equal, a route with a higher MultiExitDisc attribute is preferred over one with a lower value 🥇
5.8.4. Aggregation and MultiExitDisc
routes with different MultiExitDisc parameters MUST NOT be aggregated 🚫 Routes with the same MultiExitDisc value MAY be aggregated, and that same MultiExitDisc attribute gets attached to the aggregated object 🫶
5.8.5. Route Dissemination and MultiExitDisc
if it was received from a peer LS in another domain, an LS MAY propagate the MultiExitDisc to other LSs within its domain 📣 The MultiExitDisc attribute MUST NOT be propagated to LSs in other domains 🔐
an LS may add the MultiExitDisc attribute when propagating routing objects to an LS in another domain 🌸 Whether it's included, and what value it gets, is a matter of policy 📜✨
5.9. Communities 🫧
- Conditional Mandatory: False.
- Required Flags: Not Well-Known, Independent Transitive.
- Potential Flags: None.
- TRIP Type Code: 9.
okay so a community is just a group of destinations that share some common property, bestie 🫶 think of it like a friend group but for IP addresses 💅
The Communities attribute lets you group destinations so the routing decision can be based on which group they belong to 🎀 this is lowkey the best part, because it should seriously simplify how routing info gets distributed, since you get an administratively defined aggregation unit ✨
Each ITAD administrator gets to decide which communities a particular route belongs to. And by default? All routes belong to the general Internet Telephony community 📞🌸
Here's a cute example. The Communities attribute could be used to create an alliance between a bunch of Internet Telephony service providers for a specific subset of routing info 👑 so the members of that alliance would only accept routes for destinations in this group that were advertised by other alliance members, and everything else would be accepted more freely. To make that work, a member tags each route with a designated Community attribute value before disseminating it. The best part? Members don't have to keep track of who all the other alliance members are 🥹💖
Another iconic use is with aggregation 🦋 it's often useful to advertise both the aggregate route AND the component more-specific routes that were used to form it. But those component routes are only useful to the neighboring TRIP peer (and maybe that peer's ITAD), so you want to filter them out. You do that by specifying a Community attribute value that the neighboring peers will match and filter on. That way, the more specific routes can't propagate beyond their desired scope 🙈✨
5.9.1. Syntax of Communities
The Communities attribute is variable length 🧚 it's a set of 8-octet values, and each one specifies a community. The first 4 octets are the Community ITAD Number, and the next 4 octets are the Community ID 💜
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
+---------------+---------------+--------------+----------------+
| Community ITAD Number 1 |
+---------------+---------------+--------------+----------------+
| Community ID 1 |
+---------------+---------------+--------------+----------------+
| . . . . . . . . .
+---------------+---------------+--------------+----------------+Figure 14: Communities Syntax 🍓
For administrative assignment, the following assumptions may be made:
- The Community attribute values starting with a Community ITAD Number of
0x00000000are hereby reserved 🚫
The following communities have global significance, and their operation MUST be implemented in any Community attribute-aware TRIP LS. no skipping these, bestie 🔥
NO_EXPORT(Community ITAD Number =0x00000000and Community ID =0xFFFFFF01). Any received route with a community attribute containing this value MUST NOT be advertised outside of the receiving TRIP ITAD. this one is the main character of the whole list 😭
Other community values MUST be encoded using an ITAD number in the four most significant octets. The semantics of the final four octets (the Community ID octets) may be defined by the ITAD. For example, ITAD 690 might define research, educational, and commercial community IDs that can be used for policy routing, as defined by the operators of that ITAD 🌈
5.9.2. Route Origination and Communities
The Communities attribute is not well-known 🙈 but if a route has a Communities attribute associated with it, the LS MUST include that attribute in the advertisement it originates. no dropping it 💅
5.9.3. Route Selection and Communities
The Communities attribute may be used for route selection ✨ a route that's a member of a certain community may be preferred over another route that isn't. Likewise, routes without a certain community value may be excluded from consideration. it's giving "bouncer at the club" energy 🧚
5.9.4. Aggregation and Communities
If a set of routes is going to be aggregated, and the resulting aggregate does not carry an Atomic_Aggregate attribute, then the resulting aggregate should have a Communities attribute that contains the union of the Community attributes of the aggregated routes 🎀
5.9.5. Route Dissemination and Communities
An LS may manipulate the Communities attribute before disseminating a route to a peer 🦋 that manipulation can include adding communities, removing communities, adding a Communities attribute (if none exists), deleting the Communities attribute, etc. total glow-up energy 💖
5.10. ITAD Topology 🕸️
- Conditional Mandatory: False.
- Required Flags: Well-known, Link-State encapsulated.
- Potential Flags: None.
- TRIP Type Code: 10.
okay so within an ITAD, each LS has to know the status of the other LSs so that an LS failure can be detected 😭 to do this, each LS advertises its internal topology to the other LSs in the domain. When an LS notices that another LS is no longer active, the information sourced by that LS can be deleted (the Adj-TRIB-In for that peer may be cleared). The ITAD Topology attribute is how this info gets shared with the other LSs in the domain 🫶
An LS MUST send a topology update each time it detects a change in its internal peer set. The topology update may be sent in an UPDATE message all by itself, or it may be piggybacked on an UPDATE message that includes ReachableRoutes and/or WithdrawnRoutes information 🧚
When an LS receives a topology update from an internal LS, it MUST recalculate which LSs are active within the ITAD, using a connectivity algorithm on the topology 🔥
5.10.1. ITAD Topology Syntax
The ITAD Topology attribute indicates the LSs that the LS is currently peering with. It's a list of the TRIP Identifiers the LS is currently peering with, and the format is shown in Figure 15 📋 this attribute MUST use the link-state encapsulation as defined in Section 4.3.2.4 (don't forget it, bestie 💅).
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
+---------------+---------------+--------------+----------------+
| TRIP Identifier 1 |
+---------------+---------------+--------------+----------------+
| TRIP Identifier 2 ... |
+---------------+---------------+--------------+----------------+Figure 15: ITAD Topology Syntax 🌸
5.10.2. Route Origination and ITAD Topology
The ITAD Topology attribute is independent of any routes in the UPDATE 🦋 whenever the set of internal peers of an LS changes, it MUST create an UPDATE with the ITAD Topology attribute included, listing the current set of internal peers. The LS MUST include this attribute in the first UPDATE it sends to a peer after the peering session is established. first impressions matter, periodt ✨
5.10.3. Route Selection and ITAD Topology
This attribute is independent of any routing information in the UPDATE. When an LS receives an UPDATE with an ITAD Topology attribute, it MUST compute the set of LSs that are currently active in the domain, by performing a connectivity test on the ITAD topology as given by the set of originated ITAD Topology attributes. The LS MUST locally purge the Adj-TRIB-In for any LS that is no longer active in the domain. The LS MUST NOT propagate this purging information to other LSs, because they'll all make a similar decision on their own 🧠🫧
5.10.4. Aggregation and ITAD Topology
This information is not aggregated 🙅♀️
5.10.5. Route Dissemination and ITAD Topology
An LS MUST ignore the attribute if it's received from a peer in another domain. An LS MUST NOT send this attribute to an inter-domain peer. keep this one in the family 🏠💜
5.11. ConvertedRoute 🔁
- Conditional Mandatory: False.
- Required Flags: Well-known.
- Potential Flags: None.
- TRIP Type Code: 12.
The ConvertedRoute attribute says that an intermediate LS has altered the route by changing the route's Application Protocol 🧚 for example, if an LS gets a route with Application Protocol X and changes it to Y before advertising the route to an external peer, the LS MUST include the ConvertedRoute attribute. It's the signal that the advertised application protocol won't be used end-to-end, meaning the info advertised about this route isn't complete 🙈
5.11.1. ConvertedRoute Syntax
This attribute has length zero (0). The value field is empty 🫥
5.11.2. Route Origination and ConvertedRoute
Routes are never originated with the ConvertedRoute attribute 🚫✨
5.11.3. Route Selection and ConvertedRoute
The ConvertedRoute attribute may be used in route selection. it indicates that the advertised routing info isn't complete, so it's a little bit of a red flag 🚩
5.11.4. Aggregation and ConvertedRoute
If any of the routes being aggregated has the ConvertedRoute attribute, then so MUST the resulting aggregate 🫶 no sneaking around it!
5.11.5. Route Dissemination and ConvertedRoute
If an LS changes the Application Protocol of a route before advertising it to an external peer, the LS MUST include the ConvertedRoute attribute 💖
5.12. Considerations for Defining New TRIP Attributes 🧩
Any proposal for defining new TRIP attributes should specify the following:
- the use of this attribute,
- the attribute's flags,
- the attribute's syntax,
- how the attribute works with route origination,
- how the attribute works with route aggregation, and
- how the attribute works with route dissemination and the attribute's scope (e.g., intra-domain only like
LocalPreference)
IANA will manage the assignment of TRIP attribute type codes to new attributes 🍓
6. TRIP Error Detection and Handling 🚨
This section is all about the errors to be detected and the actions to be taken while processing TRIP messages 👀
When any of the conditions described here are detected, a NOTIFICATION message with the indicated Error Code, Error Subcode, and Data fields MUST be sent, and the TRIP connection MUST be closed. If no Error Subcode is specified, then a zero Subcode MUST be used. no vibes-based error handling here 😭
The phrase "the TRIP connection is closed" means that the transport protocol connection has been closed and that all resources for that TRIP connection have been de-allocated. If the connection was inter-domain, then routing table entries associated with the remote peer MUST be marked as invalid. Routing table entries MUST NOT be marked as invalid if an internal peering session is terminated. And the fact that the routes have been marked as invalid gets passed to other TRIP peers before the routes are deleted from the system 🧚✨
Unless specified explicitly, the Data field of the NOTIFICATION message that is sent to indicate an error MUST be empty 🫧
6.1. Message Header Error Detection and Handling ✨
okay so every error found while reading the Message Header gets reported by sending a NOTIFICATION message with the Error Code Message Header Error 💅 The Error Subcode spells out the exact problem. Every LS MUST run these checks on every message it receives 🫶
If the Length field of the message header is less than 3 or greater than 4096, or if the Length field of an OPEN message is less than the minimum length of the OPEN message, or if the Length field of an UPDATE message is less than the minimum length of the UPDATE message, or if the Length field of a KEEPALIVE message is not equal to 3, or if the Length field of a NOTIFICATION message is less than the minimum length of the NOTIFICATION message, then the Error Subcode MUST be set to Bad Message Length 🙈 The Data field holds the erroneous Length field.
If the Type field of the message header is not recognized, then the Error Subcode MUST be set to "Bad Message Type." 🍓 The Data field holds the erroneous Type field.
6.2. OPEN Message Error Detection and Handling 🌸
Any errors found while processing the OPEN message get reported with a NOTIFICATION message that has the Error Code "OPEN Message Error." 🎀 The Error Subcode tells you the specifics. Every LS MUST run these checks on every OPEN message it gets, no exceptions 💖
If the version number in the Version field of the received OPEN message isn't supported, then the Error Subcode MUST be set to "Unsupported Version Number." 🦋 The Data field is a 1-octet unsigned integer. It shows the largest version number the LS supports locally, and that number has to be less than the version the remote TRIP peer bid (as shown in the received OPEN message). Main character energy for version negotiation, honestly ✨
If the ITAD field of the OPEN message is unacceptable, then the Error Subcode MUST be set to "Bad Peer ITAD." 💅 Deciding which ITAD numbers are acceptable is outside the scope of this protocol, so that's not on us 🙈
If the Hold Time field of the OPEN message is unacceptable, then the Error Subcode MUST be set to "Unacceptable Hold Time." ⭐ An implementation MUST reject Hold Time values of one or two seconds. An implementation MAY reject any proposed Hold Time. And an implementation that accepts a Hold Time MUST use the negotiated value for the Hold Time 🫶
If the TRIP Identifier field of the OPEN message isn't valid, then the Error Subcode MUST be set to "Bad TRIP Identifier." 🧚 A TRIP identifier is 4-octets long and can be any value at all. An LS treats the TRIP Identifier as invalid if it already has an open connection with a different peer LS that has the same ITAD and TRIP Identifier. Iykyk 💜
Any two LSs in the same ITAD MUST NOT have equal TRIP Identifier values. This restriction doesn't apply to LSs in different ITADs, since the whole point is to uniquely identify an LS using its TRIP Identifier and its ITAD number 🌈
If one of the Optional Parameters in the OPEN message isn't recognized, then the Error Subcode MUST be set to "Unsupported Optional Parameters." 🙈
If the Optional Parameters of the OPEN message include Capability Information with an unsupported capability (unsupported in either capability type or value), then the Error Subcode MUST be set to "Unsupported Capability," and the entirety of the unsupported capabilities MUST be listed in the Data field of the NOTIFICATION message. 😭
If the Optional Parameters of the OPEN message include Capability Information that doesn't match the receiving LS's capabilities, then the Error Subcode MUST be set to "Capability Mismatch," and the entirety of the mismatched capabilities MUST be listed in the Data field of the NOTIFICATION message. 💀
6.3. UPDATE Message Error Detection and Handling 🦋
Errors found while processing the UPDATE message get reported with a NOTIFICATION message that has the Error Code "UPDATE Message Error." ✨ The Error Subcode says what kind of error it was. Every LS MUST run these checks on every UPDATE message it receives, and these checks MUST happen before flooding procedures get invoked with internal peers 🔥
If any recognized attribute has Attribute Flags that conflict with the Attribute Type Code, then the Error Subcode MUST be set to "Attribute Flags Error." 💅 The Data field holds the erroneous attribute (type, length and value).
If any recognized attribute has an Attribute Length that conflicts with the expected length (based on the attribute type code), then the Error Subcode MUST be set to "Attribute Length Error." 🎀 The Data field holds the erroneous attribute (type, length and value).
If any of the mandatory (i.e., conditional mandatory attribute and the conditions for including it in the UPDATE message are fulfilled) well-known attributes are missing, then the Error Subcode MUST be set to "Missing Well-known Mandatory Attribute." 🙈 The Data field holds the Attribute Type Code of the missing well-known conditional mandatory attributes.
If any of the well-known attributes aren't recognized, then the Error Subcode MUST be set to "Unrecognized Well-known Attribute." 🧚 The Data field holds the unrecognized attribute (type, length and value).
If any attribute has a syntactically incorrect value, or an undefined value, then the Error Subcode is set to "Invalid Attribute." 🌸 The Data field holds the incorrect attribute (type, length and value). For example, a NOTIFICATION message like this gets sent when a NextHopServer attribute comes in with an invalid address 🍓
The information in the AdvertisementPath attribute gets checked for ITAD loops ♻️ That works by scanning the full AdvertisementPath and checking that the local ITAD number doesn't show up in it. If the local ITAD number does appear in the AdvertisementPath, then the route MAY be stored in the Adj-TRIB-In. However, unless the LS is configured to accept routes with its own ITAD in the advertisement path, the route MUST not be passed to the TRIP Decision Process 🚫 How an LS that's set up to accept routes with its own ITAD number in the advertisement path behaves is outside the scope of this document, so we're leaving that one alone 🫶
If the UPDATE message came from an internal peer and either the WithdrawnRoutes, ReachableRoutes, or ITAD Topology attribute doesn't have the Link-State Encapsulation flag set, then the Error Subcode is set to "Invalid Attribute" and the Data field contains the attribute. Likewise, the attribute is invalid if it's received from an external peer and the Link-State Flag is set 💜
If any attribute shows up more than once in the UPDATE message, then the Error Subcode is set to "Malformed Attribute List." 💀
6.4. NOTIFICATION Message Error Detection and Handling 🙈
Okay, this one is a little sad 😭 If a peer sends a NOTIFICATION message and there's an error in that message, there's unfortunately no way to report that error with another NOTIFICATION message. Any error like that, such as an unrecognized Error Code or Error Subcode, should be noticed, logged locally, and brought to the attention of the administration of the peer. How to actually do that is outside the scope of this document 🌈
6.5. Hold Timer Expired Error Handling ⏰
If a system doesn't receive successive messages within the period set by the negotiated Hold Time, then a NOTIFICATION message with a "Hold Timer Expired" Error Code MUST be sent, and the TRIP connection MUST be closed. Bye bye connection 👋
6.6. Finite State Machine Error Handling 🧠
An error detected by the TRIP Finite State Machine (for example, getting an unexpected event) MUST result in a NOTIFICATION message with the Error Code "Finite State Machine Error" being sent, and the TRIP connection MUST be closed 🔥 Not vibing with the state machine at all, periodt 💅
6.7. Cease 🍃
As long as there aren't any fatal errors (the ones this section lists), a TRIP peer MAY choose at any time to close its TRIP connection by sending a NOTIFICATION message with the Error Code "Cease." ✨ But the Cease NOTIFICATION message MUST NOT be used when a fatal error from this section exists. No Cease-ing when something's actually broken, bestie 🙅♀️
6.8. Connection Collision Detection 💥
If a pair of LSs try to set up a transport connection to each other at the same time, two parallel connections between that pair of speakers might end up getting formed. We call this a connection collision 😳 Clearly, one of those connections must be closed.
There's a convention, based on the value of the TRIP Identifier, for figuring out which TRIP connection to keep when a collision happens 🦋 The rule is to compare the TRIP Identifiers of the peers involved and keep only the connection started by the LS with the higher-valued TRIP Identifier. Simple but iconic 👑
When an OPEN message comes in, the local LS MUST look at all of its connections that are in the OpenConfirm state. An LS MAY also look at connections in an OpenSent state if it knows the peer's TRIP Identifier through some means outside the protocol. If one of those connections goes to a remote LS whose TRIP Identifier equals the one in the OPEN message, then the local LS MUST run this collision resolution procedure 🎀
The TRIP Identifier and ITAD of the local LS get compared to the TRIP Identifier and ITAD of the remote LS (as specified in the OPEN message). TRIP Identifiers are treated as 4-octet unsigned integers for comparison 🔢
If the value of the local TRIP Identifier is less than the remote one, or if the two TRIP Identifiers are equal and the value of the local LS's ITAD is less than the value of the remote LS's ITAD, then the local LS MUST close the TRIP connection that already exists (the one already in the OpenConfirm state), and accept the TRIP connection the remote LS started:
- Otherwise, the local LS closes the newly created TRIP connection and keeps using the existing one (the one already in the OpenConfirm state).
- If a connection collision happens with an existing TRIP connection that's in the Established state, then the LS MUST unconditionally close off the newly created connection. Note that a connection collision can't be detected with connections in Idle, Connect, or Active states 🙈
- To close the TRIP connection (the one from the collision resolution procedure), an LS MUST send a NOTIFICATION message with the Error Code "Cease," and the TRIP connection MUST be closed 💜
7. TRIP Version Negotiation 🌈
Peer LSs may negotiate the protocol version by making multiple attempts to open a TRIP connection, starting with the highest version number each one supports 🪜 If an open attempt fails with the Error Code "OPEN Message Error" and the Error Subcode "Unsupported Version Number," then the LS has the version number it tried, the version number its peer tried, the version number the peer sent in the NOTIFICATION message, and the version numbers it supports itself 🧩 If the two peers support one or more common versions, this lets them figure out the highest common version super fast ⚡
To make TRIP version negotiation work, future versions of TRIP must keep the format of the OPEN and NOTIFICATION messages. That's the glue holding it all together 🫶
8. TRIP Capability Negotiation 💅
Okay so an LS MAY include the Capabilities Option in its OPEN message to a peer to show off which capabilities it supports 💖. And here's the important bit: an LS that receives an OPEN message MUST NOT use any capabilities that weren't in the peer's OPEN message when it's talking to that peer. No sneaking in features, bestie 🙈
9. TRIP Finite State Machine 🦋
This section explains TRIP operation as a Finite State Machine (FSM) ✨. Here's a quick recap of what TRIP does in each state, as decided by this FSM. A condensed version lives in Appendix 1. There's one TRIP FSM per peer, and they all run independently, like separate group chats 💅
Idle state
Initially TRIP is in the Idle state for each peer. In this state TRIP refuses all incoming connections 🙅♀️, and no resources get allocated to the peer. When the Start event shows up (from the system or the operator), the local system initializes all TRIP resources, starts the ConnectRetry timer, kicks off a transport connection to the peer, starts listening for a connection the remote TRIP peer might start, and moves to Connect. The exact value of the ConnectRetry timer is a local matter, but it should be big enough to give TCP time to initialize 🌸
If an LS detects an error, it closes the transport connection and goes back to Idle. Leaving Idle requires the Start event to be generated. If that event gets generated automatically, persistent TRIP errors can lead to persistent flapping of the LS 😭. To avoid that mess, Start events MUST NOT be generated immediately for a peer that was sent to Idle because of an error. For a peer that was sent to Idle because of an error, the time between consecutive automatic Start events MUST exponentially increase, if they're generated automatically at all. The initial timer value SHOULD be 60 seconds, and the time SHOULD be at least doubled for each consecutive retry, up to some maximum value 🔥
Any other event received in the Idle state gets ignored 🫶
Connect state
In this state an LS is waiting for a transport protocol connection to finish with the peer, and it's listening for inbound transport connections from the peer 👀
If the transport protocol connection succeeds, the local LS clears the ConnectRetry timer, finishes initialization, sends an OPEN message to its peer, sets its Hold Timer to a large value, and moves to OpenSent. A Hold Timer value of 4 minutes is suggested ⭐
If the transport protocol connect fails (for example, a retransmission timeout), the local system restarts the ConnectRetry timer, keeps listening for a connection the remote LS might start, and moves to the Active state 🌈
When the ConnectRetry timer expires, the local LS cancels any outstanding transport connection to the peer, restarts the ConnectRetry timer, starts a transport connection to the remote LS, keeps listening for a connection the remote LS might start, and stays in the Connect state 🔁
If the local LS notices that a remote peer is trying to connect and its IP address isn't one of the expected ones, the local LS rejects that attempt and keeps listening for connections from its expected peers without changing state 🚫
If an inbound transport protocol connection succeeds, the local LS clears the ConnectRetry timer, finishes initialization, sends an OPEN message to its peer, sets its Hold Timer to a large value, and moves to OpenSent. A Hold Timer value of 4 minutes is suggested 💖
The Start event is ignored in the Connect state 🙄
For any other event (from the system or the operator), the local system releases all TRIP resources tied to this connection and moves to Idle 🧹
Active state
In this state an LS is listening for an inbound connection from the peer, but it isn't in the middle of starting a connection to the peer 👂
If an inbound transport protocol connection succeeds, the local LS clears the ConnectRetry timer, finishes initialization, sends an OPEN message to its peer, sets its Hold Timer to a large value, and moves to OpenSent. A Hold Timer value of 4 minutes is suggested 🎀
When the ConnectRetry timer expires, the local system restarts the ConnectRetry timer, starts a transport connection to the TRIP peer, keeps listening for a connection the remote TRIP peer might start, and moves to Connect 🔄
If the local LS notices that a remote peer is trying to connect and its IP address isn't one of the expected ones, the local LS rejects that attempt and keeps listening for connections from its expected peers without changing state 🚫
The Start event is ignored in the Active state 🙃
For any other event (from the system or the operator), the local system releases all TRIP resources tied to this connection and moves to Idle 🧹
OpenSent state
In this state an LS has sent an OPEN message to its peer and is waiting for an OPEN message back. When an OPEN message comes in, every field gets checked for correctness 🔍. If the TRIP message header checking or the OPEN message checking detects an error (see Section 6.2), or there's a connection collision (see Section 6.8), the local system sends a NOTIFICATION message and moves to Idle 💀
If there are no errors in the OPEN message, TRIP sends a KEEPALIVE message and sets a KeepAlive timer ✨. The Hold Timer, which was originally set to a large value (see above), gets replaced with the negotiated Hold Time value (see Section 4.2). If the negotiated Hold Time value is zero, then the Hold Time timer and the KeepAlive timers don't get started. If the ITAD field's value matches the local ITAD number, the connection is an "internal" connection. Otherwise it's "external", and that affects UPDATE processing 🧐. Finally, the state changes to OpenConfirm 💅
If the local LS notices that a remote peer is trying to connect and its IP address isn't one of the expected ones, the local LS rejects that attempt and keeps listening for connections from its expected peers without changing state 🚫
If a disconnect notification comes in from the underlying transport protocol, the local LS closes the transport connection, restarts the ConnectRetry timer, keeps listening for a connection the remote TRIP peer might start, and goes into the Active state 🌸
If the Hold Timer expires, the local LS sends a NOTIFICATION message with the Error Code "Hold Timer Expired" and moves to Idle ⏰
In response to the Stop event (from the system or the operator), the local LS sends a NOTIFICATION message with the Error Code "Cease" and moves to Idle 🛑
The Start event is ignored in the OpenSent state 🙅♀️
For any other event, the local LS sends a NOTIFICATION message with the Error Code "Finite State Machine Error" and moves to Idle 😭
Whenever TRIP changes its state from OpenSent to Idle, it closes the transport connection and releases all resources tied to that connection 🧹
OpenConfirm state
In this state an LS has sent an OPEN to its peer, received an OPEN from its peer, and sent a KEEPALIVE in response to that OPEN. The LS is now waiting for a KEEPALIVE or NOTIFICATION message in reply to its OPEN 🥹
If the local LS receives a KEEPALIVE message, it moves to Established 🎉
If the Hold Timer expires before a KEEPALIVE message arrives, the local LS sends a NOTIFICATION message with the Error Code "Hold Timer Expired" and moves to Idle ⏰
If the local LS receives a NOTIFICATION message, it moves to Idle 💔
If the KeepAlive timer expires, the local LS sends a KEEPALIVE message and restarts its KeepAlive timer 💓
If a disconnect notification comes in from the underlying transport protocol, the local LS closes the transport connection, restarts the ConnectRetry timer, keeps listening for a connection the remote TRIP peer might start, and goes into the Active state 🌸
In response to the Stop event (from the system or the operator), the local LS sends a NOTIFICATION message with the Error Code "Cease" and moves to Idle 🛑
The Start event is ignored in the OpenConfirm state 🙃
For any other event, the local LS sends a NOTIFICATION message with the Error Code "Finite State Machine Error" and moves to Idle 😭
Whenever TRIP changes its state from OpenConfirm to Idle, it closes the transport connection and releases all resources tied to that connection 🧹
Established state
In the Established state, an LS can exchange UPDATE, NOTIFICATION, and KEEPALIVE messages with its peer 🤝
If the negotiated Hold Timer is zero, then no procedures are needed to keep the peering session alive. If the negotiated Hold Time value is non-zero, the procedures in this paragraph apply. If the Hold Timer expires, the local LS sends a NOTIFICATION message with the Error Code "Hold Timer Expired" and moves to Idle ⏰. If the KeepAlive Timer expires, the local LS sends a KEEPALIVE message and restarts the KeepAlive Timer 💓. If the local LS receives an UPDATE or KEEPALIVE message, it restarts its Hold Timer. Each time the LS sends an UPDATE or KEEPALIVE message, it restarts its KeepAlive Timer 🔁
If the local LS receives a NOTIFICATION message, it moves to Idle 💔
If the local LS receives an UPDATE message and the UPDATE message error handling procedure (see Section 6.3) detects an error, the local LS sends a NOTIFICATION message and moves to Idle 🚨
If a disconnect notification comes in from the underlying transport protocol, the local LS moves to Idle 👋
In response to the Stop event (from the system or the operator), the local LS sends a NOTIFICATION message with the Error Code "Cease" and moves to Idle 🛑
The Start event is ignored in the Established state 🙃
For any other event, the local LS sends a NOTIFICATION message with the Error Code "Finite State Machine Error" and moves to Idle 😭
Whenever TRIP changes its state from Established to Idle, it closes the transport connection and releases all resources tied to that connection. On top of that, if the peer is an external peer, the LS deletes all routes derived from that connection 🧹👑
10. UPDATE Message Handling ✨
okay so an UPDATE message may be received only in the Established state 💅 when one shows up, every field gets checked for validity, as spelled out in Section 6.3. the rest of this section assumes the UPDATE message already passed those error-checking steps 🫶
if the UPDATE message came from an internal peer, the flooding procedures of Section 10.1 MUST be applied 🔥 flooding is what keeps the Loc-TRIBs of all LSs in the domain in sync. some routes inside the UPDATE might get marked as old or duplicates by flooding, and those get ignored for the rest of the UPDATE processing 🙈
if the UPDATE message has withdrawn routes, the matching routes that were advertised before get removed from the Adj-TRIB-In. this LS MUST rerun its Decision Process, because that old route isn't available anymore 💀
if the UPDATE message has a route, the route MUST be put in the right Adj-TRIB-In, and then these extra steps MUST happen too 🎀
- if its destinations match those of a route already stored in the Adj-TRIB-In, the new route MUST replace the older one in the Adj-TRIB-In, which means the older route is implicitly withdrawn from service. the LS MUST rerun its Decision Process because the older route can't be used anymore 🦋
- if the new route is more specific than an earlier route in the Adj-TRIB-In and has identical attributes, no further actions are necessary ✨
- if the new route is more specific than an earlier route in the Adj-TRIB-In but its attributes are not identical, the LS MUST run its Decision Process, since the more specific route has implicitly made part of the less specific route unavailable for use 🌸
- if the new route has destinations that aren't in any route currently stored in the Adj-TRIB-In, the LS MUST run its Decision Process 🧚
- if the new route is less specific than an earlier route in the Adj-TRIB-In, the LS MUST run its Decision Process on the set of destinations that are described only by the less specific route 💜
10.1. Flooding Process
when an LS gets an UPDATE message from an internal peer, it floods the new info from that message to all of its other internal peers 🌈 flooding is how all the LSs in a domain get synced up efficiently, and it doesn't put any constraints on the domain's internal topology. it's based on the techniques used in OSPF [4] and SCSP [6]. one could argue that TRIP's flooding is really a controlled broadcast mechanism 🫶
10.1.1. Database Information
the LS MUST maintain the sequence number and originating TRIP identifier for each link-state encapsulated attribute in an internal Adj-TRIB-In 📝 these values are included with the route in the ReachableRoutes, WithdrawnRoutes, and ITAD Topology attributes. the originating TRIP identifier tells you which internal LS originated this route into the ITAD, and the sequence number tells you which version of the route that originating LS has 🍓
10.1.2. Determining Newness
for each route in the ReachableRoutes or WithdrawnRoutes field, the LS decides whether the route is new or old 👀 it does this by comparing the Sequence Number of the route in the UPDATE with the Sequence Number saved for that route in the Adj-TRIB-In. the route is new if it doesn't exist in the Adj-TRIB-In for the originating LS, or if it does exist but the Sequence Number in the UPDATE is greater than the one saved in the Adj-TRIBs-In. the newness test is applied separately to each link-state encapsulated attribute in the UPDATE (WithdrawnRoutes or ReachableRoutes or ITAD Topology) 🎀
10.1.3. Flooding
each route in the ReachableRoutes or WithdrawnRoutes field that's determined to be old gets ignored in further processing 🙈 if it's new, these actions happen.
if the route is being withdrawn, the LS MUST flood the withdrawn route to all other internal peers, and MUST mark the route as withdrawn 🥀 an LS MUST keep withdrawn routes in its databases for MaxPurgeTime seconds.
if the route is being updated, the LS MUST update the route in the Adj-TRIB-In and MUST flood it to all other internal peers 🔥
if these procedures change the Adj-TRIB-In, the route also gets made available for local route processing, as described earlier in Section 10 ✨
to implement flooding, the following is recommended. all routes received in a single UPDATE message that are determined to be new should be forwarded to all other internal peers in a single UPDATE message 💅 other variations of flooding are possible, but the local LS MUST make sure that each new route (and any associated attributes) it receives from an internal peer gets forwarded to every other internal peer 🫶
10.1.4. Sequence Number Considerations
the Sequence Number is how you tell when one version of a route is newer than another 👑 a larger Sequence Number means a newer version. it gets assigned by the LS that originates the route into the local ITAD. the Sequence Number is an unsigned 4-octet integer in the range of 1 thru 2^31-1 MinSequenceNum thru MaxSequenceNum). the value 0 is reserved 🚫
when an LS first originates a route into its ITAD (including when the LS restarts or reboots), it MUST originate it with a Sequence Number of MinSequenceNum 🌸 every time the originator updates the route within the ITAD, the Sequence Number MUST be increased 📈
if the sequence number ever gets to MaxSequenceNum-1 and it needs to go up, then the TRIP module of the LS MUST be disabled for a period of TripDisableTime. that way, all the routes this LS originated with high sequence numbers can be removed 😭
10.1.5. Purging a Route Within the ITAD
to withdraw a route it originated within the ITAD, an LS puts the route in the WithdrawnRoutes field of an UPDATE message 🗑️ the Sequence Number MUST be greater than the last valid version of the route. the LS MAY choose to use a sequence number of MaxSequenceNum when withdrawing routes within its ITAD, but it isn't required to 🦋
after withdrawing a route, an LS MUST mark it as "withdrawn" in its database, and keep the withdrawn route in that database for MaxPurgeTime seconds 🫠 if the LS needs to re-originate a route that was purged but is still in its database, it can either re-originate it right away using a Sequence Number greater than the one used in the withdraw, or it can wait until MaxPurgeTime seconds have passed since the route was withdrawn ⏳
10.1.6. Receiving Self-Originated Routes
it's super common for an LS to get UPDATEs for routes it originated within the ITAD through the flooding procedure 🔁 if the LS gets an UPDATE for a route it originated that is newer (has a higher sequence number) than the LS's current version, special actions have to be taken 🚨 this should be pretty rare, and it means a route still exists in the ITAD since the LS last restarted or rebooted 👀
if an LS gets a self-originated route update that's newer than its current version of the route, these actions MUST be taken. if the LS still wants to advertise the info in the route, it MUST increase the Sequence Number of the route to a value greater than the one received in the UPDATE and re-originate the route 🔄 if the LS doesn't want to keep advertising the route, it MUST purge the route as described in Section 10.1.5 🧹
10.1.7. Removing Withdrawn Routes
an LS SHOULD make sure routes marked as withdrawn get removed from the database in a timely way once MaxPurgeTime has expired ⏰ one example of how to do that is sweeping the database every so often and deleting the entries that were withdrawn more than MaxPurgeTime seconds ago 🧽
10.2. Decision Process
the Decision Process picks routes for later advertisement by applying the policies in the local Policy Information Base (PIB) to the routes stored in its Adj-TRIBs-In 🧠 the output is the set of routes that will be advertised to all peers, and the selected routes get stored in the local LS's Adj-TRIBs-Out 💖
the selection process is formalized by defining a function. it takes the attributes of a given route as an argument and returns a non-negative integer that shows the degree of preference for that route 📊 the function that works out the degree of preference for a route shall not use any of the following as inputs: whether other routes exist, whether other routes don't exist, or the attributes of other routes 🙅♀️ route selection then means applying the degree of preference function to each feasible route one by one, and then picking the one with the highest degree of preference 🏆
all internal LSs in an ITAD MUST run the Decision Process and apply the same decision criteria, or else it won't be possible to synchronize their Loc-TRIBs 🫶
the Decision Process works on routes in each Adj-TRIBs-In, and it's responsible for:
- selecting routes to advertise to internal peers
- selecting routes to advertise to external peers
- route aggregation and route information reduction
the Decision Process happens in three distinct phases, each kicked off by a different event 🎬
- Phase 1 works out the degree of preference for each route received from an external peer.
- Phase 2 gets invoked when Phase 1 is done. It picks the best route out of all the available ones for each distinct destination, and installs each chosen route into the Loc-TRIB.
- Phase 3 gets invoked after the Loc-TRIB has been changed. It's responsible for sharing the routes in the Loc-TRIB with each external peer, following the policies in the PIB. route aggregation and information reduction can optionally be done in this phase 🌈
10.2.1. Phase 1: Calculation of Degree of Preference ✨
okay so the Phase 1 decision function gets invoked whenever the local LS hears from a peer through an UPDATE message that advertises a new route, a replacement route, or a withdrawn route 💅
it's its own separate process, and it's totally finished once it has no more work to do 🧚
it shall lock an Adj-TRIB-In before touching any route inside it, and it shall unlock that Adj-TRIB-In after it's done with all the new or replacement routes in there 🔒
now the big one 🔥 the local LS MUST determine a degree of preference for each newly received or replacement route. if the route was learned from an internal peer, the value of the LocalPreference attribute MUST be taken as the degree of preference. if the route was learned from an external peer, the degree of preference MUST be computed from pre-configured policy information, and then it gets used as the LocalPreference value in any intra-domain TRIP advertisement. how that policy info works and how the computation goes is a local matter, so each LS handles it its own way 🦋
the output of this process is the local preference of a route. the local LS computes that for routes learned from external peers or originated internally at that LS. for a route learned from an internal peer, the local preference lives in that route's LocalPreference attribute 💖
10.2.2. Phase 2: Route Selection 👑
the Phase 2 decision function shall be invoked once Phase 1 is done 🎀 it's a separate process too, and it finishes when there's no more work left. Phase 2 has two sub-phases, 2a and 2b. they use the same route selection function, but the inputs are different for each one 🌸
in Phase 2a, the process MUST consider as inputs all external routes sitting in the Adj-TRIBs-In of external peers, plus all local routes. whatever comes out of Phase 2a goes into the Ext-TRIB. Phase 2b gets invoked as soon as 2a wraps up, and it MUST consider as inputs all routes in the Ext-TRIB plus all routes in the Adj-TRIBs-In of internal LSs. the output of 2b gets stored in the Loc-TRIB 📦
the Phase 2 decision function MUST be blocked from running while Phase 3 is in process 🚫 it MUST lock all the Adj-TRIBs-In and the Ext-TRIB before it starts, and it MUST unlock them when it's done 🔐
if the LS decides that the NextHopServer listed in a route is unreachable, then that route MAY be excluded from the Phase 2 decision function. how the LS makes that call is not mandated here 🙈
for each set of destinations that has one or more routes, the local LS's route selection function MUST identify the route that either:
- has the highest degree of preference, or
- gets selected because of the tie breaking rules in 10.2.2.1
withdrawn routes MUST be removed from the Loc-TRIB, the Ext-TRIB, and the Adj-TRIBs-In 🗑️
10.2.2.1. Breaking Ties (Phase 2) 🎲
several routes to the same destination can have the same degree of preference and get fed into the Phase 2 route selection function. the local LS can only pick one of them for the associated Ext-TRIB (Phase 2a) or Loc-TRIB (Phase 2b). it looks at all the routes with the same degree of preference, and then this algorithm shall be used to break the tie 🧠
- if the local LS is set up to use the
MultiExitDiscattribute to break ties, and the candidate routes came from the same neighboring ITAD but have differentMultiExitDiscvalues, then pick the route with the largerMultiExitDiscvalue. - if at least one of the routes was originated by an internal LS, pick the route advertised by the internal LS with the lowest TRIP ID.
- otherwise, pick the route advertised by the neighbor domain with the lowest ITAD number.
10.2.3. Phase 3: Route Dissemination 📣
the Phase 3 decision function MUST be invoked once Phase 2 is done, but only if Phase 2 changed the Loc-TRIB or when a brand new LS-to-LS peer session comes up 🌈
the Phase 3 function is separate, and it's complete when it has no more work to do. the Phase 3 routing decision function MUST be blocked from running while the Phase 2 decision function is still going 🙅
every route in the Loc-TRIB shall be processed into a matching entry in the associated Adj-TRIBs-Out. route aggregation and information reduction techniques (see 10.3.4) MAY optionally be applied too ✨
once the Adj-TRIBs-Out are fully updated, the local LS MUST run the external update process from 10.3.2 🚀
10.2.4. Overlapping Routes 🪞
when overlapping routes show up in the same Adj-TRIB-In, the more specific route takes precedence. the order goes from most specific to least specific 💅
the part of the less specific route that the overlap covers is feasible, but it isn't being used right now. if the more specific route gets withdrawn later, those destinations are still reachable through the less specific route 🛣️
if an LS receives overlapping routes, the Decision Process MUST take into account what those overlapping routes actually mean. the big worry is this: if an LS accepts the less specific route but rejects the more specific route from the same peer, the destinations in the overlap may not forward along the domains listed in that route's AdvertisementPath attribute. so an LS has these options 👇
- Install both the less and the more specific routes.
- Install the more specific route only.
- Install only the non-overlapping part of the less specific route (which means disaggregating the less-specific route).
- Aggregate the two routes and install the aggregated route.
- Install the less specific route only.
- Install neither route.
if an LS picks option 5, then it SHOULD add the AtomicAggregate attribute to the route 🏷️ a route carrying AtomicAggregate MUST NOT be de-aggregated, which means it can't be made more specific. forwarding along a route like that doesn't guarantee that the traffic only crosses the domains listed in the route's RoutedPath 😬 and if an LS picks option 1, then it MUST NOT advertise the less specific route without the more specific route too 🚫
10.3. Update-Send Process 📮
the Update-Send process is in charge of advertising UPDATE messages to all peers 💌 for example, it spreads the routes the Decision Process picked out to other LSs, whether they're in the same ITAD or a neighboring one. the rules for exchanging info with peer LSs in different ITADs are in 10.3.2, and the rules for peers in the same ITAD are in 10.3.1 🫶
before forwarding routes to peers, an LS MUST figure out which attributes should go along with that route 🧐 if a not well-known non-transitive attribute is unrecognized, it's quietly ignored. if a not well-known dependent-transitive attribute is unrecognized and the LS has changed the NextHopServer attribute, the unrecognized attribute is quietly ignored too. but if a not well-known dependent-transitive attribute is unrecognized and the LS has not modified the NextHopServer attribute, the Partial bit in the attribute flags octet is set to 1, and the attribute is kept so it can be passed on to other TRIP speakers 📦 similarly, if a not well-known independent-transitive attribute is unrecognized, the Partial bit gets set to 1 and the attribute is kept for propagation too 🌸
if a not well-known attribute is recognized and has a valid value, then, depending on what type of attribute it is, it gets updated if necessary so it can be propagated to other TRIP speakers ✨
10.3.1. Internal Updates 🏠
the Internal update process is all about sending routing info out to internal peers 🏡
when an LS gets an UPDATE message from another TRIP LS in its own ITAD, it gets flooded as described in Section 10.1 🌊
when an LS gets a new route from an LS in a neighboring ITAD, or when a local route gets injected into TRIP, the LS works out the preference of that route 🧮 if the new route has the highest degree of preference among all external and local routes to a given destination (or if it was picked through the tie-breaking procedure in 10.3.1.1), the LS MUST insert that new route into the Ext-TRIB database. the LS MUST also advertise that route to all other LSs in its ITAD using an UPDATE message 📢 and the LS MUST advertise itself as the Originator of that route within the ITAD 👑
when an LS gets an UPDATE message with a non-empty WithdrawnRoutes attribute from an external peer, or when a local route gets withdrawn from TRIP, the LS MUST remove all routes from its Adj-TRIB-In whose destinations were listed in that field 💔 if the withdrawn route had been selected into the Ext-TRIB, the LS MUST take these extra steps:
- if a new route gets selected for advertising to those destinations, then the LS MUST insert that replacement route into the Ext-TRIB to replace the withdrawn one, and advertise it to all internal LSs 🔁
- if there's no replacement route available to advertise, then the LS MUST put the destinations of the route into the
WithdrawnRoutesattribute of an UPDATE message, and MUST send that message to each internal peer. the LS MUST also remove the withdrawn route from the Ext-TRIB 🧹
10.3.1.1. Breaking Ties (Routes Received from External Peers) ⚖️
if an LS has connections to several external peers, there will be multiple Adj-TRIBs-In tied to those peers 🔗 those databases might hold several equally good routes to the same destination, and every one of them came from an external peer. the local LS shall pick one of these routes using these rules:
- if the LS is set up to use the
MultiExitDiscattribute to break ties, and the candidate routes differ in theirMultiExitDiscvalues, then pick the route with the lowestMultiExitDiscvalue. otherwise, - pick the route advertised by the external LS with the lowest TRIP Identifier.
10.3.2. External Updates 🌍
the external update process handles sending routing info out to external peers 📤 as part of the Phase 3 route selection process, the LS has updated its Adj-TRIBs-Out. every newly installed route and every newly unfeasible route that has no replacement route MUST be advertised to external peers using UPDATE messages 💌
any routes in the Loc-TRIB marked as withdrawn MUST be removed 🧽 and changes to the reachable destinations within its own ITAD SHALL also be advertised in an UPDATE message 📣
10.3.3. Controlling Routing Traffic Overhead 🚦
TRIP keeps the amount of routing traffic (in other words, UPDATE messages) in check 🙌 that protects two things: the link bandwidth needed to advertise UPDATE messages, and the processing power the Decision Process needs to digest the info inside them 🧠💪
10.3.3.1. Frequency of Route Advertisement ⏱️
okay so the MinRouteAdvertisementInterval is the minimum amount of time that has to pass between advertising routes to a particular destination from one LS. it's rate limited per destination, but the actual value gets set per LS peer, which is kind of iconic 💅
Two UPDATE messages sent from a single LS that advertise feasible routes to some common set of destinations received from external peers MUST be separated by at least MinRouteAdvertisementInterval. bestie, the only way to get that perfectly is to keep a separate timer for every common set of destinations, and that's way too much overhead 😭 so instead you just need any technique that makes sure the gap between those two UPDATEs is at least MinRouteAdvertisementInterval, and that also keeps a constant upper bound on the gap. that's the vibe ✨
Two UPDATE messages, sent from a single LS to an external peer, that advertise feasible routes to some common set of destinations received from internal peers MUST be separated by at least MinRouteAdvertisementInterval. same energy, different group 🫶
Fast convergence is non-negotiable inside an ITAD 🔥 so this rate limiting does NOT apply to routes received from internal peers that are being passed along to other internal peers. and to avoid long-lived black holes 🕳️, it also doesn't apply to explicit withdrawals (aka routes whose destinations got explicitly withdrawn by UPDATE messages). withdrawals go out right away, no waiting, periodt 💀
this procedure doesn't limit how often routes get selected, only how often they get advertised 🦋 if new routes keep getting selected while the timer is still running, the last one selected shall be advertised at the end of MinRouteAdvertisementInterval. so the final choice is the one that actually gets sent, iykyk 🌸
10.3.3.2. Frequency of Route Origination 🌈
the MinITADOriginationInterval is the minimum amount of time that has to elapse between successive advertisements of UPDATE messages that report changes inside the advertising LS's own ITAD. it's giving "pace yourself" energy 🧚
10.3.3.3. Jitter 🎀
okay so picture a bunch of LSs all sending TRIP messages at the exact same moment. that's a peak, and nobody wants a peak 🙈 to reduce the odds of that, jitter should be applied to the timers for MinITADOriginationInterval, KeepAlive, and MinRouteAdvertisementInterval. a given LS shall apply the same jitter to all of these no matter which destinations the updates are going to. so jitter does NOT get applied "per peer." keep it consistent, bestie 💜
the jitter amount is the base value of the timer multiplied by a random factor that's uniformly distributed in the range from 0.75 to 1.0. so it's always a little shorter, never longer, and it's randomized every time ✨
10.3.4. Efficient Organization of Routing Information 🍓
once a TRIP speaker has picked the routing information it's going to advertise, it can use some methods to organize that info more efficiently. the next few sections cover those methods, so let's get into it 💖
10.3.4.1. Information Reduction 🧩
real talk, information reduction can mean less granular policy control. once info has collapsed, the same policies apply to every destination and path in that equivalence class. just know the tradeoff going in 👀
the Decision Process may optionally reduce how much information it places in the Adj-TRIBs-Out using any of the following methods:
ReachableRoutes: a set of destinations can usually be represented in a compact form. for example, a set of E.164 phone numbers can be squished down into more compact E.164 prefixes 📞AdvertisementPath: AdvertisementPath info can be represented as ordered AP_SEQUENCEs or unordered AP_SETs. AP_SETs get used in the route aggregation algorithm described in Section 5.4.4. they shrink the AP_PATH info by listing each ITAD number only once, no matter how many times it showed up in the advertisement paths that got aggregated 🪄
an AP_SET means the destinations in that UPDATE can be reached through paths that go through at least some of the constituent ITADs. AP_SETs still give enough info to avoid route looping ✅ but they might prune paths that could have been feasible, since those paths aren't listed one by one like they would be in AP_SEQUENCEs. honestly, in practice this usually isn't a problem 💅 once a call reaches the edge of a group of ITADs, the LS sitting there probably has more detailed path info and can tell the individual paths to destinations apart
10.3.4.2. Aggregating Routing Information 🫧
aggregation is when you combine the characteristics of several different routes so a single route can be advertised instead 🎁 it can happen as part of the decision process to cut down on the amount of routing info that goes into the Adj-TRIBs-Out.
the whole point is that aggregation shrinks the amount of info an LS has to store and swap with other LSs 🙌 routes can get aggregated by running the following procedure separately on attributes of the same type.
routes that have the following attributes shall NOT be aggregated unless the matching attributes on each route are identical: MultiExitDisc, NextHopServer. (heads up, that one's a MUST NOT vibe for the attributes, lowercase shall stays lowercase, the caps are the rules that matter 🙈)
attributes with different type codes can't be aggregated 🚫 attributes that share a type code may be aggregated. the rules for aggregating each attribute MUST be provided together with the attribute definition. for example, the aggregation rules for TRIP's basic attributes, like ReachableRoutes and AdvertisementPath, are given in Section 5 ✨
10.4. Route Selection Criteria ⚖️
okay real quick, extra rules for comparing routes against each other are generally outside the scope of this document 🙃 there are two exceptions though, and they're important:
- if the local ITAD shows up in the AdvertisementPath of the new route being considered, then that new route cannot be viewed as better than any other route. if it ever got used, a routing loop could result 😱 (see Section 6.3)
- for distributed operation to work, only routes with a likelihood of stability can be chosen. so an ITAD must avoid unstable routes, and it must not make rapid spontaneous changes to its choice of route 🫠 quantifying "unstable" and "rapid" will take some experience, but the principle is crystal clear 💎
10.5. Originating TRIP Routes 🛰️
an LS can originate local routes by injecting routing info it got some other way (for example, from an intra-domain routing protocol, manual configuration, or some dynamic registration mechanism or protocol) into TRIP 📥 an LS that originates TRIP routes shall assign the degree of preference to those routes by running them through the Decision Process (see Section 10.2). to TRIP, local routes are literally identical to external routes, so they go through the same two-phase route selection mechanism 🥰
a local route that gets selected into the Ext-TRIB MUST be advertised to all internal LSs 📣 whether to distribute non-TRIP routes within an ITAD via TRIP depends on the environment inside that ITAD (like what kind of intra-domain routing protocol is running) and should be controlled via configuration 🎛️
11. TRIP Transport 🚚
this specification defines the use of TCP as the transport layer for TRIP. TRIP uses TCP port 6069. running TRIP over other transport protocols is for further study 🔭
12. ITAD Topology 🗺️
there are no restrictions on the intra-domain topology of TRIP LSs 🌟 for example, LSs in an ITAD can be set up as a full mesh, a star, or any other connected topology. same deal for TRIP ITADs: they can be organized in a flat topology (mesh or ring), in a multi-level hierarchy, or any other topology 🧚♀️
the border between two TRIP ITADs can sit either on the link between two TRIP LSs, or it can coincide with a TRIP LS. in the second case, that same TRIP LS is a member of more than one ITAD, and it appears to be an internal peer to the LSs in each ITAD it belongs to 🤝
13. IANA Considerations 📋
this document creates a brand new IANA registry for TRIP parameters 🎉 the following TRIP parameters are included in the registry:
- TRIP Capabilities
- TRIP Attributes
- TRIP Address Families
- TRIP Application Protocols
- TRIP ITAD Numbers
protocol parameters often get initialized or reset to 0 😅 so this document reserves the value 0 for each of the TRIP parameters above. that way an unset parameter is clearly different from any registered value for that parameter 💜
the sub-registries for each of those parameters are covered in the sections below 👇
13.1. TRIP Capabilities 🧃
requests to add TRIP capabilities other than the ones defined in Section 4.2.1.1 must be submitted to iana@iana.org. following the assigned number policies outlined in [11], Capability Codes in the range 32768-65535 are reserved for Private Use (these are the codes where the first bit of the code value is equal to 1). this document reserves value 0. Capability Codes 1 and 2 have been assigned in Section 4.2.1.1. Capability Codes in the range 2-32767 are controlled by IANA and get allocated subject to the Specification Required (IETF RFC or equivalent) condition. the specification MUST include a description of the capability, the possible values it may take, and what constitutes a capability mismatch 📝
13.2. TRIP Attributes 🏷️
this document reserves Attribute Type Codes 224-255 for Private Use (these are the codes where the first three bits of the code are equal to 1). this document reserves the value 0. Attribute Type Codes 1 through 11 have already been allocated by this document, and they're defined in Sections 5.1 through 5.11 🔖
Attribute Type Codes in the range 12-223 are controlled by IANA and require a Specification document (RFC or equivalent). the specification MUST provide all the information required in Section 5.12 of this document 📚
attribute type code registration requests must be sent to iana@iana.org. on top of the specification requirement, the request MUST include an indication of who has change control over the attribute, plus contact information (postal and email address) 📮
13.3. Destination Address Families 🌍
this document reserves address family 0. requests to add TRIP address families other than the ones defined in Section 5.1.1.1 (address families 1, 2, and 3), so anything in the range 4-32767, must be submitted to iana@iana.org. the request MUST include a brief description of the address family, its alphabet, and any special processing rules and guidelines, such as guidelines for aggregation, if there are any. these requests are subject to Expert Review. and this document reserves the address family codes 32768-65535 for vendor-specific applications 🫶
13.4. TRIP Application Protocols 🎀
okay so bestie, this part makes a brand new IANA registry for TRIP application protocols 📋✨ Code 0 is reserved (hands off 🙅♀️). Any new application protocol outside the ones in Section 5.1.1.1 (that's 1 through 4), so anything in the 5-32767 range, has to be submitted to iana@iana.org. Your request MUST include a brief background on the protocol and a description of how TRIP can be used to advertise routes for it 💅 Then those requests get Expert Review. And the range 32768-65535 is reserved for vendor-specific applications, so those are the vendors' own playground 🧚
13.5. ITAD Numbers 🌸
Same energy here 💖 ITAD number 0 is reserved. Numbers 1-255 are for Private Use (your private little club 🔒). Numbers from 256 to (232)-1** get handed out by IANA on a First-Come-First-Serve basis, aka whoever asks first gets it 🏃♀️💨 To ask, you send a request to iana@iana.org, and it MUST include:
- Info about the organization that will run the ITAD 🏢
- Contact info (postal AND email address 📬)
14. Security Considerations 🔐
okay this section is the serious one, so pay attention bestie 🫶 It's about security between peer TRIP LSs when TRIP runs over TCP in an IP environment.
Honestly, a security mechanism is clearly needed 😭 Without one, random unauthorized entities could set up sneaky peer sessions with TRIP LSs, or mess with the authorized ones. Nobody wants that drama 💀 For TRIP over TCP in an IP network, the mechanism is IPsec [12]. IPsec uses two protocols for traffic security: Authentication Header (AH) [13] and Encapsulating Security Payload (ESP) [14].
Here's the tea on AH: it gives you data origin authentication, connectionless integrity, and optional anti-replay protection for messages between the peer LSs 🛡️ ESP does all of that too, and adds confidentiality on top 🤫 So ESP is basically the full glam version 👑
Now the rules, and they're strict 😤 Implementations using the ESP header SHALL comply with section 5 of [14], which sets a minimum set of algorithms for integrity checking and encryption. Same deal for AH: implementations SHALL comply with section 5 of [13], which sets a minimum set of algorithms for integrity checking using manual keys 🔑
Also, implementations SHOULD use IKE [15] for more robust keying options ✨ And if they use IKE, they SHOULD support authentication with RSA signatures and RSA public key encryption 🌈
Quick vocab check 📚 A Security Association (SA) [12] is a simplex "connection" that gives security services to the traffic it carries. Services come from AH or ESP, but not both at once 🙅♀️ There are two kinds of SAs: transport mode and tunnel mode [12]. A transport mode SA is between two hosts, and it's the one that fits for protecting the TRIP session between two peer LSs 🦋
A1. Appendix 1: TRIP FSM State Transitions and Actions 🧚♀️
okay so this appendix walks through how the TRIP FSM moves between states when TRIP events happen 🔄 The lists and table below cover the states and events for when the negotiated Hold Time value is non-zero ⏱️
TRIP States:
1 - Idle
2 - Connect
3 - Active
4 - OpenSent
5 - OpenConfirm
6 - Established
TRIP Events:
1 - TRIP Start
2 - TRIP Stop
3 - TRIP Transport connection open
4 - TRIP Transport connection closed
5 - TRIP Transport connection open failed
6 - TRIP Transport fatal error
7 - ConnectRetry timer expired
8 - Hold Timer expired
9 - KeepAlive timer expired
10 - Receive OPEN message
11 - Receive KEEPALIVE message
12 - Receive UPDATE messages
13 - Receive NOTIFICATION messageNow the main event: the state transition table 🎀 It shows the transitions and the actions they trigger.
Event Actions Message Sent Next State
--------------------------------------------------------------------
Idle (1)
1 Initialize resources none 2
Start ConnectRetry timer
Initiate a transport connection
others none none 1
Connect(2)
1 none none 2
3 Complete initialization OPEN 4
Clear ConnectRetry timer
5 Restart ConnectRetry timer none 3
7 Restart ConnectRetry timer none 2
Initiate a transport connection
others Release resources none 1
Active (3)
1 none none 3
3 Complete initialization OPEN 4
Clear ConnectRetry timer
5 Close connection 3
Restart ConnectRetry timer
7 Restart ConnectRetry timer none 2
Initiate a transport connection
others Release resources none 1
OpenSent(4)
1 none none 4
4 Close transport connection none 3
Restart ConnectRetry timer
6 Release resources none 1
10 Process OPEN is OK KEEPALIVE 5
Process OPEN failed NOTIFICATION 1
others Close transport connection NOTIFICATION 1
Release resources
OpenConfirm (5)
1 none none 5
4 Release resources none 1
6 Release resources none 1
9 Restart KeepAlive timer KEEPALIVE 5
11 Complete initialization none 6
Restart Hold Timer
13 Close transport connection 1
Release resources
others Close transport connection NOTIFICATION 1
Release resources
Established (6)
1 none none 6
4 Release resources none 1
6 Release resources none 1
9 Restart KeepAlive timer KEEPALIVE 6
11 Restart Hold Timer none 6
12 Process UPDATE is OK UPDATE 6
Process UPDATE failed NOTIFICATION 1
13 Close transport connection 1
Release resources
others Close transport connection NOTIFICATION 1
Release resources
-----------------------------------------------------------------And here's the condensed version, for when you just want the vibes at a glance 👀
Events| Idle | Connect | Active | OpenSent | OpenConfirm | Estab
| (1) | (2) | (3) | (4) | (5) | (6)
|----------------------------------------------------------
1 | 2 | 2 | 3 | 4 | 5 | 6
| | | | | |
2 | 1 | 1 | 1 | 1 | 1 | 1
| | | | | |
3 | 1 | 4 | 4 | 1 | 1 | 1
| | | | | |
4 | 1 | 1 | 1 | 3 | 1 | 1
| | | | | |
5 | 1 | 3 | 3 | 1 | 1 | 1
| | | | | |
6 | 1 | 1 | 1 | 1 | 1 | 1
| | | | | |
7 | 1 | 2 | 2 | 1 | 1 | 1
| | | | | |
8 | 1 | 1 | 1 | 1 | 1 | 1
| | | | | |
9 | 1 | 1 | 1 | 1 | 5 | 6
| | | | | |
10 | 1 | 1 | 1 | 1 or 5 | 1 | 1
| | | | | |
11 | 1 | 1 | 1 | 1 | 6 | 6
| | | | | |
12 | 1 | 1 | 1 | 1 | 1 | 1 or 6
| | | | | |
13 | 1 | 1 | 1 | 1 | 1 | 1
| | | | | |
--------------------------------------------------------------A2. Appendix 2: Implementation Recommendations 💡
okay so this appendix has some implementation recommendations, and they're giving helpful bestie energy 🫶
This section presents some implementation recommendations.
A.2.1: Multiple Networks Per Message 📦
The TRIP protocol lets you put multiple address prefixes that share the same advertisement path and next-hop server into one message. Making use of this capability is highly recommended ✨ If you send one address prefix per message, the receiver takes a big overhead hit 😩 It has to handle way more messages, and it has to scan the routing table for updates to TRIP peers over and over 🙃
Here's a method for building messages with lots of prefixes, starting from a routing table that isn't organized by advertisement path 🗂️ As you scan the table, each address prefix gets processed like this. You allocate a message for its advertisement path and next hop if one doesn't exist yet, and then add the new prefix to it. If the message already exists, the prefix just gets appended. If the message doesn't have room for the new prefix, you transmit it, allocate a new message, and insert the prefix there. Once the whole table has been scanned, you send all the allocated messages and release their resources 🎀 You get the best compression when all the destinations covered by the address prefixes share the same next hop server and common attributes, because then lots of prefixes fit into one 4096-byte message 🍓
Now, if you're peering with a TRIP implementation that doesn't compress multiple prefixes into one message, you might need to cut down the overhead from the flood of data you get when a peer is acquired or a big network topology change happens 🌊 One option is to limit the rate of updates. That gets rid of the redundant table scans used to send flash updates to TRIP peers. The catch is that it adds propagation latency to routing information ⏳ To keep that latency low, pick a minimum flash update interval that's not much bigger than the time it takes to process the multiple messages. An even better method would be to read all received messages before sending updates 💜
That's the whole thing, bestie! 🌈
A.2.2: Processing Messages on a Stream Protocol 🌊
okay so TRIP runs on TCP 💖. TCP is a stream, which means all the bytes of one message don't always show up at the same time. Your message can arrive in chunks and you have to piece it back together 🧩. This is lowkey annoying, especially on systems where you can't even tell how much data has arrived but hasn't been processed yet 😭.
One way to handle it is to read just the message header first ✨. For KEEPALIVE, the header is the whole message 🦋. For every other type, check the header first, especially the total length. If all the checks pass, the specified length minus the size of the header is how much data is still left to read 🎀. If your routing information process would "hang" while waiting on a peer, you can give each peer a message buffer (4096 bytes) and keep filling it with data as it comes in until you have a complete message 💅.
A.2.3: Reducing Route Flapping 🎢
to avoid excessive route flapping, an LS that needs to withdraw a destination and also send an update about a more specific or less specific route SHOULD combine them into the same UPDATE message 🫶.
A.2.4: TRIP Timers ⏰
TRIP uses seven timers: ConnectRetry, Hold Time, KeepAlive, MaxPurgeTime, TripDisableTime, MinITADOriginationInterval, and MinRouteAdvertisementInterval 🧁. The suggested values are:
- ConnectRetry: 120 seconds
- Hold Time: 90 seconds
- KeepAlive: 30 seconds
- MaxPurgeTime: 10 seconds
- TripDisableTime: 180 seconds
- MinITADOriginationInterval: 30 seconds
- MinRouteAdvertisementInterval: 30 seconds
An implementation of TRIP MUST allow these timers to be configurable 🔧✨.
A.2.5: AP_SET Sorting 🗂️
another useful optimization that makes this situation simpler is sorting the ITAD numbers found in an AP_SET 💜. This optimization is entirely optional, so no pressure bestie 🌸.
Acknowledgments 🫶
huge thanks to Dave Oran for his insightful comments and suggestions 💖.
References 📚
[1] Bradner, S., "Keywords for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Rosenberg, J. and H. Schulzrinne, "A Framework for a Gateway Location Protocol", RFC 2871, June 2000.
[3] Rekhter, Y. and T. Li, "Border Gateway Protocol 4 (BGP-4)," RFC 1771, March 1995.
[4] Moy, J., "Open Shortest Path First Version 2", STD 54, RFC 2328, April 1998.
[5] "Intermediate System to Intermediate System Intra-Domain Routing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)," ISO DP 10589, February 1990.
[6] Luciani, J., Armitage, G., Halpern, J. and N. Doraswamy, "Server Cache Synchronization Protocol (SCSP)", RFC 2334, April 1998.
[7] International Telecommunication Union, "Packet-Based Multimedia Communication Systems," Recommendation H.323, Version 3 Telecommunication Standardization Sector of ITU, Geneva, Switzerland, November 2000.
[8] Handley, H., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[9] Braden, R., "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989.
[10] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[11] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[12] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[13] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[14] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[15] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
Intellectual Property Notice 🔐
the IETF doesn't take a position on whether any intellectual property or other rights that might be claimed to cover the implementation or use of the technology in this document are valid or in scope, or whether any license under those rights might be available. It also doesn't say it has tried to find any such rights. Info on the IETF's procedures for rights in standards-track and standards-related documents is in BCP 11. Copies of claims of rights made available for publication, assurances of licenses to be made available, or the results of an attempt to get a general license or permission for implementers or users of this specification can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please send that information to the IETF Executive Director.
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information, consult the online list of claimed rights.
Authors' Addresses ✍️
Jonathan Rosenberg
dynamicsoft
72 Eagle Rock Avenue
First Floor
East Hanover, NJ 07936
Phone: 973-952-5000
EMail: jdrosen@dynamicsoft.com
Hussein F. Salama
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
Phone: 408-527-7147
EMail: hsalama@cisco.com
Matt Squire
Hatteras Networks
639 Davis Drive
Suite 200
Durham, NC 27713
EMail: mattsquire@acm.orgFull Copyright Statement ©️
Copyright (C) The Internet Society (2002). All Rights Reserved.
this document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or help with its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, as long as the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for developing Internet standards, in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement 💜
Funding for the RFC Editor function is currently provided by the Internet Society 🌈.
📦 where this page comes from
- ietf: rfc3219 2002-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms