Network Working Group                                       M. Bangalore
Request for Comments: 5140                                      R. Kumar
Category: Standards Track                                   J. Rosenberg
                                                               H. Salama
                                                          Citex Software
                                                               D.N. Shah
                                                             Moowee Inc.
                                                              March 2008
           A Telephony Gateway REgistration Protocol (TGREP)

Status of This Memo


This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD 1)の最新版を参照してください。このメモの配布は無制限です。



This document describes the Telephony Gateway Registration Protocol (TGREP) for registration of telephony prefixes supported by telephony gateways and soft switches. The registration mechanism can also be used to export resource information. The prefix and resource information can then be passed on to a Telephony Routing over IP (TRIP) Location Server, which in turn can propagate that routing information within and between Internet Telephony Administrative Domains (ITADs). TGREP shares a lot of similarities with the TRIP protocol. It has similar procedures and finite state machine for session establishment. It also shares the same format for messages and a subset of attributes with TRIP.

この文書は、テレフォニーゲートウェイとソフトスイッチでサポートされている電話プレフィックスを登録するためのテレフォニーゲートウェイ登録プロトコル(TGREP)について説明します。登録メカニズムは、リソース情報をエクスポートするために使用することができます。プレフィックスとリソースの情報は、今度はインターネットテレフォニー管理ドメイン(ITADs)内との間で情報をルーティングすることを伝搬することができるオーバーIPテレフォニールーティング(TRIP)ロケーションサーバ、に渡すことができます。 TGREPは、TRIPプロトコルと多くの類似点を共有しています。これは、セッション確立のための同様の手順と有限状態マシンを持っています。また、メッセージのための同じ形式およびTRIPと属性のサブセットを共有しています。

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 ...................................26
1. Introduction
1. はじめに

It is assumed that the reader of this document is familiar with TRIP [2, 12]. In typical Voice over IP (VoIP) networks, Internet Telephony Administrative Domains (ITADs) will deploy numerous gateways for the purposes of geographical diversity, capacity, and redundancy. When a call arrives at the domain, it must be routed to one of those gateways. Frequently, an ITAD will break its network into geographic Points of Presence (POPs), with each POP containing some number of gateways, and a proxy server element that fronts those gateways. The proxy element is a SIP proxy [11] or H.323 gatekeeper. The proxy server is responsible for managing the access to the POP, and also for determining which of the gateways will receive any given call that arrives at the POP. In conjunction with the proxy server that routes the call signaling, there are two components, the "Ingress LS" (aka "TGREP receiver") and the "Egress LS". The TGREP receiver component maintains TGREP peering relationship with one or more gateways. The routing information received from the gateways is further injected into the Egress LS, which in turn disseminates into the rest of the network on TRIP. For convenience, gateway and GW are used interchangeably.

なお、この文書の読者がトリップ[2]、[12]に精通しているものとします。典型的なボイスオーバーIP(VoIP)のネットワークでは、インターネットテレフォニー管理ドメイン(ITADs)は、地理的な多様性、容量、および冗長性の目的のために、多くのゲートウェイを展開します。呼び出しは、ドメインに到着すると、それはそれらのいずれかのゲートウェイにルーティングする必要があります。しばしば、ITADは、ゲートウェイのいくつかの数、およびそれらの前線のゲートウェイをプロキシサーバーの要素を含む各POPで、プレゼンスの地理的ポイント(POPの)にそのネットワークを中断します。プロキシ要素は、SIPプロキシ[11]またはH.323ゲートキーパーです。プロキシサーバがPOPへのアクセスを管理するための、また、POPに到着する任意のコールを受信するゲートウェイのかを決定する責任があります。ルートコールシグナリングプロキシサーバと連携して、二つの成分、「進入LS」(別名「TGREP受信機」)と「出力LS」があります。 TGREP受信コンポーネントは、1つ以上のゲートウェイとTGREPピアリング関係を維持します。ゲートウェイから受信したルーティング情報は、順番にTRIP上のネットワークの他の部分に発信退出LSに注入されます。便宜のために、ゲートウェイとGWは、交換可能に使用されます。

This configuration is depicted graphically in Figure 1.


                     Signaling                 TGREP
                   ------------->          <----------------
                                                 |         |
                                                 |   GW    |
                                              >  +---------+
    SIP                                 //       +---------+
   <---->                             //         |         |
      +-------------------------+   //           |   GW    |
      |                         | //             +---------+
      |    +-------------+      |/
      |    |             |      |
      |    |  Routing    |      |                +---------+   TO PSTN
      |    |   Proxy     |      |                |         |
   --->    |             |      |----------->    |   GW    | ----->
      |+---+-----+ +-----+----+ |                +---------+
      ||         | |          | |
      ||        <+-+          | |--
      ||Egress LS| |Ingress LS| |  ---           +---------+
      ||         | |          | |     --         |         |
      |+---------+ +----------+ |       --       |   GW    |
      |                         |         --     +---------+
      |                         |           -->
    TRIP                                         +---------+
   <---->                                        |         |
                                                 |   GW    |

Figure 1: Gateway and LS Configuration


The decision about which gateway to use depends on many factors, including their availability, remaining call capacity, and call success statistics to a particular Public Switched Telephone Network (PSTN) destination (see [14]). For the proxy to do this adequately, it needs to have access to this information in real-time, as it changes. This means there must be some kind of communications between the proxy and the gateways to convey this information.


The TRIP protocol [2] is defined for carrying telephony routing information between providers, for the purposes of getting a call routed to the right provider for termination to the PSTN. However, there is no mechanism defined in TRIP that defines how routes get injected into the TRIP protocol from within the network. Nor does it define mechanisms that would allow the provider to select the specific gateway for terminating a call when it arrives. Those gaps are filled by TGREP.

[2] TRIPプロトコルは、PSTNへの終了を右プロバイダにルーティングされるコールを取得する目的で、プロバイダとの間の電話ルーティング情報を運ぶために定義されます。しかし、ルートがネットワーク内からTRIPプロトコルに注入取得方法を定義TRIPに定義されたメカニズムはありません。また、それは、プロバイダが、それが到着したときに通話を終了するための特定のゲートウェイを選択することができるようになるメカニズムを定義しません。これらのギャップはTGREPによって満たされています。

TGREP allows PSTN gateways or soft switches to inform a signaling server, such as a SIP proxy server or H.323 gatekeeper, of routes it has to the PSTN. These advertisements include fairly dynamic information, such as the remaining capacity in a particular trunk, which is essential for selecting the right gateway.


TGREP is identical in syntax and overall operation to TRIP. However, it differs in the route processing rules followed by the TGREP receiver, allowing for a route processing function called "consolidation". Consolidation combines multiple routes for the same route destination with different attributes to a single route to prevent loss of routing information. TGREP also defines a set of new attributes, usable by TGREP or TRIP. Finally, TGREP only utilizes a subset of overall TRIP capabilities. Specifically, certain attributes are not utilized (as described below), and the TGREP entities (the sender and receiver) operate in an asymmetric relationship, whereas TRIP allows symmetric and asymmetric.

