Internet Engineering Task Force (IETF) B. Davie
Request for Comments: 6016 F. Le Faucheur
Category: Standards Track A. Narayanan
ISSN: 2070-1721 Cisco Systems, Inc.
October 2010
Support for the Resource Reservation Protocol (RSVP) in Layer 3 VPNs
レイヤ3 VPNにおけるリソース予約プロトコル（RSVP）のサポート
Abstract
抽象
RFC 4364 and RFC 4659 define an approach to building provider-provisioned Layer 3 VPNs (L3VPNs) for IPv4 and IPv6. It may be desirable to use Resource Reservation Protocol (RSVP) to perform admission control on the links between Customer Edge (CE) routers and Provider Edge (PE) routers. This document specifies procedures by which RSVP messages traveling from CE to CE across an L3VPN may be appropriately handled by PE routers so that admission control can be performed on PE-CE links. Optionally, admission control across the provider's backbone may also be supported.
RFC 4364及びRFC 4659は、IPv4とIPv6のためのビルディング・プロバイダ・プロビジョニング・レイヤ3つのVPN（L3VPNs）へのアプローチを定義します。顧客エッジ（CE）ルータとプロバイダエッジ（PE）ルータ間のリンク上のアドミッション制御を実行するためにリソース予約プロトコル（RSVP）を使用することが望ましい場合があります。この文書は、アドミッション制御は、PE-CEリンク上で行うことができるので、L3VPN横切っCEにCEから走行RSVPメッセージを適切PEルータによって処理されるかもしれない手続きを指定します。必要に応じて、プロバイダのバックボーン上アドミッション制御もサポートすることができます。
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/rfc6016.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6016で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 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 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.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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 ....................................................4
1.1. Terminology ................................................5
1.2. Requirements Language ......................................5
2. Problem Statement ...............................................5
2.1. Model of Operation .........................................8
3. Admission Control on PE-CE Links ................................9
3.1. New Objects of Type VPN-IPv4 ...............................9
3.2. Path Message Processing at Ingress PE .....................11
3.3. Path Message Processing at Egress PE ......................12
3.4. Resv Processing at Egress PE ..............................13
3.5. Resv Processing at Ingress PE .............................13
3.6. Other RSVP Messages .......................................14
4. Admission Control in Provider's Backbone .......................14
5. Inter-AS Operation .............................................15
5.1. Inter-AS Option A .........................................15
5.2. Inter-AS Option B .........................................15
5.2.1. Admission Control on ASBR ..........................16
5.2.2. No Admission Control on ASBR .......................16
5.3. Inter-AS Option C .........................................17
6. Operation with RSVP Disabled ...................................17
7. Other RSVP Procedures ..........................................18
7.1. Refresh Overhead Reduction ................................18
7.2. Cryptographic Authentication ..............................18
7.3. RSVP Aggregation ..........................................19
7.4. Support for CE-CE RSVP-TE .................................19
8. Object Definitions .............................................20
8.1. VPN-IPv4 and VPN-IPv6 SESSION Objects .....................20
8.2. VPN-IPv4 and VPN-IPv6 SENDER_TEMPLATE Objects .............21
8.3. VPN-IPv4 and VPN-IPv6 FILTER_SPEC Objects .................22
8.4. VPN-IPv4 and VPN-IPv6 RSVP_HOP Objects ....................22
8.5. Aggregated VPN-IPv4 and VPN-IPv6 SESSION Objects ..........24
8.6. AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6
SENDER_TEMPLATE Objects ...................................26
8.7. AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6
FILTER_SPEC Objects .......................................27
9. IANA Considerations ............................................28
10. Security Considerations .......................................30
11. Acknowledgments ...............................................33
Appendix A. Alternatives Considered .............................34
A.1. GMPLS UNI Approach ........................................34
A.2. Label Switching Approach ..................................34
A.3. VRF Label Approach ........................................34
A.4. VRF Label Plus VRF Address Approach .......................35
References ........................................................35
Normative References ...........................................35
Informative References .........................................36
[RFC4364] and [RFC4659] define a Layer 3 VPN service known as BGP/ MPLS VPNs for IPv4 and for IPv6, respectively. [RFC2205] defines the Resource Reservation Protocol (RSVP), which may be used to perform admission control as part of the Integrated Services (Int-Serv) architecture [RFC1633][RFC2210].
[RFC4364]及び[RFC4659]は、それぞれ、IPv4のBGP / MPLS VPNのようにIPv6のために知られているレイヤ3 VPNサービスを定義します。 [RFC2205]は統合サービス（INT-Servの）アーキテクチャ[RFC1633]、[RFC2210]の一部として、アドミッション制御を実行するために使用することができるリソース予約プロトコル（RSVP）を定義します。
Customers of a Layer 3 VPN service may run RSVP for the purposes of admission control (and associated resource reservation) in their own networks. Since the links between Provider Edge (PE) and Customer Edge (CE) routers in a Layer 3 VPN may often be resource constrained, it may be desirable to be able to perform admission control over those links. In order to perform admission control using RSVP in such an environment, it is necessary that RSVP control messages, such as Path messages and Resv messages, are appropriately handled by the PE routers. This presents a number of challenges in the context of BGP/MPLS VPNs:
レイヤ3 VPNサービスの顧客は、自分のネットワークにアドミッション制御の目的のためにRSVP（および関連するリソースの予約を）実行することができます。レイヤ3でのプロバイダエッジ（PE）とカスタマエッジ間のリンク（CE）ルータのでVPNは、多くの場合、リソースが制約されてもよく、それらのリンク上アドミッション制御を実行できるようにすることが望ましい場合があります。そのような環境でRSVPを使用して、アドミッション制御を実行するために、このようなPathメッセージとRESVメッセージとしてRSVP制御メッセージは、適切PEルータによって処理されることが必要です。これは、BGP / MPLS VPNのの文脈における多くの課題を提示します：
o RSVP Path message processing depends on routers recognizing the Router Alert Option ([RFC2113], [RFC2711]) in the IP header. However, packets traversing the backbone of a BGP/MPLS VPN are MPLS encapsulated, and thus the Router Alert Option may not be visible to the egress PE due to implementation or policy considerations (e.g., if the egress PE processes the message as "pop and go" without examining the IP header).
O RSVP Pathメッセージ処理は、IPヘッダ内のルータ警告オプション（[RFC2113]、[RFC2711]）を認識ルータに依存します。しかし、パケットはBGP / MPLS VPNのバックボーンを通過MPLSカプセル化され、したがって、ルータ警告オプションにより実装またはポリシーの考慮事項（例えば、出口PEがポップ」などのメッセージを処理する場合とに出口PEには見えないかもしれません「）IPヘッダを調べずに行きます。
o BGP/MPLS VPNs support non-unique addressing of customer networks. Thus, a PE at the ingress or egress of the provider backbone may be called upon to process Path messages from different customer VPNs with non-unique destination addresses within the RSVP message. Current mechanisms for identifying customer context from data packets are incompatible with RSVP message processing rules.
O BGP / MPLS VPNは、顧客のネットワークのアドレッシング非ユニークサポートしています。したがって、プロバイダバックボーンの入口または出口におけるPEは、RSVPメッセージ内の非固有の宛先アドレスと異なる顧客のVPNからのPathメッセージを処理するために呼び出されてもよいです。データパケットから顧客のコンテクストを識別するための現在のメカニズムは、RSVPメッセージ処理ルールと互換性がありません。
o A PE at the ingress of the provider's backbone may receive Resv messages corresponding to different customer VPNs from other PEs, and needs to be able to associate those Resv messages with the appropriate customer VPNs.
Oプロバイダのバックボーンの入口におけるPEが他のPEからの異なる顧客のVPNに対応するRESVメッセージを受信し、適切な顧客のVPNを有するものRESVメッセージを関連付けることができる必要ができます。
Further discussion of these issues is presented in Section 2.
これらの問題のさらなる議論は、セクション2に示されています。
This document describes a set of procedures to overcome these challenges and thus to enable admission control using RSVP over the PE-CE links. We note that similar techniques may be applicable to other protocols used for admission control such as the combination of the NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service (QoS) Signaling [RFC5974] and General Internet Signaling Transport (GIST) protocol [RFC5971].
この文書では、これらの課題を克服するため、PE-CEリンク上でRSVPを使用したアドミッション制御を可能にするために、一連の手順を説明します。私たちは、同様の技術は、このようなサービス品質（QoS）のためのNSISシグナリング層プロトコル（NSLP）の組み合わせのようなアドミッション制御のために使用される他のプロトコルシグナリング[RFC5974]と一般的なインターネットシグナリングトランスポート（GIST）のプロトコルにも適用可能であることに注意してください[RFC5971]。
Additionally, it may be desirable to perform admission control over the provider's backbone on behalf of one or more L3VPN customers. Core (P) routers in a BGP/MPLS VPN do not have forwarding entries for customer routes, and thus they cannot natively process RSVP messages for customer flows. Also, the core is a shared resource that carries traffic for many customers, so issues of resource allocation among customers and trust (or lack thereof) also ought to be addressed. This document specifies procedures for supporting such a scenario.
さらに、一つ以上のL3VPNの顧客に代わって、プロバイダのバックボーンを介してアドミッション制御を実行することが望ましいです。 BGP / MPLS VPNコア（P）ルータは、顧客ルートの転送エントリを持っていないので、彼らは、顧客フローのネイティブプロセスRSVPメッセージはできません。顧客の間で資源配分の問題と信頼（またはその欠如）ので、また、コアは、多くの顧客のためのトラフィックを伝送する共有リソースでも対処されるべきです。この文書では、このようなシナリオをサポートするための手順を指定します。
This document deals with establishing reservations for unicast flows only. Because the support of multicast traffic in BGP/MPLS VPNs is still evolving, and raises additional challenges for admission control, we leave the support of multicast flows for further study at this point.
この文書では、ユニキャストフローの予約を確立して扱います。 BGP / MPLS VPNのマルチキャストトラフィックのサポートはまだ発展途上であり、アドミッション制御のための新たな課題を提起しているので、我々はこの時点で、さらなる研究のためのマルチキャストフローのサポートを残します。
This document draws freely on the terminology defined in [RFC2205] and [RFC4364]. For convenience, we provide a few brief definitions here:
このドキュメントは[RFC2205]及び[RFC4364]で定義された用語に自由に描画します。便宜上、ここではいくつかの簡単な定義を提供します。
o Customer Edge (CE) Router: Router at the edge of a customer site that attaches to the network of the VPN provider.
Oのカスタマーエッジ（CE）ルータ：VPNプロバイダのネットワークに接続する顧客サイトのエッジでルータ。
o Provider Edge (PE) Router: Router at the edge of the service provider's network that attaches to one or more customer sites.
Oプロバイダーエッジ（PE）ルータ：1つの以上の顧客サイトに接続する、サービスプロバイダーのネットワークのエッジでルータ。
o VPN Label: An MPLS label associated with a route to a customer prefix in a VPN (also called a VPN route label).
O VPNラベル：VPNにおける顧客プレフィックスへのルートに関連付けられたMPLSラベル（またVPNルートラベルと呼ばれます）。
o VPN Routing and Forwarding (VRF) Table: A PE typically has multiple VRFs, enabling it to be connected to CEs that are in different VPNs.
VPNルーティングおよび転送（VRF）表○：PEは、典型的には、異なるVPNにあるCEに接続することを可能にする、複数のVRFを有しています。
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]に記載されているように解釈されます。
The problem space of this document is the support of admission control between customer sites when the customer subscribes to a BGP/ MPLS VPN. We subdivide the problem into (a) the problem of admission control on the PE-CE links (in both directions) and (b) the problem of admission control across the provider's backbone.
顧客がBGP / MPLS VPNに加入する際に、この文書の問題空間は、顧客のサイト間のアドミッション制御のサポートです。我々は（両方向の）PE-CEリンク上のアドミッション制御の（a）の問題や、プロバイダのバックボーン全体のアドミッション制御の（b）の問題に問題を細分化。
RSVP Path messages are normally addressed to the destination of a session, and contain the Router Alert Option (RAO) within the IP header. Routers along the path to the destination that are configured to process RSVP messages need to detect the presence of the RAO to allow them to intercept Path messages. However, the egress PEs of a network supporting BGP/MPLS VPNs receive packets destined for customer sites as MPLS-encapsulated packets, and they possibly forward those based only on examination of the MPLS label. In order to process RSVP Path messages, the egress VPN PE would have to pop the VPN label and examine the IP header underneath, before forwarding the packet (based on the VPN label disposition rules), which is not a requirement for data packet processing today. Hence, a Path message would be forwarded without examination of the IP options and would therefore not receive appropriate processing at the PE. Another potential issue is doing Connection Admission Control (CAC) at an Autonomous System Border Router (ASBR). Even an implementation that examines the IP header when removing the VPN label (e.g., PE-CE link) would not be able to do CAC at an Option-B ASBR; that requires examining the (interior) IP header while doing a label swap, which is much less desirable behavior.
RSVP Pathメッセージは、通常、セッションの宛先に宛てて、IPヘッダ内のルータ警告オプション（RAO）を含有しています。 RSVPメッセージを処理するように構成されている宛先へのパスに沿ったルータは、彼らがPathメッセージを傍受できるようにRAOの存在を検出する必要があります。しかし、BGP / MPLS VPNをサポートするネットワークの出口のPEは、MPLSカプセル化パケットとして顧客サイト宛てのパケットを受信し、彼らはおそらく、前方これらだけMPLSラベルの検査に基づい。 RSVPのPathメッセージを処理するために、出口VPN PEはVPNラベルをポップしなければならないと（VPNラベル配置規則に基づいて）パケットを転送する前に、下にIPヘッダを調べ、現在のデータパケットの処理のために要求されていません。従って、Pathメッセージは、IPオプションの検査なしで転送されることになる、したがって、PEでの適切な処理を受けないであろう。別の潜在的な問題は、自律システム境界ルータ（ASBR）での接続アドミッション制御（CAC）を行っています。 VPNラベルを削除するとき、IPヘッダを調べても実装（例えば、PE-CEリンク）オプション-BのASBRでCACを実行することができないだろう。それははるかに少ないのが望ましい動作ですラベルスワップを行っている間（内部）IPヘッダを調べる必要となります。
In general, there are significant issues with requiring support for IP Router Alert outside of a controlled, "walled-garden" network, as described in [ALERT-USAGE]. The case of a MPLS L3VPN falls under the "Overlay Model" described therein. Fundamental to this model is that providers would seek to eliminate the requirement to process RAO-marked packets from customers, on any routers except the PEs facing those customers. Issues with requiring interior MPLS routers to process RAO-marked packets are also described in [LER-OPTIONS]. The approach for RSVP packet handling described in this document has the advantage of being independent of any data-plane requirements such as IP Router Alert support within the VPN or examining any IP options for MPLS-encapsulated packets. The only requirement for processing IP Router Alert packets is for RSVP packets received from the CE, which do not carry any MPLS encapsulation.
一般的に、[ALERT-USAGE]に記載されているように、制御された、「ウォールドガーデン」ネットワークのIPルータ警告外部のサポートを必要とするとの重要な問題があります。 MPLS L3VPNの場合は、そこに記載された「オーバーレイモデル」に該当します。このモデルの基本は、プロバイダがそれらの顧客が直面しているのPE以外の任意のルータ上で、お客様からのRAO-マークされたパケットを処理する必要性を排除しようということです。 RAO、マーキングされたパケットを処理するために内部MPLSルータを必要とするとの問題も[LER-OPTIONS]に記載されています。この文書に記載されRSVPパケット処理のためのアプローチは、IPルータ警告VPN内の支持体またはMPLSカプセル化パケットの任意のIPオプションを検査するなどの任意のデータプレーン要件とは無関係であるという利点を有します。 IPルータアラートパケットを処理するための唯一の要件は、任意のMPLSカプセル化を運ばないCEから受信RSVPパケットのためのものです。
For the PE-CE link subproblem, the most basic challenge is that RSVP control messages contain IP addresses that are drawn from the customer's address space, and PEs need to deal with traffic from many customers who may have non-unique (or overlapping) address spaces. Thus, it is essential that a PE be able, in all cases, to identify the correct VPN context in which to process an RSVP control message. The current mechanism for identifying the customer context is the VPN label, which is carried in an MPLS header outside of the RSVP message. This is divergent from the general RSVP model of session identification ([RFC2205], [RFC2209]), which relies solely on RSVP objects to identify sessions. Further, it is incompatible with protocols like COPS/RSVP (Common Open Policy Service) ([RFC2748],
PE-CEリンク部分問題については、最も基本的な課題は、そのRSVP制御メッセージは、顧客のアドレス空間から引き出されているIPアドレスが含まれており、PEは非ユニーク（または重複する）があり、多くの顧客からのトラフィックに対処する必要があるアドレスですスペース。したがって、RSVP制御メッセージを処理するために正しいVPNコンテキストを識別するために、すべての場合において、PEができることが必須です。顧客のコンテクストを識別するための現在のメカニズムは、RSVPメッセージの外MPLSヘッダで運ばれるVPNラベルです。これは、セッションを識別するために、RSVPオブジェクトのみに依存しているセッション識別（[RFC2205]、[RFC2209]）の一般的なRSVPモデルから発散します。さらに、それは、COPS / RSVP（共通オープンポリシーサービス）（[RFC2748]などのプロトコルと互換性がありません。
[RFC2749]), which replace the IP encapsulation of the RSVP message and send only RSVP objects to a COPS server. We believe it is important to retain the model of completely identifying an RSVP session from the contents of RSVP objects. Much of this document deals with this issue.
[RFC2749]）、RSVPメッセージのIPカプセル化を交換し、COPSサーバにのみRSVPオブジェクトを送信します。私たちは、完全にRSVPオブジェクトの内容からRSVPセッションを特定のモデルを維持することが重要であると考えています。このドキュメントの多くは、この問題を扱います。
For the case of making reservations across the provider backbone, we observe that BGP/MPLS VPNs do not create any per-customer forwarding state in the P (provider core) routers. Thus, in order to make reservations on behalf of customer-specified flows, it is clearly necessary to make some sort of aggregated reservation from PE-PE and then map individual, customer-specific reservations onto an aggregate reservation. That is similar to the problem tackled in [RFC3175] and [RFC4804], with the additional complications of handling customer-specific addressing associated with BGP/MPLS VPNs.
プロバイダーバックボーン全体で予約を行う場合のために、私たちはBGP / MPLS VPNのは、P（プロバイダーコア）ルータ内の任意ごとの顧客フォワーディングステートを作成しないことを確認します。したがって、顧客が指定したフローに代わって予約を行うためには、PE-PEから集約の予約のいくつかの並べ替えを行い、次いで凝集予約に個人、顧客固有の予約をマッピングするために明らかに必要です。すなわち、顧客固有の処理の追加の合併症がBGP / MPLS VPNの関連付けられたアドレッシングで、[RFC3175]及び[RFC4804]に取り組む問題と類似しています。
Consider the case where an MPLS VPN customer uses RSVP signaling across his sites for resource reservation and admission control. Let's further assume that, initially, RSVP is not processed through the MPLS VPN cloud (i.e., RSVP messages from the sender to the receiver travel transparently from CE to CE). In that case, RSVP allows the establishment of resource reservations and admission control on a subset of the flow path (from sender to ingress CE, and from the RSVP router downstream of the egress CE to the receiver). If admission control is then activated on any of the CE-PE link, the provider's backbone, or PE-CE link (as allowed by the present document), the customer will benefit from an extended coverage of admission control and resource reservation: the resource reservation will now span over a bigger subset of (and possibly the whole) flow path, which in turn will increase the QoS granted to the corresponding flow. Specific flows whose reservation is successful through admission control on the newly enabled segments will indeed benefit from this quality of service enhancement. However, it must be noted that, in case there are not enough resources on one (or more) of the newly enabled segments (e.g., say admission control is enabled on a given PE-->CE link and there is not enough capacity on that link to admit all reservations for all the flows traversing that link), then some flows will not be able to maintain, or establish, their reservation. While this may appear undesirable for these flows, we observe that this only occurs if there is indeed a lack of capacity on a segment, and that in the absence of admission control, all flows would be established but would all suffer from the resulting congestion on the bottleneck segment. We also observe that, in the case of such a lack of capacity, admission control allows enforcement of controlled and flexible policies (so that, for example, more important flows can be granted higher priority at reserving resources). We note also that flows are given a chance to establish smaller reservations so that the aggregate load can adapt dynamically to the bottleneck capacity.
MPLS VPNの顧客がリソース予約およびアドミッション制御のための彼のサイト間でRSVPシグナリングを使用する場合を考えてみましょう。のは、さらにそれを仮定しましょう、最初は、RSVPがMPLS VPNクラウドを介して処理されていない（すなわち、CEへのCEから透過的に受信機の旅行への送信者からのRSVPメッセージ）。その場合に、RSVPは、（CEを進入する送信者からの、および出力CEの下流RSVPルータから受信機への）流路のサブセットにリソース予約および入場制御の確立を可能にします。リソース：アドミッション制御は、その後（本明細書によって許可されるように）CE-PEリンク、プロバイダのバックボーン、またはPE-CEリンクのいずれかで活性化される場合、顧客は、アドミッション制御及びリソース予約の拡張カバレッジ恩恵を受ける予約は今、順番に対応するフローに付与されたQoSを増加します（そしておそらく全体）の流路の大きなサブセットをまたがっます。その予約新しく有効セグメント上のアドミッション制御を通じて成功する具体的なフローは、実際にサービス強化のこの品質の恩恵を受ける。しかし、新たな有効区間の場合には1つ（またはそれ以上）のに十分なリソースがないことに注意しなければならない（例えば、アドミッション制御は、与えられたPE上で有効になっていると言う - > CEリンクと十分な容量が上存在しませんそのリンクを通過するすべてのフローのすべての予約を）認めるへリンクしているページは、その後、いくつかのフローは、彼らの予約を維持する、または確立することができません。これは、これらの流れのために望ましくない見えるかもしれないが、我々はそこセグメント上の能力の欠如は確かであり、アドミッション制御のない状態で、すべてのフローが確立されるだろうが、すべてが上の結果の渋滞に苦しむだろうと場合にのみ発生することを確認しますボトルネックセグメント。 （例えば、より重要なフローが予約リソースでより高い優先順位を付与することができ、ように）我々はまた、容量の、このような不足の場合には、以下のことを観察し、アドミッション制御は、制御された柔軟なポリシーの実施を可能にします。私たちは、フローが集約負荷がボトルネック容量を動的に適応させることができるように小さな予約を確立する機会を与えられていることにも注意してください。
Figure 1 illustrates the basic model of operation with which this document is concerned.
図1は、この文書が関係する動作の基本的なモデルを示します。
--------------------------
/ Provider \
|----| | Backbone | |----|
Sender->| CE1| |-----| |-----| |CE2 |->Receiver
| |--| | |---| |---| | |---| |
|----| | | | P | | P | | | |----|
| PE1 |---| |-----| |-----| PE2 |
| | | | | | | |
| | |---| |---| | |
|-----| |-----|
| |
\ /
--------------------------
Figure 1. Model of Operation for RSVP-Based Admission
Control over MPLS/BGP VPN
To establish a unidirectional reservation for a point-to-point flow from Sender to Receiver that takes account of resource availability on the CE-PE and PE-CE links only, the following steps need to take place:
唯一のCE-PEおよびPE-CEリンク上のリソースの可用性を考慮したReceiverに送信者からのポイントツーポイントフローの一方向の予約を確立するには、次の手順は場所を取る必要があります。
1. The Sender sends a Path message to an IP address of the Receiver.
1.送信者は、受信側のIPアドレスにパスメッセージを送信します。
2. The Path message is processed by CE1 using normal RSVP procedures and forwarded towards the Receiver along the link CE1-PE1.
2. Pathメッセージは、通常のRSVPの手順を使用してCE1によって処理され、リンクCE1-PE1に沿ってレシーバに向けて転送されます。
3. PE1 processes the Path message and forwards it towards the Receiver across the provider backbone.
3. PE1は、Pathメッセージを処理し、プロバイダのバックボーンを通じてレシーバに向けて転送します。
4. PE2 processes the Path message and forwards it towards the Receiver along link PE2-CE2.
4. PE2は、Pathメッセージを処理し、リンクPE2-CE2に沿ってレシーバに向けて転送します。
5. CE2 processes the Path message using normal RSVP procedures and forwards it towards the Receiver.
5. CE2は、通常のRSVPの手順を使用してPathメッセージを処理し、受信機に向けて転送します。
8. PE2 processes the Resv message (including performing admission control on link PE2-CE2) and sends the Resv message to PE1.
8. PE2は（リンクPE2-CE2にアドミッション制御を実行することを含む）Resvメッセージを処理し、PE1にResvメッセージを送信します。
9. PE1 processes the Resv message and sends the Resv message to CE1.
9. PE1は、Resvメッセージを処理し、CE1にResvメッセージを送信します。
10. CE1 processes the Resv message using normal RSVP procedures, performs admission control on the link CE1-PE1, and sends the Resv message to the Sender if successful.
10. CE1は、通常のRSVPの手順を使用してResvメッセージを処理するリンクCE1-PE1にアドミッション制御を行い、成功した場合、送信者にResvメッセージを送信します。
In each of the steps involving Resv messages (6 through 10) the node sending the Resv message uses the previously established Path state to determine the "RSVP Previous Hop (PHOP)" and sends a Resv message to that address. We note that establishing that Path state correctly at PEs is one of the challenges posed by the BGP/MPLS environment.
RESVメッセージ（〜10 6）を含むステップの各々にResvメッセージを送信するノードは、「RSVP前ホップ（PHOP）」を決定するために、以前に確立されたパスの状態を使用してそのアドレスにResvメッセージを送信します。私たちは、PESで正しくそのパスの状態を確立することBGP / MPLS環境によってもたらされる課題の一つであることに注意してください。
In the following sections, we trace through the steps outlined in Section 2.1 and expand on the details for those steps where standard RSVP procedures need to be extended or modified to support the BGP/ MPLS VPN environment. For all the remaining steps described in the preceding section, standard RSVP processing rules apply.
次のセクションでは、2.1節で説明する手順をトレースして、標準のRSVP手順は、拡張またはBGP / MPLS VPN環境をサポートするように変更する必要があり、これらのステップについて詳細に展開します。前のセクションで説明するすべての残りのステップのために、標準RSVP処理ルールが適用されます。
All the procedures described below support both IPv4 and IPv6 addressing. In all cases where IPv4 is referenced, IPv6 can be substituted with identical procedures and results. Object definitions for both IPv4 and IPv6 are provided in Section 8.
すべての手順は、IPv4とIPv6の両方のアドレッシングをサポート後述します。 IPv4のが参照されるすべての場合において、IPv6は同じ手順および結果で置換することができます。 IPv4とIPv6の両方のためのオブジェクト定義は、セクション8に設けられています。
For RSVP signaling within a VPN, certain RSVP objects need to be extended. Since customer IP addresses need not be unique, the current types of SESSION, SENDER_TEMPLATE, and FILTERSPEC objects are no longer sufficient to globally identify RSVP states in P/PE routers, since they are currently based on IP addresses. We propose new types of SESSION, SENDER_TEMPLATE, and FILTERSPEC objects, which contain globally unique VPN-IPv4 format addresses. The ingress and egress PE nodes translate between the regular IPv4 addresses for messages to and from the CE, and VPN-IPv4 addresses for messages to and from PE routers. The rules for this translation are described in later sections.
VPN内のRSVPシグナリングのために、特定のRSVPオブジェクトは拡張される必要があります。お客様のIPアドレスは一意である必要はありませんので、彼らは現在、IPアドレスに基づいているため、SESSION、SENDER_TEMPLATE、およびFILTERSPECオブジェクトの現在の種類は、世界的にP / PEルータでRSVP状態を識別するために、もはや十分ではありません。私たちは、グローバルに一意なVPN-IPv4形式のアドレスを含むSESSION、SENDER_TEMPLATE、およびFILTERSPECオブジェクトの新しいタイプを、提案します。入力および出力PEノードは、CEへとからのメッセージを正規のIPv4アドレス間の変換、およびVPN-IPv4アドレスへとPEルータからメッセージのアドレス。この変換のための規則は、後のセクションで説明されています。
The RSVP_HOP object in an RSVP message currently specifies an IP address to be used by the neighboring RSVP hop to reply to the message sender. However, MPLS VPN PE routers (especially those separated by Option-B ASBRs) are not required to have direct IP reachability to each other. To solve this issue, we propose the use of label switching to forward RSVP messages between nodes within an MPLS VPN. This is achieved by defining a new VPN-IPv4 RSVP_HOP object. Use of the VPN-IPv4 RSVP_HOP object enables any two adjacent RSVP hops in an MPLS VPN (e.g., a PE in Autonomous System (AS) 1 and a PE in AS2) to correctly identify each other and send RSVP messages directly to each other.
RSVPメッセージ内RSVP_HOPオブジェクトは、現在のメッセージの送信者に返信する隣接RSVPホップで使用するIPアドレスを指定します。しかし、MPLS VPN PEルータ（オプション-BとのASBRによって分離特に）が互いに直接IP到達可能性を有することが必要とされません。この問題を解決するために、我々は、MPLS VPN内のノード間でRSVPメッセージを転送するラベルスイッチングの使用を提案しています。これは、新しいVPN-IPv4のRSVP_HOPオブジェクトを定義することによって達成されます。 VPN-IPv4のRSVP_HOPオブジェクトの使用は、MPLS VPN（例えば、自律システム（AS）1においてPE及びAS2におけるPE）が正しくお互いを識別し、互いに直接RSVPメッセージを送信するための2つの隣接RSVPホップを可能にします。
The VPN-IPv4 RSVP_HOP object carries the IPv4 address of the message sender and a Logical Interface Handle (LIH) as before, but in addition carries a VPN-IPv4 address that also represents the sender of the message. The message sender MUST also advertise this VPN-IPv4 address into BGP, associated with a locally allocated label, and this advertisement MUST be propagated by BGP throughout the VPN and to adjacent ASes if required to provide reachability to this PE. Frames received by the PE marked with this label MUST be given to the local control plane for processing. When a neighboring RSVP hop wishes to reply to a message carrying a VPN-IPv4 RSVP_HOP, it looks for a BGP advertisement of the VPN-IPv4 address contained in that RSVP_HOP. If this address is found and carries an associated label, the neighboring RSVP node MUST encapsulate the RSVP message with this label and send it via MPLS encapsulation to the BGP next hop associated with the route. The destination IP address of the message is taken from the IP address field of the RSVP_HOP object, as described in [RFC2205]. Additionally, the IPv4 address in the RSVP_HOP object continues to be used for all other existing purposes, including neighbor matching between Path/Resv and SRefresh messages [RFC2961], authentication [RFC2747], etc.
VPN-IPv4のRSVP_HOPオブジェクトは、以前のように、メッセージの送信者および論理インターフェイスハンドル（LIH）のIPv4アドレスを運び、それに加えて、メッセージの送信者を表すVPN-IPv4アドレスを運びます。メッセージ送信者はまた、局所的に割り当てられたラベルに関連付けられ、このPEに到達可能性を提供するために必要であれば、この広告は、VPN全体と隣接のASにBGPによって伝播する必要があり、BGPにこのVPN-IPv4アドレスをアドバタイズしなければなりません。このラベルでマークされたPEによって受信されたフレームは、処理のためにローカル制御プレーンに与えられなければなりません。隣接RSVPホップは、VPN-IPv4のRSVP_HOPを運ぶメッセージに返信することを望む場合、そのRSVP_HOPに含まれるVPN-IPv4アドレスのBGP広告を探し。このアドレスが見つかったと関連する標識を搬送する場合、隣接RSVPノードは、このラベルでRSVPメッセージをカプセル化し、ルートに関連付けられたBGPネクストホップへのMPLSカプセル化を介して送信しなければなりません。 [RFC2205]に記載されているように、メッセージの宛先IPアドレスは、RSVP_HOPオブジェクトのIPアドレスフィールドから取られます。また、RSVP_HOPオブジェクト内のIPv4アドレスは、パス/のResvとSRefreshメッセージ[RFC2961]、認証[RFC2747]などの間の隣接マッチングを含め、他のすべての既存の目的のために使用され続け
The VPN-IPv4 address used in the VPN-IPv4 RSVP_HOP object MAY represent an existing address in the VRF that corresponds to the flow (e.g., a local loopback or PE-CE link address within the VRF for this customer), or it MAY be created specially for this purpose. In the case where the address is specially created for RSVP signaling (and possibly other control protocols), the BGP advertisement MUST NOT be redistributed to, or reachable by, any CEs outside the MPLS VPN. One way to achieve this is by creating a special "control protocols VPN" with VRF state on every PE/ASBR, carrying route targets not imported into customer VRFs. In the case where a customer VRF address is used as the VPN-IPv4 address, a VPN-IPv4 address in one customer VRF MUST NOT be used to signal RSVP messages for a flow in a different VRF.
VPN-IPv4のRSVP_HOPオブジェクトで使用VPN-IPv4アドレスは、フロー（例えば、ローカルループバック、またはこの顧客のVRF内のPE-CEリンクアドレス）に対応するVRF内の既存のアドレスを表してもよく、またはそれであってもよいですこの目的のために特別に作成。アドレスは特別RSVPシグナリング（およびおそらく他の制御プロトコル）のために作成された場合には、BGP広告をに再配布してはいけません、またはMPLS VPN外部任意のCEによって到達可能。これを達成する1つの方法は、顧客のVRFにインポートされていないルートターゲットを運ぶ、すべてのPE / ASBR上のVRFの状態で特別な「制御プロトコルVPN」を作成することです。顧客VRFアドレスがVPN-IPv4アドレスとして使用される場合には、一人の顧客VRFでVPN-IPv4アドレスは、異なるVRF内の流れのためのRSVPメッセージを知らせるために使用してはいけません。
If a PE/ASBR is sending a Path message to another PE/ASBR within the VPN, and it has any appropriate VPN-IPv4 address for signaling that satisfies the requirements outlined above, it MUST use a VPN-IPv4 RSVP_HOP object with this address for all RSVP messages within the VPN. If a PE/ASBR does not have any appropriate VPN-IPv4 address to use for signaling, it MAY send the Path message with a regular IPv4 RSVP_HOP object. In this case, the reply will be IP encapsulated. This option is not preferred because there is no guarantee that the neighboring RSVP hop has IP reachability to the sending node. If a PE/ASBR receives or originates a Path message with a VPN-IPv4 RSVP_HOP object, any RSVP_HOP object in corresponding upstream messages for this flow (e.g., Resv, ResvTear) or downstream messages (e.g., ResvError, PathTear) sent by this node within the VPN MUST be a VPN-IPv4 RSVP_HOP.
PE / ASBRは、VPN内の別のPE / ASBRにPathメッセージを送信し、それはそれが上で概説要件を満たすシグナリングするための任意の適切なVPN-IPv4アドレスを持っている場合は、このアドレスをVPN-IPv4のRSVP_HOPオブジェクトを使用する必要がありますVPN内のすべてのRSVPメッセージ。 PE / ASBRは、シグナリングのために使用するための任意の適切なVPN-IPv4アドレスを持っていない場合、それは通常のIPv4のRSVP_HOPオブジェクトにパスメッセージを送信することができます。この場合、応答はIPカプセル化されます。近隣のRSVPホップが送信ノードへのIP到達可能性を持っている保証はありませんので、このオプションは好ましくない。 PE / ASBRは、受信またはこのノードによって送信された（例えば、のResv、たResvTear）または下流メッセージ（例えば、ResvError、PathTear）このフローの上流のメッセージを対応に、VPN-IPv4のRSVP_HOPオブジェクトに任意RSVP_HOPオブジェクトをPathメッセージを発信した場合VPN内VPN-IPv4のRSVP_HOPでなければなりません。
When a Path message arrives at the ingress PE (step 3 of Section 2.1) the PE needs to establish suitable Path state and forward the Path message on to the egress PE. In the following paragraphs, we described the steps taken by the ingress PE.
Pathメッセージは、入口PE（2.1節のステップ3）に到着するとPEは、適切なパスの状態を確立し、出口PEへのPATHメッセージを転送する必要があります。以下の段落では、我々は、入口PEによって取られるステップを説明しました。
The Path message is addressed to the eventual destination (the receiver at the remote customer site) and carries the IP Router Alert Option, in accordance with [RFC2205]. The ingress PE MUST recognize the Router Alert Option, intercept these messages and process them as RSVP signaling messages.
Pathメッセージは、[RFC2205]に従って、IPルータ警告オプションを最終的な目的地（リモート顧客サイトでの受信機）宛てと搬送されます。イングレスPEは、ルータアラートオプションを認識し、これらのメッセージを傍受し、RSVPシグナリングメッセージとして、それらを処理しなければなりません。
As noted above, there is an issue in recognizing Path messages as they arrive at the egress PE (PE2 in Figure 1). The approach defined here is to address the Path messages sent by the ingress PE directly to the egress PE, and send it without the IP Router Alert Option; that is, rather than using the ultimate receiver's destination address as the destination address of the Path message, we use the loopback address of the egress PE as the destination address of the Path message. This approach has the advantage that it does not require any new data-plane capabilities for the egress PE beyond those of a standard BGP/MPLS VPN PE. Details of the processing of this message at the egress PE are described below in Section 3.3. The approach of addressing a Path message directly to an RSVP next hop (that may or may not be the next IP hop) is already used in other environments such as those of [RFC4206] and [RFC4804].
上述したように、それらは出口PE（図1のPE2）に到着するようにPathメッセージを認識に問題があります。ここで定義されたアプローチは、直接出力PEに入力PEによって送信されたPathメッセージに対応し、IPルータアラートオプションなしでそれを送信することです。つまり、むしろPathメッセージの宛先アドレスとして、最終的な受信者の宛先アドレスを使用するよりも、我々は、Pathメッセージの宛先アドレスとして出力PEのループバックアドレスを使用します。このアプローチは、それが標準BGP / MPLS VPN PEのものを超えて出力PEのための新しいデータ・プレーン機能を必要としないという利点を有します。出口PEでのこのメッセージの処理の詳細については、セクション3.3に説明されています。 （つまり、または次のIPホップであってもなくてもよい）RSVP次ホップに直接Pathメッセージに対処するアプローチは、すでに[RFC4206]及び[RFC4804]のもののような他の環境において使用されます。
The details of operation at the ingress PE are as follows. When the ingress PE (PE1 in Figure 1) receives a Path message from CE1 that is addressed to the receiver, the VRF that is associated with the incoming interface is identified, just as for normal data path operations. The Path state for the session is stored, and is associated with that VRF, so that potentially overlapping addresses among different VPNs do not appear to belong to the same session. The destination address of the receiver is looked up in the appropriate VRF, and the BGP next hop for that destination is identified. That next hop is the egress PE (PE2 in Figure 1). A new VPN-IPv4 SESSION object is constructed, containing the Route Distinguisher (RD) that is part of the VPN-IPv4 route prefix for this destination, and the IPv4 address from the SESSION. In addition, a new VPN-IPv4 SENDER_TEMPLATE object is constructed, with the original IPv4 address from the incoming SENDER_TEMPLATE plus the RD that is used by this PE to advertise that prefix for this customer into the VPN. A new Path message is constructed with a destination address equal to the address of the egress PE identified above. This new Path message will contain all the objects from the original Path message, replacing the original SESSION and SENDER_TEMPLATE objects with the new VPN-IPv4 type objects. The Path message is sent without the Router Alert Option and contains an RSVP_HOP object constructed as specified in Section 3.1.
次のように入口PEの動作の詳細です。入口PE（図1のPE1）が受信機宛であるCE1からPathメッセージを受信すると、着信インターフェイスに関連付けられたVRFは、単に通常のデータパス操作用として、識別されます。セッションのパスの状態が保存され、異なるVPN間で潜在的に重複アドレスが同じセッションに属しているように見えないように、そのVRFに関連付けられています。受信機の宛先アドレスは、適切なVRF内で検索され、その宛先のBGPネクストホップが識別されます。その次のホップは、出口PE（図1のPE2）です。新しいVPN-IPv4のセッションオブジェクトは、この宛先のVPN-IPv4ルート接頭語の一部であるルート識別子（RD）、およびセッションからのIPv4アドレスを含む、構成されています。また、新たなVPN-IPv4のSENDER_TEMPLATEオブジェクトは、着信SENDER_TEMPLATEからオリジナルのIPv4アドレスとVPNにこの顧客のためにそのプレフィックスを通知するために、このPEによって使用されるRDと、構成されています。新たなPathメッセージは、上記で同定出口PEのアドレスに等しい宛先アドレスで構成されています。この新たなPathメッセージは、新たなVPN-IPv4のタイプのオブジェクトと元SESSIONとSENDER_TEMPLATEオブジェクトを置き換え、オリジナルのPathメッセージからすべてのオブジェクトが含まれます。 Pathメッセージは、ルータアラートオプションなしで送信され、3.1節で指定されたように構築RSVP_HOPオブジェクトが含まれています。
When a Path message arrives at the egress PE, (step 4 of Section 2.1) it is addressed to the PE itself, and is handed to RSVP for processing. The router extracts the RD and IPv4 address from the VPN-IPv4 SESSION object, and determines the local VRF context by finding a matching VPN-IPv4 prefix with the specified RD that has been advertised by this router into BGP. The entire incoming RSVP message, including the VRF information, is stored as part of the Path state.
Pathメッセージは、出口PE（2.1節のステップ4）に到着すると、それはPE自体にアドレス指定され、そして処理のためにRSVPに渡されます。ルータは、VPN-IPv4のセッション・オブジェクトからRD及びIPv4アドレスを抽出し、BGPにこのルータによってアドバタイズされた指定されたRDとの整合VPN-IPv4のプレフィックスを見つけることによってローカルVRFコンテキストを決定します。 VRF情報を含む全体の着信RSVPメッセージは、パス状態の一部として記憶されます。
Now the RSVP module can construct a Path message that differs from the Path it received in the following ways:
今RSVPモジュールは、次の方法で、受信したPathと異なりPathメッセージを構築することができます。
a. Its destination address is the IP address extracted from the SESSION object;
A。その宛先アドレスは、セッションオブジェクトから抽出されたIPアドレスです。
b. The SESSION and SENDER_TEMPLATE objects are converted back to IPv4-type by discarding the attached RD;
B。 SESSIONとSENDER_TEMPLATEオブジェクトは、添付RDを破棄することで、IPv4型に変換されます。
c. The RSVP_HOP Object contains the IP address of the outgoing interface of the egress PE and a Logical Interface Handle (LIH), as per normal RSVP processing.
C。 RSVP_HOPオブジェクトは、通常のRSVP処理通り、出口PEおよび論理インターフェイスハンドル（LIH）の発信インターフェイスのIPアドレスを含みます。
The router then sends the Path message on towards its destination over the interface identified above. This Path message carries the Router Alert Option as required by [RFC2205].
ルータは、上記に特定インタフェースを介してその先に向けた上でPathメッセージを送信します。 [RFC2205]で必要に応じて、このPathメッセージは、ルータ警告オプションを運びます。
When a receiver at the customer site originates a Resv message for the session, normal RSVP procedures apply until the Resv, making its way back towards the sender, arrives at the "egress" PE (step 8 of Section 2.1). Note that this is the "egress" PE with respect to the direction of data flow, i.e., PE2 in Figure 1. On arriving at PE2, the SESSION and FILTER_SPEC objects in the Resv, and the VRF in which the Resv was received, are used to find the matching Path state stored previously. At this stage, admission control can be performed on the PE-CE link.
顧客サイトでの受信機はセッションのResvメッセージを発信する場合、通常のRSVP手順が送信者に向かってその方法を行うこと、のResvまで適用し、「出口」PE（2.1節のステップ8）に到達します。これはデータフローの方向に対して「出口」PEであることに注意してください、すなわち、図1のPE2 PE2、のResvセッションとFILTER_SPECオブジェクトとのResvが受信されたVRFに到着であります以前に格納されたマッチングパスの状態を見つけるために使用されます。この段階では、アドミッション制御は、PE-CEリンク上で行うことができます。
Assuming admission control is successful, the PE constructs a Resv message to send to the RSVP previous hop stored in the Path state, i.e., the ingress PE (PE1 in Figure 1). The IPv4 SESSION object is replaced with the same VPN-IPv4 SESSION object received in the Path. The IPv4 FILTER_SPEC object is replaced with a VPN-IPv4 FILTER_SPEC object, which copies the VPN-IPv4 address from the SENDER_TEMPLATE received in the matching Path message. The RSVP_HOP in the Resv message MUST be constructed as specified in Section 3.1. The Resv message MUST be addressed to the IP address contained within the RSVP_HOP object in the Path message. If the Path message contained a VPN-IPv4 RSVP_HOP object, the Resv MUST be MPLS encapsulated using the label associated with that VPN-IPv4 address in BGP, as described in Section 3.1. If the Path message contained an IPv4 RSVP_HOP object, the Resv is simply IP encapsulated and addressed directly to the IP address in the RSVP_HOP object.
アドミッション制御と仮定すると成功し、PEはパス状態に格納されているRSVP前のホップに送信するResvメッセージ、すなわち、入口PE（図1のPE1）を構築します。 IPv4のセッションオブジェクトがパスで受信した同一のVPN-IPv4のセッションオブジェクトに置き換えられます。 IPv4のFILTER_SPECオブジェクトはSENDER_TEMPLATEからVPN-IPv4アドレスが一致するPathメッセージで受信したコピーVPN-IPv4のFILTER_SPECオブジェクトに置き換えられます。セクション3.1で指定されたResvメッセージにRSVP_HOPが構築されなければなりません。 Resvメッセージは、PathメッセージでRSVP_HOPオブジェクト内に含まれるIPアドレスに取り組まなければなりません。 Pathメッセージは、VPN-IPv4のRSVP_HOPオブジェクトが含まれている場合、セクション3.1で説明したように、のResvはMPLSは、BGPでそのVPN-IPv4アドレスに関連付けられたラベルを用いてカプセル化されなければなりません。 Pathメッセージは、IPv4 RSVP_HOPオブジェクトが含まれている場合、のResvは単にIPカプセル化とRSVP_HOPオブジェクト内のIPアドレスに直接アドレス指定されます。
If admission control is not successful on the egress PE, a ResvError message is sent towards the receiver as per normal RSVP processing.
アドミッション制御は、出口PEに成功しなかった場合、ResvErrorメッセージは通常のRSVP処理ごとに受信機に向けて送信されます。
Upon receiving a Resv message at the ingress PE (step 8 of Section 2.1) with respect to data flow (i.e., PE1 in Figure 1), the PE determines the local VRF context and associated Path state for this Resv by decoding the received SESSION and FILTER_SPEC objects. It is now possible to generate a Resv message to send to the appropriate CE. The Resv message sent to the ingress CE will contain IPv4 SESSION and FILTER_SPEC objects, derived from the appropriate Path state. Since we assume, in this section, that admission control over the provider's backbone is not needed, the ingress PE does not perform any admission control for this reservation.
データフローに対して（図1において、すなわち、PE1）と入口PE（2.1節のステップ8）でResvメッセージを受信すると、PEは、受信したセッションを復号化し、こののResvのローカルVRFコンテキストと関連付けられたパスの状態を決定しFILTER_SPECオブジェクト。適切なCEに送信するResvメッセージを生成することが可能になりました。入口CEに送信されたResvメッセージは、適切なパスの状態に由来のIPv4 SESSIONとFILTER_SPECオブジェクトを含むであろう。私たちは、このセクションでは、プロバイダのバックボーン上でそのアドミッション制御を必要としないと仮定しているので、入力PEは、この予約のための任意のアドミッション制御を実行しません。
Processing of PathError, PathTear, ResvError, ResvTear, and ResvConf messages is generally straightforward and follows the rules of [RFC2205]. These additional rules MUST be observed for messages transmitted within the VPN (i.e., between the PEs):
PathError、PathTear、ResvError、たResvTear、およびResvConfメッセージの処理は、一般的に簡単で、[RFC2205]の規則に従います。これらの追加の規則はVPN（すなわち、PE間）内で送信されるメッセージのために守らなければなりません。
o The SESSION, SENDER_TEMPLATE, and FILTER_SPEC objects MUST be converted from IPv4 to VPN-IPv4 form and back in the same manner as described above for Path and Resv messages.
SESSION O、SENDER_TEMPLATE、およびFILTER_SPECオブジェクトは、VPN-IPv4のフォームに、バックパスとRESVメッセージについて上述したと同様に、IPv4から変換されなければなりません。
o The appropriate type of RSVP_HOP object (VPN-IPv4 or IPv4) MUST be used as described above.
上記のようにRSVP_HOPオブジェクトの適切なタイプO（VPN-IPv4またはIPv4の）を使用しなければなりません。
o Depending on the type of RSVP_HOP object received from the neighbor, the message MUST be MPLS encapsulated or IP encapsulated as described above.
Oネイバーから受信RSVP_HOPオブジェクトのタイプに応じて、メッセージは、MPLSカプセル化しなければならないか、または上記のようにIPカプセル化。
o The matching state and VRF MUST be determined by decoding the RD and IPv4 addresses in the SESSION and FILTER_SPEC objects.
O整合状態とVRFはSESSIONとFILTER_SPECオブジェクトにRD及びIPv4アドレスをデコードすることにより決定されなければなりません。
o The message MUST be directly addressed to the appropriate PE, without using the Router Alert Option.
メッセージが直接ルータ警告オプションを使用することなく、適切なPEに対処しなければならないO。
The preceding section outlines how per-customer reservations can be made over the PE-CE links. This may be sufficient in many situations where the backbone is well engineered with ample capacity and there is no need to perform any sort of admission control in the backbone. However, in some cases where excess capacity cannot be relied upon (e.g., during failures or unanticipated periods of overload), it may be desirable to be able to perform admission control in the backbone on behalf of customer traffic.
前のセクションごとの顧客予約はPE-CEリンクを介して行うことができる方法を概説します。これは、骨格がよく十分な容量で設計し、バックボーンにアドミッション制御の任意の並べ替えを実行する必要はありませんされ、多くの状況で十分かもしれません。しかし、過剰な容量が（故障または過負荷の予期しない期間中、例えば）に依存することができないいくつかのケースでは、顧客のトラフィックの代わりに、バックボーンにアドミッション制御を実行できるようにすることが望ましい場合があります。
Because of the fact that routes to customer addresses are not present in the P routers, along with the concerns of scalability that would arise if per-customer reservations were allowed in the P routers, it is clearly necessary to map the per-customer reservations described in the preceding section onto some sort of aggregate reservations. Furthermore, customer data packets need to be tunneled across the provider backbone just as in normal BGP/MPLS VPN operation.
そのため、顧客のアドレスへのルートごとの顧客の予約がPルータで許可された場合に生じるであろうスケーラビリティの懸念とともに、Pルータに存在しないという事実のために、それを説明ごとの顧客の予約をマッピングすることが明らかに必要です集約の予約のある種の上前のセクションです。さらに、顧客のデータパケットは、通常のBGP / MPLS VPNの動作と同様に、プロバイダのバックボーンでトンネリングする必要があります。
Given these considerations, a feasible way to achieve the objective of admission control in the backbone is to use the ideas described in [RFC4804]. MPLS-TE tunnels can be established between PEs as a means to perform aggregate admission control in the backbone.
これらの考察を考えると、バックボーンにおけるアドミッション制御の目的を達成するための実現可能な方法は、[RFC4804]で説明アイデアを使用することです。 MPLS-TEトンネルは、バックボーンに集約アドミッション制御を実行するための手段として、PE間で確立することができます。
An MPLS-TE tunnel from an ingress PE to an egress PE can be thought of as a virtual link of a certain capacity. The main change to the procedures described above is that when a Resv is received at the ingress PE, an admission control decision can be performed by checking whether sufficient capacity of that virtual link remains available to admit the new customer reservation. We note also that [RFC4804] uses the IF_ID RSVP_HOP object to identify the tunnel across the backbone, rather than the simple RSVP_HOP object described in Section 3.2. The procedures of [RFC4804] should be followed here as well.
出口PEへの入口PEからMPLS-TEトンネルは、特定の容量の仮想リンクと考えることができます。上述した手順とメイン変化のResvが入口PEで受信される場合、アドミッション制御決定は、その仮想リンクの十分な容量が新たな顧客の予約を認めるために利用可能なままであるかどうかをチェックすることによって行うことができることです。我々は、[RFC4804]はなく、セクション3.2で説明シンプルRSVP_HOPオブジェクトよりも、主鎖を横切ってトンネルを識別するためにIF_ID RSVP_HOPオブジェクトを使用することにも留意されたいです。 [RFC4804]の手順は、ここにも従うべきです。
To achieve effective admission control in the backbone, there needs to be some way to separate the data-plane traffic that has a reservation from that which does not. We assume that packets that are subject to admission control on the core will be given a particular MPLS EXP value, and that no other packets will be allowed to enter the core with this value unless they have passed admission control. Some fraction of link resources will be allocated to queues on core links for packets bearing that EXP value, and the MPLS-TE tunnels will use that resource pool to make their constraint-based routing and admission control decisions. This is all consistent with the principles of aggregate RSVP reservations described in [RFC3175].
バックボーンに効果的なアドミッション制御を実現するために、しないものからの予約を持っているデータプレーントラフィックを分離するために、いくつかの方法が必要。私たちは、コア上のアドミッション制御の対象となるパケットが特定のMPLS EXP値を与え、彼らはアドミッション制御を合格していない限り、他のパケットは、この値でコアに入ることを許可されないことをされることを前提としています。リンクリソースのある割合は、EXP値、およびMPLS-TEトンネルがその制約ベースのルーティングとアドミッション制御決定を行うために、そのリソースプールを使用することを支持するパケットのコアリンク上のキューに割り当てられます。これは、[RFC3175]に記載の集合体RSVP予約の原理と全て一致しています。
[RFC4364] defines three modes of inter-AS operation for MPLS/BGP VPNs, referred to as Options A, B, and C. In the following sections we describe how the scheme described above can operate in each inter-AS environment.
[RFC4364] MPLS / BGP VPNのためのAS間の3つの動作モードを定義するには、我々は、上記のスキームは、各AS間の環境で動作することができる方法を説明し、以下のセクションではオプションA、B、およびCと称される。
Operation of RSVP in Inter-AS Option A is quite straightforward. Each ASBR operates like a PE, and the ASBR-ASBR links can be viewed as PE-CE links in terms of admission control. If the procedures defined in Section 3 are enabled on both ASBRs, then admission control may be performed on the inter-ASBR links. In addition, the operator of each AS can independently decide whether or not to perform admission control across his backbone. The new objects described in this document MUST NOT be sent in any RSVP message between two Option-A ASBRs.
インターASオプションAでのRSVPの動作は非常に簡単です。各ASBRは、PEのように動作し、ASBR-ASBRリンクアドミッション制御の観点からPE-CEリンクと見なすことができます。セクション3で定義された手順は、両方のASBRで有効になっている場合には、アドミッション制御は、インターASBRリンク上で実行されてもよいです。また、各ASのオペレータは、独立して自分のバックボーン上アドミッション制御を実行するかどうかを決定することができます。この文書で説明する新しいオブジェクトは、二つのオプション-AのASBR間の任意のRSVPメッセージで送ってはいけません。
To support inter-AS Option B, we require some additional processing of RSVP messages on the ASBRs. Recall that, when packets are forwarded from one AS to another in Option B, the VPN label is swapped by each ASBR as a packet goes from one AS to another. The
インターASオプションBをサポートするために、我々はASBRは上のRSVPメッセージのいくつかの追加の処理を必要とします。ことを思い出し、パケットはオプションBに別のように一方から転送されたときに、パケットが別のAS一方からなると、VPNラベルが各ASBRによって交換されます。ザ・
BGP next hop seen by the ingress PE will be the ASBR, and there need not be IP visibility between the ingress and egress PEs. Hence, when the ingress PE sends the Path message to the BGP next hop of the VPN-IPv4 route towards the destination, it will be received by the ASBR. The ASBR determines the next hop of the route in a similar way as the ingress PE -- by finding a matching BGP VPN-IPv4 route with the same RD and a matching prefix.
入口PEから見たBGPネクストホップはASBRであり、かつ入口および出口PE間のIP可視ではないが必要であろう。入口PEが宛先に向かってVPN-IPv4ルートのBGPネクストホップへのPathメッセージを送信するときしたがって、それはASBRによって受信されます。 ASBRは、入力PEと同様の方法で経路の次のホップを決定する - 同じRDと一致するプレフィックスと一致するBGP VPN-IPv4ルートを見つけることによって。
The provider(s) who interconnect ASes using Option B may or may not desire to perform admission control on the inter-AS links. This choice affects the detailed operation of ASBRs. We describe the two modes of operation -- with and without admission control at the ASBRs -- in the following sections.
オプションBを使用して相互接続のASは、またはAS間のリンク上のアドミッション制御を実行することを希望してもしなくてもよいプロバイダ（S）。この選択はのASBRの詳細な動作に影響を与えます。 ASBRは時とし、アドミッション制御なし - - 私たちは、2つの動作モードを説明し、次のセクションで。
In this scenario, the ASBR performs full RSVP signaling and admission control. The RSVP database is indexed on the ASBR using the VPN-IPv4 SESSION, SENDER_TEMPLATE, and FILTER_SPEC objects (which uniquely identify RSVP sessions and flows as per the requirements of [RFC2205]). These objects are forwarded unmodified in both directions by the ASBR. All other procedures of RSVP are performed as if the ASBR was an RSVP hop. In particular, the RSVP_HOP objects sent in Path and Resv messages contain IP addresses of the ASBR, which MUST be reachable by the neighbor to whom the message is being sent. Note that since the VPN-IPv4 SESSION, SENDER_TEMPLATE, and FILTER_SPEC objects satisfy the uniqueness properties required for an RSVP database implementation as per [RFC2209], no customer VRF awareness is required on the ASBR.
このシナリオでは、ASBRは、完全なRSVPシグナリングとアドミッション制御を実行します。 RSVPデータベースは、（一意[RFC2205]の要件に従ってRSVPセッションおよびフローを識別）VPN-IPv4のSESSION、SENDER_TEMPLATE、およびFILTER_SPECオブジェクトを使用して、ASBRにインデックスされます。これらのオブジェクトは、ASBRによって両方向に修飾されていない転送されます。 ASBRは、RSVPホップであるかのようにRSVPの他のすべての手順が実行されます。具体的には、パスで送信されたRSVP_HOPオブジェクトとRESVメッセージは、メッセージが送信されて、誰に隣人によって到達可能でなければならない、ASBRのIPアドレスが含まれています。 VPN-IPv4のSESSION、SENDER_TEMPLATE、およびFILTER_SPECオブジェクトは[RFC2209]に従ってRSVPデータベースの実装に必要な一意の特性を満たすため、いかなる顧客VRF意識がASBRに必要とされないことに留意されたいです。
If the ASBR is not doing admission control, it is desirable that per-flow state not be maintained on the ASBR. This requires adjacent RSVP hops (i.e., the ingress and egress PEs of the respective ASes) to send RSVP messages directly to each other. This is only possible if they are MPLS encapsulated. The use of the VPN-IPv4 RSVP_HOP object described in Section 3.1 is REQUIRED in this case.
ASBRは、アドミッション制御を行っていない場合は、フローごとの状態がASBR上で維持されないことが望ましいです。これは、互いに直接RSVPメッセージを送信するために、隣接RSVPホップ（すなわち、それぞれのASの入口および出口のPE）を必要とします。彼らはカプセル化されたMPLSている場合にのみ可能です。セクション3.1で説明VPN-IPv4のRSVP_HOPオブジェクトの使用は、この場合に必要とされます。
When an ASBR that is not installing local RSVP state receives a Path message, it looks up the next hop of the matching BGP route as described in Section 3.2, and sends the Path message to the next hop, without modifying any RSVP objects (including the RSVP_HOP). This process is repeated at subsequent ASBRs until the Path message arrives at a router that is installing local RSVP state (either the ultimate egress PE, or an ASBR configured to perform admission control). This router receives the Path and processes it as described in Section 3.3 if it is a PE, or Section 5.2.1 if it is an
ローカルRSVP状態をインストールされていないASBRは、Pathメッセージを受信した場合、セクション3.2で説明したように、それが一致するBGPルートのネクストホップを検索し、そして（含む任意のRSVPオブジェクトを変更することなく、次のホップにPathメッセージを送信します。 RSVP_HOP）。 Pathメッセージは、ローカルRSVP状態（最終的な出力PE、又はアドミッション制御を実行するように構成されたASBRのいずれか）をインストールしているルータに到着するまで、このプロセスは、後続のASBRで繰り返されます。このルータは、パスを受信している場合、それはPE、または5.2.1である場合、セクション3.3で説明したようにそれを処理します
ASBR performing admission control. When this router sends the Resv upstream, it looks up the routing table for a next hop+label for the VPN-IPv4 address in the PHOP, encapsulates the Resv with that label, and sends it upstream. This message will be received for control processing directly on the upstream RSVP hop (that last updated the RSVP_HOP field in the Path message), without any involvement of intermediate ASBRs.
ASBRは、アドミッション制御を実行します。このルータは、上流のResvを送信すると、それはPHOPでVPN-IPv4アドレスのネクストホップ+ラベルのルーティングテーブルを検索し、そのラベルでのResvをカプセル化し、上流に送信します。このメッセージは、中間のASBRの関与なしに、上流のRSVPホップで直接制御処理（PathメッセージにRSVP_HOPフィールドを更新し、その最後）のために受信されます。
The ASBR is not expected to process any other RSVP messages apart from the Path message as described above. The ASBR also does not need to store any RSVP state. Note that any ASBR along the path that wishes to do admission control or insert itself into the RSVP signaling flow may do so by writing its own RSVP_HOP object with IPv4 and VPN-IPv4 addresses pointing to itself.
ASBRは、上述のように、Pathメッセージとは別に、他のRSVPメッセージを処理することが期待されていません。 ASBRはまた、任意のRSVP状態を保存する必要はありません。アドミッション制御を行うか、RSVPシグナリングフローに自身を挿入することを希望する経路に沿った任意のASBR自体を指しIPv4およびVPN-IPv4のアドレスで独自RSVP_HOPオブジェクトを書き込むことによってこれを行うことができることに留意されたいです。
If an Option-B ASBR that receives an RSVP Path message with an IPv4 RSVP_HOP does not wish to perform admission control but is willing to install local state for this flow, the ASBR MUST process and forward RSVP signaling messages for this flow as described in Section 5.2.1 (with the exception that it does not perform admission control). If an Option-B ASBR receives an RSVP Path message with an IPv4 RSVP_HOP, but does not wish to install local state or perform admission control for this flow, the ASBR MUST NOT forward the Path message. In addition, the ASBR SHOULD send a PathError message of Error Code "RSVP over MPLS Problem" and Error Value "RSVP_HOP not reachable across VPN" (see Section 9) signifying to the upstream RSVP hop that the supplied RSVP_HOP object is insufficient to provide reachability across this VPN. This failure condition is not expected to be recoverable.
IPv4のRSVP_HOPとRSVP Pathメッセージを受信するオプション-BのASBRは、アドミッション制御を行いたいが、このフローのローカル状態をインストールしても構わないと思っていない場合、セクションに記載されているように、ASBRは、このフローのRSVPシグナリングメッセージを処理し、転送する必要があります5.2.1（それはアドミッション制御を行わないことを除いて）。オプション-B ASBRは、IPv4 RSVP_HOPとRSVP Pathメッセージを受信しますが、ローカルの状態をインストールするか、このフローのためのアドミッション制御を実行したくない場合は、ASBRは、Pathメッセージを転送してはなりません。また、ASBRは、エラーコード「MPLS通報上RSVP」とエラー値「VPNを横切る到達できないRSVP_HOP」のPathErrorメッセージを送るべきで供給RSVP_HOPオブジェクトが到達可能性を提供するには不十分である上流のRSVPホップを意味する（セクション9を参照）このVPN間。この障害状態が回復可能であることが予想されていません。
Operation of RSVP in Inter-AS Option C is also quite straightforward, because there exists an LSP directly from ingress PE to egress PE. In this case, there is no significant difference in operation from the single AS case described in Section 3. Furthermore, if it is desired to provide admission control from PE to PE, it can be done by building an inter-AS TE tunnel and then using the procedures described in Section 4.
出口PEへの入口PEから直接LSPが存在するため、インターASオプションCにおけるRSVPの動作は、また、非常に簡単です。それはPEへのPEからのアドミッション制御を提供することが望まれる場合には、この場合には、さらに第3節で説明した場合と、単一の操作で有意な差は存在しない、それは、次いで、インターAS TEトンネルを構築して行うことができますセクション4に記載された手順を使用して。
It is often the case that RSVP will not be enabled on the PE-CE links. In such an environment, a customer may reasonably expect that RSVP messages sent into the L3 VPN network should be forwarded just like any other IP datagrams. This transparency is useful when the customer wishes to use RSVP within his own sites or perhaps to perform admission control on the CE-PE links (in CE->PE direction only), without involvement of the PEs. For this reason, a PE SHOULD NOT discard or modify RSVP messages sent towards it from a CE when RSVP is not enabled on the PE-CE links. Similarly a PE SHOULD NOT discard or modify RSVP messages that are destined for one of its attached CEs, even when RSVP is not enabled on those links. Note that the presence of the Router Alert Option in some RSVP messages may cause them to be forwarded outside of the normal forwarding path, but that the guidance of this paragraph still applies in that case. Note also that this guidance applies regardless of whether RSVP-TE is used in some, all, or none of the L3VPN network.
これは、RSVPは、PE-CEリンク上で有効にされないことが多い場合です。このような環境では、顧客が合理的にL3 VPNネットワークに送信されたRSVPメッセージだけで、他のIPデータグラムのように転送する必要が期待することがあります。顧客はPEの関与なしに、CE-PEリンク（のみCE-> PE方向）にアドミッション制御を実行するために自分のサイト内またはおそらくRSVPを使用したい場合は、この透明性は便利です。このような理由から、PEは、RSVPがPE-CEリンク上で有効になっていませんCEから、それに向けて送信されるRSVPメッセージを破棄するか、変更するべきではありません。同様にPEは、RSVPがそれらのリンク上で有効になっていなくても、その付属のCEの1、のために運命づけられているRSVPメッセージを破棄するか、変更するべきではありません。いくつかのRSVPメッセージ内のルータアラートオプションの存在は、それらが通常の転送パスの外に転送される恐れがありますが、この段落のガイダンスはまだその場合に適用されること。このガイダンスは関係なく、RSVP-TEは、いくつかの中で使用されているかどうかの適用されることにも注意してください、L3VPNネットワークのすべて、またはnone。
This section describes modifications to other RSVP procedures introduced by MPLS VPNs.
このセクションでは、MPLS VPNの導入によって他のRSVP手順の変更を記載しています。
The following points ought to be noted regarding RSVP refresh overhead reduction [RFC2961] across an MPLS VPN:
以下の点は、MPLS VPNを横切るRSVPリフレッシュオーバーヘッド削減[RFC2961]について留意すべきです。
o The hop between the ingress and egress PE of a VPN is to be considered as traversing one or more non-RSVP hops. As such, the procedures described in Section 5.3 of [RFC2961] relating to non-RSVP hops SHOULD be followed.
O VPNの入口と出口PE間のホップは、1つ以上の非RSVPホップを横断するように考慮されるべきです。このように、非RSVPホップに関連する[RFC2961]のセクション5.3に記載された手順に従わされるべきです。
o The source IP address of a SRefresh message MUST match the IPv4 address signaled in the RSVP_HOP object contained in the corresponding Path or Resv message. The IPv4 address in any received VPN-IPv4 RSVP_HOP object MUST be used as the source address of that message for this purpose.
O IPv4アドレスと一致しなければならないSRefreshメッセージの送信元IPアドレスは、対応するパスまたはResvメッセージに含まRSVP_HOPオブジェクトに合図しました。任意にIPv4アドレスは、VPN-IPv4のRSVP_HOPオブジェクトがこの目的のためにそのメッセージの送信元アドレスとして使用しなければなりませんました。
The following points ought to be noted regarding RSVP cryptographic authentication ([RFC2747]) across an MPLS VPN:
以下の点は、MPLS VPNを横切るRSVP暗号化認証（[RFC2747]）について留意すべきです。
o The IPv4 address in any received VPN-IPv4 RSVP_HOP object MUST be used as the source address of that message for purposes of identifying the security association.
O任意にIPv4アドレスは、VPN-IPv4のRSVP_HOPオブジェクトがセキュリティアソシエーションを識別する目的のために、そのメッセージの送信元アドレスとして使用しなければなりませんました。
o Forwarding of Challenge and Response messages MUST follow the same rules as described above for hop-by-hop messages. Specifically, if the originator of a Challenge/Response message has received a VPN-IPv4 RSVP_HOP object from the corresponding neighbor, it MUST use the label associated with that VPN-IPv4 address in BGP to forward the Challenge/Response message.
ホップバイホップメッセージに対して上記のようにOチャレンジとレスポンスメッセージの転送は、同じ規則に従わなければなりません。チャレンジ/レスポンスメッセージの発信者が、対応するネイバーからVPN-IPv4のRSVP_HOPオブジェクトを受信した場合に具体的には、チャレンジ/レスポンスメッセージを転送するBGPでそのVPN-IPv4アドレスに関連付けられたラベルを使用しなければなりません。
[RFC3175] and [RFC4860] describe mechanisms to aggregate multiple individual RSVP reservations into a single larger reservation on the basis of a common Differentiated Services Code Point/Per-Hop Behavior (DSCP/PHB) for traffic classification. The following points ought to be noted in this regard:
[RFC3175]及び[RFC4860]は、トラフィック分類のための一般的な差別化サービスコードポイント/ホップ単位動作（DSCP / PHB）に基づいて単一のより大きな予約に複数の個々のRSVP予約を集約するメカニズムを説明しています。次のポイントは、この点で注意されるべきです：
o The procedures described in this section apply only in the case where the Aggregator and Deaggregator nodes are C/CE devices, and the entire MPLS VPN lies within the Aggregation Region. The case where the PE is also an Aggregator/Deaggregator is more complex and not considered in this document.
oをこのセクションで説明する手順は、アグリゲータおよびデアグリゲータノードがC / CEデバイスであり、全体のMPLS VPNは、アグリゲーション領域内にある場合にのみ適用されます。 PEはまた、アグリゲータ/デアグリゲーターである場合は、より複雑かつ本書で考慮されていません。
o Support of Aggregate RSVP sessions is OPTIONAL. When supported:
集約RSVPセッションのOサポートはオプションです。サポートされた場合：
* Aggregate RSVP sessions MUST be treated in the same way as regular IPv4 RSVP sessions. To this end, all the procedures described in Sections 3 and 4 MUST be followed for aggregate RSVP sessions. The corresponding new SESSION, SENDER_TEMPLATE, and FILTERSPEC objects are defined in Section 8.
*集計RSVPセッションは、通常のIPv4 RSVPセッションと同じように扱われなければなりません。この目的のために、セクション3および4に記載されているすべての手順は、集約RSVPセッションに続かなければなりません。対応する新しいSESSION、SENDER_TEMPLATE、およびFILTERSPECオブジェクトはセクション8で定義されています。
* End-To-End (E2E) RSVP sessions are passed unmodified through the MPLS VPN. These RSVP messages SHOULD be identified by their IP protocol (RSVP-E2E-IGNORE, 134). When the ingress PE receives any RSVP message with this IP protocol, it MUST process this frame as if it is regular customer traffic and ignore any Router Alert Option. The appropriate VPN and transport labels are applied to the frame and it is forwarded towards the remote CE. Note that this message will not be received or processed by any other P or PE node.
*エンドツーエンド（E2E）RSVPセッションは、MPLS VPN経由そのまま渡されます。これらのRSVPメッセージは、IPプロトコル（RSVP-E2E-IGNORE、134）によって識別されるべきです。入口PEが、このIPプロトコルで任意RSVPメッセージを受信すると、それは定期的な顧客のトラフィックであるかのように、このフレームを処理して、任意のルータ警告オプションを無視しなければなりません。適切なVPNおよび輸送ラベルがフレームに適用され、それはリモートCEに向かって転送されます。このメッセージは、他のPまたはPEノードによって受信または処理されないことに注意してください。
* Any SESSION-OF-INTEREST object (defined in [RFC4860]) MUST be conveyed unmodified across the MPLS VPN.
*（[RFC4860]で定義された）すべてのセッションの関心対象は、MPLS VPNを横切って修飾されていない搬送されなければなりません。
[RFC5824] describes a set of requirements for the establishment for CE-CE MPLS LSPs across networks offering an L3VPN service. The requirements specified in that document are similar to those addressed by this document, in that both address the issue of handling RSVP requests from customers in a VPN context. It is possible that the solution described here could be adapted to meet the requirements of [RFC5824]. To the extent that this document uses signaling extensions described in [RFC3473] that have already been used for GMPLS/TE, we expect that CE-CE RSVP/TE will be incremental work built on these extensions. These extensions will be considered in a separate document.
[RFC5824]はL3VPNサービスを提供するネットワークを介しCE-CE MPLSのLSPのために確立するための要件のセットを記述する。 VPNコンテキストにおける顧客からのRSVP要求の処理の問題に対処両方の点で、その文書に指定された要件は、本文書によって対処と同様です。ここで説明するソリューションは、[RFC5824]の要件を満たすように適応される可能性があります。この文書は、すでにGMPLS / TEのために使用されている[RFC3473]で説明したシグナル拡張を使用する限り、私たちは、CE-CEのRSVP / TEは、これらの拡張機能上に構築されたインクリメンタルな作業になることを期待しています。これらの拡張機能は、別の文書に考慮されます。
The usage of the VPN-IPv4 (or VPN-IPv6) SESSION object is described in Sections 3.2 to 3.6. The VPN-IPv4 (or VPN-IPv6) SESSION object appears in RSVP messages that ordinarily contain a SESSION object and are sent between ingress PE and egress PE in either direction. The object MUST NOT be included in any RSVP messages that are sent outside of the provider's backbone (except in the inter-AS Option-B and Option-C cases, as described above, when it may appear on inter-AS links).
VPN-IPv4の（またはVPN-IPv6）のSESSIONオブジェクトの使用量は3.2 3.6節に記載されています。 VPN-IPv4の（またはVPN-IPv6）のSESSIONオブジェクトは通常、セッションオブジェクトを含み、いずれかの方向に入口PEと出口PE間で送信されるRSVPメッセージに現れます。 （上記のように、それがAS間のリンクに表示される場合があり、インターASオプション-BおよびOption-Cの場合を除いて）オブジェクトは、プロバイダのバックボーンの外に送信されるすべてのRSVPメッセージに含まれてはいけません。
The VPN-IPv6 SESSION object is analogous to the VPN-IPv4 SESSION object, using an VPN-IPv6 address ([RFC4659]) instead of an VPN-IPv4 address ([RFC4364]).
VPN-IPv6のセッションオブジェクトはVPN-IPv6アドレス（[RFC 4659]）の代わりに、VPN-IPv4アドレスを使用して、VPN-IPv4のセッションオブジェクトに類似している（[RFC 4364]）。
The formats of the objects are as follows:
次のようにオブジェクトの形式は次のとおりです。
o VPN-IPv4 SESSION object: Class = 1, C-Type = 19
O VPN-IPv4のセッション・オブジェクト：クラス= 1、C-タイプ= 19
+-------------+-------------+-------------+-------------+
| |
+ +
| VPN-IPv4 DestAddress (12 bytes) |
+ +
| |
+-------------+-------------+-------------+-------------+
| Protocol Id | Flags | DstPort |
+-------------+-------------+-------------+-------------+
o VPN-IPv6 SESSION object: Class = 1, C-Type = 20
O VPN-IPv6のセッション・オブジェクト：クラス= 1、C-タイプ= 20
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ VPN-IPv6 DestAddress (24 bytes) +
/ /
. .
/ /
| |
+-------------+-------------+-------------+-------------+
| Protocol Id | Flags | DstPort |
+-------------+-------------+-------------+-------------+
The VPN-IPv4 DestAddress (respectively, VPN-IPv6 DestAddress) field contains an address of the VPN-IPv4 (respectively, VPN-IPv6) address family encoded as specified in [RFC4364] (respectively, [RFC4659]). The content of this field is discussed in Sections 3.2 and 3.3.
VPN-IPv4のDestAddress（それぞれ、VPN-IPv6のDestAddress）フィールドは、[RFC4364]（それぞれ、[RFC4659]）で指定されるように符号化されたVPN-IPv4の（それぞれ、VPN-IPv6）のアドレスファミリのアドレスを含みます。このフィールドの内容は、セクション3.2および3.3に記載されています。
The protocol ID, flags, and DstPort are identical to the same fields in the IPv4 and IPv6 SESSION objects ([RFC2205]).
プロトコルID、フラグ、及びDstPortのは、IPv4およびIPv6 SESSIONオブジェクト内の同じフィールドと同じである（[RFC2205]）。
The usage of the VPN-IPv4 (or VPN-IPv6) SENDER_TEMPLATE object is described in Sections 3.2 and 3.3. The VPN-IPv4 (or VPN-IPv6) SENDER_TEMPLATE object appears in RSVP messages that ordinarily contain a SENDER_TEMPLATE object and are sent between ingress PE and egress PE in either direction (such as Path, PathError, and PathTear). The object MUST NOT be included in any RSVP messages that are sent outside of the provider's backbone (except in the inter-AS Option-B and Option-C cases, as described above, when it may appear on inter-AS links). The format of the object is as follows:
VPN-IPv4の（またはVPN-IPv6）のSENDER_TEMPLATEオブジェクトの使用は、セクション3.2および3.3に記載されています。 VPN-IPv4の（またはVPN-IPv6）のSENDER_TEMPLATEオブジェクトは、通常SENDER_TEMPLATEオブジェクトを含み、（例えばパス、PathError、及びPathTearなど）のいずれかの方向に入口PEと出口PE間で送信されるRSVPメッセージに現れます。 （上記のように、それがAS間のリンクに表示される場合があり、インターASオプション-BおよびOption-Cの場合を除いて）オブジェクトは、プロバイダのバックボーンの外に送信されるすべてのRSVPメッセージに含まれてはいけません。次のようにオブジェクトの形式は次のとおりです。
o VPN-IPv4 SENDER_TEMPLATE object: Class = 11, C-Type = 14
O VPN-IPv4のSENDER_TEMPLATEオブジェクト：クラス= 11、C-タイプ= 14
+-------------+-------------+-------------+-------------+
| |
+ +
| VPN-IPv4 SrcAddress (12 bytes) |
+ +
| |
+-------------+-------------+-------------+-------------+
| Reserved | SrcPort |
+-------------+-------------+-------------+-------------+
o VPN-IPv6 SENDER_TEMPLATE object: Class = 11, C-Type = 15
O VPN-IPv6のSENDER_TEMPLATEオブジェクト：クラス= 11、C-タイプ= 15
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ VPN-IPv6 SrcAddress (24 bytes) +
/ /
. .
/ /
| |
+-------------+-------------+-------------+-------------+
| Reserved | SrcPort |
+-------------+-------------+-------------+-------------+
The VPN-IPv4 SrcAddress (respectively, VPN-IPv6 SrcAddress) field contains an address of the VPN-IPv4 (respectively, VPN-IPv6) address family encoded as specified in [RFC4364] (respectively, [RFC4659]). The content of this field is discussed in Sections 3.2 and 3.3.
VPN-IPv4のsrcaddress送信（それぞれ、VPN-IPv6のsrcaddress送信）フィールドは、[RFC4364]（それぞれ、[RFC4659]）で指定されるように符号化されたVPN-IPv4の（それぞれ、VPN-IPv6）のアドレスファミリのアドレスを含みます。このフィールドの内容は、セクション3.2および3.3に記載されています。
The SrcPort is identical to the SrcPort field in the IPv4 and IPv6 SENDER_TEMPLATE objects ([RFC2205]).
SrcPortは、IPv4およびIPv6 SENDER_TEMPLATEオブジェクト内SrcPortフィールド（[RFC2205]）と同一です。
The Reserved field MUST be set to zero on transmit and ignored on receipt.
予約フィールドは、送信時にゼロに設定して、領収書の上で無視しなければなりません。
The usage of the VPN-IPv4 (or VPN-IPv6) FILTER_SPEC object is described in Sections 3.4 and 3.5. The VPN-IPv4 (or VPN-IPv6) FILTER_SPEC object appears in RSVP messages that ordinarily contain a FILTER_SPEC object and are sent between ingress PE and egress PE in either direction (such as Resv, ResvError, and ResvTear). The object MUST NOT be included in any RSVP messages that are sent outside of the provider's backbone (except in the inter-AS Option-B and Option-C cases, as described above, when it may appear on inter-AS links).
VPN-IPv4の（またはVPN-IPv6）のFILTER_SPECオブジェクトの使用は、セクション3.4および3.5に記載されています。 VPN-IPv4の（またはVPN-IPv6）のFILTER_SPECオブジェクトは、通常FILTER_SPECオブジェクトを含み、（例えばのResv、ResvError、そしてたResvTearなど）のいずれかの方向に入口PEと出口PE間で送信されるRSVPメッセージに現れます。 （上記のように、それがAS間のリンクに表示される場合があり、インターASオプション-BおよびOption-Cの場合を除いて）オブジェクトは、プロバイダのバックボーンの外に送信されるすべてのRSVPメッセージに含まれてはいけません。
o VPN-IPv4 FILTER_SPEC object: Class = 10, C-Type = 14
O VPN-IPv4のFILTER_SPECオブジェクト：クラス= 10、C-タイプ= 14
Definition same as VPN-IPv4 SENDER_TEMPLATE object.
VPN-IPv4のSENDER_TEMPLATEオブジェクトと同じ定義。
o VPN-IPv6 FILTER_SPEC object: Class = 10, C-Type = 15
O VPN-IPv6のFILTER_SPECオブジェクト：クラス= 10、C-タイプ= 15
Definition same as VPN-IPv6 SENDER_TEMPLATE object.
VPN-IPv6のSENDER_TEMPLATEオブジェクトと同じ定義。
The content of the VPN-IPv4 SrcAddress (or VPN-IPv6 SrcAddress) field is discussed in Sections 3.4 and 3.5.
VPN-IPv4のsrcaddress送信（またはVPN-IPv6のsrcaddress送信）フィールドの内容は、セクション3.4および3.5に記載されています。
The SrcPort is identical to the SrcPort field in the IPv4 and IPv6 SENDER_TEMPLATE objects ([RFC2205]).
SrcPortは、IPv4およびIPv6 SENDER_TEMPLATEオブジェクト内SrcPortフィールド（[RFC2205]）と同一です。
The Reserved field MUST be set to zero on transmit and ignored on receipt.
予約フィールドは、送信時にゼロに設定して、領収書の上で無視しなければなりません。
Usage of the VPN-IPv4 (or VPN-IPv6) RSVP_HOP object is described in Sections 3.1 and 5.2.2. The VPN-IPv4 (VPN-IPv6) RSVP_HOP object is used to establish signaling reachability between RSVP neighbors separated by one or more Option-B ASBRs. This object may appear in RSVP messages that carry an RSVP_HOP object, and that travel between the ingress and egress PEs. It MUST NOT be included in any RSVP messages that are sent outside of the provider's backbone (except in the inter-AS Option-B and Option-C cases, as described above, when it may appear on inter-AS links). The format of the object is as follows:
VPN-IPv4の（またはVPN-IPv6）のRSVP_HOPオブジェクトの使用は、セクション3.1及び5.2.2に記載されています。 VPN-IPv4の（VPN-IPv6）のRSVP_HOPオブジェクトは、一つ以上のオプション-BののASBRによって分離されたRSVPネイバ間のシグナリングの到達可能性を確立するために使用されます。このオブジェクトは、RSVP_HOPオブジェクト、および入力および出力PE間その旅を運ぶRSVPメッセージに表示されることがあります。 （それはAS間のリンクに表示されることがあります場合は、上記のように、AS間オプション-BとOption-Cの場合を除いて）これは、プロバイダのバックボーンの外に送信されるすべてのRSVPメッセージに含めることはできません。次のようにオブジェクトの形式は次のとおりです。
o VPN-IPv4 RSVP_HOP object: Class = 3, C-Type = 5
O VPN-IPv4のRSVP_HOPオブジェクト：クラス= 3、C-タイプ= 5
+-------------+-------------+-------------+-------------+
| IPv4 Next/Previous Hop Address (4 bytes) |
+-------------+-------------+-------------+-------------+
| |
+ +
| VPN-IPv4 Next/Previous Hop Address (12 bytes) |
+ +
| |
+-------------+-------------+-------------+-------------+
| Logical Interface Handle |
+-------------+-------------+-------------+-------------+
o VPN-IPv6 RSVP_HOP object: Class = 3, C-Type = 6
O VPN-IPv6のRSVP_HOPオブジェクト：クラス= 3、C-タイプ= 6
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 Next/Previous Hop Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ VPN-IPv6 Next/Previous Hop Address (24 bytes) +
/ /
. .
/ /
| |
+-------------+-------------+-------------+-------------+
| Logical Interface Handle |
+-------------+-------------+-------------+-------------+
The IPv4 Next/Previous Hop Address, IPv6 Next/Previous Hop Address, and the Logical Interface Handle fields are identical to those of the RSVP_HOP object ([RFC2205]).
IPv4の前/次ホップアドレス、IPv6の前/次ホップアドレス、および論理インターフェイスハンドルフィールドはRSVP_HOPオブジェクト（[RFC2205]）のものと同一です。
The VPN-IPv4 Next/Previous Hop Address (respectively, VPN-IPv6 Next/ Previous Hop Address) field contains an address of the VPN-IPv4 (respectively, VPN-IPv6) address family encoded as specified in [RFC4364] (respectively, [RFC4659]). The content of this field is discussed in Section 3.1.
VPN-IPv4の前/次ホップアドレス（それぞれ、VPN-IPv6の次へ/前のホップアドレス）フィールドは、で指定されるように符号化されたVPN-IPv4の（それぞれ、VPN-IPv6）のアドレスファミリのアドレスが含ま[RFC4364]（それぞれ、[ RFC4659]）。このフィールドの内容は3.1節で議論されています。
The usage of Aggregated VPN-IPv4 (or VPN-IPv6) SESSION object is described in Section 7.3. The AGGREGATE-VPN-IPv4 (respectively, AGGREGATE-IPv6-VPN) SESSION object appears in RSVP messages that ordinarily contain a AGGREGATE-IPv4 (respectively, AGGREGATE-IPv6) SESSION object as defined in [RFC3175] and are sent between ingress PE and egress PE in either direction. The GENERIC-AGGREGATE-VPN-IPv4 (respectively, AGGREGATE-VPN-IPv6) SESSION object should appear in all RSVP messages that ordinarily contain a GENERIC-AGGREGATE-IPv4 (respectively, GENERIC-AGGREGATE-IPv6) SESSION object as defined in [RFC4860] and are sent between ingress PE and egress PE in either direction. These objects MUST NOT be included in any RSVP messages that are sent outside of the provider's backbone (except in the inter-AS Option-B and Option-C cases, as described above, when it may appear on inter-AS links). The processing rules for these objects are otherwise identical to those of the VPN-IPv4 (respectively, VPN-IPv6) SESSION object defined in Section 8.1. The format of the object is as follows:
集約VPN-IPv4の（またはVPN-IPv6）のSESSIONオブジェクトの使用は、セクション7.3に記載されています。 AGGREGATE-VPN-IPv4の（それぞれ、集約のIPv6-VPN）セッション・オブジェクトは、通常、[RFC3175]で定義されるように凝集体のIPv4（それぞれ、AGGREGATE-IPv6）のSESSIONオブジェクトを含み、入口PE間で送信されるRSVPメッセージに表示され、いずれかの方向に出口PE。 GENERIC-AGGREGATE-VPN-IPv4アドレス（それぞれ、AGGREGATE-VPN-IPv6）のSESSIONオブジェクトは[RFC4860で定義されるように、通常GENERIC-AGGREGATE-のIPv4（それぞれ、GENERIC-AGGREGATE-IPv6）のセッション・オブジェクトを含む、全てのRSVPメッセージに表示されます]のいずれかの方向に入口PEと出口PE間で送信されます。 （上記のように、それがAS間のリンクに表示される場合があり、インターASオプション-BおよびOption-Cの場合を除いて）これらのオブジェクトは、プロバイダのバックボーンの外に送信されるすべてのRSVPメッセージに含まれてはいけません。これらのオブジェクトの処理規則は、セクション8.1で定義された（それぞれ、VPN-IPv6）のVPN-IPv4のセッション・オブジェクトのものと他の点では同一です。次のようにオブジェクトの形式は次のとおりです。
o AGGREGATE-VPN-IPv4 SESSION object: Class = 1, C-Type = 21
O AGGREGATE-VPN-IPv4のセッション・オブジェクト：クラス= 1、C-タイプ= 21
+-------------+-------------+-------------+-------------+
| |
+ +
| VPN-IPv4 DestAddress (12 bytes) |
+ +
| |
+-------------+-------------+-------------+-------------+
| Reserved | Flags | Reserved | DSCP |
+-------------+-------------+-------------+-------------+
o AGGREGATE-VPN-IPv6 SESSION object: Class = 1, C-Type = 22
O AGGREGATE-VPN-IPv6のセッション・オブジェクト：クラス= 1、C-タイプ= 22
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ VPN-IPv6 DestAddress (24 bytes) +
/ /
. .
/ /
| |
+-------------+-------------+-------------+-------------+
| Reserved | Flags | Reserved | DSCP |
+-------------+-------------+-------------+-------------+
The VPN-IPv4 DestAddress (respectively, VPN-IPv6 DestAddress) field contains an address of the VPN-IPv4 (respectively, VPN-IPv6) address family encoded as specified in [RFC4364] (respectively, [RFC4659]). The content of this field is discussed in Sections 3.2 and 3.3.
VPN-IPv4のDestAddress（それぞれ、VPN-IPv6のDestAddress）フィールドは、[RFC4364]（それぞれ、[RFC4659]）で指定されるように符号化されたVPN-IPv4の（それぞれ、VPN-IPv6）のアドレスファミリのアドレスを含みます。このフィールドの内容は、セクション3.2および3.3に記載されています。
The flags and DSCP are identical to the same fields of the AGGREGATE-IPv4 and AGGREGATE-IPv6 SESSION objects ([RFC3175]).
フラグとDSCPはAGGREGATE-IPv4およびIPv6のAGGREGATE-SESSIONオブジェクトの同じフィールドと同じである（[RFC3175]）。
The Reserved field MUST be set to zero on transmit and ignored on receipt.
予約フィールドは、送信時にゼロに設定して、領収書の上で無視しなければなりません。
o GENERIC-AGGREGATE-VPN-IPv4 SESSION object:
Class = 1, C-Type = 23
+-------------+-------------+-------------+-------------+
| |
+ +
| VPN-IPv4 DestAddress (12 bytes) |
+ +
| |
+-------------+-------------+-------------+-------------+
| Reserved | Flags | PHB-ID |
+-------------+-------------+-------------+-------------+
| Reserved | vDstPort |
+-------------+-------------+-------------+-------------+
| Extended vDstPort |
+-------------+-------------+-------------+-------------+
o GENERIC-AGGREGATE-VPN-IPv6 SESSION object: Class = 1, C-Type = 24
O GENERIC-AGGREGATE-VPN-IPv6のセッション・オブジェクト：クラス= 1、C-タイプ= 24
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ VPN-IPv6 DestAddress (24 bytes) +
/ /
. .
/ /
| |
+-------------+-------------+-------------+-------------+
| Reserved | Flags | PHB-ID |
+-------------+-------------+-------------+-------------+
| Reserved | vDstPort |
+-------------+-------------+-------------+-------------+
| Extended vDstPort |
+-------------+-------------+-------------+-------------+
The VPN-IPv4 DestAddress (respectively, VPN-IPv6 DestAddress) field contains an address of the VPN-IPv4 (respectively, VPN-IPv6) address family encoded as specified in [RFC4364] (respectively, [RFC4659]). The content of this field is discussed in Sections 3.2 and 3.3.
VPN-IPv4のDestAddress（それぞれ、VPN-IPv6のDestAddress）フィールドは、[RFC4364]（それぞれ、[RFC4659]）で指定されるように符号化されたVPN-IPv4の（それぞれ、VPN-IPv6）のアドレスファミリのアドレスを含みます。このフィールドの内容は、セクション3.2および3.3に記載されています。
The flags, PHB-ID, vDstPort, and Extended vDstPort are identical to the same fields of the GENERIC-AGGREGATE-IPv4 and GENERIC-AGGREGATE-IPv6 SESSION objects ([RFC4860]).
フラグは、PHB-ID、vDstPort、および拡張vDstPortはGENERIC-AGGREGATE-IPv4およびGENERIC-AGGREGATE-IPv6のセッションオブジェクト（[RFC4860]）の同じフィールドと同じです。
The Reserved field MUST be set to zero on transmit and ignored on receipt.
予約フィールドは、送信時にゼロに設定して、領収書の上で無視しなければなりません。
The usage of Aggregated VPN-IPv4 (or VPN-IPv6) SENDER_TEMPLATE object is described in Section 7.3. The AGGREGATE-VPN-IPv4 (respectively, AGGREGATE-VPN-IPv6) SENDER_TEMPLATE object appears in RSVP messages that ordinarily contain a AGGREGATE-IPv4 (respectively, AGGREGATE-IPv6) SENDER_TEMPLATE object as defined in [RFC3175] and [RFC4860], and are sent between ingress PE and egress PE in either direction. These objects MUST NOT be included in any RSVP messages that are sent outside of the provider's backbone (except in the inter-AS Option-B and Option-C cases, as described above, when it may appear on inter-AS links). The processing rules for these objects are otherwise identical to those of the VPN-IPv4 (respectively, VPN-IPv6) SENDER_TEMPLATE object defined in Section 8.2. The format of the object is as follows:
集約VPN-IPv4の（またはVPN-IPv6）のSENDER_TEMPLATEオブジェクトの使用法は、セクション7.3に記載されています。 AGGREGATE-VPN-IPv4の（それぞれ、AGGREGATE-VPN-IPv6）はSENDER_TEMPLATEオブジェクトは[RFC3175]及び[RFC4860]で定義されるように、通常、凝集体のIPv4を含むRSVPメッセージ（それぞれ、AGGREGATE-IPv6）のSENDER_TEMPLATEオブジェクトに表示され、そしてありますいずれかの方向に入口PEと出口PE間で送信されます。 （上記のように、それがAS間のリンクに表示される場合があり、インターASオプション-BおよびOption-Cの場合を除いて）これらのオブジェクトは、プロバイダのバックボーンの外に送信されるすべてのRSVPメッセージに含まれてはいけません。これらのオブジェクトの処理規則は、セクション8.2で定義された（それぞれ、VPN-IPv6）のVPN-IPv4のSENDER_TEMPLATEオブジェクトのものと他の点では同一です。次のようにオブジェクトの形式は次のとおりです。
o AGGREGATE-VPN-IPv4 SENDER_TEMPLATE object:
Class = 11, C-Type = 16
+-------------+-------------+-------------+-------------+
| |
+ +
| VPN-IPv4 AggregatorAddress (12 bytes) |
+ +
| |
+-------------+-------------+-------------+-------------+
o AGGREGATE-VPN-IPv6 SENDER_TEMPLATE object: Class = 11, C-Type = 17
O AGGREGATE-VPN-IPv6のSENDER_TEMPLATEオブジェクト：クラス= 11、C-タイプ= 17
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ VPN-IPv6 AggregatorAddress (24 bytes) +
/ /
. .
/ /
| |
+-------------+-------------+-------------+-------------+
The VPN-IPv4 AggregatorAddress (respectively, VPN-IPv6 AggregatorAddress) field contains an address of the VPN-IPv4 (respectively, VPN-IPv6) address family encoded as specified in [RFC4364] (respectively, [RFC4659]). The content and processing rules for these objects are similar to those of the VPN-IPv4 SENDER_TEMPLATE object defined in Section 8.2.
VPN-IPv4のAggregatorAddress（それぞれ、VPN-IPv6のAggregatorAddress）フィールドは、[RFC4364]（それぞれ、[RFC4659]）で指定されるように符号化されたVPN-IPv4の（それぞれ、VPN-IPv6）のアドレスファミリのアドレスを含みます。これらのオブジェクトの内容と処理規則は、セクション8.2で定義されたVPN-IPv4のSENDER_TEMPLATEオブジェクトと同様です。
The flags and DSCP are identical to the same fields of the AGGREGATE-IPv4 and AGGREGATE-IPv6 SESSION objects.
フラグとDSCPはAGGREGATE-IPv4およびIPv6のAGGREGATE-SESSIONオブジェクトの同じフィールドと同じです。
The usage of Aggregated VPN-IPv4 FILTER_SPEC object is described in Section 7.3. The AGGREGATE-VPN-IPv4 FILTER_SPEC object appears in RSVP messages that ordinarily contain a AGGREGATE-IPv4 FILTER_SPEC object as defined in [RFC3175] and [RFC4860], and are sent between ingress PE and egress PE in either direction. These objects MUST NOT be included in any RSVP messages that are sent outside of the provider's backbone (except in the inter-AS Option-B and Option-C cases, as described above, when it may appear on inter-AS links).
集約VPN-IPv4のFILTER_SPECオブジェクトの使用量は、7.3節に記載されています。 AGGREGATE-VPN-IPv4のFILTER_SPECオブジェクトは[RFC3175]及び[RFC4860]で定義され、そしていずれかの方向に入口PEと出口PE間で送信されるように、通常、凝集体のIPv4 FILTER_SPECオブジェクトを含むRSVPメッセージに現れます。 （上記のように、それがAS間のリンクに表示される場合があり、インターASオプション-BおよびOption-Cの場合を除いて）これらのオブジェクトは、プロバイダのバックボーンの外に送信されるすべてのRSVPメッセージに含まれてはいけません。
The processing rules for these objects are otherwise identical to those of the VPN-IPv4 FILTER_SPEC object defined in Section 8.3. The format of the object is as follows:
これらのオブジェクトの処理規則は、セクション8.3で定義されたVPN-IPv4のFILTER_SPECオブジェクトのものと他の点では同一です。次のようにオブジェクトの形式は次のとおりです。
o AGGREGATE-VPN-IPv4 FILTER_SPEC object: Class = 10, C-Type = 16
O AGGREGATE-VPN-IPv4のFILTER_SPECオブジェクト：クラス= 10、C-タイプ= 16
Definition same as AGGREGATE-VPN-IPv4 SENDER_TEMPLATE object.
AGGREGATE-VPN-IPv4のSENDER_TEMPLATEオブジェクトと同じ定義。
o AGGREGATE-VPN-IPv6 FILTER_SPEC object: Class = 10, C-Type = 17
O AGGREGATE-VPN-IPv6のFILTER_SPECオブジェクト：クラス= 10、C-タイプ= 17
Definition same as AGGREGATE-VPN-IPv6 SENDER_TEMPLATE object.
AGGREGATE-VPN-IPv6のSENDER_TEMPLATEオブジェクトと同じ定義。
Section 8 defines new objects. Therefore, IANA has modified the RSVP parameters registry, 'Class Names, Class Numbers, and Class Types' subregistry, and:
第8章は、新しいオブジェクトを定義します。したがって、IANAは、「クラス名、クラス番号を、そしてクラスの種類] RSVPパラメータレジストリを修正副登録、及びました：
o assigned six new C-Types under the existing SESSION Class (Class number 1), as follows:
次のようにO、既存のセッションクラス（クラス番号1）の下に6つの新しいC-タイプの割り当て：
Class
Number Class Name Reference
------ ----------------------- ---------
1 SESSION [RFC2205]
1 SESSION [RFC2205]
Class Types or C-Types:
クラスの型やC-タイプ：
.. ... ... 19 VPN-IPv4 [RFC6016] 20 VPN-IPv6 [RFC6016] 21 AGGREGATE-VPN-IPv4 [RFC6016] 22 AGGREGATE-VPN-IPv6 [RFC6016] 23 GENERIC-AGGREGATE-VPN-IPv4 [RFC6016] 24 GENERIC-AGGREGATE-VPN-IPv6 [RFC6016]
.. ... 19 VPN-IPv4の[RFC6016] 20 VPN-のIPv6 [RFC6016] 21 AGGREGATE-VPN-IPv4の[RFC6016] 22 AGGREGATE-VPN-のIPv6 [RFC6016] 23 GENERIC-AGGREGATE-VPN-IPv4の[RFC6016 24 GENERIC-AGGREGATE-VPN-のIPv6 [RFC6016]
o assigned four new C-Types under the existing SENDER_TEMPLATE Class (Class number 11), as follows:
Oの下つの新しいC-タイプの割り当て既存のSENDER_TEMPLATEクラス（クラス番号11）、次のように
Class
Number Class Name Reference
------ ----------------------- ---------
11 SENDER_TEMPLATE [RFC2205]
11 SENDER_TEMPLATE [RFC2205]
Class Types or C-Types:
クラスの型やC-タイプ：
.. ... ... 14 VPN-IPv4 [RFC6016] 15 VPN-IPv6 [RFC6016] 16 AGGREGATE-VPN-IPv4 [RFC6016] 17 AGGREGATE-VPN-IPv6 [RFC6016]
.. ... 14 VPN-IPv4の[RFC 6016] 15 VPN-のIPv6 [RFC 6016] 16 AGGREGATE-VPN-IPv4の[RFC6016] 17 AGGREGATE-VPN-のIPv6 [RFC6016]
o assigned four new C-Types under the existing FILTER_SPEC Class (Class number 10), as follows:
Oの下つの新しいC-タイプを割り当て、既存FILTER_SPECクラス（クラス番号10）、次のように
Class
Number Class Name Reference
------ ----------------------- ---------
10 FILTER_SPEC [RFC2205]
10 FILTER_SPEC [RFC2205]
Class Types or C-Types:
クラスの型やC-タイプ：
.. ... ... 14 VPN-IPv4 [RFC6016] 15 VPN-IPv6 [RFC6016] 16 AGGREGATE-VPN-IPv4 [RFC6016] 17 AGGREGATE-VPN-IPv6 [RFC6016]
.. ... 14 VPN-IPv4の[RFC 6016] 15 VPN-のIPv6 [RFC 6016] 16 AGGREGATE-VPN-IPv4の[RFC6016] 17 AGGREGATE-VPN-のIPv6 [RFC6016]
o assigned two new C-Types under the existing RSVP_HOP Class (Class number 3), as follows:
Oの下に2つの新しいC-タイプを割り当て、既存RSVP_HOPクラス（クラス番号3）、次のように
Class
Number Class Name Reference
------ ----------------------- ---------
3 RSVP_HOP [RFC2205]
3 RSVP_HOP [RFC2205]
Class Types or C-Types:
クラスの型やC-タイプ：
.. ... ... 5 VPN-IPv4 [RFC6016] 6 VPN-IPv6 [RFC6016]
.. ... 5 VPN-IPv4の[RFC6016] 6 VPN-のIPv6 [RFC6016]
In addition, a new PathError code/value is required to identify a signaling reachability failure and the need for a VPN-IPv4 or VPN-IPv6 RSVP_HOP object as described in Section 5.2.2. Therefore, IANA has modified the RSVP parameters registry, 'Error Codes and Globally-Defined Error Value Sub-Codes' subregistry, and:
加えて、新しいPathErrorコード/値はセクション5.2.2で説明したようにシグナリング到達性障害およびVPN-IPv4またはIPv6のVPN-RSVP_HOPオブジェクトの必要性を識別するために必要とされます。したがって、IANAは、「エラーコードおよびグローバル定義のエラー値サブコード」副登録をRSVPパラメータのレジストリを変更し、しています：
o assigned a new Error Code and sub-code, as follows:
次のようにO、新しいエラーコードとサブコードを割り当て：
37 RSVP over MPLS Problem [RFC6016]
MPLS問題[RFC6016]上37 RSVP
This Error Code has the following globally-defined Error
Value sub-codes:
1 = RSVP_HOP not reachable across VPN [RFC6016]
VPN [RFC6016]を横切って到達可能ではない1 = RSVP_HOP
[RFC4364] addresses the security considerations of BGP/MPLS VPNs in general. General RSVP security considerations are discussed in [RFC2205]. To ensure the integrity of RSVP, the RSVP Authentication mechanisms defined in [RFC2747] and [RFC3097] SHOULD be supported. Those protect RSVP message integrity hop-by-hop and provide node authentication as well as replay protection, thereby protecting against corruption and spoofing of RSVP messages. [RSVP-KEYING] discusses applicability of various keying approaches for RSVP Authentication. First, we note that the discussion about applicability of group keying to an intra-provider environment where RSVP hops are not IP hops is relevant to securing of RSVP among PEs of a given Service Provider deploying the solution specified in the present document. We note that the RSVP signaling in MPLS VPN is likely to spread over multiple administrative domains (e.g., the service provider operating the VPN service, and the customers of the service). Therefore the considerations in [RSVP-KEYING] about inter-domain issues are likely to apply.
[RFC4364]は、一般的にBGP / MPLS VPNのセキュリティの考慮事項に対処しています。一般的なRSVPのセキュリティの考慮事項は、[RFC2205]で議論されています。 RSVPの整合性を保証するために、[RFC2747]及び[RFC3097]で定義されたRSVP認証メカニズムがサポートされるべきです。これらの保護RSVPメッセージ完全性ホップバイホップ、それによってRSVPメッセージの破損やなりすましに対する保護、ノード認証ならびにリプレイ保護を提供します。 [RSVP-KEYING]はRSVP認証するための各種キーのアプローチの適用可能性を論じています。まず、RSVPホップがIPホップではありません、イントラプロバイダー環境へのキーインググループの適用性に関する議論は現在のドキュメントで指定されたソリューションを展開する特定のサービスプロバイダのPEの間でRSVPの確保に関連していることに注意してください。私たちは、MPLS VPNにRSVPシグナリングは、複数の管理ドメインに広がる可能性があることに注意してください（例えば、VPNサービスを操作し、サービスプロバイダ、およびサービスの顧客）。そのため、ドメイン間の問題について[RSVP-KEYING]での考慮事項が適用する可能性があります。
Since RSVP messages travel through the L3VPN cloud directly addressed to PE or ASBR routers (without IP Router Alert Option), P routers remain isolated from RSVP messages signaling customer reservations. Providers MAY choose to block PEs from sending datagrams with the Router Alert Option to P routers as a security practice, without impacting the functionality described herein.
RSVPメッセージは、直接（IPルータ警告オプションなし）PEまたはASBRルータ宛L3VPN雲を通って移動するので、Pルータは、顧客の予約シグナリングRSVPメッセージから単離されたままです。プロバイダは、ここで説明した機能に影響を与えることなく、セキュリティプラクティスとして、Pルータにルータアラートオプションを持つデータグラムを送信してからのPEをブロックするために選ぶかもしれません。
Beyond those general issues, four specific issues are introduced by this document: resource usage on PEs, resource usage in the provider backbone, PE route advertisement outside the AS, and signaling exposure to ASBRs and PEs. We discuss these in turn.
PE上のリソース使用量、プロバイダのバックボーン内のリソースの使用状況、AS外部のPEルート広告を、とのASBRおよびPEへの暴露を知らせる：これらの一般的な問題以外にも、4つの特定の問題は、このドキュメントで紹介されています。私たちは、順番にこれらを議論します。
A customer who makes resource reservations on the CE-PE links for his sites is only competing for link resources with himself, as in standard RSVP, at least in the common case where each CE-PE link is dedicated to a single customer. Thus, from the perspective of the CE-PE links, the present document does not introduce any new security issues. However, because a PE typically serves multiple customers, there is also the possibility that a customer might attempt to use excessive computational resources on a PE (CPU cycles, memory, etc.) by sending large numbers of RSVP messages to a PE. In the extreme, this could represent a form of denial-of-service attack. In order to prevent such an attack, a PE SHOULD support mechanisms to limit the fraction of its processing resources that can be consumed by any one CE or by the set of CEs of a given customer. For example, a PE might implement a form of rate limiting on RSVP messages that it receives from each CE. We observe that these security risks and measures related to PE resource usage are very similar for any control-plane protocol operating between CE and PE (e.g., RSVP, routing, multicast).
彼のサイトのCE-PEリンクのリソース予約を行い、顧客は、少なくとも各CE-PEリンクは単一の顧客に専用されている一般的な場合には、標準のRSVPのように、自分自身とリンク資源のために競合しています。このように、CE-PEリンクの観点から、現在のドキュメントはどんな新しいセキュリティ問題を紹介しません。 PEは、通常、複数の顧客にサービスを提供しているためしかし、顧客はPEにRSVPメッセージを大量に送信することにより、PEに過度の計算リソース（CPUサイクル、メモリなど）を使用しようとするかもしれないという可能性もあります。極端な場合、これは、サービス拒否攻撃の形を表すことができます。このような攻撃を防止するために、PEは、任意の1つのCEによって、または所与の顧客のCEの組によって消費することができ、その処理リソースの割合を制限するためのメカニズムをサポートしなければなりません。例えば、PEは、各CEから受信したRSVPメッセージ上のレート制限の形態を実現するかもしれません。我々は、これらのセキュリティリスクとPEリソースの使用に関連する措置がCEおよびPE（例えば、RSVP、ルーティング、マルチキャスト）の間で動作する任意の制御プレーンプロトコルのために非常に類似していることを観察します。
The second concern arises only when the service provider chooses to offer resource reservation across the backbone, as described in Section 4. In this case, the concern may be that a single customer might attempt to reserve a large fraction of backbone capacity, perhaps with a coordinated effort from several different CEs, thus denying service to other customers using the same backbone. [RFC4804] provides some guidance on the security issues when RSVP reservations are aggregated onto MPLS tunnels, which are applicable to the situation described here. We note that a provider MAY use local policy to limit the amount of resources that can be reserved by a given customer from a particular PE, and that a policy server could be used to control the resource usage of a given customer across multiple PEs if desired. It is RECOMMENDED that an implementation of this specification support local policy on the PE to control the amount of resources that can be reserved by a given customer/CE.
サービスプロバイダはこの場合には、セクション4で説明したように、バックボーン上のリソース予約を提供することを選択した場合にのみ、第二の懸念が生じる懸念は、単一の顧客がで恐らく、バックボーン容量の大部分を予約しようとするかもしれないとすることができますいくつかの異なるのCEからの協調努力は、これと同じバックボーンを使用して他の顧客へのサービス拒否攻撃します。 [RFC4804]はRSVP予約が、ここで説明したような状況に適用されるMPLSトンネル、上に集約されているセキュリティ上の問題に関するいくつかのガイダンスを提供します。我々は、プロバイダが特定のPEからの顧客によって予約することができるリソースの量を制限するために、ローカルポリシーを使用できることに注意し、必要に応じて、ポリシーサーバーは、複数のPEを横切る所与の顧客のリソース使用量を制御するために使用することができること。 PE上の本明細書のサポート、ローカルポリシーの実装では、所与の顧客/ CEによって確保することができるリソースの量を制御することが推奨されます。
Use of the VPN-IPv4 RSVP_HOP object requires exporting a PE VPN-IPv4 route to another AS, and potentially could allow unchecked access to remote PEs if those routes were indiscriminately redistributed. However, as described in Section 3.1, no route that is not within a customer's VPN should ever be advertised to (or be reachable from) that customer. If a PE uses a local address already within a customer VRF (like PE-CE link address), it MUST NOT send this address in any RSVP messages in a different customer VRF. A "control-plane" VPN MAY be created across PEs and ASBRs and addresses in this VPN can be used to signal RSVP sessions for any customers, but these routes MUST NOT be advertised to, or made reachable from, any customer. An implementation of the present document MAY support such operation using a "control-plane" VPN. Alternatively, ASBRs MAY implement the signaling procedures described in Section 5.2.1, even if admission control is not required on the inter-AS link, as these procedures do not require any direct P/PE route advertisement out of the AS.
VPN-IPv4のRSVP_HOPオブジェクトの使用は、別のASへPE VPN-IPv4ルートをエクスポートし、そして潜在的にそれらのルートを無差別に再配布された場合、リモートPEへ未チェックのアクセスを許可する可能性が必要です。 3.1節で説明したようにしかし、顧客のVPN内にない全くルートは、これまでにアドバタイズしない（またはから到達可能である）その顧客べきです。 PEは（PE-CEリンクアドレスなど）顧客のVRF内、既にローカルアドレスを使用している場合、それは別の顧客のVRF内の任意のRSVPメッセージでこのアドレスを送ってはいけません。 「コントロールプレーンは、」VPNは、このVPNでのPEとのASBRとアドレス間で作成される任意の顧客のためのRSVPセッションを通知するために使用することができますが、これらの空路はにアドバタイズ、または任意の顧客から到達可能作られてはなりません。本文書の実装では、「制御プレーン」VPNを使用してこのような操作をサポートするかもしれません。これらの手順は、ASのうち任意の直接P / PE経路広告を必要としない、あるいは、のASBRは、アドミッション制御は、AS間のリンク上で必要とされていない場合でも、セクション5.2.1に記載のシグナリング手順を実施することができます。
Finally, certain operations described herein (Section 3) require an ASBR or PE to receive and locally process a signaling packet addressed to the BGP next hop address advertised by that router. This requirement does not strictly apply to MPLS/BGP VPNs [RFC4364]. This could be viewed as opening ASBRs and PEs to being directly addressable by customer devices where they were not open before, and could be considered a security issue. If a provider wishes to mitigate this situation, the implementation MAY support the "control protocol VPN" approach described above. That is, whenever a signaling message is to be sent to a PE or ASBR, the address of the router in question would be looked up in the "control protocol VPN", and the message would then be sent on the LSP that is found as a result of that lookup. This would ensure that the router address is not reachable by customer devices.
最後に、本明細書に記載の特定の動作（第3節）が受信し、ローカルシグナリングパケットは、そのルータによってアドバタイズBGPネクストホップアドレス宛処理するASBRまたはPEを必要とします。この要件は、厳密にMPLS / BGP VPNの[RFC4364]には適用されません。これは、彼らが以前に開いていなかった顧客のデバイスによって直接アドレス指定可能であることにのASBRとのPEを開くと見ることができ、およびセキュリティ上の問題と考えられます。プロバイダは、この状況を緩和することを希望する場合は、実装は、上記の「制御プロトコルVPN」アプローチをサポートするかもしれません。すなわち、シグナリングメッセージは、PEまたはASBRに送信するときはいつでも、である、問題のルータのアドレスは、「制御プロトコルVPN」で検索される、メッセージは次のように検出されたLSP上で送信されますその検索の結果。これは、ルータのアドレスは、お客様のデバイスによって到達できないことを確実にするでしょう。
[RFC4364] mentions use of IPsec both on a CE-CE basis and PE-PE basis:
[RFC4364]は、CE-CEベースとPE-PE単位でのIPsecの両方の使用を言及します。
Cryptographic privacy is not provided by this architecture, nor by Frame Relay or ATM VPNs. These architectures are all compatible with the use of cryptography on a CE-CE basis, if that is desired.
暗号プライバシーはこのアーキテクチャによって、またフレームリレーやATMのVPNによって提供されていません。それが望まれる場合、これらのアーキテクチャは、すべてのCE-CEベースで暗号化の使用と互換性があります。
The use of cryptography on a PE-PE basis is for further study.
PE-PEベースで暗号の使用は、今後の検討課題です。
The procedures specified in the present document for admission control on the PE-CE links (Section 3) are compatible with the use of IPsec on a PE-PE basis. The optional procedures specified in the present document for admission control in the Service Provider's backbone (Section 4) are not compatible with the use of IPsec on a PE-PE basis, since those procedures depend on the use of PE-PE MPLS TE Tunnels to perform aggregate reservations through the Service Provider's backbone.
PE-CEリンク上のアドミッション制御（セクション3）のために本明細書で指定された手順は、PE-PE単位でのIPsecの使用と互換性があります。これらの手順は、にPE-PE MPLS TEトンネルの使用に依存するので、サービスプロバイダーのバックボーン（セクション4）にアドミッション制御のために本明細書で指定された任意の手順は、PE-PE単位でのIPsecの使用と互換性がありませんサービスプロバイダのバックボーンを通じて集計予約を行います。
[RFC4923] describes a model for RSVP operation through IPsec Gateways. In a nutshell, a form of hierarchical RSVP reservation is used where an RSVP reservation is made for the IPsec tunnel and then individual RSVP reservations are admitted/aggregated over the tunnel reservation. This model applies to the case where IPsec is used on a CE-CE basis. In that situation, the procedures defined in the present document would simply apply "as is" to the reservation established for the IPsec tunnel(s).
[RFC4923]はIPsecのゲートウェイを介してRSVP動作のためのモデルを記載しています。 RSVP予約がIPsecトンネルのために作られ、その後、個々のRSVP予約がトンネル予約上凝集/入院される一言で言えば、階層RSVP予約の形態が使用されます。このモデルは、IPsecはCE-CEベースで使用されている場合に適用されます。 IPsecトンネル（S）のために確立された予約に「そのまま」という状況で、本文書で定義された手順は、単に適用されます。
Thanks to Ashwini Dahiya, Prashant Srinivas, Yakov Rekhter, Eric Rosen, Dan Tappan, and Lou Berger for their many contributions to solving the problems described in this document. Thanks to Ferit Yegenoglu for his useful comments. We also thank Stefan Santesson, Vijay Gurbani, and Alexey Melnikov for their review comments. We thank Richard Woundy for his very thorough review and comments including those that resulted in additional text discussing scenarios of admission control reject in the MPLS VPN cloud. Also, we thank Adrian Farrel for his detailed review and contributions.
このドキュメントで説明する問題を解決するための彼らの多くの貢献のためアシュビニーDahiya、のPrashantスリニバス、ヤコフ・レックター、エリック・ローゼン、ダンタッパン、およびルー・バーガーに感謝します。彼の有益なコメントFerit Yegenogluに感謝します。我々はまた、彼らのレビューコメントのためにステファンSantesson、ビジェイGurbani、およびアレクセイメルニコフに感謝します。私たちは、アドミッション制御のシナリオは、MPLS VPNクラウドで拒否議論追加テキストになったものも含め、彼の非常に徹底的なレビューとコメントのためのリチャードWoundyに感謝します。また、我々は彼の詳細なレビューと貢献のためのエードリアンファレルに感謝します。
Appendix A. Alternatives Considered
付録A.代替を検討します
At this stage, a number of alternatives to the approach described above have been considered. We document some of the approaches considered here to assist future discussion. None of these have been shown to improve upon the approach described above, and the first two seem to have significant drawbacks relative to the approach described above.
この段階で、上述のアプローチの代替の数が検討されてきました。私たちは、将来の議論を支援するために、ここで考えられるのアプローチのいくつかを文書化。これらはいずれも上記の手法を改善することが示されていない、最初の2つは、上述のアプローチに対して重大な欠点を持っているように見えます。
Appendix A.1. GMPLS UNI Approach
付録A.1。 GMPLS UNIアプローチ
[RFC4208] defines the GMPLS UNI. In Section 7, the operation of the GMPLS UNI in a VPN context is briefly described. This is somewhat similar to the problem tackled in the current document. The main difference is that the GMPLS UNI is primarily aimed at the problem of allowing a CE device to request the establishment of a Label Switched Path (LSP) across the network on the other side of the UNI. Hence, the procedures in [RFC4208] would lead to the establishment of an LSP across the VPN provider's network for every RSVP request received, which is not desired in this case.
[RFC4208]はGMPLS UNIを定義します。セクション7で、VPNコンテキストにおけるGMPLS UNIの動作を簡単に説明します。これは、現在のドキュメントに取り組んだ問題に多少似ています。主な違いは、GMPLS UNIは、主にCEデバイスはUNIの反対側にネットワークを介してラベルスイッチパス（LSP）の確立を要求することを可能にするの問題に向けられることです。したがって、[RFC4208]の手順は、この場合には、所望されない受信すべてのRSVP要求に対するVPNプロバイダのネットワークを介してLSPの確立につながります。
To the extent possible, the approach described in this document is consistent with [RFC4208], while filling in more of the details and avoiding the problem noted above.
可能な限り、この文書に記載されたアプローチは、細部のよりに充填し、問題が上述回避しつつ、[RFC4208]と一致しています。
Appendix A.2. Label Switching Approach
付録A.2。ラベルスイッチングアプローチ
Implementations that always look at IP headers inside the MPLS label on the egress PE can intercept Path messages and determine the correct VRF and RSVP state by using a combination of the encapsulating VPN label and the IP header. In our view, this is an undesirable approach for two reasons. Firstly, it imposes a new MPLS forwarding requirement for all data packets on the egress PE. Secondly, it requires using the encapsulating MPLS label to identify RSVP state, which runs counter to existing RSVP principle and practice where all information used to identify RSVP state is included within RSVP objects. RSVP extensions such as COPS/RSVP [RFC2749] which re-encapsulate RSVP messages are incompatible with this change.
常に出口PEにMPLSラベル内部IPヘッダを見て実装では、Pathメッセージを傍受し、カプセル化するVPNラベルとIPヘッダの組み合わせを使用して、正しいVRFとRSVP状態を決定することができます。我々の見解では、これは二つの理由から望ましくないアプローチです。第一に、それは出口PE上のすべてのデータ・パケットのための新しいMPLS転送要件を課します。第二に、それは既存のRSVPの原則に反するRSVP状態を識別し、RSVPの状態を識別するために使用されるすべての情報は、RSVPオブジェクト内に含まれる場合練習をカプセル化MPLSラベルを使用する必要があります。 RSVPメッセージをカプセル化し直すようCOPS / RSVP [RFC2749]としてRSVPの拡張は、この変更と互換性がありません。
Appendix A.3. VRF Label Approach
付録A.3。 VRFラベルアプローチ
Another approach to solving the problems described here involves the use of label switching to ensure that Path, Resv, and other RSVP messages are directed to the appropriate VRF on the next RSVP hop (e.g., egress PE). One challenge with such an approach is that [RFC4364] does not require labels to be allocated for VRFs, only for customer prefixes, and that there is no simple, existing method for advertising the fact that a label is bound to a VRF. If, for example, an ingress PE sent a Path message labelled with a VPN label that was advertised by the egress PE for the prefix that matches the destination address in the Path, there is a risk that the egress PE would simply label-switch the Path directly on to the CE without performing RSVP processing.
ここで説明する問題を解決するための別のアプローチは、そのパス、のResvを確実にするためにラベルスイッチングの使用を含む、その他のRSVPメッセージは、次のRSVPホップ（例えば、出口PE）上の適切なVRFに向けられています。このようなアプローチの一つの課題は、[RFC4364]は唯一の顧客プレフィックスのために、VRFのために割り当てられるラベルを必要とし、ラベルがVRFにバインドされているという事実を広告するための簡単な、既存の方法が存在しないことをしないということです。例えば、入口PEは、パス内の宛先アドレスに一致するプレフィックスの出口PEによってアドバタイズされたVPNラベルで標識されたPathメッセージを送信した場合、出口PEは、単にラベルスイッチなるおそれがありますRSVP処理を行うことなく、直接CEへのパス。
A second challenge with this approach is that an IP address needs to be associated with a VRF and used as the PHOP address for the Path message sent from ingress PE to egress PE. That address needs to be reachable from the egress PE, and to exist in the VRF at the ingress PE. Such an address is not always available in today's deployments, so this represents at least a change to existing deployment practices.
このアプローチの第二の課題は、IPアドレスがVRFに関連付けられ、出口PEへの入口PEから送信されたPathメッセージのためのPHOPアドレスとして使用する必要があることです。そのアドレスは、出口PEから到達可能であること、及び入口PEにVRFに存在する必要があります。このようなアドレスは常に今日の展開では使用できませんので、これは既存の展開慣行に少なくとも変化を示しています。
Appendix A.4. VRF Label Plus VRF Address Approach
付録A.4。 VRFラベルプラスVRFアドレスアプローチ
It is possible to create an approach based on that described in the previous section that addresses the main challenges of that approach. The basic approach has two parts: (a) define a new BGP Extended Community to tag a route (and its associated MPLS label) as pointing to a VRF; (b) allocate a "dummy" address to each VRF, specifically to be used for routing RSVP messages. The dummy address (which could be anything, e.g., a loopback of the associated PE) would be used as a PHOP for Path messages and would serve as the destination for Resv messages but would not be imported into VRFs of any other PE.
そのアプローチの主な課題に対処し、前のセクションで説明したものに基づいたアプローチを作成することが可能です。基本的なアプローチは、2つの部分を有する：（a）の経路（およびその関連するMPLSラベル）をタグ付けする新しいBGP拡張コミュニティを定義するVRFを指すように、 （b）は、具体的にRSVPメッセージをルーティングするために使用される、各VRFに「ダミー」アドレスを割り当てます。 （例えば何でも、関連するPEのループバックすることができる）ダミーアドレスは、PathメッセージのPHOPとして使用されるとRESVメッセージの宛先として役立つであろうが、任意の他のPEのVRFにインポートされないであろう。
References
リファレンス
Normative References
引用規格
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[RFC2113]カッツ、D.、 "IPルータアラートオプション"、RFC 2113、1997年2月。
[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月。
[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, October 1999.
[RFC2711]ウズラ、C.とA.ジャクソン、 "IPv6のルータアラートオプション"、RFC 2711、1999年10月。
[RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001.
[RFC3175]ベーカー、F.、Iturralde、C.、ルFaucheur、F.、およびB.デイビー、 "IPv4とIPv6の予約のためのRSVPの集約"、RFC 3175、2001年9月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364]ローゼン、E.およびY. Rekhter、 "BGP / MPLS IP仮想プライベートネットワーク（VPN）"、RFC 4364、2006年2月。
[RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, "BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN", RFC 4659, September 2006.
[RFC4659]デClercq、J.、Ooms、D.、Carugi、M.、およびF.ルFaucheur、 "BGP-MPLS IP仮想プライベートネットワーク（VPN）は、IPv6 VPNのための拡張"、RFC 4659、2006年9月。
[RFC4804] Le Faucheur, F., "Aggregation of Resource ReSerVation Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels", RFC 4804, February 2007.
[RFC4804]ルFaucheur、F.、RFC 4804 "MPLS TE / DS-TEトンネル経由リソース予約プロトコル（RSVP）予約の集約"、2007年2月。
Informative References
参考文献
[ALERT-USAGE] Le Faucheur, F., Ed., "IP Router Alert Considerations and Usage", Work in Progress, July 2010.
[ALERT-USAGE]ルFaucheur、F.、エド。、 "IPルータアラートの考慮事項および使用方法"、進歩、2010年7月に作業。
[LER-OPTIONS] Smith, D., Mullooly, J., Jaeger, W., and T. Scholl, "Requirements for Label Edge Router Forwarding of IPv4 Option Packets", Work in Progress, May 2010.
[LER-OPTIONS]スミス、D.、Mullooly、J.、ジャガールクルト、W.、およびT.ショル、 "IPv4のオプションパケットのラベルエッジルータ転送のための要件"、進歩、2010年5月での作業。
[RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[RFC1633]ブレーデン、B.、クラーク、D.、およびS. Shenker、 "インターネットアーキテクチャにおける統合サービス：概要"、RFC 1633、1994年6月。
[RFC2209] Braden, B. and L. Zhang, "Resource ReSerVation Protocol (RSVP) -- Version 1 Message Processing Rules", RFC 2209, September 1997.
[RFC2209]ブレーデン、B.およびL.チャン、 "資源予約プロトコル（RSVP） - バージョン1つのメッセージ処理ルール"、RFC 2209、1997年9月。
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[RFC2210] Wroclawski、J.、RFC 2210、1997年9月 "IETF統合サービスとRSVPの使用"。
[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月。
[RFC2748] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R., and A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000.
[RFC2748]ダラム、D.、ボイル、J.、コーエン、R.、ヘルツォーク、S.、ラジャン、R.、およびA. Sastry、 "COPS（共通オープンポリシーサービス）プロトコル"、RFC 2748、2000年1月。
[RFC2749] Herzog, S., Boyle, J., Cohen, R., Durham, D., Rajan, R., and A. Sastry, "COPS usage for RSVP", RFC 2749, January 2000.
[RFC2749]ヘルツォーク、S.、ボイル、J.、コーエン、R.、ダラム、D.、ラジャン、R.、およびA. Sastryは、RFC 2749、2000年1月 "RSVPの使用をCOPS"。
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., and S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, April 2001.
[RFC2961]バーガー、L.、ガン、D.、ツバメ、G.、パン、P.、Tommasi、F.、及びS. Molendini、 "RSVPリフレッシュオーバーヘッド削減拡張"、RFC 2961、2001年4月。
[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月。
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]バーガー、L.、 "一般化マルチプロトコルラベルスイッチング（GMPLS）シグナリング資源予約プロトコル - トラフィックエンジニアリング（RSVP-TE）を拡張"、RFC 3473、2003年1月。
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[RFC4206] Kompella、K.とY. Rekhterは、RFC 4206、2005年10月 "ラベル・パス（LSP）の階層は、一般マルチプロトコルラベルスイッチング（GMPLS）トラフィックエンジニアリング（TE）との交換しました"。
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, "Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model", RFC 4208, October 2005.
[RFC4208]ツバメ、G.、ドレイク、J.、石松、H.、およびY. Rekhter、「一般化マルチプロトコルラベルスイッチング（GMPLS）ユーザネットワークインタフェース（UNI）：リソース予約プロトコル - トラフィックエンジニアリング（RSVP-TE）オーバレイモデルのサポート」、RFC 4208、2005年10月。
[RFC4860] Le Faucheur, F., Davie, B., Bose, P., Christou, C., and M. Davenport, "Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations", RFC 4860, May 2007.
[RFC4860]ルFaucheur、F.、デイビー、B.、ボーズ、P.、Christouの、C.、およびM.ダヴェンポート、 "汎用集計リソース予約プロトコル（RSVP）予約"、RFC 4860、2007年5月。
[RFC4923] Baker, F. and P. Bose, "Quality of Service (QoS) Signaling in a Nested Virtual Private Network", RFC 4923, August 2007.
[RFC4923]ベイカー、F.およびP.ボーズ、RFC 4923、2007年8月 "ネストされた仮想プライベートネットワークにシグナリングサービス品質（QoS）"。
[RFC5824] Kumaki, K., Zhang, R., and Y. Kamite, "Requirements for Supporting Customer Resource ReSerVation Protocol (RSVP) and RSVP Traffic Engineering (RSVP-TE) over a BGP/MPLS IP-VPN", RFC 5824, April 2010.
[RFC5824]熊木、K.、張、R.、およびY. Kamite、 "BGP / MPLS IP-VPN上カスタマーリソース予約プロトコル（RSVP）とRSVPトラフィックエンジニアリング（RSVP-TE）をサポートするための要件"、RFC 5824 、2010年4月。
[RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet Signalling Transport", RFC 5971, October 2010.
[RFC5971] Schulzrinneと、H.とR.ハンコック、 "GIST：一般的なインターネットシグナリング交通"、RFC 5971、2010年10月。
[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月。
[RSVP-KEYING] Behringer, M., Faucheur, F., and B. Weis, "Applicability of Keying Methods for RSVP Security", Work in Progress, September 2010.
[RSVP-KEYING]ベーリンガー、M.、Faucheur、F.、およびB.ヴァイス、 "RSVPセキュリティのためのキーイング方法の適用"、進歩2010年9月に働いています。
Authors' Addresses
著者のアドレス
Bruce Davie Cisco Systems, Inc. 1414 Mass. Ave. Boxborough, MA 01719 USA
ブルース・デイビーシスコシステムズ株式会社1414年マサチューセッツアベニュー。ボックスボロー、MA 01719 USA
EMail: bsd@cisco.com
メールアドレス：bsd@cisco.com
Francois Le Faucheur Cisco Systems, Inc. Village d'Entreprise Green Side - Batiment T3 400, Avenue de Roumanille Biot Sophia-Antipolis 06410 France
フランソワ・リーパーシスコシステムズ社コーポレート・ヴィレッジグリーンサイド - T3ビル400、アベニューRoumanilleビオソフィアアンティポリスフランス06410
EMail: flefauch@cisco.com
メールアドレス：flefauch@cisco.com
Ashok Narayanan Cisco Systems, Inc. 1414 Mass. Ave. Boxborough, MA 01719 USA
アショク・ナラヤナンシスコ・システムズ・インク1414年マサチューセッツアベニュー。ボックスボロー、MA 01719 USA
EMail: ashokn@cisco.com
メールアドレス：ashokn@cisco.com