RFC4080 日本語訳
4080 Next Steps in Signaling (NSIS): Framework. R. Hancock, G.Karagiannis, J. Loughney, S. Van den Bosch. June 2005. (Format: TXT=122470 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
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
コメントを求めるワーキンググループR.ハンコック要求をネットワークでつないでください: 4080年のシーメンス/RMRカテゴリ: Twente/エリクソンJ.LoughneyノキアS.バンデンボッシュアルカテル2005年6月の情報のG.Karagiannis大学
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)インターネット協会(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.
Signaling(NSIS)ワーキンググループにおけるNext Stepsはデータフローのシグナリング情報のために経路に沿ってネットワークでプロトコルを考えています。 プロトコルの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
1. 序論…3 1.1. シグナリング問題の定義…3 1.2. NSISフレームワークの範囲と構造…3 2. 用語…4 3. シグナリングシナリオとプロトコル構造の概要…6 3.1. 基本的なシグナリング概念…6 3.1.1. 簡単なネットワークとシグナリングトポロジー…6
Hancock, et al. Informational [Page 1] RFC 4080 NSIS Framework June 2005
ハンコック、他 [1ページ]情報のRFC4080NSISフレームワーク2005年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
3.1.2. 経路で結合して経路で衝撃を吸収されたシグナリング…7 3.1.3. ホスト、ネットワーク、およびプロキシに合図します…8 3.1.4. シグナリングメッセージとネットワークは状態を制御します…10 3.1.5. データフローとセッション…10 3.2. プロトコル群への階層モデル…11 3.2.1. 階層モデル概要…11 3.2.2. 分裂概念を層にしてください…12 3.2.3. 中間的ノードを迂回させます…13 3.2.4. コアNSISは層の機能性を輸送します…15 3.2.5. 管理の機能性を述べてください…16 3.2.6. 経路で衝撃を吸収された操作…17 3.3. シグナリングアプリケーションの特性…18 3.3.1. 送付者/受信機オリエンテーション…18 3.3.2. Uniと双方向の操作…19 3.3.3. 異種の操作…19 3.3.4. 集合…20 3.3.5. 同輩同輩と終わり-終わりの関係…21 3.3.6. 承認と通知…21 3.3.7. セキュリティと他のAAA問題…22 4. NSISは層のプロトコルを輸送します…23 4.1. 内部のプロトコルコンポーネント…23 4.2. 扱います。24 4.3. 古典的な輸送は機能します…24 4.4. 層のインタフェースを下ろしてください…26 4.5. 上側の層のサービス…27 4.6. アイデンティティ要素…28 4.6.1. 流れ識別…28 4.6.2. セッション識別…28 4.6.3. シグナリングアプリケーション識別…29 4.7. セキュリティの特性…30 5. 他のプロトコルとの相互作用…30 5.1. IPルート設定相互作用…30 5.1.1. 負荷分割法と方針ベースの推進…31 5.1.2. 変化を発送してください…31 5.2. 移動性とマルチホーミング相互作用…33 5.3. NATsとの相互作用…36 5.4. トンネルを堀るIPとの相互作用…36 6. シグナリングアプリケーション…37 6.1. サービスの質のために、合図します…37 6.1.1. メッセージ意味論について議定書の中で述べてください…38 6.1.2. 管理を述べてください…39 6.1.3. 変化とQoS予約を発送してください…39 6.1.4. 資源管理相互作用…41 6.2. 他のシグナリングアプリケーション…42 7. セキュリティ問題…42 8. 参照…43 8.1. 標準の参照…43 8.2. 有益な参照…44
Hancock, et al. Informational [Page 2] RFC 4080 NSIS Framework June 2005
ハンコック、他 [2ページ]情報のRFC4080NSISフレームワーク2005年6月
1. Introduction
1. 序論
1.1. Definition of the Signaling Problem
1.1. シグナリング問題の定義
The Next Steps in Signaling (NSIS) working group is considering protocols for signaling information about a data flow along its path in the network.
Signaling(NSIS)ワーキンググループにおけるNext Stepsはデータフローのシグナリング情報のために経路に沿ってネットワークでプロトコルを考えています。
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.
2番目に、シグナリングはまさしくQoS(資源予約)より多くの目的のために意図します。 この柔軟性を獲得する基本的機構はシグナリングプロトコル・スタックを2つの層に分割することです: ジェネリックの(下側)の層、およびそれぞれのシグナリングアプリケーションに特定の上側の層。 NSIS仕事の範囲はジェネリックプロトコルと初めは上側の層のQoSシグナリング(RSVPの対応する機能性と同様の)とmiddleboxシグナリングに適した両方を定義することになっています。 さらなるアプリケーションは後で考えられるかもしれません。
1.2. Scope and Structure of the NSIS Framework
1.2. NSISフレームワークの範囲と構造
The underlying requirements for signaling in the context of NSIS are defined in [1] and a separate security threats document [2]; other related requirements can be found in [3] and [4] for QoS/Mobility and middlebox communication, respectively. This framework does not replace or update these requirements. Discussions about lessons to be learned from existing signaling and resource management protocols are contained in separate analysis documents [5], [6].
NSISの文脈で合図するための基本的な要件は[1]で定義されます、そして、別々の軍事的脅威は[2]を記録します。 QoS/移動性とmiddleboxコミュニケーションのための[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
このフレームワークの役割は、NSISシグナリングが、より広いネットワーク文脈の中でどう働くべきであるかを説明して、プロトコル群自体の全体的な構造について説明することです。 したがって、それ
Hancock, et al. Informational [Page 3] RFC 4080 NSIS Framework June 2005
ハンコック、他 [3ページ]情報のRFC4080NSISフレームワーク2005年6月
discusses important protocol considerations such as routing, mobility, security, and interactions with network 'resource' management (in the broadest sense).
ネットワーク'リソース'管理(最も広い意味における)とのルーティングや、移動性や、セキュリティや、相互作用などの重要なプロトコル問題について議論します。
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.
セクション3でNSISプロトコルのための基本の関係を与えます。 セクション3.1は比較におけるNSISプロトコル操作の基本的な要素についてRSVP[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で説明されます。 これは、プロトコルの詳細なデザインを定義するか、またはオプションを設計するのさえ意図しません、或るものが例として記述されていますが。 それはこの下位層プロトコルと、IP(below)層とシグナリングアプリケーション・プロトコル(above)とのインタフェースについて説明します、これらのインタフェース(セクション4.6)に現れる識別子要素を含んでいて。 これに続いて、セクション5はNSISプロトコルを使用するシグナリングアプリケーションがどう分別よく対話できるかをネットワーク層操作に説明します。 明確に、ルーティング(そして、コースを変更する)、IPの移動性、およびネットワークは、翻訳が(NAT)であると扱います。
Section 6 describes particular signaling applications. The example of signaling for QoS (comparable to core RSVP QoS signaling functionality) is given in detail in Section 6.1, which describes both the signaling application specific protocol and example modes of interaction with network resource management and other deployment aspects. However, note that these examples are included only as background and for explanation; we do not intend to define an over-arching architecture for carrying out resource management in the Internet. Further possible signaling applications are outlined in Section 6.2.
セクション6は特定のシグナリングアプリケーションについて説明します。 QoS(コアRSVP QoSシグナリングの機能性に匹敵する)のために合図する例はセクション6.1で詳細に出されます。(それは、ネットワーク資源管理との相互作用の合図しているアプリケーション特定のプロトコルと例のモードと他の展開局面の両方について説明します)。 しかしながら、これらの例がバックグラウンドだけと説明のために含まれていることに注意してください。 私たちは、インターネットで資源管理を行うためにアーチ形に曲げ過ぎるアーキテクチャを定義しないつもりです。 さらなる可能なシグナリングアプリケーションはセクション6.2に概説されています。
2. Terminology
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を見てください)。
Hancock, et al. Informational [Page 4] RFC 4080 NSIS Framework June 2005
ハンコック、他 [4ページ]情報のRFC4080NSISフレームワーク2005年6月
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管理、ファイアウォールコントロールなどであるかもしれません。 どんな特定のユーザアプリケーションとも完全に異なります。
Hancock, et al. Informational [Page 5] RFC 4080 NSIS Framework June 2005
ハンコック、他 [5ページ]情報のRFC4080NSISフレームワーク2005年6月
3. Overview of Signaling Scenarios and Protocol Structure
3. シグナリングシナリオとプロトコル構造の概要
3.1. Fundamental Signaling Concepts
3.1. 基本的なシグナリング概念
3.1.1. Simple Network and Signaling Topology
3.1.1. 簡単なネットワークとシグナリングトポロジー
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 Entities(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の両方がもう片方の何らかの州の情報を保存するかもしれませんが、彼らが必ず自分たちの間の長期のシグナリング接続を確立するという仮定が全くありません。
It is common to consider a network as composed of various domains (e.g., for administrative or routing purposes), and the operation of signaling protocols may be influenced by these domain boundaries. However, it seems there is no reason to expect that an 'NSIS domain' should exactly overlap with an IP domain (AS, area), but it is likely that its boundaries would consist of boundaries (segments) of one or several IP domains.
ネットワークを考えるのが様々なドメイン(例えば、管理の、または、掘っている目的のための)で構成されるように一般的であり、シグナリングプロトコルの操作はこれらのドメイン境界によって影響を及ぼされるかもしれません。 しかしながら、'NSISドメイン'がまさにIPドメイン(AS、領域)に重なるべきであると予想する理由が全くないように思えますが、境界は1かいくつかのIPドメインの境界(セグメント)から成りそうでしょう。
Figure 1 shows a diagram of nearly the simplest possible signaling configuration. A single data flow is running from an application in the sender to the receiver via routers R1, R2, and R3. Each host and two of the routers contain NEs that exchange signaling messages -- possibly in both directions -- about the flow. This scenario is essentially the same as that considered by RSVP for QoS signaling; the main difference is that here we make no assumptions about the particular sequence of signaling messages that will be invoked.
図1はほとんど可能な限り簡単なシグナリング構成のダイヤグラムを示しています。 ただ一つのデータフローはルータのR1、R2、およびR3を通して送付者のアプリケーションから受信機まで稼働しています。 各ホストと2つのルータが流れに関してことによると両方の方向へのシグナリングメッセージを交換するNEsを含んでいます。 このシナリオはQoSシグナリングのためにRSVPによって考えられたそれと本質的には同じです。 主な違いは私たちがここで、シグナリングの特定の系列に関する仮定を全く呼び出されるメッセージにしないということです。
Hancock, et al. Informational [Page 6] RFC 4080 NSIS Framework June 2005
ハンコック、他 [6ページ]情報のRFC4080NSISフレームワーク2005年6月
Sender Receiver
+-----------+ +----+ +----+ +----+ +-----------+
|Application|----->| R1 |----->| R2 |----->| R3 |----->|Application|
| +--+ | |+--+| |+--+| +----+ | +--+ |
| |NE|====|======||NE||======||NE||==================|===|NE| |
| +--+ | |+--+| |+--+| | +--+ |
+-----------+ +----+ +----+ +-----------+
送付者受信機+-----------+ +----+ +----+ +----+ +-----------+ |アプリケーション|、-、-、-、--、>| R1|、-、-、-、--、>| R2|、-、-、-、--、>| R3|、-、-、-、--、>|アプリケーション| | +--+ | |+--+| |+--+| +----+ | +--+ | | |Ne|====|======||Ne||======||Ne||==================|===|Ne| | | +--+ | |+--+| |+--+| | +--+ | +-----------+ +----+ +----+ +-----------+
+--+
|NE| = NSIS ==== = Signaling ---> = Data flow messages
+--+ Entity Messages (unidirectional)
+--+ |Ne| = NSIS==== = シグナリング--->= データフローメッセージ+--+ 実体Messages(単方向)
Figure 1: Simple Signaling and Data Flows
図1: 簡単なシグナリングとデータフロー
3.1.2. Path-Coupled and Path-Decoupled Signaling
3.1.2. 経路で結合して経路で衝撃を吸収されたシグナリング
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に示されたものなどのプロキシの存在は、シグナリングが経路エンドポイントに達するのを防ぐかもしれません。) 隣接しているNEsの間では、シグナリングとデータによって取られたルートは分岐するかもしれません。 明らかに経路の隣人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とこのフレームワークの当初の目標は主に経路で結合したケースに集中することです。
Hancock, et al. Informational [Page 7] RFC 4080 NSIS Framework June 2005
ハンコック、他 [7ページ]情報のRFC4080NSISフレームワーク2005年6月
3.1.3. Signaling to Hosts, Networks, and Proxies
3.1.3. ホスト、ネットワーク、およびプロキシに合図します。
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を見てください。
Hancock, et al. Informational [Page 8] RFC 4080 NSIS Framework June 2005
ハンコック、他 [8ページ]情報のRFC4080NSISフレームワーク2005年6月
Proxy1 Proxy2
+------+ +----+ +----+ +----+ +----+ +--------+
|Sender|-...->|Appl|--->| R |--->| R |--->|Appl|-...->|Receiver|
| | |+--+| |+--+| |+--+| |+--+| | |
+------+ ||NE||====||NE||====||NE||====||NE|| +--------+
|+--+| |+--+| |+--+| |+--+|
+----+ +----+ +----+ +----+
Proxy1 Proxy2+------+ +----+ +----+ +----+ +----+ +--------+ |送付者|-...->|Appl|、-、--、>| R|、-、--、>| R|、-、--、>|Appl|-...->|受信機| | | |+--+| |+--+| |+--+| |+--+| | | +------+ ||Ne||====||Ne||====||Ne||====||Ne|| +--------+ |+--+| |+--+| |+--+| |+--+| +----+ +----+ +----+ +----+
+--+
|NE| = NSIS ==== = Signaling ---> = Data flow messages
+--+ Entity Messages (unidirectional)
+--+ |Ne| = NSIS==== = シグナリング--->= データフローメッセージ+--+ 実体Messages(単方向)
Appl = signaling application
Applはシグナリングアプリケーションと等しいです。
Figure 2: "On path" NSIS proxy
図2: 「経路」NSISプロキシ
This configuration presents two specific challenges for the signaling:
この構成は2つの特定の難問をシグナリングに呈します:
o A proxy that terminates signaling on behalf of the NSIS-unaware
host (or part of the network) should be able to determine that it
is the last NSIS-aware node along the path.
o NSIS気づかないホスト(または、ネットワークの一部)を代表してシグナリングを終えるプロキシは、それが経路に沿った最後のNSIS意識しているノードであることを決定できるべきです。
o Where a proxy initiates NSIS signaling on behalf of the NSIS-
unaware host, interworking with some other "local" technology
might be required (for example, to provide QoS reservation from
proxy to the end host in the case of a QoS signaling application).
o プロキシがNSISの気づかないホストを代表してNSISシグナリングを開始するところでは、ある他の「地方」の技術がある織り込むことが必要であるかもしれません(例えばQoSシグナリングアプリケーションの場合におけるプロキシから終わりのホストまでのQoSの予約を提供する)。
+------+ +----+ +----+ +----+ +--------+
|Sender|----->| PA |----->| R2 |----->| R3 |----->|Receiver|
| | |+--+| |+--+| +----+ | +--+ |
+------+ ||NE||======||NE||==================|==|NE| |
|+--+| |+--+| | +--+ |
+-..-+ +----+ +--------+
..
..
+-..-+
|Appl|
+----+
+------+ +----+ +----+ +----+ +--------+ |送付者|、-、-、-、--、>| PA|、-、-、-、--、>| R2|、-、-、-、--、>| R3|、-、-、-、--、>|受信機| | | |+--+| |+--+| +----+ | +--+ | +------+ ||Ne||======||Ne||==================|==|Ne| | |+--+| |+--+| | +--+ | +-..-+ +----+ +--------+ .. .. +-..-+ |Appl| +----+
Appl = signaling PA = Proxy for signaling
application application
シグナリングAppl=PAはシグナリングアプリケーションアプリケーションのためにプロキシと等しいです。
Figure 3: "Off path" NSIS proxy
図3: 「オフ経路」NSISプロキシ
Hancock, et al. Informational [Page 9] RFC 4080 NSIS Framework June 2005
ハンコック、他 [9ページ]情報のRFC4080NSISフレームワーク2005年6月
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を見てください。
3.1.4. Signaling Messages and Network Control State
3.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.
したがって、それぞれのシグナリングアプリケーション(上側の層の)プロトコルはネットワーク内部の操作のそのシグナリングアプリケーションに興味がある局面のための1流れあたりの情報を運ばなければなりません。 RSVPのようなQoSシグナリングアプリケーションに関するケースのための例は資源予約を表す州のデータでしょう。 しかしながら、より一般に、1流れあたりの情報は経路に沿ったルータとmiddleboxesでのある他のコントロール機能に関連するかもしれません。 本当に、シグナリングは、全くネットワーク操作を変更しないで1流れあたりの情報を集めるのに単に使用されるかもしれません。
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.
私たちは、一般的にこの情報を'ネットワーク制御状態'と呼びます。 シグナリングメッセージは、特定のデータフローのためにネットワーク要素からこの状態をインストールするか、変更するか、リフレッシュするか、または単に読むかもしれません。 また、通常、ネットワーク要素は1流れあたりのレベルでこの情報を管理するでしょう、また、より粗く粒状('クラス'あたりの)の国家管理も可能ですが。
3.1.5. Data Flows and Sessions
3.1.5. データフローとセッション
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-tupleか同等物)を考えるのが必要であると思います。
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
セッションは2つの終点の間のパケットの交換のための応用層概念です。何らかのネットワーク状態を割り当てることになっているか、または終点に関してモニターすることになっています。 簡単な場合では、セッションは特定の流れに写像されるかもしれません。 しかしながら、シグナリングアプリケーションは作成できます。
Hancock, et al. Informational [Page 10] RFC 4080 NSIS Framework June 2005
ハンコック、他 [10ページ]情報のRFC4080NSISフレームワーク2005年6月
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.)
よりフレキシブルな流れ: セッション関係。 ('セッション'のこの概念が特定の送付先アドレスとトランスポート・プロトコルでセッションを流れと定義する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つのコンポーネントです。
3.2. Layer Model for the Protocol Suite
3.2. プロトコル群への階層モデル
3.2.1. Layer Model Overview
3.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
このドキュメントの目的に、私たちは言及する用語'NSIS Transport Layerプロトコル'(NTLP)を使用します。トランスポート層の中で使用されるコンポーネント。 また、私たちは一般的にシグナリング応用層の中のどんなプロトコルも示すのに'NSIS Signaling Layerプロトコル'(NSLP)という用語を使用します。 結局、主に互いの如何にかかわらず数個のNSLPsがあるでしょう。 これらの関係はそうです。
Hancock, et al. Informational [Page 11] RFC 4080 NSIS Framework June 2005
ハンコック、他 [11ページ]情報のRFC4080NSISフレームワーク2005年6月
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.
図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 .
. .
^ +-----------------+ | | NSISシグナリング| | | 層のプロトコル| NSIS| +----------------| middleboxesのために| シグナリング| | NSISシグナリング| +-----------------+ 層| | 層のプロトコル+--------| NSISシグナリング| | | QoSのために| | 層のプロトコル| | +-----------------+ | …のために | +に対して-----------------+ ============================================= NSIS^ +--------------------------------+ 輸送| | NSISトランスポート層プロトコル| +に対して層にしてください。--------------------------------+ ============================================= +--------------------------------+ . IPと下層…
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の中の機能性は強く他の輸送と下層操作と対話することに制限されるべきです。
3.2.2. Layer Split Concept
3.2.2. 層の分裂概念
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
以下の通り、NTLPが働いている方法を述べることができます: シグナリングメッセージが1NEから送る準備ができているとき、それがどんな流れかのためにあるかの情報に伴うNTLPにそれを与えます。 それが受け取られていて、NTLPの責任が終わる経路(上流か川下)に沿った次のNEにそれを得るのは、そして、NTLP次第です。 記述されて、ここでのメッセージがどうあるかに関する仮定が全く実際にないことに注意してください。そして(これがプロトコルデザイン問題である。
Hancock, et al. Informational [Page 12] RFC 4080 NSIS Framework June 2005
ハンコック、他 [12ページ]情報のRFC4080NSIS枠組みの2005年6月
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.
オプションがセクション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を同輩関係範囲に制限することに関する、ある動機がそれであるか設計手法、または、よりひどくコネにおける異形は基本機能です--、むしろダイレクト同輩に影響を与えるだけであるなら結果として起こる複雑さを管理するのが、より簡単である、潜在的に全体のインターネット。
3.2.3. Bypassing Intermediate Nodes
3.2.3. 中間的ノードを迂回させます。
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問題が複数のシグナリングアプリケーションを含んでいるので、特定のNSLPは経路のNSIS意識しているノードの部分集合で非常に実行されるだけでありそうでしょう、図5に示されるように。 さらに、それでも、集合領域の中のノードは流れであるシグナリングメッセージを無視したくなるでしょう、それらが一般に、ノードが処理できるシグナリングアプリケーションのためのものであっても。
Hancock, et al. Informational [Page 13] RFC 4080 NSIS Framework June 2005
ハンコック、他 [13ページ]情報のRFC4080NSIS枠組みの2005年6月
+------+ +------+ +------+ +------+
| NE | | NE | | NE | | NE |
|+----+| | | |+----+| |+----+|
||NSLP|| | | ||NSLP|| ||NSLP||
|| 1 || | | || 2 || || 1 ||
|+----+| | | |+----+| |+----+|
| || | | | | | | || |
|+----+| |+----+| |+----+| |+----+|
====||NTLP||====||NTLP||====||NTLP||====||NTLP||====
|+----+| |+----+| |+----+| |+----+|
+------+ +------+ +------+ +------+
+------+ +------+ +------+ +------+ | Ne| | Ne| | Ne| | Ne| |+----+| | | |+----+| |+----+| ||NSLP|| | | ||NSLP|| ||NSLP|| || 1 || | | || 2 || || 1 || |+----+| | | |+----+| |+----+| | || | | | | | | || | |+----+| |+----+| |+----+| |+----+| ====||NTLP||====||NTLP||====||NTLP||====||NTLP||==== |+----+| |+----+| |+----+| |+----+| +------+ +------+ +------+ +------+
Figure 5: Signaling with Heterogeneous NSLPs
図5: 異種のNSLPsと共に合図すること。
Where signaling messages traverse such NSIS-aware intermediate nodes, it is desirable to process them at the lowest level possible (in particular, on the fastest path). In order to offer a non-trivial message transfer service (in terms of security, reliability and so on) to the peer NSLP nodes, it is important that the NTLP at intermediate nodes is as transparent as possible; that is, it carries out minimal processing. In addition, if intermediate nodes have to do slow-path processing of all NSIS messages, this eliminates many of the scaling benefits of aggregation, unless tunneling is used.
シグナリングメッセージがそのようなNSIS意識している中間的ノードを横断するところでは、可能な(最も速い経路で特定の)最も低いレベルでそれらを処理するのは望ましいです。 同輩NSLPノードに重要なメッセージ転送サービスを提供する(セキュリティ、信頼性などに関して)ために、中間的ノードのNTLPができるだけ透明であることは、重要です。 すなわち、それは最小量の処理を行います。 さらに、中間的ノードがすべてのNSISメッセージの遅い経路処理をしなければならないなら、これは集合のスケーリング利益の多くを除去します、トンネリングが使用されていない場合。
Considering first the case of messages sent with the router alert option, there are two complementary methods to achieve this bypassing of intermediate NEs:
最初にメッセージに関するケースがルータ警戒オプションと共に発信したと考える場合、中間的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層では、1セットのプロトコル番号かルータ警戒オプションにおけるさまざまな値を使用できます。 このように、暗示している粒状でメッセージをマークできます、そして、ルータはさらに遅い経路の処理をメッセージの構成された部分集合だけに適用するのを選ぶことができます。 これは流れと集合あたりのシグナリングを区別するのに[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.
どちらの場合も、NSLPノード中間的NEの存在を完全に隠されます。 シグナリング使用の後期段階が直接、メッセージ(例えば、逆のルーティングのための)を記述したなら、全く中間的NEにかかわらないでしょう、恐らく正常なルータを除いて。
Hancock, et al. Informational [Page 14] RFC 4080 NSIS Framework June 2005
ハンコック、他 [14ページ]情報のRFC4080NSIS枠組みの2005年6月
There may be cases where the intermediate NE would like to do some restricted protocol processing, such as the following:
中間的NEが何らかの制限されたプロトコル処理をしたがっている以下などのケースがあるかもしれません:
o Translating addresses in message payloads (compare Section 4.6.1);
note that this would have to be done to messages passing in both
directions through a node.
o 翻訳はメッセージにペイロードを記述します(セクション4.6.1を比較してください)。 ノードを通して両方の方向に終わるメッセージにこれをしなければならないことに注意してください。
o Updating signaling application payloads with local status
information (e.g., path property measurement inside a domain).
o ローカルの状態情報(例えば、ドメインの中の経路特性の測定)でシグナリングアプリケーションペイロードをアップデートします。
If this can be done without fully terminating the NSIS protocols, it would allow a more lightweight implementation of the intermediate NE, and a more direct 'end-to-end' NTLP association between the peer NSLPs where the signaling application is fully processed. On the other hand, this is only possible with a limited class of possible NTLP designs, and makes it harder for the NTLP to offer a security service (since messages have to be partially protected). The feasibility of this approach will be evaluated during the NTLP design.
完全にNSISプロトコルを終えるというわけではなくてこれができるなら、それは中間的NEの、より軽量の実現、およびシグナリングアプリケーションが完全に処理される同輩NSLPsの間の、よりダイレクトな'終わりから終わり'NTLP協会を許容するでしょう。 他方では、これで、限られたクラスの可能なNTLPデザインで可能であるだけであり、NTLPがセキュリティー・サービスを提供するのが、より困難になります(メッセージが部分的に保護されなければならないので)。 このアプローチに関する実現の可能性はNTLPデザインの間、評価されるでしょう。
3.2.4. Core NSIS Transport Layer Functionality
3.2.4. コアNSISトランスポート層の機能性
This section describes the basic functionality to be supported by the NTLP. Note that the overall signaling solution will always be the result of joint operation of both the NTLP and the signaling layer protocols (NSLPs); for example, we can always assume that an NSLP is operating above the NTLP and taking care of end-to-end issues (e.g., recovery of messages after restarts).
NTLPによって支持されるように、このセクションは基本機能について説明します。 総合的なシグナリング解決策がいつもNTLPとシグナリングプロトコル(NSLPs)層の両方の共同経営の結果になることに注意してください。 例えば、私たちは、いつもNSLPがNTLPの上で作動して、終わりから終わりへの問題の世話をしていると思うことができます(例えばメッセージの回復は後に再開します)。
Therefore, NTLP functionality is essentially just efficient upstream and downstream peer-peer message delivery, in a wide variety of network scenarios. Message delivery includes the act of locating and/or selecting which NTLP peer to carry out signaling exchanges with for a specific data flow. This discovery might be an active process (using specific signaling packets) or a passive process (a side effect of using a particular addressing mode). In addition, it appears that the NTLP can sensibly carry out many of the functions that enable signaling messages to pass through middleboxes, since this is closely related to the problem of routing the signaling messages in the first place. Further details about NTLP functionality are contained in Sections 3.2.5 and 4.3.
したがって、NTLPの機能性はさまざまなネットワークシナリオで本質的にはちょうど効率的な上流の、そして、川下の同輩同輩メッセージ配送です。 メッセージ配送は特定のデータフローのために場所を見つける、そして/または、どのNTLP同輩を選ぶか外で合図している交換を運ぶ行為を含んでいます。 この発見は、アクティブな過程(特定のシグナリングパケットを使用する)か受け身の過程であるかもしれません(特定のアドレッシング・モードを使用する副作用)。 さらに、NTLPが分別よくmiddleboxesを通り抜けるシグナリングメッセージを可能にする機能の多くを行うことができるように見えます、これが密接に第一にシグナリングメッセージを発送するという問題に関連するので。 NTLPの機能性に関する詳細はセクション3.2.5と4.3に含まれています。
Hancock, et al. Informational [Page 15] RFC 4080 NSIS Framework June 2005
ハンコック、他 [15ページ]情報のRFC4080NSIS枠組みの2005年6月
3.2.5. State Management Functionality
3.2.5. 国家管理の機能性
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気づかないノードを通り抜けます。 (そこでそれらのタイミングをjitteredすることができないで、後のコースを変更する出来事の場合に新しい経路で再送するためにメッセージを蓄えることができません。)
3. Within any node, it is an implementation decision whether to
generate/jitter/filter refreshes separately within each signaling
application that needs this functionality, or to integrate it
with the NTLP implementation as a generic "soft-state management
toolbox". The choice doesn't affect the NTLP specification at
all. Implementations might piggyback NTLP soft-state refresh
information (if the NTLP works this way) on signaling application
messages, or they might even combine soft-state management
between layers. The state machines of the NTLP and NSLPs remain
logically independent, but an implementation is free to allow
them to interact to reduce the load on the network to the same
level that would be achieved by a monolithic model.
3. どんなノードの中ではも、それはジター/フィルタが別々にこの機能性を必要とするそれぞれのシグナリングアプリケーションの中でリフレッシュする/を発生させるか、または一般的な「軟性国家管理道具箱」としてNTLP実現とそれを統合するかという実現決定です。 選択は全くNTLP仕様に影響しません。 実現は便乗するかもしれません。NTLP軟性国家がシグナリングアプリケーションメッセージで情報をリフレッシュするか(NTLPがこのように働いているなら)、またはそれらは層の間の軟性国家管理を合併さえするかもしれません。 NTLPとNSLPsの州のマシンは論理的に独立性を確保しますが、実現で、彼らは、ネットワークに一枚岩的なモデルによって実現されるのと同じレベルに負荷を引き下げるために無料で相互作用できます。
4. It may be helpful for signaling applications to receive
state-management related 'triggers' from the NTLP indicating that
a peer has failed or become available ("down/up notifications").
These triggers would be about adjacent NTLP peers, rather than
signaling application peers. We can consider this another case
of route change detection/notification (which the NTLP is also
allowed to do anyway). However, apart from generating such
4. 同輩が失敗したのを示すNTLPから関係づけられた国家管理'引き金'を受けるか、または利用可能に(「通知への/」への)なるようにアプリケーションに合図するのにおいて、それは役立っているかもしれません。 これらの引き金はアプリケーション同輩に合図するよりむしろ隣接しているNTLP同輩に関するものでしょう。 私たちは、これがルート変化検出/通知(また、NTLPがとにかくすることができる)の別のそうであると考えることができます。 そのようなものを発生させることは別としてしかしながら。
Hancock, et al. Informational [Page 16] RFC 4080 NSIS Framework June 2005
ハンコック、他 [16ページ]情報のRFC4080NSIS枠組みの2005年6月
triggers, the NTLP takes no action itself on such events, other
than to ensure that subsequent signaling messages are routed
correctly.
引き金、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が通知と正常な交換処理の間でする本質的には同じ区別です。)
3.2.6. Path-Decoupled Operation
3.2.6. 経路で衝撃を吸収された操作
Path-decoupled signaling is defined as signaling for state installation along the data path, without the restriction of passing only through nodes that are located on the data path. Signaling messages can be routed to nodes that are off the data path, but that are (presumably) aware of it. This allows a looser coupling between signaling and data plane nodes (e.g., at the autonomous system level). Although support for path-decoupled operation is not one of the initial goals of the NSIS work, this section is included for completeness and to capture some initial considerations for future reference.
経路で衝撃を吸収されたシグナリングはデータ経路に沿った州の施設のために合図すると定義されます、データ経路に位置しているノードだけを通り抜ける制限なしで。 ありますが、(おそらく、)データ経路でそれを意識しているノードにシグナリングメッセージを発送できます。 これは飛行機ノード(例えば、自律システムレベルにおける)をシグナリングとデータの間の、よりゆるいカップリングに許容します。 経路で衝撃を吸収された操作のサポートはNSIS仕事の当初の目標の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
潜在的に、2つのシグナリングパラダイムが分析されるべきである方法の著しい違いがあります。 独身の集結されたオフ経路NEを使用すると、要件はメッセージハンドリングで増加するかもしれません。 他方では、経路で衝撃を吸収されたシグナリングは等しく分配されたオフ経路実体に適切です。 失敗回復シナリオは、もうデータと制御飛行機の間の運命共有を想定できないので異なって分析される必要があります。 その上、送付者/受信機オリエンテーションの解釈は、より自然でなくなります。 おそらく、NTLPの地方の操作で、シグナリングメッセージのルーティングに関する経路で衝撃を吸収されたシグナリングの影響は同輩決断の問題に制限されます。 しかしながら、オフ経路NSISノードが緩くデータ経路に縛られるという仮定は、同輩決断がまだL3ルーティング情報に基づくことができるのを示します。 これ
Hancock, et al. Informational [Page 17] RFC 4080 NSIS Framework June 2005
ハンコック、他 [17ページ]情報のRFC4080NSIS枠組みの2005年6月
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.
経路で衝撃を吸収されたシグナリングソリューションを実現できた同じサービスを提示する下位層プロトコルを使用する手段が経路で結合したNTLPとしてNSLPsに連結します。 新しいメッセージトランスポート・プロトコル(ことによると、経路で結合したNTLPから、派生する)が必要でしょうが、NSLP仕様と相互層の相互作用は経路で結合したケースのために変わりがないでしょう。
3.3. Signaling Application Properties
3.3. シグナリングアプリケーションの特性
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の振舞いのためのオプションのいくつかについて概説します。 これらのオプションから選び抜くことに対するさらなる仕事は問題のシグナリングアプリケーションの詳細に渡る分析によるでしょう。
3.3.1. Sender/Receiver Orientation
3.3.1. 送付者/受信機オリエンテーション
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 受信機で開始しているアプローチでは、受信機から送付者まで旅行するのが後方であるに違いないというシグナリングメッセージは、まさに送付者から受信機まで伝わる同じ流れに属すシグナリングメッセージがあとに続いたのと同じ経路に続くように、掘られました。しっかりと承認と通知を送付ノードに提供できれば、送付者によって開始されたアプローチでは、後方のルーティングは必要ではありません、そして、ノードは後方のルーティング州を維持する必要はありません。
Hancock, et al. Informational [Page 18] RFC 4080 NSIS Framework June 2005
ハンコック、他 [18ページ]情報のRFC4080NSISフレームワーク2005年6月
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実施の前に実行されたプロトコルの追加交換処理を引き起こすでしょう。 特定のシグナリングアプリケーションのための承認がどう完了しているかによって、これは送付者か受信機の開始しているシグナリングのどちらかを支持するかもしれません。 これが既存の流れのためにネットワーク制御状態の変更を複雑にするかもしれないことに注意してください。
3.3.2. Uni- and Bi-Directional Operation
3.3.2. Uniと双方向の操作
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.
ルートの部分が左右対称である強制的なtopologiesでは、双方向のシグナリングへの、より統一されたアプローチを使用するのは可能であるかもしれません。 例えば、一般的なメッセージの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がメッセージを一緒に添付するのが単に有効にされるでしょう。
3.3.3. Heterogeneous Operation
3.3.3. 異種の操作
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場合では、相互ドメインリンクに、有効なリソース記述はたぶんイントラドメイン操作の役に立つそれらと異なるでしょう(後者は1つのドメインから別のドメインまで異なるでしょう)。
Hancock, et al. Informational [Page 19] RFC 4080 NSIS Framework June 2005
ハンコック、他 [19ページ]情報のRFC4080NSISフレームワーク2005年6月
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メッセージの中でそれらを「積み重ねることができた」ということです。
3.3.4. Aggregation
3.3.4. 集合
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.
個々のノードを横断するかもしれないのは、大規模なネットワークにおける1流れあたりのシグナリングが多くの流れのためにスケーリング挑戦を提示するというよく知られる問題です。
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のレベルにおける集合のための可能性はかなり限られています。 経路で結合したシグナリングのためのプライマリスケーリング法は、シグナリングアプリケーションが流れを分類して、流れのためにというよりむしろ集合のために個別にシグナリングを実行することです。 集合は多くの方法で作成されるかもしれません。 例えば、一般的なDifferentiated Services Code Point(DSCP)マークをトンネルの下側に送るかもしれないか、または考えて、個人は流れます。 集合と反-集合ポイントは流れシグナリング単位で働きますが、集合領域の中のノードは、集合へのメッセージに合図しながら、やむを得ず処理するだけであるはずです。 これはセクション3.2.3で議論するように1流れあたりのシグナリングを無視する内部のノードの能力に依存します。
Individual NSLPs will need to specify what aggregation means in their context, and how it should be performed. For example, in the QoS context it is possible to add together the resources specified in a number of separate reservations. In the case of other applications, such as signaling to NATs and firewalls, the feasibility (and even the meaning) of aggregation is less clear.
個々のNSLPsは、集合が彼らの文脈で何を意味するか、そして、それがどのように実行されるべきであるかを指定する必要があるでしょう。 例えば、QoS文脈では、多くの別々の予約で指定されたリソースを合計するのは可能です。 NATsとファイアウォールに合図などなどの他のアプリケーションの場合では、集合に関する実現の可能性(そして、意味さえ)はそれほど明確ではありません。
Hancock, et al. Informational [Page 20] RFC 4080 NSIS Framework June 2005
ハンコック、他 [20ページ]情報のRFC4080NSISフレームワーク2005年6月
3.3.5. Peer-Peer and End-End Relationships
3.3.5. 同輩同輩と終わり-終わりの関係
The assumption in this framework is that the NTLP will operate 'locally'; that is, just over the scope of a single peer relationship. End-to-end operation is built up by concatenating these relationships. Non-local operation (if any) will take place in NSLPs.
このフレームワークにおける仮定はNTLPが'局所的に'作動するということです。 すなわち、ただ一つの同輩関係の範囲のすぐ上で。 終わりから終わりへの操作は、これらの関係を連結することによって、確立されます。 非地方の操作(もしあれば)はNSLPsで行われるでしょう。
The peering relations may also have an impact on the required amount of state at each NSIS entity. When direct interaction with remote peers is not allowed, it may be required to keep track of the path that a message has followed through the network. This could be achieved by keeping per-flow state at the NSIS entities, as is done in RSVP. Another approach would be to maintain a record route object in the messages; this object would be carried within the NSIS protocols, rather than depend on the route-recording functionality provided by the IP layer.
また、じっと見る関係はそれぞれのNSIS実体で必要な量の状態に影響を与えるかもしれません。 リモート同輩がいる直接的な相互作用が許容されていないとき、メッセージがネットワークを通して従ったのが、経路の動向をおさえるのに必要であるかもしれません。 そのままなNSIS実体で流れが状態であることを保つことによって、RSVPでしていた状態でこれを達成できるでしょう。 別のアプローチはメッセージで記録的なルートオブジェクトを維持するだろうことです。 このオブジェクトはIP層で提供されたルートを記録する機能性に依存するよりNSISプロトコルの中でむしろ運ばれるでしょう。
3.3.6. Acknowledgements and Notifications
3.3.6. 承認と通知
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同輩関係の系列に沿ってシグナリング創始者に向かって承認を送ることができます、そして、それは両方の方向にNAT縦断を許すことができます。その創始者は、NEsによって維持される必要があるセキュリティ協会に関する要件を救います。 (それは、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の全体の川下のチェーンへの責任を負うことができました、(例えば)全体の川下の経路のための予約されたリソースの有用性を示して。 あるいはまた、メッセージには、よりローカルの意味があるかもしれません、ある失敗か退行が特定のポイントにネットワークで起こったのを示して(例えば)。
Hancock, et al. Informational [Page 21] RFC 4080 NSIS Framework June 2005
ハンコック、他 [21ページ]情報のRFC4080NSISフレームワーク2005年6月
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が決定できれば)意味します)。
3.3.7. Security and Other AAA Issues
3.3.7. セキュリティと他のAAA問題
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]に含まれています。
Hancock, et al. Informational [Page 22] RFC 4080 NSIS Framework June 2005
ハンコック、他 [22ページ]情報のRFC4080NSISフレームワーク2005年6月
4. The NSIS Transport Layer Protocol
4. NSISトランスポート層プロトコル
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を設計するか、またはデザインオプションを列挙するのさえ意図しません、或るものが例として含まれていますが。 目標は、必要な機能性の一般的な議論を提供して、これに関連している問題のいくつかを強調することです。
4.1. Internal Protocol Components
4.1. 内部のプロトコルコンポーネント
The NTLP includes all functionality below the signaling application layer and above the IP layer. The functionality that is required within the NTLP is outlined in Section 3.2.4, with some more details in Sections 3.2.5 and 4.3.
NTLPはシグナリング応用層とIP層を超えたすべての機能性を含んでいます。 NTLPの中で必要である機能性はセクション3.2.5と4.3におけるそれ以上の詳細でセクション3.2.4に概説されています。
Some NTLP functionality could be provided via components operating as sublayers within the NTLP design. For example, if specific transport capabilities are required (such as congestion avoidance, retransmission, and security), then existing protocols (such as TCP+TLS or DCCP+IPsec) could be incorporated into the NTLP. This possibility is not required or excluded by this framework.
副層としてNTLPデザインの中で作動しながら、コンポーネントで何らかのNTLPの機能性を提供できるでしょう。 例えば、特定の輸送能力が必要であるなら(輻輳回避や、「再-トランスミッション」や、セキュリティなどの)、既存のプロトコル(TCP+TLSかDCCP+IPsecなどの)はNTLPに組み入れられるかもしれません。 この可能性は、このフレームワークによって必要でない、または除かれません。
If peer-peer addressing (Section 4.2) is used for some messages, then active next-peer discovery functionality will be required within the NTLP to support the explicit addressing of these messages. This could use message exchanges for dynamic peer discovery as a sublayer within the NTLP; there could also be an interface to external mechanisms to carry out this function.
同輩同輩アドレシング(セクション4.2)がいくつかのメッセージに使用されると、アクティブな次の同輩発見の機能性が、これらのメッセージの明示番地指定をサポートするのにNTLPの中で必要でしょう。 これはダイナミックな同輩発見に副層としてNTLPの中で交換処理を使用するかもしれません。 また、この機能を行う外部のメカニズムへのインタフェースがあるかもしれません。
==================== ===========================
^ +------------------+ +-------------------------+
| | | | NSIS Specific Functions |
| | | | .............|
NSIS | | Monolithic | |+----------+. Peer .|
Transport | | Protocol | || Existing |. Discovery .|
Layer | | | || Protocol |. Aspects .|
| | | |+----------+.............|
V +------------------+ +-------------------------+
==================== ===========================
==================== =========================== ^ +------------------+ +-------------------------+ | | | | NSIS具体的な機能| | | | | .............| NSIS| | 一枚岩的| |+----------+ . 同輩| 輸送| | プロトコル| || 存在しています。|. 発見| 層| | | || プロトコル|. 局面、|| | | |+----------+.............| +に対して------------------+ +-------------------------+ ==================== ===========================
Figure 6: Options for NTLP Structure
図6: NTLP構造のためのオプション
Hancock, et al. Informational [Page 23] RFC 4080 NSIS Framework June 2005
ハンコック、他 [23ページ]情報のRFC4080NSISフレームワーク2005年6月
4.2. Addressing
4.2. アドレシング
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状態から利用可能です。
4.3. Classical Transport Functions
4.3. 古典的な輸送機能
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.,
NSISシグナリングプロトコルはネットワークの周りで(シグナリング)データを輸送するのに原因となります。 一般に、これはふくそう管理、信頼性などなどの機能性を必要とします。 このセクションは、この機能性のどのくらいがNTLPの中で提供されるべきであるかを論じます。 これがNSLP/NTLP層が互いに関連する基本的な方法に影響しないように見える、(例えば。
Hancock, et al. Informational [Page 24] RFC 4080 NSIS Framework June 2005
ハンコック、他 [24ページ]情報のRFC4080NSISフレームワーク2005年6月
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.
相互層の相互作用の意味論)、。 はるかに、総合的な性能/複雑さ見返りの問題が、それぞれ中のある機能が層にされるのを入賞することによって含意したということです。
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. 小さいメッセージが一緒に荷物をまとめる、(匹敵、望まれているなら、NTLPはオプションとして局所的に[13])に提供できます。 それはほかの場所でネットワークの操作に影響しません。 NTLPは、オプションとして特徴を交渉する費用を避けるためにいつもアンバンドリングをサポートするはずです。 (関連する機能、総括をリフレッシュしてください--aのオブジェクトがどこでメッセージをリフレッシュするか前のメッセージ識別子の参照に取り替えます--NSLPsに残されます。(次に、NSLPsはある意味でシグナリングアプリケーションの国家管理要件に波長を合わせたこれができます)。 後で地方選択権として追加見え透いた圧縮の機能性をNTLPデザインに追加できました。) 外向的なインタフェースの次のノードがNSIS意識しているのが知られない場合安全に異なった流れへのメッセージであると扱われた終わりから終わりは添付することができないことに注意してください。
2. When needed, message fragmentation should be provided by the
NTLP. The use of IP fragmentation for large messages may lead to
reduced reliability and may be incompatible with some addressing
schemes. Therefore, this functionality should be provided within
the NTLP as a service for NSLPs that generate large messages.
How the NTLP determines and accommodates Maximum Transmission
Unit (MTU) constraints is left as a matter of protocol design.
To avoid imposing the cost of reassembly on intermediate nodes,
the fragmentation scheme used should allow for the independent
forwarding of individual fragments towards a node hosting an
interested NSLP.
2. 必要であると、メッセージ断片化はNTLPによって提供されるはずです。 IP断片化の大きいメッセージの使用は、減少している信頼性に通じるかもしれなくて、体系を扱ういくつかと両立しないかもしれません。 したがって、大きいメッセージを生成するNSLPsのためのサービスとしてNTLPの中でこの機能性を提供するべきです。 NTLPがどうMaximum Transmission Unit(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
3. 状態を変えるメッセージが確かに提供されるならシグナリングアプリケーションのための重要な利益があることができる、(RSVPのための[13]で導入するように; また、[14])の、より一般的な分析を見てください。 これは管理するためにアプリケーション状態に合図しながら、NSLPsによる軟性国家の使用に関する少しの仮定も変えません、そして、NSLPで応用層エラー条件から検出して、回復することへの責任は残っています。 しかしながら、それはNTLPが防ぐことができる下層における混雑か不正によるメッセージの損失からの速い回復を扱うために機能性が調整される必要はなくて、また意味するそのそのようなものを意味します。
Hancock, et al. Informational [Page 25] RFC 4080 NSIS Framework June 2005
ハンコック、他 [25ページ]情報のRFC4080NSISフレームワーク2005年6月
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.
断片化で引き起こされたメッセージ損失率の増幅。 信頼できる配信の機能性は、メッセージごとのベースに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-ホップレート)自体にオーバーロードを検出して、ローカルのシグナリングアプリケーションへのフロー制御状態としてこれを示すことができるかもしれません。 しかしながら、混雑とオーバーロードケースの両方に関して、それに従って、彼らの振舞いを適合させるのはシグナリングアプリケーション自体まで達しています。
4.4. Lower Layer Interfaces
4.4. 下層インタフェース
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は送受信がメッセージを示す目的のためにプロトコル・スタックの'下層'と対話します。 このフレームワークはNTLPの低い境界をIP層にみなします。 したがって、下層へのインタフェースは非常に簡単です:
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
正しいメッセージルーティングのために、NTLPは地方のネットワークスタックのリンクとIP層の構成の何らかの情報を必要とします。 一般に、それは、これがシグナリングメッセージのためにどのように外向的なインタフェースを選択するか、そして、どこで対応する流れによって使用されるインタフェースに合わなければならないかを知る必要があります。 IP層がメッセージを扱うのをそれ自身のルーティングを使用することでただ許容するのとこれは同じくらい簡単であるかもしれません。
Hancock, et al. Informational [Page 26] RFC 4080 NSIS Framework June 2005
ハンコック、他 [26ページ]情報のRFC4080NSISフレームワーク2005年6月
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).
テーブルの上に置きます。 IPルーティング(メッセージであると扱われた終わりから終わりの)と異なった何かをするという意志が全くありません。 しかしながら、何人かのホストがアプリケーションにそれらのデータフローのためにルーティングを迂回させます、そして、NTLP処理はこれを説明しなければなりません。 扱う情報が必要であるだろうさらなるネットワーク層はアドレスを見ました(そのようなものが存在しているなら)。
Configuration of lower-layer operation to handle flows in particular ways is handled by the signaling application.
特定の方法で流れを扱う下層操作の構成はシグナリングアプリケーションで扱われます。
4.5. Upper Layer Services
4.5. 上側の層のサービス
The NTLP offers transport-layer services to higher-layer signaling applications for two purposes: sending and receiving signaling messages, and exchanging control and feedback information.
NTLPは2つの目的のために、より高い層のシグナリングアプリケーションに対するトランスポート層サービスを提供します: メッセージに合図して、コントロールとフィードバック情報を交換しながら、発信して、受信すること。
For sending and receiving messages, two basic control primitives are required:
メッセージの送受信において、2つの基本制御基関数が必要です:
o Send Message, to allow the signaling application to pass data to
the NTLP for transport.
o Messageを送って、シグナリングアプリケーションが輸送のためにデータをNTLPに通過するのを許容してください。
o Receive Message, to allow the NTLP to pass received data to the
signaling application.
o Messageを受けて、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 ルートなどのフィードバック情報は、シグナリングアプリケーションが、どんな行動を取ったらよいかを決めることができるように、指摘を変えます。
Hancock, et al. Informational [Page 27] RFC 4080 NSIS Framework June 2005
ハンコック、他 [27ページ]情報のRFC4080NSISフレームワーク2005年6月
4.6. Identity Elements
4.6. アイデンティティ要素
4.6.1. Flow Identification
4.6.1. 流れ識別
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.
これらの識別子での高々限られたwildcardingが必要であると思われます。
We assume here that the flow identification is not hidden within the NSLP, but is explicitly part of the NTLP. The justification for this is that being able to do NSIS processing, even at a node which was unaware of the specific signaling application (see Section 3.2.3) might be valuable. An example scenario would be messages passing through an addressing boundary where the flow identification had to be re-written.
私たちは、ここで流れ識別がNSLPの中に隠されませんが、NTLPを明らかに離れさせることであると思います。 これのための正当化はそうするノードでさえNSISに特定のシグナリングアプリケーション(セクション3.2.3を見る)に気づかない状態で処理をすることができるのが貴重であるかもしれないということです。 例のシナリオは流れ識別が書き直されなければならなかったアドレシング限界を通り抜けるメッセージでしょう。
4.6.2. Session Identification
4.6.2. セッション識別
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つのアドレスが移動性イベントのため変化するなら、完全に新しい予約をインストールする必要はなくて流れ識別子を変えることができるのは望ましいです。 セッション識別子は異なった流れに関してシグナリングを関連させるメソッドを同じネットワーク制御状態に提供します。
Hancock, et al. Informational [Page 28] RFC 4080 NSIS Framework June 2005
ハンコック、他 [28ページ]情報のRFC4080NSISフレームワーク2005年6月
The session identifier is essentially a signaling application concept, since it is only used in non-trivial state management actions that are application specific. However, we assume here that it should be visible within the NTLP. This enables it to be used to control NTLP behavior; for example, by controlling how the transport layer should forward packets belonging to this session (as opposed to this signaling application). In addition, the session identifier can be used by the NTLP to demultiplex received signaling messages between multiple instances of the same signaling application, if such an operational scenario is supported (see Section 4.6.3 for more information on signaling application identification).
セッション識別子は本質的にはシグナリングアプリケーション概念です、それがアプリケーション特有の重要な州の管理活動に使用されるだけであるので。 しかしながら、私たちは、ここでそれがNTLPの中で目に見えるべきであると思います。 これは、それがNTLPの振舞いを制御するのに使用されるのを可能にします。 例えばトランスポート層がどうこのセッション(このシグナリングアプリケーションと対照的に)に属するパケットを進めるはずであるかを制御することによって。 さらに、NTLPは同じシグナリングアプリケーションの複数のインスタンスの間の「反-マルチプレックス」の受信されたシグナリングメッセージにセッション識別子を使用できます、そのような操作上のシナリオがサポートされるなら(シグナリングアプリケーション識別の詳しい情報に関してセクション4.6.3を見ます)。
To be useful for mobility support, the session identifier should be globally unique, and it should not be modified end-to-end. It is well known that it is practically impossible to generate identifiers in a way that guarantees this property; however, using a large random number makes it highly likely. In any case, the NTLP ascribes no valuable semantics to the identifier (such as 'session ownership'); this problem is left to the signaling application, which may be able to secure it to be used for this purpose.
変更された終わりから移動性サポートの役に立つように、セッション識別子はグローバルにユニークであるべきであり、終わりであるべきではありません。 この特性を保証する方法で識別子を生成するのが実際に不可能であることは、よく知られています。 しかしながら、大きい乱数を使用するのに、それは非常にありそうになります。 どのような場合でも、NTLPはどんな貴重な意味論も識別子('セッション所有権'などの)のせいにしません。 この問題はシグナリングアプリケーションに残されます。(それは、このために使用されるためにそれを機密保護することができるかもしれません)。
4.6.3. Signaling Application Identification
4.6.3. シグナリングアプリケーション識別
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:
いくつかのNSLPタイプをサポートするのにNTLPを使用できるので、特定のシグナリング交換処理がどのタイプに使用されているかを特定する必要があります。 サポートにはこれがあります:
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デザインの残りに影響を及ぼすべきではありません。
Hancock, et al. Informational [Page 29] RFC 4080 NSIS Framework June 2005
ハンコック、他 [29ページ]情報のRFC4080NSISフレームワーク2005年6月
4.7. Security Properties
4.7. セキュリティの特性
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セキュリティ手順に参加する場合にだけ、それは、アドレスを含むメッセージ分野、まさしくしばしば流れイドへのアクセスが与えられている必要があります。) 保護のタイプがそれぞれ適用されるべきであることのように未決問題ですNTLPメッセージの必要性の部品が保護して。
5. Interactions with Other Protocols
5. 他のプロトコルとの相互作用
5.1. IP Routing Interactions
5.1. IPルート設定相互作用
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で説明されます。 セクション6.1.2でQoSの文脈における、この問題の記述を与えます。
Hancock, et al. Informational [Page 30] RFC 4080 NSIS Framework June 2005
ハンコック、他 [30ページ]情報のRFC4080NSISフレームワーク2005年6月
5.1.1. Load Sharing and Policy-Based Forwarding
5.1.1. 負荷分割法と方針ベースの推進
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-tupleで同じにするなら、分岐はルータ警戒オプションの存在でまだ起こっているかもしれません。 同じICMP誤まった指示は適用されます、そして、エンドシステムがデータとシグナリングパケットを見分けるのは難しくなります。 最終的に、QoSルーティングのテクニックはルーティング決定をパケットのヘッダー(例えば、DSCP)のどんな分野にも基礎づけるかもしれません。
5.1.2. Route Changes
5.1.2. ルート変化
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
コネクションレスなネットワークでは、ヘッダー情報に基づいて各パケットは独自に発送されます。 目的地に向かったより良いルートが利用可能になるときはいつも、このルートは、推進テーブルにインストールされて、すべてのその後(データとシグナリング)のパケットに使用されるでしょう。 これは状態がインストールされた経路と推進が実際に行われる経路の間の分岐を引き起こす場合があります。 ルート変化の問題はルートであるなら減少して、ピンで止めることが実行されるということです。 ルートのピンで止めるのが、あるデータ・パケットによってInteriorゲートウェイプロトコルからのルーティングアップデートで引き起こされた可到達性変化から取られた経路からの独立について言及する、(OSPF、-、)、または、Exteriorゲートウェイプロトコル(BGP)。 NSISシグナリングに関する何も、ルートのピンで止めることがネットワークエンジニアリング技法として使用されるのを防ぎません、方法で完了していれば
Hancock, et al. Informational [Page 31] RFC 4080 NSIS Framework June 2005
ハンコック、他 [31ページ]情報のRFC4080NSISフレームワーク2005年6月
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).
それはシグナリングとデータの一般的なルーティングを保存します。 しかしながら、ルートのピンで止めるのが使用されていても、すべてのルート変化(例えばリンクの故障の場合で)を防ぐためにそれに依存できません。
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. LinkState方式プロトコルにおけるモニターしているトポロジー変化
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.
(メソッド3-4)をモニターするデータ・パケットの上と、そして、ネットワーク監視(メソッド1-2)に基づいて、モニターしているシグナリングプロトコルメッセージ(メソッド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
ルート変化が検出されたとき、状態が新しい経路に沿ってできるだけはやくインストールされるのは、重要です。 新しい経路が古い経路で利用可能であったのと同じ特性を提供できるのが保証されません。 シグナリングの写し州の施設か、よりひどく拒絶を避けるために
Hancock, et al. Informational [Page 32] RFC 4080 NSIS Framework June 2005
ハンコック、他 [32ページ]情報のRFC4080NSISフレームワーク2005年6月
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].
いくつかの環境で、接続性と流れかクラス州の管理を高可用性の特性に提供するのは望ましいです。 すなわち、急速な透明な回復と、ルート変化があるときさえ。 これはこの場合ルーティングを管理するのに使用されるプロトコルとの相互作用を必要とするかもしれません、Virtual Router Redundancyプロトコル(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によって引き起こされるでしょう。
5.2. Mobility and Multihoming Interactions
5.2. 移動性とマルチホーミング相互作用
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-層の移動性とマルチホーミングの使用は、1つ以上のIPソースか送付先アドレスがただ一つのセッションに関連することを意味します。 応用層溶液(例えば、SIPベースのアプローチ)が使用されているなら、同じくらいは適用されます。
Hancock, et al. Informational [Page 33] RFC 4080 NSIS Framework June 2005
ハンコック、他 [33ページ]情報のRFC4080NSISフレームワーク2005年6月
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]で基本的な相互作用の一般評論を与えます。([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]の経路最適化セキュリティの基礎として使用される本質的には同じアプローチです。) この仮定の結果は私たちが、(or from)の異なったアドレスにパケットストリームを異なった流れと考えるということです。 流れがトンネルの中で運ばれるところでは、それは再び異なった流れと考えられます。 カプセル化問題((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-
したがって、最もきわどい局面は複数の流れが使用されていて、それらのためのシグナリングが、関連する必要があるということです。 これはセッション識別子の意図している役割(セクション4.6.2を見てください、また、そのような識別子のためのセキュリティ要件のいくつかについて説明するもの)です。 セッション識別子はNTLPで目に見えますが、シグナリングアプリケーションは相関関係(そしてそれほどしっかりとするために)を実行するのに原因となります。 NTLP責任は正しいシグナリングアプリケーション同輩の間の各流れのためにシグナリングメッセージを提供するのに制限されます。 相関関係が行われる位置は、エンドシステムとシグナリングです。
Hancock, et al. Informational [Page 34] RFC 4080 NSIS Framework June 2005
ハンコック、他 [34ページ]情報のRFC4080NSISフレームワーク2005年6月
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.)
流れが満たされるネットワークにおけるアプリケーション意識しているノード。 (一般に、このノードは「横断歩道ルータ」と呼ばれます; それはネットワークでどこでもあることができます。)
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.
経路の共有された地域では、シグナリングが少なくとも新しい流れを含むようにパケットクラシファイアをアップデートするのに必要です、既存の流れに伴う相関関係が可能であるならどんな方針や入場コントロール処理も迂回させるのが可能であるべきですが。 また、新しい経路(そして、ことによると古い方に関するリリース)への州の施設が必要です。 どの実体(終わりのホストのひとりか横断歩道ルータ)がこれらのすべての手順を制御するかがどの実体がネットワーク州の操作を行うのが認可されるかによるので、したがって、これはアプリケーションと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
移している州の情報が、そうしなければならないのを避けるように、引き渡しの後に新しいアクセスルータでそれを作り直してください。そして、何人かのネットワークタイプの身柄の引き渡しの頻度が速く引き渡しを引き渡しのために最適のアクセスルータを選択するのに、望ましいサポートプロトコルにする、(例えば、[22])、(例えば、[23])。 これらの手順の両方には、シグナリングプロトコルとの強い相互作用があるかもしれません。 アクセスルータ選択はそれがネットワーク制御状態であることができたのに依存するかもしれません。
Hancock, et al. Informational [Page 35] RFC 4080 NSIS Framework June 2005
ハンコック、他 [35ページ]情報のRFC4080NSIS枠組みの2005年6月
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.
経路では、新しいアクセスルータを通して支持されます。 シグナリングアプリケーション状態かNTLP/NSLPプロトコル状態の転送は文脈転送の候補であるかもしれません。
5.3. Interactions with NATs
5.3. NATsとの相互作用
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].
少なくともいくつかのメッセージがペイロードとしてほぼ必然的にアドレスとことによるとより高い層の情報を含むので、私たちはアドレス変換装置(NATs)との相互作用を考えなければなりません。 これらの問題は様々なタイプの'伝統的'NATsに両方を当てはまります。(Stateless IP/ICMP Translation(SIIT)[25]などのいくつかのIPv4/v6変遷メカニズムと同様に[24])で定義されるように。
In the simplest case of an NSIS-unaware NAT in the path, payloads will be uncorrected, and signaling will refer to the flow incorrectly. Applications could attempt to use STUN [26] or similar techniques to detect and recover from the presence of the NAT. Even then, NSIS protocols would have to use a well-known encapsulation (TCP/UDP/ICMP) to avoid being dropped by more cautious low-end NAT devices.
NSIS気づかないNATの経路で最も簡単な場合では、ペイロードは非修正になるでしょう、そして、シグナリングは不当に流れについて言及するでしょう。 アプリケーションは、NATの存在から検出して、回収するSTUN[26]か同様のテクニックを使用するのを試みるかもしれません。 その時でさえ、NSISプロトコルは、より用心深いローエンドNAT装置によって落とされるのを避けるのに、周知のカプセル化(TCP/UDP/ICMP)を使用しなければならないでしょう。
A simple 'NSIS-aware' NAT would require flow identification information to be in the clear and not to be integrity protected. An alternative conceptual approach is to consider the NAT functionality part of message processing itself, in which case the translating node can take part natively in any NSIS protocol security mechanisms. Depending on NSIS protocol layering, it would be possible for this processing to be done in an NSIS entity that was otherwise ignorant of any particular signaling applications. This is the motivation for including basic flow identification information in the NTLP (Section 4.6.1).
簡単な'NSIS意識している'NATは、流れ識別情報が明確にあるのを必要とするでしょう、そして、保全でないことは保護されました。 代替の概念的アプローチは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.
この議論のすべてが特定のNSLPのNATs(そして、ファイアウォール)の一般的なコントロールの使用から独立していることに注意してください。 そのケースはセクション6.2で考えられます。
5.4. Interactions with IP Tunneling
5.4. トンネルを堀るIPとの相互作用
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を使用するのも可能であるべきです。
Hancock, et al. Informational [Page 36] RFC 4080 NSIS Framework June 2005
ハンコック、他 [36ページ]情報のRFC4080NSIS枠組みの2005年6月
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機能であるべきであることにかかわらずここから開いた状態で外されます。
6. Signaling Applications
6. シグナリングアプリケーション
This section gives an overview of NSLPs for particular signaling applications. The assumption is that the NSLP uses the generic functionality of the NTLP given earlier; this section describes specific aspects of NSLP operation. It includes simple examples that are intended to clarify how NSLPs fit into the framework. It does not replace or even form part of the formal NSLP protocol specifications; in particular, initial designs are being developed for NSLPs for resource reservation [28] and middlebox communication [29].
このセクションは特定のシグナリングアプリケーションのためにNSLPsの概観を与えます。 仮定はNSLPが、より早く与えられたNTLPの一般的な機能性を使用するということです。 このセクションはNSLP操作の特定の局面について説明します。 それはNSLPsがどう枠組みに収まるかをはっきりさせることを意図する簡単な例を含んでいます。 それは、正式なNSLPプロトコル仕様の一部を置き換えもしませんし、形成してさえいません。 特に、初期のデザインは資源予約[28]とmiddleboxコミュニケーション[29]のためのNSLPsのために開発されています。
6.1. Signaling for Quality of Service
6.1. サービスの質のために合図すること。
In the case of signaling for QoS, all the basic NSIS concepts of Section 3.1 apply. In addition, there is an assumed directionality of the signaling process, in that one end of the signaling flow takes responsibility for actually requesting the resource. This leads to the following definitions:
QoSのために合図する場合では、セクション3.1のすべての基本のNSIS概念が適用されます。 さらに、シグナリングの過程の想定された方向性があります、シグナリング流動の片端が実際にリソースを要求するのに責任を取るので。 これは以下の定義に通じます:
o QoS NSIS Initiator (QNI): the signaling entity that makes the
resource request, usually as a result of user application request.
o QoS NSIS創始者(QNI): 通常ユーザアプリケーション要求の結果、資源要求をするシグナリング実体。
o QoS NSIS Responder (QNR): the signaling entity that acts as the
endpoint for the signaling and that can optionally interact with
applications as well.
o QoS NSIS応答者(QNR): シグナリングとそれのための終点として機能するシグナリング実体は任意にまた、アプリケーションと対話できます。
o QoS NSIS Forwarder (QNF): a signaling entity between a QNI and QNR
that propagates NSIS signaling further through the network.
o QoS NSIS混載業者(QNF): QNIとQNRの間のさらにネットワークを通してNSISシグナリングを伝播するシグナリング実体。
Hancock, et al. Informational [Page 37] RFC 4080 NSIS Framework June 2005
ハンコック、他 [37ページ]情報のRFC4080NSIS枠組みの2005年6月
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の役割を果たすべきであるかでないことに注意してください: データフロー指示に関して、発信か犠牲者に、それはあるかもしれません。
6.1.1. Protocol Message Semantics
6.1.1. プロトコルメッセージ意味論
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はシグナリング経路に沿って資源予約を行う1セットのメッセージを含むでしょう。 QoS NSLPに、可能なメッセージ意味論は以下に示されます。 以下のテーブルの'指示'コラムがメッセージの'オリエンテーション'を示すだけであることに注意してください。 QNIかQNRと同様にQNFノードでメッセージを溯源して、没頭させることができます。 例はaの向こう側に流れのためのリソースに設定するメッセージを交換するドメインの縁のQNFsがそれであるならそうするでしょうに。 応答者がセットアップかセットアップの後に予約をリリースするか、または変更できるなら、それが開くままにされることに注意してください。 これは主に認可に関する仮定の問題に見えます、そして、可能性はリソースタイプ詳細に依存するかもしれません。
The table also explicitly includes a refresh operation. This does nothing to a reservation except extend its lifetime, and it is one possible state management mechanism (see next section).
また、テーブルは明らかにリフレッシュ操作を含んでいます。 生涯を広げていて、これは予約に何もしません、そして、それはある可能な国家管理メカニズム(次のセクションを見る)です。
+-----------+-----------+-------------------------------------------+ | Operation | Direction | Operation | +-----------+-----------+-------------------------------------------+ | Request | I-->R | Create a new reservation for a flow | | | | | | Modify | I-->R | Modify an existing reservation | | | (&R-->I?) | | | | | | | Release | I-->R | Delete (tear down) an existing | | | (&R-->I?) | reservation | | | | | | Accept/ | R-->I | Confirm (possibly modified?) or reject a | | Reject | | reservation request | | | | | | Notify | I-->R & | Report an event detected within the | | | R-->I | network | | | | | | Refresh | I-->R | State management (see Section 6.1.2) | +-----------+-----------+-------------------------------------------+
+-----------+-----------+-------------------------------------------+ | 操作| 指示| 操作| +-----------+-----------+-------------------------------------------+ | 要求| 私-->R| 流れの新しい予約を作成してください。| | | | | | 変更します。| 私-->R| 既存の予約を変更してください。| | | (R-->I)? | | | | | | | リリース| 私-->R| 存在を削除してください(取りこわします)。| | | (R-->I)? | 予約| | | | | | /を受け入れてください。| R-->I| aを確認するか(ことによると変更されますか?)、または拒絶してください。| | 廃棄物| | 予約の要請| | | | | | 通知してください。| I-->R| 出来事が中に検出されていると報告してください。| | | R-->I| ネットワーク| | | | | | リフレッシュしてください。| 私-->R| 国家管理(セクション6.1.2を見ます)| +-----------+-----------+-------------------------------------------+
Hancock, et al. Informational [Page 38] RFC 4080 NSIS Framework June 2005
ハンコック、他 [38ページ]情報のRFC4080NSIS枠組みの2005年6月
6.1.2. State Management
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は、これを単に(おそらく同じ)のメッセージの系列と考えます。
6.1.3. Route Changes and QoS Reservations
6.1.3. ルート変化とQoS予約
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
予約された+-----+ 予約された+-----+ =========>| QNF|===========>| QNF| +-----+ +-----+ --------------------------------------->データ経路
Figure 7: Normal NSIS Protocol Operation
図7: 通常のNSISプロトコル操作
Hancock, et al. Informational [Page 39] RFC 4080 NSIS Framework June 2005
ハンコック、他 [39ページ]情報のRFC4080NSIS枠組みの2005年6月
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]には、局部的修繕の概念があります。(ルータはルート変化によって局部的修繕で引き起こされるかもしれません)。 その場合、ノードがルート直後メッセージをPATHに送り始めることができるRSVPを変えました。 1流れあたりの状態が全くQNFに維持されないならこのオプションが利用可能でないかもしれないことに注意してください。 別のアプローチがバックアップ状態をプレインストールするだろうことであり、これをするのは、QoS-NSLPの責任でしょう。 しかしながら、それらに沿ってバックアップ道を特定して、必要なシグナリングメッセージを発送するためのメカニズムは現在、NSIS要件と枠組みで考えられません。
Route update
|
v
reserved +-----+ reserved +-----+
=========>| QNF |===========>| QNF |
+-----+ +-----+
-------- ||
\ || +-----+
| ===========>| QNF |
| +-----+
+--------------------------->
data path
ルートアップデート| vは+を予約しました。-----+ 予約された+-----+ =========>| QNF|===========>| QNF| +-----+ +-----+ -------- || \ || +-----+ | ===========>| QNF| | +-----+ +--------------------------->データ経路
Figure 8: Route Change
エイト環: ルート変化
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]で説明されます。 ルート変化が新しい発送された経路に混雑を作成するとき、このソリューションはルート変化に順応します。
Hancock, et al. Informational [Page 40] RFC 4080 NSIS Framework June 2005
ハンコック、他 [40ページ]情報のRFC4080NSISフレームワーク2005年6月
6.1.4. Resource Management Interactions
6.1.4. 資源管理相互作用
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自身はどんな特定の資源配分や管理技術にもかかわりません。 しかしながら、ServiceのQualityとの資源予約のためのNSLPの定義は入場コントロールの概念を含意します。 シグナリング成功の測定はネットワークで食糧を供給される総リソースプールからのリソースを予約するためにQoS NSLPに関しては、能力になるでしょう。 私たちはResource Management Function(RMF)としてこのリソースプールを割り当てるのに原因となる機能を定義します。 RMFはネットワークにおいてすべてリソースの食糧を供給すること、モニター、および保証機能に責任があります。
A QoS NSLP will rely on the RMF to do resource management and to provide inputs for admission control. In this model, the RMF acts as a server towards client NSLP(s). Note, however, that the RMF may in turn use another NSLP instance to do the actual resource provisioning in the network. In this case, the RMF acts as the initiator (client) of an NSLP.
QoS NSLPは、資源管理をして、入場コントロールのための入力を提供するためにRMFを当てにするでしょう。 このモデルでは、RMFはサーバとしてクライアントNSLP(s)に向かって機能します。 しかしながら、RMFがネットワークで実際のリソースの食糧を供給することをするのに順番に別のNSLPインスタンスを使用するかもしれないことに注意してください。 この場合、RMFはNSLPの創始者(クライアント)として機能します。
This essentially corresponds to a multi-level signaling paradigm, with an 'upper' level handling internetworking QoS signaling (possibly running end-to-end), and a 'lower' level handling the more specialized intra-domain QoS signaling (running between just the edges of the network). (See [10], [32], and [33] for a discussion of similar architectures.) Given that NSIS signaling is already supposed to be able to support multiple instances of NSLPs for a given flow and limited scope (e.g., edge-to-edge) operation, it is not currently clear that supporting the multi-level model leads to any new protocol requirements for the QoS NSLP.
これは本質的にはマルチレベルシグナリングパラダイムに対応しています、'上側'のレベルがインターネットワーキングQoSシグナリング(ことによると、終わらせる終わりを動かす)を扱っていて、'下側'のレベルが、より専門化しているイントラドメインQoSシグナリングを扱っていて(まさしくネットワークの縁の間で稼働していて)。 (同様のアーキテクチャの議論のための[10]、[32]、および[33]を見てください。) NSISシグナリングが与えられた流れと限られた範囲(例えば、縁から縁)操作のために既にNSLPsの複数のインスタンスをサポートすることができるべきであるなら、マルチレベルモデルをサポートするのが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(QNFとQNI/QNRの間の組み合わせとして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
RMFのプレースメントの制限は想定されません。 それは、1ドメインあたり1集結されたRMF、数個のオフ経路の分配されたRMFs、または1ルータあたり経路の1RMFであるかもしれません。 両方のアプローチの利点と損失は周知のことです。 中央集権化は以上がある、よりグローバルな情報を使用することで取られるという決定を通常許します。
Hancock, et al. Informational [Page 41] RFC 4080 NSIS Framework June 2005
ハンコック、他 [41ページ]情報のRFC4080NSISフレームワーク2005年6月
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.
その結果、効率的なリソース利用。 また、それは方針の展開かアップグレードを容易にします。 分配は地方の決定プロセスと迅速な応答をデータ経路変化に許容します。
6.2. Other Signaling Applications
6.2. 他のシグナリングアプリケーション
As well as the use for 'traditional' QoS signaling, it should be possible to develop NSLPs for other signaling applications that operate on different types of network control state. One specific case is setting up flow-related state in middleboxes (firewalls, NATs, and so on). Requirements for such communication are given in [4]. Other examples include network monitoring and testing, and tunnel endpoint discovery.
'伝統的な'QoSシグナリングの使用と同様に、異なったタイプのネットワーク制御状態を経営する他のシグナリングアプリケーションのためにNSLPsを開発するのは可能であるべきです。 1つの特定のケースがmiddleboxes(ファイアウォール、NATsなど)に流れ関連の状態を設立しています。 [4]でそのようなコミュニケーションのための要件を与えます。 他の例はネットワーク監視、テスト、およびトンネル終点発見を含んでいます。
7. Security Considerations
7. セキュリティ問題
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)がシグナリングアプリケーション詳細上側の層のプロトコル(NSLPs)のファミリーを養っていて。 したがって、シグナリングのための総合的なセキュリティ問題はそれぞれの層について想定されるか、または要求された共同セキュリティ所有地によります。
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.
セクション4.7でNTLPのためのセキュリティについて議論します。 私たちは、NTLPの主な役割はただ一つの同輩関係の範囲の上にメッセージ保護を供給することでしょう、それ自体に対するサービス不能攻撃に抵抗力があることは別として隣接しているシグナリングアプリケーション実体の間で思いました。 (これらの実体が1つ以上のNTLPホップによって切り離されるケースの議論に関してセクション3.2.3を見てください。) 既存のチャンネルセキュリティー対策で理想的にこれらの機能を提供できます、望ましくは、互いの認証に基づく外部のかぎ管理メカニズムを使用して。 可能なメカニズムに関する例は、TLSと、IPsecとSSHです。 しかしながら、セキュリティプロトコルの実際の選択とNTLPデザインの残りとの相互作用があります。 主として、ほとんどの既存のチャンネルセキュリティー対策がネットワーク、そして/または、輸送レベルでかかわる同輩の明白な識別を必要とします。 これは同輩のアイデンティティが未知であるのでこの情報がそれとなく利用可能でさえない経路で結合したシグナリング操作(例えば、発見)のそれらの局面と衝突します。 RSVPデザインに関するこの'次のホップ問題'の影響は、セキュリティ特性のドキュメント[6]で議論して、また、脅威分析[2]の多くの部分に影響を及ぼします。 したがって、このフレームワークはどんな特定のチャンネルセキュリティプロトコルの使用も強制しません。 代わりに、これは全体でNTLPのデザインについて統合していなければなりません。
Hancock, et al. Informational [Page 42] RFC 4080 NSIS Framework June 2005
ハンコック、他 [42ページ]情報のRFC4080NSISフレームワーク2005年6月
Security for the NSLPs is entirely dependent on signaling application requirements. In some cases, no additional protection may be required compared to what is provided by the NTLP. In other cases, more sophisticated object-level protection and the use of public- key-based solutions may be required. In addition, the NSLP needs to consider the authorization requirements of the signaling application. Authorization is a complex topic, for which a very brief overview is provided in Section 3.3.7.
NSLPsのためのセキュリティはシグナリングアプリケーション要件に完全に依存しています。 いくつかの場合、NTLPによって提供されるものと比べて、どんな追加保護も必要でないかもしれません。 他の場合では、より洗練されたオブジェクトレベル保護と公共のキーベースのソリューションの使用が必要であるかもしれません。 さらに、NSLPは、承認がシグナリングアプリケーションの要件であると考える必要があります。 承認は複雑な話題です。(非常に簡潔な概要はその話題においてセクション3.3.7に提供されます)。
Another factor is that NTLP security mechanisms operate only locally, whereas NSLP mechanisms may also need to operate over larger regions (not just between adjacent peers), especially for authorization aspects. This complicates the analysis of basing signaling application security on NTLP protection.
別の要素は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脅威仕事の気品によるでしょう。
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[1] Brunner, M., "Requirements for Signaling Protocols", RFC 3726,
April 2004.
[1] ブルンナー、M.、「シグナリングプロトコルのための要件」、RFC3726、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)における次のステップのための軍事的脅威」、RFC4081、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)ソリューションの要件」、RFC3583、2003年9月。
[4] Swale, R., Mart, P., Sijben, P., Brim, S., and M. Shore,
"Middlebox Communications (midcom) Protocol Requirements",
RFC 3304, August 2002.
[4] 低湿地、R.、市場、P.、Sijben、P.、縁、S.、およびM.は、「Middleboxコミュニケーション(midcom)プロトコル要件」と支えます、RFC3304、2002年8月。
Hancock, et al. Informational [Page 43] RFC 4080 NSIS Framework June 2005
ハンコック、他 [43ページ]情報のRFC4080NSISフレームワーク2005年6月
8.2. Informative References
8.2. 有益な参照
[5] Manner, J. and X. Fu, "Analysis of Existing Quality of Service
Signaling Protocols", Work in Progress, December 2004.
[5] 「既存のサービスの質シグナリングプロトコルの分析」という方法、J.、およびX.フーは進歩、2004年12月に働いています。
[6] Tschofenig, H., "RSVP Security Properties", Work in Progress,
February 2005.
[6] H.、「RSVPセキュリティの特性」というTschofenigは進歩、2005年2月に働いています。
[7] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC 2205, September 1997.
[7] ブレーデン、R.、チャン、L.、Berson、S.、ハーツォグ、S.、およびS.ジャマン、「資源予約は(RSVP)について議定書の中で述べます--バージョン1の機能的な仕様」、RFC2205、1997年9月。
[8] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[8] キャッツ、D.、「IPルータ警戒オプション」、RFC2113、1997年2月。
[9] Partridge, C. and A. Jackson, "IPv6 Router Alert Option",
RFC 2711, October 1999.
[9] ヤマウズラとC.とA.ジャクソン、「IPv6ルータ警戒オプション」、RFC2711、1999年10月。
[10] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie,
"Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175,
September 2001.
[10] ベイカー、F.、イトゥラルデ、C.、Le Faucheur、F.、およびB.デイビー、「IPv4とIPv6予約のためのRSVPの集合」、RFC3175(2001年9月)。
[11] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on
Security Considerations", BCP 72, RFC 3552, July 2003.
[11] レスコラ、E.とB.Korver、「セキュリティ問題に関するテキストをRFCに書くためのガイドライン」BCP72、2003年7月のRFC3552。
[12] Tschofenig, H., "NSIS Authentication, Authorization and
Accounting Issues", Work in Progress, March 2003.
[12] H.と、「NSIS認証、承認、および会計問題」というTschofenigは進歩、2003年3月に働いています。
[13] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., and S.
Molendini, "RSVP Refresh Overhead Reduction Extensions",
RFC 2961, April 2001.
[13] バーガー、L.、ガン、D.、ツバメ、G.、なべ、P.、トンマージ、F.、およびS.Molendini、「RSVPは全般的な減少拡大をリフレッシュする」RFC2961(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.、ゲー、Z.、黒瀬、J.、およびD.Townsley、「固い状態と軟性国家シグナリングプロトコルの比較」、コンピュータコミュニケーションは再検討されます、第33巻、No.4、2003年10月。
[15] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914,
September 2000.
[15] フロイド、S.、「輻輳制御プリンシプルズ」、BCP41、RFC2914、2000年9月。
[16] Apostolopoulos, G., Kamat, S., Williams, D., Guerin, R., Orda,
A., and T. Przygienda, "QoS Routing Mechanisms and OSPF
Extensions", RFC 2676, August 1999.
[16]Apostolopoulos、G.、Kamat、S.、ウィリアムズ、D.、ゲラン、R.、オルダ、A.、およびT.Przygienda、「メカニズムとOSPF拡張子を発送するQoS」、RFC2676(1999年8月)。
[17] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and
Multicast Next-Hop Selection", RFC 2991, November 2000.
[17] ターレルとD.とC.ホップス、「多重通路は中でユニキャストとマルチキャスト次のホップ選択を発行する」RFC2991、2000年11月。
[18] Hinden, R., "Virtual Router Redundancy Protocol (VRRP)", RFC
3768, April 2004.
[18]Hinden、2004年4月のR.、「仮想のルータ冗長プロトコル(VRRP)」RFC3768。
Hancock, et al. Informational [Page 44] RFC 4080 NSIS Framework June 2005
ハンコック、他 [44ページ]情報のRFC4080NSISフレームワーク2005年6月
[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.ウェストバーグ、「IPベースのラジオのDiffServ資源管理はネットワークにアクセスします」、ワイヤレスの個人的なマルチメディア通信WPMC'01における第4国際シンポジウムの議事、2001'9月9日〜12日。
[20] Manner, J., Lopez, A., Mihailovic, A., Velayos, H., Hepworth,
E., and Y. Khouaja, "Evaluation of Mobility and QoS
Interaction", Computer Networks Volume 38, Issue 2, p. 137-163,
5 February 2002.
[20] 方法とJ.とロペスとA.とMihailovicとA.とVelayosとH.とヘップウォース、E.とY.Khouaja、「移動性とQoS相互作用の評価」コンピュータNetworks Volume38、Issue2(p)。 137-163、2002年2月5日。
[21] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[21] ジョンソンとD.とパーキンス、C.とJ.Arkko、「IPv6"、RFC3775、2004年6月の移動性サポート。」
[22] Liebsch, M., Ed., Singh, A., Ed., Chaskar, H., Funato, D., and
E. Shim, "Candidate Access Router Discovery (CARD)", Work in
Progress, May 2005.
[22] Liebsch、M.(エド)、シン、A.(エド)、H.、船渡、D.、およびE.詰め物、「候補アクセスルータ発見(カード)」というChaskarは進行中(2005年5月)で働いています。
[23] Kempf, J., "Problem Description: Reasons For Performing Context
Transfers Between Nodes in an IP Access Network", RFC 3374,
September 2002.
[23] ケンフ、J.、「問題記述:」 「IPアクセスネットワークでノードの間の文脈転送を実行する理由」、RFC3374、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)用語と問題をネットワークでつなぐ」RFC2663、1999年8月。
[25] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)",
RFC 2765, February 2000.
[25]Nordmark、E.、「状態がないIP/ICMP変換アルゴリズム(SIIT)」、RFC2765、2000年2月。
[26] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN
- Simple Traversal of User Datagram Protocol (UDP) Through
Network Address Translators (NATs)", RFC 3489, March 2003.
[26] ローゼンバーグ、J.、ワインバーガー、J.、Huitema、C.、およびR.マーイ、「気絶させてください--ネットワークアドレス変換機構(NATs)を通したユーザー・データグラム・プロトコル(UDP)の簡単な縦断」、RFC3489、2003年3月。
[27] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP
Operation Over IP Tunnels", RFC 2746, January 2000.
2000年1月の[27]TerzisとA.とKrawczykとJ.とWroclawski、J.とL.チャン、「IP Tunnelsの上のRSVP操作」RFC2746。
[28] Bosch, S., Karagiannis, G., and A. McDonald, "NSLP for
Quality-of-Service signaling", Work in Progress, February 2005.
Progress、2005年2月の[28]ボッシュ、S.、Karagiannis、G.、およびA.マクドナルド、「サービスのQualityシグナリングのためのNSLP」Work。
[29] Stiemerling, M., "A NAT/Firewall NSIS Signaling Layer Protocol
(NSLP)", Work in Progress, February 2005.
[29] Stiemerling、M.、「NAT/ファイアウォールNSISシグナリングプロトコル(NSLP)層」が進歩、2005年2月に働いています。
[30] Braden, R., Clark, D., and S. Shenker, "Integrated Services in
the Internet Architecture: an Overview", RFC 1633, June 1994.
[30] ブレーデン、R.、クラーク、D.、およびS.Shenker、「インターネットアーキテクチャにおける統合サービス:」 「概要」、RFC1633、1994年6月。
Hancock, et al. Informational [Page 45] RFC 4080 NSIS Framework June 2005
ハンコック、他 [45ページ]情報のRFC4080NSISフレームワーク2005年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] ウェストバーグ、L.、Csaszar、A.、Karagiannis、G.、Marquetant、A.、パーテイン、D.、ポップス、O.、Rexhepi、V.、スザボ、R.、およびA.Takacs、「Diffserv(RMD)の資源管理:」 「FunctionalityとパフォーマンスBehavior Overview」、High-速度のためのプロトコルのSeventhの国際WorkshopはPfHSN2002、22をネットワークでつなぎます--2002年4月24日。
[32] Ferrari, D., Banerjea, A., and H. Zhang, "Network Support for
Multimedia - A Discussion of the Tenet Approach",
Berkeley TR-92-072, November 1992.
[32] フェラーリ、D.、バネルジー、A.、およびH.チャン、「マルチメディアのサポートをネットワークでつないでください--主義アプローチの議論」、バークレーTR-92-072、1992年11月。
[33] Nichols, K., Jacobson, V., and L. Zhang, "A Two-bit
Differentiated Services Architecture for the Internet",
RFC 2638, July 1999.
[33] ニコルズ、K.、ジェーコブソン、V.、およびL.チャン、「インターネットへの安っぽい差別化されたサービスアーキテクチャ」、RFC2638、1999年7月。
Hancock, et al. Informational [Page 46] RFC 4080 NSIS Framework June 2005
ハンコック、他 [46ページ]情報のRFC4080NSIS枠組みの2005年6月
Appendix A. Contributors
付録A.貢献者
Several parts of the introductory sections of this document (in particular, in Sections 3.1 and 3.3) are based on contributions from Ilya Freytsis, then of Cetacean Networks, Inc.
このドキュメント(特に、そして、セクション3.1、および3.3)の紹介しているセクションのいくつかの部分がそして、Cetacean Networks Inc.のイリヤFreytsisからの貢献に基づいています。
Bob Braden originally proposed "A Two-Level Architecture for Internet Signalling" as an Internet-Draft in November 2001. This document served as an important starting point for the framework discussed herein, and the authors owe a debt of gratitude to Bob for this proposal.
ボブ・ブレーデンは2001年11月に元々、インターネット草稿として「インターネット合図のための2レベルの構造」を提案しました。 このドキュメントはここに議論した枠組みのための重要な出発点として勤めました、そして、作者はこの提案にボブから恩義を借りています。
Appendix B. Acknowledgements
付録B.承認
The authors would like to thank Bob Braden, Maarten Buchli, Eleanor Hepworth, Andrew McDonald, Melinda Shore, and Hannes Tschofenig for significant contributions in particular areas of this document. In addition, the authors would like to acknowledge Cedric Aoun, Attila Bader, Anders Bergsten, Roland Bless, Marcus Brunner, Louise Burness, Xiaoming Fu, Ruediger Geib, Danny Goderis, Kim Hui, Cornelia Kappler, Sung Hycuk Lee, Thanh Tra Luu, Mac McTiffin, Paulo Mendes, Hans De Neve, Ping Pan, David Partain, Vlora Rexhepi, Henning Schulzrinne, Tom Taylor, Michael Thomas, Daniel Warren, Michael Welzl, Lars Westberg, and Lixia Zhang for insights and inputs during this and previous framework activities. Dave Oran, Michael Richardson, and Alex Zinin provided valuable comments during the final review stages.
作者はこのドキュメントの特定の領域での重要な貢献についてボブ・ブレーデン、Maarten Buchli、エレノア・ヘップウォース、アンドリュー・マクドナルド、メリンダShore、およびハンネスTschofenigに感謝したがっています。 さらに、作者は洞察と入力のためにこれと前の枠組みの活動の間、セドリックAoun、アッティラ・バーダー、アンダースBergsten、ローランドBless、Marcusブルンナー、ルイーズBurness、Xiaomingフー、ルーディガーGeib、ダニーGoderis、キム・ホイ、コルネリアKappler、Sung Hycukリー、ThanhトレイLuu、Mac McTiffin、パウロ・メンデス、ハンス・Deネーブ、Ping Pan、デヴィッド・パーテイン、ヴロレRexhepi、ヘニングSchulzrinne、トム・テイラー、マイケル・トーマス、ダニエル・ウォレン、マイケルWelzl、ラース・ウェストバーグ、およびLixiaチャンを承認したがっています。 デーヴ・オラン、マイケル・リチャードソン、およびアレックス・ジニンは最終審査ステージの間、貴重なコメントを提供しました。
Hancock, et al. Informational [Page 47] RFC 4080 NSIS Framework June 2005
ハンコック、他 [47ページ]情報のRFC4080NSIS枠組みの2005年6月
Authors' Addresses
作者のアドレス
Robert Hancock Siemens/Roke Manor Research Old Salisbury Lane Romsey, Hampshire SO51 0ZN UK
Manorの研究の古いソールズベリーLaneロムジー、ロバートハンコックシーメンス/RokeハンプシャーSO51 0ZNイギリス
EMail: robert.hancock@roke.co.uk
メール: robert.hancock@roke.co.uk
Georgios Karagiannis University of Twente P.O. BOX 217 7500 AE Enschede The Netherlands
Twente私書箱217 7500AEエンスヘーデオランダのイェオールイオスKaragiannis大学
EMail: g.karagiannis@ewi.utwente.nl
メール: g.karagiannis@ewi.utwente.nl
John Loughney Nokia Research Center 11-13 Itamerenkatu Helsinki 00180 Finland
ジョンLoughneyノキアResearch Center11-13Itamerenkatuヘルシンキ00180フィンランド
EMail: john.loughney@nokia.com
メール: john.loughney@nokia.com
Sven Van den Bosch Alcatel Francis Wellesplein 1 B-2018 Antwerpen Belgium
スベンバンデンボッシュアルカテルフランシスWellesplein1B-2018アントウェルペンベルギー
EMail: sven.van_den_bosch@alcatel.be
メール: sven.van_den_bosch@alcatel.be
Hancock, et al. Informational [Page 48] RFC 4080 NSIS Framework June 2005
ハンコック、他 [48ページ]情報のRFC4080NSIS枠組みの2005年6月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Hancock, et al. Informational [Page 49]
ハンコック、他 情報[49ページ]
一覧
スポンサーリンク
