[要約] RFC 6016は、レイヤー3 VPNでのリソース予約プロトコル（RSVP）のサポートに関するものです。このRFCの目的は、RSVPを使用してレイヤー3 VPNでのトラフィックの予約と制御を可能にすることです。
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）を構築するアプローチを定義します。リソース予約プロトコル（RSVP）を使用して、カスタマーエッジ（CE）ルーターとプロバイダーエッジ（PE）ルーターの間のリンクで入場制御を実行することが望ましい場合があります。このドキュメントは、L3VPNを介してCEからCEへと移動するRSVPメッセージをPEルーターで適切に処理できる手順を指定し、PE-CEリンクで入場制御を実行できるようにします。オプションで、プロバイダーのバックボーン全体の入場制御もサポートされる場合があります。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of 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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction ....................................................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およびIPv6のBGP/ MPLS VPNSとして知られるレイヤー3 VPNサービスを定義します。[RFC2205]は、リソース予約プロトコル（RSVP）を定義します。これは、統合サービス（INT-SERV）アーキテクチャ[RFC1633] [RFC2210]の一部として入学制御を実行するために使用できます。
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 VPNのプロバイダーエッジ（PE）と顧客エッジ（CE）ルーターの間のリンクは、リソースが制約されることが多いため、それらのリンクをアミズミンココントロールを実行できることが望ましい場合があります。このような環境でRSVPを使用して入場制御を実行するには、PATHメッセージやRESVメッセージなどのRSVP制御メッセージがPEルーターによって適切に処理されることが必要です。これは、BGP/MPLS VPNSのコンテキストで多くの課題を提示します。
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パスメッセージ処理は、IPヘッダーのルーターアラートオプション（[RFC2113]、[RFC2711]）を認識するルーターに依存します。ただし、BGP/MPLS VPNのバックボーンを通過するパケットはMPLSカプセル化されているため、実装またはポリシーの考慮事項により、ルーターアラートオプションが出口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 VPNSは、顧客ネットワークの非ユニークアドレス指定をサポートしています。したがって、プロバイダーバックボーンの侵入または出口のPEは、RSVPメッセージ内の非ユニークな宛先アドレスを使用して、異なる顧客VPNからパスメッセージを処理するために呼び出される場合があります。データパケットから顧客コンテキストを識別するための現在のメカニズムは、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は、他のPESの異なる顧客VPNに対応するRESVメッセージを受信する場合があり、それらのRESVメッセージを適切な顧客VPNに関連付けることができます。
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.
さらに、1つ以上の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 VPNSでのマルチキャストトラフィックのサポートはまだ進化しており、入場管理のための追加の課題を提起しているため、この時点でさらなる研究のためにマルチキャストフローのサポートを辞めます。
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.
o VPNルーティングと転送（VRF）テーブル：通常、PEには複数のVRFがあり、異なるVPNにあるCESに接続できるようにします。
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を購読する場合の顧客サイト間の入場制御のサポートです。問題を（a）PE-CEリンクの入場制御の問題（両方方向）と（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パスメッセージは通常、セッションの宛先に宛てられ、IPヘッダー内にルーターアラートオプション（RAO）が含まれています。RSVPメッセージを処理するように構成されている宛先へのパスに沿ったルーターは、RAOの存在を検出してパスメッセージを傍受できるようにする必要があります。ただし、BGP/MPLS VPNSをサポートするネットワークの出口PESは、MPLSでカプセル化されたパケットとして顧客サイト用に運命づけられているパケットを受信し、MPLSラベルの検査にのみ基づいているもののみを転送する可能性があります。RSVPパスメッセージを処理するために、出力VPN PEはVPNラベルをポップし、その下にIPヘッダーを調べる必要があります。。したがって、パスメッセージはIPオプションを調べずに転送されるため、PEで適切な処理を受信しません。別の潜在的な問題は、自律システムのボーダールーター（ASBR）で接続入場制御（CAC）を実行することです。VPNラベル（PE-CEリンクなど）を削除するときにIPヘッダーを調べる実装でさえ、Option-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パケット処理のアプローチには、VPN内のIPルーターアラートサポートなどのデータプレーン要件に依存しないことや、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アドレスが含まれていることであり、PESは非不一致（または重複する）アドレスを持っている可能性のある多くの顧客からのトラフィックに対処する必要があることです。スペース。したがって、PEは、すべての場合において、RSVP制御メッセージを処理する正しいVPNコンテキストを特定できることが不可欠です。顧客のコンテキストを識別するための現在のメカニズムは、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カプセル化を置き換え、RSVPオブジェクトのみをCOPSサーバーに送信します。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（Provider Core）ルーターに顧客ごとの転送状態を作成しないことがわかります。したがって、顧客指定のフローに代わって予約を行うには、PE-PEから何らかの集計された予約を行い、個々の顧客固有の予約を集計予約にマッピングする必要があることが明らかに必要です。これは、[RFC3175]および[RFC4804]で取り組まれた問題に似ており、BGP/MPLS VPNに関連する顧客固有のアドレス指定の処理の追加の合併症があります。
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
図1. MPLS/BGP VPNに対するRSVPベースの入場制御の動作モデル
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リンクのみでリソースの可用性を考慮した送信者から受信機へのポイントツーポイントフローの単方向予約を確立するには、次の手順を実行する必要があります。
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. パスメッセージは、通常のRSVP手順を使用してCE1によって処理され、リンクCE1-PE1に沿ったレシーバーに向かって転送されます。
3. PE1 processes the Path message and forwards it towards the Receiver across the provider backbone.
3. PE1はパスメッセージを処理し、プロバイダーバックボーンを介して受信機に転送します。
4. PE2 processes the Path message and forwards it towards the Receiver along link PE2-CE2.
4. PE2はパスメッセージを処理し、リンクPE2-CE2に沿って受信機に転送します。
5. CE2 processes the Path message using normal RSVP procedures and forwards it towards the Receiver.
5. CE2は、通常のRSVP手順を使用してパスメッセージを処理し、受信機に転送します。
6. The Receiver sends a Resv message to CE2.
6. 受信者は、ce2にRESVメッセージを送信します。
7. CE2 sends the Resv message to PE2.
7. CE2はRESVメッセージをPE2に送信します。
8. PE2 processes the Resv message (including performing admission control on link PE2-CE2) and sends the Resv message to PE1.
8. PE2は、RESVメッセージ（Link PE2-CE2で入場制御の実行を含む）を処理し、RESVメッセージをPE1に送信します。
9. PE1 processes the Resv message and sends the Resv message to CE1.
9. PE1はRESVメッセージを処理し、RESVメッセージをCE1に送信します。
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メッセージ（6〜10）を含む各ステップで、RESVメッセージを送信するノードは、以前に確立されたパス状態を使用して「RSVP以前のホップ（PHOP）」を決定し、RESVメッセージをそのアドレスに送信します。そのパスをPESで正しく確立することは、BGP/MPLS環境によってもたらされる課題の1つであることに注意してください。
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で概説した手順を追跡し、BGP/ MPLS VPN環境をサポートするために標準のRSVP手順を拡張または変更する必要があるこれらの手順の詳細を展開します。前のセクションで説明する残りのすべての手順には、標準の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アドレスは一意ではないため、現在のタイプのセッション、sender_template、およびfilterspecオブジェクトは、現在IPアドレスに基づいているため、P/PEルーターでRSVP状態をグローバルに識別するのに十分ではなくなりました。グローバルに一意のVPN-IPV4形式アドレスを含む新しいタイプのセッション、Sender_Template、およびFilterSpecオブジェクトを提案します。IngressおよびEutress 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ルーター（特にOption-B ASBRで分離されたもの）は、互いに直接IPリーチ性を持つ必要はありません。この問題を解決するために、MPLS VPN内のノード間でRSVPメッセージを転送するためにラベルスイッチングを使用することを提案します。これは、新しいVPN-IPV4 RSVP_HOPオブジェクトを定義することで達成されます。VPN-IPV4 RSVP_HOPオブジェクトを使用すると、MPLS VPNの2つの隣接RSVPホップ（たとえば、自律システムのPE（AS）1およびAS2のPE）が互いに正しく識別し、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オブジェクトは、メッセージ送信者のIPv4アドレスと、以前と同様に論理インターフェイスハンドル（LIH）を搭載していますが、さらにメッセージの送信者を表すVPN-IPV4アドレスも運ばれます。メッセージ送信者は、このVPN-IPV4アドレスをローカルに割り当てられたラベルに関連付けられたBGPに宣伝する必要があります。この広告は、このPEに到達可能性を提供するために必要な場合は、VPN全体および隣接するASESにbgpによって伝播する必要があります。このラベルでマークされたPEで受け取ったフレームは、処理のためにローカルコントロールプレーンに指定する必要があります。隣接するRSVPホップがVPN-IPV4 RSVP_HOPを運ぶメッセージに返信したい場合、そのRSVP_HOPに含まれるVPN-IPV4アドレスのBGP広告を探します。このアドレスが見つかり、関連するラベルが搭載されている場合、隣接するRSVPノードは、このラベルを使用してRSVPメッセージをカプセル化し、ルートに関連付けられたBGP Next HopにMPLSカプセル化を介して送信する必要があります。メッセージの宛先IPアドレスは、[RFC2205]で説明されているように、RSVP_HOPオブジェクトのIPアドレスフィールドから取得されます。さらに、RSVP_HOPオブジェクトのIPv4アドレスは、PATH/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の既存のアドレス（この顧客のVRF内のローカルループバックまたはPE-CEリンクアドレス）を表す場合があります。この目的のために特別に作成されました。アドレスがRSVPシグナリング（および場合によっては他の制御プロトコル）のために特別に作成されている場合、BGP広告は、MPLS VPNの外側のCESに再配布されるか、到達可能である必要はありません。これを達成する1つの方法は、すべてのPE/ASBRにVRF状態を備えた特別な「コントロールプロトコルVPN」を作成し、顧客VRFにインポートされていないルートターゲットを運ぶことです。顧客VRFアドレスがVPN-IPV4アドレスとして使用される場合、1つの顧客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にパスメッセージを送信し、上記の要件を満たすシグナリングに適切なVPN-IPV4アドレスを持っている場合、このアドレスを含むVPN-IPV4 RSVP_HOPオブジェクトを使用する必要があります。VPN内のすべてのRSVPメッセージ。PE/ASBRにシグナリングに使用する適切なVPN-IPV4アドレスがない場合、通常のIPv4 RSVP_HOPオブジェクトでパスメッセージを送信する場合があります。この場合、返信はIPカプセル化されます。このオプションは、近隣のRSVPホップが送信ノードに対してIPリーチ性を備えているという保証がないため、好ましくありません。PE/ASBRがVPN-IPV4 RSVP_HOPオブジェクトを使用してパスメッセージを受信または発信した場合、このフローの対応するアップストリームメッセージのRSVP_HOPオブジェクト（例えば、RESV、RESVTEAR）またはダウンストリームメッセージ（例：Resverror、Pathtear）が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.
パスメッセージがイングレスPE（セクション2.1のステップ3）に到着すると、PEは適切なパス状態を確立し、パスメッセージを出口PEに転送する必要があります。次の段落で、侵入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.
パスメッセージは、最終的な宛先（リモートカスタマーサイトのレシーバー）に宛てられ、[RFC2205]に従ってIPルーターアラートオプションを運びます。Ingress 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）。ここで定義されているアプローチは、イングレスPEによって送信されたパスメッセージに直接出口PEに対処し、IPルーターアラートオプションなしで送信することです。つまり、究極のレシーバーの宛先アドレスをパスメッセージの宛先アドレスとして使用するのではなく、出口PEのループバックアドレスをパスメッセージの宛先アドレスとして使用します。このアプローチには、標準のBGP/MPLS VPN PEのものを超えて、出力PEに新しいデータプレーン機能を必要としないという利点があります。出口PEでのこのメッセージの処理の詳細については、以下にセクション3.3で説明します。RSVP次のホップ（次のIPホップである可能性がある場合とそうでない場合がある場合）にパスメッセージに直接対処するアプローチは、[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.
Ingress PEでの操作の詳細は次のとおりです。イングレスPE（図1のPE1）が受信機に宛てられたCE1からパスメッセージを受信すると、通常のデータパス操作と同様に、着信インターフェイスに関連付けられているVRFが識別されます。セッションのパス状態は保存されており、そのVRFに関連付けられているため、異なるVPNの間で潜在的に重複するアドレスが同じセッションに属していないようです。受信機の宛先アドレスが適切なVRFで調べられ、その宛先の次のホップが識別されます。次のホップは、出口PE（図1のPE2）です。この宛先のVPN-IPV4ルートプレフィックスの一部であるRoute Distiminguisher（RD）と、セッションのIPv4アドレスを含む、新しいVPN-IPV4セッションオブジェクトが構築されています。さらに、新しいVPN-IPV4 SENDER_TEMPLATEオブジェクトが構築され、着信Sender_Templateの元のIPv4アドレスに加えて、このPEが使用するRDがこの顧客のプレフィックスをVPNに宣伝します。新しいパスメッセージは、上記で識別された出口PEのアドレスに等しい宛先アドレスで構築されます。この新しいパスメッセージには、元のパスメッセージからのすべてのオブジェクトが含まれ、元のセッションとsender_templateオブジェクトを新しいVPN-IPV4タイプオブジェクトに置き換えます。パスメッセージは、ルーターアラートオプションなしで送信され、セクション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.
パスメッセージが出口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モジュールは、次の方法で受け取ったパスとは異なるパスメッセージを作成できます。
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. セッションと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].
次に、ルーターは、上記のインターフェイスを介して宛先に向かってパスメッセージを送信します。このパスメッセージには、[RFC2205]で要求されるルーターアラートオプションが搭載されています。
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）に到着するまで適用されます。これは、データフローの方向、つまり図1のPE2に関する「出口」PEであることに注意してください。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はRESVメッセージを構築して、パス状態に保存されているRSVPの前のホップ、つまり入り口PE（図1のPE1）に送信します。IPv4セッションオブジェクトは、パスで受信した同じVPN-IPV4セッションオブジェクトに置き換えられます。IPv4 Filter_Specオブジェクトは、一致するパスメッセージで受信したsender_templateからVPN-IPV4アドレスをコピーするVPN-IPV4 Filter_Specオブジェクトに置き換えられます。RESVメッセージのRSVP_HOPは、セクション3.1で指定されているように構築する必要があります。RESVメッセージは、パスメッセージ内のRSVP_HOPオブジェクト内に含まれるIPアドレスにアドレス指定する必要があります。パスメッセージにVPN-IPV4 RSVP_HOPオブジェクトが含まれている場合、セクション3.1で説明されているように、BGPのVPN-IPV4アドレスに関連付けられたラベルを使用して、RESVをMPLSカプセル化する必要があります。パスメッセージに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で入場制御が成功しない場合、通常の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メッセージを生成することが可能になりました。Ingress CEに送信されたRESVメッセージには、適切なパス状態から派生したIPv4セッションとFilter_Specオブジェクトが含まれます。このセクションでは、プロバイダーのバックボーンに対する入場制御は必要ないと仮定しているため、Ingress 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.
o セッション、sender_template、およびfilter_specオブジェクトは、IPv4からVPN-IPV4フォームに変換し、PATHおよびRESVメッセージについて上記と同じ方法で戻る必要があります。
o The appropriate type of RSVP_HOP object (VPN-IPv4 or IPv4) MUST be used as described above.
o 適切なタイプのRSVP_HOPオブジェクト（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は、セッションとFilter_SpecオブジェクトのRDおよびIPv4アドレスをデコードすることにより、決定する必要があります。
o The message MUST be directly addressed to the appropriate PE, without using the Router Alert Option.
o メッセージは、ルーターアラートオプションを使用せずに、適切なPEに直接アドレス指定する必要があります。
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トンネルは、バックボーンで総入場制御を実行する手段としてPES間に確立できます。
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をIngress 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]は、Options A、B、およびCと呼ばれるMPLS/BGP VPNSのAS操作の3つのモードを定義します。次のセクションでは、上記のスキームが各環境でどのように動作するかについて説明します。
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.
inter-asオプションAでのRSVPの動作は非常に簡単です。各ASBRはPEのように動作し、ASBR-ASBRリンクは、入場制御の観点からPE-CEリンクとして表示できます。セクション3で定義されている手順が両方のASBRで有効になっている場合、ASBR間リンクで入場制御が実行される場合があります。さらに、それぞれのオペレーターは、バックボーン全体で入学制御を実行するかどうかを独立して決定できます。このドキュメントで説明されている新しいオブジェクトは、2つのオプション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 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.
Inter-AS Option Bをサポートするには、ASBRでRSVPメッセージの追加の処理が必要です。オプションBのパケットから別のパケットから転送されると、パケットが別のパケットから別のパケットに移動すると、VPNラベルが各ASBRに交換されることを思い出してください。Ingress PEが見たBGP次のホップはASBRになり、入り口と出口の間にIPの可視性が必要ではありません。したがって、イングレスPEがVPN-IPV4ルートの次のホップにパスメッセージを宛先に向かって送信すると、ASBRが受信します。ASBRは、同じRDとマッチングプレフィックスを備えた一致するBGP VPN-IPV4ルートを見つけることにより、イングレスPEと同様の方法でルートの次のホップを決定します。
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を使用してASEを相互接続するプロバイダーは、AS Inter-ASリンクで入場制御を実行したい場合と望んでいない場合があります。この選択は、ASBRSの詳細な操作に影響します。次のセクションで、ASBRSの入場制御の有無にかかわらず、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データベースは、VPN-IPV4セッション、Sender_Template、およびFilter_Specオブジェクトを使用してASBRでインデックス化されています（[RFC2205]の要件に従ってRSVPセッションとフローを一意に識別します）。これらのオブジェクトは、ASBRによって両方向に変更されずに転送されます。RSVPの他のすべての手順は、ASBRがRSVPホップであるかのように実行されます。特に、パスで送信されたRSVP_HOPオブジェクトとRESVメッセージには、ASBRのIPアドレスが含まれています。これは、メッセージが送信されている隣人が到達できる必要があります。VPN-IPV4セッション、Sender_Template、およびFilter_Specオブジェクトは、[RFC2209]に従ってRSVPデータベースの実装に必要な一意性プロパティを満たすため、ASBRには顧客VRF認識は必要ありません。
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ホップ（つまり、それぞれのASESの侵入と出口のペス）が必要です。これは、それらがカプセル化されている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 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.
ローカルRSVP状態をインストールしていないASBRがパスメッセージを受信すると、セクション3.2で説明されているように一致するBGPルートの次のホップを調べ、RSVPオブジェクトを変更せずに次のホップにパスメッセージを送信します（rsvp_hop）。このプロセスは、パスメッセージがローカルRSVP状態をインストールするルーター（究極の出口PE、または入場制御を実行するように構成されたASBR）に到着するまで、後続のASBRで繰り返されます。このルーターはパスを受信し、セクション3.3で説明したようにPEの場合は処理します。このルーターがRESVを上流に送信すると、PHOPのVPN-IPV4アドレスの次のホップラベルのルーティングテーブルを検索し、そのラベルでRESVをカプセル化し、上流に送信します。このメッセージは、中間ASBRの関与なしに、上流のRSVPホップ（最後にRSVP_HOPフィールドをパスメッセージの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は、上記のようにパスメッセージとは別に他のRSVPメッセージを処理することは期待されていません。ASBRは、RSVP状態を保存する必要もありません。IPv4およびVPN-IPV4アドレスを使用して独自のRSVP_HOPオブジェクトを作成することにより、入場制御またはRSVPシグナリングフローに挿入したいパスに沿ったASBRは、それ自体を指していることに注意してください。
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パスメッセージを受信するオプションB ASBRが入場制御を実行することを望まないが、このフローのためにローカル状態をインストールすることをいとわない場合、ASBRはセクションで説明されているようにこのフローのRSVPシグナル伝達メッセージを処理および転送する必要があります。5.2.1（入場制御を実行しないことを除いて）。Option-B ASBRがIPv4 RSVP_HOPを使用してRSVPパスメッセージを受信しますが、このフローのローカル状態をインストールしたり、ASMALがパスメッセージを転送してはなりません。さらに、ASBRは、エラーコード「MPLS問題に関するRSVP」およびエラー値「VPN全体に到達できないRSVP_HOP」（セクション9を参照）のPatherRorメッセージを送信する必要があります。この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.
Inter-AS Option CでのRSVPの動作も非常に簡単です。これは、Ingress PEから出力PEに直接LSPが存在するためです。この場合、セクション3で説明されているケースのように、シングルからの操作に有意な違いはありません。さらに、PEからPEへの入場制御を提供することが望ましい場合は、TETEトンネルとして、次にインタートンネルを構築することで実行できます。セクション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データグラムと同じように転送する必要があることを合理的に期待する場合があります。この透明性は、顧客が自分のサイト内でRSVPを使用したい場合、またはおそらくPESの関与なしにCE-PEリンク（CE-> PE方向のみ）で入場制御を実行する場合に役立ちます。このため、PEは、RSVPがPE-CEリンクで有効になっていない場合、CEからRSVPメッセージを破棄または変更しないでください。同様に、PEは、RSVPがそれらのリンクで有効になっていない場合でも、添付のCESの1つに運命づけられているRSVPメッセージを破棄または変更してはなりません。いくつかのRSVPメッセージにルーターアラートオプションが存在すると、通常の転送パスの外側に転送される可能性がありますが、この場合にはこの段落のガイダンスがまだ適用される可能性があることに注意してください。また、このガイダンスは、RSVP-TEがL3VPNネットワークの一部、すべて、またはいずれでも使用されていないかどうかに関係なく適用されることに注意してください。
This section describes modifications to other RSVP procedures introduced by MPLS VPNs.
このセクションでは、MPLS VPNSによって導入された他の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の入り口と出口の間のホップは、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 SREFRESHメッセージのソースIPアドレスは、対応するパスまたはRESVメッセージに含まれるRSVP_HOPオブジェクトに合図されたIPv4アドレスと一致する必要があります。受信したVPN-IPV4 RSVP_HOPオブジェクトのIPv4アドレスは、この目的のためにそのメッセージのソースアドレスとして使用する必要があります。
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 受信したVPN-IPV4 RSVP_HOPオブジェクトのIPv4アドレスは、セキュリティ協会を特定する目的で、そのメッセージのソースアドレスとして使用する必要があります。
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 このセクションで説明する手順は、アグリゲーターとDeaggregatorノードがC/CEデバイスであり、MPLS VPN全体が集合領域内にある場合にのみ適用されます。PEがアグリゲーター/Deaggregatorでもある場合は、より複雑で、このドキュメントでは考慮されていません。
o Support of Aggregate RSVP sessions is OPTIONAL. When supported:
o 集計RSVPセッションのサポートはオプションです。サポートされている場合：
* 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セッションと同じように扱う必要があります。この目的のために、集計RSVPセッションについては、セクション3および4で説明するすべての手順に従う必要があります。対応する新しいセッション、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）によって識別される必要があります。Ingress 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-CE-CE-CE-CE-CE-CE-CE-CE-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）セッションオブジェクトの使用については、セクション3.2〜3.6で説明されています。VPN-IPV4（またはVPN-IPV6）セッションオブジェクトは、通常、セッションオブジェクトを含むRSVPメッセージに表示され、どちらの方向にもイングレスPEと出口PEの間に送信されます。オブジェクトは、プロバイダーのバックボーンの外部で送信されるRSVPメッセージに含めてはなりません（上記のリンクに表示される場合、上記のように、inter-as option-bおよびoption-cのケースを除く）。
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-IPV4アドレス（[RFC4364]）の代わりに、VPN-IPV6アドレス（[RFC4659]）を使用して、VPN-IPV4セッションオブジェクトに類似しています。
The formats of the objects are as follows:
オブジェクトの形式は次のとおりです。
o VPN-IPv4 SESSION object: Class = 1, C-Type = 19
o VPN-IPV4セッションオブジェクト：class = 1、c-type = 19
+-------------+-------------+-------------+-------------+
| |
+ +
| VPN-IPv4 DestAddress (12 bytes) |
+ +
| |
+-------------+-------------+-------------+-------------+
| Protocol Id | Flags | DstPort |
+-------------+-------------+-------------+-------------+
o VPN-IPv6 SESSION object: Class = 1, C-Type = 20
o VPN-IPV6セッションオブジェクト：class = 1、c-type = 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]で指定されているようにエンコードされたVPN-IPV4（VPN-IPV6）のアドレスのアドレスが含まれています（それぞれ[RFC4659]）。このフィールドの内容については、セクション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セッションオブジェクトの同じフィールドと同じです（[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オブジェクトを含むRSVPメッセージに表示され、どちらかの方向（パス、pather、pathtearなど）のイングレスPEと出口の間に送信されます。オブジェクトは、プロバイダーのバックボーンの外部で送信されるRSVPメッセージに含めてはなりません（上記のリンクに表示される場合、上記のように、inter-as option-bおよびoption-cのケースを除く）。オブジェクトの形式は次のとおりです。
o VPN-IPv4 SENDER_TEMPLATE object: Class = 11, C-Type = 14
o vpn-ipv4 sender_templateオブジェクト：class = 11、c-type = 14
+-------------+-------------+-------------+-------------+
| |
+ +
| VPN-IPv4 SrcAddress (12 bytes) |
+ +
| |
+-------------+-------------+-------------+-------------+
| Reserved | SrcPort |
+-------------+-------------+-------------+-------------+
o VPN-IPv6 SENDER_TEMPLATE object: Class = 11, C-Type = 15
o vpn-ipv6 sender_templateオブジェクト：class = 11、c-type = 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]で指定されているようにエンコードされたVPN-IPV4（VPN-IPV6）のアドレスのアドレスが含まれています（それぞれ[RFC4659]）。このフィールドの内容については、セクション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オブジェクトを含むRSVPメッセージに表示され、どちらかの方向（RESV、Resveror、ResVTearなど）のイングレスPEと出口PEの間に送信されます。オブジェクトは、プロバイダーのバックボーンの外部で送信されるRSVPメッセージに含めてはなりません（上記のリンクに表示される場合、上記のように、inter-as option-bおよびoption-cのケースを除く）。
o VPN-IPv4 FILTER_SPEC object: Class = 10, C-Type = 14
o vpn-ipv4 filter_specオブジェクト：class = 10、c-type = 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オブジェクト：class = 10、c-type = 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オブジェクトは、1つ以上のOption-B ASBRによって分離されたRSVP近隣のシグナリングの到達可能性を確立するために使用されます。このオブジェクトは、RSVP_HOPオブジェクトを運ぶRSVPメッセージに表示される場合があり、侵入と出口の間を移動することができます。プロバイダーのバックボーンの外部で送信されるRSVPメッセージに含めてはなりません（上記のAS Inter-ASリンクに表示される場合のOption-BおよびOption-Cの場合を除く）。オブジェクトの形式は次のとおりです。
o VPN-IPv4 RSVP_HOP object: Class = 3, C-Type = 5
o vpn-ipv4 rsvp_hopオブジェクト：class = 3、c-type = 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オブジェクト：class = 3、c-type = 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 Next/前のホップアドレス、IPv6 Next/前のホップアドレス、および論理インターフェイスハンドルフィールドは、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 NEXT/以前のホップアドレス（それぞれ、VPN-IPV6 NEXT/前ホップアドレス）フィールドには、それぞれVPN-IPV4（VPN-IPV6）のアドレスが含まれています。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）セッションオブジェクトの使用については、セクション7.3で説明します。集計-VPN-IPV4（それぞれ、集計-IPV6-VPN）セッションオブジェクトは、[RFC3175]で定義され、侵入PEおよび侵入の間に送信される凝集体IPV4（それぞれ、凝集体IPV6）セッションオブジェクトを通常含めるRSVPメッセージに表示されます。どちらの方向にもPEを出力します。ジェネリックアグゲート-VPN-IPV4（それぞれ、集約VPN-IPV6）セッションオブジェクトは、[RFC4860600で定義されているように、通常、ジェネリックアグレジェート-IPV4（一般的な総合-IPV6）セッションオブジェクトを含むすべてのRSVPメッセージに表示する必要があります。]そして、どちらの方向にも侵入PEと出口PEの間に送られます。これらのオブジェクトは、プロバイダーのバックボーンの外側に送信されるRSVPメッセージに含める必要はありません（上記のリンクに表示される場合、上記のように、Inter-as as option-bおよびoption-cのケースを除く）。これらのオブジェクトの処理ルールは、セクション8.1で定義されているVPN-IPV4（それぞれ、VPN-IPV6）セッションオブジェクトの処理ルールと同一です。オブジェクトの形式は次のとおりです。
o AGGREGATE-VPN-IPv4 SESSION object: Class = 1, C-Type = 21
o aggregate-vpn-ipv4セッションオブジェクト：class = 1、c-type = 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セッションオブジェクト：class = 1、c-type = 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]で指定されているようにエンコードされたVPN-IPV4（VPN-IPV6）のアドレスのアドレスが含まれています（それぞれ[RFC4659]）。このフィールドの内容については、セクション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は、集合体-IPV4および集約-IPV6セッションオブジェクトの同じフィールドと同じです（[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
o generic-aggregate-vpn-ipv4セッションオブジェクト：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セッションオブジェクト：class = 1、c-type = 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]で指定されているようにエンコードされたVPN-IPV4（VPN-IPV6）のアドレスのアドレスが含まれています（それぞれ[RFC4659]）。このフィールドの内容については、セクション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は、汎用総合-IPV4および汎用総合-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で説明されています。集合体-VPN-IPV4（それぞれ、Aggregate-VPN-IPV6）sender_templateオブジェクトは、通常[RFC3175]および[RFC4860]で定義されているように、aggregate-IPv4（aggregate-ipv6）sender_templateオブジェクトを通常含めるRSVPメッセージに表示されます。どちらの方向にもイングレスPEと出口PEの間に送られます。これらのオブジェクトは、プロバイダーのバックボーンの外側に送信されるRSVPメッセージに含める必要はありません（上記のリンクに表示される場合、上記のように、Inter-as as option-bおよびoption-cのケースを除く）。これらのオブジェクトの処理ルールは、それ以外の場合は、セクション8.2で定義されているVPN-IPV4（それぞれVPN-IPV6）Sender_Templateオブジェクトの処理ルールと同一です。オブジェクトの形式は次のとおりです。
o AGGREGATE-VPN-IPv4 SENDER_TEMPLATE object: Class = 11, C-Type = 16
o aggregate-vpn-ipv4 sender_templateオブジェクト：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オブジェクト：class = 11、c-type = 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]で指定されているようにエンコードされたVPN-IPV4（VPN-IPV6）のアドレスのアドレスが含まれています（それぞれ[RFC4659]）。これらのオブジェクトのコンテンツおよび処理ルールは、セクション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は、集合体-IPV4および集約IPV6セッションオブジェクトの同じフィールドと同一です。
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]で定義されているように、通常、aggregate-ipv4 filter_specオブジェクトを含むrsvpメッセージに表示され、どちらの方向にもingress peとegress peの間に送信されます。これらのオブジェクトは、プロバイダーのバックボーンの外側に送信されるRSVPメッセージに含める必要はありません（上記のリンクに表示される場合、上記のように、Inter-as as option-bおよびoption-cのケースを除く）。
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オブジェクト：class = 10、c-type = 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オブジェクト：class = 10、c-type = 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セッション[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]
o assigned four new C-Types under the existing SENDER_TEMPLATE Class (Class number 11), as follows: Class Number Class Name Reference ------ ----------------------- ---------
o 既存のsender_templateクラス（クラス番号11）の下に4つの新しいcタイプが割り当てられました。クラス番号クラス名参照------------------------------------------------
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]
o assigned four new C-Types under the existing FILTER_SPEC Class (Class number 10), as follows:
o 次のように、既存のFilter_Specクラス（クラス番号10）の下に4つの新しいCタイプを割り当てました。
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]
o assigned two new C-Types under the existing RSVP_HOP Class (Class number 3), as follows:
o 次のように、既存のRSVP_HOPクラス（クラス番号3）の下に2つの新しいCタイプを割り当てました。
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:
さらに、セクション5.2.2で説明されているように、シグナリングの到達可能性の障害とVPN-IPV4またはVPN-IPV6 RSVP_HOPオブジェクトの必要性を特定するには、新しいPatherrorコード/値が必要です。したがって、IANAはRSVPパラメーターレジストリ、「エラーコード、およびグローバルに定義されたエラー値サブコードのサブレジストリを変更しました。
o assigned a new Error Code and sub-code, as follows:
o 次のように、新しいエラーコードとサブコードを割り当てました。
37 RSVP over MPLS Problem [RFC6016]
MPLS問題を介した37 RSVP [RFC6016]
This Error Code has the following globally-defined Error Value sub-codes:
このエラーコードには、次のグローバルに定義されたエラー値サブコードがあります。
1 = RSVP_HOP not reachable across VPN [RFC6016]
1 = rsvp_hop vpn全体に到達できない[rfc6016]
[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ホップではないプロバイダー内環境へのグループキーイングの適用性に関する議論は、現在のドキュメントで指定されたソリューションを展開する特定のサービスプロバイダーのPESの間で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メッセージは、PEまたはASBRルーターに直接アドレス指定されたL3VPNクラウドを通過するため（IPルーターアラートオプションなし）、Pルーターは顧客の予約を示すRSVPメッセージから分離されたままです。プロバイダーは、本明細書に記載されている機能に影響を与えることなく、セキュリティプラクティスとしてP -Routerアラートオプションを使用してPESの送信をブロックすることを選択できます。
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.
これらの一般的な問題を超えて、このドキュメントで4つの特定の問題が紹介されています。PESでのリソース使用、プロバイダーバックボーンでのリソース使用、AS外のPEルート広告、ASBRとPESへの露出のシグナリング。これらについて順番に説明します。
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リンクが単一の顧客専用の一般的なケースでは、標準のRSVPのように、自分のサイトのCE-PEリンクでリソース予約を行う顧客は、標準のRSVPのように、自分自身とのリンクリソースのみを競います。したがって、CE-PEリンクの観点から見ると、本文書は新しいセキュリティの問題を導入していません。ただし、PEは通常複数の顧客にサービスを提供するため、多数のRSVPメッセージをPEに送信することにより、顧客がPE（CPUサイクル、メモリなど）で過剰な計算リソースを使用しようとする可能性もあります。極端に、これはサービス拒否攻撃の一形態を表している可能性があります。このような攻撃を防ぐために、PEは、1人のCEまたは特定の顧客のCESのセットが消費できる処理リソースの割合を制限するメカニズムをサポートする必要があります。たとえば、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.
2番目の懸念は、セクション4で説明されているように、サービスプロバイダーがバックボーン全体でリソース予約を提供することを選択した場合にのみ発生します。いくつかの異なるCESからの調整された努力により、同じバックボーンを使用して他の顧客へのサービスを拒否します。[RFC4804]は、RSVPの予約がMPLSトンネルに集約されている場合、セキュリティの問題に関するいくつかのガイダンスを提供します。これは、ここで説明する状況に適用されます。プロバイダーはローカルポリシーを使用して、特定のPEから特定の顧客が予約できるリソースの量を制限し、ポリシーサーバーを使用して、必要に応じて複数のPESで特定の顧客のリソース使用を制御できることに注意してください。。この仕様の実装は、特定の顧客/CEが予約できるリソースの量を制御するために、PEに関するローカルポリシーをサポートすることをお勧めします。
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オブジェクトを使用するには、PE VPN-IPV4ルートを別のASにエクスポートする必要があり、それらのルートが無差別に再分配された場合、リモートPEへの未チェックのアクセスを可能にする可能性があります。ただし、セクション3.1で説明されているように、顧客のVPN内にないルートは、その顧客に宣伝される（または到達可能な）ことはありません。PEが顧客VRF内で既にローカルアドレスを使用している場合（PE-CEリンクアドレスなど）、別の顧客VRFのRSVPメッセージにこのアドレスを送信してはなりません。「コントロールプレーン」VPNは、このVPNのPESおよびASBRとアドレスを介して作成できます。顧客のRSVPセッションを通知するために使用できますが、これらのルートは顧客に宣伝されたり、顧客から到達できるようにしてはなりません。現在のドキュメントの実装は、「コントロールプレーン」VPNを使用してそのような操作をサポートする場合があります。あるいは、ASBRSは、ASの直接P/PEルート広告を必要としないため、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）で説明する特定の操作では、ASBRまたはPEが受信し、そのルーターによって宣伝されているBGP Next Hopアドレスにアドレス指定されたシグナリングパケットをローカルで処理する必要があります。この要件は、MPLS/BGP VPNS [RFC4364]に厳密には適用されません。これは、ASBRとPESを開いて、以前に開いていなかった顧客デバイスが直接アドレス指定できると見なすことができ、セキュリティの問題と見なされる可能性があります。プロバイダーがこの状況を軽減したい場合、実装は上記の「制御プロトコル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）での入学制御のために指定されています。PEPEベースでのIPSECの使用と互換性があります。サービスプロバイダーのバックボーン（セクション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操作のモデルを説明しています。一言で言えば、IPSECトンネル用にRSVP予約が行われ、個々のRSVP予約がトンネルの予約を介して認められ/集約される階層RSVP予約の形式が使用されます。このモデルは、IPSECがCE-CEベースで使用される場合に適用されます。そのような状況では、本文書で定義されている手順は、IPSECトンネルに確立された予約に「現状のまま」を単純に適用します。
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.
Ashwini Dahiya、Prashant Srinivas、Yakov Rekhter、Eric Rosen、Dan Tappan、Lou Bergerに感謝します。この文書に記載されている問題を解決するための多くの貢献に感謝します。彼の有用なコメントをしてくれたFerit Yegenogluに感謝します。また、レビューのコメントをしてくれたStefan Santesson、Vijay Gurbani、およびAlexey Melnikovにも感謝します。Richardの傷は、MPLS VPNクラウドで拒否された入場管理のシナリオを議論する追加のテキストをもたらしたものを含む、彼の非常に徹底的なレビューとコメントを含むコメントに感謝します。また、彼の詳細なレビューと貢献について、エイドリアン・ファレルに感謝します。
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.
Egress PEのMPLSラベル内のIPヘッダーを常に調べる実装は、パスメッセージをインターセプトし、カプセル化VPNラベルとIPヘッダーの組み合わせを使用して、正しいVRFとRSVP状態を決定できます。私たちの見解では、これは2つの理由で望ましくないアプローチです。まず、出力PE上のすべてのデータパケットに新しいMPLS転送要件を課します。第二に、カプセル化MPLSラベルを使用してRSVP状態を識別する必要があります。RSVP状態は、RSVP状態を識別するために使用されるすべての情報がRSVPオブジェクトに含まれる既存のRSVP原則と実践に対抗します。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ホップ（Egress PEなど）の適切なVRFに向けられることを保証するために、ラベルスイッチングの使用が含まれます。このようなアプローチでの課題の1つは、[RFC4364]は、顧客のプレフィックスにのみVRFにラベルを割り当てる必要がないこと、およびラベルがVRFにバインドされているという事実を宣伝するための単純な既存の方法がないことです。たとえば、Ingress PEが、パス内の宛先アドレスに一致するプレフィックスの出力PEによって宣伝されたVPNラベルでラベル付けされたパスメッセージを送信した場合、出力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.
このアプローチでの2番目の課題は、IPアドレスをVRFに関連付け、Ingress PEから出力PEに送信したパスメッセージの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）新しいBGP拡張コミュニティを定義して、ルート（および関連するMPLSラベル）にVRFを指すものとしてタグ付けします。（b）各VRFに「ダミー」アドレスを割り当て、特にRSVPメッセージのルーティングに使用する。ダミーアドレス（関連するPEのループバックなど）は、パスメッセージのPHOPとして使用され、RESVメッセージの宛先として機能しますが、他のPEのVRFにインポートされません。
References
参考文献
Normative References
引用文献
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[RFC2113] Katz、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205] Braden、B.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、1997年9月。
[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, October 1999.
[RFC2711] Partridge、C。およびA. Jackson、「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] Baker、F.、Iturralde、C.、Le Faucheur、F。、およびB. Davie、「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] Rosen、E。およびY. Rekhter、「BGP/MPLS IP仮想ネットワーク（VPNS）」、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] De Clercq、J.、Ooms、D.、Carugi、M。、およびF. Le 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] Le Faucheur、F。、「MPLS TE/DS-TEトンネル上のリソース予約プロトコル（RSVP）予約の集約」、RFC 4804、2007年2月。
Informative References
参考引用
[ALERT-USAGE] Le Faucheur, F., Ed., "IP Router Alert Considerations and Usage", Work in Progress, July 2010.
[Alert-Usage] Le Faucheur、F.、ed。、「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] Smith、D.、Mullooly、J.、Jaeger、W。、およびT. Scholl、「IPv4オプションパケットのラベルエッジルーター転送の要件」、2010年5月の進行中。
[RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[RFC1633] Braden、B.、Clark、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] Braden、B。およびL. Zhang、「リソース予約プロトコル（RSVP） - バージョン1メッセージ処理ルール」、RFC 2209、1997年9月。
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[RFC2210] Wroclawski、J。、「IETF統合サービスでのRSVPの使用」、RFC 2210、1997年9月。
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[RFC2747] Baker、F.、Lindell、B。、およびM. Talwar、「RSVP暗号認証」、RFC 2747、2000年1月。
[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] Durham、D.、Boyle、J.、Cohen、R.、Herzog、S.、Rajan、R.、およびA. Sastry、「The Cops（Common Open Policy Service）Protocol」、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] Herzog、S.、Boyle、J.、Cohen、R.、Durham、D.、Rajan、R.、およびA. Sastry、「RSVPのCOPS使用」、RFC 2749、2000年1月。
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., and S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, April 2001.
[RFC2961] Berger、L.、Gan、D.、Swallow、G.、Pan、P.、Tommasi、F.、およびS. Molendini、「RSVP Refrend Overhead Recotion Extensions」、RFC 2961、2001年4月。
[RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic Authentication -- Updated Message Type Value", RFC 3097, April 2001.
[RFC3097] Braden、R。およびL. Zhang、「RSVP暗号化認証 - 更新されたメッセージタイプ値」、RFC 3097、2001年4月。
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473] Berger、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、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）トラフィックエンジニアリング（TE）を備えたラベルスイッチドパス（LSP）階層」、2005年10月。
[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] Swallow、G.、Drake、J.、Ishimatsu、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] Le Faucheur、F.、Davie、B.、Bose、P.、Christou、C。、およびM. Davenport、「ジェネリック集約リソース予約プロトコル（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] Baker、F。およびP. Bose、「ネストされた仮想プライベートネットワークでのサービス品質（QoS）シグナリング」、RFC 4923、2007年8月。
[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] Kumaki、K.、Zhang、R。、およびY. Kamite、「顧客リソース予約プロトコル（RSVP）およびRSVPトラフィックエンジニアリング（RSVP-TE）をBGP/MPLS IP-VPNを介したRSVPトラフィックエンジニアリング（RSVP-TE）をサポートするための要件」、RFC 58244、2010年4月。
[RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet Signalling Transport", RFC 5971, October 2010.
[RFC5971] Schulzrinne、H。およびR. Hancock、「Gist：General Internet Signaling Transport」、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] MANER、J.、Karagiannis、G。、およびA. McDonald、「サービス品質シグナル伝達のためのNSISシグナリング層プロトコル（NSLP）」、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] Behringer、M.、Faucheur、F。、およびB. Weis、「RSVPセキュリティのためのキーイングメソッドの適用可能性」、2010年9月に進行中の作業。
Authors' Addresses
著者のアドレス
Bruce Davie Cisco Systems, Inc. 1414 Mass. Ave. Boxborough, MA 01719 USA
ブルース・デイビー・シスコ・システムズ、Inc。1414Mass。Ave.Boxborough、MA 01719 USA
EMail: 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
Francois Le Faucheur Cisco Systems、Inc。Village D'Entreprise Green Side -Batiment T3 400、Avenue de Roumanille Biot Sophia -Antipolis 06410 France
EMail: flefauch@cisco.com
Ashok Narayanan Cisco Systems, Inc. 1414 Mass. Ave. Boxborough, MA 01719 USA
Ashok Narayanan Cisco Systems、Inc。1414Mass。Ave.Boxborough、MA 01719 USA
EMail: ashokn@cisco.com