RFC5140 日本語訳
5140 A Telephony Gateway REgistration Protocol (TGREP). M. Bangalore,R. Kumar, J. Rosenberg, H. Salama, D.N. Shah. March 2008. (Format: TXT=59511 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループM.バンガロール要求をネットワークでつないでください: 5140年のR.クマーカテゴリ: 2008年の標準化過程J.ローゼンバーグのコクチマスH.サラマのCitexソフトウェアD.N.シャーMoowee株式会社行進
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
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.
このドキュメントは電話ゲートウェイと柔らかいスイッチによってサポートされた電話接頭語の登録のために、TelephonyゲートウェイRegistrationプロトコル(TGREP)について説明します。 また、リソース情報をエクスポートするのに登録メカニズムを使用できます。 そして、IP(TRIP)位置のServerの上のTelephonyルート設定に接頭語とリソース情報を通過できます。順番に、ServerはTelephony Administrative DomainsとインターネットTelephony Administrative Domains(ITADs)の間のそのルーティング情報を伝播できます。 TGREPはTRIPプロトコルと多くの類似性を共有します。 それはセッション設立のための同様の手順と有限状態機械を持っています。 また、それは属性のメッセージと部分集合のために同じ形式をTRIPと共有します。
Bangalore, et al. Standards Track [Page 1] RFC 5140 TGREP March 2008
バンガロール、他 規格は2008年のTGREP行進のときにRFC5140を追跡します[1ページ]。
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. 序論…3 2. 用語と定義…5 3. TGREP: 操作の概要…6 4. TGREP属性…7 4.1. TotalCircuitCapacity属性…8 4.2. AvailableCircuits属性…9 4.3. CallSuccess属性…10 4.4. 属性を前に置いてください…12 4.5. TrunkGroup属性…13 4.6. キャリヤー属性…15 5. TrunkGroupとキャリヤーはファミリーに演説します…16 5.1. ファミリーに構文を扱ってください…17 6. ゲートウェイ操作…18 6.1. セッション設立…18 6.2. メッセージをアップデートしてください…19 6.3. KEEPALIVEメッセージ…19 6.4. エラー処理と通知メッセージ…19 6.5. TGREP有限状態機械…19 6.6. データベースにルート設定に電話をしてください…19 6.7. 複数のアドレスファミリー…20 6.8. 選択と集合を発送してください…20 7. LS/プロキシの振舞い…20 7.1. 強化を発送してください…22 7.2. 集合…23 7.3. 強化対集合…23 8. セキュリティ問題…23 9. IANA問題…24 9.1. コードを結果と考えてください…24 9.2. ファミリーにコードを扱ってください…24 10. 承認…25 11. 参照…25 11.1. 標準の参照…25 11.2. 有益な参照…26
Bangalore, et al. Standards Track [Page 2] RFC 5140 TGREP March 2008
バンガロール、他 規格は2008年のTGREP行進のときにRFC5140を追跡します[2ページ]。
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.
このドキュメントの読者がTRIP[2、12]に詳しいと思われます。 典型的なボイス・オーバー IP(VoIP)ネットワークでは、インターネットTelephony Administrative Domains(ITADs)は地理的な多様性、容量、および冗長の目的のために多数のゲートウェイを配布するでしょう。 呼び出しがドメインに到着するとき、それらのゲートウェイの1つにそれを発送しなければなりません。 頻繁に、ITADはネットワークをPresence(POP)の地理的なPointsに細かく分けるでしょう、各POPが何らかの数のゲートウェイ、およびそれらのゲートウェイに向かうプロキシサーバ要素を含んでいて。 プロキシ要素は、SIPプロキシ[11]かH.323門番です。 プロキシサーバはPOPへのアクセスを管理する、およびゲートウェイについてPOPに到着するどんな与えられた呼び出しも受ける決定にも原因となります。 呼び出しシグナリングを発送するプロキシサーバに関連して、2つのコンポーネント、「イングレスLS」(別名「TGREP受信機」)、および「出口LS」があります。 TGREP受信機の部品は複数のゲートウェイとのTGREPじっと見る関係を維持します。 ゲートウェイから受け取られたルーティング情報がさらにEgress LSに注がれる、どれ、順番に、TRIPの上のネットワークの残りに広めるか。 便宜のために、ゲートウェイとGWは互換性を持って使用されます。
This configuration is depicted graphically in Figure 1.
この構成は図1にグラフィカルに表現されます。
Bangalore, et al. Standards Track [Page 3] RFC 5140 TGREP March 2008
バンガロール、他 規格は2008年のTGREP行進のときにRFC5140を追跡します[3ページ]。
Signaling TGREP
-------------> <----------------
シグナリングTGREP-------------><。----------------
+---------+
| |
| GW |
> +---------+
//
//
SIP // +---------+
<----> // | |
+-------------------------+ // | GW |
| | // +---------+
| +-------------+ |/
| | | |
| | Routing | | +---------+ TO PSTN
| | Proxy | | | |
---> | | |-----------> | GW | ----->
|+---+-----+ +-----+----+ | +---------+
|| | | | |
|| <+-+ | |--
||Egress LS| |Ingress LS| | --- +---------+
|| | | | | -- | |
|+---------+ +----------+ | -- | GW |
| | -- +---------+
| | -->
+-------------------------+
TRIP +---------+
<----> | |
| GW |
+---------+
+---------+ | | | GW| >+---------+ ////一口//+---------+ <。---->//| | +-------------------------+ // | GW| | | // +---------+ | +-------------+ |/ | | | | | | ルート設定| | +---------+ PSTNに| | プロキシ| | | | --->|、| |、-、-、-、-、-、-、-、-、-、--、>| GW| ----->| +---+-----+ +-----+----+ | +---------+ || | | | | || <++| |-- ||出口LS| |イングレスLS| | --- +---------+ || | | | | -- | | |+---------+ +----------+ | -- | GW| | | -- +---------+ | | -->+-------------------------+ 旅行+---------+ <。---->|、|、| 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.
どのゲートウェイを使用したらよいかに関する決定をそれらの有用性を含む呼び出し容量のままで残っている多くの要素に依存します、そして、統計を特定のPublic Switched Telephone Network(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
TRIPプロトコル[2]は電話ルーティング情報をプロバイダーの間まで運ぶために定義されます、終了のために正しいプロバイダーに呼び出しをPSTNに発送させる目的のために。 しかしながら、ルートがネットワークからTRIPプロトコルにどう注がれるかを定義するTRIPで定義されたメカニズムが全くありません。 それもそうしません。
Bangalore, et al. Standards Track [Page 4] RFC 5140 TGREP March 2008
バンガロール、他 規格は2008年のTGREP行進のときにRFC5140を追跡します[4ページ]。
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.
プロバイダーが到着すると呼び出しを終えるために特定のゲートウェイを選択できるメカニズムを定義してください。 それらの不足は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ゲートウェイか柔らかいスイッチにシグナリングサーバを知らせさせます、それがPSTNに持っているルートのSIPプロキシサーバやH.323門番などのように。 これらの広告は動的情報を公正に含んでいます、特定のトランクでの残存容量などのように。(右のゲートウェイを選択するのに、トランクは不可欠です)。
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は構文と総合的な操作がTRIPと同じです。 しかしながら、TGREP受信機が支えたルート処理規則では、異なります、「強化」と呼ばれるルート処理機能を考慮して。 ただ一つのルートへの異なった属性がある同じルートの目的地がルーティング情報の損失を防ぐように、強化は複数のルートを結合します。 また、TGREPは1セットのTGREPかTRIPが使用可能な新しい属性を定義します。 最終的に、TGREPは総合的なTRIP能力の部分集合を利用するだけです。 明確に、ある属性が利用されていなくて(以下で説明されるように)、ところが、TGREP実体(送付者と受信機)が非対称の関係で作動する、TRIPが許容する、左右対称であって、非対称です。
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
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].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[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つの交換システムが終わりから終わりとの接続の設立に使用した通信路接続です。 選択されたアプリケーションでは、それは同じ交換システムにおける両方の終了を持っているかもしれません。
Bangalore, et al. Standards Track [Page 5] RFC 5140 TGREP March 2008
バンガロール、他 規格は2008年のTGREP行進のときにRFC5140を追跡します[5ページ]。
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: trunkgroupは1セットのトランクスです、一体にして設計されたトラフィック、交換システム、または、副分類されるのを除いて、経路のすべてが交換可能である交換システムの間の関係の設立のために。
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 Location ServerにGWに住んでいて、すべての情報を集めます。TGREP Receiver(任意にこの情報を受け取って、強化と集合(セクション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送付者は、TRIPへのセッション設立と同様の手順を用いることでTGREP受信機にセッションを確立します。 セッション設立の後に、TGREP送付者はUPDATEメッセージの可到達性情報を送ります。 同じくらいがTRIPのようにメッセージでフォーマットするUPDATE。 しかしながら、あるTRIP属性はTGREPで関連していません。 それらがTGREPメッセージに存在しているなら、TGREP受信機はそれらを無視するかもしれません。 以下のTRIP属性はTGREPに適用されません:
1. AdvertisementPath
2. RoutedPath
3. AtomicAggregate
4. LocalPreference
5. MultiExitDisc
6. ITADTopology
7. ConvertedRoute
1. AdvertisementPath2。 RoutedPath3。 AtomicAggregate4。 LocalPreference5。 MultiExitDisc6。 ITADTopology7。 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回路の数を特定します。
Bangalore, et al. Standards Track [Page 6] RFC 5140 TGREP March 2008
バンガロール、他 規格は2008年のTGREP行進のときにRFC5140を追跡します[6ページ]。
- 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)を前に置いてください: この属性は、それぞれのルートが呼び出しを終了できる164Eの接頭語のリストを表すのに使用されます。
- Prefix (Decimal Routing Number): This attribute is used to
represent the list of Decimal prefixes to which the respective
route can complete calls.
- (10進ルート設定番号)を前に置いてください: この属性は、それぞれのルートが呼び出しを終了できるDecimal接頭語のリストを表すのに使用されます。
- Prefix (Hexadecimal Routing Number): This attribute is used to
represent the list of Hexadecimal prefixes to which the
respective route can complete calls.
- (16進ルート設定番号)を前に置いてください: この属性は、それぞれのルートが呼び出しを終了できるHexadecimal接頭語のリストを表すのに使用されます。
- 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で使用される属性とアドレスファミリーを指定します。また、有名であるところ以外のTRIP(例えば、AvailableCircuits属性)の一般的な用法に、ファミリーが紹介した新しい属性とアドレスも適切です。
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:
サービスプロバイダーネットワークの中の用法のため、TGREPはTRIPのために定義された属性の部分集合を利用します、いくつかの新しいものを定義することに加えて。 TRIPからの以下の属性はTGREPに特に、適切です:
1. WithdrawnRoutes
2. ReachableRoutes
3. NexthopServer
4. Prefix
5. Communities
1. WithdrawnRoutes2。 ReachableRoutes3。 NexthopServer4。 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と、CallSuccessと、TrunkGroupと、Carrierです。 以上のように、別の方法で注意されない場合、これらの新しい属性はTRIPが使用可能です。
Bangalore, et al. Standards Track [Page 7] RFC 5140 TGREP March 2008
バンガロール、他 規格は2008年のTGREP行進のときにRFC5140を追跡します[7ページ]。
A TGREP UPDATE supports the following attributes:
TGREP UPDATEは以下の属性をサポートします:
1. TotalCircuitCapacity
2. AvailableCircuits
3. CallSuccess
4. Prefix (E.164, Pentadecimal routing number, Decimal routing
number)
5. TrunkGroup
6. Carrier
1. TotalCircuitCapacity2。 AvailableCircuits3。 CallSuccess4。 5を前に置いてください(E.164、Pentadecimalルーティング番号、Decimalルーティング番号)。 TrunkGroup6。 キャリヤー
4.1. TotalCircuitCapacity Attribute
4.1. TotalCircuitCapacity属性
Mandatory: False. Required Flags: Not well-known. Potential Flags: None. TRIP Type Code: 13.
義務的: 誤る。 必要な旗: 周知のことでない。 可能性は弛みます: なし。 旅行タイプコード: 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回路の総数を特定します。 それはゲートウェイ選択におけるAvailableCircuits属性に関連してLSによって使用されます。 ゲートウェイの上の指定されたルートに送られた呼び出しの総数は定常状態条件のもとでこの総回線容量を超えることができません。
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はどんな瞬間にも可能な呼び出しの総数を表します。 これが頻繁に変化しないと予想されます。 例えば、これは、ゲートウェイのある電話本体がいつメインテナンス目的のために使われなくなっていた状態で取られるかを変えることができます。
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.
TotalCircuitCapacity属性は4八重奏の符号のない整数です。 それはこの広告を出しているルートによる呼び出しを終えるのに利用可能な回路の総数を表します。 この属性は合計でこのルートで終えることができる呼び出しの数に潜在的に達成可能な上限を表します。
4.1.2. Route Origination and TotalCircuitCapacity
4.1.2. ルート創作とTotalCircuitCapacity
Routes MAY be originated containing the TotalCircuitCapacity attribute.
ルートはTotalCircuitCapacityが結果と考える溯源された含有であるかもしれません。
Bangalore, et al. Standards Track [Page 8] RFC 5140 TGREP March 2008
バンガロール、他 規格は2008年のTGREP行進のときにRFC5140を追跡します[8ページ]。
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.
TotalCircuitCapacity属性はルート選択に使用されるかもしれません。 プライマリアプリケーションの1つがロードバランシングであるので、LSは潜在的に異なったルート(同じ目的地への1セットのルートの中の)を選びたくなるでしょう、呼び出しごとのベースで。 それぞれの呼び出しの到着のときに決定プロセスを再放送するとしてこれをモデル化できます。 この属性があるルートへの集合と普及の規則は、この選択プロセスを再放送するのが他の同輩への新しいルートの伝播を決してもたらさないのを確実にします。
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.
LS MAY集合はTotalCircuitCapacity属性を含む接頭語を同じくらいに発送します。 それ、SHOULDは、同じ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.
この属性がゲートウェイの回路リソースの静的な容量を反映するので、頻繁に変化しないと予想されます。 したがって、この属性を受けるLSは内部の、そして、ITADへの外部の両方の他の同輩にそれを広めるかもしれません。
4.2. AvailableCircuits Attribute
4.2. AvailableCircuits属性
Mandatory: False. Required Flags: Not well-known. Potential Flags: None. TRIP Type Code: 14.
義務的: 誤る。 必要な旗: 周知のことでない。 可能性は弛みます: なし。 旅行タイプコード: 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属性はそのゲートウェイを管理するのに原因となるゲートウェイとその同輩LSだけの間で使用されます。 ルートにそれを受け取るなら、それを伝播しません。
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.
AvailableCircuits属性は4八重奏の符号のない整数です。 それは呼び出しを終えるためにこのルートのままで残っている回路の数を表します。
Bangalore, et al. Standards Track [Page 9] RFC 5140 TGREP March 2008
バンガロール、他 規格は2008年のTGREP行進のときにRFC5140を追跡します[9ページ]。
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.
ルートはAvailableCircuitsが結果と考える溯源された含有であるかもしれません。 あらゆる呼び出しを交換して、この属性が非常にダイナミックであるので、変化するとき、アップデートを送るかもしれません。 しかしながら、対策がルート創作からメッセージング負荷を減少させるのを助けるために実施されるのは、RECOMMENDEDです。 時間の十分大きい窓が役に立つ集められた統計値を提供するのに使用されるのは、一層のRECOMMENDEDです。
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.
AvailableCircuits属性はルート選択に使用されるかもしれません。 プライマリアプリケーションの1つがロードバランシングであるので、LSは呼び出しごとのベースで潜在的に異なったルートを選びたくなるでしょう(同じ接頭語のための1セットのルートの中で)。 それぞれの呼び出しの到着のときに決定プロセスを再放送するとしてこれをモデル化できます。 この属性があるルートへの集合と普及の規則は、この選択プロセスを再放送するのが他の同輩への新しいルートの伝播を決してもたらさないのを確実にします。
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.
AvailableCircuits属性でルートを広めてはいけません。 属性は起因するゲートウェイだけに容量を反映することになっています。 非常にダイナミックな本質で、それは多くの場合、広めるために不適当になります。
4.3. CallSuccess Attribute
4.3. CallSuccess属性
Mandatory: False. Required Flags: Not well-known. Potential Flags: None. TRIP Type Code: 15.
義務的: 誤る。 必要な旗: 周知のことでない。 可能性は弛みます: なし。 旅行タイプコード: 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.
CallSuccess属性はそのゲートウェイを管理するのに原因となるゲートウェイとその同輩LSだけの間で使用される属性です。 ルートにそれを受け取るなら、それを伝播しません。
The CallSuccess attribute provides information about the number of normally terminated calls out of a total number of attempted calls.
CallSuccess属性は総数の試みられた呼び出しから通常、終えられた呼び出しの数の情報を提供します。
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
CallSuccessは呼び出し終了でDisconnect原因コードに基づくゲートウェイのそばで断固とすることになっています。 例えば、Alertingステージに達しますが、接続されない電話はそうします。
Bangalore, et al. Standards Track [Page 10] RFC 5140 TGREP March 2008
バンガロール、他 規格は2008年のTGREP行進のときにRFC5140を追跡します[10ページ]。
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への分離原因の正確なマッピングがあります。
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.
CallSuccess属性は、ゲートウェイを通してある電話の目的地に達する際に失敗の動向をおさえて、うまくいっている呼び出し終了の確率を高めるのにゲートウェイ選択プロセスでその情報を使用するのに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は、代替ゲートウェイが成功の、より良い見込みでそれらの目的地への呼び出しを終えると考えるのにこの情報を使用できます。
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.
CallSuccess属性は2つのコンポーネント分野で構成されます--4八重奏の符号のない整数としてそれぞれ表されます。 最初のコンポーネント分野は時間の与えられた窓の上の与えられたアドレスファミリーの広告を出している目的地に首尾よく終えられた呼び出しの総数を表します。 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受信機は意味の損失を防ぐことができるくらいの頻繁にこの情報を得るはずです。
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.
ルートはCallSuccessが結果と考える溯源された含有であるかもしれません。 より多くの呼び出しが試みられるときこの属性が時間の経過によって統計的に重要になると予想されます。 十分大きい窓が役に立つ集められた統計値を提供するのに使用されるのは、RECOMMENDEDです。
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.
CallSuccess属性はルート選択に使用されるかもしれません。 この属性は終わり呼び出しの成功の測定を広告を出している目的地に表します。 1セットの代替のルートからうまくいっている呼び出し終了の確率を増強するのを選択するのにおいてこの情報は使用されているかもしれません。
Bangalore, et al. Standards Track [Page 11] RFC 5140 TGREP March 2008
バンガロール、他 規格は2008年のTGREP行進のときにRFC5140を追跡します[11ページ]。
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.
CallSuccess属性でルートを広めてはいけません。 ダイナミックに変化する可能性で、それは広めるのにおいて適当になりません。
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.
義務的: 誤る。 必要な旗: 周知のことでない。 可能性は弛みます: なし。 旅行タイプコード: 16 164Eの接頭語、数が前に置くPentadecimalルート設定のための17、および数が前に置く10進ルート設定のための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).
Prefix属性は、それぞれのルートが呼び出しを終了できる接頭語のリストを表すのに使用されます。 CarrierかTrunkGroupアドレスファミリー(セクション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属性は、E.164、Decimal、またはPentadecimalであるかもしれません。(それらのそれぞれがそれ自身のものにコードをタイプすることにさせるのであるTRIP[2])を参照してください。 Prefix属性は属性Value分野の接頭語値の系列としてコード化されます。 図2に示されるようにそっと歩かないで、接頭語は連続して記載されています。 各接頭語は八重奏における、Address分野の長さを表す2八重奏のLength分野を含んでいます。 属性における、接頭語の注文は重要ではありません。
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としての属性のLength分野があるPrefix Attributeの存在は、TGREP GWが与えられたReachableルートへのその接頭語タイプ(E.164、Decimal、またはPentadecimal)のすべての接頭語を終えることができるのを意味します。 これはTGREPアップデートにおけるPrefix属性を除くのに同等ではありません。
Bangalore, et al. Standards Track [Page 12] RFC 5140 TGREP March 2008
バンガロール、他 規格は2008年のTGREP行進のときにRFC5140を追跡します[12ページ]。
< 2 octets > < Length1 octets > < 2 octets > < Length2 octets >
<2八重奏><Length1八重奏><2八重奏><Length2八重奏>。
+------------+--------------//--+------------+--------------//--+- | Length1 | Prefix1 | Length2 | Prefix2 | ... +------------+--------------//--+------------+--------------//--+-
+------------+--------------//--+------------+--------------//--+- | Length1| Prefix1| Length2| Prefix2| ... +------------+--------------//--+------------+--------------//--+-
Figure 2: Prefix Format
図2: 接頭語形式
4.4.2. Route Origination and Prefix
4.4.2. ルート創作と接頭語
Routes MAY be originated containing the Prefix attribute.
ルートはPrefixが結果と考える溯源された含有であるかもしれません。
4.4.3. Route Selection and Prefix
4.4.3. ルート選択と接頭語
The Prefix attribute MAY be used for route selection.
Prefix属性はルート選択に使用されるかもしれません。
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属性があるルートを集めてはいけません。 Prefix属性における同じ値があるルートは集められたかもしれません、そして、同じ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.
この属性が内部の、そして、ITADへの外部の両方の他の同輩に広めるべきであるLS受信。
4.5. TrunkGroup Attribute
4.5. TrunkGroup属性
Mandatory: False. Required Flags: Not well-known. Potential Flags: None. TRIP Type Code: 19.
義務的: 誤る。 必要な旗: 周知のことでない。 可能性は弛みます: なし。 旅行タイプコード: 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属性は、呼び出しを終了するのに使用されるゲートウェイの上のtrunkgroupsのリストを表すのに使用されます。 それは、プロバイダーが都合のよいトランクスを通して呼び出しを目的地に発送するのを可能にします。 この属性は比較的静的です。
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.
TrunkGroup属性はtrunkgroup識別子の系列で構成される可変長の属性です。 それは、ゲートウェイが系列で示されたどんな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
それぞれのtrunkgroup識別子はLength-値の分野(以下の図3では、目立つ)としてコード化されます。 Length分野は1八重奏の未署名の数値です。
Bangalore, et al. Standards Track [Page 13] RFC 5140 TGREP March 2008
バンガロール、他 規格は2008年のTGREP行進のときにRFC5140を追跡します[13ページ]。
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.
値。 「Value分野は2つの部分体から成る可変長の分野です、とtrunkgroupラベルがトランク文脈で続きました、デリミタによって切り離された2つの部分体」;、」 (セミコロン。) trunkgroupラベルとトランク文脈部分体の両方が可変長のものです。 Length分野はデリミタを含むValue分野の総サイズを表します。
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としての属性のLength分野があるTrunkGroup属性の存在は、TGREP GWが与えられたReachableルートへのすべてのtrunkgroupsを終えることができるのを意味します。
< 1 octet > < Length1 octets > < 1 octet > < Length2 octets >
1つの八重奏の1つの八重奏の<><Length1八重奏><><Length2八重奏>。
+-----------+--------------//--+-----------+--------------//--+- | Length1 | TrunkGroup 1 | Length2 | TrunkGroup 2 | ... +-----------+--------------//--+-----------+--------------//--+-
+-----------+--------------//--+-----------+--------------//--+- | Length1| TrunkGroup1| Length2| TrunkGroup2| ... +-----------+--------------//--+-----------+--------------//--+-
Figure 3: TrunkGroup Syntax
図3: TrunkGroup構文
4.5.2. Route Origination and TrunkGroup
4.5.2. ルート創作とTrunkGroup
Routes MAY be originated containing the TrunkGroup attribute.
ルートはTrunkGroupが結果と考える溯源された含有であるかもしれません。
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.
TrunkGroup属性はルート選択に使用されるかもしれません。 あるtrunkgroupsはプロバイダー方針に基づく他のものより好まれるかもしれません。
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.
この属性が頻繁に変化しないと予想されます。 したがって、この属性を受けるLSはITADへの内部の他の同輩にそれを広めるかもしれません。 播種性のがTrunkGroup属性があるITADに外部でなかったなら、SHOULDを発送します。
Bangalore, et al. Standards Track [Page 14] RFC 5140 TGREP March 2008
バンガロール、他 規格は2008年のTGREP行進のときにRFC5140を追跡します[14ページ]。
4.6. Carrier Attribute
4.6. キャリヤー属性
Mandatory: False. Required Flags: Not well-known. Potential Flags: None. TRIP Type Code: 20.
義務的: 誤る。 必要な旗: 周知のことでない。 可能性は弛みます: なし。 旅行タイプコード: 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.
Carrier属性は、ゲートウェイが呼び出しを終了するのに使用するキャリヤーのリストを表すのに使用されます。 それは、プロバイダーが好きな運送会社を通して呼び出しを目的地に発送するのを可能にします。 この属性は比較的静的です。
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].
Carrier属性はキャリヤー識別子の系列で構成される可変長の属性です。 それは、ルートがキャリヤー識別子[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.
それぞれのキャリヤー識別子はLength-値の分野(以下の図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分野はデリミタを含むValue分野の総サイズを表します。
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としての属性のLength分野があるCarrier属性の存在は、TGREP GWが与えられたReachableルートへのすべてのCarriersを終えることができるのを意味します。
< 1 octet > < Length1 octets > < 1 octet > < Length2 octets >
1つの八重奏の1つの八重奏の<><Length1八重奏><><Length2八重奏>。
+-----------+--------------//--+-----------+--------------//--+- | Length1 | Carrier 1 | Length2 | Carrier 2 | ... +-----------+--------------//--+-----------+--------------//--+-
+-----------+--------------//--+-----------+--------------//--+- | Length1| キャリヤー1| Length2| キャリヤー2| ... +-----------+--------------//--+-----------+--------------//--+-
Figure 4: Carrier Syntax
図4: キャリヤー構文
4.6.2. Route Origination and Carrier
4.6.2. ルート創作とキャリヤー
Routes MAY be originated containing the Carrier attribute.
ルートはCarrierが結果と考える溯源された含有であるかもしれません。
Bangalore, et al. Standards Track [Page 15] RFC 5140 TGREP March 2008
バンガロール、他 規格は2008年のTGREP行進のときにRFC5140を追跡します[15ページ]。
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.
Carrier属性はルート選択に使用されるかもしれません。 確信しているキャリヤーはプロバイダー方針に基づく他のものより好まれるかもしれません。
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.
異なったCarrier属性があるルートを集めてはいけません。 Carrier属性における同じ値があるルートは集められたかもしれません、そして、同じCarrier属性は集められたオブジェクトに付きました。
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.
この属性が頻繁に変化しないと予想されます。 したがって、この属性を受けるLSは内部の、そして、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]で説明されるように、Address Family分野はルートへのアドレスのタイプに与えます。 2つの新しいアドレスファミリーと彼らのコードはこのセクションで定義されます:
Code Address Family
4 TrunkGroup
5 Carrier
コードアドレスファミリー4TrunkGroup5キャリヤー
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の1セットがキャリヤーかtrunkgroupsの粒状で経営されることになっているなら、GWがCarrierアドレスファミリーかTrunkGroupアドレスファミリーを使用するルートの広告を出すのは、それぞれより適切であるかもしれません。 また、そのゲートウェイを管理するのに原因となるゲートウェイとLSとのTGREP協会で、広告を出している接頭語のものよりむしろ、例えばtrunkgroupsかキャリヤーの広告を出している特性として、より自然に適合するいくつかの属性があります、特定のtrunkgroupか特定のキャリヤーのAvailableCircuit情報。 この関係を言い表すために、既存のTRIPアドレスファミリーは不十分です。 私たちはtrunkgroupsへの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.
- それで、サービスプロバイダーは厳密に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やキャリヤーのようなダイナミックな自然の属性の、より正確な報告を容易にします。
Bangalore, et al. Standards Track [Page 16] RFC 5140 TGREP March 2008
バンガロール、他 規格は2008年のTGREP行進のときにRFC5140を追跡します[16ページ]。
- 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.
- ゲートウェイが支給数百か数1,000個の回路を能力で本当に大きく始めることができるようにそれはスケーラビリティを可能にします、そして、これはゲートウェイとLSの間のダイナミックなリソース情報を報告するトラフィックの可能性を増強できます。 したがって、効率を増強して、スケーラブルなゲートウェイ登録モデルを提供して、紹介されたモデルは潜在的にこのUPDATEトラフィックを軽減できます。
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) ...
+---------------+---------------+---------------+---------------+
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 +---------------+---------------+---------------+---------------+ | アドレスファミリー| アプリケーション・プロトコル| +---------------+---------------+---------------+---------------+ | 長さ| アドレス(可変)… +---------------+---------------+---------------+---------------+
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.
Address Family分野は、TrunkGroupかCarrierに基づいているこのファミリーのために関連づけられたアドレスのタイプの代理をするのに使用されるでしょう。 新しいアドレスファミリーのためのコードはIANAによって割り当てられました。
The code for the TrunkGroup address family is 4, and the code for the Carrier address family is 5.
TrunkGroupアドレスファミリーのためのコードは4です、そして、Carrierアドレスファミリーのためのコードは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.
Applicationプロトコル分野はファミリーがTRIP[2]で定義したDecimal、Pentadecimal、およびE.164アドレスのためのものと同じです。 Length分野はバイトで表現されるAddress分野の総サイズを表します。
The value in the Address field represents either the TrunkGroup or Carrier address family, and the syntax is as follows:
Address分野の値はTrunkGroupかCarrierアドレスファミリーの代理をします、そして、構文は以下の通りです:
For the TrunkGroup address family, the Address field represents a TrunkGroup value that is defined as specified in Section 4.5.1, "TrunkGroup Syntax".
TrunkGroupアドレスファミリーのために、Address分野はセクション4.5.1、「TrunkGroup構文」で指定されているとして定義されるTrunkGroup値を表します。
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".
Carrierアドレスファミリーのために、Address分野はCarrier値を表します。 これはValue分野が、以前のセクション4.6.1で「キャリヤー構文」と指定したのと同じです。
Bangalore, et al. Standards Track [Page 17] RFC 5140 TGREP March 2008
バンガロール、他 規格は2008年のTGREP行進のときにRFC5140を追跡します[17ページ]。
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.
上記のアドレスファミリーは階層的であるのではなく、平坦です。 ゲートウェイがこれらのアドレスファミリーのどれかを養うなら、それはオープンメッセージ能力交渉フェーズでサポートされたRouteタイプのひとりとしてそのアドレスファミリーを含むべきです。
The following attributes are currently defined to be used with all the address families including the TrunkGroup and Carrier address families.
以下の属性は、現在、TrunkGroupとCarrierアドレスファミリーを入れるすべてのアドレスファミリーと共に使用されるために定義されます。
- AvailableCircuits attribute
- TotalCircuitCapacity attribute
- CallSuccess attribute
- CallSuccessが結果と考えるAvailableCircuits属性(TotalCircuitCapacity属性)
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つの属性がTrunkGroupかCarrierアドレスファミリーと共にゲートウェイによって使用されるのは、お勧めです、できれば。 これはゲートウェイの食糧を供給するために潜在的にフレームワークを報告するより効率的なリソース、およびスケーラブルなモデルを提供するでしょう。
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.
しかしながら、ゲートウェイがTrunkGroupかCarrierアドレスファミリーを使用していないとき、それはDecimal、Pentadecimal、およびE.164アドレスファミリーがある上の属性を使用するかもしれません。
The Prefix attribute cannot be used when the address family is E164 numbers, Pentadecimal routing numbers, or Decimal routing numbers.
アドレスファミリーが164Eの数、Pentadecimalルーティング番号、またはDecimalルーティング番号であるときに、Prefix属性を使用できません。
The Carrier attribute cannot be used if the address family type is Carrier.
アドレスファミリータイプがCarrierであるならCarrier属性を使用できません。
The TrunkGroup attribute cannot be used if the address family type is TrunkGroup.
アドレスファミリータイプがTrunkGroupであるならTrunkGroup属性を使用できません。
6. Gateway Operation
6. ゲートウェイ操作
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.
ゲートウェイは、ドメインのLocation Server(s)(密接にプロキシに結びつけられるLS)に可到達性の広告を出すのにTGREPを使用します。 ゲートウェイは、可到達性の広告を出すだけでありたいのでTRIP Send Onlyモードで作動しますが、他のゲートウェイと他のドメインの可到達性に関して学びたがっていません。 また、ゲートウェイはそれ自身の呼び出しルーティングデータベースを作成しないでしょう。 このセクションで、私たちはゲートウェイにおけるTGREPの操作について説明します。
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
TGREP受信機とのじっと見るセッションを開くとき、TGREPゲートウェイはまさにいかなる他のTRIP実体とも同じ手順に従います。 TGREPゲートウェイはOptional ParametersにSend Receive Capabilityを含んでいるオープンメッセージを送ります。 発信、能力を受けてください。
Bangalore, et al. Standards Track [Page 18] RFC 5140 TGREP March 2008
バンガロール、他 規格は2008年のTGREP行進のときにRFC5140を追跡します[18ページ]。
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.
Send Onlyへのゲートウェイで、設定されます。 また、オープンメッセージはゲートウェイによって養われたアドレスファミリーを含みます。 同輩セッション設立の残りはTRIPと同じです。
6.2. UPDATE Messages
6.2. アップデートメッセージ
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]でのUPDATE処理と同じです。 TGREP送付者はすべての義務的なTRIP属性をサポートしなければなりません。
6.3. KEEPALIVE Messages
6.3. KEEPALIVEメッセージ
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[2]のセクション4.4におけるTGREPゲートウェイと指定されるとしてのTRIP LSとのじっと見るセッションの間、定期的にKEEPALIVEメッセージを交換します。
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.
同じ手順はエラー処理にTGREPと共に使用されて、NOTIFICATIONを生成するTRIPと共にメッセージを使用しました。 唯一の違いはTGREPゲートウェイがUPDATEメッセージに対応してNOTIFICATIONメッセージを決して生成しないということです、UPDATEメッセージのコンテンツの如何にかかわらず。 どんなUPDATEメッセージも静かに捨てられます。
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.
TGREP有限状態機械がEstablished状態にあって、UPDATEメッセージが受信されているとき、UPDATEメッセージは静かに捨てられます、そして、TGREPゲートウェイはEstablished州に残っています。 それを除いて、TRIP有限状態機械とTGREP有限状態機械は同じです。
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ゲートウェイは1TRIP LSとの同時のセッションを維持するかもしれません。 TGREPゲートウェイは同輩TRIP LSあたり1つの呼び出しルーティングデータベースを維持します。 これらのデータベースはTRIP Adj-TRIBsのアウトに同等です、そして、したがって、私たちは彼らを外のAdj-TRIBs-GWと呼ぶつもりです。 Adj-TRIB-GWアウトは同輩TRIP LSに広告に掲載されたゲートウェイの可到達性情報を含んでいます。 このドキュメント(ことによると手動の構成による)の範囲の外に外のAdj-TRIB-GWデータベースがどう居住されるかがあります。
Bangalore, et al. Standards Track [Page 19] RFC 5140 TGREP March 2008
バンガロール、他 規格は2008年のTGREP行進のときにRFC5140を追跡します[19ページ]。
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ゲートウェイでデータベースはTRIPの中のAdj-TRIBsとLoc-TRIBに同等になりません、TGREPゲートウェイが同輩TRIP LSsからルートを学ばないで、またしたがって、呼び出しルート選択を実行しないので。
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)接頭語アドレスファミリー(164E、Pentadecimal、およびDecimal)、(b)TrunkGroupアドレスファミリー、または(c)キャリヤーアドレスファミリーのより多くのひとりのUPDATEsを送ってはいけません。 TGREPはオープンメッセージのルートタイプ能力で特選しているアドレスファミリーを指定するはずです。 そして、上の規則に違反するオープンメッセージのルートタイプ仕様はNOTIFICATIONメッセージで拒絶されるべきです。
6.8. Route Selection and Aggregation
6.8. ルート選択と集合
TRIP's route selection and aggregation operations MUST NOT be implemented by TGREP gateways.
TRIPのルート選択と集合操作はTGREPゲートウェイによって実装されてはいけません。
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.
先に述べたように、次にさらにLocation Serverに入れることができる可到達性情報を提供することにおけるTRIPへの賞賛のプロトコルであるとTGREPをみなすことができます。LS/プロキシシステムのアーキテクチャは以下の通りです: TRIP[2]に記録されるようにスピーカーとしてI-TRIP/E- TRIPネットワークで機能するTRIP LS利用は存在しています。 このコンポーネントはこの議論の目的のための「出口LS」として呼ばれます。 そして、1セットのゲートウェイに向かうシグナリングサーバがあります。 このシグナリングに関連して、また、サーバは作動が広告を出すために情報を発送しながら中でそれらのそれぞれがTGREPを使用することである複数のゲートウェイでじっと見るモードを受ける2番目のコンポーネントです。 受ける側になって1つ以上のTGREPセッションのこのコンポーネントはこの議論の目的のための「イングレスLS」か「TGREP受信機」として呼ばれます。 また、TGREPセッションのルートの広告を出す実体(通常ゲートウェイ)は「TGREP送付者」として呼ばれます。 TRIPメッセージを受け取るTGREP受信機は、各ゲートウェイから結果として起こるルーティング情報で取って、私たちが定義する別のプロセスにそれを「エクスポートします」。以下では、それが強化と集合を実行します、そのオーダーで。 すべてのゲートウェイから集合的なセットのルートを入力するとき、これらの操作は取るでしょう。 次に、結果として起こるTRIBは以下に示すようにLS-出口プロセスに入力されるように渡されて、次に、それはTRIPを通してこれらを広めることができます。 GW(s)と共にじっと見るTGREP受信機(通称Ingress LS)とTRIP LSとのインタフェース(出口LS)は完全に地域にかかわる事柄です。
Bangalore, et al. Standards Track [Page 20] RFC 5140 TGREP March 2008
バンガロール、他 規格は2008年のTGREP行進のときにRFC5140を追跡します[20ページ]。
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 |
| |
| |
| |
| |
| |
+-----------------+
+-------------------------------------------------------+ | +-------------------------------+ | | | +-+ +-+ | | TGREP| | |A| |C| | | +-----+ | | |g| |o| | | | | | +-------------+ | |g| |n| +-------------+ | | --| GW| | | | | |r| |s| | | | | +-----+ | | 旅行| | |e| |o| | | | +--- | | LS<。----------|g<--|l<。--- TGREP|-++-| +-----+ | | | | |a| |i| | セッション| | | | | | | (I-旅行/| | | t| | d| | 管理|、-、+ ++、-、-、--、| GW| | | 電子旅行、) | | |i| |a| | | | | +-----+ | | (出口LS) | | |o| |t| | |-+ +--- | +-----------/-+ | |n| |i| +-------------+ | | +-----+ | / | | | |o| | | --| | | / | | | |n| (イングレスLS) | | | GW| | / | +-+ +-+ | | +-----+ | / | TGREP受信機| | | / +-------------------------------+ | | / | | / | +-------/-----------------------------------------------+ / LS/Proxy / / / / /+/----------------+ | | | | | | | LS| | | | | | | | | | | +-----------------+
Figure 6: LS Architecture for TRIP-GW
図6: 旅行-GWのためのLSアーキテクチャ
Bangalore, et al. Standards Track [Page 21] RFC 5140 TGREP March 2008
バンガロール、他 規格は2008年のTGREP行進のときにRFC5140を追跡します[21ページ]。
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.
TGREP受信機(イングレスLS)は1門以上からルーティング情報を受け取るかもしれません。 複数のルートが同じ目的地に利用可能であることは、可能です。 これらの同じゲートウェイか複数のゲートウェイと異なった代替のルートを受け取るかもしれません。 各目的地へのゲートウェイルートのセットを合併されるのは、RECOMMENDEDです、候補ルートを提示する前に、Egress 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は目的地「一口408」のためにキャリヤー属性値C1と共にE.164アドレスファミリーにルートの広告を出します。
- Gateway B advertises a route for destination "SIP 408" on the
E.164 address family with Carrier attribute value C2.
- ゲートウェイBは目的地「一口408」のためにE.164アドレスファミリーにキャリヤー属性値のC2でルートの広告を出します。
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受信機は目的地「一口408」のためにこれらの構成しているルートをただ一つのルートにすなわち、独特のルート、"C1 C2""のキャリヤー属性値の組合であるキャリヤー属性で統合できます。 この操作は強化と呼ばれます。 上記の例では、独特のルートが統合されなかったなら1個以上のキャリヤーを通した目的地「一口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}.
別の例は異なったゲートウェイから同じ目的地に受けられた複数のCarrierかTrunkGroupアップデートからPrefix属性を統合することです。 Carrierの目的地Xへの2門からのCarrierアドレスファミリー(AF)アップデートがあります、そして、言わせてください、そして、接頭語属性値は1つのアップデート、およびもう片方からの919、973からの408、650です。 接頭語値408、650、919、973でこれらの2つのアップデートからの接頭語値をただ一つのCarrier 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.
一般に、候補ルートがいつTRIP LSに提示されるかとき、1セットのゲートウェイからのTGREPルートが統合されないかというゲートウェイルーティング情報の損失の可能性があります。 強化操作を異なったアドレスファミリーから異なった属性とルートに適用する詳細は個々のTGREP受信機実装に残されます。
Bangalore, et al. Standards Track [Page 22] RFC 5140 TGREP March 2008
バンガロール、他 規格は2008年のTGREP行進のときにRFC5140を追跡します[22ページ]。
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.
上で議論した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/プロキシが4081、4082 4080、年のためにルートを受け取るなら… 1セットのゲートウェイからの4089、それは、旅行で定義された集合手順を用いることでそれぞれの属性が計算されているまとめられたルート目的地「408」を持つためにこれらの異なった候補ルートに集められることができました。
8. Security Considerations
8. セキュリティ問題
The security considerations for TGREP are identical to that identified in TRIP [2] and are just restated here for the purposes of clarity.
TGREPのためのセキュリティ問題は、TRIP[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つのプロトコルを使用します: 認証ヘッダー(ああ)[6]と要約セキュリティ有効搭載量(超能力)[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.
AHヘッダーは同輩LSsの間で通過されたメッセージのデータ発生源認証、コネクションレスな保全、および任意の反反復操作による保護を提供します。 超能力ヘッダーはメッセージの発生源認証、コネクションレスな保全、反反復操作による保護、および秘密性を提供します。
Bangalore, et al. Standards Track [Page 23] RFC 5140 TGREP March 2008
バンガロール、他 規格は2008年のTGREP行進のときにRFC5140を追跡します[23ページ]。
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.
本書では超能力ヘッダーSHALLを使うことで定義されたプロトコルの実装は[10]についてセクション3.1.1に従います。([10]は保全の照合と暗号化のための最小のセットのアルゴリズムを定義します)。 同様に、AHヘッダーSHALLを使う実装が[10]のセクション3.2に従います。([10]は保全の照合のための最小のセットのアルゴリズムを定義します)。
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.
実装SHOULDは、オプションを合わせながら、より強健な状態で可能にするインターネット・キー・エクスチェンジプロトコル(IKEv2)[9]を使用します。 実装の秘密性にIKEv2 SHOULDサポート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.
Security Association(SA)[3]はそれによって運ばれたトラフィックへのセキュリティー・サービスを提供するシンプレクス「接続」です。 セキュリティー・サービスをAHか超能力の使用でSAに都合しますが、ともに都合するというわけではありません。 SAsの2つのタイプが定義されます: モードとトンネルモードを輸送してください。 交通機関SAは2人のホストの間のセキュリティ協会であり、TRIPセッションを保護するのに、2同輩LSsの間で適切です。
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の両方がCapabilities、Attributes、Address Families、およびApplicationプロトコルのために同じ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:
本書では定義された新しい属性のために割り当てられたAttribute Type Codesは以下に記載されています:
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]
コード属性参照---- --------- --------- 13 TotalCircuitCapacity[RFC5140]14AvailableCircuits[RFC5140]15CallSuccess[RFC5140]16E.164接頭語[RFC5140]17Pentadecimalルート設定数の接頭語[RFC5140]18 10進ルート設定数の接頭語[RFC5140]19TrunkGroup[RFC5140]20キャリヤー[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.
以下の小区分は本書では紹介された2つの新しいアドレスファミリーのために割り当てられたコードを示しています。
Bangalore, et al. Standards Track [Page 24] RFC 5140 TGREP March 2008
バンガロール、他 規格は2008年のTGREP行進のときにRFC5140を追跡します[24ページ]。
9.2.1. TrunkGroup Address Family
9.2.1. TrunkGroupアドレスファミリー
Code Address Family Reference
---- -------------- ---------
4 TrunkGroup [RFC5140]
コードアドレスファミリー参照---- -------------- --------- 4 TrunkGroup[RFC5140]
9.2.2. Carrier Address Family
9.2.2. キャリヤーアドレスファミリー
Code Address Family Reference
---- -------------- ---------
5 Carrier [RFC5140]
コードアドレスファミリー参照---- -------------- --------- 5キャリヤー[RFC5140]
10. Acknowledgments
10. 承認
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. 参照
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.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[2] Rosenberg, J., Salama, H., and M. Squire, "Telephony Routing
over IP (TRIP)", RFC 3219, January 2002.
[2] ローゼンバーグ、J.、サラマ、H.、およびM.は2002年1月に「電話はIP(旅行)の上で掘る」RFC3219に付き添います。
[3] Kent, S. and K. Seo, "Security Architecture for the Internet
Protocol", RFC 4301, December 2005.
[3] ケントとS.とK.Seo、「インターネットプロトコルのためのセキュリティー体系」、RFC4301、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)でTrunk Groupsを表します」、RFC4904、2007年6月。
[5] Yu, J., "Number Portability Parameters for the "tel" URI", RFC
4694, October 2006.
[5] ユー、J.、「"tel"URIのためのナンバーポータビリティパラメタ」、RFC4694、2006年10月。
[6] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[6] ケント、S.、「IP認証ヘッダー」、RFC4302、2005年12月。
[7] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303,
December 2005.
[7] ケント、S.、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC4303、2005年12月。
[8] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[8] エドクロッカー、D.、P.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、STD68、RFC5234、2008年1月。
[9] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC
4306, December 2005.
[9] コーフマン、C.、エド、「インターネット・キー・エクスチェンジ(IKEv2)プロトコル」、RFC4306、12月2005日
Bangalore, et al. Standards Track [Page 25] RFC 5140 TGREP March 2008
バンガロール、他 規格は2008年のTGREP行進のときにRFC5140を追跡します[25ページ]。
[10] Manral, V., "Cryptographic Algorithm Implementation Requirements
for Encapsulating Security Payload (ESP) and Authentication
Header (AH)", RFC 4835, April 2007.
[10]Manral、V.、「セキュリティが有効搭載量(超能力)と認証ヘッダー(ああ)であるとカプセル化するための暗号アルゴリズム実装要件」、RFC4835、2007年4月。
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.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[12] Rosenberg, J. and H. Schulzrinne, "A Framework for Telephony
Routing over IP", RFC 2871, June 2000.
[12] ローゼンバーグとJ.とH.Schulzrinne、「IPの上の電話ルート設定のためのフレームワーク」、RFC2871、2000年6月。
[13] ITU-T List of ITU Carrier Codes (published periodically in the
ITU-T Operational Bulletin).
[13] ITU Carrier Codes(ITU-T Operational Bulletinで定期的に発行される)のITU-T List。
[14] Rosenberg, J., "Requirements for Gateway Registration", Work in
Progress, November 2001.
[14] ローゼンバーグ、J.、「ゲートウェイ登録のための要件」が進歩、2001年11月に働いています。
Bangalore, et al. Standards Track [Page 26] RFC 5140 TGREP March 2008
バンガロール、他 規格は2008年のTGREP行進のときにRFC5140を追跡します[26ページ]。
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
サンノゼ、カリフォルニア 95134が電話をするManjunath S.バンガロールシスコメール停止SJC-14/2/1の3625コクチマス道: +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
サンノゼ、カリフォルニア 95134が電話をするラジニーシクマーコクチマスメール停止SJC-14/4/2の3625コクチマス道: +1-408-527-6148 メールしてください: rajneesh@cisco.com
Jonathan Rosenberg Cisco Edison, NJ 08837 EMail: jdrosen@cisco.com
ジョナサン・ローゼンバーグ・Ciscoエディソン、ニュージャージー 08837はメールされます: jdrosen@cisco.com
Hussein F. Salama Citex Software Giza, Egypt EMail: hsalama@citexsoftware.com
フセイン・F.サラマCitex Softwareギーザ(エジプト)はメールされます: 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シャーMoowee Inc.4920高架鉄道幹線道路カリフォルニア 94022は以下に電話をします。 +1-408-307-7455 メールしてください: dhaval@moowee.tv
Bangalore, et al. Standards Track [Page 27] RFC 5140 TGREP March 2008
バンガロール、他 規格は2008年のTGREP行進のときにRFC5140を追跡します[27ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を扱ってください。
Bangalore, et al. Standards Track [Page 28]
バンガロール、他 標準化過程[28ページ]
一覧
スポンサーリンク