TGREPは、旅行に構文や全体的な動作は同じです。しかし、「連結」と呼ばれるルート処理機能を可能にする、TGREP受信続く経路処理ルールが異なります。統合は、ルーティング情報の損失を防止するために、単一の経路に異なる属性を持つ同じルート先の複数の経路を組み合わせ。 TGREPもTGREPまたはTRIPによって使用可能な、新たな属性の集合を定義します。最後に、TGREPは、全体的なTRIP機能のサブセットを利用しています。具体的には(後述のように)、特定の属性が使用されない、及びTRIPは、対称および非対称可能一方TGREPエンティティ(送信側と受信側)は、非対称な関係で動作します。

As a general rule, because of a lot of similarities between TRIP and TGREP, frequent reference will be made to the terminologies and formats defined in TRIP [2]. It is suggested that the reader be familiar with the concepts of TRIP like attributes, flags, route types, address families, etc.

原則として、なぜならTRIPとTGREP間の類似性のロットの、頻繁に参照がTRIP [2]で定義された用語およびフォーマットについて説明します。読者がなどの属性、フラグ、ルートタイプ、アドレスファミリ、のようなTRIPの概念に精通していることが示唆されました

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].

この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[1]。

Some other useful definitions are:


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, consisting 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 the establishment of 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 the establishment of connections within or between switching systems in which 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
3. TGREP:操作の概要

TGREP is a route registration protocol for telephony destinations on a gateway. These telephony destinations could be prefixes, trunkgroups, or carriers. The TGREP sender resides on the GW and gathers all the information from the GW to relay to the TRIP Location Server. A TGREP Receiver is defined, which receives this information and optionally performs operations like consolidation and aggregation (see Section 7.3), and hands over the reachability information to a TRIP Location Server. The routing proxy also uses the information to select the gateway for incoming calls.

TGREPは、ゲートウェイ上のテレフォニー目的地のルート登録プロトコルです。これらのテレフォニー先は接頭辞、trunkgroups、またはキャリアである可能性があります。 TGREPの送信者は、GWに常駐し、TRIPのロケーションサーバにリレーするようにGWからすべての情報を収集します。必要に応じてこの情報を受信し、定義されTGREP Receiverは、TRIPロケーション・サーバに到達可能性情報上に統合し、凝集などの操作(7.3節を参照)、及び手を行います。ルーティングプロキシは、着信呼のためのゲートウェイを選択するために情報を使用します。

The TGREP sender establishes a session to the TGREP receiver using a procedure similar to session establishment in TRIP. After the session establishment, the TGREP sender sends the reachability information in the UPDATE messages. The UPDATE messages have the same format as in TRIP. However, certain TRIP attributes are not relevant in TGREP; a TGREP receiver MAY ignore them if they are present in a TGREP message. The following TRIP attributes do not apply to TGREP:

TGREP送信者は、TRIPのセッション確立と同様の手順を使用してTGREP受信機とのセッションを確立します。セッション確立後、TGREPの送信者は、UPDATEメッセージに到達可能性情報を送信します。 UPDATEメッセージは、TRIPと同じフォーマットを有します。しかし、特定のTRIP属性がTGREPには関係ありません。彼らはTGREPメッセージに存在している場合TGREP受信機はそれらを無視するかもしれません。次TRIP属性がTGREPには適用されません。

1. AdvertisementPath 2. RoutedPath 3. AtomicAggregate 4. LocalPreference 5. MultiExitDisc 6. ITADTopology 7. ConvertedRoute

1. AdvertisementPath 2. RoutedPath 3. AtomicAggregate 4. LocalPreference 5. MultiExitDisc 6. ITADTopology 7. ConvertedRoute

In addition, TGREP defines the following new attributes in this document that can be carried in a TGREP UPDATE message.

また、TGREPはTGREP UPDATEメッセージ中で実施することができる。この文書に記載されている次の新しい属性を定義します。

- TotalCircuitCapacity: This attribute identifies the total number of PSTN circuits that are available on a route to complete calls.

- TotalCircuitCapacity:この属性は、呼び出しを完了するために、ルート上で利用可能なPSTN回線の総数を特定します。

- AvailableCircuits: This attribute identifies the number of PSTN circuits that are currently available on a route to complete calls.

- AvailableCircuits:この属性は、呼び出しを完了するために、ルート上で現在利用可能なPSTN回線の番号を識別します。

- CallSuccess: This attribute represents information about the number of normally terminated calls out of a total number of attempted calls.

- CallSuccess:この属性は、試行されたコールの総数のうち正常に終了コール数についての情報を表します。

- Prefix (E164): This attribute is used to represent the list of E164 prefixes to which the respective route can complete calls.

- プレフィックス(E164):この属性は、それぞれのルートが呼び出しを完了することができたE164プレフィックスのリストを表すために使用されます。

- Prefix (Decimal Routing Number): This attribute is used to represent the list of Decimal prefixes to which the respective route can complete calls.

- プレフィックス(小数点ルーティング番号):この属性は、それぞれのルートが呼び出しを完了することができたに進接頭辞のリストを表すために使用されます。

- Prefix (Hexadecimal Routing Number): This attribute is used to represent the list of Hexadecimal prefixes to which the respective route can complete calls.

- プレフィックス(16進数ルーティング番号):この属性は、そのそれぞれのルートが呼び出しを完了できるために進接頭辞のリストを表すために使用されます。

- TrunkGroup: This attribute enables providers to route calls to destinations through preferred trunks.

- TrunkGroup:この属性が優先トランクを使用して宛先へのコールをルーティングするようにプロバイダーを可能にします。

- Carrier: This attribute enables providers to route calls to destinations through preferred carriers.

- キャリア:この属性は、好ましい担体て目的地へのコールをルーティングするようにプロバイダーを可能にします。

In the rest of the document, we specify attributes and address families used in TGREP. The new attributes and address families introduced are also applicable for general usage in TRIP except where noted (AvailableCircuits attribute, for example).


4. TGREP Attributes
4. TGREP属性

Due to its usage within a service provider network, TGREP makes use of a subset of the attributes defined for TRIP, in addition to defining several new ones. In particular, the following attributes from TRIP are applicable to TGREP:


1. WithdrawnRoutes 2. ReachableRoutes 3. NexthopServer 4. Prefix 5. Communities

1. WithdrawnRoutes 2. ReachableRoutes 3. NexthopServer 4.プレフィックス5.コミュニティ

TGREP also defines several new attributes, described in this section. These are TotalCircuitCapacity, AvailableCircuits, CallSuccess, TrunkGroup, and Carrier. As mentioned above, these new attributes are usable by TRIP unless noted otherwise.


A TGREP UPDATE supports the following attributes:


1. TotalCircuitCapacity 2. AvailableCircuits 3. CallSuccess 4. Prefix (E.164, Pentadecimal routing number, Decimal routing number) 5. TrunkGroup 6. Carrier

1. TotalCircuitCapacity 2. AvailableCircuits 3. CallSuccess 4.プレフィックス(E.164、十五進法ルーティング番号、進ルーティング番号)5. TrunkGroup 6キャリア

4.1. TotalCircuitCapacity Attribute
4.1. TotalCircuitCapacity属性

Mandatory: False. Required Flags: Not well-known. Potential Flags: None. TRIP Type Code: 13.

必須:偽。必要なフラグ:よく知られていません。潜在的なフラグ:なし。 TRIPタイプコード:13。

