[要約] RFC 3726は、信号プロトコルの要件に関する規格であり、信号プロトコルの設計と実装に関するガイドラインを提供します。その目的は、信号プロトコルの信頼性、拡張性、相互運用性を確保することです。
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）The Internet Society（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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、BCP 14、RFC 2119 [キーワード]に記載されているとおりに解釈されます。
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 Initiator（NI）：NSISシグナリングを開始してネットワーク状態を設定または操作するNSISエンティティ。
NSIS Responder (NR): NSIS Entity that terminates NSIS signaling and can optionally interact with applications as well.
NSIS Responder（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).
フロー：特定のパケットレベルの処理が提供されるトラフィックストリーム（2つのエンドシステム間の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.
サービス：あるエンティティから提供され、別のエンティティによって消費される一般的なもの。リソースを割り当てることで構築できます。ネットワークはユーザーに提供できます。または、ネットワークノードはパケットに提供できます。
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.) 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レスポンダー。次のセクションでは、仮定/除外に関するさらなる声明を示します。
The main elements are:
主な要素は次のとおりです。
1. Something that starts the request for state to be set up in the network, the NSIS Initiator.
1. NSISイニシエーターであるネットワークで州のリクエストを開始するもの。
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.
2. シグナリングパス、NSISフォワーダーに沿ってさらに状態を管理するのに役立つもの。
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レスポンダー、およびおそらくシグナリングパス、エッジツーエッジまたはエンドツーエンドの1つ以上のNSISフォワーダーと相互作用します。
3. Something that terminates the signaling path, the NSIS Responder.
3. シグナリングパス、NSISレスポンダーを終了するもの。
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.
4. シグナリングパスは、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つのリンクが含まれているという特別な場合を除く）。ドメインは管理エンティティであると想定されています。したがって、セキュリティ要件は、ドメイン間およびドメイン内のシグナリングに異なる適用を適用する可能性があります。どちらの場合も、このドキュメントで扱います。
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フォワーダーはすべてのルーターに配置される可能性があります。後者の場合、QoSプロビジョニングは、さらなるシグナリングなしでローカル実装依存の方法で実行できますが、リモートNSISフォワーダーの場合、パスに沿ったルーターを制御するためにプロトコルが必要になる場合があります。このプロトコルは、エンドツーエンド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エンティティの発見には、適切に対処する必要があるセキュリティの影響があります。一部のセキュリティメカニズム（つまり、Kerberos、事前に共有された秘密）の場合、他のエンティティのアイデンティティを知る必要があります。したがって、発見メカニズムは、このアイデンティティを学習する手段を提供する場合があり、その後、必要なキーとパラメーターを取得するために後に使用されます。
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.
2. シグナルプロトコルに必要な交渉機能と情報セマンティクスに関する要件を明確にすることを除いて、輸送/アプリケーションとネットワークレイヤー間の相互作用のための特定のメカニズム（APIなど）は考慮されません。
3. Specific mechanisms and protocols for provisioning or other network control functions within a domain/subdomain are not considered. The goal is to reuse existing functions and protocols unchanged. However, NSIS itself can be used for signaling within a domain/subdomain.
3. ドメイン/サブドメイン内のプロビジョニングまたはその他のネットワーク制御機能のための特定のメカニズムとプロトコルは考慮されません。目標は、既存の機能とプロトコルを変更せずに再利用することです。ただし、NSI自体は、ドメイン/サブドメイン内のシグナル伝達に使用できます。
For instance in the QoS example, it means that the setting of QoS mechanisms in a domain is out of scope, but if we have a tunnel, NSIS could also be used for tunnel setup with QoS guarantees. It should be possible to exploit these mechanisms optimally within the end-to-end context. Consideration of how to do this might generate new requirements for NSIS however. For example, the information needed by a NSIS Forwarder to manage a radio subnetwork needs to be provided by the NSIS solution.
たとえば、QoSの例では、ドメイン内のQoSメカニズムの設定が範囲外であることを意味しますが、トンネルがある場合、NSIはQoS保証付きのトンネルセットアップにも使用できます。これらのメカニズムをエンドツーエンドのコンテキスト内で最適に活用することが可能であるはずです。ただし、これを行う方法を考慮すると、NSIの新しい要件が生成される場合があります。たとえば、無線サブネットワークを管理するためにNSISフォワーダーが必要とする情報は、NSISソリューションによって提供される必要があります。
4. Specific mechanisms (APIs and so on) for interaction between the network layer and underlying provisioning mechanisms are not considered.
4. ネットワークレイヤーと基礎となるプロビジョニングメカニズム間の相互作用のための特定のメカニズム（APIなど）は考慮されません。
5. Interaction with resource management or other internal state management capabilities is not considered. Standard protocols might be used for this. This may imply requirements for the sort of information that should be exchanged between the NSIS entities.
5. リソース管理またはその他の内部州管理機能との相互作用は考慮されていません。これには標準プロトコルが使用される場合があります。これは、NSISエンティティ間で交換されるべき種類の情報の要件を意味する場合があります。
6. Security implications related to multicasting are outside the scope of the signaling protocol.
6. マルチキャストに関連するセキュリティへの影響は、シグナリングプロトコルの範囲外です。
7. Service definitions and in particular QoS services and classes are out of scope. Together with the service definition any definition of service specific parameters are not considered in this document. Only the base NSIS signaling protocol for transporting the service information are addressed.
7. サービスの定義、特にQoSサービスとクラスは範囲外です。サービス定義とともに、このドキュメントでは、サービス固有のパラメーターの定義は考慮されていません。サービス情報を輸送するためのベースNSISシグナル伝達プロトコルのみに対処します。
8. Similarly, specific methods, protocols, and ways to express service information in the Application/Session level are not considered (e.g., SDP, SIP, RTSP, etc.).
8. 同様に、特定の方法、プロトコル、およびアプリケーション/セッションレベルでサービス情報を表現する方法は考慮されません（例：SDP、SIP、RTSPなど）。
9. The specification of any extensions needed to signal information via application level protocols (e.g., SDP), and the mapping to NSIS information are considered outside of the scope of NSIS working group, as this work is in the direct scope of other IETF working groups (e.g., MMUSIC).
9. アプリケーションレベルのプロトコル（例：SDP）を介して情報を信号に信号を送るために必要な拡張機能の仕様、およびNSIS情報へのマッピングは、NSISワーキンググループの範囲外であるため、他のIETFワーキンググループの直接的な範囲にあるため、たとえば、mmusic）。
10. Handoff decision and trigger sources: An NSIS protocol is not used to trigger handoffs in mobile IP, nor is it used to decide whether to handoff or not. As soon as or in some situations even before a handoff happened, an NSIS protocol might be used for signaling for the particular service again. The basic underlying assumption is that the route comes first (defining the path) and the signaling comes after it (following the path). This doesn't prevent a signaling application at some node interacting with something that modifies the path, but the requirement is then just for NSIS to live with that possibility. However, NSIS must interwork with several protocols for mobility management.
10. ハンドオフの決定とトリガーソース：NSISプロトコルは、モバイルIPのハンドオフをトリガーするために使用されず、ハンドオフのかどうかを決定するためにも使用されません。ハンドオフが発生する前であっても、または状況によっては、NSISプロトコルが特定のサービスのシグナリングに再び使用される可能性があります。基本的な根本的な仮定は、ルートが最初に来る（パスを定義する）ことであり、シグナル伝達がその後（パスに従っている）ということです。これは、パスを変更するものと相互作用する一部のノードでのシグナリングアプリケーションを妨げるものではありませんが、要件はNSIがその可能性とともに生き続けるためだけです。ただし、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
ソリューションの2つの一般的な（および潜在的に矛盾する）目標は、非常に幅広いシナリオに適用できることであり、同時に、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.
特定のプロトコル属性、特にパフォーマンス特性が特に重要な展開条件を指すためのいくつかの特定の要件の議論では、「アクセス」と「コア」が非公式に。具体的には、「アクセス」とは、ユーザーとセッションが少ない容量の低いネットワークを指します。「Core」とは、多数のユーザーとセッションを含む大容量ネットワークを指します。
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.
信号プロトコルは、輸送される制御情報から明確に分離する必要があります。これにより、ソリューションのこれら2つの側面の独立した開発が提供され、アプリケーションレイヤーのプロトコル、既存のプロトコル、または将来開発されているプロトコルなど、この制御情報を他のプロトコル内で実施できます。情報の輸送で得られた柔軟性により、さまざまなシナリオで同じプロトコルの適用性が可能になります。
However, note that the information carried needs to be standardized; otherwise interoperability is difficult to achieve.
ただし、運ばれる情報は標準化する必要があることに注意してください。それ以外の場合、相互運用性を達成することは困難です。
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.
このセクションには、サポートされる可能性のあるシグナル伝達フローに関連する要件が含まれています。たとえば、どのエンティティ（エンドシステム、ルーター、ミドルボックス、管理システム）の間のフローパスのどの部分で、どの方向にありますか。
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）にルーティングされるパス分解シグナル伝達モードをサポートする場合があります。ノード（NES）は、データパス上にあると想定されていませんが、それを認識しています。
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.
言い換えれば、NSIは階層的なシナリオで動作するはずです。ここでは、NSISシグナル伝達を使用して大きなパイプ/トランクがセットアップされますが、その大きなパイプ/トランク内で実行されるフローもNSIを使用してセットアップされます。
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エンティティは、おそらく通知に反応する可能性が高いことです。たとえば、エラー通知を取得した場合、すべてが問題ない場合でも、状態を消去する可能性があります。したがって、通知は、通知の送信者とその受信者との間のセキュリティ関連に依存する可能性があります。ホップバイホップのセキュリティメカニズムが選択されている場合、これは、通知を逆パスで送信する必要があることを意味します。
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に代わって国家の設立を認めなければなりません。国家の設立を拒否することは、国家の設立を拒否したことによって否定的な承認を得て返信する必要があります。NIに送信する必要があります。シグナリングアプリケーションに応じて、（正または負の）通知は、さらに上流のNESを通過する必要がある場合があります。状態を設定する拒否の理由に関する情報が利用可能になる場合があります。たとえば、リソース予約の例では、否定的な答えとともに、利用可能なリソースの量も返される場合があります。
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フォワーダーの識別が搭載される場合があります。ただし、Edgeの識別は、End Host（NSIS Initiator）に表示されるべきではなく、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イニシエーターが信号情報の可変性を制御できるはずです。たとえば、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.
アドレス指定または識別状態は、フロー識別子（フローエンドポイント、トポロジーアドレス）とは無関係でなければなりません。モビリティエリアのさまざまなシナリオには、ハンドオフに起因するフローがエンドポイントなどが変更された可能性があるため、この独立性が必要です。また、いくつかのプロキシベースのシグナル伝達方法は、このような独立から利益を得ていますが、これらはNSIの作業項目をチャーターしたものではありません。
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は、いくつかのマイクロフローのシグナリング情報を1つのシグナリングメッセージにグループ化する場合があります。これの目標は、セットアップ遅延の観点からの最適化であり、並行して発生する可能性があります。これにより、アプリケーションが一度にいくつかのフローを要求するのに役立ちます。また、潜在的なリフレッシュ（ソフトステートソリューションの場合）は、グループ化から利益を得る可能性があります。
However, the network need not know that a relationship between the grouped flows exists. There MUST NOT be any transactional semantic associated with the grouping. It is only meant for optimization purposes.
ただし、ネットワークは、グループ化されたフロー間の関係が存在することを知る必要はありません。グループに関連付けられたトランザクションセマンティックはありません。最適化の目的のみを目的としています。
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 Initiator、NSIS Forwarder、およびNSIS Responder）が受信したメッセージの数でスケーラブルでなければなりません。主な懸念は、多数のメッセージが到着するネットワークの中核にあります。
It MUST be scalable in number of hand-offs in mobile environments. This mainly applies in access networks, because the core is transparent to mobility in most cases.
モバイル環境でのハンドオフ数でスケーラブルでなければなりません。これは、ほとんどの場合、コアがモビリティに対して透明であるため、主にアクセスネットワークに適用されます。
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.
具体的には、NSIはインターネットスケールの展開で動作する必要があり、ホストによるシグナリングの使用が普遍的になります。要件5.2.4には、解釈なしでネットワークを介して透過的に信号を送る機能が必要であることに注意してください。さらに、要件5.6.1には、集約する機能がリストされています。さらに、要件5.5.4は、NSIがデバイスの負荷を制限できるはずだと述べています。基本的に、シグナル伝達の性能は、過負荷条件下で壊滅的にではなく、優雅に劣化する必要があります。
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は、状態の低下セットアップを可能にする必要があります。これは、短い時間スケール（モバイル環境でのハンドオーバーなど）で状態のセットアップが必要なシナリオ、または人間の相互作用がすぐに関係する（たとえば、音声通信セットアップの遅延）のみが必要です。
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負荷、メモリスペース、シグナリング帯域幅の消費、信号強度）を制約する機能を提供する必要があります。理由の1つは、プロトコルの取り扱いがインテリア（コア）ノードに最小限の影響を与える必要があることです。
This can be achieved by many different methods. Examples include message aggregation, header compression, minimizing functionality, or ignoring signaling in core nodes. NSIS may choose any method as long as the requirement is met.
これは、さまざまな方法で実現できます。例には、メッセージ集約、ヘッダー圧縮、機能の最小化、またはコアノードのシグナル伝達の無視が含まれます。NSISは、要件が満たされている限り、任意の方法を選択できます。
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レスポンダーがデータストリームの最後のポイントにない可能性があることを意味します。
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レスポンダーは、状態の変化を開始できるはずです。リソースの予約の例では、これはしばしばリソースの再交渉と呼ばれます。ローカルリソース不足（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.
単方向と双方向の状態の両方のセットアップが可能です。双方向の状態のセットアップでは、双方向データフローの状態がセットアップされていることを意味します。双方向のデータフローには同じエンドポイントがありますが、2つの方向のパスは同じである必要はありません。
The goal of a bi-directional state setup is mainly an optimization in terms of setup delay. There is no requirements on constrains such as use of the same data path etc.
双方向の状態セットアップの目標は、主にセットアップ遅延の観点から最適化です。同じデータパスなどの使用など、制約に関する要件はありません。
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レスポンダーの間のエンドツーエンドのセキュリティを使用して、不可能なデータフィールドの保護を提供することができます。ネットワークからネットワークへのセキュリティとは、さまざまなホップを介したメッセージの保護を指しますが、特定のネットワークで保護されているエンドツーエンドの方法ではありません。
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.
IDの機密性をサポートする必要があります。パスに沿った信号トラフィックを攻撃することにより、プライバシーを可能にし、エンティティのプロファイリングを回避します。認証のプロセスで使用されるIDは、イニシエーターが添付されているネットワークから限られた範囲で隠される場合があります。ただし、IDは、アクセスネットワーク内のノードに十分な情報を提供して、会計データを収集する必要があります。
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シグナル伝達を破るべきではありません。NSIは、これらの状況のいくつかで機能する場合があります。特に、NSIの組み合わせが気づいていないノードとそれ以外のノードをルーティングすると、いくつかの問題が発生します。非伝統的なルーティングには、たとえば、ポート番号、宛先アドレスよりもその他の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.
ドキュメントの議論にかなりの多くの人々が関与しており、いくつかのアイデア、要件などを追加します。完全性を保証することなくそれらをリストします：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（Berlin）、Xiaoming FU（技術大学ベルリン）、Hans-Peter Schwefel（Siemens）、Mathias Rautenberg（Siemens）、Christoph Niedermeier（Siemens）、Andreas Kassler（Ulm of Ulm）、Ilya 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.
テキスト、要件、シナリオのテキストおよび/またはアイデアは、次の著者によって書かれたインターネットドラフトから取得されています：David Partain（Ericsson）、Anders Bergsten（Telia Research）、Marc Greis（Nokia）、Georgios Karagiannis（Ericsson）、ジュッカマナー（ヘルシンキ大学）、ピンパン（ジュニパー）、vlora rexhepi（エリクソン）、ラースウェストバーグ（エリクソン）、ハイホンチェン（ノキア）。それらのいくつかは、このドキュメントにも積極的に新しいテキストを提供しています。
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.
この文書に影響を与える別のインターネットドラフトは、スベンヴァンデンボッシュ、マルテンブックリ、およびダニーゴデリス（すべてのアルカテル）によって書かれています。これらの人々は新しいテキストも貢献しました。
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.
テキストの変更については、Kwok Ho Chan（Nortel）にも感謝します。そして最後に、徹底的な広告レビューをしてくれたAlison Mankinに感謝し、IESGレビューのコメントをしてくれたHarald Tveit AlvestrandとSteve 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.
私たちが見ているシナリオは、モバイル端末（MT）があるアクセスポイントから別のアクセスポイントに変更される場合です。アクセスポイントは、別々のQoSドメインにあります。このシナリオのネットワークレイヤーのモビリティを処理するモバイルIPを想定し、モバイルターミナルをローミングするために「高速ハンドオーバー」を提供するために、モバイルIPのさまざまな拡張機能（IETF提案）を検討します。達成される目標は、ハンドオーバーの場合に継続的なIPセッションに要求されたQOを提供、維持、および適応させることにあります。さらに、IETF内のさまざまな「高速ハンドオーバー」提案をサポートするために、古い接続を介した新しいドメインとのQoSパラメーターの交渉が必要になる場合があります。
The entities involved in this scenario include a mobile terminal, access points, an access network manager, and communication partners of the MT (the other end(s) of the communication association). From a technical point of view, terminal mobility means changing the access point of a mobile terminal (MT). However, technologies might change in various directions (access technology, QoS technology, administrative domain). If the access points are within one specific QoS technology (independent of access technology) we call this intra-QoS technology handoff. In the case of an inter-QoS technology handoff, one changes from e.g., a DiffServ to an IntServ domain, however still using the same access technology. Finally, if the access points are using different access technologies we call it inter-technology hand-off.
このシナリオに関与するエンティティには、モバイル端末、アクセスポイント、アクセスネットワークマネージャー、およびMTのコミュニケーションパートナー（通信協会のもう一方の端）が含まれます。技術的な観点から、ターミナルモビリティとは、モバイル端末（MT）のアクセスポイントを変更することを意味します。ただし、テクノロジーはさまざまな方向に変化する可能性があります（アクセステクノロジー、QoSテクノロジー、管理ドメイン）。アクセスポイントが1つの特定のQoSテクノロジー（アクセステクノロジーに依存しない）内にある場合は、このIntra-QOSテクノロジーハンドオフと呼びます。QOS間のテクノロジーのハンドオフの場合、たとえば、diffservからintservドメインに変更されますが、同じアクセステクノロジーを使用しています。最後に、アクセスポイントがさまざまなアクセステクノロジーを使用している場合は、テクノロジー間ハンドオフと呼ばれます。
The following issues are of special importance in this scenario:
このシナリオでは、次の問題が特に重要です。
1) Handoff decision
1) ハンドオフ決定
- The QoS management requests handoff. The QoS management can decide to change the access point, since the traffic conditions of the new access point are better supporting the QoS requirements. The metric may be different (optimized towards a single or a group/class of users). Note that the MT or the network (see below) might trigger the handoff.
- QoS管理はハンドオフを要求します。QoS管理は、新しいアクセスポイントのトラフィック条件がQoS要件をよりよくサポートしているため、アクセスポイントを変更することを決定できます。メトリックは異なる場合があります（単一またはグループ/クラスのユーザーに向けて最適化されています）。MTまたはネットワーク（以下を参照）がハンドオフをトリガーする可能性があることに注意してください。
- The mobility management forces handoff. This can have several reasons. The operator optimizes his network, admission is no longer granted (e.g., emptied prepaid condition). Or another example is when the MT is reaching the focus of another base station. However, this might be detected via measurements of QoS on the physical layer and is therefore out of scope of QoS signaling in IP. Note again that the MT or the network (see below) might trigger the handoff.
- モビリティ管理はハンドオフを強制します。これにはいくつかの理由があります。オペレーターは自分のネットワークを最適化し、入場はもはや許可されていません（たとえば、空のプリペイド条件など）。または、別の例は、MTが別の基地局の焦点に到達しているときです。ただし、これは物理層上のQoSの測定によって検出される可能性があるため、IPでのQoSシグナル伝達の範囲外です。MTまたはネットワーク（以下を参照）がハンドオフをトリガーする可能性があることに再度注意してください。
- This scenario shows that local decisions might not be enough. The rest of the path to the other end of the communication needs to be considered as well. Hand-off decisions in a QoS domain do not only depend on the local resource availability, e.g., the wireless part, but involve the rest of the path as well. Additionally, decomposition of an end-to-end signaling might be needed, in order to change only parts of it.
- このシナリオは、現地の決定だけでは不十分である可能性があることを示しています。通信のもう一方の端へのパスの残りの部分も考慮する必要があります。QoSドメインでのハンドオフの決定は、現地のリソースの可用性、たとえばワイヤレス部分に依存するだけでなく、パスの残りの部分も関与します。さらに、その一部のみを変更するには、エンドツーエンドシグナル伝達の分解が必要になる場合があります。
2) Trigger sources
2) ソースをトリガーします
- Mobile terminal: If the end-system QoS management identifies another (better-suited) access point, it will request the handoff from the terminal itself. This will be especially likely in the case that two different provider networks are involved. Another important example is when the current access point bearer disappears (e.g., removing the Ethernet cable). In this case, the NSIS Initiator is basically located on the mobile terminal.
- モバイル端末：最終システムQoS管理が別の（より適切な）アクセスポイントを識別した場合、端末自体からハンドオフを要求します。これは、2つの異なるプロバイダーネットワークが関与している場合に特にありそうです。別の重要な例は、現在のアクセスポイントベアラーが消えるときです（たとえば、イーサネットケーブルの削除）。この場合、NSISイニシエーターは基本的にモバイル端末にあります。
- 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本のハンドオーバーを生成します。第3世代のネットワーク（UMTなど）の場合、いくつかのセルへの無線リンクを同時に（マクロダイバーシティ）保持する必要がある場合、ハンドオーバー率は大幅に高くなります。
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:
QOに関するこのような環境の問題には次のものがあります。
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フォワーダーの最も効率的な配置は、ワイヤレスネットワークでは決定されていませんが、いくつかの潜在的なシナリオを想像できます。NSISイニシエーターは、エンドホスト（例：3Gユーザー機器（UE））、アクセスゲートウェイ、またはポリシー決定機能などのデータパスに直接ないノードに配置できます。アクセスゲートウェイは、エンドホストに代わってプロキシ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フォワーダーは、モビリティイベントを検出し、リソースの再交渉を自律的にトリガーする必要があります。
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.
次の例は、3G環境でNSISシグナル伝達プロトコルが使用される可能性のある純粋な仮説シナリオです。潜在的な統合がどのように行われるかを課すことはありません。3GPPアーキテクチャからの用語は、特異性を与えるために、しかし仮想設計では、3GPPによる開発もレビューも反映していない仮想設計で使用されます（以下でP-CSCF、IMS、以下で拡張）。この例は、さまざまな環境で使用できるように、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）は、アウトバウンドSIPプロキシ（IPマルチメディアサブシステム（IMS）でのみ使用）です。アクセスゲートウェイは、3Gワイヤレスドメインの出口ルーターであり、バックボーンIPネットワークのエッジルーター（ER）にラジオアクセスネットワークを接続します。ポリシー決定関数（PDF）は、セッションレベルサービス、たとえばSIPに関連して、ベアラーレベルのリソースの割り当て/脱アロケーションを制御する責任のあるエンティティです。ポリシー決定機能は、アクセスゲートウェイを制御して、ゲートを開閉し、フローごとのポリシーを構成すること、つまりユーザートラフィックを承認または禁止することもできます。P-CSCF（IMSでのみ使用）とAccess Gatewayは、ネットワークリソースの割り当て/解釈決定のために、ポリシー決定関数と通信します。ユーザー機器（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ワイヤレスネットワークでの1つのフローまたは集約化入場制御に必要なQoS情報がすべて搭載されています。P-CSCFおよび/またはアクセスゲートウェイなどからリソース割り当て/解釈要求を受信し、ポリシー決定で応答します。したがって、PDFは、NSISイニシエーターの機能をホストする候補エンティティであり、バックボーンIPネットワークに向けてNSIS QoSシグナリングを開始します。一方、UE/MSは、NSISイニシエーターとして機能するか、アクセスゲートウェイがUE/MSに代わってプロキシNSISイニシエーターとして機能する場合があります。前者の場合、P-CSCF/PDFは、コーデックタイプとメディア記述子（SIP/SDPシグナル伝達から派生）からIPトラフィック記述子へのマッピングを行う必要があります。後者の場合、UE/MSは、NSISイニシエーターとして適切なQoSシグナル伝達メカニズムを使用する場合があります。Access GatewayがUE/MSに代わってプロキシNSISイニシエーターとして機能している場合、リクエストをNSISフォワーダーに転送する前に、ラジオアクセス固有のQOSからIP 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ワイヤレスアーキテクチャの一部ではありません。ただし、エンドツーエンドのQoSを達成するには、NSISイニシエーターがIPネットワークへのQoS接続を要求できるように、NSISフォワーダーが必要です。前の例と同様に、NSISフォワーダーは、IPネットワーク内の事前に生成されたリソースのセットを管理できます。つまり、帯域幅パイプ、およびNSISフォワーダーはこれらのパイプに流れごとの入場制御を実行します。このようにして、2つの3Gワイヤレスアクセスネットワークの間に接続を行うことができ、したがって、エンドツーエンドのQOを実現できます。この場合、NSISイニシエーターとNSISフォワーダーは、明らかに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つの部分で構成されています。、図2に示すように、この図は、ワイヤレスネットワークのアーキテクチャの概要としてはなく、ワイヤレスネットワーク内の概念的なQoSドメインを表示すると見なされるべきであることに注意してください。
In this scenario, a mobile host can roam and perform a handover procedure between base stations/access routers. In this scenario the NSIS QoS protocol can be applied between a base station and the gateway (GW). In this case a GW can also be considered as a local handover anchor point. Furthermore, in this scenario the NSIS QoS protocol can also be applied either between two GWs, or between two edge routers (ER).
このシナリオでは、モバイルホストはベースステーション/アクセスルーター間でハンドオーバー手順を歩き回って実行できます。このシナリオでは、NSIS QoSプロトコルをベースステーションとゲートウェイ（GW）に適用できます。この場合、GWはローカルハンドオーバーアンカーポイントと見なすこともできます。さらに、このシナリオでは、NSIS QoSプロトコルを2つのGWSの間、または2つのエッジルーター（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) ワイヤレスインターフェイス：AIRインターフェイスリンクのソリューションでは、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.
これらの非常に異なる特性と要件により、多くの場合、矛盾している場合、3つのネットワークパーツのそれぞれで異なるQoSシグナル伝達ソリューションが必要になる場合があります。
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を変更せずに通信のエンドポイントが変更されることを意味します。
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 GWが通話ルーティングの決定を下すことができます。
PSTN gateways may handle thousands of calls simultaneously and there may be hundreds of PSTN gateways in a single provider network. These numbers are likely to increase as the size of the network increases. The point being that scalability is a major issue.
PSTNゲートウェイは、数千の呼び出しを同時に処理する場合があり、単一のプロバイダーネットワークに何百ものPSTNゲートウェイがある場合があります。これらの数値は、ネットワークのサイズが大きくなると増加する可能性があります。ポイントは、スケーラビリティが大きな問題であるということです。
There are several ways that a PSTN gateway can acquire assurances that a network can carry its traffic across the network. These include:
PSTNゲートウェイがネットワークがネットワーク全体にトラフィックを運ぶことができるという保証を取得できるいくつかの方法があります。これらには以下が含まれます：
1. Over-provisioning a high availability network.
1. 高可用性ネットワークの過剰プロビジョニング。
2. Handling admission control through some policy server that has a global view of the network and its resources.
2. ネットワークとそのリソースのグローバルビューを持ついくつかのポリシーサーバーを介して入場制御を処理します。
3. Per PSTN GW pair admission control.
3. PSTN GWペアの入場制御ごと。
4. Per call admission control (where a call is defined as the 5-tuple used to carry a single RTP flow).
4. 通話入場制御ごと（コールは、単一のRTPフローを運ぶために使用される5タプルとして定義されます）。
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 GWSが比較的少ない場合にのみ有効です。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は、帯域幅とQoS要件を定義したいくつかの5タプルの定義フローのエンドツーエンドを信号します。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.
Edgeルーター（つまり、ボーダーノード）では、フローが認められ、再び外部のポリシーサーバーが含まれるオプションの認証プロセスがあります。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シグナリングプロトコルのユースケースの1つは、QoSをサポートするIPネットワークと相互接続PSTNゲートウェイのシナリオです。
Four different scenarios are considered here.
ここでは、4つの異なるシナリオが考慮されます。
1. In-band QoS signaling is used. In this case the Media Gateway (MG) will be acting as the NSIS Initiator and the Edge Router (ER) will be the NSIS Forwarder. Hence, the ER should do admission control (into pre-provisioned traffic trunks) for the individual traffic flows. This scenario is not further considered here.
1. インバンドQoSシグナル伝達が使用されます。この場合、メディアゲートウェイ（MG）がNSISイニシエーターとして機能し、エッジルーター（ER）がNSISフォワーダーになります。したがって、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. 複数のドメイン間の帯域外シグナリング、NSISフォワーダー（MGCに統合される可能性がある）は、次のドメインのNSISフォワーダーをトリガーします。
When the out-of-band QoS signaling is used the Media Gateway Controller (MGC) will be acting as the NSIS Initiator.
バンド外のQoSシグナリングを使用すると、Media Gateway Controller（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.
3番目のシナリオでは、音声プロバイダーはネットワーク内のトラフィックトランクをリースしません。別のエンティティは、トラフィックトランクをリースし、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.
4番目のシナリオでは、複数の輸送ドメインが関係しています。発信ネットワークでは、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などです。VPNSで最も重要な問題の1つは、フローの識別方法とフローがどのような品質を得るかに関連しています。流れの識別は、輸送プロトコルポート番号の間で構成される場合があります。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ネットワークを介してシグナルを行うことを望む場合があります。このようなシグナル伝達は、顧客が定額を支払うのではなく、需要とネットワークコストを変更したい場合に役立つ場合があります。このようなシグナル伝達は、2つのCPEルーターの間に存在します。中間アクセスとエッジルーターは、エンドポイントがPSTN GWSではなく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は実際に顧客管理されたVPNSに対して部分的に許可されます。つまり、顧客は、その後のNSISシグナリングをさまざまなエンドポイントにセットアップできます。さらに、トンネルのエンドポイントは、必ずしもアプリケーションにバインドされていません。顧客管理者は、NSISシグナリングをトリガーするものかもしれません。
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.
Per Per Flow Signalingの場合、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.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Braden、R.、ed。、Zhang、L.、Berson、S.、Herzog、S.およびS. Jamin、「Resource Protocol（RSVP） - バージョン1機能仕様」、RFC 2205、1997年9月。
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002.
[RFC3234]大工、B。およびS.ブリム、「ミドルボックス：分類法と問題」、RFC 3234、2002年2月。
Marcus Brunner (Editor) NEC Europe Ltd. Network Laboratories Kurfuersten-Anlage 36 D-69115 Heidelberg Germany
Marcus Brunner（編集者）Nec Europe Ltd. Network Laboratories Kurfuersen-Anlage 36 D-69115ハイデルベルクドイツ
EMail: brunner@netlab.nec.de
Robert Hancock Roke Manor Research Ltd Romsey, Hants, SO51 0ZN United Kingdom
ロバート・ハンコック・ローク・マナー・リサーチ・リミテッド・ロンシー、ハンツ、SO51 0ZNイギリス
EMail: robert.hancock@roke.co.uk
Eleanor Hepworth Roke Manor Research Ltd Romsey, Hants, SO51 0ZN United Kingdom
エレノア・ヘプワース・ローク・マナー研究株式会社ロムシー、ハンツ、SO51 0ZNイギリス
EMail: eleanor.hepworth@roke.co.uk
Cornelia Kappler Siemens AG Berlin 13623 Germany
Cornelia Kappler Siemens AG Berlin 13623ドイツ
EMail: cornelia.kappler@siemens.com
Hannes Tschofenig Siemens AG Otto-Hahn-Ring 6 81739 Munchen Germany
Hannes Tschofenig Siemens Ag Otto-Hahn-Ring 6 81739 Munchen Germany
EMail: 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）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。