[要約] RFC 3209は、RSVP-TE（RSVP Traffic Engineering）のためのRSVPの拡張に関するものであり、LSP（Label Switched Path）トンネルのための機能を提供します。このRFCの目的は、LSPトンネルの設定と管理を改善し、ネットワークのトラフィックエンジニアリングをサポートすることです。
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
RSVP-TE：LSPトンネルのRSVPへの拡張
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.
Copyright（c）The Internet Society（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（Multi-Protocolラベルスイッチング）でラベルスイッチパス（LSP）を確立するために、必要なすべての拡張機能を含むRSVP（リソース予約プロトコル）の使用について説明します。LSPに沿った流れは、パスのイングレスノードに適用されるラベルによって完全に識別されるため、これらのパスはトンネルとして扱われる場合があります。LSPトンネルの重要なアプリケーションは、RFC 2702で指定されている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では、ラベル分布プロトコルを1つのラベルを切り替えたルーター（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トンネルは、ネットワークの障害、輻輳、およびボトルネックから自動的または手動でルーティングできます。さらに、2つのノードの間に複数の平行LSPトンネルを確立でき、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パスメッセージを介してイングレスノードによって開始されます。この目的のために、RSVPパスメッセージはlabel_requestオブジェクトで拡張されます。ラベルは下流に割り当てられ、RSVP RESVメッセージによって分布（上流に伝播）されます。この目的のために、RSVP RESVメッセージは特別なラベルオブジェクトで拡張されます。ラベルの割り当て、配布、結合、および積み重ねの手順は、このドキュメントの後続のセクションで説明されています。
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.
シグナリングプロトコルモデルは、明示的なルーティング機能もサポートしています。これは、Simple rebricit_RouteオブジェクトをRSVPパスメッセージに組み込むことで実現されます。liblicit_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.
明示的なルーティングの有用なアプリケーションの1つは、交通工学です。明示的にルーティングされた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の侵入ノードに内部トポロジが不透明なノードのグループです。抽象ノードは、1つの物理ノードのみが含まれている場合、単純であると言われています。この抽象化の概念を使用して、明示的にルーティングされた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].
RSVPを使用してLSPトンネルを確立する利点は、パスに沿ったリソースの割り当てを可能にすることです。たとえば、帯域幅は、標準の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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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の侵入ノードに不透明なノードのグループ。抽象ノードは、1つの物理ノードのみが含まれている場合、単純であると言われています。
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].
1つ以上のラベルスイッチ付きホップの連結によって作成されたパスにより、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.
トラフィックトランクを運ぶ1つ以上の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とMPLが組み合わされている場合、フローまたはセッションをより大きな柔軟性と一般性で定義できます。LSPのIngressノードは、さまざまな手段を使用して、特定のラベルが割り当てられているパケットを決定できます。ラベルがパケットのセットに割り当てられると、ラベルは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セッション、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 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
一部のアプリケーションでは、LSPトンネルのセットを関連付けることが役立ちます。これは、操作の操作や複数のパスにトラフィックトランクを広めるときに役立ちます。トラフィックエンジニアリングアプリケーションでは、そのようなセットはトラフィックエンジニアリングトンネル（TEトンネル）と呼ばれます。このようなLSPトンネルの識別と関連性を有効にするために、2つの識別子が運ばれます。トンネルIDはセッションオブジェクトの一部です。セッションオブジェクトは、交通エンジニアリングトンネルを一意に定義します。sender_templateおよびfilter_specオブジェクトには、LSP IDがあります。sender_template（またはfilter_spec）オブジェクトとセッションオブジェクトは、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トンネルを確立する機能、（2）確立されたLSPトンネルを動的に再ルーティングする機能、（3）確立されたLSPトンネルによって横断される実際のルートを観察する機能、（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パスメッセージを作成し、パスメッセージにラベル_requestオブジェクトを挿入します。label_requestオブジェクトは、このパスのラベルバインディングが要求されていることを示し、また、このパスに渡されるネットワークレイヤープロトコルの兆候を提供します。この理由は、ネットワークレイヤープロトコルがLSPを送信することはIPであると想定できず、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パスメッセージにrebricit_routeオブジェクトを追加します。liblicit_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.
セッションが正常に確立された後、送信者ノードがより良いルートを発見した場合、送信者はexpricit_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.
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オブジェクトをパスメッセージに追加して、セッションの識別と診断を支援できます。セットアップと保持優先順位、リソース親和性（[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.
パスに沿ったルーターは、セットアップを使用して、PATHメッセージに含まれるPORICYコントロールへの入力として、sender_tspecおよびPolicy_dataオブジェクトとともに優先順位を保持する場合があります。たとえば、トラフィックエンジニアリングアプリケーションでは、より低い優先度の予約を先取りする前に、パス全体に沿って帯域幅が特定の優先度に存在することを確認する手段としてパスメッセージを使用することが非常に便利です。リソースが不十分なときにパスメッセージが進行することが許可されている場合、このポイントの下流の優先予約が低いことは、この要求に応える無駄な試みで不必要に先制される危険があります。
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.
reblicit_routeオブジェクト（ERO）が存在する場合、EROによって指定されたパスに沿って、パスメッセージが宛先に向かって転送されます。パスに沿った各ノードは、パス状態ブロックにEROを記録します。ノードは、パスメッセージを転送する前に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に応答します。ラベルオブジェクトは、フィルター仕様の直後にフィルター仕様リストに挿入されます。
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].
ラベルオブジェクトを含むRESVメッセージを受信する各ノードは、このLSPトンネルに関連付けられた発信トラフィックにそのラベルを使用します。ノードが送信者ではない場合、新しいラベルを割り当て、RESVメッセージの対応するラベルオブジェクトにPHOPに送信するラベルを配置します。ラベルオブジェクトの上流に送信されるラベルは、このノードがこのLSPトンネルに関連する着信トラフィックを識別するために使用するラベルです。このラベルは、フィルター仕様の速記としても機能します。ノードは、「着信ラベルマップ」（ILM）を更新できるようになりました。これは、着信ラベルパケットを「次のホップラベル転送エントリ」（NHLFE）にマッピングするために使用されます。[2]を参照してください。
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].
このドキュメントは、予約の統合サービス要求の種類を制限しません。ただし、実装では、制御されたロードサービス[4]とNullサービス[16]をサポートする必要があります。
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.
WildCardフィルター（WF）予約スタイルを使用すると、すべての送信者にセッションの1つの共有予約が使用されます。リンクの総予約は、送信者の数に関係なく同じままです。
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.
セッションのすべての送信者向けに、単一のマルチポイントからポイントまでのラベルスイッチパスが作成されます。セッションシェアへの送信者のリンクでは、単一のラベル値がセッションに割り当てられます。送信者が1つしかない場合、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を使用して提供できます。Multipoint-to-Point LSPは、PATHメッセージがexplicit_Routeオブジェクトを運ばない場合、またはPATHメッセージに同一のexpricit_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.
さまざまな送信者からのパスメッセージはそれぞれ独自の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 Tunnel Rerouteが通常必要な別の重要なコンテキストは、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.
一般に、トラフィックを混乱させたり、テンネルの再ルーティングが進行中にネットワーク操作に悪影響を及ぼさないことが非常に望ましいです。この適応的でスムーズな再ルーティング要件には、古いLSPトンネルから古いLSPトンネルを引き裂く前に、新しいLSPトンネルを確立し、古いLSPトンネルからトラフィックをそこに移す必要があります。この概念は、「ブレイク前」と呼ばれます。古いLSPトンネルと新しいLSPトンネルは、共通のネットワークセグメントのリソースと互いに競合する可能性があるため、問題が発生する可能性があります。リソースの可用性に応じて、この競争により、新しいLSPトンネルが確立されないように入場制御を引き起こす可能性があります。RSVPを使用してLSPトンネルを確立する利点は、この問題を非常にエレガントに解決することです。
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トンネルが使用するリソースをリリースしないでください。これにより、入場制御が新しいLSPトンネルを拒否する可能性があるため、予約を2回カウントすべきではありません。
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.
TEトンネルの帯域幅を増やしたい場合、同様の状況が発生する可能性があります。新しい予約は必要な全額ですが、必要な実際の割り当ては、新しい帯域幅と古い帯域幅の間のデルタのみです。中間ノードによってパスメッセージにポリシーが適用されている場合、帯域幅の多くを要求するパスメッセージが拒否されます。この状況では、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トンネルが共通のリンクに沿ってリソースを共有するということです。LSP_Tunnelセッションオブジェクトは、RSVPセッションの範囲を問題の特定のTEトンネルに狭めるために使用されます。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.
再ルートを実現するために、Ingressノードは新しいLSP IDを選択し、新しいsender_templateを形成します。イングレスノードは、新しいパスを定義する新しいEROを作成します。その後、ノードは、元のセッションオブジェクトと新しいsender_templateとEROを使用して新しいパスメッセージを送信します。古いLSPを使用して、古いパスメッセージを更新し続けています。共通していないリンクでは、新しいパスメッセージは従来の新しいLSPトンネルセットアップとして扱われます。共通して保持されているリンクでは、共有セッションオブジェクトとSEスタイルを使用すると、LSPを古いLSPと共有リソースを確立できます。Ingressノードが新しい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].
PATH MTU情報は、統合サービスまたはNULLサービスオブジェクトに存在するものに応じて伝達されます。統合サービスオブジェクトを使用する場合、[11]で定義されている手順に基づいてPATH MTUが提供されます。NULLサービスオブジェクトを使用する場合のPATH 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を使用すると、PATH MTU情報が送信者によって使用され、どのIPパケットがPATH MTUを超えているかを確認します。Path 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. このノードで追加されるラベルを含む、ラベルスタック内のバイト数（つまり、ラベルスタックエントリの4倍）とします。
2. Let M be the smaller of the "Maximum Initially Labeled IP Datagram Size" or of (Path MTU - N).
2. Mを「最初にラベル付けされたIPデータグラムサイズ」または（PATH MTU -N）の小さいものとします。
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
私。コードフィールド[12]を「断片化が必要とDFセット」に設定します。次のホップMTUフィールド[13]を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) Next-Hop Link MTUフィールド[14]を使用して、ICMPパケットを作成しすぎてMTUフィールド[14]
(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.
セッション、sender_template、およびfilter_spec、オブジェクトには、新しいCタイプも割り当てられています。
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とラベルオブジェクトは必須です。
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.
ラベルと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.
liblicit_route、label_request、およびsession_attributeオブジェクトの相対的な配置は、単なる推奨事項です。これらのオブジェクトの順序は重要ではないため、実装を任意の順序でオブジェクトを受け入れるように準備する必要があります。
The format of the Path message is as follows:
パスメッセージの形式は次のとおりです。
<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にバインドされています。各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 class = 16, C_Type = 1
ラベルクラス= 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.
ラベルの内容は、4オクテットでエンコードされた単一のラベルです。各汎用MPLSラベルは、0〜1048575の範囲の署名されていない整数です。一般的なMPLSラベルとFRラベルは、4オクテットで右にエンコードされています。ATMラベルは、ビット0-15で正当化されたVPI右およびビット16-31で正当化されたVCIでエンコードされます。
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-Type 2のlabel_requestオブジェクトのMbit、ATMラベル範囲のラベル要求は、この目的を果たします。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メッセージを送信する前に、割り当てられたラベルを運ぶパケットを転送する準備をする必要があります。ラベルオブジェクトは、予約状態ブロックに保持する必要があります。次に、RESVメッセージをフォーマットするために、次のRESVリフレッシュイベントで使用されます。
A node is expected to send a Resv message before its refresh timers expire if the contents of the LABEL object change.
ラベルオブジェクトの内容が変更された場合、リフレッシュタイマーが期限切れになる前に、ノードは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人の送信者に割り当てました
2. The implicit null label was assigned, but the node is not capable of doing a penultimate pop for the associated L3PID
2. 暗黙のヌルラベルが割り当てられましたが、ノードは関連するL3PIDに対して最後から2番目のポップを行うことができません
3. The assigned label is outside the requested label range
3. 割り当てられたラベルは、要求されたラベル範囲の外側です
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.
通常の状況では、ノードは、対応するパスメッセージにlabel_requestオブジェクトを含めていない限り、RESVメッセージにラベルオブジェクトを受信しないでください。ただし、ラベルオブジェクトを認識しないRSVPルーターは、エラーコード「不明なオブジェクトクラス」をレシーバーに送信します。これにより、予約が失敗します。
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.
ラベル要求クラスは19です。現在、3つの可能なC_TYPESがあります。タイプ1は、ラベル範囲のないラベル要求です。タイプ2は、ATMラベルの範囲のラベル要求です。タイプ3は、フレームリレーラベル範囲のラベルリクエストです。label_requestオブジェクト形式を以下に示します。
Class = 19, C_Type = 1
class = 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
l3pid
an identifier of the layer 3 protocol using this path. Standard Ethertype values are used.
このパスを使用したレイヤー3プロトコルの識別子。標準のeterytype値が使用されます。
Class = 19, C_Type = 2
class = 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
l3pid
an identifier of the layer 3 protocol using this path. Standard Ethertype values are used.
このパスを使用したレイヤー3プロトコルの識別子。標準のeterytype値が使用されます。
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
class = 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
l3pid
an identifier of the layer 3 protocol using this path. Standard Ethertype values are used.
このパスを使用したレイヤー3プロトコルの識別子。標準のeterytype値が使用されます。
DLI
dli
DLCI Length Indicator. The number of bits in the DLCI. The following values are supported:
DLCI長インジケーター。DLCIのビット数。次の値がサポートされています。
Len DLCI bits
len dlciビット
0 10 2 23
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ビットフィールドは、発信スイッチでサポートされているデータリンク接続識別子（DLCIS）のブロックの下限を指定します。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ビットフィールドは、発信スイッチでサポートされているデータリンク接続識別子（DLCIS）のブロックの上限を指定します。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オブジェクトを使用してパスメッセージを作成します。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.
Path Refrequestメッセージには、Path_RequestがPath Stateブロックに保存する必要があります。パスメッセージが受信機に到達すると、label_requestオブジェクトの存在がレシーバーをトリガーし、ラベルを割り当て、対応するRESVメッセージのラベルオブジェクトにラベルを配置します。ラベルの範囲が指定されている場合、ラベルはその範囲から割り当てる必要があります。label_requestオブジェクトを受け入れるレシーバーには、そのパスメッセージに関連するRESVメッセージにラベルオブジェクトを含める必要があります。パスメッセージにlabel_requestオブジェクトが存在しなかった場合、ノードには、そのパスメッセージのセッションとPHOPのRESVメッセージにラベルオブジェクトを含めてはなりません。
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メッセージ内のラベルオブジェクトを受け入れ、正しく処理する準備ができている必要があります。
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オブジェクトを認識しますが、それをサポートできないノード（おそらくラベルの割り当ての失敗のため）は、エラーコード「ルーティング問題」とエラー値「MPLSラベル割り当て障害」を備えたPatherrを送信する必要があります。これには、ラベル範囲が指定されており、ラベルをその範囲から割り当てることができない場合が含まれます。
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オブジェクトを使用して各パスメッセージを受信して転送するノードは、受信したlabel_requestオブジェクトからl3pidを転送されたlabel_requestオブジェクトにコピーする必要があります。
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をサポートできない場合、エラーコード「ルーティング問題」とエラー値「サポートされていないL3PID」を備えたPatherrに送信する必要があります。これにより、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ルーターは、エラーコード「不明なオブジェクトクラス」を送信者に送信します。label_requestオブジェクトを認識しますが、C_Typeを認識しないRSVPルーターは、エラーコード「不明なオブジェクトC_Type」を送信者に送信します。これにより、パスセットアップが失敗します。送信者は、LSPを確立できないことを経営陣に通知し、Label_Requestなしで予約を継続するために行動を起こす可能性があります。
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オブジェクトを宣伝してはなりません。ルーターは、エラーコード「ルーティング問題」とエラー値「MPLS」がネゴシエートされている場合、Patherrを送信者に送り返す必要がありますが、RSVPではないルーターがパスに立っています。」Routerが非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: Class = 20, C_Type = 1
明示的なルートは、rebricit_routeオブジェクト（ERO）を介して指定されます。明示的なルートクラスは20です。現在、1つのC_TYPEが定義されており、タイプ1の明示的ルートが定義されています。liblicit_routeオブジェクトには次の形式があります：class = 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.
liblicit_routeオブジェクトの内容は、Subobjectsと呼ばれる一連の可変長データ項目です。サブオブジェクトは、以下のセクション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.
パスメッセージに複数の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とliblicit_routeオブジェクトをサポートする場合にのみ使用されます。rebricit_routeオブジェクトには、フォーム0bbbbbbbbのクラス値が割り当てられます。したがって、オブジェクトをサポートしない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.
ディスカッションを正式にするために、ノードの各グループを抽象ノードと呼びます。したがって、明示的なルートは、移動する抽象ノードのセットの仕様であると言います。抽象ノードが1つのノードのみで構成されている場合、単純な抽象ノードと呼びます。
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:
liblicit_routeオブジェクトの内容は、Subobjectsと呼ばれる一連の可変長データ項目です。各サブオブジェクトにはフォームがあります。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+
|L| Type | Length | (Subobject contents) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+
L
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
1 IPv4プレフィックス2 IPv6プレフィックス32自律システム番号
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.
厳密なノードとその前のノードの間のパスには、Strictノードとその前の抽象ノードのネットワークノードのみを含める必要があります。
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
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プレフィックスSubObobjectの内容は、4-OCTET IPv4アドレス、1-OCTETプレフィックスの長さ、および1-OCTETパッドです。このサブオブジェクトで表される要約ノードは、このプレフィックス内にある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
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プレフィックスSubobjectの内容は、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）番号サブオブジェクトは、数として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オブジェクトを含むパスメッセージを受信するノードは、このパスの次のホップを決定する必要があります。これは、明示的なルートに沿った次の抽象ノードが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メッセージを受信するノードは、最初に最初のサブオブジェクトを評価する必要があります。ノードが最初のサブオブジェクトで説明されている抽象ノードの一部でない場合、メッセージが誤って受信され、「悪い初期サブオブジェクト」エラーを返す必要があります。最初のサブオブジェクトがない場合、メッセージも誤っており、システムは「bad rebricit_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) 2番目のサブオブジェクトがない場合、これは明示的なルートの終了を示します。explicit_routeオブジェクトは、パスメッセージから削除する必要があります。このノードは、パスの終わりである場合とそうでない場合があります。セクション4.3.4.2で処理が続き、新しいriblicit_routeオブジェクトがパスメッセージに追加される場合があります。
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で処理を続けます。これにより、次の反復の最初のサブオブジェクトに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番目のサブオブジェクトで記述された抽象ノードに隣接するかどうかを決定します。その場合、ノードは抽象ノードのメンバーである特定の次のホップを選択します。次に、ノードは最初のサブオブジェクトを削除し、セクション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番目のサブオブジェクトの抽象ノード（次の抽象ノード）へのパスに沿っている最初のサブオブジェクト（ノードが属する）の抽象ノード内の次のホップを選択します）。そのようなパスが存在しない場合、2つのケースがあります。
5a) If the second subobject is a strict subobject, there is an error and the node SHOULD return a "Bad strict node" error.
5a）2番目のサブオブジェクトが厳密なサブオブジェクトである場合、エラーがあり、ノードは「悪い厳格なノード」エラーを返す必要があります。
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.
5b）それ以外の場合、2番目のサブオブジェクトが緩いサブオブジェクトの場合、ノードは次の抽象ノードへのパスに沿っている次のホップを選択します。パスが存在しない場合、エラーがあり、ノードは「緩いノード」エラーを返す必要があります。
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オブジェクトが削除され、ノードは新しいribsit_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処理中に認識されていないサブオブジェクトに遭遇するノードは、エラーコード「ルーティングエラー」と「悪い明示的ルートオブジェクト」のエラー値を送信者に送信します。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.
reblitity_routeオブジェクトを認識しないRSVPルーターは、エラーコード「不明なオブジェクトクラス」を送信者に送信します。これにより、パスセットアップが失敗します。送信者は、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）を介して記録できます。オプションで、ラベルも記録される場合があります。レコードルートクラスは21です。現在、1つのC_TYPEが定義されており、タイプ1のレコードルートが定義されています。Record_Routeオブジェクトには、次の形式があります。
Class = 21, C_Type = 1
class = 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オブジェクトの内容は、Subobjectsと呼ばれる一連の可変長データ項目です。サブオブジェクトは、以下のセクション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メッセージの両方に存在する可能性があります。パスメッセージに複数のRROが含まれている場合、最初のRROのみが意味があります。後続のRROは無視されるべきであり、伝播しないでください。同様に、RESVメッセージで別のfilter_specが遭遇する前にfilter_specに続いて複数のrrosが遭遇した場合、最初のRROのみが意味があります。後続のRROは無視されるべきであり、伝播しないでください。
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オブジェクトの内容は、Subobjectsと呼ばれる一連の可変長データ項目です。各サブオブジェクトには独自の長さフィールドがあります。長さには、タイプと長さのフィールドを含む、バイト内のサブオブジェクトの全長が含まれます。長さは常に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.
サブオブジェクトのない空の部屋は違法と見なされます。
Three kinds of subobjects are currently defined.
現在、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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
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.
このノードの下流のリンクがローカル修理メカニズムを介して保護されていることを示します。このフラグは、対応するパスメッセージのsession_attributeオブジェクトにローカル保護フラグが設定された場合にのみ設定できます。
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
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.
このノードの下流のリンクがローカル修理メカニズムを介して保護されていることを示します。このフラグは、対応するパスメッセージのsession_attributeオブジェクトにローカル保護フラグが設定された場合にのみ設定できます。
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.
0x01 =グローバルラベルこのフラグは、インターフェイスで受信した場合にラベルが理解されることを示しています。
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の3つの用途があります。まず、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".
第三に、RRO構文は、わずかな変更で、オブジェクト全体をliblicit_routeオブジェクトへの入力として使用できるように設計されています。これは、送信者がRESVメッセージで受信機からRROを受信し、「セッションパスを固定する」ために次のパスメッセージで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.
通常、ノードはRROをパスメッセージに追加してRSVPセッションを開始します。最初のRROには、1つのサブオブジェクトのみが含まれています - 送信者のIPアドレス。ノードがラベルの録音も希望する場合、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を含むパスメッセージが中間ルーターによって受信されると、ルーターはパス状態ブロックにそのコピーを保存します。RROは、パスメッセージをフォーマットするために次のパスリフレッシュイベントで使用されます。新しいパスメッセージを送信すると、ルーターはRROに新しいサブオブジェクトを追加し、送信前に結果の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アドレスでなければなりません。追加するアドレスは、発信パスメッセージのインターフェイスアドレスである必要があります。選択する複数のアドレスがある場合、決定はローカルな問題です。ただし、同じアドレスを一貫して選択することをお勧めします。
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.
初期パスメッセージを受信すると、ノードに含まれるラベルがある可能性は低いことに注意してください。ラベルが取得されたら、ノードには、次のパスリフレッシュイベントで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 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".
新しく追加されたサブオブジェクトがRROをパス（またはRESV）メッセージに収めるには大きすぎる場合、RROオブジェクトはメッセージから削除され、メッセージ処理は通常どおり継続します。patherr（またはresverr）メッセージは、送信者（または受信者）に返送する必要があります。「NOTIFY」のエラーコードと「MTUには大きすぎるRRO」のエラー値が使用されています。受信者がそのようなResverrを受信した場合、「通知」のエラーコードと「RRO通知」のエラー値を使用してPatherRメッセージを送信する必要があります。
A sender receiving either of these error values SHOULD remove the RRO from the Path message.
これらのエラー値のいずれかを受信する送信者は、パスメッセージから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メッセージの更新間隔が大きいところです。ノードは、送信されるメッセージの数を制限するために制限および/またはバックオフタイマーを適用する場合があります。
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ルーターは、次のパスメッセージのRROが前のものとは異なる場合、更新時間の前にパスメッセージを送信することを決定できます。これは、以前のホップルーターから受信したRROの内容が変更された場合、またはこのRROがパスメッセージに新しく追加された（または削除された）場合に発生する可能性があります。
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を使用してパスメッセージを受信すると、これは送信者ノードにルート録音が必要であることを示します。宛先ノードは、RROへのRROメッセージを追加することにより、RROプロセスを開始します。処理はパスメッセージのそれを反映しています。唯一の違いは、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のない受信したパスメッセージは、送信者ノードがルート録画を録音する必要がなくなったことを示します。後続の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.
下流のノードがパスメッセージを受信するか、上流のノードが含まれている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.
転送ループには2つの広範な分類があります。最初のクラスは過渡ループです。これは、L3ルーティングがすべての目的地の一貫した転送パスに収束しようとするため、操作の通常の部分として発生します。転送ループの2番目のクラスは永続的なループであり、通常はネットワークの誤った構成に起因します。
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.
転送ループを含むパスメッセージの場合、ルーターは「ルーティングの問題」PATHERRメッセージを構築および送信し、エラー値「ループが検出されました」とパスメッセージをドロップします。ループが削除されるまで、このセッションはデータパケットの転送には適していません。ループがどのように排除されたかは、このドキュメントの範囲を超えています。
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オブジェクトには、フォーム0bbbbbbbbのクラス値が割り当てられます。したがって、オブジェクトをサポートしない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です。「Notify」エラーコードの値は25です。
The following defines error values for the Routing Problem Error Code:
以下は、ルーティング問題エラーコードのエラー値を定義します。
Value Error:
値エラー：
1 Bad EXPLICIT_ROUTE object
1つのBad reblicit_routeオブジェクト
2 Bad strict node
2つの悪い厳格なノード
3 Bad loose node
3悪いルーズノード
4 Bad initial subobject
4悪い初期サブオブジェクト
5 No route available toward destination
5目的地に向かって利用できるルートはありません
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つのMPLですが、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:
Notifyエラーコードの場合、エラー値フィールドの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.
セッション、sender_template、およびfilter_specオブジェクトには、新しいCタイプが定義されています。
The LSP_TUNNEL objects have the following format:
lsp_tunnelオブジェクトには、次の形式があります。
Class = SESSION, LSP_TUNNEL_IPv4 C-Type = 7
class = session、lsp_tunnel_ipv4 c-type = 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ビット識別子は、トンネルの存続期間中に一定のままです。通常、すべてのゼロに設定されています。イングレスエグレスペアにセッションの範囲を狭めたいと考えているイングレスノードは、ここにグローバルに一意の識別子としてIPv4アドレスを配置する可能性があります。
Class = SESSION, LSP_TUNNEL_IPv6 C_Type = 8
class = 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バイトの識別子は、トンネルの存続期間中に一定のままです。通常、すべてのゼロに設定されています。イングレスエグレスペアにセッションの範囲を狭めたいと考えているイングレスノードは、ここにグローバルに一意の識別子としてIPv6アドレスを配置する可能性があります。
Class = SENDER_TEMPLATE, LSP_TUNNEL_IPv4 C-Type = 7
class = sender_template、lsp_tunnel_ipv4 c-type = 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
class = 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
class =フィルター仕様、lsp_tunnel_ipv4 c-type = 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
class =フィルター仕様、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.
このセクションでは、リソースの予約を維持できるトンネルを設定する方法について説明します（再ルーティング中または帯域幅を増やそうとしている間に、二重カウントなし）。最初のパスメッセージでは、Ingressノードはセッションオブジェクトを形成し、Tunnel_IDを割り当て、IPv4アドレスをExtended_tunnel_idに配置します。また、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.
パスメッセージを受信すると、出力ノードは、イングレスノードに向かって明示的なスタイルを使用して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.
確立されたパスを持つイングレスノードがそのパスを変更したい場合、次のように新しいパスメッセージを形成します。既存のセッションオブジェクトが使用されます。特に、tunnel_idとextended_tunnel_idは変更されていません。Ingressノードは、新しいLSP_IDを選択して新しいSender_Templateを形成します。新しいルートのliblicit_routeオブジェクトを作成します。新しいパスメッセージが送信されます。Ingressノードは、古いパスメッセージと新しいパスメッセージの両方を再表示します。
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>
(Note that if the PHOPs are different, then two messages are sent each with the appropriate FILTER_SPEC and 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.
（PHOPが異なる場合、適切なFilter_Specとlabel_objectで2つのメッセージがそれぞれ送信されます。）Ingressノードが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です。2つのc_typesが定義されています。lsp_tunnel、c-type = 7およびlsp_tunnel_ra、c-type = 1はlsp_tunnel_ra c-typeにlsp_tunnel c-typeと同じフィールドが含まれます。さらに、リソースアフィニティ情報が搭載されています。フォーマットは次のとおりです。
SESSION_ATTRIBUTE class = 207, LSP_TUNNEL C-Type = 7
session_attribute class = 207、lsp_tunnel c-type = 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.
このフラグは、トンネルイングレスノードがこのトンネルを引き裂くことなく再ルーティングすることを選択できることを示しています。Tunnel Egressノードは、RESVメッセージで応答するときにSEスタイルを使用する必要があります。
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 class = 207、lsp_tunnel_ra 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Exclude-any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Include-any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Include-all |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Setup Prio | Holding Prio | Flags | Name Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Session Name (NULL padded display string) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Exclude-any
除外 - 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
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ビットベクトルは、そのいずれかを（このテストに関して）許容可能なリンクにします。nullセット（すべてのビットセットがゼロに設定）が自動的に通過します。
Include-all
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ビットベクトルは、（このテストに関して）リンクを受け入れるためにはすべて存在する必要があります。nullセット（すべてのビットセットがゼロに設定）が自動的に通過します。
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.
このフラグは、トンネルイングレスノードがこのトンネルを引き裂くことなく再ルーティングすることを選択できることを示しています。Tunnel Egressノードは、RESVメッセージで応答するときにSEスタイルを使用する必要があります。
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 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.
上記のように、先制は2つの優先順位によって実装されます。セットアップの優先順位は、リソースを取得するための優先事項です。保持の優先順位は、リソースを保持するための優先事項です。具体的には、保持優先度は、このセッションに割り当てられたリソースが予約される優先度です。セットアップの優先順位は、特定のセッションの保持優先度よりも高くなるべきではありません。
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]で定義されているように、セットアップと保持優先順位は、先制および防御の優先順位に直接類似しています。これら2つのオブジェクトの相互作用は最終的にポリシーの問題ですが、次のデフォルトの相互作用が推奨されます。
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-2）によって、先制優先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.
新しいパスメッセージが入場のために考慮される場合、要求された帯域幅は、セットアップの優先順位で指定された優先度で利用可能な帯域幅と比較されます。
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のエラーコード、入場制御障害、および0x0002のエラー値で返されます。エラー値の最初の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（）UpCallをローカルクライアントに引き起こし、理由を示すサブコードを通過します。コード「ポリシー管理の失敗」を備えた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オブジェクトのラベルレコーディングデザインフラグによって制御されます。ラベルSubobjectはすべてのアプリケーションに必要ではないため、自動的に記録されません。フラグにより、アプリケーションは必要なときにのみこれを要求できます。
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の倍数であり、少なくとも8でなければなりません。4の倍数ではないオブジェクトの長さの場合、オブジェクトには、後続のヌル文字がパッドが付けられています。名前の長さフィールドには、実際の文字列長が含まれています。
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]で説明されています。このドキュメントでは、後者の用語のブリーファー用語リソースアフィニティを使用します。リソースクラスは、リンクに関連付けられ、ルーティングプロトコルで宣伝される可能性があります。リソースクラスの親和性は、RSVPによって2つの方法で使用されます。検証するには、リンクは以下の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.
link-attrリンクに関連付けられた属性を表す32ビットベクトル。
The three tests are
3つのテストは次のとおりです
1. Exclude-any
1. 除外 - any
This test excludes a link from consideration if the link carries any of the attributes in the set.
このテストでは、リンクがセット内の属性のいずれかを伝えている場合、考慮事項からリンクを除外します。
(link-attr & exclude-any) == 0
（link-attr＆exclude-any）== 0
2. Include-any
2. include-any
This test accepts a link if the link carries any of the attributes in the set.
このテストは、リンクがセット内の属性のいずれかを伝える場合、リンクを受け入れます。
(include-any == 0) | ((link-attr & include-any) != 0)
3. Include-all
3. include-all
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)
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.
パスメッセージに複数の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 Hello Extensionを使用すると、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.
Hello Extensionは、一方の側がメカニズムを使用できるように特別に設計されていますが、反対側はメカニズムを使用できません。近隣の故障検出はいつでも開始される場合があります。これには、隣人が最初にお互いについて学ぶとき、または隣人が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 Extensionは、Helloメッセージ、Hello Requestオブジェクト、Hello ACKオブジェクトで構成されています。2つの近隣の間のこんにちは処理は、通常構成された障害検出間隔の独立した選択をサポートしています。各隣人は、Hello Requestオブジェクトを自律的に発行できます。各リクエストは謝辞によって回答されます。Helloメッセージには十分な情報が含まれているため、1人の隣人が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オブジェクトは、インスタンス値を投票して提供するメカニズムを提供します。投票リクエストには、送信者のインスタンス値も含まれます。これにより、世論調査の受信者は、オプションで世論調査を暗黙の世論調査の対応として扱うことができます。このオプションの取り扱いは、隣人が処理する投票と回答の総数を減らすことができる最適化です。すべての場合において、双方が最適化をサポートする場合、結果は障害検出間隔ごとに1セットの投票と回答のみになります。選択した間隔に応じて、最適化をサポートしている隣人が1人だけであっても、同じ利点が発生する可能性があります。
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.
こんにちはメッセージは常に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メッセージのMSGタイプ20は20です。Helloメッセージ形式は次のとおりです。
<Hello Message> ::= <Common Header> [ <INTEGRITY> ]
<HELLO>
The HELLO Class is 22. There are two C_Types defined.
ハロークラスは22です。2つのC_TYPESが定義されています。
Class = HELLO Class, C_Type = 1
class = hello class、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
class = hello class、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メッセージは完全にオプションです。すべてのメッセージは、Helloメッセージ処理に参加したくないノードによって無視される場合があります。このセクションの残高は、受信者と送信者が参加していると仮定して書かれています。特に、レシーバーに対する必須および必要の使用は、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_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.
hello requestオブジェクトを含むメッセージを生成する場合、送信者はsrc_instanceフィールドに入力して、近隣インスタンスごとの値を表す値に記入します。この値は、エージェントが対応する隣人とHellosを交換している間に変更してはなりません。送信者はまた、DST_INSTANCEフィールドに、近隣から最近受け取ったSRC_INSTANCE値を記入します。参照のために、この変数neighbor_src_instanceを呼び出します。隣人から値が受け取られていない場合、またはこのノードが隣人との通信が失われたと見なされた場合、neighbor_src_instanceはゼロ（0）に設定されます。メッセージの生成は、以前のhello_interval間隔内の宛先ノードからhello requestオブジェクトを受信したときに抑制する必要があります。
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 Requestオブジェクトを含むメッセージを受け取ったとき、受信者はHello ACKオブジェクトを含むハローメッセージを生成する必要があります。また、レシーバーは、隣人がリセットされていないことを確認する必要があります。これは、送信者の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.
Hello Requestオブジェクトの受信者は、隣人が受信者のインスタンス値を反映していることを確認する必要があります。これは、受信したDST_INSTANCEフィールドを、最近その近隣に送信したSRC_INSTANCE値とSRC_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.
hello 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.
Hello 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.
上記のように通信が失われたり、失われたりすると推定される場合、ノードはHellosを再挿入する可能性があります。ノードが再インチーブする場合、前の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.
前述のように、Hello Extensionは、リンク障害ごとではなくノード障害を検出することを目的としています。隣接するノード間に1つのリンクしかない場合、またはノードのペア間のすべてのリンクが故障した場合、ノードとリンク障害の区別は実際には意味がなく、そのような障害の取り扱いはすでにカバーされています。隣人の間で共有される複数のリンクがある場合、特別な考慮事項があります。隣人間のリンクに番号が付けられている場合、各リンクでHellosを実行する必要があり、前述のメカニズムが適用されます。
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.
リンクの数の場合、リンク障害検出は、Hellos以外の何らかの手段で提供する必要があります。各ノードは、隣人との単一のハローエクスチェンジを使用する必要があります。すべてのリンクが失敗した場合は、前のセクションで言及されているNOの受信価値ケースと同じです。
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.
Hello Extensionは、他の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 Extensionは完全に逆方向に互換性があります。helloクラスには、フォーム0bbbbbbbbのクラス値が割り当てられます。実装に応じて、拡張機能をサポートしない実装は、Helloメッセージを静かに破棄するか、「不明なオブジェクトクラス」エラーで応答します。どちらの場合でも、送信者は発行された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）のセッションオブジェクトを使用して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プロトコルパラメーターに値を割り当てます。現在のドキュメント内では、limplicit_routeオブジェクトとroute_recordオブジェクトが定義されています。これらの各オブジェクトにはサブオブジェクトが含まれています。このセクションでは、サブオブジェクト番号の割り当てに関するルールを定義します。このセクションでは、RFCSでIANAの考慮事項セクションを作成するためのBCP 26 "ガイドラインの用語を使用しています[15]。
EXPLICIT_ROUTE Subobject Type
liblicit_route subobjectタイプ
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.
Liblicit_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コンセンサスアクションを通じて割り当てられ、64〜95（0x40-0x5F）の範囲のコードが最初に提供されるように割り当てられます。96〜127（0x60-0x7F）の範囲のコードは、私的使用のために予約されています。
ROUTE_RECORD Subobject Type
route_record subobjectタイプ
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 subobjectタイプは、サブオブジェクトの関数を識別する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（0x00-0x7F）の範囲の範囲のサブオブジェクトタイプはIETFコンセンサスアクションを通じて割り当てられ、範囲128-191（0x80-0XBF）のコードが最初に提供されるように割り当てられます。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セッション
Class Types or C-Types:
クラスタイプまたはCタイプ：
7 LSP Tunnel IPv4 8 LSP Tunnel IPv6
7 LSPトンネルIPv4 8 LSPトンネルIPv6
10 FILTER_SPEC
10 filter_spec
Class Types or C-Types:
クラスタイプまたはCタイプ：
7 LSP Tunnel IPv4 8 LSP Tunnel IPv6
7 LSPトンネルIPv4 8 LSPトンネルIPv6
11 SENDER_TEMPLATE
11 sender_template
Class Types or C-Types:
クラスタイプまたはCタイプ：
7 LSP Tunnel IPv4 8 LSP Tunnel IPv6
7 LSPトンネルIPv4 8 LSPトンネルIPv6
16 RSVP_LABEL
16 rsvp_label
Class Types or C-Types:
クラスタイプまたはCタイプ：
1 Type 1 Label
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
ラベル範囲なし2 ATMラベル範囲3のフレームリレーラベル範囲の範囲3
20 EXPLICIT_ROUTE
20 liblicit_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型ルートレコード
22 HELLO
22こんにちは
Class Types or C-Types:
クラスタイプまたはCタイプ：
1 Request 2 Acknowledgment
1リクエスト2の確認
207 SESSION_ATTRIBUTE
207 session_attribute
Class Types or C-Types:
クラスタイプまたはCタイプ：
1 LSP_TUNNEL_RA 7 LSP Tunnel
1 lsp_tunnel_ra 7 lspトンネル
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 bad displicit_routeオブジェクト2悪い厳格ノード3悪いルースノードラベル割り当て障害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を使用したliblicit_routeオブジェクトのサブオブジェクト：
1 IPv4 prefix 2 IPv6 prefix 32 Autonomous system number
1 IPv4プレフィックス2 IPv6プレフィックス32自律システム番号
Subobjects of the RECORD_ROUTE object with C-Type 1:
cタイプ1を備えたrecord_routeオブジェクトのサブオブジェクト：
1 IPv4 address 2 IPv6 address 3 Label
1 IPv4アドレス2 IPv6アドレス3ラベル
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.
このドキュメントには、以前のインターネットドラフトに登場したテキストだけでなく、アイデアも含まれています。現在の文書の著者は、これらのドラフトの著者に感謝したいと考えています。彼らはスティーブン・ブレイク、ブルース・デイビー、ロック・ゲリン、サンジェイ・カマット、ヤコフ・レクター、エリック・ローゼン、アルン・ヴィスワナサンです。また、この文書に関するコメントについて、Bora Akyol、Yoram Bernet、Alex 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] Braden、R.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1、機能仕様」、RFC 2205、1997年9月。
[2] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[2] Rosen、E.、Viswanathan、A。and R. Callon、「Multiprotocol Label Switching Architecture」、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.、Malcolm、J.、Agogbua、J.、O'DellおよびJ. McManus、「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] Rosen、E.、Tappan、D.、Fedorkow、G.、Rekhter、Y.、Farinacci、D.、Li、T。およびA. Conta、「Mpls Label Stack Encoding」、RFC 3032、2001年1月。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[6] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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] Nichols、K.、Blake、S.、Baker、F。and D. Black、「IPv4およびIPv6ヘッダーの差別化されたサービスフィールド（DSフィールド）の定義」、RFC 2474、1998年12月。
[9] Herzog, S., "Signaled Preemption Priority Policy Element", RFC 2751, January 2000.
[9] Herzog、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.、Hannan、A。およびX. Xiao、「LSP-TunnelsのRSVPへの拡張の適用性ステートメント」、RFC 3210、2001年12月。
[11] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[11] Wroclawski、J。、「IETF統合サービスでのRSVPの使用」、RFC 2210、1997年9月。
[12] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[12] Postel、J。、「インターネットコントロールメッセージプロトコル」、STD 5、RFC 792、1981年9月。
[13] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, November 1990.
[13] Mogul、J。およびS. Deering、「Path MTU Discovery」、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] Conta、A。およびS. Deering、「インターネットプロトコルバージョン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.
[15] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[16] Bernet, Y., Smiht, A. and B. Davie, "Specification of the Null Service Type", RFC 2997, November 2000.
[16] Bernet、Y.、Smiht、A。およびB. Davie、「Nullサービスタイプの仕様」、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
Daniel O. Awduche Movaz Networks、Inc。7926 Jones Branch Drive、Suite 615 McLean、VA 22102 Voice：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
Lou Berger Movaz Networks、Inc。7926 Jones Branch Drive、Suite 615 McLean、VA 22102音声：1 703 847 1801メール：lberger@movaz.com
Der-Hwa Gan Juniper Networks, Inc. 385 Ravendale Drive Mountain View, CA 94043 EMail: dhg@juniper.net
Der-HWA Gan Juniper Networks、Inc。385 Ravendale Drive Mountain View、CA 94043メール：dhg@juniper.net
Tony Li Procket Networks 3910 Freedom Circle, Ste. 102A Santa Clara CA 95054 EMail: tli@procket.com
Tony Li Procket Networks 3910 Freedom Circle、Ste。102a Santa Clara CA 95054メール：tli@procket.com
Vijay Srinivasan Cosine Communications, Inc. 1200 Bridge Parkway Redwood City, CA 94065 Voice: +1 650 628 4892 EMail: vsriniva@cosinecom.com
Vijay Srinivasan Cosine Communications、Inc。1200 Bridge Parkway Redwood City、CA 94065音声：1 650 628 4892メール：vsriniva@cosinecom.com
George Swallow Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA 01824 Voice: +1 978 244 8143 EMail: swallow@cisco.com
George Swallow Cisco Systems、Inc。250 Apollo Drive Chelmsford、MA 01824 Voice：1 978 244 8143メール：swallow@cisco.com
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。