Network Working Group R. Hancock
Request for Comments: 4080 Siemens/RMR
Category: Informational G. Karagiannis
University of Twente/Ericsson
J. Loughney
Nokia
S. Van den Bosch
Alcatel
June 2005
Next Steps in Signaling (NSIS): Framework
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 (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
The Next Steps in Signaling (NSIS) working group is considering protocols for signaling information about a data flow along its path in the network. The NSIS suite of protocols is envisioned to support various signaling applications that need to install and/or manipulate such state in the network. Based on existing work on signaling requirements, this document proposes an architectural framework for these signaling protocols.
シグナリング（NSIS）ワーキンググループにおける次のステップは、ネットワーク内のパスに沿ったデータフローに関する情報をシグナリングするためのプロトコルを検討しています。プロトコルのNSISスイートをインストールおよび/またはネットワークでそのような状態を操作する必要がある様々なシグナリングアプリケーションをサポートするために想定されます。シグナリングの要件に作業を既存のに基づいて、このドキュメントはこれらのシグナリングプロトコルのためのアーキテクチャフレームワークを提案しています。
This document provides a model for the network entities that take part in such signaling, and for the relationship between signaling and the rest of network operation. We decompose the overall signaling protocol suite into a generic (lower) layer, with separate upper layers for each specific signaling application.
この文書では、このようなシグナル伝達に関与するネットワークエンティティのためのモデルを提供し、シグナリングおよびネットワークの動作の他の部分との関係について。我々は、各特定のシグナリングアプリケーションのための別個の上位層で、ジェネリック（下部）層への全体的なシグナリングプロトコルスイートを分解する。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Definition of the Signaling Problem ........................3
1.2. Scope and Structure of the NSIS Framework ..................3
2. Terminology .....................................................4
3. Overview of Signaling Scenarios and Protocol Structure ..........6
3.1. Fundamental Signaling Concepts .............................6
3.1.1. Simple Network and Signaling Topology ...............6
3.1.2. Path-Coupled and Path-Decoupled Signaling ...........7
3.1.3. Signaling to Hosts, Networks, and Proxies ...........8
3.1.4. Signaling Messages and Network Control State .......10
3.1.5. Data Flows and Sessions ............................10
3.2. Layer Model for the Protocol Suite ........................11
3.2.1. Layer Model Overview ...............................11
3.2.2. Layer Split Concept ................................12
3.2.3. Bypassing Intermediate Nodes .......................13
3.2.4. Core NSIS Transport Layer Functionality ............15
3.2.5. State Management Functionality .....................16
3.2.6. Path-Decoupled Operation ...........................17
3.3. Signaling Application Properties ..........................18
3.3.1. Sender/Receiver Orientation ........................18
3.3.2. Uni- and Bi-Directional Operation ..................19
3.3.3. Heterogeneous Operation ............................19
3.3.4. Aggregation ........................................20
3.3.5. Peer-Peer and End-End Relationships ................21
3.3.6. Acknowledgements and Notifications .................21
3.3.7. Security and Other AAA Issues ......................22
4. The NSIS Transport Layer Protocol ..............................23
4.1. Internal Protocol Components ..............................23
4.2. Addressing ................................................24
4.3. Classical Transport Functions .............................24
4.4. Lower Layer Interfaces ....................................26
4.5. Upper Layer Services ......................................27
4.6. Identity Elements .........................................28
4.6.1. Flow Identification ................................28
4.6.2. Session Identification .............................28
4.6.3. Signaling Application Identification ...............29
4.7. Security Properties .......................................30
5. Interactions with Other Protocols ..............................30
5.1. IP Routing Interactions ...................................30
5.1.1. Load Sharing and Policy-Based Forwarding ...........31
5.1.2. Route Changes ......................................31
5.2. Mobility and Multihoming Interactions .....................33
5.3. Interactions with NATs ....................................36
5.4. Interactions with IP Tunneling ............................36
6. Signaling Applications .........................................37
6.1. Signaling for Quality of Service ..........................37
6.1.1. Protocol Message Semantics .........................38
6.1.2. State Management ...................................39
6.1.3. Route Changes and QoS Reservations .................39
6.1.4. Resource Management Interactions ...................41
6.2. Other Signaling Applications ..............................42
7. Security Considerations ........................................42
8. References .....................................................43
8.1. Normative References ......................................43
8.2. Informative References ....................................44
The Next Steps in Signaling (NSIS) working group is considering protocols for signaling information about a data flow along its path in the network.
シグナリング（NSIS）ワーキンググループにおける次のステップは、ネットワーク内のパスに沿ったデータフローに関する情報をシグナリングするためのプロトコルを検討しています。
It is assumed that the path taken by the data flow is already determined by network configuration and routing protocols, independently of the signaling itself; that is, signaling to set up the routes themselves is not considered. Instead, the signaling simply interacts with nodes along the data flow path. Additional simplifications are that the actual signaling messages pass directly through these nodes themselves (i.e., the 'path-coupled' case; see Section 3.1.2) and that only unicast data flows are considered.
データ・フローによって取られる経路は既に独立シグナリング自体の、ネットワーク構成およびルーティングプロトコルによって決定されているものとします。つまり、自身が考慮されていないルートを設定するシグナル。その代わりに、シグナリングは、単にデータ流路に沿ったノードと相互作用します。付加的な単純化は、実際のシグナリングメッセージは、これらのノードを直接通過することをしている自分自身（即ち、「パス結合」の場合、セクション3.1.2を参照）のみ、ユニキャストデータフローを考慮すること。
The signaling problem in this sense is very similar to that addressed by RSVP. However, there are two generalizations. First, the intention is that components of the NSIS protocol suite will be usable in different parts of the Internet, for different needs, without requiring a complete end-to-end deployment (in particular, the signaling protocol messages may not need to run all the way between the data flow endpoints).
この意味でのシグナリングの問題は、RSVPによって対処と非常によく似ています。しかし、2つの一般化があります。まず、意図はNSISプロトコル群の成分は、特に、（完全なエンドツーエンドの展開を必要とすることなく、さまざまなニーズのためのインターネットのさまざまな部分で使用可能になることで、シグナリングプロトコルメッセージは、すべて実行する必要がないかもしれませんデータフローのエンドポイント間の道）。
Second, the signaling is intended for more purposes than just QoS (resource reservation). The basic mechanism to achieve this flexibility is to divide the signaling protocol stack into two layers: a generic (lower) layer, and an upper layer specific to each signaling application. The scope of NSIS work is to define both the generic protocol and, initially, upper layers suitable for QoS signaling (similar to the corresponding functionality in RSVP) and middlebox signaling. Further applications may be considered later.
第二に、シグナリングはただのQoS（リソース予約）以上の目的のために意図されます。ジェネリック（下部）層、及び各シグナリングアプリケーションに固有の上層：この柔軟性を達成するための基本的なメカニズムは二層にシグナリングプロトコルスタックを分割することです。 NSIS作業の範囲は、一般的なプロトコルと、最初に、QoSのための適切な上位層シグナリング（RSVPに対応する機能に類似）とミドルシグナリングの両方を定義することです。さらに、アプリケーションは、後で考えてもよいです。
The underlying requirements for signaling in the context of NSIS are defined in [1] and a separate security threats document [2]; other related requirements can be found in [3] and [4] for QoS/Mobility and middlebox communication, respectively. This framework does not replace or update these requirements. Discussions about lessons to be learned from existing signaling and resource management protocols are contained in separate analysis documents [5], [6].
NSISの文脈においてシグナリングするための基礎となる要件が定義されている[1]と別のセキュリティ脅威文献[2]。他の関連する要件が中に見出すことができる[3]及び[4]は、それぞれのQoS /モビリティとミドルの通信のため。このフレームワークは、これらの要件を交換したり、更新されません。レッスンについての議論は、既存のシグナリングとリソース管理プロトコルから学習するために別の分析文書に含まれている[5]、[6]。
The role of this framework is to explain how NSIS signaling should work within the broader networking context, and to describe the overall structure of the protocol suite itself. Therefore, it discusses important protocol considerations such as routing, mobility, security, and interactions with network 'resource' management (in the broadest sense).
このフレームワークの役割は、NSISシグナリングが広いネットワーキング・コンテキスト内で動作するはず、とプロトコルスイート自体の全体的な構造を記述するためにどのように説明することです。したがって、そのようなルーティング、モビリティ、セキュリティ、および（広い意味で）ネットワーク「リソース」管理との相互作用などの重要なプロトコルの考慮事項について説明します。
The basic context for NSIS protocols is given in Section 3. Section 3.1 describes the fundamental elements of NSIS protocol operation in comparison to RSVP [7]; in particular, Section 3.1.3 describes more general signaling scenarios, and Section 3.1.4 defines a broader class of signaling applications for which the NSIS protocols should be useful. The two-layer protocol architecture that supports this generality is described in Section 3.2, and Section 3.3 gives examples of the ways in which particular signaling application properties can be accommodated within signaling layer protocol behavior.
NSISプロトコルの基本的なコンテキストは第3セクション3.1に記載されている[7] RSVPと比較して、NSISプロトコルの動作の基本的な要素について説明し、特に、セクション3.1.3は、より一般的なシグナリング・シナリオについて説明し、セクション3.1.4はNSISプロトコルが有用であるべきためのシグナリングアプリケーションのより広いクラスを定義します。この一般性をサポートする二層プロトコルアーキテクチャは、セクション3.2に記載され、セクション3.3は、特定のシグナリングアプリケーションのプロパティは、シグナリング層プロトコルの動作に収容することができる方法の例を示しています。
The overall functionality required from the lower (generic) protocol layer is described in Section 4. This is not intended to define the detailed design of the protocol or even design options, although some are described as examples. It describes the interfaces between this lower-layer protocol and the IP layer (below) and signaling application protocols (above), including the identifier elements that appear on these interfaces (Section 4.6). Following this, Section 5 describes how signaling applications that use the NSIS protocols can interact sensibly with network layer operations; specifically, routing (and re-routing), IP mobility, and network address translation (NAT).
いくつかの例として説明したが低い（一般）プロトコル・レイヤから要求全体的な機能は、これは、プロトコルの詳細な設計を定義する、あるいはオプションを設計することが意図されていないセクション4に記載されています。なお、この下位層プロトコル（下記）IP層との間のインターフェースを説明し、これらのインタフェース（セクション4.6）に表示される識別子要素を含むアプリケーションプロトコル（上記）を、シグナリング。これに続いて、第5節ではNSISプロトコルを使用するシグナリング・アプリケーションは、ネットワーク層操作と賢明に対話できる方法を説明します。具体的には、ルーティング（再ルーティング）、IPモビリティ、およびネットワークアドレス変換（NAT）。
Section 6 describes particular signaling applications. The example of signaling for QoS (comparable to core RSVP QoS signaling functionality) is given in detail in Section 6.1, which describes both the signaling application specific protocol and example modes of interaction with network resource management and other deployment aspects. However, note that these examples are included only as background and for explanation; we do not intend to define an over-arching architecture for carrying out resource management in the Internet. Further possible signaling applications are outlined in Section 6.2.
第6節では、特定のシグナリングアプリケーションについて説明します。 （機能シグナリングコアRSVP QoSのに匹敵する）QoSのためのシグナリングの一例は、ネットワークリソース管理および他の展開側面との相互作用のシグナリングアプリケーション特定プロトコル及び例モードの両方が記載され、セクション6.1で詳細に説明されています。しかし、これらの実施例は、単に背景として、説明のために含まれていることに注意してください。私たちは、インターネットでのリソース管理を行うためのオーバーアーチアーキテクチャを定義するつもりはありません。さらに可能なシグナリングアプリケーションは、6.2節で概説されています。
Classifier: an entity that selects packets based on their contents according to defined rules.
クラシファイア：定義された規則に従って、それらの内容に基づいてパケットを選択するエンティティ。
[Data] flow: a stream of packets from sender to receiver that is a distinguishable subset of a packet stream. Each flow is distinguished by some flow identifier (see Section 4.6.1).
[データ]流量：それはパケット・ストリームの識別可能なサブセットである受信機への送信者からのパケットの流れ。各フローは、いくつかのフロー識別子によって区別される（4.6.1項を参照してください）。
Edge node: an (NSIS-capable) node on the boundary of some administrative domain.
エッジノード：いくつかの管理ドメインの境界上（NSIS対応）ノード。
Interior nodes: the set of (NSIS-capable) nodes that form an administrative domain, excluding the edge nodes.
内部ノード（NSIS対応）のセットの管理ドメインを構成するノード、エッジノードを除きます。
NSIS Entity (NE): the function within a node that 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 Signaling Layer Protocol (NSLP): generic term for an NSIS protocol component that supports a specific signaling application. See also Section 3.2.1.
NSISシグナリング層プロトコル（NSLP）：特定のシグナリングアプリケーションをサポートしているNSISプロトコルコンポーネントの総称。また、3.2.1項を参照してください。
NSIS Transport Layer Protocol (NTLP): placeholder name for the NSIS protocol component that will support lower-layer (signaling application-independent) functions. See also Section 3.2.1.
NSISトランスポート層プロトコル（NTLP）：下位機能（アプリケーションに依存しないシグナリング）をサポートするNSISプロトコルコンポーネントのプレースホルダ名。また、3.2.1項を参照してください。
Path-coupled signaling: a mode of signaling in which the signaling messages follow a path that is tied to the data messages.
パス結合シグナリング：シグナリングメッセージはデータメッセージに関連付けされているパスをたどるするシグナルのモード。
Path-decoupled signaling: signaling for state manipulation related to data flows, but only loosely coupled to the data path; e.g., at the AS level.
パス切り離さシグナリング：データフローに関連する状態の操作のためのシグナリングが、唯一緩くデータパスに結合されました。例えば、ASレベルで。
Peer discovery: the act of locating and/or selecting which NSIS peer to carry out signaling exchanges with for a specific data flow.
ピア発見：NSISは、特定のデータフロー用と交換シグナリング行うためピア位置決めの行為及び/又は選択します。
Peer relationship: signaling relationship between two adjacent NSIS entities (i.e., NEs with no other NEs between them).
ピア関係の2つの隣接するNSISエンティティ（それらの間に他のNEと、すなわち、NES）の関係をシグナリングします。
Receiver: the node in the network that is receiving the data packets in a flow.
受信機：フローのデータ・パケットを受信しているネットワーク内のノード。
Sender: the node in the network that is sending the data packets in a flow.
送信者：フローのデータ・パケットを送信しているネットワーク内のノード。
Session: application layer flow of information for which some network control state information is to be manipulated or monitored (see Section 3.1.5).
セッション：いくつかのネットワーク制御状態情報を操作又は監視されるべき情報のアプリケーション層流（セクション3.1.5を参照）。
Signaling application: the purpose of the NSIS signaling. A signaling application could be QoS management, firewall control, and so on. Totally distinct from any specific user application.
シグナリングアプリケーション：NSISシグナリングの目的。シグナリングアプリケーションはそれほどのQoS管理、ファイアウォール管理、および可能性があります。任意の特定のユーザアプリケーションとは全く異なります。
The NSIS suite of protocols is envisioned to support various signaling applications that need to install and/or manipulate state in the network. This state is related to a data flow and is installed and maintained on the NSIS Entities (NEs) along the data flow path through the network; not every node has to contain an NE. The basic protocol concepts do not depend on the signaling application, but the details of operation and the information carried do. This section discusses the basic entities involved with signaling as well as interfaces between them.
プロトコルのNSISスイートは、インストールおよび/またはネットワークの状態を操作する必要がある様々なシグナリングアプリケーションをサポートするために想定されます。この状態は、データフローに関連し、ネットワークを介してデータ流路に沿って設置され、NSISエンティティ（NES）に維持されます。いないすべてのノードには、NEが含まれている必要があります。基本的なプロトコルの概念は、シグナリングアプリケーションに依存しませんが、動作の詳細や実施情報が行います。このセクションでは、シグナリングだけでなく、それらの間のインターフェースに関わる基本的なエンティティを説明します。
Two NSIS entities that communicate directly are said to be in a 'peer relationship'. This concept might loosely be described as an 'NSIS hop'; however, there is no implication that it corresponds to a single IP hop. Either or both NEs might store some state information about the other, but there is no assumption that they necessarily establish a long-term signaling connection between themselves.
直接通信する二つのNSIS実体は、「ピア関係」にあると言われています。この概念は、大まかに「NSISホップ」として記述されているかもしれません。しかし、それは単一のIPホップに対応することを何ら意味はありません。いずれかまたは両方のNEは、他のいくつかについての状態情報を格納するかもしれないが、彼らは必ずしも彼ら自身の間で長期的なシグナリング接続を確立することは前提はありません。
It is common to consider a network as composed of various domains (e.g., for administrative or routing purposes), and the operation of signaling protocols may be influenced by these domain boundaries. However, it seems there is no reason to expect that an 'NSIS domain' should exactly overlap with an IP domain (AS, area), but it is likely that its boundaries would consist of boundaries (segments) of one or several IP domains.
（管理またはルーティングの目的のために、例えば、）種々のドメインからなるようなネットワークを考慮することが一般的であり、およびシグナリングプロトコルの動作は、これらのドメイン境界によって影響され得ます。しかし、NSISドメインは「正確IPドメイン（AS、面積）と重複しなければならないことを期待する理由はないようだが、その境界は、1つまたは複数のIPドメインの境界（セグメント）で構成されます可能性が高いです。
Figure 1 shows a diagram of nearly the simplest possible signaling configuration. A single data flow is running from an application in the sender to the receiver via routers R1, R2, and R3. Each host and two of the routers contain NEs that exchange signaling messages -- possibly in both directions -- about the flow. This scenario is essentially the same as that considered by RSVP for QoS signaling; the main difference is that here we make no assumptions about the particular sequence of signaling messages that will be invoked.
図1は、ほぼ最も単純なシグナリング構成図を示します。単一のデータ・フローは、ルータR1、R2、及びR3を介して受信機に送信側で、アプリケーションから実行されています。おそらく両方の方向に - - フローについて各ホストとルータの2は、シグナリングメッセージを交換するNEが含まれています。このシナリオでは、本質的にQoSシグナリングのためのRSVPによって考慮と同様です。主な違いは、ここで私たちが呼び出されるシグナリングメッセージの特定の順序についての仮定をしないということです。
Sender Receiver
+-----------+ +----+ +----+ +----+ +-----------+
|Application|----->| R1 |----->| R2 |----->| R3 |----->|Application|
| +--+ | |+--+| |+--+| +----+ | +--+ |
| |NE|====|======||NE||======||NE||==================|===|NE| |
| +--+ | |+--+| |+--+| | +--+ |
+-----------+ +----+ +----+ +-----------+
+--+
|NE| = NSIS ==== = Signaling ---> = Data flow messages
+--+ Entity Messages (unidirectional)
Figure 1: Simple Signaling and Data Flows
図1：シンプルなシグナリングとデータフロー
We can consider two basic paradigms for resource reservation signaling, which we refer to as "path-coupled" and "path-decoupled".
私たちは、「パス結合」および「パス・デカップリング」と呼ぶリソース予約シグナリングのための2つの基本的なパラダイムを、検討することができます。
In the path-coupled case, signaling messages are routed only through NEs that are on the data path. They do not have to reach all the nodes on the data path. (For example, there could be intermediate signaling-unaware nodes, or the presence of proxies such as those shown in Figure 2 could prevent the signaling from reaching the path end points.) Between adjacent NEs, the route taken by signaling and data might diverge. The path-coupled case can be supported by various addressing styles, with messages either explicitly addressed to the neighbor on-path NE, or addressed identically to the data packets, but also with the router alert option (see [8] and [9]), and intercepted. These cases are considered in Section 4.2. In the second case, some network configurations may split the signaling and data paths (see Section 5.1.1); this is considered an error case for path-coupled signaling.
パス結合場合、シグナリングメッセージは、データ・パス上にあるNEを介してルーティングされます。彼らは、データパス上のすべてのノードに到達する必要はありません。 （例えば、中間体シグナリング非対応ノードが存在することができ、あるいは図2に示されるようなプロキシの存在は、パスのエンドポイントに到達するシグナリングを防ぐことができる。）隣接NE間の、シグナリングおよびデータにより撮影されたルートが分岐するかもしれません。パス結合する場合は、明示的に近隣のパスNE宛、またはデータパケットと同一に対処するだけでなく、ルータ警告オプションを使用して（参照のいずれかのメッセージで、様々なアドレッシング・スタイルでサポートできる[8]、[9] ）、および傍受。これらの例は、4.2節において検討されています。第二のケースでは、いくつかのネットワーク構成は、シグナリング及びデータパスを分割することができる（セクション5.1.1を参照）。これはパス結合シグナリングのためのエラー・ケースとみなされます。
In the path-decoupled case, signaling messages are routed to nodes (NEs) that are not assumed to be on the data path, but that are (presumably) aware of it. Signaling messages will always be directly addressed to the neighbor NE, and the signaling endpoints may have no relation at all with the ultimate data sender or receiver. The implications of path-decoupled operation for the NSIS protocols are considered briefly in Section 3.2.6; however, the initial goal of NSIS and this framework is to concentrate mainly on the path-coupled case.
パス・デカップリングの場合に、シグナリングメッセージは、データ・パス上にあると想定されていないノード（NES）にルーティングされ、それのものである（おそらく）を意識。シグナリングメッセージはいつも直接隣人NEに対処されることになりますし、シグナリングエンドポイントは、究極のデータ送信側または受信側では全く関係がなくてもよいです。 NSISプロトコルのパスデカップリング動作の影響は、セクション3.2.6で簡単に考えられています。しかし、NSISとこのフレームワークの最初の目標は、パス結合する場合に主に集中することです。
There are different possible triggers for the signaling protocols. Among them are user applications (that are using NSIS signaling services), other signaling applications, network management actions, some network events, and so on. The variety of possible triggers requires that the signaling can be initiated and terminated in the different parts of the network: hosts, domain boundary nodes (edge nodes), or interior domain nodes.
シグナリングプロトコルのための異なる可能なトリガーがあります。その中でもように、ユーザ（NSISシグナリングのサービスを使用している）アプリケーション、他のシグナリングアプリケーション、ネットワーク管理措置、いくつかのネットワークイベント、およびです。ホスト、ドメインの境界ノード（エッジノード）、または内部ドメインノード：可能なトリガーの多様なシグナリングがネットワークの異なる部分で開始し、終了することができることを必要とします。
The NSIS protocol suite extends the RSVP model to consider this wider variety of possible signaling exchanges. As well as the basic end-to-end model already described, examples such as end-to-edge and edge-to-edge can be considered. The edge-to-edge case might involve the edge nodes communicating directly, as well as via the interior nodes.
NSISプロトコル群は、可能なシグナリング交換のこの広い多様性を考慮するRSVPモデルを拡張します。基本的なエンドツーエンドモデルは、既に説明したと同様に、そのようなエンド・エッジおよびエッジ・ツー・エッジのような例が考えられます。エッジ・ツー・エッジの場合は直接、並びに内部ノードを介して通信するエッジノードを含むかもしれません。
Although the end-to-edge (host-to-network) scenario requires only intra-domain signaling, the other cases might need inter-domain NSIS signaling as well if the signaling endpoints (hosts or network edges) are connected to different domains. Depending on the trust relation between concatenated NSIS domains, the edge-to-edge scenario might cover a single domain or multiple concatenated NSIS domains. The latter case assumes the existence of trust relations between domains.
エンド・ツー・エッジ（ホストとネットワーク）シナリオのみドメイン内シグナル伝達を必要とするが、他の場合は、シグナリングエンドポイント（ホストまたはネットワークエッジ）が異なるドメインに接続されている場合だけでなく、シグナリングドメイン間NSISを必要とするかもしれません。連結NSISドメイン間の信頼関係に応じて、エッジツーエッジシナリオは、単一のドメインまたは複数の連結NSISドメインをカバーするかもしれません。後者の場合は、ドメイン間の信頼関係が存在することを前提としています。
In some cases, it is desired to be able to initiate and/or terminate NSIS signaling not from the end host that sends/receives the data flow, but from some other entities in the network that can be called signaling proxies. There could be various reasons for this: signaling on behalf of the end hosts that are not NSIS-aware, consolidation of the customer accounting (authentication, authorization) in respect to consumed application and transport resources, security considerations, limitation of the physical connection between host and network, and so on. This configuration can be considered a kind of "proxy on the data path"; see Figure 2.
いくつかの場合において、/データフローを送受信するが、プロキシシグナリングと呼ばれることができ、ネットワーク内の他のエンティティからエンドホストからではなくシグナリングNSISを開始および/または終了できることが望まれています。このため、さまざまな理由が考えられます：NSIS-認識していないエンドホストに代わってシグナリングを、消費アプリケーションおよびトランスポートリソース、セキュリティ上の考慮事項、との間の物理的な接続の制限に関して顧客会計（認証、許可）の統合その上のホストとネットワーク、および。この構成は、「データパス上のプロキシ」の一種と見なすことができます。図2を参照してください。
Proxy1 Proxy2
+------+ +----+ +----+ +----+ +----+ +--------+
|Sender|-...->|Appl|--->| R |--->| R |--->|Appl|-...->|Receiver|
| | |+--+| |+--+| |+--+| |+--+| | |
+------+ ||NE||====||NE||====||NE||====||NE|| +--------+
|+--+| |+--+| |+--+| |+--+|
+----+ +----+ +----+ +----+
+--+
|NE| = NSIS ==== = Signaling ---> = Data flow messages
+--+ Entity Messages (unidirectional)
Appl = signaling application
APPL =シグナリングアプリケーション
Figure 2: "On path" NSIS proxy
図2：「路上」NSISプロキシ
This configuration presents two specific challenges for the signaling:
この構成では、シグナリングのための2つの特定の課題を提示します。
o A proxy that terminates signaling on behalf of the NSIS-unaware host (or part of the network) should be able to determine that it is the last NSIS-aware node along the path.
O NSIS非対応ホスト（またはネットワークの一部）に代わってシグナリングを終端するプロキシは、それが経路に沿って最後NSIS対応ノードであると判断することができなければなりません。
o Where a proxy initiates NSIS signaling on behalf of the NSIS-unaware host, interworking with some other "local" technology might be required (for example, to provide QoS reservation from proxy to the end host in the case of a QoS signaling application).
プロキシがNSISはNSIS非対応ホストの代わりにシグナリングを開始どこO、他のいくつかの「ローカル」技術と相互動作が必要になる場合があります（たとえば、アプリケーションのQoSシグナリングの場合のエンドホストへのプロキシからのQoS予約を提供するために） 。
+------+ +----+ +----+ +----+ +--------+
|Sender|----->| PA |----->| R2 |----->| R3 |----->|Receiver|
| | |+--+| |+--+| +----+ | +--+ |
+------+ ||NE||======||NE||==================|==|NE| |
|+--+| |+--+| | +--+ |
+-..-+ +----+ +--------+
..
..
+-..-+
|Appl|
+----+
Appl = signaling PA = Proxy for signaling
application application
Figure 3: "Off path" NSIS proxy
図3：「オフパス」NSISプロキシ
Another possible configuration, shown in Figure 3, is where an NE can send and receive signaling information to a remote processor. The NSIS protocols may or may not be suitable for this remote interaction, but in any case it is not currently part of the NSIS problem. This configuration is supported by considering the NE a proxy at the signaling application level. This is a natural implementation approach for some policy control and centralized control architectures; see also Section 6.1.4.
NEは、送信および遠隔プロセッサにシグナリング情報を受信することができる。ここで、図3に示す別の可能な構成があります。 NSISプロトコルは、またはこのリモート相互作用に適していてもいなくてもよいが、いずれの場合にも、現在NSIS問題の一部ではありません。この構成は、NEにシグナリングアプリケーションレベルでのプロキシを考慮することによってサポートされています。これは、いくつかのポリシー制御と集中制御アーキテクチャのための自然な実装アプローチです。また、6.1.4項を参照してください。
The distinguishing features of the signaling supported by the NSIS protocols are that it is related to specific flows (rather than to network operation in general), and that it involves nodes in the network (rather than running transparently between the end hosts).
NSISプロトコルによってサポートされるシグナル伝達の顕著な特徴は、それが特定のフロー（というより一般的にネットワーク動作）に関連していることであり、それは（むしろエンドホスト間で透過的に実行するよりも）、ネットワーク内のノードを含むこと。
Therefore, each signaling application (upper-layer) protocol must carry per-flow information for the aspects of network-internal operation that are of interest to that signaling application. An example for the case of an RSVP-like QoS signaling application would be state data representing resource reservations. However, more generally, the per-flow information might be related to some other control function in routers and middleboxes along the path. Indeed, the signaling might simply be used to gather per-flow information, without modifying network operation at all.
したがって、各シグナリングアプリケーション（上位層）プロトコルは、シグナリングアプリケーションに関心のあるネットワーク内部動作の態様のためのフローごとの情報を運ばなければなりません。アプリケーションシグナリングRSVP状のQoSの場合の例では、リソース予約を表す状態データであろう。しかし、より一般的には、フローごとの情報は、経路に沿ったルータ及び中間装置の一部の他の制御機能に関連するかもしれません。実際に、シグナリングは、単純にすべてのネットワーク動作を変更することなく、フローごとの情報を収集するために使用されるかもしれません。
We call this information 'network control state' generically. Signaling messages may install, modify, refresh, or simply read this state from network elements for particular data flows. Usually a network element will also manage this information at the per-flow level, although coarser-grained ('per-class') state management is also possible.
私たちは、一般的に、この情報のネットワーク制御状態」と呼びます。シグナリングメッセージは、インストール、変更、更新、または単に特定のデータフローのためのネットワーク要素からこの状態を読み取ることができます。粗い粒度が通常、ネットワーク要素はまた、フローごとのレベルでこの情報を管理する（「クラスごと」）状態の管理も可能です。
Formally, a data flow is a (unidirectional) sequence of packets between the same endpoints that all follow a unique path through the network (determined by IP routing and other network configuration). A flow is defined by a packet classifier (in the simplest cases, just the destination address and topological origin are needed). In general we assume that when discussing only the data flow path, we only need to consider 'simple' fixed classifiers (e.g., IPv4 5-tuple or equivalent).
正式に、データフローは（IPルーティングと他のネットワーク構成によって決定される）すべてのネットワークを介して固有の経路をたどる同じエンドポイント間のパケットの（一方向）配列です。フローは、パケット分類（最も単純な場合には、単に宛先アドレスとトポロジカル原点が必要である）によって定義されます。一般に、我々は、データ流路を議論する際、我々は唯一の「単純な」固定分類（例えば、IPv4の5タプルまたは同等）を考慮する必要があると仮定する。
A session is an application layer concept for an exchange of packets between two endpoints, for which some network state is to be allocated or monitored. In simple cases, a session may map to a specific flow; however, signaling applications are allowed to create more flexible flow:session relationships. (Note that this concept of 'session' is different from that of RSVP, which defines a session as a flow with a specific destination address and transport protocol. The NSIS usage is closer to the session concepts of higher-layer protocols.)
セッションは、いくつかのネットワーク状態が割り当てまたは監視されるべき2つのエンドポイント間のパケットの交換のためのアプリケーションレイヤの概念です。単純なケースでは、セッションは、特定のフローにマッピングすることができます。セッション関係：しかし、シグナルのアプリケーションは、より柔軟なフローを作成することが許可されています。 （「セッション」のこの概念は、特定の宛先アドレスおよびトランスポートプロトコルと流れとしてセッションを定義RSVPのものとは異なることに留意されたい。NSIS使用率が上位層プロトコルのセッションの概念に近いです）。
The simplest service provided by NSIS signaling protocols is the management of network control state at the level of a specific flow, as described in the previous subsection. In particular, it should be possible to monitor routing updates as they change the path taken by a flow and, for example, update network state appropriately. This is no different from the case for RSVP (local path repair). Where there is a 1:1 flow:session relationship, this is all that is required.
前節で説明したようにNSISシグナリングプロトコルによって提供される最も単純なサービスは、特定のフローのレベルのネットワーク制御状態の管理です。これらは流れによって取ら路を変更して、例えば、適切にネットワーク状態を更新するように、特に、ルーティングアップデートを監視することが可能であるべきです。これは、RSVP（ローカルパス修復）のための場合と変わりません。 1流れ：1がある場合、セッションの関係は、これはすべてのことが必要とされています。
However, for some more complex scenarios (especially mobility and multihoming related ones; see [1] and the mobility discussion of [5]), it is desirable to update the flow:session mapping during the session lifetime. For example, a new flow can be added, and the old one deleted (and maybe in that order, for a 'make-before-break' handover), effectively transferring the network control state between data flows to keep it associated with the same session. Such updates are best managed by the end systems (generally, systems that understand the flow:session mapping and are aware of the packet classifier change). To enable this, it must be possible to relate signaling messages to sessions as well as to data flows. A session identifier (Section 4.6.2) is one component of the solution.
セッションの寿命の間のセッションマッピング：;ただし、いくつかのより複雑なシナリオ（特に移動度及びマルチホーミングに関連するものを参照してください[1]、[5]のモビリティ議論）のために、フローを更新することが望ましいです。たとえば、新しいフローを追加することができ、古いものは、効果的にデータ間のネットワーク制御状態が、それは同じに関連付けられている保つために流れて転送する、（「メイクビフォア・ブレイク」を、ハンドオーバのために、そしておそらくこの順番で）削除しますセッション。このような更新は、最高のエンドシステム（：セッションマッピングとパケット分類の変更を認識している流れを理解し、一般的に、システム）によって管理されています。これを有効にするには、セッションにだけでなく、データフローへのシグナリングメッセージを関連付けることが可能でなければなりません。セッション識別子（セクション4.6.2）溶液の一の成分です。
In order to achieve a modular solution for the NSIS requirements, the NSIS protocol suite will be structured in two layers:
NSIS要件のためにモジュラーソリューションを達成するために、NSISプロトコル群は、2層構成されます。
o a 'signaling transport' layer, responsible for moving signaling messages around, which should be independent of any particular signaling application; and
O「シグナル輸送」層、任意の特定のシグナリングアプリケーションとは独立であるべき、周りのシグナリングメッセージを移動するための責任を負います。そして
o a 'signaling application' layer, which contains functionality such as message formats and sequences, specific to a particular signaling application.
特定のシグナリングアプリケーションに固有のようなメッセージフォーマット及び配列などの機能が含まれている「シグナリングアプリケーション」層、O。
For the purpose of this document, we use the term 'NSIS Transport Layer Protocol' (NTLP) to refer to the component that will be used in the transport layer. We also use the term 'NSIS Signaling Layer Protocol' (NSLP) to refer generically to any protocol within the signaling application layer; in the end, there will be several NSLPs, largely independent of each other. These relationships are illustrated in Figure 4. Note that the NTLP may or may not have an interesting internal structure (e.g., including existing transport protocols), but that is not relevant at this level of description.
このドキュメントの目的のために、我々はトランスポート層で使用されるコンポーネントを参照するために用語「NSISトランスポート層プロトコル」（NTLP）を使用します。我々はまた、シグナリングアプリケーション層内の任意のプロトコルに一般的に指すために用語「NSISシグナリング層プロトコル」（NSLP）を使用します。最後に、お互いにほとんど依存いくつかのNSLPs、あるでしょう。これらの関係は、（例えば、既存のトランスポートプロトコルを含む）NTLPが面白いまたは内部構造を有しても有さなくてもよいことは、図4（注）に示されているが、それは説明のこのレベルで関連していません。
^ +-----------------+
| | NSIS Signaling |
| | Layer Protocol |
NSIS | +----------------| for middleboxes |
Signaling | | NSIS Signaling | +-----------------+
Layer | | Layer Protocol +--------| NSIS Signaling |
| | for QoS | | Layer Protocol |
| +-----------------+ | for ... |
V +-----------------+
=============================================
NSIS ^ +--------------------------------+
Transport | | NSIS Transport Layer Protocol |
Layer V +--------------------------------+
=============================================
+--------------------------------+
. IP and lower layers .
. .
Figure 4: NSIS Protocol Components
図4：NSISプロトコルコンポーネント
Note that not every generic function has to be located in the NTLP. Another option would be to have re-usable components within the signaling application layer. Functionality within the NTLP should be restricted to what interacts strongly with other transport and lower-layer operations.
必ずしもすべての一般的な機能がNTLPに配置する必要があることに注意してください。別のオプションは、シグナリングアプリケーション層内の再利用可能なコンポーネントを持っているだろう。 NTLP内の機能は、他の交通機関と下位層の操作と強く相互作用するものに限定されなければなりません。
This section describes the basic concepts underlying the functionality of the NTLP. First, we make a working assumption that the protocol mechanisms of the NTLP operate only between adjacent NEs (informally, the NTLP is a 'hop-by-hop' protocol), whereas any larger-scope issues (including e2e aspects) are left to the upper layers.
このセクションでは、NTLPの機能の基礎となる基本的な概念を説明します。まず、（E2E局面を含む）いずれかのより大きなスコープの問題がに残っているのに対し、NTLPのプロトコルメカニズムは、（非公式、NTLPは「ホップバイホップ」プロトコルである）隣接NE間のみ動作する作業仮説を作ります上位層。
The way in which the NTLP works can be described as follows: When a signaling message is ready to be sent from one NE, it is given to the NTLP along with information about what flow it is for; it is then up to the NTLP to get it to the next NE along the path (upstream or downstream), where it is received and the responsibility of the NTLP ends. Note that there is no assumption here about how the messages are actually addressed (this is a protocol design issue, and the options are outlined in Section 4.2). The key point is that the NTLP for a given NE does not use any knowledge about addresses, capabilities, or status of any NEs other than its direct peers.
次のようにNTLPが動作する方法を記述することができるシグナリングメッセージは、1つのNEから送信される準備ができている場合、それがためであるフローについての情報とともにNTLPに与えられます。それは、それが受信され、NTLPの責任が終了する（上流又は下流）経路に沿って次のNEにそれを得るためにNTLPまで、次にです。メッセージは実際に対処する方法についてここでは何の仮定（これはプロトコルの設計の問題であり、そしてオプションは4.2節で概説されている）が存在しないことに注意してください。キーポイントは、与えられたNEのNTLPはアドレス、機能、またはその直接のピア以外のNEの状態についての知識を使用していないということです。
The NTLP in the receiving NE either forwards the message directly or, if there is an appropriate signaling application locally, passes it upwards for further processing; the signaling application can then generate another message to be sent via the NTLP. In this way, larger-scope (including end-to-end) message delivery is achieved.
受信NEでNTLP直接メッセージを転送または、適切なシグナリングアプリケーションがローカルに存在する場合、さらなる処理のために上方に渡しいずれか。シグナリングアプリケーションは、NTLPを介して送信される別のメッセージを生成することができます。このように、より大きな範囲（エンド・ツー・エンドを含む）のメッセージ配信が達成されます。
This definition relates to NTLP operation. It does not restrict the ability of an NSLP to send messages by other means. For example, an NE in the middle or end of the signaling path could send a message directly to the other end as a notification or acknowledgement of some signaling application event. However, the issues in sending such messages (endpoint discovery, security, NAT traversal, and so on) are so different from the direct peer-peer case that there is no benefit in extending the NTLP to include such non-local functionality. Instead, an NSLP that requires such messages and wants to avoid traversing the path of NEs should use some other existing transport protocol. For example, UDP or DCCP would be a good match for many of the scenarios that have been proposed. Acknowledgements and notifications of this type are considered further in Section 3.3.6.
この定義は、NTLP操作に関するものです。これは、他の手段でメッセージを送信するNSLPの能力を制限するものではありません。例えば、シグナル伝達経路の途中または終わりにおけるNEは、いくつかのシグナリングアプリケーションイベントの通知又は確認応答などの他の端部に直接メッセージを送ることができます。しかしながら、そのようなメッセージの送信における問題（エンドポイント検出、セキュリティ、NATトラバーサルなど）は、非ローカル機能を含むようにNTLPを延長するには利点がないことを直接ピア - ピア場合とそれほど異なっています。代わりに、このようなメッセージを必要とNEのパスを横断避けたいNSLPは、他のいくつかの既存のトランスポートプロトコルを使用する必要があります。例えば、UDPまたはDCCPが提案されているシナリオの多くのために良い試合になるでしょう。謝辞このタイプの通知は、セクション3.3.6でさらに考えられています。
One motivation for restricting the NTLP to peer-relationship scope is that if there are any options or variants in design approach -- or, worse, in basic functionality -- it is easier to manage the resulting complexity if it only impacts direct peers rather than potentially the whole Internet.
基本的な機能や、より悪い、 - - スコープ - 関係ピアにNTLPを制限するための一つの動機は、任意のオプションまたはバリアント設計手法であるかどうかということです、結果の複雑さを管理することが容易であるならば、それだけ影響を与える直接のピアではなく、潜在的にインターネット全体。
Because the NSIS problem includes multiple signaling applications, it is very likely that a particular NSLP will only be implemented on a subset of the NSIS-aware nodes on a path, as shown in Figure 5. In addition, a node inside an aggregation region will still wish to ignore signaling messages that are per-flow, even if they are for a signaling application that the node is generally able to process.
NSISの問題は、複数のシグナリングアプリケーションが含まれているため、また、図5に示すように、特定のNSLPのみ、経路上のNSIS対応ノードのサブセットに集合領域内のノードになります実装される可能性が非常に高いですまだ彼らは、ノードが、一般的に処理することが可能であるシグナリングアプリケーションのためのものである場合でも、フロー毎いるシグナリングメッセージを無視したいです。
+------+ +------+ +------+ +------+
| NE | | NE | | NE | | NE |
|+----+| | | |+----+| |+----+|
||NSLP|| | | ||NSLP|| ||NSLP||
|| 1 || | | || 2 || || 1 ||
|+----+| | | |+----+| |+----+|
| || | | | | | | || |
|+----+| |+----+| |+----+| |+----+|
====||NTLP||====||NTLP||====||NTLP||====||NTLP||====
|+----+| |+----+| |+----+| |+----+|
+------+ +------+ +------+ +------+
Figure 5: Signaling with Heterogeneous NSLPs
図5：ヘテロジニアスNSLPsとシグナリング
Where signaling messages traverse such NSIS-aware intermediate nodes, it is desirable to process them at the lowest level possible (in particular, on the fastest path). In order to offer a non-trivial message transfer service (in terms of security, reliability and so on) to the peer NSLP nodes, it is important that the NTLP at intermediate nodes is as transparent as possible; that is, it carries out minimal processing. In addition, if intermediate nodes have to do slow-path processing of all NSIS messages, this eliminates many of the scaling benefits of aggregation, unless tunneling is used.
シグナリングメッセージは、NSIS対応の中間ノードを通過する場合、（最速パス上に、特に）可能な最低レベルでそれらを処理することが望ましいです。ピアNSLPノードに（セキュリティ、信頼性などの点で）非自明なメッセージ転送サービスを提供するためには、中間ノードでNTLPができるだけ透明であることが重要です。つまり、それは最小限の処理を行います。中間ノードは、すべてのNSISメッセージのスローパスの処理を行う必要がある場合は、トンネリングが使用されていない限りまた、これは、凝集のスケーリング利点の多くを排除します。
Considering first the case of messages sent with the router alert option, there are two complementary methods to achieve this bypassing of intermediate NEs:
最初のルータアラートオプションを使用して送信されたメッセージの場合を考えると、中間のNEのこのバイパスを達成するための2つの補完的な方法があります。
o At the IP layer, a set of protocol numbers or a range of values in the router alert option can be used. In this way, messages can be marked with an implied granularity, and routers can choose to apply further slow-path processing only to configured subsets of messages. This is the method used in [10] to distinguish per-flow and per-aggregate signaling.
IPレイヤ、プロトコル番号のセットやルータ警告オプションの値の範囲でoは使用することができます。このように、メッセージは暗黙の粒度でマークすることができ、およびルータはメッセージのみの構成されたサブセットにさらにスローパス処理を適用することを選択することができます。これは、フロー単位および凝集シグナルを区別する[10]に使用される方法です。
o The NTLP could process the message but determine that there was no local signaling application it was relevant to. At this stage, the message can be returned unchanged to the IP layer for normal forwarding; the intermediate NE has effectively chosen to be transparent to the message in question.
O NTLPは、メッセージを処理し、それはに関連したローカルシグナリングアプリケーションが存在しないことを決定することができます。この段階で、メッセージは、通常の転送のためにIP層に不変戻すことができます。中間NEは、効果的に問題になっているメッセージに透明になるように選択しました。
In both cases, the existence of the intermediate NE is totally hidden from the NSLP nodes. If later stages of the signaling use directly addressed messages (e.g., for reverse routing), they will not involve the intermediate NE at all, except perhaps as a normal router.
どちらの場合も、中間NEの存在は完全にNSLPノードから隠されています。シグナリング使用の後の段階で直接メッセージ（例えば、逆方向ルーティングのための）をアドレス指定する場合、それらは、おそらく通常のルータとして除き、すべてで中間NEを伴わないであろう。
There may be cases where the intermediate NE would like to do some restricted protocol processing, such as the following:
中間NEは、次のような、いくつかの制限されたプロトコル処理を行うたい場合があるかもしれません。
o Translating addresses in message payloads (compare Section 4.6.1); note that this would have to be done to messages passing in both directions through a node.
メッセージペイロードのアドレスを翻訳O（セクション4.6.1を比較）。これは、ノードを介して両方向に通過するメッセージに行わなければならないことに注意してください。
o Updating signaling application payloads with local status information (e.g., path property measurement inside a domain).
ローカルステータス情報とシグナリングアプリケーションペイロードを更新O（例えば、ドメイン内部のパス特性測定）。
If this can be done without fully terminating the NSIS protocols, it would allow a more lightweight implementation of the intermediate NE, and a more direct 'end-to-end' NTLP association between the peer NSLPs where the signaling application is fully processed. On the other hand, this is only possible with a limited class of possible NTLP designs, and makes it harder for the NTLP to offer a security service (since messages have to be partially protected). The feasibility of this approach will be evaluated during the NTLP design.
これは完全にNSISプロトコルを終了せずに行うことができる場合、それは中間NEのより軽量の実装、およびシグナリングアプリケーションが完全に処理されたピアNSLPs間のより直接的な「エンドツーエンド」NTLPの関連付けを可能にするであろう。一方で、これは可能NTLPデザインの限定されたクラスでのみ可能であり、（メッセージが部分的に保護する必要があるため）、それは難しいNTLPがセキュリティサービスを提供できるようになります。このアプローチの実現可能性がNTLP設計時に評価されます。
This section describes the basic functionality to be supported by the NTLP. Note that the overall signaling solution will always be the result of joint operation of both the NTLP and the signaling layer protocols (NSLPs); for example, we can always assume that an NSLP is operating above the NTLP and taking care of end-to-end issues (e.g., recovery of messages after restarts).
このセクションでは、NTLPによりサポートされる基本的な機能を説明します。全体的なシグナル溶液が常にNTLPとシグナリング層プロトコル（NSLPs）の両方の関節の動作の結果であろうことに留意されたいです。例えば、私たちは常にNSLPがNTLPの上に動作し、エンド・ツー・エンドの問題の世話をしていると仮定することができます（例えば、再起動後のメッセージの回復）。
Therefore, NTLP functionality is essentially just efficient upstream and downstream peer-peer message delivery, in a wide variety of network scenarios. Message delivery includes the act of locating and/or selecting which NTLP peer to carry out signaling exchanges with for a specific data flow. This discovery might be an active process (using specific signaling packets) or a passive process (a side effect of using a particular addressing mode). In addition, it appears that the NTLP can sensibly carry out many of the functions that enable signaling messages to pass through middleboxes, since this is closely related to the problem of routing the signaling messages in the first place. Further details about NTLP functionality are contained in Sections 3.2.5 and 4.3.
したがって、NTLP機能は、ネットワークシナリオの広範囲に、本質的に単に効率的な上流および下流のピア・ツー・ピア・メッセージの配信です。メッセージの配信は、NTLPは、特定のデータフローのためとの交流シグナリング行うことピア及び/又は選択を配置する動作を含みます。この発見は、（特定のシグナリングパケットを使用して）アクティブなプロセスまたは受動的プロセス（特定のアドレッシングモードを使用することの副作用）であるかもしれません。また、最初の場所でシグナリングメッセージをルーティングの問題と密接に関連しているので、NTLPが賢明、ミドルボックスを通過するシグナリングメッセージを可能にする機能の多くを実行することができることが表示されます。 NTLPの機能についての詳細は、セクション3.2.5と4.3に含まれています。
Internet signaling requires the existence and management of state within the network for several reasons. This section describes how state management functionality is split across the NSIS layers. (Note that how the NTLP internal state is managed is a matter for its design and indeed implementation.)
インターネットシグナリングは、いくつかの理由のために、ネットワーク内の存在と状態の管理を必要とします。このセクションでは、状態管理機能はNSIS層にまたがって分割される方法を説明します。 （どのようにNTLP内部状態が管理されていることは、そのデザインと実際の実装の問題であることに注意してください。）
1. Conceptually, the NTLP provides a uniform message delivery service. It is unaware of the difference in state semantics between different types of signaling application messages (e.g., whether a message changes, just refreshes signaling application state, or even has nothing to with signaling application state at all).
1.概念的、NTLPは、均一なメッセージ配信サービスを提供します。これは、（例えば、メッセージが変更するかどうか、単にシグナリングアプリケーション状態を更新し、あるいは全くアプリケーションの状態をシグナリングとに何も持たない）アプリケーションシグナリングメッセージの異なるタイプの間の状態の意味の違いを認識しません。
2. An NTLP instance processes and, if necessary, forwards all signaling application messages "immediately". (It might offer different service classes, but these would be distinguished by, for example, reliability or priority, not by state aspects.) This means that the NTLP does not know explicit timer or message sequence information for the signaling application; and that signaling application messages pass immediately through an NSLP-unaware node. (Their timing cannot be jittered there, nor can messages be stored up to be re-sent on a new path in case of a later re-routing event.)
2.アンNTLPインスタンス工程と、必要に応じて、転送すべてのシグナリングアプリケーションメッセージ「直ちに」。 （これは、異なるサービスクラスを提供するかもしれないが、これらは一例、信頼性や優先順位のために、ではない状態の側面によって、によって区別されます。）これはNTLPがシグナリングアプリケーションのための明示的なタイマーやメッセージシーケンス情報を知らないことを意味します。およびシグナリングアプリケーションメッセージがNSLP非対応ノードを介して直ちに通過します。 （そのタイミングがジッターすることができない、またメッセージは、後で再ルーティングイベントの場合、新しい経路で再送信されるまで保存することができます。）
3. Within any node, it is an implementation decision whether to generate/jitter/filter refreshes separately within each signaling application that needs this functionality, or to integrate it with the NTLP implementation as a generic "soft-state management toolbox". The choice doesn't affect the NTLP specification at all. Implementations might piggyback NTLP soft-state refresh information (if the NTLP works this way) on signaling application messages, or they might even combine soft-state management between layers. The state machines of the NTLP and NSLPs remain logically independent, but an implementation is free to allow them to interact to reduce the load on the network to the same level that would be achieved by a monolithic model.
3.任意のノード内で、それが生成する/ジッタ/フィルタは、一般的な「ソフトステート管理ツールボックス」としてNTLP実装でそれを統合するために、この機能を必要とする、または各シグナリングアプリケーション内で別々にリフレッシュするかどうかを実装決定です。選択は全くNTLPの仕様には影響を与えません。 （NTLPがこのように動作するかどうか）実装はアプリケーションシグナリングメッセージにNTLPソフトステートリフレッシュ情報を背負う可能性がある、または彼らも、層間のソフトステート管理を統合することがあります。 NTLPとNSLPsのステートマシンは、論理的に独立したままですが、実装は、それらがモノリシックモデルによって達成されるのと同じレベルにまでネットワークの負荷を軽減するために相互作用することを可能にして自由です。
4. It may be helpful for signaling applications to receive state-management related 'triggers' from the NTLP indicating that a peer has failed or become available ("down/up notifications"). These triggers would be about adjacent NTLP peers, rather than signaling application peers. We can consider this another case of route change detection/notification (which the NTLP is also allowed to do anyway). However, apart from generating such triggers, the NTLP takes no action itself on such events, other than to ensure that subsequent signaling messages are routed correctly.
4.これは、ピアが失敗したか（「ダウン/アップ通知」）が利用可能になったことを示すNTLPから状態管理関連の「トリガー」を受信するアプリケーションを知らせるために有用であり得ます。これらのトリガーは、むしろアプリケーションピアに信号を送るよりも、隣接するNTLPピア程度だろう。私たちは、この（NTLPも、とにかくやって許可されている）ルート変更検出/通知の別のケースを検討することができます。しかし、離れて、このようなトリガを生成するから、NTLPは、後続のシグナリングメッセージが正しく配線されていることを確認するため以外に、このようなイベントに何の行動自体を取りません。
5. The existence of these triggers doesn't replace NSLP refreshes as the mechanism for maintaining liveness at the signaling application level. In this sense, up/down notifications are advisories that allow faster reaction to events in the network, but that shouldn't be built into NSLP semantics. (This is essentially the same distinction, with the same rationale, that SNMP makes between notifications and normal message exchanges.)
5. NSLPを置き換えないこれらのトリガーの存在をシグナリングアプリケーションレベルでの生存性を維持するための機構としてリフレッシュ。この意味で、アップ/ダウンの通知は、ネットワーク内のイベントへのより速い反応を可能勧告しているが、それはNSLPのセマンティクスに組み込まれるべきではありません。 （これは、SNMPは、通知と通常のメッセージ交換の間で行うことが、同じ原理を用いて、本質的に同じ区別です。）
Path-decoupled signaling is defined as signaling for state installation along the data path, without the restriction of passing only through nodes that are located on the data path. Signaling messages can be routed to nodes that are off the data path, but that are (presumably) aware of it. This allows a looser coupling between signaling and data plane nodes (e.g., at the autonomous system level). Although support for path-decoupled operation is not one of the initial goals of the NSIS work, this section is included for completeness and to capture some initial considerations for future reference.
パス切り離さシグナリングは専用データ経路上に配置されているノードを通過するのを制限することなく、データ経路に沿った状態のインストールのためのシグナリングとして定義されます。シグナリングメッセージは、データパスオフになっているノードにルーティングすることができますが、それはそれの（おそらく）認識しています。これは、（自律システムレベルで、例えば）シグナリングとデータプレーンノード間の疎結合を可能にします。パス・デカップリング操作のサポートはNSIS作業の最初の目標の一つではありませんが、このセクションでは、完全を期すために含まれており、今後の参考のためにいくつかの初期の配慮をキャプチャします。
The main advantages of path-decoupled signaling are ease of deployment and support of additional functionality. The ease of deployment comes from a restriction of the number of impacted nodes in case of deployment and/or upgrade of an NSLP. Path-decoupled signaling would allow, for instance, deploying a solution without upgrading any of the routers in the data plane. Additional functionality that can be supported includes the use of off-path proxies to support authorization or accounting architectures.
パス切り離さシグナリングの主な利点は、追加機能の展開とサポートの容易さです。展開のしやすさはNSLPの展開および/またはアップグレードの場合に影響を受けるノード数の制限から来ています。パス切り離さシグナリングは、例えば、データプレーン内のルータのいずれかをアップグレードせずに溶液を導入できるようになります。サポート可能な追加機能が承認または会計アーキテクチャをサポートするために、オフパスプロキシの使用を含みます。
There are potentially significant differences in the way that the two signaling paradigms should be analyzed. Using a single centralized off-path NE may increase the requirements in terms of message handling; on the other hand, path-decoupled signaling is equally applicable to distributed off-path entities. Failure recovery scenarios need to be analyzed differently because fate-sharing between data and control planes can no longer be assumed. Furthermore, the interpretation of sender/receiver orientation becomes less natural. With the local operation of the NTLP, the impact of path-decoupled signaling on the routing of signaling messages is presumably restricted to the problem of peer determination. The assumption that the off-path NSIS nodes are loosely tied to the data path suggests, however, that peer determination can still be based on L3 routing information. This means that a path-decoupled signaling solution could be implemented using a lower-layer protocol presenting the same service interface to NSLPs as the path-coupled NTLP. A new message transport protocol (possibly derived from the path-coupled NTLP) would be needed, but NSLP specifications and the inter-layer interaction would be unchanged from the path-coupled case.
2つの信号のパラダイムが分析されるべき方法に大きな違いが潜在的にあります。メッセージハンドリングの点で要件を増大させることができる単一の集中オフパスNEを用いました。一方、経路切り離さシグナリングは分散オフパスエンティティにも同様に適用可能です。障害回復シナリオは、データプレーンとコントロールプレーン間の運命共有は、もはや仮定できないため別々に分析する必要があります。さらに、送信側/受信側の向きの解釈が少なく、自然になります。 NTLPのローカル操作で、シグナリングメッセージのルーティングにパス切り離さシグナリングの影響は、おそらくピア決意の問題に制限されます。オフパスNSISノードが緩くデータ経路に接続されているという仮定は、ピア決意がまだL3ルーティング情報に基づくことができることが示唆されます。これは、パス切り離さシグナリング溶液パス結合NTLPとしてNSLPsに同じサービス・インターフェースを提示する下位層プロトコルを使用して実施することができることを意味します。 （おそらくパス結合NTLP由来）新しいメッセージ・トランスポート・プロトコルが必要とされるが、NSLP仕様と層間の相互作用は、パス結合の場合と変わらないであろう。
It is clear that many signaling applications will require specific protocol behavior in their NSLP. This section outlines some of the options for NSLP behavior; further work on selecting from these options would depend on detailed analysis of the signaling application in question.
多くのシグナリングアプリケーションがNSLPで特定のプロトコルの動作を必要とするであろうことは明らかです。このセクションでは、NSLPの行動のためのオプションのいくつかを概説します。これらのオプションから選択に関する更なる作業は、問題のシグナリングアプリケーションの詳細な分析に依存するであろう。
In some signaling applications, a node at one end of the data flow takes responsibility for requesting special treatment (such as a resource reservation) from the network. Which end may depend on the signaling application, or on characteristics of the network deployment.
いくつかのシグナリングアプリケーションでは、データフローの一端のノードは、ネットワークから（例えば、リソース予約のような）特別な処理を要求するための責任を負います。これ端は、シグナリングアプリケーションに、またはネットワーク配備の特性に依存し得ます。
In a sender-initiated approach, the sender of the data flow requests and maintains the treatment for that flow. In a receiver-initiated approach, the receiver of the data flow requests and maintains the treatment for that flow. The NTLP itself has no freedom in this area: Next NTLP peers have to be discovered in the sender-to-receiver direction, but after that the default assumption is that signaling is possible both upstream and downstream (unless a signaling application specifically indicates that this is not required). This implies that backward routing state must be maintained by the NTLP or that backward routing information must be available in the signaling message.
送信者が開始したアプローチでは、データ・フロー・リクエストの送信者とその流れのための治療法を維持します。受信機が開始したアプローチでは、データの受信側は、要求を流れ、その流れのための治療を維持します。 NTLP自体は、この領域には自由度がありません：次のNTLPピアは、送信者 - 受信器の方向に発見されなければならないが、その後、デフォルトの仮定は、シグナリングアプリケーションは、具体的に、このことを示していない限り、シグナリングが（上流および下流の両方が可能であるということです必須ではありません）。これは、逆方向ルーティング状態はNTLPによって維持されなければならない、またはその逆方向ルーティング情報をシグナリングメッセージで利用可能でなければならないことを意味します。
The sender- and receiver-initiated approaches have several differences in their operational characteristics. The main ones are as follows:
センダとレシーバが開始したアプローチは、その動作特性のいくつかの違いがあります。次のように主なものは以下のとおりです。
o In a receiver-initiated approach, the signaling messages traveling from the receiver to the sender must be backward routed such that they follow exactly the same path as was followed by the signaling messages belonging to the same flow traveling from the sender to the receiver. In a sender-initiated approach, provided that acknowledgements and notifications can be delivered securely to the sending node, backward routing is not necessary, and nodes do not have to maintain backward routing state.
O受信器で開始アプローチでは、送信側に受信機から走行シグナリングメッセージは逆方向送信機から受信機に走行同じフローに属するシグナリングメッセージが続いたように、それらが正確に同じ経路をたどるようにルーティングされなければなりません。送信者によって開始アプローチでは、肯定応答及び通知が送信ノードに安全に送達することができることを条件とする、後方ルーティングは不要であり、ノードは、下位のルーティング状態を維持する必要はありません。
o In a sender-initiated approach, a mobile node can initiate a reservation for its outgoing flows as soon as it has moved to another roaming subnetwork. In a receiver-initiated approach, a mobile node has to inform the receiver about its handover, thus allowing the receiver to initiate a reservation for these flows. For incoming flows, the reverse argument applies.
O送信者によって開始アプローチでは、モバイルノードは、すぐにそれが別のローミングサブネットワークに移動したように、その発信フローの予約を開始することができます。受信機が開始したアプローチでは、モバイルノードは、このように、受信機がこれらのフローの予約を開始することができ、そのハンドオーバについて受信機に通知しなければなりません。入ってくる流れのために、逆引きが適用されます。
o In general, setup and modification will be fastest if the node responsible for authorizing these actions can initiate them directly within the NSLP. A mismatch between authorizing and initiating NEs will cause additional message exchanges, either in the NSLP or in a protocol executed prior to NSIS invocation. Depending on how the authorization for a particular signaling application is done, this may favor either sender- or receiver-initiated signaling. Note that this may complicate modification of network control state for existing flows.
これらのアクションを許可する責任ノードはNSLP内で直接それらを開始することができればO一般的には、セットアップおよび変更が最速になります。認可と開始NE間のミスマッチはNSLPまたはNSISの呼び出しの前に実行されるプロトコルのいずれかで、追加のメッセージ交換を引き起こすであろう。特定のシグナリングアプリケーションのための認証が行われている方法に応じて、これは、センダまたはレシーバが開始したいずれかのシグナル伝達を好むことがあります。これは既存のフローのためのネットワーク制御状態の変更を複雑にすることができることに留意されたいです。
For some signaling applications and scenarios, signaling may only be considered for a unidirectional data flow. However, in other cases, there may be interesting relationships in the signaling between the two flows of a bi-directional session; an example is QoS for a voice call. Note that the path in the two directions may differ due to asymmetric routing. In the basic case, bi-directional signaling can simply use a separate instance of the same signaling mechanism in each direction.
いくつかのシグナリングアプリケーションとシナリオでは、シグナリングは一方向のみのデータフローのために考慮されてもよいです。しかしながら、他の場合には、双方向セッションの二つの流れの間のシグナリングに興味深い関係があってもよいです。例では、音声通話のためのQoSです。二方向パスは非対称ルーティングのために異なっていてもよいことに留意されたいです。基本的なケースでは、双方向シグナリングは、単純に各方向に同一のシグナル伝達機構の別のインスタンスを使用することができます。
In constrained topologies where parts of the route are symmetric, it may be possible to use a more unified approach to bi-directional signaling; e.g., carrying the two signaling directions in common messages. This optimization might be used for example to make mobile QoS signaling more efficient.
ルートの部分は対称である制約トポロジでは、双方向シグナル伝達に、より統一されたアプローチを使用することも可能です。例えば、一般的なメッセージに2つの信号方向を運びます。この最適化は、シグナリングモバイルQoSは、より効率的にするために、たとえば使用される可能性があります。
In either case, the correlation of the signaling for the two flow directions is carried out in the NSLP. The NTLP would simply be enabled to bundle the messages together.
いずれの場合においても、2つの流れ方向のためのシグナリングの相関はNSLPで行われます。 NTLPは、単にメッセージを一緒にバンドルするために有効にするでしょう。
It is likely that the appropriate way to describe the state for which NSIS is signaling will vary from one part of the network to another (depending on the signaling application). For example, in the QoS case, resource descriptions that are valid for inter-domain links will probably be different from those useful for intra-domain operation (and the latter will differ from one domain to another).
NSISシグナリングされた状態を説明するための適切な方法は、（シグナリングアプリケーションに応じて）ネットワークのある部分から別のものに変化する可能性があります。例えば、QoSのケースでは、ドメイン間リンクの有効なリソース記述は、おそらくドメイン内の操作のために有用なものとは異なるであろう（後者は、あるドメインから別のドメインに異なるであろう）。
One way to address this issue is to consider the state description used within the NSLP as carried in globally-understood objects and locally-understood objects. The local objects are only applicable for intra-domain signaling, while the global objects are mainly used in inter-domain signaling. Note that the local objects are still part of the protocol but are inserted, used, and removed by one single domain.
この問題に対処する1つの方法は、グローバルに理解オブジェクトや地元理解のオブジェクトで運ばとしてNSLP内で使用される状態の説明を考慮することです。グローバルオブジェクトは、主に、ドメイン間のシグナリングに使用されている間、ローカルオブジェクトは、ドメイン内シグナリングのためにのみ適用可能です。ローカルオブジェクトがまだプロトコルの一部であるが、挿入された使用、及び単一ドメインによって除去されることに留意されたいです。
The purpose of this division is to provide additional flexibility in defining the objects carried by the NSLP such that only the objects applicable in a particular setting are used. One approach for reflecting the distinction is that local objects could be put into separate local messages that are initiated and terminated within one single domain; an alternative is that they could be "stacked" within the NSLP messages that are used anyway for inter-domain signaling.
この分割の目的は、特定の設定に適用可能なオブジェクトのみが使用されるようにNSLPによって運ばれるオブジェクトを定義する際にさらなる柔軟性を提供することです。区別を反映させるための一つのアプローチは、ローカルオブジェクトが開始され、1つのドメイン内で終端されている別のローカルメッセージに入れることができることです。代替は、彼らは、ドメイン間のシグナリングのためにとにかく使用されているNSLPメッセージの中に「スタック」することができることです。
It is a well-known problem that per-flow signaling in large-scale networks presents scaling challenges because of the large number of flows that may traverse individual nodes.
これは、大規模ネットワークにおけるフロー毎のシグナリングがあるため、個々のノードを横断することができるフローの多数のスケーリングの課題を提示することは周知の問題です。
The possibilities for aggregation at the level of the NTLP are quite limited; the primary scaling approach for path-coupled signaling is for a signaling application to group flows together and to perform signaling for the aggregate, rather than for the flows individually. The aggregate may be created in a number of ways; for example, the individual flows may be sent down a tunnel, or given a common Differentiated Services Code Point (DSCP) marking. The aggregation and de-aggregation points perform per flow signaling, but nodes within the aggregation region should only be forced to process signaling messages for the aggregate. This depends on the ability of the interior nodes to ignore the per-flow signaling as discussed in Section 3.2.3.
NTLPのレベルでの凝集の可能性は非常に限られています。パス結合シグナルのプライマリスケーリングアプローチは、グループへのシグナリングアプリケーションのために合流され、個別に集計するためではなく、フローのためのシグナリングを実行します。骨材は、いくつかの方法で作成することができます。例えば、個々のフローは、トンネルを下され、又は共通の差別化サービスコードポイント（DSCP）がマーキング与えられてもよいです。凝集および脱凝集点は、フローシグナリングあたり行うが、凝集領域内のノードは、集約のためのシグナリングメッセージを処理するように強制されるべきです。これは、セクション3.2.3で説明したようにフローごとのシグナリングを無視する内部ノードの能力に依存します。
Individual NSLPs will need to specify what aggregation means in their context, and how it should be performed. For example, in the QoS context it is possible to add together the resources specified in a number of separate reservations. In the case of other applications, such as signaling to NATs and firewalls, the feasibility (and even the meaning) of aggregation is less clear.
個々のNSLPsは、凝集がそのコンテキストで何を意味するかを指定する必要があります、そしてそれがどのように実行する必要があります。例えば、QoSのコンテキストでは、別個の予約数で指定されたリソースを一緒に追加することが可能です。このようなのNATやファイアウォールへのシグナリングなどの他のアプリケーションの場合には、凝集の可能性（さらに意味）はあまり明確ではありません。
The assumption in this framework is that the NTLP will operate 'locally'; that is, just over the scope of a single peer relationship. End-to-end operation is built up by concatenating these relationships. Non-local operation (if any) will take place in NSLPs.
このフレームワークでの仮定はNTLPは「ローカル」で動作するということです。それは、ただ一つのピア関係の範囲にわたり、です。エンドツーエンドの操作は、これらの関係を連結することによって構築されます。非ローカル操作は、（もしあれば）NSLPsで行われます。
The peering relations may also have an impact on the required amount of state at each NSIS entity. When direct interaction with remote peers is not allowed, it may be required to keep track of the path that a message has followed through the network. This could be achieved by keeping per-flow state at the NSIS entities, as is done in RSVP. Another approach would be to maintain a record route object in the messages; this object would be carried within the NSIS protocols, rather than depend on the route-recording functionality provided by the IP layer.
ピアリング関係は、各NSISエンティティの状態の必要量に影響を与えることができます。リモートピアとの直接的な相互作用が許可されていない場合は、メッセージがネットワークを介して続いた経路を追跡するために必要とされ得ます。 RSVPに行われているようにこれは、NSIS実体でフローごとの状態を維持することによって達成することができます。別のアプローチは、メッセージのレコードルートオブジェクトを維持することです。このオブジェクトは、IPレイヤによって提供されるルート記録機能に依存するのではなく、NSISプロトコルの中で運ばれることになります。
We are assuming that the NTLP provides a simple message transfer service, and that any acknowledgements or notifications it generates are handled purely internally (and apply within the scope of a single NTLP peer relationship).
我々は、NTLPは、単純なメッセージ転送サービスを提供することが想定され、それは純粋に内部的に処理されて生成する任意の肯定応答又は通知（とは、単一のNTLPピア関係の範囲内で適用する）こと。
However, we expect that some signaling applications will require acknowledgements regarding the failure/success of state installation along the data path, and this will be an NSLP function.
しかし、我々はいくつかのシグナリングアプリケーションは、データパスに沿った状態のインストールの失敗/成功についての承認が必要になることを期待し、これはNSLP機能になります。
Acknowledgements can be sent along the sequence of NTLP peer relationships towards the signaling initiator, which relieves the requirements on the security associations that need to be maintained by NEs and that can allow NAT traversal in both directions. (If this direction is towards the sender, it implies maintaining reverse routing state in the NTLP.) In certain circumstances (e.g., trusted domains), an optimization could be to send acknowledgements directly to the signaling initiator outside the NTLP (see Section 3.2.2), although any such approach would have to take into account the necessity of handling denial of service attacks launched from outside the network.
謝辞のNEによって維持されるように、それが両方向にNATトラバーサルを可能にすることができる必要があるセキュリティアソシエーションに関する要件を緩和シグナリングイニシエータに向かってNTLPピア関係の配列に沿って送信することができます。 （この方向は、送信者に向かっている場合、それはNTLP状態ルーティング逆維持を意味する。）特定の状況（例えば、信頼されたドメイン）において、最適化はNTLP外シグナリングイニシエータ（セクション3.2を参照に直接肯定応答を送信するかもしれません。 2）、どのようなアプローチを考慮にネットワークの外部から打ち上げサービス妨害攻撃を処理する必要性を取る必要がありますが。
The semantics of the acknowledgement messages are of particular importance. An NE sending a message could assume responsibility for the entire downstream chain of NEs, indicating (for instance) the availability of reserved resources for the entire downstream path. Alternatively, the message could have a more local meaning, indicating (for instance) that a certain failure or degradation occurred at a particular point in the network.
受信確認メッセージの意味は特に重要です。メッセージを送信するNEは、NEの全体の下流側鎖、（例えば）を示す全体下流経路のための予約されたリソースの利用について責任を負う可能性があります。代替的に、メッセージは、特定の故障や劣化がネットワーク内の特定の時点で発生したことを（例えば）を示す、より局所的な意味を有することができます。
Notifications differ from acknowledgements because they are not (necessarily) generated in response to other signaling messages. This means that it may not be obvious how to determine where the notification should be sent. Other than that, the same considerations apply as for acknowledgements. One useful distinction to make would be to differentiate between notifications that trigger a signaling action and others that don't. The security requirements for the latter are less stringent, which means they could be sent directly to the NE they are destined for (provided that this NE can be determined).
それらがないので、通知は、他のシグナリングメッセージに応答して生成される（必ずしも）肯定応答異なります。通知が送信されるべき場所を決定する方法は明白ではないかもしれないということを意味します。それ以外は、同じ考慮事項が確認応答用として適用されます。作るために一つの有用な区別はないシグナリングアクションなどをトリガー通知を区別することです。後者のセキュリティ要件は、それらが、それらが（このNEを決定することができることを条件とする）を宛先とするNEに直接送信することができることを意味する、あまり厳しくありません。
In some cases, it will be possible to achieve the necessary level of signaling security by using basic 'channel security' mechanisms [11] at the level of the NTLP, and the possibilities are described in Section 4.7. In other cases, signaling applications may have specific security requirements, in which case they are free to invoke their own authentication and key exchange mechanisms and to apply 'object security' to specific fields within the NSLP messages.
場合によっては、NTLPのレベルで基本的な「チャネルセキュリティ」メカニズム[11]を使用してシグナリングセキュリティの必要なレベルを達成することが可能となり、そして可能性は、セクション4.7に記載されています。他の例では、シグナリング・アプリケーションは、独自の認証と鍵交換のメカニズムを起動するとNSLPメッセージ内の特定のフィールドに「オブジェクトセキュリティ」を適用するために自由である場合には、特定のセキュリティ要件を有していてもよいです。
In addition to authentication, the authorization (to manipulate network control state) has to be considered as functionality above the NTLP level, since it will be entirely application specific. Indeed, authorization decisions may be handed off to a third party in the protocol (e.g., for QoS, the resource management function as described in Section 6.1.4). Many different authorization models are possible, and the variations impact:
認証に加えて、認可が（ネットワーク制御状態を操作するために）、それは完全にアプリケーション固有であるので、NTLPレベル以上の機能として考慮されなければなりません。実際、許可決定をプロトコルに第三者にハンドオフすることができる（例えば、QoSのため、セクション6.1.4に記載したように、リソース管理機能）。多くの異なる認証モデルが可能であり、および変形への影響：
o what message flows take place -- for example, whether authorization information is carried along with a control state modification request or is sent in the reverse direction in response to it;
Oどのメッセージが行わ流れる - 例えば、許可情報が制御状態変更要求と一緒に実施されるかに応じて、逆方向に送信されるかどうか;
o what administrative relationships are required -- for example, whether authorization takes place only between peer signaling applications, or over longer distances.
O管理何の関係が要求される - たとえば、認証がアプリケーションのみのシグナリングピアの間、またはより長い距離を介して行われますか。
Because the NTLP operates only between adjacent peers and places no constraints on the direction or order in which signaling applications can send messages, these authorization aspects are left open to be defined by each NSLP. Further background discussion of this issue is contained in [12].
NTLPのみ隣接ピアと場所の間のシグナリングアプリケーションがメッセージを送信することが可能な方向や順序には制約を運営していないので、これらの許可側面は、各NSLPによって定義されることが開いたままにしています。この問題のさらなる背景の説明は、[12]に含まれています。
This section describes the overall functionality required from the NTLP. It mentions possible protocol components within the NTLP layer and the different possible addressing modes that can be utilized, as well as the assumed transport and state management functionality. The interfaces between NTLP and the layers above and below it are identified, with a description of the identity elements that appear on these interfaces.
このセクションでは、NTLPから必要な全体的な機能について説明します。これはNTLP層とを利用することができる異なる可能なアドレッシングモード内の可能なプロトコル要素、ならびに想定輸送及び状態管理機能に言及しています。 NTLPと、その上下の層の間のインタフェースは、これらのインターフェイスに表示される同一要素の説明と、同定されています。
This discussion is not intended to design the NTLP or even to enumerate design options, although some are included as examples. The goal is to provide a general discussion of required functionality and to highlight some of the issues associated with this.
この議論は、いくつかの例として含まれているが、NTLPを設計したり、デザインオプションを列挙するものではありません。目標は、必要な機能の一般的な議論を提供し、これに関連した問題のいくつかを強調することです。
The NTLP includes all functionality below the signaling application layer and above the IP layer. The functionality that is required within the NTLP is outlined in Section 3.2.4, with some more details in Sections 3.2.5 and 4.3.
NTLPは、シグナリングアプリケーション層の下及びIP層以上のすべての機能を含みます。 NTLP内で必要とされる機能は、セクション3.2.5と4.3のいくつかの詳細を、セクション3.2.4に概説されています。
Some NTLP functionality could be provided via components operating as sublayers within the NTLP design. For example, if specific transport capabilities are required (such as congestion avoidance, retransmission, and security), then existing protocols (such as TCP+TLS or DCCP+IPsec) could be incorporated into the NTLP. This possibility is not required or excluded by this framework.
いくつかのNTLPの機能はNTLPデザイン内のサブレイヤとして動作構成要素を介して提供することができます。特定のトランスポート機能は（例えば、輻輳回避、再送、セキュリティなど）が要求される場合、例えば、（例えば、TCP + TLSまたはDCCP + IPsecのような）既存のプロトコルはNTLPに組み込むことができます。この可能性は、このフレームワークで必要とされるか、除外されていません。
If peer-peer addressing (Section 4.2) is used for some messages, then active next-peer discovery functionality will be required within the NTLP to support the explicit addressing of these messages. This could use message exchanges for dynamic peer discovery as a sublayer within the NTLP; there could also be an interface to external mechanisms to carry out this function.
ピアツーピアアドレッシング（セクション4.2）は、いくつかのメッセージに使用されている場合、アクティブ次のピア発見機能は、これらのメッセージのアドレス指定を明示的にサポートするためにNTLP内で必要とされるであろう。これはNTLP内サブレイヤとして動的ピア発見のためのメッセージ交換を使用することができます。また、この機能を実行するために、外部のメカニズムへのインタフェースがあるかもしれません。
==================== ===========================
^ +------------------+ +-------------------------+
| | | | NSIS Specific Functions |
| | | | .............|
NSIS | | Monolithic | |+----------+. Peer .|
Transport | | Protocol | || Existing |. Discovery .|
Layer | | | || Protocol |. Aspects .|
| | | |+----------+.............|
V +------------------+ +-------------------------+
==================== ===========================
Figure 6: Options for NTLP Structure
図6：NTLP構造のためのオプション
There are two ways to address a signaling message being transmitted between NTLP peers:
NTLPピア間で送信されたシグナリングメッセージに対処する方法は2つあります。
o peer-peer, where the message is addressed to a neighboring NSIS entity that is known to be closer to the destination NE.
メッセージが宛先NEに近いことが知られている隣接するNSISエンティティにアドレス指定されたピア - ピア、O。
o end-to-end, where the message is addressed to the flow destination directly and intercepted by an intervening NE.
Oエンドツーエンドのメッセージを直接流宛先宛および介在NEによって遮断されます。
With peer-peer addressing, an NE will determine the address of the next NE based on the payload of the message (and potentially on the previous NE). This requires that the address of the destination NE be derivable from the information present in the payload, either by using some local routing table or through participation in active peer discovery message exchanges. Peer-peer addressing inherently supports tunneling of messages between NEs, and is equally applicable to the path-coupled and path-decoupled cases.
ピア・ツー・ピアのアドレス指定と、NEは、メッセージ（および潜在的に前NE上）のペイロードに基づいて、次のNEのアドレスを決定します。これは、宛先NEのアドレスは、いくつかのローカルルーティングテーブルを使用して、またはアクティブピア発見メッセージ交換に参加を通じてのいずれかで、ペイロードに存在する情報から誘導されることを必要とします。本質的に対処するピアツーピアは、NE間のメッセージのトンネリングをサポートし、パス結合およびパス・デカップリングの場合にも同様に適用可能です。
In the case of end-to-end addressing, the message is addressed to the data flow receiver, and (some of) the NEs along the data path intercept the messages. The routing of the messages should follow exactly the same path as the associated data flow (but see Section 5.1.1 on this point). Note that securing messages sent this way raises some interesting security issues (these are discussed in [2]). In addition, it is a matter of the protocol design what should be used as the source address of the message (the flow source or signaling source).
エンドツーエンドのアドレス指定の場合に、メッセージがデータフロー受信機にアドレス指定され、そしてメッセージインターセプトデータパスに沿ってのNE（の一部）。メッセージのルーティングは、関連するデータ・フローと全く同じ経路をたどる（しかし、この点については、セクション5.1.1を参照）すべきです。このように送信されたメッセージを確保することは、いくつかの興味深いセキュリティ上の問題を提起することに注意してください（これらはで議論されている[2]）。また、メッセージ（流源または信号源）の送信元アドレスとして使用されるべきプロトコルの設計の問題です。
It is not possible at this stage to mandate one addressing mode or the other. Indeed, each is necessary for some aspects of NTLP operation: In particular, initial discovery of the next downstream peer will usually require end-to-end addressing, whereas reverse routing will always require peer-peer addressing. For other message types, the choice is a matter of protocol design. The mode used is not visible to the NSLP, and the information needed in each case is available from the flow identifier (Section 4.6.1) or locally stored NTLP state.
これは、1つのアドレッシングモードまたは他のを強制するために、この段階では不可能です。実際、それぞれがNTLP操作のいくつかの態様のために必要である：逆ルーティングが常にアドレッシングピアツーピアを必要とするのに対し、特に、次の下流のピアの最初の発見は、通常、エンド・ツー・エンドのアドレス指定を必要とするであろう。他のメッセージタイプの場合、選択肢は、プロトコルの設計の問題です。使用されるモードはNSLPには見えないが、それぞれの場合に必要な情報は、フロー識別子（セクション4.6.1）またはローカルに格納されたNTLP状態から入手可能です。
The NSIS signaling protocols are responsible for transporting (signaling) data around the network; in general, this requires functionality such as congestion management, reliability, and so on. This section discusses how much of this functionality should be provided within the NTLP. It appears that this doesn't affect the basic way in which the NSLP/NTLP layers relate to each other (e.g., in terms of the semantics of the inter-layer interaction); it is much more a question of the overall performance/complexity tradeoff implied by placing certain functions within each layer.
NSISシグナリングプロトコルはネットワーク周り（シグナリング）のデータを転送するための責任があります。一般的に、これには、このような輻輳管理などの機能性、信頼性、およびが必要です。このセクションでは、NTLPの中に提供されるべきか、この機能の多くについて説明します。 NSLP / NTLPレイヤ（例えば、レイヤ間の相互作用の意味論の観点で）互いに関連する基本的な方法に影響を与えないように思われます。それは、それぞれの層の中に特定の機能を配置することによって、暗黙の全体的なパフォーマンス/複雑性のトレードオフのはるかに質問です。
Note that, per the discussion at the end of Section 3.2.3, there may be cases where intermediate nodes wish to modify messages in transit even though they do not perform full signaling application processing. In this case, not all the following functionality would be invoked at every intermediate node.
3.2.3の最後に議論につき、中間ノードは、彼らが完全なシグナリングアプリケーションの処理を行わなくても輸送中のメッセージを変更したい場合があるかもしれない、ということに注意してください。この場合には、全てではない以下の機能は、すべての中間ノードで呼び出されることになります。
The following functionality is assumed to lie within the NTLP:
以下の機能がNTLPの中にあると想定されます。
1. Bundling together of small messages (comparable to [13]) can be provided locally by the NTLP as an option, if desired; it doesn't affect the operation of the network elsewhere. The NTLP should always support unbundling, to avoid the cost of negotiating the feature as an option. (The related function of refresh summarization -- where objects in a refresh message are replaced with a reference to a previous message identifier -- is left to NSLPs, which can then do this in a way tuned to the state management requirements of the signaling application. Additional transparent compression functionality could be added to the NTLP design later as a local option.) Note that end-to-end addressed messages for different flows cannot be bundled safely unless the next node on the outgoing interface is known to be NSIS-aware.
1.（[13]と同等）小さなメッセージを一緒にバンドル所望であれば、オプションとしてNTLPによって局所的に提供することができます。それは他の場所でネットワークの動作に影響を与えません。 NTLPは常にオプションとしての機能を交渉のコストを避けるために、アンバンドリングをサポートする必要があります。リフレッシュ要約の（関連する機能 - リフレッシュメッセージ内のオブジェクトは、以前のメッセージ識別子を用いて置換される - NSLPsに残され、その後、シグナリングアプリケーションの状態管理要件に同調方法でこれを行うことができ。追加の透明圧縮機能は、後に地元のオプションとしてNTLPデザインに追加することができます。）発信インターフェイス上の次のノードがNSIS認識であることが知られていない限り異なるフローのため、エンド・ツー・エンドの対処メッセージが安全に同梱することはできません。
2. When needed, message fragmentation should be provided by the NTLP. The use of IP fragmentation for large messages may lead to reduced reliability and may be incompatible with some addressing schemes. Therefore, this functionality should be provided within the NTLP as a service for NSLPs that generate large messages. How the NTLP determines and accommodates Maximum Transmission Unit (MTU) constraints is left as a matter of protocol design. To avoid imposing the cost of reassembly on intermediate nodes, the fragmentation scheme used should allow for the independent forwarding of individual fragments towards a node hosting an interested NSLP.
2.必要に応じて、メッセージの断片化は、NTLPによって提供されるべきです。大きなメッセージのためのIPフラグメンテーションの使用は、信頼性低下につながる可能性があり、一部のアドレス指定方式と互換性がない可能性があります。したがって、この機能は、大きなメッセージを生成NSLPsのサービスとしてNTLP内に提供されるべきです。 NTLPが決定して収納する方法最大伝送単位（MTU）の制約は、プロトコル設計の問題として残されています。中間ノードの再構築のコストを課す避けるために、使用フラグメンテーションスキームは興味NSLPをホスティングしているノードに向けた個々の断片の独立した転送を可能にしなければなりません。
3. There can be significant benefits for signaling applications if state-changing messages are delivered reliably (as introduced in [13] for RSVP; see also the more general analysis of [14]). This does not change any assumption about the use of soft-state by NSLPs to manage signaling application state, and it leaves the responsibility for detecting and recovering from application layer error conditions in the NSLP. However, it means that such functionality does not need to be tuned to handle fast recovery from message loss due to congestion or corruption in the lower layers, and it also means that the NTLP can prevent the amplification of message loss rates caused by fragmentation. Reliable delivery functionality is invoked by the NSLP on a message-by-message basis and is always optional to use.
前記状態変更メッセージが確実に配信される場合にアプリケーションをシグナリングするための重要な利点があり得る（[13]で導入されるようRSVPのために、また、より一般的な分析を参照[14]）。これは、アプリケーションの状態を管理するためのシグナリングをNSLPsでソフト状態の使用についての仮定を変更しない、それが検出およびNSLPにおけるアプリケーション層のエラー状態からの回復のための責任を残します。しかし、それはそのような機能が下位層における輻輳や破損によるメッセージの損失からの迅速なリカバリを処理するように調整する必要がないことを意味し、それはまた、NTLPが断片化によって引き起こされるメッセージの損失率の増幅を防止することができることを意味します。信頼性の高い配信機能は、メッセージごとにNSLPによって呼び出され、常に使用するオプションです。
4. The NTLP should not allow signaling messages to cause congestion in the network (i.e., at the IP layer). Congestion could be caused by retransmission of lost signaling packets or by upper layer actions (e.g., a flood of signaling updates to recover from a route change). In some cases, it may be possible to engineer the network to ensure that signaling cannot overload it; in others, the NTLP would have to detect congestion and to adapt the rate at which it allows signaling messages to be transmitted. Principles of congestion control in Internet protocols are given in [15]. The NTLP may or may not be able to detect overload in the control plane itself (e.g., an NSLP-aware node several NTLP-hops away that cannot keep up with the incoming message rate) and indicate this as a flow-control condition to local signaling applications. However, for both the congestion and overload cases, it is up to the signaling applications themselves to adapt their behavior accordingly.
4. NTLP（すなわち、IP層での）ネットワークの輻輳を引き起こすシグナリングメッセージを許可してはなりません。輻輳が失われたシグナリングパケットの再送によって、または上層アクション（例えば、経路変更から回復するための更新シグナリングの洪水）によって引き起こされ得ます。いくつかのケースでは、それをオーバーロードすることができないシグナル伝達を確実にするためにネットワークを設計することも可能です。他では、NTLPは、輻輳を検出し、それがシグナリングメッセージを送信することを可能にする速度を適応させる必要があります。インターネット・プロトコルの輻輳制御の原理は、[15]に記載されています。 NTLPはまたは（例えば、着信メッセージの速度に追いつくことができない離れNSLP対応ノードいくつかのNTLPホップ）制御プレーン自体に過負荷を検出することができるし、ローカルにフロー制御条件としてこれを示していてもいなくてもよいですシグナリング・アプリケーションに最適です。しかし、両方の渋滞や過負荷の場合のために、それに応じてその動作を適応させるために、シグナリングアプリケーション自体に任されています。
The NTLP interacts with 'lower layers' of the protocol stack for the purposes of sending and receiving signaling messages. This framework places the lower boundary of the NTLP at the IP layer. The interface to the lower layer is therefore very simple:
NTLPは、シグナリングメッセージを送受信するの目的のためのプロトコルスタックの「下層」と相互作用します。このフレームワークは、IP層でNTLPの下限を配置します。下位レイヤへのインタフェースは、したがって、非常に簡単です。
o The NTLP sends raw IP packets
O NTLPは生のIPパケットを送信します
o The NTLP receives raw IP packets. In the case of peer-peer addressing, they have been addressed directly to it. In the case of end-to-end addressing, this will be achieved by intercepting packets that have been marked in some special way (by special protocol number or by some option interpreted within the IP layer, such as the router alert option).
O NTLPは生のIPパケットを受信します。ピア・ツー・ピアアドレッシングの場合、彼らはそれに直接対処されています。エンドツーエンドのアドレッシングの場合、これは（特別なプロトコル番号によって、またはそのようなルータ警告オプションとしてIPレイヤ内で解釈いくつかのオプションにより）いくつかの特別な方法でマークされたパケットを傍受することによって達成されます。
o The NTLP receives indications from the IP layer (including local forwarding tables and routing protocol state) that provide some information about route changes and similar events (see Section 5.1).
O NTLPは、ルート変更及び類似のイベント（セクション5.1を参照）に関する情報を提供する（ローカル転送テーブルとルーティングプロトコル状態を含む）IP層からの指示を受信します。
For correct message routing, the NTLP needs to have some information about link and IP layer configuration of the local networking stack. In general, it needs to know how to select the outgoing interface for a signaling message and where this must match the interface that will be used by the corresponding flow. This might be as simple as just allowing the IP layer to handle the message using its own routing table. There is no intention to do something different from IP routing (for end-to-end addressed messages); however, some hosts allow applications to bypass routing for their data flows, and the NTLP processing must account for this. Further network layer information would be needed to handle scoped addresses (if such things ever exist).
正しいメッセージのルーティングのために、NTLPは、リンクやローカルネットワークスタックのIPレイヤの構成に関するいくつかの情報を持っている必要があります。一般的には、シグナリングメッセージの発信インターフェイスを選択し、ここで、これは、対応するフローによって使用されるインターフェースと一致しなければならない方法を知っている必要があります。これは、単にIP層は独自のルーティングテーブルを使用してメッセージを処理できるようにするのと同じくらい簡単かもしれません。 （エンド・ツー・エンドのメッセージに対処するために）IPルーティングとは異なる何かをするつもりはありません。しかし、いくつかのホストは、アプリケーションがデータフローのルーティングをバイパスすることができ、かつNTLP処理がこのことを考慮しなければなりません。さらに、ネットワーク層情報は、（このようなことは今まで存在している場合）、スコープのアドレスを処理するために必要とされるであろう。
Configuration of lower-layer operation to handle flows in particular ways is handled by the signaling application.
特定の方法でフローを処理するために下層動作の構成は、シグナリングアプリケーションによって処理されます。
The NTLP offers transport-layer services to higher-layer signaling applications for two purposes: sending and receiving signaling messages, and exchanging control and feedback information.
送信およびシグナリングメッセージを受信し、制御およびフィードバック情報を交換する：NTLPは2つの目的のために、上位層のシグナリングアプリケーションへのトランスポート層のサービスを提供しています。
For sending and receiving messages, two basic control primitives are required:
メッセージを送受信するための、二つの基本的な制御プリミティブが必要です。
o Send Message, to allow the signaling application to pass data to the NTLP for transport.
Oシグナリングアプリケーションは、輸送のためNTLPにデータを渡すことができるように、メッセージを送信します。
o Receive Message, to allow the NTLP to pass received data to the signaling application.
O NTLPがシグナリングアプリケーションに受信データを渡すことができるように、メッセージを表示します。
The NTLP and signaling application may also want to exchange other control information, such as the following:
NTLPとシグナリングアプリケーションは、次のような、他の制御情報を交換することができます。
o Signaling application registration/de-registration, so that particular signaling application instances can register their presence with the transport layer. This may also require some identifier to be agreed upon between the NTLP and signaling application to support the exchange of further control information and to allow the de-multiplexing of incoming data.
特定のシグナリングアプリケーションインスタンスがトランスポート層でその存在を登録することができるように、アプリケーションの登録/登録解除をシグナリングO。これはまた、いくつかの識別子がNTLPとシグナリングアプリケーション、さらに制御情報の交換をサポートするために、着信データの逆多重化を可能にする間に合意する必要ができます。
o NTLP configuration, allowing signaling applications to indicate what optional NTLP features they want to use, and to configure NTLP operation, such as controlling what transport layer state should be maintained.
O NTLP構成、彼らが使用したい任意何NTLPの特徴を示すために、このようなトランスポート層状態を維持すべきかを制御としてNTLP動作を設定するためのアプリケーションシグナリングを可能にします。
o Error messages, to allow the NTLP to indicate error conditions to the signaling application, and vice versa.
NTLPがシグナリングアプリケーション、およびその逆にエラー条件を指示できるようにOエラーメッセージ、。
o Feedback information, such as route change indications so that the signaling application can decide what action to take.
このような経路変更適応症としてOフィードバック情報、シグナリングアプリケーションが取るべきアクションを決定できるように。
The flow identification is a method of identifying a flow in a unique way. All packets associated with the same flow will be identified by the same flow identifier. The key aspect of the flow identifier is to provide enough information such that the signaling flow receives the same treatment along the data path as the actual data itself; i.e., consistent behavior is applied to the signaling and data flows by a NAT or policy-based forwarding engine.
フロー識別は、独自の方法でフローを識別する方法です。同じフローに関連付けられたすべてのパケットは同じフロー識別子によって識別されます。フロー識別子の重要な側面は、シグナリングフローは、実際のデータ自体のデータ経路に沿って同一の処理を受けるように、十分な情報を提供することです。即ち、一貫性のある動作は、シグナリングおよびデータに適用されているNATまたはポリシーベースの転送エンジンによって流れます。
Information that could be used in flow identification may include:
フロー識別に使用できる情報を含むことができます。
o source IP address;
O送信元IPアドレス。
o destination IP address;
O宛先IPアドレス。
o protocol identifier and higher layer (port) addressing;
Oプロトコル識別子と上位レイヤ（ポート）アドレッシング。
o flow label (typical for IPv6);
（IPv6のための典型的な）Oフローラベル。
o SPI field for IPsec encapsulated data; and
O IPsecのSPIフィールドには、データをカプセル化。そして
o DSCP/TOS field.
O DSCP / TOSフィールド。
It is assumed that at most limited wildcarding on these identifiers is needed.
これらの識別子上で最も制限されたワイルドカードが必要とされているものとします。
We assume here that the flow identification is not hidden within the NSLP, but is explicitly part of the NTLP. The justification for this is that being able to do NSIS processing, even at a node which was unaware of the specific signaling application (see Section 3.2.3) might be valuable. An example scenario would be messages passing through an addressing boundary where the flow identification had to be re-written.
私たちは、フロー識別がNSLPの中に隠されていないことを、ここで前提としますが、明示的にNTLPの一部です。このため正当化も、特定のシグナリングアプリケーションの知らなかったノードにおいて、NSIS処理を実行することができる（セクション3.2.3参照）貴重であるかもしれないということです。シナリオ例は、フロー識別が再書き込みされなければならなかったアドレッシング境界を通過するメッセージであろう。
There are circumstances in which being able to refer to signaling application state independently of the underlying flow is important. For example, if the address of one of the flow endpoints changes due to a mobility event, it is desirable to be able to change the flow identifier without having to install a completely new reservation. The session identifier provides a method to correlate the signaling about the different flows with the same network control state.
独立して、基礎となるフローのアプリケーションの状態をシグナリングすることが重要であるを参照することができるような状況があります。例えば、モビリティイベントに起因するフローエンドポイントの変更のいずれかのアドレスならば、完全に新しい予約をインストールすることなくフロー識別子を変更できることが望ましいです。セッション識別子は、同一のネットワーク制御状態と異なるフローに関するシグナリングを相関させる方法を提供します。
The session identifier is essentially a signaling application concept, since it is only used in non-trivial state management actions that are application specific. However, we assume here that it should be visible within the NTLP. This enables it to be used to control NTLP behavior; for example, by controlling how the transport layer should forward packets belonging to this session (as opposed to this signaling application). In addition, the session identifier can be used by the NTLP to demultiplex received signaling messages between multiple instances of the same signaling application, if such an operational scenario is supported (see Section 4.6.3 for more information on signaling application identification).
それが唯一のアプリケーション固有である非自明な状態管理アクションで使用されているので、セッション識別子は、基本的にシグナリングアプリケーションの概念です。しかし、我々はそれがNTLPの中に見えなければならないことを、ここで想定しています。これはNTLPの動作を制御するために使用されることを可能にします。例えば、トランスポート層は、このセッションに属するパケットを転送する方法を制御することにより（このシグナリングアプリケーションとは対照的に）。このような動作シナリオがサポートされている場合に加えて、セッション識別子が同一のシグナリングアプリケーションの複数のインスタンス間で受信されたシグナリングメッセージを逆多重化するためにNTLPによって使用することができ、（アプリケーション識別シグナリングの詳細については、セクション4.6.3を参照）。
To be useful for mobility support, the session identifier should be globally unique, and it should not be modified end-to-end. It is well known that it is practically impossible to generate identifiers in a way that guarantees this property; however, using a large random number makes it highly likely. In any case, the NTLP ascribes no valuable semantics to the identifier (such as 'session ownership'); this problem is left to the signaling application, which may be able to secure it to be used for this purpose.
モビリティサポートのために有用であるために、セッション識別子は、グローバルに一意である必要があり、そしてそれは、エンドツーエンドを変更すべきではありません。よく、このプロパティを保証した方法で識別子を生成することは事実上不可能であることが知られています。しかし、大規模な乱数を使用すると、それは可能性が高いことができます。いずれの場合においても、NTLPは、（例えば、「セッションの所有権」として）識別子への貴重な意味を帰していません。この問題は、この目的のために使用されることを確保することができる場合があり、シグナリングアプリケーションに任されています。
Because the NTLP can be used to support several NSLP types, there is a need to identify which type a particular signaling message exchange is being used for. This is to support:
NTLPは、いくつかのNSLPタイプをサポートするために使用することができるので、特定のシグナリングメッセージの交換をするために使用されているタイプを識別する必要があります。これは、サポートすることです：
o processing of incoming messages -- the NTLP should be able to demultiplex these towards the appropriate signaling applications; and
着信メッセージのO処理 - NTLPは、適切なシグナリングアプリケーションに向かってこれらを分離することができなければなりません。そして
o processing of general messages at an NSIS-aware intermediate node -- if the node does not handle the specific signaling application, it should be able to make a forwarding decision without having to parse upper-layer information.
NSIS認識中間ノードにおける一般的なメッセージのO処理 - ノードは、特定のシグナリングアプリケーションを処理しない場合、上位レイヤ情報を解析することなく、転送決定を行うことができなければなりません。
No position is taken on the form of the signaling application identifier, or even the structure of the signaling application 'space': free-standing applications, potentially overlapping groups of capabilities, etc. These details should not influence the rest of the NTLP design.
潜在的にこれらの詳細は、NTLPデザインの残りの部分に影響を与えてはならないなど、機能のグループを重ね、自立用途：いいえ位置は、シグナリングアプリケーション識別子、またはシグナリングアプリケーション「スペース」のも、構造の形で取られません。
It is assumed that the only security service required within the NTLP is channel security. Channel security requires a security association to be established between the signaling endpoints, which is carried out via some authentication and key management exchange. This functionality could be provided by reusing a standard protocol.
NTLPの中に必要な唯一のセキュリティサービスは、チャネルセキュリティであるとします。チャネルのセキュリティは、いくつかの認証と鍵管理交換を介して行われるシグナリングエンドポイントの間に確立されるセキュリティアソシエーションが必要です。この機能は、標準プロトコルを再利用して提供することができます。
In order to protect a particular signaling exchange, the NSIS entity needs to select the security association that it has in place with the next NSIS entity that will be receiving the signaling message. The ease of doing this depends on the addressing model in use by the NTLP (see Section 4.2).
特定のシグナリング交換を保護するために、NSISエンティティは、シグナリングメッセージを受信する次のNSISエンティティと適所に有するセキュリティアソシエーションを選択する必要があります。これを行うのしやすさがNTLPで使用されているアドレス指定のモデルによって異なります（4.2節を参照してください）。
Channel security can provide many different types of protection to signaling exchanges, including integrity and replay protection and encryption. It is not clear which of these is required at the NTLP layer, although most channel security mechanisms support them all. It is also not clear how tightly an NSLP can 'bind' to the channel security service provided by the NTLP.
チャネルセキュリティは、完全性とリプレイ保護や暗号化などの交流を、シグナルへの保護の多くの異なる種類を提供することができます。ほとんどのチャネルセキュリティメカニズムは、それらすべてをサポートするが、NTLPレイヤで必要とされるこれらのかが明確ではありません。どのようにしっかりNSLPがNTLPによって提供されるチャネルのセキュリティ・サービスに「バインド」することができますまた、明確ではありません。
Channel security can also be applied to the signaling messages with differing granularity; i.e., all or parts of the signaling message may be protected. For example, if the flow is traversing a NAT, only the parts of the message that do not need to be processed by the NAT should be protected. (Alternatively, if the NAT takes part in NTLP security procedures, it only needs to be given access to the message fields containing addresses, often just the flow id.) Which parts of the NTLP messages need protecting is an open question, as is what type of protection should be applied to each.
チャネルセキュリティも粒度が異なるシグナリングメッセージに適用することができます。すなわち、シグナリングメッセージのすべてまたは部分は保護されていてもよいです。フローはNATを通過されている場合、NATによって処理する必要のないメッセージの部分だけを保護する必要があります。 （NATがNTLPのセキュリティ手順に関与する場合あるいは、それだけで、多くの場合、単にフローIDをアドレスを含むメッセージ・フィールドへのアクセスを付与する必要があります。）であるとしてNTLPメッセージの部分は、保護が未解決の問題である必要がある何保護の種類は、それぞれに適用されなければなりません。
The NTLP is responsible for determining the next node to be visited by the signaling protocol. For path-coupled signaling, this next node should be one that will be visited by the data flow. In practice, this peer discovery will be approximate, as any node could use any feature of the peer discovery packet to route it differently from the corresponding data flow packets. Divergence between the data and signaling paths can occur due to load sharing or load balancing (Section 5.1.1). An example specific to the case of QoS is given in Section 6.1.1. Route changes cause a temporary divergence between the data path and the path on which signaling state has been installed. The occurrence, detection, and impact of route changes is described in Section 5.1.2. A description of this issue in the context of QoS is given in Section 6.1.2.
NTLPは、シグナリングプロトコルによって訪問されるべき次のノードを決定する責任があります。パス結合シグナリングのために、この次のノードは、データフローによって訪問されるものであるべきです。任意のノードが異なる対応するデータフローパケットからのルートにピア発見パケットの任意の機能を使用することができるように、実際には、このピア発見は、近似であろう。データおよびシグナリング経路との間の乖離が原因負荷共有またはロードバランシング（セクション5.1.1）に発生する可能性があります。 QoSの場合に具体的な例は、6.1.1項に示されています。ルート変更は、データパスとシグナリング状態がインストールされているパスの間の一時的な乖離の原因となります。ルート変更の発生、検出、および影響は、セクション5.1.2に記載されています。 QoSののコンテキストで、この問題の説明は、セクション6.1.2に記載されています。
Load sharing or load balancing is a network optimization technique that exploits the existence of multiple paths to the same destination in order to obtain benefits in terms of protection, resource efficiency, or network stability. It has been proposed for a number of routing protocols, such as OSPF [16] and others. In general, load sharing means that packet forwarding will take into account header fields in addition to the destination address; a general discussion of such techniques and the problems they cause is provided in [17].
負荷分散やロードバランシングは、保護、資源効率、ネットワーク安定性の点で利点を得るために、同じ宛先への複数のパスの存在を利用するネットワーク最適化技術です。このようなOSPF [16]などのようなルーティングプロトコル、多数提案されています。一般に、負荷分散は、パケット転送は、宛先アドレスに加えてアカウントヘッダフィールドにかかることを意味します。そのような技術およびそれらが引き起こす問題の一般的な議論は[17]で提供されます。
The significance of load sharing in the context of NSIS is that routing of signaling messages using end-to-end addressing does not guarantee that these messages will follow the data path. Policy-based forwarding for data packets -- where the outgoing link is selected based on policy information about fields additional to the packet destination address -- has the same impact. Signaling and data packets may diverge because of both of these techniques.
NSISの文脈における負荷分散の重要性は、エンドツーエンドのアドレス指定を使用してシグナリングメッセージのルーティングは、これらのメッセージは、データ・パスに続くことを保証するものではないということです。ポリシー・ベースのデータ・パケットの転送 - 発信リンクがパケットの宛先アドレスに追加のフィールドに関するポリシー情報に基づいて選択される - 同じインパクトを有します。シグナリングおよびデータパケットは、これらの技術の両方を発散することがあります。
If signaling packets are given source and destination addresses identical to data packets, signaling and data may still diverge because of layer-4 load balancing (based on protocol or port). Such techniques would also cause ICMP errors to be misdirected to the source of the data because of source address spoofing. If signaling packets are made identical in the complete 5-tuple, divergence may still occur because of the presence of router alert options. The same ICMP misdirection applies, and it becomes difficult for the end systems to distinguish between data and signaling packets. Finally, QoS routing techniques may base the routing decision on any field in the packet header (e.g., DSCP).
シグナリングパケットは、データパケットと同じ送信元および宛先アドレスを指定されたシグナリングおよびデータは依然としてため（プロトコルまたはポートに基づいて）レイヤ4ロードバランシング発散できる。いる場合このような技術はまた、ICMPエラーが原因で送信元アドレススプーフィングのデータのソースに誤って誘導される原因になります。シグナリングパケットが完全な5タプルで同じにしている場合は、発散がまだあるため、ルータアラートオプションの存在により発生する可能性があります。同じICMPの誤った方向に適用され、エンドシステムはデータおよびシグナリングパケットを区別することが困難となります。最後に、QoSルーティング技術は、パケットヘッダ（例えば、DSCP）の任意のフィールドにルーティング決定を基づかできます。
In a connectionless network, each packet is independently routed based on its header information. Whenever a better route towards the destination becomes available, this route is installed in the forwarding table and will be used for all subsequent (data and signaling) packets. This can cause a divergence between the path along which state has been installed and the path along which forwarding will actually take place. The problem of route changes is reduced if route pinning is performed. Route pinning refers to the independence of the path taken by certain data packets from reachability changes caused by routing updates from an Interior Gateway Protocol (OSPF, IS-IS) or an Exterior Gateway Protocol (BGP). Nothing about NSIS signaling prevents route pinning from being used as a network engineering technique, provided that it is done in a way that preserves the common routing of signaling and data. However, even if route pinning is used, it cannot be depended on to prevent all route changes (for example, in the case of link failures).
コネクションレスネットワークでは、各パケットは、独立して、そのヘッダ情報に基づいてルーティングされます。先に向かって、より良いルートが利用可能になるたびに、この経路は、転送テーブルにインストールされ、それ以降のすべての（データおよびシグナリング）パケットに使用されるであろう。これは、状態がインストールされているに沿ってパスおよび転送が実際に行われます、それに沿ってパス間の乖離を引き起こす可能性があります。ルートピニングが行われた場合はルート変更の問題が軽減されます。ルートピニングインテリアゲートウェイプロトコル（OSPF、IS-IS）又は外部ゲートウェイプロトコル（BGP）からアップデートをルーティングすることによって引き起こされる到達性の変化から特定のデータパケットによって取られる経路の独立を意味します。 NSISシグナリングについては何もネットワークエンジニアリング技術として使用されるのピンニング経路を妨げるものはない、それは、シグナリング及びデータの共通のルーティングを保存方法で行われることを条件とします。しかし、ルートピニングを使用しても、（例えば、リンク障害の場合）すべてのルートの変更を防止するために依存することはできません。
Handling route changes requires the presence of three processes in the signaling protocol:
ルート変更を処理するシグナリングプロトコルに三つのプロセスの存在を必要とします。
1. route change detection
1.ルート変更検出
2. installation of state on the new path
新しいパスの状態の2.インストール
3. removal of state on the old path
古いパス上の状態の3除去
Many route change detection methods can be used, some needing explicit protocol support, and some of which are implementation-internal. They differ in their speed of reaction and in the types of change they can detect. In rough order of increasing applicability, they can be summarized as follows:
多くの経路変更検出方法は、いくつかの必要明示的なプロトコル・サポートを使用することができ、そのうちのいくつかは、実装内部です。彼らは反応の彼らの速さが異なると変化の種類に彼らは検出することができます。次のように増加適用可能性の荒いために、彼らは要約することができます。
1. monitoring changes in local forwarding table state
ローカル転送テーブルの状態1.監視変更
2. monitoring topology changes in a link-state routing protocol
リンクステートルーティングプロトコル2.モニタリングトポロジの変更
3. inference from changes in data packet TTL
データパケットのTTLの変化から前記推論
4. inference from loss of packet stream in a flow-aware router
流れ認識ルータにおけるパケットストリームの損失から4推論
5. inference from changes in signaling packet TTL
シグナリングパケットのTTLの変化から前記推論
6. changed route of an end-to-end addressed signaling packet
6.シグナリングパケット対処エンド・ツー・エンドの経路を変更しました
7. changed route of a specific end-to-end addressed probe packet
7.特定のエンド・ツー・エンドのアドレス指定プローブパケットの経路を変更しました
These methods can be categorized as being based on network monitoring (methods 1-2), on data packet monitoring (methods 3-4) and on monitoring signaling protocol messages (methods 5-7); method 6 is the baseline method of RSVP. The network monitoring methods can only detect local changes; in particular, method 1 can only detect an event that changes the immediate next downstream hop, and method 2 can only detect changes within the scope of the link-state protocol. Methods 5-7, which are contingent on monitoring signaling messages, become less effective as soft-state refresh rates are reduced.
これらの方法は、（方法3-4）と、監視シグナリングプロトコルメッセージ（方法5-7）上でデータパケット監視に、ネットワーク監視（方法1-2）に基づいているとして分類することができます。方法6は、RSVPのベースライン方法です。ネットワーク監視方法は、ローカル変化を検出することができます。特に、方法1は、即時次の下流のホップを変更するイベントを検出することができ、及び方法2は、リンクステートプロトコルの範囲内で変更を検出することができます。ソフトステートリフレッシュレートが低下しているとして、シグナリングメッセージの監視の偶発されている方法5-7は、あまり有効となります。
When a route change has been detected, it is important that state is installed as quickly as possible along the new path. It is not guaranteed that the new path will be able to provide the same characteristics that were available on the old path. To avoid duplicate state installation or, worse, rejection of the signaling message because of previously installed state, it is important to be able to recognize the new signaling message as belonging to an existing session. In this respect, we distinguish between route changes with associated change of the flow identification (e.g., in case of a mobility event when the IP source might change) and route changes without change of the flow identification (e.g., in case of a link failure along the path). The former case requires an identifier independent from the flow identification; i.e., the session identifier (Section 4.6.2). Mobility issues are discussed in more detail in Section 5.2.
ルート変更が検出された場合は、状態は新しいパスに沿って、可能な限り迅速にインストールされていることが重要です。新しいパスが古いパスで使用可能だった同じ特性を提供できるようになることを保証するものではありません。重複した状態のインストールや、さらに悪い、なぜなら、以前にインストールされた状態のシグナリングメッセージの拒絶反応を回避するためには、既存のセッションに属するものとして、新たなシグナリングメッセージを認識できることが重要です。この点で、我々は、フロー識別の関連する変化とルート変更（モビリティイベントの場合には、例えば、IPソースが変更される可能性があります）、リンク障害が発生した場合に、フロー識別の変更せずにルート変更（例えば、区別します）パスに沿って。前者の場合は、フロー識別から独立識別子を必要とします即ち、セッション識別子（セクション4.6.2）。モビリティの問題は、5.2節で詳しく説明されています。
When state has been installed along the new path, the existing state on the old path needs to be removed. With the soft-state principle, this will happen automatically because of the lack of refresh messages. Depending on the refresh timer, however, it may be required to tear down this state much faster (e.g., because it is tied to an accounting record). In that case, the teardown message needs to be able to distinguish between the new path and the old path.
状態は、新しいパスに沿って設置された場合は、古いパス上の既存の状態を除去する必要があります。ソフトステート原理で、これは、リフレッシュメッセージの不足のため自動的に行われます。 （それはアカウンティングレコードに結びついているので、例えば）リフレッシュタイマによっては、しかし、はるかに速く、この状態を取り壊すために必要とすることができます。その場合には、ティアダウンメッセージは、新しいパスと、古いパスを区別できるようにする必要があります。
In some environments, it is desirable to provide connectivity and per-flow or per-class state management with high-availability characteristics; i.e., with rapid transparent recovery, even in the presence of route changes. This may require interactions with protocols that are used to manage the routing in this case, such as Virtual Router Redundancy Protocol (VRRP) [18].
いくつかの環境では、接続ごとの流量または高可用性特性を持つクラス毎の状態管理を提供することが望ましいです。すなわち、でもルート変更の存在下での急速な復旧、と。これは、仮想ルータ冗長プロトコル（VRRP）、この場合にルーティングを管理するために使用されるプロトコル、[18]との相互作用を必要とするかもしれません。
Our basic assumption about such interactions is that the NTLP would be responsible for detecting the route change and ensuring that signaling messages were re-routed consistently (in the same way as the data traffic). However, further state re-synchronization (including failover between 'main' and 'standby' nodes in the high availability case) would be the responsibility of the signaling application and its NSLP, and would possibly be triggered by the NTLP.
このような相互作用に関する当社の基本的な前提は、NTLPは、ルート変更を検出し、シグナリングメッセージは、（データトラフィックと同じように）一貫再ルーティングされたことを保証する責任があるだろうということです。しかし、（高可用性の場合の「主」と「スタンバイ」のノード間のフェイルオーバーを含む）、さらに状態の再同期は、シグナリングアプリケーションとそのNSLPの責任であろう、そしておそらくNTLPによってトリガーされるであろう。
The issues associated with mobility and multihoming are a generalization of the basic route change case of the previous section. As well as the fact that packets for a given session are no longer traveling over a single topological path, the following extra considerations arise:
モビリティとマルチホーミングに関連した問題は、前のセクションの基本的なルート変更の例一般化しています。同様に与えられたセッションのためのパケットは、もはや単一トポロジパス上を移動していることを事実として、以下の追加の考慮事項が発生します：
1. The use of IP-layer mobility and multihoming means that more than one IP source or destination address will be associated with a single session. The same applies if application-layer solutions (e.g., SIP-based approaches) are used.
1. IPレイヤモビリティ及びマルチホーミングの使用は、複数のIP送信元または宛先アドレスが、単一のセッションに関連することを意味します。アプリケーション層ソリューション（例えば、SIPベースのアプローチ）を使用する場合も同じことが当てはまります。
2. Mobile IP and associated protocols use some special encapsulations for some segments of the data path.
2.モバイルIPと関連プロトコルは、データパスの一部のセグメントのためのいくつかの特別なカプセル化を使用します。
3. The double route may persist for some time in the network (e.g., in the case of a 'make-before-break' handover being done by a multihomed host).
3.二重経路（例えば、「メークビフォアブレーク」ハンドオーバの場合にマルチホームホストによって行われる）ネットワーク内のいくつかの時間持続することができます。
4. Conversely, the re-routing may be rapid and routine (unlike network-internal route changes), increasing the importance of rapid state release on old paths.
4.逆に、再ルーティングは、古いパスの急速状態解除の重要性を増加させる、（ネットワーク内部ルート変更とは異なり）迅速かつルーチンであってもよいです。
The interactions between mobility and signaling have been extensively analyzed in recent years, primarily in the context of RSVP and Mobile IP interaction (e.g., the mobility discussion of [5]), but also in that of other types of network (e.g., [19]). A general review of the fundamental interactions is given in [20], which provides further details on many of the subjects considered in this section.
モビリティとシグナリングの間の相互作用は広く、主にRSVPとモバイルIPの相互作用（例えば、[5]のモビリティ議論）の文脈ではなく、他のタイプのネットワーク（例えば、のように、近年では分析されている[19 ]）。基本相互作用の一般的な総説は、このセクションで考慮対象の多くの詳細を提供する、[20]に記載されています。
We assume that the signaling will refer to 'outer' IP headers when defining the flows it is controlling. There are two main reasons for this. The first is that the data plane will usually be unable to work in terms of anything else when implementing per-flow treatment (e.g., we cannot expect that a router will analyze inner headers to decide how to schedule packets). The second reason is that we are implicitly relying on the security provided by the network infrastructure to ensure that the correct packets are given the special treatment being signaled for, and this is built on the relationship between packet source and destination addresses and network topology. (This is essentially the same approach that is used as the basis of route optimization security in Mobile IPv6 [21].) The consequence of this assumption is that we see the packet streams to (or from) different addresses as different flows. Where a flow is carried inside a tunnel, it is seen as a different flow again. The encapsulation issues (point (2) above) are therefore to be handled the same way as other tunneling cases (Section 5.4).
私たちは、それが制御しているフローを定義する際に、シグナリングが「外側のIPヘッダを参照することを前提としています。これには二つの主な理由があります。最初は、データプレーンは通常、フローごとの治療を実装するときに何かの面で作業することができませんということである（例えば、我々は、ルータがパケットをスケジュールする方法を決定するために、内部ヘッダを分析することを期待することはできません）。第二の理由は、私たちが暗黙のうち、正しいパケットがの合図をしている特別な治療を与えられていることを確認するために、ネットワークインフラストラクチャによって提供されるセキュリティに依存している、そしてこれは、パケットの送信元アドレス、宛先アドレス、およびネットワークトポロジとの関係に基づいて構築されていることです。 （これは、本質的にモバイルIPv6 [21]における経路最適化のセキュリティの基礎として使用されるのと同じアプローチである。）この仮定の結果は、我々は、異なるフローとして異なるアドレスパケットに（又はから）ストリームを見ることです。流れがトンネル内行われる場合、それは再び、異なるフローとして見られています。カプセル化問題（点（2））は、したがって、他のトンネルの場合（5.4）と同じように扱われるべきです。
Therefore, the most critical aspect is that multiple flows are being used, and the signaling for them needs to be correlated. This is the intended role of the session identifier (see Section 4.6.2, which also describes some of the security requirements for such an identifier). Although the session identifier is visible at the NTLP, the signaling application is responsible for performing the correlation (and for doing so securely). The NTLP responsibility is limited to delivering the signaling messages for each flow between the correct signaling application peers. The locations at which the correlation takes place are the end system and the signaling- application-aware node in the network where the flows meet. (This node is generally referred to as the "crossover router"; it can be anywhere in the network.)
したがって、最も重要な側面は、複数のフローが使用されていることであり、そのためのシグナリングは、相関される必要があります。これは、セッション識別子（また、そのような識別子のためのセキュリティ要件のいくつかを説明し、セクション4.6.2を参照）の意図的な役割です。セッション識別子はNTLPで可視であるが、シグナリングアプリケーションは（かつ確実にそうするために）相関を実行する責任があります。 NTLP責任は正しいシグナリングアプリケーションピア間の各フローのためのシグナリングメッセージの配信に限定されます。相関が起こる場所は、流れが満たすネットワーク内のエンドシステムとsignaling-アプリケーションアウェアノードです。 （このノードは、一般に「クロスオーバールータ」と呼ばれ、それがネットワーク内のどこであってもよいです。）
Although much work has been done in the past on finding the crossover router directly from information held in particular mobility signaling protocols, the initial focus of NSIS work should be a solution that is not tightly bound to any single mobility approach. In other words, it should be possible to determine the crossover router based on NSIS signaling. (This doesn't rule out the possibility that some implementations may be able to do this discovery faster; e.g., by being tightly integrated with local mobility management protocols. This is directly comparable to spotting route changes in fixed networks by being routing aware.)
多くの仕事は、特定のモビリティシグナリングプロトコルで開催された情報から直接クロスオーバールータを見つけることに、過去に行われてきたが、NSIS作業の最初の焦点は、しっかりと任意の単一のモビリティアプローチにバインドされていないソリューションでなければなりません。換言すれば、NSISシグナリングに基づいて、クロスオーバールータを決定することが可能であるべきです。 （これは、いくつかの実装が速くこの発見を行うことができるかもしれないという可能性を排除しない、例えば、しっかりローカルモビリティ管理プロトコルと統合されることにより、これはアウェアルーティングされて固定ネットワークにおけるルート変更をスポットと直接比較です。）。
Note that the crossover router discovery may involve end-to-end signaling exchanges (especially for flows towards the mobile or multihomed node), which raises a latency concern. On the other hand, end-to-end signaling will have been necessary in any case, at the application level not only to communicate changed addresses, but also to update packet classifiers along the path. It is a matter for further analysis to decide how these exchanges could be combined or carried out in parallel.
クロスオーバールータの発見は、エンドツーエンド待ち時間の懸念を提起し、（特にモバイルまたはマルチホームノードに向かって流れるために）交換シグナリングを含み得ることに留意されたいです。一方、エンドツーエンドシグナリングは、どのような場合に必要であったであろう、アプリケーション・レベルで変更アドレスを通信するだけでなく、パスに沿ってパケット分類器を更新します。これらの交換を組み合わせたり、並列に行うことができた方法を決定するために更なる分析のための問題です。
On the shared part of the path, signaling is needed at least to update the packet classifiers to include the new flow, although if correlation with the existing flow is possible it should be possible to bypass any policy or admission control processing. State installation on the new path (and possibly release on the old one) are also required. Which entity (one of the end hosts or the crossover router) controls all these procedures depends on which entities are authorized to carry out network state manipulations, so this is therefore a matter of signaling application and NSLP design. The approach may depend on the sender/receiver orientation of the original signaling (see Section 3.3.1). In addition, in the mobility case, the old path may no longer be directly accessible to the mobile node; inter-access-router communication may be required to release state in these circumstances.
経路の共有部分に、シグナリングは、既存のフローとの相関が可能である場合、任意のポリシーまたはアドミッション制御処理をバイパスすることが可能であるべきであるが、新たなフローを含むように、パケット分類器を更新するために少なくとも必要です。新しいパス（おそらく古いものにリリース）の状態のインストールも必要とされています。どのエンティティ（エンドホストやクロスオーバールータの1）は、すべてのこれらの手順を制御することで、ネットワークの状態操作を実行するために許可されているエンティティに依存し、これはそのためのアプリケーションやNSLPデザインのシグナリングの問題です。アプローチ（セクション3.3.1を参照）、元の信号の送信側/受信側の向きに依存し得ます。加えて、モビリティの場合に、古い経路は、もはやモバイルノードに直接アクセスしなくてもよいです。インターアクセス・ルータの通信は、このような状況で状態を解除する必要があります。
The frequency of handovers in some network types makes fast handover support protocols desirable, for selecting the optimal access router for handover (for example, [22]), and for transferring state information to avoid having to regenerate it in the new access router after handover (for example, [23]). Both of these procedures could have strong interactions with signaling protocols. The access router selection might depend on the network control state that could be supported on the path through the new access router. Transfer of signaling application state or NTLP/NSLP protocol state may be a candidate for context transfer.
いくつかのネットワークタイプにおけるハンドオーバの頻度は、（例えば、[22]）ハンドオーバーのための最適なアクセスルータを選択するため、ハンドオーバ後の新たなアクセスルータでそれを再生することを避けるために、状態情報を転送するために、望ましい高速ハンドオーバをサポートプロトコルを行います（例えば、[23]）。これらの手順の両方は、シグナリングプロトコルとの強い相互作用を持つことができます。アクセスルータの選択は、新しいアクセスルータを介してパスでサポートできるネットワークの制御状態に依存する場合があります。シグナリングアプリケーション状態又はNTLP / NSLPプロトコル状態の転送は、コンテキスト転送の候補とすることができます。
Because at least some messages will almost inevitably contain addresses and possibly higher-layer information as payload, we must consider the interaction with address translation devices (NATs). These considerations apply both to 'traditional' NATs of various types (as defined in [24]) as well as some IPv4/v6 transition mechanisms, such as Stateless IP/ICMP Translation (SIIT) [25].
少なくともいくつかのメッセージは、ほぼ必然的にアドレスやペイロードとしておそらく上位レイヤの情報が含まれていますので、我々は、アドレス変換デバイス（NATを）との相互作用を考慮しなければなりません。これらの考慮事項は、[25]様々な種類（[24]で定義されるように）、ならびにそのようなステートレスIP / ICMP翻訳（SIIT）のようないくつかのIPv4 / v6の遷移メカニズムの「伝統的な」のNATの両方に適用します。
In the simplest case of an NSIS-unaware NAT in the path, payloads will be uncorrected, and signaling will refer to the flow incorrectly. Applications could attempt to use STUN [26] or similar techniques to detect and recover from the presence of the NAT. Even then, NSIS protocols would have to use a well-known encapsulation (TCP/UDP/ICMP) to avoid being dropped by more cautious low-end NAT devices.
パスにおけるNSIS非対応NATの最も単純なケースでは、ペイロードは、補正されていないであろう、そしてシグナルが誤って流れを指します。アプリケーションはSTUN [26]または検出およびNATの存在から回復するために同様の技術を使用しようとすることができます。それでも、NSISプロトコルは、より慎重なローエンドのNATデバイスによってドロップされるのを避けるために、よく知られているカプセル化（TCP / UDP / ICMP）を使用しなければならないでしょう。
A simple 'NSIS-aware' NAT would require flow identification information to be in the clear and not to be integrity protected. An alternative conceptual approach is to consider the NAT functionality part of message processing itself, in which case the translating node can take part natively in any NSIS protocol security mechanisms. Depending on NSIS protocol layering, it would be possible for this processing to be done in an NSIS entity that was otherwise ignorant of any particular signaling applications. This is the motivation for including basic flow identification information in the NTLP (Section 4.6.1).
シンプルな「NSIS対応の」NATを明確にするために、フロー識別情報を必要とし、完全性を保護することはありません。別の概念的アプローチは、翻訳ノードは、任意のNSISプロトコルのセキュリティメカニズムでネイティブに参加することができ、その場合、それ自体を処理するメッセージのNAT機能部分を、考慮することです。この処理は、任意の特定のシグナリングアプリケーションのそれ以外の場合は無知であったNSISエンティティにおいて行われるためNSISプロトコルレイヤリングに応じて、それが可能です。これはNTLP（セクション4.6.1）における基本的なフロー識別情報を含むための動機です。
Note that all of this discussion is independent of the use of a specific NSLP for general control of NATs (and firewalls). That case is considered in Section 6.2.
この議論の全ては、NATの（およびファイアウォール）の一般的な制御のための特定のNSLPの使用とは無関係であることに留意されたいです。その場合は、セクション6.2で考えられています。
Tunneling is used in the Internet for a number of reasons, such as flow aggregation, IPv4/6 transition mechanisms, mobile IP, virtual private networking, and so on. An NSIS solution must continue to work in the presence of these techniques. The presence of the tunnel should not cause problems for end-to-end signaling, and it should also be possible to use NSIS signaling to control the treatment of the packets carrying the tunneled data.
トンネリングは、フロー集約などの理由、そうでのIPv4 / 6移行メカニズム、モバイルIP、仮想プライベートネットワーク、および多くのためにインターネットで使用されています。 NSISソリューションは、これらの技術の存在下での作業を続けなければなりません。トンネルの存在は、エンドツーエンドシグナリングの問題を引き起こしてはならない、また、トンネリングされたデータを搬送するパケットの処理を制御するために、NSISシグナリングを使用することが可能であるべきです。
It is assumed that the NSIS approach will be similar to that of [27], where the signaling for the end-to-end data flow is tunneled along with that data flow and is invisible to nodes along the path of the tunnel (other than the endpoints). This provides backwards compatibility with networks where the tunnel endpoints do not support the NSIS protocols. We assume that NEs will not unwrap tunnel encapsulations to find and process tunneled signaling messages.
それ以外の（エンド・ツー・エンドのデータフローのためのシグナリングは、データフローと共にトンネリング及びトンネルの経路に沿ってノードに不可視である場合、NSISアプローチは、[27]のものと同様であろうと想定されますエンドポイント）。これは、トンネルエンドポイントは、NSISプロトコルをサポートしないネットワークとの下位互換性を提供します。私たちは、NEが見つけるためにトンネルカプセル化を解いて処理シグナリングメッセージをトンネル化しないことを前提としています。
To signal for the packets carrying the tunneled data, the tunnel is considered a new data flow in its own right, and NSIS signaling is applied to it recursively. This requires signaling support in at least one tunnel endpoint. In some cases (where the signaling initiator is at the opposite end of the data flow from the tunnel initiator; i.e., in the case of receiver initiated signaling), the ability to provide a binding between the original flow identification and that for the tunneled flow is needed. It is left open here whether this should be an NTLP or an NSLP function.
トンネリングされたデータを搬送するパケットの信号には、トンネルはそれ自体で新規データ・フローとみなされ、NSISシグナリングは再帰的に適用されます。これは、少なくとも1つのトンネルエンドポイントでサポートシグナリングが必要です。いくつかのケースでは（シグナリングイニシエータは、トンネル・イニシエータからのデータフローの反対側の端部にあり、すなわち、受信機の場合にシグナリング開始される）、能力は、トンネルの流れの元のフロー識別とその間の結合を提供するため必要とされています。これはNTLPやNSLP機能するかどうかをここで開いたままにされます。
This section gives an overview of NSLPs for particular signaling applications. The assumption is that the NSLP uses the generic functionality of the NTLP given earlier; this section describes specific aspects of NSLP operation. It includes simple examples that are intended to clarify how NSLPs fit into the framework. It does not replace or even form part of the formal NSLP protocol specifications; in particular, initial designs are being developed for NSLPs for resource reservation [28] and middlebox communication [29].
このセクションでは、特定のシグナリングアプリケーションのためのNSLPsの概要を説明します。仮定はNSLPが早く与えられたNTLPの一般的な機能を使用することです。このセクションはNSLP操作の特定の側面を説明しています。それはNSLPsは、フレームワークにどのように適合するかを明確に意図されている簡単な例を含んでいます。これは、交換する、あるいは正式なNSLPプロトコル仕様の一部を構成するものではありません。特に、初期のデザインは[29]、リソース予約[28]とミドル通信用NSLPsために開発されています。
In the case of signaling for QoS, all the basic NSIS concepts of Section 3.1 apply. In addition, there is an assumed directionality of the signaling process, in that one end of the signaling flow takes responsibility for actually requesting the resource. This leads to the following definitions:
QoSのためのシグナリングの場合は、3.1節のすべての基本的なNSISの概念が適用されます。また、実際にリソースを要求するための責任を負うシグナリングフローの一端にシグナリング処理の想定方向があります。これは、次の定義につながります。
o QoS NSIS Initiator (QNI): the signaling entity that makes the resource request, usually as a result of user application request.
OのQoS NSISイニシエータ（QNI）：通常、ユーザーアプリケーション要求の結果として、リソース要求を行うシグナリングエンティティ。
o QoS NSIS Responder (QNR): the signaling entity that acts as the endpoint for the signaling and that can optionally interact with applications as well.
OのQoS NSISレスポンダ（QNR）：シグナリングのエンドポイントとして機能し、それは選択的にアプリケーションと対話することができるシグナリングエンティティ。
o QoS NSIS Forwarder (QNF): a signaling entity between a QNI and QNR that propagates NSIS signaling further through the network.
OのQoS NSISフォワーダ（QNF）：NSISは、ネットワークを介して更なるシグナリング伝搬QNIとQNRとの間のシグナリングエンティティ。
Each of these entities will interact with a resource management function (RMF) that actually allocates network resources (router buffers, interface bandwidth, and so on).
これらの各エンティティは、実際に（ようにルータのバッファ、インターフェイスの帯域幅、および）ネットワークリソースを割り当て、リソース管理機能（RMF）と相互に作用します。
Note that there is no constraint on which end of the signaling flow should take the QNI role: With respect to the data flow direction, it could be at the sending or receiving end.
QNI役割を担うべきシグナリングフローのどの端部には制約がないことに注意：データの流れの方向に関しては、送受信端であってもよいです。
The QoS NSLP will include a set of messages to carry out resource reservations along the signaling path. A possible set of message semantics for the QoS NSLP is shown below. Note that the 'direction' column in the table below only indicates the 'orientation' of the message. Messages can be originated and absorbed at QNF nodes as well as the QNI or QNR; an example might be QNFs at the edge of a domain exchanging messages to set up resources for a flow across a it. Note that it is left open if the responder can release or modify a reservation, during or after setup. This seems mainly a matter of assumptions about authorization, and the possibilities might depend on resource type specifics.
QoSのNSLPは、シグナリングパスに沿ってリソース予約を実行するためにメッセージのセットが含まれます。 QoSのNSLPのためのメッセージの意味の可能なセットを以下に示します。のみ以下の表の「方向」列は、メッセージの「方向」を示していることに留意されたいです。メッセージが発信され、QNFがQNI又はQNRならびにノードに吸収することができます。例では、それを横切る流れのためのリソースを設定するためにメッセージを交換ドメインのエッジでQNFsかもしれません。レスポンダがセットアップ中または後に、予約を解除または変更することができた場合、それが開いたままにされていることに注意してください。これは、認可に関する仮定、および可能性の問題は、リソースタイプの仕様に依存する場合があります主に思えます。
The table also explicitly includes a refresh operation. This does nothing to a reservation except extend its lifetime, and it is one possible state management mechanism (see next section).
表には、明示的にリフレッシュ動作を含んでいます。これは、その寿命を延ばす除い予約に何もしません、それは一つの可能な状態管理メカニズム（次のセクションを参照）です。
+-----------+-----------+-------------------------------------------+
| Operation | Direction | Operation |
+-----------+-----------+-------------------------------------------+
| Request | I-->R | Create a new reservation for a flow |
| | | |
| Modify | I-->R | Modify an existing reservation |
| | (&R-->I?) | |
| | | |
| Release | I-->R | Delete (tear down) an existing |
| | (&R-->I?) | reservation |
| | | |
| Accept/ | R-->I | Confirm (possibly modified?) or reject a |
| Reject | | reservation request |
| | | |
| Notify | I-->R & | Report an event detected within the |
| | R-->I | network |
| | | |
| Refresh | I-->R | State management (see Section 6.1.2) |
+-----------+-----------+-------------------------------------------+
The primary purpose of NSIS is to manage state information along the path taken by a data flow. The issues regarding state management within the NTLP (state related to message transport) are described in Section 4. The QoS NSLP will typically have to handle additional state related to the desired resource reservation to be made.
NSISの主な目的は、データフローによって取られる経路に沿って状態情報を管理することです。 NTLP（メッセージ転送に関連する状態）内の状態管理に関する問題は、QoS NSLPは、典型的に行われることが望まリソース予約に関連する追加の状態を処理しなければならないセクション4に記載されています。
There two critical issues to be considered in building a robust NSLP to handle this problem:
そこにこの問題を処理するために、堅牢なNSLPを構築する際に考慮すべき2つの重要な問題は：
o The protocol must be scalable. It should allow minimization of the resource reservation state-storage demands that it implies for intermediate nodes; in particular, storage of state per 'micro' flow is likely to be impossible except at the very edge of the network. A QoS signaling application might require per-flow or lower granularity state; examples of each for the case of QoS would be IntServ [30] or RMD [31] (per 'class' state), respectively.
Oプロトコルはスケーラブルでなければなりません。それが中間ノードのための意味リソースの予約状態記憶要求の最小化を可能にすべきです。特に、「マイクロ」フローごとの状態のストレージは、ネットワークの非常にエッジを除いて不可能である可能性が高いです。アプリケーションQoSシグナリングごとの流量または低い粒状状態必要になる場合があります。 QoSの場合のそれぞれの例は、それぞれ、（「クラス」状態当たり）のIntServ [30]又はRMD [31]であろう。
o The protocol must be robust against failure and other conditions that imply that the stored resource reservation state has to be moved or removed.
Oプロトコルは、障害と記憶されたリソース予約状態が移動または削除されなければならないことを意味するもので、他の条件に対してロバストでなければなりません。
For resource reservations, soft-state management is typically used as a general robustness mechanism. According to the discussion of Section 3.2.5, the soft-state protocol mechanisms are built into the NSLP for the specific signaling application that needs them; the NTLP sees this simply as a sequence of (presumably identical) messages.
リソース予約のために、ソフトステート管理は、典型的には、一般的な堅牢性機構として使用されます。セクション3.2.5の議論によれば、ソフトステートプロトコルメカニズムは、それらを必要とする特定のシグナリングアプリケーションのためのNSLPに組み込まれています。 NTLPは単純に（おそらく同一の）メッセージのシーケンスとしてこれを見ています。
In this section, we will explore the expected interaction between resource signaling and routing updates (the precise source of routing updates does not matter). The normal operation of the NSIS protocol will lead to the situation depicted in Figure 7, where the reserved resources match the data path.
このセクションでは、リソースのシグナリングおよびルーティングアップデート（ルーティングアップデートの正確な供給源は関係ありません）との間に予想される相互作用を検討します。 NSISプロトコルの正常な動作が確保されたリソースは、データパスに一致する。図7に示されている状況につながります。
reserved +-----+ reserved +-----+
=========>| QNF |===========>| QNF |
+-----+ +-----+
--------------------------------------->
data path
Figure 7: Normal NSIS Protocol Operation
図7：通常のNSISプロトコル動作
A route change can occur while such a reservation is in place. The route change will be installed immediately, and any data will be forwarded on the new path. This situation is depicted Figure 8.
そのような予約が整備されている間、ルート変更が発生する可能性があります。ルート変更はすぐにインストールされ、任意のデータを新しいパスに転送されます。この状況は、図8に描かれています。
Resource reservation on the new path will only be started once the next control message is routed along the new path. This means that there is a certain time interval during which resources are not reserved on (part of) the data path, and certain delay or drop-sensitive applications will require that this time interval be minimized. Several techniques to achieve this could be considered. As an example, RSVP [7] has the concept of local repair, whereby the router may be triggered by a route change. In that case, the RSVP node can start sending PATH messages directly after the route has been changed. Note that this option may not be available if no per-flow state is kept in the QNF. Another approach would be to pre-install backup state, and it would be the responsibility of the QoS-NSLP to do this. However, mechanisms for identifying backup paths and routing the necessary signaling messages along them are not currently considered in the NSIS requirements and framework.
次の制御メッセージは、新しいパスに沿ってルーティングされた後、新しいパス上のリソース予約にのみ開始されます。これは、リソースがこの時間間隔が最小化されることを必要とするであろう（の一部）は、データパス、および特定の遅延または低下に敏感なアプリケーションに予約されていない時に一定の時間間隔があることを意味します。これを達成するためのいくつかの技術が考えることができます。一例として、RSVP [7]ルータが経路変更によってトリガすることができることにより、局所的な修復の概念を有します。その場合には、RSVPノードは、ルートが変更された直後にPATHメッセージの送信を開始することができます。何のフローごとの状態はQNFに保管されていない場合、このオプションは使用できない場合があります。別のアプローチは、バックアップの状態を事前にインストールすることになり、これを行うためのQoSの-NSLPの責任になります。しかし、バックアップパスを識別し、それらに沿って必要なシグナリングメッセージをルーティングするためのメカニズムは、現在、NSIS要件と枠組みにおいて考慮されません。
Route update
|
v
reserved +-----+ reserved +-----+
=========>| QNF |===========>| QNF |
+-----+ +-----+
-------- ||
\ || +-----+
| ===========>| QNF |
| +-----+
+--------------------------->
data path
Figure 8: Route Change
図8：ルート変更
The new path might not be able to provide the same guarantees that were available on the old path. Therefore, it might be desirable for the QNF to wait until resources have been reserved on the new path before allowing the route change to be installed (unless, of course, the old path no longer exists). However, delaying the route change installation while waiting for reservation setup needs careful analysis of the interaction with the routing protocol being used, in order to avoid routing loops.
新しいパスが古いパスで使用可能だった同じ保証を提供できないことがあります。リソースは、経路変更が（もちろん、古いパスがもはや存在しない、しない限り）をインストールすることを許可する前に新しいパス上に確保されるまでQNFが待機するため、それは望ましいかもしれません。ただし、予約セットアップを待っている間にルート変更のインストールを遅らせることは、ルーティングループを避けるために、使用されているルーティングプロトコルとの相互作用を慎重に分析する必要があります。
Another example related to route changes is denoted as severe congestion and is explained in [31]. This solution adapts to a route change when a route change creates congestion on the new routed path.
ルート変更に関連する別の例は、重度の輻輳として示され、[31]で説明されています。ルート変更は、新しいルーティングされたパス上の輻輳を作成するときに、このソリューションは、ルート変更に適応します。
The QoS NSLP itself is not involved in any specific resource allocation or management techniques. The definition of an NSLP for resource reservation with Quality of Service, however, implies the notion of admission control. For a QoS NSLP, the measure of signaling success will be the ability to reserve resources from the total resource pool that is provisioned in the network. We define the function responsible for allocating this resource pool as the Resource Management Function (RMF). The RMF is responsible for all resource provisioning, monitoring, and assurance functions in the network.
QoSのNSLP自体は、特定のリソースの割り当てや管理技術に関与していません。サービスの品質とリソース予約のためのNSLPの定義は、しかし、アドミッション制御の概念を意味します。 QoSのNSLPのために、シグナルの成功の尺度は、ネットワークでプロビジョニングされた総リソースプールからのリソースを予約する機能になります。私たちは、リソース管理機能（RMF）として、このリソースプールを割り当てるための責任の関数を定義します。 RMFは、ネットワーク内のすべてのリソースのプロビジョニング、監視、および保証機能を担っています。
A QoS NSLP will rely on the RMF to do resource management and to provide inputs for admission control. In this model, the RMF acts as a server towards client NSLP(s). Note, however, that the RMF may in turn use another NSLP instance to do the actual resource provisioning in the network. In this case, the RMF acts as the initiator (client) of an NSLP.
QoSのNSLPは、リソース管理を行うこととアドミッション制御のための入力を提供するために、RMFに依存しています。このモデルでは、RMFは、クライアントNSLP（S）に向けたサーバーとして動作します。 RMFは、順番に、ネットワーク内の実際のリソースのプロビジョニングを行うには、別のNSLPインスタンスを使用すること、しかし、注意してください。この場合には、RMFはNSLPのイニシエータ（クライアント）として機能します。
This essentially corresponds to a multi-level signaling paradigm, with an 'upper' level handling internetworking QoS signaling (possibly running end-to-end), and a 'lower' level handling the more specialized intra-domain QoS signaling (running between just the edges of the network). (See [10], [32], and [33] for a discussion of similar architectures.) Given that NSIS signaling is already supposed to be able to support multiple instances of NSLPs for a given flow and limited scope (e.g., edge-to-edge) operation, it is not currently clear that supporting the multi-level model leads to any new protocol requirements for the QoS NSLP.
これは本質的に（おそらく実行されているエンドツーエンドの）シグナリングインターネットワーキングQoSを取り扱う「上部」レベル、及びだけ間を走る（シグナリングより特殊ドメイン内QoSを扱う「低い」レベルと、マルチレベルシグナリングパラダイムに対応しますネットワークのエッジ）。 （同様のアーキテクチャの議論については[33] [32]、[10]参照、および。）NSISシグナリングが既に所与のフローと限られた範囲のためNSLPsの複数のインスタンスをサポートすることができるようになっていることを考えると（例えば、edge-エッジ）の操作は、マルチレベルのモデルをサポートするのQoS NSLPのための任意の新しいプロトコル要件につながることは現在明らかではありません。
The RMF may or may not be co-located with a QNF (note that co-location with a QNI/QNR can be handled logically as a combination between QNF and QNI/QNR). To cater for both cases, we define a (possibly logical) QNF-RMF interface. Over this interface, information may be provided from the RMF about monitoring, resource availability, topology, and configuration. In the other direction, the interface may be used to trigger requests for resource provisioning. One way to formalize the interface between the QNF and the RMF is via a Service Level Agreement (SLA). The SLA may be static or it may be dynamically updated by means of a negotiation protocol. Such a protocol is outside the scope of NSIS.
RMFは、または（QNFおよびQNI / QNRの組み合わせとして論理的に扱うことができるQNI / QNRと共位置に注意）QNFと同じ場所に配置してもしなくてもよいです。両方の場合に対応するため、我々は、（おそらく論理）QNF-RMFインターフェースを定義します。このインタフェースを介して、情報は、監視、リソースの利用可能性、トポロジ、および構成についてRMFから提供されてもよいです。他の方向では、インターフェイスは、リソースプロビジョニングのための要求をトリガするために使用されてもよいです。 QNFとRMFの間のインタフェースを形式化する一つの方法は、サービスレベル契約（SLA）を介してです。 SLAは、静的であってもよいし、動的に交渉プロトコルを用いて更新することができます。そのようなプロトコルはNSISの範囲外です。
There is no assumed restriction on the placement of the RMF. It may be a centralized RMF per domain, several off-path distributed RMFs, or an on-path RMF per router. The advantages and disadvantages of both approaches are well-known. Centralization typically allows decisions to be taken using more global information, with more efficient resource utilization as a result. It also facilitates deployment or upgrade of policies. Distribution allows local decision processes and rapid response to data path changes.
RMFの配置には想定さ制限はありません。これは、ドメインごとに集中RMF、いくつかのオフパス分散RMFs、またはルータごとにパスRMFであってもよいです。両方のアプローチの長所と短所はよく知られています。集中化は、一般的に意思決定が、結果として、より効率的なリソースの利用で、よりグローバルな情報を使用して撮影することができます。また、政策の展開やアップグレードを容易にします。配布はローカル決定プロセスとデータパスの変化に迅速に対応することができます。
As well as the use for 'traditional' QoS signaling, it should be possible to develop NSLPs for other signaling applications that operate on different types of network control state. One specific case is setting up flow-related state in middleboxes (firewalls, NATs, and so on). Requirements for such communication are given in [4]. Other examples include network monitoring and testing, and tunnel endpoint discovery.
同様に「伝統的な」のQoSシグナリングのための使用などは、ネットワーク制御状態の異なる種類で動作する他のシグナリングアプリケーションのためのNSLPsを開発することが可能でなければなりません。一つの特定の場合には、中間装置（ファイアウォール、NATの、など）でフローに関する状態をセットアップします。そのような通信のための要件は、[4]に記載されています。他の例は、ネットワークの監視およびテスト、およびトンネルエンドポイント検出を含みます。
This document describes a framework for signaling protocols that assumes a two-layer decomposition, with a common lower layer (NTLP) supporting a family of signaling-application-specific upper-layer protocols (NSLPs). The overall security considerations for the signaling therefore depend on the joint security properties assumed or demanded for each layer.
この文書では、シグナリング・アプリケーション固有の上位層プロトコル（NSLPs）のファミリーをサポートする共通の下部層（NTLP）と、二層の分解を想定シグナリングプロトコルのためのフレームワークを記述する。シグナリングのための全体的なセキュリティ問題は、したがって、関節のセキュリティ特性が想定または各層に要求に依存します。
Security for the NTLP is discussed in Section 4.7. We have assumed that, apart from being resistant to denial of service attacks against itself, the main role of the NTLP will be to provide message protection over the scope of a single peer relationship, between adjacent signaling application entities. (See Section 3.2.3 for a discussion of the case where these entities are separated by more than one NTLP hop.) These functions can ideally be provided by an existing channel security mechanism, preferably using an external key management mechanism based on mutual authentication. Examples of possible mechanisms are TLS, IPsec and SSH. However, there are interactions between the actual choice of security protocol and the rest of the NTLP design. Primarily, most existing channel security mechanisms require explicit identification of the peers involved at the network and/or transport level. This conflicts with those aspects of path-coupled signaling operation (e.g., discovery) where this information is not even implicitly available because peer identities are unknown; the impact of this 'next-hop problem' on RSVP design is discussed in the security properties document [6] and also influences many parts of the threat analysis [2]. Therefore, this framework does not mandate the use of any specific channel security protocol; instead, this has to be integrated with the design of the NTLP as a whole.
NTLPのセキュリティは、セクション4.7で説明されています。我々は離れ自体に対するサービス拒否攻撃に対して耐性であることから、NTLPの主な役割は、隣接シグナリングアプリケーションエンティティ間で、単一のピア関係の範囲にわたってメッセージ保護を提供するであろう、と仮定しています。 （これらのエンティティが複数のNTLPホップによって分離された場合の議論については、セクション3.2.3を参照）。これらの関数は、理想的には、好ましくは、相互認証に基づいて、外部鍵管理メカニズムを使用して、既存のチャネル・セキュリティ・メカニズムによって提供することができます。可能なメカニズムの例としては、TLS、IPsecとSSHです。しかし、セキュリティプロトコルの実際の選択とNTLPデザインの残りの部分との間の相互作用があります。主に、ほとんどの既存のチャネルのセキュリティメカニズムは、ネットワークおよび/またはトランスポートレベルで関与するピアの明示的な識別を必要とします。これは、ピアのアイデンティティが未知であるため、この情報も暗黙的に使用できませんパス結合シグナル動作（例えば、発見）のこれらの態様と矛盾します。 RSVP設計上のこの「ネクストホップ問題」の影響は、セキュリティプロパティの文書に記載されている[6]、また、脅威分析の多くの部分に影響する[2]。したがって、このフレームワークは、任意の特定のチャネルセキュリティプロトコルの使用を強制しません。その代わり、これは全体としてNTLPの設計と統合する必要があります。
Security for the NSLPs is entirely dependent on signaling application requirements. In some cases, no additional protection may be required compared to what is provided by the NTLP. In other cases, more sophisticated object-level protection and the use of public-key-based solutions may be required. In addition, the NSLP needs to consider the authorization requirements of the signaling application. Authorization is a complex topic, for which a very brief overview is provided in Section 3.3.7.
NSLPsのセキュリティは、アプリケーション要件をシグナルに完全に依存しています。いくつかのケースでは、追加の保護はNTLPによって提供されるものに比べて必要とされないことがあります。他の例では、より洗練されたオブジェクトレベルの保護と公開鍵ベースのソリューションの使用が必要になることがあります。また、NSLPは、シグナリングアプリケーションの許可要件を検討する必要があります。認可は、非常に簡単な概要は、セクション3.3.7で提供されている複雑なトピックです。
Another factor is that NTLP security mechanisms operate only locally, whereas NSLP mechanisms may also need to operate over larger regions (not just between adjacent peers), especially for authorization aspects. This complicates the analysis of basing signaling application security on NTLP protection.
別の要因は、NSLP機構は、特に許可の態様は、（だけでなく、隣接するピア間で）より大きな領域にわたって動作する必要がある場合があり、一方、NTLPセキュリティメカニズムは、ローカルでのみ動作するということです。これはNTLP保護上のシグナリングアプリケーションのセキュリティを基づかの解析を複雑にします。
An additional concern for signaling applications is the session identifier security issue (Sections 4.6.2 and 5.2). The purpose of this identifier is to decouple session identification (as a handle for network control state) from session "location" (i.e., the data flow endpoints). The identifier/locator distinction has been extensively discussed in the user plane for end-to-end data flows, and is known to lead to non-trivial security issues in binding the two together again. Our problem is the analogue in the control plane, and is at least similarly complex, because of the need to involve nodes in the interior of the network as well.
シグナリングのアプリケーションのための追加的な懸念は、セッション識別子のセキュリティ上の問題（セクション4.6.2と5.2）です。この識別子の目的は、セッション「位置」（すなわち、データ・フロー・エンドポイント）から（ネットワーク制御状態のハンドルのような）セッション識別を分離することです。識別子/ロケータ区別が広くエンドツーエンドデータフローのためのユーザプレーンにおいて議論されており、再び2つの結合に非自明なセキュリティ上の問題につながることが知られています。我々の問題は、制御プレーンにおいてアナログであり、なぜなら同様にネットワークの内部のノードが関与する必要性、少なくとも同様に複雑です。
Further work on this and other security design will depend on a refinement of the NSIS threats work begun in [2].
これと他のセキュリティ設計上の更なる作業は、[2]に始まっNSIS脅威の仕事の改善に依存します。
[1] Brunner, M., "Requirements for Signaling Protocols", RFC 3726, April 2004.
[1]ブルナー、M.、 "シグナリングプロトコルのための要件"、RFC 3726、2004年4月。
[2] Tschofenig, H. and D. Kroeselberg, "Security Threats for Next Steps in Signaling (NSIS)", RFC 4081, June 2005.
[2] Tschofenig、H.およびD. Kroeselberg、 "シグナリングにおける次のステップのためのセキュリティの脅威（NSIS）"、RFC 4081、2005年6月。
[3] Chaskar, H., "Requirements of a Quality of Service (QoS) Solution for Mobile IP", RFC 3583, September 2003.
[3] Chaskar、H.、 "サービス品質の要件（QoS）のモバイルIPのためのソリューション"、RFC 3583、2003年9月を。
[4] Swale, R., Mart, P., Sijben, P., Brim, S., and M. Shore, "Middlebox Communications (midcom) Protocol Requirements", RFC 3304, August 2002.
[4] Swale、R.、マート、P.、Sijben、P.、つば、S.、およびM.ショア、 "ミドル・コミュニケーションズ（MIDCOM）プロトコル要件"、RFC 3304、2002年8月。
[5] Manner, J. and X. Fu, "Analysis of Existing Quality of Service Signaling Protocols", Work in Progress, December 2004.
[5]マナー、J.およびX.フー、「サービスシグナリングプロトコルの既存の品質の分析」、進歩、2004年12月に作業。
[6] Tschofenig, H., "RSVP Security Properties", Work in Progress, February 2005.
[6] Tschofenig、H.、 "RSVPセキュリティのプロパティ"、進歩、2005年2月に作業。
[7] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[7]ブレーデン、R.、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1機能仕様"、RFC 2205、1997年9月。
[8] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[8]カッツ、D.、 "IPルータアラートオプション"、RFC 2113、1997年2月。
[9] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, October 1999.
[9]ウズラ、C.とA.ジャクソン、 "IPv6のルータアラートオプション"、RFC 2711、1999年10月。
[10] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001.
[10]ベーカー、F.、Iturralde、C.、ルFaucheur、F.、およびB.デイビー、 "IPv4とIPv6の予約のためのRSVPの集約"、RFC 3175、2001年9月。
[11] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
、BCP 72、RFC 3552、2003年7月[11]レスコラ、E.とB.コーバー、 "セキュリティの考慮事項の書き方RFCテキストのためのガイドライン"。
[12] Tschofenig, H., "NSIS Authentication, Authorization and Accounting Issues", Work in Progress, March 2003.
[12] Tschofenig、H.、 "NSIS認証、認可および会計問題"、進歩、2003年3月に作業。
[13] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., and S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, April 2001.
[13]バーガー、L.、ガン、D.、ツバメ、G.、パン、P.、Tommasi、F.、及びS. Molendini、 "RSVPリフレッシュオーバーヘッド削減拡張"、RFC 2961、2001年4月。
[14] Ji, P., Ge, Z., Kurose, J., and D. Townsley, "A Comparison of Hard-State and Soft-State Signaling Protocols", Computer Communication Review, Volume 33, Number 4, October 2003.
[14]智、P.、ゲルマニウム、Z.、黒瀬、J.、およびD. Townsley、「ハードステートの比較とソフトステートシグナリングプロトコル」、コンピュータコミュニケーションレビュー、33巻、4号、2003年10月。
[15] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[15]フロイド、S.、 "輻輳制御の原理"、BCP 41、RFC 2914、2000年9月。
[16] Apostolopoulos, G., Kamat, S., Williams, D., Guerin, R., Orda, A., and T. Przygienda, "QoS Routing Mechanisms and OSPF Extensions", RFC 2676, August 1999.
[16] Apostolopoulos、G.、Kamat、S.、ウィリアムズ、D.、ゲラン、R.、オルダ、A.、およびT. Przygienda、 "QoSルーティングメカニズムとOSPF拡張"、RFC 2676、1999年8月。
[17] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and Multicast Next-Hop Selection", RFC 2991, November 2000.
[17]ターラー、D.およびC. Hoppsが、 "ユニキャストとマルチキャストの次ホップの選択におけるマルチパスの問題"、RFC 2991、2000年11月。
[18] Hinden, R., "Virtual Router Redundancy Protocol (VRRP)", RFC 3768, April 2004.
[18] HindenとR.、 "仮想ルータ冗長プロトコル（VRRP）"、RFC 3768、2004年4月。
[19] Heijenk, G., Karagiannis, G., Rexhepi, V., and L. Westberg, "DiffServ Resource Management in IP-based Radio Access Networks", Proceedings of 4th International Symposium on Wireless Personal Multimedia Communications WPMC'01, September 9 - 12 2001.
[19] Heijenk、G.、Karagiannis、G.、Rexhepi、V.、およびL. Westberg、 "IPベースの無線アクセスネットワーク内のDiffServリソース管理"、無線パーソナルマルチメディア通信WPMC'01第4回国際シンポジウム、年9月9から12まで2001。
[20] Manner, J., Lopez, A., Mihailovic, A., Velayos, H., Hepworth, E., and Y. Khouaja, "Evaluation of Mobility and QoS Interaction", Computer Networks Volume 38, Issue 2, p. 137-163, 5 February 2002.
[20]ようにして、J.、ロペス、A.、Mihailovic、A.、ベラヨス、H.、ヘップワース、E.、およびY. Khouaja、 "モビリティの評価とQoSの相互作用"、コンピュータネットワークボリューム38、第2号、 P。 137から163まで、2002年2月5日。
[21] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[21]ジョンソン、D.、パーキンス、C.、およびJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 3775、2004年6月。
[22] Liebsch, M., Ed., Singh, A., Ed., Chaskar, H., Funato, D., and E. Shim, "Candidate Access Router Discovery (CARD)", Work in Progress, May 2005.
[22] Liebsch、M.、編、シン、A.編、Chaskar、H.、船戸、D.、およびE.シム、 "候補アクセスルータ発見（CARD）"、進行中で働いて、2005年5月。
[23] Kempf, J., "Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network", RFC 3374, September 2002.
[23]ケンプ、J.、「問題の説明：IPアクセスネットワーク内のノード間のコンテキスト転送を実行した理由」、RFC 3374、2002年9月。
[24] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[24] Srisuresh、P.とM.ホールドレッジ、 "IPネットワークアドレス変換（NAT）用語と考慮事項"、RFC 2663、1999年8月。
[25] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000.
[25] Nordmarkと、E.、 "ステートレスIP / ICMP翻訳アルゴリズム（SIIT）"、RFC 2765、2000年2月。
[26] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003.
[26]ローゼンバーグ、J.、ワインバーガー、J.、のHuitema、C.、およびR.マーイ、 - 2003年3月、RFC 3489 "STUNネットワークを介して、ユーザーデータグラムプロトコル（UDP）の簡単なトラバーサルは、翻訳者（NATのを）アドレス"。
[27] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP Operation Over IP Tunnels", RFC 2746, January 2000.
[27] Terzis、A.、Krawczyk、J.、Wroclawski、J.、およびL.チャン、 "RSVPオペレーションオーバーIPトンネル"、RFC 2746、2000年1月。
[28] Bosch, S., Karagiannis, G., and A. McDonald, "NSLP for Quality-of-Service signaling", Work in Progress, February 2005.
[28]ボッシュ、S.、Karagiannis、G.、およびA.マクドナルド、 "サービス品質シグナリングのためのNSLP"、進歩、2005年2月に作業。
[29] Stiemerling, M., "A NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", Work in Progress, February 2005.
[29] Stiemerling、M.、 "NAT /ファイアウォールNSISシグナリング層プロトコル（NSLP）"、進歩、2005年2月に作業。
[30] Braden, R., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[30]ブレーデン、R.、クラーク、D.、およびS. Shenker、 "インターネットアーキテクチャにおける統合サービス：概要"、RFC 1633、1994年6月。
[31] Westberg, L., Csaszar, A., Karagiannis, G., Marquetant, A., Partain, D., Pop, O., Rexhepi, V., Szabo, R., and A. Takacs, "Resource Management in Diffserv (RMD): A Functionality and Performance Behavior Overview", Seventh International Workshop on Protocols for High-Speed networks PfHSN 2002, 22 - 24 April 2002.
[31] Westberg、L.、Csaszar、A.、Karagiannis、G.、Marquetant、A.、パーテイン、D.、ポップ、O.、Rexhepi、V.、ザボ、R.、およびA.タカーチ、「リソース2002年4月24日 - 高速ネットワークのPfHSN 2002、22のためのプロトコルの機能とパフォーマンスの動作概要」、第7回国際ワークショップ：Diffservの（RMD）で管理。
[32] Ferrari, D., Banerjea, A., and H. Zhang, "Network Support for Multimedia - A Discussion of the Tenet Approach", Berkeley TR-92-072, November 1992.
[32]フェラーリ、D.、Banerjea、A.、およびH.チャン、 "マルチメディアのためのネットワークサポート - テネットアプローチの議論"、バークレーTR-92から072、1992年11月。
[33] Nichols, K., Jacobson, V., and L. Zhang, "A Two-bit Differentiated Services Architecture for the Internet", RFC 2638, July 1999.
[33]ニコルズ、K.、ヤコブソン、V.、およびL.チャン、 "インターネットのための2ビットの差別化サービスアーキテクチャ"、RFC 2638、1999年7月。
Appendix A. Contributors
付録A.協力者
Several parts of the introductory sections of this document (in particular, in Sections 3.1 and 3.3) are based on contributions from Ilya Freytsis, then of Cetacean Networks, Inc.
（セクション3.1および3.3で特に）この文書の冒頭セクションのいくつかの部分は、その後、クジラネットワーク、Inc.のイリヤFreytsis、からの寄与に基づいています
Bob Braden originally proposed "A Two-Level Architecture for Internet Signalling" as an Internet-Draft in November 2001. This document served as an important starting point for the framework discussed herein, and the authors owe a debt of gratitude to Bob for this proposal.
ボブブレーデンはもともとこの文書は、本明細書で議論フレームワークのための重要な出発点を務めた2001年11月にインターネットドラフトとして「インターネットシグナリングのための二つのレベルのアーキテクチャ」を提案し、作者はこの提案のためにボブに感謝の負債を負います。
Appendix B. Acknowledgements
付録B.謝辞
The authors would like to thank Bob Braden, Maarten Buchli, Eleanor Hepworth, Andrew McDonald, Melinda Shore, and Hannes Tschofenig for significant contributions in particular areas of this document. In addition, the authors would like to acknowledge Cedric Aoun, Attila Bader, Anders Bergsten, Roland Bless, Marcus Brunner, Louise Burness, Xiaoming Fu, Ruediger Geib, Danny Goderis, Kim Hui, Cornelia Kappler, Sung Hycuk Lee, Thanh Tra Luu, Mac McTiffin, Paulo Mendes, Hans De Neve, Ping Pan, David Partain, Vlora Rexhepi, Henning Schulzrinne, Tom Taylor, Michael Thomas, Daniel Warren, Michael Welzl, Lars Westberg, and Lixia Zhang for insights and inputs during this and previous framework activities. Dave Oran, Michael Richardson, and Alex Zinin provided valuable comments during the final review stages.
著者は、この文書の特定の領域で重要な貢献のためにボブブレーデン、マールテンBuchli、エレノア・ヘップワース、アンドリュー・マクドナルド、メリンダ・ショア、およびハンネスTschofenigに感謝したいと思います。また、著者らはセドリックアウン、アッティラバーダー、アンダース・バーグステン、ローランドが祝福、マーカスブルンナー、ルイーズBurness、暁明フー、Ruediger Geib、ダニーGoderis、キム・ホイ、コーネリアKappler、宋Hycukリー、タントラLUUを確認したいと思い、マックMcTiffin、パウロ・メンデス、ハンス・デ・ネーヴ、Pingのパン、デビッドパーテイン、Vlora Rexhepi、ヘニングSchulzrinneと、トム・テイラー、マイケル・トーマス、ダニエル・ウォーレン、マイケルWelzl、ラースWestberg、およびLixiaチャン洞察と入力この中に、前のフレームワーク活動のため。デイブ・オラン、マイケル・リチャードソン、およびアレックスジニンは最終審査の段階で貴重なコメントを提供しました。
Authors' Addresses
著者のアドレス
Robert Hancock Siemens/Roke Manor Research Old Salisbury Lane Romsey, Hampshire SO51 0ZN UK
ロバート・ハンコックシーメンス/ Rokeマナー研究オールド・ソールズベリーレーンロムジー、ハンプシャーSO51 0ZN英国
EMail: robert.hancock@roke.co.uk
メールアドレス：robert.hancock@roke.co.uk
Georgios Karagiannis University of Twente P.O. BOX 217 7500 AE Enschede The Netherlands
トウェンテの私書箱のゲオルギオスカラGiannis大学BOX 217 7500 AEエンスヘーデ、ネザーランズ
EMail: g.karagiannis@ewi.utwente.nl
メールアドレス：g.karagiannis@ewi.utwente.nl
John Loughney Nokia Research Center 11-13 Itamerenkatu Helsinki 00180 Finland
ジョンLoughneyノキア・リサーチセンター11-13 Itamerenkatuヘルシンキ00180フィンランド
EMail: john.loughney@nokia.com
メールアドレス：john.loughney@nokia.com
Sven Van den Bosch Alcatel Francis Wellesplein 1 B-2018 Antwerpen Belgium
スヴェン・ヴァン・デン・ボッシュアルカテル・フランシス・ウェルズプレイン1 B-2018アントワープベルギー
EMail: sven.van_den_bosch@alcatel.be
メールアドレス：sven.van_den_bosch@alcatel.be
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。