Internet Engineering Task Force (IETF) F. Le Faucheur
Request for Comments: 6401 J. Polk
Category: Standards Track Cisco
ISSN: 2070-1721 K. Carlberg
G11
October 2011
RSVP Extensions for Admission Priority
Abstract
抽象
Some applications require the ability to provide an elevated probability of session establishment to specific sessions in times of network congestion. When supported over the Internet Protocol suite, this may be facilitated through a network-layer admission control solution that supports prioritized access to resources (e.g., bandwidth). These resources may be explicitly set aside for prioritized sessions, or may be shared with other sessions. This document specifies extensions to the Resource reSerVation Protocol (RSVP) that can be used to support such an admission priority capability at the network layer.
一部のアプリケーションは、ネットワークの輻輳時に特定のセッションにセッション確立の高い確率を提供する能力が必要です。インターネットプロトコルスイートの上にサポートされている場合、これは、リソースへの優先アクセス（例えば、帯域幅）をサポートするネットワーク層アドミッションコントロール溶液を通して容易にすることができます。これらのリソースは、明示的に優先順位を付けたセッションのために確保されてもよいし、他のセッションと共有することができます。この文書では、ネットワーク層で、このような入場優先機能をサポートするために使用することができるリソース予約プロトコル（RSVP）への拡張を指定します。
Based on current security concerns, these extensions are intended for use in a single administrative domain.
現在の安全保障上の懸念に基づいて、これらの拡張機能は、単一の管理ドメインでの使用を目的としています。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6401.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6401で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of
この文書では、BCP 78との日に有効な（http://trustee.ietf.org/license-info）IETFドキュメントに関連IETFトラストの法律の規定に従うもの
publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本書の出版物。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Applicability Statement . . . . . . . . . . . . . . . . . . . 4
3. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
4. Overview of RSVP Extensions and Operations . . . . . . . . . . 4
4.1. Operations of Admission Priority . . . . . . . . . . . . . 6
5. New Policy Elements . . . . . . . . . . . . . . . . . . . . . 7
5.1. Admission Priority Policy Element . . . . . . . . . . . . 8
5.1.1. Admission Priority Merging Rules . . . . . . . . . . . 9
5.2. Application-Level Resource Priority Policy Element . . . . 10
5.2.1. Application-Level Resource Priority Modifying and
Merging Rules . . . . . . . . . . . . . . . . . . . . 11
5.3. Default Handling . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6.1. Use of RSVP Authentication between RSVP Neighbors . . . . 13
6.2. Use of INTEGRITY object within the POLICY_DATA Object . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . . 18
Appendix A. Examples of Bandwidth Allocation Model for
Admission Priority . . . . . . . . . . . . . . . . . 19
A.1. Admission Priority with Maximum Allocation Model (MAM) . . 19
A.2. Admission Priority with Russian Dolls Model (RDM) . . . . 23
A.3. Admission Priority with Priority Bypass Model (PrBM) . . . 26
Appendix B. Example Usages of RSVP Extensions . . . . . . . . . . 29
Some applications require the ability to provide an elevated probability of session establishment to specific sessions in times of network congestion.
一部のアプリケーションは、ネットワークの輻輳時に特定のセッションにセッション確立の高い確率を提供する能力が必要です。
Solutions to meet this requirement for elevated session establishment probability may involve session-layer capabilities prioritizing access to resources controlled by the session control function. As an example, entities involved in session control (such as SIP user agents, when the Session Initiation Protocol (SIP) [RFC3261], is the session control protocol in use) can influence their treatment of session establishment requests (such as SIP requests). This may include the ability to "queue" session establishment requests when those can not be immediately honored (in some cases with the notion of "bumping", or "displacement", of less important session establishment requests from that queue). It may include additional mechanisms such as alternate routing and exemption from certain network management controls.
高架セッション確立確率がセッション制御機能によって制御される資源へのアクセスを優先セッション層の機能を含むことができるため、この要件を満たすためのソリューション。一例として、（例えば、セッション開始プロトコル（SIP）[RFC3261]は、使用中のセッション制御プロトコルであるSIPユーザエージェント、など）のセッション制御に関与するエンティティは、（例えば、SIPリクエストのような）セッション確立要求のそれらの治療に影響を与えることができます。これは、それらがすぐに（そのキューから重要度の低いセッション確立要求の「バンピング」、または「変位」の概念といくつかのケースでは）光栄することができない「キュー」セッション確立要求への能力を備えることができます。そのような特定のネットワーク管理コントロールから代替ルーティングと免除などの追加の機構を含んでもよいです。
Solutions to meet the requirement for elevated session establishment probability may also take advantage of network-layer admission control mechanisms supporting admission priority. Networks usually have engineered capacity limits that characterize the maximum load that can be handled (say, on any given link) for a class of traffic while satisfying the quality-of-service (QoS) requirements of that traffic class. Admission priority may involve setting aside some network resources (e.g., bandwidth) out of the engineered capacity limits for the prioritized sessions only. Or alternatively, it may involve allowing the prioritized sessions to seize additional resources beyond the engineered capacity limits applied to normal sessions. This document specifies the necessary extensions to support such admission priority when network-layer admission control is performed using the Resource reSerVation Protocol (RSVP) [RFC2205].
溶液はまた、アドミッション優先度をサポートするネットワーク層アドミッション制御メカニズムを利用することができる高められたセッション確立確率の要件を満たすために。そのトラフィッククラスのサービス品質（QoS）の要件を満たしつつ、ネットワークは、通常トラフィックのクラスのための（任意のリンクで、例えば）処理できる最大負荷を特徴付ける容量制限を設計してきました。アドミッション優先順位は、優先順位セッションの操作能力の制限のうちいくつかのネットワークリソース（例えば、帯域幅）を別に設定することを含むことができます。または代わりに、それは通常のセッションに適用される設計容量の限界を超えて追加のリソースをつかむために優先順位のセッションを許可することを含むことができます。この文書では、ネットワーク層のアドミッション制御は、リソース予約プロトコル（RSVP）[RFC2205]を使用して実行されたときにそのようなアドミッション優先度をサポートするために必要な拡張機能を指定します。
[RFC3181] specifies the Signaled Preemption Priority Policy Element that can be signaled in RSVP so that network node may take into account this policy element in order to preempt some previously admitted low-priority sessions in order to make room for a newer, higher-priority session. In contrast, this document specifies new RSVP extensions to increase the probability of session establishment without preemption of existing sessions. This is achieved by engineered capacity techniques in the form of bandwidth allocation models. In particular, this document specifies two new RSVP policy elements allowing the admission priority to be conveyed inside RSVP signaling messages so that RSVP nodes can enforce a selective bandwidth admission control decision based on the session admission priority. Appendix A of this document also provides examples of bandwidth allocation models that can be used by RSVP-routers to enforce such admission priority on every link. A given reservation may be signaled with the admission priority extensions specified in the present document, with the preemption priority specified in [RFC3181], or with both.
[RFC3181]は、ネットワークノードは、新しい、より高い優先順位のための部屋を作るためにいくつかの以前に入院優先度の低いセッションを先取りするためには、アカウントにこのポリシー要素がかかる場合がありますので、RSVPに通知することができ合図先取り重点要素を指定しますセッション。これとは対照的に、このドキュメントは、既存のセッションのプリエンプションずにセッション確立の確率を高めるために、新たなRSVP拡張子を指定します。これは、帯域幅の割り当てモデルの形で設計容量技術によって達成されます。具体的には、このドキュメントは、RSVPノードは、セッション受付優先順位に基づいて、選択帯域アドミッション制御決定を適用できるように入場プライオリティがRSVPシグナリングメッセージの内部に搬送されることを可能にする二つの新しいRSVPポリシーの要素を指定します。この文書の付録Aは、また、すべてのリンク上でこのようなアドミッション優先順位を適用するRSVP-ルータによって使用することができる帯域割当モデルの例を提供します。所与の予約は[RFC3181]で指定された先取り優先順位を持つ、またはその両方で、本文書で指定されたアドミッション優先拡張でシグナリングすることができます。
This document assumes the terminology defined in [RFC2753]. For convenience, the definitions of a few key terms are repeated here:
この文書では、[RFC2753]で定義された用語を前提としています。便宜上、いくつかの重要な用語の定義は、ここでは繰り返されています。
o Policy Decision Point (PDP): The point where policy decisions are made.
Oポリシー決定ポイント（PDP）：政策決定がなされるポイント。
o Local Policy Decision Point (LPDP): The PDP local to the network element.
Oローカルポリシー決定ポイント（LPDP）：ネットワーク要素へのPDPは、ローカル。
o Policy Enforcement Point (PEP): The point where the policy decisions are actually enforced.
Oポリシー実行ポイント（PEP）：政策決定が実際に施行されているポイント。
o Policy Ignorant Node (PIN): A network element that does not explicitly support policy control using the mechanisms defined in [RFC2753].
Oポリシー無知ノード（PIN）：明示的に[RFC2753]で定義されたメカニズムを使用して、ポリシー制御をサポートしていないネットワーク要素。
A subset of RSVP messages are signaled with the Router Alert Option (RAO) ([RFC2113], [RFC2711]). The security aspects and common practices around the use of the current IP Router Alert Option and consequences on the use of IP Router Alert by applications such as RSVP are discussed in [RFC6398]. Based on those, the extensions defined in this document are intended for use within a single administrative domain. Thus, in particular, the extensions defined in this document are not intended for end-to-end use on the Internet.
RSVPメッセージのサブセットは、ルータ警告オプション（RAO）（[RFC2113]、[RFC2711]）を用いてシグナリングされます。このようRSVPなどのアプリケーションによって、IPルータアラートの使用に関する現在のIPルータアラートオプションと結果の使用の周りのセキュリティ面および共通プラクティスは、[RFC6398]で議論されています。これらに基づき、この文書で定義された拡張機能は、単一の管理ドメイン内での使用を目的としています。このように、具体的には、この文書で定義された拡張は、インターネット上のエンドツーエンドの使用を意図していません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
Let us consider the case where a session requires elevated probability of establishment, and more specifically that the preference to be granted to this session is in terms of network-layer "admission priority" (as opposed to preference granted through preemption of existing sessions). By "admission priority" we mean allowing the priority session to seize network-layer resources from the engineered capacity that has been set aside for priority sessions (and not made available to normal sessions) or, alternatively, allowing the priority session to seize additional resources beyond the engineered capacity limits applied to normal sessions.
私たちは、セッションが確立するの上昇確率を必要とし、より具体的に好みがこのセッションに付与することをネットワーク層「入場優先」（既存のセッションのプリエンプションによって付与された優先順位ではなく）の面である場合を考えます。 「入場優先度が」私たちは意味の優先順位セッションが優先セッションが追加のリソースを押収することができ、その代わりに、優先度のセッションのために確保さ（と通常のセッションでは利用できない）、またはされた設計容量からネットワーク層のリソースをつかむことを可能にすることにより通常のセッションに適用される設計容量制限を超えました。
Session establishment can be made conditional on resource-based and policy-based network-layer admission control achieved via RSVP signaling. In the case where the session control protocol is SIP, the use of RSVP-based admission control in conjunction with SIP is specified in [RFC3312].
セッションの確立は、リソースベースとRSVPシグナリングを介して達成されたポリシーベースのネットワークレイヤのアドミッション制御を条件とすることができます。セッション制御プロトコルがSIPである場合には、SIPと一緒にRSVPベースのアドミッション制御の使用は、[RFC3312]で指定されています。
Devices involved in the session establishment are expected to be aware of the application-level priority requirements of prioritized sessions. For example, considering the case where the session control protocol is SIP, the SIP user agents may be made aware of the resource priority requirements of a given session using the "Resource-Priority" header mechanism specified in [RFC4412]. The end-devices involved in the upper-layer session establishment simply need to copy the application-level resource priority requirements (e.g., as communicated in the SIP "Resource-Priority" header) inside the new RSVP Application-Level Resource Priority Policy Element defined in this document.
セッションの確立に関与デバイスは、優先順位を付け、セッションのアプリケーションレベルの優先順位の要件を認識することが期待されています。例えば、セッション制御プロトコルがSIPである場合を考慮し、SIPユーザエージェントは、「リソースプライオリティ」[RFC4412]で指定されたヘッダ・メカニズムを使用して、指定されたセッションの資源優先度の要件を認識してもよいです。上位レイヤのセッション確立に関与エンドデバイスは、単純に定義された新しいRSVPのアプリケーションレベルのリソース重点要素内のアプリケーションレベルのリソースの優先順位の要件（例えば、SIPで通信される「リソース優先」ヘッダ）をコピーする必要がありますこのドキュメントインチ
Conveying the application-level resource priority requirements inside the RSVP message allows this application-level requirement to be mapped/remapped into a different RSVP "admission priority" at a policy boundary based on the policy applicable in that policy area. In a typical model (see [RFC2753]) where PDPs control PEPs at the periphery of the policy area (e.g., on the first hop router), PDPs would interpret the RSVP Application-Level Resource Priority Policy Element and map the requirement of the prioritized session into an RSVP "admission priority" level. Then, PDPs would convey this information inside the new Admission Priority Policy Element defined in this document. This way, the RSVP admission priority can be communicated to downstream PEPs (i.e., RSVP routers) of the same policy domain that have LPDPs but no controlling PDP. In turn, this means the necessary RSVP Admission priority can be enforced at every RSVP hop, including all the (possibly many) hops that do not have any understanding of application-level resource priority semantics. It is not expected that the RSVP Application-Level Resource Priority Header Policy Element would be taken into account at RSVP hops within a given policy area. It is expected to be used at policy area boundaries only in order to set/reset the RSVP Admission Priority Policy Element.
RSVPメッセージ内のアプリケーションレベル資源優先度の要件を搬送することは、このアプリケーション・レベルの要件は、そのポリシー領域に適用可能なポリシーに基づくポリシーの境界で異なるRSVP「入場優先」に再マッピング/マッピングすることを可能にします。典型的なモデル（[RFC2753]を参照）（最初のホップルータ上など、）政策領域の周辺部でのPDP制御のPEPでは、PDPはRSVPのアプリケーションレベルのリソースプライオリティポリシー要素を解釈し、優先順位付けの要件をマッピングしますRSVP「入場優先」レベルにセッション。次に、PDPは、この文書で定義された新しいアドミッション重点要素内にこの情報を伝えるでしょう。この方法は、RSVPアドミッション優先度がLPDPsを有する同一のポリシー・ドメインが、無制御PDPの下流のPEP（すなわち、RSVPルータ）と通信することができます。ターンでは、これは優先度がアプリケーションレベルのリソース優先順位のセマンティクスのいずれかを理解していないすべての（おそらく多くの）ホップを含め、すべてのRSVPホップで適用することができ、必要なRSVPアドミッションを意味しています。 RSVPのアプリケーションレベルのリソースプライオリティヘッダーポリシー要素が与えられた政策領域内のRSVPホップで考慮されることが期待されていません。唯一のRSVPアドミッション優先権方針要素をセット/リセットするために、政策分野の境界で使用されることが期待されます。
Remapping by PDPs of the Admission Priority Policy Element from the Application-Level Resource Priority Policy Element may also be used at boundaries with other signaling protocols, such as the NSIS Signaling Layer Protocol (NSLP) for QoS Signaling [RFC5974].
アドミッション優先権方針要素の型PDPで再マッピングアプリケーションレベルのリソースプライオリティポリシー要素はまた、QoSシグナリング[RFC5974]のためのNSISシグナリング層プロトコル（NSLP）などの他のシグナリングプロトコルとの境界で使用することができるから。
As can be observed, the framework described above for mapping/ remapping application-level resource priority requirements into an RSVP admission priority can also be used together with [RFC3181] for mapping/remapping application-level resource priority requirements into an RSVP preemption priority (when preemption is indeed deemed necessary by the prioritized session handling policy). In that case, when processing the RSVP Application-Level Resource Priority Policy Element, the PDPs at policy boundaries (or between various QoS signaling protocols) can map it into an RSVP "preemption priority" information. This preemption priority information comprises a setup preemption level and a defending preemption priority level that can then be encoded inside the Preemption Priority Policy Element of [RFC3181].
観察することができるように、RSVPアドミッション優先にアプリケーションレベル資源優先度の要求を再マッピング/マッピングについて上述したフレームワークはまた、場合（RSVPプリエンプション優先にアプリケーションレベル資源優先度の要求を再マッピング/マッピングのために[RFC3181]と一緒に使用することができますプリエンプションは確かに）優先順位セッションの取扱方針によって必要と判断されます。その場合に、RSVPアプリケーションレベルリソースプライオリティポリシー要素、ポリシー境界でのPDPを処理するときに（またはプロトコルシグナリング種々のQoSとの間の）RSVP「先取り優先」情報にそれをマッピングすることができます。この先取り優先順位情報が設定プリエンプションレベルし、[RFC3181]の先取り優先権方針要素の内部に符号化することができる防御先取優先度を含みます。
Appendix B provides examples of various hypothetical policies for prioritized session handling, some of them involving admission priority, some of them involving both admission priority and preemption priority. Appendix B also identifies how the application-level resource priority needs to be mapped into RSVP policy elements by the PDPs to realize these policies.
付録Bには、優先順位セッション処理のための様々な仮想的な政策の例、入場の優先度を含む、それらのいくつか、入場優先順位とプリエンプションの優先順位の両方を含むそれらのいくつかを提供します。付録Bは、アプリケーションレベルのリソース優先順位はこれらのポリシーを実現するためのPDPによってRSVPポリシーエレメントにマッピングされる必要がある方法を特定します。
The RSVP Admission Priority Policy Element defined in this document allows admission bandwidth to be allocated preferentially to prioritized sessions. Multiple models of bandwidth allocation MAY be used to that end.
この文書で定義されたRSVPアドミッション重点要素は入場帯域幅を優先セッションに優先的に割り当てることができます。帯域幅の割り当ての複数のモデルは、その目的のために使用することができます。
A number of bandwidth allocation models have been defined in the IETF for allocation of bandwidth across different classes of traffic trunks in the context of Diffserv-aware MPLS Traffic Engineering. Those include the Maximum Allocation Model (MAM) defined in [RFC4125], the Russian Dolls Model (RDM) specified in [RFC4127], and the Maximum Allocation model with Reservation (MAR) defined in [RFC4126]. However, these same models MAY be applied for allocation of bandwidth across different levels of admission priority as defined in this document. Appendix A provides an illustration of how these bandwidth allocation models can be applied for such purposes and also introduces an additional bandwidth allocation model that we term the Priority Bypass Model (PrBM). It is important to note that the models described and illustrated in Appendix A are only informative and do not represent a recommended course of action.
帯域幅の割り当てモデルの数は、Diffservの対応のMPLSトラフィックエンジニアリングの文脈における交通トランクスの異なるクラス間の帯域幅の割り当てのためにIETFで定義されています。それらは[RFC4126]で定義された[RFC4125]で定義された最大割り当てモデル（MAM）、[RFC4127]で指定されたロシア人形モデル（RDM）、および予約（MAR）での最大配分モデルを含みます。この文書で定義されているが、これらの同じモデルアドミッション優先順位の異なるレベルにわたって帯域幅の割り当てのために適用することができます。付録Aは、これらの帯域幅の割り当てモデルは、このような目的のためにどのように適用できるかの実例を提供し、また、我々は優先順位バイパスモデル（PrBMを）用語追加の帯域幅の割り当てモデルを導入しています。付録Aに記載され、示されたモデルのみが有益であり、アクションの推奨コースを表すものではないことに注意することが重要です。
We can see in these examples how the RSVP Admission Priority can be used by RSVP routers to influence their admission control decision (for example, by determining which bandwidth pool is to be used by RSVP for performing its bandwidth allocation) and therefore to increase the probability of reservation establishment. In turn, this increases the probability of application-level session establishment for the corresponding session.
私たちは、RSVPアドミッション優先順位は、（例えば、帯域幅プールは、その帯域幅の割り当てを行うためにRSVPが使用するかを決定することによって）自分のアドミッション制御の決定に影響を与えるためにRSVPルータで使用することができますどのようにこれらの例で見ることができるので、確率を高めるために予約成立の。今度は、これは、対応するセッションのためのアプリケーションレベルのセッション確立の可能性を増大させます。
The Framework document for policy-based admission control [RFC2753] describes the various components that participate in policy decision making (i.e., PDP, PEP, and LPDP).
ポリシーベースのアドミッション制御のためのフレームワークドキュメント[RFC2753]は、ポリシーの意思決定（即ち、PDP、PEP、及びLPDP）に関与する様々な構成要素を説明しています。
As described in Section 4 of the present document, the Application-Level Resource Priority Policy Element and the Admission Priority Policy Element serve different roles in this framework:
現在のドキュメントのセクション4で説明したように、アプリケーションレベルのリソースプライオリティポリシー要素とアドミッション優先権方針要素は、この枠組みの中で異なる役割を果たします。
o The Application-Level Resource Priority Policy Element conveys application-level information and is processed by PDPs.
Oアプリケーションレベルのリソースプライオリティポリシー要素は、アプリケーション・レベルの情報を搬送したPDPによって処理されます。
o The emphasis of Admission Priority Policy Element is to be simple, stateless, and lightweight such that it can be processed internally within a node's LPDP. It can then be enforced internally within a node's PEP. It is set by PDPs based on processing of the Application-Level Resource Priority Policy Element.
Oアドミッション優先権方針要素の重点は、単純でステートレス、そしてそれは、ノードのLPDP内で内部的に処理することができるように軽量になることです。これは、そのノードのPEP内で内部的に強制することができます。これは、アプリケーションレベルのリソースプライオリティポリシー要素の処理に基づいたPDPによって設定されています。
[RFC2750] defines extensions for supporting generic policy-based admission control in RSVP. These extensions include the standard format of POLICY_DATA objects and a description of RSVP handling of policy events.
[RFC2750]はRSVPに汎用ポリシーベースのアドミッション制御をサポートするための拡張機能を定義します。これらの拡張機能は、POLICY_DATAオブジェクトの標準フォーマットとポリシーイベントのRSVP処理の記述が含まれています。
The POLICY_DATA object contains one or more policy elements, each representing a different (and perhaps orthogonal) policy. As an example, [RFC3181] specifies the Preemption Priority Policy Element. This document defines two new policy elements called:
POLICY_DATAオブジェクトは、1つまたは複数のポリシーエレメント、異なる（そしておそらく直交）ポリシーを表すそれぞれを含有します。例として、[RFC3181]は先取り優先権方針要素を指定します。この文書では、と呼ばれる2つの新しいポリシー要素を定義します。
o the Admission Priority Policy Element
Oアドミッション優先権方針要素
o the Application-Level Resource Priority Policy Element
アプリケーションレベルのリソース重点要素O
The format of the Admission Priority Policy Element is as shown in Figure 1:
図1に示すように、アドミッション優先権方針要素の形式は次のとおりです。
0 0 0 1 1 2 2 3
0 . . . 7 8 . . . 5 6 . . . 3 4 . . . 1
+-------------+-------------+-------------+-------------+
| Length | P-Type = ADMISSION_PRI |
+-------------+-------------+-------------+-------------+
| Flags | M. Strategy | Error Code | Reserved |
+-------------+-------------+-------------+-------------+
| Reserved |Adm. Priority|
+---------------------------+---------------------------+
Figure 1: Admission Priority Policy Element
図1：入学優先権方針要素
where:
どこ：
o Length: 16 bits
O長さ：16ビット
* Always 12. The overall length of the policy element, in bytes.
*常に12バイトのポリシー要素の全体の長さ、。
o P-Type: 16 bits
O p型：16ビット
* ADMISSION_PRI = 0x05 (see the "IANA Considerations" section).
* ADMISSION_PRIの= 0×05（ "IANAの考慮事項" を参照してください）。
o Flags: Reserved
Oフラグ：予約
* SHALL be set to zero on transmit and SHALL be ignored on reception.
*送信時にゼロに設定されるものとし、受信時に無視されなければなりません。
o Merge Strategy: 8 bits (applicable to multicast flows)
O戦略をマージ：8ビット（マルチキャストフローに適用）
* values are defined in the corresponding registry maintained by IANA (see the "IANA Considerations" section).
*値は（「IANAの考慮事項」の項を参照）IANAによって維持対応するレジストリに定義されています。
o Error code: 8 bits (applicable to multicast flows)
Oエラーコード：8ビット（マルチキャストフローに適用）
* values are defined in the corresponding registry maintained by IANA (see the "IANA Considerations" section).
*値は（「IANAの考慮事項」の項を参照）IANAによって維持対応するレジストリに定義されています。
o Reserved: 8 bits
O予約：8ビット
* SHALL be set to zero on transmit and SHALL be ignored on reception.
*送信時にゼロに設定されるものとし、受信時に無視されなければなりません。
o Reserved: 24 bits
O予約：24ビット
* SHALL be set to zero on transmit and SHALL be ignored on reception
*送信時にゼロに設定されるものとし、受信時に無視されます
o Adm. Priority (Admission Priority): 8 bits (unsigned)
Adm O優先度（入場優先）：8ビット（符号なし）
* The admission control priority of the flow, in terms of access to network bandwidth in order to provide higher probability of session completion to selected flows. Higher values represent higher priority. Bandwidth allocation models such as those described in Appendix A are to be used by the RSVP router to achieve increased probability of session establishment. The admission priority value effectively indicates which bandwidth constraint(s) of the bandwidth constraint model in use is/are applicable to admission of this RSVP reservation.
*選択されたフローにセッション終了の高い可能性を提供するためにネットワーク帯域幅へのアクセスの点で流れのアドミッション制御の優先順位。より高い値は高い優先度を表します。例えば、付録Aに記載されているような帯域割当モデルは、セッション確立の増加確率を達成するために、RSVPルータによって使用されます。アドミッション優先順位値を効果的に使用中の帯域幅制約モデルの帯域幅制限（単数または複数）/ ISこのRSVP予約の入場に適用可能であるかを示します。
Note that the Admission Priority Policy Element does NOT indicate that this RSVP reservation is to preempt any other RSVP reservation. If a priority session justifies both admission priority and preemption priority, the corresponding RSVP reservation needs to carry both an Admission Priority Policy Element and a Preemption Priority Policy Element. The Admission Priority and Preemption Priority are handled by LPDPs and PEPs as separate mechanisms. They can be used one without the other, or they can be used both in combination.
アドミッション優先権方針要素は、このRSVP予約が、他のRSVP予約を先取りすることであることを示していないことに注意してください。優先順位のセッションが入場優先順位とプリエンプションの優先順位の両方を正当化する場合は、対応するRSVP予約が入学優先権方針要素と先取り優先権方針要素の両方を運ぶために必要です。入学優先と先取り優先権は、別のメカニズムとしてLPDPsとのPEPによって処理されます。彼らは他のないものを使用することができ、またはそれらを組み合わせて、両方を使用することができます。
This section discusses alternatives for dealing with RSVP admission priority in case of merging of reservations. As merging applies to multicast, this section also applies to multicast sessions.
このセクションでは、予約の合併の場合にRSVPアドミッション優先に対処するための代替案を説明します。マージがマルチキャストに適用されるように、このセクションでは、マルチキャストセッションに適用されます。
The rules for merging Admission Priority Policy Elements are defined by the value encoded inside the Merge Strategy field in accordance with the corresponding IANA registry. This registry applies both to the Merge Strategy field of the Admission Priority Policy Element defined in the present document and to the Merge Strategy field of the Preemption Priority Policy Element defined in [RFC3181]. The registry initially contains the values already defined in [RFC3181] (see the "IANA Considerations" section).
マージアドミッション重点要素に関するルールは、対応するIANAレジストリに従ってマージ戦略フィールド内符号化された値によって定義されています。このレジストリは、現在のドキュメントにして、[RFC3181]で定義された先取り優先権方針要素のマージ戦略フィールドに定義されたアドミッション優先権方針要素のマージ戦略分野の両方に適用されます。レジストリは、最初に、すでに[RFC3181]で定義された値（「IANAの考慮事項」の項を参照）を含みます。
The only difference from [RFC3181] is that this document does not recommend a given merge strategy over the others for Admission Priority, while [RFC3181] recommends the first of these merge strategies for Preemption Priority. Note that with the Admission Priority (as is the case with the Preemption Priority), "take highest priority" translates into "take the highest numerical value".
[RFC3181]からの唯一の違いは、[RFC3181]は先取り優先権のための戦略をマージこれらの最初のを推奨していながら、この文書は、入場の優先順位のために他の人の上に与えられたマージ戦略を推奨していないことです。入場優先順位で（先取り優先権の場合のように）、「最高の優先度を取る」「最高の数値をとる」に変換することに注意してください。
The format of the Application-Level Resource Priority Policy Element is as shown in Figure 2:
図2に示すように、アプリケーションレベルのリソースプライオリティポリシー要素の形式は次のとおりです。
0 0 0 1 1 2 2 3
0 . . . 7 8 . . . 5 6 . . . 3 4 . . . 1
+-------------+-------------+-------------+-------------+
| Length | P-Type = APP_RESOURCE_PRI |
+-------------+-------------+-------------+-------------+
// ALRP List //
+---------------------------+---------------------------+
Figure 2: Application-Level Resource Priority Policy Element
図2：アプリケーションレベルのリソースプライオリティポリシー要素
where:
どこ：
o Length:
Oの長さ：
* The length of the policy element (including the Length and P-Type) is in number of octets (MUST be a multiple of 4) and indicates the end of the ALRP list.
*（長さおよびp型を含む）ポリシーエレメントの長さは、オクテットの数である（4の倍数でなければならない）とALRPリストの終わりを示します。
o P-Type: 16 bits
O p型：16ビット
* APP_RESOURCE_PRI = 0x06 (see the "IANA Considerations" section).
* APP_RESOURCE_PRIの=の0x06の（ "IANAの考慮事項" を参照してください）。
o ALRP List:
ALRP一覧○：
* List of ALRPs where each ALRP is encoded as shown in Figure 3.
*図3に示すように、各ALRPが符号化されるALRPsのリスト。
ALRP:
0 0 0 1 1 2 2 3
0 . . . 7 8 . . . 5 6 . . . 3 4 . . . 1
+---------------------------+-------------+-------------+
| ALRP Namespace | Reserved |ALRP Value |
+---------------------------+---------------------------+
Figure 3: Application-Level Resource Priority
図3：アプリケーションレベルのリソースプライオリティ
where:
どこ：
o ALRP Namespace (Application-Level Resource Priority Namespace): 16 bits (unsigned)
O ALRPネームスペース（アプリケーションレベルのリソースプライオリティネームスペース）：16ビット（符号なし）
* Contains a numerical value identifying the namespace of the application-level resource priority. This value is encoded as per the "Resource Priority Namespaces" IANA registry. (See the "IANA Considerations" section; IANA has extended the registry to include this numerical value).
*アプリケーションレベルのリソース優先順位の名前空間を識別する数値が含まれています。この値は、「リソースプライオリティネームスペース」IANAレジストリあたりとしてエンコードされます。 （「IANAの考慮事項」を参照してください、IANAは、この数値を含むようにレジストリを拡張しました）。
o Reserved: 8 bits
O予約：8ビット
* SHALL be set to zero on transmit and SHALL be ignored on reception.
*送信時にゼロに設定されるものとし、受信時に無視されなければなりません。
o ALRP Value (Application-Level Resource Priority Value): 8 bits (unsigned)
O ALRP値（アプリケーションレベル資源優先度の値）が8ビット（符号なし）
* Contains the priority value within the namespace of the application-level resource priority. This value is encoded as per the "Resource Priority Priority-Value" IANA registry. (See the "IANA Considerations" section; IANA has extended the registry to include this numerical value).
*アプリケーションレベルのリソース優先順位の名前空間内の優先度の値が含まれています。この値は、「リソースプライオリティプライオリティ・バリュー」IANAレジストリあたりとしてエンコードされます。 （「IANAの考慮事項」を参照してください、IANAは、この数値を含むようにレジストリを拡張しました）。
When POLICY_DATA objects are protected by integrity, LPDPs should not attempt to modify them. They MUST be forwarded without modification to ensure their security envelope is not invalidated.
POLICY_DATAオブジェクトが整合性によって保護されている場合は、LPDPsは、それらを変更しようとするべきではありません。彼らは、セキュリティのエンベロープが無効にされていないことを確認するために変更することなく転送する必要があります。
In case of multicast, when POLICY_DATA objects are not protected by integrity, LPDPs MAY merge incoming Application-Level Resource Priority Elements to reduce their size and number. When they do merge those elements, LPDPs MUST do so according to the following rule:
POLICY_DATAオブジェクトが整合性によって保護されていないマルチキャストの場合、LPDPsは、その大きさや数を減らすために、着信アプリケーションレベルのリソースプライオリティ要素をマージするかもしれません。彼らはそれらの要素をマージ行うと、LPDPsは、以下のルールに従って行う必要があります：
o The ALRP List in the outgoing APP_RESOURCE_PRI element MUST contain all the ALRPs appearing in the ALRP List of an incoming APP_RESOURCE_PRI element. A given ALRP MUST NOT appear more than once. In other words, the outgoing ALRP List is the union of the incoming ALRP Lists that are merged.
Oの発信APP_RESOURCE_PRI要素でALRP一覧は、着信APP_RESOURCE_PRI要素のALRPリストに登場するすべてALRPsを含まなければなりません。与えられたALRP回以上現れてはなりません。言い換えれば、送信ALRPリストがマージされ、着信ALRPリストの和集合です。
As merging applies to multicast, this rule also applies to multicast sessions.
マージがマルチキャストに適用されるように、このルールは、マルチキャストセッションに適用されます。
As specified in Section 4.2 of [RFC2750], Policy Ignorant Nodes (PINs) implement a default handling of POLICY_DATA objects ensuring that those objects can traverse PINs in transit from one PEP to another. This applies to the situations where POLICY_DATA objects contain the Admission Priority Policy Element and the ALRP Policy Element specified in this document, so that those objects can traverse PINs.
[RFC2750]のセクション4.2で指定されるように、ポリシー無知ノード（ピン）これらのオブジェクトは、別のPEPからトランジットのピンを通過できることを確実POLICY_DATAオブジェクトのデフォルト処理を実装します。これは、これらのオブジェクトは、PINを横断できるようにPOLICY_DATAオブジェクトは、この文書で指定されたアドミッション優先権方針要素とALRPポリシー要素が含まれている状況に適用されます。
Section 4.2 of [RFC2750] also defines a similar default behavior for policy-capable nodes that do not recognize a particular policy element. This applies to the Admission Priority Policy Element and the ALRP Policy Element specified in this document, so that those elements can traverse policy-capable nodes that do not support these extensions defined in the present document.
[RFC2750]のセクション4.2は、特定のポリシー要素を認識しないポリシー対応ノードに対して同様のデフォルト動作を定義します。これらの要素が存在する文書で定義されたこれらの拡張機能をサポートしていない政策対応のノードを通過できるように、これは、この文書で指定されたアドミッション優先権方針要素とALRP方針要素に適用されます。
As this document defines extensions to RSVP, the security considerations of RSVP apply. Those are discussed in [RFC2205], [RFC4230], and [RFC6411]. Approaches for addressing those concerns are discussed further below.
このドキュメントはRSVPに拡張を定義すると、RSVPのセキュリティに関する考慮事項が適用されます。それらは、[RFC2205]、[RFC4230]及び[RFC6411]に記載されています。これらの懸念に対処するためのアプローチは、以下でさらに議論されています。
A subset of RSVP messages are signaled with the Router Alert Option (RAO) ([RFC2113], [RFC2711]). The security aspects and common practices around the use of the current IP Router Alert Option and consequences on the use of IP Router Alert by applications such as RSVP are discussed in [RFC6398]. As discussed in Section 2, the extensions defined in this document are intended for use within a single administrative domain.
RSVPメッセージのサブセットは、ルータ警告オプション（RAO）（[RFC2113]、[RFC2711]）を用いてシグナリングされます。このようRSVPなどのアプリケーションによって、IPルータアラートの使用に関する現在のIPルータアラートオプションと結果の使用の周りのセキュリティ面および共通プラクティスは、[RFC6398]で議論されています。第2節で述べたように、このドキュメントで定義された拡張機能は、単一の管理ドメイン内での使用を目的としています。
[RFC6398] discusses router alert protection approaches for service providers. These approaches can be used to protect a given network against the potential risks associated with the leaking of router alert packets resulting from the use of the present extensions in another domain. Also, where RSVP is not used, by simply not enabling RSVP on the routers of a given network, generally that network can isolate itself from any RSVP signaling that may leak from another network that uses the present extensions (since the routers will then typically ignore RSVP messages). Where RSVP is to be used internally within a given network, the network operator can activate, on the edge of his network, mechanisms that either tunnel or, as a last resort, drop incoming RSVP messages in order to protect the given network from RSVP signaling that may leak from another network that uses the present extensions.
[RFC6398]は、サービスプロバイダのルータ警告保護のアプローチについて説明します。これらのアプローチは、別のドメインに存在する拡張の使用に起因するルータのアラートパケットの漏洩に伴う潜在的リスクに対して与えられたネットワークを保護するために使用することができます。 RSVPは、単に与えられたネットワークのルータにRSVPを有効にしないことによって、使用されていない場合にも、一般的にそのネットワークは、ルータは次いで、典型的には無視するので、本拡張機能を使用する別のネットワーク（から漏れる可能性のRSVPシグナリングからそれ自体を分離することができRSVPメッセージ）。 RSVPは、所与のネットワーク内で内部的に使用される場合、ネットワークオペレータは、自分のネットワークのエッジ上で、いずれかのトンネルまたは、最後の手段として、RSVPシグナリングから所定のネットワークを保護するために、着信RSVPメッセージをドロップメカニズムを活性化することができますすなわち、本拡張機能を使用する別のネットワークから漏出することができます。
The ADMISSION_PRI and APP_RESOURCE_PRI Policy Elements defined in this document are signaled by RSVP through encapsulation in a POLICY_DATA object as defined in [RFC2750]. Therefore, like any other policy elements, their integrity can be protected as discussed in Section 6 of [RFC2750] by two optional security mechanisms. The first mechanism relies on RSVP authentication as specified in [RFC2747] and [RFC3097] to provide a chain of trust when all RSVP nodes are policy capable. With this mechanism, the INTEGRITY object is carried inside RSVP messages. The second mechanism relies on the INTEGRITY object within the POLICY_DATA object to guarantee integrity between RSVP PEPs that are not RSVP neighbors.
[RFC2750]で定義されるように、この文書で定義されADMISSION_PRIとAPP_RESOURCE_PRIポリシーの要素はPOLICY_DATAオブジェクト内にカプセル化を通してRSVPによってシグナリングされます。 [RFC2750]のセクション6で説明したようにそのため、他のポリシー要素を、それらの完全性は、二つのオプションのセキュリティメカニズムによって保護することができます。 [RFC2747]及び[RFC3097]で指定されるように第1の機構は、すべてのRSVPノードがポリシーが可能である場合に、信頼の連鎖を提供するために、RSVP認証に依存しています。このメカニズムでは、INTEGRITYオブジェクトは、RSVPメッセージ内で運ばれます。第2のメカニズムは、隣人をRSVPされていないのRSVPのPEP間の整合性を保証するためにPOLICY_DATAオブジェクト内INTEGRITYオブジェクトに依存しています。
RSVP authentication can be used between RSVP neighbors that are policy capable. RSVP authentication (defined in [RFC2747] and [RFC3097]) SHOULD be supported by an implementation of the present document.
RSVP認証は政策能力があるRSVP隣人の間で使用することができます。 （[RFC2747]及び[RFC3097]で定義される）RSVP認証は、本文書の実装によってサポートされてください。
With RSVP authentication, the RSVP neighbors use shared keys to compute the cryptographic signature of the RSVP message. [RFC6411] discusses key types and key provisioning methods as well as their respective applicabilities.
RSVP認証では、RSVP隣人は、RSVPメッセージの暗号署名を計算するために、共有キーを使用します。 [RFC6411]キータイプとキープロビジョニング方法ならびにそれらのそれぞれの適用可能性を論じています。
The INTEGRITY object within the POLICY_DATA object can be used to guarantee integrity between non-neighboring RSVP PEPs. This is useful only when some RSVP nodes are Policy Ignorant Nodes (PINs). The INTEGRITY object within the POLICY_DATA object MAY be supported by an implementation of the present document.
POLICY_DATAオブジェクト内のINTEGRITYオブジェクトは、非隣接のRSVPのPEP間の整合性を保証するために使用することができます。これは、いくつかのRSVPノードが方針無知なノード（ピン）の場合のみ有効です。 POLICY_DATAオブジェクト内の整合性の目的は、本文書の実装によって支持されてもよいです。
Details for computation of the content of the INTEGRITY object can be found in Appendix B of [RFC2750]. This states that the Policy Decision Point (PDP), at its discretion, and based on the destination PEP/PDP or other criteria, selects an Authentication Key and the hash algorithm to be used. Keys to be used between PDPs can be distributed manually or via a standard key management protocol for secure key distribution.
INTEGRITYオブジェクトの内容を計算するための詳細は、[RFC2750]の付録Bに見出すことができます。これは、ポリシー決定ポイント（PDP）は、その裁量で、宛先PEP / PDP又は他の基準に基づいて、認証キーとハッシュアルゴリズムを使用することを選択することを述べています。プラズマディスプレイパネルとの間に使用されるキーは、手動で、または安全な鍵配布のための標準的な鍵管理プロトコルを介して配布することができます。
Note that where non-RSVP hops may exist in between RSVP hops, as well as where RSVP-capable PINs may exist in between PEPs, it may be difficult for the PDP to determine what is the destination PDP for a POLICY_DATA object contained in some RSVP messages (such as a Path message). This is because in those cases the next PEP is not known at the time of forwarding the message. In this situation, key shared across multiple PDPs may be used. This is conceptually similar to the use of a key shared across multiple RSVP neighbors as discussed in [RFC6411]. We observe also that this issue may not exist in some deployment scenarios where a single (or low number of) PDP is used to control all the PEPs of a region (such as an administrative domain). In such scenarios, it may be easy for a PDP to determine what is the next-hop PDP, even when the next-hop PEP is not known, simply by determining what is the next region that will be traversed (say, based on the destination address).
ここで、非RSVPホップがRSVPホップの間に存在し得る、ならびにRSVP対応PINがPEPの間で存在し得る場合、それはPOLICY_DATAオブジェクトの宛先PDPは、いくつかのRSVPに含まれるものを決定するために、PDPは困難であってもよいことに留意されたいです（このようなPathメッセージなどの）メッセージ。これらのケースでは、次のPEPがメッセージを転送する時には知られていないためです。このような状況では、複数のPDP全体で共有キーを使用することができます。これは[RFC6411]で説明したように、複数のRSVPネイバ間で共有キーを使用すると概念的に類似しています。我々は、（管理ドメインなど）地域のすべてのPEPを制御するために使用されるPDPこの問題は、単一の（または少ない数の）いくつかの展開シナリオに存在しない可能性があることも確認します。 PDPは、ネクストホップPEPはに基づいて、単純に言う（トラバースされる次の領域が何であるかを決定することによって、知られていない場合でも、次ホップPDPが何であるかを決定するためにそのようなシナリオでは、それは簡単であってもよいです宛先アドレス）。
As specified in [RFC2750], standard RSVP policy elements (P-type values) are to be assigned by IANA as per "IETF Consensus" policy as outlined in [RFC2434] (this policy is now called "IETF Review" as per [RFC5226]) .
[RFC2750]で指定されるように、標準RSVPポリシー素子（P型値）[RFC2434]に概説されるように（このポリシーは、現在RFC5226 [通り「IETFレビュー」と呼ばれる「IETFコンセンサス」ポリシーに従ってIANAによって割り当てられます]）。
IANA has allocated two P-Types from the standard RSVP policy element range:
IANAは、標準的なRSVPポリシーエレメントの範囲から、2つのPタイプを割り当てました。
o 0x05 ADMISSION_PRI for the Admission Priority Policy Element
Oアドミッション重点要素のための0x05をADMISSION_PRI
o 0x06 APP_RESOURCE_PRI for the Application-Level Resource Priority Policy Element
Oアプリケーションレベルのリソース重点要素のための0x06でAPP_RESOURCE_PRI
In Section 5.1, the present document defines a Merge Strategy field inside the Admission Priority Policy Element. This registry is to be specified as also applicable to the Merge Strategy field of the Preemption Priority Policy Elements defined in [RFC3181]. Since it is conceivable that, in the future, values will be added to the registry that only apply to the Admission Priority Policy Element or to the Preemption Priority Policy Element (but not to both), IANA has listed the applicable documents for each value. IANA has allocated the following values:
5.1節では、本文書には、アドミッション優先権方針要素内のマージ戦略のフィールドを定義します。このレジストリは、[RFC3181]で定義された先取り優先権方針要素のマージ戦略分野にも適用可能として指定することです。それは将来的に、値が唯一の入学優先権方針要素または先取り優先権方針要素（両方ではないに）に適用され、レジストリに追加される、ということも考えられるので、IANAは、各値の該当文書をリストされています。 IANAは、次の値を割り当てました。
o 0: Reserved
0：予約済み
o 1: Take priority of highest QoS [RFC3181] [RFC6401]
O 1：最高のQoSの優先順位を取る[RFC3181] [RFC6401]
o 2: Take highest priority [RFC3181] [RFC6401]
2 O：最高の優先度[RFC3181] [RFC6401]を取ります
o 3: Force Error on heterogeneous merge [RFC3181] [RFC6401]
O 3：異種マージの強制エラー[RFC3181] [RFC6401]
Following the policies outlined in [RFC5226], numbers in the range 0-127 are allocated according to the "IETF Review" policy, numbers in the range 128-240 as "First Come First Served", and numbers in the range 241-255 are "Reserved for Private Use".
「最初は役立っ最初に来る」、および範囲241-255内の数字として、[RFC5226]に概説された方針に続いて、0から127の範囲内の数値は、128から240の範囲内の数値、「IETFレビュー」ポリシーに応じて割り当てられ、 「私的使用のために予約」されています。
In Section 5.1, the present document defines an Error Code field inside the Admission Priority Policy Element. IANA has created a registry for this field and allocate the following values:
5.1節では、本文書には、アドミッション優先権方針要素内部のエラーコードフィールドを定義します。 IANAは、このフィールドのレジストリを作成し、以下の値を割り当てています：
o 0: NO_ERROR - Value used for regular ADMISSION_PRI elements
O 0：NO_ERROR - 定期ADMISSION_PRI要素に使用される値
o 2: HETEROGENEOUS - This element encountered heterogeneous merge
O 2：HETEROGENEOUS - この要素は、異種のマージが発生しました
Following the policies outlined in [RFC5226], numbers in the range 0-127 are allocated according to the "IETF Review" policy, numbers in the range 128-240 as "First Come First Served", and numbers in the range 241-255 are "Reserved for Private Use". Value 1 is Reserved (for consistency with [RFC3181] Error Code values).
「最初は役立っ最初に来る」、および範囲241-255内の数字として、[RFC5226]に概説された方針に続いて、0から127の範囲内の数値は、128から240の範囲内の数値、「IETFレビュー」ポリシーに応じて割り当てられ、 「私的使用のために予約」されています。値1は、（[RFC3181]のエラーコード値との整合性のために）予約されています。
The present document defines an ALRP Namespace field in Section 5.2 that contains a numerical value identifying the namespace of the application-level resource priority. The IANA already maintains the Resource-Priority Namespaces registry (under the SIP Parameters) listing all such namespaces. That registry has been updated to allocate a numerical value to each namespace. To be exact, the IANA has extended the Resource-Priority Namespaces registry in the following ways:
本文書では、アプリケーションレベルのリソース優先順位の名前空間を識別する数値が含まれているセクション5.2でALRP名前空間フィールドを定義します。 IANAは、すでにそのようなすべての名前空間をリスト（SIPパラメータの下で）リソースプライオリティネームスペースのレジストリを維持します。そのレジストリは、各名前空間に数値を割り当てるように更新されました。正確には、IANAは、次の方法でリソース優先名前空間レジストリを拡張しました：
o A new column has been added to the registry.
O新しい列がレジストリに追加されました。
o The title of the new column is "Namespace Numerical Value *".
O新しい列のタイトルは、「名前空間数値*」です。
o In the Legend, a line has been added stating "Namespace Numerical Value = the unique numerical value identifying the namespace".
O凡例に、ラインは「名前空間数値=名前空間を識別する一意の数値を」知らせる追加されています。
o In the Legend, a line has been added stating "* : [RFC6401]".
「：[RFC6401] *を」O伝説では、ラインは述べ追加されました。
o An actual numerical value has been allocated to each namespace in the registry and is listed in the new "Namespace Numerical Value *" column.
O実際の数値は、レジストリ内の各名前空間に割り当てられていると新しい「名前空間数値*」欄に記載されています。
A numerical value has been allocated by IANA for all existing namespaces. In the future, IANA should automatically allocate a numerical value to any new namespace added to the registry.
数値は、すべての既存の名前空間のためにIANAによって割り当てられています。将来的には、IANAは、自動的にレジストリに追加された新しい名前空間に数値を割り当てる必要があります。
The present document defines an ALRP Priority field in Section 5.2 that contains a numerical value identifying the actual application-level resource priority within the application-level resource priority namespace. The IANA already maintains the Resource-Priority Priority-Values registry (under the SIP Parameters) listing all such priorities. That registry has been updated to allocate a numerical value to each priority-value. To be exact, the IANA has extended the Resource-Priority Priority-Values registry in the following ways: o For each namespace, the registry is structured with two columns.
本文書では、アプリケーション・レベルのリソース優先順位の名前空間内の実際のアプリケーションレベルのリソースの優先度を識別する数値が含まれているセクション5.2でALRP Priorityフィールドを定義します。 IANAは、すでにそのようなすべての優先順位をリスト（SIPパラメータの下で）資源優先度優先度-値のレジストリを維持します。そのレジストリは、各優先度の値に数値を割り当てるように更新されました。正確には、IANAは、次の方法でリソース優先優先-値レジストリを拡張しています。各名前空間のO、レジストリは、2つの列で構成されています。
o The title of the first column is "Priority Values (least to greatest)".
O最初の列のタイトルは、「（少なくとも最大の）優先順位の値」です。
o The first column lists all the values currently defined in the registry (e.g., for the drsn namespace: "routine", "priority", "immediate", "flash", "flash-override", and "flash-override-override")
「ルーチン」、「優先度」、「即時」、「フラッシュ」、「フラッシュ・オーバーライド」、および「フラッシュオーバーライドオーバーライド：最初のカラムには、現在のレジストリ（例えば、DRSN名前空間の中で定義されたすべての値を示していますoを「）
o The title of the second column is "Priority Numerical Value *".
O第二カラムのタイトルは「*重点数値」です。
o At the bottom of the registry, a "Legend" has been added with a line stating "Priority Numerical Value = the unique numerical value identifying the priority within a namespace".
レジストリの底部にはOは、「凡例」を「優先数値=ネームスペース内で優先順位を識別する一意の数値」述べラインに追加されています。
o In the Legend, a line has been added stating "* : [RFC6401]".
「：[RFC6401] *を」O伝説では、ラインは述べ追加されました。
o An actual numerical value has been allocated to each priority value and is listed in the new "Priority Numerical Value *" column.
O実際の数値は、各優先順位の値に割り当てられていると、新しい「優先数値*」欄に記載されています。
A numerical value has been allocated by IANA to all existing priorities. In the future, IANA should automatically allocate a numerical value to any new namespace added to the registry. The numerical value must be unique within each namespace. Within each namespace, values should be allocated in decreasing order ending with 0 (so that the greatest priority is always allocated value 0). For example, in the drsn namespace, "routine" is allocated numerical value 5, and "flash-override-override" is allocated numerical value 0.
数値は、すべての既存の優先順位にIANAによって割り当てられています。将来的には、IANAは、自動的にレジストリに追加された新しい名前空間に数値を割り当てる必要があります。数値は、各名前空間内で一意でなければなりません。 （最大の優先度が常に値0が割り当てられるように）それぞれの名前空間内で、値が0で終わる順に割り当てられるべきです。例えば、DRSN名前空間で、「ルーチン」は数値5割り当てられ、「フラッシュオーバーライドオーバーライド」は数値0を割り当てられます。
We would like to thank An Nguyen for his encouragement to address this topic and ongoing comments. Also, this document borrows heavily from some of the work of S. Herzog on the Preemption Priority Policy Element [RFC3181]. Dave Oran and Janet Gunn provided useful input for this document. Ron Bonica, Magnus Westerlund, Cullen Jennings, Ross Callon and Tim Polk provided specific guidance for the applicability statement of the mechanisms defined in this document.
私たちは、このトピックと継続的なコメントに対処するために彼の激励のためにアングエンに感謝したいと思います。また、この文書は、先取り優先権方針要素[RFC3181]でS.ヘルツォークの仕事の一部から重く借ります。デイブ・オランとジャネット・ガンは、この文書のための便利な入力を提供します。ロンBonica、マグヌスウェスター、カレン・ジェニングス、ロスCallonとティム・ポークは、この文書で定義されたメカニズムの適用性声明のための具体的な指針を提供します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]ブレーデン、B.、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1機能仕様"、RFC 2205、1997年9月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[RFC2747]ベーカー、F.、リンデル、B.、およびM. Talwar、 "RSVP暗号化認証"、RFC 2747、2000年1月。
[RFC2750] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000.
[RFC2750]ヘルツォーク、S.、 "ポリシー制御のためのRSVP拡張機能"、RFC 2750、2000年1月。
[RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic Authentication -- Updated Message Type Value", RFC 3097, April 2001.
[RFC3097]ブレーデン、R.とL.チャン、 "RSVP暗号化認証 - 更新メッセージタイプ価値"、RFC 3097、2001年4月。
[RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element", RFC 3181, October 2001.
[RFC3181]ヘルツォーク、S.、RFC 3181 2001年10月、 "先取り優先権方針要素が通知さ"。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312, October 2002.
[RFC3312]キャマリロ、G.、マーシャル、W.、およびJ.ローゼンバーグ、RFC 3312、2002年10月 "資源管理とセッション開始プロトコル（SIP）の統合"。
[RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource Priority for the Session Initiation Protocol (SIP)", RFC 4412, February 2006.
[RFC4412] Schulzrinneと、H.とJ.ポーク、 "セッション開始プロトコル（SIP）のための通信リソースプライオリティ"、RFC 4412、2006年2月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。
[RFC6398] Le Faucheur, F., Ed., "IP Router Alert Considerations and Usage", BCP 168, RFC 6398, October 2011.
[RFC6398]ルFaucheur、F.、エド。、 "IPルータアラートの考慮事項および使用方法"、BCP 168、RFC 6398、2011年10月。
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[RFC2113]カッツ、D.、 "IPルータアラートオプション"、RFC 2113、1997年2月。
[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, October 1999.
[RFC2711]ウズラ、C.とA.ジャクソン、 "IPv6のルータアラートオプション"、RFC 2711、1999年10月。
[RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework for Policy-based Admission Control", RFC 2753, January 2000.
[RFC2753] Yavatkar、R.、Pendarakis、D.、およびR.ゲラン、 "ポリシーベースのアドミッション制御のためのフレームワーク"、RFC 2753、2000年1月。
[RFC4125] Le Faucheur, F. and W. Lai, "Maximum Allocation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering", RFC 4125, June 2005.
[RFC4125]ルFaucheur、F.およびW.ライ、 "Diffservの認識MPLSトラフィックエンジニアリングの最大割り当て帯域幅の制約モデル"、RFC 4125、2005年6月。
[RFC4126] Ash, J., "Max Allocation with Reservation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering & Performance Comparisons", RFC 4126, June 2005.
[RFC4126]アッシュ、J.、RFC 4126「のDiffservを意識したMPLSトラフィックエンジニアリング＆パフォーマンスの比較のための予約帯域幅の制約モデルによる最大配分」、2005年6月。
[RFC4127] Le Faucheur, F., "Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering", RFC 4127, June 2005.
[RFC4127]ルFaucheur、F.、 "Diffservの認識MPLSトラフィックエンジニアリングのためのロシア人形の帯域幅制約モデル"、RFC 4127、2005年6月。
[RFC4230] Tschofenig, H. and R. Graveman, "RSVP Security Properties", RFC 4230, December 2005.
[RFC4230] Tschofenig、H.とR. Graveman、 "RSVPセキュリティのプロパティ"、RFC 4230、2005年12月。
[RFC4495] Polk, J. and S. Dhesikan, "A Resource Reservation Protocol (RSVP) Extension for the Reduction of Bandwidth of a Reservation Flow", RFC 4495, May 2006.
[RFC4495]ポーク、J.とS. Dhesikan、「リソース予約プロトコル（RSVP）の予約フローの帯域幅の削減のための拡張」、RFC 4495、2006年5月。
[RFC5974] Manner, J., Karagiannis, G., and A. McDonald, "NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling", RFC 5974, October 2010.
[RFC5974]マナー、J.、Karagiannis、G.、およびA.マクドナルド、 "NSISシグナリング層プロトコルクオリティ・オブ・サービスシグナリングのための（NSLP）"、RFC 5974、2010年10月。
[RFC6411] Behringer, M., Le Faucheur, F., and B. Weis, "Applicability of Keying Methods for RSVP Security", RFC 6411, October 2011.
[RFC6411]ベリンガー、M.、ルFaucheur、F.、およびB.ヴァイス、RFC 6411、2011年10月 "RSVPセキュリティのためのキーイング方法の適用"。
Appendix A. Examples of Bandwidth Allocation Model for Admission Priority
入場優先順位のための帯域幅割り当てモデルの付録A.例
Appendices A.1 and A.2 respectively illustrate how the Maximum Allocation Model (MAM) [RFC4125] and the Russian Dolls Model (RDM) [RFC4127] can be used for support of admission priority. The Maximum Allocation model with Reservation (MAR) [RFC4126] can also be used in a similar manner for support of admission priority. Appendix A.3 illustrates how a simple "Priority Bypass Model" can also be used for support of admission priority.
付録A.1およびA.2は、それぞれ、[RFC4125]とロシア人形モデル（RDM）[RFC4127]は、アドミッション優先の支援のために使用することができる方法を最大割り当てモデル（MAM）を示します。予約での最大配分モデル（MAR）[RFC4126]も入場優先順位をサポートするために同様に使用することができます。付録A.3は、単純な「優先バイパスモデル」も入場優先順位のサポートのために使用することができる方法を示しています。
For simplicity, operations with only a single "priority" level (beyond non-priority) are illustrated here; however, the reader will appreciate that operations with multiple priority levels can easily be supported with these models.
簡単にするために、（非優先超える）単一の「優先度」レベルの操作は、ここで示されています。しかし、読者は、複数の優先レベルを有する操作が容易にこれらのモデルでサポートすることができることを理解するであろう。
In all the figures below:
以下の全ての図面において：
"x" represents a non-priority session "o" represents a priority session
「x」は非優先セッション「O」が優先セッションを表し
A.1. Admission Priority with Maximum Allocation Model (MAM)
A.1。最大割当モデルによる入場プライオリティ（MAM）
This section illustrates operations of admission priority when a Maximum Allocation Model (MAM) is used for bandwidth allocation across non-priority traffic and priority traffic. A property of the Maximum Allocation Model is that priority traffic cannot use more than the bandwidth made available to priority traffic (even if the non-priority traffic is not using all of the bandwidth available for it).
このセクションでは、最大割り当てモデル（MAM）は、非優先トラフィックと優先トラヒックを横切る帯域割当のために使用されるアドミッション優先度の動作を示します。最大配分モデルのプロパティは、その優先順位トラフィックがプライオリティトラフィック（非優先トラフィックがそれのために利用可能な帯域幅のすべてを使用していない場合であっても）に利用可能な帯域幅を超えて使用することはできませんです。
-----------------------
^ ^ ^ | | ^
. . . | | .
Total . . . | | . Bandwidth
(1)(2)(3) | | . available
Engi- . . . | | . for non-priority use
neered .or.or. | | .
. . . | | .
Capacity. . . | | .
v . . | | v
. . |--------------| ---
v . | | ^
. | | . Bandwidth available for
v | | v priority use
-------------------------
Figure 4: MAM Bandwidth Allocation
図4：MAMの帯域割り当て
Figure 4 shows a link that is within a routed network and conforms to this document. On this link are two amounts of bandwidth available to two types of traffic: non-priority and priority.
図4は、ルーティングされたネットワーク内にあり、この文書に準拠したリンクを示しています。非優先と優先順位：このリンク上のトラフィックの2種類が利用可能な帯域幅の2枚の金額です。
If the non-priority traffic load reaches the maximum bandwidth available for non-priority, no additional non-priority sessions can be accepted even if the bandwidth reserved for priority traffic is not fully utilized currently.
非優先トラフィック負荷が非優先で使用可能な最大帯域幅に達した場合、優先トラフィック用に予約された帯域幅が十分に現在利用されていない場合でも、追加の非優先セッションが受けできません。
With the Maximum Allocation Model, in the case where the priority load reaches the maximum bandwidth reserved for priority sessions, no additional priority sessions can be accepted.
最大割り当てモデルで、優先負荷が優先セッションのために予約される最大帯域幅に達する場合には、追加の優先度のセッションが受け入れられないことができます。
As illustrated in Figure 4, an operator may map the MAM to the engineered capacity limits according to different policies. At one extreme, where the proportion of priority traffic is reliably known to be fairly small at all times and where there may be some safety margin factored in the engineered capacity limits, the operator may decide to configure the bandwidth available for non-priority use to the full engineered capacity limits, effectively allowing the priority traffic to ride within the safety margin of this engineered capacity. This policy can be seen as an economically attractive approach as all of the engineered capacity is made available to non-priority sessions. This policy is illustrated as (1) in Figure 4. As an example, if the engineered capacity limit on a given link is X, the operator may configure the bandwidth available to non-priority traffic to X, and the bandwidth available to priority traffic to 5% of X. At the other extreme, where the proportion of priority traffic may be significant at times and the engineered capacity limits are very tight, the operator may decide to configure the bandwidth available to non-priority traffic and the bandwidth available to priority traffic such that their sum is equal to the engineered capacity limits. This guarantees that the total load across non-priority and priority traffic is always below the engineered capacity and, in turn, guarantees there will never be any QoS degradation. However, this policy is less attractive economically as it prevents non-priority sessions from using the full engineered capacity, even when there is no or little priority load, which is the majority of time. This policy is illustrated as (3) in Figure 4. As an example, if the engineered capacity limit on a given link is X, the operator may configure the bandwidth available to non-priority traffic to 95% of X, and the bandwidth available to priority traffic to 5% of X. Of course, an operator may also strike a balance anywhere in between these two approaches. This policy is illustrated as (2) in Figure 4.
図4に示すように、オペレータは、異なるポリシーに従って操作容量限界にMAMをマッピングすることができます。優先トラフィックの割合は確実にすべての回で、かなり小さいことが知られており、設計容量制限に織り込んいくつかの安全マージンがあるような場所で、オペレータは非優先使用のために利用可能な帯域幅を設定することを決定して、極端な1、で完全な設計容量制限は、効果的に優先順位のトラフィックがこの設計容量の安全マージン内乗ることができます。設計能力の全てが非優先セッションで利用できるようになり、このポリシーは、経済的に魅力的なアプローチとして見ることができます。このポリシーは、所与のリンク上の操作能力の限界がXである場合、オペレータは、優先トラフィックに使用可能なXの非優先トラフィックに使用可能な帯域幅、および帯域幅を設定することができ、一例として図4の（1）として示されています優先トラフィックの割合は倍で有意とすることができ、設計容量制限は非常にタイトです、オペレータは、非優先トラフィックとに使用可能な帯域幅が利用可能な帯域幅を設定するように決定することができる他の極端で、Xの5％にその合計が操作された容量制限に等しくなるように優先順位トラフィック。これは、順番に、任意のQoSの劣化があることはありません保証し、非優先と優先順位のトラフィック全体の総負荷は常に設計容量以下であることを保証します。何か少し優先順位の負荷、時間の大半が存在しない場合でも、それは、完全な設計能力を使用してから、非優先セッションを防ぐようしかし、この政策は、経済的にあまり魅力的です。このポリシーは、所与のリンク上の操作能力の限界がXである場合、オペレータは95 Xの％、および利用可能な帯域幅に非優先トラフィックに利用可能な帯域幅を設定することができ、一例として図4の（3）として示されていますもちろんXの5％に優先トラフィックに、オペレータは、これらの2つの方法の内の任意の場所にバランスを取ることができます。このポリシーは、図4の（2）として示されています。
Figure 5 shows some of the non-priority capacity of this link being used.
図5は、使用されて、このリンクの非優先容量の一部を示しています。
-----------------------
^ ^ ^ | | ^
. . . | | .
Total . . . | | . Bandwidth
. . . | | . available
Engi- . . . | | . for non-priority use
neered .or.or. |xxxxxxxxxxxxxx| .
. . . |xxxxxxxxxxxxxx| .
Capacity. . . |xxxxxxxxxxxxxx| .
v . . |xxxxxxxxxxxxxx| v
. . |--------------| ---
v . | | ^
. | | . Bandwidth available for
v | | v priority use
-------------------------
Figure 5: Partial Load of Non-Priority Calls
図5：非優先コールの部分負荷
Figure 6 shows the same amount of non-priority load being used at this link and a small amount of priority bandwidth being used.
図6は、非優先このリンクで使用される負荷と使用されている優先帯域幅の少量の同じ量を示します。
-----------------------
^ ^ ^ | | ^
. . . | | .
Total . . . | | . Bandwidth
. . . | | . available
Engi- . . . | | . for non-priority use
neered .or.or. |xxxxxxxxxxxxxx| .
. . . |xxxxxxxxxxxxxx| .
Capacity. . . |xxxxxxxxxxxxxx| .
v . . |xxxxxxxxxxxxxx| v
. . |--------------| ---
v . | | ^
. | | . Bandwidth available for
v |oooooooooooooo| v priority use
-------------------------
Figure 6: Partial Load of Non-Priority Calls and Partial Load of Priority Calls
図6：非優先コールと優先呼の部分負荷の部分負荷
Figure 7 shows the case where non-priority load equates or exceeds the maximum bandwidth available to non-priority traffic. Note that additional non-priority sessions would be rejected even if the bandwidth reserved for priority sessions is not fully utilized.
図7は、非優先負荷が等しい又は非優先トラフィックに使用可能な最大帯域幅を超えた場合を示しています。優先度のセッション用に予約された帯域幅が十分に活用されていない場合でも、追加の非優先セッションは拒否されることに注意してください。
-----------------------
^ ^ ^ |xxxxxxxxxxxxxx| ^
. . . |xxxxxxxxxxxxxx| .
Total . . . |xxxxxxxxxxxxxx| . Bandwidth
. . . |xxxxxxxxxxxxxx| . available
Engi- . . . |xxxxxxxxxxxxxx| . for non-priority use
neered .or.or. |xxxxxxxxxxxxxx| .
. . . |xxxxxxxxxxxxxx| .
Capacity. . . |xxxxxxxxxxxxxx| .
v . . |xxxxxxxxxxxxxx| v
. . |--------------| ---
v . | | ^
. | | . Bandwidth available for
v |oooooooooooooo| v priority use
-------------------------
Figure 7: Full Non-Priority Load and Partial Load of Priority Calls
図7：フル非優先負荷と優先呼の部分負荷
Figure 8 shows the case where the priority traffic equates or exceeds the bandwidth reserved for such priority traffic.
図8は、優先度のトラフィックは、優先順位トラフィックのために予約帯域幅を等しい又は超える場合を示しています。
In that case, additional priority sessions could not be accepted. Note that this does not mean that such sessions are dropped altogether: they may be handled by mechanisms, which are beyond the scope of this particular document (such as establishment through preemption of existing non-priority sessions or such as queueing of new priority session requests until capacity becomes available again for priority traffic).
その場合には、追加の優先順位セッションが受け入れられませんでした。それらは既存の非優先セッションのプリエンプションを介して、または、そのような新しい優先セッション要求のキューイングのように（例えば、確立、この特定の文書の範囲を超えているメカニズムによって処理することができる：これは、このようなセッションが完全にドロップされることを意味しないことに注意してください容量まで）優先順位のトラフィックのために再び利用可能になります。
-----------------------
^ ^ ^ |xxxxxxxxxxxxxx| ^
. . . |xxxxxxxxxxxxxx| .
Total . . . |xxxxxxxxxxxxxx| . Bandwidth
. . . |xxxxxxxxxxxxxx| . available
Engi- . . . |xxxxxxxxxxxxxx| . for non-priority use
neered .or.or. |xxxxxxxxxxxxxx| .
. . . |xxxxxxxxxxxxxx| .
Capacity. . . | | .
v . . | | v
. . |--------------| ---
v . |oooooooooooooo| ^
. |oooooooooooooo| . Bandwidth available for
v |oooooooooooooo| v priority use
-------------------------
Figure 8: Partial Non-Priority Load and Full Priority Load
図8：部分的な非優先負荷とフル優先ロード
A.2. Admission Priority with Russian Dolls Model (RDM)
A.2。ロシアの人形のモデルで入場プライオリティ（RDM）
This section illustrates operations of admission priority when a Russian Dolls Model (RDM) is used for bandwidth allocation across non-priority traffic and priority traffic. A property of the RDM is that priority traffic can use the bandwidth that is not currently used by non-priority traffic.
このセクションでは、ロシア人形モデル（RDM）は、非優先トラフィックと優先トラヒックを横切る帯域割当のために使用されるアドミッション優先度の動作を示します。 RDMのプロパティは、プライオリティトラフィックは現在、非優先トラフィックが使用されていない帯域幅を使用することができるということです。
As with the MAM, an operator may map the RDM onto the engineered capacity limits according to different policies. The operator may decide to configure the bandwidth available for non-priority use to the full engineered capacity limits. As an example, if the engineered capacity limit on a given link is X, the operator may configure the bandwidth available to non-priority traffic to X, and the bandwidth available to non-priority and priority traffic to 105% of X.
MAMと同様に、オペレータは、異なるポリシーに従って操作容量限界にRDMをマッピングすることができます。オペレータは、完全な設計容量制限に非優先使用のために利用可能な帯域幅を設定することもできます。所与のリンク上の操作能力の限界がXである場合、一例として、操作者は、Xの105％に対して非優先優先トラフィックに利用可能なXに非優先トラフィックに使用可能な帯域幅、および帯域幅を設定することができます
Alternatively, the operator may decide to configure the bandwidth available to non-priority and priority traffic to the engineered capacity limits. As an example, if the engineered capacity limit on a given link is X, the operator may configure the bandwidth available to non-priority traffic to 95% of X, and the bandwidth available to non-priority and priority traffic to X.
また、オペレータは、設計容量制限に非優先とプライオリティトラフィックに利用できる帯域幅を設定することもできます。所与のリンク上の操作能力の限界がXである場合、一例として、操作者がXの95％、非優先トラフィックに利用可能な帯域幅、及びXと非優先と優先トラフィックに利用可能な帯域幅を設定することができます
Finally, the operator may decide to strike a balance in between. The considerations presented for these policies in the previous section in the MAM context are equally applicable to RDM.
最後に、オペレータは、間のバランスを取ることを決定することができます。 MAMの文脈で前のセクションでこれらのポリシーのために提示考慮事項がRDMにも同様に適用可能です。
Figure 9 shows the case where only some of the bandwidth available to non-priority traffic is being used, and a small amount of priority traffic is in place. In that situation, both new non-priority sessions and new priority sessions would be accepted.
図9は、非優先トラフィックに利用可能な帯域幅の一部のみが使用されている場合を示しており、優先トラフィック少量の場所です。そのような状況では、新しい非優先セッションと新しい優先順位セッションの両方が受け入れられるでしょう。
--------------------------------------
|xxxxxxxxxxxxxx| . ^
|xxxxxxxxxxxxxx| . Bandwidth .
|xxxxxxxxxxxxxx| . available for .
|xxxxxxxxxxxxxx| . non-priority .
|xxxxxxxxxxxxxx| . use .
|xxxxxxxxxxxxxx| . . Bandwidth
| | . . available for
| | v . non-priority
|--------------| --- . and priority
| | . use
| | .
|oooooooooooooo| v
---------------------------------------
Figure 9: Partial Non-Priority Load and Partial Aggregate Load
図9の部分的、非優先負荷および部分集計ロード
Figure 10 shows the case where all of the bandwidth available to non-priority traffic is being used and a small amount of priority traffic is in place. In that situation, new priority sessions would be accepted, but new non-priority sessions would be rejected.
図10は、非優先トラフィックに利用可能な帯域幅のすべてが使用されており、優先順位トラフィック少量の所定の位置にある場合を示しています。そのような状況では、新しい優先順位のセッションが受け入れられるだろうが、新しい非優先セッションは拒否されます。
--------------------------------------
|xxxxxxxxxxxxxx| . ^
|xxxxxxxxxxxxxx| . Bandwidth .
|xxxxxxxxxxxxxx| . available for .
|xxxxxxxxxxxxxx| . non-priority .
|xxxxxxxxxxxxxx| . use .
|xxxxxxxxxxxxxx| . . Bandwidth
|xxxxxxxxxxxxxx| . . available for
|xxxxxxxxxxxxxx| v . non-priority
|--------------| --- . and priority
| | . use
| | .
|oooooooooooooo| v
---------------------------------------
Figure 10: Full Non-Priority Load and Partial Aggregate Load
図10：全非優先負荷と部分負荷集計
Figure 11 shows the case where only some of the bandwidth available to non-priority traffic is being used, and a heavy load of priority traffic is in place. In that situation, both new non-priority sessions and new priority sessions would be accepted. Note that, as illustrated in Figure 10, priority sessions use some of the bandwidth currently not used by non-priority traffic.
図11は、非優先トラフィックに利用可能な帯域幅の一部が使用されている場合のみを示しており、優先順位トラフィックの重い負荷が所定の位置にあります。そのような状況では、新しい非優先セッションと新しい優先順位セッションの両方が受け入れられるでしょう。図10に示すように、なお、優先度のセッションは、現在、非優先トラフィックによって使用されない帯域幅の一部を使用します。
--------------------------------------
|xxxxxxxxxxxxxx| . ^
|xxxxxxxxxxxxxx| . Bandwidth .
|xxxxxxxxxxxxxx| . available for .
|xxxxxxxxxxxxxx| . non-priority .
|xxxxxxxxxxxxxx| . use .
| | . . Bandwidth
| | . . available for
|oooooooooooooo| v . non-priority
|--------------| --- . and priority
|oooooooooooooo| . use
|oooooooooooooo| .
|oooooooooooooo| v
---------------------------------------
Figure 11: Partial Non-Priority Load and Heavy Aggregate Load
図11：部分的な非優先負荷とヘビー集計荷重
Figure 12 shows the case where all of the bandwidth available to non-priority traffic is being used, and all of the remaining available bandwidth is used by priority traffic. In that situation, new non-priority sessions would be rejected, and new priority sessions could not be accepted right away. Those priority sessions may be handled by mechanisms, which are beyond the scope of this particular document (such as established through preemption of existing non-priority sessions or such as queueing of new priority session requests until capacity becomes available again for priority traffic).
図12は、非優先トラフィックに利用可能な帯域幅のすべてが使用されている場合を示し、残りの利用可能な帯域幅の全ては、優先順位トラフィックによって使用されます。そのような状況では、新しい非優先セッションは拒否されると、新しい優先順位セッションはすぐに受け入れられませんでした。これらの優先度のセッションは、この特定の文書の範囲を超えているメカニズム、（容量優先順位トラフィックのために再び使用可能になるまで、既存の非優先セッションまたは新たな優先セッション要求のキューイングなどのプリエンプションを介して確立など）によって処理されてもよいです。
--------------------------------------
|xxxxxxxxxxxxxx| . ^
|xxxxxxxxxxxxxx| . Bandwidth .
|xxxxxxxxxxxxxx| . available for .
|xxxxxxxxxxxxxx| . non-priority .
|xxxxxxxxxxxxxx| . use .
|xxxxxxxxxxxxxx| . . Bandwidth
|xxxxxxxxxxxxxx| . . available for
|xxxxxxxxxxxxxx| v . non-priority
|--------------| --- . and priority
|oooooooooooooo| . use
|oooooooooooooo| .
|oooooooooooooo| v
---------------------------------------
Figure 12: Full Non-Priority Load and Full Aggregate Load
図12：全非優先負荷とフル集計ロード
A.3. Admission Priority with Priority Bypass Model (PrBM)
A.3。優先順位バイパスモデル（PrBM）で入場優先
This section illustrates operations of admission priority when a simple Priority Bypass Model (PrBM) is used for bandwidth allocation across non-priority traffic and priority traffic. With the PrBM, non-priority traffic is subject to resource-based admission control, while priority traffic simply bypasses the resource-based admission control. In other words:
このセクションでは、単純な優先バイパスモデル（PrBM）が非優先トラフィックと優先トラヒックを横切る帯域割当のために使用されるアドミッション優先度の動作を示します。優先順位トラフィックが単にリソースベースのアドミッション制御を迂回しながらPrBMと、非優先トラフィックは、リソースベースのアドミッション制御の対象となります。言い換えると：
o when a non-priority session arrives, this session is subject to bandwidth admission control and is accepted if the current total load (aggregate over non-priority and priority traffic) is below the engineered/allocated bandwidth.
O非優先セッションが到着したとき、このセッションは、帯域アドミッション制御の対象であり、現在の総負荷（非優先優先トラフィック上集約）が操作され/割り当てられた帯域幅以下である場合に受け入れられます。
o when a priority session arrives, this session is admitted regardless of the current load.
優先順位のセッションが到着したときに、O、このセッションは関係なく、現在の負荷の認められています。
A property of this model is that a priority session is never rejected.
このモデルのプロパティが優先セッションが拒否されることはありませんということです。
The rationale for this simple scheme is that, in practice, in some networks:
この単純なスキームの理論的根拠は、その、実際には、いくつかのネットワークです。
o The volume of priority sessions is very low for the vast majority of time, so it may not be economical to completely set aside bandwidth for priority sessions and preclude the utilization of this bandwidth by normal sessions in normal situations.
O優先順位セッションの量は、時間の大半のための非常に低いので、完全に優先順位セッションの帯域幅を脇に設定して経済的で、通常の状況では、通常のセッションでこの帯域幅の利用を妨げないことがあります。
o Even in congestion periods where priority sessions may be more heavily used, those sessions always still represent a fairly small proportion of the overall load that can be absorbed within the safety margin of the engineered capacity limits. Thus, even if they are admitted beyond the engineered bandwidth threshold, they are unlikely to result in noticeable QoS degradation.
Oでも優先セッションがより頻繁に使用されてもよい輻輳期間において、これらのセッションは常に依然として操作容量制限の安全マージン内で吸収することができる全体的な負荷のかなり小さな割合を表します。したがって、それらは設計帯域幅のしきい値を超えて入院している場合でも、彼らは顕著なQoSの低下につながる可能性は低いです。
As with the MAM and RDM, an operator may map the PrBM onto the engineered capacity limits according to different policies. The operator may decide to configure the bandwidth limit for admission of non-priority traffic to the full engineered capacity limit. As an example, if the engineered capacity limit on a given link is X, the operator may configure the bandwidth limit for non-priority traffic to X. Alternatively, the operator may decide to configure the bandwidth limit for non-priority traffic to below the engineered capacity limits (so that the sum of the non-priority and priority traffic stays below the engineered capacity). As an example, if the engineered capacity limit on a given link is X, the operator may configure the bandwidth limit for non-priority traffic to 95% of X. Finally, the operator may decide to strike a balance in between. The considerations presented for these policies in the previous sections in the MAM and RDM contexts are equally applicable to the PrBM.
MAMおよびRDMと同様に、オペレータは、異なるポリシーに従って操作容量限界にPrBMをマッピングすることができます。オペレータは、完全な設計容量制限に非優先トラフィックの入学のための帯域幅の制限を設定することもできます。所与のリンク上の操作能力の限界がXである場合、一例として、オペレータは、代替的にXに非優先トラフィックの帯域幅制限を設定することができ、オペレータは以下に非優先トラフィックの帯域幅制限を設定することを決定することができます操作された容量制限（非優先と優先トラフィックの合計が操作された容量以下に留まるように）。所与のリンク上の操作能力の限界がXである場合、一例として、操作者は、最後に、オペレータは、間にバランスを取ることを決定することができるXの95％、非優先トラフィックの帯域幅制限を設定することができます。 MAMの前のセクションでこれらのポリシーのために提示考慮事項とRDMコンテキストはPrBMにも同様に適用可能です。
Figure 13 illustrates the bandwidth allocation with the PrBM.
図13は、PrBMと帯域割当を示します。
-----------------------
^ ^ | | ^
. . | | .
Total . . | | . Bandwidth limit
(1) (2) | | . (on non-priority + priority)
Engi- . . | | . for admission
neered . or . | | . of non-priority traffic
. . | | .
Capacity. . | | .
v . | | v
. |--------------| ---
. | |
v | |
| |
Figure 13: Priority Bypass Model Bandwidth Allocation
図13：優先順位バイパスモデル帯域割り当て
Figure 14 shows some of the non-priority capacity of this link being used. In this situation, both new non-priority and new priority sessions would be accepted.
図14は、使用されて、このリンクの非優先容量の一部を示しています。このような状況で、新しい非優先して、新しい優先順位セッションの両方が受け入れられるでしょう。
-----------------------
^ ^ |xxxxxxxxxxxxxx| ^
. . |xxxxxxxxxxxxxx| .
Total . . |xxxxxxxxxxxxxx| . Bandwidth limit
(1) (2) |xxxxxxxxxxxxxx| . (on non-priority + priority)
Engi- . . | | . for admission
neered . or . | | . of non-priority traffic
. . | | .
Capacity. . | | .
v . | | v
. |--------------| ---
. | |
v | |
| |
Figure 14: Partial Load of Non-Priority Calls
図14：非プライオリティコールの部分負荷
Figure 15 shows the same amount of non-priority load being used at this link and a small amount of priority bandwidth being used. In this situation, both new non-priority and new priority sessions would be accepted.
図15は、非優先このリンクに使用される負荷と使用されている優先帯域幅の少量の同じ量を示します。このような状況で、新しい非優先して、新しい優先順位セッションの両方が受け入れられるでしょう。
-----------------------
^ ^ |xxxxxxxxxxxxxx| ^
. . |xxxxxxxxxxxxxx| .
Total . . |xxxxxxxxxxxxxx| . Bandwidth limit
(1) (2) |xxxxxxxxxxxxxx| . (on non-priority + priority)
Engi- . . |oooooooooooooo| . for admission
neered . or . | | . of non-priority traffic
. . | | .
Capacity. . | | .
v . | | v
. |--------------| ---
. | |
v | |
| |
Figure 15: Partial Load of Non-Priority Calls and Partial Load of Priority Calls
図15：非優先コールと優先呼の部分負荷の部分負荷
Figure 16 shows the case where aggregate non-priority and priority load exceeds the bandwidth limit for admission of non-priority traffic. In this situation, any new non-priority session is rejected, while any new priority session is admitted.
図16は、集約非優先および優先負荷が非優先トラフィックの入場のための帯域幅の上限を超えた場合を示しています。任意の新しい優先順位のセッションが入院している間、このような状況では、すべての新しい非優先セッションが、拒否されます。
-----------------------
^ ^ |xxxxxxxxxxxxxx| ^
. . |xxxxxxxxxxxxxx| .
Total . . |xxxxxxxxxxxxxx| . Bandwidth limit
(1) (2) |xxxxxxxxxxxxxx| . (on non-priority + priority)
Engi- . . |oooooooooooooo| . for admission
neered . or . |xxxooxxxooxxxo| . of non-priority traffic
. . |xxoxxxxxxoxxxx| .
Capacity. . |oxxxooooxxxxoo| .
v . |xxoxxxooxxxxxx| v
. |--------------| ---
. |oooooooooooooo|
v | |
| |
Figure 16: Full Non-Priority Load
図16：全非優先ロード
Appendix B. Example Usages of RSVP Extensions
RSVPの拡張の付録B.例用途
This section provides examples of how RSVP extensions defined in this document can be used (in conjunction with other RSVP functionality and SIP functionality) to enforce different hypothetical policies for handling prioritized sessions in a given administrative domain. This appendix does not provide additional specification. It is only included in this document for illustration purposes.
このセクションでは、この文書で定義されたRSVPの拡張機能は、所与の管理ドメイン内の優先セッションを処理するための異なる仮定のポリシーを適用する（他のRSVP機能及びSIP機能と組み合わせて）使用することができる方法の例を提供します。この付録では、追加の仕様を提供していません。これは、説明のみを目的として、この文書に含まれています。
We assume an environment where SIP is used for session control and RSVP is used for resource reservation.
私たちは、SIPは、セッション制御のために使用され、RSVPは、リソース予約のために使用される環境を前提としています。
We refer here to "Session Queueing" as the set of "session-layer" capabilities that may be implemented by SIP user agents to influence their treatment of SIP requests. This may include the ability to "queue" session requests when those cannot be immediately honored (in some cases with the notion of "bumping", or "displacement", of less important session requests from that queue). It may include additional mechanisms such as alternate routing and exemption from certain network management controls.
私たちは、SIPリクエストの彼らの治療に影響を与えるようにSIPユーザエージェントによって実現することができる「セッション層」機能のセットとして「セッションキューイング」をここに参照してください。これは、それらがすぐに（そのキューから重要度の低いセッション要求の「バンピング」、または「変位」の概念といくつかのケースでは）光栄することができない「キュー」セッション要求する能力を備えていてもよいです。そのような特定のネットワーク管理コントロールから代替ルーティングと免除などの追加の機構を含んでもよいです。
We only mention below the RSVP policy elements that are to be enforced by PEPs. It is assumed that these policy elements are set at a policy area boundary by PDPs. The Admission Priority and
我々は唯一のPEPによって強制されるRSVPポリシー要素の下に言及します。これらのポリシー要素は、プラズマディスプレイパネルによって、政策分野の境界に設定されているものとします。入学優先度と
Preemption Priority RSVP policy elements are set by PDPs as a result of processing the Application-Level Resource Priority Policy Element (which is carried in RSVP messages).
先取り優先権RSVPポリシー要素は（RSVPメッセージで運ばれる）アプリケーションレベルリソースプライオリティポリシー要素を処理した結果としてのPDPによって設定されています。
If one wants to implement a prioritized service purely based on Session Queueing, one can achieve this by signaling prioritized sessions:
1は純粋にセッションキューイングに基づいて優先順位付けのサービスを実装したい場合は、1が優先セッションをシグナリングすることによって、これを達成することができます：
o using the "Resource-Priority" header in SIP
SIPにおける「リソース優先」を使用してヘッダO
o not using the Admission-Priority Policy Element in RSVP
O RSVPで入場-重点要素を使用していません
o not using the Preemption Policy Element in RSVP
O RSVPでのプリエンプションポリシー要素を使用していません
If one wants to implement a prioritized service based on Session Queueing and "prioritized access to network-layer resources", one can achieve this by signaling prioritized sessions:
1は、セッションキューイングおよび「ネットワーク層のリソースへのアクセス優先順位」に基づいて優先順位付けのサービスを実装したい場合は、1が優先セッションをシグナリングすることによって、これを達成することができます：
o using the "Resource-Priority" header in SIP
SIPにおける「リソース優先」を使用してヘッダO
o using the Admission-Priority Policy Element in RSVP
RSVPに入学、優先権方針要素を使用してO
o not using the Preemption Policy Element in RSVP
O RSVPでのプリエンプションポリシー要素を使用していません
Establishment of prioritized sessions will not result in preemption of any session. Different bandwidth allocation models can be used to offer different "prioritized access to network-layer resources". Just as examples, this includes setting aside capacity exclusively for prioritized sessions as well as simple bypass of admission limits for prioritized sessions.
優先順位のセッションの確立には、任意のセッションのプリエンプションにはなりません。異なる帯域幅の割り当てモデルは異なる「ネットワーク層のリソースへのアクセスを優先させる」を提供するために使用することができます。あくまで一例として、これは優先順位のセッションだけでなく、優先順位のセッションのため入場制限の簡単なバイパス専用の容量を脇に設定することを含みます。
If one wants to implement a prioritized service based on Session Queueing and "prioritized access to network-layer resources", and wants to ensure that (say) "Prioritized-1" sessions can preempt "Prioritized-2" sessions, but non-prioritized sessions are not affected by preemption, one can do that by signaling prioritized sessions:
1は、セッションキューイングおよび「ネットワーク層のリソースへの優先順位のアクセス」に基づいて優先順位のサービスを実装したい、との点を確認したい場合（例えば）「優先-1」のセッションでは、「優先-2」のセッションを先取りすることができますが、非優先しますセッションがプリエンプションに影響されない、1は優先順位のセッションをシグナリングすることによってそれを行うことができます。
o using the "Resource-Priority" header in SIP
SIPにおける「リソース優先」を使用してヘッダO
o using the Admission-Priority Policy Element in RSVP
RSVPに入学、優先権方針要素を使用してO
o using the Preemption Policy Element in RSVP with:
とRSVPにプリエンプションポリシー要素を使用して、O：
* setup (Prioritized-1) > defending (Prioritized-2)
*設定（優先-1）>（優先-2）を防御
* setup (Prioritized-2) <= defending (Prioritized-1)
*設定（優先-2）<=（優先-1）を防御
* setup (Prioritized-1) <= defending (Non-Prioritized)
*設定（優先-1）<=防御（非優先）
* setup (Prioritized-2) <= defending (Non-Prioritized)
*設定（優先-2）<=防御（非優先）
If one wants to implement a prioritized service based on Session Queueing and "prioritized access to network-layer resources", and wants to ensure that prioritized sessions can preempt regular sessions, one could do that by signaling Prioritized sessions:
1は、セッションキューイングおよび「ネットワーク層のリソースへの優先順位のアクセス」に基づいて優先順位のサービスを実装したい、と優先順位のセッションは、通常のセッションを先取りできることを確認したい場合は、1が優先セッションをシグナリングすることによってそれを行うことができます：
o using the "Resource-Priority" header in SIP
SIPにおける「リソース優先」を使用してヘッダO
o using the Admission-Priority Policy Element in RSVP
RSVPに入学、優先権方針要素を使用してO
o using the Preemption Policy Element in RSVP with:
とRSVPにプリエンプションポリシー要素を使用して、O：
* setup (Prioritized) > defending (Non-Prioritized)
*セットアップ（優先）>ディフェンディ（非優先）
* setup (Non-Prioritized) <= defending (Prioritized)
*セットアップ（非優先）<=ディフェンディング（優先）
If one wants to implement a prioritized service based on Session Queueing and "prioritized access to network-layer resources", and wants to ensure that prioritized sessions can partially preempt regular sessions (i.e., reduce their reservation size), one could do that by signaling prioritized sessions:
1は、セッションキューイングおよび「ネットワーク層のリソースへの優先順位のアクセス」に基づいて優先順位付けのサービスを実装したい、そして部分的に定期的なセッションを先取りすることができ、その優先順位のセッションを確保したい場合は、1シグナリングであることを行うことができ（すなわち、その予約のサイズを小さくします）優先順位のセッション：
o using the "Resource-Priority" header in SIP
SIPにおける「リソース優先」を使用してヘッダO
o using the Admission-Priority Policy Element in RSVP
RSVPに入学、優先権方針要素を使用してO
o using the Preemption Policy Element in RSVP with:
とRSVPにプリエンプションポリシー要素を使用して、O：
* setup (Prioritized) > defending (Non-Prioritized)
*セットアップ（優先）>ディフェンディ（非優先）
* setup (Non-Prioritized) <= defending (Prioritized)
*セットアップ（非優先）<=ディフェンディング（優先）
o activate [RFC4495] RSVP bandwidth reduction mechanisms
O [RFC4495] RSVP帯域幅削減メカニズムを活性化します
Authors' Addresses
著者のアドレス
Francois Le Faucheur Cisco Systems Greenside, 400 Avenue de Roumanille Sophia Antipolis 06410 France
フランソワ・リーパーシスコシステムズグリーンサイド、400アベニューRoumanille 06410ソフィアアンティポリスフランス
Phone: +33 4 97 23 26 19 EMail: flefauch@cisco.com
電話：+33 4 97 23 26 19 Eメール：flefauch@cisco.com
James Polk Cisco Systems 2200 East President George Bush Highway Richardson, TX 75082-3550 United States
ジェームズ・ポークシスコシステムズ2200東ブッシュ大統領ハイウェイ・リチャードソン、テキサス州75082から3550米国
Phone: +1 972 813 5208 EMail: jmpolk@cisco.com
電話：+1 972 813 5208 Eメール：jmpolk@cisco.com
Ken Carlberg G11 123a Versailles Circle Towson, MD 21204 United States
ケン・カールバーグG11 123Aベルサイユサークルタウソン、MD 21204米国
EMail: carlberg@g11.org.uk
メールアドレス：carlberg@g11.org.uk