The TotalCircuitCapacity attribute identifies the total number of PSTN circuits that are available on a route to complete calls. It is used in conjunction with the AvailableCircuits attribute in gateway selection by the LS. The total number of calls sent to the specified route on the gateway cannot exceed this total circuit capacity under steady state conditions.


The TotalCircuitCapacity attribute is used to reflect the administratively provisioned capacity as opposed to the availability at a given point in time as provided by the AvailableCircuits attribute. Because of its relatively static nature, this attribute MAY be propagated beyond the LS that receives it.


TotalCircuitCapacity represents the total number of possible calls at any instant. This is not expected to change frequently. This can change, for instance, when certain telephony trunks on the gateway are taken out of service for maintenance purposes.


4.1.1. TotalCircuitCapacity Syntax
4.1.1. 構文TotalCircuitCapacity

The TotalCircuitCapacity attribute is a 4-octet unsigned integer. It represents the total number of circuits available for terminating calls through this advertised route. This attribute represents 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
4.1.2. ルートオリジネーションとTotalCircuitCapacity

Routes MAY be originated containing the TotalCircuitCapacity attribute.


4.1.3. Route Selection and TotalCircuitCapacity
4.1.3. ルート選択とTotalCircuitCapacity

The TotalCircuitCapacity attribute MAY be used for route selection. Since one of its primary applications is load balancing, an LS will wish to choose a potentially different route (amongst a set of routes for the same destination), on a call-by-call basis. This can be modeled as re-running the decision process on the arrival of each call. The aggregation and dissemination rules for routes with this attribute ensure that re-running this selection process never results in propagation of a new route to other peers.


4.1.4. Aggregation and TotalCircuitCapacity
4.1.4. 集約とTotalCircuitCapacity

An LS MAY aggregate routes to the same prefix that contains a TotalCircuitCapacity attribute. It SHOULD add the values of the individual routes to determine the value for the aggregated route in the same ITAD.


4.1.5. Route Dissemination and TotalCircuitCapacity
4.1.5. ルート普及とTotalCircuitCapacity

Since this attribute reflects the static capacity of the gateway's circuit resources, it is not expected to change frequently. Hence, the LS receiving this attribute MAY disseminate it to other peers, both internal and external to the ITAD.


4.2. AvailableCircuits Attribute
4.2. AvailableCircuits属性

Mandatory: False. Required Flags: Not well-known. Potential Flags: None. TRIP Type Code: 14.

必須:偽。必要なフラグ:よく知られていません。潜在的なフラグ:なし。 TRIPタイプコード: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 cannot exceed the circuit capacity. If it does, the signaling protocol will likely generate errors, and calls will be rejected.


The AvailableCircuits attribute is used ONLY between a gateway and its peer LS responsible for managing that gateway. If it is received in a route, it is not propagated.


4.2.1. AvailableCircuits Syntax
4.2.1. AvailableCircuits構文

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
4.2.2. ルートオリジネーションとAvailableCircuits

Routes MAY be originated containing the AvailableCircuits attribute. Since this attribute is highly dynamic, changing with every call, updates MAY be sent as it changes. However, it is RECOMMENDED that measures be taken to help reduce the messaging load from route origination. It is further RECOMMENDED that a sufficiently large window of time be used to provide a useful aggregated statistic.


4.2.3. Route Selection and AvailableCircuits
4.2.3. ルート選択とAvailableCircuits

The AvailableCircuits attribute MAY be used for route selection. Since one of its primary applications is load balancing, an LS will wish to choose a potentially different route (amongst a set of routes for the same prefix) on a call-by-call basis. This can be modeled as re-running the decision process on the arrival of each call. The aggregation and dissemination rules for routes with this attribute ensure that re-running this selection process never results in propagation of a new route to other peers.


4.2.4. Aggregation and AvailableCircuits
4.2.4. 集約とAvailableCircuits

Not applicable.


4.2.5. Route Dissemination and AvailableCircuits
4.2.5. ルート普及とAvailableCircuits

Routes MUST NOT be disseminated with the AvailableCircuits attribute. The attribute is meant to reflect capacity at the originating gateway only. Its highly dynamic nature makes it inappropriate to disseminate in most cases.


4.3. CallSuccess Attribute
4.3. CallSuccess属性

Mandatory: False. Required Flags: Not well-known. Potential Flags: None. TRIP Type Code: 15.

必須:偽。必要なフラグ:よく知られていません。潜在的なフラグ:なし。 TRIPタイプコード:15。

The CallSuccess attribute is an attribute used ONLY between a gateway and its peer LS responsible for managing that gateway. If it is received in a route, it is not propagated.


The CallSuccess attribute provides information about the number of normally terminated calls out of a total number of attempted calls.


CallSuccess is to be determined by the gateway based on the Disconnect cause code at call termination. For example, a call that reaches the Alerting stage but does not get connected due to the unavailability of the called party, or the called party being busy, is conventionally considered a successful call. On the other hand, a call that gets disconnected because of a circuit or resource being unavailable is conventionally considered a failed call. The exact mapping of disconnect causes to CallSuccess is at the discretion of the gateway reporting the attribute.

CallSuccessは、コール終了時に切断原因コードに基づいて、ゲートウェイによって決定されるべきです。たとえば、アラートの段階に到達したが、被呼者、または話中着信側の使用不能に起因して接続されないコールは、従来、呼び出しが成功と見なされます。一方、利用できないためである回路またはリソースの切断された呼は、通常失敗したコールであると考えられます。 CallSuccessに切断原因の正確なマッピングは、属性を報告するゲートウェイの裁量です。

The CallSuccess attribute is used by the LS to keep track of failures in reaching certain telephony destinations through a gateway(s) and to use that information in the gateway selection process to enhance the probability of successful call termination.


This information can be used by the LS to consider alternative gateways to terminate calls to those destinations with a better likelihood of success.


4.3.1. CallSuccess Syntax
4.3.1. CallSuccess構文

The CallSuccess attribute is composed of two component fields -- each represented as a 4-octet unsigned integer. The first component field represents 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 represents the total number of attempted calls for the advertised destination within the same window of time.

4オクテットの符号なし整数として表される各 - CallSuccess属性は、二つの成分のフィールドから構成されています。最初のコンポーネントのフィールドは、所与の時間窓の上に与えられたアドレスファミリのアドバタイズされた宛先に正常に終了したコールの合計数を表します。第二の成分のフィールドは、同じ時間ウィンドウ内でアドバタイズ宛先の試行されたコールの合計数を表します。

When the value for the total number of attempted calls wraps around, the counter value for the number of successful calls is reset to keep it aligned with the other component over a given window of time. The TGREP receiver using this information should obtain this information frequently enough to prevent loss of significance.


4.3.2. Route Origination and CallSuccess
4.3.2. ルートオリジネーションとCallSuccess

Routes MAY be originated containing the CallSuccess attribute. This attribute is expected to get statistically significant with passage of time as more calls are attempted. It is RECOMMENDED that sufficiently large windows be used to provide a useful aggregated statistic.


4.3.3. Route Selection and CallSuccess
4.3.3. ルート選択とCallSuccess

