Network Working Group K. Carlberg
Request for Comments: 4958 G11
Category: Informational July 2007
A Framework for Supporting Emergency Telecommunications Services (ETS) within a Single Administrative Domain
単一の管理ドメイン内の緊急通信サービス（ETS）をサポートするためのフレームワーク
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 IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
Abstract
抽象
This document presents a framework discussing the role of various protocols and mechanisms that could be considered candidates for supporting Emergency Telecommunication Services (ETS) within a single administrative domain. Comments about their potential usage as well as their current deployment are provided to the reader. Specific solutions are not presented.
この文書では、単一の管理ドメイン内の緊急通信サービス（ETS）をサポートするための候補と考えられるさまざまなプロトコルとメカニズムの役割を議論する枠組みを提示します。その潜在的な使用方法、並びにそれらの現在の展開についてのコメントは、読者に提供されています。具体的な解決策が提示されていません。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Differences between Single and Inter-Domain ................3
2. Common Practice: Provisioning ...................................4
3. Objective .......................................................5
3.1. Scenarios ..................................................5
4. Topic Areas .....................................................6
4.1. MPLS .......................................................6
4.2. RSVP .......................................................7
4.2.1. Relation to ETS .....................................8
4.3. Policy .....................................................8
4.4. Subnetwork Technologies ....................................9
4.4.1. IEEE 802.1 VLANs ....................................9
4.4.2. IEEE 802.11e QoS ...................................10
4.4.3. Cable Networks .....................................10
4.5. Multicast .................................................11
4.5.1. IP Layer ...........................................12
4.5.2. IEEE 802.1d MAC Bridges ............................12
4.6. Discovery .................................................13
4.7. Differentiated Services (Diffserv) ........................14
5. Security Considerations ........................................14
6. Summary Comments ...............................................15
7. Acknowledgements ...............................................15
8. References .....................................................15
8.1. Normative Reference .......................................15
8.2. Informative References ....................................15
This document presents a framework for supporting Emergency Telecommunications Services (ETS) within the scope of a single administrative domain. This narrow scope provides a reference point for considering protocols that could be deployed to support ETS. [rfc4375] is a complementary effort that articulates requirements for a single administrative domain and defines it as "collection of resources under the control of a single administrative authority". We use this other effort as both a starting point and guide for this document.
この文書では、単一の管理ドメインの範囲内で緊急通信サービス（ETS）をサポートするためのフレームワークを提示します。この狭い範囲は、ETSをサポートするために展開することができプロトコルを検討するための基準点を提供します。 [rfc4375]は、単一の管理ドメインのための要件を明確に表現し、「単一の管理権限の制御下にあるリソースのコレクション」としてそれを定義する補完的な努力です。私たちは、この文書の出発点とガイドの両方としてこの他の努力を使用しています。
A different example of a framework document for ETS is [rfc4190], which focused on support for ETS within IP telephony. In this case, the focal point was a particular application whose flows could span multiple autonomous domains. Even though this document uses a somewhat more constrained perspective than [rfc4190], we can still expect some measure of overlap in the areas that are discussed.
ETSのためのフレームワーク文書の別の例では、IP電話内のETSのサポートに焦点を当て[rfc4190]、です。この場合、焦点は、その流れ複数の自律ドメインにまたがることができ、特定の用途でした。この文書は[rfc4190]よりもいくらか制約視点を使用しても、我々はまだ議論されている領域にオーバーラップのいくつかの尺度を期待することができます。
The progression of our work in the following sections is helped by stating some key differences between the single and inter-domain cases. From a general perspective, one can start by observing the following.
次のセクションで私たちの仕事の進行は、単一のドメイン間のケースの間にいくつかの重要な違いを示すことによって助けられます。一般的な観点から、一つは次のことを観察することによって開始することができます。
a) Congruent with physical topology of resources, each domain is an authority zone, and there is currently no scalable way to transfer authority between zones.
A）リソースの物理トポロジーと一致、各ドメインは、権威ゾーンで、ゾーン間の権限を転送する全くスケーラブルな方法は現在ありません。
b) Each authority zone is under separate management.
b）の各権限ゾーンは、個別の管理下にあります。
c) Authority zones are run by competitors; this acts as further deterrent to transferring authority.
C）権限ゾーンは競合他社によって運営されています。これは、権限委譲への更なる抑止力として機能します。
As a result of the initial statements in (a) through (c) above, additional observations can be made that distinguish the single and inter-domain cases, as follows.
上記（c）は（A）における最初の文の結果として、付加的な観察は、以下のように、単一及びドメイン間のケースを区別することとすることができます。
d) Different policies might be implemented in different administrative domains.
d）に異なるポリシーが異なる管理ドメインで実装される可能性があります。
e) There is an absence of any practical method for ingress nodes of a transit domain to authenticate all of the IP network layer packets that have labels indicating a preference or importance.
e）の優先または重要度を示すラベルを有するIPネットワーク層パケットのすべてを認証するトランジットドメインの入口ノードに対する任意の実用的な方法が存在しないことがあります。
f) Given item (d) above, all current inter-domain QoS mechanisms at the network level generally create easily exploited and significantly painful Denial of Service (DoS) / Distributed Denial of Service (DDoS) attack vectors on the network.
F）上記（d）に示すように、現在のすべてのドメイン間のQoSメカニズムネットワークレベルでのサービスの一般作成容易に利用著しく痛みを伴う拒否（DoS）/ネットワーク上の分散サービス妨害（DDoS）攻撃の攻撃ベクトルを考えます。
g) A single administrative domain can deploy various mechanisms (e.g., access control lists) into each and every edge device (e.g., ethernet switch or router) to ensure that only authorized end-users (or layer 2 interfaces) are able to emit frames/packets with non-default QoS labels into the network. This is not feasible in the inter-domain case because the inter-domain link contains aggregated flows. In addition, the dissemination of access control lists at the network level is not scalable in the inter-domain case.
G）は、単一の管理ドメインにのみ許可され、エンドユーザ（またはレイヤー2インターフェイス）はフレームを放出することが可能であることを保証するために、それぞれ、すべてのエッジデバイス（例えば、イーサネット（登録商標）スイッチまたはルータ）に種々の機構（例えば、アクセス制御リスト）を展開することができ/非デフォルトのQoSを持つパケットがネットワークにラベルを付けます。ドメイン間リンクが集約されたフローが含まれているので、これは、ドメイン間のケースでは実現不可能です。また、ネットワークレベルでのアクセス制御リストの普及は、ドメイン間の場合にはスケーラブルではありません。
h) A single domain can deploy mechanisms into the edge devices to enforce its domain-wide policies -- without having to trust any third party to configure things correctly. This is not possible in the inter-domain case.
正しく物事を設定するために第三者を信用しなくても - h）は、単一のドメインは、そのドメイン全体のポリシーを適用するエッジデバイスにメカニズムを導入することができます。これは、ドメイン間のケースでは不可能です。
While the above is not an all-inclusive set of differences, it does provide some rationale why one may wish to focus efforts in the more constrained scenario of a single administrative domain.
上記の違いのすべてを含むセットではありませんが、それは1つが、単一の管理ドメインのより多くの制約シナリオに努力を集中することを望むかもしれない理由をいくつかの根拠を提供します。
The IEPREP working group and mailing list have had extensive discussions about over-provisioning. Many of these exchanges have debated the need for QoS mechanisms versus over-provisioning of links.
IEPREPワーキンググループとメーリングリストは、オーバープロビジョニングについての広範な議論がありました。これらの交換の多くは、オーバープロビジョニングリンクの対QoSメカニズムの必要性を議論しています。
In reality, most IP network links are provisioned with a percentage of excess capacity beyond that of the average load. The 'shared' resource model together with TCP's congestion avoidance algorithms helps compensate for those cases where spikes or bursts of traffic are experienced by the network.
実際には、ほとんどのIPネットワークリンクは平均負荷のそれを超えた過剰生産能力の割合でプロビジョニングされています。 TCPの輻輳回避アルゴリズムと一緒に「共有」リソース・モデルは、スパイクやトラフィックのバーストがネットワークによって経験されているような場合を補うことができます。
The thrust of the debate within the IEPREP working group is whether it is always better to over-provision links to such a degree that spikes in load can still be supported with no loss due to congestion. Advocates of this position point to many ISPs in the US that take this approach instead of using QoS mechanisms to honor agreements with their peers or customers. These advocates point to cost effectiveness in comparison to complexity and security issues associated with other approaches.
IEPREPワーキンググループ内での議論の推力は、それが常に負荷のスパイクはまだ、輻輳に起因する損失なく支持することができる程度にオーバープロビジョニングリンクに優れているかどうかです。同僚や顧客との契約を尊重するためにQoSメカニズムを使用する代わりに、このアプローチを取る米国の多くのISPにこの位置ポイントの支持者。これらの支持者は、他のアプローチに伴う複雑さとセキュリティの問題と比較して有効性をコストにポイントします。
Proponents of QoS mechanisms argue that the relatively low cost of bandwidth enjoyed in the US (particularly, by large ISPs) is not necessarily available throughout the world. Beyond the subject of cost, some domains are comprised of physical networks that support wide disparity in bandwidth capacity -- e.g., attachment points connected to high capacity fiber and lower capacity wireless links.
QoSメカニズムの支持者は、米国で楽しむ帯域幅の比較的低コストで（特に、大規模なISPが）、世界全体では必ずしも利用できないと主張しています。高容量の繊維と低容量無線リンクに接続され、例えば、付着点 - コストの主題を越えて、いくつかのドメインは、帯域幅容量の広い視差をサポートする物理ネットワークで構成されています。
This document does not advocate one of these positions over the other. The author does advocate that network administrators/operators should perform a cost analysis between over-provisioning for spikes versus QoS mechanisms as applied within a domain and its access link to another domain (e.g., a customer and its ISP). This analysis, in addition to examining policies and requirements of the administrative domain, should be the key to deciding how (or if) ETS should be supported within the domain.
この文書では、他の上にこれらの位置の1を提唱しません。著者は、別のドメイン（例えば、顧客とそのISP）へのドメインとそのアクセスリンク内で適用されるように、そのネットワーク管理者/オペレータは、QoSメカニズム対スパイクのためのオーバープロビジョニングの間のコスト分析を実行する必要が提唱し。この分析は、管理ドメインのポリシーおよび要件を検討することに加えて、ETSドメイン内でサポートされるべきか（または場合）を決定するための鍵である必要があります。
If the decision is to rely on over-provisioning, then some of the following sections will have little to no bearing on how ETS is supported within a domain. The exception would be labeling mechanisms used to convey information to other communication architectures (e.g., SIP-to-SS7/ISUP gateways).
決定は、オーバープロビジョニングに依存している場合は、次のセクションのいくつかは、ドメイン内でサポートされてどのようETSにはベアリングに少しを持っています。例外は、他の通信アーキテクチャ（例えば、SIP対SS7 / ISUPゲートウェイ）に情報を伝えるために使用されるメカニズムを標識するであろう。
The primary objective is to provide a target measure of service within a domain for flows that have been labeled for ETS. This level may be better than best effort, the best available service that the network (or parts thereof) can offer, or a specific percentage of resource set aside for ETS. [rfc4375] presents a set of requirements in trying to achieve this objective.
主な目的は、ETSのために標識されているフローのためのドメイン内のサービスの目標指標を提供することです。このレベルでは、ネットワーク（またはその一部）が提供できる最高の利用可能なサービス、またはETS用に確保されたリソースの特定の割合、ベストエフォートよりも良いかもしれません。 [rfc4375]はこの目的を達成しようとする際に一連の要件を提示します。
This framework document uses [rfc4375] as a reference point in discussing existing areas of engineering work or protocols that can play a role in supporting ETS within a domain. Discussion of these areas and protocols are not to be confused with expectations that they exist within a given domain. Rather, the subjects discussed in Section 4 below are ones that are recognized as candidates that can exist and could be used to facilitate ETS users or data flows.
このフレームワークドキュメントはドメイン内のETSを支える役割を果たすことができるのエンジニアリング作業やプロトコルの既存の分野を議論する中で基準点として[rfc4375]を使用しています。これらの領域とプロトコルの議論は、彼らが特定のドメイン内に存在することを期待と混同してはなりません。むしろ、以下のセクション4で説明した被験者が存在し得る候補として認識され、ETSユーザまたはデータフローを容易にするために使用することができるものです。
One of the topics of discussion on the IEPREP mailing list and in the working group meetings is the operating environment of the ETS user. Many variations can be dreamed of with respect to underlying network technologies and applications. Instead of getting lost in hundreds of potential scenarios, we attempt to abstract the scenarios into two simple case examples.
IEPREPメーリングリスト上やワーキンググループの会合での議論の話題の一つは、ETSのユーザーの動作環境です。多くの変形は、基盤となるネットワーク技術とアプリケーションに関しての夢を見たことができます。代わりに、潜在的なシナリオの数百に迷子の、我々は2つの単純なケースを例に抽象化のシナリオにしよう。
(a) A user in their home network attempts to use or leverage any ETS capability within the domain.
（a）はそのホームネットワーク内のユーザーが使用したり、ドメイン内の任意のETS機能を活用しようとします。
(b) A user visits a foreign network and attempts to use or leverage any ETS capability within the domain.
（b）は、ユーザがフォーリン・ネットワークを訪問し、使用またはドメイン内の任意のETS能力を活用することを試みます。
We borrow the terms "home" and "foreign" network from that used in Mobile IP [rfc3344]. Case (a) is considered the normal and vastly most prevalent scenario in today's Internet. Case (b) above may simply be supported by the Dynamic Host Configuration Protocol (DHCP) [rfc2131], or a static set of addresses, that are assigned to 'visitors' of the network. This effort is predominantly operational in nature and heavily reliant on the management and security policies of that network.
私たちは、用語「ホーム」とモバイルIP [RFC3344]で使用されているから、「外国人」のネットワークを借ります。 （a）の場合は、今日のインターネットでの大幅通常、最も普及シナリオと考えられています。ケースには、上記（b）単に動的ホスト構成プロトコル（DHCP）[RFC2131]、またはネットワークの「訪問者に割り当てられたアドレスの静的セットでサポートすることができます。この取り組みは、自然の中で主に運用し、そのネットワークの管理とセキュリティポリシーに大きく依存しています。
A more ambitious way of supporting the mobile user is through the use of the Mobile IP (MIP) protocol. MIP offers a measure of application-transparent mobility as a mobile host moves from one subnetwork to another while keeping the same stable IP address registered at a global anchor point. However, this feature may not always be available or in use. In any case, where it is in use, at least some of the packets destined to and from the mobile host go through the home network.
モバイルユーザをサポートする、より野心的な方法は、モバイルIP（MIP）プロトコルを使用することです。グローバルアンカーポイントに登録同じ安定したIPアドレスを維持しながら、MIPは、別のサブネットワークからモバイルホストが移動すると、アプリケーション透過的なモビリティの指標を提供しています。ただし、この機能は常に利用または使用中ではないかもしれません。それが使用されているいずれにせよ、に、に、モバイルホストから送信されるパケットの少なくとも一部は、ホームネットワークを通過します。
The topic areas presented below are not presented in any particular order or along any specific layering model. They represent capabilities that may be found within an administrative domain. Many are topics of on-going work within the IETF.
以下に示すトピック領域は、任意の特定の順序または任意の特定の階層化モデルに沿って提示されません。彼らは、管理ドメイン内に見出すことができる能力を表します。多くは、IETF内で、進行中の作業のトピックです。
It must be stressed that readers of this document should not expect any of the following to exist within a domain for ETS users. In many cases, while some of the following areas have been standardized and in wide use for several years, others have seen very limited deployment.
このドキュメントの読者は次のいずれかがETSユーザーのドメイン内に存在することを期待してはならないことを強調しなければなりません。以下の分野のいくつかは数年のために標準化し、広く使用されてきたが、多くの場合、他の人は非常に限られた展開を見てきました。
Multiprotocol Label Switching (MPLS) is generally the first protocol that comes to mind when the subject of traffic engineering is brought up. MPLS signaling produces Labeled Switched Paths (LSPs) through a network of Label Switch Routers [rfc3031]. When traffic reaches the ingress boundary of an MPLS domain (which may or may not be congruent with an administrative domain), the packets are classified, labeled, scheduled, and forwarded along an LSP.
マルチプロトコルラベルスイッチング（MPLS）は、一般的にトラフィックエンジニアリングの対象を育てているとき心に来る最初のプロトコルです。 MPLSシグナリングは、標識は、ラベルスイッチルータ[RFC3031]のネットワークを通じてパス（LSPを）交換生成します。トラフィック（または管理ドメインと一致してもしなくてもよい）MPLSドメインの入口境界に到達すると、パケットは、分類標識された、スケジュール、およびLSPに沿って転送されます。
[rfc3270] describes how MPLS can be used to support Differentiated Services. The RFC discusses the use of the 3-bit EXP (experimental) field to convey the Per Hop Behavior (PHB) to be applied to the packet. As we shall see in later sections, this 3-bit field can be mapped to fields in several other protocols.
[rfc3270]はMPLSは、差別化サービスをサポートするために使用することができる方法を説明します。 RFCは、パケットに適用されるパーホップの動作（PHB）を搬送する3ビットEXP（実験）フィールドの使用を論じています。私たちは後の節で見るように、この3ビットのフィールドは、いくつかの他のプロトコル内のフィールドにマッピングすることができます。
The inherent features of classification, scheduling, and labeling are viewed as symbiotic, and therefore, they are often integrated with other protocols and architectures. Examples of this include RSVP and Differentiated Services. Below, we discuss several instances where a given protocol specification or mechanism has been known to be complemented with MPLS. This includes the potential labels that may be associated with ETS. However, we stress that MPLS is only one of several approaches to support traffic engineering. In addition, the complexity of the MPLS protocol and architecture may make it suited only for large domains.
分類、スケジューリング、およびラベルの固有の特徴は、共生と見ているため、彼らはしばしば他のプロトコルおよびアーキテクチャに統合されています。この例としては、RSVPと差別化サービスが含まれます。以下に、私たちは、与えられたプロトコル仕様やメカニズムは、MPLSを補完することが知られているいくつかの例を議論します。これは、ETSに関連付けることができる潜在的な標識を含みます。しかし、私たちは、MPLSトラフィックエンジニアリングをサポートするためのいくつかのアプローチのうちの1つにすぎないことを強調します。また、MPLSプロトコル及びアーキテクチャの複雑さは、それが唯一の大きなドメインに適して行うことができます。
The original design of RSVP, together with the Integrated Services model, was one of an end-to-end signaling capability to set up a path of reserved resources that spanned networks and administrative domains [rfc2205]. Currently, RSVP has not been widely deployed by network administrators for QoS across domains. Today's limited deployment by network administrators has been mostly constrained to boundaries within a domain, and commonly in conjunction with MPLS signaling. Early deployments of RSVP ran into unanticipated scaling issues; it is not entirely clear how scalable an RSVP approach would be across the Internet.
一体化サービスモデルとRSVPの元の設計は、ネットワークや管理ドメイン[RFC2205]をスパン予約されたリソースのパスを設定するためのエンドツーエンドシグナリング能力の一つでした。現在、RSVPは広くドメイン間のQoSのためのネットワーク管理者によって展開されていません。ネットワーク管理者によって今日の限られた展開は、主に、ドメイン内の境界に拘束され、一般的にMPLSシグナリングと一緒にされています。 RSVPの早期展開は予想外のスケーリングの問題に遭遇しました。 RSVPのアプローチは、インターネットを介しだろうかスケーラブルで完全には明らかではありません。
[rfc3209] is one example of how RSVP has evolved to complement efforts that are scoped to operate within a domain. In this case, extensions to RSVP are defined that allow it to establish intra-domain Labeled Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS).
[RFC3209]はRSVPは、ドメイン内で動作するようにスコープされた努力を補完するために進化してきた方法の一例です。この場合、RSVPへの拡張は、マルチプロトコルラベルでスイッチドパス（LSPの）標識ドメイン内スイッチング（MPLS）を確立することを可能にするように定義されています。
[rfc2750] specifies extensions to RSVP so that it can support generic policy-based admission control. This standard goes beyond the support of the POLICY_DATA object stipulated in [rfc3209], by defining the means of control and enforcement of access and usage policies. While the standard does not advocate a particular policy architecture, the IETF has defined one that can complement [rfc2750] -- we expand on this in Section 4.3 below.
[rfc2750]は、それが一般的なポリシーベースのアドミッション制御をサポートできるように、RSVPに拡張子を指定します。この規格は、アクセスと利用ポリシーの管理と執行の手段を定義することによって、[RFC3209]に規定POLICY_DATAオブジェクトのサポートを超えました。標準は、特定のポリシーのアーキテクチャを提唱していませんが、IETFは、[rfc2750]を補完することができるものを定義している - 私たちは以下のセクション4.3でこれを拡張します。
The ability to reserve resources correlates to an ability to provide preferential service for specifically classified traffic -- the classification being a tuple of 1 or more fields which may or may not include an ETS specific label. In cases where a tuple includes a label that has been defined for ETS usage, the reservation helps ensure that an emergency-related flow will be forwarded towards its destination. Within the scope of this document, this means that RSVP would be used to facilitate the forwarding of traffic within a domain.
リソースを予約する能力は、具体的に分類されたトラフィックに対して優先サービスを提供する能力と相関する - 分類またはETS特定のラベルを含んでも含まなくてもよい1つの以上のフィールドの組です。タプルは、ETSの使用のために定義されたラベルを含む場合には、予約が緊急関連フローがその宛先に向けて転送されることを保証するのに役立ちます。このドキュメントの範囲内で、これは、RSVPは、ドメイン内のトラフィックの転送を容易にするために使用されることを意味しています。
We note that this places an importance on defining a label and an associated field that can be set and/or examined by RSVP-capable nodes.
これはラベルと設定および/またはRSVP対応のノードで調べることができる関連するフィールドの定義を重視することに注意してください。
Another important observation is that major vendor routers currently constrain their examination of fields for classification to the network and transport layers. This means that application layer labels will mostly likely be ignored by routers/switches.
もう一つの重要な観察は、主要ベンダーのルータは、現在のネットワーク層とトランスポート層への分類のための分野の彼らの調査を制約ということです。これは、アプリケーション層のラベルはほとんど可能性がルータ/スイッチによって無視されることを意味します。
The Common Open Policy Service (COPS) protocol [rfc2748] was defined to provide policy control over QoS signaling protocols, such as RSVP. COPS is based on a query/response model in which Policy Enforcement Points (PEPs) interact with Policy Decision Points (i.e., policy servers) to exchange policy information. COPS provides application-level security and can operate over IPsec or TLS. COPS is also a stateful protocol that supports a push model. This means that servers can download new policies or alter existing ones to known clients.
共通オープンポリシーサービス（COPS）プロトコル[rfc2748は、このようなRSVPなどのプロトコルを、QoSシグナリングオーバーポリシー制御を提供するために定義されました。 COPSは、ポリシー施行ポイント（のPEP）はポリシー情報を交換するために、ポリシー決定ポイント（すなわち、ポリシーサーバ）と対話しているクエリ/応答モデルに基づいています。 COPSは、アプリケーションレベルのセキュリティを提供し、IPSecまたはTLS上で動作することができます。 COPSまた、プッシュモデルをサポートしてステートフルなプロトコルです。これは、サーバが新しいポリシーをダウンロードしたり、既知のクライアントに、既存のものを変化させることができることを意味します。
[rfc2749] articulates the usage of COPS with RSVP. It specifies COPS client types, context objects, and decision objects. Thus, when an RSVP reservation is received by a PEP, the PEP decides whether to accept or reject it based on policy. This policy information can be stored a priori to the reception of the RSVP PATH message, or it can be retrieved on an on-demand basis. A similar course of action could be applied in cases where ETS-labeled control flows are received by the PEP. This of course would require an associated (and new) set of documents that first articulates types of ETS signaling and then specifies its usage with COPS.
[rfc2749]はRSVPとCOPSの使用を明確に表現します。それはCOPSクライアントタイプ、コンテキストオブジェクト、および意思決定のオブジェクトを指定します。 RSVP予約がPEPによって受信されたときしたがって、PEPはポリシーに基づいて、それを受け入れるか拒否するかを決定します。このポリシー情報は、RSVP PATHメッセージの受信に事前に格納することができ、またはそれは、オンデマンドベースで検索することができます。アクションの同様のコースでは、ETS-標識された制御フローはPEPによって受信される場合に適用することができます。もちろん、これは最初のETSシグナリングの種類を明確に表現して、COPSとその使用方法を指定する文書の関連する（および新しい）セットが必要となります。
A complementary document to the COPS protocols is COPS Usage for Policy Provisioning (COPS-PR) [rfc3084].
COPSプロトコルに相補的な文書がポリシーのプロビジョニング（COPS-PR）[rfc3084]のためにCOPS使用です。
As a side note, the current lack of deployment by network administrators of RSVP has also played at least an indirect role in the subsequent lack of implementation and deployment of COPS-PR. [rfc3535] is an output from the IAB Network Management Workshop in which the topic of COPS and its current state of deployment was discussed. At the time of that workshop in 2002, COPS-PR was considered a technology/architecture that did not fully meet the needs of network operators. It should also be noted that at the 60th IETF meeting held in San Diego in 2004, COPS was discussed as a candidate protocol that should be declared as historic because of lack of use and concerns about its design. In the future, an altered design of COPS may emerge that addresses the concern of operators, but speculation on that or other possibilities is beyond the scope of this document.
注意点として、RSVPのネットワーク管理者による展開の現在の欠如はまた、COPS-PRの実装と展開のその後の不足で、少なくとも間接的な役割を果たしてきました。 [rfc3535]はCOPSおよび展開の現在の状態のトピックが議論されたIABネットワーク管理ワークショップから出力されます。 2002年にそのワークショップの時には、COPS-PRは完全にネットワーク事業者のニーズを満たしていなかった技術/アーキテクチャと考えられていました。また、2004年にサンディエゴで開催された第60回IETFミーティングで、COPSがあるため、使用の欠如とそのデザインへの懸念の歴史として宣言されなければならない候補プロトコルとして議論されたことに留意すべきです。将来的には、COPSの変更されたデザインは、事業者の懸念に対処している出現するかもしれないが、そのまたは他の可能性についての憶測は、このドキュメントの範囲を超えています。
This is a generalization of work that is considered "under" IP and for the most part outside of the IETF standards body. We discuss some specific topics here because there is a relationship between them and IP in the sense that each physical network interacts at its edge with IP.
これは、IP「の下に」とIETF標準化団体の外側の大部分は考慮されている作品を一般化したものです。各物理ネットワークがIPとの縁で相互に作用するという意味で、それらとIPの間に関係があるので、私たちはここにいくつかの特定のトピックについて説明します。
The IEEE 802.1q standard defined a tag appended to a Media Access Controller (MAC) frame for support of layer 2 Virtual Local Area Networks (VLANs). This tag has two parts: a VLAN identifier (12 bits) and a Prioritization field of 3 bits. A subsequent standard, IEEE 802.1p, later incorporated into a revision of IEEE 802.1d, defined the Prioritization field of this new tag [iso15802]. It consists of 8 levels of priority, with the highest priority being a value of 7. Vendors may choose a queue per priority codepoint, or aggregate several codepoints to a single queue.
IEEE 802.1Qの標準は、レイヤ2仮想ローカルエリアネットワーク（VLAN）のサポートのためのメディアアクセスコントローラ（MAC）フレームに付加されるタグを定義しました。 VLAN識別子（12ビット）と3ビットの優先順位フィールド：このタグは、2つの部分を有します。後IEEE 802.1Dのリビジョンに組み込まれ、その後の規格、IEEE 802.1Pは、この新しいタグ[iso15802]の優先順位フィールドを定義しました。これは、最高の優先度が7ベンダーの値は、単一のキューに優先コードポイントごとにキュー、または集約いくつかのコードポイントを選択することができることで、優先順位の8つのレベルから成ります。
The 3-bit Prioritization field can be easily mapped to the old ToS field of the upper-layer IP header. In turn, these bits can also be mapped to a subset of differentiated codepoints. Bits in the IP header that could be used to support ETS (e.g., specific Diffserv codepoints) can in turn be mapped to the Prioritization bits of 802.1p. This mapping could be accomplished in a one-to-one manner between the 802.1p field and the IP ToS bits, or in an aggregate manner if one considers the entire Diffserv field in the IP header. In either case, because of the scarcity of bits, ETS users should expect that their traffic will be combined or aggregated with the same level of priority as some other types of "important" traffic. In other words, given the existing 3-bit Priority Field for 802.1p, there will not be an exclusive bit value reserved for ETS traffic.
3ビットの優先順位フィールドが容易上層IPヘッダの古いToSフィールドにマッピングすることができます。次に、これらのビットはまた、分化したコードポイントのサブセットにマッピングすることができます。 ETS（例えば、特定のDiffservコードポイント）をサポートするために使用できるIPヘッダ内のビットは、順番に802.1Pのプライオリティビットにマッピングすることができます。一つは、IPヘッダ全体DiffServフィールドを考える場合、このマッピングは、または凝集方法で802.1Pフィールド及びIP ToSビットの間に一対一の方法で達成することができます。いずれの場合においても、ビットの不足のため、ETSユーザーは、トラフィックが組み合わさまたは「重要な」トラフィックのいくつかの他のタイプのような優先順位の同じレベルで集計されることを期待すべきです。換言すれば、802.1pのための既存の3ビットの優先度フィールド所与、ETSトラフィックのために予約排他ビット値が存在しないであろう。
Certain vendors are currently providing mappings between the 802.1p field and the ToS bits. This is in addition to integrating the signaling of RSVP with the low-level inband signaling offered in the Priority field of 802.1p.
一部のベンダーは、現在の802.1pフィールドとToSビット間のマッピングを提供しています。これは802.1Pの優先分野で提供低レベル帯域内シグナリングでRSVPのシグナルを統合することに加えています。
It is important to note that the 802.1p standard does not specify the correlation of a layer 2 codepoint to a physical network bandwidth reservation. Instead, this standard provides what has been termed as "best effort QoS". The value of the 802.1p Priority codepoints is realized at the edges: either as the MAC payload is passed to upper layers (like IP), or as it is bridged to other physical networks like Frame Relay. Either of these actions help provide an intra-domain wide propagation of a labeled flow for both layer 2 and layer 3 flows.
802.1p規格は、物理的なネットワーク帯域幅予約にレイヤ2コードポイントの相関を指定していないことに注意することが重要です。代わりに、この規格では、「ベストエフォートのQoS」と呼ばれているものを提供します。それはフレーム・リレーのような他の物理ネットワークにブリッジされるMACペイロードが（IPなど）を上位レイヤに渡されるかのように、または：802.1pプライオリティコードポイントの値がエッジで実現されます。これらのアクションのいずれかは、両方のレイヤ2およびレイヤ3のフローに標識されたフローのイントラドメインワイド伝播を提供するのに役立ちます。
The 802.11e standard is a proposed enhancement that specifies mechanisms to provide QoS to the 802.11 family of protocols for wireless LANs.
802.11e規格は、無線LANのプロトコルの802.11ファミリにQoSを提供するためのメカニズムを指定する提案拡張機能です。
Previously, 802.11 had two modes of operation. One was Distributed Coordination Function (DCF) , which is based on the classic collision detection schema of "listen before sending". A second optional mode is the Point Coordination Function (PCF). The modes splits access time into contention-free and contention-active periods -- transmitting data during the former.
以前は、802.11は、2つの動作モードを持っていました。一つは、「送信する前に聞く」の古典的な衝突検出スキーマに基づいてコーディネーション機能（DCF）を、分散されました。第2の任意のモードは、ポイント調整機能（PCF）です。モードは、コンテンションフリー及びコンテンションアクティブ期間にアクセスタイムを分割 - 前者の中にデータを送信します。
The 802.11e standard enhances DCF by adding support for 8 different traffic categories or classifications. Each higher category waits a little less time than the next lower one before it sends its data.
802.11e規格は、8つの異なるトラフィックカテゴリや分類のためのサポートを追加することにより、DCFを強化します。それはそのデータを送信する前に、各上位カテゴリには、次の低いものよりも少し短い時間を待ちます。
In the case of PCF, a Hybrid Coordination Function has been added that polls stations during contention-free time slots and grants them a specific start time and maximum duration for transmission. This second mode is more complex than enhanced DCF, but the QoS can be more finely tuned to offer specific bandwidth and jitter control. It must be noted that neither enhancement offers a guarantee of service.
PCFの場合には、ハイブリッドコーディネーション機能は、コンテンションフリータイムスロットの間にそのポーリングステーションを追加し、それらに特定の開始時刻と送信の最大持続時間を付与されています。この第2のモードは強化DCFよりも複雑ですが、QoSは、より細かく特定の帯域幅とジッタ制御を提供するように調整することができます。どちらの機能拡張は、サービスの保証を提供することに留意しなければなりません。
The Data Over Cable Service Interface Specification (DOCSIS) is a standard used to facilitate the communication and interaction of the cable subnetwork with upper-layer IP networks [docsis]. Cable subnetworks tend to be asynchronous in terms of data load capacity: typically, 27 M downstream, and anywhere from 320 kb to 10 M upstream (i.e., in the direction of the user towards the Internet).
データオーバーケーブルサービスインターフェース仕様（DOCSIS）上層IPネットワークとケーブルサブ[DOCSIS]の通信及び相互作用を容易にするために使用される標準です。ケーブルサブネットワークは、データ負荷容量の点で非同期である傾向がある。典型的に、27 Mは、下流、およびどこ320キロバイトから（即ち、インターネットに向かってユーザの方向に）10 M上流へ。
The evolution of the DOCSIS specification, from 1.0 to 1.1, brought about changes to support a service other than best effort. One of the changes was indirectly added when the 802.1d protocol added the Priority field, which was incorporated within the DOCSIS 1.1 specification. Another change was the ability to perform packet fragmentation of large packets so that Priority-marked packets (i.e., packets marked with non-best effort labels) can be multiplexed in between the fragmented larger packet.
DOCSIS仕様の進化は、1.0から1.1に、最善の努力以外のサービスをサポートするために変化をもたらしました。 802.1DプロトコルはDOCSIS 1.1仕様内に組み込まれた優先度フィールドを追加したときの変更のいずれかを間接的に添加しました。別の変更は、その優先度にマーキングされたパケット（非ベストエフォートのラベルの付いた、すなわち、パケット）断片より大きなパケットとの間で多重化することができるように、大きいパケットのパケットの断片化を実行する能力でした。
It's important to note that the DOCSIS specifications do not specify how vendors implement classification, policing, and scheduling of traffic. Hence, operators must rely on mechanisms in Cable Modem Termination Systems (CMTS) and edge routers to leverage indirectly or directly the added specifications of DOCSIS 1.1. As in the case of 802.1p, ETS-labeled traffic would most likely be aggregated with other types of traffic, which implies that an exclusive bit (or set of bits) will not be reserved for ETS users. Policies and other managed configurations will determine the form of the service experienced by ETS labeled traffic.
これは、DOCSIS仕様は、ベンダーが分類、ポリシング、およびトラフィックのスケジューリングを実装する方法を指定していないことに注意することが重要です。したがって、オペレータは、DOCSIS 1.1の間接的または直接的に添加仕様を活用するケーブルモデム終端システム（CMTS）およびエッジルータのメカニズムに依存しなければなりません。 802.1Pの場合のように、ETS-標識されたトラフィックは、ほとんど排他的ビット（またはビットのセット）はETSのユーザのために確保されないことを意味する、トラフィックの他のタイプの集約されるであろう。ポリシーおよびその他の管理の構成はETSラベルされたトラフィックが経験するサービスの形式を決定します。
Traffic engineering and management of ETS labeled flows, including its classification and scheduling at the edges of the DOCSIS cloud, could be accomplished in several ways. A simple schema could be based on non-FIFO queuing mechanisms like class-based weighted fair queuing (or combinations and derivations thereof). The addition of active queue management like Random Early Detection could provide simple mechanisms for dealing with bursty traffic contributing to congestion. A more elaborate scheme for traffic engineering would include the use of MPLS. However, the complexity of MPLS should be taken into consideration before its deployment in networks.
DOCSIS雲の縁でその分類とスケジューリングを含むETSラベルされたフローのトラフィックエンジニアリングと管理は、いくつかの方法で達成することができます。単純なスキーマは、クラスベース重み付け均等化キューイング（またはそれらの組み合わせおよび派生）などの非FIFOキューイングメカニズムに基づくことができます。ランダム早期検出のようなアクティブキュー管理の添加は混雑に貢献バーストトラフィックを処理するための簡単なメカニズムを提供することができます。トラフィックエンジニアリングのためのより精巧なスキームは、MPLSの使用が含まれます。しかし、MPLSの複雑さは、ネットワークでの展開の前に考慮すべきです。
Network layer multicast has existed for quite a few years. Efforts such as the Mbone (multicast backbone) have provided a form of tunneled multicast that spans domains, but the routing hierarchy of the Mbone can be considered flat and non-congruent with unicast routing. Efforts like the Multicast Source Discovery Protocol [rfc3618] together with the Protocol Independent Multicast - Sparse Mode (PIM-SM) have been used by a small subset of Internet Service Providers to provide forms of inter-domain multicast [rfc4601]. However, network layer multicast has not been accepted as a common production level service by a vast majority of ISPs.
ネットワーク層マルチキャストはかなりの数年間存在しています。そのようなMBONE（マルチキャストバックボーン）などの努力がドメインにまたがるトンネリングマルチキャストの形態を提供してきたが、MBONEのルーティング階層は、ユニキャストルーティングをフラットと非合同と考えることができます。一緒にプロトコル独立マルチキャストとマルチキャストソース発見プロトコル[rfc3618]のような取り組み - 希薄モード（PIM-SM）は、ドメイン間のマルチキャスト[RFC4601]の形を提供するために、インターネット・サービス・プロバイダーの小さなサブセットによって使用されています。しかし、ネットワーク層マルチキャストは、ISPの大半のことで、共通の生産レベルのサービスとして受け入れられていません。
In contrast, intra-domain multicast in domains has gained more acceptance as an additional network service. Multicast can produce denial-of-service attacks using the any sender model, with the problem made more acute with flood and prune algorithms. Source- specific multicast [rfc3569], together with access control lists of who is allowed to be a sender, reduces the potential and scope of such attacks.
これとは対照的に、ドメイン内のドメイン内のマルチキャストは、追加のネットワークサービスとして、より受け入れられています。マルチキャストは、洪水やプルーンのアルゴリズムでより深刻に作られた問題で、任意の送信者モデルを使用して、サービス拒否攻撃を生成することができます。ソース - 特定のマルチキャスト[RFC3569]、一緒に送信者であることを許可するユーザーのアクセス制御リストでは、このような攻撃の可能性と範囲を低減します。
The value of IP multicast is its efficient use of resources in sending the same datagram to multiple receivers. An extensive discussion on the strengths of and concerns about multicast is outside the scope of this document. However, one can argue that multicast can very naturally complement the push-to-talk feature of land mobile radio (LMR) networks.
IPマルチキャストの値は、複数の受信者に同じデータグラムを送信におけるリソースの効率的な使用です。強みとマルチキャストの懸念について広範な議論は、この文書の範囲外です。しかし、一つは、マルチキャストは非常に自然に陸上移動無線（LMR）ネットワークのプッシュ・ツー・トーク機能を補完できることを主張することができます。
Push-to-talk is a form of group communication where every user in the "talk group" can participate in the same conversation. LMR is the type of network used by First Responders (e.g., police, firemen, and medical personnel) that are involved in emergencies. Currently, certain vendors and providers are offering push-to-talk service to the general public in addition to First Responders. Some of these systems are operated over IP networks or are interfaced with IP networks to extend the set of users that can communicate with each other. We can consider at least a subset of these systems as either closed IP networks, or domains, since they do not act as transits to other parts of the Internet.
プッシュ・ツー・トークは、「トークグループ」内のすべてのユーザーが同じ会話に参加できるグループコミュニケーションの一形態です。 LMRは、緊急事態に関与している第一応答者（例えば、警察、消防、および医療従事者）によって使用されるネットワークのタイプです。現在、特定のベンダーやプロバイダは、ファーストレスポンダに加えて、一般市民へのプッシュ・トゥ・トークサービスを提供しています。これらのシステムのいくつかは、IPネットワーク上で動作しているか、互いに通信することができるユーザの組を拡張するためにIPネットワークとインターフェースされます。我々は、彼らがインターネットの他の部分への遷移として機能していないので、クローズドIPネットワーク、またはドメインのいずれかとし、これらのシステムの少なくともサブセットを考慮することができます。
The potential integration of LMR talk groups with IP multicast is an open issue. LMR talk groups are established in a static manner with man-in-the-loop participation in their establishment and teardown. The seamless integration of these talk groups with multicast group addresses is a feature that has not been discussed in open forums.
IPマルチキャストとLMRのトークグループの潜在的な統合は、未解決の問題です。 LMRのトークグループは、彼らの確立とティアダウンの男・イン・ザ・ループ参加を静的に設定されています。マルチキャストグループアドレスを持つこれらのトークグループのシームレスな統合は、オープンフォーラムで議論されていない機能です。
The IEEE 802.1d standard specifies fields and capabilities for a number of features. In Section 4.3.2 above, we discussed its use for defining a Prioritization field. The 802.1d standard also covers the topic of filtering MAC layer multicast frames.
IEEE 802.1D準拠の標準は、機能の数のフィールドや能力を指定します。上記4.3.2項では、優先順位付けのフィールドを定義するためのその使用を議論しました。 802.1D規格は、MAC層マルチキャストフレームをフィルタリングのトピックをカバーしています。
One of the concerns about multicast is that broadcast storms can arise and generate a denial of service against other users/nodes. Some administrators purposely filter out multicast frames in cases where the subnetwork resource is relatively small (e.g., 802.11 networks). Operational considerations with respect to ETS may wish to consider doing this on an as-needed basis, balancing the conditions of the network with the perceived need for multicast. In cases where filtering out multicast can be activated dynamically, COPS may be a good means of providing consistent domain-wide policy control.
マルチキャストの懸念の一つは、ブロードキャストストームが発生すると、他のユーザ/ノードに対するサービス拒否を発生させることができるということです。いくつかの管理者が意図的にサブネットワークリソースが比較的小さい場合（例えば、802.11ネットワーク）内のマルチキャストフレームを除外する。 ETSに関する運用の考慮事項は、マルチキャストのための認知必要性とネットワークの条件のバランスをとる、など必要に応じてこれを行うことを検討することを望むかもしれません。動的に活性化することができるマルチキャストフィルタリングの場合において、COPSは、一貫性のドメイン全体のポリシー制御を提供する優れた手段であってもよいです。
If a service is being offered to explicitly support ETS, then it would seem reasonable that discovery of the service may be of benefit. For example, if a domain has a subset of servers that recognize ETS-labeled traffic, then dynamic discovery of where these servers are (or even if they exist) would be more beneficial than relying on statically configured information.
サービスは、明示的にETSをサポートするために提供されている場合、サービスの発見が有益であり得ることを合理的と思われます。ドメインは、ETS-標識されたトラフィックを認識するサーバのサブセットを有する場合、例えば、これらのサーバである（またはそれらが存在する場合であっても）ここでの動的な発見は、静的に設定された情報を頼るよりも有益であろう。
The Service Location Protocol (SLP) [rfc2608] is designed to provide information about the existence, location, and configuration of networked services. In many cases, the name of the host supporting the desired service is needed to be known a priori in order for users to access it. SLP eliminates this requirement by using a descriptive model that identifies the service. Based on this description, SLP then resolves the network address of the service and returns this information to the requester. An interesting design element of SLP is that it assumes that the protocol is run over a collection of nodes that are under the control of a single administrative authority. This model follows the scope of this framework document. However, the scope of SLP may be better suited for parts of an enterprise network versus an entire domain.
サービスロケーションプロトコル（SLP）[RFC2608]はネットワークサービスの存在、位置、および構成に関する情報を提供するように設計されています。多くの場合、所望のサービスをサポートするホストの名前がそれにアクセスするユーザーのために事前に知らする必要があります。 SLPは、サービスを識別する記述的モデルを用いて、この要件を排除します。この説明に基づいて、SLPは、サービスのネットワークアドレスを解決し、要求者にこの情報を返します。 SLPの興味深い設計要素は、プロトコルは、単一の管理権限の制御下にあるノードのコレクション上で実行されていることを前提としていることです。このモデルは、この枠組み文書の範囲に従います。しかし、SLPの範囲は、ドメイン全体に対する企業ネットワークの部品に適してもよいです。
Anycasting [rfc1546] is another means of discovering nodes that support a given service. Interdomain anycast addresses, propagated by BGP, represent anycast in a wide scope and have been used by multiple root servers for a while. Anycast can also be realized in a more constrained and limited scope (i.e., solely within a domain or subnet), and as in the case of multicast, it may not be supported.
[rfc1546]をエニーキャストする所定のサービスをサポートしているノードを発見する別の手段です。 BGPによって伝播ドメイン間のエニーキャストアドレスは、広い範囲でエニーキャストを代表し、しばらくの間、複数のルートサーバで使用されています。エニーキャストはまた、より多くの制約及び制限された範囲（すなわち、単独ドメイン又はサブネット内の）で実現することができ、およびマルチキャストの場合のように、それはサポートされなくてもよいです。
[rfc4291] covers the topic of anycast addresses for IPv6. Unlike SLP, users/applications must know the anycast address associated with the target service. In addition, responses to multiple requests to the anycast address may come from different servers. Lack of response (not due to connectivity problems) correlates to the discovery that a target service is not available. Detailed tradeoffs between this approach and SLP are outside the scope of this framework document.
[RFC4291]はIPv6のエニーキャストアドレスのトピックをカバーしています。 SLPとは異なり、ユーザー/アプリケーションは、ターゲット・サービスに関連したエニーキャストアドレスを知っている必要があります。また、エニーキャストアドレスに複数の要求に対する応答が異なるサーバから来るかもしれません。 （接続の問題が原因ではない）応答の欠如は、ターゲット・サービスが利用できない発見に相関します。このアプローチとSLPとの間の詳細なトレードオフは、このフレームワーク文書の範囲外です。
The Dynamic Delegation Discovery System (DDDS) is used to implement a binding of strings to data in order to support dynamically configured delegation systems [rfc3401]. The DDDS functions by mapping some unique string to data stored within a DDDS Database by iteratively applying string transformation rules until a terminal condition is reached. The potential then exists that a client could specify a set of known tags (e.g., RetrieveMail:Pop3) that would identify/discover the appropriate server with which it can communicate.
ダイナミックな委譲発見システム（DDDS）は動的に設定委譲システム[rfc3401]をサポートするためにデータへの文字列の結合を実現するために使用されます。 DDDS機能端末状態が達成されるまで反復文字列変換規則を適用することによって、DDDSデータベース内に格納されたデータにいくつかのユニークな文字列をマッピングすることによって。 /識別が通信可能な適切なサーバを発見するであろう：電位は、クライアントが既知のタグ（POP3例えば、RetrieveMail）のセットを指定することができることに存在します。
There are a number of examples where Diffserv [rfc2474] has been deployed strictly within a domain, with no extension of service to neighboring domains. Various reasons exist for Diffserv not being widely deployed in an inter-domain context, including ones rooted in the complexity and problems in supporting the security requirements for Diffserv codepoints. An extensive discussion on Diffserv deployment is outside the scope of this document.
Diffservの[RFC2474]は、隣接ドメインへのサービスのない拡張で、ドメイン内に厳密に展開された例は多数あります。 Diffservの広く複雑に根ざしたものとDiffservコードポイントのセキュリティ要件をサポートする問題を含む、ドメイン間コンテキストに配備されていないため、様々な理由が存在します。 Diffservの展開について広範な議論は、この文書の範囲外です。
[Baker] presents common examples of various codepoints used for well-known applications. The document does not recommend these associations as being standard or fixed. Rather, the examples in [Baker] provide a reference point for known deployments that can act as a guide for other network administrators.
【ベーカー】周知の用途に使用される種々のコードポイントの一般的な例を提示します。文書は、標準または固定されているように、これらの関連付けを推奨していません。むしろ、[ベーカー]の例では、他のネットワーク管理者のためのガイドとして作用することができる公知の展開のための基準点を提供します。
An argument can be made that Diffserv, with its existing codepoint specifications of Assured Forwarding (AF) and Expedited Forwarding (EF), goes beyond what would be needed to support ETS within a domain. By this we mean that the complexity in terms of maintenance and support of AF or EF may exceed or cause undue burden on the management resources of a domain. Given this possibility, users or network administrators may wish to determine if various queuing mechanisms, like class-based weighted fair queuing, is sufficient to support ETS flows through a domain. Note, as we stated earlier in Section 2, over-provisioning is another option to consider. We assume that if the reader is considering something like Diffserv, then it has been determined that over-provisioning is not a viable option given their individual needs or capabilities.
引数が保証転送（AF）と緊急転送（EF）の既存のコードポイントの仕様に、Diffservのことを行うことができ、ドメイン内のETSをサポートするために必要とされるものを超えています。これにより、我々は、AFやEFのメンテナンスやサポートの面で複雑さを超えたり、ドメインの経営資源に過度の負担を引き起こす可能性があることを意味します。この可能性を考えると、ユーザーやネットワーク管理者は、クラスベース均等化キューイングのように、様々なキューイングメカニズムかどうかを確認したい場合があり、ETSは、ドメインを介してフローをサポートするのに十分です。私たちは第2節で先に述べたように、注意してください、オーバープロビジョニングを検討する別のオプションです。私たちは、読者がDiffservのようなものを検討しているならば、オーバープロビジョニングは、個々のニーズや能力を与えられた現実的な選択肢ではないと判断されていることを前提としています。
Services used to offer better or best available service for a particular set of users (in the case of this document, ETS users) are prime targets for security attacks or simple misuse. Hence, administrators that choose to incorporate additional protocols/services to support ETS are strongly encouraged to consider new policies to address the added potential of security attacks. These policies, and any additional security measures, should be considered independent of any mechanism or equipment that restricts access to the administrative domain.
ユーザーの特定のセットのためのよりよいまたは利用可能な最善のサービスを提供するために使用されるサービス（この文書の場合は、ETSのユーザー）はセキュリティ攻撃や簡単な誤用のための主要な標的です。したがって、ETSをサポートするために追加のプロトコル/サービスを組み込むことを選択し、管理者が強くセキュリティ攻撃の追加可能性に対処するための新たな政策を検討することをお勧めします。これらのポリシー、および任意の追加のセキュリティ対策は、管理ドメインへのアクセスを制限する任意の機構や機器とは独立して考えるべきです。
Determining how authorization is accomplished is an open issue. Many times the choice is a function of the service that is deployed. One example is source addresses in an access list permitting senders to the multicast group (as described in Section 4.5). Within a single domain environment, cases can be found where network administrators tend to find this approach acceptable. However, other services may require more stringent measures that employ detailed credentials, and possibly multiple levels of access and authentication. Ease of use, deployment, scalability, and susceptibility to security breach all play a role in determining authorization schemas. The potential is that accomplishing this for only a single domain may be easier than at the inter-domain scope, if only in terms of scalability and trust.
認証が行われる方法を決定することは、未解決の問題です。何度選択が展開されているサービスの機能です。一例では（セクション4.5で説明したように）マルチキャストグループへの送信者のアクセス許可リストに送信元アドレスです。ネットワーク管理者は、許容可能なこのアプローチを見つけるために傾向がある場所を単一のドメイン環境では、例を見つけることができます。しかし、他のサービスは、詳細な資格情報を使用し、より厳しい措置、およびアクセスと認証の可能性が複数のレベルを必要とするかもしれません。セキュリティ侵害への使用、展開、拡張性、および感受性のしやすさは、すべての許可スキーマを決定する際に役割を果たしています。可能性は、単一のドメインに対してこれを達成する場合にのみ、スケーラビリティと信頼の面で、ドメイン間の範囲でより容易になることです。
This document has presented a number of protocols and complementary technologies that can be used to support ETS users. Their selection is dictated by the fact that all or significant portions of the protocols can be operated and controlled within a single administrative domain. It is this reason why other protocols, like those under current development in the Next Steps in Signaling (NSIS) working group, have not been discussed.
この文書では、ETSのユーザーをサポートするために使用できるプロトコルと補完的な技術の数を提示しました。彼らの選択は、プロトコルの全てまたはかなりの部分は、単一の管理ドメイン内で動作し、制御することができるという事実によって決定されます。これは、他のプロトコルは、シグナリング（NSIS）ワーキンググループにおける次のステップでは、現在開発中のものと同様、議論されていない理由はこのような理由です。
By listing a variety of efforts in this document, we avoid taking on the role of "king maker" and at the same time indirectly point out that a variety of solutions exist in support of ETS. These solutions may involve QoS, traffic engineering, or simply protection against detrimental conditions (e.g., spikes in traffic load). Again, the choice is up to the reader.
このドキュメントの努力の多様性をリストすることによって、私たちは「キングメーカー」の役割を引き受けると同時に、間接的に様々なソリューションは、ETSのサポートに存在することを指摘することは避けてください。これらのソリューションは、単純なQoS、トラフィック・エンジニアリング、または有害な条件に対する保護を伴うこと（例えば、トラフィック負荷の急増）。ここでも、選択は読者次第です。
Thanks to Ran Atkinson, Scott Bradner, Jon Peterson, and Kimberly King for comments and suggestions on this document.
このドキュメントに関するコメントや提案のための蘭アトキンソン、スコット・ブラッドナー、ジョンピーターソン、およびキンバリー王に感謝します。
[rfc4375] Carlberg, K., "Emergency Telecommunications Services (ETS) Requirements for a Single Administrative Domain", RFC 4375, January 2006.
[rfc4375]カールバーグ氏、K.、 "単一の管理ドメインのための緊急通信サービス（ETS）要件"、RFC 4375、2006年1月。
[Baker] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, August 2006.
[ベーカー] Babiarz、J.、チャン、K.、およびF.ベイカー、 "DiffServのサービスクラスの設定時の注意事項"、RFC 4594、2006年8月。
[docsis] "Data-Over-Cable Service Interface Specifications: Cable Modem to Customer Premise Equipment Interface Specification SP-CMCI-I07-020301", DOCSIS, March 2002, http://www.cablemodem.com.
[DOCSIS] "データオーバーケーブルサービスインターフェイス仕様：顧客宅内機器インタフェース仕様SP-CMCI-I07-020301にケーブルモデム"、DOCSIS、2002年3月、http://www.cablemodem.com。
[iso15802] "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Common specifications - Part 3: Media Access Control (MAC) Bridges: Revision. This is a revision of ISO/IEC 10038: 1993, 802.1j-1992 and 802.6k-1992. It incorporates P802.11c, P802.1p and P802.12e." ISO/IEC 15802-3:1998"
[iso15802]「情報技術 - 電気通信及びシステム間の情報交換 - 地方とメトロポリタンエリアネットワーク - 共通仕様 - 第3部：メディアアクセス制御（MAC）が橋：1993、802.1j：リビジョンこれは、ISO / IEC 10038の改訂版であります-1992と802.6k-1992。それはP802.11c、P802.1pとP802.12eが組み込まれています。」 ISO / IEC 15802-3：1998"
[rfc1546] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993.
[rfc1546]ウズラ、C.、メンデス、T.、およびW.ミリケン、 "ホストエニーキャストサービス"、RFC 1546、1993年11月。
[rfc2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131] Droms、R.、 "動的ホスト構成プロトコル"、RFC 2131、1997年3月。
[rfc2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]ブレーデン、R.、エド、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1の機能的な仕様"。、RFC 2205、9月1997。
[rfc2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474]ニコルズ、K.、ブレイク、S.、ベイカー、F.、およびD.黒、 "IPv4とIPv6ヘッダーとの差別化されたサービス分野（DS分野）の定義"、RFC 2474、1998年12月。
[rfc2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999.
[RFC2608]ガットマン、E.、パーキンス、C.、Veizades、J.、およびM.日、 "サービスロケーションプロトコル、バージョン2"、RFC 2608、1999年6月。
[rfc2748] Durham, D., Ed., Boyle, J., Cohen, R., Herzog, S., Rajan, R., and A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000.
[rfc2748]ダラム、D.、編、ボイル、J.、コーエン、R.、ヘルツォーク、S.、ラジャン、R.、およびA. Sastry、 "COPS（共通オープンポリシーサービス）プロトコル"、RFC 2748 、2000年1月。
[rfc2749] Herzog, S., Ed., Boyle, J., Cohen, R., Durham, D., Rajan, R., and A. Sastry, "COPS usage for RSVP", RFC 2749, January 2000.
[rfc2749]ヘルツォーク、S.編、ボイル、J.、コーエン、R.、ダラム、D.、ラジャン、R.、およびA. Sastryは、RFC 2749、2000年1月 "RSVPの使用をCOPS"。
[rfc2750] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000.
[rfc2750]ヘルツォーク、S.、 "ポリシー制御のためのRSVP拡張機能"、RFC 2750、2000年1月。
[rfc3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]ローゼン、E.、Viswanathanの、A.、およびR. Callon、 "マルチプロトコルラベルスイッチングアーキテクチャ"、RFC 3031、2001年1月。
[rfc3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002.
[rfc3270]ルFaucheur、F.、ウー、L.、デイビー、B.、Davari、S.、Vaananen、P.、クリシュナン、R.、シュヴァル、P.、およびJ. Heinanen、「マルチプロトコルラベルスイッチング（MPLS）差別化サービスのサポート」、RFC 3270、2002年5月。
[rfc3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、バーガー、L.、ガン、D.、李、T.、スリニヴァサン、V.、およびG.ツバメ、 "RSVP-TE：LSPトンネルのためのRSVPの拡張"、RFC 3209年12月2001。
[rfc3344] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[RFC3344]パーキンス、C.、エド。、 "IPv4のIPモビリティサポート"、RFC 3344、2002年8月。
[rfc3084] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, K., Herzog, S., Reichmeyer, F., Yavatkar, R., and A. Smith, "COPS Usage for Policy Provisioning (COPS-PR)", RFC 3084, March 2001.
[rfc3084]チャン、K.、Seligson、J.、ダラム、D.、ガイ、S.、McCloghrie、K.、ヘルツォーク、S.、Reichmeyer、F.、Yavatkar、R.、およびA.スミス、「COPSポリシープロビジョニング（COPS-PR）」、RFC 3084、2001年3月のために使用。
[rfc3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401 October 2002.
[rfc3401] Mealling、M.、 "ダイナミックな委譲発見システム（DDDS）第一部：総合DDDS"、RFC 3401 2002年10月。
[rfc3535] Schoenwaelder, J., "Overview of the 2002 IAB Network Management Workshop", RFC 3535, May 2003.
[rfc3535] Schoenwaelder、J.、RFC 3535、2003年5月 "2002 IABネットワーク管理ワークショップの概要" を参照してください。
[rfc3569] Bhattacharyya, S., Ed., "An Overview of Source-Specific Multicast (SSM)", RFC 3569, July 2003.
[RFC3569]バッタチャリヤ、S.、エド。、 "ソース固有マルチキャスト（SSM）の概要"、RFC 3569、2003年7月。
[rfc3618] Fenner, B., Ed., and D. Meyer, Ed., "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003.
[rfc3618]フェナー、B.、エド。、およびD.マイヤー、エド。、 "は、Multicast Source Discovery Protocol（MSDP）"、RFC 3618、2003年10月。
[rfc4190] Carlberg, K., Brown, I., and C. Beard, "Framework for Supporting Emergency Telecommunications Service (ETS) in IP Telephony", RFC 4190, November 2005.
[rfc4190]カールバーグ氏、K.、ブラウン、I.、およびC.ベアード、 "IPテレフォニーで緊急通信サービス（ETS）をサポートするためのフレームワーク"、RFC 4190、2005年11月。
[rfc4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] HindenとR.とS.デアリング、 "IPバージョン6アドレッシング体系"、RFC 4291、2006年2月。
[rfc4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4601]フェナー、B.、ハンドリー、M.、ホルブルック、H.、およびI. Kouvelas、 "プロトコル独立マルチキャスト - スパースモード（PIM-SM）：プロトコル仕様（改訂）"、RFC 4601、2006年8月。
Author's Address
著者のアドレス
Ken Carlberg G11 123a Versailles Circle Baltimore, MD USA
ケン・カールバーグG11 123Aベルサイユサークルボルチモア、MD USA
EMail: carlberg@g11.org.uk
メールアドレス：carlberg@g11.org.uk
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。