[要約] RFC 6401は、RSVP（Resource Reservation Protocol）の拡張機能であるAdmission Priorityに関する規格です。このRFCの目的は、ネットワークリソースの予約時に優先度を設定するための方法を提供することです。
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
入場の優先順位のためのRSVP拡張機能
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
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およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。
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で説明されている法的規定のセクション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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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ユーザーエージェント、セッション開始プロトコル（SIP）[RFC3261]が使用中のセッション制御プロトコル）は、セッション確立リクエストの治療に影響を与える可能性があります（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
[RFC3181]は、RSVPで信号を送信できるシグナル先の先制優先ポリシー要素を指定して、ネットワークノードがこのポリシー要素を考慮して、以前に認められたいくつかの優先順位のあるセッションを先取りするために、より新しい、より優先順位のためのスペースを確保するために、セッション。対照的に、このドキュメントは、既存のセッションを先制せずにセッション確立の確率を高めるために、新しいRSVP拡張機能を指定します。これは、帯域幅の割り当てモデルの形式の設計容量技術によって達成されます。特に、このドキュメントは、RSVPノードがセッション入場に基づいて選択的帯域幅の入場管理決定を強制できるように、RSVPシグナリングメッセージ内で入場の優先順位を伝えることができる2つの新しいRSVPポリシー要素を指定しています。
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.
優先順位。このドキュメントの付録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]）で信号されます。現在のIPルーターアラートオプションの使用に関するセキュリティの側面と一般的な慣行と、RSVPなどのアプリケーションによる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アプリケーションレベルのリソース優先ポリシー要素内の新しい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の「入場優先度」レベルにセッションします。次に、PDPSは、このドキュメントで定義されている新しい入学優先度ポリシー要素内でこの情報を伝えます。このように、RSVP入場の優先順位は、LPDPを持つがPDPを制御しないのと同じポリシードメインの下流のPEPS（つまり、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シグナル伝達のためのNSISシグナルレイヤープロトコル（NSLP）など、他のシグナル伝達プロトコルとの境界でも使用できます[RFC5974]。
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入学の優先順位にマッピング/再マッピング/再マッピング/再マッピングするためのフレームワークは、[RFC3181]とともに、アプリケーションレベルのリソースの優先要件をRSVPプリエンプションの優先順位にマッピング/再マッピングするために使用することもできます（プリエンプションは、優先順位付けされたセッション処理ポリシーによって実際に必要であるとみなされます）。その場合、RSVPアプリケーションレベルのリソース優先ポリシー要素を処理する場合、ポリシー境界（またはさまざまなQoSシグナリングプロトコル間）のPDPは、それを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で多くの帯域幅割り当てモデルが定義されています。これらには、[RFC4125]で定義された最大割り当てモデル（MAM）、[RFC4127]で指定されたロシア人形モデル（RDM）、および[RFC4126]で定義された予約（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ルーターが入学制御の決定に影響を与える方法を確認できます（たとえば、どの帯域幅プールが帯域幅の割り当てを実行するために使用するかを決定することにより）。予約施設の。次に、これにより、対応するセッションのアプリケーションレベルのセッション確立の確率が向上します。
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).
* assioni_pri = 0x05（「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)
o Adm。Priority（入場優先度）：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ルーターによって使用され、セッション確立の確率が増加します。入場優先順位値は、使用中の帯域幅制約モデルの帯域幅制約がこの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予約は、入場優先ポリシー要素と先制優先ポリシー要素の両方を運ぶ必要があります。入場の優先順位と先制の優先順位は、LPDPと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:
o ALRPリスト：
* List of ALRPs where each ALRP is encoded as shown in Figure 3.
* 図3に示すように、各ALRPがエンコードされているALRPのリスト。
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オブジェクトが整合性によって保護されている場合、LPDPはそれらを変更しようとしてはなりません。セキュリティエンベロープが無効にされないようにするために、変更なしで転送する必要があります。
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は、入力するアプリケーションレベルのリソース優先要素をマージしてサイズと数を減らすことができます。それらがこれらの要素をマージする場合、LPDPは次のルールに従ってそうしなければなりません。
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リストに表示されるすべてのALRPを含める必要があります。与えられた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で指定されているように、ポリシー無知のノード（PIN）は、Policy_Dataオブジェクトのデフォルトの処理を実装して、これらのオブジェクトがPEPから別のPEPに輸送中にピンを通過できるようにします。これは、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]）で信号されます。現在のIPルーターアラートオプションの使用に関するセキュリティの側面と一般的な慣行と、RSVPなどのアプリケーションによる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]で定義されているように、Policy_Dataオブジェクトのカプセル化により、このドキュメントで定義されているAntimant_priおよびapp_resource_priポリシー要素は、RSVPによってシグナル化されます。したがって、他のポリシー要素と同様に、[RFC2750]のセクション6で2つのオプションのセキュリティメカニズムによって説明されているように、その完全性は保護できます。最初のメカニズムは、[RFC2747]および[RFC3097]で指定されているRSVP認証に依存して、すべてのRSVPノードがポリシー対応である場合に信頼のチェーンを提供します。このメカニズムにより、整合性オブジェクトはRSVPメッセージ内に運ばれます。2番目のメカニズムは、policy_Dataオブジェクト内の整合性オブジェクトに依存して、RSVP近隣ではないRSVP PEP間の完全性を保証します。
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近隣の間で使用できます。RSVP認証（[RFC2747]および[RFC3097]で定義）は、現在のドキュメントの実装によってサポートされる必要があります。
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オブジェクト内の整合性オブジェクトを使用して、非依存性のRSVP PEPS間の整合性を保証できます。これは、一部のRSVPノードがポリシーに無知なノード（PIN）である場合にのみ役立ちます。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.
整合性オブジェクトの内容の計算の詳細は、[RFC2750]の付録Bに記載されています。これは、ポリシー決定ポイント（PDP）がその裁量で、宛先PEP/PDPまたはその他の基準に基づいて、使用する認証キーとハッシュアルゴリズムを選択することを示しています。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
RSVPホップの間に非RSVPホップが存在する可能性がある場合、およびRSVP対応ピンがPEPの間に存在する場合は、PDPがRSVPに含まれるポリシー_DATAオブジェクトの宛先PDPの宛先PDPを決定することは難しい場合があることに注意してください。メッセージ（パスメッセージなど）。これは、これらの場合、メッセージを転送する時点で次のPEPが知られていないためです。この状況では、複数のPDPにわたって共有されたキーが使用される場合があります。これは、議論されているように、複数のRSVPネイバーで共有されたキーの使用に概念的に似ています
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).
[RFC6411]で。また、この問題は、単一（または少ない数の）PDPが、地域のすべてのPEP（管理ドメインなど）を制御するために使用されるいくつかの展開シナリオには存在しない可能性があることも観察します。このようなシナリオでは、PDPが次のホップPEPがわからない場合でも、次の領域が何であるかを判断するだけで、次のホップPPがわからない場合でも、次の領域を決定するのが簡単な場合があります（たとえば、宛先アドレス）。
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]で概説されている「IETFコンセンサス」ポリシーに従ってIANAによって割り当てられます（このポリシーは、[RFC5226に従って「IETFレビュー」と呼ばれます。]）。
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入場優先度のあるポリシー要素のadmistion_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
o 0：予約済み
o 1: Take priority of highest QoS [RFC3181] [RFC6401]
o 1：最高のQoS [RFC3181] [RFC6401]の優先順位
o 2: Take highest priority [RFC3181] [RFC6401]
o 2：最優先事項[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".
[RFC5226]で概説されているポリシーに続いて、0〜127の範囲の数値は「IETFレビュー」ポリシーに従って割り当てられ、128-240の範囲の数字は「First Come First Serve」、241-255の範囲の数字が割り当てられます。「私的使用のために予約されています」。
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-通常のadmision_pri要素に使用される値
o 2: HETEROGENEOUS - This element encountered heterogeneous merge
o 2：不均一 - この要素には不均一なマージが遭遇しました
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).
[RFC5226]で概説されているポリシーに続いて、0〜127の範囲の数値は「IETFレビュー」ポリシーに従って割り当てられ、128-240の範囲の数字は「First Come First Serve」、241-255の範囲の数字が割り当てられます。「私的使用のために予約されています」。値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]".
o 伝説では、「*：[rfc6401]」を記載する行が追加されています。
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:
現在のドキュメントでは、セクション5.2のALRP優先度フィールドを定義します。これには、アプリケーションレベルのリソース優先名画面内の実際のアプリケーションレベルのリソースの優先度を識別する数値を含みます。IANAはすでに、そのような優先順位をすべてリストするリソース優先度の優先順位値レジストリ（SIPパラメーターの下）を維持しています。そのレジストリは、各優先順位値に数値を割り当てるために更新されました。正確には、IANAは次の方法でリソース優先度の優先順位値レジストリを拡張しました。
o For each namespace, the registry is structured with two columns.
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")
o 最初の列には、レジストリで現在定義されているすべての値がリストされています（例：DRSNネームスペース：「ルーチン」、「優先度」、「即時」、「フラッシュ」、「フラッシュオーバーライド」、および「フラッシュオーバーライドオーバーライド」をリストします。））
o The title of the second column is "Priority Numerical Value *".
o 2番目の列のタイトルは「Priority数値 *」です。
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]".
o 伝説では、「*：[rfc6401]」を記載する行が追加されています。
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.
このトピックと進行中のコメントに取り組むための励ましについて、Nguyenに感謝したいと思います。また、この文書は、先制優先政策要素[RFC3181]に関するS. herzogの研究の一部から大きく借りています。Dave OranとJanet Gunnは、この文書に有用な入力を提供しました。Ron Bonica、Magnus Westerlund、Cullen Jennings、Ross Callon、Tim Polkは、この文書で定義されているメカニズムの適用性声明の特定のガイダンスを提供しました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Braden、B.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（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] Baker、F.、Lindell、B。、およびM. Talwar、「RSVP暗号認証」、RFC 2747、2000年1月。
[RFC2750] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000.
[RFC2750] Herzog、S。、「ポリシー管理のためのRSVP拡張」、RFC 2750、2000年1月。
[RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic Authentication -- Updated Message Type Value", RFC 3097, April 2001.
[RFC3097] Braden、R。およびL. Zhang、「RSVP暗号化認証 - 更新されたメッセージタイプ値」、RFC 3097、2001年4月。
[RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element", RFC 3181, October 2001.
[RFC3181] Herzog、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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、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] Camarillo、G.、Marshall、W。、およびJ. Rosenberg、「リソース管理とセッション開始プロトコルの統合（SIP）」、RFC 3312、2002年10月。
[RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource Priority for the Session Initiation Protocol (SIP)", RFC 4412, February 2006.
[RFC4412] Schulzrinne、H。およびJ. Polk、「セッション開始プロトコル（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] Le Faucheur、F.、ed。、「IPルーターのアラートの考慮事項と使用法」、BCP 168、RFC 6398、2011年10月。
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[RFC2113] Katz、D。、「IPルーターアラートオプション」、RFC 2113、1997年2月。
[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, October 1999.
[RFC2711] Partridge、C。およびA. Jackson、「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. Guerin、「政策ベースの入場管理の枠組み」、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] Le Faucheur、F。およびW. Lai、「Diffserv-Aware 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] Ash、J。、「Diffserv-Aware MPLSトラフィックエンジニアリングとパフォーマンスの比較のための予約帯域幅制約モデルによる最大割り当て」、RFC 4126、2005年6月。
[RFC4127] Le Faucheur, F., "Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering", RFC 4127, June 2005.
[RFC4127] Le Faucheur、F。、「Diffserv-Aware 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] Polk、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] MANER、J.、Karagiannis、G。、およびA. McDonald、「サービス品質シグナル伝達のための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] Behringer、M.、Le Faucheur、F。、およびB. Weis、「RSVPセキュリティのためのキーイングメソッドの適用可能性」、RFC 6411、2011年10月。
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は、それぞれ最大割り当てモデル（MAM）[RFC4125]およびロシア人形モデル（RDM）[RFC4127]を使用して入学優先事項をサポートする方法を示しています。予約を備えた最大割り当てモデル（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"は優先セッションを表します
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をさまざまなポリシーに従って設計された容量制限にマッピングできます。優先順位のトラフィックの割合が常にかなり小さいことが確実に知られている場合、エンジニアリング容量制限にいくつかの安全マージンが因数分解される可能性がある場合、オペレーターは、完全に設計された容量制限により、優先順位のトラフィックがこの設計容量の安全マージン内に乗ることができます。このポリシーは、エンジニアリングされたすべての容量が非優先セッションで利用可能になっているため、経済的に魅力的なアプローチと見なすことができます。このポリシーを図4に（1）として示します。例として、特定のリンクのエンジニアリング容量制限がXの場合、演算子はXへの非適合トラフィックで利用可能な帯域幅を構成し、優先トラフィックで利用可能な帯域幅を構成することができます。 Xの5％まで。他の極端では、優先順位のトラフィックの割合が時々有意であり、エンジニアリングされた容量制限が非常に厳しい場合、オペレーターは、利用可能なトラフィックと利用可能な帯域幅を利用できる帯域幅を構成することを決定する場合があります。その合計が設計された容量制限に等しくなるように優先トラフィック。これにより、非優先度と優先度のトラフィック全体の総負荷が常にエンジニアリング容量を下回っていることが保証され、次に、QoSの劣化がないことを保証します。ただし、このポリシーは、優先度の高いセッションが完全なエンジニアリング容量を使用することを妨げるため、経済的に魅力的ではありません。このポリシーは図4に（3）として示されています。例として、特定のリンクのエンジニアリング容量制限がXの場合、演算子はXの95％に非優先順位トラフィックで使用可能な帯域幅を構成し、利用可能な帯域幅を構成することができます。もちろん、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：部分的でない荷重と完全な優先負荷
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への非優先順位トラフィックで利用可能な帯域幅を構成し、Xの105％に非優先順位と優先トラフィックで利用可能な帯域幅を構成することができます。
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：完全な非優先荷重と完全な骨材荷重
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
o 優先セッションがより頻繁に使用される可能性のある混雑期間でさえ、これらのセッションは常に、全体的な負荷のかなり少ない割合を表しています。
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.
設計された容量制限の安全マージン。したがって、たとえそれらがエンジニアリングされた帯域幅のしきい値を超えて認められていても、顕著な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：完全な非プライティ負荷
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
PEPSによって施行されるRSVPポリシー要素の以下のみについて言及します。これらのポリシー要素は、PDPによってポリシーエリアの境界に設定されていると想定されています。入場の優先順位と
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:
純粋にセッションキューイングに基づいて優先順位付けされたサービスを実装したい場合、優先順位付けされたセッションを合図することでこれを達成できます。
o using the "Resource-Priority" header in SIP
o SIPで「リソース優先度」ヘッダーを使用します
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:
セッションキューイングと「ネットワーク層リソースへの優先順位付けアクセス」に基づいて優先順位付けされたサービスを実装したい場合、優先順位付けされたセッションを合図することでこれを達成できます。
o using the "Resource-Priority" header in SIP
o SIPで「リソース優先度」ヘッダーを使用します
o using the Admission-Priority Policy Element in RSVP
o RSVPで入場優先ポリシー要素を使用します
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」セッションが「優先順位付けされた2」セッションを先取りできるが、適切ではないことを確認したい場合セッションは先制の影響を受けません。優先順位付けされたセッションを合図することでそれを行うことができます。
o using the "Resource-Priority" header in SIP
o SIPで「リソース優先度」ヘッダーを使用します
o using the Admission-Priority Policy Element in RSVP
o RSVPで入場優先ポリシー要素を使用します
o using the Preemption Policy Element in RSVP with:
o RSVPで先制ポリシー要素を使用して：
* 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:
セッションキューイングと「ネットワークレイヤーリソースへの優先順位のあるアクセス」に基づいて優先順位付けされたサービスを実装し、優先順位付けされたセッションが定期的なセッションを先取りできるようにしたい場合、優先順位付けされたセッションを合図することでそれを行うことができます。
o using the "Resource-Priority" header in SIP
o SIPで「リソース優先度」ヘッダーを使用します
o using the Admission-Priority Policy Element in RSVP
o RSVPで入場優先ポリシー要素を使用します
o using the Preemption Policy Element in RSVP with:
o RSVPで先制ポリシー要素を使用して：
* 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:
セッションキューイングと「ネットワークレイヤーリソースへの優先順位付けのアクセス」に基づいて優先順位付けされたサービスを実装したい場合、優先順位付けされたセッションが定期的なセッションを部分的に先取りすることができる（つまり、予約サイズを縮小する）ことを望む場合、シグナリングによってそれを行うことができます優先セッション：
o using the "Resource-Priority" header in SIP
o SIPで「リソース優先度」ヘッダーを使用します
o using the Admission-Priority Policy Element in RSVP
o RSVPで入場優先ポリシー要素を使用します
o using the Preemption Policy Element in RSVP with:
o RSVPで先制ポリシー要素を使用して：
* 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
Francois Le Faucheur Cisco Systems Greenside、400 Avenue de Roumanille Sophia Antipolis 06410 France
Phone: +33 4 97 23 26 19
EMail: 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
Ken Carlberg G11 123a Versailles Circle Towson, MD 21204 United States
Ken Carlberg G11 123a Versailles Circle Towson、MD 21204米国
EMail: carlberg@g11.org.uk