The CallSuccess attribute MAY be used for route selection. This attribute represents a measure of success of terminating calls to the advertised destination(s). This information MAY be used to select from amongst a set of alternative routes to increase the probability of successful call termination.


4.3.4. Aggregation and CallSuccess
4.3.4. 集約とCallSuccess

Not applicable.


4.3.5. Route Dissemination and CallSuccess
4.3.5. ルート普及とCallSuccess

Routes MUST NOT be disseminated with the CallSuccess attribute. Its potential to change dynamically does not make it suitable to disseminate.


4.4. Prefix Attributes
4.4. プレフィックスの属性

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.

必須:偽。必要なフラグ:よく知られていません。潜在的なフラグ:なし。 TRIPタイプコード:10進数ルーティング番号プレフィックスのE164プレフィックス、十五進法ルーティング番号プレフィックスの17、及び18のための16。

The Prefix attribute is used to represent the list of prefixes to which the respective route can complete calls. This attribute is intended to be used with the Carrier or TrunkGroup address family (discussed in Section 5).


Though it is possible that all prefix ranges may be reachable through a given carrier, administrative issues could make certain ranges preferable to others.


4.4.1. Prefix Attribute Syntax
4.4.1. 接頭辞属性の構文

The Prefix attribute could be E.164, Decimal, or Pentadecimal (refer to TRIP [2]), each of them having its own type code. The Prefix attribute is encoded as a sequence of prefix values in the attribute Value field. The prefixes are listed sequentially with no padding as shown in Figure 2. Each prefix includes a 2-octet Length field that represents the length of the Address field in octets. The order of prefixes in the attribute is not significant.

prefix属性は、それらのそれぞれが独自のタイプコードを有する、([2]旅行参照)E.164、進数、又は十五進法であってもよいです。 prefix属性は、属性値]フィールドにプレフィックス値のシーケンスとして符号化されています。各プレフィックスは、オクテットのアドレスフィールドの長さを表す2オクテットの長さフィールドを含む図2に示すように、接頭辞のないパディングで連続的に記載されています。属性内の接頭辞の順序は重要ではありません。

The presence of the Prefix Attribute with the Length field of the attribute as 0 signifies that the TGREP GW can terminate ALL prefixes of that prefix type (E.164, Decimal, or Pentadecimal) for the given Reachable route(s). This is not equivalent to excluding the Prefix attribute in the TGREP update.

0 TGREP GWが所定の到達可能経路(S)のためにそのプレフィックスタイプ(E.164、進数、又は十五進法)の全てのプレフィックスを終了することができることを意味するようにプレフィックスの存在は、属性の長さフィールドと属性。これはTGREPアップデートでprefix属性を除くと同等ではありません。

< 2 octets > < Length1 octets > < 2 octets > < Length2 octets >

<2つのオクテット> <長さ1オクテット> <2つのオクテット> <LENGTH2オクテット>

   |   Length1  |    Prefix1       |   Length2  |   Prefix2        | ...

Figure 2: Prefix Format


4.4.2. Route Origination and Prefix
4.4.2. ルートオリジネーションおよびプレフィックス

Routes MAY be originated containing the Prefix attribute.


4.4.3. Route Selection and Prefix
4.4.3. ルート選択とプレフィックス

The Prefix attribute MAY be used for route selection.


4.4.4. Aggregation and Prefix
4.4.4. 集約とプレフィックス

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 attached to the aggregated object.

異なるプレフィックス属性を持つルートは集約されてはなりません。 prefix属性に同じ値を持つルートが集約されてもよく、同じプレフィックスの属性は、集約オブジェクトに取り付けられました。

4.4.5. Route Dissemination and Prefix
4.4.5. ルート普及とプレフィックス

The LS receiving this attribute should disseminate to other peers, both internal and external to the ITAD.


4.5. TrunkGroup Attribute
4.5. TrunkGroup属性

Mandatory: False. Required Flags: Not well-known. Potential Flags: None. TRIP Type Code: 19.

必須:偽。必要なフラグ:よく知られていません。潜在的なフラグ:なし。 TRIPタイプコード:19。

The TrunkGroup attribute is used to represent the list of trunkgroups on the gateway used to complete calls. It enables providers to route calls to destinations through preferred trunks. This attribute is relatively static.


4.5.1. TrunkGroup Syntax
4.5.1. TrunkGroup構文

The TrunkGroup attribute is a variable-length attribute that is composed of a sequence of trunkgroup identifiers. It indicates that the gateway can complete the call through any trunkgroup identifier indicated in the 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 a variable-length field consisting of two subfields, a trunkgroup label followed by a trunk context, the two subfields separated by the delimiter ";" (semicolon). Both the trunkgroup label and the trunk context subfields are of variable length. The Length field represents the total size of the Value field including the delimiter.

各trunkgroup識別子は、(図3以下に示す)長さ - 値フィールドとして符号化されます。 Lengthフィールドは1オクテットの符号なしの数値です。 Valueフィールドは、2つのサブフィールド、トランクコンテキスト続いtrunkgroupラベル、区切り文字で区切られた2つのサブフィールドからなる可変長フィールドです「;」 (セミコロン)。 trunkgroupラベルやトランクコンテキストサブフィールドの両方が可変長です。 Lengthフィールドは、区切り記号を含む値フィールドの合計サイズを表します。

The permissible character set for the trunk group label and the trunkgroup context subfields and the associated ABNF [8] is per rules outlined in [4].

トランクグループラベルの許容文字セットとtrunkgroupコンテキストサブフィールドと関連したABNF [8]に概説ルールごとである[4]。

The presence of the TrunkGroup attribute with the Length field of the attribute as 0 signifies that the TGREP GW can terminate ALL trunkgroups for the given Reachable route(s).

0として、属性の長さフィールドを持つTrunkGroup属性の存在はTGREP GWは、所与の到達可能経路(S)のためにALL trunkgroupsを終了することができることを意味します。

< 1 octet > < Length1 octets > < 1 octet > < Length2 octets >

<1オクテット> <長さ1オクテット> <1オクテット> <LENGTH2オクテット>

   |  Length1  |  TrunkGroup 1    |  Length2  |  TrunkGroup 2    | ...

Figure 3: TrunkGroup Syntax


4.5.2. Route Origination and TrunkGroup
4.5.2. ルートオリジネーションとTrunkGroup

Routes MAY be originated containing the TrunkGroup attribute.


4.5.3. Route Selection and TrunkGroup
4.5.3. ルート選択とTrunkGroup

The TrunkGroup attribute MAY be used for route selection. Certain trunkgroups MAY be preferred over others based on provider policy.


4.5.4. Aggregation and TrunkGroup
4.5.4. 集約と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 attached to the aggregated object.

TrunkGroup属性が異なるルートは集約されてはなりません。 TrunkGroup属性に同じ値を持つルートが集約されてもよく、同じTrunkGroup属性が集約オブジェクトに取り付けられました。

4.5.5. Route Dissemination and TrunkGroup
4.5.5. ルート普及とTrunkGroup

This attribute is not expected to change frequently. Hence, the LS receiving this attribute MAY disseminate it to other peers, internal to ITAD. Routes SHOULD not be disseminated external to the ITAD, with TrunkGroup attribute.


4.6. Carrier Attribute
4.6. キャリア属性

