RFC3726 日本語訳
3726 Requirements for Signaling Protocols. M. Brunner, Ed.. April 2004. (Format: TXT=98020 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Brunner, Ed. Request for Comments: 3726 NEC Category: Informational April 2004
ワーキンググループのM.ブルンナー、エドをネットワークでつないでください。コメントのために以下を要求してください。 3726年のNECカテゴリ: 情報の2004年4月
Requirements for Signaling Protocols
シグナリングプロトコルのための要件
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 (2004). All Rights Reserved.
Copyright(C)インターネット協会(2004)。 All rights reserved。
Abstract
要約
This document defines requirements for signaling across different network environments, such as across administrative and/or technology domains. Signaling is mainly considered for Quality of Service (Qos) such as the Resource Reservation Protocol (RSVP). However, in recent years, several other applications of signaling have been defined. For example, signaling for label distribution in Multiprotocol Label Switching (MPLS) or signaling to middleboxes. To achieve wide applicability of the requirements, the starting point is a diverse set of scenarios/use cases concerning various types of networks and application interactions. This document presents the assumptions before listing the requirements. The requirements are grouped according to areas such as architecture and design goals, signaling flows, layering, performance, flexibility, security, and mobility.
このドキュメントは異なったネットワーク環境、管理である、そして/または、技術ドメインなどのシグナリングのための要件を定義します。 シグナリングはResource予約プロトコル(RSVP)などのService(Qos)のQualityのために主に考えられます。 しかしながら、シグナリングの他の近年いくつかのアプリケーションが定義されました。 例えば、Multiprotocol Label Switching(MPLS)でのラベル分配のために合図するか、またはmiddleboxesに合図すること。 要件の広い適用性を達成するために、出発点はさまざまのセットのシナリオ/が様々なタイプのネットワークとアプリケーション間連携に関してケースを使用するということです。 要件をリストアップする前に、このドキュメントは仮定を提示します。 構造やデザイン目標などの領域に従って、要件は分類されます、流れ、レイヤリング、性能、柔軟性、セキュリティ、および移動性に合図して。
Brunner Informational [Page 1] RFC 3726 Requirements for Signaling Protocols April 2004
プロトコル2004年4月に合図するためのブルンナー情報[1ページ]のRFC3726Requirements
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Keywords . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Problem Statement and Scope. . . . . . . . . . . . . . . . . . 6
4. Assumptions and Exclusions . . . . . . . . . . . . . . . . . . 8
4.1. Assumptions and Non-Assumptions. . . . . . . . . . . . . 8
4.2. Exclusions . . . . . . . . . . . . . . . . . . . . . . . 9
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Architecture and Design Goals. . . . . . . . . . . . . . 11
5.1.1. NSIS SHOULD Provide Availability Information
on Request . . . . . . . . . . . . . . . . . . . 11
5.1.2. NSIS MUST be Designed Modularly. . . . . . . . . 11
5.1.3. NSIS MUST Decouple Protocol and Information. . . 12
5.1.4. NSIS MUST Support Independence of Signaling and
Network Control Paradigm . . . . . . . . . . . . 12
5.1.5. NSIS SHOULD be Able to Carry Opaque Objects. . . 12
5.2. Signaling Flows. . . . . . . . . . . . . . . . . . . . . 12
5.2.1. The Placement of NSIS Initiator, Forwarder, and
Responder Anywhere in the Network MUST be
Allowed. . . . . . . . . . . . . . . . . . . . . 12
5.2.2. NSIS MUST Support Path-Coupled and MAY Support
Path-Decoupled Signaling . . . . . . . . . . . . 13
5.2.3. Concealment of Topology and Technology
Information SHOULD be Possible . . . . . . . . . 13
5.2.4. Transparent Signaling Through Networks SHOULD be
Possible . . . . . . . . . . . . . . . . . . . . 13
5.3. Messaging. . . . . . . . . . . . . . . . . . . . . . . . 13
5.3.1. Explicit Erasure of State MUST be Possible . . . 13
5.3.2. Automatic Release of State After Failure MUST be
Possible . . . . . . . . . . . . . . . . . . . . 14
5.3.3. NSIS SHOULD Allow for Sending Notifications
Upstream . . . . . . . . . . . . . . . . . . . . 14
5.3.4. Establishment and Refusal to set up State MUST
be Notified. . . . . . . . . . . . . . . . . . . 15
5.3.5. NSIS MUST Allow for Local Information Exchange . 15
5.4. Control Information. . . . . . . . . . . . . . . . . . . 16
5.4.1. Mutability Information on Parameters SHOULD be
Possible . . . . . . . . . . . . . . . . . . . . 16
5.4.2. It SHOULD be Possible to Add and Remove Local
Domain Information . . . . . . . . . . . . . . . 16
5.4.3. State MUST be Addressed Independent of Flow
Identification . . . . . . . . . . . . . . . . . 16
5.4.4. Modification of Already Established State SHOULD
be Seamless. . . . . . . . . . . . . . . . . . . 16
5.4.5. Grouping of Signaling for Several Micro-Flows
MAY be Provided. . . . . . . . . . . . . . . . . 17
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1。 キーワード. . . . . . . . . . . . . . . . . . . . . . . . 5 2。 用語。 . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. 問題声明と範囲。 . . . . . . . . . . . . . . . . . 6 4. 仮定と除外. . . . . . . . . . . . . . . . . . 8 4.1。 仮定と非仮定。 . . . . . . . . . . . . 8 4.2. 除外. . . . . . . . . . . . . . . . . . . . . . . 9 5。 要件. . . . . . . . . . . . . . . . . . . . . . . . . 10 5.1。 構造とデザイン目標。 . . . . . . . . . . . . . 11 5.1.1. NSISは要求. . . . . . . . . . . . . . . . . . . 11 5.1.2に関する有用性情報を提供するはずです。 NSIS MUST、Designed Modularlyになってください。 . . . . . . . . 11 5.1.3. NSISはプロトコルと情報の衝撃を吸収しなければなりません。 . . 12 5.1.4. NSISはシグナリングからの独立とネットワーク制御パラダイム. . . . . . . . . . . . 12 5.1.5を支持しなければなりません。 NSIS SHOULD、Carry Opaque ObjectsへのAbleになってください。 . . 12 5.2. シグナリングは流れます。 . . . . . . . . . . . . . . . . . . . . 12 5.2.1. NetworkのNSIS Initiator、Forwarder、およびResponder AnywhereのPlacementはAllowedであるに違いありません。 . . . . . . . . . . . . . . . . . . . . 12 5.2.2. NSISは経路で結合されるのと5月のサポートの経路で衝撃を吸収されたシグナリング. . . . . . . . . . . . 13 5.2.3を支持しなければなりません。 隠すこと、.4にTopologyとTechnology情報SHOULDでは、Possible. . . . . . . . . 13 5.2になってください。 透明なSignaling Through Networks SHOULD、Possible. . . . . . . . . . . . . . . . . . . . 13 5.3になってください。 メッセージング。 . . . . . . . . . . . . . . . . . . . . . . . 13 5.3.1. 州の明白なErasureはPossible. . . 13 5.3.2であるに違いありません。 州After Failureの自動ReleaseはPossible. . . . . . . . . . . . . . . . . . . . 14 5.3.3であるに違いありません。 NSISは、通知上流の. . . . . . . . . . . . . . . . . . . . 14 5.3.4を送ると考慮するはずです。 州を設立する設立とRefusalはNotifiedであるに違いありません。 . . . . . . . . . . . . . . . . . . 15 5.3.5. NSISは地方の情報交換. 15 5.4を考慮しなければなりません。 情報を制御してください。 . . . . . . . . . . . . . . . . . . 16 5.4.1. 無常情報、.2にParameters SHOULDの上では、Possible. . . . . . . . . . . . . . . . . . . . 16 5.4になってください。 それ、SHOULD、.3にAddへのPossibleとRemove Local Domain情報. . . . . . . . . . . . . . . 16 5.4になってください。 状態はFlow Identification. . . . . . . . . . . . . . . . . 16 5.4.4のAddressed無党派であるに違いありません。 変更、Already Established州SHOULDにおいて、Seamlessはそうです。 . . . . . . . . . . . . . . . . . . 16 5.4.5. Several Micro-流れのためのSignalingの組分けはProvidedであるかもしれません。 . . . . . . . . . . . . . . . . 17
Brunner Informational [Page 2] RFC 3726 Requirements for Signaling Protocols April 2004
プロトコル2004年4月に合図するためのブルンナー情報[2ページ]のRFC3726Requirements
5.5. Performance. . . . . . . . . . . . . . . . . . . . . . . 17
5.5.1. Scalability. . . . . . . . . . . . . . . . . . . 17
5.5.2. NSIS SHOULD Allow for Low Latency in Setup . . . 18
5.5.3. NSIS MUST Allow for Low Bandwidth Consumption
for the Signaling Protocol . . . . . . . . . . . 18
5.5.4. NSIS SHOULD Allow to Constrain Load on Devices . 18
5.5.5. NSIS SHOULD Target the Highest Possible Network
Utilization. . . . . . . . . . . . . . . . . . . 18
5.6. Flexibility. . . . . . . . . . . . . . . . . . . . . . . 19
5.6.1. Flow Aggregation . . . . . . . . . . . . . . . . 19
5.6.2. Flexibility in the Placement of the NSIS
Initiator/Responder. . . . . . . . . . . . . . . 19
5.6.3. Flexibility in the Initiation of State Change. . 19
5.6.4. SHOULD Support Network-Initiated State Change. . 19
5.6.5. Uni / Bi-directional State Setup . . . . . . . . 20
5.7. Security . . . . . . . . . . . . . . . . . . . . . . . . 20
5.7.1. Authentication of Signaling Requests . . . . . . 20
5.7.2. Request Authorization. . . . . . . . . . . . . . 20
5.7.3. Integrity Protection . . . . . . . . . . . . . . 20
5.7.4. Replay Protection. . . . . . . . . . . . . . . . 21
5.7.5. Hop-by-Hop Security. . . . . . . . . . . . . . . 21
5.7.6. Identity Confidentiality and Network Topology
Hiding . . . . . . . . . . . . . . . . . . . . . 21
5.7.7. Denial-of-Service Attacks. . . . . . . . . . . . 21
5.7.8. Confidentiality of Signaling Messages. . . . . . 22
5.7.9. Ownership of State . . . . . . . . . . . . . . . 22
5.8. Mobility . . . . . . . . . . . . . . . . . . . . . . . . 22
5.8.1. Allow Efficient Service Re-Establishment After
Handover . . . . . . . . . . . . . . . . . . . . 22
5.9. Interworking with Other Protocols and Techniques . . . . 22
5.9.1. MUST Interwork with IP Tunneling . . . . . . . . 22
5.9.2. MUST NOT Constrain Either to IPv4 or IPv6. . . . 23
5.9.3. MUST be Independent from Charging Model. . . . . 23
5.9.4. SHOULD Provide Hooks for AAA Protocols . . . . . 23
5.9.5. SHOULD work with Seamless Handoff Protocols. . . 23
5.9.6. MUST Work with Traditional Routing . . . . . . . 23
5.10. Operational. . . . . . . . . . . . . . . . . . . . . . . 23
5.10.1. Ability to Assign Transport Quality to Signaling
Messages . . . . . . . . . . . . . . . . . . . . 23
5.10.2. Graceful Fail Over . . . . . . . . . . . . . . . 24
5.10.3. Graceful Handling of NSIS Entity Problems. . . . 24
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 24
7. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 24
8. Appendix: Scenarios/Use Cases. . . . . . . . . . . . . . . . . 26
8.1. Terminal Mobility. . . . . . . . . . . . . . . . . . . . 26
8.2. Wireless Networks. . . . . . . . . . . . . . . . . . . . 28
8.3. An Example Scenario for 3G Wireless Networks . . . . . . 29
8.4. Wired Part of Wireless Network . . . . . . . . . . . . . 31
5.5. パフォーマンス。 . . . . . . . . . . . . . . . . . . . . . . 17 5.5.1. スケーラビリティ。 . . . . . . . . . . . . . . . . . . 17 5.5.2. NSISはセットアップ. . . 18 5.5.3における低遅延を考慮するはずです。 NSISはシグナリングプロトコル. . . . . . . . . . . 18 5.5.4のための低い帯域幅消費を考慮しなければなりません。 NSISは装置. 18 5.5.5で負荷を抑制させるべきです。 NSISは可能な限り高いネットワーク利用を狙うはずです。 . . . . . . . . . . . . . . . . . . 18 5.6. 柔軟性。 . . . . . . . . . . . . . . . . . . . . . . 19 5.6.1. 流れ集合. . . . . . . . . . . . . . . . 19 5.6.2。 NSIS創始者/応答者のプレースメントにおける柔軟性。 . . . . . . . . . . . . . . 19 5.6.3. 州の変化の開始における柔軟性。 . 19 5.6.4. ネットワークによって開始された州の変化を支持するべきです。 . 19 5.6.5. Uni/双方向の州のセットアップ. . . . . . . . 20 5.7。 セキュリティ. . . . . . . . . . . . . . . . . . . . . . . . 20 5.7.1。 シグナリング要求. . . . . . 20 5.7.2の認証。 認可を要求してください。 . . . . . . . . . . . . . 20 5.7.3. 保全保護. . . . . . . . . . . . . . 20 5.7.4。 保護を再演してください。 . . . . . . . . . . . . . . . 21 5.7.5. ホップごとのセキュリティ。 . . . . . . . . . . . . . . 21 5.7.6. アイデンティティ秘密性とネットワーク形態隠れること. . . . . . . . . . . . . . . . . . . . . 21 5.7.7。 サービス不能攻撃。 . . . . . . . . . . . 21 5.7.8. シグナリングメッセージの秘密性。 . . . . . 22 5.7.9. 状態. . . . . . . . . . . . . . . 22 5.8の所有権。 移動性. . . . . . . . . . . . . . . . . . . . . . . . 22 5.8.1。 引き渡. . . . . . . . . . . . . . . . . . . . 22 5.9しの後に効率的なサービス再建を許容してください。 他のプロトコルとテクニック. . . . 22 5.9.1で、織り込みます。 IPトンネリング. . . . . . . . 22 5.9.2で織り込まなければなりません。 IPv4かIPv6に抑制してはいけません。 . . . 23 5.9.3. Charging Modelからの無党派はそうであるに違いありませんか? . . . . 23 5.9.4. AAAプロトコル. . . . . 23 5.9.5にフックを提供するべきです。 SHOULDはSeamless Handoffプロトコルで働いています。 . . 23 5.9.6. 伝統的なルート設定. . . . . . . 23 5.10で働かなければなりません。 操作上。 . . . . . . . . . . . . . . . . . . . . . . 23 5.10.1. シグナリングメッセージ. . . . . . . . . . . . . . . . . . . . 23 5.10.2に輸送品質を割り当てる能力。 優雅なフェイルオーバー. . . . . . . . . . . . . . . 24 5.10.3。 NSIS実体問題の優雅な取り扱い… 24 6。 セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 24 7. 承認。 . . . . . . . . . . . . . . . . . . . . . . . 24 8. 付録: シナリオ/はケースを使用します。 . . . . . . . . . . . . . . . . 26 8.1. 端末の移動性。 . . . . . . . . . . . . . . . . . . . 26 8.2. ワイヤレス・ネットワーク。 . . . . . . . . . . . . . . . . . . . 28 8.3. 3G無線電信のための例のシナリオは.298.4をネットワークでつなぎます。 ワイヤレス・ネットワーク. . . . . . . . . . . . . 31のWired部分
Brunner Informational [Page 3] RFC 3726 Requirements for Signaling Protocols April 2004
プロトコル2004年4月に合図するためのブルンナー情報[3ページ]のRFC3726Requirements
8.5. Session Mobility . . . . . . . . . . . . . . . . . . . . 33
8.6. QoS Reservation/Negotiation from Access to Core Network. 34
8.7. QoS Reservation/Negotiation Over Administrative
Boundaries . . . . . . . . . . . . . . . . . . . . . . . 34
8.8. QoS Signaling Between PSTN Gateways and Backbone Routers 35
8.9. PSTN Trunking Gateway. . . . . . . . . . . . . . . . . . 36
8.10. An Application Requests End-to-End QoS Path from the
Network. . . . . . . . . . . . . . . . . . . . . . . . . 38
8.11. QOS for Virtual Private Networks . . . . . . . . . . . . 39
8.11.1. Tunnel End Points at the Customer Premises . . . 39
8.11.2. Tunnel End Points at the Provider Premises . . . 39
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40
9.1. Normative References . . . . . . . . . . . . . . . . . . 40
9.2. Informative References . . . . . . . . . . . . . . . . . 40
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 41
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 42
8.5. セッションの移動性. . . . . . . . . . . . . . . . . . . . 33 8.6。 コアネットワークへのアクセスからのQoS予約/交渉。 34 8.7. 管理境界. . . . . . . . . . . . . . . . . . . . . . . 34 8.8の上のQoS予約/交渉。 PSTNゲートウェイと背骨ルータ35 8.9の間で合図するQoS。 PSTN中継方式ゲートウェイ。 . . . . . . . . . . . . . . . . . 36 8.10. アプリケーションはネットワークから終わりから端へのQoS経路を要求します。 . . . . . . . . . . . . . . . . . . . . . . . . 38 8.11. 仮想私設網. . . . . . . . . . . . 39 8.11.1のためのQOS。 顧客構内. . . 39 8.11.2におけるエンドポイントにトンネルを堀ってください。 プロバイダー構内. . . 39 9でエンドポイントにトンネルを堀ってください。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 40 9.1。 引用規格. . . . . . . . . . . . . . . . . . 40 9.2。 有益な参照. . . . . . . . . . . . . . . . . 40 10。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 41 11。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 42
Brunner Informational [Page 4] RFC 3726 Requirements for Signaling Protocols April 2004
プロトコル2004年4月に合図するためのブルンナー情報[4ページ]のRFC3726Requirements
1. Introduction
1. 序論
This document is the product of the Next Steps in Signaling (NSIS) Working Group. It defines requirements for signaling across different network environments. It does not list any problems of existing signaling protocols such as [RSVP].
このドキュメントはSignaling(NSIS)作業部会におけるNext Stepsの製品です。 それは異なったネットワーク環境の向こう側に合図するための要件を定義します。 それは[RSVP]などのプロトコルに合図しながら存在するというどんな問題も記載しません。
In order to derive requirements for signaling it is necessary to first have an idea of the scope within which they are applicable. Therefore, we list use cases and scenarios where an NSIS protocol could be applied. The scenarios are used to help derive requirements and to test the requirements against use cases.
シグナリングのための要件を引き出すために、最初にそれらが適切である範囲の考えを持つのが必要です。 したがって、私たちは記載します。NSISプロトコルを適用できたところでケースとシナリオを使用してください。 要件を引き出すのを助けて、要件をテストする使用されるシナリオはケースを使用します。
The requirements listed are independent of any application. However, resource reservation and QoS related issues are used as examples within the text. However, QoS is not the only field where signaling is used in the Internet. Signaling might also be used as a communication protocol to setup and maintain the state in middleboxes [RFC3234].
リストアップされた要件はどんなアプリケーションからも独立しています。 しかしながら、資源予約とQoSの関連する問題は例としてテキストの中で使用されます。 しかしながら、QoSはシグナリングがインターネットで使用される唯一の分野ではありません。 また、シグナリングは、middleboxes[RFC3234]で状態をセットアップして、維持するのに通信プロトコルとして使用されるかもしれません。
This document does not cover requirements in relation to some networking areas, in particular, interaction with host and site multihoming. We leave these for future analysis.
このドキュメントは特にいくつかのネットワーク部門、ホストとの相互作用、およびサイトマルチホーミングと関連して要件をカバーしていません。 私たちは今後の分析にこれらを残します。
1.1. Keywords
1.1. キーワード
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 BCP 14, RFC 2119 [KEYWORDS].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14RFC2119[キーワード]で説明されるように本書では解釈されることであるべきです。
2. Terminology
2. 用語
We list the most often used terms in the document. However, they cannot be made precise without a more complete architectural model, and they are not meant to prescribe any solution in the document. Where applicable, they will be defined in protocol documents.
私たちは最も多くのしばしば使用された期間、ドキュメントに記載します。 しかしながら、それらをより完全な建築モデルなしで正確にすることができません、そして、彼らはドキュメントの少しの解決策も定めることになっていません。 適切であるところでは、それらがプロトコルドキュメントで定義されるでしょう。
NSIS Entity (NE): The function within a node, which implements an NSIS protocol. In the case of path-coupled signaling, the NE will always be on the data path.
NSIS実体(Ne): ノードの中の機能。ノードはNSISプロトコルを実行します。 経路で結合したシグナリングの場合には、NEがデータ経路にいつもあるでしょう。
NSIS Forwarder (NF): NSIS Entity between a NI and NR, which may interact with local state management functions in the network. It also propagates NSIS signaling further through the network.
NSIS混載業者(nf): NIとNRの間のNSIS Entity。NRはネットワークで地方の州の管理機能と対話するかもしれません。 また、それはさらにネットワークを通してNSISシグナリングを伝播します。
NSIS Initiator (NI): NSIS Entity that starts NSIS signaling to set up or manipulate network state.
NSIS創始者(Ni): NSISがネットワーク状態を設立するか、または操ると合図し始めるNSIS Entity。
Brunner Informational [Page 5] RFC 3726 Requirements for Signaling Protocols April 2004
プロトコル2004年4月に合図するためのブルンナー情報[5ページ]のRFC3726Requirements
NSIS Responder (NR): NSIS Entity that terminates NSIS signaling and can optionally interact with applications as well.
NSIS応答者(NR): NSISシグナリングを終えて、任意に終えることができるNSIS Entityはまた、アプリケーションと対話します。
Flow: A traffic stream (sequence of IP packets between two end systems) for which a specific packet level treatment is provided. The flow can be unicast (uni- or bi-directional) or multicast. For multicast, a flow can diverge into multiple flows as it propagates toward the receiver. For multi-sender multicast, a flow can also diverge when viewed in the reverse direction (toward the senders).
流れ: 特定のパケット・レベル処理が提供される交通の流れ(2台のエンドシステムの間のIPパケットの系列)。 流れは、ユニキャスト(uniの、または、双方向の)かマルチキャストであるかもしれません。 マルチキャストのために、受信機に向かって伝播するのに応じて、流れは複数の流れに分岐できます。また、マルチ送付者マルチキャストのために、反対の方向(送付者に向かった)として見られると、流れは分岐できます。
Data Path: The route across the networks taken by a flow or aggregate, i.e., which domains/subdomains it passes through and the egress/ingress points for each.
データ経路: すなわち流れか集合によって取られたそれがそれのドメイン/サブドメインを通り抜けるネットワークの向こう側のルートと出口/イングレスはそれぞれのために示されます。
Signaling Path: The route across the networks taken by a signaling flow or aggregate, i.e., which domains/subdomains it passes through and the egress/ingress points for each.
シグナリング経路: すなわちシグナリング流動か集合によって取られたそれがそれのドメイン/サブドメインを通り抜けるネットワークの向こう側のルートと出口/イングレスはそれぞれのために示されます。
Path-coupled signaling: A mode of signaling where the signaling messages follow a path that is tied to the data packets. Signaling messages are routed only through nodes (NEs) that are in the data path.
経路で結合したシグナリング: シグナリングメッセージがデータ・パケットに結ばれる経路に続くところで合図するモード。 シグナリングメッセージはデータ経路にないノード(NEs)しかを通して発送されます。
Path-decoupled signaling: Signaling with independent data and signaling paths. Signaling messages are routed to nodes (NEs) which are not assumed to be on the data path, but which are (presumably) aware of it. Signaling messages will always be directly addressed to the neighbor NE, and the NI/NR may have no relation at all with the ultimate data sender or receiver.
経路で衝撃を吸収されたシグナリング: 独立しているデータで合図して、経路に合図します。 シグナリングメッセージは思われませんでしたが、(おそらく、)データ経路にあるのをそれを意識しているノード(NEs)に発送されます。 シグナリングメッセージはいつも直接隣人NEに記述されるでしょう、そして、NI/NRは究極のデータ送付者か受信機で全く関係がないかもしれません。
Service: A generic something provided by one entity and consumed by another. It can be constructed by allocating resources. The network can provide it to users or a network node can provide it to packets.
サービス: 何かが1つの実体で提供して、別のもので消費したジェネリック。 リソースを割り当てることによって、それを組み立てることができます。 ネットワークがそれをユーザに提供できますか、またはネットワーク・ノードはパケットにそれを備えることができます。
3. Problem Statement and Scope
3. 問題声明と範囲
We provide in the following a preliminary architectural picture as a basis for discussion. We will refer to it in the following requirement sections.
私たちは議論の基礎として予備の建築絵を以下に提供します。 以下の要件部で私たちはそれについて言及するつもりです。
Note that this model is intended not to constrain the technical approach taken subsequently, simply to allow concrete phrasing of requirements (e.g., requirements about placement of the NSIS Initiator.)
このモデルが次に取られた技術的なアプローチを抑制しないで、単に要件の具体的な言い回しを許容することを意図することに注意してください。(例えば、NSIS Initiatorのプレースメントに関する要件。)
Brunner Informational [Page 6] RFC 3726 Requirements for Signaling Protocols April 2004
プロトコル2004年4月に合図するためのブルンナー情報[6ページ]のRFC3726Requirements
Roughly, the scope of NSIS is assumed to be the interaction between the NSIS Initiator, NSIS Forwarder(s), and NSIS Responder including a protocol to carry the information, and the syntax/semantics of the information that is exchanged. Further statements on assumptions/exclusions are given in the next Section.
およそ、NSISの範囲は情報を運ぶためにプロトコルを含むNSIS Initiatorと、NSIS Forwarder(s)と、NSIS Responderとの相互作用と、交換される情報の構文/意味論であると思われます。 次のセクションで仮定/除外に関するさらなる声明を与えます。
The main elements are:
主な要素は以下の通りです。
1. Something that starts the request for state to be set up in the
network, the NSIS Initiator.
1. 状態がネットワーク、NSIS Initiatorに設立されるという要求を始める何か。
This might be in the end system or within some other part of the
network. The distinguishing feature of the NSIS Initiator is that
it acts on triggers coming (directly or indirectly) from the
higher layers in the end systems. It needs to map the services
requested by them, and also provides feedback information to the
higher layers, which might be used by transport layer algorithms
or adaptive applications.
エンドシステムかネットワークのある他の部分の中にこれはあるかもしれません。 NSIS Initiatorの区別の特徴はエンドシステムで、より高い層から来る(直接か間接的に)引き金に影響するということです。それは、それらによって要求されたサービスを写像するのが必要であり、また、より高い層にフィードバック情報を供給します。(層はトランスポート層アルゴリズムか適応型のアプリケーションで使用されるかもしれません)。
2. Something that assists in managing state further along the
signaling path, the NSIS Forwarder.
2. シグナリング経路、NSIS Forwarderに沿って、より遠くに状態を経営するのを助ける何か。
The NSIS Forwarder does not interact with higher layers, but
interacts with the NSIS Initiator, NSIS Responder, and possibly
one or more NSIS Forwarders on the signaling path, edge-to-edge or
end-to-end.
NSIS Forwarderは、より高い層と対話しませんが、NSIS Initiator、NSIS Responder、およびことによるとシグナリング経路、斜めに進ませる縁または終わらせる終わりの1NSIS Forwardersと対話します。
3. Something that terminates the signaling path, the NSIS Responder.
3. シグナリング経路、NSIS Responderを終える何か。
The NSIS responder might be in an end-system or within other
equipment. The distinguishing feature of the NSIS Responder is
that it responds to requests at the end of a signaling path.
NSIS応答者はエンドシステムか他の設備の中にいるかもしれません。 NSIS Responderの区別の特徴はシグナリング経路の端での要求に応じるということです。
4. The signaling path traverses an underlying network covering one or
more IP hops. The underlying network might use locally different
technology. For instance, QoS technology has to be provisioned
appropriately for the service requested. In the QoS example, an
NSIS Forwarder maps service-specific information to technology-
related QoS parameters and receives indications about success or
failure in response.
4. シグナリング経路は1つ以上のIPホップを覆う基本的なネットワークを横断します。 基本的なネットワークは局所的に異なった技術を使用するかもしれません。 例えば、QoS技術は要求されたサービスのために適切に食糧を供給されなければなりません。 QoSの例では、NSIS Forwarderは技術関連するQoSパラメタにサービス特有の情報を写像して、応答における成否に関して指摘を受けます。
5. We can see the network at the level of domains/subdomains rather
than individual routers (except in the special case that the
domain contains one link). Domains are assumed to be
administrative entities. So security requirements might apply
differently for the signaling between the domains and within a
domain. Both cases we deal with in this document.
5. 私たちは個々のルータよりむしろドメイン/サブドメインのレベルでネットワークを見ることができます(ドメインが含む特別なケースを除いて、1つはリンクします)。 ドメインは管理実体であると思われます。 それで、セキュリティ要件はドメインの間と、そして、ドメインの中でシグナリングに異なって申し込むかもしれません。 私たちが本書では対処する両方のケース。
Brunner Informational [Page 7] RFC 3726 Requirements for Signaling Protocols April 2004
プロトコル2004年4月に合図するためのブルンナー情報[7ページ]のRFC3726Requirements
4. Assumptions and Exclusions
4. 仮定と除外
4.1. Assumptions and Non-Assumptions
4.1. 仮定と非仮定
1. The NSIS signaling could run end-to-end, end-to-edge, or edge-to-
edge, or network-to-network (between providers), depending on what
point in the network acts as NSIS initiator, and how far towards
the other end of the network the signaling propagates. In
general, we could expect NSIS Forwarders to become more 'dense'
towards the edges of the network, but this is not a requirement.
For example, in the case of QoS, an over-provisioned domain might
contain no NSIS Forwarders at all (and be NSIS transparent); at
the other extreme, NSIS Forwarders might be placed at every
router. In the latter case, QoS provisioning can be carried out
in a local implementation-dependent way without further signaling,
whereas in the case of remote NSIS Forwarders, a protocol might be
needed to control the routers along the path. This protocol is
then independent of the end-to-end NSIS signaling.
1. NSISシグナリングはネットワークから終わりから終わり、終わりから縁、または縁から縁、またはネットワーク(プロバイダーの間の)を経営しているかもしれません、ネットワークにおけるどんなポイントがNSIS創始者として機能するか、そして、シグナリングがどれくらいネットワークのもう一方の端に向かって遠くに伝播されるかによって。 一般に、私たちは、NSIS Forwardersがネットワークの縁に向かって、より'濃く'なると予想できましたが、これは要件ではありません。 例えば、QoSの場合では、食糧を供給され過ぎるドメインはNSIS Forwardersを全く含まないかもしれません(NSISが透明であったなら)。 それとは正反対に、NSIS Forwardersはあらゆるルータに置かれるかもしれません。 後者の場合では、リモートNSIS Forwardersの場合では、プロトコルが経路に沿ってルータを制御するのに必要であるかもしれませんが、さらに合図しないで、ローカルの実現依存する方法でQoSの食糧を供給することを行うことができます。 このプロトコルはその時、終わりから終わりへのNSISシグナリングから独立しています。
2. We do not consider 'pure' end-to-end signaling that is not
interpreted anywhere within the network. Such signaling is a
higher-layer issue and IETF protocols such as SIP etc. can be
used.
2. 私たちは、'純粋な'終わりから終わりがネットワークの中で何処にも解釈されないシグナリングであると、考えません。 そのようなシグナリングは、より高い層の発行です、そして、SIPなどのIETFプロトコルは使用できます。
3. Where the signaling does cover several domains, we do not exclude
that different signaling protocols are used in each domain. We
only place requirements on the universality of the control
information that is being transported. (The goals here would be
to allow the use of signaling protocols, which are matched to the
characteristics of the portion of the network being traversed.)
Note that the outcome of NSIS work might result in various flavors
of the same protocol.
3. シグナリングがいくつかのドメインをカバーしていて、私たちがそれを除かないところでは、異なったシグナリングプロトコルが各ドメインで使用されます。 私たちは輸送されている制御情報の普遍性に要件を置くだけです。 (ここの目標は横断されるネットワークの一部の特性に合わせられているシグナリングプロトコルの使用を許すだろうことです。) NSIS仕事の結果が同じプロトコルの様々な風味をもたらすかもしれないことに注意してください。
4. We assume that the service definitions a NSIS Initiator can ask
for are known in advance of the signaling protocol running. For
instance in the QoS example, the service definition includes QoS
parameters, lifetime of QoS guarantee etc., or any other service-
specific parameters.
4. 私たちは、NSIS Initiatorが求めることができるサービス定義がシグナリングプロトコル走行の前に知られていると思います。 例えば、QoSの例では、サービス定義はQoSパラメタを含んで、QoS保証など、またはいかなる他のサービスの寿命も特定のパラメタです。
There are many ways service requesters get to know about available
services. There might be standardized services, the definition
can be negotiated together with a contract, the service definition
is published in some on-line directory (e.g., at a Web page), and
so on.
サービスリクエスタが営業品目に関して知り合う多くの道があります。 サービスが標準化されるかもしれなくて、契約と共に定義を交渉できて、サービス定義は何らかのオンラインディレクトリ(例えば、ウェブページの)、などに発行されます。
5. We assume that there are means for the discovery of NSIS entities
in order to know the signaling peers (solutions include static
configuration, automatically discovered, or implicitly runs over
5. 私たちは、NSIS実体の発見のための手段がシグナリング同輩を知るためにあると思います。(解決策は静的な構成を含んでいます、自動的に発見されてそれとなく、あふれます。
Brunner Informational [Page 8] RFC 3726 Requirements for Signaling Protocols April 2004
プロトコル2004年4月に合図するためのブルンナー情報[8ページ]のRFC3726Requirements
the right nodes along the data path, etc.). The discovery of the
NSIS entities has security implications that need to be addressed
properly. For some security mechanisms (i.e., Kerberos, pre-
shared secret) it is required to know the identity of the other
entity. Hence the discovery mechanism may provide means to learn
this identity, which is then later used to retrieve the required
keys and parameters.
データ経路などに沿った正しいノード) NSIS実体の発見には、適切に記述される必要があるセキュリティ意味があります。 いくつかのセキュリティー対策(すなわち、ケルベロス、プレ共有秘密キー)において、それが、もう片方の実体のアイデンティティを知るのに必要です。 したがって、発見メカニズムは次に後で必要なキーとパラメタを検索するのに使用されるこのアイデンティティを学ぶ手段を提供するかもしれません。
6. NSIS assumes layer 3 routing and the determination of next data
node selection is not done by NSIS.
6. NSISは、NSISが次のデータノード選択の層3のルーティングと決断を完了していないと仮定します。
4.2. Exclusions
4.2. 除外
1. Development of specific mechanisms and algorithms for application
and transport layer adaptation are not considered, nor are the
protocols that would support it.
1. アプリケーションのための特定のメカニズムとアルゴリズムとトランスポート層適合の開発は考えられません、そして、それがサポートするプロトコルはそれではありません。
2. Specific mechanisms (APIs and so on) for interaction between
transport/applications and the network layer are not considered,
except to clarify the requirements on the negotiation
capabilities and information semantics that would be needed of
the signaling protocol.
2. 輸送/アプリケーションとネットワーク層との相互作用のための特定のメカニズム(APIなど)は考えられません、シグナリングプロトコルについて必要である交渉能力と情報意味論に関する要件をはっきりさせるのを除いて。
3. Specific mechanisms and protocols for provisioning or other
network control functions within a domain/subdomain are not
considered. The goal is to reuse existing functions and
protocols unchanged. However, NSIS itself can be used for
signaling within a domain/subdomain.
3. 食糧を供給する特定のメカニズムとプロトコルかドメイン/サブドメインの中の他のネットワーク制御機能が考えられません。 目標は変わりがない状態で従来の機能とプロトコルを再利用することです。 しかしながら、ドメイン/サブドメインの中で合図するのにNSIS自身を使用できます。
For instance in the QoS example, it means that the setting of QoS
mechanisms in a domain is out of scope, but if we have a tunnel,
NSIS could also be used for tunnel setup with QoS guarantees. It
should be possible to exploit these mechanisms optimally within
the end-to-end context. Consideration of how to do this might
generate new requirements for NSIS however. For example, the
information needed by a NSIS Forwarder to manage a radio
subnetwork needs to be provided by the NSIS solution.
例えば、QoSの例では、範囲の外にドメインのQoSメカニズムの設定があることを意味しますが、私たちがトンネルを持っているなら、また、NSISはトンネルセットアップにQoS保証で使用されるかもしれません。 終わりから終わりへの文脈の中でこれらのメカニズムを最適に利用するのは可能であるべきです。 しかしながら、どうこれをするかに関する考慮はNSISのための新しい要件を発生させるかもしれません。例えば、ラジオサブネットワークを管理するためにNSIS Forwarderによって必要とされた情報は、NSIS解決策によって提供される必要があります。
4. Specific mechanisms (APIs and so on) for interaction between the
network layer and underlying provisioning mechanisms are not
considered.
4. メカニズムに食糧を供給するネットワーク層と基本的さとの相互作用のための特定のメカニズム(APIなど)は考えられません。
5. Interaction with resource management or other internal state
management capabilities is not considered. Standard protocols
might be used for this. This may imply requirements for the sort
of information that should be exchanged between the NSIS
entities.
5. 資源管理か他の内部の国家管理能力との相互作用は考えられません。 標準プロトコルはこれに使用されるかもしれません。 これはNSIS実体の間で交換されるべきである情報の種類のための要件を含意するかもしれません。
Brunner Informational [Page 9] RFC 3726 Requirements for Signaling Protocols April 2004
プロトコル2004年4月に合図するためのブルンナー情報[9ページ]のRFC3726Requirements
6. Security implications related to multicasting are outside the
scope of the signaling protocol.
6. シグナリングプロトコルの範囲の外にマルチキャスティングに関連するセキュリティ含意があります。
7. Service definitions and in particular QoS services and classes
are out of scope. Together with the service definition any
definition of service specific parameters are not considered in
this document. Only the base NSIS signaling protocol for
transporting the service information are addressed.
7. サービス定義と特定のQoSに、範囲の外にサービスとクラスがあります。 サービス定義と共に、サービスの特定のパラメタの少しの定義も本書では考えられません。 サービス情報を輸送するためのベースNSISシグナリングプロトコルだけが記述されます。
8. Similarly, specific methods, protocols, and ways to express
service information in the Application/Session level are not
considered (e.g., SDP, SIP, RTSP, etc.).
8. 同様に、特定の方法、プロトコル、およびApplication/セッションレベルのサービス情報を言い表す方法は(例えば、SDP、SIP、RTSPなど)であると考えられません。
9. The specification of any extensions needed to signal information
via application level protocols (e.g., SDP), and the mapping to
NSIS information are considered outside of the scope of NSIS
working group, as this work is in the direct scope of other IETF
working groups (e.g., MMUSIC).
9. どんな拡大の仕様も、アプリケーションレベルプロトコル(例えば、SDP)で情報に合図する必要がありました、そして、NSIS情報へのマッピングはNSISワーキンググループの範囲の外で考えられます、この仕事が他のIETFワーキンググループ(例えば、MMUSIC)のダイレクト範囲にあるとき。
10. Handoff decision and trigger sources: An NSIS protocol is not
used to trigger handoffs in mobile IP, nor is it used to decide
whether to handoff or not. As soon as or in some situations even
before a handoff happened, an NSIS protocol might be used for
signaling for the particular service again. The basic underlying
assumption is that the route comes first (defining the path) and
the signaling comes after it (following the path). This doesn't
prevent a signaling application at some node interacting with
something that modifies the path, but the requirement is then
just for NSIS to live with that possibility. However, NSIS must
interwork with several protocols for mobility management.
10. 移管決定と引き金のソース: NSISプロトコルは可動のIPでhandoffsの引き金となるのに使用されません、そして、それは移管であるか否かに関係なく、決めるのにおいて使用されていません。 状況かいくつかの状況で、移管が起こる前にさえNSISプロトコルは、特定のサービスのために再び合図するのに使用されるかもしれません。 基本的な基本的な仮定はルートが一番になるという(経路を定義して)ことです、そして、シグナリングはそれに続いています(経路に続いて)。 これは、何らかのノードのシグナリングアプリケーションが経路を変更する何かと対話するのを防ぎませんが、要件はそして、NSISがまさしくその可能性を受け入れることです。 しかしながら、NSISは移動性のためにいくつかのプロトコルで管理を織り込まなければなりません。
11. Service monitoring is out of scope. It is heavily dependent on
the type of the application and or transport service, and in what
scenario it is used.
11. 範囲の外にサービスモニターがあります。 そして、それがずっしりとアプリケーションのタイプに依存している、または、輸送サービスであってそれはどんなシナリオで使用されていますか?
5. Requirements
5. 要件
This section defines more detailed requirements for a signaling solution, respecting the problem statement, scoping assumptions, and terminology considered earlier. The requirements are in subsections, grouped roughly according to general technical aspects: architecture and design goals, topology issues, parameters, performance, security, information, and flexibility.
仮定、および、より早く考えられた用語を見て、問題声明を尊敬して、このセクションはシグナリング解決策のための、より詳細な要件を定義します。 一般的な技術的側面に従っておよそ分類された小区分には要件があります: 構造、デザイン目標、トポロジー問題、パラメタ、性能、セキュリティ、情報、および柔軟性。
Two general (and potentially contradictory) goals for the solution are that it should be applicable in a very wide range of scenarios, and at the same time be lightweight in implementation complexity and resource consumption requirements in NSIS Entities. We use the terms
ソリューションの2つの一般的で(潜在的に相容れません)の目標はそれが非常に広範囲のシナリオで適切であり、同時にNSIS Entitiesの実装の複雑さとリソース消費要件で軽量であるべきであるということです。 私たちは用語を使用します。
Brunner Informational [Page 10] RFC 3726 Requirements for Signaling Protocols April 2004
プロトコル2004年4月に合図するためのブルンナー情報[10ページ]のRFC3726Requirements
'access' and 'core' informally in the discussion of some particular requirements to refer to deployment conditions where particular protocol attributes, especially performance characteristics, have special importance. Specifically, 'access' refers to lower capacity networks with fewer users and sessions. 'Core' refers to high capacity networks with a large number of users and sessions.
'特定のプロトコル属性(特に性能の特性)が特別な重要性を持っているところと展開状態を呼ぶといういくつかの特定の要件の議論で''コア'に非公式にアクセスしてください。 明確に、'アクセス'は、より少ないユーザとセッションで低い容量ネットワークを示します。 'コア'は多くのユーザとセッションで高容量ネットワークを示します。
One approach to this is that the solution could deal with certain requirements via modular components or capabilities, which are optional to implement or use in individual nodes.
これへの1つのアプローチはモジュールのコンポーネントか能力でソリューションが、ある要件に対処するかもしれないということです。(能力は、個々のノードで実装するか、または使用するために任意です)。
5.1. Architecture and Design Goals
5.1. アーキテクチャとデザイン目標
This section contains requirements related to desirable overall characteristics of a solution, e.g., enabling flexibility, or independence of parts of the framework.
このセクションはソリューションの望ましい総合的な特性、例えば、柔軟性を可能にするか、またはフレームワークの部品からの独立に関連する要件を含みます。
5.1.1. NSIS SHOULD Provide Availability Information on Request
5.1.1. NSISは要求に応じて有用性情報を提供するはずです。
NSIS SHOULD provide a mechanism to check whether state to be setup is available without setting it up. For the resource reservation example this translates into checking resource availability without performing resource reservation. In some scenarios, e.g., the mobile terminal scenario, it is required to query, whether resources are available, without performing a reservation on the resource.
NSIS SHOULDは、セットアップである状態がそれをセットアップしないで利用可能であるかどうかチェックするためにメカニズムを提供します。 資源予約の例に関しては、資源予約を実行しないで、これは照合リソースの有用性に翻訳されます。 いくつかのシナリオ、例えば、移動体端末シナリオでは、それが質問するのに必要です、リソースが利用可能であるか否かに関係なく、リソースの予約を実行しないで。
5.1.2. NSIS MUST be Designed Modularly
5.1.2. NSIS MUST、Designed Modularlyになってください。
A modular design allows for more lightweight implementations, if fewer features are needed. Mutually exclusive solutions are supported. Examples for modularity:
より少ない特徴が必要であるなら、モジュールのデザインは、より軽量の実装を考慮します。 互いに排他的なソリューションはサポートされます。 モジュール方式のための例:
- Work over any kind of network (narrowband versus broadband,
error-prone versus reliable, ...). This implies low bandwidth
signaling, and elimination of redundant information MUST be
supported if necessary.
- どんな種類のネットワーク(狭帯域対誤り信頼できるに対して傾向があるブロードバンド)の上でも働いてください。 これは低い帯域幅シグナリングを含意します、そして、必要なら、余分な情報の除去をサポートしなければなりません。
- State setup for uni- and bi-directional flows is possible.
- uniと双方向の流れのための州のセットアップは可能です。
- Extensible in the future with different add-ons for certain
environments or scenarios.
- 将来、異なったアドオンで、ある環境かシナリオにおいて広げることができます。
- Protocol layering, where appropriate. This means NSIS MUST
provide a base protocol, which can be adapted to different
environments.
- 適切であるところでレイヤリングについて議定書の中で述べてください。 これは、NSIS MUSTがベースプロトコルを提供することを意味します。(異なった環境にプロトコルを適合させることができます)。
Brunner Informational [Page 11] RFC 3726 Requirements for Signaling Protocols April 2004
プロトコル2004年4月に合図するためのブルンナー情報[11ページ]のRFC3726Requirements
5.1.3. NSIS MUST Decouple Protocol and Information
5.1.3. NSISはプロトコルと情報の衝撃を吸収しなければなりません。
The signaling protocol MUST be clearly separated from the control information being transported. This provides for the independent development of these two aspects of the solution, and allows for this control information to be carried within other protocols, including application layer ones, existing ones or those being developed in the future. The flexibility gained in the transport of information allows for the applicability of the same protocol in various scenarios.
輸送される制御情報とシグナリングプロトコルを明確に切り離さなければなりません。 これは、ソリューションのこれらの2つの局面の自主開発に備えて、この制御情報が他のプロトコルの中で運ばれるのを許容します、将来開発されていて、応用層もの、既存のものまたはそれらを含んでいて。 情報の輸送で獲得された柔軟性は様々なシナリオの同じプロトコルの適用性を考慮します。
However, note that the information carried needs to be standardized; otherwise interoperability is difficult to achieve.
しかしながら、情報が標準化されるべき必要性を運んだことに注意してください。 さもなければ、相互運用性は達成するのが難しいです。
5.1.4. NSIS MUST Support Independence of Signaling and Network Control
Paradigm
5.1.4. NSISはシグナリングとネットワーク制御パラダイムからの独立をサポートしなければなりません。
The signaling MUST be independent of the paradigm and mechanism of network control. E.g., in the case of signaling for QoS, the independence of the signaling protocol from the QoS provisioning allows for using the NSIS protocol together with various QoS technologies in various scenarios.
シグナリングはネットワーク制御のパラダイムとメカニズムから独立しているに違いありません。 例えば、QoSのために合図する場合では、QoSの食糧を供給するのからのシグナリングプロトコルからの独立は、様々なシナリオの様々なQoS技術と共にNSISプロトコルを使用すると考慮します。
5.1.5. NSIS SHOULD be Able to Carry Opaque Objects
5.1.5. NSIS SHOULD、Carry Opaque ObjectsへのAbleになってください。
NSIS SHOULD be able to pass around opaque objects, which are interpreted only by some NSIS-capable nodes.
NSIS SHOULD、不透明なオブジェクトを回すことができてください。(オブジェクトはいくつかのNSISできるノードだけによって解釈されます)。
5.2. Signaling Flows
5.2. シグナリングは流れます。
This section contains requirements related to the possible signaling flows that should be supported, e.g., over what parts of the flow path, between what entities (end-systems, routers, middleboxes, management systems), in which direction.
このセクションはサポートされるべきである可能なシグナリング流れに関連する要件を含みます、例えば、流路のどんな地域の上で、どんな実体(エンドシステム、ルータ、middleboxes、マネージメントシステム)の間で、どの方向に。
5.2.1. The placement of NSIS Initiator, Forwarder, and Responder
Anywhere in the Network MUST be Allowed
5.2.1. NetworkのNSIS Initiator、Forwarder、およびResponder AnywhereのプレースメントはAllowedであるに違いありません。
The protocol MUST work in various scenarios such as host-to-network- to-host, edge-to-edge, (e.g., just within one provider's domain), user-to-network (from end system into the network, ending, e.g., at the entry to the network and vice versa), and network-to-network (e.g., between providers).
プロトコルがホストからネットワークなどの様々なシナリオで働かなければならない、-ホストであることが斜めに進むために斜めに進んでください、(例えば、まさしく1つのプロバイダーのドメインの中の)、ユーザからネットワーク(ネットワークへのエンドシステムから例えば、ネットワークへのエントリーで逆もまた同様に終わる)、およびネットワークからネットワーク(例えば、プロバイダーの間の)。
Placing the NSIS Forwarder and NSIS Initiator functions at different locations allows for various scenarios to work with the same protocol.
NSIS ForwarderとNSIS Initiator機能を別の場所にみなすのは、様々なシナリオが同じプロトコルで働くのを許容します。
Brunner Informational [Page 12] RFC 3726 Requirements for Signaling Protocols April 2004
プロトコル2004年4月に合図するためのブルンナー情報[12ページ]のRFC3726Requirements
5.2.2. NSIS MUST Support Path-Coupled and MAY Support Path-Decoupled
Signaling.
5.2.2. NSISは経路で結合されるのと5月のサポートの経路で衝撃を吸収されたシグナリングをサポートしなければなりません。
The path-coupled signaling mode MUST be supported. NSIS signaling messages are routed only through nodes (NEs) that are in the data path.
経路で結合したシグナリングモードをサポートしなければなりません。 NSISシグナリングメッセージはデータ経路にないノード(NEs)しかを通して発送されます。
However, there is a set of scenarios, where signaling is not on the data path. Therefore, NSIS MAY support the path-decoupled signaling mode, where signaling messages are routed to nodes (NEs), which are not assumed to be on the data path, but which are aware of it.
しかしながら、1セットのシナリオがあります。そこには、シグナリングがデータ経路にありません。 したがって、NSIS MAYは経路で衝撃を吸収されたシグナリングモードをサポートします、シグナリングメッセージがノード(NEs)(思われませんがデータ経路にあるのをそれを意識している)に発送されるところで。
5.2.3. Concealment of Topology and Technology Information SHOULD be
Possible
5.2.3. 隠すこと、TopologyとTechnology情報SHOULDでは、Possibleになってください。
The NSIS protocol SHOULD allow for hiding the internal structure of a NSIS domain from end-nodes and from other networks. Hence an adversary should not be able to learn the internal structure of a network with the help of the signaling protocol.
NSISプロトコルSHOULDは、エンドノードと他のネットワークからNSISドメインの内部の構造を隠すと考慮します。 したがって、敵はシグナリングプロトコルの助けでネットワークの内部の構造を学ぶことができないべきです。
In various scenarios, topology information should be hidden for various reasons. From a business point of view, some administrations don't want to reveal the topology and technology used.
様々なシナリオでは、トポロジー情報は様々な理由で隠されるべきです。 ビジネス観点から、トポロジーと技術が使用されているのを明らかにしたがっていない政権もあります。
5.2.4. Transparent Signaling Through Networks SHOULD be Possible
5.2.4. 透明なSignaling Through Networks SHOULD、Possibleになってください。
It SHOULD be possible that the signaling for some flows traverses path segments transparently, i.e., without interpretation at NSIS Forwarders within the network. An example would be a subdomain within a core network, which only interpreted signaling for aggregates established at the domain edge, with the signaling for individual flows passing transparently through it.
それ、SHOULD、いくつかの流れのためのシグナリングが透過的に経路セグメントを横断するのを可能であってください、すなわち、ネットワークの中のNSIS Forwardersの解釈なしで。 例はコアネットワークの中のサブドメインでしょう、個々の流れのためのシグナリングが透過的にそれを通り抜けていて。ネットワークはドメイン縁で確立された集合のためにシグナリングを解釈するだけでした。
In other words, NSIS SHOULD work in hierarchical scenarios, where big pipes/trunks are setup using NSIS signaling, but also flows which run within that big pipe/trunk are setup using NSIS.
言い換えれば、NSIS SHOULDは階層的なシナリオで働いていますが、その大きいパイプ/トランクの中に稼働する流れはNSISを使用するまたセットアップでもあります。(そこでは、大きいパイプ/トランクスはNSISシグナリングを使用するセットアップです)。
5.3. Messaging
5.3. メッセージング
5.3.1. Explicit Erasure of State MUST be Possible
5.3.1. 州の明白なErasureはPossibleであるに違いありません。
When state along a path is no longer necessary, e.g., because the application terminates, or because a mobile host experienced a hand- off, it MUST be possible to erase the state explicitly.
例えば、アプリケーションが終わるので経路に沿った状態はもう必要でないときに、モバイルホストが下に手を経験したので、明らかに状態を消すのは可能であるに違いありません。
Brunner Informational [Page 13] RFC 3726 Requirements for Signaling Protocols April 2004
プロトコル2004年4月に合図するためのブルンナー情報[13ページ]のRFC3726Requirements
5.3.2. Automatic Release of State After Failure MUST be Possible
5.3.2. 州After Failureの自動ReleaseはPossibleであるに違いありません。
When the NSIS Initiator goes down, the state it requested in the network SHOULD be released, since it will most likely no longer be necessary.
NSIS Initiatorが落ちたら、それがネットワークSHOULDで要求した状態がリリースされて、たぶん必要性になるので、もう必要にしないでください。
After detection of a failure in the network, any NSIS Forwarder/Initiator MUST be able to release state it is involved in. For example, this may require signaling of the "Release after Failure" message upstream as well as downstream, or soft state timing out.
ネットワークにおける、失敗の検出の後に、どんなNSIS Forwarder/創始者もそれがかかわる状態をリリースできなければなりません。 例えば、これは外で川下の、または、柔らかい州のタイミングと同様に「リリース後失敗」メッセージ上流をシグナリングに要求するかもしれません。
The goal is to prevent stale state within the network and add robustness to the operation of NSIS. So in other words, an NSIS signaling protocol or mechanisms MUST provide means for an NSIS entity to discover and remove local stale state.
目標は、ネットワークの中で聞き古した状態を防いで、NSISの操作に丈夫さを加えることです。 それで、言い換えれば、NSISシグナリングプロトコルかメカニズムがNSIS実体が地方の聞き古した状態を発見して、取り除く手段を提供しなければなりません。
Note that this might need to work together with a notification mechanism. Note as well, that transient failures in NSIS processing shouldn't necessarily have to cause all state to be released immediately.
これが、通知メカニズムと共に働く必要であるかもしれないことに注意してください。 すぐに必ずNSIS処理における一時障害ですべての状態をリリースする必要はないはずであるというまた、メモ。
5.3.3. NSIS SHOULD Allow for Sending Notifications Upstream
5.3.3. NSISは、上流へ通知を送ると考慮するはずです。
NSIS Forwarders SHOULD notify the NSIS Initiator or any other NSIS Forwarder upstream, if there is a state change inside the network. There are various types of network changes for instance among them:
NSIS Forwarders SHOULDは上流へNSIS Initiatorかいかなる他のNSIS Forwarderにも通知します、ネットワークの中に州の変化があれば。 それらの中に例えば様々なタイプのネットワーク変化があります:
Recoverable errors: the network nodes can locally repair this type error. The network nodes do not have to notify the users of the error immediately. This is a condition when the danger of degradation (or actual short term degradation) of the provided service was overcome by the network (NSIS Forwarder) itself.
回復可能エラー: ネットワーク・ノードは局所的にこのタイプ誤りを修理できます。 ネットワーク・ノードはすぐに、誤りについてユーザに通知する必要はありません。 提供されたサービスの退行(または、実際の短期間退行)の危険がネットワーク(NSIS Forwarder)自体によって克服されたとき、これは状態です。
Unrecoverable errors: the network nodes cannot handle this type of error, and have to notify the users as soon as possible.
回復不能エラー: ネットワーク・ノードは、このタイプの誤りを扱うことができないで、できるだけ早く、ユーザに通知しなければなりません。
Service degradation: In case the service cannot be provided completely but only partially.
退行を修理してください: 場合では、完全に提供できるのではなく、サービスを部分的だけに提供します。
Repair indication: If an error occurred and it has been fixed, this triggers the sending of a notification.
指示を修理してください: 誤りが発生して、それが修理されたなら、これは通知の発信の引き金となります。
Service upgrade available: If a previously requested better service becomes available.
利用可能なアップグレードを修理してください: 以前に要求されたより良いサービスが利用可能になるなら。
Brunner Informational [Page 14] RFC 3726 Requirements for Signaling Protocols April 2004
プロトコル2004年4月に合図するためのブルンナー情報[14ページ]のRFC3726Requirements
The content of the notification is very service specific, but it is must at least carry type information. Additionally, it may carry the location of the state change.
通知の内容はまさしくそのサービス詳細ですが、必須がタイプ情報を少なくとも運ぶということです。 さらに、それは州の変化の位置を運ぶかもしれません。
The notifications may or may not be in response to a NSIS message. This means an NSIS entity has to be able to handle notifications at any time.
通知はNSISメッセージに対応しているかもしれません。 これは、NSIS実体がいつでも通知を扱うことができなければならないことを意味します。
Note however, that there are a number of security consideration needs to be solved with notification, even more important if the notification is sent without prior request (asynchronously). The problem basically is, that everybody could send notifications to any NSIS entity and the NSIS entity most likely reacts on the notification. For example, if it gets an error notification it might erase state, even if everything is ok. So the notification might depend on security associations between the sender of the notification and its receiver. If a hop-by-hop security mechanism is chosen, this implies also that notifications need to be sent on the reverse path.
しかしながら、先の要求(非同期である)なしで通知を送るなら通知、さらに重要で解決して、それが考慮が必要とするセキュリティの数がいることに注意してください。 問題が基本的にあります、そして、そのみんなはどんなNSIS実体にも通告を送るかもしれません、そして、NSIS実体はたぶん通知に影響します。 例えば、エラー通知を得るなら、すべてが間違いなくても、それは状態を消すかもしれません。 それで、通知は通知の送付者とその受信機とのセキュリティ仲間に頼るかもしれません。また、ホップごとのセキュリティー対策が選ばれているなら、これは、通知が、逆の経路で送られる必要であるのを含意します。
5.3.4. Establishment and Refusal to Set Up State MUST be Notified
5.3.4. Set Up州への設立とRefusalはNotifiedであるに違いありません。
A NR MUST acknowledge establishment of state on behalf of the NI requesting establishment of that state. A refusal to set up state MUST be replied with a negative acknowledgement by the NE refusing to set up state. It MUST be sent to the NI. Depending on the signaling application the (positive or negative) notifications may have to pass through further NEs upstream. Information on the reason of the refusal to set up state MAY be made available. For example, in the resource reservation example, together with a negative answer, the amount of resources available might also be returned.
NR MUSTはその状態の設立を要求するNIを代表して状態の設立を承諾します。 NEによる否定的承認が、状態を設立するのを拒否している状態で、状態を設立することへの拒否について返答しなければなりません。 それをNIに送らなければなりません。 シグナリングアプリケーションによって、(肯定するか否定する)の通知は一層のNEs上流を通り抜けなければならないかもしれません。 状態を設立することへの拒否の理由に関する情報を利用可能にするかもしれません。 例えば、また、資源予約の例では、否定的な返答と共に、リソースの有効な量は返されるかもしれません。
5.3.5. NSIS MUST Allow for Local Information Exchange
5.3.5. NSISは地方の情報交換を考慮しなければなりません。
The signaling protocol MUST be able to exchange local information between NSIS Forwarders located within one single administrative domain. The local information exchange is performed by a number of separate messages not belonging to an end-to-end signaling process. Local information might, for example, be IP addresses, notification of successful or erroneous processing of signaling messages, or other conditions.
シグナリングプロトコルは1つのただ一つの管理ドメインの中に位置したNSIS Forwardersの間でローカルの情報を交換できなければなりません。 地方の情報交換は終わりから終わりへのシグナリングプロセスに属さない多くの別々のメッセージによって実行されます。 例えば、ローカルの情報はIPアドレス、シグナリングメッセージ、または他の状態のうまくいっているか誤った処理が通知であるかもしれません。
In some cases, the NSIS signaling protocol MAY carry identification of the NSIS Forwarders located at the boundaries of a domain. However, the identification of edge should not be visible to the end host (NSIS Initiator) and only applies within one administrative domain.
いくつかの場合、NSISシグナリングプロトコルはドメインの境界に位置するNSIS Forwardersの識別を運ぶかもしれません。 しかしながら、縁の識別は、終わりのホスト(NSIS Initiator)において目に見えるべきでなくて、1つの管理ドメインの中で適用されるだけです。
Brunner Informational [Page 15] RFC 3726 Requirements for Signaling Protocols April 2004
プロトコル2004年4月に合図するためのブルンナー情報[15ページ]のRFC3726Requirements
5.4. Control Information
5.4. 制御情報
This section contains requirements related to the control information that needs to be exchanged.
このセクションは交換される必要がある制御情報に関連する要件を含みます。
5.4.1. Mutability Information on Parameters SHOULD be Possible
5.4.1. 無常情報、Parameters SHOULDの上では、Possibleになってください。
It is possible that nodes modify parameters of a signaling message. However, it SHOULD be possible for the NSIS Initiator to control the mutability of the signaled information. For example, the NSIS Initiator should be able to control what is requested end-to-end, without the request being gradually mutated as it passes through a sequence of nodes.
ノードがシグナリングメッセージのパラメタを変更するのは、可能です。 しかしながら、それ、SHOULD、NSIS Initiatorが合図された情報の無常を制御するのにおいて、可能であってください。 例えば、NSIS Initiatorは、何が要求されたノードの系列を通り抜けるので徐々に変異する要求存在がなければ終わりから終わりであるかを制御するはずであることができます。
5.4.2. It SHOULD be Possible to Add and Remove Local Domain Information
5.4.2. それ、SHOULD、AddへのPossibleとRemove Local Domain情報になってください。
It SHOULD be possible to add and remove local scope elements. Compared to Requirement 5.3.5 this requirement does use the normal signaling process and message exchange for transporting local information. For example, at the entrance to a domain, domain- specific information is added information is added, which is used in this domain only, and the information is removed again when a signaling message leaves the domain. The motivation is in the economy of re-using the protocol for domain internal signaling of various information pieces. Where additional information is needed within a particular domain, it should be possible to carry this at the same time as the end-to-end information.
それ、SHOULDは加えるのにおいて可能であり、ローカルの範囲要素を取り除きます。 Requirement5.3.5と比べて、この要件は、ローカルの情報を輸送するのに正常なシグナリングプロセスと交換処理を使用します。 例えば、ドメインへの入り口では、ドメイン特殊情報は付記された情報(このドメインだけで使用される)が加えられて、一方、シグナリングメッセージがいつドメインを出るかという情報が取り除かれるということです。 様々な情報片のドメインの内部のシグナリングにプロトコルを再使用する経済には動機があります。 追加情報が特定のドメインの中で必要であるところでは、終わりから終わりへの情報と同時にこれを運ぶのは可能であるべきです。
5.4.3. State MUST be Addressed Independent of Flow Identification
5.4.3. 状態はFlow IdentificationのAddressed無党派であるに違いありません。
Addressing or identifying state MUST be independent of the flow identifier (flow end-points, topological addresses). Various scenarios in the mobility area require this independence because flows resulting from handoff might have changed end-points etc. but still have the same service requirement. Also several proxy-based signaling methods profit from such independence, though these are not chartered work items for NSIS.
状態を演説するか、または特定するのが流れ識別子(流れエンドポイント、位相的なアドレス)から独立しているに違いありません。 移動性領域の様々なシナリオには、移管から生じる流れがエンドポイントなどを変えたかもしれないのでこの独立を必要としますが、同じサービス要件がまだあります。 これらはNSISにおける貸し切りの仕事項目ではありませんが、いくつかのプロキシベースのシグナリングメソッドもそのような独立から利益を得ます。
5.4.4. Modification of Already Established State SHOULD be Seamless
5.4.4. 変更、Already Established州SHOULDでは、Seamlessになってください。
In many case, the established state needs to be updated (in QoS example upgrade or downgrade of resource usage). This SHOULD happen seamlessly without service interruption. At least the signaling protocol should allow for it, even if some data path elements might not be capable of doing so.
多くの場合では、設立された州は、アップデートする(リソース用法のQoS例のアップグレードかダウングレードで)必要があります。 このSHOULDは停電なしでシームレスに起こります。 少なくともシグナリングプロトコルはそれを考慮するべきです、いくつかのデータ経路要素がそうすることができないかもしれなくても。
Brunner Informational [Page 16] RFC 3726 Requirements for Signaling Protocols April 2004
プロトコル2004年4月に合図するためのブルンナー情報[16ページ]のRFC3726Requirements
5.4.5. Grouping of Signaling for Several Micro-Flows MAY be Provided
5.4.5. Several Micro-流れのためのSignalingの組分けはProvidedであるかもしれません。
NSIS MAY group signaling information for several micro-flows into one signaling message. The goal of this is the optimization in terms of setup delay, which can happen in parallel. This helps applications requesting several flows at once. Also potential refreshes (in case of a soft state solution) might profit from grouping.
NSIS MAYは1つのシグナリングメッセージへの数回のマイクロ流れのためにシグナリング情報を分類します。 この目標はセットアップ遅れに関する最適化です。(それは、平行で起こることができます)。 これは、アプリケーションがすぐに数個の流れを要求するのを助けます。 また、可能性は組分けから力の利益をリフレッシュします(軟性国家ソリューションの場合に)。
However, the network need not know that a relationship between the grouped flows exists. There MUST NOT be any transactional semantic associated with the grouping. It is only meant for optimization purposes.
しかしながら、ネットワークは、分類された流れの間の関係が存在するのを知る必要はありません。 いずれか取引であったならそこでそうしてはいけない、意味、組分けに関連しています。 それは最適化目的のために意味されるだけです。
5.5. Performance
5.5. パフォーマンス
This section discusses performance requirements and evaluation criteria and the way in which these could and should be traded off against each other in various parts of the solution.
このセクションはこれらが交換できて、ソリューションの様々な部分で互いに対して交換されるべきである性能要件、評価基準、および方法を論じます。
Scalability is always an important requirement for signaling protocols. However, the type of scalability and its importance varies from one scenario to another.
いつもスケーラビリティはシグナリングプロトコルのための重要な要件です。 しかしながら、スケーラビリティのタイプとその重要性は1つのシナリオから別のものに異なります。
Note that many of the performance issues are heavily dependent on the scenario assumed and are normally a trade-off between speed, reliability, complexity, and scalability. The trade-off varies in different parts of the network. For example, in radio access networks low bandwidth consumption will outweigh the low latency requirement, while in core networks it may be reverse.
性能問題の多くがずっしりと想定されたシナリオに依存していて、通常、速度と、信頼性と、複雑さと、スケーラビリティの間のトレードオフであることに注意してください。 トレードオフはネットワークの異なった部分で異なります。 例えば、ラジオアクセスネットワークでは、低い帯域幅消費は低遅延要件より重いでしょう、コアネットワークにおいて、それが逆であるかもしれませんが。
5.5.1. Scalability
5.5.1. スケーラビリティ
NSIS MUST be scalable in the number of messages received by a signaling communication partner (NSIS Initiator, NSIS Forwarder, and NSIS Responder). The major concern lies in the core of the network, where large numbers of messages arrive.
NSIS MUST、シグナリングコミュニケーションパートナー(NSIS Initiator、NSIS Forwarder、およびNSIS Responder)によって受け取られたメッセージの数では、スケーラブルであってください。 主要な関心事がネットワークのコアにあります。(そこでは、多くのメッセージが到着します)。
It MUST be scalable in number of hand-offs in mobile environments. This mainly applies in access networks, because the core is transparent to mobility in most cases.
それはモバイル環境における、手-offsの数でスケーラブルであるに違いありません。 コアが多くの場合移動性に透明であるので、これはアクセスネットワークで主に適用されます。
It MUST be scalable in the number of interactions for setting up state. This applies for end-systems setting up several states. Some servers might be expected to setup a large number of states.
状態を設立するのに、それは相互作用の数でスケーラブルであるに違いありません。 これは、いくつかの州を設立しながら、エンドシステムに申し込みます。 いくつかのサーバが多くの州をセットアップすると予想されるかもしれません。
Scalability in the amount of state per entity MUST be achieved for NSIS Forwarders in the core of the network.
ネットワークのコアのNSIS Forwardersのために1実体あたりの状態の量におけるスケーラビリティを達成しなければなりません。
Brunner Informational [Page 17] RFC 3726 Requirements for Signaling Protocols April 2004
プロトコル2004年4月に合図するためのブルンナー情報[17ページ]のRFC3726Requirements
Scalability in CPU usage MUST be achieved on end terminals and intermediate nodes in case of many state setup processes at the same time.
同時に、多くの州のセットアッププロセスの場合に端の端末と中間的ノードでCPU用法によるスケーラビリティを達成しなければなりません。
Specifically, NSIS MUST work in Internet scale deployments, where the use of signaling by hosts becomes universal. Note that requirement 5.2.4 requires the functionality of transparently signaling through networks without interpretation. Additionally, requirement 5.6.1 lists the capability to aggregate. Furthermore, requirement 5.5.4 states that NSIS should be able to constrain the load on devices. Basically, the performance of the signaling MUST degrade gracefully rather than catastrophically under overload conditions.
明確に、ホストで合図することの使用が普遍的になるところでNSIS MUSTはインターネットスケール展開で働いています。 要件5.2.4がネットワークを通して解釈なしで透過的に合図する機能性を必要とすることに注意してください。 さらに、要件5.6.1は集める能力を記載します。 その上、要件5.5.4は、NSISがデバイスで負荷を抑制するはずであることができると述べます。 基本的に、シグナリングの性能は過負荷条件の下で不運であるというよりむしろ優雅に下がらなければなりません。
5.5.2. NSIS SHOULD Allow for Low Latency in Setup
5.5.2. NSISはセットアップで低遅延を考慮するはずです。
NSIS SHOULD allow for low latency setup of states. This is only needed in scenarios where state setups are required on a short time scale (e.g., handover in mobile environments), or where human interaction is immediately concerned (e.g., voice communication setup delay).
NSIS SHOULDは州の低遅延セットアップを考慮します。 これが州のセットアップが短いタイムスケール(例えば、モバイル環境における引き渡し)で必要である、または人間の交流がすぐに関するシナリオ(例えば、声のコミュニケーションセットアップ遅れ)で必要であるだけです。
5.5.3. NSIS MUST Allow for Low Bandwidth Consumption for the Signaling
Protocol
5.5.3. NSISはシグナリングプロトコルのための低い帯域幅消費を考慮しなければなりません。
NSIS MUST allow for low bandwidth consumption in certain access networks. Again only small sets of scenarios call for low bandwidth, mainly those where wireless links are involved.
NSIS MUSTはあるアクセスネットワークで低い帯域幅消費を考慮します。 一方、小さいセットのシナリオだけが低い帯域幅、主にワイヤレスのリンクがかかわるところのそれらを求めます。
5.5.4. NSIS SHOULD Allow to Constrain Load on Devices
5.5.4. NSISはデバイスで負荷を抑制させるべきです。
The NSIS architecture SHOULD give the ability to constrain the load (CPU load, memory space, signaling bandwidth consumption and signaling intensity) on devices where it is needed. One of the reasons is that the protocol handling should have a minimal impact on interior (core) nodes.
NSISアーキテクチャSHOULDはそれが必要であるデバイスで負荷(CPU荷重、メモリスペース、シグナリング帯域幅消費、およびシグナリング強度)を抑制する能力を与えます。 理由の1つはプロトコル取り扱いが内部の(コア)ノードの上に最小量の影響力を持つべきであるということです。
This can be achieved by many different methods. Examples include message aggregation, header compression, minimizing functionality, or ignoring signaling in core nodes. NSIS may choose any method as long as the requirement is met.
多くの異なったメソッドでこれを達成できます。 コアノードで機能性を最小にするか、またはシグナリングを無視して、例はメッセージ集合、ヘッダー圧縮を含んでいます。 必要条件が満たされる限り、NSISはどんなメソッドも選ぶかもしれません。
5.5.5. NSIS SHOULD Target the Highest Possible Network Utilization
5.5.5. NSISは可能な限り高いネットワーク利用を狙うはずです。
This requirement applies specifically to QoS signaling.
この要件は特にQoSシグナリングに適用されます。
Brunner Informational [Page 18] RFC 3726 Requirements for Signaling Protocols April 2004
プロトコル2004年4月に合図するためのブルンナー情報[18ページ]のRFC3726Requirements
There are networking environments that require high network utilization for various reasons, and the signaling protocol SHOULD to its best ability support high resource utilization while maintaining appropriate service quality.
様々な理由で高いネットワーク利用を必要とするネットワーク環境があります、そして、最も良い性能へのシグナリングプロトコルSHOULDは適切なサービス品質を維持している間、高いリソース利用をサポートします。
In networks where resources are very expensive (as is the case for many wireless networks), efficient network utilization for signaling traffic is of critical financial importance. On the other hand there are other parts of the network where high utilization is not required.
リソースが非常に高価である(多くのワイヤレス・ネットワークのためにそうであるように)ネットワークでは、シグナリングトラフィックのための効率的なネットワーク利用は財政的に重要に重要です。 他方では、ネットワークの他の部分が高使用率は必要でないところにあります。
5.6. Flexibility
5.6. 柔軟性
This section lists the various ways the protocol can flexibly be employed.
このセクションは柔軟にプロトコルを使うことができる様々な方法を記載します。
5.6.1. Flow Aggregation
5.6.1. 流れ集合
NSIS MUST allow for flow aggregation, including the capability to select and change the level of aggregation.
集合のレベルを選択して、変える能力を含んでいて、NSIS MUSTは流れ集合を考慮します。
5.6.2. Flexibility in the Placement of the NSIS Initiator/Responder
5.6.2. NSIS創始者/応答者のプレースメントにおける柔軟性
NSIS MUST be flexible in placing an NSIS Initiator and NSIS Responder. The NSIS Initiator might be located at the sending or the receiving side of a data stream, and the NSIS Responder naturally on the other side.
NSIS MUST、NSIS InitiatorとNSIS Responderを置くのにおいて、フレキシブルであってください。 NSIS Initiatorはデータ・ストリームの送付か受信側面、およびNSIS Responderに自然に反対側に位置するかもしれません。
Also network-initiated signaling and termination MUST be allowed in various scenarios such as PSTN gateways, some VPNs, and mobility. This means the NSIS Initiator and NSIS Responder might not be at the end points of the data stream.
PSTNゲートウェイや、いくつかのVPNsや、移動性などの様々なシナリオでネットワークによって開始されたもシグナリングと終了を許さなければなりません。 これは、データ・ストリームのエンドポイントにはNSIS InitiatorとNSIS Responderがないかもしれないことを意味します。
5.6.3. Flexibility in the Initiation of State Change
5.6.3. 州の変化の開始における柔軟性
The NSIS Initiator or the NSIS Responder SHOULD be able to initiate a change of state. In the example of resource reservation this is often referred to as resource re-negotiation. It can happen due to various reasons, such as local resource shortage (CPU, memory on end-system) or a user changed application preference/profiles.
NSIS InitiatorかNSIS Responder SHOULD、状態の変化を起こすことができてください。 資源予約に関する例では、これはしばしばリソース再交渉と呼ばれます。 それは様々な理由のため起こることができて、そのような同じくらい地元のリソース不足(CPU、エンドシステムに関するメモリ)かユーザがアプリケーション好み/プロフィールを変えました。
5.6.4. SHOULD Support Network-Initiated State Change
5.6.4. サポートのネットワークによって開始された状態は変化するべきですか?
NSIS SHOULD support network-initiated state change. In the QoS example, this is used in cases, where the network is not able to further guarantee resources and wants to e.g., downgrade a resource reservation.
NSIS SHOULDは、ネットワークによって開始された状態が変化であるとサポートします。 QoSの例では、これは、場合に使用されて、例えば、ダウングレードに資源予約を必要とします。(そこでは、ネットワークが保証リソースを促進できません)。
Brunner Informational [Page 19] RFC 3726 Requirements for Signaling Protocols April 2004
プロトコル2004年4月に合図するためのブルンナー情報[19ページ]のRFC3726Requirements
5.6.5. Uni / Bi-Directional State Setup
5.6.5. Uni/双方向の州のセットアップ
Both unidirectional as well as bi-direction state setup SHOULD be possible. With bi-directional state setup we mean that the state for bi-directional data flows is setup. The bi-directional data flows have the same end-points, but the path in the two directions does not need to be the same.
単方向、二方向の両方が、セットアップSHOULDが可能であると述べます。 双方向の州のセットアップで、私たちは、双方向のデータフローのための状態がセットアップであると言っています。 双方向のデータフローには、同じエンドポイントがありますが、2つの方向への経路は同じである必要はありません。
The goal of a bi-directional state setup is mainly an optimization in terms of setup delay. There is no requirements on constrains such as use of the same data path etc.
双方向の州のセットアップの目標は主にセットアップ遅れに関する最適化です。 どんなオンである要件もない、同じデータ経路の使用などのように、などを抑制します。
5.7. Security
5.7. セキュリティ
This section discusses security-related requirements. The NSIS protocol MUST provide means for security, but it MUST be allowed that nodes implementing NSIS signaling do not have to use the security means.
このセクションはセキュリティ関連の要件について論じます。 NSISプロトコルは手段をセキュリティに提供しなければなりませんが、NSISがシグナリングであると実装するノードがセキュリティ手段を使用する必要はないのを許容しなければなりません。
5.7.1. Authentication of Signaling Requests
5.7.1. シグナリング要求の認証
A signaling protocol MUST make provision for enabling various entities to be authenticated against each other using strong authentication mechanisms. The term strong authentication points to the fact that weak plain-text password mechanisms must not be used for authentication.
シグナリングプロトコルは様々な実体が互いに対して認証されるのを強い認証機構を使用することで可能にすることへの設備をしなければなりません。用語の強い認証は認証に弱いプレーンテキストパスワードメカニズムを使用してはいけないという事実を示します。
5.7.2. Request Authorization
5.7.2. 承認を要求してください。
The signaling protocol MUST provide means to authorize state setup requests. This requirement demands a hook to interact with a policy entity to request authorization data. This allows an authenticated entity to be associated with authorization data and to verify the request. Authorization prevents state setup by unauthorized entities, setups violating policies, and theft of service. Additionally it limits denial of service attacks against parts of the network or the entire network caused by unrestricted state setups. Additionally it might be helpful to provide some means to inform other protocols of participating nodes within the same administrative domain about a previous successful authorization event.
シグナリングプロトコルは州のセットアップ要求を認可する手段を提供しなければなりません。 この要件は、承認データを要求するために方針実体と対話するためにフックを要求します。 これで、認証された実体は、承認データに関連していて、要求について確かめます。 承認はサービスの権限のない実体、方針に違反するセットアップ、および窃盗で州のセットアップを防ぎます。 さらに、それは無制限な州のセットアップで引き起こされたネットワークか全体のネットワークの部分に対してサービス不能攻撃を制限します。 さらに、同じ管理ドメインの中で前のうまくいっている承認イベントに関して参加ノードの他のプロトコルを知らせるいくつかの手段を提供するのは役立っているかもしれません。
5.7.3. Integrity Protection
5.7.3. 保全保護
The signaling protocol MUST provide means to protect the message payloads against modifications. Integrity protection prevents an adversary from modifying parts of the signaling message and from mounting denial of service or theft of service type of attacks against network elements participating in the protocol execution.
シグナリングプロトコルは変更に対してメッセージペイロードを保護する手段を提供しなければなりません。 保全保護によって、敵は、シグナリングメッセージの部分を変更して、ネットワーク要素に対する上がっているサービスの否定か攻撃のサービスタイプの窃盗からプロトコル実行に参加できません。
Brunner Informational [Page 20] RFC 3726 Requirements for Signaling Protocols April 2004
プロトコル2004年4月に合図するためのブルンナー情報[20ページ]のRFC3726Requirements
5.7.4. Replay Protection
5.7.4. 反復操作による保護
To prevent replay of previous signaling messages the signaling protocol MUST provide means to detect old i.e., already transmitted signaling messages. A solution must cover issues of synchronization problems in the case of a restart or a crash of a participating network element.
前のシグナリングメッセージの再生を防ぐために、シグナリングプロトコルは古い状態で検出する手段を提供しなければなりません、すなわち、シグナリングメッセージが既に、送られました。 ソリューションは再開の場合か参加しているネットワーク要素のクラッシュにおける同期問題の問題をカバーしなければなりません。
5.7.5. Hop-by-Hop Security
5.7.5. ホップごとのセキュリティ
Channel security between signaling entities MUST be implemented. It is a well known and proven concept in Quality of Service and other signaling protocols to have intermediate nodes that actively participate in the protocol to modify the messages as it is required by processing rules. Note that this requirement does not exclude end-to-end or network-to-network security of a signaling message. End-to-end security between the NSIS Initiator and the NSIS Responder may be used to provide protection of non-mutable data fields. Network-to-network security refers to the protection of messages over various hops but not in an end-to-end manner i.e., protected over a particular network.
シグナリング実体の間のチャンネルセキュリティを実装しなければなりません。 それが処理規則によって必要とされるようにメッセージを変更するために活発にプロトコルに参加する中間的ノードを持つのは、ServiceのQualityのよく知られていて立証された概念と他のシグナリングプロトコルです。 この要件がネットワークから終わりから終わりかネットワークへのシグナリングメッセージのセキュリティを除かないことに注意してください。 NSIS InitiatorとNSIS Responderの間の終わりから終わりへのセキュリティは、非可変データ分野の保護を提供するのに使用されるかもしれません。 ネットワークからネットワークへのセキュリティは、すなわち、特定のネットワークの上に保護されていた状態で様々なホップの上のメッセージの保護について言及しますが、終わりから終わりへの方法で言及するというわけではありません。
5.7.6. Identity Confidentiality and Network Topology Hiding
5.7.6. アイデンティティ秘密性とネットワーク形態隠れること
Identity confidentiality SHOULD be supported. It enables privacy and avoids profiling of entities by adversary eavesdropping the signaling traffic along the path. The identity used in the process of authentication may also be hidden to a limited extent from a network to which the initiator is attached. However the identity MUST provide enough information for the nodes in the access network to collect accounting data.
アイデンティティ秘密性SHOULD、サポートされてください。 それは、経路に沿ってシグナリングトラフィックを盗み聞いている敵で、プライバシーを可能にして、実体が輪郭を描くのを避けます。 また、創始者が付けているネットワーク限られた程度で認証の途中に使用されるアイデンティティを隠されるかもしれません。 しかしながら、アイデンティティはアクセスネットワークにおけるノードが会計データを集めることができるくらいの情報を提供しなければなりません。
Network topology hiding MAY be supported to prevent entities along the path to learn the topology of a network. Supporting this property might conflict with a diagnostic capability.
ネットワーク形態隠れることは、ネットワークのトポロジーを学ぶために経路に沿って実体を防ぐためにサポートされるかもしれません。 この特性を支えると、診断能力は衝突するかもしれません。
5.7.7. Denial-of-Service Attacks
5.7.7. サービス不能攻撃
A signaling protocol SHOULD provide prevention of Denial-of-service attacks. To effectively prevent denial-of-service attacks it is necessary that the used security and protocol mechanisms MUST have low computational complexity to verify a state setup request prior to authenticating the requesting entity. Additionally the signaling protocol and the used security mechanisms SHOULD NOT require large resource consumption on NSIS Entities (for example main memory or other additional message exchanges) before a successful authentication is done.
SHOULDがサービスのDenialの防止を提供するシグナリングプロトコルは攻撃されます。 事実上、サービス不能攻撃を防ぐために、要求実体を認証する前に州のセットアップ要求について確かめるのが中古のセキュリティとプロトコルメカニズムには低い計算量がなければならないのが必要です。 さらに、うまくいっている認証が完了している前にシグナリングプロトコルと中古のセキュリティー対策SHOULD NOTはNSIS Entities(例えば主記憶装置か他の追加交換処理)で大きいリソース消費を必要とします。
Brunner Informational [Page 21] RFC 3726 Requirements for Signaling Protocols April 2004
プロトコル2004年4月に合図するためのブルンナー情報[21ページ]のRFC3726Requirements
5.7.8. Confidentiality of Signaling Messages
5.7.8. シグナリングメッセージの秘密性
Based on the signaling information exchanged between nodes participating in the signaling protocol an adversary may learn both the identities and the content of the signaling messages. Since the ability to listen to signaling channels is a major guide to what data channels are interesting ones.
シグナリングプロトコルに参加しながらノードの間で交換されたシグナリング情報に基づいて、敵は両方のアイデンティティとシグナリングメッセージの内容を学ぶかもしれません。 以来、シグナリングチャンネルの言うことを聞く能力はどんなデータ・チャンネルがおもしろいものであるかへの一流のガイドです。
To prevent this from happening, confidentiality of the signaling message in a hop-by-hop manner SHOULD be provided. Note that most messages must be protected on a hop-by-hop basis, since entities, which actively participate in the signaling protocol, must be able to read and eventually modify the signaling messages.
出来事、ホップごとの方法SHOULDによるシグナリングメッセージの秘密性からこれを防ぐには、提供してください。 ホップごとのベースでほとんどのメッセージを保護しなければならないことに注意してください、実体(活発にシグナリングプロトコルに参加する)が読んで、結局シグナリングメッセージを変更できなければならないので。
5.7.9. Ownership of State
5.7.9. 状態の所有権
When existing states have to be modified then there is a need to use a session identifier to uniquely identify the established state. A signaling protocol MUST provide means of security protection to prevent adversaries from modifying state.
現状がその時変更されなければならないとき、唯一設立された状態を特定するのにセッション識別子を使用する必要があります。 シグナリングプロトコルは敵が機密保持によって状態を変更できない手段を提供しなければなりません。
5.8. Mobility
5.8. 移動性
5.8.1. Allow Efficient Service Re-Establishment After Handover
5.8.1. 引き渡しの後に効率的なサービス再建を許容してください。
Handover is an essential function in wireless networks. After handover, the states may need to be completely or partially re- established due to route changes. The re-establishment may be requested by the mobile node itself or triggered by the access point that the mobile node is attached to. In the first case, the signaling MUST allow efficient re-establishment after handover. Re- establishment after handover MUST be as quick as possible so that the mobile node does not experience service interruption or service degradation. The re-establishment SHOULD be localized, and not require end-to-end signaling.
引き渡しはワイヤレス・ネットワークで不可欠の機能です。 引き渡しの後に、州は、ルート変化のため完全か部分的に再設立される必要があるかもしれません。 再建は、モバイルノード自体によって要求されるか、またはモバイルノードが添付されるアクセスポイントによって引き起こされるかもしれません。 前者の場合、シグナリングは引き渡しの後に効率的な再建を許容しなければなりません。引き渡しの後の再設立ができるだけ迅速でなければならないので、モバイルノードは停電かサービス退行になりません。 再建SHOULDはローカライズされて、終わりから終わりへのシグナリングを必要としません。
5.9. Interworking with Other Protocols and Techniques
5.9. 他のプロトコルとテクニックとの織り込むこと
Hooks SHOULD be provided to enable efficient interworking between various protocols and techniques including the following listed.
フックスSHOULD、様々なプロトコルと以下を含むテクニックの間の効率的な織り込むことを可能にするのが記載したかどうかということになってください。
5.9.1. MUST Interwork with IP Tunneling
5.9.1. 必須はIPと共にトンネリングを織り込みます。
IP tunneling for various applications MUST be supported. More specifically IPSec tunnels are of importance. This mainly impacts the identification of flows. When using IPSec, parts of information commonly used for flow identification (e.g., transport protocol information and ports) may not be accessible due to encryption.
様々なアプリケーションのためにトンネルを堀るIPをサポートしなければなりません。 より明確にIPSecトンネルは重要です。 これは流れの識別に主に影響を与えます。 IPSecを使用するとき、暗号化のために、流れ識別(例えば、輸送プロトコル情報とポート)に一般的に使用される情報の部分はアクセスしやすくないかもしれません。
Brunner Informational [Page 22] RFC 3726 Requirements for Signaling Protocols April 2004
プロトコル2004年4月に合図するためのブルンナー情報[22ページ]のRFC3726Requirements
5.9.2. MUST NOT Constrain Either to IPv4 or IPv6
5.9.2. 必須はIPv4かIPv6にどちらも抑制しません。
5.9.3. MUST be Independent from Charging Model
5.9.3. Charging Modelからの無党派でなければなりません。
Signaling MUST NOT be constrained by charging models or the charging infrastructure used.
モデルか充電インフラストラクチャが使用したと宣言することによって、シグナリングを抑制してはいけません。
5.9.4. SHOULD Provide Hooks for AAA Protocols
5.9.4. AAAプロトコルにフックを提供するべきです。
The NSIS protocol SHOULD be developed with respect to be able to collect usage records from one or more network elements.
開発されてください。NSISがSHOULDについて議定書の中で述べる、1つ以上のネットワーク要素で用法記録を集めることができてください。
5.9.5. SHOULD Work with Seamless Handoff Protocols
5.9.5. シームレスの移管プロトコルで働くべきです。
An NSIS protocol SHOULD work with seamless handoff protocols such as context transfer and candidate access router (CAR) discovery.
NSISは文脈転送と候補アクセスルータ(CAR)発見などのシームレスの移管プロトコルでSHOULD仕事について議定書の中で述べます。
5.9.6. MUST Work with Traditional Routing
5.9.6. 伝統的であるとの仕事が掘られて、そうしなければなりません。
NSIS assumes traditional L3 routing, which is purely based on L3 destination addresses. NSIS MUST work with L3 routing, in particular it MUST work in case of route changes. This means state on the old route MUST be released and state on the new route MUST be established by an NSIS protocol.
NSISは、伝統的なL3がルーティングであると仮定します。(純粋に、それは、L3送付先アドレスに基づいています)。 NSIS MUSTはL3ルーティングで働いていて、特に、それはルート変化の場合に働かなければなりません。 これは、古いルートの状態をリリースしなければならなくて、NSISプロトコルで新しいルートの状態を設置しなければならないことを意味します。
Networks, which do non-traditional routing, should not break NSIS signaling. NSIS MAY work for some of these situations. Particularly, combinations of NSIS unaware nodes and routing other then traditional one causes some problems. Non-traditional routing includes, for example, routing decisions based on port numbers, other IP header fields than the destination address, or splitting traffic based on header hash values. These routing environments result in the signaling path being potentially different than the data path.
ネットワーク(非伝統的なルーティングをする)はNSISシグナリングを壊すべきではありません。 NSIS MAYはこれらの状況のいくつかのために働いています。 特に、NSISの気づかないノードと例えば決定を発送することにおける. 非伝統的なルーティングが含むいくつかの問題がポートナンバー、送付先アドレス以外のIPヘッダーフィールド、またはトラフィックを分けるのに基礎づけた他の当時の伝統的な1つの原因を発送する組み合わせはハッシュ値をヘッダーに基礎づけました。 これらのルーティング環境はデータ経路と潜在的に異なったシグナリング経路をもたらします。
5.10. Operational
5.10. 操作上
5.10.1. Ability to Assign Transport Quality to Signaling Messages
5.10.1. 輸送品質をシグナリングメッセージに割り当てる能力
The NSIS architecture SHOULD allow the network operator to assign the NSIS protocol messages a certain transport quality. As signaling opens up the possibility of denial-of-service attacks, this requirement gives the network operator a means, but also the obligation, to trade-off between signaling latency and the impact (from the signaling messages) on devices within the network. From protocol design this requirement states that the protocol messages SHOULD be detectable, at least where the control and assignment of the messages priority is done.
NSISアーキテクチャSHOULDはネットワーク・オペレータに、ある輸送品質をNSISプロトコルメッセージに割り当てさせます。 シグナリングがサービス不能攻撃では、この要件が手段をネットワーク・オペレータに与える可能性、しかし、義務も開けるネットワークの中でデバイスで潜在と影響(シグナリングメッセージからの)に合図することの間のトレードオフに。 プロトコルデザインから、この要件は、プロトコルメッセージSHOULDが少なくともメッセージ優先権のコントロールと課題が行われるところで検出可能であると述べます。
Brunner Informational [Page 23] RFC 3726 Requirements for Signaling Protocols April 2004
プロトコル2004年4月に合図するためのブルンナー情報[23ページ]のRFC3726Requirements
Furthermore, the protocol design must take into account reliability concerns. Communication reliability is seen as part of the quality assigned to signaling messages. So procedures MUST be defined for how an NSIS signaling system behaves if some kind of request it sent stays unanswered. The basic transport protocol to be used between adjacent NSIS Entities MAY ensure message integrity and reliable transport.
その上、プロトコルデザインは信頼性の関心を考慮に入れなければなりません。 品質の一部がメッセージをシグナリングに割り当てたので、コミュニケーションの信頼性は見られます。 それで、それが送ったある種の要求が答えがない状態で残っているならNSISシグナリングシステムがどう反応するように手順を定義しなければならないか。 隣接しているNSIS Entitiesの間で使用されるべき基本的なトランスポート・プロトコルはメッセージの保全と信頼できる輸送を確実にするかもしれません。
5.10.2. Graceful Fail Over
5.10.2. 優雅なフェイルオーバー
Any unit participating in NSIS signaling MUST NOT cause further damage to other systems involved in NSIS signaling when it has to go out of service.
NSISシグナリングに参加するどんなユニットも使われなくなるようにならなければならないとNSISシグナリングにかかわる他のシステムへのさらなる損傷をもたらしてはいけません。
5.10.3. Graceful Handling of NSIS Entity Problems
5.10.3. NSIS実体問題の優雅な取り扱い
NSIS entities SHOULD be able to detect a malfunctioning peer. It may notify the NSIS Initiator or another NSIS entity involved in the signaling process. The NSIS peer may handle the problem itself e.g., switching to a backup NSIS entity. In the latter case note that synchronization of state between the primary and the backup entity is needed.
NSIS実体SHOULD、誤動作している同輩を検出できてください。 それはシグナリングプロセスにかかわるNSIS Initiatorか別のNSIS実体に通知するかもしれません。 NSIS同輩は問題自体を扱うかもしれません、例えば、aに切り替わって、NSIS実体のバックアップをとってください。 後者の場合では、予備選挙とバックアップ実体の間の状態の同期が必要であることに注意してください。
6. Security Considerations
6. セキュリティ問題
Section 5.7 of this document provides security related requirements of a signaling protocol.
このドキュメントのセクション5.7はシグナリングプロトコルの関連する要件をセキュリティに提供します。
7. Acknowledgments
7. 承認
Quite a number of people have been involved in the discussion of the document, adding some ideas, requirements, etc. We list them without a guarantee on completeness: Changpeng Fan (Siemens), Krishna Paul (NEC), Maurizio Molina (NEC), Mirko Schramm (Siemens), Andreas Schrader (NEC), Hannes Hartenstein (NEC), Ralf Schmitz (NEC), Juergen Quittek (NEC), Morihisa Momona (NEC), Holger Karl (Technical University Berlin), Xiaoming Fu (Technical University Berlin), Hans- Peter Schwefel (Siemens), Mathias Rautenberg (Siemens), Christoph Niedermeier (Siemens), Andreas Kassler (University of Ulm), Ilya Freytsis.
いくつかの考え、要件などを加えて、かなりの数の人々がドキュメントの議論にかかわりました。 私たちは保証なしで完全性にそれらを記載します: Changpengは(シーメンス)を扇ぎます、クリシュナ・ポール(NEC)、マウリジオモリーナ(NEC)、ミルコ・シュラム(シーメンス)、アンドレアスシュレーダー(NEC)、ハンネス・ハルテンシュタイン(NEC)、ラルフ・シュミッツ(NEC)、ユルゲンQuittek(NEC)、Morihisa Momona(NEC)、オルガー・カール(技術的な大学ベルリン)、ハンスピーターSchwefel(シーメンス)、Xiaomingフー(技術的な大学ベルリン)、マティアスRautenberg(シーメンス)、クリストフNiedermeier(シーメンス)、アンドレアスKassler(ウルム大学)、イリヤFreytsis。
Some text and/or ideas for text, requirements, scenarios have been taken from an Internet Draft written by the following authors: David Partain (Ericsson), Anders Bergsten (Telia Research), Marc Greis (Nokia), Georgios Karagiannis (Ericsson), Jukka Manner (University of Helsinki), Ping Pan (Juniper), Vlora Rexhepi (Ericsson), Lars Westberg (Ericsson), Haihong Zheng (Nokia). Some of those have actively contributed new text to this document as well.
以下の作者によって書かれたインターネットDraftから何らかのテキスト、そして/または、テキストのための考え、要件、シナリオを取りました: デヴィッド・パーテイン(エリクソン)、アンダースBergsten(冬胞子堆研究)(マークGreis(ノキア)、イェオールイオスKaragiannis(エリクソン)ユッカManner(ヘルシンキ大学))はなべ(杜松)を確認します、ヴロレRexhepi(エリクソン)、ラース・ウェストバーグ(エリクソン)、Haihongツェン(ノキア)。 それらのいくつかが活発にまた、このドキュメントに新しいテキストを寄付しました。
Brunner Informational [Page 24] RFC 3726 Requirements for Signaling Protocols April 2004
プロトコル2004年4月に合図するためのブルンナー情報[24ページ]のRFC3726Requirements
Another Internet Draft impacting this document has been written by Sven Van den Bosch, Maarten Buchli, and Danny Goderis (all Alcatel). These people contributed also new text.
このドキュメントに影響を与える別のインターネットDraftがスベン・バンデンボッシュ、Maarten Buchli、およびダニーGoderis(すべてのアルカテル)によって書かれています。 また、これらの人々は新しいテキストを寄付しました。
Thanks also to Kwok Ho Chan (Nortel) for text changes. And finally thanks Alison Mankin for the thorough AD review and thanks to Harald Tveit Alvestrand and Steve Bellovin for the IESG review comments.
ありがとうございます、そして、また、クォックHoに、テキストのためのチェン(ノーテル)は変化します。 そして、最終的に、徹底的なADレビューとハラルドTveit AlvestrandとスティーブBellovinのおかげでIESGレビューコメントのためのアリソン・マンキンは感謝します。
Brunner Informational [Page 25] RFC 3726 Requirements for Signaling Protocols April 2004
プロトコル2004年4月に合図するためのブルンナー情報[25ページ]のRFC3726Requirements
8. Appendix: Scenarios/Use Cases
8. 付録: シナリオ/はケースを使用します。
In the following we describe scenarios, which are important to cover, and which allow us to discuss various requirements. Some regard this as use cases to be covered defining the use of a signaling protocol. In general, these scenarios consider the specific case of signaling for QoS (resource reservation), although many of the issues carry over directly to other signaling types.
以下では、私たちはシナリオについて説明します。(シナリオは、カバーするために重要であり、私たちが様々な要件について議論するのを許容します)。 シグナリングプロトコルの使用を定義しながらカバーされているのにケースを使用するとき、或るものはこれを見なします。 これらのシナリオは、QoS(資源予約)のために合図する特定のケースであると問題の多くですが、一般に、直接他のシグナリングタイプに及ぶように考えます。
8.1. Terminal Mobility
8.1. 端末の移動性
The scenario we are looking at is the case where a mobile terminal (MT) changes from one access point to another access point. The access points are located in separate QoS domains. We assume Mobile IP to handle mobility on the network layer in this scenario and consider the various extensions (i.e., IETF proposals) to Mobile IP, in order to provide 'fast handover' for roaming Mobile Terminals. The goal to be achieved lies in providing, keeping, and adapting the requested QoS for the ongoing IP sessions in case of handover. Furthermore, the negotiation of QoS parameters with the new domain via the old connection might be needed, in order to support the different 'fast handover' proposals within the IETF.
私たちが見ているシナリオは移動体端末(MT)が1つのアクセスポイントから別のアクセスポイントに変化するケースです。 アクセスポイントは別々のQoSドメインに位置しています。 私たちは、モバイルIPが、このシナリオのネットワーク層で移動性を扱って、様々な拡大が(すなわち、IETF提案)であるとモバイルIPと考えると思います、'速い引き渡し'をローミングのモバイルTerminalsに供給するために。 達成されるべき目標は提供で位置しています、引き渡しの場合に進行中のIPセッションのために要求されたQoSを保って、適合させて。その上、年取った接続を通した新しいドメインとのQoSパラメタの交渉が必要であるかもしれません、IETFの中で異なった'速い引き渡し'が提案であるとサポートするために。
The entities involved in this scenario include a mobile terminal, access points, an access network manager, and communication partners of the MT (the other end(s) of the communication association). From a technical point of view, terminal mobility means changing the access point of a mobile terminal (MT). However, technologies might change in various directions (access technology, QoS technology, administrative domain). If the access points are within one specific QoS technology (independent of access technology) we call this intra-QoS technology handoff. In the case of an inter-QoS technology handoff, one changes from e.g., a DiffServ to an IntServ domain, however still using the same access technology. Finally, if the access points are using different access technologies we call it inter-technology hand-off.
このシナリオにかかわる実体はMT(コミュニケーション協会の他の終わり)の移動体端末、アクセスポイント、アクセスネットワークマネージャ、およびコミュニケーションパートナーを含んでいます。 視点のテクニカルポイントから、端末の移動性は、移動体端末(MT)のアクセスポイントを変えることを意味します。 しかしながら、技術は様々な方向(アクセス技術、QoS技術、管理ドメイン)に変化するかもしれません。 1つの特定のQoS技術(アクセス技術の如何にかかわらず)の中にアクセスポイントがあるなら、私たちはこのイントラ-QoS技術移管を呼びます。 相互QoS技術移管の場合では、1つは例えば、DiffServからIntServドメインに変化します、しかしながら、まだ同じアクセス技術を使用していて。 最終的に、アクセスポイントが異なったアクセス技術を使用しているなら、私たちは、それを相互技術ハンドオフと呼びます。
The following issues are of special importance in this scenario:
以下の問題はこのシナリオで特別に重要です:
1) Handoff decision
1) 移管決定
- The QoS management requests handoff. The QoS management can
decide to change the access point, since the traffic conditions of
the new access point are better supporting the QoS requirements.
The metric may be different (optimized towards a single or a
group/class of users). Note that the MT or the network (see
below) might trigger the handoff.
- QoS経営者側は移管を要求します。 QoS経営者側は、アクセスポイントを変えると決めることができます、QoSが要件であるとサポートしながら新しいアクセスポイントの交通状況が、より良いので。 メートル法は異なっているかもしれません(ユーザのシングルかグループ/クラスに向かって最適化された)。 MTかネットワーク(以下を見る)が移管の引き金となるかもしれないことに注意してください。
Brunner Informational [Page 26] RFC 3726 Requirements for Signaling Protocols April 2004
プロトコル2004年4月に合図するためのブルンナー情報[26ページ]のRFC3726Requirements
- The mobility management forces handoff. This can have several
reasons. The operator optimizes his network, admission is no
longer granted (e.g., emptied prepaid condition). Or another
example is when the MT is reaching the focus of another base
station. However, this might be detected via measurements of QoS
on the physical layer and is therefore out of scope of QoS
signaling in IP. Note again that the MT or the network (see
below) might trigger the handoff.
- 移動性経営者側は移管を強制します。 これはいくつかの理由を持つことができます。 入場はもうオペレータが彼のネットワークを最適化すると承諾されません(例えば、前払いの状態を空にします)。 または、別の例はMTが別の基地局の焦点に達している時です。 しかしながら、これは、物理的な層のQoSの測定値で検出されるかもしれなくて、したがって、IPで合図するQoSの範囲の外にあります。 MTかネットワーク(以下を見る)が移管の引き金となるかもしれないことにもう一度注意してください。
- This scenario shows that local decisions might not be enough. The
rest of the path to the other end of the communication needs to be
considered as well. Hand-off decisions in a QoS domain do not
only depend on the local resource availability, e.g., the wireless
part, but involve the rest of the path as well. Additionally,
decomposition of an end-to-end signaling might be needed, in order
to change only parts of it.
- このシナリオは、ローカルの決定が十分でないかもしれないことを示します。 コミュニケーションのもう一方の端までの経路の残りは、また、考えられる必要があります。 QoSドメインでのハンドオフ決定はローカル資源の有用性、例えば、ワイヤレスの部分によるだけではなく、また、経路の残りを伴います。 さらに、終わりから終わりへのシグナリングの分解が、それの部品だけを変えるのに必要であるかもしれません。
2) Trigger sources
2) 引き金のソース
- Mobile terminal: If the end-system QoS management identifies
another (better-suited) access point, it will request the handoff
from the terminal itself. This will be especially likely in the
case that two different provider networks are involved. Another
important example is when the current access point bearer
disappears (e.g., removing the Ethernet cable). In this case, the
NSIS Initiator is basically located on the mobile terminal.
- 移動体端末: エンドシステムQoS経営者側が別の(適合するほうがよいです)アクセスポイントを特定すると、それは端末自体から移管を要求するでしょう。 2つの異なったプロバイダーネットワークがかかわって、これは特にありそうになるでしょう。 別の重要な例は現在のアクセスポイントの運搬人が姿を消す(例えば、イーサネットケーブルを取り除きます)時です。 この場合、NSIS Initiatorは移動体端末の上に基本的に位置しています。
- Network (access network manager): Sometimes, the handoff trigger
will be issued from the network management to optimize the overall
load situation. Most likely this will result in changing the
base-station of a single providers network. Most likely the NSIS
Initiator is located on a system within the network.
- (アクセスネットワークマネージャ)をネットワークでつないでください: 時々、移管引き金は、総合的な負荷状況を最適化するためにネットワークマネージメントから支給されるでしょう。 たぶん、これはただ一つのプロバイダーネットワークの基地局を変えるのに結果として生じるでしょう。 たぶん、NSIS Initiatorはネットワークの中にシステムに位置しています。
3) Integration with other protocols
3) 他のプロトコルによる統合
- Interworking with other protocol must be considered in one or the
other form. E.g., it might be worth combining QoS signaling
between different QoS domains with mobility signaling at hand-
over.
- 1かもう片方のフォームで他のプロトコルによる織り込むことを考えなければなりません。 例えば、手元の移動性シグナリングが終わっていた状態で異なったQoSドメインの間で合図するQoSを結合する価値があるかもしれません。
4) Handover rates
4) 引き渡し率
In mobile networks, the admission control process has to cope with far more admission requests than call setups alone would generate. For example, in the GSM (Global System for Mobile communications) case, mobility usually generates an average of one to two handovers
モバイルネットワークでは、入場コントロールプロセスは呼び出しセットアップだけが生成するだろうより遠くにさらに多くの入場要求を切り抜けなければなりません。 例えば、GSM(モバイルコミュニケーションのためのグローバルなSystem)場合では、通常、移動性は平均1〜2つの身柄の引き渡しを生成します。
Brunner Informational [Page 27] RFC 3726 Requirements for Signaling Protocols April 2004
プロトコル2004年4月に合図するためのブルンナー情報[27ページ]のRFC3726Requirements
per call. For third generation networks (such as UMTS), where it is necessary to keep radio links to several cells simultaneously (macro-diversity), the handover rate is significantly higher.
呼び出し単位で。 第三世代ネットワーク(UMTSなどの)には、引き渡し率はかなり高いです。そこでは、ラジオが同時のいくつかのセル(マクロ多様性)へのリンクであることを保つのが必要です。
5) Fast state installation
5) 速い州の施設
Handover can also cause packet losses. This happens when the processing of an admission request causes a delayed handover to the new base station. In this situation, some packets might be discarded, and the overall speech quality might be degraded significantly. Moreover, a delay in handover may cause degradation for other users. In the worst-case scenario, a delay in handover may cause the connection to be dropped if the handover occurred due to bad air link quality. Therefore, it is critical that QoS signaling in connection with handover be carried out very quickly.
また、引き渡しはパケット損失を引き起こす場合があります。 入場要求の処理が新しい基地局に遅れた引き渡しを引き起こすと、これは起こります。 この状況で、いくつかのパケットが捨てられるかもしれません、そして、総合的なスピーチ品質はかなり下げられるかもしれません。 そのうえ、引き渡しの遅れは他のユーザのために退行を引き起こすかもしれません。 下手をすると、引き渡しの遅れで、引き渡しが汚気リンク品質のため起こったなら、接続を下げるかもしれません。 したがって、引き渡しに関して合図するQoSが非常にすばやく行われるのは、重要です。
6) Call blocking in case of overload
6) オーバーロードの場合にブロッキングに電話をしてください。
Furthermore, when the network is overloaded, it is preferable to keep states for previously established flows while blocking new requests. Therefore, the resource reservation requests in connection with handover should be given higher priority than new requests for resource reservation.
ネットワークが積みすぎられるとき、その上、新しい要求を妨げている間の以前に確立した流れのために州を維持するのは望ましいです。 したがって、引き渡しに関する資源予約要求は優先するべきです資源予約を求める新しい要求より高い。
8.2. Wireless Networks
8.2. ワイヤレス・ネットワーク
In this scenario, the user is using the packet services of a wireless system (such as the 3rd generation wireless system 3GPP/UMTS, 3GPP2/cdma2000). The region between the End Host and the Edge Node (Edge Router) connecting the wireless network to another QoS domain is considered to be a single QoS domain.
このシナリオでは、ユーザはワイヤレスシステム(3番目の世代ワイヤレスシステム3GPP/UMTS、3GPP2/cdma2000などの)のパケットサービスを利用しています。 別のQoSドメインにワイヤレス・ネットワークを接続するEnd HostとEdge Node(縁のRouter)の間の領域はただ一つのQoSドメインであると考えられます。
The issues in such an environment regarding QoS include:
QoSに関するそのような環境における問題は:
1) The wireless networks provide their own QoS technology with
specialized parameters to coordinate the QoS provided by both the
radio access and wired access networks. Provisioning of QoS
technologies within a wireless network can be described mainly in
terms of calling bearer classes, service options, and service
instances. These QoS technologies need to be invoked with
suitable parameters when higher layers trigger a request for QoS.
Therefore these involve mapping of the requested higher layer QoS
parameters onto specific bearer classes or service instances. The
request for allocation of resources might be triggered by
signaling at the IP level that passes across the wireless system,
and possibly other QoS domains. Typically, wireless network
specific messages are invoked to setup the underlying bearer
1) ワイヤレス・ネットワークは、ラジオアクセスとワイヤードなアクセスネットワークの両方によって提供されたQoSを調整するためにそれら自身のQoS技術に専門化しているパラメタを提供します。 運搬人のクラス、サービスオプション、およびサービスを主にインスタンスと呼ぶことに関してワイヤレス・ネットワークの中のQoS技術の食糧を供給することについて説明できます。 これらのQoS技術は、より高い層がQoSを求める要求の引き金となるとき、適当なパラメタで呼び出される必要があります。 したがって、これらは、写像することを特定の運搬人のクラスかサービスインスタンスに要求されたより高い層のQoSパラメタを伴います。 リソースの配分を求める要求は、ワイヤレスシステムの向こう側に終わるIPレベルにおいてことによると他のQoSドメインに合図することによって、引き起こされるかもしれません。 通常、ワイヤレス・ネットワークの特定のメッセージは、基本的な運搬人をセットアップするために呼び出されます。
Brunner Informational [Page 28] RFC 3726 Requirements for Signaling Protocols April 2004
プロトコル2004年4月に合図するためのブルンナー情報[28ページ]のRFC3726Requirements
classes or service instances in parallel with the IP layer QoS
negotiation, to allocate resources within the radio access
network.
IPと平行したクラスかサービスインスタンスが、ラジオアクセスネットワークの中にリソースを割り当てるためにQoS交渉を層にします。
2) The IP signaling messages are initiated by the NSIS initiator and
interpreted by the NSIS Forwarder. The most efficient placement
of the NSIS Initiator and NSIS Forwarder has not been determined
in wireless networks, but a few potential scenarios can be
envisioned. The NSIS Initiator could be located at the End Host
(e.g., 3G User equipment (UE)), the Access Gateway or at a node
that is not directly on the data path, such as a Policy Decision
Function. The Access Gateway could act as a proxy NSIS Initiator
on behalf of the End Host. The Policy Decision Function that
controls per-flow/aggregate resources with respect to the session
within its QoS domain (e.g., the 3G wireless network) may act as a
proxy NSIS Initiator for the end host or the Access Gateway.
Depending on the placement of the NSIS Initiator, the NSIS
Forwarder may be located at an appropriate point in the wireless
network.
2) IPシグナリングメッセージは、NSIS創始者によって開始されて、NSIS Forwarderによって解釈されます。 NSIS InitiatorとNSIS Forwarderの最も効率的なプレースメントはワイヤレス・ネットワークでは決定していませんが、いくつかの潜在的シナリオを思い描くことができます。 NSIS InitiatorはEnd Host(例えば、3G User設備(UE))に位置できました、ゲートウェイか直接データ経路にないノードのAccess、Policy Decision Functionのように。 AccessゲートウェイはプロキシNSIS InitiatorとしてEnd Hostを代表して機能できました。 QoSドメイン(例えば、3Gワイヤレス・ネットワーク)の中でセッションに関して流れ/集合のリソースを制御するPolicy Decision Functionは終わりのホストかAccessゲートウェイのプロキシNSIS Initiatorとして機能するかもしれません。 NSIS Initiatorのプレースメントによって、NSIS Forwarderはワイヤレス・ネットワークで適切なポイントで位置するかもしれません。
3) The need for re-negotiation of resources in a new wireless domain
due to host mobility. In this case the NSIS Initiator and the
NSIS Forwarder should detect mobility events and autonomously
trigger re-negotiation of resources.
3) ホストの移動性による新しいワイヤレスのドメインでのリソースの再交渉の必要性。 この場合、NSIS InitiatorとNSIS Forwarderは移動性イベントを検出して、自主的にリソースの再交渉の引き金となるはずです。
8.3. An Example Scenario for 3G Wireless Networks
8.3. 3Gワイヤレス・ネットワークのための例のシナリオ
The following example is a pure hypothetical scenario, where an NSIS signaling protocol might be used in a 3G environment. We do not impose in any way, how a potential integration might be done. Terms from the 3GPP architecture are used (P-CSCF, IMS, expanded below) in order to give specificity, but in a hypothetical design, one that reflects neither development nor review by 3GPP. The example should help in the design of a NSIS signaling protocol such that it could be used in various environments.
以下の例は純粋な仮定しているシナリオです。(そこでは、NSISシグナリングプロトコルが3G環境で使用されるかもしれません)。 私たちはどんな道、どう潜在的統合をするかもしれないかでもでしゃばりません。 3GPPアーキテクチャからの用語は、特異性を与えるのに使用されますが(P-CSCF(IMS)は以下に広がりました)、仮定しているデザイン、どちらの開発も反映しないものにはあって、3GPPによって再検討されます。 例は、様々な環境でそれを使用できるようにNSISシグナリングプロトコルのデザインで助けるべきです。
The 3G wireless access scenario is shown in Figure 1. The Proxy-Call State Control Function (P-CSCF) is the outbound SIP proxy (only used in IP Multimedia Subsystems (IMS)). The Access Gateway is the egress router of the 3G wireless domain and it connects the radio access network to the Edge Router (ER) of the backbone IP network. The Policy Decision Function (PDF) is an entity responsible for controlling bearer level resource allocations/de-allocations in relation to session level services e.g., SIP. The Policy Decision Function may also control the Access Gateway to open and close the gates and to configure per-flow policies, i.e., to authorize or forbid user traffic. The P-CSCF (only used in IMS) and the Access Gateway communicate with the Policy Decision Function, for network
3Gワイヤレス・アクセスシナリオは図1に示されます。 Proxy-呼び出し州Control Function(P-CSCF)は外国行きのSIPプロキシ(IP Multimedia Subsystems(IMS)で使用されるだけである)です。 Accessゲートウェイは3Gのワイヤレスのドメインの出口ルータです、そして、それはバックボーンIPネットワークのEdge Router(ER)にラジオアクセスネットワークを接続します。 Policy Decision Function(PDF)は例えば、セッションレベルサービスSIPと関連して運搬人レベル反-資源配分/配分を制御するのに原因となる実体です。 また、Policy Decision Functionは、ゲートを開けて、閉じて、すなわち、ユーザトラフィックを認可するか、または禁じるために1流れあたりの方針を構成するためにAccessゲートウェイを制御するかもしれません。 P-CSCF(IMSで使用されるだけである)とAccessゲートウェイはネットワークのためにPolicy Decision Functionとコミュニケートします。
Brunner Informational [Page 29] RFC 3726 Requirements for Signaling Protocols April 2004
プロトコル2004年4月に合図するためのブルンナー情報[29ページ]のRFC3726Requirements
resource allocation/de-allocation decisions. The User Equipment (UE) or the Mobile Station (MS) consists of a Mobile Terminal (MT) and Terminal Equipment (TE), e.g., a laptop.
反-資源配分/配分決定。 User Equipment(UE)かモバイル駅(MS)がモバイルTerminal(MT)とTerminal Equipment(TE)(例えば、ラップトップ)から成ります。
+--------+
+--------->| P-CSCF |---------> SIP signaling
/ +--------+
/ SIP |
| |
| +-----+ +----------------+
| | PDF |<---------->| NSIS Forwarder |<--->
| +-----+ +----------------+
| | ^
| | |
| | |
| |COPS |
| | |
+------+ +---------+ |
| UE/MS|----------| Access |<-----------+ +----+
+------+ | Gateway |------------------| ER |
+---------+ +----+
+--------+ +--------->| P-CSCF|--------->SIPシグナリング/+--------+/一口| | | | +-----+ +----------------+ | | PDF| <、-、-、-、-、-、-、-、-、--、>| NSIS混載業者| <、-、--、>| +-----+ +----------------+ | | ^ | | | | | | | |巡査| | | | +------+ +---------+ | | UE/さん|----------| アクセス| <、-、-、-、-、-、-、-、-、-、--+ +----+ +------+ | ゲートウェイ|------------------| えー| +---------+ +----+
Figure 1: 3G wireless access scenario
図1: 3Gワイヤレス・アクセスシナリオ
The PDF has all the required QoS information for per-flow or aggregate admission control in 3G wireless networks. It receives resource allocation/de-allocation requests from the P-CSCF and/or Access Gateway etc. and responds with policy decisions. Hence the PDF may be a candidate entity to host the functionality of the NSIS Initiator, initiating the NSIS QoS signaling towards the backbone IP network. On the other hand, the UE/MS may act as the NSIS Initiator or the Access Gateway may act as a Proxy NSIS Initiator on behalf of the UE/MS. In the former case, the P-CSCF/PDF has to do the mapping from codec types and media descriptors (derived from SIP/SDP signaling) to IP traffic descriptor. In the latter case, the UE/MS may use any appropriate QoS signaling mechanism as the NSIS Initiator. If the Access Gateway is acting as the Proxy NSIS initiator on behalf of the UE/MS, then it may have to do the mapping of parameters from radio access specific QoS to IP QoS traffic parameters before forwarding the request to the NSIS Forwarder.
PDFは3Gワイヤレス・ネットワークで流れか集合入場コントロールのためのすべての必要なQoS情報を持っています。 それは反-資源配分/配分を受けます。P-CSCF、そして/または、Accessからゲートウェイなどを要求して、政策決定で応じます。 したがって、PDFはNSIS Initiatorの機能性をホスティングするためには候補実体であるかもしれません、バックボーンIPネットワークに向かってNSIS QoSシグナリングを開始して。 他方では、NSIS InitiatorかAccessゲートウェイがProxy NSIS InitiatorとしてUE/MSを代表して作動するとき、UE/MSは行動するかもしれません。前の場合では、P-CSCF/PDFはマッピングをコーデックタイプとメディア記述子(SIP/SDPシグナリングから、派生する)からIPトラフィック記述子までしなければなりません。 後者の場合では、UE/MSはNSIS Initiatorとしてどんな適切なQoSシグナル伝達機構も使用するかもしれません。 AccessゲートウェイがProxy NSIS創始者としてUE/MSを代表して機能しているなら、要求をNSIS Forwarderに転送する前に、それはIP QoSトラフィックパラメタへのラジオアクセスの特定のQoSからパラメタに関するマッピングをしなければならないかもしれません。
The NSIS Forwarder is currently not part of the standard 3G wireless architecture. However, to achieve end-to-end QoS a NSIS Forwarder is needed such that the NSIS Initiators can request a QoS connection to the IP network. As in the previous example, the NSIS Forwarder could manage a set of pre-provisioned resources in the IP network, i.e., bandwidth pipes, and the NSIS Forwarder perform per-flow admission control into these pipes. In this way, a connection can be made
現在、NSIS Forwarderは標準の3Gワイヤレスのアーキテクチャの一部ではありません。 しかしながら、終わりから終わりへのQoSを達成するために、NSIS ForwarderはNSIS InitiatorsがIPネットワークにQoS接続を要求できるくらいの必要なそのようなものです。 前の例のように、NSIS ForwarderはIPネットワークで1セットのあらかじめ食糧を供給されたリソースに対処できました、すなわち、帯域幅パイプ、そして、NSIS Forwarderが1流れあたりの入場コントロールをこれらのパイプに実行します。 このように、接続を作ることができます。
Brunner Informational [Page 30] RFC 3726 Requirements for Signaling Protocols April 2004
プロトコル2004年4月に合図するためのブルンナー情報[30ページ]のRFC3726Requirements
between two 3G wireless access networks, and hence, end-to-end QoS can be achieved. In this case the NSIS Initiator and NSIS Forwarder are clearly two separate logical entities. The Access Gateway or/and the Edge Router in Fig.1 may contain the NSIS Forwarder functionality, depending upon the placement of the NSIS Initiator as discussed in scenario 2 in section 8.2. This use case clearly illustrates the need for an NSIS QoS signaling protocol between NSIS Initiator and NSIS Forwarder. An important application of such a protocol may be its use in the end-to-end establishment of a connection with specific QoS characteristics between a mobile host and another party (e.g., end host or content server).
2の間では、3Gワイヤレス・アクセスネットワーク、およびしたがって、終わりから終わりへのQoSを達成できます。 この場合、NSIS InitiatorとNSIS Forwarderは明確に2つの別々の論理的な実体です。 Accessゲートウェイか/とFig.1のEdge RouterはNSIS Forwarderの機能性を含むかもしれません、シナリオ2でセクション8.2で議論するようにNSIS Initiatorのプレースメントによって。 これは明確にケースを使用します。NSIS InitiatorとNSIS Forwarderの間のプロトコルに合図しながら、NSIS QoSの必要性を例証します。 そのようなプロトコルの重要な応用は使用が終わらせる終わりへのモバイルホストと別のパーティー(例えば、終わりのホストか満足しているサーバ)の間の特定のQoSの特性との関係の設立であったならそうするかもしれません。
8.4. Wired Part of Wireless Network
8.4. ワイヤレス・ネットワークのWired部分
A wireless network, seen from a QoS domain perspective, usually consists of three parts: a wireless interface part (the "radio interface"), a wired part of the wireless network (i.e., Radio Access Network) and the backbone of the wireless network, as shown in Figure 2. Note that this figure should not be seen as an architectural overview of wireless networks but rather as showing the conceptual QoS domains in a wireless network.
通常、QoSドメイン見解から見られたワイヤレス・ネットワークは3つの部品から成ります: 図2のワイヤレスインターフェース一部(「ラジオインタフェース」)とワイヤレス・ネットワークのワイヤードな部分(すなわち、Radio Access Network)と示されるとしてのワイヤレス・ネットワークのバックボーン。 ワイヤレス・ネットワークについて建築概要と考えられるのではなく、この図がむしろワイヤレス・ネットワークで概念的なQoSドメインを示していると考えられるべきであることに注意してください。
In this scenario, a mobile host can roam and perform a handover procedure between base stations/access routers. In this scenario the NSIS QoS protocol can be applied between a base station and the gateway (GW). In this case a GW can also be considered as a local handover anchor point. Furthermore, in this scenario the NSIS QoS protocol can also be applied either between two GWs, or between two edge routers (ER).
このシナリオでは、モバイルホストは、基地局/アクセスルータの間の引き渡し手順を歩き回って、実行できます。 このシナリオでは、基地局とゲートウェイ(GW)の間でNSIS QoSプロトコルを適用できます。 また、この場合、ローカルの引き渡しアンカー・ポイントであるとGWをみなすことができます。 その上、また、このシナリオでは、2GWsの間、または、2つの縁のルータ(ER)の間でNSIS QoSプロトコルを適用できます。
Brunner Informational [Page 31] RFC 3726 Requirements for Signaling Protocols April 2004
プロトコル2004年4月に合図するためのブルンナー情報[31ページ]のRFC3726Requirements
|--|
|GW|
|--| |--|
|MH|--- .
|--| / |-------| .
/--|base | |--| .
|station|-|ER|...
|-------| |--| . |--| back- |--| |---| |----|
..|ER|.......|ER|..|BGW|.."Internet"..|host|
-- |-------| |--| . |--| bone |--| |---| |----|
|--| \ |base |-|ER|... .
|MH| \ |station| |--| .
|--|--- |-------| . MH = mobile host
|--| ER = edge router
<----> |GW| GW = gateway
Wireless link |--| BGW = border gateway
... = interior nodes
<------------------->
Wired part of wireless network
|--| |GW| |--| |--| |MH|--- . |--| / |-------| . /--|ベース| |--| . |ステーション|-|えー|... |-------| |--| . |--| 後部|--| |---| |----| ..|えー|.......|えー|..|BGW|.."「インターネット。」|ホスト| -- |-------| |--| . |--| 骨|--| |---| |----| |--| \ |ベース|-|えー|... . |MH| \ |ステーション| |--| . |--|--- |-------| . MHはモバイルホストと等しいです。|--| ERは縁のルータ<と等しいです。---->| GW| GW=ゲートウェイWirelessリンク|--| BGWは境界ゲートウェイと等しいです… = 内部のノード<。------------------->はワイヤレス・ネットワークの一部を配線しました。
<---------------------------------------->
Wireless Network
<。---------------------------------------->ワイヤレス・ネットワーク
Figure 2. QoS architecture of wired part of wireless network
図2。 ワイヤレス・ネットワークのワイヤードな部分のQoSアーキテクチャ
Each of these parts of the wireless network impose different issues to be solved on the QoS signaling solution being used:
それぞれのワイヤレス・ネットワークのこれらの部分は使用されるQoSシグナリングソリューションで解決されるために別問題を課します:
1) Wireless interface: The solution for the air interface link has to
ensure flexibility and spectrum efficient transmission of IP
packets. However, this link layer QoS can be solved in the same
way as any other last hop problem by allowing a host to request
the proper QoS profile.
1) ワイヤレスインターフェース: 空気インタフェースリンクへのソリューションはIPパケットの柔軟性とスペクトルの効率的な送信を確実にしなければなりません。 しかしながら、いかなる他の最後のホップ問題とも同様に、ホストが適切なQoSプロフィールを要求するのを許容することによって、このQoSリンクレイヤを解決できます。
2) Wired part of the wireless network: This is the part of the
network that is closest to the base stations/access routers. It
is an IP network although some parts logically perform tunneling
of the end user data. In cellular networks, the wired part of the
wireless network is denoted as a radio access network.
2) ワイヤレス・ネットワークのWired部分: これは基地局/アクセスルータの最も近くにあるネットワークの部分です。 いくつかの部品がエンドユーザデータのトンネリングを論理的に実行しますが、それはIPネットワークです。 セルラー・ネットワークでは、ワイヤレス・ネットワークのワイヤードな部分はラジオアクセスネットワークとして指示されます。
This part of the wireless network has different requirements for
signaling protocol characteristics when compared to traditional IP
networks:
ワイヤレス・ネットワークのこの部分には、伝統的なIPネットワークと比べると、シグナリングプロトコルの特性のための異なった要件があります:
- The network must support mobility. Many wireless networks are
able to provide a combination of soft and hard handover
procedures. When handover occurs, reservations need to be
established on new paths. The establishment time has to be as
- ネットワークは移動性をサポートしなければなりません。 多くのワイヤレス・ネットワークが柔らかくて困難な引き渡し手順の組み合わせを提供できます。 引き渡しが起こると、予約は、新しい経路に設立される必要があります。 設立時間がなければなりません。
Brunner Informational [Page 32] RFC 3726 Requirements for Signaling Protocols April 2004
プロトコル2004年4月に合図するためのブルンナー情報[32ページ]のRFC3726Requirements
short as possible since long establishment times for s degrade
the performance of the wireless network. Moreover, for maximal
utilization of the radio spectrum, frequent handover operations
are required.
以来可能であるとして、sのための長い設立時間がワイヤレス・ネットワークの性能を下げるのを短いです。 そのうえ、電波スペクトルの最大限度の利用において、頻繁な引き渡し操作が必要です。
- These links are typically rather bandwidth-limited.
- 通常、これらのリンクは帯域幅によってかなり限られます。
- The wired transmission in such a network contains a relatively
high volume of expensive leased lines. Overprovisioning might
therefore be prohibitively expensive.
- そのようなネットワークにおける有線伝送は高価な専用線の比較的高いボリュームを含んでいます。 したがって、Overprovisioningは法外に高価であるかもしれません。
- The radio base stations are spread over a wide geographical
area and are in general situated a large distance from the
backbone.
- ラジオ基地局は、広い地理的な領域にわたって広げられて、一般に、バックボーンから大きい距離に位置しています。
3) Backbone of the wireless network: the requirements imposed by this
network are similar to the requirements imposed by other types of
backbone networks.
3) ワイヤレス・ネットワークのバックボーン: このネットワークによって課された要件は他のタイプのバックボーンネットワークによって課された要件と同様です。
Due to these very different characteristics and requirements, often contradictory, different QoS signaling solutions might be needed in each of the three network parts.
これらの非常に異なった特性と要件、しばしば相容れなくて、異なったQoSのため、シグナリングソリューションがそれぞれの3つのネットワーク一部で必要であるかもしれません。
8.5. Session Mobility
8.5. セッションの移動性
In this scenario, a session is moved from one end-system to another. Ongoing sessions are kept and QoS parameters need to be adapted, since it is very likely that the new device provides different capabilities. Note that it is open which entity initiates the move, which implies that the NSIS Initiator might be triggered by different entities.
このシナリオでは、セッションは片端システムから別のシステムまで動かされます。 進行中のセッションは保たれます、そして、QoSパラメタは適合させられる必要があります、新しいデバイスが異なった能力を非常に提供しそうであるので。 どの実体がNSIS Initiatorが異なった実体によって引き起こされるかもしれないのを含意する移動を開始するかが、開いていることに注意してください。
User mobility (i.e., a user changing the device and therefore moving the sessions to the new device) is considered to be a special case within the session mobility scenario.
ユーザの移動性(すなわち、デバイスを変えて、したがってセッションを新しいデバイスに動かしているユーザ)はセッション移動性シナリオの中の特別なケースであると考えられます。
Note that this scenario is different from terminal mobility. The terminal (end-system) has not moved to a different access point. Both terminals are still connected to an IP network at their original points.
このシナリオが端末の移動性と異なっていることに注意してください。 端末(エンドシステム)は異なったアクセスポイントに移行していません。 両方の端末はまだそれらの元のポイントのIPネットワークにつなげられています。
The issues include:
問題は:
1) Keeping the QoS guarantees negotiated implies that the end-
point(s) of communication are changed without changing the s.
1) QoS保証を交渉し続けるのがコミュニケーションの終わりのポイントがsを変えないで変えられるのを含意します。
2) The trigger of the session move might be the user or any other
party involved in the session.
2) セッション移動の引き金は、セッションでユーザかいかなる他の取引の当事者であるかもしれません。
Brunner Informational [Page 33] RFC 3726 Requirements for Signaling Protocols April 2004
プロトコル2004年4月に合図するためのブルンナー情報[33ページ]のRFC3726Requirements
8.6. QoS Reservation/Negotiation from Access to Core Network
8.6. コアネットワークへのアクセスからのQoS予約/交渉
The scenario includes the signaling between access networks and core networks in order to setup and change reservations together with potential negotiation.
シナリオは、潜在的交渉と共に予約をセットアップして、変えるためにアクセスネットワークとコアネットワークの間のシグナリングを含んでいます。
The issues to be solved in this scenario are different from previous ones.
このシナリオで解決するべき問題は前のものと異なっています。
1) The entity of reservation is most likely an aggregate.
1) 予約の実体はたぶん集合です。
2) The time scales of states might be different (long living states
of aggregates, less often re-negotiation).
2) 州のタイムスケールは異なっているかもしれません(集合の長い生活事情、よりしばしば再交渉)。
3) The specification of the traffic (amount of traffic), a particular
QoS is guaranteed for, needs to be changed. E.g., in case
additional flows are added to the aggregate, the traffic
specification of the flow needs to be added if it is not already
included in the aggregates specification.
3) トラフィック(トラフィックの量)の仕様(QoSが保証される事項)は、変えられる必要があります。 例えば、追加流れが集合に追加されるといけないので、それが集合仕様に既に含まれていないなら、流れのトラフィック仕様は、加えられる必要があります。
4) The flow specification is more complex including network addresses
and sets of different address for the source as well as for the
destination of the flow.
4) ソースと流れの目的地への異なったアドレスのネットワーク・アドレスとセットを含むことでは流れ仕様は、より複雑です。
8.7. QoS Reservation/Negotiation Over Administrative Boundaries
8.7. 管理境界の上のQoS予約/交渉
Signaling between two or more core networks to provide QoS is handled in this scenario. This might also include access to core signaling over administrative boundaries. Compared to the previous one it adds the case, where the two networks are not in the same administrative domain. Basically, it is the inter-domain/inter-provider signaling which is handled in here.
2つ以上のコアネットワークの間でQoSを提供すると合図するのがこのシナリオで扱われます。 また、これは管理境界の上のコアシグナリングへのアクセスを含むかもしれません。 前のものと比べて、2つのネットワークが同じ管理ドメインで加えないところでそれはケースを加えます。 基本的に、それはここで扱われる相互相互ドメイン/プロバイダーシグナリングです。
The domain boundary is the critical issue to be resolved. Which of various flavors of issues a QoS signaling protocol has to be concerned with.
ドメイン境界は決議されるべき重大な問題です。 QoSシグナリングプロトコルは問題の様々な風味のどれに関係がなければなりませんか?
1) Competing administrations: Normally, only basic information should
be exchanged, if the signaling is between competing
administrations. Specifically information about core network
internals (e.g., topology, technology, etc.) should not be
exchanged. Some information exchange about the "access points" of
the core networks (which is topology information as well) may be
required, to be exchanged, because it is needed for proper
signaling.
1) 競争している政権: 競争している政権の間には、シグナリングがあるなら、基本情報だけを交換するべきです。 明確にコアネットワークインターナル(例えば、トポロジー、技術など)の情報を交換するべきではありません。 コアネットワークの「アクセスポイント」(また、トポロジー情報である)に関する何らかの情報交換が交換するのに必要であるかもしれません、それが適切なシグナリングに必要であるので。
2) Additionally, as in scenario 4, signaling most likely is based on
aggregates, with all the issues raise there.
2) さらに、シナリオ4のように、シグナリングはたぶん問題がそこに上げるすべてがある集合に基づいています。
Brunner Informational [Page 34] RFC 3726 Requirements for Signaling Protocols April 2004
プロトコル2004年4月に合図するためのブルンナー情報[34ページ]のRFC3726Requirements
3) Authorization: It is critical that the NSIS Initiator is
authorized to perform a QoS path setup.
3) 承認: NSIS InitiatorがQoS経路セットアップを実行するのが認可されるのは重要です。
4) Accountability: It is important to notice that signaling might be
used as an entity to charge money for, therefore the
interoperation with accounting needs to be available.
4) 責任: シグナリングがお金を充電する実体として使用されるかもしれないのに気付くのが重要である、したがって、会計があるinteroperationは利用可能である必要があります。
8.8. QoS Signaling Between PSTN Gateways and Backbone Routers
8.8. PSTNゲートウェイとバックボーンルータの間で合図するQoS
A PSTN gateway (i.e., host) requires information from the network regarding its ability to transport voice traffic across the network. The voice quality will suffer due to packet loss, latency and jitter. Signaling is used to identify and admit a flow for which these impairments are minimized. In addition, the disposition of the signaling request is used to allow the PSTN GW to make a call routing decision before the call is actually accepted and delivered to the final destination.
PSTNゲートウェイ(すなわち、ホスト)はネットワークの向こう側に音声トラヒックを輸送する性能に関するネットワークからの情報を必要とします。 音声の品質にパケット損失、潜在、およびジターのため苦しむでしょう。 シグナリングは、これらの損傷が最小にされる流れを特定して、認めるのに使用されます。 さらに、シグナリング要求の気質は、呼び出しが最終的な送付先に実際に受け入れられて、提供される前にPSTN GWが呼び出しルーティング決定をするのを許容するのに使用されます。
PSTN gateways may handle thousands of calls simultaneously and there may be hundreds of PSTN gateways in a single provider network. These numbers are likely to increase as the size of the network increases. The point being that scalability is a major issue.
PSTNゲートウェイは同時に何千もの呼び出しを扱うかもしれません、そして、ただ一つのプロバイダーネットワークには何百PSTN門がもあるかもしれません。 ネットワークのサイズが増加するのに従って、これらの数は増加しそうです。 そのスケーラビリティであるポイントは主要な問題です。
There are several ways that a PSTN gateway can acquire assurances that a network can carry its traffic across the network. These include:
PSTNゲートウェイがネットワークがネットワークの向こう側にトラフィックを運ぶことができるという保証を取得できるいくつかの方法があります。 これらは:
1. Over-provisioning a high availability network.
1. 高可用性ネットワークに食糧を供給し過ぎます。
2. Handling admission control through some policy server that has a
global view of the network and its resources.
2. ネットワークの国際的視野を持っている何らかの方針サーバとそのリソースを通した入場コントロールを扱います。
3. Per PSTN GW pair admission control.
3. PSTN GWに従って、入場コントロールを対にしてください。
4. Per call admission control (where a call is defined as the 5-tuple
used to carry a single RTP flow).
4. コール許可に従って、制御してください(呼び出しがただ一つのRTP流動を運ぶのに使用される5-tupleと定義されるところ)。
Item 1 requires no signaling at all and is therefore outside the scope of this working group.
項目1は、全く合図するのが必要でなく、したがって、このワーキンググループの範囲の外にあります。
Item 2 is really a better informed version of 1, but it is also outside the scope of this working group as it relies on a particular telephony signaling protocol rather than a packet admission control protocol.
項目2は本当に1の、より良い知識があるバージョンですが、パケット入場制御プロトコルよりむしろ特定の電話シグナリングプロトコルを当てにするとき、このワーキンググループの範囲の外にもそれはあります。
Item 3 is initially attractive, as it appears to have reasonable scaling properties, however, its scaling properties only are effective in cases where there are relatively few PSTN GWs. In the
項目3は初めは魅力的です、スケーリング特性だけが比較的わずかなPSTN GWsがある場合で有効であることがしかしながら、妥当なスケーリング特性を持っているように見えるとき。 in
Brunner Informational [Page 35] RFC 3726 Requirements for Signaling Protocols April 2004
プロトコル2004年4月に合図するためのブルンナー情報[35ページ]のRFC3726Requirements
more general case where a PSTN GW reduces to a single IP phone sitting behind some access network, the opportunities for aggregation are reduced and the problem reduces to item 4.
PSTN GWが何らかのアクセスネットワークの後ろにある単一のIP電話に減少するより一般的なケース、集合の機会は減少します、そして、問題は項目4に減少します。
Item 4 is the most general case. However, it has the most difficult scaling problems. The objective here is to place the requirements on Item 4 such that a scalable per-flow admission control protocol or protocol suite may be developed.
項目4は最も一般的なケースです。 しかしながら、それには、最も難しいスケーリング問題があります。ここの目的は1流れあたりのスケーラブルな入場制御プロトコルかプロトコル群を開発できるようにItem4に要件を置くことです。
The case where per-flow signaling extends to individual IP end-points allows the inclusion of IP phones on cable, DSL, wireless or other access networks in this scenario.
1流れあたりのシグナリングが個々のIPエンドポイントに達するこの件はケーブルにおけるIP電話の包含を許容します、DSL、このシナリオのワイヤレスの、または、他のアクセスネットワーク。
Call Scenario
シナリオに電話をしてください。
A PSTN GW signals end-to-end for some 5-tuple defined flow a bandwidth and QoS requirement. Note that the 5-tuple might include masking/wildcarding. The access network admits this flow according to its local policy and the specific details of the access technology.
PSTN GWはいくつかに関して、5-tupleが流れの帯域幅とQoSを定義した終わりから終わりへの要件に合図します。 5-tupleが、マスクをかけるか、またはwildcardingするのを含むかもしれないことに注意してください。 ローカルの方針とアクセス技術の特定の詳細に従って、アクセスネットワークはこの流れを認めます。
At the edge router (i.e., border node), the flow is admitted, again with an optional authentication process, possibly involving an external policy server. Note that the relationship between the PSTN GW and the policy server and the routers and the policy server is outside the scope of NSIS. The edge router then admits the flow into the core of the network, possibly using some aggregation technique.
縁のルータ(すなわち、境界ノード)では、流れは認められます、再び任意の認証過程で、ことによると対外政策サーバにかかわって。NSISの範囲の外にPSTN GWと、方針サーバと、ルータと方針サーバとの関係があることに注意してください。 そして、ことによると何らかの集合のテクニックを使用して、縁のルータはネットワークのコアへの流れを認めます。
At the interior nodes, the NSIS host-to-host signaling should either be ignored or invisible as the Edge router performed the admission control decision to some aggregate.
内部のノードでは、Edgeルータが入場コントロール決定を何らかの集合に実行したので、NSISホストからホストへのシグナリングは、無視されているか、または目に見えないはずです。
At the inter-provider router (i.e., border node), again the NSIS host-to-host signaling should either be ignored or invisible, as the Edge router has performed an admission control decision about an aggregate across a carrier network.
一方、NSISホストからホストへのシグナリングは、相互プロバイダールータ(すなわち、境界ノード)では、無視されているか、または目に見えないはずです、Edgeルータがキャリヤーネットワークの向こう側に集合に関する入場コントロール決定を実行したとき。
8.9. PSTN Trunking Gateway
8.9. PSTN中継方式ゲートウェイ
One of the use cases for the NSIS signaling protocol is the scenario of interconnecting PSTN gateways with an IP network that supports QoS.
NSISシグナリングのためのケースが議定書の中で述べる使用の1つはQoSをサポートするIPがあるPSTNゲートウェイがネットワークでつなぐ内部連絡のシナリオです。
Brunner Informational [Page 36] RFC 3726 Requirements for Signaling Protocols April 2004
プロトコル2004年4月に合図するためのブルンナー情報[36ページ]のRFC3726Requirements
Four different scenarios are considered here.
4つの異なったシナリオがここで考えられます。
1. In-band QoS signaling is used. In this case the Media Gateway
(MG) will be acting as the NSIS Initiator and the Edge Router (ER)
will be the NSIS Forwarder. Hence, the ER should do admission
control (into pre-provisioned traffic trunks) for the individual
traffic flows. This scenario is not further considered here.
1. バンドにおけるQoSシグナリングは使用されています。 NSIS InitiatorとEdge Router(ER)がNSIS Forwarderになるので、この場合、メディアゲートウェイ(MG)は行動するでしょう。 したがって、ERは個々の交通の流れのための入場コントロール(あらかじめ食糧を供給されたトラフィックトランクスへの)をするはずです。 このシナリオはここでさらに考えられません。
2. Out-of-band signaling in a single domain, the NSIS forwarder is
integrated in the Media Gateway Controller (MGC). In this case no
NSIS protocol is required.
2. バンドでは、単一領域で合図して、NSIS混載業者はメディアゲートウェイController(MGC)で統合しています。 この場合、NSISプロトコルは全く必要ではありません。
3. Out-of-band signaling in a single domain, the NSIS forwarder is a
separate box. In this case NSIS signaling is used between the MGC
and the NSIS Forwarder.
3. ドメインがバンドの外にシングルで示して、NSIS混載業者は別々の箱です。 この場合、NSISシグナリングはMGCとNSIS Forwarderの間で使用されます。
4. Out-of-band signaling between multiple domains, the NSIS Forwarder
(which may be integrated in the MGC) triggers the NSIS Forwarder
of the next domain.
4. 複数のドメインの間のバンドで出ているシグナリング、NSIS Forwarder(MGCで統合しているかもしれない)は次のドメインのNSIS Forwarderの引き金となります。
When the out-of-band QoS signaling is used the Media Gateway Controller (MGC) will be acting as the NSIS Initiator.
バンドで出ているQoSシグナリングが使用されているとき、メディアゲートウェイController(MGC)はNSIS Initiatorとして機能するでしょう。
In the second scenario the voice provider manages a set of traffic trunks that are leased from a network provider. The MGC does the admission control in this case. Since the NSIS Forwarder acts both as a NSIS Initiator and a NSIS Forwarder, no NSIS signaling is required. This scenario is shown in Figure 3.
2番目のシナリオでは、声のプロバイダーはネットワーク内の提供者から賃貸される1セットのトラフィックトランクスを管理します。 MGCはこの場合入場コントロールをします。 NSIS Forwarderが行動するので、NSIS InitiatorとNSIS Forwarder、どんなNSISとしても、シグナリングは必要ではありません。 このシナリオは図3に示されます。
+-------------+ ISUP/SIGTRAN +-----+ +-----+
| SS7 network |---------------------| MGC |--------------| SS7 |
+-------------+ +-------+-----+---------+ +-----+
: / : \
: / : \
: / +--------:----------+ \
: MEGACO / / : \ \
: / / +-----+ \ \
: / / | NMS | \ \
: / | +-----+ | \
: : | | :
+--------------+ +----+ | bandwidth pipe (SLS) | +----+
| PSTN network |--| MG |--|ER|======================|ER|-| MG |--
+--------------+ +----+ \ / +----+
\ QoS network /
+-------------------+
+-------------+ ISUP/SIGTRAN+-----+ +-----+ | SS7ネットワーク|---------------------| MGC|--------------| SS7| +-------------+ +-------+-----+---------+ +-----+ : / : \ : / : \ : / +--------:----------+ \ : MEGACO//: \ \ : / / +-----+ \ \ : / / | NMS| \ \ : / | +-----+ | \ : : | | : +--------------+ +----+ | 帯域幅パイプ(SLS)| +----+ | PSTNネットワーク|--| mg|--|えー|======================|えー|-| mg|-- +--------------+ +----+ \ / +----+ \QoSネットワーク/+-------------------+
Figure 3: PSTN trunking gateway scenario
図3: PSTN中継方式ゲートウェイシナリオ
Brunner Informational [Page 37] RFC 3726 Requirements for Signaling Protocols April 2004
プロトコル2004年4月に合図するためのブルンナー情報[37ページ]のRFC3726Requirements
In the third scenario, the voice provider does not lease traffic trunks in the network. Another entity may lease traffic trunks and may use a NSIS Forwarder to do per-flow admission control. In this case the NSIS signaling is used between the MGC and the NSIS Forwarder, which is a separate box here. Hence, the MGC acts only as a NSIS Initiator. This scenario is depicted in Figure 4.
3番目のシナリオでは、声のプロバイダーはネットワークでトラフィックトランクスを賃貸しません。 別の実体は、トラフィックトランクスを賃貸して、1流れあたりの入場コントロールをするのにNSIS Forwarderを使用するかもしれません。 この場合、NSISシグナリングはMGCとNSIS Forwarderの間で使用されます。NSIS Forwarderはここの別々の箱です。 したがって、MGCは単にNSIS Initiatorとして機能します。 このシナリオは図4に表現されます。
+-------------+ ISUP/SIGTRAN +-----+ +-----+
| SS7 network |---------------------| MGC |--------------| SS7 |
+-------------+ +-------+-----+---------+ +-----+
: / : \
: / +-----+ \
: / | NF | \
: / +-----+ \
: / : \
: / +--------:----------+ \
: MEGACO : / : \ :
: : / +-----+ \ :
: : / | NMS | \ :
: : | +-----+ | :
: : | | :
+--------------+ +----+ | bandwidth pipe (SLS) | +----+
| PSTN network |--| MG |--|ER|======================|ER|-| MG |--
+--------------+ +----+ \ / +----+
\ QoS network /
+-------------------+
+-------------+ ISUP/SIGTRAN+-----+ +-----+ | SS7ネットワーク|---------------------| MGC|--------------| SS7| +-------------+ +-------+-----+---------+ +-----+ : / : \ : / +-----+ \ : / | nf| \ : / +-----+ \ : / : \ : / +--------:----------+ \ : MEGACO: / : \ : : : / +-----+ \ : : : / | NMS| \ : : : | +-----+ | : : : | | : +--------------+ +----+ | 帯域幅パイプ(SLS)| +----+ | PSTNネットワーク|--| mg|--|えー|======================|えー|-| mg|-- +--------------+ +----+ \ / +----+ \QoSネットワーク/+-------------------+
Figure 4: PSTN trunking gateway scenario
図4: PSTN中継方式ゲートウェイシナリオ
In the fourth scenario multiple transport domains are involved. In the originating network either the MGC may have an overview on the resources of the overlay network or a separate NSIS Forwarder will have the overview. Hence, depending on this either the MGC or the NSIS Forwarder of the originating domain will contact the NSIS Forwarder of the next domain. The MGC always acts as a NSIS Initiator and may also be acting as a NSIS Forwarder in the first domain.
4番目のシナリオに、複数の輸送ドメインがかかわります。 起因するネットワークでは、MGCがオーバレイネットワークに関するリソースに概要を持っているかもしれませんか、または別々のNSIS Forwarderには概要があるでしょう。 したがって、これによって、起因するドメインのMGCかNSIS Forwarderのどちらかが次のドメインのNSIS Forwarderに連絡するでしょう。 MGCはNSIS Initiatorとしていつも機能して、また、NSIS Forwarderとして最初のドメインで機能しているかもしれません。
8.10. An Application Requests End-to-End QoS Path from the Network
8.10. アプリケーションはネットワークから終わりから端へのQoS経路を要求します。
This is actually the conceptually simplest case. A multimedia application requests a guaranteed service from an IP network. We assume here that the application is somehow able to specify the network service. The characteristics here are that many hosts might do it, but that the requested service is low capacity (bounded by the access line). Note that there is an issue of scaling in the number of applications requesting this service in the core of the network.
これは実際に概念的に最も簡単なそうです。 マルチメディア応用はIPネットワークから保証されたサービスを要求します。 私たちは、ここでアプリケーションがどうにかネットワーク・サービスを指定できると思います。 ここの特性は多くのホストがそれをするかもしれないのにもかかわらずの、要求されたサービスが低容量(アクセス回線のそばでバウンドしている)であるということです。 ネットワークのコアでこのサービスを要求する応募件数を計量する問題があることに注意してください。
Brunner Informational [Page 38] RFC 3726 Requirements for Signaling Protocols April 2004
プロトコル2004年4月に合図するためのブルンナー情報[38ページ]のRFC3726Requirements
8.11. QOS for Virtual Private Networks
8.11. 仮想私設網のためのQOS
In a Virtual Private Network (VPN), a variety of tunnels might be used between its edges. These tunnels could be for example, IPSec, GRE, and IP-IP. One of the most significant issues in VPNs is related to how a flow is identified and what quality a flow gets. A flow identification might consist among others of the transport protocol port numbers. In an IP-Sec tunnel this will be problematic since the transport protocol information is encrypted.
Virtual兵士のNetwork(VPN)では、さまざまなトンネルが縁の間で使用されるかもしれません。 例えば、これらのトンネルは、IPSecと、GREと、IP-IPであるかもしれません。 VPNsで最も重要な問題の1つは流れがどのように特定されるか、そして、流れがどんな品質を得るかと関係づけられます。 流れ識別は特にトランスポート・プロトコルポートナンバーから成るかもしれません。 IP-秒のトンネルでは、輸送プロトコル情報が暗号化されているので、これが問題が多くなるでしょう。
There are two types of L3 VPNs, distinguished by where the endpoints of the tunnels exist. The endpoints of the tunnels may either be on the customer (CPE) or the provider equipment or provider edge (PE).
トンネルの終点が存在するところによって区別されたL3 VPNsの2つのタイプがあります。 トンネルの終点が顧客(CPE)、プロバイダー設備またはプロバイダー縁(PE)にあるかもしれません。
Virtual Private networks are also likely to request bandwidth or other type of service in addition to the premium services the PSTN GW are likely to use.
また、仮想の兵士のネットワークもPSTN GWが利用しそうであるプレミアムサービスに加えた帯域幅か他のタイプのサービスを要求しそうです。
8.11.1. Tunnel End Points at the Customer Premises
8.11.1. 顧客構内のトンネルエンドポイント
When the endpoints are the CPE, the CPE may want to signal across the public IP network for a particular amount of bandwidth and QoS for the tunnel aggregate. Such signaling may be useful when a customer wants to vary their network cost with demand, rather than paying a flat rate. Such signaling exists between the two CPE routers. Intermediate access and edge routers perform the same exact call admission control, authentication and aggregation functions performed by the corresponding routers in the PSTN GW scenario with the exception that the endpoints are the CPE tunnel endpoints rather than PSTN GWs and the 5-tuple used to describe the RTP flow is replaced with the corresponding flow spec to uniquely identify the tunnels. Tunnels may be of any variety (e.g., IP-Sec, GRE, IP-IP).
終点がCPEであるときに、CPEはトンネル集合のための特定の量の帯域幅とQoSのために公立のIPネットワークの向こう側に合図したがっているかもしれません。 要求に従って顧客が均一料金を支払うよりそれらのネットワーク費用をむしろ変えたがっているとき、そのようなシグナリングは役に立つかもしれません。 そのようなシグナリングは2つのCPEルータの間に存在しています。 中間的アクセスと縁のルータは唯一トンネルを特定するために対応する流れ仕様に取り替えて、コントロール、認証、および総計機能が例外があるPSTN GWシナリオの終点がPSTN GWsよりむしろCPEトンネル終点であり、RTP流動について説明するのに使用される5-tupleが終点である対応するルータで実行した同じ正確なコール許可を実行します。 Tunnelsはどんなバラエティー(例えば、IP秒、GRE、IP-IP)のものであるかもしれません。
In such a scenario, NSIS would actually allow partly for customer managed VPNs, which means a customer can setup VPNs by subsequent NSIS signaling to various end-point. Plus the tunnel end-points are not necessarily bound to an application. The customer administrator might be the one triggering NSIS signaling.
そのようなシナリオでは、NSISは実際に顧客の管理されたVPNsを一部考慮するでしょう。(VPNsは、顧客が様々なエンドポイントに合図するその後のNSISでVPNsをセットアップできることを意味します)。 トンネルが終わりで指すプラスは必ずアプリケーションに縛られるというわけではありません。 顧客管理者はNSISシグナリングの引き金となるものであるかもしれません。
8.11.2. Tunnel End Points at the Provider Premises
8.11.2. プロバイダー構内のトンネルエンドポイント
In the case were the tunnel end-points exist on the provider edge, requests for bandwidth may be signaled either per flow, where a flow is defined from a customers address space, or between customer sites.
場合では、エンドポイントが存在するトンネルがプロバイダー縁であったなら、流れか、流れが顧客アドレス空間から定義されるところか、顧客サイトの間で帯域幅を求める要求に合図するかもしれません。
In the case of per flow signaling, the PE router must map the bandwidth request to the tunnel carrying traffic to the destination specified in the flow spec. Such a tunnel is a member of an
シグナリング、必須が写像する1流れあたりのPEルータの場合では、目的地までトラフィックを運ぶトンネルへの帯域幅要求は流れ仕様で指定しました。 そのようなトンネルはメンバーです。
Brunner Informational [Page 39] RFC 3726 Requirements for Signaling Protocols April 2004
プロトコル2004年4月に合図するためのブルンナー情報[39ページ]のRFC3726Requirements
aggregate to which the flow must be admitted. In this case, the operation of admission control is very similar to the case of the PSTN GW with the additional level of indirection imposed by the VPN tunnel. Therefore, authentication, accounting and policing may be required on the PE router.
流れを認めなければならない集合。 この場合、入場コントロールの操作は追加レベルの間接指定がVPNトンネルによって課されているPSTN GWに関するケースと非常に同様です。 したがって、認証、会計、および取り締まりがPEルータで必要であるかもしれません。
In the case of per site signaling, a site would need to be identified. This may be accomplished by specifying the network serviced at that site through an IP prefix. In this case, the admission control function is performed on the aggregate to the PE router connected to the site in question.
中では、シグナリング、1サイトあたり1つのサイトに関するケースは必要があるでしょう。特定されるのが必要です。 これは、IP接頭語を通してそのサイトでサービスを提供されたネットワークを指定することによって、達成されるかもしれません。 この場合、入場コントロール機能は問題のサイトに関連づけられたPEルータへの集合に実行されます。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[KEYWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
9.2. Informative References
9.2. 有益な参照
[RSVP] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S. and S.
Jamin, "Resource Protocol (RSVP) -- Version 1 Functional
Specification", RFC 2205, September 1997.
[RSVP]ブレーデン、R.(エド)、チャン、L.、Berson、S.、ハーツォグ、S.、およびS.ジャマン、「リソースは(RSVP)について議定書の中で述べます--バージョン1の機能的な仕様」、RFC2205、1997年9月。
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
Issues", RFC 3234, February 2002.
[RFC3234]大工、B.、およびS.があふれそうになる、「Middleboxes:」 「分類学と問題」、RFC3234、2月2002日
Brunner Informational [Page 40] RFC 3726 Requirements for Signaling Protocols April 2004
プロトコル2004年4月に合図するためのブルンナー情報[40ページ]のRFC3726Requirements
10. Authors' Addresses
10. 作者のアドレス
Marcus Brunner (Editor) NEC Europe Ltd. Network Laboratories Kurfuersten-Anlage 36 D-69115 Heidelberg Germany
マーカスブルンナー(エディタ)NECヨーロッパ株式会社ネットワーク研究所Kurfuersten-原基36D-69115ハイデルベルグドイツ
EMail: brunner@netlab.nec.de
メール: brunner@netlab.nec.de
Robert Hancock Roke Manor Research Ltd Romsey, Hants, SO51 0ZN United Kingdom
ロバート・ハンコックRoke荘園研究Ltdロムジー、Hants、SO51 0ZNイギリス
EMail: robert.hancock@roke.co.uk
メール: robert.hancock@roke.co.uk
Eleanor Hepworth Roke Manor Research Ltd Romsey, Hants, SO51 0ZN United Kingdom
エレノア・ヘップウォース・Roke荘園研究Ltdロムジー、Hants、SO51 0ZNイギリス
EMail: eleanor.hepworth@roke.co.uk
メール: eleanor.hepworth@roke.co.uk
Cornelia Kappler Siemens AG Berlin 13623 Germany
コルネリア・Kapplerジーメンス株式会社ベルリン13623ドイツ
EMail: cornelia.kappler@siemens.com
メール: cornelia.kappler@siemens.com
Hannes Tschofenig Siemens AG Otto-Hahn-Ring 6 81739 Munchen Germany
ハンネスTschofenigジーメンス株式会社オットーハーン一味6 81739ミュンヘンドイツ
EMail: Hannes.Tschofenig@mchp.siemens.de
メール: Hannes.Tschofenig@mchp.siemens.de
Brunner Informational [Page 41] RFC 3726 Requirements for Signaling Protocols April 2004
プロトコル2004年4月に合図するためのブルンナー情報[41ページ]のRFC3726Requirements
11. Full Copyright Statement
11. 完全な著作権宣言文
Copyright (C) The Internet Society (2004). 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.
Copyright(C)インターネット協会(2004)。 このドキュメントは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 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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に情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Brunner Informational [Page 42]
ブルンナーInformationalです。[42ページ]
一覧
スポンサーリンク
