RFC2719 日本語訳
2719 Framework Architecture for Signaling Transport. L. Ong, I.Rytina, M. Garcia, H. Schwarzbauer, L. Coene, H. Lin, I. Juhasz, M.Holdrege, C. Sharp. October 1999. (Format: TXT=48646 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group L. Ong
Request for Comments: 2719 Nortel Networks
Category: Informational I. Rytina
M. Garcia
Ericsson
H. Schwarzbauer
L. Coene
Siemens
H. Lin
Telcordia
I. Juhasz
Telia
M. Holdrege
Lucent
C. Sharp
Cisco Systems
October 1999
コメントを求めるワーキンググループL.オングの要求をネットワークでつないでください: 2719 ノーテルはカテゴリをネットワークでつなぎます: 鋭いC.シスコシステムズ1999年10月に透明な情報のI.のTelcordia I.Juhasz冬胞子堆M.Rytina M.ガルシアエリクソンH.Schwarzbauer L.CoeneジーメンスH.リンHoldrege
Framework Architecture for Signaling Transport
シグナリング輸送のためのフレームワークアーキテクチャ
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
Abstract
要約
This document defines an architecture framework and functional requirements for transport of signaling information over IP. The framework describes relationships between functional and physical entities exchanging signaling information, such as Signaling Gateways and Media Gateway Controllers. It identifies interfaces where signaling transport may be used and the functional and performance requirements that apply from existing Switched Circuit Network (SCN) signaling protocols.
このドキュメントはIPの上でシグナリング情報の輸送のためのアーキテクチャフレームワークと機能条件書を定義します。 フレームワークはSignaling GatewaysやメディアゲートウェイControllersのシグナリング情報を交換する機能的で物理的な実体の間の関係について説明します。 それはプロトコルを示すシグナリング輸送が使用されるかもしれないインタフェースと既存のSwitched Circuit Network(SCN)から適用される機能的、そして、性能要件を特定します。
Ong, et al. Informational [Page 1] RFC 2719 Framework Architecture for Signaling Transport October 1999
オング、他 輸送1999年10月に合図するための情報[1ページ]のRFC2719フレームワークアーキテクチャ
Table of Contents
目次
1. Introduction..................................................2 1.1 Overview.....................................................2 1.2 Terminology..................................................3 1.3 Scope.......................................................5 2. Signaling Transport Architecture.............................5 2.1 Gateway Component Functions.................................5 2.2 SS7 Interworking for Connection Control.....................6 2.3 ISDN Interworking for Connection Control....................8 2.4 Architecture for Database Access............................9 3. Protocol Architecture........................................10 3.1 Signaling Transport Components..............................10 3.2 SS7 access for Media Gateway Control........................11 3.3 Q.931 Access to MGC.........................................12 3.4 SS7 Access to IP/SCP........................................12 3.5 SG to SG....................................................14 4. Functional Requirements......................................15 4.1 Transport of SCN Signaling Protocols........................15 4.2 Performance of SCN Signaling Protocols......................17 4.2.1 SS7 MTP Requirements......................................17 4.2.2 SS7 MTP Level 3 Requirements..............................17 4.2.3 SS7 User Part Requirements................................18 4.2.4 ISDN Signaling Requirements...............................18 5. Management...................................................19 6. Security Considerations......................................19 6.1 Security Requirements.......................................19 6.2 Security Mechanisms Currently Available in IP Networks......20 7. Abbreviations................................................21 8. Acknowledgements.............................................21 9. References...................................................21 Authors' Addresses..............................................22 Full Copyright Statement........................................24
1. 序論…2 1.1概要…2 1.2用語…3 1.3範囲…5 2. シグナリングはアーキテクチャを輸送します…5 2.1ゲートウェイの部品は機能します…5 2.2 接続のために織り込むSS7が制御します…6 接続のためにコントロールを織り込む2.3ISDN…8 データベースアクセサリーのための2.4アーキテクチャ…9 3. アーキテクチャについて議定書の中で述べてください…10 3.1 シグナリング輸送コンポーネント…10 3.2 SS7はメディアのためにゲートウェイControlにアクセスします…11 3.3 MGCへのQ.931アクセス…12 3.4 IP/SCPへのSS7アクセス…12 SGへの3.5SG…14 4. 機能条件書…15 4.1 SCNシグナリングプロトコルの輸送…15 SCNシグナリングプロトコルの4.2パフォーマンス…17 4.2 .1 SS7 MTP要件…17 4.2 .2 SS7 MTPは3つの要件を平らにします…17 4.2 .3 SS7ユーザ部分要件…18 4.2 .4 ISDNシグナリング要件…18 5. 管理…19 6. セキュリティ問題…19 6.1 セキュリティ要件…19 6.2 現在IPネットワークで利用可能なセキュリティメカニズム…20 7. 略語…21 8. 承認…21 9. 参照…21人の作者のアドレス…22 完全な著作権宣言文…24
1. Introduction
1. 序論
1.1 Overview
1.1 概要
This document defines an architecture framework for transport of message-based signaling protocols over IP networks. The scope of this work includes definition of encapsulation methods, end-to-end protocol mechanisms and use of existing IP capabilities to support the functional and performance requirements for signaling transport.
このドキュメントはメッセージベースのシグナリングプロトコルの輸送のためにIPネットワークの上でアーキテクチャフレームワークを定義します。 この仕事の範囲はシグナリング輸送のための機能的、そして、性能要件をサポートする既存のIP能力のカプセル化メソッドの定義、終わりから終わりへのプロトコルメカニズム、および使用を含んでいます。
The framework portion describes the relationships between functional and physical entities used in signaling transport, including the framework for control of Media Gateways, and other scenarios where signaling transport may be required.
フレームワーク部分はシグナリング輸送に使用される機能的で物理的な実体の間の関係について説明します、シグナリング輸送が必要であるかもしれないメディアGateways、および他のシナリオのコントロールのためのフレームワークを含んでいて。
Ong, et al. Informational [Page 2] RFC 2719 Framework Architecture for Signaling Transport October 1999
オング、他 輸送1999年10月に合図するための情報[2ページ]のRFC2719フレームワークアーキテクチャ
The requirements portion describes functional and performance requirements for signaling transport such as flow control, in- sequence delivery and other functions that may be required for specific SCN signaling protocols.
シグナリングがフロー制御や、コネ系列配送や他の機能などのようにそれを輸送するので、部分が機能的、そして、性能要件について説明するという要件が特定のSCNシグナリングプロトコルに必要であるかもしれません。
1.2 Terminology
1.2 用語
The following are general terms are used in this document:
以下による一般項が本書では使用されるということです:
Backhaul:
逆送:
Backhaul refers to the transport of signaling from the point of interface for the associated data stream (i.e., SG function in the MGU) back to the point of call processing (i.e., the MGCU), if this is not local.
逆送は関連データストリーム(すなわち、SGはMGUで機能する)のためにインタフェースのポイントから呼び出し処理(すなわち、MGCU)まで合図する輸送について言及します、これが地方ならでない。
Signaling Transport (SIG):
シグナリング輸送(SIG):
SIG refers to a protocol stack for transport of SCN signaling protocols over an IP network. It will support standard primitives to interface with an unmodified SCN signaling application being transported, and supplements a standard IP transport protocol underneath with functions designed to meet transport requirements for SCN signaling.
SIGはIPネットワークの上でプロトコルに合図するSCNの輸送についてプロトコル・スタックについて言及します。 それは、機能がある下部がSCNシグナリングのための輸送必要条件を満たすように設計した標準のIPトランスポート・プロトコルを輸送されるアプリケーション、および補足に合図する変更されていないSCNに連結するように標準の基関数をサポートするでしょう。
Switched Circuit Network (SCN):
交換回線網ネットワーク(SCN):
The term SCN is used to refer to a network that carries traffic within channelized bearers of pre-defined sizes. Examples include Public Switched Telephone Networks (PSTNs) and Public Land Mobile Networks (PLMNs). Examples of signaling protocols used in SCN include Q.931, SS7 MTP Level 3 and SS7 Application/User parts.
存在というトラフィックを運ぶネットワークを示すのに使用される用語SCNは中で事前に定義されたサイズの運搬人をchannelizedしました。 例は公衆交換電話網(PSTNs)とPublic LandのモバイルNetworks(PLMNs)を含んでいます。 SCNで使用されるシグナリングプロトコルに関する例はQ.931、SS7 MTP Level3、およびSS7 Application/ユーザの部品を含んでいます。
The following are terms for functional entities relating to signaling transport in a distributed gateway model.
↓これは分配されたゲートウェイモデルにおけるシグナリング輸送に関連する機能的な実体のための用語です。
Media Gateway (MG):
メディアゲートウェイ(mg):
A MG terminates SCN media streams, packetizes the media data,, if it is not already packetized, and delivers packetized traffic to the packet network. It performs these functions in reverse order for media streams flowing from the packet network to the SCN.
A MGがSCNメディアストリームを終えて、メディアデータをpacketizesする、既にpacketizedされないで、packetizedトラフィックをパケット網に提供するなら。 それはパケット網からSCNまで流れるメディアストリームのために逆順でこれらの機能を実行します。
Ong, et al. Informational [Page 3] RFC 2719 Framework Architecture for Signaling Transport October 1999
オング、他 輸送1999年10月に合図するための情報[3ページ]のRFC2719フレームワークアーキテクチャ
Media Gateway Controller (MGC):
メディアゲートウェイコントローラ(MGC):
An MGC handles the registration and management of resources at the MG. The MGC may have the ability to authorize resource usage based on local policy. For signaling transport purposes, the MGC serves as a possible termination and origination point for SCN application protocols, such as SS7 ISDN User Part and Q.931/DSS1.
MGCはMGでリソースの登録と管理を扱います。 MGCには、ローカルの方針に基づくリソース用法を認可する能力があるかもしれません。 シグナリング輸送目的のために、可能な終了と創作がSCNアプリケーション・プロトコルのために指すとき、MGCは役立ちます、SS7 ISDN User PartやQ.931/DSS1のように。
Signaling Gateway (SG):
シグナリングゲートウェイ(SG):
An SG is a signaling agent that receives/sends SCN native signaling at the edge of the IP network. The SG function may relay, translate or terminate SS7 signaling in an SS7-Internet Gateway. The SG function may also be co-resident with the MG function to process SCN signaling associated with line or trunk terminations controlled by the MG (e.g., signaling backhaul).
SGはIPネットワークの縁でネイティブのシグナリングをSCNに受けるか、または送るシグナル伝達物質です。 SG機能は、SS7-インターネットゲートウェイでSS7シグナリングをリレーするか、翻訳するか、または終えるかもしれません。 また、SG機能はMG(例えば、シグナリング逆送)によって制御される系列かトランク終了に関連しているSCNシグナリングを処理するMG機能のコレジデントであるかもしれません。
The following are terms for physical entities relating to signaling transport in a distributed gateway model:
↓これは分配されたゲートウェイモデルにおけるシグナリング輸送に関連する物理的実体のための用語です:
Media Gateway Unit (MGU)
メディアゲートウェイユニット(MGU)
An MG-Unit is a physical entity that contains the MG function. It may contain other functions, esp. an SG function for handling facility-associated signaling.
MG-ユニットはMG機能を含む物理的実体です。 それは、施設で関連しているシグナリングを扱うために他の機能、特にSG機能を含むかもしれません。
Media Gateway Control Unit (MGCU)
メディアゲートウェイ制御装置(MGCU)
An MGC-Unit is a physical entity containing the MGC function.
MGC-ユニットはMGC機能を含む物理的実体です。
Signaling Gateway Unit (SGU)
シグナリングゲートウェイユニット(SGU)
An SG-Unit is a physical entity containing the SG function.
SG-ユニットはSG機能を含む物理的実体です。
Signaling End Point (SEP):
シグナリングエンドポイント(9月):
This is a node in an SS7 network that originates or terminates signaling messages. One example is a central office switch.
これはシグナリングメッセージを溯源するか、または終えるSS7ネットワークでノードです。 1つの例が電話局スイッチです。
Signal Transfer Point (STP):
転送ポイント(STP)に合図してください:
This is a node in an SS7 network that routes signaling messages based on their destination point code in the SS7 network.
これはSS7ネットワークでそれらの目的地ポイントコードに基づくシグナリングメッセージを発送するSS7ネットワークでノードです。
Ong, et al. Informational [Page 4] RFC 2719 Framework Architecture for Signaling Transport October 1999
オング、他 輸送1999年10月に合図するための情報[4ページ]のRFC2719フレームワークアーキテクチャ
1.3 Scope
1.3 範囲
Signaling transport provides transparent transport of message-based signaling protocols over IP networks. The scope of this work includes definition of encapsulation methods, end-to-end protocol mechanisms and use of IP capabilities to support the functional and performance requirements for signaling.
シグナリング輸送はメッセージベースのシグナリングプロトコルのわかりやすい輸送をIPネットワークの上に提供します。 この仕事の範囲はシグナリングのための機能的、そして、性能要件をサポートするIP能力のカプセル化メソッドの定義、終わりから終わりへのプロトコルメカニズム、および使用を含んでいます。
Signaling transport shall be used for transporting SCN signaling between a Signaling Gateway Unit and Media Gateway Controller Unit. Signaling transport may also be used for transport of message-based signaling between a Media Gateway Unit and Media Gateway Controller Unit, between dispersed Media Gateway Controller Units, and between two Signaling Gateway Units connecting signaling endpoints or signal transfer points in the SCN.
シグナリング輸送は、SignalingゲートウェイUnitとメディアゲートウェイController Unitの間で合図するSCNを輸送するのに使用されるものとします。 また、シグナリング輸送はメディアのゲートウェイUnitとメディアゲートウェイController Unitの間と、そして、分散メディアゲートウェイController Unitsの間と、そして、SCNの終点か信号転送ポイントに合図しながら接続する2SignalingゲートウェイUnitsの間のメッセージベースのシグナリングの輸送に使用されるかもしれません。
Signaling transport will be defined in such a way as to support encapsulation and carriage of a variety of SCN protocols. It is defined in such a way as to be independent of any SCN protocol translation functions taking place at the endpoints of the signaling transport, since its function is limited to the transport of the SCN protocol.
シグナリング輸送はさまざまなSCNプロトコルのサポートカプセル化とキャリッジに関してそのような方法で定義されるでしょう。 それはシグナリング輸送の終点で行われるどんなSCNプロトコル変換機能からも独立しているほどそのような方法で定義されます、機能がSCNプロトコルの輸送に制限されるので。
Since the function being provided is transparent transport, the following areas are considered outside the scope of the signaling transport work:
提供される、機能存在以来わかりやすい輸送、以下の領域がシグナリング輸送仕事の範囲の外で考えられるということです:
- definition of the SCN protocols themselves.
- signaling interworking such as conversion from Channel Associated
Signaling (CAS) to message signaling protocols.
- specification of the functions taking place within the SGU or MGU
- in particular, this work does not address whether the SGU provides
mediation/interworking, as this is transparent to the transport
function.
- similarly, some management and addressing functions taking place
within the SGU or MGU are also considered out of scope, such as
determination of the destination IP address for signaling, or
specific procedures for assessing the performance of the transport
session (i.e., testing and proving functions).
- SCNプロトコル自体の定義。 - Channel Associated Signaling(CAS)からメッセージシグナリングプロトコルまでの変換などを織り込むことように合図します。 - SGUかMGUの中で行われる機能の仕様--SGUが仲介/織り込むことを提供するか否かに関係なく、特に、この仕事はどんなアドレスもしません、これが輸送機能に透明であるときに。 - また、同様に、SGUかMGUの中で行われる何らかの管理と機能を扱うのは範囲から考えられます、シグナリングのための送付先IPアドレス、または輸送セッションの性能を評価するための特定の手順(すなわち、機能をテストして、立証する)の決断などのように。
2. Signaling Transport Architecture
2. シグナリング輸送アーキテクチャ
2.1 Gateway Component Functions
2.1 ゲートウェイコンポーネント機能
Figure 1 defines a commonly defined functional model that separates out the functions of SG, MGC and MG. This model may be implemented in a number of ways, with functions implemented in separate devices or combined in single physical units.
図1はSG、MGC、およびMGの機能を分離する一般的に定義された機能論的モデルを定義します。 このモデルは多くの方法で実装されるかもしれません、機能が別々のデバイスで実装されるか、または単一の物理装置で結合されている状態で。
Ong, et al. Informational [Page 5] RFC 2719 Framework Architecture for Signaling Transport October 1999
オング、他 輸送1999年10月に合図するための情報[5ページ]のRFC2719フレームワークアーキテクチャ
Where physical separation exists between functional entities, Signaling Transport can be applied to ensure that SCN signaling information is transported between entities with the required functionality and performance.
物理的分離が機能的な実体の間に存在しているところでは、SCNシグナリング情報が実体の間で必要な機能性と性能で輸送されるのを保証するためにSignaling Transportを適用できます。
+---------------+ +--------------+
| | | |
SCN<-------->[SG] <--+---------O------------+--> [SG] <------> SCN
signal | | | | | | signal
+-------|-------+ +-----|--------+
Signaling|gateway Signaling|gateway (opt)
O O
| |
+-------|-------+ +-----|--------+
| | | | | |
| [MGC] <--+--------O-------------+--> [MGC] |
| | | | | |
| | | | | |
+-------|-------+ +-----|--------+
Gateway | controller Gateway | controller (opt)
O O
| |
+-------|-------+ +-----|--------+
Media | | | | | | Media
<------+---->[MG] <---+-----RTP stream-------+-> [MG] <----+-------->
stream| | | | stream
+---------------+ +--------------+
Media gateway Media gateway
+---------------+ +--------------+ | | | | SCN<。-------->[SG]<--+---------O------------+-->[SG]<。------>SCN信号| | | | | | 信号+-------|-------+ +-----|--------+ シグナリング|ゲートウェイSignaling|ゲートウェイ(選ぶ)O O| | +-------|-------+ +-----|--------+ | | | | | | | [MGC]<--+--------O-------------+-->[MGC]| | | | | | | | | | | | | +-------|-------+ +-----|--------+ ゲートウェイ| コントローラゲートウェイ| コントローラ(選ぶ)O O| | +-------|-------+ +-----|--------+ メディア| | | | | | メディア<。------+---->[mg]<。---+-----RTPストリーム-------+->[mg]<。----+-------->ストリーム| | | | ストリーム+---------------+ +--------------+ メディアゲートウェイメディアゲートウェイ
Figure 1: Sigtran Functional Model
図1: Sigtran機能論的モデル
As discussed above, the interfaces pertaining to signaling transport include SG to MGC, SG to SG. Signaling transport may potentially be applied to the MGC to MGC or MG to MGC interfaces as well, depending on requirements for transport of the associated signaling protocol.
上で議論するように、シグナリング輸送に関係するインタフェースはMGC、SGへのSGをSGに含めます。 シグナリング輸送は潜在的にMGCへのMGCかまた、MGCインタフェースへのMGに適用されるかもしれません、関連シグナリングプロトコルの輸送のための要件によって。
2.2 SS7 Interworking for Connection Control
2.2 接続のためにコントロールを織り込むSS7
Figure 2 below shows some example implementations of these functions in physical entities as used for interworking of SS7 and IP networks for Voice over IP, Voice over ATM, Network Access Servers, etc. No recommendation is made as to functional distribution and many other examples are possible but are not shown to be concise. The use of signaling transport is independent of the implementation.
以下の図2はSS7を織り込むのとボイス・オーバー IP、ATMの上のVoice、Network Access ServersなどのためのIPネットワークに使用されるように物理的実体におけるこれらの機能のいくつかの例の実装を示しています。 機能的分配に関して推薦状を全くしないで、他の多くの例は、可能ですが、簡潔になるように示されません。 シグナリング輸送の使用は実装から独立しています。
Ong, et al. Informational [Page 6] RFC 2719 Framework Architecture for Signaling Transport October 1999
オング、他 輸送1999年10月に合図するための情報[6ページ]のRFC2719フレームワークアーキテクチャ
For interworking with SS7-controlled SCN networks, the SG terminates the SS7 link and transfers the signaling information to the MGC using signaling transport. The MG terminates the interswitch trunk and controls the trunk based on the control signaling it receives from the MGC. As shown below in case (a), the SG, MGC and MG may be implemented in separate physical units, or as in case (b), the MGC and MG may be implemented in a single physical unit.
SS7によって制御されたSCNと共にネットワークを織り込むために、SGはシグナリング輸送を使用することでSS7リンクを終えて、シグナリング情報をMGCに移します。 MGはトランクがそれがMGCから受けるコントロールシグナリングに基礎づけたinterswitchトランクとコントロールを終えます。 以下に示すように、(a)、SG、MGC、およびMGが別々の物理装置、またはケース(b)のように実装されるといけないかもしれないので、MGCとMGは単一の物理装置で実装されるかもしれません。
In alternative case (c), a facility-associated SS7 link is terminated by the same device (i.e., the MGU) that terminates the interswitch trunk. In this case, the SG function is co-located with the MG function, as shown below, and signaling transport is used to "backhaul" control signaling to the MGCU.
代替の場合(c)では、interswitchトランクを終えるのと同じデバイス(すなわち、MGU)によって施設で関連しているSS7リンクは終えられます。 この場合、SG機能は以下に示すようにMG機能で共同見つけられています、そして、シグナリング輸送はMGCUに合図する「逆送」コントロールに使用されます。
Note: SS7 links may also be terminated directly on the MGCU by cross-connecting at the physical level before or at the MGU.
以下に注意してください。 また、SS7リンクは、直接MGCUでMGUの前かMGUの物理的なレベルで十字で接続することによって、終えられるかもしれません。
SGU
+--------+
SS7<------>[SG] |
(ISUP) | | |
+---|----+
ST | SGU MGCU
+---|----+ +--------+ +--------+
| [MGC] | SS7---->[SG] | | [MGC] |
| | | | | | | | | |
+---|----+ +---|----+ +--|-|---+
MGCU | ST | | |
| | ST | |
Media +---|----+ Media +---|----+ +--|-|---+
------->[MG] | ----->[MG/MGC]| SS7 link-->[SG]| |
stream | | stream | | Media------> [MG] |
+--------+ +--------+ stream +--------+
MGU MGU MGU
SGU+--------+ SS7<。------>[SG]| (ISUP) | | | +---|----第+| SGU MGCU+---|----+ +--------+ +--------+ | [MGC]| SS7---->[SG]| | [MGC]| | | | | | | | | | | +---|----+ +---|----+ +--|-|---+ MGCU| st| | | | | st| | メディア+---|----+ メディア+---|----+ +--|-|---+ ------->[mg]| ----->[mg/MGC]| SS7リンク-->[SG]| | ストリーム| | ストリーム| | メディア------>[mg]| +--------+ +--------+ ストリーム+--------+ MGU MGU MGU
(a) (b) (c)
(a) (b)(c)
Notes: ST = Signaling Transport used to carry SCN signaling
注意: シグナリングST=Transportは以前はよくSCNシグナリングを運びました。
Figure 2: Example Implementations
図2: 例の実装
Ong, et al. Informational [Page 7] RFC 2719 Framework Architecture for Signaling Transport October 1999
オング、他 輸送1999年10月に合図するための情報[7ページ]のRFC2719フレームワークアーキテクチャ
In some implementations, the function of the SG may be divided into multiple physical entities to support scaling, signaling network management and addressing concerns. Thus, Signaling Transport can be used between SGs as well as from SG to MGC. This is shown in Figure 3 below.
いくつかの実装では、SGの機能は、サポートするネットワークマネージメントに合図して、比例する複数の物理的実体に分割されて、危惧に対処しているかもしれません。 したがって、SGsとSGからMGCまでSignaling Transportを使用できます。 これは以下の図3に示されます。
SGU MGCU
+---------+ +---------+
| | ST | |
| [SG2]------------------------------>[MGC] |
| ^ ^ | | |
+---|-|---+ +---------+
| |
| | ST
ST| +--------------------------------+
| |
| |
SS7 +---|----------+ SS7 +----|---------+
-----------> [SG1] | -----------> [SG1] |
media | | media | |
------------------->[MG] | ------------------->[MG] |
stream +--------------+ stream +--------------+
MGU MGU
SGU MGCU+---------+ +---------+ | | st| | | [SG2]------------------------------>[MGC]| | ^ ^ | | | +---|-|---+ +---------+ | | | | st| +--------------------------------+ | | | | SS7+---|----------+ SS7+----|---------+ ----------->[SG1]| ----------->[SG1]| メディア| | メディア| | ------------------->[mg]| ------------------->[mg]| ストリーム+--------------+ ストリーム+--------------+ MGU MGU
Figure 3: Multiple SG Case
図3: 複数のSGケース
In this configuration, there may be more than one MGU handling facility associated signaling (i.e. more than one containing it's own SG function), and only a single SGU. It will therefore be possible to transport one SS7 layer between SG1 and SG2, and another SS7 layer between SG2 and MGC. For example, SG1 could transport MTP3 to SG2, and SG2 could transport ISUP to MGC.
この構成には、1つ以上のMGU取り扱い施設関連しているシグナリングがあるかもしれない、(すなわち、ある含有以上、それの自己のSG機能)、そして、独身のSGUだけ。 したがって、SG1とSG2の間で1つのSS7層を輸送して、SG2とMGCの間で別のSS7層を輸送するのは可能でしょう。 例えば、SG1はMTP3をSG2に輸送できました、そして、SG2はISUPをMGCに輸送できました。
2.3 ISDN Interworking for Connection Control
2.3 接続のためにコントロールを織り込むISDN
In ISDN access signaling, the signaling channel is carried along with data channels, so that the SG function for handling Q.931 signaling is co-located with the MG function for handling the data stream. Where Q.931 is then transported to the MGC for call processing, signaling transport would be used between the SG function and MGC. This is shown in Figure 3 below.
ISDNアクセスシグナリングでは、シグナリングチャンネルはデータ・チャンネルと共に運ばれます、取り扱いQ.931シグナリングのためのSG機能がデータ・ストリームを扱うためのMG機能で共同見つけられているように。 次に、Q.931が呼び出し処理のためにMGCに輸送されるところでは、シグナリング輸送はSG機能とMGCの間で使用されるでしょう。 これは以下の図3に示されます。
Ong, et al. Informational [Page 8] RFC 2719 Framework Architecture for Signaling Transport October 1999
オング、他 輸送1999年10月に合図するための情報[8ページ]のRFC2719フレームワークアーキテクチャ
MGCU
+-------------+
| [MGC] |
| | | |
+-----|-|-----+
| |
| O device control
| |
Q.931/ST O |
| |
+-----|-|-----+
| | | |
Q.931---->[SG]| |
signals| | |
| | |
Media---->[MG] |
stream | |
+-------------+
MGU
MGCU+-------------+ | [MGC]| | | | | +-----|-|-----+ | | | ○ 装置制御| | Q.931/第o| | | +-----|-|-----+ | | | | Q.931---->[SG]| | 信号| | | | | | メディア---->[mg]| ストリーム| | +-------------+ MGU
Figure 4: Q.931 transport model
図4: Q.931輸送モデル
2.4 Architecture for Database Access
2.4 データベースアクセスのためのアーキテクチャ
Transaction Capabilities (TCAP) is the application part within SS7 that is used for non-circuit-related signaling.
トランザクションCapabilities(TCAP)は非回路関連のシグナリングに使用されるSS7の中のアプリケーション部分です。
TCAP signaling within IP networks may be used for cross-access between entities in the SS7 domain and the IP domain, such as, for example:
IPネットワークの中で合図するTCAPはSS7ドメインとIPドメインの実体の間の交差しているアクセスに使用されるかもしれません、あれほど、例えば:
- access from an SS7 network to a Service Control Point (SCP) in IP. - access from an SS7 network to an MGC. - access from an MGC to an SS7 network element. - access from an IP SCP to an SS7 network element.
- IPで(SCP)にSS7ネットワークからService Control Pointまでアクセスしてください。 - SS7ネットワークからMGCまでのアクセス。 - MGCからSS7ネットワーク要素までのアクセス。 - IP SCPからSS7ネットワーク要素までのアクセス。
A basic functional model for TCAP over IP is shown in Figure 5.
IPの上のTCAPの基本的な機能論的モデルは図5で見せられます。
Ong, et al. Informational [Page 9] RFC 2719 Framework Architecture for Signaling Transport October 1999
オング、他 輸送1999年10月に合図するための情報[9ページ]のRFC2719フレームワークアーキテクチャ
+--------------+
| IP SCP |
+--|----|------+
| |
SGU | | SGU
+--------------+ | | +--------------+
| | | | | |
SS7<--------->[SG] ---------+ | | [SG]<---------> SS7
(TCAP) | | | | | | |
+------|-------+ | +------|-------+
| | |
O +------------+ O
MGCU | | | MGCU
+-------|----|--+ +-----|--------+
| | | | | | |
| [MGC] | | [MGC] |
| | | | | |
+-------|-------+ +-----|--------+
| |
+-------|-------+ +-----|------+
Media | | | | | | Media
<------+---->[MG] <---+--RTP stream---+--> [MG] <-+-------->
stream| | | | stream
+---------------+ +------------+
MGU MGU
+--------------+ | IP SCP| +--|----|------+ | | SGU| | SGU+--------------+ | | +--------------+ | | | | | | SS7<。--------->[SG]---------+ | | [SG]<。--------->SS7(TCAP)| | | | | | | +------|-------+ | +------|-------+ | | | ○ +------------+ ○ MGCU| | | MGCU+-------|----|--+ +-----|--------+ | | | | | | | | [MGC]| | [MGC]| | | | | | | +-------|-------+ +-----|--------+ | | +-------|-------+ +-----|------+ メディア| | | | | | メディア<。------+---->[mg]<。---+--RTPは流れます。---+-->[mg]<-+-------->ストリーム| | | | ストリーム+---------------+ +------------+ MGU MGU
Figure 5: TCAP Signaling over IP
図5: IPの上で合図するTCAP
3. Protocol Architecture
3. プロトコルアーキテクチャ
This section provides a series of examples of protocol architecture for the use of Signaling Transport (SIG).
このセクションはSignaling Transport(SIG)の使用にプロトコルアーキテクチャに関する一連の例を提供します。
3.1 Signaling Transport Components
3.1 シグナリング輸送コンポーネント
Signaling Transport in the protocol architecture figures below is assumed to consist of three components (see Figure 6):
以下のプロトコルアーキテクチャの数字でTransportに合図するのが3つのコンポーネントから成ると思われます(図6を見てください):
1) an adaptation sub-layer that supports specific primitives, e.g.,
management indications, required by a particular SCN signaling
application protocol.
2) a Common Signaling Transport Protocol that supports a common set
of reliable transport functions for signaling transport.
3) a standard, unmodified IP transport protocol.
1) 特定の基関数をサポートする適合副層、例えば特定のSCNシグナリングアプリケーション・プロトコルによって必要とされた管理指摘。 2) 一般的な信頼できる輸送をサポートするCommon Signaling Transportプロトコルはシグナリング輸送のために機能します。 3) 標準の、そして、変更されていないIPトランスポート・プロトコル。
Ong, et al. Informational [Page 10] RFC 2719 Framework Architecture for Signaling Transport October 1999
オング、他 輸送1999年10月に合図するための情報[10ページ]のRFC2719フレームワークアーキテクチャ
+-- +--------------------------------+
| | SCN adaptation module |
| +--------------------------------+
| |
S | +--------------------------------+
I | | Common Signaling Transport |
G | +--------------------------------+
| |
| +--------------------------------+
| | standard IP transport |
+-- +--------------------------------+
+-- +--------------------------------+ | | SCN適合モジュール| | +--------------------------------+ | | S| +--------------------------------+ 私| | 一般的なシグナリング輸送| G| +--------------------------------+ | | | +--------------------------------+ | | 標準のIP輸送| +-- +--------------------------------+
Figure 6: Signaling Transport Components
図6: シグナリング輸送コンポーネント
3.2. SS7 access for Media Gateway Control
3.2. メディアゲートウェイControlのためのSS7アクセス
This section provides a protocol architecture for signaling transport supporting SS7 access for Media Gateway Control.
このセクションはメディアゲートウェイControlのためにSS7がアクセスであるとサポートするシグナリング輸送にプロトコルアーキテクチャを提供します。
****** SS7 ******* SS7 ****** IP *******
*SEP *--------* STP *------* SG *------------* MGC *
****** ******* ****** *******
****** SS7*******SS7******IP********9月*--------* STP*------* SG*------------* MGC***************************
+----+ +-----+
|ISUP| | ISUP|
+----+ +-----+ +---------+ +-----+
|MTP | |MTP | |MTP | SIG| | SIG |
|L1-3| |L1-3 | |L1-3+----+ +-----+
| | | | | | IP | | IP |
+----+ +-----+ +---------+ +-----+
+----+ +-----+ |ISUP| | ISUP| +----+ +-----+ +---------+ +-----+ |MTP| |MTP| |MTP| SIG| | SIG| |L1-3| |L1-3| |L1-3+----+ +-----+ | | | | | | IP| | IP| +----+ +-----+ +---------+ +-----+
STP - Signal Transfer Point SEP - Signaling End Point
SG - Signaling Gateway SIG - Signaling Transport
MGC - Media Gateway Controller
STP--信号転送ポイント9月--輸送MGCに合図して、ゲートウェイSIGに合図して、エンドポイントSGに合図します--メディアゲートウェイコントローラ
Figure 7: SS7 Access to MGC
図7: MGCへのSS7アクセス
Ong, et al. Informational [Page 11] RFC 2719 Framework Architecture for Signaling Transport October 1999
オング、他 輸送1999年10月に合図するための情報[11ページ]のRFC2719フレームワークアーキテクチャ
3.3. Q.931 Access to MGC
3.3. MGCへのQ.931アクセス
This section provides a protocol architecture for signaling transport supporting ISDN point-to-point access (Q.931) for Media Gateway Control.
このセクションはメディアゲートウェイControlのためにISDNポイントツーポイントアクセスが(Q.931)であるとサポートするシグナリング輸送にプロトコルアーキテクチャを提供します。
****** ISDN ********* IP *******
* EP *--------------* SG/MG *------------* MGC *
****** ********* *******
****** ISDN*********IP********EP*--------------* SG/mg*------------* MGC***********************
+----+ +-----+
|Q931| | Q931|
+----+ +---------+ +-----+
|Q921| |Q921| SIG| | SIG |
+ + + +----+ +-----+
| | | | IP | | IP |
+----+ +---------+ +-----+
+----+ +-----+ |Q931| | Q931| +----+ +---------+ +-----+ |Q921| |Q921| SIG| | SIG| + + + +----+ +-----+ | | | | IP| | IP| +----+ +---------+ +-----+
MG/SG - Media Gateway with SG function for backhaul
EP - ISDN End Point
MG/SG--逆送EPへのSG機能があるメディアゲートウェイ--ISDN End Point
Figure 8: ISDN Access
エイト環: ISDNアクセス
3.4. SS7 Access to IP/SCP
3.4. IP/SCPへのSS7アクセス
This section provides a protocol architecture for database access, for example providing signaling between two IN nodes or two mobile network nodes. There are a number of scenarios for the protocol stacks and the functionality contained in the SIG, depending on the SS7 application.
このセクションはプロトコルアーキテクチャをデータベースアクセスに提供します、例えば、2つのINノードか2つのモバイルネットワークノードの間にシグナリングを提供して。 プロトコル・スタックとSIGに含まれた機能性のための多くのシナリオがあります、SS7アプリケーションによって。
In the diagrams, SS7 Application Part (S7AP) is used for generality to cover all Application Parts (e.g. MAP, IS-41, INAP, etc). Depending on the protocol being transported, S7AP may or may not include TCAP. The interface to the SS7 layer below S7AP can be either the TC-user interface or the SCCP-user interface.
一般性がすべてのApplication Partsをカバーするのにダイヤグラムで、SS7 Application Part(S7AP)が使用される、(例えば、MAP、-41である、INAPなど) 輸送されるプロトコルによって、S7APはTCAPを含むかもしれません。 S7APの下のSS7層へのインタフェースは、TC-ユーザーインタフェースかSCCP-ユーザーインタフェースのどちらかであるかもしれません。
Figure 9a shows the scenario where SCCP is the signaling protocol being transported between the SG and an IP Signaling Endpoint (ISEP), that is, an IP destination supporting some SS7 application protocols.
図9aは、SCCPがどこのSGとIP Signaling Endpoint(ISEP)(すなわち、何らかのSS7アプリケーションがプロトコルであるとサポートするIPの目的地)の間で輸送されるシグナリングプロトコルであるかをシナリオに示します。
Ong, et al. Informational [Page 12] RFC 2719 Framework Architecture for Signaling Transport October 1999
オング、他 輸送1999年10月に合図するための情報[12ページ]のRFC2719フレームワークアーキテクチャ
****** SS7 ******* SS7 ****** IP *******
*SEP *--------* STP *------* SG *-------------* ISEP*
****** ******* ****** *******
****** SS7*******SS7******IP********9月*--------* STP*------* SG*-------------* ISEP***************************
+-----+ +-----+
|S7AP | |S7AP |
+-----+ +-----+
|SCCP | |SCCP |
+-----+ +-----+ +---------+ +-----+
|MTP | |MTP | |MTP |SIG | |SIG |
+ + + + + +----+ +-----+
| | | | | | IP | |IP |
+-----+ +-----+ +---------+ +-----+
+-----+ +-----+ |S7AP| |S7AP| +-----+ +-----+ |SCCP| |SCCP| +-----+ +-----+ +---------+ +-----+ |MTP| |MTP| |MTP|SIG| |SIG| + + + + + +----+ +-----+ | | | | | | IP| |IP| +-----+ +-----+ +---------+ +-----+
Figure 9a: SS7 Access to IP node - SCCP being transported
図9a: IPノードへのSS7 Access--輸送されるSCCP
Figure 9b shows the scenario where S7AP is the signaling protocol being transported between SG and ISEP. Depending on the protocol being transported, S7AP may or may not include TCAP, which implies that SIG must be able to support both the TC-user and the SCCP-user interfaces.
図9bは、S7APがどこのSGとISEPの間で輸送されるシグナリングプロトコルであるかをシナリオに示します。 輸送されるプロトコルによって、S7APはTCAPを含むかもしれません。(TCAPは、SIGが、両方がTC-ユーザとSCCP-ユーザインタフェースであるとサポートすることができなければならないのを含意します)。
****** SS7 ******* SS7 ****** IP *******
*SEP *--------* STP *------* SG *-------------* ISEP*
****** ******* ****** *******
****** SS7*******SS7******IP********9月*--------* STP*------* SG*-------------* ISEP***************************
+-----+ +-----+
|S7AP | |S7AP |
+-----+ +----+----+ +-----+
|SCCP | |SCCP| | | |
+-----+ +-----+ +----|SIG | |SIG |
|MTP | |MTP | |MTP | | | |
+ + + + + +----+ +-----+
| | | | | |IP | |IP |
+-----+ +-----+ +---------+ +-----+
+-----+ +-----+ |S7AP| |S7AP| +-----+ +----+----+ +-----+ |SCCP| |SCCP| | | | +-----+ +-----+ +----|SIG| |SIG| |MTP| |MTP| |MTP| | | | + + + + + +----+ +-----+ | | | | | |IP| |IP| +-----+ +-----+ +---------+ +-----+
Figure 9b: SS7 Access to IP node - S7AP being transported
図9b: IPノードへのSS7 Access--輸送されるS7AP
Ong, et al. Informational [Page 13] RFC 2719 Framework Architecture for Signaling Transport October 1999
オング、他 輸送1999年10月に合図するための情報[13ページ]のRFC2719フレームワークアーキテクチャ
3.5. SG to SG
3.5. SGへのSG
This section identifies a protocol architecture for support of signaling between two endpoints in an SCN signaling network, using signaling transport directly between two SGs.
このセクションはSCNシグナル伝達ネットワークにおける2つの終点の間で合図するサポートのためにプロトコルアーキテクチャを特定します、2SGsの直接間のシグナリング輸送を使用して。
The following figure describes protocol architecture for a scenario with two SGs providing different levels of function for interworking of SS7 and IP. This corresponds to the scenario given in Figure 3.
以下の図は2SGsが異なったレベルの関数をSS7とIPを織り込むのに提供しているシナリオのためにプロトコルアーキテクチャについて説明します。 これは図3で与えられたシナリオに対応しています。
The SS7 User Part (S7UP) shown is an SS7 protocol using MTP directly for transport within the SS7 network, for example, ISUP.
(S7UP)がSS7であることを示すSS7 User Partは、直接輸送に例えば、SS7ネットワーク、ISUPの中でMTPを使用することで議定書を作ります。
In this scenario, there are two different usage cases of SIG, one which transports MTP3 signaling, the other which transports ISUP signaling.
このシナリオには、SIGの2つの異なった用法ケースがあります、MTP3シグナリングを輸送するもの、ISUPシグナリングを輸送するもう片方。
****** SS7 ****** IP ****** IP ******
*SEP *-------* SG1*----------* SG2*-------*MGC *
****** ****** ****** ******
****** SS7******IP******IP*******9月*-------* SG1*----------* SG2*-------*MGC*************************
+----+ +----+
|S7UP| |S7UP|
+----+ +----+----+ +----+
|MTP3| |MTP3| | | |
+----+ +---------+ +----+ SIG| |SIG |
|MTP2| |MTP2|SIG | |SIG | | | |
+ + + +----+ +----+----+ +----+
| | | | IP | | IP | | IP |
+----+ +----+----+ +----+----+ +----+
+----+ +----+ |S7UP| |S7UP| +----+ +----+----+ +----+ |MTP3| |MTP3| | | | +----+ +---------+ +----+ SIG| |SIG| |MTP2| |MTP2|SIG| |SIG| | | | + + + +----+ +----+----+ +----+ | | | | IP| | IP| | IP| +----+ +----+----+ +----+----+ +----+
S7UP - SS7 User Part
S7UP--SS7ユーザ部分
Figure 10: SG to SG Case 1
図10: SGケース1へのSG
The following figure describes a more generic use of SS7-IP interworking for transport of SS7 upper layer signaling across an IP network, where the endpoints are both SS7 SEPs.
以下の図が説明する、 より多くのジェネリック使用、SS7の輸送のために終点が両方であるIPネットワークの向こう側に上側の層のシグナリングを織り込むSS7-IP SS7 9月について。
Ong, et al. Informational [Page 14] RFC 2719 Framework Architecture for Signaling Transport October 1999
オング、他 輸送1999年10月に合図するための情報[14ページ]のRFC2719フレームワークアーキテクチャ
****** SS7 ****** IP ****** SS7 ******
*SEP *--------* SG *-----------* SG *--------*SEP *
****** ****** ****** ******
****** SS7******IP******SS7*******9月*--------* SG*-----------* SG*--------*9月*************************
+----+ +-----+
|S7UP| | S7UP|
+----+ +-----+
|MTP3| | MTP3|
+----+ +---------+ +---------+ +-----+
|MTP2| |MTP2| SIG| |SIG |MTP2| | MTP2|
+ + + +----+ +----+ + + +
| | | | IP | | IP | | | |
+----+ +----+----+ +----+----+ +-----+
+----+ +-----+ |S7UP| | S7UP| +----+ +-----+ |MTP3| | MTP3| +----+ +---------+ +---------+ +-----+ |MTP2| |MTP2| SIG| |SIG|MTP2| | MTP2| + + + +----+ +----+ + + + | | | | IP| | IP| | | | +----+ +----+----+ +----+----+ +-----+
Figure 11: SG to SG Case 2
図11: SGケース2へのSG
4. Functional Requirements
4. 機能条件書
4.1 Transport of SCN Signaling Protocols
4.1 SCNシグナリングプロトコルの輸送
Signaling transport provides for the transport of native SCN protocol messages over a packet switched network.
シグナリング輸送はパケット交換網の上に固有のSCNプロトコルメッセージの輸送に備えます。
Signaling transport shall:
シグナリング輸送はそうするでしょう:
1) Transport of a variety of SCN protocol types, such as the application and user parts of SS7 (including MTP Level 3, ISUP, SCCP, TCAP, MAP, INAP, IS-41, etc.) and layer 3 of the DSS1/PSS1 protocols (i.e. Q.931 and QSIG).
1) SS7のアプリケーションやユーザ部分などのさまざまなSCNプロトコルタイプの輸送、(MTP Level3、ISUP、SCCP、TCAP、MAP、INAPを含んでいる、-41である、など) そして、DSS1/PSS1プロトコル(すなわち、Q.931とQSIG)の層3。
2) Provide a means to identify the particular SCN protocol being transported.
2) 輸送される特定のSCNプロトコルを特定する手段を提供してください。
3) Provide a common base protocol defining header formats, security extensions and procedures for signaling transport, and support extensions as necessary to add individual SCN protocols if and when required.
3) 必要であるなら個々のSCNプロトコルを加えるように輸送、および必要に応じてサポート拡大に合図するためのヘッダー形式、セキュリティ拡大、および手順を定義する一般的なベースプロトコルを提供してください。
4) In conjunction with the underlying network protocol (IP), provide the relevant functionality as defined by the appropriate SCN lower layer.
4) 基本的なネットワーク・プロトコル(IP)に関連して、適切なSCN低級層のそばで定義されるように関連機能性を提供してください。
Relevant functionality may include (according to the protocol being transported):
関連機能性は以下を含むかもしれません(輸送されるプロトコルによると)。
- flow control - in sequence delivery of signaling messages within a control stream
- フロー制御--連続して制御ストリームの中のシグナリングメッセージの配送
Ong, et al. Informational [Page 15] RFC 2719 Framework Architecture for Signaling Transport October 1999
オング、他 輸送1999年10月に合図するための情報[15ページ]のRFC2719フレームワークアーキテクチャ
- logical identification of the entities on which the signaling
messages originate or terminate
- logical identification of the physical interface controlled by the
signaling message
- error detection
- recovery from failure of components in the transit path
- retransmission and other error correcting methods
- detection of unavailability of peer entities.
- シグナリングメッセージが起因するか、または終わる実体の論理的な識別--物理インターフェースの論理的な識別はシグナリングメッセージ--誤り検出--トランジット経路のコンポーネントの失敗からの回復--「再-トランスミッション」と他のエラー修正メソッド--同輩実体の使用不能の検出で制御されました。
For example:
例えば:
- if the native SCN protocol is ISUP or SCCP, the relevant
functionality provided by MTP2/3 shall be provided.
- if the native SCN protocol is TCAP, the relevant functionality
provided by SCCP connectionless classes and MTP 2/3 shall be
supported.
- if the native SCN protocol is Q.931, the relevant functionality
provided by Q.921 shall be supported.
- if the native SCN protocol is MTP3, the relevant functionality of
MTP2 shall be supported.
- 固有のSCNプロトコルがISUPかSCCPであるなら、MTP2/3によって提供された関連機能性を提供するものとします。 - 固有のSCNプロトコルがTCAPであるなら、SCCPのコネクションレスなクラスとMTP2/3によって提供された関連機能性はサポートされるものとします。 - 固有のSCNプロトコルがQ.931であるなら、Q.921によって提供された関連機能性はサポートされるものとします。 - 固有のSCNプロトコルがMTP3であるなら、MTP2の関連機能性はサポートされるものとします。
5) Support the ability to multiplex several higher layer SCN sessions on one underlying signaling transport session. This allows, for example, several DSS1 D-Channel sessions to be carried in one signaling transport session.
5) 多重送信する1つの基本的なシグナリング輸送セッションに関するいくつかの、より高い層のSCNセッションの能力をサポートしてください。 これは、例えば、いくつかのDSS1D-チャンネルセッションが1つのシグナリング輸送セッションのときに運ばれるのを許容します。
In general, in-sequence delivery is required for signaling messages within a single control stream, but is not necessarily required for messages that belong to different control streams. The protocol should if possible take advantage of this property to avoid blocking delivery of messages in one control stream due to sequence error within another control stream. The protocol should also allow the SG to send different control streams to different destination ports if desired.
一般に、連続して配送は、単一管理ストリームの中でメッセージに合図するのに必要ですが、異なった制御ストリームに属すメッセージに必ず必要であるというわけではありません。できれば、プロトコルは、別の制御ストリームの中で系列誤りによる1つの制御ストリームにおける、メッセージの配送を妨げるのを避けるのにこの特性を利用するべきです。 また、望まれているなら、SGはプロトコルで異なった制御ストリームを異なった仕向港に送るはずであることができます。
6) Be able to transport complete messages of greater length than the underlying SCN segmentation/reassembly limitations. For example, signaling transport should not be constrained by the length limitations defined for SS7 lower layer protocol (e.g. 272 bytes in the case of narrowband SS7) but should be capable of carrying longer messages without requiring segmentation.
6) 基本的なSCN分割/再アセンブリ制限より大きい長さの完全なメッセージを輸送できてください。 例えば、分割を必要としないで、シグナリング輸送は、SS7下位層プロトコル(例えば、狭帯域SS7の場合における272バイト)のために定義された長さの制限で抑制するべきではありませんが、より長いメッセージを伝えることができるべきです。
7) Allow for a range of suitably robust security schemes to protect signaling information being carried across networks. For example, signaling transport shall be able to operate over proxyable sessions, and be able to be transported through firewalls.
7) ネットワークの向こう側に運ばれる情報に合図して、さまざまな適当に強健なセキュリティ体系が保護されるのを許容してください。 例えば、シグナリング輸送は、「プロキシ-可能」セッションの間、作動できて、ファイアウォールを通して輸送できるでしょう。
Ong, et al. Informational [Page 16] RFC 2719 Framework Architecture for Signaling Transport October 1999
オング、他 輸送1999年10月に合図するための情報[16ページ]のRFC2719フレームワークアーキテクチャ
8) Provide for congestion avoidance on the Internet, by supporting appropriate controls on signaling traffic generation (including signaling generated in SCN) and reaction to network congestion.
8) インターネットに輻輳回避に備えてください、トラフィック世代(シグナリングがSCNで生成した包含)と反応に合図するときの適切なコントロールをネットワークの混雑にサポートすることによって。
4.2 Performance of SCN Signaling Protocols
4.2 SCNシグナリングプロトコルのパフォーマンス
This section provides basic values regarding performance requirements of key SCN protocols to be transported. Currently only message-based SCN protocols are considered. Failure to meet these requirements is likely to result in adverse and undesirable signaling and call behavior.
このセクションは主要なSCNプロトコルが輸送されるという性能要件に関して基礎価格を提供します。 現在、メッセージベースだけのSCNプロトコルは考えられます。 これらの必要条件を満たさないことは、不利で望ましくないシグナリングをもたらして、振舞いと呼びそうです。
4.2.1 SS7 MTP requirements
4.2.1 SS7 MTP要件
The performance requirements below have been specified for transport of MTP Level 3 network management messages. The requirements given here are only applicable if all MTP Level 3 messages are to be transported over the IP network.
以下の性能要件はMTP Level3ネットワークマネージメントメッセージの輸送に指定されました。 ここに与えられた要件はすべてのMTP Level3メッセージが単にIPネットワークの上で輸送されることであるなら適切です。
- Message Delay
- MTP Level 3 peer-to-peer procedures require response within 500
to 1200 ms. This value includes round trip time and processing
at the remote end.
Failure to meet this limitation will result in the initiation
of error procedures for specific timers, e.g., timer T4 of
ITU-T Recommendation Q.704.
- メッセージDelay--MTP Level3ピアツーピア手順は原稿This価値が旅行時間と処理の周りにリモートエンドで含む500〜1200の中で応答を必要とします。 この制限を満たさないと、特定のタイマ(ITU-T Recommendation Q.704の例えば、タイマT4)のための誤り処理手続きの開始をもたらすでしょう。
4.2.2 SS7 MTP Level 3 requirements
4.2.2 SS7 MTP Level3要件
The performance requirements below have been specified for transport of MTP Level 3 user part messages as part of ITU-T SS7 Recommendations [SS7].
以下の性能要件はITU-T SS7 Recommendations[SS7]の一部としてMTP Level3ユーザ部分メッセージの輸送に指定されました。
- Message Loss
- no more than 1 in 10E+7 messages will be lost due to transport
failure
- メッセージLoss--10E+7のメッセージの1未満は輸送失敗のため失われるでしょう。
- Sequence Error
- no more than 1 in 10E+10 messages will be delivered out-of-
sequence (including duplicated messages) due to transport
failure
- 系列Error--10E+10のメッセージの1未満は-外に提供されて、系列では、(コピーされたメッセージを含んでいます)が失敗を輸送するということでしょう。
- Message Errors
- no more than 1 in 10E+10 messages will contain an error that is
undetected by the transport protocol (requirement is 10E+9 for
ANSI specifications)
- メッセージErrors--10E+10のメッセージの1未満はトランスポート・プロトコルによって非検出される誤りを含むでしょう。(要件はANSI仕様のための10E+9です)
Ong, et al. Informational [Page 17] RFC 2719 Framework Architecture for Signaling Transport October 1999
オング、他 輸送1999年10月に合図するための情報[17ページ]のRFC2719フレームワークアーキテクチャ
- Availability
- availability of any signaling route set is 99.9998% or better,
i.e., downtime 10 min/year or less. A signaling route set is
the complete set of allowed signaling paths from a given
signaling point towards a specific destination.
- 有用性--どんなシグナリングルートセットの有用性も、99.9998%か、より良く、すなわち、休止時間は10分/年以下です。 シグナリングルートセットは特定の目的地に向かった与えられたシグナリングポイントからの完全なセットの許容シグナリング経路です。
- Message length (payload accepted from SS7 user parts)
- 272 bytes for narrowband SS7, 4091 bytes for broadband SS7
- メッセージ長(SS7ユーザの部品から受け入れられたペイロード)--狭帯域SS7への272バイト、ブロードバンドSS7のための4091バイト
4.2.3 SS7 User Part Requirements
4.2.3 SS7ユーザ部分要件
More detailed analysis of SS7 User Part Requirements can be found in [Lin].
[リン]でSS7 User Part Requirementsの、より詳細な分析を見つけることができます。
ISUP Message Delay - Protocol Timer Requirements
ISUPメッセージ遅延--プロトコルタイマ要件
- one example of ISUP timer requirements is the Continuity Test
procedure, which requires that a tone generated at the sending
end be returned from the receiving end within 2 seconds of
sending an IAM indicating continuity test. This implies that
one way signaling message transport, plus accompanying nodal
functions need to be accomplished within 2 seconds.
- ISUPタイマ要件に関する1つの例がContinuity Test手順です。(その手順は、送信側に生成されたトーンがIAMに連続テストを示させた後2秒以内に犠牲者から返されるのを必要とします)。 これはその一方通行のシグナリングメッセージ転送を含意します、そして、付随のこぶのような機能は2秒以内に達成される必要があります。
ISUP Message Delay - End-to-End Requirements
ISUPメッセージ遅延--終わりから終わりへの要件
- the requirement for end-to-end call setup delay in ISUP is that
an end-to-end response message be received within 20-30 seconds
of the sending of the IAM. Note: while this is the protocol
guard timer value, users will generally expect faster response
time.
- 終わりから終わりへのISUPの呼び出しセットアップ遅れのための要件はIAMの発信だったのの後20-30秒以内に終わりから終わりへの応答メッセージを受け取るということです。 以下に注意してください。 これはプロトコル警備タイマ価値ですが、一般に、ユーザは、より速い応答時間を予想するでしょう。
TCAP Requirements - Delay Requirements
TCAP要件--遅れ要件
- TCAP does not itself define a set of delay requirements. Some
work has been done [Lin2] to identify application-based delay
requirements for TCAP applications.
- TCAPはそれ自体をするというわけではありません。1セットの遅れ要件を定義してください。 TCAPアプリケーションのためのアプリケーションベースの遅れ要件を特定するためにいくらかの仕事をしました[Lin2]。
4.2.4 ISDN Signaling Requirements
4.2.4 ISDNシグナリング要件
Q.931 Message Delay
Q.931メッセージ遅延
- round-trip delay should not exceed 4 seconds. A Timer of this
length is used for a number of procedures, esp. RELASE/RELEASE
COMPLETE and CONNECT/CONNECT ACK where excessive delay may
result in management action on the channel, or release of a
call being set up. Note: while this value is indicated by
protocol timer specifications, faster response time is normally
expected by the user.
- 往復の遅れは4秒を超えるべきではありません。 この長さのTimerは多くの手順に特に使用されます。 過度の遅れがチャンネルへの管理活動、またはセットアップされる呼び出しのリリースをもたらすかもしれないRELASE/RELEASE COMPLETEとCONNECT/CONNECT ACK。 以下に注意してください。 この値はプロトコルタイマ仕様で示されますが、通常、より速い応答時間はユーザによって予想されます。
Ong, et al. Informational [Page 18] RFC 2719 Framework Architecture for Signaling Transport October 1999
オング、他 輸送1999年10月に合図するための情報[18ページ]のRFC2719フレームワークアーキテクチャ
- 12 sec. timer (T309) is used to maintain an active call in
case of loss of the data link, pending re-establishment. The
related ETSI documents specify a maximum value of 4 seconds
while ANSI specifications [T1.607] default to 90 seconds.
- 12秒のタイマ(T309)はデータ・リンクの損失の場合に活発な呼び出しを維持するのに使用されます、再建まで。 ANSI仕様[T1.607]が90秒をデフォルトとしている間、関連するETSIドキュメントは4秒の最大値を指定します。
5. Management
5. 管理
Operations, Administration & Management (OA&M) of IP networks or SCN networks is outside the scope of SIGTRAN. Examples of OA&M include legacy telephony management systems or IETF SNMP managers. OA&M implementors and users should be aware of the functional interactions of the SG, MGC and MG and the physical units they occupy.
SIGTRANの範囲の外にIPネットワークかSCNネットワークの操作、政権、およびManagement(OA&M)があります。 OA&Mの例はレガシー電話マネージメントシステムかIETF SNMPマネージャを含んでいます。 OAとM作成者とユーザはそれらが占領するSG、MGC、MG、および物理装置の機能的相補作用を意識しているべきです。
6. Security Considerations
6. セキュリティ問題
6.1 Security Requirements
6.1 セキュリティ要件
When SCN related signaling is transported over an IP network two possible network scenarios can be distinguished:
SCNの関連するシグナリングがIPネットワークの上で輸送されるとき、2つの可能なネットワークシナリオを区別できます:
- Signaling transported only within an Intranet;
Security measures are applied at the discretion of the network
owner.
- シグナリングはイントラネットを中だけに輸送しました。 安全策はネットワーク所有者の裁量で適用されます。
- Signaling transported, at least to some extent, in the public
Internet;
The public Internet should be regarded generally as an "insecure"
network and usage of security measures is required.
- 公共のインターネットで少なくともある程度輸送されたシグナリング。 一般に、安全策の「不安定な」ネットワークと用法が必要であるように公共のインターネットは見なされるべきです。
Generally security comprises several aspects
一般にセキュリティはいくつかの局面を包括します。
- Authentication:
It is required to ensure that the information is sent to/from a
known and trusted partner.
- 認証: それが、情報が知られていて信じられたパートナーからの/に送られるのを保証するのに必要です。
- Integrity:
It is required to ensure that the information hasn't been modified
while in transit.
- 保全: トランジットにはある間、それが、情報が変更されていないのを保証するのに必要です。
- Confidentiality:
It might be sometimes required to ensure that the transported
information is encrypted to avoid illegal use.
- 秘密性: それが、輸送された情報が違法使用を避けるために暗号化されるのを保証するのに時々必要であるかもしれません。
- Availability:
It is required that the communicating endpoints remain in service
for authorized use even if under attack.
- 有用性: 攻撃で交信終点が認可された使用に使用中のままで残るのが必要です。
Ong, et al. Informational [Page 19] RFC 2719 Framework Architecture for Signaling Transport October 1999
オング、他 輸送1999年10月に合図するための情報[19ページ]のRFC2719フレームワークアーキテクチャ
6.2 Security Mechanisms Currently Available in IP Networks
6.2 現在IPネットワークで利用可能なセキュリティメカニズム
Several security mechanisms are currently available for use in IP networks.
数個のセキュリティー対策が現在、IPネットワークにおける使用に利用可能です。
- IPSEC ([RFC2401]):
IPSEC provides security services at the IP layer that address the
above mentioned requirements. It defines the two protocols AH and
ESP respectively that essentially provide data integrity and data
confidentiality services.
- IPSEC([RFC2401]): IPSECはIP層の上記の要件を扱うセキュリティー・サービスを提供します。 それは2プロトコルAH、それぞれそれが本質的にはデータ保全を提供する超能力、およびデータの機密性サービスを定義します。
The ESP mechanism can be used in two different modes:
- Transport mode;
- Tunnel mode.
2つの異なったモードで超能力メカニズムを使用できます: - モードを輸送してください。 - モードにトンネルを堀ってください。
In Transport mode IPSEC protects the higher layer protocol data portion of an IP packet, while in Tunnel mode a complete IP packet is encapsulated in a secure IP tunnel.
Transportモードで、IPSECはIPパケットの、より高い層のプロトコルデータ部を保護します、完全なIPパケットが安全なIPトンネルでTunnelモードでカプセルに入れられますが。
If the SIG embeds any IP addresses outside of the SA/DA in the IP header, passage through a NAT function will cause problems. The same is true for using IPsec in general, unless an IPsec ready RSIP function is used as described in RFC 2663 [NAT].
SIGがIPヘッダーで何かIPアドレスをSA/DAの外に埋め込むと、NAT機能を通した通路は問題を起こすでしょう。一般に、IPsecを使用するのに、同じくらいは本当です、IPsecの持ち合わせのRSIP機能がRFC2663[NAT]で説明されるように使用されていない場合。
The use of IPSEC does not hamper the use of TCP or UDP as the underlying basis of SIG. If automated distribution of keys is required the IKE protocol ([RFC2409]) can be applied.
IPSECの使用はSIGの基本的な基礎としてTCPかUDPの使用を妨げません。 キーの自動化された分配が必要であるなら、IKEプロトコル([RFC2409])を適用できます。
- SSL, TLS ([RFC2246]):
SSL and TLS also provide appropriate security services but operate
on top of TCP/IP only.
- SSL、TLS([RFC2246]): SSLとTLSはまた、適切なセキュリティー・サービスを提供しますが、TCP/IPだけの上で作動します。
It is not required to define new security mechanisms in SIG, as the use of currently available mechanisms is sufficient to provide the necessary security. It is recommended that IPSEC or some equivalent method be used, especially when transporting SCN signaling over public Internet.
それはSIGで新しいセキュリティー対策を定義するのに必要ではありません、現在利用可能なメカニズムの使用が必要なセキュリティを提供するために十分であるときに。 特に公共のインターネットの上でSCNシグナリングを輸送するとき、IPSECか何らかの同等なメソッドが使用されるのは、お勧めです。
Ong, et al. Informational [Page 20] RFC 2719 Framework Architecture for Signaling Transport October 1999
オング、他 輸送1999年10月に合図するための情報[20ページ]のRFC2719フレームワークアーキテクチャ
7. Abbreviations
7. 略語
CAS Channel-Associated Signaling DSS1 Digital Subscriber Signaling INAP Intelligent Network Application Part ISEP IP Signaling End Point ISUP Signaling System 7 ISDN User Part MAP Mobile Application Part MG Media Gateway MGU Media Gateway Unit MGC Media Gateway Controller MGCU Media Gateway Controller Unit MTP Signaling System 7 Message Transfer Part PLMN Public Land Mobile Network PSTN Public Switched Telephone Network S7AP SS7 Application Part S7UP SS7 User Part SCCP SS7 Signaling Connection Control Part SCN Switched Circuit Network SEP Signaling End Point SG Signaling Gateway SIG Signaling Transport protocol stack SS7 Signaling System No. 7 TCAP Signaling System 7 Transaction Capabilities Part
チャンネルで関連しているCASのメディアゲートウェイコントローラユニットMTPシグナリングDSS1デジタル加入者のISEP IPシグナリングエンドポイントシグナリングINAPインテリジェントネットワークアプリケーションパートISUPモバイル7シグナリングシステムISDNユーザ部分地図アプリケーション部分mgメディアゲートウェイMGUメディアゲートウェイユニットMGCメディアゲートウェイコントローラMGCUシグナリング; モバイルシステム7のゲートウェイSIG Signaling Transportプロトコル・スタックSS7 Signaling System Message Transfer Part PLMN Public Land Network PSTN Public Switched Telephone Network S7AP SS7 Application Part S7UP SS7 User Part SCCP SS7Signaling Connection Control Part SCN Switched Circuit Network9月のSignaling End Point SG Signaling No; 7 TCAPシグナリングシステム7トランザクション能力一部
8. Acknowledgements
8. 承認
The authors would like to thank K. Chong, I. Elliott, Ian Spiers, Al Varney, Goutam Shaw, C. Huitema, Mike McGrew and Greg Sidebottom for their valuable comments and suggestions.
作者は彼らの貴重なコメントと提案についてK.チョン、I.エリオット、イアン・スピアーズ、アル・ヴァーニー、Goutamショー、C.Huitema、マイク・マグリュー、およびグレッグSidebottomに感謝したがっています。
9. References
9. 参照
[NAT] Srisuresh P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", RFC
2663, August 1999.
[NAT]Srisuresh P.、M.Holdrege、および「IPネットワークアドレス変換機構(NAT)用語と問題」、RFC2663、1999年8月。
[PSS1/QSIG] ISO/IEC 11572 Ed. 2 (1997-06), "Information technology
- Telecommunications and information exchange between
systems - Private Integrated Services Network - Circuit
mode bearer services - Inter-exchange signalling
procedures and protocol"
[PSS1/QSIG]ISO/IEC、11572、エド. 2(1997-06)、「情報技術--システムの間のテレコミュニケーションと情報交換--個人的なIntegrated Services Network(回路モード運搬人サービス)は相互合図手順を交換して、議定書を作ります」。
[Q.931/DSS1] ITU-T Recommendation Q.931, ISDN user-network interface
layer 3 specification (5/98)
[Q.931/DSS1]ITU-T Recommendation Q.931、ISDNユーザネットワーク・インターフェース層3の仕様(5/98)
[SS7] ITU-T Recommendations Q.700-775, Signalling System No. 7
[SS7] ITU-T推薦Q.700-775、合図システムNo.7
Ong, et al. Informational [Page 21] RFC 2719 Framework Architecture for Signaling Transport October 1999
オング、他 輸送1999年10月に合図するための情報[21ページ]のRFC2719フレームワークアーキテクチャ
[SS7 MTP] ITU-T Recommendations Q.701-6, Message Transfer Part of
SS7
[SS7 MTP]ITU-T推薦Q.701-6、SS7のメッセージ転送部分
[T1.607] ANSI T1.607-1998, Digital Subscriber Signaling System
Number 1 (DSS1) - Layer 3 Signaling Specification for
Circuit-Switched Bearer Services
[T1.607]ANSI T1.607-1998、デジタル加入者シグナリングシステムNo.1(DSS1)--回路で切り換えられた運搬人サービスのための層3のシグナリング仕様
[Lin] Lin, H., Seth, T., et al., "Performance Requirements for
Signaling in Internet Telephony", Work in Progress.
[リン] リン、H.、セス、T.、他、「インターネット電話で合図するためのパフォーマンス要件」、ProgressのWork。
[Lin2] Lin, H., et al., "Performance Requirements for TCAP
Signaling in Internet Telephony", Work in Progress.
[Lin2] リン、H.、他、「TCAPのためのインターネット電話で合図するパフォーマンス要件」、ProgressのWork。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[RFC2246] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。
[RFC2409] Harkins, D. and C. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC2409]ハーキンとD.とC.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2401] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
Authors' Addresses
作者のアドレス
Lyndon Ong Nortel Networks 4401 Great America Parkway Santa Clara, CA 95054, USA
サンタクララ、カリフォルニア 95054、リンドンオングノーテルネットワーク4401Great Americaパークウェイ米国
EMail: long@nortelnetworks.com
メール: long@nortelnetworks.com
Ian Rytina Ericsson Australia 37/360 Elizabeth Street Melbourne, Victoria 3000, Australia
ビクトリア3000、イアン・Rytinaエリクソンオーストラリア37/360エリザベス・通りメルボルン(オーストラリア)
EMail: ian.rytina@ericsson.com
メール: ian.rytina@ericsson.com
Matt Holdrege Lucent Technologies 1701 Harbor Bay Parkway Alameda, CA 94502 USA
マットHoldregeルーセントテクノロジーズ1701港湾のParkwayカリフォルニア94502アラメダ(米国)
EMail: holdrege@lucent.com
メール: holdrege@lucent.com
Ong, et al. Informational [Page 22] RFC 2719 Framework Architecture for Signaling Transport October 1999
オング、他 輸送1999年10月に合図するための情報[22ページ]のRFC2719フレームワークアーキテクチャ
Lode Coene Siemens Atea Atealaan 34 Herentals, Belgium
鉱脈CoeneシーメンスAtea Atealaan34ヘーレンタルス(ベルギー)
EMail: lode.coene@siemens.atea.be
メール: lode.coene@siemens.atea.be
Miguel-Angel Garcia Ericsson Espana Retama 7 28005 Madrid, Spain
ミゲル-天使ガルシア・エリクソンエスパニアRetama7 28005マドリード(スペイン)
EMail: Miguel.A.Garcia@ericsson.com
メール: Miguel.A.Garcia@ericsson.com
Chip Sharp Cisco Systems 7025 Kit Creek Road Res Triangle Pk, NC 27709, USA
急シスコシステムズ7025キットクリーク道路Res三角形Pk、NC 27709、米国を欠いてください。
EMail: chsharp@cisco.com
メール: chsharp@cisco.com
Imre Juhasz Telia Sweden
イムレ・Juhasz Teliaスウェーデン
EMail: imre.i.juhasz@telia.se
メール: imre.i.juhasz@telia.se
Haui-an Paul Lin Telcordia Technologies Piscataway, NJ, USA
Haui、-1、ポール・リンTelcordia Technologiesピスキャタウェイ(ニュージャージー)(米国)
EMail: hlin@research.telcordia.com
メール: hlin@research.telcordia.com
HannsJuergen Schwarzbauer SIEMENS AG Hofmannstr. 51 81359 Munich, Germany
HannsJuergen Schwarzbauerジーメンス株式会社Hofmannstr。 51 81359ミュンヘン(ドイツ)
EMail: HannsJuergen.Schwarzbauer@icn.siemens.de
メール: HannsJuergen.Schwarzbauer@icn.siemens.de
Ong, et al. Informational [Page 23] RFC 2719 Framework Architecture for Signaling Transport October 1999
オング、他 輸送1999年10月に合図するための情報[23ページ]のRFC2719フレームワークアーキテクチャ
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Ong, et al. Informational [Page 24]
オング、他 情報[24ページ]
一覧
スポンサーリンク
