Network Working Group M. Brunner, Ed.
Request for Comments: 3726 NEC
Category: Informational April 2004
Requirements for Signaling Protocols
Status of this 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.
著作権（C）インターネット協会（2004）。全著作権所有。
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.
この文書では、このような管理および/または技術ドメイン間など異なるネットワーク環境にわたって、シグナリングのための要件を定義します。シグナリングは、主に、このようなリソース予約プロトコル（RSVP）などのサービスの品質（QoS）のために考えられています。しかし、近年では、シグナリングのいくつかの他のアプリケーションが定義されています。例えば、（MPLS）をマルチプロトコルラベルスイッチングのラベル配布のためのシグナリング又は中間装置へのシグナリング。要件の幅広い適用性を達成するために、出発点は、ネットワークとアプリケーションの相互作用の様々な種類に関するシナリオ/ユースケースの多様なセットです。この文書では、要件をリストする前に仮定を提示します。要件は、このようなアーキテクチャと設計目標、シグナリングフロー、階層化、パフォーマンス、柔軟性、セキュリティ、およびモビリティなどの分野に応じてグループ化されています。
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
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
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
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].
この文書では、シグナリングにおける次のステップ（NSIS）ワーキンググループの製品です。これは、異なるネットワーク環境間のシグナリングのための要件を定義します。それは、このような[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は、シグナリングが、インターネットで使用されている唯一のフィールドではありません。シグナリングはまた、セットアップへの通信プロトコルとして使用され、中間装置[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.
この文書では、ホストおよびサイトマルチホーミングと、特に、相互作用のいくつかのネットワーキングの分野に関連する要件を、カバーしていません。私たちは、将来の分析のためにこれらを残します。
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"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119 [KEYWORDS]で説明されるように解釈されます。
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エンティティ。それはまた、NSIS、ネットワークを介して更なるシグナルを伝播します。
NSIS Initiator (NI): NSIS Entity that starts NSIS signaling to set up or manipulate network state.
NSISイニシエータ（NI）：NSISエンティティ設定やネットワークの状態を操作するためのシグナリングNSISを開始します。
NSIS Responder (NR): NSIS Entity that terminates NSIS signaling and can optionally interact with applications as well.
NSISレスポンダ（NR）：NSISエンティティNSISシグナリングを終了し、必要に応じて、同様のアプリケーションと対話することができます。
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).
フロー：特定のパケットレベルの治療が提供されるトラフィックストリーム（両端のシステム間のIPパケットの順序）。フローは、ユニキャスト（ユニまたは双方向）またはマルチキャストすることができます。それは、受信機に向かって伝播するマルチキャストのため、流れは複数の流れに分岐することができます。 （送信者に向かって）逆方向に見たときに、マルチ送信元マルチキャストのため、流れも発散することができます。
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つのエンティティによって提供され、他で消費されます。これは、リソースを割り当てることにより構築することができます。ネットワークは、ユーザに提供することができ、またはネットワークノードはパケットにそれを提供することができます。
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イニシエータの配置について、例えば、要件）。
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イニシエータ、NSISフォワーダ（S）、およびNSISレスポンダとの間の相互作用であると仮定されます。仮定/除外の更なる書類は、次のセクションに記載されています。
The main elements are:
主な要素は以下のとおりです。
1. Something that starts the request for state to be set up in the network, the NSIS Initiator.
ネットワーク内に設定される状態の要求、NSISイニシエータを開始します。1.何か。
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開始剤の顕著な特徴は、それがエンド・システムにおけるより高いレイヤから（直接または間接的に）来るトリガに作用することです。それはそれらによって要求されたサービスをマッピングする必要があり、また、トランスポート層のアルゴリズムや適応のアプリケーションで使用されるかもしれない、より高い層にフィードバック情報を提供します。
2. Something that assists in managing state further along the signaling path, the NSIS Forwarder.
シグナリングパス、NSISフォワーダーに沿ってさらに状態を管理するのを助ける2.何か。
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フォワーダは、上位層と相互作用するが、シグナリングパス上NSISイニシエータ、レスポンダNSIS、そしておそらく一つ以上のNSISフォワーダと相互作用し、端から端まで、またはエンドツーエンドありません。
3. Something that terminates the signaling path, the NSIS Responder.
シグナリングパス、NSISレスポンダを終了3.何か。
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レスポンダの際立った特徴は、それがシグナリングパスの末尾のリクエストに応答することです。
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.
前記シグナリングパスは、1つまたは複数のIPホップをカバーする基本的なネットワークを横断します。基盤となるネットワークは、局所的に異なる技術を使用する場合があります。たとえば、QoS技術が要求されたサービスのために適切にプロビジョニングする必要があります。 QoSの例では、NSISフォワーダは、技術関連の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. 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フォワーダはネットワークのエッジに対してより「密」になることを期待できますが、これは必須ではありません。例えば、のQoSの場合、オーバープロビジョニングドメインは全くNSISフォワーダを含まない（透明NSISである）かもしれません。他の極端で、NSISフォワーダーは、すべてのルータに配置されることがあります。遠隔NSISフォワーダの場合、プロトコルは、経路に沿ったルータを制御するために必要とされるかもしれないのに対し、後者の場合には、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イニシエータが求めることができ、サービス定義はシグナリングプロトコルの実行の前に知られていることを前提としています。 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.
サービス要求者が利用可能なサービスについて知ってもらう多くの方法があります。標準化されたサービスがあるかもしれません、定義は契約と一緒に交渉することができ、サービス定義はように（Webページで、例えば）いくつかのオンラインディレクトリに公開され、。
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 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.
5.私たちは、シグナリングピアを知るためにNSIS実体の発見のための手段があることを前提とし（ソリューションは、静的な構成、自動的など、データパスに沿って右のノード上で実行される暗黙のうちに発見された、またはが含まれます）。 NSIS実体の発見は、適切に対処する必要があるセキュリティ上の意味を持っています。いくつかのセキュリティメカニズム（すなわち、ケルベロス、秘密事前共有）の場合には、他のエンティティの身元を知ることが必要です。したがって、検出メカニズムは、後で必要なキーおよびパラメータを取得するために使用され、このアイデンティティを学ぶための手段を提供することができます。
6. NSIS assumes layer 3 routing and the determination of next data node selection is not done by NSIS.
6. NSISはレイヤ3ルーティングを想定し、次のデータノード選択の決意は、NSISによって行われていません。
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.
シグナリングプロトコルで必要とされるネゴシエーション機能と情報の意味に関する要件を明確にする以外は、トランスポート/アプリケーションとネットワーク層との間の相互作用のために（そうでAPIと）2.特定のメカニズムは、考慮されません。
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.
4. Specific mechanisms (APIs and so on) for interaction between the network layer and underlying provisioning mechanisms are not considered.
ネットワーク層と下層のプロビジョニング機構との間の相互作用のために（そうでAPIと）4.特定のメカニズムは考慮されません。
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エンティティ間で交換されるべき情報の並べ替えのための要件を意味し得ます。
6. Security implications related to multicasting are outside the scope of the signaling protocol.
マルチキャストに関連する前記セキュリティへの影響は、シグナリングプロトコルの範囲外です。
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同様に、特定の方法、プロトコル、および方法（例えば、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).
この作業は、他のIETFワーキングの直接範囲内にあるように9 NSIS情報へのアプリケーションレベルのプロトコル（例えば、SDP）を介して情報をシグナリングするために必要な任意の拡張の仕様、及びマッピングは、NSISワーキンググループの範囲外であると考えられます基（例えば、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にハンドオフをトリガするために使用されていない、またそれがハンドオフするか否かを決定するために使用されます。すぐにまたはハンドオフが起こった前であっても、いくつかの状況では、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.サービスの監視は範囲外です。これは、アプリケーションおよびまたは輸送サービスの種類に大きく依存し、そしてどのようなシナリオでは、それが使用されています。
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
解決のための二つの一般的な（そして潜在的に矛盾した）目標は、それはシナリオの非常に広い範囲に適用可能であるべきであるということであると同時に、NSISエンティティにおける実装の複雑さと資源消費要件で軽量であること。私たちは、用語を使用します
'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つのアプローチは、溶液が実装または個々のノードで使用するオプションでモジュラーコンポーネントまたは機能を介して、特定の要件に対処することができることです。
This section contains requirements related to desirable overall characteristics of a solution, e.g., enabling flexibility, or independence of parts of the framework.
このセクションでは、柔軟性、またはフレームワークの部分の独立性を可能にする、例えば、溶液の所望の全体的な特性に関連する要件を含んでいます。
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は、設定すべき状態がそれを設定せずに利用可能であるかどうかを確認するためのメカニズムを提供する必要があります。リソース予約たとえばこれは、リソースの予約を行うことなく、リソースの可用性をチェックするに変換します。いくつかのシナリオ、例えば、移動端末のシナリオでは、リソースの予約を行うことなく、リソースが利用可能であるかどうかを照会する必要があります。
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.
- ユニと双方向フローの状態の設定が可能です。
- 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は異なる環境に適応することができるベースプロトコルを提供しなければならないことを意味します。
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.
シグナリングプロトコルは、明らかに輸送された制御情報から分離されなければなりません。これは、溶液のこれら二つの側面の独立した開発を提供し、この制御情報は、アプリケーション層のうち、既存のものまたはそれら将来開発されるなど、他のプロトコル内で実施することが可能になります。情報の輸送に得られる柔軟性は、様々なシナリオで同じプロトコルの適用を可能にします。
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プロトコルを使用することを可能にします。
NSIS SHOULD be able to pass around opaque objects, which are interpreted only by some NSIS-capable nodes.
NSISは、いくつかのNSIS対応ノードによって解釈されるの周りに不透明なオブジェクトを渡すことができるべきです。
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.
このセクションでは、どの方向に、流路のどの部分、どのエンティティ間（エンド・システム、ルータ、中間装置、管理システム）上に、例えば、サポートされるべき可能なシグナリング・フローに関連する要件を含んでいます。
5.2.1. The placement of NSIS Initiator, Forwarder, and Responder Anywhere in the Network MUST be Allowed
5.2.1. ネットワーク内のどこにでもNSISイニシエータ、フォワーダー、およびレスポンダの配置が許可されている必要があり
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フォワーダとNSISイニシエータ機能を配置することができます。
5.2.2. NSIS MUST Support Path-Coupled and MAY Support Path-Decoupled Signaling.
5.2.2. NSISはパス-結合をサポートしなければならないとパスデカップリングシグナリングをサポートすることができます。
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.
しかしながら、シグナリングがデータ・パス上にないシナリオのセットがあります。したがって、NSISシグナリングメッセージは、データ・パス上にあると想定されていないが、それを認識しているノード（NES）にルーティングされる経路切り離さシグナリングモードをサポートすることができます。
5.2.3. Concealment of Topology and Technology Information SHOULD be Possible
5.2.3. トポロジおよび技術情報の隠蔽は可能なはずです
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プロトコルは、エンドノードから他のネットワークから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.
様々なシナリオでは、トポロジ情報は、様々な理由で非表示にする必要があります。ビジネスの観点からは、いくつかの投与が使用さトポロジーと技術を明らかにしたくありません。
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.
いくつかのフローのためのシグナリングは、ネットワーク内のNSISフォワーダで解釈されず、透過的に経路セグメント、すなわちを横断することが可能であるべきです。例は、それを透過通過する個々のフローのためのシグナリングを用いて、ドメインのエッジで確立された凝集体のためのシグナリングを解釈コアネットワーク内のサブドメイン、あろう。
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は大きなパイプ/トランクがNSISシグナリングを使用して設定されているが、また、その大きなパイプ/トランク内で実行されて流れ、階層的なシナリオで動作するはずNSISを使用して設定されています。
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.
アプリケーションが終了する、またはモバイルホストがハンドオフを経験したので、明示的状態を消去することが可能でなければならないので、経路に沿った状態では、例えば、もはや必要ではない場合。
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イニシエータがダウンすると、それが最も可能性が高い、もはや必要ではないだろうから、それがネットワークに要求された状態では、解放する必要があります。
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フォワーダ/開始剤は、それが関与する状態を解除することができなければなりません。例えば、これは、「失敗した後にリリース」メッセージ上流ならびに下流、またはソフトステートタイミングのシグナリングを必要とするかもしれませんでる。
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処理における一時的な障害は、必ずしもすべての状態をすぐに解除させるようにしていないことを、同様に注意してください。
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フォワーダは、上流NSIS開始剤や任意の他のNSISフォワーダを通知すべきです。その中で例えばネットワークの変更の様々な種類があります。
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フォワーダ）自体によって克服された状態です。
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.
利用可能なサービスのアップグレード：以前に要求より良いサービスが利用可能になった場合。
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エンティティに通知を送ることができること、です。それがエラー通知を取得する場合たとえば、それはすべてがOKである場合でも、状態を消去することがあります。だから、通知は、通知の送信者とその受信機間のセキュリティアソシエーションに依存する場合があります。ホップバイホップのセキュリティ・メカニズムを選択した場合、これは、通知は逆の経路で送信する必要があることも意味します。
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は、その状態の確立を要求NIに代わって国家の設立を承認しなければなりません。状態を設定するには拒否状態を設定することを拒否NEによって否定応答で答えなければなりません。これは、NIに送らなければなりません。シグナリングアプリケーションに応じて、（正または負）通知はさらに上流のNEを通過する必要があります。状態を設定するには、拒否の理由に関する情報が利用できるようにすることができます。例えば、リソース予約の例では、一緒に否定的な答えで、利用可能なリソースの量も返されることがあります。
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.
シグナリングプロトコルは、単一の管理ドメイン内に位置するNSISフォワーダ間のローカルな情報を交換することができなければなりません。ローカル情報交換は、エンドツーエンドシグナリングプロセスに属さない別のメッセージの数で行われます。地域情報は、例えば、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フォワーダの識別を搬送することができます。しかしながら、エッジの識別は、エンドホスト（NSISイニシエータ）に表示されてはならず、唯一1つの管理ドメイン内で適用されます。
This section contains requirements related to the control information that needs to be exchanged.
このセクションでは、交換する必要制御情報に関連する要件が含まれています。
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.
ノードは、シグナリングメッセージのパラメータを変更することが可能です。 NSIS Initiatorがシグナリング情報の可変性を制御するためしかし、それは可能なはずです。それはノードの配列を通過するように要求が徐々に変異されず、例えば、NSISイニシエータは、エンド・ツー・エンドを要求しているものを制御することができるべきです。
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.
ローカルスコープ要素を追加および削除することが可能なはずです。要件5.3.5と比較すると、この要件は、地元の情報を輸送するための通常のシグナリングプロセスとメッセージ交換を使用して行います。例えば、ドメインの入口に、ドメイン固有情報付加される情報は、このドメインで使用され、追加され、シグナリングメッセージがドメインを離れるときの情報が再び除去されます。動機は、各種情報のドメイン内部のシグナリングのためのプロトコルを再使用の経済性です。追加情報は、特定のドメイン内で必要とされる場合、エンド・ツー・エンドの情報と同時にこれを実行することが可能でなければなりません。
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のためのチャーター作業項目ではありませんけれども。
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の例にアップグレードするか、リソース使用量のダウングレード）を更新する必要があります。これは、サービスを中断することなくシームレスに行われる必要があります。少なくとも、シグナリングプロトコルは、いくつかのデータパス要素がそうすることができない可能性がある場合でも、それを可能にすべきです。
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基。これの目標は、並行して発生する可能性がセットアップ遅延の面で最適化、です。これは、一度に複数のフローを要求するアプリケーションに役立ちます。また、（柔らかい状態の溶液の場合）電位リフレッシュがグルーピングから利益かもしれません。
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.
しかし、ネットワークは、グループ化されたフローとの関係が存在することを知っている必要はありません。グループに関連付けられたすべてのトランザクションのセマンティックがあってはなりません。これは、唯一の最適化のために意味されます。
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.
拡張性は常にシグナリングプロトコルのための重要な要件です。しかし、スケーラビリティの種類とその重要性は、別のシナリオによって異なります。
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.
パフォーマンスの問題の多くは想定したシナリオに大きく依存しており、通常の速度、信頼性、複雑性、およびスケーラビリティの間のトレードオフであることに注意してください。トレードオフは、ネットワークの異なる部分で変化します。コアネットワークにそれが逆であり得るが、例えば、無線アクセスネットワーク内の低帯域幅の消費は、低レイテンシ要件を上回るであろう。
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シグナリング通信相手（NSISイニシエータ、NSISフォワーダ、およびNSISレスポンダ）により受信されたメッセージの数がスケーラブルでなければなりません。主要な関心事は、大量のメッセージが到着するネットワークのコアにあります。
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.
これは、モバイル環境でのハンドオフの数はスケーラブルでなければなりません。コアはほとんどの場合、モビリティに透明であるので、これは主に、アクセスネットワークに適用されます。
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フォワーダのために達成されなければなりません。
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はホストによるシグナリングの使用が普遍的になり、インターネット規模な展開に働かなければなりません。要件5.2.4は透過的に解釈することなく、ネットワークを介したシグナル伝達の機能を必要とすることに注意してください。また、要件5.6.1は、集約する機能が一覧表示されます。さらに、要件5.5.4は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は、状態の低レイテンシーの設定を可能にすべきです。これは状態のみセットアップが短い時間スケールで必要とされるシナリオで必要とされる（例えば、モバイル環境におけるハンドオーバ）、または人間の相互作用を直ちに（例えば、音声通信セットアップ遅延）懸念されます。
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は、特定のアクセスネットワークにおける低帯域幅の消費を考慮しなければなりません。再びシナリオのほんのセットは、無線リンクが含まれている場所を中心に、それらは、低帯域幅のために呼び出します。
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アーキテクチャは、それが必要とされる機器の負荷を制限する能力（CPU負荷、メモリ空間、強度、帯域幅の消費をシグナリングとシグナリング）を与えるべきです。理由の一つは、プロトコル処理が内部（コア）ノードに最小限の影響を有していなければならないということです。
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は限り要件が満たされるよう任意の方法を選択することができます。
This requirement applies specifically to QoS signaling.
この要件は、QoSシグナリングに特異的に適用されます。
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.
そこ様々な理由のために高いネットワーク使用率を必要とするネットワーク環境であり、かつ適切なサービス品質を維持しながら、シグナリングプロトコルは、その最高の能力をサポート高いリソース使用率をするためにすべきです。
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.
リソースは、（多くのワイヤレスネットワークの場合のように）非常に高価であり、ネットワークでは、シグナリングトラフィックのための効率的なネットワーク利用が重要な財務重要です。一方、高い利用率が必要とされていないネットワークの他の部分があります。
This section lists the various ways the protocol can flexibly be employed.
このセクションでは、プロトコルが柔軟に採用することができるさまざまな方法を示しています。
NSIS MUST allow for flow aggregation, including the capability to select and change the level of aggregation.
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は、NSISイニシエータとレスポンダNSISを確定に柔軟でなければなりません。 NSISイニシエータは反対側に自然に送信またはデータ・ストリームの受信側に位置し、NSISレスポンダれるかもしれません。
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ゲートウェイ、いくつかのVPN、および移動度のような様々なシナリオにおいて許容されなければなりません。これは、NSISイニシエータとNSIS Responderは、データストリームのエンドポイントであることを意味しない場合があります。
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イニシエータまたはNSIS Responderは状態の変更を開始することができるべきです。リソース予約の例では、これは多くの場合、リソースの再交渉と呼ばれています。それは、そのようなローカルリソース不足（エンドシステム上のCPU、メモリ）などの様々な理由に起こることができ、またはユーザは、アプリケーション優先/プロファイルを変更しました。
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は、ネットワーク開始状態変化をサポートする必要があります。 QoSの例では、これはネットワークがさらに保証リソースにできないと、例えばリソース予約をダウングレードしたい場合に使用されています。
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.
両方の単方向だけでなく、双方向の状態の設定が可能であるべきです。双方向状態のセットアップで、私たちは、双方向データフローの状態が設定されていることを意味します。双方向データフローは、同じエンドポイントを持っているが、二つの方向におけるパスが同じである必要はありません。
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.
双方向状態のセットアップの目標は、主にセットアップ遅延の面で最適化です。など、同じデータ・パスの使用などの制約には何の要件はありません
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シグナリングを実装するノードその許可する必要があります。
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.
シグナリングプロトコルは、強力な認証メカニズムを使用して互いに認証される様々なエンティティを可能にするための準備を行う必要があります。弱いプレーンテキストのパスワードメカニズムが認証に使用してはならないという事実に用語強力な認証ポイント。
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.
シグナリングプロトコルは、状態設定要求を承認する手段を提供しなければなりません。この要件は、認証データを要求する方針エンティティと対話するためのフックを要求しています。これは、認証されたエンティティは、認証データと関連することが、要求を検証することを可能にします。認証は、不正なエンティティ、ポリシーに違反セットアップ、およびサービスの盗難によって状態のセットアップを防ぎます。さらに、ネットワークの一部または無制限状態のセットアップに起因する、ネットワーク全体に対するサービス拒否攻撃を制限します。さらに、以前に成功し、認可イベントに関する同じ管理ドメイン内の参加ノードの他のプロトコルに通知するために、いくつかの手段を提供するために役に立つかもしれません。
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.
シグナリングプロトコルは変更に対するメッセージ・ペイロードを保護する手段を提供しなければなりません。完全性保護は、シグナリングメッセージの部分を変更することから、プロトコルの実行に関与するネットワーク要素に対する攻撃のサービスタイプのサービスや盗難の取付拒否から敵を防止します。
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.
以前のシグナリングメッセージの再生を防止するために、シグナリングプロトコルは、すでにシグナリングメッセージを送信し、すなわち古いを検出するための手段を提供しなければなりません。解決策は、再起動や、参加ネットワーク要素のクラッシュした場合には、同期の問題の問題をカバーしなければなりません。
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.
シグナリング・エンティティ間のチャネルのセキュリティを実装する必要があります。積極的にそれを処理するルールによって必要とされるようにメッセージを修正するためのプロトコルに参加中間ノードを持つことがサービスの品質及びその他のシグナリングプロトコルではよく知られており、実績のある概念です。この要件は、エンドツーエンドまたはシグナリングメッセージのネットワーク・ツー・ネットワークのセキュリティを排除するものではないことに注意してください。 NSISイニシエータとNSIS Responderの間のエンドツーエンドのセキュリティは非可変データフィールドの保護を提供するために使用することができます。ネットワーク・ツー・ネットワークセキュリティは、様々なホップを介してメッセージの保護を意味するが、エンドツーエンドの方法で、すなわち、特定のネットワーク上で保護されていません。
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.
アイデンティティの機密性がサポートされるべきです。これは、プライバシーを可能にし、パスに沿って敵盗聴によってシグナリングトラフィックを実体のプロファイリングを回避することができます。認証の方法で使用される同一性はまた、イニシエータが接続されているネットワークからの限られた範囲に隠すことができます。しかし、アイデンティティは、会計データを収集するために、アクセスネットワーク内のノードのための十分な情報を提供しなければなりません。
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.
ネットワークトポロジの隠蔽は、ネットワークのトポロジーを学ぶために、パスに沿ってエンティティを防ぐためにサポートされるかもしれません。このプロパティをサポートする診断機能と競合する可能性があります。
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.
シグナリングプロトコルは、サービス拒否攻撃の防止を提供する必要があります。効果的にサービス拒否攻撃を防ぐために使用されるセキュリティプロトコルメカニズムは、前要求エンティティを認証する状態設定要求を検証するために、低い計算の複雑さを持たなければならないことが必要です。さらにシグナリングプロトコルとNSISエンティティに大きなリソース消費を必要とすべきではない使用されるセキュリティメカニズムは、成功した認証の前に（例えばメインメモリまたは他の追加のメッセージ交換のために）行われます。
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.
これを防ぐために、ホップバイホップの方法でシグナリングメッセージの機密性は提供されるべきです。ほとんどのメッセージは、積極的にシグナリングプロトコルに参加するエンティティ、以来、ホップ単位で保護されなければならないことに注意してください、シグナリングメッセージを読んで、最終的に修正することができなければなりません。
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.
既存の状態が変更されなければならないときに一意に確立された状態を識別するためのセッション識別子を使用する必要があります。シグナリングプロトコルは、状態を変更するから敵を防ぐために、セキュリティ保護の手段を提供しなければなりません。
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.
ハンドオーバーは、無線ネットワークにおける必須の機能です。ハンドオーバ後、状態が完全にまたは部分的に起因するルート変更に再確立される必要があり得ます。再確立は、モバイルノード自体によって要求又は移動ノードが接続されているアクセスポイントによってトリガされてもよいです。最初のケースでは、シグナリングは、ハンドオーバー後の効率的な再確立を可能にしなければなりません。モバイルノードがサービスの中断やサービスの低下を経験しないように、再確立ハンドオーバ後、できるだけ迅速でなければなりません。再確立は、局所、およびエンドツーエンドのシグナリングを必要としないことべきです。
Hooks SHOULD be provided to enable efficient interworking between various protocols and techniques including the following listed.
フックは、列挙された以下を含む様々なプロトコルおよび技術との間の効率的なインターワーキングを可能にするために提供されるべきです。
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を使用する場合、一般的にフロー識別のために使用される情報の一部（例えば、トランスポートプロトコル情報及びポート）による暗号化にアクセス可能ではないかもしれません。
Signaling MUST NOT be constrained by charging models or the charging infrastructure used.
シグナリングは、モデルや使用充電インフラを充電することによって制約されてはなりません。
The NSIS protocol SHOULD be developed with respect to be able to collect usage records from one or more network elements.
NSISプロトコルは、1つまたは複数のネットワーク要素から使用レコードを収集することができるように関連して開発されるべきです。
An NSIS protocol SHOULD work with seamless handoff protocols such as context transfer and candidate access router (CAR) discovery.
NSISプロトコルは、コンテキスト転送および候補アクセスルータ（CAR）として発見シームレス・ハンドオフ・プロトコルで動作するはずです。
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は、特にそれがルート変更の場合に動作しなければならない、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は、これらの状況のいくつかのために働くかもしれません。特に、NSIS気づかないノードと他のルーティングの組み合わせは、従来の1は、いくつかの問題が発生します。非伝統的なルーティングは、例えば、ヘッダのハッシュ値に基づいて、ポート番号、宛先アドレス以外のIPヘッダフィールド、または分割トラフィックに基づいてルーティング決定。これらのルーティング環境は、シグナリングパスはデータパスよりも潜在的に異なることをもたらします。
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アーキテクチャは、ネットワークオペレータはNSISプロトコルメッセージを特定の輸送品質を割り当てることが可能にすべきです。シグナリングは、サービス拒否攻撃の可能性を開くように、この要件はトレードオフする待ち時間と、ネットワーク内のデバイス上で（シグナリングメッセージから）影響をシグナリングとの間のネットワークオペレータ手段だけでなく、義務を与えます。プロトコル設計から、この要件は、プロトコル・メッセージは、メッセージ優先順位の制御及び割り当てが行われ、少なくともここで、検出されるべきであると述べています。
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エンティティ間で使用する基本的なトランスポートプロトコルは、メッセージの整合性と信頼性の高い輸送を確実にすることができます。
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のシグナル伝達に関与する他のシステムへのさらなる損傷を引き起こしてはなりません。
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実体が誤動作ピアを検出することができるはずで。これは、NSIS開始剤またはシグナリングプロセスに関与する別のNSISエンティティに通知することができます。 NSISピアはバックアップNSISエンティティへの切り替え、例えば、問題自体を処理することができます。後者の場合、ノートにプライマリとバックアップのエンティティとの間の状態の同期が必要とされています。
Section 5.7 of this document provides security related requirements of a signaling protocol.
このドキュメントのセクション5.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.
人々のかなりの数は、ドキュメント、いくつかのアイデアを追加し、要件、などの議論に関与していますチャンパン・ファン（シーメンス）、クリシュナ・ポール（NEC）、マウリツィオ・モリーナ（NEC）、ミルコ・シュラム（シーメンス）、アンドレアス・シュレイダー（NEC）、ハンネス・ハルテンシュタイン（NEC）、ラルフ・シュミッツ（NEC）：私たちは完全に保証することなく、それらを一覧表示しますユルゲンQuittek（NEC）、盛久Momona（NEC）、ホルガー・カール（ベルリン工科大学）、暁明フー（ベルリン工科大学）、ハンス・ペーター・硫黄（シーメンス）、マティアスダイヤモンドベルク（シーメンス）、クリストフ・低マイヤー（シーメンス）、アンドレアスカッセラー（ウルム大学）、イリヤ・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.
いくつかのテキストおよび/またはテキストのためのアイデアは、要件、シナリオは以下の著者によって書かれたインターネットドラフトから撮影されています：デヴィッドパーテイン（エリクソン）、アンダース・バーグステン（テリアリサーチ）、マルク・グレイス（ノキア）、ゲオルギオスKaragiannis（エリクソン）、ユッカマナー（ヘルシンキ大学）、Pingのパン（ジュニパー）、Vlora Rexhepi（エリクソン）、ラースWestberg（エリクソン）、Haihong鄭（ノキア）。これらの中には、積極的にだけでなく、この文書に新しいテキストを貢献しています。
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.
この文書に影響を与える別のインターネットドラフトは、スヴェン・ヴァン・デン・ボッシュ、マールテン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.
テキストの変更についてもクォックホーチャン（ノーテル）に感謝します。そして最後に、徹底したADのレビューとIESGレビューコメントのハラルド・トバイット・アルベストランドとスティーブBellovin氏への感謝のために感謝アリソンマンキン。
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の（リソース予約）のためのシグナリングの特定の場合を考えます。
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.
私たちが見ているシナリオは、モバイル端末別のアクセスポイントへの1つのアクセスポイントから（MT）が変化する場合です。アクセスポイントは、別のQoSドメインに位置しています。私たちは、モバイルIPは、このシナリオでは、ネットワーク層でモビリティを処理し、モバイル端末のローミングは「高速ハンドオーバ」を提供するために、モバイルIPへの様々な拡張（すなわち、IETFの提案を）検討することを前提としています。目標は、提供保ち、及びハンドオーバの場合には、進行中の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技術、管理ドメイン）に変更される可能性があります。アクセスポイントは、ある特定のQoS技術（アクセス技術に依存しない）の範囲内であれば、私たちはこの内のQoS技術ハンドオフを呼び出します。インターQoS技術ハンドオフの場合には、例えばから1つの変化、イントサーブドメインへのDiffServ、しかしまだ同じアクセス技術を使用して。アクセスポイントは、異なるアクセス技術を使用している場合は最後に、我々は、技術間ハンドオフを呼び出します。
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またはネットワークが（下記参照）のハンドオフをトリガする可能性があることに注意してください。
- 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管理は別の（より良い適し）アクセスポイントを識別する場合には、自端末からのハンドオフを要求します。これは、二つの異なるプロバイダのネットワークが関与していることを場合に特に可能性が高くなります。現在のアクセスポイントベアラが消えたときに別の重要な例は、（例えば、イーサネットケーブルを除去します）。この場合には、NSIS開始剤は、基本的には、携帯端末上に配置されています。
- 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イニシエータは、ネットワーク内のシステム上に位置しています。
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.
- 他のプロトコルとのインターワーキングは、一つ又は他の形で考慮しなければなりません。例えば、それはハンドオーバーでモビリティシグナリングと異なる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 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.
モバイルネットワークでは、アドミッション制御プロセスだけでは、コールセットアップが生成するよりもはるかに多くの入場要求に対処する必要があります。例えば、GSM（移動通信用グローバルシステム）の場合、移動度は通常、呼ごとに1〜2ハンドオーバの平均値を生成します。同時に複数のセル（マクロダイバーシティ）への無線リンクを維持する必要がある（例えば、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.
ネットワークが過負荷されたときにさらに、新しい要求をブロックしながら、以前に確立されたフローのための状態を維持することが望ましいです。したがって、ハンドオーバに関連したリソース予約要求は、リソース予約のための新しい要求よりも高い優先順位を与えられるべきです。
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ドメインに無線ネットワークを接続するエッジノード（エッジルータ）との間の領域は、単一の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 classes or service instances in parallel with the IP layer QoS negotiation, to allocate resources within the radio access network.
1）無線ネットワークは、無線アクセス及び有線アクセスネットワークの両方によって提供されるQoSを調整する特殊なパラメータを使用して、独自のQoS技術を提供します。無線ネットワーク内のQoS技術のプロビジョニングは、ベアラクラス、サービスオプション、およびサービスインスタンスを呼び出すという点を中心に説明することができます。これらのQoS技術は、より高い層がQoSの要求をトリガする際に適切なパラメータで呼び出される必要があります。したがって、これらは、特定のベアラ・クラスまたはサービスインスタンスへの要求された上位層のQoSパラメータのマッピングを含みます。リソースの割り当て要求を無線システムを通過、およびおそらく他のQoSドメインIPレベルでのシグナリングによってトリガーされるかもしれません。一般的に、無線ネットワークの特定のメッセージは、無線アクセスネットワーク内のリソースを割り当てるために、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フォワーダによって解釈されます。 NSISイニシエータとNSIS Forwarderの最も効率的な配置は、無線ネットワークで決定されていないが、いくつかの潜在的なシナリオを想定することができます。 NSIS開始剤は、エンドホストに配置することができる（例えば、3Gユーザ装置（UE））、アクセス・ゲートウェイ、またはそのようなポリシー決定機能として、データパス上に直接ないノードで。 Access Gatewayは、エンドホストに代わって代理NSIS開始剤として作用することができます。そのQoSドメイン内のセッションに対してフローごと/集計リソースを制御ポリシー決定機能（例えば、3G無線ネットワーク）は、エンドホストのプロキシNSISイニシエータ又はアクセスゲートウェイとして機能してもよいです。 NSISイニシエータの配置に応じて、NSISフォワーダは、無線ネットワーク内の適切な箇所に配置されてもよいです。
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イニシエータとNSIS Forwarderのは、モビリティイベントを検出し、自律的に資源の再ネゴシエーションをトリガする必要があります。
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によってどちらの開発も検討を反映して1でされています。例は、それが様々な環境で使用することができるように、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 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.
3G無線アクセスシナリオが図1に示されているプロキシ呼状態制御機能（P-CSCF）は、（のみIPマルチメディアサブシステム（IMS）で使用される）アウトバウンドSIPプロキシです。 Access Gatewayは3Gワイヤレスドメインの出口ルータであり、それは、バックボーンIPネットワークのエッジルータ（ER）への無線アクセスネットワークを接続しています。ポリシー決定機能（PDF）は、例えば、セッション・レベルのサービスに関連してSIPをベアラレベルリソース割り当て/デアロケーションを制御する責任を負うエンティティです。ポリシー決定機能はまた、開閉ゲートをし、フロー単位のポリシーを設定するには、すなわち、ユーザトラフィックを許可するか禁止するためにアクセスゲートウェイを制御することができます。 （のみIMSで使用される）P-CSCF及びアクセス・ゲートウェイは、ネットワークリソース割り当て/割り当て解除の決定のために、ポリシー決定機能と通信します。ユーザ機器（UE）または移動局（MS）は、移動端末（MT）と端末装置（TE）、例えば、ラップトップから成ります。
+--------+
+--------->| P-CSCF |---------> SIP signaling
/ +--------+
/ SIP |
| |
| +-----+ +----------------+
| | PDF |<---------->| NSIS Forwarder |<--->
| +-----+ +----------------+
| | ^
| | |
| | |
| |COPS |
| | |
+------+ +---------+ |
| UE/MS|----------| Access |<-----------+ +----+
+------+ | Gateway |------------------| ER |
+---------+ +----+
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および/またはその他アクセスゲートウェイからのリソースの割り当て/割り当て解除要求を受信し、政策決定に応答します。従って、PDFは、バックボーンIPネットワークに向けてのシグナリングNSIS QoSを開始し、NSISイニシエータの機能をホストする候補エンティティであってもよいです。一方、UE / MSがUE / MSの代わりにプロキシNSIS開始剤として作用することができるNSISイニシエータ又はアクセスゲートウェイとして機能してもよいです。前者の場合、P-CSCF / PDFコーデックタイプとメディア記述からマッピングを実行する必要があるIPトラフィック記述子に（SIP / SDPシグナリングに由来します）。後者の場合、UE / MSは、NSIS開始剤としてメカニズムをシグナリング任意の適切なQoSを使用してもよいです。 Access GatewayはUE / MSに代わってプロキシNSISイニシエータとして動作している場合、それはNSISフォワーダーに要求を転送する前に、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 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).
NSISフォワーダは、現在の標準的な3Gワイヤレスアーキテクチャの一部ではありません。しかし、エンド・ツー・エンドのNSIS ForwarderのはNSISイニシエータはIPネットワークへのQoS接続を要求することができるように必要とされたQoS実現しています。前の例のように、NSISフォワーダは、IPネットワーク、すなわち、帯域幅パイプに予めプロビジョニングされたリソースのセットを管理することができ、およびNSISフォワーダは、これらのパイプに当たりフローアドミッション制御を実行します。このように、接続は、2つの3G無線アクセスネットワークとの間で行うことができ、したがって、エンド・ツー・エンドのQoSを実現することができます。この場合、NSISイニシエータとNSIS Forwarderのは、2つの別々の論理エンティティは明らかにされています。アクセスゲートウェイ及び/又は図1のエッジルータはセクション8.2シナリオ2で説明したようにNSISイニシエータの配置に応じて、NSISフォワーダ機能を含んでいてもよいです。このユースケースは明らかNSISイニシエータとNSISフォワーダ間のNSISのQoSシグナリングプロトコルの必要性を示しています。そのようなプロトコルの重要な用途は、モバイルホストと相手（例えば、エンドホストまたはコンテンツサーバ）との間の特定のQoS特性との接続のエンドツーエンドの確立におけるその使用であってもよいです。
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つの部分から構成さこの図は、無線ネットワークのアーキテクチャの概要としてではなく、無線ネットワークにおける概念のQoSドメインを示すように見えるべきではないことを、図2注に示すように。
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).
このシナリオでは、モバイルホストがローミングすることができ、基地局/アクセスルータ間のハンドオーバ手順を実行します。このシナリオではNSISのQoSプロトコルは、基地局とゲートウェイ（GW）との間に印加することができます。この場合、GWは、ローカルハンドオーバ・アンカー・ポイントと見なすことができます。さらに、このシナリオではNSISのQoSプロトコルは、2つのGWの間で、又は二エッジルータ（ER）との間のいずれかで適用することができます。
|--|
|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
<---------------------------------------->
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）無線ネットワークの有線部分：これは、基地局/アクセスルータに最も近いネットワークの一部です。いくつかの部分は、論理的にエンドユーザーデータのトンネリングを行うが、それは、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 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.
- ネットワークは、モビリティをサポートしている必要があります。多くの無線ネットワークは、ソフトとハードハンドオーバ手順の組み合わせを提供することができます。ハンドオーバが発生した場合、予約は新しいパスに確立する必要があります。確立時間が秒間長く確立時間は、無線ネットワークのパフォーマンスを低下させるので、できるだけ短くなければなりません。また、無線スペクトルの最大限利用するため、頻繁なハンドオーバの動作が必要とされます。
- 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.
- そのようなネットワーク内の有線伝送は、高価な専用線の比較的高いボリュームを含みます。オーバープロビジョニングは、したがって、非常に高価であるかもしれません。
- 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つのネットワーク部分のそれぞれに必要になる可能性があります。
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イニシエータが異なるエンティティによってトリガーされる可能性があることを意味動きを、開始するエンティティオープンであることに注意してください。
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）はSを変更することなく変更されることを意味します。
2) The trigger of the session move might be the user or any other party involved in the session.
2）セッション移動のトリガーは、ユーザーまたはセッションに関係するその他の当事者であるかもしれません。
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）フロー仕様は、ソースのためだけでなく、フローの宛先のネットワークアドレスと異なるアドレスのセットを含むより複雑です。
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.
QoSを提供するために、2つの以上のコアネットワークとの間のシグナリングは、このシナリオで処理されます。また、これは管理境界を超えるシグナルコアへのアクセスが含まれる場合があります。前のと比較すると、それは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のように、最も可能性の高いシグナル伝達が、集計に基づいています。
3) Authorization: It is critical that the NSIS Initiator is authorized to perform a QoS path setup.
3）許可：NSISイニシエータが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）説明責任：シグナリングは、したがって、会計との相互運用が利用できるようにする必要があり、ためにお金を充電するエンティティとして使用されるかもしれないことに注意することが重要です。
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).
（呼が単一のRTPフローを運ぶために使用される5タプルとして定義される）コールアドミッション制御当たり4。
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 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.
項目3は、それが合理的なスケーリング特性を持っているように見えますように、しかし、そのスケーリング特性は、比較的少数のPSTNのGWがある場合に有効である、最初は魅力的です。 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は、最も一般的なケースです。しかし、それは最も困難なスケーリング問題があります。ここでの目的は、スケーラブルなフローごとのアドミッション制御プロトコルまたはプロトコルスイートを開発することができるように、項目4の要件を配置することです。
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.
フロー毎のシグナリングが個々のIPエンドポイントまで延びている場合には、このシナリオでは、ケーブル、DSL、無線または他のアクセスネットワーク上のIP電話の包含を可能にします。
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タプル定義されたフロー帯域幅およびQoSの要件のために。 5タプルがマスク/ワイルドカードを含むかもしれないことに注意してください。アクセスネットワークは、そのローカルポリシーとアクセス技術の具体的な詳細に応じて、このフローを認めています。
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.
エッジルータ（すなわち、境界ノード）では、流れはおそらく、外部のポリシーサーバを含む、任意の認証プロセスを再度、認められます。 PSTN GWとポリシーサーバとルータとの間の関係と、ポリシーサーバはNSISの範囲外であることに留意されたいです。エッジルータは、おそらくいくつかのアグリゲーション技術を使用して、ネットワークのコアへの流れを認めます。
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.
エッジルータは、いくつかの集計にアドミッション制御の決定を行って内部ノードでは、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ホストツーホスト信号のいずれか、無視されるか、または不可視されるべきです。
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シグナリングプロトコルの使用事例の一つは、QoSをサポートするIPネットワークとPSTNゲートウェイを相互接続するシナリオです。
Four different scenarios are considered here.
四つの異なるシナリオがここでは考慮されています。
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シグナリングが使用されます。メディアゲートウェイ（MG）はNSISイニシエータとエッジルータ（ER）として動作します。この場合、NSIS Forwarderのだろう。したがって、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フォワーダは、メディアゲートウェイコントローラ（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フォワーダ間で使用されます。
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.アウトオブバンド複数のドメイン間のシグナリング、（MGCに統合されてもよい）NSISフォワーダは、次のドメインのNSISフォワーダをトリガします。
When the out-of-band QoS signaling is used the Media Gateway Controller (MGC) will be acting as the NSIS Initiator.
アウトオブバンドのQoSシグナリングを使用する場合はメディアゲートウェイコントローラ（MGC）はNSISイニシエータとして動作します。
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番目のシナリオでは、音声プロバイダがネットワークプロバイダからリースされたトラフィックトランクのセットを管理します。 MGCは、この場合にはアドミッション制御を行います。 NSISフォワーダがNSISイニシエータとNSISフォワーダの両方として作用するため、何NSISシグナリングが必要とされません。このシナリオは、図3に示されています。
+-------------+ ISUP/SIGTRAN +-----+ +-----+
| SS7 network |---------------------| MGC |--------------| SS7 |
+-------------+ +-------+-----+---------+ +-----+
: / : \
: / : \
: / +--------:----------+ \
: MEGACO / / : \ \
: / / +-----+ \ \
: / / | NMS | \ \
: / | +-----+ | \
: : | | :
+--------------+ +----+ | bandwidth pipe (SLS) | +----+
| PSTN network |--| MG |--|ER|======================|ER|-| MG |--
+--------------+ +----+ \ / +----+
\ QoS network /
+-------------------+
Figure 3: PSTN trunking gateway scenario
図3：PSTNトランクゲートウェイシナリオ
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.
第三のシナリオでは、音声プロバイダは、ネットワーク内のトラフィックトランクをリースすることはありません。別のエンティティは、トラフィックトランクスをリースすることができ、フローごとのアドミッション制御を行うためにNSISフォワーダを使用することができます。この場合、NSISシグナリングはMGCとここで別個のボックスであるNSISフォワーダ、の間で使用されています。したがって、MGCは、NSIS開始剤として作用します。このシナリオは、図4に示されています。
+-------------+ ISUP/SIGTRAN +-----+ +-----+
| SS7 network |---------------------| MGC |--------------| SS7 |
+-------------+ +-------+-----+---------+ +-----+
: / : \
: / +-----+ \
: / | NF | \
: / +-----+ \
: / : \
: / +--------:----------+ \
: MEGACO : / : \ :
: : / +-----+ \ :
: : / | NMS | \ :
: : | +-----+ | :
: : | | :
+--------------+ +----+ | bandwidth pipe (SLS) | +----+
| PSTN network |--| MG |--|ER|======================|ER|-| MG |--
+--------------+ +----+ \ / +----+
\ QoS network /
+-------------------+
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.
第四のシナリオでは、複数の輸送ドメインが関与しています。発信ネットワークではMGCのどちらかは、オーバーレイ・ネットワークのリソースに概要を有していても、別のNSISフォワーダーは、概要を説明しています。したがって、発信元ドメインのこれに応じて、MGCまたはNSISフォワーダのいずれかが、次のドメインのNSISフォワーダ接触します。 MGCは常にNSISイニシエータとして機能し、また、最初のドメインにNSISフォワーダーとして機能することができます。
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ネットワークからの保証サービスを要求します。私たちは、アプリケーションが何らかの形でネットワークサービスを指定することが可能であることを、ここで想定しています。ここでの特徴は、多くのホストがそれを行うかもしれないことですが、要求されたサービスは、（アクセス回線で囲まれた）低容量であること。ネットワークのコアでこのサービスを要求するアプリケーションの数のスケーリングの問題があることに注意してください。
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.
仮想プライベートネットワーク（VPN）では、トンネルの様々な、その端部との間で使用される可能性があります。これらのトンネルは、例えばIPSecの、GRE、およびIP-IPである可能性があります。 VPNの中で最も重要な問題の一つは、フローを識別し、どのような品質の流れが取得される方法に関連しています。フロー識別は、トランスポート・プロトコル・ポート番号のとりわけ成るかもしれません。トランスポートプロトコル情報が暗号化されているので、IP-SECトンネルでは、これは問題であろう。
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 VPNの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が使用する可能性があるプレミアムサービスに加えて、帯域幅やサービスの他のタイプを要求する可能性があります。
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ネットワークを介して合図することをお勧めします。顧客ではなく定額料金を支払うよりも、需要とのネットワークコストを変更したい場合には、このようなシグナリングは有用である可能性があります。そのようなシグナルは、二つのCPEルータとの間に存在します。中間アクセスとエッジルータは、エンドポイントではなくPSTNのGWと記述するために使用される5タプルよりCPEトンネルエンドポイントであることを除いてPSTN GWシナリオに対応するルータによって実行される同一の正確なコールアドミッション制御、認証および集約機能を実行しますRTPフローを一意トンネルを識別するために、対応するフロー仕様に置き換えられます。トンネルは、任意の種々のものであってもよい（例えば、IP-SEC、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は、実際に顧客がさまざまなエンドポイントに、その後のNSISシグナリングによって、顧客の缶セットアップVPNを意味VPNを、管理の一部を可能にするであろう。プラストンネルエンドポイントは、必ずしもアプリケーションにバインドされていません。顧客の管理者は、NSISシグナリングをトリガー1かもしれません。
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 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.
フローごとシグナリングの場合には、PEルータは、フロー仕様で指定された宛先にトラフィックを運ぶトンネルの帯域幅要求をマッピングしなければなりません。このようなトンネルは、流れが許可されなければならないの集合体の一員です。この場合、アドミッション制御の動作は、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.
サイトごとにシグナリングの場合は、サイトが識別される必要があるであろう。これは、IPプレフィックスを通じて、そのサイトでのサービスネットワークを指定することによって達成することができます。この場合、アドミッション制御機能は、問題のサイトに接続されたPEルータの集合体上で行われます。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[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の機能的な仕様"。、RFC 2205、1997年9月。
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002.
[RFC3234]大工、B.とS.つば、 "のMiddleboxes：分類と課題"、RFC 3234、2002年2月。
Marcus Brunner (Editor) NEC Europe Ltd. Network Laboratories Kurfuersten-Anlage 36 D-69115 Heidelberg Germany
マーカス・ブルナー（編集）NECヨーロッパ社ネットワーク研究所Kurfuerstenコンディショニング36 D-69115ハイデルベルク、ドイツ
EMail: brunner@netlab.nec.de
メールアドレス：brunner@netlab.nec.de
Robert Hancock Roke Manor Research Ltd Romsey, Hants, SO51 0ZN United Kingdom
ロバート・ハンコックRokeマナーリサーチ株式会社ロムジー、ハンツ、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マナーリサーチ株式会社ロムジー、ハンツ、SO51 0ZNイギリス
EMail: eleanor.hepworth@roke.co.uk
メールアドレス：eleanor.hepworth@roke.co.uk
Cornelia Kappler Siemens AG Berlin 13623 Germany
コルネリアKapplerシーメンスAGベルリン13623ドイツ
EMail: cornelia.kappler@siemens.com
メールアドレス：cornelia.kappler@siemens.com
Hannes Tschofenig Siemens AG Otto-Hahn-Ring 6 81739 Munchen Germany
ハンネスTschofenigシーメンスAGオットー・ハーンリング6 81739ミュンヘンドイツ
EMail: Hannes.Tschofenig@mchp.siemens.de
メールアドレス：Hannes.Tschofenig@mchp.siemens.de
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.
著作権（C）インターネット協会（2004）。この文書では、BCP 78に含まれる権利、ライセンスおよび制限があり、そこに記載された以外、作者は彼らのすべての権利を保有します。
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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。