Mandatory: False. Required Flags: Not well-known. Potential Flags: None. TRIP Type Code: 20.

必須:偽。必要なフラグ:よく知られていません。潜在的なフラグ:なし。 TRIPタイプコード:20。

The Carrier attribute is used to represent the list of carriers that the gateway uses to complete calls. It enables providers to route calls to destinations through preferred carriers. This attribute is relatively static.


4.6.1. Carrier Syntax
4.6.1. キャリア構文

The Carrier attribute is a variable-length attribute that is composed of a sequence of carrier identifiers. It indicates that the route can complete the call to any of the carriers represented in the 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 a variable-length field.

各キャリア識別子は、(図4以下に示す)長さ - 値フィールドとして符号化されます。 Lengthフィールドは1オクテットの符号なしの数値です。 Valueフィールドは可変長フィールドです。

The permissible character set for the Value field and the associated ABNF [8] is per rules outlined in [5]. Specifically, it carries "global-cic" or "local-cic" [5]. In case of "local-cic", the "phonedigit-hex" part and the "cic-context" part would be separated by the delimiter ";". Hence, absence or presence of the delimiter can be used to determine if the value is a "global-cic" or a "local-cic". The Length field represents the total size of the Value field including the delimiter.

Valueフィールドの許容文字セットと関連するABNF [8] [5]に概説ルールごとです。具体的には、「グローバルCIC」または「ローカルCIC」を担持する[5]。 「ローカルCIC」の場合、「phonedigit-ヘクス」部分と「CICコンテキスト」部分はデリミタによって分離されます「;」。したがって、デリミタの有無は、値が「グローバルCIC」または「ローカルCIC」であるかどうかを決定するために使用することができます。 Lengthフィールドは、区切り記号を含む値フィールドの合計サイズを表します。

The presence of the Carrier attribute with the Length field of the attribute as 0 signifies that the TGREP GW can terminate ALL Carriers for the given Reachable route(s).

0として、属性の長さフィールドを持つキャリア属性の存在はTGREP GWは、所与の到達可能経路(S)のためのすべてのキャリアを終了することができることを意味します。

< 1 octet > < Length1 octets > < 1 octet > < Length2 octets >

<1オクテット> <長さ1オクテット> <1オクテット> <LENGTH2オクテット>

   |  Length1  |  Carrier 1       |  Length2  |  Carrier 2       | ...

Figure 4: Carrier Syntax


4.6.2. Route Origination and Carrier
4.6.2. ルートオリジネーションとキャリア

Routes MAY be originated containing the Carrier attribute.


4.6.3. Route Selection and Carrier
4.6.3. ルート選択とキャリア

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
4.6.4. 集約とキャリア

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 attached to the aggregated object.


4.6.5. Route Dissemination and Carrier
4.6.5. ルート普及とキャリア

This attribute is not expected to change frequently. Hence, the LS receiving this attribute MAY disseminate it to other peers, both internal and external to the ITAD.


5. TrunkGroup and Carrier Address Families
5. TrunkGroupとキャリアアドレスファミリー

As described in TRIP [2], the Address Family field gives the type of address for the route. Two new address families and their codes are defined in this section:

TRIP [2]に記載のように、アドレスファミリフィールドは、ルートのアドレスの種類を与えます。二つの新しいアドレスファミリとそのコードは、このセクションで定義されています。

               Code              Address Family
               4                 TrunkGroup
               5                 Carrier

When a set of GWs is to be managed at the granularity of carriers or trunkgroups, then it may be more appropriate for a GW to advertise routes using the Carrier address family or TrunkGroup address family, respectively. Also, in a TGREP association between the gateway and the LS responsible for managing that gateway, there are some attributes that more naturally fit in as advertised properties of trunkgroups or carriers rather than that of advertised prefixes, for example, the AvailableCircuit information on a particular trunkgroup or a particular carrier. To express this relationship, the existing TRIP address families are inadequate. We need separate address families that can associate certain properties like AvailableCircuits information to trunkgroups or carriers.


The primary benefits of this model are as follows:


- It allows a service provider to route calls based strictly on the trunkgroups or carriers.

- それは厳密にtrunkgroupsまたはキャリアに基づいてコールをルーティングサービスプロバイダを可能にします。

- It facilitates more accurate reporting of attributes of a dynamic nature like AvailableCircuits by providing the ability to manage resources at the granularity of a trunkgroup or a carrier.

- それはtrunkgroupやキャリアの粒度でリソースを管理する機能を提供することにより、AvailableCircuitsのような動的な性質の属性のより正確な報告を容易にします。

- It enables scalability as gateways can get really large with the ability to provision hundreds or a few thousand circuits, and this can increase the potential for traffic that reports dynamic resource information between the gateway and the LS. The model introduced can potentially alleviate this UPDATE traffic, hence increasing efficiency and providing a scalable gateway registration model.

- ゲートウェイが提供数百または数千の回路への能力を持つ非常に大きな得ることができるように、それは、スケーラビリティを可能にし、これは、ゲートウェイとLSの間の動的なリソース情報を報告し、トラフィックの可能性を高めることができます。導入されたモデルは、潜在的に効率を高め、スケーラブルゲートウェイ登録モデルを提供するため、この更新トラフィックを軽減することができます。

5.1. Address Family Syntax
5.1. 家族の構文を住所

Consider the generic TRIP route format from TRIP [2] shown below.

以下に示すTRIP [2]から、ジェネリックTRIPルート形式を考えます。

       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 Format


The Address Family field will be used to represent the type of the address associated for this family, which is based on the TrunkGroup or Carrier. The codes for the new address families have been allocated by IANA.


The code for the TrunkGroup address family is 4, and the code for the Carrier address family is 5.


The Application Protocol field is the same as the one for the Decimal, Pentadecimal, and E.164 address families defined in TRIP [2]. The Length field represents the total size of the Address field in bytes.

アプリケーションプロトコルフィールドは、TRIPで定義された進数、十五進法、およびE.164アドレス家族のためのものと同じである[2]。 Lengthフィールドは、バイト単位でアドレスフィールドの合計サイズを表します。

The value in the Address field represents either the TrunkGroup or Carrier address family, and the syntax is as follows:


For the TrunkGroup address family, the Address field represents a TrunkGroup value that is defined as specified in Section 4.5.1, "TrunkGroup Syntax".


For the Carrier address family, the Address field represents a Carrier value. This is the same as the Value field specified in an earlier Section 4.6.1, "Carrier Syntax".


The above mentioned address families are not hierarchical, but flat. If a gateway supports any of these address families, it should include that address family as one of the Route types supported in the OPEN message capability negotiation phase.


The following attributes are currently defined to be used with all the address families including the TrunkGroup and Carrier address families.


- AvailableCircuits attribute - TotalCircuitCapacity attribute - CallSuccess attribute

- AvailableCircuits属性 - TotalCircuitCapacity属性 - CallSuccess属性

It is recommended that the above three attributes be used by the gateway with the TrunkGroup or Carrier address family, if possible. This will potentially offer a more efficient resource reporting framework, and a scalable model for gateway provisioning.


However, when the gateway is not using the TrunkGroup or Carrier address family, it MAY use the above 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

A gateway uses TGREP to advertise its reachability to its domain's Location Server(s) (LS, which are closely coupled with proxies). The gateway operates in TRIP Send Only mode since it is only interested in advertising its reachability, but is not interested in learning about the reachability of other gateways and other domains. Also, the gateway will not create its own call routing database. In this section, we describe the operation of TGREP on a gateway.


6.1. Session Establishment
6.1. セッションの確立

When opening a peering session with a TGREP receiver, a TGREP gateway follows exactly the same procedures as any other TRIP entity. The TGREP gateway sends an OPEN message that includes a Send Receive Capability in the Optional Parameters. The Send Receive Capability is set by the gateway to Send Only. The OPEN message also contains the address families supported by the gateway. The remainder of the peer session establishment is identical to TRIP.

TGREP受信機とのピアリングセッションを開くとき、TGREPゲートウェイは、他のTRIPエンティティとまったく同じ手順に従います。 TGREPゲートウェイが送信オプションパラメータでの受信機能を備えてOPENメッセージを送信します。送信、受信能力をのみ送信するためのゲートウェイで設定されています。 OPENメッセージは、ゲートウェイでサポートされているアドレスファミリが含まれています。ピアセッション確立の残りの部分は、TRIPと同一です。

6.2. UPDATE Messages
6.2. UPDATEメッセージ

Once the peer session has been established, the gateway sends UPDATE messages to the TRIP LS with the gateway's entire reachability. The gateway also sends any attributes associated with the routes.

ピアセッションが確立されると、ゲートウェイは、ゲートウェイの全体の到達可能性とTRIP LSにUPDATEメッセージを送信します。ゲートウェイは、ルートに関連付けられたすべての属性を送信します。

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.

ゲートウェイでUPDATEメッセージのTGREP処理TRIP [2]の処理を更新することと同一です。 TGREPの送信者は、すべての必須TRIP属性をサポートしなければなりません。

6.3. KEEPALIVE Messages
6.3. キープアライブメッセージ

KEEPALIVE messages are periodically exchanged over the peering session between the TGREP gateway and the TRIP LS as specified in Section 4.4 of TRIP [2].

TRIPのセクション4.4で指定されるようにキープアライブメッセージを定期的TGREPゲートウェイとTRIP LSとの間のピアリングセッションを介して交換される[2]。

6.4. Error Handling and NOTIFICATION Messages
6.4. エラー処理と通知メッセージ

The same procedures used with TRIP are used with TGREP for error handling and generating NOTIFICATION messages. The only difference is that a TGREP gateway will never generate a NOTIFICATION message in response to an UPDATE message, irrespective of the contents of the UPDATE message. Any UPDATE message is silently discarded.


6.5. TGREP Finite State Machine
6.5. TGREP有限ステートマシン

When the TGREP finite state machine is in the Established state and an UPDATE message is received, the UPDATE message is silently discarded and the TGREP gateway remains 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
6.6. ルーティングデータベースを呼び出し

A TGREP gateway may maintain simultaneous sessions with more than one TRIP LS. A TGREP gateway maintains one call routing database per peer TRIP LS. These databases are equivalent to TRIP's Adj-TRIBs-Out, and hence we will call them Adj-TRIBs-GW-Out. An Adj-TRIB-GW-Out contains the gateway's reachability information 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).

TGREPゲートウェイは、複数のTRIPのLSとの同時セッションを維持することができます。 TGREPゲートウェイは、ピアトリップLSあたりデータベースルーティングコールを1つ保持します。これらのデータベースは、TRIPの調整]-TRIBsアウトと同等であるので、我々は調整] - TRIBs-GWアウトそれらを呼び出します。調整] - TRIB-GWアウトは、そのピアTRIPのLSにアドバタイズゲートウェイの到達可能性情報が含まれています。方法のAdj-TRIB-GWアウトデータベースが移入されます(おそらく手動設定による)、この文書の範囲外です。

The TGREP gateway does not have databases equivalent to TRIP's Adj-TRIBs-In and Loc-TRIB, because the TGREP gateway does not learn routes from its peer TRIP LSs, and hence it does not run call route selection.


6.7. Multiple Address Families
6.7. 複数のアドレスファミリー

As mentioned above, TGREP supports various address families in order to convey the reachability of telephony destinations. A TGREP session MUST NOT send UPDATEs of more than one of the following categories (a) Prefix address families (E164, Pentadecimal, and Decimal), (b) TrunkGroup address family, or (c) Carrier address family for a given established session. TGREP should specify its choice address family through the route-type capability in the OPEN message. And route-type specification in the OPEN message violating the above rule should be rejected with a NOTIFICATION message.

前述したように、TGREPは、電話先の到達可能性を伝えるために、さまざまなアドレスファミリをサポートしています。 TGREPセッションは、次のカテゴリ(a)のプレフィックスアドレスファミリ(E164、十五進法、および10進数)、(b)はTrunkGroupアドレスファミリ、または特定の確立されたセッションのための(c)のキャリアアドレスファミリの複数の更新を送ってはいけません。 TGREPは、OPENメッセージ内のルート型機能を通じて選択アドレスファミリを指定する必要があります。そして、上記のルールに違反OPENメッセージでルート型仕様は、通知メッセージを拒否しなければなりません。

6.8. Route Selection and Aggregation
6.8. ルート選択と集約

TRIP's route selection and aggregation operations MUST NOT be implemented by TGREP gateways.


7. LS/Proxy Behavior
7. LS /プロキシの挙動

As mentioned earlier, TGREP can be considered as a protocol complimentary to TRIP in providing reachability information, which can then be further fed into the Location Server. The architecture of an LS/Proxy system is as follows: There exists a TRIP LS application that functions as a speaker in the I-TRIP/E-TRIP network as documented in TRIP [2]. This component is termed as "Egress LS" for the purposes of this discussion. Then, there is a signaling server fronting a set of gateways. In conjunction with this signaling server is also a second component operating in receive mode, which peers with one or more gateways, each of them using TGREP to advertise routing information. This component on the receiving end of one or more TGREP sessions is termed as the "Ingress LS" or "TGREP receiver" for the purposes of this discussion. Also, the entity (typically, a gateway) advertising the routes on the TGREP session is termed as the "TGREP sender". The TGREP receiver receiving the TRIP messages takes the resulting routing information from each gateway, and "exports" it to another process we define below, that performs consolidation and aggregation, in that order. These operations would take as input the collective set of routes from all the gateways. Subsequently, the resulting TRIB is passed as input into the LS-Egress process as shown below, that can then disseminate these 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.

