[要約] RFC 5140は、テレフォニーゲートウェイ登録プロトコル（TGREP）に関する仕様です。TGREPの目的は、テレフォニーゲートウェイの登録と管理を効率化することです。
Network Working Group M. Bangalore
Request for Comments: 5140 R. Kumar
Category: Standards Track J. Rosenberg
Cisco
H. Salama
Citex Software
D.N. Shah
Moowee Inc.
March 2008
A Telephony Gateway REgistration Protocol (TGREP)
テレフォニーゲートウェイ登録プロトコル（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）の現在のエディションを参照してください。このメモの配布は無制限です。
Abstract
概要
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）について説明します。登録メカニズムは、リソース情報のエクスポートにも使用できます。プレフィックスとリソース情報は、IP（Trip）Location Serverを介したテレフォニールーティングに渡すことができます。TGREPは、旅行プロトコルと多くの類似点を共有しています。同様の手順とセッション設立のための有限状態マシンがあります。また、メッセージについて同じ形式と旅行の属性のサブセットも共有しています。
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
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）ネットワークでは、インターネットテレフォニー管理ドメイン（ITAD）は、地理的多様性、能力、および冗長性を目的として、多数のゲートウェイを展開します。コールがドメインに到着すると、それらのゲートウェイの1つにルーティングする必要があります。多くの場合、ITADはネットワークを地理的な存在点（POPS）に分割し、各ポップにはいくつかのゲートウェイとそれらのゲートウェイの前にあるプロキシサーバー要素が含まれています。プロキシ要素は、SIPプロキシ[11]またはH.323 GateKeeperです。プロキシサーバーは、ポップへのアクセスを管理する責任があり、また、どのゲートウェイがポップに到着する特定のコールを受信するかを決定する責任があります。コールシグナリングをルーティングするプロキシサーバーと併せて、「イングレスLS」（「TGREPレシーバー」）と「出口LS」という2つのコンポーネントがあります。TGREPレシーバーコンポーネントは、1つ以上のゲートウェイとのTGREPピアリング関係を維持します。ゲートウェイから受け取ったルーティング情報は、さらに出口LSに注入され、旅行中にネットワークの残りの部分に普及します。便利なため、ゲートウェイとGWは同じ意味で使用されます。
This configuration is depicted graphically in Figure 1.
この構成は、図1にグラフィカルに描かれています。
Signaling TGREP
-------------> <----------------
+---------+
| |
| GW |
> +---------+
//
//
SIP // +---------+
<----> // | |
+-------------------------+ // | GW |
| | // +---------+
| +-------------+ |/
| | | |
| | Routing | | +---------+ TO PSTN
| | Proxy | | | |
---> | | |-----------> | GW | ----->
|+---+-----+ +-----+----+ | +---------+
|| | | | |
|| <+-+ | |--
||Egress LS| |Ingress LS| | --- +---------+
|| | | | | -- | |
|+---------+ +----------+ | -- | GW |
| | -- +---------+
| | -->
+-------------------------+
TRIP +---------+
<----> | |
| GW |
+---------+
Figure 1: Gateway and LS Configuration
図1：ゲートウェイとLS構成
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.
どのゲートウェイを使用するかについての決定は、その可用性、残りのコール容量、特定の公共の切り替え電話ネットワーク（PSTN）の目的地への成功統計を含む多くの要因に依存します（[14]を参照）。プロキシがこれを適切に行うには、変更されているため、この情報にリアルタイムでアクセスできる必要があります。これは、この情報を伝えるために、プロキシとゲートウェイの間に何らかの通信がなければならないことを意味します。
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.
TRIPプロトコル[2]は、PSTNへの終了のために適切なプロバイダーに通話をルーティングする目的で、プロバイダー間でテレフォニールーティング情報を運ぶために定義されます。ただし、旅行では、ネットワーク内からルートが旅行プロトコルに挿入される方法を定義するメカニズムはありません。また、プロバイダーが到着時に呼び出しを終了するための特定のゲートウェイを選択できるメカニズムを定義していません。これらのギャップは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を使用すると、PSTNゲートウェイまたはソフトスイッチが、SIPプロキシサーバーやH.323 GateKeeperなどの信号サーバーにPSTNに持っているルートの通知を許可します。これらの広告には、特定のトランクの残り容量など、適切なゲートウェイを選択するために不可欠なかなり動的な情報が含まれています。
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は、トリップ機能全体のサブセットのみを使用します。具体的には、特定の属性は使用されず（以下に説明するように）、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.
一般的なルールとして、旅行とTGREPの間に多くの類似点があるため、旅行で定義された用語と形式を頻繁に参照します[2]。読者は、属性、フラグ、ルートタイプ、住所家族などのような旅行の概念に精通していることが示唆されています。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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.
回路：回路は、信号を運ぶことができる2つ以上のポイント間の個別の（特定の）パスです。これに関連して、回路は1つ以上のワイヤと場合によっては中間スイッチングポイントで構成される物理パスです。
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.
トランク：ネットワークでは、トランクは、エンドツーエンド接続の確立に使用される2つのスイッチングシステムを接続する通信パスです。選択したアプリケーションでは、同じスイッチングシステムに両方の終端がある場合があります。
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.
TRUNKGROUP：トランクグループは、サブグループ化された場合を除き、すべてのパスが交換可能なスイッチングシステム内またはスイッチングシステム間の接続を確立するために、ユニットとしてエンジニアリングされたトラフィックのセットです。
Carrier: A carrier is a company offering telephone and data communications between points (end-users and/or exchanges).
キャリア：キャリアは、ポイント（エンドユーザーおよび/または交換）間で電話およびデータ通信を提供する会社です。
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は、ゲートウェイ上のテレフォニー宛先用のルート登録プロトコルです。これらのテレフォニーの目的地は、プレフィックス、トランクグループ、またはキャリアです。TGREP送信者はGWに存在し、GWからすべての情報を収集して、Trip Location Serverに中継します。この情報を受信し、オプションで統合や集約などの操作をオプションで実行し（セクション7.3を参照）、到達可能性情報をTrip Location Serverに渡します。ルーティングプロキシは、情報を使用して、着信のゲートウェイを選択します。
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送信者は、旅行中のセッション確立と同様の手順を使用して、TGREPレシーバーへのセッションを確立します。セッションの確立後、TGREP送信者は更新メッセージに到達可能性情報を送信します。更新メッセージは、旅行と同じ形式を持っています。ただし、特定の旅行属性はTGREPには関係ありません。TGREPレシーバーは、TGREPメッセージに存在する場合、それらを無視する場合があります。次の旅行属性は、tgrepには適用されません。
1. AdvertisementPath 2. RoutedPath 3. AtomicAggregate 4. LocalPreference 5. MultiExitDisc 6. ITADTopology 7. ConvertedRoute
1. AdvertisementPath 2.ルーティングパス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アップデートメッセージに伝達できるこのドキュメントの次の新しい属性を定義します。
- 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.
- calluccess：この属性は、通常終了した呼び出しの数に関する情報を表します。
- 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.
- プレフィックス（10進ルーティング番号）：この属性は、それぞれのルートが呼び出しを完了できる小数のプレフィックスのリストを表すために使用されます。
- Prefix (Hexadecimal Routing Number): This attribute is used to represent the list of Hexadecimal prefixes to which the respective route can complete calls.
- プレフィックス（16進ルーティング番号）：この属性は、それぞれのルートが呼び出しを完了できる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).
文書の残りの部分では、TGREPで使用される属性とアドレスファミリを指定します。導入された新しい属性と住所ファミリは、記載されている場合を除き、旅行での一般的な使用にも適用されます（たとえば、availablecircuits属性など）。
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:
サービスプロバイダーネットワーク内での使用により、TGREPは、いくつかの新しいものを定義することに加えて、旅行のために定義された属性のサブセットを使用します。特に、旅行からの次の属性は、TGREPに適用されます。
1. WithdrawnRoutes 2. ReachableRoutes 3. NexthopServer 4. Prefix 5. Communities
1. RectownRoutes 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.
TGREPは、このセクションで説明するいくつかの新しい属性も定義します。これらは、Totalcircuitcapacity、availablecircuits、calluccess、trunkgroup、およびキャリアです。上記のように、これらの新しい属性は、特に明記しない限り、旅行で使用できます。
A TGREP UPDATE supports the following attributes:
TGREPアップデートは、次の属性をサポートしています。
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. calluccess 4. prefix（e.164、pentadecimalルーティング番号、10進ルーティング番号）5。トランクグループ6.キャリア
Mandatory: False. Required Flags: Not well-known. Potential Flags: None. TRIP Type Code: 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.
TotalCircuitCapacity属性は、完全な呼び出しへのルートで利用可能なPSTN回路の総数を識別します。これは、LSによるゲートウェイ選択でavailablecircuits属性と組み合わせて使用されます。ゲートウェイの指定されたルートに送信されるコールの総数は、定常状態条件下でこの回路容量を超えることはできません。
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属性は、AvailableCircuits属性によって提供されるように、特定の時点での可用性とは対照的に、管理的にプロビジョニングされた容量を反映するために使用されます。その比較的静的な性質のため、この属性は、それを受け取るLSを超えて伝播される可能性があります。
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.
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.
TotalCircuitCapacity属性は、4-OCTET Unsigned Integerです。これは、この宣伝されたルートを介して通話を終了するために利用できる回路の総数を表します。この属性は、このルートで合計で終了できるコールの数に対する潜在的に達成可能な上限を表します。
Routes MAY be originated containing the TotalCircuitCapacity attribute.
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.
TotalCircuitCapacity属性は、ルート選択に使用できます。主要なアプリケーションの1つはロードバランシングであるため、LSは、潜在的に異なるルート（同じ宛先のルートのセットの中で）を選択して、コールごとに選択したいと考えています。これは、各コールの到着時に決定プロセスを再実行するようにモデル化できます。この属性を使用したルートの集約および普及規則により、この選択プロセスを再実行することにより、他のピアへの新しいルートの伝播が決して生じないようにします。
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.
LSは、ROUTをTotalCircuitCapacity属性を含む同じプレフィックスに集約する場合があります。個々のルートの値を追加して、同じITADの集約されたルートの値を決定する必要があります。
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.
この属性はゲートウェイの回路リソースの静的容量を反映しているため、頻繁に変更されるとは予想されていません。したがって、この属性を受信するLSは、ITADの内部および外部の両方の他のピアにそれを広めることができます。
Mandatory: False. Required Flags: Not well-known. Potential Flags: None. TRIP Type Code: 14.
必須：false。必要なフラグ：よく知られていません。潜在的なフラグ：なし。トリップタイプコード：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.
availableCircuits属性は、完全な呼び出しへのルートで現在利用可能なPSTN回路の数を識別します。そのルートのゲートウェイに送信される追加のコールの数は、回路容量を超えることはできません。もしそうなら、シグナリングプロトコルはエラーを生成する可能性が高く、呼び出しは拒否されます。
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.
availablecircuits属性は、ゲートウェイとそのゲートウェイの管理を担当するピアLの間でのみ使用されます。ルートで受信された場合、伝播されません。
The AvailableCircuits attribute is a 4-octet unsigned integer. It represents the number of circuits remaining for terminating calls to this route.
availableCircuits属性は、4-OCTETの符号なし整数です。このルートへの呼び出しを終了するために残っている回路の数を表します。
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.
可用性回路属性を含むルートは発生する場合があります。この属性は非常に動的であり、呼び出しごとに変更されるため、更新は変更されると送信される場合があります。ただし、ルートオリジネーションからのメッセージング負荷を減らすのに役立つ対策を講じることをお勧めします。さらに、十分に大きな時間の窓を使用して、有用な集約された統計を提供することをお勧めします。
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.
availablecircuits属性は、ルート選択に使用できます。主要なアプリケーションの1つはロードバランシングであるため、LSは、コールごとに潜在的に異なるルート（同じプレフィックスのルートのセットの中から）を選択したいと考えています。これは、各コールの到着時に決定プロセスを再実行するようにモデル化できます。この属性を使用したルートの集約および普及規則により、この選択プロセスを再実行することにより、他のピアへの新しいルートの伝播が決して生じないようにします。
Not applicable.
適用できない。
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.
ルートをavailablecircuits属性と播種してはなりません。属性は、発信ゲートウェイのみの容量を反映することを目的としています。その非常にダイナミックな性質により、ほとんどの場合に広めることは不適切です。
Mandatory: False. Required Flags: Not well-known. Potential Flags: None. TRIP Type Code: 15.
必須：false。必要なフラグ：よく知られていません。潜在的なフラグ：なし。トリップタイプコード：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.
Calluccess属性は、ゲートウェイとそのゲートウェイの管理を担当するピアLの間でのみ使用される属性です。ルートで受信された場合、伝播されません。
The CallSuccess attribute provides information about the number of normally terminated calls out of a total number of attempted calls.
Calluccess属性は、通常終了した呼び出しの数に関する情報を提供します。
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.
Calluccessは、コール終了時の切断原因コードに基づいてゲートウェイによって決定されます。たとえば、アラート段階に到達しますが、呼び出されたパーティーや忙しいと呼ばれるパーティーが利用できないために接続されないコールは、従来、成功した呼び出しと見なされます。一方、回路やリソースが利用できないために切断されるコールは、従来、失敗した呼び出しと見なされます。Calluccessの切断の原因の正確なマッピングは、属性を報告するゲートウェイの裁量にあります。
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.
Calluccess属性は、LSによって使用され、ゲートウェイを介して特定のテレフォニーの目的地に到達する際の障害を追跡し、ゲートウェイ選択プロセスでその情報を使用して、コール終了を成功させる確率を高めます。
This information can be used by the LS to consider alternative gateways to terminate calls to those destinations with a better likelihood of success.
この情報は、LSが使用して、成功の可能性を秘めたこれらの目的地への呼び出しを終了するための代替ゲートウェイを検討することができます。
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.
Calluccess属性は、2つのコンポーネントフィールドで構成されています。それぞれが4-OCTET Unsigned Integerとして表されます。最初のコンポーネントフィールドは、特定の窓の窓にわたって特定のアドレスファミリーで広告された宛先に対して正常に終了したコールの総数を表します。2番目のコンポーネントフィールドは、同じ時間のウィンドウ内で広告された宛先の試行試行の総数を表します。
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.
試行された呼び出しの総数の値がラップすると、成功したコールの数のカウンター値がリセットされ、特定の時間の窓にわたって他のコンポーネントと整列します。この情報を使用するTGREPレシーバーは、この情報を頻繁に取得する必要があります。
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.
calluccess属性を含むルートは発生する場合があります。この属性は、より多くの呼び出しが試行されると、時間の経過とともに統計的に有意になると予想されます。十分に大きなウィンドウを使用して、有用な集約統計を提供することをお勧めします。
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.
Calluccess属性は、ルート選択に使用できます。この属性は、広告された宛先への呼び出しを終了する成功の尺度を表します。この情報は、コール終了を成功させる確率を高めるために、代替ルートのセットの中から選択するために使用できます。
Not applicable.
適用できない。
Routes MUST NOT be disseminated with the CallSuccess attribute. Its potential to change dynamically does not make it suitable to disseminate.
ルートにcalluccess属性と普及してはなりません。動的に変化する可能性は、普及するのに適していません。
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.
必須：false。必要なフラグ：よく知られていません。潜在的なフラグ：なし。トリップタイプコード：E164プレフィックスの場合は16、五角形のルーティング番号プレフィックスの場合は17、小数点以下のルーティング番号プレフィックスの場合は18。
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).
プレフィックス属性は、それぞれのルートが呼び出しを完了できるプレフィックスのリストを表すために使用されます。この属性は、キャリアまたはトランクグループアドレスファミリで使用することを目的としています（セクション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.
すべてのプレフィックス範囲が特定のキャリアを介して到達可能になる可能性がありますが、管理上の問題は特定の範囲を他の範囲よりも好ませる可能性があります。
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.
接頭辞属性は、E.164、10進、または五角形（トリップ[2]を参照）である可能性があり、それぞれが独自のタイプコードを持っています。プレフィックス属性は、属性値フィールドのプレフィックス値のシーケンスとしてエンコードされます。接頭辞は、図2に示すようにパディングなしで順番にリストされています。各プレフィックスには、オクテットのアドレスフィールドの長さを表す2-OCTETの長さフィールドが含まれています。属性内のプレフィックスの順序は重要ではありません。
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が、与えられた到達可能なルートのそのプレフィックスタイプ（e.164、10進、または五角形）のすべてのプレフィックスを終了できることを意味します。これは、TGREPアップデートでプレフィックス属性を除外することと同等ではありません。
< 2 octets > < Length1 octets > < 2 octets > < Length2 octets >
+------------+--------------//--+------------+--------------//--+-
| Length1 | Prefix1 | Length2 | Prefix2 | ...
+------------+--------------//--+------------+--------------//--+-
Figure 2: Prefix Format
図2：プレフィックス形式
Routes MAY be originated containing the Prefix attribute.
プレフィックス属性を含むルートは発信される場合があります。
The Prefix attribute MAY be used for route selection.
プレフィックス属性は、ルートの選択に使用できます。
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.
異なるプレフィックス属性を持つルートを集約してはなりません。プレフィックス属性に同じ値のルートを集計し、集約されたオブジェクトに接続された同じプレフィックス属性を集計できます。
The LS receiving this attribute should disseminate to other peers, both internal and external to the ITAD.
この属性を受け取るLSは、ITADの内部および外部の両方の他の仲間に普及する必要があります。
Mandatory: False. Required Flags: Not well-known. Potential Flags: None. TRIP Type Code: 19.
必須：false。必要なフラグ：よく知られていません。潜在的なフラグ：なし。トリップタイプコード：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.
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.
TrunkGroup属性は、一連のトランクグループ識別子で構成される可変長属性です。これは、ゲートウェイがシーケンスに示されているトランクグループ識別子を介して通話を完了できることを示しています。
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.
各トランクグループ識別子は、長さ価値のフィールドとしてエンコードされます（以下の図3に示す）。長さフィールドは、1-OCTETの符号なし数値です。値フィールドは、2つのサブフィールドで構成される可変長さのフィールドです。トランクグループラベルに続いてトランクコンテキストが続き、区切り文字で区切られた2つのサブフィールド「;」（セミコロン）。トランクグループラベルとトランクコンテキストサブフィールドの両方は、長さが可変です。長さフィールドは、区切り文字を含む値フィールドの合計サイズを表します。
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].
トランクグループラベルとトランクグループコンテキストサブフィールドと関連する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として属性の長さフィールドを持つトランクグループ属性の存在は、TGREP GWが与えられた到達可能なルートのすべてのトランクグループを終了できることを意味します。
< 1 octet > < Length1 octets > < 1 octet > < Length2 octets >
+-----------+--------------//--+-----------+--------------//--+-
| Length1 | TrunkGroup 1 | Length2 | TrunkGroup 2 | ...
+-----------+--------------//--+-----------+--------------//--+-
Figure 3: TrunkGroup Syntax
図3：TrunkGroup構文
Routes MAY be originated containing the TrunkGroup attribute.
TrunkGroup属性を含むルートは発信される場合があります。
The TrunkGroup attribute MAY be used for route selection. Certain trunkgroups MAY be preferred over others based on provider policy.
トランクグループ属性は、ルート選択に使用できます。プロバイダーポリシーに基づいて、特定のトランクグループが他のトランクグループよりも好まれる場合があります。
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属性を集計することができます。
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.
この属性は頻繁に変更されるとは予想されていません。したがって、この属性を受け取るLSは、ITADの内部の他の仲間にそれを広めることができます。ルートは、TrunkGroup属性を使用して、ITADの外部に配布してはなりません。
Mandatory: False. Required Flags: Not well-known. Potential Flags: None. TRIP Type Code: 20.
必須：false。必要なフラグ：よく知られていません。潜在的なフラグ：なし。トリップタイプコード：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.
キャリア属性は、ゲートウェイが通話を完了するために使用するキャリアのリストを表すために使用されます。これにより、プロバイダーは、優先キャリアを介して目的地への呼び出しをルーティングできます。この属性は比較的静的です。
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].
キャリア属性は、キャリア識別子のシーケンスで構成される可変長属性です。これは、ルートが、キャリア識別子のシーケンスに表されるキャリアのいずれかへの呼び出しを完了できることを示しています[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に示す）。長さフィールドは、1-OCTETの符号なし数値です。値フィールドは可変長さフィールドです。
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.
値フィールドと関連するABNF [8]の許容文字セットは、[5]で概説されているルールごとにあります。具体的には、「グローバル-CIC」または「ローカル-CIC」[5]を搭載しています。「ローカル-CIC」の場合、「電話装置ヘックス」部分と「CICコンテキスト」部分は、区切り文字 "によって分離されます。したがって、区切り文字の不在または存在を使用して、値が「グローバル-CIC」か「ローカル-CIC」であるかを判断できます。長さフィールドは、区切り文字を含む値フィールドの合計サイズを表します。
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が特定の到達可能なルートのすべてのキャリアを終了できることを意味します。
< 1 octet > < Length1 octets > < 1 octet > < Length2 octets >
+-----------+--------------//--+-----------+--------------//--+-
| Length1 | Carrier 1 | Length2 | Carrier 2 | ...
+-----------+--------------//--+-----------+--------------//--+-
Figure 4: Carrier Syntax
図4：キャリア構文
Routes MAY be originated containing the Carrier attribute.
キャリア属性を含むルートは発生する場合があります。
The Carrier attribute MAY be used for route selection. Certain carriers MAY be preferred over others based on provider policy.
キャリア属性は、ルートの選択に使用できます。プロバイダーポリシーに基づいて、特定のキャリアが他のキャリアよりも好まれる場合があります。
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.
キャリア属性が異なるルートは、集約してはなりません。キャリア属性に同じ値を持つルートは、集約され、集約されたオブジェクトに接続された同じキャリア属性を集計することができます。
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.
この属性は頻繁に変更されるとは予想されていません。したがって、この属性を受信するLSは、ITADの内部および外部の両方の他のピアにそれを広めることができます。
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:
旅行[2]で説明されているように、アドレスファミリフィールドはルートのアドレスのタイプを提供します。このセクションでは、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.
GWSのセットをキャリアまたはトランクグループの粒度で管理する場合、GWがそれぞれキャリアアドレスファミリまたはトランクグループアドレスファミリを使用してルートを宣伝する方が適切かもしれません。また、ゲートウェイとそのゲートウェイの管理を担当するLSの間のTGREP関連では、たとえば、特定のプレフィックスの宣伝されたプレフィックスのプロパティではなく、トランクグループまたはキャリアの宣伝されたプロパティとしてより自然に適合する属性がいくつかあります。トランクグループまたは特定のキャリア。この関係を表現するには、既存の旅行住所家族は不十分です。AvailableCircuits情報などの特定のプロパティをトランクグループまたはキャリアに関連付けることができる個別の住所ファミリが必要です。
The primary benefits of this model are as follows:
このモデルの主な利点は次のとおりです。
- It allows a service provider to route calls based strictly on the trunkgroups or carriers.
- これにより、サービスプロバイダーは、トランクグループまたはキャリアに厳密に基づいて呼び出しをルーティングできます。
- 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.
- トランクグループまたはキャリアの粒度でリソースを管理する能力を提供することにより、可用性のような動的な性質の属性のより正確な報告を促進します。
- 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の間に動的なリソース情報を報告するトラフィックの可能性が高まります。導入されたモデルは、この更新トラフィックを潜在的に軽減する可能性があるため、効率が向上し、スケーラブルなゲートウェイ登録モデルを提供できます。
Consider the generic TRIP route format from TRIP [2] shown below.
以下に示す旅行[2]からの一般的なトリップルート形式を考えてみましょう。
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
図5：一般的なトリップルート形式
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.
アドレスファミリフィールドは、トランクグループまたはキャリアに基づいたこのファミリに関連するアドレスのタイプを表すために使用されます。新しい住所ファミリのコードは、IANAによって割り当てられています。
The code for the TrunkGroup address family is 4, and the code for the Carrier address family is 5.
トランクグループアドレスファミリのコードは4で、キャリアアドレスファミリのコードは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.
アプリケーションプロトコルフィールドは、先10進数、五角形、およびE.164の対処ファミリーと同じものと同じです[2]。長さフィールドは、バイト内のアドレスフィールドの合計サイズを表します。
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".
トランクグループアドレスファミリの場合、アドレスフィールドは、セクション4.5.1「トランクグループ構文」で指定されていると定義されるトランクグループ値を表します。
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".
キャリアアドレスファミリの場合、アドレスフィールドはキャリア値を表します。これは、以前のセクション4.6.1「キャリア構文」で指定された値フィールドと同じです。
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.
上記の住所ファミリは階層的ではなく、フラットです。ゲートウェイがこれらのアドレスファミリのいずれかをサポートしている場合、オープンメッセージ能力交渉フェーズでサポートされているルートタイプの1つとして、そのアドレスファミリを含める必要があります。
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属性-Calluccess属性
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.
可能であれば、上記の3つの属性は、トランクグループまたはキャリアアドレスファミリを使用してゲートウェイで使用することをお勧めします。これにより、より効率的なリソースレポートフレームワークと、ゲートウェイプロビジョニングのスケーラブルなモデルが提供されます。
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.
ただし、ゲートウェイがトランクグループまたはキャリアアドレスファミリを使用していない場合、上記の属性を10進、五角形、およびE.164アドレスファミリを使用する場合があります。
The Prefix attribute cannot be used when the address family is E164 numbers, Pentadecimal routing numbers, or Decimal routing numbers.
アドレスファミリがE164番号、五角形のルーティング番号、または10進ルーティング番号の場合、プレフィックス属性は使用できません。
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.
アドレスファミリタイプがTrunkGroupである場合、TrunkGroup属性は使用できません。
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.
Gatewayは、TGREPを使用して、その到達可能性をドメインのロケーションサーバー（LS）に宣伝します。これはプロキシと密接に結びついています）。ゲートウェイは、到達可能性を宣伝することにのみ関心があるが、他のゲートウェイや他のドメインの到達可能性について学ぶことに関心がないため、Trip Sendのみモードで動作します。また、ゲートウェイは独自の呼び出しルーティングデータベースを作成しません。このセクションでは、ゲートウェイでのTGREPの操作について説明します。
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ゲートウェイは他の旅行エンティティとまったく同じ手順に従います。TGREPゲートウェイは、オプションのパラメーターに送信受信機能を含むオープンメッセージを送信します。送信受信機能は、ゲートウェイによって設定され、送信のみが設定されます。オープンメッセージには、ゲートウェイでサポートされているアドレスファミリも含まれています。ピアセッション施設の残りの部分は、旅行と同じです。
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.
ピアセッションが確立されると、ゲートウェイはゲートウェイの到達可能性全体で更新メッセージをトリップLSに送信します。ゲートウェイは、ルートに関連付けられた属性も送信します。
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.
Gatewayでの更新メッセージのTGREP処理は、旅行での処理を更新するのと同じです[2]。TGREP送信者は、すべての必須の旅行属性をサポートする必要があります。
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].
Keepaliveメッセージは、TGREPゲートウェイと旅行LSの間のピアリングセッションで定期的に交換されます[2]のセクション4.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.
旅行で使用される同じ手順は、エラー処理と通知メッセージの生成のためにTGREPで使用されます。唯一の違いは、更新メッセージの内容に関係なく、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.
TGREPの有限状態マシンが確立された状態にあり、更新メッセージが受信されると、更新メッセージは静かに破棄され、TGREPゲートウェイは確立された状態のままです。それ以外に、トリップ有限状態マシンとTGREP有限状態マシンは同一です。
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ゲートウェイは、複数の旅行LSで同時セッションを維持する場合があります。TGREPゲートウェイは、ピアトリップLSごとに1つの呼び出しルーティングデータベースを維持します。これらのデータベースはTribのAdj-Tribs-Outと同等であるため、Adj-Tribs-Gw-Outと呼びます。adj-trib-gw-outには、ピアトリップLSに宣伝されているゲートウェイの到達可能性情報が含まれています。adj-trib-gw-outデータベースがどのように人数化されているかは、このドキュメントの範囲外です（おそらく手動構成による）。
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.
TGREPゲートウェイは、TGREPゲートウェイがピアトリップLSSからルートを学習せず、したがってコールルート選択を実行しないため、TribのAdj-Tribs-inおよびLoc-Tribに相当するデータベースがありません。
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セッションでは、次のカテゴリの2つ以上の更新を送信してはなりません（a）プレフィックスアドレスファミリー（E164、五科、および小数）、（b）トランクグループアドレスファミリー、または（c）特定の確立されたセッションのキャリアアドレスファミリー。TGREPは、オープンメッセージのルートタイプの機能を介して、選択肢アドレスファミリを指定する必要があります。また、上記のルールに違反するオープンメッセージのルートタイプの仕様は、通知メッセージで拒否される必要があります。
TRIP's route selection and aggregation operations MUST NOT be implemented by TGREP gateways.
Tripのルートの選択と集約操作は、TGREPゲートウェイで実装してはなりません。
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は、到達可能性情報を提供する際にトリップを補完するプロトコルと見なすことができます。LS/プロキシシステムのアーキテクチャは次のとおりです。TRIP/E-TRIPネットワークのスピーカーとして機能するTRIP LSアプリケーションが存在します[2]。このコンポーネントは、この議論の目的のために「出口ls」と呼ばれます。次に、ゲートウェイのセットをフロンツする信号サーバーがあります。このシグナリングサーバーと連携して、受信モードで動作する2番目のコンポーネントもあります。これは、1つ以上のゲートウェイを採用しており、それぞれがTGREPを使用してルーティング情報を宣伝しています。1つ以上のTGREPセッションの受信側のこのコンポーネントは、この議論の目的で「イングレスLS」または「TGREPレシーバー」と呼ばれます。また、TGREPセッションのルートを宣伝するエンティティ（通常、ゲートウェイ）は「TGREP送信者」と呼ばれます。トリップメッセージを受信するTGREPレシーバーは、各ゲートウェイから結果のルーティング情報を取得し、その順序で統合と集約を実行する別のプロセスに「エクスポート」します。これらの操作は、すべてのゲートウェイからの集合的なルートセットを入力するために使用されます。その後、結果として得られた部族は、以下に示すようにLS-Egressプロセスへの入力として渡され、旅行でこれらを広めることができます。TGREPレシーバー（別名Ingress LS）とGW（S）とTrip LS（Egress 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
図6：Trip-GWのLSアーキテクチャ
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.
TGREPレシーバー（Ingress LS）は、1つ以上のゲートウェイからルーティング情報を受信する場合があります。同じ宛先で複数のルートを使用できる可能性があります。これらの異なる代替ルートは、同じゲートウェイまたは複数のゲートウェイから受信できます。各宛先のゲートウェイルートのセットを、候補ルートを提示する前に、出口LSエンティティに統合することをお勧めします。この操作の動機は、このTGREPレシーバーによって管理されたゲートウェイのセットの集合的なルーティング機能を最大限に表すことができるルートを定義することです。この操作の動機を引き出すために、例のシナリオを取りましょう。TGREPレシーバーは、ゲートウェイAと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.
- Gateway 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.
これらのルートを受信するTGREPレシーバーは、これらの構成要素ルートを宛先「SIP 408」の単一ルートに統合することができ、そのキャリア属性は個々のルートのキャリア属性値、つまり「C1 C2」の結合です。この操作は統合と呼ばれます。上記の例では、個々のルートが統合されていない場合、目的地へのルート「SIP 408」へのルート「SIP 408」が1つ以上のキャリアを介して失われた可能性があります。
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}.
別の例は、同じ宛先の異なるゲートウェイから受信した複数のキャリアまたはトランクグループの更新からプレフィックス属性を統合することです。キャリアアドレスファミリ（AF）のキャリア宛先宛先Xの2つのゲートウェイからの更新があり、プレフィックス属性の値は1つの更新から{408、650}、もう1つの更新から{919、973}です。これら2つの更新のプレフィックス値は、プレフィックス値{408、650、919、973}を使用して、単一のキャリアAFルート広告に統合できます。
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.
一般に、ゲートウェイのセットからのTGREPルートが候補ルートが旅行LSに提示されたときに統合されない場合、ゲートウェイルーティング情報を失う可能性があります。さまざまなアドレスファミリからのさまざまな属性とルートに統合操作を適用する詳細は、個々のTGREPレシーバーの実装に任されています。
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処理（Egress LS）の原因となるLSインスタンスにインポートする前に集約される場合があります。この操作は、各ルート属性の集約ルールを順守しながら、旅行[2]で説明されている標準的な集約手順に従います。
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.
上記の2つの操作の違いを強調するために、「統合」は同じルートの宛先の複数のルートを組み合わせていますが、「集約」は、候補者として要約される資格のある異なるルートの宛先のルートを組み合わせて、ルート情報の削減をもたらします。
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のゲートウェイのセットの中から4089のルートを受信した場合、これらの異なる候補ルートを集計して、各属性と要約されたルート宛先「408」を持つことができます。旅行で定義された集約手順を使用して計算されました。
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]で特定されたものと同一であり、明確さの目的のためにここで修正されています。
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].
IPネットワークでのTGREP GWとTRIP LSの間のピアリングセッションのセキュリティメカニズムはIPSECです[3]。IPSECは、2つのプロトコルを使用してトラフィックセキュリティを提供します：認証ヘッダー（AH）[6]とセキュリティペイロードのカプセル化（ESP）[7]。
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.
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.
ESPヘッダーを使用してこのドキュメントで定義されているプロトコルの実装は、[10]のセクション3.1.1に準拠するものとします。これは、整合性チェックと暗号化のためのアルゴリズムの最小セットを定義します。同様に、AHヘッダーを使用している実装は、[10]のセクション3.2に準拠するものとします。これは、整合性チェックのためのアルゴリズムの最小セットを定義します。
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.
実装は、インターネットキーエクスチェンジプロトコル（IKEV2）[9]を使用して、より堅牢なキーイングオプションを可能にする必要があります。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に提供されますが、両方ではありません。2種類のSASが定義されています：トランスポートモードとトンネルモード。トランスポートモードSAは、2つのホスト間のセキュリティアソシエーションであり、2つのピアLSS間の旅行セッションを保護するのに適しています。
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.
旅行[2]とTGREPの両方は、機能、属性、住所ファミリー、およびアプリケーションプロトコルについて、同じIANAレジストリを共有しています。IANAは、次の属性コードを追加し、家族コードを旅行[2]レジストリにアドレス指定しました。
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]
The following subsections show the codes that have been assigned for the two new address families introduced in this document.
次のサブセクションは、このドキュメントで紹介された2つの新しいアドレスファミリに割り当てられたコードを示しています。
Code Address Family Reference
---- -------------- ---------
4 TrunkGroup [RFC5140]
Code Address Family Reference
---- -------------- ---------
5 Carrier [RFC5140]
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.
Vijay Gurbani、Li Li、Kevin McDermott、David Oran、Bob Penfield、Jon Peterson、Anirudh Sahoo、およびJames Yuの洞察に満ちたコメントと提案に感謝します。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Rosenberg, J., Salama, H., and M. Squire, "Telephony Routing over IP (TRIP)", RFC 3219, January 2002.
[2] Rosenberg、J.、Salama、H。、およびM. Squire、「Thelephony Routing over IP（Trip）」、RFC 3219、2002年1月。
[3] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[3] Kent、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. Jennings、「Tel/SIPユニフォームリソース識別子（URIS）のトランクグループを表す」、RFC 4904、2007年6月。
[5] Yu, J., "Number Portability Parameters for the "tel" URI", RFC 4694, October 2006.
[5] Yu、J。、「「Tel "URI」の番号携帯性パラメーター、RFC 4694、2006年10月。
[6] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[6] Kent、S。、「IP認証ヘッダー」、RFC 4302、2005年12月。
[7] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[7] Kent、S。、「セキュリティペイロード（ESP）のカプセル化IP」、RFC 4303、2005年12月。
[8] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[8] Crocker、D.、ed。、およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、STD 68、RFC 5234、2008年1月。
[9] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[9] Kaufman、C.、ed。、「Internet Key Exchange（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。、「セキュリティペイロード（ESP）および認証ヘッダー（AH）をカプセル化するための暗号化アルゴリズムの実装要件」、RFC 4835、2007年4月。
[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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INIATIATION Protocol"、RFC 3261、2002年6月。
[12] Rosenberg, J. and H. Schulzrinne, "A Framework for Telephony Routing over IP", RFC 2871, June 2000.
[12] Rosenberg、J。およびH. Schulzrinne、「IPを介したテレフォニールーティングのフレームワーク」、RFC 2871、2000年6月。
[13] ITU-T List of ITU Carrier Codes (published periodically in the ITU-T Operational Bulletin).
[13] ITUキャリアコードのITU-Tリスト（ITU-T運用速報で定期的に公開）。
[14] Rosenberg, J., "Requirements for Gateway Registration", Work in Progress, November 2001.
[14] Rosenberg、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: manjax@cisco.com
Manjunath S. Bangalore Cisco Mail Stop SJC-14/2/1 3625 Cisco Way San Jose、CA 95134電話：1-408-525-7555メール：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
Rajneesh Kumar Cisco Mail Stop SJC-14/4/2 3625 Cisco Way San Jose、CA 95134電話：1-408-527-6148メール：rajneesh@cisco.com
Jonathan Rosenberg Cisco Edison, NJ 08837 EMail: jdrosen@cisco.com
Jonathan Rosenberg Cisco Edison、NJ 08837メール：jdrosen@cisco.com
Hussein F. Salama Citex Software Giza, Egypt EMail: hsalama@citexsoftware.com
Hussein F. Salama Citexソフトウェアギザ、エジプトメール：hsalama@citexsoftware.com
Dhaval Niranjan Shah Moowee Inc. 4920 El Camino Real Los Altos, CA 94022 Phone: +1-408-307-7455 EMail: dhaval@moowee.tv
Dhaval Niranjan Shah Moowee Inc. 4920 El Camino Real Los Altos、CA 94022電話：1-408-307-7455メール：dhaval@moowee.tv
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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 http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンライン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.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。