Network Working Group D. Awduche
Request for Comments: 3209 Movaz Networks, Inc.
Category: Standards Track L. Berger
D. Gan
Juniper Networks, Inc.
T. Li
Procket Networks, Inc.
V. Srinivasan
Cosine Communications, Inc.
G. Swallow
Cisco Systems, Inc.
December 2001
RSVP-TE: Extensions to RSVP for LSP Tunnels
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
Abstract
抽象
This document describes the use of RSVP (Resource Reservation Protocol), including all the necessary extensions, to establish label-switched paths (LSPs) in MPLS (Multi-Protocol Label Switching). Since the flow along an LSP is completely identified by the label applied at the ingress node of the path, these paths may be treated as tunnels. A key application of LSP tunnels is traffic engineering with MPLS as specified in RFC 2702.
この文書では、MPLS（マルチプロトコルラベルスイッチング）でラベルスイッチパス（LSPを）確立すること、必要なすべての拡張を含むRSVP（リソース予約プロトコル）の使用を記載しています。 LSPに沿った流れが完全パスの入口ノードで適用されたラベルによって識別されるので、これらの経路は、トンネルのように処理することができます。 RFC 2702で指定されたLSPトンネルの主要なアプリケーションは、MPLSとトラフィックエンジニアリングです。
We propose several additional objects that extend RSVP, allowing the establishment of explicitly routed label switched paths using RSVP as a signaling protocol. The result is the instantiation of label-switched tunnels which can be automatically routed away from network failures, congestion, and bottlenecks.
私たちは、明示的にルーティングされたラベルの設立は、シグナリングプロトコルとしてRSVPを使用してパスを切り替えることができ、RSVPを拡張し、いくつかの追加のオブジェクトを提案します。結果は、自動的にネットワーク障害、輻輳、およびボトルネックから離して配線することができますラベルスイッチのトンネルをインスタンス化したものです。
Contents
コンテンツ
1 Introduction .......................................... 3
1.1 Background ............................................. 4
1.2 Terminology ............................................ 6
2 Overview .............................................. 7
2.1 LSP Tunnels and Traffic Engineered Tunnels ............. 7
2.2 Operation of LSP Tunnels ............................... 8
2.3 Service Classes ........................................ 10
2.4 Reservation Styles ..................................... 10
2.4.1 Fixed Filter (FF) Style ................................ 10
2.4.2 Wildcard Filter (WF) Style ............................. 11
2.4.3 Shared Explicit (SE) Style ............................. 11
2.5 Rerouting Traffic Engineered Tunnels ................... 12
2.6 Path MTU ............................................... 13
3 LSP Tunnel related Message Formats ..................... 15
3.1 Path Message ........................................... 15
3.2 Resv Message ........................................... 16
4 LSP Tunnel related Objects ............................. 17
4.1 Label Object ........................................... 17
4.1.1 Handling Label Objects in Resv messages ................ 17
4.1.2 Non-support of the Label Object ........................ 19
4.2 Label Request Object ................................... 19
4.2.1 Label Request without Label Range ...................... 19
4.2.2 Label Request with ATM Label Range ..................... 20
4.2.3 Label Request with Frame Relay Label Range ............. 21
4.2.4 Handling of LABEL_REQUEST .............................. 22
4.2.5 Non-support of the Label Request Object ................ 23
4.3 Explicit Route Object .................................. 23
4.3.1 Applicability .......................................... 24
4.3.2 Semantics of the Explicit Route Object ................. 24
4.3.3 Subobjects ............................................. 25
4.3.4 Processing of the Explicit Route Object ................ 28
4.3.5 Loops .................................................. 30
4.3.6 Forward Compatibility .................................. 30
4.3.7 Non-support of the Explicit Route Object ............... 31
4.4 Record Route Object .................................... 31
4.4.1 Subobjects ............................................. 31
4.4.2 Applicability .......................................... 34
4.4.3 Processing RRO ......................................... 35
4.4.4 Loop Detection ......................................... 36
4.4.5 Forward Compatibility .................................. 37
4.4.6 Non-support of RRO ..................................... 37
4.5 Error Codes for ERO and RRO ............................ 37
4.6 Session, Sender Template, and Filter Spec Objects ...... 38
4.6.1 Session Object ......................................... 39
4.6.2 Sender Template Object ................................. 40
4.6.3 Filter Specification Object ............................ 42
4.6.4 Reroute and Bandwidth Increase Procedure ............... 42
4.7 Session Attribute Object ............................... 43
4.7.1 Format without resource affinities ..................... 43
4.7.2 Format with resource affinities ........................ 45
4.7.3 Procedures applying to both C-Types .................... 46
4.7.4 Resource Affinity Procedures .......................... 48
5 Hello Extension ........................................ 49
5.1 Hello Message Format ................................... 50
5.2 HELLO Object formats ................................... 51
5.2.1 HELLO REQUEST object ................................... 51
5.2.2 HELLO ACK object ....................................... 51
5.3 Hello Message Usage .................................... 52
5.4 Multi-Link Considerations .............................. 53
5.5 Compatibility .......................................... 54
6 Security Considerations ................................ 54
7 IANA Considerations .................................... 54
7.1 Message Types .......................................... 55
7.2 Class Numbers and C-Types .............................. 55
7.3 Error Codes and Globally-Defined Error Value Sub-Codes . 57
7.4 Subobject Definitions .................................. 57
8 Intellectual Property Considerations ................... 58
9 Acknowledgments ........................................ 58
10 References ............................................. 58
11 Authors' Addresses ..................................... 60
12 Full Copyright Statement ............................... 61
Section 2.9 of the MPLS architecture [2] defines a label distribution protocol as a set of procedures by which one Label Switched Router (LSR) informs another of the meaning of labels used to forward traffic between and through them. The MPLS architecture does not assume a single label distribution protocol. This document is a specification of extensions to RSVP for establishing label switched paths (LSPs) in MPLS networks.
MPLSアーキテクチャ[2]のセクション2.9つのラベルは、ルータ（LSR）を交換れる手順のセットとしてラベル配布プロトコルを定義する間、それらを介してトラフィックを転送するために使用されるラベルの意味の他に通知します。 MPLSアーキテクチャは、単一のラベル配布プロトコルを負いません。このドキュメントでは、ラベルは、MPLSネットワーク内のパス（LSPを）切り替え確立するためのRSVPへの拡張機能の仕様です。
Several of the new features described in this document were motivated by the requirements for traffic engineering over MPLS (see [3]). In particular, the extended RSVP protocol supports the instantiation of explicitly routed LSPs, with or without resource reservations. It also supports smooth rerouting of LSPs, preemption, and loop detection.
このドキュメントで説明する新機能のいくつかは、MPLS上のトラフィックエンジニアリングのための要件が動機とされた（[3]参照）。具体的には、拡張されたRSVPプロトコルは、リソース予約の有無にかかわらず、明示的にルーティングされたLSPのインスタンス化をサポートしています。また、スムーズなLSPの再ルーティング、プリエンプション、およびループ検出をサポートしています。
The LSPs created with RSVP can be used to carry the "Traffic Trunks" described in [3]. The LSP which carries a traffic trunk and a traffic trunk are distinct though closely related concepts. For example, two LSPs between the same source and destination could be load shared to carry a single traffic trunk. Conversely several traffic trunks could be carried in the same LSP if, for instance, the LSP were capable of carrying several service classes. The applicability of these extensions is discussed further in [10].
RSVPで作成されたLSPは、[3]に記載の「トラフィックトランク」を運ぶために使用することができます。トラフィックトランクとトラフィックトランクを運ぶLSPは、密接に関連する概念けれども異なります。例えば、同一の送信元と宛先の間の2つのLSPは、負荷は、単一のトラフィックトランクを運ぶために共有することができます。例えば、LSPは、複数のサービス・クラスを運ぶことができた、場合逆に、いくつかのトラフィックトランクが同じLSPで搬送することができます。これらの拡張機能の適用は、[10]で詳しく説明されています。
Since the traffic that flows along a label-switched path is defined by the label applied at the ingress node of the LSP, these paths can be treated as tunnels, tunneling below normal IP routing and filtering mechanisms. When an LSP is used in this way we refer to it as an LSP tunnel.
ラベルスイッチパスに沿って流れるトラフィックはLSPの入口ノードで適用されたラベルによって定義されているため、これらの経路は、トンネル、通常のIPルーティングおよびフィルタリングメカニズム下トンネリングとして扱うことができます。 LSPがこのように使用されている場合、我々は、LSPトンネルのようにそれを参照します。
LSP tunnels allow the implementation of a variety of policies related to network performance optimization. For example, LSP tunnels can be automatically or manually routed away from network failures, congestion, and bottlenecks. Furthermore, multiple parallel LSP tunnels can be established between two nodes, and traffic between the two nodes can be mapped onto the LSP tunnels according to local policy. Although traffic engineering (that is, performance optimization of operational networks) is expected to be an important application of this specification, the extended RSVP protocol can be used in a much wider context.
LSPトンネルは、ネットワークパフォーマンスの最適化に関連する政策の様々な実装を可能にします。例えば、LSPトンネルは自動または手動でネットワーク障害、輻輳、およびボトルネックから離れてルーティングすることができます。さらに、複数の並列LSPトンネルは2つのノード間に確立することができ、2つのノード間のトラフィックは、ローカルポリシーに従ってLSPトンネルにマッピングすることができます。トラフィックエンジニアリングは、（つまり、運用ネットワークのパフォーマンスの最適化である）、この仕様の重要なアプリケーションであることが予想されるが、拡張されたRSVPプロトコルは、はるかに広い文脈で使用することができます。
The purpose of this document is to describe the use of RSVP to establish LSP tunnels. The intent is to fully describe all the objects, packet formats, and procedures required to realize interoperable implementations. A few new objects are also defined that enhance management and diagnostics of LSP tunnels.
このドキュメントの目的は、LSPトンネルを確立するために、RSVPの使用を記述することです。目的は、完全に相互運用可能な実装を実現するために必要なすべてのオブジェクト、パケットフォーマット、および手順を記述することです。いくつかの新しいオブジェクトも、それは管理とLSPトンネルの診断を強化定義されています。
The document also describes a means of rapid node failure detection via a new HELLO message.
文書はまた、新しいHELLOメッセージを経由して、迅速なノード障害検出の手段が記載されています。
All objects and messages described in this specification are optional with respect to RSVP. This document discusses what happens when an object described here is not supported by a node.
本明細書に記載されたすべてのオブジェクトとのメッセージがRSVPに関しては省略可能です。このドキュメントでは、ここで説明したオブジェクトは、ノードによってサポートされていないときに何が起こるかを説明します。
Throughout this document, the discussion will be restricted to unicast label switched paths. Multicast LSPs are left for further study.
本書では、議論はユニキャストのラベルに制限されますパスを切り替えます。マルチキャストLSPは、さらなる研究のために残されています。
Hosts and routers that support both RSVP [1] and Multi-Protocol Label Switching [2] can associate labels with RSVP flows. When MPLS and RSVP are combined, the definition of a flow can be made more flexible. Once a label switched path (LSP) is established, the traffic through the path is defined by the label applied at the ingress node of the LSP. The mapping of label to traffic can be accomplished using a number of different criteria. The set of packets that are assigned the same label value by a specific node are said to belong to the same forwarding equivalence class (FEC) (see [2]), and effectively define the "RSVP flow." When traffic is mapped onto a label-switched path in this way, we call the LSP an "LSP Tunnel". When labels are associated with traffic flows, it becomes possible for a router to identify the appropriate reservation state for a packet based on the packet's label value.
ホストとの両方RSVP [1]と[2] RSVPフローにラベルを関連付けることができるマルチプロトコルラベルスイッチングをサポートするルータ。 MPLSおよびRSVPを組み合わせた場合、フローの定義をより柔軟にすることができます。ラベルスイッチドパス（LSP）が確立されると、パスを介してトラフィックがLSPの入口ノードで適用されたラベルによって定義されます。トラフィックへのラベルのマッピングは、異なる多くの基準を用いて達成することができます。特定のノードが同一のラベル値が付与されたパケットのセットは、同じ転送等価クラス（FEC）（参照[2]）、かつ効果的に定義するために属すると言われている「RSVPフロー」。トラフィックがこのようにラベルスイッチパス上にマッピングされたとき、私たちは「LSPトンネル」LSPを呼び出します。ラベルはトラフィックフローに関連付けられている場合、ルータは、パケットのラベル値に基づいてパケットのための適切な予約状態を識別することが可能となります。
The signaling protocol model uses downstream-on-demand label distribution. A request to bind labels to a specific LSP tunnel is initiated by an ingress node through the RSVP Path message. For this purpose, the RSVP Path message is augmented with a LABEL_REQUEST object. Labels are allocated downstream and distributed (propagated upstream) by means of the RSVP Resv message. For this purpose, the RSVP Resv message is extended with a special LABEL object. The procedures for label allocation, distribution, binding, and stacking are described in subsequent sections of this document.
シグナリングプロトコルモデルは、ダウンストリームオンデマンドラベル配布を使用しています。特定LSPトンネルにラベルを結合するための要求がRSVP Pathメッセージを介して入口ノードによって開始されます。この目的のために、RSVP PathメッセージはLABEL_REQUESTオブジェクトで拡張されます。ラベルは下流割り当てられ、RSVP Resvメッセージによって（上流伝播）に分布しています。この目的のために、RSVP Resvメッセージは、特別なLABELオブジェクトに拡張されます。ラベル割り当て、分布、結合、および積層の手順は、この文書の後のセクションに記載されています。
The signaling protocol model also supports explicit routing capability. This is accomplished by incorporating a simple EXPLICIT_ROUTE object into RSVP Path messages. The EXPLICIT_ROUTE object encapsulates a concatenation of hops which constitutes the explicitly routed path. Using this object, the paths taken by label-switched RSVP-MPLS flows can be pre-determined, independent of conventional IP routing. The explicitly routed path can be administratively specified, or automatically computed by a suitable entity based on QoS and policy requirements, taking into consideration the prevailing network state. In general, path computation can be control-driven or data-driven. The mechanisms, processes, and algorithms used to compute explicitly routed paths are beyond the scope of this specification.
シグナリングプロトコルモデルは、明示的なルーティング機能をサポートしています。これは、RSVPパスメッセージに簡単なEXPLICIT_ROUTEオブジェクトを組み込むことによって達成されます。 EXPLICIT_ROUTEオブジェクトは、明示的ルーティング経路を構成するホップの連結をカプセル化します。このオブジェクトを使用して、ラベルスイッチRSVP-MPLS流れによって取られる経路は、従来のIPルーティングの独立予め決定することができます。明示的にルーティングされたパスは、管理指定、または自動的に考慮現行のネットワーク状態を取って、QoSおよびポリシー要件に基づいて適切なエンティティによって計算することができます。一般に、経路計算は制御駆動またはデータ駆動型であってもよいです。明示的ルーティング経路を計算するために使用されるメカニズム、プロセス、およびアルゴリズムは、本明細書の範囲外です。
One useful application of explicit routing is traffic engineering. Using explicitly routed LSPs, a node at the ingress edge of an MPLS domain can control the path through which traffic traverses from itself, through the MPLS network, to an egress node. Explicit routing can be used to optimize the utilization of network resources and enhance traffic oriented performance characteristics.
明示的なルーティングの一つの有用な用途は、トラフィックエンジニアリングです。明示的にルーティングされたLSPを使用して、MPLSドメインの入口端のノードは、トラフィックが出口ノードに、MPLSネットワークを介して、自身から横断する経路を制御することができます。明示的なルーティングは、ネットワークリソースの使用率を最適化し、トラフィック指向の性能特性を向上させるために使用することができます。
The concept of explicitly routed label switched paths can be generalized through the notion of abstract nodes. An abstract node is a group of nodes whose internal topology is opaque to the ingress node of the LSP. An abstract node is said to be simple if it contains only one physical node. Using this concept of abstraction, an explicitly routed LSP can be specified as a sequence of IP prefixes or a sequence of Autonomous Systems.
明示的にルーティングされたラベルのコンセプトは、パスが抽象ノードの概念を通じて一般化することができるスイッチ。抽象ノードは、内部トポロジーLSPの入口ノードに不透明であるノードのグループです。抽象化ノードは、それが唯一の物理ノードが含まれている場合は、簡単なことと言われています。抽象化のこの概念を使用して、明示的にルーティングされたLSPは、IPプレフィックスのシーケンスまたは自律システムのシーケンスとして指定することができます。
The signaling protocol model supports the specification of an explicit path as a sequence of strict and loose routes. The combination of abstract nodes, and strict and loose routes significantly enhances the flexibility of path definitions.
シグナリングプロトコルモデルは、厳密とルーズ経路のシーケンスとして、明示的なパスの指定をサポートします。抽象ノード、及び厳密緩い経路の組み合わせが有意パス定義の柔軟性を高めます。
An advantage of using RSVP to establish LSP tunnels is that it enables the allocation of resources along the path. For example, bandwidth can be allocated to an LSP tunnel using standard RSVP reservations and Integrated Services service classes [4].
LSPトンネルを確立するために、RSVPを使用する利点は、それがパスに沿ってリソースの割り当てを可能にするということです。たとえば、帯域幅は、標準的なRSVPの予約とサービス統合サービス・クラスを使用して、LSPトンネルに割り当てられることができる[4]。
While resource reservations are useful, they are not mandatory. Indeed, an LSP can be instantiated without any resource reservations whatsoever. Such LSPs without resource reservations can be used, for example, to carry best effort traffic. They can also be used in many other contexts, including implementation of fall-back and recovery policies under fault conditions, and so forth.
リソース予約が有用であるが、彼らは必須ではありません。確かに、LSPはいかなるリソース予約なしでインスタンス化することができます。リソース予約なしでこのようなLSPはベストエフォートトラフィックを運ぶために、例えば、使用することができます。彼らはまた、などの故障状態の下でフォールバックと回復政策の実施を含む他の多くの文脈で使用することができます。
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 RFC2119 [6].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC2119 [6]に記載のように解釈されます。
The reader is assumed to be familiar with the terminology in [1], [2] and [3].
読者はで専門用語に精通していると仮定される[1]、[2]、[3]。
Abstract Node
抽象ノード
A group of nodes whose internal topology is opaque to the ingress node of the LSP. An abstract node is said to be simple if it contains only one physical node.
内部トポロジーLSPの入口ノードに不透明であるノードのグループ。抽象化ノードは、それが唯一の物理ノードが含まれている場合は、簡単なことと言われています。
Explicitly Routed LSP
明示的ルートLSP
An LSP whose path is established by a means other than normal IP routing.
その経路通常のIPルーティング以外の手段によって確立されるLSP。
Label Switched Path
ラベルスイッチパス
The path created by the concatenation of one or more label switched hops, allowing a packet to be forwarded by swapping labels from an MPLS node to another MPLS node. For a more precise definition see [2].
一つ以上のラベルの連結によって作成されたパスは、パケットが他のMPLSノードにMPLSノードからのラベルを交換することにより転送されることを可能にする、ホップを切り替えます。より正確な定義のための[2]を参照。
LSP
LSP
A Label Switched Path
ラベルスイッチパス
LSP Tunnel
LSPトンネル
An LSP which is used to tunnel below normal IP routing and/or filtering mechanisms.
通常のIPルーティングおよび/またはフィルタリング機構以下トンネルに使用されるLSP。
Traffic Engineered Tunnel (TE Tunnel)
交通エンジニアトンネル（TEトンネル）
A set of one or more LSP Tunnels which carries a traffic trunk.
トラフィックトランクを運ぶ一つ以上のLSPトンネルのセット。
Traffic Trunk
交通トランク
A set of flows aggregated by their service class and then placed on an LSP or set of LSPs called a traffic engineered tunnel. For further discussion see [3].
LSP上に配置された、またはLSPのセット次いで、そのサービスクラスによって集約され、流れのセットは、トラヒックエンジニアリングトンネルと呼ばれます。さらなる議論に関しては、[3]を参照してください。
According to [1], "RSVP defines a 'session' to be a data flow with a particular destination and transport-layer protocol." However, when RSVP and MPLS are combined, a flow or session can be defined with greater flexibility and generality. The ingress node of an LSP can use a variety of means to determine which packets are assigned a particular label. Once a label is assigned to a set of packets, the label effectively defines the "flow" through the LSP. We refer to such an LSP as an "LSP tunnel" because the traffic through it is opaque to intermediate nodes along the label switched path.
[1]によれば、「RSVPは、特定の宛先とトランスポート層プロトコルとデータ・フローであることを 『セッション』を定義します。」 RSVPとMPLSを組み合わせた場合しかし、フロー又はセッションは、柔軟性と汎用性と定義することができます。 LSPの入口ノードは、パケットが特定のラベルが割り当てられているかを決定するための様々な手段を使用することができます。ラベルはパケットの集合に割り当てられると、ラベルを効果LSPを介して「フロー」を定義します。ラベルスイッチパスに沿って通過するトラフィックは、中間ノードに不透明であるので、我々は、「LSPトンネル」のようなLSPを指します。
New RSVP SESSION, SENDER_TEMPLATE, and FILTER_SPEC objects, called LSP_TUNNEL_IPv4 and LSP_TUNNEL_IPv6 have been defined to support the LSP tunnel feature. The semantics of these objects, from the perspective of a node along the label switched path, is that traffic belonging to the LSP tunnel is identified solely on the basis of packets arriving from the PHOP or "previous hop" (see [1]) with the particular label value(s) assigned by this node to upstream senders to the session. In fact, the IPv4(v6) that appears in the object name only denotes that the destination address is an IPv4(v6) address. When we refer to these objects generically, we use the qualifier LSP_TUNNEL.
LSP_TUNNEL_IPv4とLSP_TUNNEL_IPv6と呼ばれる新しいRSVP SESSION、SENDER_TEMPLATE、およびFILTER_SPECオブジェクトは、LSPトンネル機能をサポートするために定義されています。ラベルスイッチパスに沿ったノードの観点から、これらのオブジェクトの意味論、LSPトンネルに属するトラフィックを単独PHOPまたは「前ホップ」から到着したパケットに基づいて識別されることである（[1]参照）セッションへの送信者の上流には、このノードによって割り当てられた特定のラベル値（複数可）。実際には、オブジェクト名に表示されたIPv4（V6）は、宛先アドレスだけがIPv4（V6）アドレスであることを示しています。我々は一般的に、これらのオブジェクトを参照するとき、我々は予選LSP_TUNNELを使用しています。
In some applications it is useful to associate sets of LSP tunnels. This can be useful during reroute operations or to spread a traffic trunk over multiple paths. In the traffic engineering application such sets are called traffic engineered tunnels (TE tunnels). To enable the identification and association of such LSP tunnels, two identifiers are carried. A tunnel ID is part of the SESSION object. The SESSION object uniquely defines a traffic engineered tunnel. The
一部のアプリケーションでは、LSPトンネルのセットを関連付けることが便利です。これは、リルート操作中に有用であり得るか、または複数のパスを介してトラフィックトランクを広めるために。トラフィックエンジニアリングアプリケーションでは、このようなセットは、トラフィックエンジニアリングトンネル（TEトンネル）と呼ばれています。そのようなLSPトンネルの同定および関連付けを可能にするために、二つの識別子を搭載しています。トンネルIDは、セッションオブジェクトの一部です。 SESSIONオブジェクトを一意にトラヒックエンジニアリングトンネルを定義します。ザ・
SENDER_TEMPLATE and FILTER_SPEC objects carry an LSP ID. The SENDER_TEMPLATE (or FILTER_SPEC) object together with the SESSION object uniquely identifies an LSP tunnel
RENDER_TEMPLATEとFILTER SPECオブジェクトはLSP ISを運びます。 RENDER_TEMPLATE（又はFILTER_SPEC）SESSIONオブジェクトとともにオブジェクトが一意にLSPトンネルを識別する
This section summarizes some of the features supported by RSVP as extended by this document related to the operation of LSP tunnels. These include: (1) the capability to establish LSP tunnels with or without QoS requirements, (2) the capability to dynamically reroute an established LSP tunnel, (3) the capability to observe the actual route traversed by an established LSP tunnel, (4) the capability to identify and diagnose LSP tunnels, (5) the capability to preempt an established LSP tunnel under administrative policy control, and (6) the capability to perform downstream-on-demand label allocation, distribution, and binding. In the following paragraphs, these features are briefly described. More detailed descriptions can be found in subsequent sections of this document.
LSPトンネルの動作に関連する本文書によって拡張としてこのセクションでは、RSVPによってサポートされる機能の一部をまとめたもの。これらは、（1）QoS要件の有無にかかわらずLSPトンネルを確立する能力を、動的に確立されたLSPトンネルを再ルーティングする（2）機能、確立されたLSPトンネルによって横断実際のルートを観察する（3）機能、（4 ）を識別し、診断LSPトンネルを、（5）機能は、管理ポリシー・コントロールの下で設立LSPトンネルを先取りする、及び（6）能力が下流オンデマンドラベル割り当て、分布、及び結合を行うようにする能力。以下の段落では、これらの機能について簡単に説明されています。より詳細な説明は、このドキュメントの後のセクションに記載されています。
To create an LSP tunnel, the first MPLS node on the path -- that is, the sender node with respect to the path -- creates an RSVP Path message with a session type of LSP_TUNNEL_IPv4 or LSP_TUNNEL_IPv6 and inserts a LABEL_REQUEST object into the Path message. The LABEL_REQUEST object indicates that a label binding for this path is requested and also provides an indication of the network layer protocol that is to be carried over this path. The reason for this is that the network layer protocol sent down an LSP cannot be assumed to be IP and cannot be deduced from the L2 header, which simply identifies the higher layer protocol as MPLS.
LSPトンネルを作成するために、経路上の最初のMPLSノード - 、パスに対する送信元ノードである - LSP_TUNNEL_IPv4又はLSP_TUNNEL_IPv6のセッションタイプでRSVP Pathメッセージを作成し、PathメッセージにLABEL_REQUESTオブジェクトを挿入します。 LABEL_REQUESTオブジェクトは、このパスに対する結合ラベルが要求されていることを示し、またこのパスを介して搬送されるネットワーク層プロトコルの指標を提供します。この理由は、ネットワーク層プロトコルはIPであると仮定することができないLSPを下し単にMPLSなどの上位層プロトコルを特定するL2ヘッダ、から推定することができないことです。
If the sender node has knowledge of a route that has high likelihood of meeting the tunnel's QoS requirements, or that makes efficient use of network resources, or that satisfies some policy criteria, the node can decide to use the route for some or all of its sessions. To do this, the sender node adds an EXPLICIT_ROUTE object to the RSVP Path message. The EXPLICIT_ROUTE object specifies the route as a sequence of abstract nodes.
送信ノードは、トンネルのQoS要件を満たす見込みが高いルートの知識を持っている、またはそれは、ネットワークリソースを効率的に使用し、またはそのいくつかのポリシー基準を満たしている場合、ノードは、その一部またはすべてのルートを使用することを決定することができますセッション。これを行うには、送信側ノードは、RSVP PathメッセージにEXPLICIT_ROUTEオブジェクトを追加します。 EXPLICIT_ROUTEオブジェクトは抽象ノードのシーケンスとして経路を特定します。
If, after a session has been successfully established, the sender node discovers a better route, the sender can dynamically reroute the session by simply changing the EXPLICIT_ROUTE object. If problems are encountered with an EXPLICIT_ROUTE object, either because it causes a routing loop or because some intermediate routers do not support it, the sender node is notified.
、セッションが正常に確立された後、送信ノードは、より良いルートを発見した場合、送信者は動的単にEXPLICIT_ROUTEオブジェクトを変更することで、セッションを再ルーティングすることができます。問題はEXPLICIT_ROUTEオブジェクトに遭遇した場合は、どちらかそれは、ルーティングループが発生したり、いくつかの中間ルータがそれをサポートしていないため、送信ノードに通知されるため。
By adding a RECORD_ROUTE object to the Path message, the sender node can receive information about the actual route that the LSP tunnel traverses. The sender node can also use this object to request notification from the network concerning changes to the routing path. The RECORD_ROUTE object is analogous to a path vector, and hence can be used for loop detection.
PathメッセージにRECORD_ROUTEオブジェクトを追加することによって、送信側ノードは、LSPトンネルを横断する実際の経路に関する情報を受信することができます。送信側ノードは、ルーティング経路の変更に関するネットワークからの通知を要求するために、このオブジェクトを使用することができます。 RECORD_ROUTEオブジェクトは、パスベクトルに類似しており、従って、ループ検出のために使用することができます。
Finally, a SESSION_ATTRIBUTE object can be added to Path messages to aid in session identification and diagnostics. Additional control information, such as setup and hold priorities, resource affinities (see [3]), and local-protection, are also included in this object.
最後に、SESSION_ATTRIBUTEオブジェクトは、セッションの識別と診断を支援するためにPathメッセージに追加することができます。このようなセットアップおよびホールド優先度、リソースの親和性（[3]参照）、及びローカル保護などの追加の制御情報は、このオブジェクトに含まれています。
Routers along the path may use the setup and hold priorities along with SENDER_TSPEC and any POLICY_DATA objects contained in Path messages as input to policy control. For instance, in the traffic engineering application, it is very useful to use the Path message as a means of verifying that bandwidth exists at a particular priority along an entire path before preempting any lower priority reservations. If a Path message is allowed to progress when there are insufficient resources, then there is a danger that lower priority reservations downstream of this point will unnecessarily be preempted in a futile attempt to service this request.
経路に沿ったルータは、セットアップを使用して、SENDER_TSPECおよびポリシー制御への入力としてPathメッセージに含まれるPOLICY_DATAオブジェクトとともに優先度を保持することができます。例えば、トラフィックエンジニアリングアプリケーションでは、帯域幅が任意のより低い優先度の予約を先取りする前に全体の経路に沿って特定の優先度で存在することを確認する手段として、Pathメッセージを使用することは非常に有用です。 Pathメッセージが不十分なリソースがある場合に進行させている場合は、この時点の下流で、優先順位の低い予約が必要以上にこの要求を処理するために無益な試みでプリエンプトされる危険性があります。
When the EXPLICIT_ROUTE object (ERO) is present, the Path message is forwarded towards its destination along a path specified by the ERO. Each node along the path records the ERO in its path state block. Nodes may also modify the ERO before forwarding the Path message. In this case the modified ERO SHOULD be stored in the path state block in addition to the received ERO.
EXPLICIT_ROUTEオブジェクト（ERO）が存在する場合に、Pathメッセージは、EROによって指定されたパスに沿ってその宛先に向けて転送されます。経路に沿った各ノードは、そのパス状態ブロックにおけるEROを記録します。ノードはまた、Pathメッセージを転送する前にEROを変更することがあります。この場合、修飾されたEROは、受信したEROに加えて、パス状態ブロック内に保存されるべきです。
The LABEL_REQUEST object requests intermediate routers and receiver nodes to provide a label binding for the session. If a node is incapable of providing a label binding, it sends a PathErr message with an "unknown object class" error. If the LABEL_REQUEST object is not supported end to end, the sender node will be notified by the first node which does not provide this support.
LABEL_REQUESTオブジェクトは、セッションのための結合標識を提供するために、中間ルータと受信ノードを要求します。ノードは、ラベルバインディングを提供することができない場合、それは「未知のオブジェクトクラス」エラーでのPathErrメッセージを送信します。 LABEL_REQUESTオブジェクトはエンドツーエンドのサポートされていない場合、送信ノードは、このサポートを提供していません最初のノードによって通知されます。
The destination node of a label-switched path responds to a LABEL_REQUEST by including a LABEL object in its response RSVP Resv message. The LABEL object is inserted in the filter spec list immediately following the filter spec to which it pertains.
ラベルスイッチパスの宛先ノードは、その応答RSVP RESVメッセージのラベルオブジェクトを含むことによってLABEL_REQUESTに応答します。 LABELオブジェクトは直ちにそれが関連するフィルタスペック次フィルタスペックリストに挿入されます。
The Resv message is sent back upstream towards the sender, following the path state created by the Path message, in reverse order. Note that if the path state was created by use of an ERO, then the Resv message will follow the reverse path of the ERO.
Resvメッセージは、逆の順序でPathメッセージによって作成されたパスの状態を、以下、送信側に向かって上流に送り返されます。パス状態がEROを用いて作成された場合、次にResvメッセージがEROの逆の経路をたどることに注意してください。
Each node that receives a Resv message containing a LABEL object uses that label for outgoing traffic associated with this LSP tunnel. If the node is not the sender, it allocates a new label and places that label in the corresponding LABEL object of the Resv message which it sends upstream to the PHOP. The label sent upstream in the LABEL object is the label which this node will use to identify incoming traffic associated with this LSP tunnel. This label also serves as shorthand for the Filter Spec. The node can now update its "Incoming Label Map" (ILM), which is used to map incoming labeled packets to a "Next Hop Label Forwarding Entry" (NHLFE), see [2].
LABELオブジェクトを含むResvメッセージを受信する各ノードはこのLSPトンネルに関連付けられた発信トラフィックのためにそのラベルを使用します。ノードが送信者でない場合、それはPHOPに上流の送信Resvメッセージの対応LABELオブジェクトにラベルを付け、新しいラベルと場所を割り当てます。 LABELオブジェクト上流送信ラベルは、このノードがこのLSPトンネルに関連付けられた着信トラフィックを識別するために使用されるラベルです。このラベルは、フィルタ仕様の省略形として機能します。ノードは、現在[2]を参照、「ネクストホップラベル転送エントリー」（NHLFE）に入ってくる標識されたパケットをマップするために使用され、その「受信ラベルマップ」（ILM）を更新することができます。
When the Resv message propagates upstream to the sender node, a label-switched path is effectively established.
Resvメッセージは、送信ノードの上流伝播する際、ラベルスイッチパスを効果的に確立されます。
This document does not restrict the type of Integrated Service requests for reservations. However, an implementation SHOULD support the Controlled-Load service [4] and the Null Service [16].
この文書では、予約のための統合されたサービス要求の種類を制限するものではありません。しかし、実装が[16] [4]及びヌルサービス制御負荷サービスをサポートしなければなりません。
The receiver node can select from among a set of possible reservation styles for each session, and each RSVP session must have a particular style. Senders have no influence on the choice of reservation style. The receiver can choose different reservation styles for different LSPs.
受信ノードは、各セッションのための可能な予約スタイルのセットの中から選択することができ、それぞれのRSVPセッションは、特定のスタイルを持っている必要があります。送信者は、予約スタイルの選択に影響を及ぼしません。受信機は、異なるLSPのために異なる予約スタイルを選択することができます。
An RSVP session can result in one or more LSPs, depending on the reservation style chosen.
RSVPセッションは、選択された予約スタイルに応じて、1つのまたは複数のLSPにつながることができます。
Some reservation styles, such as FF, dedicate a particular reservation to an individual sender node. Other reservation styles, such as WF and SE, can share a reservation among several sender nodes. The following sections discuss the different reservation styles and their advantages and disadvantages. A more detailed discussion of reservation styles can be found in [1].
例えばFFのようないくつかの予約スタイルは、個々の送信元ノードに特定の予約を捧げます。このようWFやSEなどの他の予約スタイルは、いくつかの送信ノード間で予約を共有することができます。次のセクションでは、異なる予約スタイルとその長所と短所を議論します。予約スタイルのより詳細な説明は、[1]に見出すことができます。
The Fixed Filter (FF) reservation style creates a distinct reservation for traffic from each sender that is not shared by other senders. This style is common for applications in which traffic from each sender is likely to be concurrent and independent. The total amount of reserved bandwidth on a link for sessions using FF is the sum of the reservations for the individual senders.
固定フィルタ（FF）予約スタイルは、他の送信者によって共有されていない各送信元からのトラフィックのための個別の予約を作成します。このスタイルは、各送信者からのトラフィックが同時かつ独立した可能性が高いである用途のために一般的です。 FFを使用して、セッションのリンク上の予約帯域幅の合計は、個々の送信者の予約の合計です。
Because each sender has its own reservation, a unique label is assigned to each sender. This can result in a point-to-point LSP between every sender/receiver pair.
各送信者は、自身の予約を持っているので、ユニークなラベルは、各送信者に割り当てられています。これは、すべての送信側/受信側のペア間のポイントツーポイントLSPをもたらすことができます。
With the Wildcard Filter (WF) reservation style, a single shared reservation is used for all senders to a session. The total reservation on a link remains the same regardless of the number of senders.
ワイルドカードフィルタ（WF）予約スタイルで、単一の共有の予約は、セッションへのすべての送信者に使用されます。リンク上のご予約総額にかかわらず、送信者の数と同じまま。
A single multipoint-to-point label-switched-path is created for all senders to the session. On links that senders to the session share, a single label value is allocated to the session. If there is only one sender, the LSP looks like a normal point-to-point connection. When multiple senders are present, a multipoint-to-point LSP (a reversed tree) is created.
単一のマルチポイント・ツー・ポイントのラベルスイッチパスは、セッションへのすべての送信者のために作成されます。セッション共有に送信者のリンクでは、単一のラベル値は、セッションに割り当てられています。唯一の送信者が存在する場合、LSPは通常のポイントツーポイント接続のように見えます。複数の送信者が存在する場合、マルチポイントツーポイントLSP（逆ツリー）が作成されます。
This style is useful for applications in which not all senders send traffic at the same time. A phone conference, for example, is an application where not all speakers talk at the same time. If, however, all senders send simultaneously, then there is no means of getting the proper reservations made. Either the reserved bandwidth on links close to the destination will be less than what is required or then the reserved bandwidth on links close to some senders will be greater than what is required. This restricts the applicability of WF for traffic engineering purposes.
このスタイルではないすべての送信者が同時にトラフィックを送信する用途に有用です。電話会議は、たとえば、いないすべてのスピーカーが同時に話をするアプリケーションです。しかし、すべての送信者が同時に送信する場合は、作られた適切な予約を取得する手段がありません。目的地に近いリンク上の予約帯域幅のいずれかが必要とされるものよりも小さくなりますかその後、いくつかの送信者に近いリンク上の予約帯域幅が必要とされるものよりも大きくなります。これは、トラフィックエンジニアリングの目的で、WFの適用可能性を制限します。
Furthermore, because of the merging rules of WF, EXPLICIT_ROUTE objects cannot be used with WF reservations. As a result of this issue and the lack of applicability to traffic engineering, use of WF is not considered in this document.
また、WFのマージルールのため、EXPLICIT_ROUTEオブジェクトはWFの予約と一緒に使用することができません。この問題およびトラフィックエンジニアリングへの適用性の欠如の結果として、WFの使用は、この文書では考慮されていません。
The Shared Explicit (SE) style allows a receiver to explicitly specify the senders to be included in a reservation. There is a single reservation on a link for all the senders listed. Because each sender is explicitly listed in the Resv message, different labels may be assigned to different senders, thereby creating separate LSPs.
共有明示（SE）スタイルは、受信機が明示的に予約に含まれる送信者を指定することができます。記載されているすべての送信者のリンク上の単一の予約があります。各送信者が明示的にResvメッセージに記載されているので、異なるラベルが、異なる送信者に割り当てられ、それによって別個のLSPを作成することができます。
SE style reservations can be provided using multipoint-to-point label-switched-path or LSP per sender. Multipoint-to-point LSPs may be used when path messages do not carry the EXPLICIT_ROUTE object, or when Path messages have identical EXPLICIT_ROUTE objects. In either of these cases a common label may be assigned.
SEスタイルの予約は、マルチポイント・ツー・ポイントのラベルスイッチパスまたは送信者ごとにLSPを使用して提供することができます。パスメッセージはEXPLICIT_ROUTEオブジェクトを運ばないときマルチポイント・ツー・ポイントのLSPを用いてもよいし、Pathメッセージは、同一のEXPLICIT_ROUTEオブジェクトを持っている場合。どちらの場合も、共通のラベルを割り当てることもできます。
Path messages from different senders can each carry their own ERO, and the paths taken by the senders can converge and diverge at any point in the network topology. When Path messages have differing EXPLICIT_ROUTE objects, separate LSPs for each EXPLICIT_ROUTE object must be established.
異なる送信者からのPathメッセージは、それぞれ独自のEROを運ぶことができ、及び送信者によって取られる経路は、ネットワークトポロジ内の任意の点に収束と発散することができます。 PathメッセージがEXPLICIT_ROUTEオブジェクトが異なるたら、各EXPLICIT_ROUTEオブジェクトに対して別々のLSPを確立する必要があります。
One of the requirements for Traffic Engineering is the capability to reroute an established TE tunnel under a number of conditions, based on administrative policy. For example, in some contexts, an administrative policy may dictate that a given TE tunnel is to be rerouted when a more "optimal" route becomes available. Another important context when TE tunnel reroute is usually required is upon failure of a resource along the TE tunnel's established path. Under some policies, it may also be necessary to return the TE tunnel to its original path when the failed resource becomes re-activated.
トラフィックエンジニアリングのための要件の1つは、管理ポリシーに基づいて、多数の条件の下で設立されTEトンネルを再ルーティングする機能です。例えば、いくつかの文脈では、管理ポリシーは、より「最適」経路が利用可能になったとき、所与のTEトンネルが再ルーティングされることを指示することができます。 TEトンネル・リルートが通常必要とされるもう一つの重要な文脈は、TEトンネルの確立されたパスに沿ってリソースの障害時です。いくつかの方針の下で、また、失敗したリソースが再活性化になったときにその元の経路にTEトンネルを返すために必要であり得ます。
In general, it is highly desirable not to disrupt traffic, or adversely impact network operations while TE tunnel rerouting is in progress. This adaptive and smooth rerouting requirement necessitates establishing a new LSP tunnel and transferring traffic from the old LSP tunnel onto it before tearing down the old LSP tunnel. This concept is called "make-before-break." A problem can arise because the old and new LSP tunnels might compete with each other for resources on network segments which they have in common. Depending on availability of resources, this competition can cause Admission Control to prevent the new LSP tunnel from being established. An advantage of using RSVP to establish LSP tunnels is that it solves this problem very elegantly.
一般的には、トラフィックを中断させるか、または不利TEトンネル再ルーティングの進行中に、ネットワーク・オペレーションに影響を与えないことが非常に望ましいです。この適応とスムーズな再ルーティングの要件は、新しいLSPトンネルを確立し、古いLSPトンネルを切断する前に、その上に古いLSPトンネルからのトラフィックを転送する必要があります。この概念は、「メーク・ビフォア・ブレイク」と呼ばれています。古いものと新しいLSPトンネルは、彼らが共通しているネットワークセグメント上のリソースのために互いに競合する可能性があるため、問題が発生する可能性があります。リソースの可用性に応じて、この競争が確立されてから新しいLSPトンネルを防止するためのアドミッションコントロールを引き起こす可能性があります。 LSPトンネルを確立するために、RSVPを使用することの利点は、それは非常にエレガントに、この問題を解決することをです。
To support make-before-break in a smooth fashion, it is necessary that on links that are common to the old and new LSPs, resources used by the old LSP tunnel should not be released before traffic is transitioned to the new LSP tunnel, and reservations should not be counted twice because this might cause Admission Control to reject the new LSP tunnel.
メイク前にブレークスムーズにサポートするために、トラフィックが新しいLSPトンネルに移行される前に、新旧のLSPに共通しているリンク上で、古いLSPトンネルが使用するリソースを解放してはならないことが必要である、とこれは、アドミッション制御は新しいLSPトンネルを拒否することがありますので、予約は二度カウントすべきではありません。
A similar situation can arise when one wants to increase the bandwidth of a TE tunnel. The new reservation will be for the full amount needed, but the actual allocation needed is only the delta between the new and old bandwidth. If policy is being applied to PATH messages by intermediate nodes, then a PATH message requesting too much bandwidth will be rejected. In this situation simply increasing the bandwidth request without changing the SENDER_TEMPLATE, could result in a tunnel being torn down, depending upon local policy.
1は、TEトンネルの帯域幅を増加させたい場合にも同様の状況が発生する可能性があります。新しい予約が必要な全額のためになりますが、必要に応じて実際の配分は、新旧の帯域幅の間の唯一のデルタです。ポリシーは、中間ノードでのPATHメッセージに適用されている場合は、あまりにも多くの帯域幅を要求するPATHメッセージは拒否されます。単にSENDER_TEMPLATEを変更せずに帯域幅要求を増大させるこのような状況では、ローカルポリシーに応じて、取り壊されているトンネルが生じる可能性があります。
The combination of the LSP_TUNNEL SESSION object and the SE reservation style naturally accommodates smooth transitions in bandwidth and routing. The idea is that the old and new LSP tunnels share resources along links which they have in common. The LSP_TUNNEL SESSION object is used to narrow the scope of the RSVP session to the particular TE tunnel in question. To uniquely identify a TE tunnel, we use the combination of the destination IP address (an address of the node which is the egress of the tunnel), a Tunnel ID, and the tunnel ingress node's IP address, which is placed in the Extended Tunnel ID field.
LSP_TUNNELセッションオブジェクトとSEの予約スタイルの組み合わせは、当然、帯域幅およびルーティングにおけるスムーズな移行に対応しています。アイデアは、古いものと新しいLSPは、彼らが共通しているリンクに沿って共有リソースをトンネルということです。 LSP_TUNNELセッションオブジェクトは、問題の特定のTEトンネルにRSVPセッションの範囲を狭めるために使用されます。一意TEトンネルを識別するために、我々は、宛先IPアドレス（トンネルの出口であるノードのアドレス）の組合せ、トンネルID、および拡張トンネル内に配置されるトンネル入口ノードのIPアドレスを使用しますIDフィールド。
During the reroute or bandwidth-increase operation, the tunnel ingress needs to appear as two different senders to the RSVP session. This is achieved by the inclusion of the "LSP ID", which is carried in the SENDER_TEMPLATE and FILTER_SPEC objects. Since the semantics of these objects are changed, a new C-Types are assigned.
リルートまたは帯域幅の増加動作中に、トンネル入口は、RSVPセッションへの2つの異なる送信者として表示する必要があります。これはSENDER_TEMPLATEとFILTER_SPECオブジェクトで運ばれる「LSP ID」を含めることによって達成されます。これらのオブジェクトのセマンティクスが変更されているので、新しいC-タイプが割り当てられます。
To effect a reroute, the ingress node picks a new LSP ID and forms a new SENDER_TEMPLATE. The ingress node then creates a new ERO to define the new path. Thereafter the node sends a new Path Message using the original SESSION object and the new SENDER_TEMPLATE and ERO. It continues to use the old LSP and refresh the old Path message. On links that are not held in common, the new Path message is treated as a conventional new LSP tunnel setup. On links held in common, the shared SESSION object and SE style allow the LSP to be established sharing resources with the old LSP. Once the ingress node receives a Resv message for the new LSP, it can transition traffic to it and tear down the old LSP.
リルートを達成するために、入口ノードは、新しいLSP IDを選ぶと、新しいSENDER_TEMPLATEを形成します。入口ノードは、新しいパスを定義するための新しいEROを作成します。その後、ノードは、元のセッションオブジェクトと新しいSENDER_TEMPLATEとEROを使用して、新しいパスメッセージを送信します。これは、古いLSPを使用して、古いPathメッセージを更新し続けています。一般的に保持されていないリンク上で、新たなPathメッセージは、従来の新しいLSPトンネル設定として扱われます。共通で開催されたリンクでは、共有セッションオブジェクトとSEスタイルは、LSPが古いLSPで共有リソースを確立することを可能にします。入口ノードは、新しいLSPのためのResvメッセージを受信すると、それへのトラフィックを移行し、古いLSPを取り壊すことができます。
To effect a bandwidth-increase, a new Path Message with a new LSP_ID can be used to attempt a larger bandwidth reservation while the current LSP_ID continues to be refreshed to ensure that the reservation is not lost if the larger reservation fails.
帯域幅の増加をもたらすために、新しいLSP_IDで新しいパスメッセージは、現在のLSP_IDが大きく、予約が失敗した場合、予約が失われないことを確実にするためにリフレッシュされ続けながら、より大きな帯域幅予約を試みるために使用することができます。
Standard RSVP [1] and Int-Serv [11] provide the RSVP sender with the minimum MTU available between the sender and the receiver. This path MTU identification capability is also provided for LSPs established via RSVP.
標準RSVP [1]とのInt-SERV [11]送信側と受信側の間で利用可能な最小のMTUでRSVP送信機を提供します。この経路MTU識別能力はまた、RSVPを介して確立されたLSPのために提供されます。
Path MTU information is carried, depending on which is present, in the Integrated Services or Null Service objects. When using Integrated Services objects, path MTU is provided based on the procedures defined in [11]. Path MTU identification when using Null Service objects is defined in [16].
パスMTU情報は、どのサービス統合型またはNullサービスオブジェクトに、存在しているに応じて、実施されます。統合サービスオブジェクトを使用する場合、パスMTUは[11]で定義された手順に基づいて提供されます。ヌル・サービスを使用してパスMTU識別が[16]で定義されるオブジェクト。
With standard RSVP, the path MTU information is used by the sender to check which IP packets exceed the path MTU. For packets that exceed the path MTU, the sender either fragments the packets or, when the IP datagram has the "Don't Fragment" bit set, issues an ICMP destination unreachable message. This path MTU related handling is also required for LSPs established via RSVP.
標準のRSVPでは、パスMTU情報は、パケットがパスMTUを超えたIPチェックするために、送信者によって使用されます。パスMTUを超えるパケットの場合、送信者は、パケットを断片化のいずれか、または、IPデータグラムは、ビットセットを「フラグメント不可」した場合に、ICMP宛先到達不能メッセージを発行します。このパスMTU関連の取り扱いもRSVPを介して確立するLSPのために必要とされます。
The following algorithm applies to all unlabeled IP datagrams and to any labeled packets which the node knows to be IP datagrams, to which labels need to be added before forwarding. For labeled packets the bottom of stack is found, the IP header examined.
次のアルゴリズムは、すべての非標識IPデータグラムにし、ラベルは、転送の前に追加する必要があるために、ノードがIPデータグラムであることを知っている任意のラベル付きパケットに適用されます。スタックの底部が検出された標識されたパケットは、IPヘッダを調べ。
Using the terminology defined in [5], an LSR MUST execute the following algorithm:
で定義された用語を使用すると、[5]、LSRは、以下のアルゴリズムを実行する必要があります。
1. Let N be the number of bytes in the label stack (i.e, 4 times the number of label stack entries) including labels to be added by this node.
1. Nこのノードが追加されるラベルを含むラベルスタック（すなわち、ラベルスタックエントリの4倍の数）のバイト数とします。
2. Let M be the smaller of the "Maximum Initially Labeled IP Datagram Size" or of (Path MTU - N).
2. Mが「最大当初標識IPデータグラムサイズ」または（ - NパスMTU）のうち小さい方とします。
When the size of an IPv4 datagram (without labels) exceeds the value of M,
（ラベルなし）のIPv4データグラムのサイズは、Mの値を超えた場合、
If the DF bit is not set in the IPv4 header, then
DFビットはIPv4ヘッダに設定されていない場合、次いで
(a) the datagram MUST be broken into fragments, each of whose size is no greater than M, and
（a）は、データグラムが断片に分割されなければならない、そのサイズの各々はM以下であり、かつ
(b) each fragment MUST be labeled and then forwarded.
（B）各断片を標識し、その後転送されなければなりません。
If the DF bit is set in the IPv4 header, then
DFビットはIPv4ヘッダに設定されている場合、
(a) the datagram MUST NOT be forwarded
（a）はデータグラムを転送してはなりません
(b) Create an ICMP Destination Unreachable Message:
（b）はICMP宛先到達不能メッセージを作成します。
i. set its Code field [12] to "Fragmentation Required and
DF Set",
ii. set its Next-Hop MTU field [13] to M
(c) If possible, transmit the ICMP Destination Unreachable Message to the source of the of the discarded datagram.
（C）可能な場合、廃棄されたデータグラムのソースにICMP宛先到達不能メッセージを送信します。
When the size of an IPv6 datagram (without labels) exceeds the value of M,
（ラベルなし）のIPv6データグラムのサイズは、Mの値を超えた場合、
(a) the datagram MUST NOT be forwarded
（a）はデータグラムを転送してはなりません
(b) Create an ICMP Packet too Big Message with the Next-Hop link MTU field [14] set to M
（B）次ホップリンクMTUフィールドでICMPパケットが大きすぎるメッセージを作成[14] Mに設定
(c) If possible, transmit the ICMP Packet too Big Message to the source of the of the discarded datagram.
可能な場合（C）、廃棄データグラムのソースにICMPパケットが大きすぎるメッセージを送信します。
Five new objects are defined in this section:
5つの新しいオブジェクトは、このセクションで定義されています。
Object name Applicable RSVP messages
--------------- ------------------------
LABEL_REQUEST Path
LABEL Resv
EXPLICIT_ROUTE Path
RECORD_ROUTE Path, Resv
SESSION_ATTRIBUTE Path
New C-Types are also assigned for the SESSION, SENDER_TEMPLATE, and FILTER_SPEC, objects.
新しいC-タイプもSESSION、SENDER_TEMPLATE、およびFILTER_SPEC、オブジェクトに割り当てられています。
Detailed descriptions of the new objects are given in later sections. All new objects are OPTIONAL with respect to RSVP. An implementation can choose to support a subset of objects. However, the LABEL_REQUEST and LABEL objects are mandatory with respect to this specification.
新しいオブジェクトの詳細な説明は後のセクションに記載されています。すべての新しいオブジェクトは、RSVPに関しては省略可能です。実装は、オブジェクトのサブセットをサポートすることを選択することができます。しかし、LABEL_REQUESTとLABELオブジェクトは、この仕様に関しては必須です。
The LABEL and RECORD_ROUTE objects, are sender specific. In Resv messages they MUST appear after the associated FILTER_SPEC and prior to any subsequent FILTER_SPEC.
LABELとRECORD_ROUTEオブジェクトは、送信者固有のものです。 RESVメッセージでは、彼らは、関連するFILTER_SPEC後に現れなければならないと、その後のFILTER_SPEC前に。
The relative placement of EXPLICIT_ROUTE, LABEL_REQUEST, and SESSION_ATTRIBUTE objects is simply a recommendation. The ordering of these objects is not important, so an implementation MUST be prepared to accept objects in any order.
EXPLICIT_ROUTE、LABEL_REQUEST、およびSESSION_ATTRIBUTEオブジェクトの相対的な配置は、単純にオススメです。これらのオブジェクトの順序は重要ではありませんので、実装は任意の順序でオブジェクトを受け入れるように準備しなければなりません。
The format of the Path message is as follows:
次のようにPathメッセージの形式は次のとおりです。
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST>
[ <SESSION_ATTRIBUTE> ]
[ <POLICY_DATA> ... ]
<sender descriptor>
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC> ]
[ <RECORD_ROUTE> ]
The format of the Resv message is as follows:
次のようにResvメッセージの形式は次のとおりです。
<Resv Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <RESV_CONFIRM> ] [ <SCOPE> ]
[ <POLICY_DATA> ... ]
<STYLE> <flow descriptor list>
<flow descriptor list> ::= <FF flow descriptor list>
| <SE flow descriptor>
<FF flow descriptor list> ::= <FLOWSPEC> <FILTER_SPEC>
<LABEL> [ <RECORD_ROUTE> ]
| <FF flow descriptor list>
<FF flow descriptor>
<FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> <LABEL>
[ <RECORD_ROUTE> ]
<SE flow descriptor> ::= <FLOWSPEC> <SE filter spec list>
<SE filter spec list> ::= <SE filter spec>
| <SE filter spec list> <SE filter spec>
<SE filter spec> ::= <FILTER_SPEC> <LABEL> [ <RECORD_ROUTE> ]
Note: LABEL and RECORD_ROUTE (if present), are bound to the preceding FILTER_SPEC. No more than one LABEL and/or RECORD_ROUTE may follow each FILTER_SPEC.
注：LABELとRECORD_ROUTE（存在する場合）、先行FILTER_SPECに結合されています。いいえ複数のラベルおよび/またはRECORD_ROUTEは、各FILTER_SPECに従っていないことがあります。
Labels MAY be carried in Resv messages. For the FF and SE styles, a label is associated with each sender. The label for a sender MUST immediately follow the FILTER_SPEC for that sender in the Resv message.
ラベルはRESVメッセージで行うことができます。 FFとSEスタイルのために、ラベルは各送信者に関連付けられています。送信者のためのラベルは、すぐにResvメッセージにその送信者のためのFILTER_SPECに従わなければなりません。
The LABEL object has the following format:
LABELオブジェクトの形式は次のとおりです。
LABEL class = 16, C_Type = 1
LABELクラス= 16、C_Type = 1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (top label) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The contents of a LABEL is a single label, encoded in 4 octets. Each generic MPLS label is an unsigned integer in the range 0 through 1048575. Generic MPLS labels and FR labels are encoded right aligned in 4 octets. ATM labels are encoded with the VPI right justified in bits 0-15 and the VCI right justified in bits 16-31.
LABELの内容は4つのオクテットで符号化された、単一のラベルです。各汎用MPLSラベルは右4つのオクテットに整列符号化される1048575汎用MPLSラベルとFRラベルを介して範囲0の符号なし整数です。 ATMラベルはビット16-31における右寄せのビット0-15及びVCIに正当化VPI権で符号化されます。
In MPLS a node may support multiple label spaces, perhaps associating a unique space with each incoming interface. For the purposes of the following discussion, the term "same label" means the identical label value drawn from the identical label space. Further, the following applies only to unicast sessions.
MPLSにおいて、ノードは、おそらく各入力インタフェースを備えたユニークな空間を関連付ける、複数のラベルスペースをサポートしてもよいです。以下の議論の目的のために、用語「同じラベル」は、同一ラベルスペースから引き出され、同一のラベル値を意味しています。さらに、次のようにユニキャストセッションにのみ適用されます。
Labels received in Resv messages on different interfaces are always considered to be different even if the label value is the same.
異なるインターフェイス上のResvメッセージで受信したラベルは、常にラベル値が同じであっても異なると考えられています。
The downstream node selects a label to represent the flow. If a label range has been specified in the label request, the label MUST be drawn from that range. If no label is available the node sends a PathErr message with an error code of "routing problem" and an error value of "label allocation failure".
下流ノードは、流れを表すラベルを選択します。ラベル範囲は、ラベル要求に指定されている場合、ラベルはその範囲から引き出さなければなりません。ラベルが利用できない場合、ノードは、「ルーティングの問題」のエラー・コードと「ラベル割り当て失敗」のエラー値とのPathErrメッセージを送信します。
If a node receives a Resv message that has assigned the same label value to multiple senders, then that node MAY also assign a single value to those same senders or to any subset of those senders. Note that if a node intends to police individual senders to a session, it MUST assign unique labels to those senders.
ノードが複数の送信者に同一のラベル値を割り当てたResvメッセージを受信した場合、そのノードは、同じ送信者に送信者またはそれらの任意のサブセットに対して単一の値を割り当てることができます。ノードがセッションに個々の送信者を取り締まるしようとする場合、それはそれらの送信者にユニークなラベルを割り当てなければならないことに注意してください。
In the case of ATM, one further condition applies. Some ATM nodes are not capable of merging streams. These nodes MAY indicate this by setting a bit in the label request to zero. The M-bit in the LABEL_REQUEST object of C-Type 2, label request with ATM label range, serves this purpose. The M-bit SHOULD be set by nodes which are merge capable. If for any senders the M-bit is not set, the downstream node MUST assign unique labels to those senders.
ATMの場合には、1つの更なる条件が適用されます。一部のATMノードは、ストリームをマージすることができません。これらのノードはゼロにラベル要求にビットを設定することで、これを示すかもしれ。 C-2型、ATMラベル範囲とラベル要求のLABEL_REQUEST目的でMビットは、この目的を果たします。 Mビットは、可能なマージされたノードによって設定されるべきです。任意の送信者のためにMビットが設定されていない場合、下流ノードは、それらの送信者に固有のラベルを割り当てる必要があります。
Once a label is allocated, the node formats a new LABEL object. The node then sends the new LABEL object as part of the Resv message to the previous hop. The node SHOULD be prepared to forward packets carrying the assigned label prior to sending the Resv message. The LABEL object SHOULD be kept in the Reservation State Block. It is then used in the next Resv refresh event for formatting the Resv message.
ラベルが割り当てられると、ノードは、新しいラベルオブジェクトをフォーマットします。ノードは、前のホップにResvメッセージの一部として、新しいラベルオブジェクトを送信します。ノードは、前Resvメッセージを送信に割り当てられたラベルを搬送するパケットを転送するために準備されるべきです。 LABELオブジェクトは、予約状態のブロックに保管してください。次に、それをResvメッセージをフォーマットするために、次のResvリフレッシュイベントで使用されています。
A node is expected to send a Resv message before its refresh timers expire if the contents of the LABEL object change.
ノードは、LABELオブジェクトの変更の内容ならばそのリフレッシュタイマーが期限切れになる前に、Resvメッセージを送信することが期待されます。
A node uses the label carried in the LABEL object as the outgoing label associated with the sender. The router allocates a new label and binds it to the incoming interface of this session/sender. This is the same interface that the router uses to forward Resv messages to the previous hops.
ノードは、送信者に関連付けられている発信ラベルとしてラベルオブジェクトで運ばれたラベルを使用します。ルータは、新しいラベルを割り当て、このセッション/送信者の着信インターフェイスにバインドします。これは、ルータが前のホップにRESVメッセージを転送するために使用するのと同じインタフェースです。
Several circumstance can lead to an unacceptable label.
いくつかの状況は容認できないラベルにつながることができます。
1. the node is a merge incapable ATM switch but the downstream node has assigned the same label to two senders
1.ノードはマージできないATMスイッチであるが、下流ノードは、二つの送信者に同じラベルを割り当てました
2. The implicit null label was assigned, but the node is not capable of doing a penultimate pop for the associated L3PID
2.暗黙的ヌルラベルが割り当てられていたが、ノードは、関連するL3PIDのために最後から二番目のポップを行うことが可能ではありません
In any of these events the node send a ResvErr message with an error code of "routing problem" and an error value of "unacceptable label value".
これらのイベントのいずれかのノードは、「ルーティングの問題」および「許容できないラベル値」のエラー値のエラーコードでResvErrメッセージを送信します。
Under normal circumstances, a node should never receive a LABEL object in a Resv message unless it had included a LABEL_REQUEST object in the corresponding Path message. However, an RSVP router that does not recognize the LABEL object sends a ResvErr with the error code "Unknown object class" toward the receiver. This causes the reservation to fail.
それは、対応するPathメッセージでLABEL_REQUESTオブジェクトが含まれていない限り、通常の状況下では、ノードは、ResvメッセージにLABELオブジェクトを受け取ることはありません。しかし、LABELオブジェクトを認識しないRSVPルータは、受信機に向けて、エラーコード「不明なオブジェクトクラス」とResvErrを送信します。これは予約が失敗します。
The Label Request Class is 19. Currently there are three possible C_Types. Type 1 is a Label Request without label range. Type 2 is a label request with an ATM label range. Type 3 is a label request with a Frame Relay label range. The LABEL_REQUEST object formats are shown below.
ラベル要求クラスは、現在、三つの可能なC_Typesがある19です。タイプ1は、ラベル範囲なしのラベル要求です。タイプ2は、ATMのラベル範囲とラベル要求です。タイプ3は、フレームリレーラベル範囲とラベル要求です。 LABEL_REQUESTオブジェクトフォーマットを以下に示します。
Class = 19, C_Type = 1
クラス= 19、C_Type = 1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | L3PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
予約済み
This field is reserved. It MUST be set to zero on transmission and MUST be ignored on receipt.
このフィールドは予約されています。これは、送信時にゼロに設定しなければならなくて、領収書の上で無視しなければなりません。
L3PID
オベイド
an identifier of the layer 3 protocol using this path. Standard Ethertype values are used.
このパスを使用して、レイヤ3プロトコルの識別子。標準のEthertype値が使用されています。
Class = 19, C_Type = 2
クラス= 19、C_Type = 2
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | L3PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M| Res | Minimum VPI | Minimum VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Res | Maximum VPI | Maximum VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved (Res)
予約（RES）
This field is reserved. It MUST be set to zero on transmission and MUST be ignored on receipt.
このフィールドは予約されています。これは、送信時にゼロに設定しなければならなくて、領収書の上で無視しなければなりません。
L3PID
オベイド
an identifier of the layer 3 protocol using this path. Standard Ethertype values are used.
このパスを使用して、レイヤ3プロトコルの識別子。標準のEthertype値が使用されています。
M
M
Setting this bit to one indicates that the node is capable of merging in the data plane
このビットを1に設定すると、ノードは、データ・プレーンにマージすることが可能であることを示しています
Minimum VPI (12 bits)
最小VPI（12ビット）
This 12 bit field specifies the lower bound of a block of Virtual Path Identifiers that is supported on the originating switch. If the VPI is less than 12-bits it MUST be right justified in this field and preceding bits MUST be set to zero.
この12ビットのフィールドは、発信スイッチでサポートされている仮想パス識別子のブロックの下限を指定します。 VPI未満、12ビットである場合、このフィールドに右詰めなければならず、先行ビットはゼロに設定しなければなりません。
Minimum VCI (16 bits)
最小VCI（16ビット）
This 16 bit field specifies the lower bound of a block of Virtual Connection Identifiers that is supported on the originating switch. If the VCI is less than 16-bits it MUST be right justified in this field and preceding bits MUST be set to zero.
この16ビットのフィールドは、発信スイッチでサポートされている仮想接続識別子のブロックの下限を指定します。 VCI未満、16ビットである場合、このフィールドに右詰めなければならず、先行ビットはゼロに設定しなければなりません。
Maximum VPI (12 bits)
最大VPI（12ビット）
This 12 bit field specifies the upper bound of a block of Virtual Path Identifiers that is supported on the originating switch. If the VPI is less than 12-bits it MUST be right justified in this field and preceding bits MUST be set to zero.
この12ビットのフィールドは、発信スイッチでサポートされている仮想パス識別子のブロックの上限を指定します。 VPI未満、12ビットである場合、このフィールドに右詰めなければならず、先行ビットはゼロに設定しなければなりません。
Maximum VCI (16 bits)
最大VCI（16ビット）
This 16 bit field specifies the upper bound of a block of Virtual Connection Identifiers that is supported on the originating switch. If the VCI is less than 16-bits it MUST be right justified in this field and preceding bits MUST be set to zero.
この16ビットのフィールドは、発信スイッチでサポートされている仮想接続識別子のブロックの上限を指定します。 VCI未満、16ビットである場合、このフィールドに右詰めなければならず、先行ビットはゼロに設定しなければなりません。
Class = 19, C_Type = 3
クラス= 19、C_Type = 3
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | L3PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |DLI| Minimum DLCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Maximum DLCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
予約済み
This field is reserved. It MUST be set to zero on transmission and ignored on receipt.
このフィールドは予約されています。これは、送信時にゼロに設定して、領収書の上で無視しなければなりません。
L3PID
オベイド
an identifier of the layer 3 protocol using this path. Standard Ethertype values are used.
このパスを使用して、レイヤ3プロトコルの識別子。標準のEthertype値が使用されています。
DLI
DLI
DLCI Length Indicator. The number of bits in the DLCI. The following values are supported:
DLCIの長さインジケータ。 DLCIのビット数。次の値がサポートされています。
Len DLCI bits
レンDLCIビット
0 10 2 23
０ １０ ２ ２３
Minimum DLCI
最小DLCI
This 23-bit field specifies the lower bound of a block of Data Link Connection Identifiers (DLCIs) that is supported on the originating switch. The DLCI MUST be right justified in this field and unused bits MUST be set to 0.
この23ビットのフィールドは、発信スイッチでサポートされているデータリンク接続識別子（DLCI）のブロックの下限を指定します。 DLCIは、この分野で右詰めなければならず、未使用ビットが0に設定しなければなりません。
Maximum DLCI
最大DLCI
This 23-bit field specifies the upper bound of a block of Data Link Connection Identifiers (DLCIs) that is supported on the originating switch. The DLCI MUST be right justified in this field and unused bits MUST be set to 0.
この23ビットのフィールドは、発信スイッチでサポートされているデータリンク接続識別子（DLCI）のブロックの上限を指定します。 DLCIは、この分野で右詰めなければならず、未使用ビットが0に設定しなければなりません。
To establish an LSP tunnel the sender creates a Path message with a LABEL_REQUEST object. The LABEL_REQUEST object indicates that a label binding for this path is requested and provides an indication of the network layer protocol that is to be carried over this path. This permits non-IP network layer protocols to be sent down an LSP. This information can also be useful in actual label allocation, because some reserved labels are protocol specific, see [5].
LSPトンネルを確立するために、送信者はLABEL_REQUESTオブジェクトとPathメッセージを作成します。 LABEL_REQUESTオブジェクトは、このパスに対する結合ラベルが要求されていることを示し、このパスを介して搬送されるネットワーク層プロトコルの指標を提供します。これは、非IPネットワーク層プロトコルは、LSPを下されることを可能にします。この情報はまた、いくつかの予約ラベルはプロトコル固有であるため、参照、実際のラベル割り当てに有用であることができる[5]。
The LABEL_REQUEST SHOULD be stored in the Path State Block, so that Path refresh messages will also contain the LABEL_REQUEST object. When the Path message reaches the receiver, the presence of the LABEL_REQUEST object triggers the receiver to allocate a label and to place the label in the LABEL object for the corresponding Resv message. If a label range was specified, the label MUST be allocated from that range. A receiver that accepts a LABEL_REQUEST object MUST include a LABEL object in Resv messages pertaining to that Path message. If a LABEL_REQUEST object was not present in the Path message, a node MUST NOT include a LABEL object in a Resv message for that Path message's session and PHOP.
そのパスのリフレッシュメッセージもLABEL_REQUESTオブジェクトが含まれていますのでLABEL_REQUESTは、パス状態ブロックに格納する必要があります。 Pathメッセージが受信機に到達すると、LABEL_REQUEST物体の存在は、ラベルを割り当てることと、対応するResvメッセージのラベルオブジェクトにラベルを配置するために受信機をトリガします。ラベル範囲を指定した場合、ラベルはその範囲から割り当てなければなりません。 LABEL_REQUESTオブジェクトを受け取り、受信機は、Pathメッセージに関連するRESVメッセージのラベルオブジェクトを含まなければなりません。 LABEL_REQUESTオブジェクトは、Pathメッセージ中に存在していなかった場合、ノードはそのPathメッセージのセッションとPHOPためのResvメッセージにLABELオブジェクトを含めることはできません。
A node that sends a LABEL_REQUEST object MUST be ready to accept and correctly process a LABEL object in the corresponding Resv messages.
LABEL_REQUEST・オブジェクトを送信したノードは、受け入れ、正しく対応するRESVメッセージにLABELオブジェクトを処理する準備ができなければなりません。
A node that recognizes a LABEL_REQUEST object, but that is unable to support it (possibly because of a failure to allocate labels) SHOULD send a PathErr with the error code "Routing problem" and the error value "MPLS label allocation failure." This includes the case where a label range has been specified and a label cannot be allocated from that range.
（おそらくラベルを割り当てに失敗した）LABEL_REQUESTオブジェクトを認識し、それはそれをサポートすることができないノードは、エラーコード「ルーティング問題」と誤差値とのPathErrを送ります「MPLSラベル割り当てに失敗しました。」これは、ラベル範囲が指定されたラベルは、その範囲から割り当てることができない場合を含みます。
A node which receives and forwards a Path message each with a LABEL_REQUEST object, MUST copy the L3PID from the received LABEL_REQUEST object to the forwarded LABEL_REQUEST object.
LABEL_REQUESTオブジェクトにそれぞれを受信し、Pathメッセージを転送するノードは、転送LABEL_REQUESTオブジェクトに受信LABEL_REQUESTオブジェクトからL3PIDをコピーする必要があります。
If the receiver cannot support the protocol L3PID, it SHOULD send a PathErr with the error code "Routing problem" and the error value "Unsupported L3PID." This causes the RSVP session to fail.
受信機は、プロトコルL3PIDをサポートできない場合は、エラーコード「ルーティング問題」とエラー値とのPathErrを送るべきである「サポートされていないL3PID。」これが失敗するRSVPセッションが発生します。
An RSVP router that does not recognize the LABEL_REQUEST object sends a PathErr with the error code "Unknown object class" toward the sender. An RSVP router that recognizes the LABEL_REQUEST object but does not recognize the C_Type sends a PathErr with the error code "Unknown object C_Type" toward the sender. This causes the path setup to fail. The sender should notify management that a LSP cannot be established and possibly take action to continue the reservation without the LABEL_REQUEST.
LABEL_REQUESTオブジェクトを認識しないRSVPルータは、送信者に向けて、エラーコード「不明なオブジェクトクラス」とのPathErrを送ります。 LABEL_REQUESTオブジェクトを認識するがC_Typeを認識しないRSVPルータは、送信者に向けて、エラーコード「未知のオブジェクトC_Type」とのPathErrを送ります。これは、パス設定が失敗します。送信者はLABEL_REQUESTせずに予約を続けるために行動を取る可能性がLSPを確立することができないことを管理に通知しなければなりません。
RSVP is designed to cope gracefully with non-RSVP routers anywhere between senders and receivers. However, obviously, non-RSVP routers cannot convey labels via RSVP. This means that if a router has a neighbor that is known to not be RSVP capable, the router MUST NOT advertise the LABEL_REQUEST object when sending messages that pass through the non-RSVP routers. The router SHOULD send a PathErr back to the sender, with the error code "Routing problem" and the error value "MPLS being negotiated, but a non-RSVP capable router stands in the path." This same message SHOULD be sent, if a router receives a LABEL_REQUEST object in a message from a non-RSVP capable router. See [1] for a description of how a downstream router can determine the presence of non-RSVP routers.
RSVPは、どこにでも送信側と受信側との間の非RSVPルータと優雅に対処するように設計されています。しかし、明らかに、非RSVPルータは、RSVPを経由して、ラベルを伝えることはできません。これは、ルータがRSVP対応ではないと知られている隣人を持っている場合は非RSVPルータを通過するメッセージを送信するとき、ルータはLABEL_REQUESTオブジェクトを広告してはならないことを意味します。ルータは、エラーコード「ルーティング問題」とエラー値と、差出人に戻ったPathErrを送るべきである「MPLSが交渉されているが、非RSVP対応ルータは、パスに立っています。」ルータは、非RSVP対応ルータからのメッセージにLABEL_REQUESTオブジェクトを受信した場合、この同じメッセージが、送信されるべきです。下流のルータは、非RSVPルータの存在を決定する方法の説明については、[1]参照。
Explicit routes are specified via the EXPLICIT_ROUTE object (ERO). The Explicit Route Class is 20. Currently one C_Type is defined, Type 1 Explicit Route. The EXPLICIT_ROUTE object has the following format:
明示的なルートはEXPLICIT_ROUTEオブジェクト（ERO）を介して指定されています。明示的なルートクラスは、現在1 C_Typeが定義されている20、タイプ1の明示的なルートです。 EXPLICIT_ROUTEオブジェクトの形式は次のとおりです。
Class = 20, C_Type = 1
クラス= 20、C_Type = 1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Subobjects
サブオブジェクト
The contents of an EXPLICIT_ROUTE object are a series of variable-length data items called subobjects. The subobjects are defined in section 4.3.3 below.
EXPLICIT_ROUTEオブジェクトの内容は、サブオブジェクトと呼ばれる可変長のデータ項目のシリーズです。サブオブジェクトは、以下のセクション4.3.3で定義されています。
If a Path message contains multiple EXPLICIT_ROUTE objects, only the first object is meaningful. Subsequent EXPLICIT_ROUTE objects MAY be ignored and SHOULD NOT be propagated.
Pathメッセージは、複数のEXPLICIT_ROUTEオブジェクトが含まれている場合は、唯一の第一の目的は、有意義です。後続のEXPLICIT_ROUTEオブジェクトは無視してもよいし、伝播されるべきではありません。
The EXPLICIT_ROUTE object is intended to be used only for unicast situations. Applications of explicit routing to multicast are a topic for further research.
EXPLICIT_ROUTEオブジェクトのみユニキャスト状況のために使用されることが意図されます。マルチキャストへの明示的なルーティングのアプリケーションでは、さらなる研究のためのトピックです。
The EXPLICIT_ROUTE object is to be used only when all routers along the explicit route support RSVP and the EXPLICIT_ROUTE object. The EXPLICIT_ROUTE object is assigned a class value of the form 0bbbbbbb. RSVP routers that do not support the object will therefore respond with an "Unknown Object Class" error.
EXPLICIT_ROUTEオブジェクトが使用される場合にのみ、明示的経路支持RSVPとEXPLICIT_ROUTEオブジェクトに沿った全てのルータ。 EXPLICIT_ROUTEオブジェクトは、フォームの0bbbbbbbはクラス値が割り当てられます。オブジェクトをサポートしていないRSVPルータは、したがって、「不明なオブジェクトクラス」エラーで応答します。
An explicit route is a particular path in the network topology. Typically, the explicit route is determined by a node, with the intent of directing traffic along that path.
明示的なルートは、ネットワークトポロジ内の特定のパスです。典型的には、明示的な経路は、その経路に沿ってトラフィックを導くことを意図して、ノードによって決定されます。
An explicit route is described as a list of groups of nodes along the explicit route. In addition to the ability to identify specific nodes along the path, an explicit route can identify a group of nodes that must be traversed along the path. This capability allows the routing system a significant amount of local flexibility in fulfilling a request for an explicit route. This capability allows the generator of the explicit route to have imperfect information about the details of the path.
明示的なルートは、明示的な経路に沿ったノードのグループのリストとして記述されています。経路に沿って特定のノードを識別するための能力に加えて、明示的な経路は、経路に沿って横断しなければならないノードのグループを識別することができます。この機能は、明示的な経路に対する要求を満たすにルーティングシステムをローカル柔軟性のかなりの量を可能にします。この機能は、明示的なルートの発電機は、パスの詳細についての不完全な情報を持つことができます。
The explicit route is encoded as a series of subobjects contained in an EXPLICIT_ROUTE object. Each subobject identifies a group of nodes in the explicit route. An explicit route is thus a specification of groups of nodes to be traversed.
明示的なルートはEXPLICIT_ROUTEオブジェクトに含まれるサブオブジェクトの一連として符号化されます。各サブオブジェクトは、明示的経路内のノードのグループを識別する。明示的なルートは、このようにトラバースされるノードのグループの仕様です。
To formalize the discussion, we call each group of nodes an abstract node. Thus, we say that an explicit route is a specification of a set of abstract nodes to be traversed. If an abstract node consists of only one node, we refer to it as a simple abstract node.
議論を形式化するために、我々は抽象ノードのノードの各グループを呼び出します。したがって、我々は、明示的なルートが横断する抽象化ノードのセットの仕様であると言います。抽象化ノードは一つのノードのみで構成されている場合、我々は、単純な抽象化ノードとしてそれを参照してください。
As an example of the concept of abstract nodes, consider an explicit route that consists solely of Autonomous System number subobjects. Each subobject corresponds to an Autonomous System in the global topology. In this case, each Autonomous System is an abstract node, and the explicit route is a path that includes each of the specified Autonomous Systems. There may be multiple hops within each Autonomous System, but these are opaque to the source node for the explicit route.
抽象的なノードの概念の一例として、もっぱら自律システム番号サブオブジェクトで構成され、明示的なルートを検討してください。各サブオブジェクトは、グローバルトポロジ内の自律システムに対応しています。この場合には、各自律システムは抽象ノードであり、明示的なルートは、指定された自律システムのそれぞれを含むパスです。そこ各自律システム内の複数のホップであるが、これらは、明示的な経路の送信元ノードに不透明であることができます。
The contents of an EXPLICIT_ROUTE object are a series of variable-length data items called subobjects. Each subobject has the form:
EXPLICIT_ROUTEオブジェクトの内容は、サブオブジェクトと呼ばれる可変長のデータ項目のシリーズです。各サブオブジェクトの形式は次のとおりです。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+
|L| Type | Length | (Subobject contents) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+
L
ザ・
The L bit is an attribute of the subobject. The L bit is set if the subobject represents a loose hop in the explicit route. If the bit is not set, the subobject represents a strict hop in the explicit route.
Lビットは、サブオブジェクトの属性です。サブオブジェクトは、明示的なルートでルーズホップを表す場合、Lビットが設定されています。ビットが設定されていない場合、サブオブジェクトは、明示的経路に厳密ホップを表します。
Type
タイプ
The Type indicates the type of contents of the subobject. Currently defined values are:
タイプは、サブオブジェクトの内容の種類を示します。現在、定義された値は次のとおりです。
1 IPv4 prefix
2 IPv6 prefix
32 Autonomous system number
Length
長さ
The Length contains the total length of the subobject in bytes, including the L, Type and Length fields. The Length MUST be at least 4, and MUST be a multiple of 4.
長さL、タイプと長さフィールドを含むバイト単位のサブオブジェクトの全長を含んでいます。長さは少なくとも4でなければなりません、及び4の倍数でなければなりません。
The L bit in the subobject is a one-bit attribute. If the L bit is set, then the value of the attribute is 'loose.' Otherwise, the value of the attribute is 'strict.' For brevity, we say that if the value of the subobject attribute is 'loose' then it is a 'loose subobject.' Otherwise, it's a 'strict subobject.' Further, we say that the abstract node of a strict or loose subobject is a strict or a loose node, respectively. Loose and strict nodes are always interpreted relative to their prior abstract nodes.
サブオブジェクトのLビットは1ビットの属性です。 Lビットが設定されている場合、属性の値は「ゆるい」です。それ以外の場合は、属性の値は「厳しい」です。簡潔にするために、我々は、サブオブジェクトの属性の値が「緩い」の場合、それがあると言う「緩いサブオブジェクト」。そうでなければ、それは厳格なサブオブジェクト。 "ですさらに、我々は厳しいか緩いサブオブジェクトの抽象化ノードは、それぞれ、厳密か緩いノードであることを言います。ルースと厳格なノードは、常に彼らの前に抽象化ノードに関連して解釈されます。
The path between a strict node and its preceding node MUST include only network nodes from the strict node and its preceding abstract node.
厳密ノードとその前のノードの間の経路は、厳密なノードからのみネットワークノードとその前の抽象ノードを含まなければなりません。
The path between a loose node and its preceding node MAY include other network nodes that are not part of the strict node or its preceding abstract node.
ルーズノードとその前のノードの間の経路は、厳密なノードまたはその前の抽象ノードの一部ではない他のネットワークノードを含むかもしれません。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | IPv4 address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address (continued) | Prefix Length | Resvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L
ザ・
The L bit is an attribute of the subobject. The L bit is set if the subobject represents a loose hop in the explicit route. If the bit is not set, the subobject represents a strict hop in the explicit route.
Lビットは、サブオブジェクトの属性です。サブオブジェクトは、明示的なルートでルーズホップを表す場合、Lビットが設定されています。ビットが設定されていない場合、サブオブジェクトは、明示的経路に厳密ホップを表します。
Type
タイプ
0x01 IPv4 address
0x01のIPv4アドレス
Length
長さ
The Length contains the total length of the subobject in bytes, including the Type and Length fields. The Length is always 8.
長さは、タイプと長さフィールドを含むバイト単位のサブオブジェクトの全長を含んでいます。長さは常に8です。
IPv4 address
IPv4アドレス
An IPv4 address. This address is treated as a prefix based on the prefix length value below. Bits beyond the prefix are ignored on receipt and SHOULD be set to zero on transmission.
IPv4アドレス。このアドレスは以下プレフィックス長値に基づいて、接頭辞として扱われます。接頭辞を超えたビットは、領収書の上で無視され、送信時にゼロに設定する必要があります。
Prefix length
プレフィックス長
Length in bits of the IPv4 prefix
IPv4プレフィクスのビットの長さ
Padding
パディング
Zero on transmission. Ignored on receipt.
伝送上のゼロ。領収書の上で無視。
The contents of an IPv4 prefix subobject are a 4-octet IPv4 address, a 1-octet prefix length, and a 1-octet pad. The abstract node represented by this subobject is the set of nodes that have an IP address which lies within this prefix. Note that a prefix length of 32 indicates a single IPv4 node.
IPv4のプレフィックスのサブオブジェクトの内容が4オクテットのIPv4アドレス、1オクテットのプレフィックス長、および1オクテットのパッドです。このサブオブジェクトによって表される抽象ノードがこのプレフィックス内にあるIPアドレスを持つノードの集合です。 32のプレフィックス長は、単一のIPv4ノードを示すことに留意されたいです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | IPv6 address (16 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) | Prefix Length | Resvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L
ザ・
The L bit is an attribute of the subobject. The L bit is set if the subobject represents a loose hop in the explicit route. If the bit is not set, the subobject represents a strict hop in the explicit route.
Lビットは、サブオブジェクトの属性です。サブオブジェクトは、明示的なルートでルーズホップを表す場合、Lビットが設定されています。ビットが設定されていない場合、サブオブジェクトは、明示的経路に厳密ホップを表します。
Type
タイプ
0x02 IPv6 address
0x02のIPv6アドレス
Length
長さ
The Length contains the total length of the subobject in bytes, including the Type and Length fields. The Length is always 20.
長さは、タイプと長さフィールドを含むバイト単位のサブオブジェクトの全長を含んでいます。長さは常に20です。
IPv6 address
IPv6アドレス
An IPv6 address. This address is treated as a prefix based on the prefix length value below. Bits beyond the prefix are ignored on receipt and SHOULD be set to zero on transmission.
IPv6アドレス。このアドレスは以下プレフィックス長値に基づいて、接頭辞として扱われます。接頭辞を超えたビットは、領収書の上で無視され、送信時にゼロに設定する必要があります。
Prefix Length
プレフィックス長
Length in bits of the IPv6 prefix.
IPv6プレフィックスのビットの長さ。
Padding
パディング
Zero on transmission. Ignored on receipt.
伝送上のゼロ。領収書の上で無視。
The contents of an IPv6 prefix subobject are a 16-octet IPv6 address, a 1-octet prefix length, and a 1-octet pad. The abstract node represented by this subobject is the set of nodes that have an IP address which lies within this prefix. Note that a prefix length of 128 indicates a single IPv6 node.
IPv6プレフィックスのサブオブジェクトの内容は、16オクテットのIPv6アドレス、1オクテットのプレフィックス長、および1オクテットのパッドです。このサブオブジェクトによって表される抽象ノードがこのプレフィックス内にあるIPアドレスを持つノードの集合です。 128のプレフィックス長は、単一のIPv6ノードを示すことに留意されたいです。
The contents of an Autonomous System (AS) number subobject are a 2- octet AS number. The abstract node represented by this subobject is the set of nodes belonging to the autonomous system.
自律システム（AS）番号のサブオブジェクトの内容が数AS 2-オクテットです。このサブオブジェクトで表される抽象ノードは、自律システムに属するノードの集合です。
The length of the AS number subobject is 4 octets.
AS番号のサブオブジェクトの長さは4つのオクテットです。
A node receiving a Path message containing an EXPLICIT_ROUTE object must determine the next hop for this path. This is necessary because the next abstract node along the explicit route might be an IP subnet or an Autonomous System. Therefore, selection of this next hop may involve a decision from a set of feasible alternatives. The criteria used to make a selection from feasible alternatives is implementation dependent and can also be impacted by local policy, and is beyond the scope of this specification. However, it is assumed that each node will make a best effort attempt to determine a loop-free path. Note that paths so determined can be overridden by local policy.
EXPLICIT_ROUTEオブジェクトを含むPathメッセージを受信したノードは、この経路の次のホップを決定しなければなりません。明示的なルートに沿って次の抽象化ノードはIPサブネットまたは自律システムであるかもしれないので、これが必要です。したがって、この次のホップの選択が可能な選択肢のセットからの決定を含むことができます。実現可能な選択肢から選択を行うために使用される基準は実装依存であり、また、ローカルポリシーによって影響を受ける可能性があり、この仕様の範囲を超えています。しかし、各ノードがループフリーパスを決定するために最善の努力の試みを行うことを想定しています。そう決定パスはローカルポリシーによって上書きすることができることに留意されたいです。
To determine the next hop for the path, a node performs the following steps:
経路の次のホップを決定するために、ノードは以下のステップを実行します。
1) The node receiving the RSVP message MUST first evaluate the first subobject. If the node is not part of the abstract node described by the first subobject, it has received the message in error and SHOULD return a "Bad initial subobject" error. If there is no first subobject, the message is also in error and the system SHOULD return a "Bad EXPLICIT_ROUTE object" error.
1）RSVPメッセージを受信したノードは、まず、第1のサブオブジェクトを評価しなければなりません。ノードは、最初のサブオブジェクトによって記述される抽象ノードの一部ではない場合、それはエラーメッセージを受信したと「不良初期サブオブジェクト」エラーを返すべきです。何の最初のサブオブジェクトが存在しない場合、メッセージはエラーでもあり、システムは「悪いEXPLICIT_ROUTEオブジェクト」エラーを返すべきです。
2) If there is no second subobject, this indicates the end of the explicit route. The EXPLICIT_ROUTE object SHOULD be removed from the Path message. This node may or may not be the end of the path. Processing continues with section 4.3.4.2, where a new EXPLICIT_ROUTE object MAY be added to the Path message.
いかなる第二サブオブジェクトがない場合は2）、これは、明示的なルートの終わりを示します。 EXPLICIT_ROUTEオブジェクトはPathメッセージから除去されるべきです。このノードは、またはパスの終わりであってもなくてもよいです。処理は、新たなEXPLICIT_ROUTEオブジェクトは、Pathメッセージに追加されるかもしれないセクション4.3.4.2、と続きます。
3) Next, the node evaluates the second subobject. If the node is also a part of the abstract node described by the second subobject, then the node deletes the first subobject and continues processing with step 2, above. Note that this makes the second subobject into the first subobject of the next iteration and allows the node to identify the next abstract node on the path of the message after possible repeated application(s) of steps 2 and 3.
3）次に、ノードは、第二のサブオブジェクトを評価します。ノードは、第2のサブオブジェクトによって記述される抽象ノードの一部である場合、そのノードは、最初のサブオブジェクトを削除し、上記のステップ2で処理を継続します。これは、次の反復の最初のサブオブジェクトに第二のサブオブジェクトを作成し、ノードは、ステップ2および3の可能な繰り返し適用（複数可）の後に、メッセージの経路上の次の抽象ノードを識別することを可能にすることに留意されたいです。
4) Abstract Node Border Case: The node determines whether it is topologically adjacent to the abstract node described by the second subobject. If so, the node selects a particular next hop which is a member of the abstract node. The node then deletes the first subobject and continues processing with section 4.3.4.2.
4）抽象ノードボーダーケース：ノードは、第2サブオブジェクトによって記述される抽象ノードにトポロジ的に隣接しているか否かを判断します。そうである場合、ノードは、抽象ノードのメンバーである特定の次のホップを選択します。ノードは、第1のサブオブジェクトを削除し、セクション4.3.4.2で処理を継続します。
5) Interior of the Abstract Node Case: Otherwise, the node selects a next hop within the abstract node of the first subobject (which the node belongs to) that is along the path to the abstract node of the second subobject (which is the next abstract node). If no such path exists then there are two cases:
5）抽象ノードケースの内部は：そうでない場合、ノードは、次の第二サブオブジェクト（の抽象ノードへのパスに沿ったノードが属する最初のサブオブジェクト（）の抽象ノード内の次のホップを選択します抽象化ノード）。そのようなパスが存在しない場合、2つのケースがあります。
5a) If the second subobject is a strict subobject, there is an error and the node SHOULD return a "Bad strict node" error.
第二のサブオブジェクトは、厳密なサブオブジェクトである場合は図5（a））、そこにエラーがあるとノードが「不良厳密ノード」エラーを返すべきです。
5b) Otherwise, if the second subobject is a loose subobject, the node selects any next hop that is along the path to the next abstract node. If no path exists, there is an error, and the node SHOULD return a "Bad loose node" error.
第二のサブオブジェクトが緩んサブオブジェクトである場合は図5（b））そうでない場合、ノードは、次の抽象ノードへの経路に沿ったいずれかの次のホップを選択します。パスが存在しない場合は、そこに誤差があり、ノードは「悪い緩いノード」エラーを返すべきです。
6) Finally, the node replaces the first subobject with any subobject that denotes an abstract node containing the next hop. This is necessary so that when the explicit route is received by the next hop, it will be accepted.
6）最後に、ノードは、次ホップを含む抽象ノードを表す任意のサブオブジェクトとの最初のサブオブジェクトを置き換えます。明示的なルートが次のホップによって受信されると、それが受け入れられるようにするために必要です。
After selecting a next hop, the node MAY alter the explicit route in the following ways.
次のホップを選択した後、ノードは、次の方法で明示的経路を変更することができます。
If, as part of executing the algorithm in section 4.3.4.1, the
、セクション4.3.4.1にアルゴリズムを実行することの一部として、もし
EXPLICIT_ROUTE object is removed, the node MAY add a new EXPLICIT_ROUTE object.
EXPLICIT_ROUTEオブジェクトが削除され、ノードは新しいEXPLICIT_ROUTEオブジェクトを追加するかもしれません。
Otherwise, if the node is a member of the abstract node for the first subobject, a series of subobjects MAY be inserted before the first subobject or MAY replace the first subobject. Each subobject in this series MUST denote an abstract node that is a subset of the current abstract node.
ノードは、最初のサブオブジェクトの抽象ノードのメンバーである場合はそうでなければ、サブオブジェクトの一連の最初のサブオブジェクトの前に挿入され得るか、または最初のサブオブジェクトに取って代わることができます。このシリーズの各サブオブジェクトは、現在の抽象ノードのサブセットである抽象ノードを意味しなければなりません。
Alternately, if the first subobject is a loose subobject, an arbitrary series of subobjects MAY be inserted prior to the first subobject.
最初のサブオブジェクトが緩んサブオブジェクトである場合、交互に、サブオブジェクトの任意の一連の最初のサブオブジェクトの前に挿入されてもよいです。
While the EXPLICIT_ROUTE object is of finite length, the existence of loose nodes implies that it is possible to construct forwarding loops during transients in the underlying routing protocol. This can be detected by the originator of the explicit route through the use of another opaque route object called the RECORD_ROUTE object. The RECORD_ROUTE object is used to collect detailed path information and is useful for loop detection and for diagnostics.
EXPLICIT_ROUTEオブジェクトが有限長であるが、ルーズノードの存在は、基礎となるルーティングプロトコルにおける過渡時転送ループを構築することが可能であることを意味します。これはRECORD_ROUTEオブジェクトと呼ばれる別の不透明なルートオブジェクトの使用を介して明示的ルートの発信によって検出することができます。 RECORD_ROUTEオブジェクトは、詳細な経路情報を収集するために使用され、ループ検出および診断のために有用です。
It is anticipated that new subobjects may be defined over time. A node which encounters an unrecognized subobject during its normal ERO processing sends a PathErr with the error code "Routing Error" and error value of "Bad Explicit Route Object" toward the sender. The EXPLICIT_ROUTE object is included, truncated (on the left) to the offending subobject. The presence of an unrecognized subobject which is not encountered in a node's ERO processing SHOULD be ignored. It is passed forward along with the rest of the remaining ERO stack.
新たなサブオブジェクトが時間をかけて定義されてもよいことが予想されます。通常のERO処理中に認識されていないサブオブジェクトを検出したノードは、送信側に向かって、「悪い明示的経路オブジェクト」のエラーコード「ルーティングエラー」と誤差値とのPathErrを送信します。 EXPLICIT_ROUTEオブジェクトは、含まれる問題のあるサブオブジェクトに（左側に）切り捨てられます。ノードのERO処理で遭遇されていない未認識のサブオブジェクトの存在は無視されるべきです。これは、残りのEROスタックの残りの部分に沿って前方に渡されます。
An RSVP router that does not recognize the EXPLICIT_ROUTE object sends a PathErr with the error code "Unknown object class" toward the sender. This causes the path setup to fail. The sender should notify management that a LSP cannot be established and possibly take action to continue the reservation without the EXPLICIT_ROUTE or via a different explicit route.
EXPLICIT_ROUTEオブジェクトを認識しないRSVPルータは、送信者に向けて、エラーコード「不明なオブジェクトクラス」とのPathErrを送ります。これは、パス設定が失敗します。送信者は、LSPを確立することができないという管理を通知し、おそらくEXPLICIT_ROUTEなしまたは異なる明示的なルートを経由して予約を続けるために行動を取る必要があります。
Routes can be recorded via the RECORD_ROUTE object (RRO). Optionally, labels may also be recorded. The Record Route Class is 21. Currently one C_Type is defined, Type 1 Record Route. The RECORD_ROUTE object has the following format:
ルートはRECORD_ROUTEオブジェクト（RRO）を介して記録することができます。必要に応じて、ラベルも記録することができます。レコードのルートクラスは、1 C_Typeが定義されている現在、タイプ1のレコードルート21です。 RECORD_ROUTEオブジェクトの形式は次のとおりです。
Class = 21, C_Type = 1
クラス= 21、C_Type = 1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Subobjects
サブオブジェクト
The contents of a RECORD_ROUTE object are a series of variable-length data items called subobjects. The subobjects are defined in section 4.4.1 below.
RECORD_ROUTEオブジェクトの内容は、サブオブジェクトと呼ばれる可変長のデータ項目のシリーズです。サブオブジェクトは、以下のセクション4.4.1で定義されています。
The RRO can be present in both RSVP Path and Resv messages. If a Path message contains multiple RROs, only the first RRO is meaningful. Subsequent RROs SHOULD be ignored and SHOULD NOT be propagated. Similarly, if in a Resv message multiple RROs are encountered following a FILTER_SPEC before another FILTER_SPEC is encountered, only the first RRO is meaningful. Subsequent RROs SHOULD be ignored and SHOULD NOT be propagated.
RROは、RSVPパスとRESVメッセージの両方に存在することができます。 Pathメッセージは、複数のRROsが含まれている場合は、最初のRROは意味があります。後続のRROsは無視され、伝播されるべきではありません。別のFILTER_SPECに遭遇する前に、Resvメッセージに複数RROsをFILTER_SPEC下記発生した場合、同様に、最初のRROは意味があります。後続のRROsは無視され、伝播されるべきではありません。
The contents of a RECORD_ROUTE object are a series of variable-length data items called subobjects. Each subobject has its own Length field. The length contains the total length of the subobject in bytes, including the Type and Length fields. The length MUST always be a multiple of 4, and at least 4.
RECORD_ROUTEオブジェクトの内容は、サブオブジェクトと呼ばれる可変長のデータ項目のシリーズです。各サブオブジェクトには、独自の長さフィールドを持っています。長さは、タイプと長さフィールドを含むバイト単位のサブオブジェクトの全長を含んでいます。長さが常に4の倍数であり、少なくとも4なければなりません。
Subobjects are organized as a last-in-first-out stack. The first subobject relative to the beginning of RRO is considered the top. The last subobject is considered the bottom. When a new subobject is added, it is always added to the top.
サブオブジェクトは後入れ先出しスタックとして編成されています。 RROの先頭に最初のサブオブジェクトの相対的なトップと考えられています。最後のサブオブジェクトは、ボトムと考えられています。新しいサブオブジェクトが追加されると、それは常に一番上に追加されます。
An empty RRO with no subobjects is considered illegal.
なしサブオブジェクトと空のRROを違法と見なされます。
Three kinds of subobjects are currently defined.
サブオブジェクトの三種類は、現在定義されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | IPv4 address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address (continued) | Prefix Length | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
0x01 IPv4 address
0x01のIPv4アドレス
Length
長さ
The Length contains the total length of the subobject in bytes, including the Type and Length fields. The Length is always 8.
長さは、タイプと長さフィールドを含むバイト単位のサブオブジェクトの全長を含んでいます。長さは常に8です。
IPv4 address
IPv4アドレス
A 32-bit unicast, host address. Any network-reachable interface address is allowed here. Illegal addresses, such as certain loopback addresses, SHOULD NOT be used.
32ビットのユニキャスト、ホストアドレス。任意のネットワーク到達可能なインターフェイスアドレスはここで許可されています。そのような特定のループバックアドレスなどの不正アドレスには、使用するべきではありません。
Prefix length
プレフィックス長
32
３２
Flags
国旗
0x01 Local protection available
利用可能0x01のローカル保護
Indicates that the link downstream of this node is
protected via a local repair mechanism. This flag can
only be set if the Local protection flag was set in the
SESSION_ATTRIBUTE object of the corresponding Path
message.
0x02 Local protection in use
使用中の0x02のローカル保護
Indicates that a local repair mechanism is in use to
maintain this tunnel (usually in the face of an outage
of the link it was previously routed over).
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | IPv6 address (16 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) | Prefix Length | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
0x02 IPv6 address
0x02のIPv6アドレス
Length
長さ
The Length contains the total length of the subobject in bytes, including the Type and Length fields. The Length is always 20.
長さは、タイプと長さフィールドを含むバイト単位のサブオブジェクトの全長を含んでいます。長さは常に20です。
IPv6 address
IPv6アドレス
A 128-bit unicast host address.
128ビットのユニキャストホストアドレス。
Prefix length
プレフィックス長
128
１２８
Flags
国旗
0x01 Local protection available
利用可能0x01のローカル保護
Indicates that the link downstream of this node is
protected via a local repair mechanism. This flag can
only be set if the Local protection flag was set in the
SESSION_ATTRIBUTE object of the corresponding Path
message.
0x02 Local protection in use
使用中の0x02のローカル保護
Indicates that a local repair mechanism is in use to
maintain this tunnel (usually in the face of an outage
of the link it was previously routed over).
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Flags | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Contents of Label Object |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
0x03 Label
0x03のラベル
Length
長さ
The Length contains the total length of the subobject in bytes, including the Type and Length fields.
長さは、タイプと長さフィールドを含むバイト単位のサブオブジェクトの全長を含んでいます。
Flags
国旗
0x01 = Global label This flag indicates that the label will be understood if received on any interface.
0×01 =グローバルラベルは、このフラグは、任意のインターフェイス上で受信したラベルが理解されるであろうことを示しています。
C-Type
C型
The C-Type of the included Label Object. Copied from the Label Object.
付属ラベルオブジェクトのC型。ラベルオブジェクトからコピーされました。
Contents of Label Object
ラベルオブジェクトの内容
The contents of the Label Object. Copied from the Label Object
ラベルオブジェクトの内容。ラベルオブジェクトからコピー
Only the procedures for use in unicast sessions are defined here.
ユニキャストセッションで使用するための唯一の方法は、ここで定義されています。
There are three possible uses of RRO in RSVP. First, an RRO can function as a loop detection mechanism to discover L3 routing loops, or loops inherent in the explicit route. The exact procedure for doing so is described later in this document.
RSVPでのRROの三つの可能な用途があります。まず、RROは、L3ルーティングのループを検出するループ検出機構として機能する、または明示的な経路に固有のループができます。そうするための正確な手順は、このドキュメントで後述します。
Second, an RRO collects up-to-date detailed path information hop-by-hop about RSVP sessions, providing valuable information to the sender or receiver. Any path change (due to network topology changes) will be reported.
第二に、RROは、最新の詳細なパス情報は、ホップバイホップRSVPセッションについては、送信者または受信者に貴重な情報を提供する収集します。 （ネットワークトポロジの変化に起因する）任意のパスの変更が報告されます。
Third, RRO syntax is designed so that, with minor changes, the whole object can be used as input to the EXPLICIT_ROUTE object. This is useful if the sender receives RRO from the receiver in a Resv message, applies it to EXPLICIT_ROUTE object in the next Path message in order to "pin down session path".
軽微な変更で、オブジェクト全体がEXPLICIT_ROUTEオブジェクトへの入力として使用することができ、ように第三に、RRO構文が設計されています。送信者は、Resvメッセージ中で受信機からRROを受信する「セッション経路を突き止める」するために、次のPathメッセージ内のオブジェクトをEXPLICIT_ROUTEするためにそれを適用する場合に便利です。
Typically, a node initiates an RSVP session by adding the RRO to the Path message. The initial RRO contains only one subobject - the sender's IP addresses. If the node also desires label recording, it sets the Label_Recording flag in the SESSION_ATTRIBUTE object.
典型的には、ノードは、PathメッセージにRROを追加することによって、RSVPセッションを開始します。送信者のIPアドレス - 初期RROは、唯一のサブオブジェクトが含まれています。ノードはまた、ラベル記録を望む場合、それはSESSION_ATTRIBUTEオブジェクト内Label_Recordingフラグをセットします。
When a Path message containing an RRO is received by an intermediate router, the router stores a copy of it in the Path State Block. The RRO is then used in the next Path refresh event for formatting Path messages. When a new Path message is to be sent, the router adds a new subobject to the RRO and appends the resulting RRO to the Path message before transmission.
RROを含むPathメッセージは、中間ルータによって受信されると、ルータは、パス状態ブロック内のそれのコピーを格納します。 RROは、その後、Pathメッセージをフォーマットするために、次のパスのリフレッシュイベントで使用されています。新しいPathメッセージが送信されると、ルータはRROに新しいサブオブジェクトを追加し、送信前にPathメッセージに結果のRROを追加します。
The newly added subobject MUST be this router's IP address. The address to be added SHOULD be the interface address of the outgoing Path messages. If there are multiple addresses to choose from, the decision is a local matter. However, it is RECOMMENDED that the same address be chosen consistently.
新しく追加されたサブオブジェクトは、このルータのIPアドレスでなければなりません。追加するアドレスが送信するPathメッセージのインタフェースアドレスでなければなりません。選択する複数のアドレスがある場合は、決定はローカルの問題です。しかし、同じアドレスが一貫して選択することを推奨します。
When the Label_Recording flag is set in the SESSION_ATTRIBUTE object, nodes doing route recording SHOULD include a Label Record subobject. If the node is using a global label space, then it SHOULD set the Global Label flag.
Label_RecordingフラグがSESSION_ATTRIBUTEオブジェクトに設定されている場合、ルート記録を行うノードは、ラベルレコードサブオブジェクトが含まれるべきです。ノードがグローバルラベルスペースを使用している場合、それはグローバルラベルフラグを設定する必要があります。
The Label Record subobject is pushed onto the RECORD_ROUTE object prior to pushing on the node's IP address. A node MUST NOT push on a Label Record subobject without also pushing on an IPv4 or IPv6 subobject.
ラベルレコードサブオブジェクトは、前のノードのIPアドレスにプッシュするにRECORD_ROUTEオブジェクトにプッシュされます。ノードは、IPv4またはIPv6のサブオブジェクトに押さずにラベルレコードサブオブジェクトにプッシュしてはなりません。
Note that on receipt of the initial Path message, a node is unlikely to have a label to include. Once a label is obtained, the node SHOULD include the label in the RRO in the next Path refresh event.
初期のPathメッセージの受信時に、ノードには、ラベルを持っている可能性は低いことに注意してください。ラベルが得られると、ノードは次のパスのリフレッシュイベントでRROにラベルを含むべきです。
If the newly added subobject causes the RRO to be too big to fit in a Path (or Resv) message, the RRO object SHALL be dropped from the message and message processing continues as normal. A PathErr (or
新しく追加されたサブオブジェクトは、RRO（またはのResv）メッセージパスに収まるには大きすぎることが原因となる場合、RROオブジェクトがメッセージから削除されなければならず、メッセージ処理は通常通り継続します。たPathErr（または
ResvErr) message SHOULD be sent back to the sender (or receiver). An error code of "Notify" and an error value of "RRO too large for MTU" is used. If the receiver receives such a ResvErr, it SHOULD send a PathErr message with error code of "Notify" and an error value of "RRO notification".
ResvErr）メッセージは、送信（または受信）に返送されるべきです。 「通知」のエラーコードと「MTUに対して大きすぎるRRO」のエラー値が使用されます。受信機は、ResvErrを受信した場合、それは「通知」のエラーコードおよび「RRO通知」のエラー値とのPathErrメッセージを送信すべきです。
A sender receiving either of these error values SHOULD remove the RRO from the Path message.
これらのエラー値のいずれかを受けた送信者は、PathメッセージからRROを削除する必要があります。
Nodes SHOULD resend the above PathErr or ResvErr message each n seconds where n is the greater of 15 and the refresh interval for the associated Path or RESV message. The node MAY apply limits and/or back-off timers to limit the number of messages sent.
ノードは、上記のPathErr又はResvErrメッセージnが15より大きいと関連するパスまたはRESVメッセージのリフレッシュ間隔で各n秒を再送すべきです。ノードは、送信されたメッセージの数を制限する制限及び/又はバックオフタイマーを適用することができます。
An RSVP router can decide to send Path messages before its refresh time if the RRO in the next Path message is different from the previous one. This can happen if the contents of the RRO received from the previous hop router changes or if this RRO is newly added to (or deleted from) the Path message.
RSVPルータは、次のPathメッセージでのRROが前のものと異なる場合は、そのリフレッシュ時間前にPathメッセージを送信することを決定することができます。 RROの内容が前のホップルータの変更またはこのRROが新たに追加（またはから削除）Pathメッセージした場合、受信した場合に発生することができます。
When the destination node of an RSVP session receives a Path message with an RRO, this indicates that the sender node needs route recording. The destination node initiates the RRO process by adding an RRO to Resv messages. The processing mirrors that of the Path messages. The only difference is that the RRO in a Resv message records the path information in the reverse direction.
RSVPセッションの宛先ノードがRROとPathメッセージを受信すると、これは、送信側ノードは、ルート記録を必要とすることを示しています。宛先ノードは、メッセージをRESVするRROを追加することによって、RROプロセスを開始します。処理は、Pathメッセージのことを反映しています。唯一の違いは、Resvメッセージ中のRROは逆方向に経路情報を記録することです。
Note that each node along the path will now have the complete route from source to destination. The Path RRO will have the route from the source to this node; the Resv RRO will have the route from this node to the destination. This is useful for network management.
パスに沿った各ノードが現在送信元から宛先までの完全な経路を有することになることに留意されたいです。パスRROは、このノードへの送信元からのルートを持つことになります。 Resv RROは、目的地への、このノードからのルートを持つことになります。これは、ネットワーク管理に有用です。
A received Path message without an RRO indicates that the sender node no longer needs route recording. Subsequent Resv messages SHALL NOT contain an RRO.
RROずに受信したPathメッセージは、送信ノードがもはやルート記録を必要としないことを示します。後続のRESVメッセージは、RROを含んではなりません。
As part of processing an incoming RRO, an intermediate router looks into all subobjects contained within the RRO. If the router determines that it is already in the list, a forwarding loop exists.
着信RROを処理の一部として、中間ルータはRRO内に含まれる全てのサブオブジェクトに見えます。ルータは、それがリストに既にあると判断した場合、転送ループが存在します。
An RSVP session is loop-free if downstream nodes receive Path messages or upstream nodes receive Resv messages with no routing loops detected in the contained RRO.
下流ノードは、Pathメッセージを受信するか、上流のノードが含まれるRROで検出ないルーティングループとRESVメッセージを受信した場合RSVPセッションはループフリーです。
There are two broad classifications of forwarding loops. The first class is the transient loop, which occurs as a normal part of operations as L3 routing tries to converge on a consistent forwarding path for all destinations. The second class of forwarding loop is the permanent loop, which normally results from network mis-configuration.
転送ループの二つの広い分類があります。最初のクラスは、L3ルーティングが全ての目的地のための一貫性のある転送経路に収束しようとする操作の正常部分として生じる過渡的なループです。転送ループの第二のクラスは、通常、ネットワークの設定ミスに起因する永久ループです。
The action performed by a node on receipt of an RRO depends on the message type in which the RRO is received.
RROの受信時にノードによって実行されるアクションは、RROが受信されたメッセージタイプに依存します。
For Path messages containing a forwarding loop, the router builds and sends a "Routing problem" PathErr message, with the error value "loop detected," and drops the Path message. Until the loop is eliminated, this session is not suitable for forwarding data packets. How the loop eliminated is beyond the scope of this document.
転送ループを含むPathメッセージのために、ルータは、構築し、エラー値と、「ルーティング問題」のPathErrメッセージを送信する「検出ループ」とPathメッセージをドロップ。ループが解消されるまで、このセッションは、データパケットを転送するには適していません。どのように解消ループは、このドキュメントの範囲を超えています。
For Resv messages containing a forwarding loop, the router simply drops the message. Resv messages should not loop if Path messages do not loop.
転送ループを含むRESVメッセージの場合、ルータは単にメッセージをドロップします。 Pathメッセージがループしない場合はRESVメッセージは、ループいけません。
New subobjects may be defined for the RRO. When processing an RRO, unrecognized subobjects SHOULD be ignored and passed on. When processing an RRO for loop detection, a node SHOULD parse over any unrecognized objects. Loop detection works by detecting subobjects which were inserted by the node itself on an earlier pass of the object. This ensures that the subobjects necessary for loop detection are always understood.
新しいサブオブジェクトは、RROのために定義することができます。 RROを処理する場合、認識されていないサブオブジェクトは無視され、渡されるべきです。ループ検出用のRROを処理するとき、ノードは、任意の認識されていないオブジェクトをオーバー解析すべきです。ループ検出は、オブジェクトの以前のパス上のノード自身が挿入されたサブオブジェクトを検出することによって動作します。これは、ループ検出のために必要なサブオブジェクトが常に理解されることが保証されます。
The RRO object is to be used only when all routers along the path support RSVP and the RRO object. The RRO object is assigned a class value of the form 0bbbbbbb. RSVP routers that do not support the object will therefore respond with an "Unknown Object Class" error.
RROオブジェクトが使用される場合にのみ、パスサポートRSVPとRROオブジェクトに沿った全てのルータ。 RROオブジェクトは、フォームの0bbbbbbbはクラス値が割り当てられます。オブジェクトをサポートしていないRSVPルータは、したがって、「不明なオブジェクトクラス」エラーで応答します。
In the processing described above, certain errors must be reported as either a "Routing Problem" or "Notify". The value of the "Routing Problem" error code is 24; the value of the "Notify" error code is 25.
上述の処理では、特定のエラーが「ルーティング問題」または「通知」のいずれかとして報告しなければなりません。 「ルーティング問題」エラーコードの値は24です。 「通知」のエラーコードの値は25です。
The following defines error values for the Routing Problem Error Code:
以下は、ルーティング問題エラーコードのエラー値を定義します。
Value Error:
値のエラー：
1 Bad EXPLICIT_ROUTE object
1つの悪いEXPLICIT ROUTEオブジェクト
2 Bad strict node
2バート厳密ノード
3 Bad loose node
3悪い緩いノード
4 Bad initial subobject
4悪い最初のサブオブジェクト
5 No route available toward destination
先に向けて利用可能な5 Noルート
6 Unacceptable label value
6許容できないラベル値
7 RRO indicated routing loops
7 RROは、ルーティングループ示し
8 MPLS being negotiated, but a non-RSVP-capable router stands in the path
8つのMPLSは、ネゴシエートされたが、非RSVP対応ルータは、パスに立っ
9 MPLS label allocation failure
9 MPLSラベル割り当ての失敗
10 Unsupported L3PID
10サポートされていないL3PID
For the Notify Error Code, the 16 bits of the Error Value field are:
通知エラーコードの場合は、エラー値フィールドの16ビットは、次のとおりです。
ss00 cccc cccc cccc
SS00 CCCCのCCCCのCCCC
The high order bits are as defined under Error Code 1. (See [1]).
エラーコード1で定義した上位ビットは、（[1]参照）です。
When ss = 00, the following subcodes are defined:
SS = 00、次のサブコードが定義されている場合：
1 RRO too large for MTU
MTUのためには大きすぎる1 RRO
2 RRO notification
2 RRO通知
3 Tunnel locally repaired
3トンネルは、ローカル修理します
New C-Types are defined for the SESSION, SENDER_TEMPLATE and FILTER_SPEC objects.
新しいC-タイプはSESSION、SENDER_TEMPLATEとFILTER_SPECオブジェクトのために定義されています。
The LSP_TUNNEL objects have the following format:
LSP_TUNNELオブジェクトの形式は次のとおりです。
Class = SESSION, LSP_TUNNEL_IPv4 C-Type = 7
クラス= SESSION、LSP_TUNNEL_IPv4 Cタイプ= 7
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel end point address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 tunnel end point address
IPv4のトンネルエンドポイントアドレス
IPv4 address of the egress node for the tunnel.
トンネルの出口ノードのIPv4アドレス。
Tunnel ID
トンネルID
A 16-bit identifier used in the SESSION that remains constant over the life of the tunnel.
トンネルの寿命にわたって一定のままでセッションで使用される16ビットの識別子。
Extended Tunnel ID
拡張トンネルID
A 32-bit identifier used in the SESSION that remains constant over the life of the tunnel. Normally set to all zeros. Ingress nodes that wish to narrow the scope of a SESSION to the ingress-egress pair may place their IPv4 address here as a globally unique identifier.
トンネルの寿命にわたって一定のままでセッションで使用される32ビットの識別子。通常はすべてゼロに設定します。入・出力ペアにSESSIONの範囲を狭めることを望むのIngressノードは、グローバルに一意の識別子として、ここで自分のIPv4アドレスを入れることができます。
Class = SESSION, LSP_TUNNEL_IPv6 C_Type = 8
クラス= SESSION、LSP_TUNNEL_IPv6 C_Type = 8
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| IPv6 tunnel end point address |
+ +
| (16 bytes) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Extended Tunnel ID |
+ +
| (16 bytes) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 tunnel end point address
IPv6のトンネルエンドポイントアドレス
IPv6 address of the egress node for the tunnel.
トンネルの出口ノードのIPv6アドレス。
Tunnel ID
トンネルID
A 16-bit identifier used in the SESSION that remains constant over the life of the tunnel.
トンネルの寿命にわたって一定のままでセッションで使用される16ビットの識別子。
Extended Tunnel ID
拡張トンネルID
A 16-byte identifier used in the SESSION that remains constant over the life of the tunnel. Normally set to all zeros. Ingress nodes that wish to narrow the scope of a SESSION to the ingress-egress pair may place their IPv6 address here as a globally unique identifier.
トンネルの寿命にわたって一定のままでセッションで使用される16バイトの識別子。通常はすべてゼロに設定します。入・出力ペアにSESSIONの範囲を狭めることを望むのIngressノードは、グローバルに一意の識別子として、ここで自分のIPv6アドレスを入れることができます。
Class = SENDER_TEMPLATE, LSP_TUNNEL_IPv4 C-Type = 7
クラス= SENDER_TEMPLATE、LSP_TUNNEL_IPv4 Cタイプ= 7
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel sender address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 tunnel sender address
IPv4トンネルの送信元アドレス
IPv4 address for a sender node
送信ノードのIPv4アドレス
LSP ID
LSP ID
A 16-bit identifier used in the SENDER_TEMPLATE and the FILTER_SPEC that can be changed to allow a sender to share resources with itself.
送信者が自分自身でリソースを共有できるように変更することができるSENDER_TEMPLATEとFILTER_SPECで使用される16ビットの識別子。
Class = SENDER_TEMPLATE, LSP_TUNNEL_IPv6 C_Type = 8
クラス= SENDER_TEMPLATE、LSP_TUNNEL_IPv6 C_Type = 8
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| IPv6 tunnel sender address |
+ +
| (16 bytes) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 tunnel sender address
IPv6トンネルの送信元アドレス
IPv6 address for a sender node
送信ノードのIPv6アドレス
LSP ID
LSP ID
A 16-bit identifier used in the SENDER_TEMPLATE and the FILTER_SPEC that can be changed to allow a sender to share resources with itself.
送信者が自分自身でリソースを共有できるように変更することができるSENDER_TEMPLATEとFILTER_SPECで使用される16ビットの識別子。
Class = FILTER SPECIFICATION, LSP_TUNNEL_IPv4 C-Type = 7
クラス=フィルタ仕様、LSP_TUNNEL_IPv4 Cタイプ= 7
The format of the LSP_TUNNEL_IPv4 FILTER_SPEC object is identical to the LSP_TUNNEL_IPv4 SENDER_TEMPLATE object.
LSP_TUNNEL_IPv4 FILTER_SPECオブジェクトのフォーマットは、LSP_TUNNEL_IPv4 SENDER_TEMPLATEオブジェクトと同一です。
Class = FILTER SPECIFICATION, LSP_TUNNEL_IPv6 C_Type = 8
クラス=フィルタ仕様、LSP_TUNNEL_IPv6 C_Type = 8
The format of the LSP_TUNNEL_IPv6 FILTER_SPEC object is identical to the LSP_TUNNEL_IPv6 SENDER_TEMPLATE object.
LSP_TUNNEL_IPv6 FILTER_SPECオブジェクトのフォーマットは、LSP_TUNNEL_IPv6 SENDER_TEMPLATEオブジェクトと同一です。
This section describes how to setup a tunnel that is capable of maintaining resource reservations (without double counting) while it is being rerouted or while it is attempting to increase its bandwidth. In the initial Path message, the ingress node forms a SESSION object, assigns a Tunnel_ID, and places its IPv4 address in the Extended_Tunnel_ID. It also forms a SENDER_TEMPLATE and assigns a LSP_ID. Tunnel setup then proceeds according to the normal procedure.
このセクションでは、どのようにセットアップが再ルーティングされている間（ダブルカウントなし）リソース予約を維持するか、その帯域幅を増加しようとしている間にすることが可能なトンネルに記載されています。初期のPathメッセージにおいて、入口ノードは、セッションオブジェクトを形成Tunnel_IDを割り当て、Extended_Tunnel_IDにそのIPv4アドレスを置きます。また、SENDER_TEMPLATEを形成し、LSP_IDを割り当てます。トンネルの設定は、通常の手順に従って進行します。
On receipt of the Path message, the egress node sends a Resv message with the STYLE Shared Explicit toward the ingress node.
Pathメッセージの受信時に、出口ノードが入口ノードに向けて明示的共有スタイルでResvメッセージを送信します。
When an ingress node with an established path wants to change that path, it forms a new Path message as follows. The existing SESSION object is used. In particular the Tunnel_ID and Extended_Tunnel_ID are unchanged. The ingress node picks a new LSP_ID to form a new SENDER_TEMPLATE. It creates an EXPLICIT_ROUTE object for the new route. The new Path message is sent. The ingress node refreshes both the old and new path messages.
確立されたパスと始点ノードは、そのパスを変更したい場合は、以下のように、それは新しいPathメッセージを形成しています。既存のセッションオブジェクトが使用されています。特に、Tunnel_IDとExtended_Tunnel_IDは変更されません。入口ノードは、新しいSENDER_TEMPLATEを形成するための新しいLSP_IDを選びます。これは、新しいルートのEXPLICIT_ROUTEオブジェクトを作成します。新しいPathメッセージが送信されます。入口ノードは、新旧両方のパスメッセージをリフレッシュします。
The egress node responds with a Resv message with an SE flow descriptor formatted as:
出口ノードは、としてフォーマットSEフロー記述とResvメッセージで応答します。
<FLOWSPEC><old_FILTER_SPEC><old_LABEL_OBJECT><new_FILTER_SPEC> <new_LABEL_OBJECT>
<FLOWSPEC> <old_FILTER_SPEC> <old_LABEL_OBJECT> <new_FILTER_SPEC> <new_LABEL_OBJECT>
(Note that if the PHOPs are different, then two messages are sent each with the appropriate FILTER_SPEC and LABEL_OBJECT.)
（PHOPsが異なる場合、2件のメッセージが適切なFILTER_SPECとLABEL_OBJECTでそれぞれ送信されることに注意してください。）
When the ingress node receives the Resv Message(s), it may begin using the new route. It SHOULD send a PathTear message for the old route.
入口ノードは、RESVメッセージ（単数または複数）を受信すると、新たな経路を使用して開始することができます。これは、古いルートのPathTearメッセージを送るべきです。
The Session Attribute Class is 207. Two C_Types are defined, LSP_TUNNEL, C-Type = 7 and LSP_TUNNEL_RA, C-Type = 1. The LSP_TUNNEL_RA C-Type includes all the same fields as the LSP_TUNNEL C-Type. Additionally it carries resource affinity information. The formats are as follows:
セッション属性クラスは、207二C_Typesが定義されているLSP_TUNNEL、C型= 7とLSP_TUNNEL_RA、C型= 1 LSP_TUNNEL_RA C-TypeがLSP_TUNNEL C型など、すべて同じフィールドを含んでいます。さらに、それはリソース・アフィニティ情報を運びます。次のように形式は次のとおりです。
SESSION_ATTRIBUTE class = 207, LSP_TUNNEL C-Type = 7
SESSION_ATTRIBUTEクラス= 207、LSP_TUNNEL Cタイプ= 7
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Setup Prio | Holding Prio | Flags | Name Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Session Name (NULL padded display string) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Setup Priority
セットアップの優先順位
The priority of the session with respect to taking resources, in the range of 0 to 7. The value 0 is the highest priority. The Setup Priority is used in deciding whether this session can preempt another session.
0〜7の範囲内のリソースを取るに対するセッションの優先順位、値0は最高の優先順位です。セットアップの優先順位は、このセッションは別のセッションを先取りできるかどうかを決定する際に使用されています。
Holding Priority
保持優先度
The priority of the session with respect to holding resources, in the range of 0 to 7. The value 0 is the highest priority. Holding Priority is used in deciding whether this session can be preempted by another session.
0〜7の範囲内のリソースを保持に対するセッションの優先順位、値0は最高の優先順位です。保持優先順位は、このセッションが別のセッションによってプリエンプトできるかどうかを決定するのに使用されています。
Flags
国旗
0x01 Local protection desired
希望0x01のローカル保護
This flag permits transit routers to use a local repair
mechanism which may result in violation of the explicit
route object. When a fault is detected on an adjacent
downstream link or node, a transit router can reroute
traffic for fast service restoration.
0x02 Label recording desired
0x02のラベルは、所望の記録します
This flag indicates that label information should be
included when doing a route record.
0x04 SE Style desired
0x04のSEスタイルが望ま
This flag indicates that the tunnel ingress node may
choose to reroute this tunnel without tearing it down.
A tunnel egress node SHOULD use the SE Style when
responding with a Resv message.
Name Length
名前の長さ
The length of the display string before padding, in bytes.
バイトでパディング前の表示文字列の長さ、。
Session Name
セッション名
A null padded string of characters.
ヌル文字の文字列を埋め。
SESSION_ATTRIBUTE class = 207, LSP_TUNNEL_RA C-Type = 1
SESSION_ATTRIBUTEクラス= 207、LSP_TUNNEL_RA Cタイプ= 1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Exclude-any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Include-any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Include-all |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Setup Prio | Holding Prio | Flags | Name Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Session Name (NULL padded display string) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Exclude-any
除外、任意の
A 32-bit vector representing a set of attribute filters associated with a tunnel any of which renders a link unacceptable.
許容できないリンクをレンダリングする任意のそのトンネルに関連付けられている属性フィルタのセットを表す32ビットのベクトル。
Include-any
含める-いずれかを
A 32-bit vector representing a set of attribute filters associated with a tunnel any of which renders a link acceptable (with respect to this test). A null set (all bits set to zero) automatically passes.
（この試験に対して）許容されるリンクをレンダリングする任意のそのトンネルに関連付けられている属性フィルタのセットを表す32ビットのベクトル。空集合（すべてのビットがゼロに設定）を自動的に通過します。
Include-all
含める-すべて
A 32-bit vector representing a set of attribute filters associated with a tunnel all of which must be present for a link to be acceptable (with respect to this test). A null set (all bits set to zero) automatically passes.
（この試験に関して）許容さへのリンクは存在していなければならないすべてがトンネルに関連付けられている属性フィルタのセットを表す32ビットのベクトル。空集合（すべてのビットがゼロに設定）を自動的に通過します。
Setup Priority
セットアップの優先順位
The priority of the session with respect to taking resources, in the range of 0 to 7. The value 0 is the highest priority. The Setup Priority is used in deciding whether this session can preempt another session.
0〜7の範囲内のリソースを取るに対するセッションの優先順位、値0は最高の優先順位です。セットアップの優先順位は、このセッションは別のセッションを先取りできるかどうかを決定する際に使用されています。
Holding Priority
保持優先度
The priority of the session with respect to holding resources, in the range of 0 to 7. The value 0 is the highest priority. Holding Priority is used in deciding whether this session can be preempted by another session.
0〜7の範囲内のリソースを保持に対するセッションの優先順位、値0は最高の優先順位です。保持優先順位は、このセッションが別のセッションによってプリエンプトできるかどうかを決定するのに使用されています。
Flags
国旗
0x01 Local protection desired
希望0x01のローカル保護
This flag permits transit routers to use a local repair
mechanism which may result in violation of the explicit
route object. When a fault is detected on an adjacent
downstream link or node, a transit router can reroute
traffic for fast service restoration.
0x02 Label recording desired
0x02のラベルは、所望の記録します
This flag indicates that label information should be
included when doing a route record.
0x04 SE Style desired
0x04のSEスタイルが望ま
This flag indicates that the tunnel ingress node may
choose to reroute this tunnel without tearing it down.
A tunnel egress node SHOULD use the SE Style when
responding with a Resv message.
Name Length
名前の長さ
The length of the display string before padding, in bytes.
バイトでパディング前の表示文字列の長さ、。
Session Name
セッション名
A null padded string of characters.
ヌル文字の文字列を埋め。
The support of setup and holding priorities is OPTIONAL. A node can recognize this information but be unable to perform the requested operation. The node SHOULD pass the information downstream unchanged.
セットアップおよび保持優先順位のサポートはオプションです。ノードは、この情報を認識するだけで、要求された操作を実行できないことができます。ノードは、下流不変の情報を渡す必要があります。
As noted above, preemption is implemented by two priorities. The Setup Priority is the priority for taking resources. The Holding Priority is the priority for holding a resource. Specifically, the
上述したように、プリエンプションは、2つの優先度によって実現されます。セットアップの優先順位は、リソースを取るための優先事項です。保持優先度は、リソースを保持するための優先事項です。具体的には、
Holding Priority is the priority at which resources assigned to this session will be reserved. The Setup Priority SHOULD never be higher than the Holding Priority for a given session.
保持優先順位は、このセッションに割り当てられたリソースが予約される時の優先順位です。セットアップの優先順位が与えられたセッションのための保持優先度よりも高くなることはありません。
The setup and holding priorities are directly analogous to the preemption and defending priorities as defined in [9]. While the interaction of these two objects is ultimately a matter of policy, the following default interaction is RECOMMENDED.
セットアップおよび保持優先順位がプリエンプションに直接類似しており、[9]で定義されるように優先順位を守ります。これら二つのオブジェクトの相互作用が、最終的にポリシーの問題ですが、次のデフォルトの相互作用が推奨されます。
When both objects are present, the preemption priority policy element is used. A mapping between the priority spaces is defined as follows. A session attribute priority S is mapped to a preemption priority P by the formula P = 2^(14-2S). The reverse mapping is shown in the following table.
両方のオブジェクトが存在する場合、先取り優先ポリシー要素が使用されます。次のように優先順位空間の間のマッピングが定義されています。セッション属性優先Sは、式P = 2 ^（14-2S）によって先取り優先度Pにマッピングされます。逆マッピングを以下の表に示されています。
Preemption Priority Session Attribute Priority
先取り優先権セッション属性の優先順位
0 - 3 7 4 - 15 6 16 - 63 5 64 - 255 4 256 - 1023 3 1024 - 4095 2 4096 - 16383 1 16384 - 65535 0
０ ー ３ ７ ４ ー １５ ６ １６ ー ６３ ５ ６４ ー ２５５ ４ ２５６ ー １０２３ ３ １０２４ ー ４０９５ ２ ４０９６ ー １６３８３ １ １６３８４ ー ６５５３５ ０
When a new Path message is considered for admission, the bandwidth requested is compared with the bandwidth available at the priority specified in the Setup Priority.
新しいPathメッセージが入学を考えた場合、要求された帯域幅は、セットアップ優先順位に指定された優先度で利用可能な帯域幅と比較されます。
If the requested bandwidth is not available a PathErr message is returned with an Error Code of 01, Admission Control Failure, and an Error Value of 0x0002. The first 0 in the Error Value indicates a globally defined subcode and is not informational. The 002 indicates "requested bandwidth unavailable".
要求された帯域幅が利用できない場合のPathErrメッセージは、01のエラーコード、アドミッション制御の障害、および0×0002のエラー値を返します。エラー値の最初の0は、グローバルに定義されたサブコードを示し、情報提供ではありません。 002は、「使用できない帯域幅を要求」を示しています。
If the requested bandwidth is less than the unused bandwidth then processing is complete. If the requested bandwidth is available, but is in use by lower priority sessions, then lower priority sessions (beginning with the lowest priority) MAY be preempted to free the necessary bandwidth.
要求帯域が未使用の帯域幅より小さい場合、処理は完了です。要求された帯域幅が利用可能ですが、優先度の低いセッションで使用されている場合には、（最低の優先順位で始まる）優先度の低いセッションが必要な帯域幅を解放するために先取りされるかもしれません。
When preemption is supported, each preempted reservation triggers a TC_Preempt() upcall to local clients, passing a subcode that indicates the reason. A ResvErr and/or PathErr with the code "Policy Control failure" SHOULD be sent toward the downstream receivers and upstream senders.
プリエンプションがサポートされている場合、各先取り予約（TC_Preemptをトリガする）理由を示すサブコードを渡し、ローカルクライアントにアップコール。 ResvErrおよび/またはコード「ポリシー制御不良」とのPathErrは、下流の受信機と、上流の送信者に向けて送信されるべきです。
The support of local-protection is OPTIONAL. A node may recognize the local-protection Flag but may be unable to perform the requested operation. In this case, the node SHOULD pass the information downstream unchanged.
地元の保護のサポートはオプションです。ノードは、ローカル保護フラグを認識することができるが、要求された操作を実行することができません。この場合、ノードは、下流不変の情報を渡す必要があります。
The recording of the Label subobject in the ROUTE_RECORD object is controlled by the label-recording-desired flag in the SESSION_ATTRIBUTE object. Since the Label subobject is not needed for all applications, it is not automatically recorded. The flag allows applications to request this only when needed.
ROUTE_RECORDオブジェクトのラベルサブオブジェクトの記録はSESSION_ATTRIBUTEオブジェクト内のラベル記録所望のフラグによって制御されます。ラベルサブオブジェクトは、すべてのアプリケーションのために必要されていないので、それが自動的に記録されていません。フラグが必要な場合にのみ、アプリケーションがこれを要求することができます。
The contents of the Session Name field are a string, typically of display-able characters. The Length MUST always be a multiple of 4 and MUST be at least 8. For an object length that is not a multiple of 4, the object is padded with trailing NULL characters. The Name Length field contains the actual string length.
セッション名フィールドの内容は、一般的に表示可能な文字の文字列です。長さが常に4の倍数でなければならないと4の倍数ではない物体長のために少なくとも8でなければなりません、オブジェクトがNULL文字を末尾で埋めています。名前の長さフィールドは、実際の文字列の長さが含まれています。
Resource classes and resource class affinities are described in [3]. In this document we use the briefer term resource affinities for the latter term. Resource classes can be associated with links and advertised in routing protocols. Resource class affinities are used by RSVP in two ways. In order to be validated a link MUST pass the three tests below. If the test fails a PathErr with the code "policy control failure" SHOULD be sent.
リソースクラスとリソースクラスの親和性は、[3]で説明されています。この文書では、後者の用語のために簡潔用語リソース親和性を使用しています。リソースクラスは、リンクに関連付けられており、ルーティングプロトコルで広告することができます。リソースクラスの親和性は、2つの方法でRSVPで使用されています。リンクを検証するために、以下の3つのテストに合格する必要があります。テストが失敗した場合は、コード「ポリシー制御の失敗」とのPathErrを送ってください。
When a new reservation is considered for admission over a strict node in an ERO, a node MAY validate the resource affinities with the resource classes of that link. When a node is choosing links in order to extend a loose node of an ERO, the node MUST validate the resource classes of those links against the resource affinities. If no acceptable links can be found to extend the ERO, the node SHOULD send a PathErr message with an error code of "Routing Problem" and an error value of "no route available toward destination".
新しい予約がEROに厳格なノード上で入学を考えた場合、ノードは、そのリンクのリソースクラスとリソースの親和性を検証することができます。ノードはEROの緩いノードを拡張するためにリンクを選択した場合、ノードは、リソースの親和性に対するこれらのリンクのリソースクラスを検証する必要があります。受け入れ可能なリンクがEROを拡張するために見つからない場合、ノードは、「ルーティング問題」と「目的地に向かってなしルート」のエラー値のエラーコードでのPathErrメッセージを送信すべきです。
In order to be validated a link MUST pass the following three tests.
リンクを検証するために、以下の3つの試験に合格しなければなりません。
To precisely describe the tests use the definitions in the object description above. We also define
精密検査は、上記オブジェクト記述の定義を使用説明します。また、定義します
Link-attr A 32-bit vector representing attributes associated with a link.
リンクATTRリンクに関連付けられている属性を表す32ビットのベクトル。
The three tests are
3つのテストがあります
This test excludes a link from consideration if the link carries any of the attributes in the set.
リンクは、セット内の属性のいずれかを担持する場合は、このテストでは考慮からリンクを除外する。
(link-attr & exclude-any) == 0
（リンク-ATTR＆除外-任意の）== 0
This test accepts a link if the link carries any of the attributes in the set.
リンクは、セット内の属性のいずれかを運ぶ場合は、このテストでは、リンクを受け入れます。
(include-any == 0) | ((link-attr & include-any) != 0)
（含ま-いかなる== 0）| （（リンク-ATTR＆含める-いずれかを）！= 0）
This test accepts a link only if the link carries all of the attributes in the set.
このテストでは、リンクはセット内の属性のすべてを運ぶ場合にのみ、リンクを受け付けます。
(include-all == 0) | (((link-attr & include-all) ^ include-all) == 0)
（含ま-すべて== 0）| （（（リンク-ATTR＆含め、すべての）^含ま-すべてを）== 0）
For a link to be acceptable, all three tests MUST pass. If the test fails, the node SHOULD send a PathErr message with an error code of "Routing Problem" and an error value of "no route available toward destination".
リンクが受け入れられるためには、3つのすべてのテストに合格しなければなりません。テストが失敗した場合、ノードは、「ルーティング問題」と「目的地に向かってなしルート」のエラー値のエラーコードでのPathErrメッセージを送信すべきです。
If a Path message contains multiple SESSION_ATTRIBUTE objects, only the first SESSION_ATTRIBUTE object is meaningful. Subsequent SESSION_ATTRIBUTE objects can be ignored and need not be forwarded.
Pathメッセージは、複数SESSION_ATTRIBUTEオブジェクトが含まれている場合は、最初SESSION_ATTRIBUTEオブジェクトは有意義です。後続のSESSION_ATTRIBUTEオブジェクトは無視することができ、転送する必要はありません。
All RSVP routers, whether they support the SESSION_ATTRIBUTE object or not, SHALL forward the object unmodified. The presence of non-RSVP routers anywhere between senders and receivers has no impact on this object.
すべてのRSVPルータは、彼らはSESSION_ATTRIBUTEオブジェクトをサポートするかどうか、オブジェクトがそのまま転送するものとします。どこでも送信側と受信側との間の非RSVPルータの存在は、このオブジェクトに影響を及ぼしません。
The RSVP Hello extension enables RSVP nodes to detect when a neighboring node is not reachable. The mechanism provides node to node failure detection. When such a failure is detected it is handled much the same as a link layer communication failure. This mechanism is intended to be used when notification of link layer failures is not available and unnumbered links are not used, or when the failure detection mechanisms provided by the link layer are not sufficient for timely node failure detection.
RSVPハロー拡張は、隣接ノードが到達可能でないときを検出するRSVPノードを可能にします。機構は、ノード障害検出にノードを提供します。このような障害が検出された場合には、はるかにリンクレイヤ通信障害と同様に扱われます。リンクレイヤ障害の通知が利用可能ではなく、無数のリンクが使用されていない場合、またはこのメカニズムが使用されることが意図されるリンク層により提供される障害検出メカニズムは、タイムリーなノード故障検出のために十分ではない場合。
It should be noted that node failure detection is not the same as a link failure detection mechanism, particularly in the case of multiple parallel unnumbered links.
ノード障害検出は、特に、複数の平行な無数のリンクの場合、リンク障害検出機構と同じではないことに留意すべきです。
The Hello extension is specifically designed so that one side can use the mechanism while the other side does not. Neighbor failure detection may be initiated at any time. This includes when neighbors first learn about each other, or just when neighbors are sharing Resv or Path state.
他の側はそうではない片側機構を使用できるようにこんにちは拡張が特別に設計されています。近隣の障害検出は、任意の時点で開始することができます。隣人が最初にお互いを知る、または隣人がのResvまたはパスの状態を共有しているちょうどその時とき、これが含まれています。
The Hello extension is composed of a Hello message, a HELLO REQUEST object and a HELLO ACK object. Hello processing between two neighbors supports independent selection of, typically configured, failure detection intervals. Each neighbor can autonomously issue HELLO REQUEST objects. Each request is answered by an acknowledgment. Hello Messages also contain enough information so that one neighbor can suppress issuing hello requests and still perform neighbor failure detection. A Hello message may be included as a sub-message within a bundle message.
ハロー拡張はHelloメッセージ、ハローリクエスト・オブジェクトとのHELLO ACKオブジェクトで構成されています。こんにちは2人の隣人の間の処理は、障害検出間隔、一般的に構成された、とは独立して選択をサポートしています。各隣人は、自律的に、HELLO REQUESTオブジェクトを発行することができます。各要求は、肯定応答で答えています。 1つのネイバーがハロー要求を発行抑制し、まだ近隣の故障検出を行うことができるようにhelloメッセージも十分な情報が含まれています。 Helloメッセージは、バンドルメッセージ内のサブメッセージとして含まれてもよいです。
Neighbor failure detection is accomplished by collecting and storing a neighbor's "instance" value. If a change in value is seen or if the neighbor is not properly reporting the locally advertised value, then the neighbor is presumed to have reset. When a neighbor's value is seen to change or when communication is lost with a neighbor, then the instance value advertised to that neighbor is also changed. The HELLO objects provide a mechanism for polling for and providing an instance value. A poll request also includes the sender's instance value. This allows the receiver of a poll to optionally treat the poll as an implicit poll response. This optional handling is an optimization that can reduce the total number of polls and responses processed by a pair of neighbors. In all cases, when both sides support the optimization the result will be only one set of polls and responses per failure detection interval. Depending on selected intervals, the same benefit can occur even when only one neighbor supports the optimization.
近隣の故障検出は、ネイバーの「インスタンス」の値を収集し、保存することによって達成されます。隣人が適切にローカルに宣伝値を報告されていない場合は、値の変化が見られたりした場合は、隣人はリセットを持っていると推定されます。隣人の値を見ているときに変更するか、通信が隣人で失われたとき、そのネイバーにアドバタイズされるインスタンス値も変更されます。ハローオブジェクトはのためのポーリングおよびインスタンス値を提供するための機構を提供します。ポーリング要求も送信者のインスタンス値を含んでいます。これは、ポーリングの受信機が暗黙ポーリング応答としてポーリングを扱う任意することを可能にします。このオプションの取り扱いは隣人のペアによって処理をポーリングし、応答の合計数を減らすことができ、最適化です。すべての場合において、双方が最適化をサポートする結果は、投票や障害検出間隔ごとの応答の一組のみとなります。唯一の隣人が最適化をサポートしている場合でも、選択した間隔に応じて、同じ利益が発生する可能性があります。
Hello Messages are always sent between two RSVP neighbors. The IP source address is the IP address of the sending node. The IP destination address is the IP address of the neighbor node.
helloメッセージは、常に2人のRSVP隣人の間で送信されます。 IP送信元アドレスは、送信ノードのIPアドレスです。 IP宛先アドレスは、近隣ノードのIPアドレスです。
The HELLO mechanism is intended for use between immediate neighbors. When HELLO messages are being the exchanged between immediate neighbors, the IP TTL field of all outgoing HELLO messages SHOULD be set to 1.
ハロー機構はすぐ隣の間に使用するためのものです。 helloメッセージは、すぐ隣の間で交換されている場合は、すべてのHELLO送信メッセージのIP TTLフィールドが1に設定する必要があります。
The Hello message has a Msg Type of 20. The Hello message format is as follows:
Helloメッセージは、以下のようにHelloメッセージのフォーマットである20のメッセージタイプを有します。
<Hello Message> ::= <Common Header> [ <INTEGRITY> ]
<HELLO>
The HELLO Class is 22. There are two C_Types defined.
ハロークラスが定義された2つのC_Typesがある22です。
Class = HELLO Class, C_Type = 1
クラス=ハロークラス、C_Type = 1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src_Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dst_Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Class = HELLO Class, C_Type = 2
クラス=ハロークラス、C_Type = 2
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src_Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dst_Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Src_Instance: 32 bits
Src_Instance：32ビット
a 32 bit value that represents the sender's instance. The advertiser maintains a per neighbor representation/value. This value MUST change when the sender is reset, when the node reboots, or when communication is lost to the neighboring node and otherwise remains the same. This field MUST NOT be set to zero (0).
送信者のインスタンスを表す32ビットの値。広告主は、隣人あたりの表現/値を維持します。ノードがリブート、または通信が隣接ノードに失われた場合にそうでない場合と同じままである場合、送信者は、リセットされた場合、この値は変更しなければなりません。このフィールドは、ゼロ（0）に設定してはいけません。
Dst_Instance: 32 bits
Dst_Instance：32ビット
The most recently received Src_Instance value received from the neighbor. This field MUST be set to zero (0) when no value has ever been seen from the neighbor.
ネイバーから受信最後に受信Src_Instance値。何の価値が今まで隣人から見られていない場合、このフィールドはゼロ（0）に設定しなければなりません。
The Hello Message is completely OPTIONAL. All messages may be ignored by nodes which do not wish to participate in Hello message processing. The balance of this section is written assuming that the receiver as well as the sender is participating. In particular, the use of MUST and SHOULD with respect to the receiver applies only to a node that supports Hello message processing.
こんにちは、メッセージは完全に任意です。すべてのメッセージは、Helloメッセージの処理に参加することを希望しないノードによって無視されることがあります。このセクションの残りは、受信機と同様に送信者が参加していると仮定して書かれています。具体的には、受信機に対する必要があり、SHOULDの使用は、Helloメッセージの処理をサポートするノードに適用されます。
A node periodically generates a Hello message containing a HELLO REQUEST object for each neighbor who's status is being tracked. The periodicity is governed by the hello_interval. This value MAY be configured on a per neighbor basis. The default value is 5 ms.
ノードは、定期的にステータスが追跡されていた各ネイバーのhello要求オブジェクトを含むHelloメッセージを生成します。周期性はHELLO_INTERVALによって支配されています。この値は、隣接ごとに構成されるかもしれません。デフォルト値は5ミリ秒です。
When generating a message containing a HELLO REQUEST object, the sender fills in the Src_Instance field with a value representing it's per neighbor instance. This value MUST NOT change while the agent is exchanging Hellos with the corresponding neighbor. The sender also fills in the Dst_Instance field with the Src_Instance value most recently received from the neighbor. For reference, call this variable Neighbor_Src_Instance. If no value has ever been received from the neighbor or this node considers communication to the neighbor to have been lost, the Neighbor_Src_Instance is set to zero (0). The generation of a message SHOULD be suppressed when a HELLO REQUEST object was received from the destination node within the prior hello_interval interval.
ハローリクエストオブジェクトを含むメッセージを生成する際に、送信者は、それが隣接インスタンスごとだ表す値でSrc_Instanceフィールドを埋めます。エージェントが対応するネイバーとhelloを交換している間、この値は変化してはいけません。送信者はまた、最近ネイバーから受信Src_Instance値でDst_Instanceフィールドを埋めます。参考のため、この変数Neighbor_Src_Instanceを呼び出します。何値が今までネイバーから受信されていない、またはこのノードが失われたと隣人への通信を考慮した場合、Neighbor_Src_Instanceはゼロ（0）に設定されています。ハローリクエストオブジェクトが前HELLO_INTERVAL間隔内で宛先ノードから受信されたときに、メッセージの生成が抑制されるべきです。
On receipt of a message containing a HELLO REQUEST object, the receiver MUST generate a Hello message containing a HELLO ACK object. The receiver SHOULD also verify that the neighbor has not reset. This is done by comparing the sender's Src_Instance field value with the previously received value. If the Neighbor_Src_Instance value is zero, and the Src_Instance field is non-zero, the Neighbor_Src_Instance is updated with the new value. If the value differs or the Src_Instance field is zero, then the node MUST treat the neighbor as if communication has been lost.
ハローリクエストオブジェクトを含むメッセージを受信すると、受信機は、HELLO ACKオブジェクトを含むHelloメッセージを生成しなければなりません。また、受信機は、ネイバーがリセットされていないことを確認する必要があります。これは、以前に受信した値と送信者のSrc_Instanceフィールド値を比較することによって行われます。 Neighbor_Src_Instance値がゼロであり、Src_Instanceフィールドがゼロでない場合、Neighbor_Src_Instanceは新しい値で更新されます。値が異なるかSrc_Instanceフィールドがゼロの場合の通信が失われたかのように、ノードは隣人を扱わなければなりません。
The receiver of a HELLO REQUEST object SHOULD also verify that the neighbor is reflecting back the receiver's Instance value. This is done by comparing the received Dst_Instance field with the Src_Instance field value most recently transmitted to that neighbor. If the neighbor continues to advertise a wrong non-zero value after a configured number of intervals, then the node MUST treat the neighbor as if communication has been lost.
ハローリクエストオブジェクトの受信機は、隣人がレシーバのインスタンスの値をバック反映されていることを確認すべきです。これは、最近そのネイバーに送信Src_Instanceフィールド値で受信Dst_Instanceフィールドを比較することによって行われます。隣人が間隔の設定された数の後、間違ったゼロ以外の値を宣伝し続けた場合の通信が失われたかのように、ノードは隣人を扱わなければなりません。
On receipt of a message containing a HELLO ACK object, the receiver MUST verify that the neighbor has not reset. This is done by comparing the sender's Src_Instance field value with the previously received value. If the Neighbor_Src_Instance value is zero, and the Src_Instance field is non-zero, the Neighbor_Src_Instance is updated with the new value. If the value differs or the Src_Instance field is zero, then the node MUST treat the neighbor as if communication has been lost.
ハローACKオブジェクトを含むメッセージを受信すると、受信機は、近隣がリセットしていないことを確かめなければなりません。これは、以前に受信した値と送信者のSrc_Instanceフィールド値を比較することによって行われます。 Neighbor_Src_Instance値がゼロであり、Src_Instanceフィールドがゼロでない場合、Neighbor_Src_Instanceは新しい値で更新されます。値が異なるかSrc_Instanceフィールドがゼロの場合の通信が失われたかのように、ノードは隣人を扱わなければなりません。
The receiver of a HELLO ACK object MUST also verify that the neighbor is reflecting back the receiver's Instance value. If the neighbor advertises a wrong value in the Dst_Instance field, then a node MUST treat the neighbor as if communication has been lost.
ハローACKオブジェクトの受信機は、隣人がレシーバのインスタンスの値をバック反映されていることを確認しなければなりません。隣人がDst_Instanceフィールドに誤った値を広告する場合の通信が失われたかのように、ノードは隣人を扱わなければなりません。
If no Instance values are received, via either REQUEST or ACK objects, from a neighbor within a configured number of hello_intervals, then a node MUST presume that it cannot communicate with the neighbor. The default for this number is 3.5.
ないインスタンス値はhello_intervalsの構成数内ネイバーから、要求またはACKのいずれかのオブジェクトを介して、受信されない場合、そのノードは、ネイバーと通信できないことを推測しなければなりません。この番号のデフォルトは3.5です。
When communication is lost or presumed to be lost as described above, a node MAY re-initiate HELLOs. If a node does re-initiate it MUST use a Src_Instance value different than the one advertised in the previous HELLO message. This new value MUST continue to be advertised to the corresponding neighbor until a reset or reboot occurs, or until another communication failure is detected. If a new instance value has not been received from the neighbor, then the node MUST advertise zero in the Dst_instance value field.
通信が失われたり、上記のように失われると推定される場合、ノードが再開始することができるhelloを。ノードがない場合、それは前HELLOメッセージでアドバタイズとは異なるSrc_Instance値を使用しなければなりません再起動。この新しい値は、リセットまたは再起動が発生するまで、対応するネイバーにアドバタイズすることを継続する必要があり、または別の通信障害が検出されるまで。新しいインスタンス値は、ネイバーから受信されていない場合、ノードはDst_instance値フィールドにゼロを宣伝しなければなりません。
As previously noted, the Hello extension is targeted at detecting node failures not per link failures. When there is only one link between neighboring nodes or when all links between a pair of nodes fail, the distinction between node and link failures is not really meaningful and handling of such failures has already been covered. When there are multiple links shared between neighbors, there are special considerations. When the links between neighbors are numbered, then Hellos MUST be run on each link and the previously described mechanisms apply.
先に述べたように、ハロー拡張子がないリンク障害ごとのノードの障害を検出対象としています。隣接ノードまたは時に一対のノード間のすべてのリンクが失敗の間に一つだけのリンクがある場合は、ノードとリンク障害の区別が本当に意味のあるような障害の取り扱いが既にカバーされているではありません。隣人の間で共有複数のリンクがある場合、特別な考慮事項があります。ネイバー間のリンクは番号が付けられている場合は、その後、ハローズは、各リンク上で実行する必要があり、前述のメカニズムが適用されます。
When the links are unnumbered, link failure detection MUST be provided by some means other than Hellos. Each node SHOULD use a single Hello exchange with the neighbor. The case where all links have failed, is the same as the no received value case mentioned in the previous section.
リンクが番号付けされていない場合は、リンク障害検出はハローズ以外の手段によって提供されなければなりません。各ノードは、隣人を持つ単一のHello交換を使用すべきです。すべてのリンクが失敗した場合は、前のセクションで述べない受信値の場合と同様です。
The Hello extension does not affect the processing of any other RSVP message. The only effect is to allow a link (node) down event to be declared sooner than it would have been. RSVP response to that condition is unchanged.
こんにちは拡張子は、他のRSVPメッセージの処理には影響を与えません。唯一の効果は、イベントダウンリンク（ノード）は、それがあったであろうよりも早く宣言することができるようにすることです。その条件にRSVPの応答は変更されません。
The Hello extension is fully backwards compatible. The Hello class is assigned a class value of the form 0bbbbbbb. Depending on the implementation, implementations that do not support the extension will either silently discard Hello messages or will respond with an "Unknown Object Class" error. In either case the sender will fail to see an acknowledgment for the issued Hello.
こんにちは拡張子は完全な下位互換性があります。 Helloクラスは、フォーム0bbbbbbbはのクラス値が割り当てられます。実装に応じて、拡張をサポートしない実装はどちらか静かにHelloメッセージを破棄しますか「不明なオブジェクトクラス」エラーで応答します。いずれの場合も、送信者は、発行こんにちはに対する肯定応答を確認するために失敗します。
In principle these extensions to RSVP pose no security exposures over and above RFC 2205[1]. However, there is a slight change in the trust model. Traffic sent on a normal RSVP session can be filtered according to source and destination addresses as well as port numbers. In this specification, filtering occurs only on the basis of an incoming label. For this reason an administration may wish to limit the domain over which LSP tunnels can be established. This can be accomplished by setting filters on various ports to deny action on a RSVP path message with a SESSION object of type LSP_TUNNEL_IPv4 (7) or LSP_TUNNEL_IPv6 (8).
原則的にRSVPするために、これらの拡張機能はオーバーとRFC 2205の上にはセキュリティリスクを提起しない[1]。しかし、信頼モデルのわずかな変化があります。通常のRSVPセッションで送信されるトラフィックは、送信元アドレス、宛先アドレス、並びにポート番号に応じてフィルタリングすることができます。本明細書では、フィルタリングは、のみ着信ラベルに基づいて行われます。この理由政権はLSPトンネルを確立することができ、その上、ドメインを制限したいことがあります。これは、タイプLSP_TUNNEL_IPv4（7）またはLSP_TUNNEL_IPv6（8）のSESSIONオブジェクトにRSVPの経路メッセージにアクションを拒否するために種々のポートにフィルタを設定することによって達成することができます。
IANA assigns values to RSVP protocol parameters. Within the current document an EXPLICIT_ROUTE object and a ROUTE_RECORD object are defined. Each of these objects contain subobjects. This section defines the rules for the assignment of subobject numbers. This section uses the terminology of BCP 26 "Guidelines for Writing an IANA Considerations Section in RFCs" [15].
IANAは、プロトコルパラメータをRSVPに値を割り当てます。現在のドキュメント内EXPLICIT_ROUTEオブジェクトとROUTE_RECORDオブジェクトが定義されています。これらの各オブジェクトには、サブオブジェクトが含まれています。このセクションでは、サブオブジェクト番号の割り当てのための規則を定義します。このセクションでは、「RFCでIANA問題部に書くためのガイドライン」[15] BCP 26の用語を使用しています。
EXPLICIT_ROUTE Subobject Type
EXPLICIT_ROUTEサブオブジェクトタイプ
EXPLICIT_ROUTE Subobject Type is a 7-bit number that identifies the function of the subobject. There are no range restrictions. All possible values are available for assignment.
EXPLICIT_ROUTEサブオブジェクトタイプサブオブジェクトの機能を特定する7ビット数です。何の範囲の制限はありません。すべての可能な値は、割り当てのために利用可能です。
Following the policies outlined in [15], subobject types in the range 0 - 63 (0x00 - 0x3F) are allocated through an IETF Consensus action, codes in the range 64 - 95 (0x40 - 0x5F) are allocated as First Come First Served, and codes in the range 96 - 127 (0x60 - 0x7F) are reserved for Private Use.
[15]に概説された方針以下、範囲内のサブオブジェクトタイプ0から63（0x00の - は0x3F）がIETF Consensus動作を通じて割り当てられ、範囲の符号64から95を（0x40の - 0x5F）最初の配信最初に来るように、割り当てられています範囲96でコード - 127（0x60 - 0x7Fの）は、私的使用のために予約されています。
ROUTE_RECORD Subobject Type
ROUTE_RECORDサブオブジェクトタイプ
ROUTE_RECORD Subobject Type is an 8-bit number that identifies the function of the subobject. There are no range restrictions. All possible values are available for assignment.
ROUTE_RECORDサブオブジェクトタイプサブオブジェクトの機能を識別する8ビットの数です。何の範囲の制限はありません。すべての可能な値は、割り当てのために利用可能です。
Following the policies outlined in [15], subobject types in the range 0 - 127 (0x00 - 0x7F) are allocated through an IETF Consensus action, codes in the range 128 - 191 (0x80 - 0xBF) are allocated as First Come First Served, and codes in the range 192 - 255 (0xC0 - 0xFF) are reserved for Private Use.
[15]に概説された方針以下、範囲内のサブオブジェクトタイプ0から127（$ 00 - から0x7F）がIETF Consensus動作を通じて割り当てられ、範囲128内のコード - 191（0x80の - 0xbfの）は、第1の配信最初に来るように、割り当てられています範囲192内のコード - 255（0xC0の - 0xFFでは）私的使用のために予約されています。
The following assignments are made in this document.
以下の割り当ては、この文書で作られています。
Message Message Number Name
メッセージメッセージ数名
20 Hello
20こんにちは
Class Class Number Name
クラスクラス数名
1 SESSION
1 SESSION
Class Types or C-Types:
クラスの型やC-タイプ：
7 LSP Tunnel IPv4
8 LSP Tunnel IPv6
10 FILTER_SPEC
10 FILTER_SPEC
Class Types or C-Types:
クラスの型やC-タイプ：
7 LSP Tunnel IPv4
8 LSP Tunnel IPv6
11 SENDER_TEMPLATE
11 SENDER_TEMPLATE
Class Types or C-Types:
クラスの型やC-タイプ：
7 LSP Tunnel IPv4
8 LSP Tunnel IPv6
16 RSVP_LABEL
16 RSVP_LABEL
Class Types or C-Types:
クラスの型やC-タイプ：
1 Type 1 Label
1つのタイプ1ラベル
19 LABEL_REQUEST
19 LABEL_REQUEST
Class Types or C-Types:
クラスの型やC-タイプ：
1 Without Label Range
2 With ATM Label Range
3 With Frame Relay Label Range
20 EXPLICIT_ROUTE
20 EXPLICIT_ROUTE
Class Types or C-Types:
クラスの型やC-タイプ：
1 Type 1 Explicit Route
1タイプ1の明示的なルート
21 ROUTE_RECORD
21 ROUTE_RECORD
Class Types or C-Types:
クラスの型やC-タイプ：
1 Type 1 Route Record
1タイプ1のルートを記録
22 HELLO
22ハロー
Class Types or C-Types:
クラスの型やC-タイプ：
1 Request
2 Acknowledgment
207 SESSION_ATTRIBUTE
207セッション属性
Class Types or C-Types:
クラスの型やC-タイプ：
1 LSP_TUNNEL_RA
7 LSP Tunnel
The following list extends the basic list of Error Codes and Values that are defined in [RFC2205].
以下のリストは、[RFC2205]で定義されているエラーコードと値の基本的なリストを拡張します。
Error Code Meaning
エラーコードの意味
24 Routing Problem
24ルーティングの問題
This Error Code has the following globally-defined
Error Value sub-codes:
1 Bad EXPLICIT_ROUTE object 2 Bad strict node 3 Bad loose node 4 Bad initial subobject 5 No route available toward destination 6 Unacceptable label value 7 RRO indicated routing loops 8 MPLS being negotiated, but a non-RSVP-capable router stands in the path 9 MPLS label allocation failure 10 Unsupported L3PID
1つのバートEXPLICIT_ROUTEオブジェクト2バート厳密ノード3悪い緩いノード4バート初期サブオブジェクト5 RROルーティング8つのMPLSが交渉さループ示さ7宛先6許可されないラベル値に向かってなし経路が、非RSVP対応ルータが経路9 MPLSに立っラベル割り当て失敗10サポートされていないL3PID
25 Notify Error
25エラーを通知します
This Error Code has the following globally-defined
Error Value sub-codes:
1 RRO too large for MTU 2 RRO Notification 3 Tunnel locally repaired
1 RROローカル修復MTU 2 RRO通知3トンネルには大きすぎます
Subobjects of the EXPLICIT_ROUTE object with C-Type 1:
C-1型EXPLICIT_ROUTEオブジェクトのサブオブジェクト。
1 IPv4 prefix
2 IPv6 prefix
32 Autonomous system number
Subobjects of the RECORD_ROUTE object with C-Type 1:
C-1型RECORD_ROUTEオブジェクトのサブオブジェクト。
1 IPv4 address
2 IPv6 address
3 Label
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.
IETFは、この文書に含まれる仕様の一部またはすべてについて記載知的財産権について通知されています。詳細については、要求された権利のオンラインリストを参照してください。
This document contains ideas as well as text that have appeared in previous Internet Drafts. The authors of the current document wish to thank the authors of those drafts. They are Steven Blake, Bruce Davie, Roch Guerin, Sanjay Kamat, Yakov Rekhter, Eric Rosen, and Arun Viswanathan. We also wish to thank Bora Akyol, Yoram Bernet and Alex Mondrus for their comments on this document.
この文書は、以前のインターネットドラフトに登場してきたアイデアだけでなく、テキストが含まれています。現在の文書の著者は、これらのドラフトの作者に感謝したいです。彼らはスティーブ・ブレイク、ブルースデイビー、ロッホゲラン、サンジャイKamat、ヤコフ・レックター、エリック・ローゼン、そしてアルンViswanathanのです。また、この文書に彼らのコメントのためにボラAkyol、Yoram BernetとアレックスMondrusに感謝したいです。
[1] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1, Functional Specification", RFC 2205, September 1997.
[1]ブレーデン、R.、チャン、L.、Berson氏、S.、ハーツォグ、S.とS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1、機能仕様"、RFC 2205、1997年9月。
[2] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[2]ローゼン、E.、Viswanathanの、A.とR. Callon、 "マルチプロトコルラベルスイッチングアーキテクチャ"、RFC 3031、2001年1月。
[3] Awduche, D., Malcolm, J., Agogbua, J., O'Dell and J. McManus, "Requirements for Traffic Engineering over MPLS", RFC 2702, September 1999.
[3] Awduche、D.、マルコム、J.、Agogbua、J.、オデルとJ.マクマナス、 "MPLSのトラフィックエンジニアリングのための要件"、RFC 2702、1999年9月。
[4] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997.
[4] Wroclawski、J.、RFC 2211 "制御負荷ネットワーク要素サービスの仕様"、1997年9月。
[5] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T. and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[5]ローゼン、E.、タッパン、D.、Fedorkow、G.、Rekhter、Y.、ファリナッチ、D.、李、T.、およびA.コンタ、 "MPLSラベルスタックエンコーディング"、RFC 3032、2001年1月。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[6]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[7] Almquist, P., "Type of Service in the Internet Protocol Suite", RFC 1349, July 1992.
[7] Almquist、P.、 "インターネットプロトコルスイートでサービスの種類"、RFC 1349、1992年7月。
[8] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[8]ニコルズ、K.、ブレイク、S.、ベイカー、F.とD.ブラック、 "IPv4とIPv6ヘッダーの差別化されたサービス分野（DSフィールド）の定義"、RFC 2474、1998年12月。
[9] Herzog, S., "Signaled Preemption Priority Policy Element", RFC 2751, January 2000.
[9]ヘルツォーク、S.、 "合図先取り優先権方針要素"、RFC 2751、2000年1月。
[10] Awduche, D., Hannan, A. and X. Xiao, "Applicability Statement for Extensions to RSVP for LSP-Tunnels", RFC 3210, December 2001.
[10] Awduche、D.、阪南、A.及びX.シャオ、 "LSP-トンネルのためのRSVPの拡張のための適用性に関する声明"、RFC 3210、2001年12月。
[11] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[11] Wroclawski、J.、RFC 2210、1997年9月 "IETF統合サービスとRSVPの使用"。
[12] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[12]ポステル、J.、 "インターネット制御メッセージプロトコル"、STD 5、RFC 792、1981年9月。
[13] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, November 1990.
[13]モーグル、J.およびS.デアリング、 "パスMTUディスカバリ"、RFC 1191、1990年11月。
[14] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)", RFC 2463, December 1998.
[14]コンタ、A.、およびS.デアリング、 "インターネットプロトコルバージョン6（IPv6）のためのインターネット制御メッセージプロトコル（ICMPv6の）"、RFC 2463、1998年12月。
[15] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
、BCP 26、RFC 2434、1998年10月[15] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"。
[16] Bernet, Y., Smiht, A. and B. Davie, "Specification of the Null Service Type", RFC 2997, November 2000.
[16] Bernet、Y.、Smiht、A.及びB.デイビー、 "ヌルサービスタイプの仕様"、RFC 2997、2000年11月。
Daniel O. Awduche Movaz Networks, Inc. 7926 Jones Branch Drive, Suite 615 McLean, VA 22102 Voice: +1 703-298-5291 EMail: awduche@movaz.com
ダニエルO. Awduche Movazネットワークス株式会社7926ジョーンズ支店ドライブ、スイート615マクリーン、VA 22102声：+1 703-298-5291電子メール：awduche@movaz.com
Lou Berger Movaz Networks, Inc. 7926 Jones Branch Drive, Suite 615 McLean, VA 22102 Voice: +1 703 847 1801 EMail: lberger@movaz.com
ルー・バーガーMovazネットワークス株式会社7926ジョーンズ支店ドライブ、スイート615マクリーン、VA 22102声：+1 703 847 1801 Eメール：lberger@movaz.com
Der-Hwa Gan Juniper Networks, Inc. 385 Ravendale Drive Mountain View, CA 94043 EMail: dhg@juniper.net
デア・ファガンジュニパーネットワークス株式会社385 Ravendaleドライブマウンテンビュー、CA 94043 Eメール：dhg@juniper.net
Tony Li Procket Networks 3910 Freedom Circle, Ste. 102A Santa Clara CA 95054 EMail: tli@procket.com
トニー・李Procket Networksの3910自由サークル、マリー。 102AサンタクララCA 95054 Eメール：tli@procket.com
Vijay Srinivasan Cosine Communications, Inc. 1200 Bridge Parkway Redwood City, CA 94065 Voice: +1 650 628 4892 EMail: vsriniva@cosinecom.com
ビジェイ・スリニバサンコサインコミュニケーションズ株式会社1200ブリッジパークウェイレッドウッドシティ、CA 94065音声：+1 650 628 4892 Eメール：vsriniva@cosinecom.com
George Swallow Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA 01824 Voice: +1 978 244 8143 EMail: swallow@cisco.com
ジョージツバメシスコシステムズ社250アポロドライブチェルムズフォード、MA 01824声：+1 978 244 8143 Eメール：swallow@cisco.com
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。