RFC 5140
A Telephony Gateway REgistration Protocol (TGREP)
A Telephony Gateway REgistration Protocol (TGREP) 📞
Okay bestie, let's start with the basics 💖 This is RFC 5140, and it's a Standards Track doc from March 2008 that lives in the Network Working Group 🎀 The authors are M. Bangalore, R. Kumar, and J. Rosenberg from Cisco, H. Salama from Citex Software, and D.N. Shah from Moowee Inc. 🌸 The title block doesn't list anything it obsoletes or updates, so no drama there ✨
Status of This Memo 📋
So this is an Internet standards track protocol for the whole Internet community, and they're literally asking for discussion and suggestions to make it better 💬 For the current standardization state and status, go check "Internet Official Protocol Standards" (STD 1) 📚 And yes, distribution of this memo is unlimited 🌈
Abstract ✨
So TGREP, the Telephony Gateway Registration Protocol, is how telephony prefixes supported by telephony gateways and soft switches get registered 📞 The registration mechanism can also be used to export resource information 💅 That prefix and resource info can then get passed to a Telephony Routing over IP (TRIP) Location Server, which can spread that routing info within and between Internet Telephony Administrative Domains (ITADs) 🦋 TGREP is giving a lot of TRIP energy: it has similar procedures and a similar finite state machine for session establishment, it uses the same message format, and it shares a subset of TRIP's attributes 💜
Table of Contents 🗂️
1. Introduction ....................................................3
2. Terminology and Definitions .....................................5
3. TGREP: Overview of Operation ....................................6
4. TGREP Attributes ................................................7
4.1. TotalCircuitCapacity Attribute .............................8
4.2. AvailableCircuits Attribute ................................9
4.3. CallSuccess Attribute .....................................10
4.4. Prefix Attributes .........................................12
4.5. TrunkGroup Attribute ......................................13
4.6. Carrier Attribute .........................................15
5. TrunkGroup and Carrier Address Families ........................16
5.1. Address Family Syntax .....................................17
6. Gateway Operation ..............................................18
6.1. Session Establishment .....................................18
6.2. UPDATE Messages ...........................................19
6.3. KEEPALIVE Messages ........................................19
6.4. Error Handling and NOTIFICATION Messages ..................19
6.5. TGREP Finite State Machine ................................19
6.6. Call Routing Databases ....................................19
6.7. Multiple Address Families .................................20
6.8. Route Selection and Aggregation ...........................20
7. LS/Proxy Behavior ..............................................20
7.1. Route Consolidation .......................................22
7.2. Aggregation ...............................................23
7.3. Consolidation versus Aggregation ..........................23
8. Security Considerations ........................................23
9. IANA Considerations ............................................24
9.1. Attribute Codes ...........................................24
9.2. Address Family Codes ......................................24
10. Acknowledgments ...............................................25
11. References ....................................................25
11.1. Normative References .....................................25
11.2. Informative References ...................................261. Introduction ✨
Okay so, it's assumed you already know TRIP [2, 12] 🧚 In typical Voice over IP (VoIP) networks, ITADs deploy loads of gateways for geographical diversity, capacity, and redundancy 🌸 When a call shows up at the domain, it must be routed to one of those gateways. Often an ITAD splits its network into geographic Points of Presence (POPs), and each POP has some gateways plus a proxy server element that fronts them 💅 That proxy element is a SIP proxy [11] or an H.323 gatekeeper. The proxy server manages access to the POP and decides which gateway gets each incoming call 🎀 Alongside the proxy that routes call signaling, there are two components: the "Ingress LS" (aka "TGREP receiver") and the "Egress LS" 🦋 The TGREP receiver keeps a TGREP peering relationship with one or more gateways. The routing info it gets from those gateways is injected into the Egress LS, which spreads it across the rest of the network over TRIP ✨ For convenience, gateway and GW mean the same thing 💖
Here's the picture 👀
Signaling TGREP
-------------> <----------------
+---------+
| |
| GW |
> +---------+
//
//
SIP // +---------+
<----> // | |
+-------------------------+ // | GW |
| | // +---------+
| +-------------+ |/
| | | |
| | Routing | | +---------+ TO PSTN
| | Proxy | | | |
---> | | |-----------> | GW | ----->
|+---+-----+ +-----+----+ | +---------+
|| | | | |
|| <+-+ | |--
||Egress LS| |Ingress LS| | --- +---------+
|| | | | | -- | |
|+---------+ +----------+ | -- | GW |
| | -- +---------+
| | -->
+-------------------------+
TRIP +---------+
<----> | |
| GW |
+---------+Figure 1: Gateway and LS Configuration
Picking a gateway depends on lots of stuff: their availability, remaining call capacity, and call success stats to a particular Public Switched Telephone Network (PSTN) destination (see [14]) 📊 For the proxy to do this well, it needs that info in real time, as it changes. So there has to be some kind of communication between the proxy and the gateways to convey it 🫶
TRIP [2] is defined for carrying telephony routing info between providers, so calls get routed to the right provider for termination to the PSTN 🌍 But TRIP has no mechanism for how routes get injected into it from within the network. It also doesn't define how a provider picks the specific gateway to terminate a call when it arrives. TGREP fills those gaps 💅
TGREP lets PSTN gateways or soft switches tell a signaling server, like a SIP proxy server or H.323 gatekeeper, about the routes they have to the PSTN 📡 These advertisements include fairly dynamic info, like the remaining capacity in a particular trunk, which is essential for picking the right gateway 🔥
TGREP is identical in syntax and overall operation to TRIP. However, it differs in the route processing rules the TGREP receiver follows, which allows a route processing function called "consolidation". Consolidation combines multiple routes for the same route destination, with different attributes, into a single route so routing information doesn't get lost 👑 TGREP also defines a set of new attributes, usable by TGREP or TRIP. Finally, TGREP only uses a subset of overall TRIP capabilities. Certain attributes aren't used (as described below), and the TGREP entities (the sender and receiver) work in an asymmetric relationship, whereas TRIP allows symmetric and asymmetric 🦋
As a general rule, because TRIP and TGREP are so similar, frequent reference will be made to the terminologies and formats defined in TRIP [2]. It's suggested that you be familiar with TRIP concepts like attributes, flags, route types, address families, etc. 💜
2. Terminology and Definitions 📖
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. Those caps-lock words are important, so read them carefully 👀
Some other useful definitions, bestie:
Circuit: A circuit is a discrete (specific) path between two or more points along which signals can be carried. In this context, a circuit is a physical path, made of one or more wires and possibly intermediate switching points ⚡
Trunk: In a network, a trunk is a communication path connecting two switching systems, used in establishing an end-to-end connection. In selected applications, it may have both its terminations in the same switching system 🧵
TrunkGroup: A trunkgroup is a set of trunks, traffic engineered as a unit, for establishing connections within or between switching systems. All of the paths are interchangeable except where subgrouped 🫧
Carrier: A carrier is a company offering telephone and data communications between points (end-users and/or exchanges) 📞💖
3. TGREP: Overview of Operation 🧚
okay so TGREP is a route registration protocol for telephony destinations on a gateway 📞 those destinations can be prefixes, trunkgroups, or carriers. the TGREP sender lives on the GW and gathers all the info to pass along to the TRIP Location Server. then there's a TGREP Receiver that takes that info, can optionally do consolidation and aggregation (see Section 7.3) 💅, and hands the reachability info over to a TRIP Location Server. the routing proxy uses it too, to pick which gateway handles incoming calls 🎀
the TGREP sender sets up a session with the TGREP receiver in a way that's pretty similar to session setup in TRIP 🦋 once that's up, the sender sends the reachability info inside UPDATE messages. those UPDATE messages look the same as TRIP's, BUT some TRIP attributes just aren't relevant here, so a TGREP receiver MAY ignore them if they show up in a TGREP message 🙈 these TRIP attributes do NOT apply to TGREP:
AdvertisementPathRoutedPathAtomicAggregateLocalPreferenceMultiExitDiscITADTopologyConvertedRoute
and TGREP adds some brand new attributes that can ride along in a TGREP UPDATE message ✨
TotalCircuitCapacity: the total number of PSTN circuits available on a route to complete calls. ⭐AvailableCircuits: the number of PSTN circuits that are currently available on a route to complete calls. 🍓CallSuccess: info about how many calls terminated normally out of the total number of attempted calls. 💜Prefix (E164): the list of E164 prefixes that the respective route can complete calls to. 🌸Prefix (Decimal Routing Number): the list of Decimal prefixes that the respective route can complete calls to. 🌈Prefix (Hexadecimal Routing Number): the list of Hexadecimal prefixes that the respective route can complete calls to. 🦋TrunkGroup: lets providers route calls to destinations through preferred trunks. 🫶Carrier: lets providers route calls to destinations through preferred carriers. 👑
for the rest of the doc, we spell out the attributes and address families used in TGREP. the new attributes and address families are also usable for general TRIP stuff EXCEPT where it's noted (AvailableCircuits is the example here) 🙌
4. TGREP Attributes 💖
bestie, since TGREP lives inside a service provider network, it borrows a SUBSET of the TRIP attributes and then adds a few of its own 🧚 these TRIP attributes apply to TGREP:
WithdrawnRoutesReachableRoutesNexthopServerPrefixCommunities
TGREP also defines some new ones, described in this section: TotalCircuitCapacity, AvailableCircuits, CallSuccess, TrunkGroup, and Carrier. like we said, these new ones are usable by TRIP unless noted otherwise 💅
a TGREP UPDATE supports these attributes:
TotalCircuitCapacityAvailableCircuitsCallSuccessPrefix(E.164, Pentadecimal routing number, Decimal routing number)TrunkGroupCarrier
4.1. TotalCircuitCapacity Attribute 🎀
Mandatory: False.
Required Flags: Not well-known.
Potential Flags: None.
TRIP Type Code: 13.the TotalCircuitCapacity attribute tells you the total number of PSTN circuits available on a route to complete calls 📞 it's used together with AvailableCircuits for gateway selection by the LS. the total number of calls sent to the specified route on the gateway can NOT go over this total circuit capacity under steady state conditions 🙅♀️
this one reflects the administratively provisioned capacity instead of what's available at any given moment (that's what AvailableCircuits is for) ✨ because it's pretty static, this attribute MAY be propagated beyond the LS that receives it 🦋
TotalCircuitCapacity is the total number of possible calls at any instant 🌸 it isn't expected to change often. it can change, for example, when some telephony trunks on the gateway get taken out of service for maintenance 🔧
4.1.1. TotalCircuitCapacity Syntax 🍓
the TotalCircuitCapacity attribute is a 4-octet unsigned integer 🔢 it represents the total number of circuits available for terminating calls through this advertised route. it's a potentially achievable upper bound on the number of calls that can be terminated on this route in total 💜
4.1.2. Route Origination and TotalCircuitCapacity 🌈
routes MAY be originated containing the TotalCircuitCapacity attribute ✨
4.1.3. Route Selection and TotalCircuitCapacity 🧚
the TotalCircuitCapacity attribute MAY be used for route selection 💅 since load balancing is one of its main uses, an LS will want to pick a potentially different route (out of a set of routes for the same destination) on a call-by-call basis. you can model that as re-running the decision process when each call arrives 📞 the aggregation and dissemination rules for routes with this attribute make sure that re-running this selection NEVER results in a new route getting propagated to other peers 🫶
4.1.4. Aggregation and TotalCircuitCapacity 🎀
an LS MAY aggregate routes to the same prefix that contain a TotalCircuitCapacity attribute. it SHOULD add up the values of the individual routes to work out the value for the aggregated route in the same ITAD 🧮
4.1.5. Route Dissemination and TotalCircuitCapacity 🦋
since this attribute reflects the static capacity of the gateway's circuit resources, it isn't expected to change often 🔒 so the LS that receives it MAY disseminate it to other peers, both internal AND external to the ITAD 🌸
4.2. AvailableCircuits Attribute 🍓
Mandatory: False.
Required Flags: Not well-known.
Potential Flags: None.
TRIP Type Code: 14.the AvailableCircuits attribute identifies the number of PSTN circuits that are currently available on a route to complete calls 📞 the number of additional calls sent to that gateway for that route can NOT go over the circuit capacity. if it does, the signaling protocol will likely throw errors and calls will get rejected 😭
AvailableCircuits is used ONLY between a gateway and its peer LS, the one responsible for managing that gateway 💖 if it's received in a route, it does NOT get propagated 🙅♀️
4.2.1. AvailableCircuits Syntax 🔢
the AvailableCircuits attribute is a 4-octet unsigned integer. it represents the number of circuits remaining for terminating calls to this route ✨
4.2.2. Route Origination and AvailableCircuits 🌈
routes MAY be originated containing the AvailableCircuits attribute 🧚 this one is super dynamic (it changes with every call), so updates MAY be sent as it changes. BUT it is RECOMMENDED that measures be taken to help cut down the messaging load from route origination 📉 it is further RECOMMENDED that a sufficiently large window of time be used so you get a useful aggregated statistic 📊
4.2.3. Route Selection and AvailableCircuits 💅
the AvailableCircuits attribute MAY be used for route selection 🎀 load balancing is one of its main uses, so an LS will want to pick a potentially different route (out of a set of routes for the same prefix) on a call-by-call basis. you can model that as re-running the decision process when each call arrives 📞 the aggregation and dissemination rules for routes with this attribute make sure that re-running this selection NEVER results in a new route getting propagated to other peers 🫶
4.2.4. Aggregation and AvailableCircuits 🦋
Not applicable. 🙅♀️
4.2.5. Route Dissemination and AvailableCircuits 🔒
routes MUST NOT be disseminated with the AvailableCircuits attribute 🚫 it's meant to reflect capacity at the originating gateway ONLY. and since it's so highly dynamic, it's just not a good fit to disseminate in most cases 💀
4.3. CallSuccess Attribute 💜
Mandatory: False.
Required Flags: Not well-known.
Potential Flags: None.
TRIP Type Code: 15.the CallSuccess attribute is used ONLY between a gateway and its peer LS, the one responsible for managing that gateway 🫶 if it's received in a route, it does NOT get propagated 🙅♀️
CallSuccess tells you about the number of normally terminated calls out of a total number of attempted calls 📊
the gateway decides CallSuccess based on the Disconnect cause code at call termination 🔍 for example, a call that reaches the Alerting stage but doesn't connect because the called party is unavailable, or is busy, is conventionally counted as a successful call ✅ on the flip side, a call that gets disconnected because a circuit or resource is unavailable is conventionally counted as a failed call ❌ the exact mapping from disconnect causes to CallSuccess is up to the gateway reporting the attribute 🎀
the LS uses CallSuccess to keep track of failures in reaching certain telephony destinations through a gateway (or gateways) 🌸 then it uses that info in gateway selection to boost the chances of successful call termination 🧚
this info can help the LS consider alternative gateways for terminating calls to those destinations, ones with a better likelihood of success 🌈
4.3.1. CallSuccess Syntax 🔢
the CallSuccess attribute is made up of two component fields, and each one is a 4-octet unsigned integer 💖 the first component field is the total number of calls terminated successfully for the advertised destination on a given address family over a given window of time. the second component field is the total number of attempted calls for the advertised destination within that same window of time 📞
when the total number of attempted calls wraps around, the counter for successful calls gets reset so it stays aligned with the other component over a given window of time 🔄 the TGREP receiver using this info should get it frequently enough to prevent loss of significance 🫶
4.3.2. Route Origination and CallSuccess 🌈
routes MAY be originated containing the CallSuccess attribute ✨ this one is expected to become statistically significant as time passes and more calls get attempted 📈 it is RECOMMENDED that sufficiently large windows be used so you get a useful aggregated statistic 📊
4.3.3. Route Selection and CallSuccess 💅
the CallSuccess attribute MAY be used for route selection 🎀 it's a measure of how successful terminating calls to the advertised destination(s) has been 🌸 this info MAY be used to pick from a set of alternative routes to raise the probability of successful call termination 🧚
4.3.4. Aggregation and CallSuccess 🦋
Not applicable. 🙅♀️
4.3.5. Route Dissemination and CallSuccess
Okay bestie, routes MUST NOT get disseminated with the CallSuccess attribute 🙅♀️. Its potential to change dynamically means it's not suitable to pass around, so don't even try 💅
4.4. Prefix Attributes ✨
Mandatory: False. 🎀 Required Flags: Not well-known. Potential Flags: None. TRIP Type Codes: 16 for E164 Prefix, 17 for Pentadecimal Routing Number Prefix, and 18 for Decimal Routing Number Prefix.
So the Prefix attribute holds the list of prefixes a route can complete calls to 📞🌸 It's meant to be used with the Carrier or TrunkGroup address family (we'll get to that in Section 5 💖).
Okay, real talk: a carrier could reach every prefix range, but administrative stuff might make some ranges way more preferable than others 🙈
4.4.1. Prefix Attribute Syntax 🧚
The Prefix attribute could be E.164, Decimal, or Pentadecimal (refer to TRIP [2]), and each one gets its own type code 💜 The attribute is encoded as a sequence of prefix values in the attribute Value field. The prefixes are listed one after another with no padding, as shown in Figure 2. Each prefix has a 2-octet Length field that tells you the length of the Address field in octets. The order of prefixes in the attribute doesn't matter ✨
If the Prefix attribute shows up with its Length field set to 0, that means the TGREP GW can terminate ALL prefixes of that prefix type (E.164, Decimal, or Pentadecimal) for the given Reachable route(s). And no, leaving out the Prefix attribute entirely in the TGREP update is not the same thing 😭
< 2 octets > < Length1 octets > < 2 octets > < Length2 octets >
+------------+--------------//--+------------+--------------//--+-
| Length1 | Prefix1 | Length2 | Prefix2 | ...
+------------+--------------//--+------------+--------------//--+-
Figure 2: Prefix Format4.4.2. Route Origination and Prefix 🦋
Routes MAY be originated containing the Prefix attribute.
4.4.3. Route Selection and Prefix 🍓
The Prefix attribute MAY be used for route selection.
4.4.4. Aggregation and Prefix 💅
Routes with differing Prefix attributes MUST NOT be aggregated. Routes with the same value in the Prefix attribute MAY be aggregated, and the same Prefix attribute gets attached to the aggregated object. Iconic behavior, honestly 👑
4.4.5. Route Dissemination and Prefix 🌈
The LS that receives this attribute should disseminate it to other peers, both internal and external to the ITAD. ✨
4.5. TrunkGroup Attribute 🌸
Mandatory: False. 🎀 Required Flags: Not well-known. Potential Flags: None. TRIP Type Code: 19.
The TrunkGroup attribute holds the list of trunkgroups on the gateway that get used to complete calls 📞 It lets providers route calls to destinations through their preferred trunks 🫶 This one is relatively static, so it's the chill girl of the attributes 🧘♀️
4.5.1. TrunkGroup Syntax 🔥
The TrunkGroup attribute is a variable-length attribute made up of a sequence of trunkgroup identifiers. It means the gateway can complete the call through any trunkgroup identifier in that sequence.
Each trunkgroup identifier is encoded as a Length-Value field (shown in Figure 3 below). The Length field is a 1-octet unsigned numeric value. The Value field is variable-length and has two subfields: a trunkgroup label, then a trunk context, separated by the delimiter ";" (semicolon). Both subfields are variable length. The Length field counts the total size of the Value field, delimiter included 🧮
The permissible character set for the trunk group label and trunkgroup context subfields, and the associated ABNF [8], follow the rules outlined in [4]. Be careful with those characters, bestie 🙏
If the TrunkGroup attribute shows up with its Length field set to 0, that means the TGREP GW can terminate ALL trunkgroups for the given Reachable route(s). 💀
< 1 octet > < Length1 octets > < 1 octet > < Length2 octets >
+-----------+--------------//--+-----------+--------------//--+-
| Length1 | TrunkGroup 1 | Length2 | TrunkGroup 2 | ...
+-----------+--------------//--+-----------+--------------//--+-
Figure 3: TrunkGroup Syntax4.5.2. Route Origination and TrunkGroup 🦋
Routes MAY be originated containing the TrunkGroup attribute.
4.5.3. Route Selection and TrunkGroup 💖
The TrunkGroup attribute MAY be used for route selection. Certain trunkgroups MAY be preferred over others based on provider policy. Policy is the boss here 👑
4.5.4. Aggregation and TrunkGroup 🎀
Routes with differing TrunkGroup attributes MUST NOT be aggregated. Routes with the same value in the TrunkGroup attribute MAY be aggregated, and the same TrunkGroup attribute gets attached to the aggregated object. ✨
4.5.5. Route Dissemination and TrunkGroup 🌷
This attribute isn't expected to change frequently. So the LS receiving it MAY disseminate it to other peers, internal to the ITAD. Routes SHOULD not be disseminated external to the ITAD with the TrunkGroup attribute. Keep it in the family, bestie 🏠💜
4.6. Carrier Attribute 💜
Mandatory: False. 🎀 Required Flags: Not well-known. Potential Flags: None. TRIP Type Code: 20.
The Carrier attribute holds the list of carriers the gateway uses to complete calls 📱 It lets providers route calls to destinations through preferred carriers 🫶 And yep, it's also relatively static 🧚
4.6.1. Carrier Syntax 🔮
The Carrier attribute is a variable-length attribute made up of a sequence of carrier identifiers. It means the route can complete the call to any of the carriers represented in that sequence of carrier identifiers [13].
Each carrier identifier is encoded as a Length-Value field (shown in Figure 4 below). The Length field is a 1-octet unsigned numeric value. The Value field is variable-length.
The permissible character set for the Value field, and the associated ABNF [8], follow the rules outlined in [5]. Specifically, it carries "global-cic" or "local-cic" [5]. For "local-cic", the "phonedigit-hex" part and the "cic-context" part are separated by the delimiter ";". So the absence or presence of that delimiter tells you whether the value is a "global-cic" or a "local-cic" 🕵️♀️ The Length field counts the total size of the Value field, delimiter included.
If the Carrier attribute shows up with its Length field set to 0, that means the TGREP GW can terminate ALL Carriers for the given Reachable route(s). 🙌
< 1 octet > < Length1 octets > < 1 octet > < Length2 octets >
+-----------+--------------//--+-----------+--------------//--+-
| Length1 | Carrier 1 | Length2 | Carrier 2 | ...
+-----------+--------------//--+-----------+--------------//--+-
Figure 4: Carrier Syntax4.6.2. Route Origination and Carrier 🌈
Routes MAY be originated containing the Carrier attribute.
4.6.3. Route Selection and Carrier ⭐
The Carrier attribute MAY be used for route selection. Certain carriers MAY be preferred over others based on provider policy. 💅
4.6.4. Aggregation and Carrier 🍓
Routes with differing Carrier attributes MUST NOT be aggregated. Routes with the same value in the Carrier attribute MAY be aggregated, and the same Carrier attribute gets attached to the aggregated object. Slay 🔥
4.6.5. Route Dissemination and Carrier 🦋
This attribute isn't expected to change frequently. So the LS receiving it MAY disseminate it to other peers, both internal and external to the ITAD. 🫶
5. TrunkGroup and Carrier Address Families 🎀
As described in TRIP [2], the Address Family field gives the type of address for the route. This section defines two new address families and their codes ✨
Code Address Family
4 TrunkGroup
5 CarrierWhen a set of GWs needs to be managed at the granularity of carriers or trunkgroups, it may make more sense for a GW to advertise routes using the Carrier address family or the TrunkGroup address family, respectively. 🧠
Also, in a TGREP association between the gateway and the LS responsible for managing that gateway, some attributes fit more naturally as advertised properties of trunkgroups or carriers, rather than of advertised prefixes. For example, AvailableCircuit information on a particular trunkgroup or a particular carrier 🌸 The existing TRIP address families just aren't enough for this relationship, so we need separate address families that can tie properties like AvailableCircuits information to trunkgroups or carriers 💖
The primary benefits of this model are:
- It lets a service provider route calls based strictly on the trunkgroups or carriers. 👑
- It gives more accurate reporting of dynamic attributes like AvailableCircuits, by letting you manage resources at the granularity of a trunkgroup or a carrier. 📊
- It helps with scalability. Gateways can get really large, with the ability to provision hundreds or a few thousand circuits, and that can crank up the traffic reporting dynamic resource info between the gateway and the LS. This model can potentially ease that UPDATE traffic, which means better efficiency and a more scalable gateway registration model 🚀✨
5.1. Address Family Syntax ✨
okay so first up, the generic TRIP route format from TRIP [2] 💖 Here it is, 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
+---------------+---------------+---------------+---------------+
| Address Family | Application Protocol |
+---------------+---------------+---------------+---------------+
| Length | Address (variable) ...
+---------------+---------------+---------------+---------------+
Figure 5: Generic TRIP Route FormatThe Address Family field tells you what kind of address this family is using, and that's based on the TrunkGroup or Carrier 🎀 IANA already handed out the codes for the new address families, so no drama there.
The TrunkGroup address family is code 4, and the Carrier address family is code 5 🌸
The Application Protocol field is the same one used for the Decimal, Pentadecimal, and E.164 address families from TRIP [2] 🦋 And the Length field is the total size of the Address field, in bytes.
The Address field holds either a TrunkGroup or a Carrier value, and the syntax goes like this:
For the TrunkGroup address family, the Address field is a TrunkGroup value defined the way it's specified in Section 4.5.1, "TrunkGroup Syntax" ✨
For the Carrier address family, the Address field is a Carrier value. It's the same as the Value field from the earlier Section 4.6.1, "Carrier Syntax" 💜
These address families are not hierarchical. They're flat 🧚 If a gateway supports any of them, it should include that address family as one of the Route types supported in the OPEN message capability negotiation phase.
Heads up: these attributes are flat, not nested. Don't go looking for a hierarchy here, bestie 🙈
The following attributes are currently defined for use with all the address families, including TrunkGroup and Carrier 👑
- AvailableCircuits attribute
- TotalCircuitCapacity attribute
- CallSuccess attribute
It is recommended that the gateway use those three attributes with the TrunkGroup or Carrier address family, if possible. The payoff is a more efficient resource reporting framework and a scalable model for gateway provisioning. Literally iconic 🔥
When the gateway isn't using the TrunkGroup or Carrier address family, though, it MAY use those attributes with the Decimal, Pentadecimal, and E.164 address families 🌈
The Prefix attribute cannot be used when the address family is E164 numbers, Pentadecimal routing numbers, or Decimal routing numbers 💀
The Carrier attribute cannot be used if the address family type is Carrier 🙅
The TrunkGroup attribute cannot be used if the address family type is TrunkGroup 💅
6. Gateway Operation ✨
okay so a gateway uses TGREP to advertise its reachability to its domain's Location Server(s) 🌸 (LS, which are closely coupled with proxies). The gateway runs in TRIP Send Only mode because it only cares about advertising its own reachability. It isn't interested in learning about other gateways and other domains, and it won't create its own call routing database. This section walks through how TGREP works on a gateway 🦋
6.1. Session Establishment 💖
When a TGREP gateway opens a peering session with a TGREP receiver, it follows exactly the same procedures as any other TRIP entity ✨ The gateway sends an OPEN message that includes a Send Receive Capability in the Optional Parameters, and the gateway sets that capability to Send Only. The OPEN message also lists the address families the gateway supports. The rest of the peer session establishment is identical to TRIP 🎀
6.2. UPDATE Messages 🫶
Once the peer session is up, the gateway sends UPDATE messages to the TRIP LS with its entire reachability. It also sends any attributes associated with the routes 🍓
TGREP processing of the UPDATE message at the gateway is identical to UPDATE processing in TRIP [2]. A TGREP sender MUST support all mandatory TRIP attributes 💜
6.3. KEEPALIVE Messages 🌈
KEEPALIVE messages get exchanged periodically over the peering session between the TGREP gateway and the TRIP LS, as specified in Section 4.4 of TRIP [2] ⭐
6.4. Error Handling and NOTIFICATION Messages 😭
Error handling and NOTIFICATION generation work the same way with TGREP as they do with TRIP ✨ The only difference is that a TGREP gateway will never generate a NOTIFICATION message in response to an UPDATE message, no matter what's in that UPDATE message. Any UPDATE message just gets silently discarded 🙈
6.5. TGREP Finite State Machine 🔥
When the TGREP finite state machine is in the Established state and an UPDATE message comes in, that UPDATE message is silently discarded and the TGREP gateway stays in the Established state 💅 Other than that, the TRIP finite state machine and the TGREP finite state machine are identical 🦋
6.6. Call Routing Databases 👑
A TGREP gateway may maintain simultaneous sessions with more than one TRIP LS 🌸 It keeps one call routing database per peer TRIP LS. These databases are equivalent to TRIP's Adj-TRIBs-Out, so we'll call them Adj-TRIBs-GW-Out 💖 Each Adj-TRIB-GW-Out contains the gateway's reachability information that was advertised to its peer TRIP LS. How an Adj-TRIB-GW-Out database gets populated is outside the scope of this document (possibly by manual configuration) ✨
The TGREP gateway doesn't have databases equivalent to TRIP's Adj-TRIBs-In and Loc-TRIB. That's because the TGREP gateway doesn't learn routes from its peer TRIP LSs, so it doesn't run call route selection 🧚
6.7. Multiple Address Families 🌈
okay so TGREP supports various address families to convey the reachability of telephony destinations 📞 Here's the big rule: a TGREP session MUST NOT send UPDATEs of more than one of the following categories for a given established session: (a) Prefix address families (E164, Pentadecimal, and Decimal), (b) TrunkGroup address family, or (c) Carrier address family 🙅
TGREP should specify its choice of address family through the route-type capability in the OPEN message 🎀 And a route-type specification in the OPEN message that breaks the above rule should be rejected with a NOTIFICATION message 😭
6.8. Route Selection and Aggregation 💀
TRIP's route selection and aggregation operations MUST NOT be implemented by TGREP gateways 🙈 No route selection or aggregation on the gateway, periodt 💅
7. LS/Proxy Behavior 🌸
As mentioned earlier, TGREP can be considered a protocol complimentary to TRIP when it comes to providing reachability information, and that information can then be fed into the Location Server 🦋 Here's the architecture of an LS/Proxy system. There's a TRIP LS application that acts as a speaker in the I-TRIP/E-TRIP network, as documented in TRIP [2]. This component is called "Egress LS" for the purposes of this discussion 👑 Then there's a signaling server fronting a set of gateways. Working alongside that signaling server is a second component operating in receive mode. It peers with one or more gateways, and each of those gateways uses TGREP to advertise routing information 💖
That component, on the receiving end of one or more TGREP sessions, is called the "Ingress LS" or "TGREP receiver" for the purposes of this discussion ✨ The entity advertising the routes on the TGREP session (typically a gateway) is called the "TGREP sender" 🫶
The TGREP receiver takes the resulting routing information from each gateway, and it "exports" that information to another process we define below. That process does consolidation and aggregation, in that order 🧚 These operations take as input the collective set of routes from all the gateways. After that, the resulting TRIB gets passed as input into the LS-Egress process, as shown below, and that process can then disseminate the routes via TRIP 🔥 The interface between the TGREP receiver (aka Ingress LS) peering with the GW(s) and the TRIP LS (Egress LS) is entirely a local matter 🙈
The nature of the consolidation and aggregation operations, and the motivation behind them, is described in the subsections below. The order in which the operations are listed is an implicit logical sequence in which they're applied 🌈 The architecture for an LS/Proxy entity is shown in Figure 6 below 🍓
+-------------------------------------------------------+
| +-------------------------------+ |
| | +-+ +-+ | | TGREP
| | |A| |C| | | +-----+
| | |g| |o| | | | |
| +-------------+ | |g| |n| +-------------+ | | --| GW |
| | | | |r| |s| | | | | +-----+
| | TRIP | | |e| |o| | | | +---
| | LS <----------|g<--|l<--- TGREP |-++-| +-----+
| | | | |a| |i| | Session | | | | |
| | (I-TRIP/ | | |t| |d| | Management |-++-+----| GW |
| | E-TRIP) | | |i| |a| | | | | +-----+
| | (Egress LS) | | |o| |t| | |-+ +---
| +-----------/-+ | |n| |i| +-------------+ | | +-----+
| / | | | |o| | | --| |
| / | | | |n| (Ingress LS) | | | GW |
| / | +-+ +-+ | | +-----+
| / | TGREP Receiver | |
| / +-------------------------------+ |
| / |
| / |
+-------/-----------------------------------------------+
/ LS/Proxy
/
/
/
/
/
+/----------------+
| |
| |
| |
| LS |
| |
| |
| |
| |
| |
+-----------------+
Figure 6: LS Architecture for TRIP-GW7.1. Route Consolidation ✨
okay so the TGREP receiver (aka the Ingress LS 💅) can get routing info from one or more gateways, and honestly it's super common for multiple routes to exist for the same destination 👀. Those alternatives might come from the same gateway or from different ones. It is RECOMMENDED that the set of gateway routes for each destination get consolidated before a candidate route is presented to the Egress LS entity 🫶. The goal is to build one route that best represents what all the gateways managed by this TGREP receiver can collectively do. Let's walk through an example so you can see why this matters. Say the TGREP receiver is peering with gateways A and B:
- Gateway A advertises a route for destination "SIP 408" on the E.164 address family with the Carrier attribute value C1.
- Gateway B advertises a route for destination "SIP 408" on the E.164 address family with Carrier attribute value C2.
The TGREP receiver can consolidate those two routes into a single route for "SIP 408", where the Carrier attribute is the union of both values, namely "C1 C2" ✨. That's what consolidation is. Without it, a route to "SIP 408" through one or more of those carriers could get lost 😭.
Here's another one. Say there are Carrier address family (AF) updates from two gateways for Carrier destination X, and one update has prefix values {408, 650} while the other has {919, 973}. Those prefixes can be merged into one Carrier AF route advertisement with prefix value {408, 650, 919, 973} 🌸.
Basically, if TGREP routes from a set of gateways aren't consolidated before a candidate route goes to the TRIP LS, there's a real risk of losing gateway routing information 💀. How you apply consolidation to different attributes and routes from different address families is up to each TGREP receiver implementation 🧚.
7.2. Aggregation 🦋
The gateway routes, whether they've been consolidated or not, may be aggregated before they get imported into the LS instance in charge of I-TRIP/E-TRIP processing (Egress LS). This follows the standard aggregation procedures described in TRIP [2], while respecting the aggregation rules for each route attribute 💜.
7.3. Consolidation versus Aggregation 🎀
Let's clear up the difference between these two, because they sound alike but aren't 😤. Consolidation combines multiple routes for the same route destination. Aggregation combines routes for different route destinations that qualify to be summarized, which cuts down on route information 🍓.
For example, if multiple gateways offer routes to the E.164 destination "408" but with different attributes (like Carrier), the LS/Proxy can combine them into one route for "408" that represents those attributes collectively. That's consolidation 💖.
Now say the LS/Proxy gets routes for 4080, 4081, 4082, ... 4089 from a set of gateways. It could aggregate those candidate routes into a summarized route destination "408", with each attribute computed using the aggregation procedures defined in TRIP ✨.
8. Security Considerations 🔐
The security considerations for TGREP are identical to the ones for TRIP [2], and they're restated here just so everything is clear 💅.
The security mechanism for the peering session between a TGREP GW and a TRIP LS, over an IP network, is IPsec [3]. IPsec uses two protocols to provide traffic security: Authentication Header (AH) [6] and Encapsulating Security Payload (ESP) [7] 🧚.
The AH header provides data origin authentication, connectionless integrity, and optional anti-replay protection for messages passed between the peer LSs. The ESP header provides origin authentication, connectionless integrity, anti-replay protection, and confidentiality for messages ⭐.
Implementations that use the ESP header SHALL comply with Section 3.1.1 of [10], which defines a minimum set of algorithms for integrity checking and encryption. Likewise, implementations that use the AH header SHALL comply with Section 3.2 of [10], which defines a minimum set of algorithms for integrity checking. This is a must-do, bestie 😭🔥
Implementations SHOULD use the Internet Key Exchange Protocol (IKEv2) [9] to get more robust keying options 🫶. Implementations that use IKEv2 SHOULD support 3DES-CBC for confidentiality and HMAC-SHA1 for integrity 🌈.
A Security Association (SA) [3] is a simplex "connection" that provides security services to the traffic it carries 🔥. Those services are provided to an SA by using AH or ESP, but not both 🙈. There are two types of SAs: transport mode and tunnel mode. A transport mode SA is a security association between two hosts, and it's the right fit for protecting the TRIP session between two peer LSs 👑.
9. IANA Considerations 📋
Both TRIP [2] and TGREP share the same IANA registry for Capabilities, Attributes, Address Families, and Application Protocols 💜. IANA added the following attribute codes and address family codes to the TRIP [2] registries 🦋.
9.1. Attribute Codes 🌸
The Attribute Type Codes assigned to the new attributes defined in this document are listed below:
Code Attribute Reference
---- --------- ---------
13 TotalCircuitCapacity [RFC5140]
14 AvailableCircuits [RFC5140]
15 CallSuccess [RFC5140]
16 E.164 Prefix [RFC5140]
17 Pentadecimal Routing Number Prefix [RFC5140]
18 Decimal Routing Number Prefix [RFC5140]
19 TrunkGroup [RFC5140]
20 Carrier [RFC5140]9.2. Address Family Codes 🧁
The next subsections show the codes assigned for the two new address families introduced in this document ✨.
9.2.1. TrunkGroup Address Family 🎀
Code Address Family Reference
---- -------------- ---------
4 TrunkGroup [RFC5140]9.2.2. Carrier Address Family 💅
Code Address Family Reference
---- -------------- ---------
5 Carrier [RFC5140]10. Acknowledgments 🫶
Big thank-you to Vijay Gurbani, Li Li, Kevin McDermott, David Oran, Bob Penfield, Jon Peterson, Anirudh Sahoo, and James Yu for their insightful comments and suggestions 💖. They're literally the best ✨.
11. References 📚
11.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Rosenberg, J., Salama, H., and M. Squire, "Telephony Routing
over IP (TRIP)", RFC 3219, January 2002.
[3] Kent, S. and K. Seo, "Security Architecture for the Internet
Protocol", RFC 4301, December 2005.
[4] Gurbani, V. and C. Jennings, "Representing Trunk Groups in
tel/sip Uniform Resource Identifiers (URIs)", RFC 4904, June
2007.
[5] Yu, J., "Number Portability Parameters for the "tel" URI", RFC
4694, October 2006.
[6] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[7] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303,
December 2005.
[8] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[9] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC
4306, December 2005.
[10] Manral, V., "Cryptographic Algorithm Implementation Requirements
for Encapsulating Security Payload (ESP) and Authentication
Header (AH)", RFC 4835, April 2007.11.2. Informative References
[11] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[12] Rosenberg, J. and H. Schulzrinne, "A Framework for Telephony
Routing over IP", RFC 2871, June 2000.
[13] ITU-T List of ITU Carrier Codes (published periodically in the
ITU-T Operational Bulletin).
[14] Rosenberg, J., "Requirements for Gateway Registration", Work in
Progress, November 2001.Authors' Addresses 🌈
Manjunath S. Bangalore
Cisco
Mail Stop SJC-14/2/1
3625 Cisco Way
San Jose, CA 95134
Phone: +1-408-525-7555
EMail: manjax@cisco.com
Rajneesh Kumar
Cisco
Mail Stop SJC-14/4/2
3625 Cisco Way
San Jose, CA 95134
Phone: +1-408-527-6148
EMail: rajneesh@cisco.com
Jonathan Rosenberg
Cisco
Edison, NJ 08837
EMail: jdrosen@cisco.com
Hussein F. Salama
Citex Software
Giza, Egypt
EMail: hsalama@citexsoftware.com
Dhaval Niranjan Shah
Moowee Inc.
4920 El Camino Real
Los Altos, CA 94022
Phone: +1-408-307-7455
EMail: dhaval@moowee.tvFull Copyright Statement ⚖️
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property 🔒
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 💖✨
📦 where this page comes from
- ietf: rfc5140 2008-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms