RFC3209 日本語訳
3209 RSVP-TE: Extensions to RSVP for LSP Tunnels. D. Awduche, L.Berger, D. Gan, T. Li, V. Srinivasan, G. Swallow. December 2001. (Format: TXT=132264 bytes) (Updated by RFC3936, RFC4420, RFC4874, RFC5151) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
Awducheがコメントのために要求するワーキンググループD.をネットワークでつないでください: 3209MovazはInc.カテゴリをネットワークでつなぎます: 規格はInc.2001年12月にL.バーガーD.ガン杜松ネットワークInc.T.李ProcketネットワークInc.V.Srinivasan CosineコミュニケーションInc.G.Swallowシスコシステムズを追跡します。
RSVP-TE: Extensions to RSVP for LSP Tunnels
RSVP-Te: LSP TunnelsのためのRSVPへの拡大
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
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.
このドキュメントはRSVP(リソース予約プロトコル)の使用について説明します、ラベルで切り換えられた経路(LSPs)をMPLS(マルチプロトコルLabel Switching)に証明するためにすべての必要な拡大を含んでいて。 LSPに沿った流れが経路のイングレスノードで適用されたラベルによって完全に特定されるので、これらの経路はトンネルとして扱われるかもしれません。 LSPトンネルの主要なアプリケーションは指定されるとしてのMPLSがRFC2702にある交通工学です。
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を使用することで明らかに発送されたラベルの設立に切り換えられた経路を許容して。 結果は自動的にネットワーク失敗、混雑、およびボトルネックから遠くに発送できるラベルの切り換えられたトンネルの具体化です。
Awduche, et al. Standards Track [Page 1] RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
Awduche、他 規格はTunnels2001年12月にLSPのためにRFC3209拡張子をRSVPに追跡します[1ページ]。
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
1つの序論… 3 1.1バックグラウンド… 4 1.2用語… 6 2概要… 7 2.1 LSP Tunnelsと設計されたトラフィックはトンネルを堀ります… 7 2.2 LSPの操作はトンネルを堀ります… 8 2.3 サービスは属します… 10 2.4 予約様式… 10 2.4 .1 フィルタ(ff)様式を修理します… 10 2.4 .2 ワイルドカードフィルタ(WF)様式… 11 2.4 .3 明白な(SE)様式を共有します… 11 交通ルートを変更する2.5はTunnelsを設計しました… 12 2.6 経路MTU… 13 3 LSP TunnelはMessage Formatsを関係づけました… 15 3.1経路メッセージ… 15 3.2Resvメッセージ… 16 4 LSP TunnelはObjectsを関係づけました… 17 4.1 オブジェクトをラベルしてください… 17 4.1 .1 Resvメッセージの取り扱いLabel Objects… 17 4.1 .2 ラベルオブジェクトの非サポート… 19 4.2 要求オブジェクトをラベルしてください… 19 4.2 .1 ラベル範囲なしで要求をラベルしてください… 19 4.2 .2 気圧ラベル範囲との要求をラベルしてください… 20 4.2 .3 ラベル範囲とフレームリレーとの要求をラベルしてください… 21 4.2 .4 ラベル_要求の取り扱い… 22 4.2 .5 ラベル要求オブジェクトの非サポート… 23 4.3の明白なルートオブジェクト… 23 4.3 .1の適用性… 24 4.3 .2 明白なルートオブジェクトの意味論… 24 4.3 .3Subobjects… 25 4.3 .4 明白なルートオブジェクトの処理… 28 4.3 .5 輪にします… 30 4.3 .6 互換性を進めてください… 30 4.3 .7 明白なルートオブジェクトの非サポート… 31 4.4 ルートオブジェクトを記録してください… 31 4.4 .1Subobjects… 31 4.4 .2の適用性… 34 4.4 .3 処理RRO… 35 4.4 .4 検出を輪にしてください… 36 4.4 .5 互換性を進めてください… 37 4.4 .6 RROの非サポート… 37 4.5 EROとRROのための誤りコード… 37 4.6個のセッション、送付者テンプレート、およびフィルタ仕様オブジェクト… 38 4.6 .1セッションオブジェクト… 39 4.6 .2送付者テンプレートオブジェクト… 40 4.6 .3 仕様オブジェクトをフィルターにかけてください… 42
Awduche, et al. Standards Track [Page 2] RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
Awduche、他 規格はTunnels2001年12月にLSPのためにRFC3209拡張子をRSVPに追跡します[2ページ]。
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
4.6.4 コースを変更してください。そうすれば、帯域幅は手順を増強します… 42 4.7セッション属性オブジェクト… 43 4.7 .1 リソースなしで親近感をフォーマットしてください… 43 4.7 .2 リソースで、親近感をフォーマットしてください… 45 4.7 両方のC-タイプに適用される.3の手順… 46 4.7 .4 リソース親近感手順… 48、5、こんにちは、拡大… 49、5.1、こんにちは、メッセージ・フォーマット… 50 5.2 HELLO Object形式… 51 5.2 .1 HELLO REQUESTは反対します… 51 5.2 .2 HELLO ACKは反対します… 51、5.3、こんにちは、メッセージ用法… 52 5.4 マルチリンク問題… 53 5.5の互換性… 54 6 セキュリティ問題… 54 7 IANA問題… 54 7.1 メッセージタイプ… 55 7.2 クラス番号とC-タイプ… 55 7.3 誤りコードとグローバルに定義された誤りは.577.4のサブコードSubobject定義を評価します… 57 8 知的所有権問題… 58 9つの承認… 58 10の参照箇所… 58 11人の作者のアドレス… 60 12の完全な著作権宣言文… 61
1. Introduction
1. 序論
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はLabel Switched Router(LSR)がそれらの間と、そして、それらを通してトラフィックを進めるのに使用されるラベルの意味について別のものに知らせる1セットの手順とラベル分配プロトコルを定義します。 MPLSアーキテクチャはただ一つのラベル分配プロトコルを仮定しません。 このドキュメントはラベルの切り換えられた経路(LSPs)をMPLSネットワークに設立するための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プロトコルは資源予約のあるなしにかかわらず明らかに発送されたLSPsの具体化をサポートします。 また、それはLSPs、先取り、および輪の検出について滑らかなコースを変更することをサポートします。
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
[3]で説明された「トラフィックトランクス」を運ぶのにRSVPと共に作成されたLSPsは使用できます。 密接に関係づけられた概念ですが、トラフィックトランクとトラフィックトランクを運ぶLSPは異なっています。 例えば、同じソースと目的地の間の2LSPsがただ一つのトラフィックトランクを運ぶために共有された負荷であるかもしれません。 逆に数個です。
Awduche, et al. Standards Track [Page 3] RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
Awduche、他 規格はTunnels2001年12月にLSPのためにRFC3209拡張子をRSVPに追跡します[3ページ]。
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].
例えば、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.
このドキュメント中では、議論はユニキャストのラベルの切り換えられた経路に制限されるでしょう。 マルチキャストLSPsはさらなる研究に残されます。
1.1. Background
1.1. バックグラウンド
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
RSVP[1]とMulti-プロトコルLabel Switching[2]の両方をサポートするホストとルータはRSVP流れにラベルを関連づけることができます。 MPLSとRSVPが結合しているとき、流れの定義をよりフレキシブルにすることができます。 ラベルがいったん切り替わると、経路(LSP)は確立されて、経路を通したトラフィックはLSPのイングレスノードで適用されたラベルによって定義されます。 多くの異なった評価基準を使用することでトラフィックへのラベルに関するマッピングを達成できます。 同じラベル値が特定のノードによって割り当てられるパケットのセットはそうです。
Awduche, et al. Standards Track [Page 4] RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
Awduche、他 規格はTunnels2001年12月にLSPのためにRFC3209拡張子をRSVPに追跡します[4ページ]。
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.
言われていて、同じ推進同値類(FEC)に属してください。([2])を見てください、そして、事実上、「RSVP流動」を定義してください。 トラフィックがこのようにラベルで切り換えられた経路に写像されるとき、私たちは、LSPを「LSPトンネル」と呼びます。 ラベルが交通の流れに関連しているとき、ルータがパケットのラベル値に基づくパケットのために適切な予約状態を特定するのは可能になります。
The signaling protocol model uses downstream-on-demand label distribution. A request to bind labels to a specific LSP tunnel is initiated by an ingress node through the RSVP Path message. For this purpose, the RSVP Path message is augmented with a LABEL_REQUEST object. Labels are allocated downstream and distributed (propagated upstream) by means of the RSVP Resv message. For this purpose, the RSVP Resv message is extended with a special LABEL object. The procedures for label allocation, distribution, binding, and stacking are described in subsequent sections of this document.
シグナリングプロトコルモデルは川下要求次第のラベル分配を使用します。 特定のLSPトンネルにラベルを縛るという要求はRSVP Pathメッセージを通してイングレスノードによって開始されます。 このために、RSVP PathメッセージはLABEL_REQUESTオブジェクトで増大します。 ラベルは、RSVP Resvメッセージによって川下に割り当てられて、分配されます(上流へ伝播されます)。 このために、RSVP Resvメッセージは特別なLABELオブジェクトで広げられます。 ラベル配分、分配、結合、および積み重ねのための手順はこのドキュメントのその後のセクションで説明されます。
The signaling protocol model also supports explicit routing capability. This is accomplished by incorporating a simple EXPLICIT_ROUTE object into RSVP Path messages. The EXPLICIT_ROUTE object encapsulates a concatenation of hops which constitutes the explicitly routed path. Using this object, the paths taken by label-switched RSVP-MPLS flows can be pre-determined, independent of conventional IP routing. The explicitly routed path can be administratively specified, or automatically computed by a suitable entity based on QoS and policy requirements, taking into consideration the prevailing network state. In general, path computation can be control-driven or data-driven. The mechanisms, processes, and algorithms used to compute explicitly routed paths are beyond the scope of this specification.
また、シグナリングプロトコルモデルは、明白なルーティングが能力であるとサポートします。 これは、簡単なEXPLICIT_ROUTEオブジェクトをRSVP Pathメッセージに組み入れることによって、達成されます。 EXPLICIT_ROUTEオブジェクトは明らかに発送された経路を構成するホップの連結をカプセル化します。 このオブジェクトを使用して、従来のIPルーティングの如何にかかわらずラベルで切り換えられたRSVP-MPLS流れによって取られた経路は予定できます。 明らかに発送された経路は、行政上指定しているか、または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つの役に立つ適用が交通工学です。 明らかに発送されたLSPsを使用して、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つの物理的なノードだけを含んでいるなら、抽象的なノードは簡単であると言われます。 抽象化のこの概念を使用して、IP接頭語の系列かAutonomous Systemsの系列として明らかに発送されたLSPは指定できます。
Awduche, et al. Standards Track [Page 5] RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
Awduche、他 規格はTunnels2001年12月にLSPのためにRFC3209拡張子をRSVPに追跡します[5ページ]。
The signaling protocol model supports the specification of an explicit path as a sequence of strict and loose routes. The combination of abstract nodes, and strict and loose routes significantly enhances the flexibility of path definitions.
シグナリングプロトコルモデルは厳しくてゆるいルートの系列として明白な経路の仕様をサポートします。 組み合わせ、ノードを抜粋してください。そうすれば、厳しくてゆるいルートは経路定義の柔軟性をかなり高めます。
An advantage of using RSVP to establish LSP tunnels is that it enables the allocation of resources along the path. For example, bandwidth can be allocated to an LSP tunnel using standard RSVP reservations and Integrated Services service classes [4].
LSPトンネルを確立するRSVPを使用する利点は経路に沿ってリソースの配分を可能にするということです。 例えば、標準のRSVPの予約とIntegrated Servicesサービスのクラス[4]を使用することでLSPトンネルに帯域幅を割り当てることができます。
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を例示できます。例えば、ベストエフォート型トラフィックを運ぶのに資源予約のないそのようなLSPsを使用できます。 また、他の多くの文脈でそれらを使用できます、欠点状態、などに後退と回復方針の実装を含んでいて。
1.2. Terminology
1.2. 用語
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [6].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは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
ラベルの切り換えられた経路
Awduche, et al. Standards Track [Page 6] RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
Awduche、他 規格はTunnels2001年12月にLSPのためにRFC3209拡張子をRSVPに追跡します[6ページ]。
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.
トラフィックトランクを運ぶ1LSPのTunnelsの1セット。
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].
トラフィックと呼ばれるLSPsのLSPかセットにそれらのサービスのクラスによって集められて、次に置かれた流れのセットはトンネルを設計しました。 さらなる議論に関しては、[3]を見てください。
2. Overview
2. 概要
2.1. LSP Tunnels and Traffic Engineered Tunnels
2.1. LSP Tunnelsとトラフィックの設計されたTunnels
According to [1], "RSVP defines a 'session' to be a data flow with a particular destination and transport-layer protocol." However, when RSVP and MPLS are combined, a flow or session can be defined with greater flexibility and generality. The ingress node of an LSP can use a variety of means to determine which packets are assigned a particular label. Once a label is assigned to a set of packets, the label effectively defines the "flow" through the LSP. We refer to such an LSP as an "LSP tunnel" because the traffic through it is opaque to intermediate nodes along the label switched path.
[1]によると、「RSVPは特定の目的地とトランスポート層プロトコルがあるデータフローになるように'セッション'を定義します」。 しかしながら、RSVPとMPLSが結合されているとき、より大きい柔軟性と一般性で流れかセッションを定義できます。 LSPのイングレスノードは特定のラベルがどのパケットに割り当てられるかを決定するさまざまな手段を使用できます。 ラベルがいったん1セットのパケットに割り当てられると、事実上、ラベルは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.
新しいRSVP SESSION(SENDER_TEMPLATE、およびFILTER_SPECオブジェクト)は、LSP_をTUNNEL_IPv4と呼びました、そして、LSP_TUNNEL_IPv6は、LSPトンネルの特徴をサポートするために定義されました。 ラベルの切り換えられた経路に沿ったノードの見解から、これらのオブジェクトの意味論はLSPトンネルに属すトラフィックが唯一PHOPから到着するパケットか「前のホップ」に基づいて特定されるということです。(特定のラベル値がこのノードによってセッションまで上流送付者に割り当てられている状態で、[1])を見てください。 事実上、オブジェクト名に現れるIPv4(v6)は、送付先アドレスがIPv4(v6)アドレスであることを指示するだけです。 一般的にこれらのオブジェクトについて言及するとき、私たちは資格を与える人LSP_TUNNELを使用します。
In some applications it is useful to associate sets of LSP tunnels. This can be useful during reroute operations or to spread a traffic trunk over multiple paths. In the traffic engineering application such sets are called traffic engineered tunnels (TE tunnels). To enable the identification and association of such LSP tunnels, two identifiers are carried. A tunnel ID is part of the SESSION object. The SESSION object uniquely defines a traffic engineered tunnel. The
使用目的によってはそれは、LSPトンネルのセットを関連づけるために役に立ちます。 これが役に立つ場合がある、複数の経路にわたって操作か普及にトラフィックトランクを別ルートで送ってください。 交通工学アプリケーションでは、そのようなセットはトラフィックの設計されたトンネル(TEトンネル)と呼ばれます。 そのようなLSPトンネルの識別と協会を可能にするために、2つの識別子が運ばれます。 トンネルIDはSESSIONオブジェクトの一部です。 SESSIONオブジェクトは唯一トラフィックの設計されたトンネルを定義します。 The
Awduche, et al. Standards Track [Page 7] RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
Awduche、他 規格はTunnels2001年12月にLSPのためにRFC3209拡張子をRSVPに追跡します[7ページ]。
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
SENDER_TEMPLATEとFILTER_SPECオブジェクトはLSP IDを運びます。 SESSIONオブジェクトに伴うSENDER_TEMPLATE(または、FILTER_SPEC)オブジェクトは唯一LSPトンネルを特定します。
2.2. Operation of LSP Tunnels
2.2. LSP Tunnelsの操作
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) LSPを設立する能力はQoS要件、(2)のあるなしにかかわらず確立したLSPトンネル、(3)が施政方針コントロールの下で(4) 確立したLSPトンネルによって横断された、実際のルート、特定する能力を観測して、(5) LSPトンネル、確立した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.
経路の最初のMPLSノード(すなわち、経路に関する送付者ノード)は、LSPトンネルを作成するために、LSP_TUNNEL_IPv4かLSP_TUNNEL_IPv6のセッションタイプでRSVP Pathメッセージを作成して、LABEL_REQUESTオブジェクトをPathメッセージに挿入します。 LABEL_REQUESTオブジェクトは、この経路で固まるラベルが要求されているのを示して、また、この経路の上まで運ばれることになっているネットワーク層プロトコルのしるしを供給します。 この理由はネットワーク層プロトコルがLSPをIPであると思うことができないで、より高い層のプロトコルがMPLSであると単に認識するL2ヘッダーから推論できないのを下に降ろしたということです。
If the sender node has knowledge of a route that has high likelihood of meeting the tunnel's QoS requirements, or that makes efficient use of network resources, or that satisfies some policy criteria, the node can decide to use the route for some or all of its sessions. To do this, the sender node adds an EXPLICIT_ROUTE object to the RSVP Path message. The EXPLICIT_ROUTE object specifies the route as a sequence of abstract nodes.
送付者ノードにトンネルのQoS必要条件を満たすという高い見込みを持っているか、ネットワーク資源の効率的な使用をするか、またはいくつかの方針評価基準を満たすルートに関する知識があるなら、ノードは、セッションのいくつかかすべてにルートを使用すると決めることができます。 これをするために、送付者ノードはEXPLICIT_ROUTEオブジェクトをRSVP Pathメッセージに追加します。 EXPLICIT_ROUTEオブジェクトは抽象的なノードの系列としてルートを指定します。
If, after a session has been successfully established, the sender node discovers a better route, the sender can dynamically reroute the session by simply changing the EXPLICIT_ROUTE object. If problems are encountered with an EXPLICIT_ROUTE object, either because it causes a routing loop or because some intermediate routers do not support it, the sender node is notified.
セッションが首尾よく確立された後に送付者ノードが、より良いルートを発見するなら、送付者は、単にEXPLICIT_ROUTEオブジェクトを変えることによって、ダイナミックにセッションを別ルートで送ることができます。 ルーティング輪を引き起こすか、またはいくつかの中間的ルータがそれをサポートしないので問題がEXPLICIT_ROUTEオブジェクトで行きあたられるなら、送付者ノードは通知されます。
By adding a RECORD_ROUTE object to the Path message, the sender node can receive information about the actual route that the LSP tunnel traverses. The sender node can also use this object to request
RECORD_ROUTEオブジェクトをPathメッセージに追加することによって、送付者ノードはLSPトンネルが横断する実際のルートの情報を受け取ることができます。 また、送付者ノードは要求するこのオブジェクトを使用できます。
Awduche, et al. Standards Track [Page 8] RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
Awduche、他 規格はTunnels2001年12月にLSPのためにRFC3209拡張子をRSVPに追跡します[8ページ]。
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オブジェクトは、経路ベクトルに類似していて、したがって、輪の検出に使用できます。
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.
最終的に、セッション識別と病気の特徴で支援するPathメッセージに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.
経路に沿ったルータは、DATAオブジェクトが方針コントロールに入力されるようにPathメッセージに含んだSENDER_TSPECとどんなPOLICY_と共にもセットアップを使用して、優位に立つかもしれません。 例えば、交通工学アプリケーションでは、どんな低優先度の予約も先取りする前にその帯域幅について確かめる手段が全体の経路に沿って特定の優先で存在するとき、Pathメッセージを使用するのは非常に役に立ちます。 不十分なリソースがあるとき、Pathメッセージが進歩をすることができるなら、このポイントの低優先度予約川下がこの要求を修理する空しい試みで不必要に先取りされるという危険があります。
When the EXPLICIT_ROUTE object (ERO) is present, the Path message is forwarded towards its destination along a path specified by the ERO. Each node along the path records the ERO in its path state block. Nodes may also modify the ERO before forwarding the Path message. In this case the modified ERO SHOULD be stored in the path state block in addition to the received ERO.
EXPLICIT_ROUTEオブジェクト(ERO)が存在しているとき、EROによって指定された経路に沿った目的地に向かってPathメッセージを転送します。 経路に沿った各ノードは経路州のブロックにEROを記録します。 また、Pathメッセージを転送する前に、ノードはEROを変更するかもしれません。 この場合、保存されたコネが容認されたEROに加えた経路州のブロックであったならERO SHOULDを変更しました。
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オブジェクトを含んでいることによって、LABEL_REQUESTに応じます。 すぐにそれが関係するフィルタ仕様に続いて、LABELオブジェクトはフィルタ仕様リストに挿入されます。
The Resv message is sent back upstream towards the sender, following the path state created by the Path message, in reverse order. Note that if the path state was created by use of an ERO, then the Resv message will follow the reverse path of the ERO.
Resvメッセージは上流へ送付者に向かって返送されます、Pathメッセージによって創設された経路州に続いて、逆順で。 経路州がEROの使用で創設されたならResvメッセージがEROの逆の経路に続くことに注意してください。
Each node that receives a Resv message containing a LABEL object uses that label for outgoing traffic associated with this LSP tunnel. If the node is not the sender, it allocates a new label and places that label in the corresponding LABEL object of the Resv message which it
LABELオブジェクトを含むResvメッセージを受け取る各ノードはこのLSPトンネルに関連している外向的なトラフィックにそのラベルを使用します。 ノードが送付者でないなら、新しいラベルとResvメッセージの対応するLABELオブジェクトをどれをラベルする場所を割り当てる、それ
Awduche, et al. Standards Track [Page 9] RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
Awduche、他 規格はTunnels2001年12月にLSPのためにRFC3209拡張子をRSVPに追跡します[9ページ]。
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].
上流へ、PHOPに送ります。 ラベルは、LABEL物がこのノードがこのLSPトンネルに関連している入って来る交通を特定するのに使用するラベルであることを上流へ送りました。 また、このラベルはFilter Specのための速記として機能します。 ノードは現在、(ILM)(「次のホップラベル推進エントリー」(NHLFE)にパケットとラベルされた入来を写像するのに使用される)が見る「入って来るラベル地図」[2]をアップデートできます。
When the Resv message propagates upstream to the sender node, a label-switched path is effectively established.
Resvメッセージが上流へ送付者ノードに伝播されるとき、事実上、ラベルで切り換えられた経路は確立されます。
2.3. Service Classes
2.3. サービスのクラス
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].
このドキュメントは予約を求めるIntegrated Service要求のタイプを制限しません。 しかしながら、実現SHOULDはControlled-負荷サービス[4]とNull Service[16]を支持します。
2.4. Reservation Styles
2.4. 予約様式
The receiver node can select from among a set of possible reservation styles for each session, and each RSVP session must have a particular style. Senders have no influence on the choice of reservation style. The receiver can choose different reservation styles for different LSPs.
受信機ノードは各セッションのために可能な予約のセットの中でスタイルから選び抜くことができます、そして、それぞれのRSVPセッションには、特定のスタイルがなければなりません。 送付者は予約スタイルの選択に影響を全く与えません。 受信機は異なったLSPsのための異なった予約スタイルを選ぶことができます。
An RSVP session can result in one or more LSPs, depending on the reservation style chosen.
RSVPセッションは1LSPsをもたらして、選ばれた予約スタイルに依存できます。
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]で予約スタイルの、より詳細な議論を見つけることができます。
2.4.1. Fixed Filter (FF) Style
2.4.1. 固定フィルタ(ff)様式
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.
Fixed Filter(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をもたらすことができます。
Awduche, et al. Standards Track [Page 10] RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
Awduche、他 規格はTunnels2001年12月にLSPのためにRFC3209拡張子をRSVPに追跡します[10ページ]。
2.4.2. Wildcard Filter (WF) Style
2.4.2. ワイルドカードフィルタ(WF)様式
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 Filter(WF)予約スタイルで、ただ一つの共有された予約はすべての送付者にセッションまで使用されます。 リンクの総予約は送付者の数にかかわらず同じままで残っています。
A single multipoint-to-point label-switched-path is created for all senders to the session. On links that senders to the session share, a single label value is allocated to the session. If there is only one sender, the LSP looks like a normal point-to-point connection. When multiple senders are present, a multipoint-to-point LSP (a reversed tree) is created.
多点からポイントへのラベルただ一つの切り換えられた経路はすべての送付者のためにセッションまで作成されます。 セッションまでの送付者が共有するリンクの上では、セッションまでただ一つのラベル値を割り当てます。 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の合併している規則のために、WFの予約と共にEXPLICIT_ROUTE物を使用できません。 交通工学への適用性のこの問題と不足の結果、WFの使用は本書では考えられません。
2.4.3. Shared Explicit (SE) Style
2.4.3. 共有された明白な(SE)様式
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.
Shared Explicit(SE)スタイルで、受信機は、予約に含まれるように明らかに送付者を指定できます。 リンクのすべての送付者のただ一つの記載された予約があります。 各送付者がResvメッセージに明らかに記載されているので、異なったラベルは異なった送付者に割り当てられるかもしれません、その結果、別々のLSPsを作成します。
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スタイルの予約は、多点からポイントを使用して、ラベルが経路を切り換えたか、そして、1送付者あたりLSPであるかもしれません。 経路メッセージがEXPLICIT_ROUTE物を運ばないか、またはPathメッセージに同じEXPLICIT_ROUTE物があると、多点からポイントへのLSPsは使用されるかもしれません。 これらのケースのどちらかでは、一般的なラベルは割り当てられるかもしれません。
Awduche, et al. Standards Track [Page 11] RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
Awduche、他 規格はTunnels2001年12月にLSPのためにRFC3209拡張子をRSVPに追跡します[11ページ]。
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物のための別々のLSPsを設立しなければなりません。
2.5. Rerouting Traffic Engineered Tunnels
2.5. 交通の設計されたTunnelsを別ルートで送ります。
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.
Traffic Engineeringのための要件の1つは多くの条件のもとで確立したTEトンネルを別ルートで送る能力です、施政方針に基づいて。 例えば、いくつかの文脈では、施政方針は、より「最適」のルートが利用可能になるとき、与えられたTEトンネルが別ルートで送られることになっていると決めるかもしれません。 トンネルが別ルートで送るTEが通常必要であるときに、TEトンネルの確立した経路に沿って別の重要な文脈はリソースの失敗にあります。 また、いくつかの方針の下では、失敗したリソースが現役に戻されるようになるとき、TEトンネルを元の経路に返すのも必要であるかもしれません。
In general, it is highly desirable not to disrupt traffic, or adversely impact network operations while TE tunnel rerouting is in progress. This adaptive and smooth rerouting requirement necessitates establishing a new LSP tunnel and transferring traffic from the old LSP tunnel onto it before tearing down the old LSP tunnel. This concept is called "make-before-break." A problem can arise because the old and new LSP tunnels might compete with each other for resources on network segments which they have in common. Depending on availability of resources, this competition can cause Admission Control to prevent the new LSP tunnel from being established. An advantage of using RSVP to establish LSP tunnels is that it solves this problem very elegantly.
一般に、交通を中断しないのが非常に望ましいか、またはTEトンネルのコースを変更することが進行している間、ネットワーク操作に逆に、影響を与えます。 この適応型の、そして、滑らかなコースを変更する要件は、古いLSPトンネルを取りこわす前に新しいLSPトンネルを確立して、交通を古いLSPトンネルからそれに移すのを必要とします。 この概念は「以前、開閉してください。」と呼ばれます。 古くて新しいLSPトンネルがそれらが共通であるネットワークセグメントに関するリソースのために互いと競争するかもしれないので、問題は起こることができます。 リソースの有用性によって、この競争相手はAdmission Controlに新しいLSPトンネルが確立されるのを防がせることができます。 LSPトンネルを確立するRSVPを使用する利点は非常に上品にこの問題を解決するということです。
To support make-before-break in a smooth fashion, it is necessary that on links that are common to the old and new LSPs, resources used by the old LSP tunnel should not be released before traffic is transitioned to the new LSP tunnel, and reservations should not be counted twice because this might cause Admission Control to reject the new LSP tunnel.
以前滑らかなファッションでサポートに開閉しています、交通がある前に古くて新しいLSPsに共通のリンクでは古いLSPトンネルのそばの運用資金をリリースするべきでないのが新しいLSPトンネルに移行して、Admission Controlがこれで新しいLSPトンネルを拒絶するかもしれないので二度予約を数えないのが必要です。
A similar situation can arise when one wants to increase the bandwidth of a TE tunnel. The new reservation will be for the full amount needed, but the actual allocation needed is only the delta between the new and old bandwidth. If policy is being applied to PATH messages by intermediate nodes, then a PATH message requesting too much bandwidth will be rejected. In this situation simply increasing the bandwidth request without changing the SENDER_TEMPLATE, could result in a tunnel being torn down, depending upon local policy.
人がTEトンネルの帯域幅を増加させたがっているとき、同様の状況は起こることができます。 新しい予約は必要である全額のためにものになるでしょうが、必要である実際の唯一の配分は新しくて古い帯域幅の間のデルタです。 方針が中間的ノードによってPATHメッセージに適用することにされるのであると、あまりに多くの帯域幅を要求するPATHメッセージは拒絶されるでしょう。 SENDER_TEMPLATEを変えないで帯域幅要求を単に増加させるこの状況で、取りこわされるトンネルはもたらすことができました、ローカルの方針によって。
Awduche, et al. Standards Track [Page 12] RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
Awduche、他 規格はTunnels2001年12月にLSPのためにRFC3209拡張子をRSVPに追跡します[12ページ]。
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 SESSION物とSE予約スタイルの組み合わせは帯域幅とルーティングで自然にスムーズな移行を収容します。 考えは古くて新しいLSPトンネルがそれらが共通であるリンクに沿ってリソースを共有するということです。 LSP_TUNNEL SESSION物は、問題の特定のTEトンネルにRSVPセッションの範囲を狭くするのに使用されます。 唯一TEトンネルを特定するために、私たちはExtended Tunnel ID分野に置かれる送付先IPアドレス(トンネルの出口であるノードのアドレス)、Tunnel ID、およびトンネルイングレスノードのIPアドレスの組み合わせを使用します。
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.
操作を別ルートで送るか、または帯域幅で増加させてください、そして、トンネルイングレスは、2人の異なった送付者としてRSVPセッションまで現れる必要があります。 これは送付者_テンプレートとフィルタ_仕様物で運ばれる「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.
aに作用するように、コースを変更してください、イングレスノードは、新しいLSP IDを選んで、新しいSENDER_TEMPLATEを形成します。 そして、イングレスノードは、新しい経路を定義するために新しいEROを作成します。 その後、ノードは、オリジナルのSESSION物、新しいSENDER_TEMPLATE、およびEROを使用することで新しいPath Messageを送ります。 それは、古いLSPを使用して、古いPathメッセージをリフレッシュし続けています。 一般的で持たれていないリンクの上では、新しいPathメッセージは従来の新しいLSPトンネルセットアップとして扱われます。 一般的で持たれていたリンクの上では、共有されたSESSION物とSEスタイルで、LSPは、古いLSPとリソースを共有しながら、創業します。 イングレスノードがいったん新しいLSPへのResvメッセージを受け取ると、それはそれと古いLSPの下側への裂け目への変遷交通を受け取ることができます。
To effect a bandwidth-increase, a new Path Message with a new LSP_ID can be used to attempt a larger bandwidth reservation while the current LSP_ID continues to be refreshed to ensure that the reservation is not lost if the larger reservation fails.
帯域幅増加に作用するなら、現在のLSP_IDが、より大きい予約が失敗するなら予約が無くならないのを保証するためにリフレッシュされ続けている間、より大きい帯域幅の予約を試みるのに新しいLSP_IDがある新しいPath Messageを使用できます。
2.6. Path MTU
2.6. 経路MTU
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を通して設立されたLSPsに提供します。
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].
どれがIntegrated Servicesに存在しているか、そして、Null Service物によって、経路MTU情報は運ばれます。 Integrated Services物を使用するとき、[11]で定義された手順に基づいて経路MTUを提供します。 Null Service物を使用するとき、経路MTU識別は[16]で定義されます。
Awduche, et al. Standards Track [Page 13] RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
Awduche、他 規格はTunnels2001年12月にLSPのためにRFC3209拡張子をRSVPに追跡します[13ページ]。
With standard RSVP, the path MTU information is used by the sender to check which IP packets exceed the path MTU. For packets that exceed the path MTU, the sender either fragments the packets or, when the IP datagram has the "Don't Fragment" bit set, issues an ICMP destination unreachable message. This path MTU related handling is also required for LSPs established via RSVP.
標準のRSVPと共に、経路MTU情報は、どのIPパケットが経路MTUを超えているかをチェックするのに送付者によって使用されます。 IPデータグラムで「断片化しないでください」というビットを設定するとき、経路MTUを超えているパケットに関しては、送付者は、パケットを断片化するか、またはICMP送信不可能メッセージを発行します。 また、この経路のMTUの関連する取り扱いがRSVPを通して設立されたLSPsに必要です。
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 MUSTは以下のアルゴリズムを実行します:
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. このノードによって加えられるためにラベルを含んでいて、ラベルスタック(i.e、数の4倍のラベルスタックエントリー)でNがバイト数であることをさせてください。
2. Let M be the smaller of the "Maximum Initially Labeled IP Datagram
Size" or of (Path MTU - N).
2. または、「初めはラベルされた最大のIPデータグラムサイズ」でMが、より小さくしいさせてください、(経路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
i. 「断片化が必要であり、DFはセットしたこと」に(ii)Code分野[12]を設定してください、そして、Next-ホップMTU分野[13]をMに設定してください。
(c) If possible, transmit the ICMP Destination Unreachable
Message to the source of the of the discarded datagram.
(c) できれば、ICMP Destination Unreachable Messageをソースに伝えてください、捨てられたデータグラムについて。
When the size of an IPv6 datagram (without labels) exceeds the
value of M,
IPv6データグラム(ラベルのない)のサイズがMの値を超えていると
Awduche, et al. Standards Track [Page 14] RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
Awduche、他 規格はTunnels2001年12月にLSPのためにRFC3209拡張子をRSVPに追跡します[14ページ]。
(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) ICMP Packetを作成してください、また、Next-ホップリンクMTU分野[14]があるBig MessageはMにセットしました。
(c) If possible, transmit the ICMP Packet too Big Message to
the source of the of the discarded datagram.
(c) できれば、ICMP Packetも伝えてください、ソースへのBig Message、捨てられたデータグラムについて。
3. LSP Tunnel related Message Formats
3. LSP TunnelはMessage Formatsを関係づけました。
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
オブジェクト名Applicable RSVPメッセージ--------------- ------------------------ 明白な_ルート経路記録_ルート経路、Resvセッション_属性経路と_要求経路ラベルResvをラベルしてください。
New C-Types are also assigned for the SESSION, SENDER_TEMPLATE, and FILTER_SPEC, objects.
また、新しいC-タイプはSESSIONのために選任されて、SENDER_TEMPLATE、およびFILTER_SPECは反対します。
Detailed descriptions of the new objects are given in later sections. All new objects are OPTIONAL with respect to RSVP. An implementation can choose to support a subset of objects. However, the LABEL_REQUEST and LABEL objects are mandatory with respect to this specification.
後のセクションで新しい物の詳述を与えます。 すべての新しい物がRSVPに関するOPTIONALです。 実現は、物の部分集合をサポートするのを選ぶことができます。 しかしながら、LABEL_REQUESTとLABEL物はこの仕様に関して義務的です。
The LABEL and RECORD_ROUTE objects, are sender specific. In Resv messages they MUST appear after the associated FILTER_SPEC and prior to any subsequent FILTER_SPEC.
LABELとRECORD_ROUTE物は送付者特有です。 Resvメッセージでは、それらは関連FILTER_SPECの後とどんなその後のFILTER_SPECの前にも現れなければなりません。
The relative placement of EXPLICIT_ROUTE, LABEL_REQUEST, and SESSION_ATTRIBUTE objects is simply a recommendation. The ordering of these objects is not important, so an implementation MUST be prepared to accept objects in any order.
EXPLICIT_ROUTE、LABEL_REQUEST、およびSESSION_ATTRIBUTE物の相対的なプレースメントは単に推薦です。 これらの物の注文が重要でないので、物が順不同であると受け入れるように実現を準備しなければなりません。
3.1. Path Message
3.1. 経路メッセージ
The format of the Path message is as follows:
Pathメッセージの形式は以下の通りです:
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST>
[ <SESSION_ATTRIBUTE> ]
<経路メッセージ>:、:= <一般的なヘッダー>[<保全>]<><RSVP_ホップ><時間_セッションは>[<の明白な_ルート>]<ラベル_要求>を評価します。[<セッション_属性>]
Awduche, et al. Standards Track [Page 15] RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
Awduche、他 規格はTunnels2001年12月にLSPのためにRFC3209拡張子をRSVPに追跡します[15ページ]。
[ <POLICY_DATA> ... ]
<sender descriptor>
[<方針_データ>] <送付者記述子>。
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC> ]
[ <RECORD_ROUTE> ]
<送付者記述子>:、:= _<送付者_テンプレート><送付者TSPEC>[<ADSPEC>][<記録_ルート>]
3.2. Resv Message
3.2. Resvメッセージ
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>
<Resvメッセージ>:、:= <一般的なヘッダー>[<保全>]<><RSVP_ホップ><時間_セッションは>を評価します[<RESV_は>を確認します][<範囲>][<方針_データ>…]。 <様式><流れ記述子リスト>。
<flow descriptor list> ::= <FF flow descriptor list>
| <SE flow descriptor>
<流れ記述子リスト>:、:= <FF流れ記述子リスト>。| <SE流れ記述子>。
<FF flow descriptor list> ::= <FLOWSPEC> <FILTER_SPEC>
<LABEL> [ <RECORD_ROUTE> ]
| <FF flow descriptor list>
<FF flow descriptor>
<FF流れ記述子リスト>:、:= <FLOWSPEC><フィルタ_仕様><ラベル>[<記録_ルート>]| <FF流れ記述子リスト><FF流れ記述子>。
<FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> <LABEL>
[ <RECORD_ROUTE> ]
<FF流れ記述子>:、:= [<FLOWSPEC>]<フィルタ_仕様><ラベル>。[<記録_ルート>]
<SE flow descriptor> ::= <FLOWSPEC> <SE filter spec list>
<SE流れ記述子>:、:= <FLOWSPEC><SEフィルタ仕様リスト>。
<SE filter spec list> ::= <SE filter spec>
| <SE filter spec list> <SE filter spec>
<SEは仕様リスト>をフィルターにかけます:、:= <SEフィルタ仕様>。| <SEフィルタ仕様リスト><SEフィルタ仕様>。
<SE filter spec> ::= <FILTER_SPEC> <LABEL> [ <RECORD_ROUTE> ]
<SEは仕様>をフィルターにかけます:、:= <フィルタ_仕様><ラベル>。[<記録_ルート>]
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ですか? 1LABEL、そして/または、RECORD_ROUTEは各FILTER_SPECに続くかもしれません。
Awduche, et al. Standards Track [Page 16] RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
Awduche、他 規格はTunnels2001年12月にLSPのためにRFC3209拡張子をRSVPに追跡します[16ページ]。
4. LSP Tunnel related Objects
4. LSP TunnelはObjectsを関係づけました。
4.1. Label Object
4.1. ラベル物
Labels MAY be carried in Resv messages. For the FF and SE styles, a label is associated with each sender. The label for a sender MUST immediately follow the FILTER_SPEC for that sender in the Resv message.
ラベルはResvメッセージで運ばれるかもしれません。 FFとSEスタイルにおいて、ラベルは各送付者に関連しています。 送付者のためのラベルはすぐに、Resvメッセージのその送付者のためのFILTER_SPECに続かなければなりません。
The LABEL object has the following format:
LABEL物には、以下の形式があります:
LABEL class = 16, C_Type = 1
LABELのクラスは16、C_Type=1と等しいです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (top label) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (トップラベル) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The contents of a LABEL is a single label, encoded in 4 octets. Each generic MPLS label is an unsigned integer in the range 0 through 1048575. Generic MPLS labels and FR labels are encoded right aligned in 4 octets. ATM labels are encoded with the VPI right justified in bits 0-15 and the VCI right justified in bits 16-31.
LABELのコンテンツは4つの八重奏でコード化された単一のラベルです。 それぞれの一般的なMPLSラベルは0〜1048575に範囲の符号のない整数です。 一般的なMPLSラベルとFRラベルは4つの八重奏で並べられたコード化された権利です。 VPI権利がビット0-15で正当化されて、VCI権利がビット16-31で正当化されている状態で、ATMラベルはコード化されます。
4.1.1. Handling Label Objects in Resv messages
4.1.1. Resvメッセージの取り扱いLabel Objects
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メッセージに受け取られたラベルを異ならせると考えられます。
4.1.1.1. Downstream
4.1.1.1. 川下
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
また、ノードが同じラベル値を複数の送付者に割り当てたResvメッセージを受け取るなら、そのノードはそれらの同じ送付者、または、それらの送付者のどんな部分集合にもただ一つの値を割り当てるかもしれません。 注意
Awduche, et al. Standards Track [Page 17] RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
Awduche、他 規格はTunnels2001年12月にLSPのためにRFC3209拡張子をRSVPに追跡します[17ページ]。
that if a node intends to police individual senders to a session, it MUST assign unique labels to those senders.
それはノードであるならセッションまで個々の送付者を取り締まるつもりであり、それはユニークなラベルをそれらの送付者に割り当てなければなりません。
In the case of ATM, one further condition applies. Some ATM nodes are not capable of merging streams. These nodes MAY indicate this by setting a bit in the label request to zero. The M-bit in the LABEL_REQUEST object of C-Type 2, label request with ATM label range, serves this purpose. The M-bit SHOULD be set by nodes which are merge capable. If for any senders the M-bit is not set, the downstream node MUST assign unique labels to those senders.
ATMの場合では、さらなる1つの状態が適用されます。 いくつかのATMノードは流れを合併できません。これらのノードは、ラベル要求にゼロに少しセットすることによって、これを示すかもしれません。 C-タイプ2のLABEL_REQUEST物のM-ビット(ATMラベル範囲があるラベル要求)はこの目的に役立ちます。 マージであるノードによるセットができたなら、SHOULDに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.
いったんラベルを割り当てると、ノードは新しいLABEL物をフォーマットします。 そして、ノードはResvメッセージの一部として新しいLABEL物を前のホップに送ります。 ノードSHOULD、Resvメッセージを送る前に割り当てられたラベルを運びながらパケットを進めるように用意してください。 LABEL、SHOULDは保たれたコネが予約州Blockであったなら反対します。 次の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メッセージを送ると予想される、それ、タイマはLABEL物の変化のコンテンツであるなら期限が切れます。
4.1.1.2. Upstream
4.1.1.2. 上流
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.
ノードは送付者に関連している出発しているラベルとしてLABEL物で運ばれたラベルを使用します。 ルータは、このセッション/送付者の入って来るインタフェースまで新しいラベルを割り当てて、それを縛ります。 これはルータが前のホップへのメッセージを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のために終わりから二番目のポップスができません。
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メッセージを送ります。
Awduche, et al. Standards Track [Page 18] RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
Awduche、他 規格はTunnels2001年12月にLSPのためにRFC3209拡張子をRSVPに追跡します[18ページ]。
4.1.2. Non-support of the Label Object
4.1.2. ラベル物の非サポート
Under normal circumstances, a node should never receive a LABEL object in a Resv message unless it had included a LABEL_REQUEST object in the corresponding Path message. However, an RSVP router that does not recognize the LABEL object sends a ResvErr with the error code "Unknown object class" toward the receiver. This causes the reservation to fail.
通常の状況下で、対応するPathメッセージにLABEL_REQUEST物を含んでいない場合、ノードはResvメッセージでLABEL物を決して受けないでしょうに。 しかしながら、LABEL物を認識しないRSVPルータはエラーコード「未知の物のクラス」があるResvErrを受信機に向かって送ります。これは予約に失敗されます。
4.2. Label Request Object
4.2. ラベル要求物
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.
Label Request Classは19歳です。 現在、3可能なC_Typesがあります。 タイプ1はラベル範囲がなければLabel Requestです。 タイプ2はATMラベル範囲があるラベル要求です。 タイプ3はFrame Relayラベル範囲があるラベル要求です。 LABEL_REQUEST物の書式は以下に示されます。
4.2.1. Label Request without Label Range
4.2.1. ラベル範囲のないラベル要求
Class = 19, C_Type = 1
クラス=19、C_は=1をタイプします。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | L3PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。| 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のプロトコルに関する識別子。 標準のEthertype値は使用されています。
Awduche, et al. Standards Track [Page 19] RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
Awduche、他 規格はTunnels2001年12月にLSPのためにRFC3209拡張子をRSVPに追跡します[19ページ]。
4.2.2. Label Request with ATM Label Range
4.2.2. 気圧ラベル範囲とのラベル要求
Class = 19, C_Type = 2
クラス=19、C_は=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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。| L3PID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M| Res| 最小のVPI| 最小のVCI| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Res| 最大のVPI| 最大の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のプロトコルに関する識別子。 標準のEthertype値は使用されています。
M
M
Setting this bit to one indicates that the node is capable of
merging in the data plane
このビットを1つに設定するのは、ノードがデータ飛行機で合併できるのを示します。
Minimum VPI (12 bits)
最小のVPI(12ビット)
This 12 bit field specifies the lower bound of a block of
Virtual Path Identifiers that is supported on the originating
switch. If the VPI is less than 12-bits it MUST be right
justified in this field and preceding bits MUST be set to zero.
この12ビットの分野は由来しているスイッチの上に支持されるVirtual Path Identifiersの1ブロックの下界を指定します。 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ビットの分野は由来しているスイッチの上に支持されるVirtual Connection Identifiersの1ブロックの下界を指定します。 VCIがあまり16ビットでないなら、この分野でまさしく正当でなければなりません、そして、ビットに先行するのをゼロに設定しなければなりません。
Awduche, et al. Standards Track [Page 20] RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
Awduche、他 規格はTunnels2001年12月にLSPのためにRFC3209拡張子をRSVPに追跡します[20ページ]。
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ビットの分野は由来しているスイッチの上に支持されるVirtual Path Identifiersの1ブロックの上限を指定します。 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ビットの分野は起因するスイッチの上にサポートされるVirtual Connection Identifiersの1ブロックの上限を指定します。 VCIがあまり16ビットでないなら、この分野でまさしく正当でなければなりません、そして、ビットに先行するのをゼロに設定しなければなりません。
4.2.3. Label Request with Frame Relay Label Range
4.2.3. フレームリレーラベル範囲とのラベル要求
Class = 19, C_Type = 3
クラス=19、C_は=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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。| L3PID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。|DLI| 最小のDLCI| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。| 最大の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のプロトコルに関する識別子。 標準のEthertype値は使用されています。
DLI
DLI
DLCI Length Indicator. The number of bits in the DLCI. The
following values are supported:
DLCI長さのインディケータ。 DLCIのビットの数。 以下の値はサポートされます:
Len DLCI bits
レンDLCIビット
0 10
2 23
0 10 2 23
Awduche, et al. Standards Track [Page 21] RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
Awduche、他 規格はTunnels2001年12月にLSPのためにRFC3209拡張子をRSVPに追跡します[21ページ]。
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ビットの分野は起因するスイッチの上にサポートされるData Link Connection Identifiers(DLCIs)の1ブロックの下界を指定します。 DLCI MUST、この分野と未使用のビットで正当化された権利を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ビットの分野は起因するスイッチの上にサポートされるData Link Connection Identifiers(DLCIs)の1ブロックの上限を指定します。 DLCI MUST、この分野と未使用のビットで正当化された権利を0に設定しなければならないということになってください。
4.2.4. Handling of LABEL_REQUEST
4.2.4. ラベル_要求の取り扱い
To establish an LSP tunnel the sender creates a Path message with a LABEL_REQUEST object. The LABEL_REQUEST object indicates that a label binding for this path is requested and provides an indication of the network layer protocol that is to be carried over this path. This permits non-IP network layer protocols to be sent down an LSP. This information can also be useful in actual label allocation, because some reserved labels are protocol specific, see [5].
LSPトンネルを証明するために、送付者はLABEL_REQUESTオブジェクトでPathメッセージを作成します。 LABEL_REQUESTオブジェクトは、この経路で固まるラベルが要求されているのを示して、この経路の上まで運ばれることになっているネットワーク層プロトコルのしるしを供給します。 これは、非IPネットワーク層プロトコルがLSPの下側に送られることを許可します。 また、いくつかの予約されたラベルがプロトコル特有であるので、この情報も実際のラベル配分で役に立つ場合があって、[5]を見てください。
The LABEL_REQUEST SHOULD be stored in the Path State Block, so that Path refresh messages will also contain the LABEL_REQUEST object. When the Path message reaches the receiver, the presence of the LABEL_REQUEST object triggers the receiver to allocate a label and to place the label in the LABEL object for the corresponding Resv message. If a label range was specified, the label MUST be allocated from that range. A receiver that accepts a LABEL_REQUEST object MUST include a LABEL object in Resv messages pertaining to that Path message. If a LABEL_REQUEST object was not present in the Path message, a node MUST NOT include a LABEL object in a Resv message for that Path message's session and PHOP.
LABEL_REQUEST SHOULDがPath州Blockに保存されて、したがって、また、PathがメッセージをリフレッシュするのがLABEL_REQUESTオブジェクトを含むでしょう。 Pathメッセージが受信機に達すると、LABEL_REQUESTオブジェクトの存在はラベルを割り当てて、対応するResvメッセージのためにLABELオブジェクトにラベルを置く受信機の引き金となります。 ラベル範囲を指定したなら、その範囲からラベルを割り当てなければなりません。 そのPathメッセージに関して、LABEL_REQUESTオブジェクトを受け入れる受信機はResvメッセージにLABELオブジェクトを含まなければなりません。 LABEL_REQUESTオブジェクトがPathメッセージに存在していなかったなら、ノードはそのPathメッセージのセッションとPHOPへのResvメッセージにLABELオブジェクトを含んではいけません。
A node that sends a LABEL_REQUEST object MUST be ready to accept and correctly process a LABEL object in the corresponding Resv messages.
LABEL_REQUESTオブジェクトを送るノードは、受け入れて、対応するResvメッセージで正しくLABELオブジェクトを処理する準備ができているに違いありません。
A node that recognizes a LABEL_REQUEST object, but that is unable to support it (possibly because of a failure to allocate labels) SHOULD send a PathErr with the error code "Routing problem" and the error value "MPLS label allocation failure." This includes the case where a label range has been specified and a label cannot be allocated from that range.
しかし、LABEL_REQUESTオブジェクトを認識するノード、それは、それ(ことによるとラベルを割り当てないことによる)がSHOULDであるとサポートすることができません。エラーコード「ルート設定問題」と誤り値の「MPLSラベル割り振りの失敗」があるPathErrを送ってください。 これはラベル範囲を指定して、その範囲からラベルを割り当てることができないケースを含んでいます。
Awduche, et al. Standards Track [Page 22] RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
Awduche、他 規格はTunnels2001年12月にLSPのためにRFC3209拡張子をRSVPに追跡します[22ページ]。
A node which receives and forwards a Path message each with a LABEL_REQUEST object, MUST copy the L3PID from the received LABEL_REQUEST object to the forwarded LABEL_REQUEST object.
LABEL_REQUESTと共にそれぞれPathメッセージを受け取って、転送するノードは、反対して、容認されたLABEL_REQUESTオブジェクトから進められたLABEL_REQUESTオブジェクトまでL3PIDをコピーしなければなりません。
If the receiver cannot support the protocol L3PID, it SHOULD send a PathErr with the error code "Routing problem" and the error value "Unsupported L3PID." This causes the RSVP session to fail.
受信機であるならプロトコルがL3PIDであるとサポートすることができません、それ。SHOULDはエラーコード「ルート設定問題」と誤り値の「サポートされないL3PID」と共にPathErrを送ります。 これはRSVPセッションに失敗されます。
4.2.5. Non-support of the Label Request Object
4.2.5. ラベル要求オブジェクトの非サポート
An RSVP router that does not recognize the LABEL_REQUEST object sends a PathErr with the error code "Unknown object class" toward the sender. An RSVP router that recognizes the LABEL_REQUEST object but does not recognize the C_Type sends a PathErr with the error code "Unknown object C_Type" toward the sender. This causes the path setup to fail. The sender should notify management that a LSP cannot be established and possibly take action to continue the reservation without the LABEL_REQUEST.
LABEL_REQUESTオブジェクトを認識しないRSVPルータはエラーコード「未知のオブジェクトのクラス」があるPathErrを送付者に向かって送ります。 LABEL_REQUESTオブジェクトを認識しますが、C_Typeは認識しないRSVPルータがエラーコード「_未知のオブジェクトC Type」と共に送付者に向かってPathErrを送ります。 これは経路セットアップに失敗されます。 送付者は、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オブジェクトの広告を出してはいけないことを意味します。 ルータSHOULDはエラーコード「ルート設定問題」をもっている送付者への後部をPathErrに送って、「交渉されるMPLS、しかし、できるルータが経路に立てる非RSVP」を誤り値に送ります。 _この同じメッセージSHOULDを送って、ルータがLABELを受けるなら、REQUESTはメッセージで非RSVPのできるルータから反対します。 川下のルータがどう非RSVPルータの存在を決定できるかに関する記述のための[1]を見てください。
4.3. Explicit Route Object
4.3. 明白なルートオブジェクト
Explicit routes are specified via the EXPLICIT_ROUTE object (ERO). The Explicit Route Class is 20. Currently one C_Type is defined, Type 1 Explicit Route. The EXPLICIT_ROUTE object has the following format:
明白なルートはEXPLICIT_ROUTEオブジェクト(ERO)を通して指定されます。 Explicit Route Classは20歳です。 _Type1Explicit Route、現在の、1Cのときに、Typeは定義されます。 EXPLICIT_ROUTEオブジェクトには、以下の形式があります:
Awduche, et al. Standards Track [Page 23] RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
Awduche、他 規格はTunnels2001年12月にLSPのためにRFC3209拡張子をRSVPに追跡します[23ページ]。
Class = 20, C_Type = 1
クラス=20、C_は=1をタイプします。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
Subobjects
The contents of an EXPLICIT_ROUTE object are a series of variable- length data items called subobjects. The subobjects are defined in section 4.3.3 below.
EXPLICIT_ROUTEオブジェクトの内容は「副-オブジェクト」と呼ばれる一連の可変長さのデータ項目です。 「副-オブジェクト」はセクション4.3.3未満で定義されます。
If a Path message contains multiple EXPLICIT_ROUTE objects, only the first object is meaningful. Subsequent EXPLICIT_ROUTE objects MAY be ignored and SHOULD NOT be propagated.
Pathメッセージが複数のEXPLICIT_ROUTEオブジェクトを含んでいるなら、最初のオブジェクトだけが重要です。 _ROUTEが無視されるかもしれないのを反対させるその後のEXPLICITとSHOULD NOT、伝播されてください。
4.3.1. Applicability
4.3.1. 適用性
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.
明白なルートに沿ったすべてのルータがRSVPとEXPLICIT_ROUTEオブジェクトを支えるときだけ、EXPLICIT_ROUTEオブジェクトは使用されていることになっています。 フォーム0bbbbbbbの階級値はEXPLICIT_ROUTEオブジェクトに割り当てられます。 したがって、オブジェクトを支えないRSVPルータが「未知のオブジェクトのクラス」誤りで応じるでしょう。
4.3.2. Semantics of the Explicit Route Object
4.3.2. 明白なルートオブジェクトの意味論
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.
明白なルートは明白なルートに沿ってノードのグループのリストとして記述されています。 経路に沿って特定のノードを特定する能力に加えて、明白なルートは経路に沿って横断しなければならないノードのグループを特定できます。 この能力は明白なルートを求める要求を実現させる際にかなりの量の地方の柔軟性をルーティングシステムに許容します。 この能力で、明白なルートのジェネレータは経路の詳細の不完全な情報を持つことができます。
Awduche, et al. Standards Track [Page 24] RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
Awduche、他 規格はTunnels2001年12月にLSPのためにRFC3209拡張子をRSVPに追跡します[24ページ]。
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セットの抽象的なノードの仕様であると言います。 抽象的なノードが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.
抽象的なノードの概念に関する例と、唯一Autonomous System番号「副-オブジェクト」から成る明白なルートを考えてください。 各「副-オブジェクト」はグローバルなトポロジーのAutonomous Systemに対応しています。 この場合、各Autonomous Systemは抽象的なノードです、そして、明白なルートはそれぞれの指定されたAutonomous Systemsを含んでいる経路です。各Autonomous Systemの中に複数のホップがあるかもしれませんが、これらは明白なルートのためのソースノードに不透明です。
4.3.3. Subobjects
4.3.3. Subobjects
The contents of an EXPLICIT_ROUTE object are a series of variable- length data items called subobjects. Each subobject has the form:
EXPLICIT_ROUTEオブジェクトの内容は「副-オブジェクト」と呼ばれる一連の可変長さのデータ項目です。 各「副-オブジェクト」には、フォームがあります:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+
|L| Type | Length | (Subobject contents) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+ |L| タイプ| 長さ| (Subobjectコンテンツ) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+
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:
Typeは「副-オブジェクト」のコンテンツのタイプを示します。 現在定義された値は以下の通りです。
1 IPv4 prefix
2 IPv6 prefix
32 Autonomous system number
1 IPv4接頭語2IPv6接頭語32Autonomousシステム番号
Awduche, et al. Standards Track [Page 25] RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
Awduche、他 規格はTunnels2001年12月にLSPのためにRFC3209拡張子をRSVPに追跡します[25ページ]。
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.
LengthはL、Type、およびLength分野を含むバイトで表現される「副-オブジェクト」の全長を含んでいます。 Lengthは少なくとも4歳でなければならなく、4の倍数であるに違いありません。
4.3.3.1. Strict and Loose Subobjects
4.3.3.1. 厳しくてゆるいSubobjects
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ビットが設定されるなら、属性の値は'ゆるいです'。Otherwise、属性の値は'厳しいです'。Forの簡潔さ、私たちは「副-オブジェクト」属性の値が'ゆるい'ならそれが'ゆるい「副-オブジェクト」'であると言います。Otherwise、それは'厳しい「副-オブジェクト」'です。Further、私たちは厳しいかゆるい「副-オブジェクト」の抽象的なノードがそれぞれ厳しいノードであるかゆるいノードであると言います。 ゆるくて厳しいノードはいつも彼らの先の抽象的なノードに比例して解釈されます。
The path between a strict node and its preceding node MUST include only network nodes from the strict node and its preceding abstract node.
厳しいノードとその前のノードの間の経路は厳しいノードとその前の抽象的なノードからのネットワーク・ノードだけを含まなければなりません。
The path between a loose node and its preceding node MAY include other network nodes that are not part of the strict node or its preceding abstract node.
ゆるいノードとその前のノードの間の経路は厳しいノードかその前の抽象的なノードの一部でない他のネットワーク・ノードを含むかもしれません。
4.3.3.2. Subobject 1: IPv4 prefix
4.3.3.2. Subobject1: 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 | IPv4 address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address (continued) | Prefix Length | Resvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| タイプ| 長さ| IPv4アドレス(4バイト)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4アドレス(続けられています)| 接頭語の長さ| 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
0×01 IPv4アドレス
Awduche, et al. Standards Track [Page 26] RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
Awduche、他 規格はTunnels2001年12月にLSPのためにRFC3209拡張子をRSVPに追跡します[26ページ]。
Length
長さ
The Length contains the total length of the subobject in bytes,
including the Type and Length fields. The Length is always 8.
LengthはTypeとLength分野を含むバイトで表現される「副-オブジェクト」の全長を含んでいます。 いつもLengthは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アドレス。 このアドレスは以下で接頭語長さの価値に基づいた接頭語として扱われます。 接頭語を超えたビットはゼロにオンなセットがトランスミッションであったなら領収書とSHOULDで無視されます。
Prefix length
接頭語の長さ
Length in bits of the IPv4 prefix
IPv4接頭語のビットの長さ
Padding
詰め物
Zero on transmission. Ignored on receipt.
トランスミッションのゼロ。 領収書の上で無視されます。
The contents of an IPv4 prefix subobject are a 4-octet IPv4 address, a 1-octet prefix length, and a 1-octet pad. The abstract node represented by this subobject is the set of nodes that have an IP address which lies within this prefix. Note that a prefix length of 32 indicates a single IPv4 node.
IPv4接頭語「副-オブジェクト」の内容は、4八重奏のIPv4アドレスと、1八重奏の接頭語の長さと、1八重奏のパッドです。 この「副-オブジェクト」によって表された抽象的なノードはこの接頭語に属すIPアドレスを持っているノードのセットです。 32の接頭語の長さがただ一つのIPv4ノードを示すことに注意してください。
4.3.3.3. Subobject 2: IPv6 Prefix
4.3.3.3. Subobject2: IPv6接頭語
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| タイプ| 長さ| IPv6アドレス(16バイト)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6アドレス(続けられています)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6アドレス(続けられています)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6アドレス(続けられています)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6アドレス(続けられています)| 接頭語の長さ| 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ビットは設定されます。 ビットが設定されないなら、「副-オブジェクト」は明白なルートに厳しいホップを表します。
Awduche, et al. Standards Track [Page 27] RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
Awduche、他 規格はTunnels2001年12月にLSPのためにRFC3209拡張子をRSVPに追跡します[27ページ]。
Type
タイプ
0x02 IPv6 address
0×02 IPv6アドレス
Length
長さ
The Length contains the total length of the subobject in bytes,
including the Type and Length fields. The Length is always 20.
LengthはTypeとLength分野を含むバイトで表現される「副-オブジェクト」の全長を含んでいます。 いつもLengthは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アドレス。 このアドレスは以下で接頭語長さの価値に基づいた接頭語として扱われます。 接頭語を超えたビットはゼロにオンなセットがトランスミッションであったなら領収書とSHOULDで無視されます。
Prefix Length
接頭語の長さ
Length in bits of the IPv6 prefix.
IPv6接頭語のビットの長さ。
Padding
詰め物
Zero on transmission. Ignored on receipt.
トランスミッションのゼロ。 領収書の上で無視されます。
The contents of an IPv6 prefix subobject are a 16-octet IPv6 address, a 1-octet prefix length, and a 1-octet pad. The abstract node represented by this subobject is the set of nodes that have an IP address which lies within this prefix. Note that a prefix length of 128 indicates a single IPv6 node.
IPv6接頭語「副-オブジェクト」の内容は、16八重奏のIPv6アドレスと、1八重奏の接頭語の長さと、1八重奏のパッドです。 この「副-オブジェクト」によって表された抽象的なノードはこの接頭語に属すIPアドレスを持っているノードのセットです。 128の接頭語の長さがただ一つのIPv6ノードを示すことに注意してください。
4.3.3.4. Subobject 32: Autonomous System Number
4.3.3.4. Subobject32: 自律システム番号
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.
Autonomous System(AS)番号「副-オブジェクト」の内容は2八重奏AS番号です。 この「副-オブジェクト」によって表された抽象的なノードは自律システムに属すノードのセットです。
The length of the AS number subobject is 4 octets.
AS番号「副-オブジェクト」の長さは4つの八重奏です。
4.3.4. Processing of the Explicit Route Object
4.3.4. 明白なルートオブジェクトの処理
4.3.4.1. Selection of the Next Hop
4.3.4.1. 次のホップの選択
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
EXPLICIT_ROUTEオブジェクトを含むPathメッセージを受け取るノードは次のホップをこの経路に決定しなければなりません。 明白なルートに沿った次の抽象的なノードがIPサブネットかAutonomous Systemであるかもしれないので、これが必要です。 したがって、この次のホップの選択は1セットの可能な代替手段から決定にかかわるかもしれません。 評価基準は、可能な代替手段からの選択が実装に依存していて、また、ローカルの方針で影響を与えることができて、向こうで影響を与えられるように作るのに使用しました。
Awduche, et al. Standards Track [Page 28] RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
Awduche、他 規格はTunnels2001年12月にLSPのためにRFC3209拡張子をRSVPに追跡します[28ページ]。
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.
この仕様の範囲。 しかしながら、各ノードが無輪の経路を決定するベストエフォート型試みをすると思われます。 ローカルの方針でとても決定している経路はくつがえすことができることに注意してください。
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メッセージを受け取るノードは最初に、最初の「副-オブジェクト」を評価しなければなりません。 ノードが最初の「副-オブジェクト」によって説明された抽象的なノードの一部でないなら、メッセージを間違って受け取りました、そして、SHOULDは「悪い初期の「副-オブジェクト」」誤りを返します。 「副-オブジェクト」、また、1番目が全くなければ、メッセージも間違っています、そして、システムSHOULDは「悪いEXPLICIT_ROUTEオブジェクト」誤りを返します。
2) If there is no second subobject, this indicates the end of the
explicit route. The EXPLICIT_ROUTE object SHOULD be removed from
the Path message. This node may or may not be the end of the
path. Processing continues with section 4.3.4.2, where a new
EXPLICIT_ROUTE object MAY be added to the Path message.
2) 「副-オブジェクト」、2番目が全くなければ、これは明白なルートの端を示します。 EXPLICIT_ROUTEオブジェクトSHOULD、Pathメッセージから、取り除いてください。 このノードは経路の端であるかもしれません。 処理はセクション4.3.4で.2を続けています。そこでは、新しいEXPLICIT_ROUTEオブジェクトがPathメッセージに追加されるかもしれません。
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番目の「副-オブジェクト」が厳しい「副-オブジェクト」であるなら、誤りがあります、そして、ノードSHOULDは「悪い厳しいノード」誤りを返します。
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番目の「副-オブジェクト」がゆるい「副-オブジェクト」であるなら、ノードは経路に沿って次の抽象的なノードにはある次のいくつかのホップを選択します。 経路が全く存在していないなら、誤りがあります、そして、ノードSHOULDは「悪いゆるいノード」誤りを返します。
Awduche, et al. Standards Track [Page 29] RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
Awduche、他 規格はTunnels2001年12月にLSPのためにRFC3209拡張子をRSVPに追跡します[29ページ]。
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) 最終的に、ノードは最初の「副-オブジェクト」を次のホップを含む抽象的なノードを指示するどんな「副-オブジェクト」にも取り替えます。 これが、次のホップで明白なルートを受け取るとき、それを受け入れるくらい必要です。
4.3.4.2. Adding subobjects to the Explicit Route Object
4.3.4.2. Explicit Route Objectに「副-オブジェクト」を加えます。
After selecting a next hop, the node MAY alter the explicit route in the following ways.
次のホップを選択した後に、ノードは以下の方法で明白なルートを変更するかもしれません。
If, as part of executing the algorithm in section 4.3.4.1, the
アルゴリズムコネセクション4.3.4.1を実行する一部として
EXPLICIT_ROUTE object is removed, the node MAY add a new EXPLICIT_ROUTE object.
ノードは、EXPLICIT_ROUTEオブジェクトを取り除いて、新しいEXPLICIT_ROUTEオブジェクトを加えるかもしれません。
Otherwise, if the node is a member of the abstract node for the first subobject, a series of subobjects MAY be inserted before the first subobject or MAY replace the first subobject. Each subobject in this series MUST denote an abstract node that is a subset of the current abstract node.
さもなければ、ノードが最初の「副-オブジェクト」のための抽象的なノードの器官であるなら、一連の「副-オブジェクト」が、最初の「副-オブジェクト」の前に挿入されるか、または最初の「副-オブジェクト」を取り替えるかもしれません。 このシリーズにおける各「副-オブジェクト」は現在の抽象的なノードの部分集合である抽象的なノードを指示しなければなりません。
Alternately, if the first subobject is a loose subobject, an arbitrary series of subobjects MAY be inserted prior to the first subobject.
交互に、「副-オブジェクト」の任意のシリーズは最初の「副-オブジェクト」がゆるい「副-オブジェクト」であるなら、最初の「副-オブジェクト」の前に挿入されるかもしれません。
4.3.5. Loops
4.3.5. 輪
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オブジェクトは、詳細な経路情報を集めるのに使用されて、輪の検出と病気の特徴の役に立ちます。
4.3.6. Forward Compatibility
4.3.6. 下位互換
It is anticipated that new subobjects may be defined over time. A node which encounters an unrecognized subobject during its normal ERO processing sends a PathErr with the error code "Routing Error" and error value of "Bad Explicit Route Object" toward the sender. The EXPLICIT_ROUTE object is included, truncated (on the left) to the offending subobject. The presence of an unrecognized subobject which is not encountered in a node's ERO processing SHOULD be ignored. It is passed forward along with the rest of the remaining ERO stack.
新しい「副-オブジェクト」が時間がたつにつれて定義されるかもしれないと予期されます。 通常のERO処理の間に認識されていない「副-オブジェクト」に遭遇するノードは「悪い明白なルートオブジェクト」のエラーコード「ルート設定誤り」と誤り値があるPathErrを送付者に向かって送ります。 EXPLICIT_ROUTEオブジェクトは、怒っている「副-オブジェクト」に含まれていて、端が欠けています(左の)。 そうする認識されていない「副-オブジェクト」の存在はノードのEROで処理SHOULDに遭遇しませんでした。無視されます。 それは残っているEROスタックの残りと共に前方へパスされます。
Awduche, et al. Standards Track [Page 30] RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
Awduche、他 規格はTunnels2001年12月にLSPのためにRFC3209拡張子をRSVPに追跡します[30ページ]。
4.3.7. Non-support of the Explicit Route Object
4.3.7. 明白なルートオブジェクトの非サポート
An RSVP router that does not recognize the EXPLICIT_ROUTE object sends a PathErr with the error code "Unknown object class" toward the sender. This causes the path setup to fail. The sender should notify management that a LSP cannot be established and possibly take action to continue the reservation without the EXPLICIT_ROUTE or via a different explicit route.
EXPLICIT_ROUTEオブジェクトを認識しないRSVPルータはエラーコード「未知のオブジェクトのクラス」があるPathErrを送付者に向かって送ります。 これは経路セットアップに失敗されます。 送付者は、LSPを設立できないように管理に通知して、EXPLICIT_ROUTEなしで異なった明白なルートで予約を続けるためにことによると行動を取るべきです。
4.4. Record Route Object
4.4. 記録的なルートオブジェクト
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)を通してルートを記録できます。 また、任意に、ラベルは記録されるかもしれません。 Record Route Classは21歳です。 _Type1Record Route、現在の、1Cのときに、Typeは定義されます。 RECORD_ROUTEオブジェクトには、以下の形式があります:
Class = 21, C_Type = 1
クラス=21、C_は=1をタイプします。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
Subobjects
The contents of a RECORD_ROUTE object are a series of
variable-length data items called subobjects. The subobjects
are defined in section 4.4.1 below.
RECORD_ROUTEオブジェクトの内容は「副-オブジェクト」と呼ばれる一連の可変長のデータ項目です。 「副-オブジェクト」はセクション4.4.1未満で定義されます。
The RRO can be present in both RSVP Path and Resv messages. If a Path message contains multiple RROs, only the first RRO is meaningful. Subsequent RROs SHOULD be ignored and SHOULD NOT be propagated. Similarly, if in a Resv message multiple RROs are encountered following a FILTER_SPEC before another FILTER_SPEC is encountered, only the first RRO is meaningful. Subsequent RROs SHOULD be ignored and SHOULD NOT be propagated.
RROはRSVP PathとResvメッセージの両方に存在している場合があります。 Pathメッセージが複数のRROsを含んでいるなら、最初のRROだけが重要です。 その後のRROs SHOULD、無視されてください、SHOULD NOT、伝播されてください。 同様に、FILTER_SPECに続いて、別のFILTER_SPECが遭遇する前に複数のRROsがResvメッセージで遭遇するなら、最初のRROだけが重要です。 その後のRROs SHOULD、無視されてください、SHOULD NOT、伝播されてください。
4.4.1. Subobjects
4.4.1. Subobjects
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オブジェクトの内容は「副-オブジェクト」と呼ばれる一連の可変長のデータ項目です。 各「副-オブジェクト」には、それ自身のLength分野があります。 長さはTypeとLength分野を含むバイトで表現される「副-オブジェクト」の全長を含んでいます。 いつも長さは4、および少なくとも4の倍数であるに違いありません。
Awduche, et al. Standards Track [Page 31] RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
Awduche、他 規格はTunnels2001年12月にLSPのためにRFC3209拡張子をRSVPに追跡します[31ページ]。
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.
Subobjectsは最初に外の最終スタックとして組織化されます。 RROの始まりに比例した最初の「副-オブジェクト」は先端であると考えられます。 最後の「副-オブジェクト」は下部であると考えられます。 新しい「副-オブジェクト」が加えられるとき、それはいつも先端に加えられます。
An empty RRO with no subobjects is considered illegal.
「副-オブジェクト」のない空のRROは不法であると考えられます。
Three kinds of subobjects are currently defined.
3種類の「副-オブジェクト」は現在、定義されます。
4.4.1.1. Subobject 1: IPv4 address
4.4.1.1. Subobject1: 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | IPv4 address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address (continued) | Prefix Length | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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アドレス(4バイト)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4アドレス(続けられています)| 接頭語の長さ| 旗| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
0x01 IPv4 address
0×01 IPv4アドレス
Length
長さ
The Length contains the total length of the subobject in bytes,
including the Type and Length fields. The Length is always 8.
LengthはTypeとLength分野を含むバイトで表現される「副-オブジェクト」の全長を含んでいます。 いつもLengthは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ビットのユニキャスト、ホスト・アドレス。 どんなネットワーク届いているインターフェース・アドレスもここに許容されています。 不法入国者はあるループバックアドレスなどのようにSHOULD NOTを扱います。使用されます。
Prefix length
接頭語の長さ
32
32
Flags
旗
0x01 Local protection available
0×01 利用可能な地方の保護
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.
このノードのリンク川下が局部的修繕メカニズムで保護されるのを示します。 Local保護旗が対応するPathメッセージのSESSION_ATTRIBUTEオブジェクトに設定された場合にだけ、この旗を設定できます。
Awduche, et al. Standards Track [Page 32] RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
Awduche、他 規格はTunnels2001年12月にLSPのためにRFC3209拡張子をRSVPに追跡します[32ページ]。
0x02 Local protection in use
0×02 使用中の地方の保護
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).
局部的修繕メカニズムがこのトンネル(通常それが以前に発送されたリンクの供給停止に直面して)を維持するために使用中であることを示します。
4.4.1.2. Subobject 2: IPv6 address
4.4.1.2. Subobject2: IPv6アドレス
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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アドレス(16バイト)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6アドレス(続けられています)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6アドレス(続けられています)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6アドレス(続けられています)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6アドレス(続けられています)| 接頭語の長さ| 旗| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
0x02 IPv6 address
0×02 IPv6アドレス
Length
長さ
The Length contains the total length of the subobject in bytes,
including the Type and Length fields. The Length is always 20.
LengthはTypeとLength分野を含むバイトで表現される「副-オブジェクト」の全長を含んでいます。 いつもLengthは20歳です。
IPv6 address
IPv6アドレス
A 128-bit unicast host address.
128ビットのユニキャストホスト・アドレス。
Prefix length
接頭語の長さ
128
128
Flags
旗
0x01 Local protection available
0×01 利用可能な地方の保護
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.
このノードのリンク川下が局部的修繕メカニズムで保護されるのを示します。 Local保護旗が対応するPathメッセージのSESSION_ATTRIBUTEオブジェクトに設定された場合にだけ、この旗を設定できます。
Awduche, et al. Standards Track [Page 33] RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
Awduche、他 規格はTunnels2001年12月にLSPのためにRFC3209拡張子をRSVPに追跡します[33ページ]。
0x02 Local protection in use
0×02 使用中の地方の保護
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).
局部的修繕メカニズムがこのトンネル(通常それが以前に発送されたリンクの供給停止に直面して)を維持するために使用中であることを示します。
4.4.1.3. Subobject 3, Label
4.4.1.3. Subobject3、ラベル
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 旗| C-タイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ラベルオブジェクトのコンテンツ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
0x03 Label
0×03ラベル
Length
長さ
The Length contains the total length of the subobject in bytes,
including the Type and Length fields.
LengthはTypeとLength分野を含むバイトで表現される「副-オブジェクト」の全長を含んでいます。
Flags
旗
0x01 = Global label
This flag indicates that the label will be understood
if received on any interface.
0×01 グローバルなラベルThisが旗を揚げさせる=は、どんなインタフェースにも受け取るとラベルを理解するのを示します。
C-Type
C-タイプ
The C-Type of the included Label Object. Copied from the Label
Object.
含まれているLabel ObjectのC-タイプ。 ラベルオブジェクトから、コピーされます。
Contents of Label Object
ラベルオブジェクトのコンテンツ
The contents of the Label Object. Copied from the Label Object
Label Objectのコンテンツ。 ラベルオブジェクトから、コピーされます。
4.4.2. Applicability
4.4.2. 適用性
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.
RROの3つの可能な用途がRSVPにあります。 まず最初に、RROは、L3ルーティング輪、または明白なルートで固有の輪を発見するために輪の検出メカニズムとして機能できます。 そうするための正確な手順は後で本書では説明されます。
Awduche, et al. Standards Track [Page 34] RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
Awduche、他 規格はTunnels2001年12月にLSPのためにRFC3209拡張子をRSVPに追跡します[34ページ]。
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.
2番目に、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".
3番目に、RRO構文は、EXPLICIT_ROUTEオブジェクトに入力されるようにマイナーチェンジによる全体のオブジェクトを使用できるように設計されています。 送付者が「セッション経路を束縛する」ためにResvメッセージの受信機からRROを受け取って、ROUTEが次のPathメッセージで反対させるEXPLICIT_にそれを適用するなら、これは役に立ちます。
4.4.3. Processing RRO
4.4.3. 処理RRO
Typically, a node initiates an RSVP session by adding the RRO to the Path message. The initial RRO contains only one subobject - the sender's IP addresses. If the node also desires label recording, it sets the Label_Recording flag in the SESSION_ATTRIBUTE object.
通常、ノードは、PathメッセージにRROを追加することによって、RSVPセッションを開始します。 初期の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を含むPathメッセージを受け取るとき、ルータはPath州Blockにそれのコピーを保存します。 RROはそうであり、次のPathで使用されて、次に、形式Pathメッセージのためにイベントをリフレッシュしてください。 新しいPathメッセージが送ることであるときに、ルータは、新しい「副-オブジェクト」をRROに加えて、トランスミッションの前に結果として起こるRROをPathメッセージに追加します。
The newly added subobject MUST be this router's IP address. The address to be added SHOULD be the interface address of the outgoing Path messages. If there are multiple addresses to choose from, the decision is a local matter. However, it is RECOMMENDED that the same address be chosen consistently.
新たに加えられた「副-オブジェクト」はこのルータのIPアドレスであるに違いありません。 出発しているPathのインターフェース・アドレスがメッセージであったなら加えられたSHOULDであるアドレス。 選ぶ複数のアドレスがあれば、決定は地域にかかわる事柄です。 しかしながら、同じアドレスが一貫して選ばれているのは、RECOMMENDEDです。
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オブジェクトに設定されるとき、ルート録音SHOULDをするノードがLabel Record subobjectを含んでいます。 ノードであるなら、次に、グローバルなラベルスペースを使用するのは、それです。SHOULDはGlobal Label旗を設定します。
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アドレスを押す前に、Label Record subobjectはRECORD_ROUTEオブジェクトに押されます。 また、IPv4かIPv6 subobjectを押さないで、ノードはLabel Record subobjectを押してはいけません。
Note that on receipt of the initial Path message, a node is unlikely to have a label to include. Once a label is obtained, the node SHOULD include the label in the RRO in the next Path refresh event.
初期のPathメッセージを受け取り次第ノードが含んでいるラベルを持っていそうにないことに注意してください。 一度、ラベルを入手して、ノードSHOULDはRROにラベルを含んでいます。次のPathでは、イベントはリフレッシュしています。
If the newly added subobject causes the RRO to be too big to fit in a Path (or Resv) message, the RRO object SHALL be dropped from the message and message processing continues as normal. A PathErr (or
新たに加えられた「副-オブジェクト」が、RROが大き過ぎることを引き起こすなら、Path(または、Resv)メッセージ、RROオブジェクトSHALLをうまくはめ込むには、処理が標準として続けているメッセージとメッセージから、下げられてください。 またはPathErr、(。
Awduche, et al. Standards Track [Page 35] RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
Awduche、他 規格はTunnels2001年12月にLSPのためにRFC3209拡張子をRSVPに追跡します[35ページ]。
ResvErr) message SHOULD be sent back to the sender (or receiver). An error code of "Notify" and an error value of "RRO too large for MTU" is used. If the receiver receives such a ResvErr, it SHOULD send a PathErr message with error code of "Notify" and an error value of "RRO notification".
ResvErr) 送付者(または、受信機)に送り返された状態でSHOULDを通信させてください。 「通知してください」のエラーコードと「MTUには、大き過ぎるRRO」の誤り値は使用されています。 受信機はそのようなResvErrを受けます、それ。SHOULDは「通知」のエラーコードと「RRO通知」の誤り値があるPathErrメッセージを送ります。
A sender receiving either of these error values SHOULD remove the RRO from the Path message.
これらの誤り値のSHOULDのどちらかを受ける送付者はPathメッセージからRROを取り外します。
Nodes SHOULD resend the above PathErr or ResvErr message each n seconds where n is the greater of 15 and the refresh interval for the associated Path or RESV message. The node MAY apply limits and/or back-off timers to limit the number of messages sent.
そして、ノードSHOULDが各n秒単位で15でnが、よりすばらしいところに上のPathErrかResvErrメッセージを再送する、関連Pathか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ルータが、以前メッセージをPathに送ると決めることができる、それ、次のPathメッセージのRROが前のものと異なるなら、時間をリフレッシュしてください。 または、RROのコンテンツが前のホップルータ変化から受信されたか、または新たにこのRROに加えられるならこれが起こることができる、(削除される、)、Pathメッセージ。
When the destination node of an RSVP session receives a Path message with an RRO, this indicates that the sender node needs route recording. The destination node initiates the RRO process by adding an RRO to Resv messages. The processing mirrors that of the Path messages. The only difference is that the RRO in a Resv message records the path information in the reverse direction.
RSVPセッションの目的地ノードがRROと共にPathメッセージを受け取るとき、これは、送付者ノードがルート録音を必要とするのを示します。 目的地ノードは、ResvメッセージにRROを追加することによって、RROプロセスを開始します。 処理はPathメッセージのものを映します。 唯一の違いはResvメッセージのRROが経路情報を反対の方向に記録するということです。
Note that each node along the path will now have the complete route from source to destination. The Path RRO will have the route from the source to this node; the Resv RRO will have the route from this node to the destination. This is useful for network management.
経路に沿った各ノードにはソースから目的地まで完全なルートが現在あることに注意してください。 Path RROには、ソースからこのノードまでルートがあるでしょう。 Resv RROには、このノードから目的地までルートがあるでしょう。 これはネットワークマネージメントの役に立ちます。
A received Path message without an RRO indicates that the sender node no longer needs route recording. Subsequent Resv messages SHALL NOT contain an RRO.
RROのない受信されたPathメッセージは、送付者ノードがもうルート録音を必要としないのを示します。 その後のResvメッセージSHALL NOTはRROを含んでいます。
4.4.4. Loop Detection
4.4.4. 輪の検出
As part of processing an incoming RRO, an intermediate router looks into all subobjects contained within the RRO. If the router determines that it is already in the list, a forwarding loop exists.
入って来るRROを処理する一部として、中間的ルータはRROの中に含まれたすべての「副-オブジェクト」を調べます。 ルータが、それがリストに既にあることを決定するなら、推進輪は存在しています。
An RSVP session is loop-free if downstream nodes receive Path messages or upstream nodes receive Resv messages with no routing loops detected in the contained RRO.
川下のノードがPathメッセージを受け取るなら、RSVPセッションが輪なしです、または上流のノードは含まれたRROに検出されたルーティング輪なしでResvメッセージを受け取ります。
Awduche, et al. Standards Track [Page 36] RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
Awduche、他 規格はTunnels2001年12月にLSPのためにRFC3209拡張子をRSVPに追跡します[36ページ]。
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ルーティングとしての操作の標準の部分が一貫した推進経路にすべての目的地に集まろうとするとき、その輪は現れます)。 推進輪の二等は永久的な輪です。(通常、その輪はネットワークから誤構成で結果として生じます)。
The action performed by a node on receipt of an RRO depends on the message type in which the RRO is received.
RROを受け取り次第ノードによって実行された動作はRROが受け取られているメッセージタイプに頼っています。
For Path messages containing a forwarding loop, the router builds and sends a "Routing problem" PathErr message, with the error value "loop detected," and drops the Path message. Until the loop is eliminated, this session is not suitable for forwarding data packets. How the loop eliminated is beyond the scope of this document.
推進輪を含むPathメッセージに関しては、ルータは、「輪は検出した」誤り値と共に「ルート設定問題」PathErrメッセージを築き上げて、送って、Pathメッセージを下げます。 輪が排除されるまで、このセッションは推進データ・パケットに適当ではありません。 輪がどう排泄されたかはこのドキュメントの範囲を超えています。
For Resv messages containing a forwarding loop, the router simply drops the message. Resv messages should not loop if Path messages do not loop.
推進輪を含むResvメッセージに関しては、ルータは単にメッセージを下げます。 Pathメッセージが輪にされないなら、Resvメッセージは輪にされるべきではありません。
4.4.5. Forward Compatibility
4.4.5. 下位互換
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を処理するとき、認識されていないsubobjects SHOULDは無視されて、亡くなりました。 輪の検出のためにRROを処理するとき、SHOULDがどんな認識されていないオブジェクトの上にも分析するノードです。 輪の検出は、ノード自体によってオブジェクトの以前のパスに挿入された「副-オブジェクト」を検出することによって、働いています。 これは、輪の検出に必要な「副-オブジェクト」がいつも理解されているのを確実にします。
4.4.6. Non-support of RRO
4.4.6. 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.
経路に沿ったすべてのルータがRSVPとRROオブジェクトを支えるときだけ、RROオブジェクトは使用されていることになっています。 フォーム0bbbbbbbの階級値はRROオブジェクトに割り当てられます。 したがって、オブジェクトを支えないRSVPルータが「未知のオブジェクトのクラス」誤りで応じるでしょう。
4.5. Error Codes for ERO and RRO
4.5. EROとRROのためのエラーコード
In the processing described above, certain errors must be reported as either a "Routing Problem" or "Notify". The value of the "Routing Problem" error code is 24; the value of the "Notify" error code is 25.
上で説明された処理では、「ルート設定問題」か「通知してください」のどちらかとしてある誤りを報告しなければなりません。 「ルート設定問題」エラーコードの値は24です。 「通知してください」というエラーコードの値は25です。
Awduche, et al. Standards Track [Page 37] RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
Awduche、他 規格はTunnels2001年12月にLSPのためにRFC3209拡張子をRSVPに追跡します[37ページ]。
The following defines error values for the Routing Problem Error Code:
以下はルート設定Problem Error Codeのために誤り値を定義します:
Value Error:
誤りを評価してください:
1 Bad EXPLICIT_ROUTE object
1 悪いEXPLICIT_ROUTEは反対します。
2 Bad strict node
2の悪い厳しいノード
3 Bad loose node
3の悪いゆるいノード
4 Bad initial subobject
4 悪い初期の「副-オブジェクト」
5 No route available toward destination
5 目的地に向かって利用可能なルートがありません。
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
しかし、交渉される、8MPLS、経路のできる非RSVPルータスタンド
9 MPLS label allocation failure
9MPLSが失敗と配分をラベルします。
10 Unsupported L3PID
10 サポートされないL3PID
For the Notify Error Code, the 16 bits of the Error Value field are:
Notify Error Codeに関しては、Error Value分野の16ビットは以下の通りです。
ss00 cccc cccc cccc
ss00 cccc cccc cccc
The high order bits are as defined under Error Code 1. (See [1]).
高位のビットがError Code1の下で定義されるようにあります。 ([1])を見てください。
When ss = 00, the following subcodes are defined:
ss=00であるときに、以下の部分符号は定義されます:
1 RRO too large for MTU
1 MTUには、大き過ぎるRRO
2 RRO notification
2 RRO通知
3 Tunnel locally repaired
局所的に修理された3トンネル
4.6. Session, Sender Template, and Filter Spec Objects
4.6. セッション、送付者テンプレート、およびフィルタ仕様オブジェクト
New C-Types are defined for the SESSION, SENDER_TEMPLATE and FILTER_SPEC objects.
新しいC-タイプはSESSION、SENDER_TEMPLATE、およびFILTER_SPECオブジェクトのために定義されます。
The LSP_TUNNEL objects have the following format:
LSP_TUNNELオブジェクトには、以下の形式があります:
Awduche, et al. Standards Track [Page 38] RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
Awduche、他 規格はTunnels2001年12月にLSPのためにRFC3209拡張子をRSVPに追跡します[38ページ]。
4.6.1. Session Object
4.6.1. セッションオブジェクト
4.6.1.1. LSP_TUNNEL_IPv4 Session Object
4.6.1.1. LSP_トンネル_IPv4セッションオブジェクト
Class = SESSION, LSP_TUNNEL_IPv4 C-Type = 7
クラス=セッション、LSP_トンネル_IPv4C-タイプ=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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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トンネルエンドポイントアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ゼロでなければなりません。| トンネルID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 拡張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ビットの識別子はトンネルの寿命の上でSESSIONでその残り定数を使用しました。
Extended Tunnel ID
拡張Tunnel ID
A 32-bit identifier used in the SESSION that remains constant
over the life of the tunnel. Normally set to all zeros.
Ingress nodes that wish to narrow the scope of a SESSION to the
ingress-egress pair may place their IPv4 address here as a
globally unique identifier.
32ビットの識別子はトンネルの寿命の上でSESSIONでその残り定数を使用しました。 通常、すべてのゼロにセットしてください。 イングレス出口組にSESSIONの範囲を狭くしたがっているイングレスノードはグローバルにユニークな識別子としてそれらのIPv4アドレスをここに置くかもしれません。
Awduche, et al. Standards Track [Page 39] RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
Awduche、他 規格はTunnels2001年12月にLSPのためにRFC3209拡張子をRSVPに追跡します[39ページ]。
4.6.1.2. LSP_TUNNEL_IPv6 Session Object
4.6.1.2. LSP_トンネル_IPv6セッションオブジェクト
Class = SESSION, LSP_TUNNEL_IPv6 C_Type = 8
クラス=セッション、LSP_トンネル_IPv6C_は=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) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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トンネルエンドポイントアドレス| + + | (16バイト) | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ゼロでなければなりません。| トンネルID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | 拡張Tunnel ID| + + | (16バイト) | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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ビットの識別子はトンネルの寿命の上でSESSIONでその残り定数を使用しました。
Extended Tunnel ID
拡張Tunnel ID
A 16-byte identifier used in the SESSION that remains constant
over the life of the tunnel. Normally set to all zeros.
Ingress nodes that wish to narrow the scope of a SESSION to the
ingress-egress pair may place their IPv6 address here as a
globally unique identifier.
16バイトの識別子はトンネルの寿命の上でSESSIONでその残り定数を使用しました。 通常、すべてのゼロにセットしてください。 イングレス出口組にSESSIONの範囲を狭くしたがっているイングレスノードはグローバルにユニークな識別子としてそれらのIPv6アドレスをここに置くかもしれません。
4.6.2. Sender Template Object
4.6.2. 送付者テンプレートオブジェクト
4.6.2.1. LSP_TUNNEL_IPv4 Sender Template Object
4.6.2.1. LSP_トンネル_IPv4送付者テンプレートオブジェクト
Class = SENDER_TEMPLATE, LSP_TUNNEL_IPv4 C-Type = 7
クラス=送付者_テンプレート、LSP_トンネル_IPv4C-タイプ=7
Awduche, et al. Standards Track [Page 40] RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
Awduche、他 規格はTunnels2001年12月にLSPのためにRFC3209拡張子をRSVPに追跡します[40ページ]。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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トンネル送付者アドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ゼロでなければなりません。| 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.
16ビットの識別子はSENDER_TEMPLATEとFILTERで_送付者がそれ自体とリソースを共有するのを許容するために変えることができるSPECを使用しました。
4.6.2.2. LSP_TUNNEL_IPv6 Sender Template Object
4.6.2.2. LSP_トンネル_IPv6送付者テンプレートオブジェクト
Class = SENDER_TEMPLATE, LSP_TUNNEL_IPv6 C_Type = 8
クラス=送付者_テンプレート、LSP_トンネル_IPv6C_は=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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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トンネル送付者アドレス| + + | (16バイト) | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ゼロでなければなりません。| 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.
16ビットの識別子はSENDER_TEMPLATEとFILTERで_送付者がそれ自体とリソースを共有するのを許容するために変えることができるSPECを使用しました。
Awduche, et al. Standards Track [Page 41] RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
Awduche、他 規格はTunnels2001年12月にLSPのためにRFC3209拡張子をRSVPに追跡します[41ページ]。
4.6.3. Filter Specification Object
4.6.3. フィルタ仕様オブジェクト
4.6.3.1. LSP_TUNNEL_IPv4 Filter Specification Object
4.6.3.1. LSP_トンネル_IPv4フィルタ仕様オブジェクト
Class = FILTER SPECIFICATION, LSP_TUNNEL_IPv4 C-Type = 7
クラス=フィルタ仕様、LSP_トンネル_IPv4C-タイプ=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オブジェクトと同じです。
4.6.3.2. LSP_TUNNEL_IPv6 Filter Specification Object
4.6.3.2. LSP_トンネル_IPv6フィルタ仕様オブジェクト
Class = FILTER SPECIFICATION, LSP_TUNNEL_IPv6 C_Type = 8
クラス=フィルタ仕様、LSP_トンネル_IPv6C_は=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オブジェクトと同じです。
4.6.4. Reroute and Bandwidth Increase Procedure
4.6.4. コースを変更してください。そうすれば、帯域幅は手順を増強します。
This section describes how to setup a tunnel that is capable of maintaining resource reservations (without double counting) while it is being rerouted or while it is attempting to increase its bandwidth. In the initial Path message, the ingress node forms a SESSION object, assigns a Tunnel_ID, and places its IPv4 address in the Extended_Tunnel_ID. It also forms a SENDER_TEMPLATE and assigns a LSP_ID. Tunnel setup then proceeds according to the normal procedure.
このセクションはそれが別ルートで送られているか、または帯域幅を増強するのを試みている間に資源予約(二重計算のない)を維持できるトンネルをセットアップする方法を説明します。 初期のPathメッセージでは、イングレスノードは、Extended_Tunnel_IDにSESSIONオブジェクトを形成して、Tunnel_IDを割り当てて、IPv4アドレスを置きます。 それは、また、SENDER_TEMPLATEを形成して、LSP_IDを割り当てます。 そして、正常な手順によると、トンネルセットアップは続きます。
On receipt of the Path message, the egress node sends a Resv message with the STYLE Shared Explicit toward the ingress node.
Pathメッセージを受け取り次第、出口ノードは様式Shared ExplicitがあるResvメッセージをイングレスノードに向かって送ります。
When an ingress node with an established path wants to change that path, it forms a new Path message as follows. The existing SESSION object is used. In particular the Tunnel_ID and Extended_Tunnel_ID are unchanged. The ingress node picks a new LSP_ID to form a new SENDER_TEMPLATE. It creates an EXPLICIT_ROUTE object for the new route. The new Path message is sent. The ingress node refreshes both the old and new path messages.
その経路を変える確立した経路必需品があるイングレスノードであるときに、それは以下の新しいPathメッセージを形成します。 既存のSESSIONオブジェクトは使用されています。 Tunnel_IDとExtended_Tunnel_IDは特に、変わりがありません。 イングレスノードは、新しいSENDER_TEMPLATEを形成するために新しいLSP_IDを選びます。 それはEXPLICIT_ROUTEオブジェクトを新しいルートに作成します。 新しいPathメッセージを送ります。 イングレスノードは両方の古くて新しい経路メッセージをリフレッシュします。
The egress node responds with a Resv message with an SE flow descriptor formatted as:
出口ノードは以下としてのSE流れ記述子がフォーマットされているResvメッセージで応じます。
<FLOWSPEC><old_FILTER_SPEC><old_LABEL_OBJECT><new_FILTER_SPEC>
<new_LABEL_OBJECT>
古い古い新しい<のフィルタ_仕様><新しい_FLOWSPEC><_フィルタ_仕様><_ラベル_オブジェクト><_ラベル_オブジェクト>。
(Note that if the PHOPs are different, then two messages are sent each with the appropriate FILTER_SPEC and LABEL_OBJECT.)
(PHOPsが異なるならそれぞれが適切なFILTER_SPECとLABEL_OBJECTと共に2つのメッセージに送られることに注意してください。)
Awduche, et al. Standards Track [Page 42] RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
Awduche、他 規格はTunnels2001年12月にLSPのためにRFC3209拡張子をRSVPに追跡します[42ページ]。
When the ingress node receives the Resv Message(s), it may begin using the new route. It SHOULD send a PathTear message for the old route.
イングレスノードがResv Message(s)を受けるとき、それは、新しいルートを使用し始めるかもしれません。 それ、SHOULDは古いルートへのPathTearメッセージを送ります。
4.7. Session Attribute Object
4.7. セッション属性オブジェクト
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:
Session Attribute Classは207歳です。 LSP_TUNNEL(C-タイプの=7とLSP_TUNNEL_RA)は2C_Typesが定義されて、=1をCでタイプします。 LSP_TUNNEL_RA C-タイプはLSP_TUNNEL C-タイプへのちょうど同じ分野を入れます。 さらに、それはリソース親近感情報を運びます。 形式は以下の通りです:
4.7.1. Format without resource affinities
4.7.1. リソースの親近感のない形式
SESSION_ATTRIBUTE class = 207, LSP_TUNNEL C-Type = 7
SESSION_ATTRIBUTEのクラスは207、LSP_TUNNEL C-タイプ=7と等しいです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Setup Prio | Holding Prio | Flags | Name Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Session Name (NULL padded display string) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | セットアップPrio| Prioを持っています。| 旗| 名前の長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | //セッションName(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は最優先です。 このセッションが別のセッションを先取りできるかどうか決める際にSetup Priorityは使用されます。
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は最優先です。 別のセッションでこのセッションを先取りできるかどうか決める際に優位に立つのは使用されます。
Awduche, et al. Standards Track [Page 43] RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
Awduche、他 規格はTunnels2001年12月にLSPのためにRFC3209拡張子をRSVPに追跡します[43ページ]。
Flags
旗
0x01 Local protection desired
地方の保護が望んでいた0×01
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
0×02は必要であると録音をラベルします。
This flag indicates that label information should be
included when doing a route record.
この旗は、ルート記録をするとき、ラベル情報が含まれるべきであるのを示します。
0x04 SE Style desired
0×04 望まれていた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.
この旗は、トンネルイングレスノードが、それを取りこわさないでこのトンネルを別ルートで送るのを選ぶかもしれないのを示します。 Resvメッセージで応じるとき、トンネル出口ノードSHOULDはSE様式を使用します。
Name Length
名前の長さ
The length of the display string before padding, in bytes.
バイトでそっと歩く前のディスプレイストリングの長さ。
Session Name
セッション名
A null padded string of characters.
ヌルはキャラクタのストリングを水増ししました。
Awduche, et al. Standards Track [Page 44] RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
Awduche、他 規格はTunnels2001年12月にLSPのためにRFC3209拡張子をRSVPに追跡します[44ページ]。
4.7.2. Format with resource affinities
4.7.2. リソースの親近感がある形式
SESSION_ATTRIBUTE class = 207, LSP_TUNNEL_RA C-Type = 1
SESSION_ATTRIBUTEのクラスは207、LSP_TUNNEL_RA C-タイプ=1と等しいです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Exclude-any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Include-any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Include-all |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Setup Prio | Holding Prio | Flags | Name Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Session Name (NULL padded display string) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | いずれも除きます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | いずれも含んでいます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | すべてを含んでいます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | セットアップPrio| Prioを持っています。| 旗| 名前の長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | //セッションName(NULLは表示ストリングを水増しした)//| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Exclude-any
いずれも除きます。
A 32-bit vector representing a set of attribute filters
associated with a tunnel any of which renders a link
unacceptable.
1セットの属性を表す32ビットのベクトルに、フィルタはそれのいずれもリンクを容認できなくするトンネルと交際しました。
Include-any
いずれも含んでいます。
A 32-bit vector representing a set of attribute filters
associated with a tunnel any of which renders a link acceptable
(with respect to this test). A null set (all bits set to zero)
automatically passes.
1セットの属性を表す32ビットのベクトルに、フィルタはそれのいずれもリンクを許容できるように(このテストに関する)するトンネルと交際しました。 零集合(すべてのビットがゼロにセットした)は自動的に終わります。
Include-all
すべてを含んでいます。
A 32-bit vector representing a set of attribute filters
associated with a tunnel all of which must be present for a
link to be acceptable (with respect to this test). A null set
(all bits set to zero) automatically passes.
1セットの属性を表す32ビットのベクトルに、フィルタはそれのすべてがリンクが許容できる(このテストに関する)ために出席していなければならないトンネルと交際しました。 零集合(すべてのビットがゼロにセットした)は自動的に終わります。
Setup Priority
セットアップ優先権
The priority of the session with respect to taking resources,
in the range of 0 to 7. The value 0 is the highest priority.
The Setup Priority is used in deciding whether this session can
preempt another session.
0〜7の範囲でリソースを取ることに関するセッションの優先権。 値0は最優先です。 このセッションが別のセッションを先取りできるかどうか決める際にSetup Priorityは使用されます。
Awduche, et al. Standards Track [Page 45] RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
Awduche、他 規格はTunnels2001年12月にLSPのためにRFC3209拡張子をRSVPに追跡します[45ページ]。
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
地方の保護が望んでいた0×01
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
0×02は必要であると録音をラベルします。
This flag indicates that label information should be
included when doing a route record.
この旗は、ルート記録をするとき、ラベル情報が含まれるべきであるのを示します。
0x04 SE Style desired
0×04 望まれていた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.
この旗は、トンネルイングレスノードが、それを取りこわさないでこのトンネルを別ルートで送るのを選ぶかもしれないのを示します。 Resvメッセージで応じるとき、トンネル出口ノードSHOULDはSE様式を使用します。
Name Length
名前の長さ
The length of the display string before padding, in bytes.
バイトでそっと歩く前の表示ストリングの長さ。
Session Name
セッション名
A null padded string of characters.
ヌルはキャラクタのストリングを水増ししました。
4.7.3. Procedures applying to both C-Types
4.7.3. 両方のC-タイプに適用される手順
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.
セットアップと把持プライオリティのサポートはOPTIONALです。 ノードは、この情報を認識しますが、要求された操作を実行できません。 ノードSHOULDは情報を川下に変わりがない状態で通過します。
As noted above, preemption is implemented by two priorities. The Setup Priority is the priority for taking resources. The Holding Priority is the priority for holding a resource. Specifically, the
上で述べたように、先取りは2つのプライオリティによって実行されます。 Setup Priorityは、リソースを取るための優先権です。 Holding Priorityは、リソースを保持するための優先権です。 明確に
Awduche, et al. Standards Track [Page 46] RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
Awduche、他 規格はTunnels2001年12月にLSPのためにRFC3209拡張子をRSVPに追跡します[46ページ]。
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.
優位に立つのは、このセッションまで割り当てられたリソースが予約される優先権です。 Setup Priority SHOULD、与えられたセッションのためにHolding Priorityより決して高しないでください。
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個の物の相互作用は方針の問題ですが、以下のデフォルト相互作用はRECOMMENDEDです。
When both objects are present, the preemption priority policy element is used. A mapping between the priority spaces is defined as follows. A session attribute priority S is mapped to a preemption priority P by the formula P = 2^(14-2S). The reverse mapping is shown in the following table.
両方の物が存在しているとき、先取り優先権方針要素は使用されています。 優先権空間の間のマッピングは以下の通り定義されます。 セッション属性優先Sは公式P=2^(14-2S)によって先取り優先Pに写像されます。 逆のマッピングは以下のテーブルに示されます。
Preemption Priority Session Attribute Priority
先取り優先権セッション属性優先権
0 - 3 7
4 - 15 6
16 - 63 5
64 - 255 4
256 - 1023 3
1024 - 4095 2
4096 - 16383 1
16384 - 65535 0
0 - 3 7 4 - 15 6 16 - 63 5 64 - 255 4 256 - 1023 3 1024 - 4095 2 4096 - 16383 1 16384 - 65535 0
When a new Path message is considered for admission, the bandwidth requested is compared with the bandwidth available at the priority specified in the Setup Priority.
新しいPathメッセージが入場のために考えられるとき、帯域幅が利用可能な状態で要求された帯域幅は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".
要求された帯域幅が利用可能でないなら、01のError Code、Admission Control Failure、および0×0002のError Valueと共にPathErrメッセージを返します。 Error Valueにおける最初の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、そして/または、コード「方針Controlの故障」SHOULDを川下の受信機と上流の送付者に向かって送るPathErr。
Awduche, et al. Standards Track [Page 47] RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
Awduche、他 規格はTunnels2001年12月にLSPのためにRFC3209拡張子をRSVPに追跡します[47ページ]。
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.
地方の保護のサポートはOPTIONALです。 ノードは、地方の保護Flagを認識しますが、要求された操作を実行できないかもしれません。 この場合、ノードSHOULDは情報を川下に変わりがない状態で通過します。
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物でのLabel subobjectの録音はSESSION_ATTRIBUTE物の望まれていたラベル録音旗で制御されます。 Label 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.
Session Name分野の内容は通常、表示できるキャラクタのストリングです。 Lengthはいつも4の倍数でなければならなく、少なくとも8歳であるに違いありません。 4の倍数でない物の長さにおいて、物は引きずっているNULLキャラクタと共に水増しされます。 Name Length分野は実際のストリング長を含んでいます。
4.7.4. Resource Affinity Procedures
4.7.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つのテストに合格しなければなりません。 コード「方針コントロール失敗」SHOULDに応じてテストが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を広げるのをどんな許容できるリンクも見つけることができないなら、ノードSHOULDは「ルート設定問題」のエラーコードと「目的地に向かって利用可能なルートがありません」の誤り値があるPathErrメッセージを送ります。
In order to be validated a link MUST pass the following three tests.
有効にされるために、リンクは以下の3つのテストに合格しなければなりません。
To precisely describe the tests use the definitions in the object description above. We also define
正確にテストについて説明するには、上の物の記述との定義を使用してください。 また、私たちは定義します。
Link-attr A 32-bit vector representing attributes associated
with a link.
リンクに関連している属性を表すリンク-attrのA32ビットのベクトル。
Awduche, et al. Standards Track [Page 48] RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
Awduche、他 規格はTunnels2001年12月にLSPのためにRFC3209拡張子をRSVPに追跡します[48ページ]。
The three tests are
3つのテストがそうです。
1. Exclude-any
1. いずれも除きます。
This test excludes a link from consideration if the link
carries any of the attributes in the set.
リンクがセットで属性のどれかを運ぶなら、このテストは考慮にリンクを入れないようにします。
(link-attr & exclude-any) == 0
(リンク-attrといずれも除きます)の=0
2. Include-any
2. いずれも含んでいます。
This test accepts a link if the link carries any of the
attributes in the set.
リンクがセットで属性のどれかを運ぶなら、このテストはリンクを受け入れます。
(include-any == 0) | ((link-attr & include-any) != 0)
(いずれも含んでいる=0)| ((リンク-attrの、そして、いずれも含んでいる)=0)
3. Include-all
3. すべてを含んでいます。
This test accepts a link only if the link carries all of the
attributes in the set.
リンクがセットで属性のすべてを運ぶ場合にだけ、このテストはリンクを受け入れます。
(include-all == 0) | (((link-attr & include-all) ^ include-
all) == 0)
(すべてを含んでいる=0)| (((リンク-attrとすべてを含んでいます)の^はすべてを含んでいます)=0)
For a link to be acceptable, all three tests MUST pass. If the test fails, the node SHOULD send a PathErr message with an error code of "Routing Problem" and an error value of "no route available toward destination".
リンクが許容できるために、すべての3つのテストに合格しなければなりません。 テストが失敗するなら、ノードSHOULDは「ルート設定問題」のエラーコードと「目的地に向かって利用可能なルートがありません」の誤り値があるPathErrメッセージを送ります。
If a Path message contains multiple SESSION_ATTRIBUTE objects, only the first SESSION_ATTRIBUTE object is meaningful. Subsequent SESSION_ATTRIBUTE objects can be ignored and need not be forwarded.
Pathメッセージが複数のSESSION_ATTRIBUTE物を含んでいるなら、最初のSESSION_ATTRIBUTE物だけが重要です。 その後のSESSION_ATTRIBUTE物を無視できて、進める必要はありません。
All RSVP routers, whether they support the SESSION_ATTRIBUTE object or not, SHALL forward the object unmodified. The presence of non- RSVP routers anywhere between senders and receivers has no impact on this object.
すべてのRSVPルータであり、それらがSESSION_ATTRIBUTE物を支えるか否かに関係なく、SHALLは変更されていなく物を進めます。 送付者と受信機の間でどこでも非RSVPのルータの存在はこの物に変化も与えません。
5. Hello Extension
5. こんにちは、拡大
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拡張子は、RSVPノードが、隣接しているノードにいつ届いていないかを検出するのを可能にします。 メカニズムはノード障害検出にノードを提供します。 そのような失敗が検出されるとき、それはリンクレイヤ通信障害として似たり寄ったりの状態で扱われます。 リンクレイヤの故障の通知が利用可能でなく、また無数のリンクが使用されていないか、またはリンクレイヤで提供された失敗検出メカニズムがタイムリーなノード障害検出に十分でないときに、このメカニズムが使用されることを意図します。
Awduche, et al. Standards Track [Page 49] RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
Awduche、他 規格はTunnels2001年12月にLSPのためにRFC3209拡張子をRSVPに追跡します[49ページ]。
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拡張子は、半面がメカニズムを使用できるように、反対側が設計されていない間、明確に設計されています。 隣人失敗検出はいつでも、開始されるかもしれません。 これは、隣人が最初に、いつ互いに関して学ぶか、そして、または隣人がいったいいつResvかPath状態を共有しているかを含んでいます。
The Hello extension is composed of a Hello message, a HELLO REQUEST object and a HELLO ACK object. Hello processing between two neighbors supports independent selection of, typically configured, failure detection intervals. Each neighbor can autonomously issue HELLO REQUEST objects. Each request is answered by an acknowledgment. Hello Messages also contain enough information so that one neighbor can suppress issuing hello requests and still perform neighbor failure detection. A Hello message may be included as a sub-message within a bundle message.
Hello拡張子はHelloメッセージ、HELLO REQUEST物、およびHELLO ACK物で構成されます。 こんにちは、2人の隣人の間の処理は失敗検出間隔の通常構成されて、独立している品揃えを支持します。 各隣人は自主的にHELLO REQUESTに物を発行できます。 承認で各要求は答えられます。 こんにちは、Messages、また、こんにちはを発行する隣人が抑圧できる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セットの投票と応答に失敗検出間隔あたりなるでしょう。 選択された間隔によって、1人の隣人だけが最適化を支持すると、同じ利益は起こることができます。
5.1. Hello Message Format
5.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隣人の間に送って、いつもMessagesはそうです。 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であるときにメッセージはすぐ隣の人の間の交換でした、すべての出発しているHELLOメッセージSHOULDのIP TTL分野。1に設定されます。
Awduche, et al. Standards Track [Page 50] RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
Awduche、他 規格はTunnels2001年12月にLSPのためにRFC3209拡張子をRSVPに追跡します[50ページ]。
The Hello message has a Msg Type of 20. The Hello message format is as follows:
Helloメッセージには、20のエムエスジーTypeがあります。 Helloメッセージ・フォーマットは以下の通りです:
<Hello Message> ::= <Common Header> [ <INTEGRITY> ]
<HELLO>
<、こんにちは、メッセージ>:、:= <一般的なヘッダー>[<保全>]<、こんにちは、>。
5.2. HELLO Object formats
5.2. HELLO Object形式
The HELLO Class is 22. There are two C_Types defined.
HELLO Classは22歳です。 C_Typesが定義した2があります。
5.2.1. HELLO REQUEST object
5.2.1. HELLO REQUEST物
Class = HELLO Class, C_Type = 1
こんにちは、クラス、C_クラス=タイプ=1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src_Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dst_Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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_例| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Dst_例| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.2.2. HELLO ACK object
5.2.2. HELLO ACK物
Class = HELLO Class, C_Type = 2
こんにちは、クラス、C_クラス=タイプ=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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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_例| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Dst_例| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Src_Instance: 32 bits
Src_例: 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ビットの値。 広告主は隣人表現/値あたりのaを維持します。 この値は隣接しているノードに失われていて、そうでなければ、コミュニケーションがいつ送付者がいつリセットされるか、そして、ノードがいつリブートするか、そして、または同じままで残っているかを変えなければなりません。 この分野が(0)のゼロに合うように設定されてはいけません。
Dst_Instance: 32 bits
Dst_例: 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)のゼロを合わせるようにこの分野を設定しなければなりません。
Awduche, et al. Standards Track [Page 51] RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
Awduche、他 規格はTunnels2001年12月にLSPのためにRFC3209拡張子をRSVPに追跡します[51ページ]。
5.3. Hello Message Usage
5.3. こんにちは、メッセージ用法
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 Messageは完全にOPTIONALです。 すべてのメッセージがHelloメッセージ処理に参加したがっていないノードによって無視されるかもしれません。 送付者と同様に受信機が関与していると仮定しながら、このセクションのバランスは書かれています。 そして、特に使用、受信機に関するSHOULDはHelloメッセージ処理を支えるノードだけに適用しなければなりません。
A node periodically generates a Hello message containing a HELLO REQUEST object for each neighbor who's status is being tracked. The periodicity is governed by the hello_interval. This value MAY be configured on a per neighbor basis. The default value is 5 ms.
ノードは状態である各隣人のためのHELLO REQUEST物を含むのが追跡されているというHelloメッセージを定期的に発生させます。 周期性が決定される、こんにちは、_間隔。 この値は隣人基礎あたりのaで構成されるかもしれません。 デフォルト値は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での中詰めがさばく送付者は隣人例単位でいます。 エージェントが対応する隣人と共にこんにちはの挨拶を交わしている間、この値は変化してはいけません。 また、送付者はごく最近隣人からSrc_Instance値を受け取っていてDst_Instance分野に記入します。 参照には、この可変Neighbor_をSrc_Instanceと呼んでください。 今までに、隣人から値を全く受け取ったことがないか、またはこのノードが、隣人へのコミュニケーションが失われたと考えるなら、Neighbor_Src_Instanceは(0)のゼロを合わせるように用意ができています。 世代、先の中の目的地ノードからHELLO REQUEST物を受け取ったときにはaメッセージSHOULDでは、抑圧してください、こんにちは、_間隔間隔。
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物を含むHelloメッセージを発生させなければなりません。 また、受信機SHOULDは、隣人にはリセットがないことを確かめます。 送付者の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物のSHOULDの受信機は、隣人が受信機のInstance値を映し出していることを確かめます。 ごく最近その隣人に送られたSrc_Instance分野価値と容認されたDst_Instance分野を比べることによって、これをします。 隣人が、構成された数の間隔の後に間違った非ゼロ値の広告を出し続けているなら、まるでコミュニケーションが失われたかのようにノードは隣人を扱わなければなりません。
On receipt of a message containing a HELLO ACK object, the receiver MUST verify that the neighbor has not reset. This is done by comparing the sender's Src_Instance field value with the previously
HELLO ACK物を含むメッセージを受け取り次第、受信機は、隣人にはリセットがないことを確かめなければなりません。 Instanceが値をさばく送付者のSrc_を比較することによってこれをする、以前に。
Awduche, et al. Standards Track [Page 52] RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
Awduche、他 規格はTunnels2001年12月にLSPのためにRFC3209拡張子をRSVPに追跡します[52ページ]。
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.
容認された値。 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物の受信機は、隣人が受信機のInstance値を映し出していることを確かめなければなりません。 隣人が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.
REQUESTかACKが構成された数の中の隣人から反対するどちらかを通してInstance値を全く受け取らない、こんにちは、_間隔、そして、ノードは隣人とコミュニケートできないと推定しなければなりません。 この数のためのデフォルトは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_例の値の分野にゼロの広告を出さなければなりません。
5.4. Multi-Link Considerations
5.4. マルチリンク問題
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拡張子はリンクの故障でないのあたりのノード障害を検出するのに狙います。 隣接しているノードの間には、1個のリンクしかないか、または1組のノードの間のすべてのリンクが失敗するとき、ノードとリンクの故障の区別は本当に重要ではありません、そして、既にそのような失敗の取り扱いをカバーしています。 隣人の間で共有された複数のリンクがあるとき、特別な問題があります。 隣人の間のリンクが番号付であるなら、ハローズは各リンクで経営されていなければなりません、そして、以前に説明されたメカニズムは適用されます。
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.
リンクが無数であるときに、ハローズを除いて、どうでもリンク失敗検出を提供しなければなりません。 各ノードSHOULDは隣人とのただ一つのHello交換を使用します。 すべてのリンクが失敗したケースはノー、が前項で言及された値のケースを受けたのと同じです。
Awduche, et al. Standards Track [Page 53] RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
Awduche、他 規格はTunnels2001年12月にLSPのためにRFC3209拡張子をRSVPに追跡します[53ページ]。
5.5. Compatibility
5.5. 互換性
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拡張子はいかなる他のRSVPメッセージの処理にも影響しません。 唯一の効果はリンク(ノード)下に出来事がそれであるだろうより早く宣言されるのを許容することです。 その状態へのRSVP応答は変わりがありません。
The Hello extension is fully backwards compatible. The Hello class is assigned a class value of the form 0bbbbbbb. Depending on the implementation, implementations that do not support the extension will either silently discard Hello messages or will respond with an "Unknown Object Class" error. In either case the sender will fail to see an acknowledgment for the issued Hello.
Hello拡張子は完全に遅れています。互換性がある。 フォーム0bbbbbbbの階級値はHelloのクラスに配属されます。 実現によって、拡大を支持しない実現が、静かにHelloメッセージを捨てるか、または「未知の物のクラス」誤りで応じるでしょう。 どちらの場合ではも、送付者は発行されたHelloに関して承認を見ないでしょう。
6. Security Considerations
6. セキュリティ問題
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]の上と、そして、RFC 2205[1]の上でセキュリティ露出を全く引き起こしません。 しかしながら、信用モデルにおける小変化があります。 交通は、通常のRSVPセッションが情報筋と送付先アドレスによってフィルターにかけられて、数を移植できるのを転送しました。 この仕様では、フィルタリングは単に入って来るラベルに基づいて起こります。 管理がどのLSPの上でドメインを制限したがっているかもしれないかこの理由で、トンネルを確立できます。 タイプLSP_TUNNEL_IPv4(7)かLSP_TUNNEL_IPv6(8)のSESSION物でRSVP経路メッセージへの動作を否定するために様々なポートにフィルタをけしかけることによって、これを達成できます。
7. IANA Considerations
7. IANA問題
IANA assigns values to RSVP protocol parameters. Within the current document an EXPLICIT_ROUTE object and a ROUTE_RECORD object are defined. Each of these objects contain subobjects. This section defines the rules for the assignment of subobject numbers. This section uses the terminology of BCP 26 "Guidelines for Writing an IANA Considerations Section in RFCs" [15].
IANAはRSVPプロトコルパラメタに値を割り当てます。 現在のドキュメントの中では、EXPLICIT_ROUTE物とROUTE_RECORD物は定義されます。 それぞれのこれらの物は「副-物」を含んでいます。 このセクションは「副-物」の番号の課題のために規則を決めます。 このセクションはBCP26「RFCsにIANA問題部に書くためのガイドライン」[15]の用語を使用します。
EXPLICIT_ROUTE Subobject Type
明白な_ルート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.
EXPLICIT_ROUTE Subobject Typeは「副-物」の機能を特定する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]に概説された方針に従って、IETF Consensus動作で0--63(0×00--0x3F)の範囲の「副-物」のタイプを割り当てます、そして、First Come First Servedとして64--95(0×40--0x5F)の範囲のコードを割り当てます、そして、兵士のUseのために96--127(0×60--0x7F)の範囲のコードを予約します。
Awduche, et al. Standards Track [Page 54] RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
Awduche、他 規格はTunnels2001年12月にLSPのためにRFC3209拡張子をRSVPに追跡します[54ページ]。
ROUTE_RECORD Subobject Type
ルート_記録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 Typeは「副-物」の機能を特定する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]に概説された方針に従って、IETF Consensus動作で0--127(0×00--0x7F)の範囲の「副-物」のタイプを割り当てます、そして、First Come First Servedとして128--191(0×80--0xBF)の範囲のコードを割り当てます、そして、兵士のUseのために192--255(0xC0--0xFF)の範囲のコードを予約します。
The following assignments are made in this document.
本書では以下の課題をします。
7.1. Message Types
7.1. メッセージタイプ
Message Message Number Name
メッセージメッセージ番号名
20 Hello
20 こんにちは
7.2. Class Numbers and C-Types
7.2. クラス番号とC-タイプ
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フィルタ_仕様
Class Types or C-Types:
クラスタイプかC-タイプ:
7 LSP Tunnel IPv4
8 LSP Tunnel IPv6
7 LSPトンネルIPv4 8 LSPトンネルIPv6
11 SENDER_TEMPLATE
11送付者_テンプレート
Class Types or C-Types:
クラスタイプかC-タイプ:
7 LSP Tunnel IPv4
8 LSP Tunnel IPv6
7 LSPトンネルIPv4 8 LSPトンネルIPv6
Awduche, et al. Standards Track [Page 55] RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
Awduche、他 規格はTunnels2001年12月にLSPのためにRFC3209拡張子をRSVPに追跡します[55ページ]。
16 RSVP_LABEL
16RSVP_ラベル
Class Types or C-Types:
クラスタイプかC-タイプ:
1 Type 1 Label
1 タイプ1個のラベル
19 LABEL_REQUEST
19ラベル_要求
Class Types or C-Types:
クラスタイプかC-タイプ:
1 Without Label Range
2 With ATM Label Range
3 With Frame Relay Label Range
1 フレームリレーラベル範囲がある気圧ラベル範囲3があるラベル範囲2なしで
20 EXPLICIT_ROUTE
20の明白な_ルート
Class Types or C-Types:
クラスタイプかC-タイプ:
1 Type 1 Explicit Route
1 1つのタイプの明白なルート
21 ROUTE_RECORD
21ルート_記録
Class Types or C-Types:
クラスタイプかC-タイプ:
1 Type 1 Route Record
1 1つのタイプルート記録
22 HELLO
22 こんにちは
Class Types or C-Types:
クラスタイプかC-タイプ:
1 Request
2 Acknowledgment
1 要求2承認
207 SESSION_ATTRIBUTE
207セッション_属性
Class Types or C-Types:
クラスタイプかC-タイプ:
1 LSP_TUNNEL_RA
7 LSP Tunnel
1 LSP_トンネル_RA7LSPトンネル
Awduche, et al. Standards Track [Page 56] RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
Awduche、他 規格はTunnels2001年12月にLSPのためにRFC3209拡張子をRSVPに追跡します[56ページ]。
7.3. Error Codes and Globally-Defined Error Value Sub-Codes
7.3. エラーコードとグローバルに定義された誤り値のサブコード
The following list extends the basic list of Error Codes and Values that are defined in [RFC2205].
以下のリストは[RFC2205]で定義されるError CodesとValuesの基本のリストを広げています。
Error Code Meaning
エラーコード意味
24 Routing Problem
24ルート設定問題
This Error Code has the following globally-defined
Error Value sub-codes:
このError Codeは以下のグローバルに定義されたError Valueをサブコードであるのに持っています:
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 交渉される輪の8MPLS、しかし、できる非RSVPルータを発送しながら示された目的地6Unacceptableラベル価値7のRROに向かって利用可能な厳しい悪いEXPLICIT_ROUTE物2のノード3BadゆるいBadノード4のBad初期の「副-物」の5いいえルートは経路9MPLSラベル割り振りの失敗で10Unsupported L3PIDを立てます。
25 Notify Error
25は誤りに通知します。
This Error Code has the following globally-defined
Error Value sub-codes:
このError Codeは以下のグローバルに定義されたError Valueをサブコードであるのに持っています:
1 RRO too large for MTU
2 RRO Notification
3 Tunnel locally repaired
1 局所的に修理されたMTU2RRO Notification3Tunnelには、大き過ぎるRRO
7.4. Subobject Definitions
7.4. Subobject定義
Subobjects of the EXPLICIT_ROUTE object with C-Type 1:
EXPLICIT_ROUTEのSubobjectsはC-タイプ1で反対します:
1 IPv4 prefix
2 IPv6 prefix
32 Autonomous system number
1 IPv4接頭語2IPv6接頭語32Autonomousシステム番号
Awduche, et al. Standards Track [Page 57] RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
Awduche、他 規格はTunnels2001年12月にLSPのためにRFC3209拡張子をRSVPに追跡します[57ページ]。
Subobjects of the RECORD_ROUTE object with C-Type 1:
RECORD_ROUTEのSubobjectsはC-タイプ1で反対します:
1 IPv4 address
2 IPv6 address
3 Label
1 IPv4アドレス2IPv6アドレス3Label
8. Intellectual Property Considerations
8. 知的所有権問題
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は本書では含まれた仕様いくつかかすべてに関して要求された知的所有権について通知されました。 詳しい情報に関しては、要求された権利のオンラインリストに相談してください。
9. Acknowledgments
9. 承認
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.
このドキュメントはテキストと同様に前のインターネットDraftsに現れた考えを含んでいます。 現在のドキュメントの作者はそれらの草稿の作者に感謝したがっています。 それらは、スティーブン・ブレークと、ブルース・デイビーと、Rochゲランと、Sanjay Kamatと、ヤコフRekhterと、エリック・ローゼンと、アルンViswanathanです。 また、このドキュメントの彼らのコメントについてBora Akyol、ヨラムBernet、およびアレックスMondrusに感謝申し上げます。
10. References
10. 参照
[1] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1, Functional
Specification", RFC 2205, September 1997.
[1] ブレーデン、R.、チャン、L.、Berson、S.、ハーツォグ、S.、およびS.ジャマン、「資源予約は(RSVP)について議定書の中で述べます--バージョン1、機能的な仕様」、RFC2205、1997年9月。
[2] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label
Switching Architecture", RFC 3031, January 2001.
[2] ローゼンとE.とViswanathanとA.とR.Callon、「Multiprotocolラベル切り換え構造」、RFC3031、2001年1月。
[3] Awduche, D., Malcolm, J., Agogbua, J., O'Dell and J. McManus,
"Requirements for Traffic Engineering over MPLS", RFC 2702,
September 1999.
[3]AwducheとD.とマルコムとJ.とAgogbuaとJ.、オデルとJ.マクマナス、「MPLSの上の交通工学のための要件」RFC2702(1999年9月)。
[4] Wroclawski, J., "Specification of the Controlled-Load Network
Element Service", RFC 2211, September 1997.
[4]Wroclawski、J.、「制御負荷ネットワーク要素サービスの仕様」、RFC2211、1997年9月。
[5] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D.,
Li, T. and A. Conta, "MPLS Label Stack Encoding", RFC 3032,
January 2001.
[5] ローゼン、E.、タッパン、D.、Fedorkow、G.、Rekhter、Y.、ファリナッチ、D.、李、T.、およびA.コンタ、「MPLSはスタックコード化をラベルします」、RFC3032、2001年1月。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[6] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[7] Almquist, P., "Type of Service in the Internet Protocol Suite",
RFC 1349, July 1992.
[7]Almquist、P.、「インターネットプロトコル群のサービスのタイプ」、RFC1349、1992年7月。
Awduche, et al. Standards Track [Page 58] RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
Awduche、他 規格はTunnels2001年12月にLSPのためにRFC3209拡張子をRSVPに追跡します[58ページ]。
[8] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of
the Differentiated Services Field (DS Field) in the IPv4 and
IPv6 Headers", RFC 2474, December 1998.
[8] ニコルズとK.とブレークとS.、ベイカーとF.とD.黒、「IPv4とIPv6ヘッダーとの微分されたサービス分野(DS分野)の定義」RFC2474(1998年12月)。
[9] Herzog, S., "Signaled Preemption Priority Policy Element", RFC
2751, January 2000.
[9] ハーツォグ、S.、「合図された先取り優先権方針要素」、RFC2751、2000年1月。
[10] Awduche, D., Hannan, A. and X. Xiao, "Applicability Statement
for Extensions to RSVP for LSP-Tunnels", RFC 3210, December
2001.
[10]AwducheとD.とハナンとA.とX.Xiao、「LSP-TunnelsのためのRSVPへの拡大のための適用性証明」、RFC3210、2001年12月。
[11] Wroclawski, J., "The Use of RSVP with IETF Integrated Services",
RFC 2210, September 1997.
[11]Wroclawski、J.、「IETFの統合サービスとのRSVPの使用」、RFC2210、1997年9月。
[12] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792,
September 1981.
[12] ポステル、J.、「インターネット・コントロール・メッセージ・プロトコル」、STD5、RFC792、1981年9月。
[13] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191,
November 1990.
[13] ムガール人とJ.とS.デアリング、「経路MTU発見」、RFC1191、1990年11月。
[14] Conta, A. and S. Deering, "Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6)", RFC 2463,
December 1998.
[14] コンタ、A.、およびS.デアリング、「インターネットへのインターネット・コントロール・メッセージ・プロトコル(ICMPv6)はバージョン6(IPv6)について議定書の中で述べます」、RFC2463、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問題部に書くためのガイドライン」BCP26、RFC2434(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.デイビー、「ヌルサービスタイプの仕様」、RFC2997、2000年11月。
Awduche, et al. Standards Track [Page 59] RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
Awduche、他 規格はTunnels2001年12月にLSPのためにRFC3209拡張子をRSVPに追跡します[59ページ]。
11. Authors' Addresses
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
Suite615マクリーン、ダニエルO.Awduche MovazはInc.7926ジョーンズ支店Driveをネットワークでつないで、ヴァージニア 22102は以下を声に出します。 +1 703-298-5291 メールしてください: awduche@movaz.com
Lou Berger Movaz Networks, Inc. 7926 Jones Branch Drive, Suite 615 McLean, VA 22102 Voice: +1 703 847 1801 EMail: lberger@movaz.com
Suite615マクリーン、ルウバーガーMovazはInc.7926ジョーンズ支店Driveをネットワークでつないで、ヴァージニア 22102は以下を声に出します。 +1 1801年の703 847メール: lberger@movaz.com
Der-Hwa Gan Juniper Networks, Inc. 385 Ravendale Drive Mountain View, CA 94043 EMail: dhg@juniper.net
Der-Hwaガン杜松はマウンテンビュー、カリフォルニア 94043がメールするInc.385Ravendaleドライブをネットワークでつなぎます: dhg@juniper.net
Tony Li Procket Networks 3910 Freedom Circle, Ste. 102A Santa Clara CA 95054 EMail: tli@procket.com
Ste、トニー李Procketは3910年の自由円をネットワークでつなぎます。 102Aサンタクララカリフォルニア 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
Parkwayレッドウッドシティー、Inc.1200Bridgeカリフォルニア 94065が声に出すビジェイSrinivasanコサインコミュニケーション: +1 4892年の650 628メール: vsriniva@cosinecom.com
George Swallow Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA 01824 Voice: +1 978 244 8143 EMail: swallow@cisco.com
チェルムズフォード、MA 01824が声に出すジョージツバメシスコシステムズInc.250アポロDrive: +1 8143年の978 244メール: swallow@cisco.com
Awduche, et al. Standards Track [Page 60] RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
Awduche、他 規格はTunnels2001年12月にLSPのためにRFC3209拡張子をRSVPに追跡します[60ページ]。
12. Full Copyright Statement
12. 完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Awduche, et al. Standards Track [Page 61]
Awduche、他 標準化過程[61ページ]
一覧
スポンサーリンク
