[要約] RFC 4080は、次世代のシグナリング（NSIS）のフレームワークに関するものであり、NSISの目的は、ネットワークリソースの予約や制御を効率的に行うためのプロトコルを提供することです。
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
シグナリングの次のステップ（NSIS）：フレームワーク
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).
Copyright（c）The Internet Society（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（リソース予約）よりも多くの目的を目的としています。この柔軟性を実現するための基本的なメカニズムは、シグナル伝達プロトコルスタックを2つのレイヤーに分割することです：ジェネリック（下）レイヤーと各シグナリングアプリケーションに固有の上層層。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].
NSIのコンテキストでのシグナリングの根本的な要件は、[1]および個別のセキュリティ脅威文書[2]で定義されています。その他の関連する要件は、それぞれQOS/モビリティとミドルボックス通信の[3]および[4]に記載されています。このフレームワークは、これらの要件を置き換えたり更新したりしません。既存のシグナル伝達とリソース管理プロトコルから学習すべき教訓についての議論は、個別の分析ドキュメント[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では、RSVPと比較したNSISプロトコル操作の基本要素について説明します[7]。特に、セクション3.1.3では、より一般的なシグナル伝達シナリオについて説明し、セクション3.1.4では、NSISプロトコルが役立つはずのより広範なシグナリングアプリケーションを定義しています。この一般性をサポートする2層プロトコルアーキテクチャは、セクション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で説明されています。これは、プロトコルまたは設計オプションの詳細な設計を定義することではありませんが、一部は例として説明されています。これらのインターフェイスに表示される識別子要素（セクション4.6）を含む、この低層プロトコルとIPレイヤー（下）とシグナリングアプリケーションプロトコル（上記）の間のインターフェイスを説明します。これに続いて、セクション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では、特定のシグナリングアプリケーションについて説明します。QoSのシグナル伝達の例（Core RSVP 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エンティティ（つまり、それらの間に他のNESがない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.
直接通信する2つのNSISエンティティは、「ピア関係」にあると言われています。この概念は、大まかに「nsisホップ」と呼ばれるかもしれません。ただし、単一のIPホップに対応するという意味はありません。いずれかまたは両方のNESは、他のNESに関するいくつかの状態情報を保存する可能性がありますが、それらが必ずしも自分自身の間に長期的なシグナリング接続を確立するという仮定はありません。
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は、可能な限り最も単純なシグナリング構成の図を示しています。Ruters R1、R2、およびR3を介して、送信者のアプリケーションから受信機への単一のデータフローが実行されています。各ホストと2つのルーターには、信号メッセージを交換するNESが含まれています。このシナリオは、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.
パス共役の場合、シグナリングメッセージは、データパス上にあるNESを介してのみルーティングされます。データパス上のすべてのノードに到達する必要はありません。（たとえば、中間信号とアウェアのノードが存在する可能性があります。または、図2に示すようなプロキシの存在は、シグナリングがパスエンドポイントに到達するのを防ぐことができます。）隣接するNEの間で、シグナルとデータがとるルートが分岐する可能性があります。。パス結合されたケースは、さまざまなアドレス指定スタイルによってサポートされ、隣人に明示的にアドレス指定されるか、データパケットと同じように扱われますが、ルーターアラートオプションも同様です（[8]および[9]を参照してください。）、および傍受。これらのケースは、セクション4.2で考慮されます。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
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).
o ProxyがNSISに使用されたホストに代わってNSISシグナル伝達を開始する場合、他の「ローカル」テクノロジーとのインターワーキングが必要になる場合があります（たとえば、QoSシグナリングアプリケーションの場合、プロキシから最終ホストへのQoS予約を提供します）。
+------+ +----+ +----+ +----+ +--------+
|Sender|----->| PA |----->| R2 |----->| R3 |----->|Receiver|
| | |+--+| |+--+| +----+ | +--+ |
+------+ ||NE||======||NE||==================|==|NE| |
|+--+| |+--+| | +--+ |
+-..-+ +----+ +--------+
..
..
+-..-+
|Appl|
+----+
Appl = signaling PA = Proxy for signaling application application
Appl =シグナル伝達PA =シグナリングアプリケーションのプロキシ
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.
図3に示す別の可能な構成は、NEがリモートプロセッサに信号情報を送信および受信できる場所です。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の概念とは異なることに注意してください。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）は、ソリューションの1つのコンポーネントです。
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）という用語を使用して、シグナリングアプリケーションレイヤー内の任意のプロトコルを一般的に参照します。最終的に、大部分は互いに独立しているいくつかのNSLPがあります。これらの関係を図4に示します。NTLPには、興味深い内部構造（既存の輸送プロトコルを含むなど）がある場合とない場合がありますが、このレベルの説明には関係ありません。
^ +-----------------+
| | 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の機能の根底にある基本概念について説明します。まず、NTLPのプロトコルメカニズムは隣接するNES（非公式には、NTLPは「ホップバイホップ」プロトコル）の間でのみ動作するのに対し、大規模なスコープの問題（E2Eの側面を含む）が任されると仮定します。上層。
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に至り、それが受信され、NTLPの責任が終了するパス（上流または下流）に沿って次のNEに到達します。ここには、メッセージが実際にどのように対処されるかについての仮定はないことに注意してください（これはプロトコル設計の問題であり、オプションはセクション4.2で概説されています）。重要なポイントは、特定のNEのNTLPが、直接ピア以外のNESのアドレス、機能、またはステータスに関する知識を使用しないことです。
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を拡張してそのような非局所機能を含めることには利点がありません。代わりに、そのようなメッセージを必要とし、NESの経路を横断することを避けたい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をピア関連の範囲に制限する動機の1つは、設計アプローチにオプションやバリエーションがある場合、または基本的な機能には、直接ピアではなく直接ピアに影響を与える場合にのみ複雑さを管理する方が簡単であることです。潜在的にインターネット全体。
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：不均一なNSLPによるシグナル伝達
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:
最初にルーターアラートオプションで送信されたメッセージのケースを考慮すると、このバイパスを実現するための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.
o IPレイヤーでは、一連のプロトコル番号またはルーターアラートオプションの値の範囲を使用できます。このようにして、メッセージは暗黙の粒度でマークすることができ、ルーターはメッセージの構成されたサブセットにのみ、さらにスローパス処理を適用することを選択できます。これは、[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のより軽量の実装と、シグナリングアプリケーションが完全に処理されるピアNSLP間のより直接的な「エンドツーエンド」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とシグナル層プロトコル（NSLP）の両方の共同操作の結果であることに注意してください。たとえば、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およびNSLPの状態マシンは論理的に独立したままですが、実装により、ネットワーク上の負荷をモノリシックモデルによって達成するのと同じレベルに削減するために自由に相互作用できるようになります。
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.
パス分解されたシグナル伝達は、データパスにあるノードのみを通過することを制限することなく、データパスに沿った状態インストールのシグナル伝達として定義されます。シグナリングメッセージは、データパスから外れているノードにルーティングできますが、（おそらく）認識しています。これにより、シグナリングとデータプレーンノード（自律システムレベルなど）の間の緩い結合が可能になります。Pathが分離した操作のサポートは、NSIS作業の初期目標の1つではありませんが、このセクションは完全性と将来の参照のためのいくつかの最初の考慮事項をキャプチャするために含まれています。
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と同じサービスインターフェイスをNSLPに提示する下層層プロトコルを使用して、パス分離シグナル伝達ソリューションを実装できることを意味します。新しいメッセージトランスポートプロトコル（おそらくパス結合された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.
o 一般に、これらのアクションを許可するノードがNSLP内で直接開始できる場合、セットアップと変更は最速になります。NESの承認と開始の間の不一致は、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.
一部のシグナリングアプリケーションおよびシナリオの場合、シグナリングは単方向のデータフローのみで考慮される場合があります。ただし、他の場合では、双方向セッションの2つのフロー間のシグナル伝達に興味深い関係があるかもしれません。例は、音声通話のQoSです。2つの方向のパスは、非対称ルーティングのために異なる場合があることに注意してください。基本的な場合、双方向シグナル伝達は、各方向に同じシグナル伝達メカニズムの別のインスタンスを単に使用できます。
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内で使用されている状態の説明を、世界的に理解されているオブジェクトとローカルに理解されているオブジェクトで運ばれるものとして考慮することです。ローカルオブジェクトはドメイン内シグナル伝達にのみ適用できますが、グローバルオブジェクトは主にドメイン間シグナル伝達で使用されます。ローカルオブジェクトはまだプロトコルの一部ですが、1つのドメインで挿入、使用、削除されていることに注意してください。
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つのアプローチは、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.
個々のNSLPは、そのコンテキストでの集約の意味と、それがどのように実行されるべきかを指定する必要があります。たとえば、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が「ローカル」で動作することです。つまり、単一のピア関係の範囲を超えています。エンドツーエンドの操作は、これらの関係を連結することにより構築されます。非ローカル操作（もしあれば）はNSLPで行われます。
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.
承認は、NTLPピア関係のシーケンスに沿って、シグナリングイニシエーターに向けて送信できます。これにより、NESが維持する必要があり、両方向にNATトラバーサルを可能にするセキュリティ関連の要件が解放されます。（この指示が送信者に向かっている場合、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は、NESの下流チェーン全体の責任を引き受ける可能性があり、（たとえば）ダウンストリームパス全体の予約リソースの可用性を（たとえば）示しています。あるいは、メッセージはより局所的な意味を持ち、ネットワーク内の特定のポイントで特定の障害または劣化が発生したことを（たとえば）示している可能性があります。
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).
通知は、他のシグナリングメッセージに応じて（必ずしも）生成されないため、謝辞とは異なります。これは、通知をどこに送信するかを判断する方法が明らかではないことを意味します。それ以外は、謝辞と同じ考慮事項が適用されます。行うべき有用な区別の1つは、信号アクションをトリガーする通知とそうでない他のものを区別することです。後者のセキュリティ要件はそれほど厳しくありません。つまり、運命づけられている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.4で概説されており、セクション3.2.5および4.3に詳細がいくつかあります。
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.
o ピアピア。メッセージは、宛先NEに近いことが知られている近隣のNSISエンティティに宛てられています。
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のアドレスが、ローカルルーティングテーブルを使用するか、アクティブピアディスカバリーメッセージ交換に参加することにより、ペイロードに存在する情報から派生可能であることが必要です。ピアピアアドレス指定は、NES間のメッセージのトンネリングを本質的にサポートしており、パス結合およびパス分解されたケースに等しく適用できます。
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).
エンドツーエンドのアドレス指定の場合、メッセージはデータフロー受信機に宛てられ、データパスに沿ったNESがメッセージをインターセプトします。メッセージのルーティングは、関連するデータフローとまったく同じパスに従う必要があります（ただし、この点のセクション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は、機能をオプションとして交渉するコストを回避するために、常にアンバンドリングをサポートする必要があります。（更新メッセージ内のオブジェクトが以前のメッセージ識別子への参照に置き換えられる場合、更新の要約の関連する関数はNSLPに任されています。これは、シグナリングアプリケーションの状態管理要件に合わせて調整された方法でこれを行うことができます。追加の透明な圧縮機能は、ローカルオプションとして後で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断片化を使用すると、信頼性が低下する可能性があり、一部のアドレス指定スキームと互換性がない場合があります。したがって、この機能は、大きなメッセージを生成するNSLPのサービスとして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.
3. 状態を変更するメッセージが確実に配信される場合、シグナリングアプリケーションには大きな利点があります（RSVPの[13]で導入されているように。[14]のより一般的な分析も参照）。これは、シグナリングアプリケーションの状態を管理するためのNSLPによるソフトステートの使用に関する仮定を変更することはなく、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-hops）。シグナリングアプリケーション。ただし、輻輳と過負荷の両方のケースの両方で、それに応じて行動を適応させるのはシグナルアプリケーション自体次第です。
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は、ルートの変更と同様のイベントに関する情報を提供するIPレイヤー（ローカル転送テーブルおよびルーティングプロトコル状態を含む）から表示を受け取ります（セクション5.1を参照）。
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つの目的で、シグナリングメッセージの送信と受信、およびコントロールとフィードバック情報の交換という2つの目的で、高層シグナリングアプリケーションに輸送層サービスを提供します。
For sending and receiving messages, two basic control primitives are required:
メッセージを送信および受信するには、2つの基本的な制御プリミティブが必要です。
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.
o エラーメッセージ、NTLPがシグナリングアプリケーションにエラー条件を示すようにし、その逆も同様です。
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);
o フローラベル（IPv6の典型）;
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の一部であると仮定します。これの正当性は、特定のシグナリングアプリケーション（セクション3.2.3を参照）に気付いていないノードであっても、NSIS処理を行うことができるということです。例のシナリオは、フロー識別を書き直す必要があるアドレス指定境界を通過するメッセージです。
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.
基礎となる流れとは無関係にシグナリングアプリケーション状態を参照できる状況が重要です。たとえば、モビリティイベントのためにフローエンドポイントの1つのアドレスが変更された場合、まったく新しい予約をインストールせずにフロー識別子を変更できることが望ましいです。セッション識別子は、同じネットワーク制御状態と異なるフローに関するシグナルを相関させる方法を提供します。
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の動作を制御するために使用できます。たとえば、輸送層がこのセッションに属するパケットをどのように転送するかを制御することにより（このシグナリングアプリケーションとは対照的に）。さらに、セッション識別子は、そのような運用シナリオがサポートされている場合、同じシグナリングアプリケーションの複数のインスタンス間の受信シグナリングメッセージをDemultlexに使用することができます（シグナリングアプリケーション識別の詳細については、セクション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タイプをサポートするために使用できるため、どのタイプA特定のシグナル伝達メッセージ交換が使用されているかを特定する必要があります。これはサポートするためです：
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.
o NSIS認識中間ノードでの一般的なメッセージの処理 - ノードが特定のシグナリングアプリケーションを処理しない場合、上層情報を解析することなく転送決定を行うことができるはずです。
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だけです。）保護の種類はそれぞれに適用する必要があります。
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:
ルートの変更には、シグナリングプロトコルに3つのプロセスが存在する必要があります。
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
3. データパケットTTLの変更からの推論
4. inference from loss of packet stream in a flow-aware router
4. フローアウェアルーターでのパケットストリームの損失からの推論
5. inference from changes in signaling packet TTL
5. シグナリングパケット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.
これらの方法は、ネットワーク監視（方法1-2）、データパケットモニタリング（方法3-4）、およびシグナル伝達プロトコルメッセージの監視（方法5-7）に基づいていることに分類できます。方法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ヘッダーを指すと仮定します。これには2つの主な理由があります。1つ目は、通常、フローごとの処理を実装するときにデータプレーンが他の点で機能することができないことです（たとえば、ルーターが内側のヘッダーを分析してパケットをスケジュールする方法を決定することを期待できません）。2番目の理由は、ネットワークインフラストラクチャによって提供されるセキュリティに暗黙的に依存して、正しいパケットに合図されている特別な処理が与えられていることを確認し、これはパケットソースと宛先アドレスとネットワークトポロジの関係に基づいて構築されていることです。（これは本質的に、モバイル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の責任は、正しいシグナリングアプリケーションピア間の各フローの信号メッセージを配信することに限定されます。相関が発生する場所は、エンドシステムと、フローが満たされるネットワーク内のシグナリングアプリケーション対応ノードです。（このノードは一般に「クロスオーバールーター」と呼ばれます。ネットワーク内のどこにでもあります。）
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）との相互作用を考慮する必要があります。これらの考慮事項は、さまざまなタイプ（[24]で定義されている）の「従来の」NATと、Stateless IP/ICMP翻訳（SIIT）[25]などのいくつかのIPv4/V6遷移メカニズムの両方に適用されます。
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-Unaware 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-aware」NATは、整合性の保護されないように、フロー識別情報を明確にしていないようにする必要があります。別の概念的アプローチは、メッセージ処理自体のNAT機能の部分を考慮することです。この場合、翻訳ノードはNSISプロトコルセキュリティメカニズムにネイティブに参加できます。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プロトコルをサポートしていないネットワークとの逆方向の互換性が提供されます。NESは、トンネルのカプセルを開始して、トンネルのシグナル伝達メッセージを見つけて処理することはないと仮定します。
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].
このセクションでは、特定のシグナリングアプリケーションのNSLPの概要を示します。仮定は、NSLPが以前に与えられたNTLPの一般的な機能を使用することです。このセクションでは、NSLP操作の特定の側面について説明します。これには、NSLPがフレームワークにどのように適合するかを明確にすることを目的とした簡単な例が含まれています。正式なNSLPプロトコル仕様の一部を置き換えたり、形成したりしません。特に、リソース予約[28]およびミドルボックス通信[29]のために、NSLPの初期設計が開発されています。
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 Initiator（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 Responder（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 Forwarder（QNF）：QNIとQNRの間のシグナリングエンティティは、ネットワークを介してNSISシグナリングをさらに伝播します。
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のメッセージセマンティクスの可能なセットを以下に示します。下の表の「方向」列は、メッセージの「方向」のみを示していることに注意してください。メッセージは、QNIまたはQNRと同様にQNFノードで発信および吸収される可能性があります。例としては、メッセージを交換するドメインの端にあるQNFSが、ITを横切るフローのリソースをセットアップすることです。レスポンダーがセットアップ中またはセットアップ中または後に予約をリリースまたは変更できる場合、開いたままにしておくことに注意してください。これは主に認可に関する仮定の問題のようであり、可能性はリソースタイプの詳細に依存する可能性があります。
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).
テーブルには、更新操作も明示的に含まれています。これは、その生涯を延長することを除いて、予約には何もしません。これは、可能な国家管理メカニズムの1つです（次のセクションを参照）。
+-----------+-----------+-------------------------------------------+
| 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内の国家管理に関する問題（メッセージトランスポートに関連する状態）については、セクション4で説明します。QoS NSLPは、通常、希望するリソース予約に関連する追加の状態を処理する必要があります。
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ノードは、ルートが変更された直後にパスメッセージの送信を開始できます。このオプションは、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に向けてサーバーとして機能します。ただし、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シグナリング（Just Petweentionの間で実行される「より低い」レベルを処理するネットワークのエッジ）。（同様のアーキテクチャの議論については、[10]、[32]、および[33]を参照してください。）NSISシグナル伝達は、特定のフローと限られた範囲に対してNSLPの複数のインスタンスをサポートできると既に想定していることを考えると（例：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とのコロケーションは、QNFとQNI/QNRの組み合わせとして論理的に処理できることに注意してください）。どちらの場合も対応するために、（おそらく論理的な）QNF-RMFインターフェイスを定義します。このインターフェイスでは、監視、リソースの可用性、トポロジ、および構成に関する情報をRMFから提供することができます。他の方向では、インターフェイスを使用して、リソースプロビジョニングのリクエストをトリガーすることができます。QNFとRMFの間のインターフェイスを形式化する1つの方法は、サービスレベル契約（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、いくつかのオフパス分散RMF、またはルーターごとのパスオンパス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シグナル伝達の使用に加えて、さまざまなタイプのネットワーク制御状態で動作する他のシグナリングアプリケーションのNSLPを開発することが可能です。特定のケースの1つは、ミドルボックス（ファイアウォール、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.
このドキュメントでは、2層分解を想定しているシグナル伝達プロトコルのフレームワークを説明し、共通の下層（NTLP）がシグナル付録固有の上層プロトコル（NSLP）のファミリーをサポートしています。したがって、シグナル伝達の全体的なセキュリティ上の考慮事項は、各レイヤーに対して想定または要求される共同セキュリティプロパティに依存します。
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.
NSLPのセキュリティは、シグナリングアプリケーションの要件に完全に依存しています。場合によっては、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.
もう1つの要因は、NTLPセキュリティメカニズムが局所的にのみ動作するのに対し、NSLPメカニズムは、特に許可の側面のために、より大きな地域（隣接するピア間だけでなく）で動作する必要があることです。これにより、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] Brunner、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。、「モバイルIPのサービス品質（QoS）ソリューションの要件」、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.、Mart、P.、Sijben、P.、Brim、S。、およびM. Shore、「Middlebox Communications（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] Mather、J。およびX. Fu、「既存のサービス品質シグナル伝達プロトコルの分析」、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] Braden、R.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、1997年9月。
[8] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[8] Katz、D。、「IPルーターアラートオプション」、RFC 2113、1997年2月。
[9] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, October 1999.
[9] Partridge、C。and A. Jackson、「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] Baker、F.、Iturralde、C.、Le Faucheur、F。、およびB. Davie、「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.
[11] Rescorla、E。and B. Korver、「セキュリティに関する考慮事項に関するRFCテキストを書くためのガイドライン」、BCP 72、RFC 3552、2003年7月。
[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] Berger、L.、Gan、D.、Swallow、G.、Pan、P.、Tommasi、F。、およびS. Molendini、「RSVP Refrend Overhead Recotion Extensions」、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] Ji、P.、Ge、Z.、Kurose、J。、およびD. Townsley、「ハードステートとソフトステートのシグナル伝達プロトコルの比較」、コンピューターコミュニケーションレビュー、第33巻、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.、Williams、D.、Guerin、R.、Orda、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] Thaler、D。およびC. Hopps、「UnicastおよびMulticast Next-Hop Selectionのマルチパスの問題」、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 Resource Management」、ワイヤレスパーソナルマルチメディアコミュニケーションWPMC'01、9月9日に関する第4回国際シンポジウムの議事録 - 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] Mather、J.、Lopez、A.、Mihailovic、A.、Velayos、H.、Hepworth、E。、およびY. Khouaja、「モビリティとQoS相互作用の評価」、コンピューターネットワークVolume 38、Issue 2、p。137-163、2002年2月5日。
[21] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[21] Johnson、D.、Perkins、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.、ed。、Singh、A.、ed。、Chaskar、H.、Funato、D。、およびE. Shim、「候補者アクセスルーターディスカバリー（カード）」、2005年5月の作業。
[23] Kempf, J., "Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network", RFC 3374, September 2002.
[23] Kempf、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. Holdrege、「IPネットワークアドレス翻訳者（NAT）用語と考慮事項」、RFC 2663、1999年8月。
[25] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000.
[25] Nordmark、E。、「Stateless 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] Rosenberg、J.、Weinberger、J.、Huitema、C。、およびR. Mahy、「Stun-ネットワークアドレス翻訳者（NAT）を介したユーザーデータグラムプロトコル（UDP）の単純なトラバーサル」、RFC 3489、2003年3月。
[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. Zhang、「RSVP Operation over IP Tunnels」、RFC 2746、2000年1月。
[28] Bosch, S., Karagiannis, G., and A. McDonald, "NSLP for Quality-of-Service signaling", Work in Progress, February 2005.
[28] Bosch、S.、Karagiannis、G。、およびA. McDonald、「サービス品質信号のための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] Braden、R.、Clark、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.、Partain、D.、Pop、O.、Rexhepi、V.、Szabo、R。、およびA. Takacs、「Diffservのリソース管理（RMD）：機能とパフォーマンスの動作の概要」、高速ネットワークのプロトコルに関する第7回国際ワークショップPFHSN 2002、22-24 2002年4月。
[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] Ferrari、D.、Banerjea、A。、およびH. Zhang、「マルチメディアのネットワークサポート - 教義アプローチの議論」、Berkeley 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] Nichols、K.、Jacobson、V。、およびL. Zhang、「インターネット用の2ビット差別化されたサービスアーキテクチャ」、RFC 2638、1999年7月。
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の）は、次にCetacean Networks、Inc。のIlya 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月にインターネットドラフトとして「インターネットシグナリングのための2レベルのアーキテクチャ」を提案しました。この文書は、ここで議論されたフレームワークの重要な出発点として機能し、著者はこの提案に対してボブに感謝の負債を負っています。。
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.
著者は、この文書の特定の分野で重要な貢献について、ボブ・ブレイデン、マルテン・ブクリ、エレノア・ヘップワース、アンドリュー・マクドナルド、メリンダ・ショア、ハンヌ・ツェコフェニグに感謝したいと思います。さらに、著者は、セドリック・アウン、アッティラ・バダー、アンダース・バーグステン、ローランド・ブレッシング、マーカス・ブルナー、ルイーズ・ブルネス、Xiaoming Fu、Ruediger Geib、Danny Goderis、Kim Hui、Cornelia Kappler、Sung hycuk Lee、Thanh 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、Lixia Zhangは、このおよび以前のフレームワーク活動中の洞察とインプットのために。デイブ・オラン、マイケル・リチャードソン、アレックス・ジニンは、最終レビュー段階で貴重なコメントを提供しました。
Authors' Addresses
著者のアドレス
Robert Hancock Siemens/Roke Manor Research Old Salisbury Lane Romsey, Hampshire SO51 0ZN UK
ロバート・ハンコック・シーメンス/ローク・マナー研究オールド・ソールズベリー・レーン・ロムシー、ハンプシャーSO51 0ZN UK
EMail: robert.hancock@roke.co.uk
Georgios Karagiannis University of Twente P.O. BOX 217 7500 AE Enschede The Netherlands
Georgios Karagiannis大学Twente P.O.Box 217 7500 AE Enschede The Netherlands
EMail: g.karagiannis@ewi.utwente.nl
John Loughney Nokia Research Center 11-13 Itamerenkatu Helsinki 00180 Finland
ジョン・ラウニー・ノキア・リサーチ・センター11-13 itamerenkatu Helsinki 00180フィンランド
EMail: 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
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。