前述したように、TGREPはその後さらにロケーションサーバに供給することができる到達可能性情報を提供することでトリップする相補プロトコル、と考えることができます。 I-TRIP / E-TRIPネットワークにおけるスピーカとして機能TRIPに記載されているようにTRIPのLSのアプリケーションが存在する[2]:LS /プロキシシステムのアーキテクチャは、以下の通りです。このコンポーネントは、この議論の目的のために「出力LS」と呼ばれます。その後、ゲートウェイのセットに面しシグナリング・サーバがあります。このシグナリングサーバと連携して、それらの各々は、ルーティング情報をアドバタイズするTGREPを使用して、1つまたは複数のゲートウェイとピア受信モードで動作する第2の構成要素でもあります。一つ以上のTGREPセッションの受信側で、このコンポーネントは、この議論の目的のための「進入LS」または「TGREP受信機」と呼ばれます。また、TGREPセッションにルートを広告するエンティティ(通常、ゲートウェイ)「TGREP送信者」と呼ばれています。 TRIPメッセージを受信TGREP受信機は、各ゲートウェイから得られたルーティング情報を取得し、我々はそのために、統合および集合を実行することを、以下に定義する他のプロセスを「エクスポート」を。これらの操作は、入力としてすべてのゲートウェイからのルートの集合的なセットを取るだろう。その後、得られたTRIBは次にTRIP介してこれらを広めることができ、以下に示すように、LS-出口プロセスへの入力として渡されます。 GW(複数可)及びTRIPのLS(出力LS)とピアリングTGREP受信機との間のインターフェース(別名進入LS)は、完全にローカルの問題です。

The nature of the consolidation and aggregation operations and the accompanying motivation are described in the subsections below. The order in which the operations are listed represents an implicit logical sequence in which they are applied. The architecture for an LS/Proxy entity is shown in Figure 6 below.

統合と集約操作の性質及び付随するモチベーションは、以下のサブセクションに記載されています。操作がリストされる順序は、それらが適用される暗黙的な論理配列を表します。 LS /プロキシエンティティのアーキテクチャは、以下の図6に示されています。

    |                    +-------------------------------+  |
    |                    |     +-+  +-+                  |  | 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-GW


7.1. Route Consolidation
7.1. ルートの統合

The TGREP receiver (Ingress LS) may receive routing information from one or more gateways. It is possible that multiple routes are available for the same destination. These different alternative routes may be received from the same gateway or from multiple gateways. It is RECOMMENDED that the set of gateway routes for each destination be consolidated, before presenting a candidate route, to the Egress LS entity. The motivation for this operation should be to define a route that can maximally represent the collective routing capabilities of the set of gateways, managed by this TGREP receiver. Let us take an example scenario in order to bring out the motivation for this operation. Let us say, the TGREP receiver maintains peering sessions 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.

- ゲートウェイAは、キャリア属性値C1とE.164アドレスファミリの目的地「SIP 408」のためのルートをアドバタイズします。

- Gateway B advertises a route for destination "SIP 408" on the E.164 address family with Carrier attribute value C2.

- ゲートウェイBは、キャリア属性値C2とE.164アドレスファミリの「SIP 408」目的地へのルートをアドバタイズ。

The TGREP receiver that receives these routes can consolidate these constituent routes into a single route for destination "SIP 408" with its Carrier attribute being a union of the Carrier attribute values of the individual routes, namely, "C1 C2". This operation is referred to as consolidation. In the above example, it is possible that a route to the destination "SIP 408" through one or more carriers may have been lost if the individual routes were not consolidated.

これらのルートは、そのキャリア属性はキャリアの組合された状態で「SIP 408」目的地のための単一の経路にこれらの構成のルートを統合することができる受信TGREP受信機は、個々の経路、すなわち、「C1 C2」の属性値。この操作は、連結と呼ばれています。上記の例では、個々のルートが統合されなかった場合は、1つのまたは複数のキャリアを介して目的地までの経路「SIP 408」が失われている可能性があります。

Another example is to consolidate the Prefix attribute from multiple Carrier or TrunkGroup updates received from different gateways for the same destination. Let us say, there are Carrier address family (AF) updates from two gateways for Carrier destination X, and the prefix attribute values are {408, 650} from one update and {919, 973} from the other. The prefix values from these two updates can be consolidated into a single Carrier AF route advertisement with prefix value {408, 650, 919, 973}.


In general, there is a potential for loss of gateway routing information when TGREP routes from a set of gateways are not consolidated when a candidate route is presented to the TRIP LS. The specifics of applying the consolidation operation to different attributes and routes from different address families is left to the individual TGREP receiver implementations.

一般的に、候補経路がTRIP LSに提示されたときのゲートウェイのセットからTGREPルートが連結されていませんゲートウェイルーティング情報の損失の可能性があります。異なるアドレスファミリから異なる属性及びルートに統合化動作を適用することの詳細は、個々TGREP受信機の実装に任されています。

7.2. Aggregation
7.2. 集合

The set of gateway routes, which are in a consolidated form or otherwise, may be aggregated before importing it to the LS instance that is responsible for I-TRIP/E-TRIP processing (Egress LS). This operation follows the standard aggregation procedures described in TRIP [2], while adhering to the aggregation rules for each route attribute.

連結形またはさもなければいるゲートウェイルートのセットは、I-TRIP / E-TRIP処理(出力LS)の原因であるLSのインスタンスにインポートする前に集約することができます。各ルート属性の集計規則を守りながら、この動作は、TRIP [2]に記載の標準的な凝集手順に従います。

7.3. Consolidation versus Aggregation
7.3. 集計対統合

To highlight the difference between the two operations discussed above, "consolidation" combines multiple routes for the same route destination, whereas "aggregation" combines routes for different route destinations that qualify as candidates to be summarized resulting in route information reduction.


To take an example, if there are multiple gateways offering routes to an E.164 destination "408" but with possibly different attributes (e.g., Carrier), the LS/Proxy can combine these to form one route for "408" but representing the attribute information collectively. This process is consolidation.

E.164先「408」へのルートを提供する複数のゲートウェイがある場合は、例を取ることが、おそらく異なる属性(例えば、キャリア)と、LS /プロキシは、「408」のための1つの経路を形成するために、これらを組み合わせることが、表現することができます総称属性情報。このプロセスは統合です。

If, for example, the LS/Proxy receives routes for 4080, 4081, 4082, ... 4089 from amongst a set of gateways, it could aggregate these different candidate routes to have a summarized route destination "408" with each of the attributes computed using the aggregation procedures defined in TRIP.

例えば、LS /プロキシゲートウェイのセットの中から、4080、4081、4082、... 4089のルートを受信した場合、その属性のそれぞれに要約ルート先を有するように「408」を、これらの異なる候補経路を集約することができTRIPで定義された集約手順を使用して計算しました。

8. Security Considerations

The security considerations for TGREP are identical to that identified in TRIP [2] and are just restated here for the purposes of clarity.

TGREPのためのセキュリティの考慮事項は、[2] TRIPで特定されたものと同一であり、単に明確化の目的のためにここに修正再表示されます。

The security mechanism for the peering session between TGREP GW and a TRIP LS, in an IP network, is IPsec [3]. IPsec uses two protocols to provide traffic security: Authentication Header (AH) [6] and Encapsulating Security Payload (ESP) [7].

TGREP GWとTRIP LSとの間のピアリング・セッションのセキュリティメカニズムは、IPネットワークでは、IPsecのである[3]。認証ヘッダー(AH)[6]とカプセル化セキュリティペイロード(ESP)[7]:IPsecはトラフィックセキュリティを提供するために、2つのプロトコルを使用しています。

The AH header affords data origin authentication, connectionless integrity, and optional anti-replay protection of messages passed between the peer LSs. The ESP header provides origin authentication, connectionless integrity, anti-replay protection, and confidentiality of messages.

AHヘッダは、データ発信元認証、コネクションレス完全性、およびピアのLSの間で渡されるメッセージのオプションのアンチリプレイ保護を与えます。 ESPヘッダは、発信元認証、コネクションレス完全性、抗再生保護、およびメッセージの機密性を提供します。

