[要約] RFC 4958は、単一の管理ドメイン内で緊急通信サービス（ETS）をサポートするためのフレームワークを提供するものです。その目的は、緊急通信サービスの設計と実装に関するガイドラインを提供し、効果的な緊急通信サービスの提供を支援することです。
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）The IETF Trust（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のフレームワークドキュメントの別の例は[RFC4190]で、IPテレフォニー内のETSのサポートに焦点を当てています。この場合、焦点は特定のアプリケーションであり、そのフローは複数の自律ドメインにまたがる可能性があります。このドキュメントでは、[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.
上記の（a）から（c）の最初の声明の結果として、次のように、単一および領域間のケースを区別する追加の観察を行うことができます。
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.
上記は包括的な違いのセットではありませんが、単一の管理ドメインのより制約されたシナリオに努力を集中したい理由を提供する理由を提供します。
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.
このドキュメントは、これらのポジションのいずれかを他方よりも提唱していません。著者は、ネットワーク管理者/オペレーターが、ドメイン内で適用されるスパイクとQoSメカニズムの過剰プロビジョニングと、別のドメイン（例：顧客とそのISP）へのアクセスリンクとの間のコスト分析を実行する必要があることを主張しています。この分析は、管理ドメインのポリシーと要件を調べることに加えて、ドメイン内でETをどのようにサポートするか（または）を決定するための鍵である必要があります。
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.
このフレームワークドキュメントでは、[RFC4375]は、ドメイン内のETSをサポートする上で役割を果たすことができるエンジニアリング作業またはプロトコルの既存の領域を議論するための基準点として使用しています。これらの領域とプロトコルの議論は、特定のドメイン内に存在するという期待と混同されるべきではありません。むしろ、以下のセクション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メーリングリストとワーキンググループミーティングでの議論のトピックの1つは、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）プロトコルを使用することです。MIPは、モバイルホストが1つのサブネットワークから別のサブネットワークに移動しながら、同じ安定したIPアドレスをグローバルなアンカーポイントに登録したままにするため、アプリケーション透明モビリティの尺度を提供します。ただし、この機能が常に利用可能であるとは限りません。いずれにせよ、それが使用されている場合、少なくともモバイルホストとの間で運命づけられたパケットの一部は、ホームネットワークを通過します。
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]は、MPLを使用して差別化されたサービスをサポートする方法を説明しています。RFCは、3ビットEXP（実験）フィールドの使用について説明して、パケットに適用するPERホップ動作（PHB）を伝えます。後のセクションで見るように、この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]に及ぶ予約されたリソースのパスを設定するためのエンドツーエンドのシグナリング機能の1つでした。現在、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への拡張は定義されており、マルチプロトコルラベルスイッチング（MPLS）でドメイン内標識スイッチドパス（LSP）を確立できるようにします。
[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.
もう1つの重要な観察は、主要なベンダールーターが現在、ネットワークおよび輸送層への分類のためにフィールドの調査を制限していることです。これは、アプリケーションレイヤーラベルがルーター/スイッチによってほとんど無視される可能性が高いことを意味します。
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を使用したCOPの使用を明確にします。COPのクライアントタイプ、コンテキストオブジェクト、および決定オブジェクトを指定します。したがって、RSVPの予約がPEPによって受信されると、PEPはポリシーに基づいてそれを受け入れるか拒否するかどうかを決定します。このポリシー情報は、RSVPパスメッセージの受信のアプリオリを保存することも、オンデマンドベースで取得することもできます。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は、その設計に関する使用不足と懸念のために歴史的であると宣言されるべき候補プロトコルとして議論されたことに注意する必要があります。将来的には、警官の設計が変化する可能性があり、オペレーターの懸念に対処することができますが、そのまたは他の可能性に関する推測は、この文書の範囲を超えています。
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.
これは、「下」と見なされる作業の一般化であり、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.1pは、後にIEEE 802.1dの改訂に組み込まれ、この新しいタグ[ISO15802]の優先順位付けフィールドを定義しました。これは8レベルの優先度で構成され、最優先度は7の値です。ベンダーは、優先度のコードポイントごとにキューを選択するか、いくつかのコードポイントを単一のキューに集約できます。
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 CodePointsなど）をサポートするために使用できるIPヘッダーのビットは、802.1pの優先順位付けビットにマッピングできます。このマッピングは、802.1pフィールドとIP TOSビットの間に1対1の方法で、またはIPヘッダーのDiffServフィールド全体を考慮した場合、集約的な方法で実現できます。どちらの場合でも、ビットが不足しているため、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ビットの間にマッピングを提供しています。これは、RSVPのシグナルを802.1pの優先フィールドで提供される低レベルのインバンドシグナル伝達と統合することに加えています。
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」と呼ばれるものを提供します。802.1pの優先度コードポイントの値は、エッジで実現されます。MACペイロードが上層（IPなど）に渡されるか、フレームリレーなどの他の物理ネットワークに架かるためです。これらのアクションのいずれかが、レイヤー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つの動作モードがありました。1つは、「送信前に聞く」という古典的な衝突検出スキーマに基づいた分散調整関数（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 kbから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.
1.0から1.1のDOCSIS仕様の進化により、最善の努力以外のサービスをサポートするために変更がもたらされました。802.1Dプロトコルが優先フィールドを追加した場合、変更の1つが間接的に追加されました。これは、DOCSIS 1.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仕様は、ベンダーがトラフィックの分類、ポリシング、スケジューリングを実装する方法を指定していないことに注意することが重要です。したがって、オペレーターは、ケーブルモデム終了システム（CMT）およびエッジルーターのメカニズムに依存して、DOCSIS 1.1の追加された仕様を間接的または直接活用する必要があります。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の使用が含まれます。ただし、MPLの複雑さは、ネットワークでの展開前に考慮に入れる必要があります。
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マルチキャストの値は、同じデータグラムを複数の受信機に送信する際にリソースを効率的に使用することです。マルチキャストの強みと懸念に関する広範な議論は、このドキュメントの範囲外です。ただし、マルチキャストは、Land Mobile Radio（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.
LMRトークグループとIPマルチキャストの潜在的な統合は、未解決の問題です。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.
マルチキャストに関する懸念の1つは、ブロードキャストストームが発生し、他のユーザー/ノードに対するサービスの拒否を生み出す可能性があることです。一部の管理者は、サブネットワークリソースが比較的小さい場合（たとえば、802.11ネットワーク）の場合、意図的にマルチキャストフレームを除外します。ETSに関する運用上の考慮事項は、ネットワークの条件とマルチキャストの必要性とのバランスをとることを検討することを検討したい場合があります。マルチキャストを動的にアクティブにすることができる場合、COPは一貫したドメイン全体のポリシー制御を提供する良い手段かもしれません。
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.
AnyCasting [RFC1546]は、特定のサービスをサポートするノードを発見するもう1つの手段です。BGPによって伝播されたドメインインタードメインAnycastアドレスは、幅広い範囲でAnycastを表し、しばらく複数のルートサーバーで使用されてきました。Anycastは、より制約された限られた範囲（つまり、ドメインまたはサブネット内のみ）で実現することもでき、マルチキャストの場合と同様に、サポートされない場合があります。
[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のAnycastアドレスのトピックをカバーしています。SLPとは異なり、ユーザー/アプリケーションは、ターゲットサービスに関連付けられているAnycastアドレスを知っている必要があります。さらに、AnyCastアドレスへの複数のリクエストへの応答は、異なるサーバーから得られる場合があります。応答の欠如（接続性の問題によるものではなく）は、ターゲットサービスが利用できないという発見と相関しています。このアプローチと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.
動的に構成された委任システム[RFC3401]をサポートするために、動的委任ディスカバリーシステム（DDDS）を使用してデータへの文字列の結合を実装します。DDDSは、端末条件に達するまで文字列変換ルールを反復的に適用することにより、DDDSデータベース内に保存されたデータにいくつかの一意の文字列をマッピングすることにより機能します。次に、クライアントが、通信できる適切なサーバーを識別/発見する一連の既知のタグ（例：再審査：POP3）を指定できる可能性が存在します。
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 CodePointsのセキュリティ要件をサポートする際の複雑さと問題に根ざしたものを含む、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.
[Baker]は、よく知られているアプリケーションに使用されるさまざまなコードポイントの一般的な例を示しています。このドキュメントでは、これらの関連付けは標準または修正として推奨されません。むしろ、[Baker]の例は、他のネットワーク管理者のガイドとして機能できる既知の展開の基準点を提供します。
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）の既存のCodePoint仕様により、ドメイン内のETSをサポートするために必要なものを超えるDiffServがdiffservを行うことができます。これにより、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.
認可がどのように達成されるかを判断することは、未解決の問題です。多くの場合、選択は展開されるサービスの関数です。1つの例は、送信者をマルチキャストグループに許可するアクセスリストのソースアドレスです（セクション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.
この文書に関するコメントと提案について、Ran Atkinson、Scott Bradner、Jon Peterson、Kimberly Kingに感謝します。
[rfc4375] Carlberg, K., "Emergency Telecommunications Services (ETS) Requirements for a Single Administrative Domain", RFC 4375, January 2006.
[RFC4375] Carlberg、K。、「単一の管理ドメインの緊急通信サービス（ETS）要件」、RFC 4375、2006年1月。
[Baker] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, August 2006.
[Baker] Babiarz、J.、Chan、K。、およびF. Baker、「Diffserv Service Classeの構成ガイドライン」、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）ブリッジ：改訂。これはISO/IEC 10038：1993、802.1Jの改訂です-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] Partridge、C.、Mendez、T。、およびW. Milliken、「Host Anycasting Service」、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] Braden、R.、Ed。、Zhang、L.、Berson、S.、Herzog、S.、およびS. Jamin、「リソース予約プロトコル（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] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「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] Guttman、E.、Perkins、C.、Veizades、J。、およびM. Day、「サービスロケーションプロトコル、バージョン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] Durham、D.、Ed。、Boyle、J.、Cohen、R.、Herzog、S.、Rajan、R.、およびA. Sastry、「The Cops（Common Open Policy Service）Protocol」、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] Herzog、S.、Ed。、Boyle、J.、Cohen、R.、Durham、D.、Rajan、R.、およびA. Sastry、「RSVPのCops使用」、RFC 2749、2000年1月。
[rfc2750] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000.
[RFC2750] Herzog、S。、「ポリシー管理のためのRSVP拡張」、RFC 2750、2000年1月。
[rfc3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocolラベルスイッチングアーキテクチャ」、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] Le Faucheur、F.、Wu、L.、Davie、B.、Davari、S.、Vaananen、P.、Krishnan、R.、Cheval、P。、およびJ. Heinanen、「Multi-Protocol Label Switching」（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.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：LSPトンネルのRSVPへの拡張」、RFC 3209、12月2001年。
[rfc3344] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[RFC3344] Perkins、C.、ed。、「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] Chan、K.、Seligson、J.、Durham、D.、Gai、S.、McCloghrie、K.、Herzog、S.、Reichmeyer、F.、Yavatkar、R。、およびA. Smith、「警官」ポリシープロビジョニングの使用（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）パート1：包括的なDDDS」、RFC 3401 2002年10月。
[rfc3535] Schoenwaelder, J., "Overview of the 2002 IAB Network Management Workshop", RFC 3535, May 2003.
[RFC3535] Schoenwaelder、J。、「2002年のIABネットワーク管理ワークショップの概要」、RFC 3535、2003年5月。
[rfc3569] Bhattacharyya, S., Ed., "An Overview of Source-Specific Multicast (SSM)", RFC 3569, July 2003.
[RFC3569] Bhattacharyya、S.、ed。、「ソース固有のマルチキャスト（SSM）の概要」、RFC 3569、2003年7月。
[rfc3618] Fenner, B., Ed., and D. Meyer, Ed., "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003.
[RFC3618] Fenner、B.、ed。、およびD. Meyer、ed。、「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] Carlberg、K.、Brown、I。、およびC. Beard、「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. Deering、「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] Fenner、B.、Handley、M.、Holbrook、H.、およびI. Kouvelas、 "Protocol Independent Multicast -Sparse Mode（PIM -SM）：Protocol Specification（改訂）、RFC 4601、2006年8月。
Author's Address
著者の連絡先
Ken Carlberg G11 123a Versailles Circle Baltimore, MD USA
Ken Carlberg G11 123a Versailles Circle Baltimore、MD USA
EMail: carlberg@g11.org.uk
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。