Implementations of the protocol defined in this document employing the ESP header SHALL comply with Section 3.1.1 of [10], which defines a minimum set of algorithms for integrity checking and encryption. Similarly, implementations employing the AH header SHALL comply with Section 3.2 of [10], which defines a minimum set of algorithms for integrity checking.


Implementations SHOULD use the Internet Key Exchange Protocol (IKEv2) [9] to permit more robust keying options. Implementations employing IKEv2 SHOULD support 3DES-CBC for confidentiality and HMAC-SHA1 for integrity.

実装は、[9]より堅牢なキーイングオプションを可能にするために、インターネット鍵交換プロトコル(IKEv2の)を使用する必要があります。 IKEv2のを採用した実装は、整合性のために機密性のための3DES-CBCとHMAC-SHA1をサポートする必要があります。

A Security Association (SA) [3] is a simplex "connection" that affords security services to the traffic carried by it. Security services are afforded to an SA by the use of AH or ESP, but not both. Two types of SAs are defined: transport mode and tunnel mode. A transport mode SA is a security association between two hosts, and is appropriate for protecting the TRIP session between two peer LSs.

セキュリティアソシエーション(SA)が[3]、それによって運ばれるトラフィックにセキュリティサービスを提供シンプレックス「接続」です。セキュリティサービスは、両方ではなく、AHまたはESPの使用により、SAに与えています。 SAの二つのタイプが定義されている:トランスポートモードとトンネルモード。トランスポートモードSAは、2つのホスト間のセキュリティアソシエーションであり、2つのピア間のLS TRIPセッションを保護するために適切です。

9. IANA Considerations
9. IANAの考慮事項

Both TRIP [2] and TGREP share the same IANA registry for Capabilities, Attributes, Address Families, and Application Protocols. IANA has added the following attribute codes and address family codes to the TRIP [2] registries.

TRIP [2]及びTGREP両方が機能、属性、アドレスファミリ、およびアプリケーションプロトコルの同じIANAレジストリを共有します。 IANAはTRIP [2]レジストリに以下の属性コードとアドレスファミリのコードを追加しました。

9.1. Attribute Codes
9.1. コード属性

The Attribute Type Codes assigned for 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
9.2. アドレスファミリコード

The following subsections show the codes that have been assigned for the two new address families introduced in this document.


9.2.1. TrunkGroup Address Family
9.2.1. TrunkGroupアドレスファミリ
      Code      Address Family                   Reference
      ----      --------------                   ---------
       4          TrunkGroup                     [RFC5140]
9.2.2. Carrier Address Family
9.2.2. キャリアアドレスファミリ
      Code      Address Family                   Reference
      ----      --------------                   ---------
       5          Carrier                        [RFC5140]
10. Acknowledgments

We wish to thank Vijay Gurbani, Li Li, Kevin McDermott, David Oran, Bob Penfield, Jon Peterson, Anirudh Sahoo, and James Yu for their insightful comments and suggestions.

私たちは、彼らの洞察に満ちたコメントと提案のためのビジェイGurbani、李、ケビン・マクダーモット、デビッド・オラン、ボブペンフィールド、ジョン・ピーターソン、Anirudh Sahoo、そしてジェームズ・ゆうに感謝したいです。

11. References
11.1. Normative References
11.1. 引用規格

[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。

[2] Rosenberg, J., Salama, H., and M. Squire, "Telephony Routing over IP (TRIP)", RFC 3219, January 2002.

[2]ローゼンバーグ、J.、サラマ、H.、およびM.スクワイア、 "オーバーIPテレフォニールーティング(TRIP)"、RFC 3219、2002年1月。

[3] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.

[3]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。

[4] Gurbani, V. and C. Jennings, "Representing Trunk Groups in tel/sip Uniform Resource Identifiers (URIs)", RFC 4904, June 2007.

[4] Gurbani、V.およびC.ジェニングスを、 "TELでトランクグループを表す/ Uniform Resource Identifier(URI)をすする"、RFC 4904、2007年6月。

[5] Yu, J., "Number Portability Parameters for the "tel" URI", RFC 4694, October 2006.

[5]ゆう、J.、TEL "URI "" の番号ポータビリティパラメータ"、RFC 4694、2006年10月。

[6] Kent, S., "IP Authentication Header", RFC 4302, December 2005.

[6]ケント、S.、 "IP認証ヘッダー"、RFC 4302、2005年12月。

[7] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.

[7]ケント、S.、 "IPカプセル化セキュリティペイロード(ESP)"、RFC 4303、2005年12月。

[8] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.

。、STD 68、RFC 5234、2008年1月:[8]クロッカー、D.、エド、およびP. Overell、 "ABNF構文仕様のためのBNFを拡張"。

[9] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.

[9]カウフマン、C.、エド。、 "インターネットキーエクスチェンジ(IKEv2の)プロトコル"、RFC 4306、2005年12月。

[10] Manral, V., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4835, April 2007.

[10] Manral、V.、RFC 4835、2007年4月 "カプセル化セキュリティペイロード(ESP)と認証ヘッダー(AH)のための暗号アルゴリズム実装要件"。

11.2. Informative References
11.2. 参考文献

[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.

[11]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP:セッション開始プロトコル" 、RFC 3261、2002年6月。

[12] Rosenberg, J. and H. Schulzrinne, "A Framework for Telephony Routing over IP", RFC 2871, June 2000.

[12]ローゼンバーグ、J.、およびH. Schulzrinneと、 "IP上テレフォニールーティングの枠組み"、RFC 2871、2000年6月。

[13] ITU-T List of ITU Carrier Codes (published periodically in the ITU-T Operational Bulletin).

ITUキャリアコード(ITU-T動作公報に定期的に発行)の[13] ITU-Tリスト。

[14] Rosenberg, J., "Requirements for Gateway Registration", Work in Progress, November 2001.

[14]ローゼンバーグ、J.、 "ゲートウェイの登録のための要件"、進歩、2001年11月の作品。

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:

Manjunath S.バンガロールのCiscoメールストップSJC-14/2月1日3625シスコウェイサンノゼ、CA 95134電話:+ 1-408-525-7555 Eメール

Rajneesh Kumar Cisco Mail Stop SJC-14/4/2 3625 Cisco Way San Jose, CA 95134 Phone: +1-408-527-6148 EMail:

ラジニーシ・クマールのCiscoメールストップSJC-14/4月2日3625シスコウェイサンノゼ、CA 95134電話:+ 1-408-527-6148 Eメール

Jonathan Rosenberg Cisco Edison, NJ 08837 EMail:

ジョナサン・ローゼンバーグシスコエジソン、NJ 08837 Eメール

Hussein F. Salama Citex Software Giza, Egypt EMail:


Dhaval Niranjan Shah Moowee Inc. 4920 El Camino Real Los Altos, CA 94022 Phone: +1-408-307-7455 EMail:

DhavalシャーNiranjan Moowee株式会社4920エル・カミノレアルロスアルトス、CA 94022電話:+ 1-408-307-7455 Eメール

Full 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.

この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。


この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、(もしあれば)を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。

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.

IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78および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


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は、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。