RFC5151 日本語訳
5151 Inter-Domain MPLS and GMPLS Traffic Engineering -- ResourceReservation Protocol-Traffic Engineering (RSVP-TE) Extensions. A.Farrel, Ed., A. Ayyangar, JP. Vasseur. February 2008. (Format: TXT=56663 bytes) (Updates RFC3209, RFC3473) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Farrel, Ed.
Request for Comments: 5151 Old Dog Consulting
Updates: 3209, 3473 A. Ayyangar
Category: Standards Track Juniper Networks
JP. Vasseur
Cisco Systems, Inc.
February 2008
ワーキンググループのA.ファレル、エドをネットワークでつないでください。コメントのために以下を要求してください。 5151の古い犬のコンサルティングアップデート: 3209、3473A.Ayyangarカテゴリ: 規格は杜松ネットワークJPを追跡します。 VasseurシスコシステムズInc.2008年2月
Inter-Domain MPLS and GMPLS Traffic Engineering --
Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions
相互ドメインMPLSとGMPLS交通工学--資源予約プロトコル交通工学(RSVP-Te)拡大
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This document describes procedures and protocol extensions for the use of Resource Reservation Protocol-Traffic Engineering (RSVP-TE) signaling in Multiprotocol Label Switching-Traffic Engineering (MPLS-TE) packet networks and Generalized MPLS (GMPLS) packet and non-packet networks to support the establishment and maintenance of Label Switched Paths that cross domain boundaries.
Multiprotocol Label Switching-交通Engineering(MPLS-TE)パケット網、Generalized MPLS(GMPLS)パケット、および非パケット網でドメイン境界に交差するLabel Switched Pathsの設立と維持を支持すると合図しながら、このドキュメントはResource予約プロトコル交通Engineering(RSVP-TE)の使用のための手順とプロトコル拡大について説明します。
For the purpose of this document, a domain is considered to be any collection of network elements within a common realm of address space or path computation responsibility. Examples of such domains include Autonomous Systems, Interior Gateway Protocol (IGP) routing areas, and GMPLS overlay networks.
このドキュメントの目的のために、ドメインはアドレス空間の一般的な分野の中のネットワーク要素か経路計算責任のどんな収集であるとも考えられます。 そのようなドメインに関する例はAutonomous Systems、Interiorゲートウェイプロトコル(IGP)ルーティング部門、およびGMPLSオーバレイネットワークを含んでいます。
Farrel, et al. Standards Track [Page 1] RFC 5151 Inter-Domain MPLS & GMPLS RSVP-TE Extensions February 2008
ファレル、他 標準化過程[1ページ]RFC5151相互ドメインMPLSとGMPLS RSVP-Te拡大2008年2月
Table of Contents
目次
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
1.2. Terminology ................................................4
2. Signaling Overview ..............................................4
2.1. Signaling Options ..........................................5
3. Procedures on the Domain Border Node ............................6
3.1. Rules on ERO Processing ....................................8
3.2. LSP Setup Failure and Crankback ...........................10
3.3. RRO Processing across Domains .............................11
3.4. Notify Message Processing .................................11
4. RSVP-TE Signaling Extensions ...................................12
4.1. Control of Downstream Choice of Signaling Method ..........12
5. Protection and Recovery of Inter-Domain TE LSPs ................13
5.1. Fast Recovery Support Using MPLS-TE Fast Reroute (FRR) ....14
5.1.1. Failure within a Domain (Link or Node Failure) .....14
5.1.2. Failure of Link at Domain Border ...................14
5.1.3. Failure of a Border Node ...........................15
5.2. Protection and Recovery of GMPLS LSPs .....................15
6. Reoptimization of Inter-Domain TE LSPs .........................16
7. Backward Compatibility .........................................17
8. Security Considerations ........................................18
9. IANA Considerations ............................................20
9.1. Attribute Flags for LSP_Attributes Object .................20
9.2. New Error Codes ...........................................20
10. Acknowledgments ...............................................21
11. References ....................................................21
11.1. Normative References ....................................21
11.2. Informative References ..................................22
1. 序論…3 1.1. このドキュメントで中古のコンベンション…3 1.2. 用語…4 2. シグナリング概観…4 2.1. シグナリングオプション…5 3. ドメインの手順はノードに接しています…6 3.1. ERO処理での規則…8 3.2. LSPは失敗とCrankbackをセットアップします…10 3.3. ドメイン中のRRO処理…11 3.4. メッセージ処理に通知してください…11 4. RSVP-Teシグナリング拡大…12 4.1. 方法に合図することの川下の選択のコントロール…12 5. 相互ドメインTe LSPsの保護と回復…13 5.1. 速くMPLS-Teを使用する速い回復支援が(FRR)を別ルートで送ります…14 5.1.1. ドメイン(リンクかノード障害)の中の失敗…14 5.1.2. ドメイン境界のリンクの失敗…14 5.1.3. 境界ノードの失敗…15 5.2. GMPLS LSPsの保護と回復…15 6. 相互ドメインTe LSPsのReoptimization…16 7. 後方の互換性…17 8. セキュリティ問題…18 9. IANA問題…20 9.1. LSP_属性のための属性旗は反対します…20 9.2. 新しいエラーコード…20 10. 承認…21 11. 参照…21 11.1. 標準の参照…21 11.2. 有益な参照…22
Farrel, et al. Standards Track [Page 2] RFC 5151 Inter-Domain MPLS & GMPLS RSVP-TE Extensions February 2008
ファレル、他 標準化過程[2ページ]RFC5151相互ドメインMPLSとGMPLS RSVP-Te拡大2008年2月
1. Introduction
1. 序論
The requirements for inter-area and inter-AS (Autonomous System) Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) are stated in [RFC4105] and [RFC4216], respectively. Many of these requirements also apply to Generalized MPLS (GMPLS) networks. The framework for inter-domain MPLS-TE is provided in [RFC4726].
相互領域と相互AS(自治のSystem)Multiprotocol Label Switching(MPLS)交通Engineering(TE)のための要件は[RFC4105]と[RFC4216]にそれぞれ述べられています。 また、これらの要件の多くがGeneralized MPLS(GMPLS)ネットワークに適用されます。 相互ドメインMPLS-TEのための枠組みを[RFC4726]に提供します。
This document presents procedures and extensions to Resource Reservation Protocol-Traffic Engineering (RSVP-TE) signaling for the setup and maintenance of traffic engineered Label Switched Paths (TE LSPs) that span multiple domains in MPLS-TE or GMPLS networks. The signaling procedures described in this document are applicable to MPLS-TE packet LSPs established using RSVP-TE ([RFC3209]) and all LSPs (packet and non-packet) that use RSVP-TE GMPLS extensions as described in [RFC3473].
このドキュメントは、MPLS-TEの複数のドメインかGMPLSネットワークにかかる交通の設計されたLabel Switched Paths(TE LSPs)のセットアップとメンテナンスのために合図しながら、Resource予約プロトコル交通Engineering(RSVP-TE)に手順と拡大を提示します。 本書では説明されたシグナリング手順はRSVP-TEを使用することで設立されたMPLS-TEパケットLSPs([RFC3209])と[RFC3473]で説明されるようにRSVP-TE GMPLS拡張子を使用するすべてのLSPs(パケットと非パケット)に適切です。
Three different signaling methods for inter-domain RSVP-TE signaling are identified in [RFC4726]. Contiguous LSPs are achieved using the procedures of [RFC3209] and [RFC3473] to create a single end-to-end LSP that spans all domains. Nested LSPs are established using the techniques described in [RFC4206] to carry the end-to-end LSP in a separate tunnel across each domain. Stitched LSPs are established using the procedures of [RFC5150] to construct an end-to-end LSP from the concatenation of separate LSPs each spanning a domain.
相互ドメインRSVP-TEシグナリングのための3つの異なったシグナリング方法が[RFC4726]で特定されます。 隣接のLSPsは、ただ一つの終わりから終わりへのすべてのドメインにかかるLSPを作成するのに[RFC3209]と[RFC3473]の手順を用いることで達成されます。 入れ子にされたLSPsは、別々のトンネルで各ドメインの向こう側に終わりから終わりへのLSPを運ぶために[RFC4206]で説明されたテクニックを使用することで設立されます。 ステッチされたLSPsは、それぞれ別々のLSPsの連結から終わりから終わりへのLSPを組み立てるのにドメインにかかりながら[RFC5150]の手順を用いることで設立されます。
This document defines the RSVP-TE protocol extensions necessary to control and select which of the three signaling mechanisms is used for any one end-to-end inter-domain TE LSP.
このドキュメントは制御して、選択するのに必要なRSVP-TEプロトコル拡張子を定義します(終わりから終わりへの相互ドメインどんなTE LSPにも3台のシグナル伝達機構について使用されます)。
For the purpose of this document, a domain is considered to be any collection of network elements within a common realm of address space or path computation responsibility. Examples of such domains include Autonomous Systems, IGP areas, and GMPLS overlay networks ([RFC4208]).
このドキュメントの目的のために、ドメインはアドレス空間の一般的な分野の中のネットワーク要素か経路計算責任のどんな収集であるとも考えられます。 そのようなドメインに関する例はAutonomous Systems、IGP領域、およびGMPLSオーバレイネットワーク([RFC4208])を含んでいます。
1.1. Conventions Used in This Document
1.1. 本書では使用されるコンベンション
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
Farrel, et al. Standards Track [Page 3] RFC 5151 Inter-Domain MPLS & GMPLS RSVP-TE Extensions February 2008
ファレル、他 標準化過程[3ページ]RFC5151相互ドメインMPLSとGMPLS RSVP-Te拡大2008年2月
1.2. Terminology
1.2. 用語
AS: Autonomous System.
: 自律システム。
ASBR: Autonomous System Border Router. A router used to connect together ASs of a different or the same Service Provider via one or more inter-AS links.
ASBR: 自律システム境界ルータ。 ルータは1個以上の相互ASリンクを通して異なるか同じService ProviderのASsを一緒に接続していました。
Bypass Tunnel: An LSP that is used to protect a set of LSPs passing over a common facility.
トンネルを迂回させてください: 一般的な施設を通り過ぎるLSPsの1セットを保護するのに使用されるLSP。
ERO: Explicit Route Object.
ERO: 明白なルート物。
FA: Forwarding Adjacency.
ファ: 隣接番組を進めます。
LSR: Label Switching Router.
LSR: 切り換えルータをラベルしてください。
MP: Merge Point. The node where bypass tunnels meet the protected LSP.
MP: ポイントを合併してください。 迂回トンネルが保護されたLSPに会うノード。
NHOP bypass tunnel: Next-Hop Bypass Tunnel. A backup tunnel, which bypasses a single link of the protected LSP.
NHOPはトンネルを迂回させます: 次のホップ迂回トンネル。 バックアップトンネル。(そのトンネルは保護されたLSPの単一のリンクを迂回させます)。
NNHOP bypass tunnel: Next-Next-Hop Bypass Tunnel. A backup tunnel, which bypasses a single node of the protected LSP.
NNHOPはトンネルを迂回させます: 次に次に跳んでいる迂回トンネル。 バックアップトンネル。(そのトンネルは保護されたLSPのただ一つのノードを迂回させます)。
PLR: Point of Local Repair. The ingress of a bypass tunnel.
PLR: 局部的修繕のポイント。 迂回トンネルのイングレス。
RRO: Record Route Object.
RRO: ルート物を記録してください。
TE link: Traffic Engineering link.
TEはリンクします: 交通Engineeringはリンクします。
2. Signaling Overview
2. シグナリング概観
The RSVP-TE signaling of a TE LSP within a single domain is described in [RFC3209] and [RFC3473]. Inter-domain TE LSPs can be supported by one of three options as described in [RFC4726] and set out in the next section:
単一領域の中のTE LSPのRSVP-TEシグナリングは[RFC3209]と[RFC3473]で説明されます。 次のセクションを相互ドメインTE LSPsを[RFC4726]で説明されるように3つのオプションの1つで支持して、始めることができます:
- contiguous LSPs - nested LSPs - stitched LSPs.
- 隣接のLSPs(入れ子にされたLSPs)はLSPsをステッチしました。
In fact, as pointed out in [RFC4726], any combination of these three options may be used in the course of an end-to-end inter-domain LSP. That is, the options should be considered as per-domain transit options so that an end-to-end inter-domain LSP that starts in domain A, transits domains B, C, and D, and ends in domain E might use an
事実上、[RFC4726]で指摘されるように、これらの3つのオプションのどんな組み合わせも終わりから終わりへの相互ドメインLSPの間に使用されるかもしれません。 すなわち、オプションはトランジットが終わりから終わりへの相互ドメインドメインAで始まるLSP、トランジットドメインB、C、およびD、およびドメインEへの終わりが使用するかもしれないそうをゆだねるドメインであるとみなされるべきです。
Farrel, et al. Standards Track [Page 4] RFC 5151 Inter-Domain MPLS & GMPLS RSVP-TE Extensions February 2008
ファレル、他 標準化過程[4ページ]RFC5151相互ドメインMPLSとGMPLS RSVP-Te拡大2008年2月
LSP that runs contiguously from the ingress in domain A, through domain B to the border with domain C. Domain C might be transited using the nested LSP option to reach the border with domain D, and domain D might be transited using the stitched LSP option to reach the border with domain E, from where a normal LSP runs to the egress.
ドメインBを通したドメインAのイングレスからドメインC.Domain Cとの境界まで近接してへ走るLSPはドメインDとの境界に達するのに入れ子にされたLSPオプションを使用することで通過されるかもしれません、そして、ドメインDはドメインEとの境界に達するのにステッチされたLSPオプションを使用することで通過されるかもしれません、正常なLSPが出口に走るところから。
This document describes the RSVP-TE signaling extensions required to select and control which of the three signaling mechanisms is used.
このドキュメントは選択するのに必要なRSVP-TEシグナリング拡張子と3台のシグナル伝達機構で使用されたコントロールについて説明します。
The specific protocol extensions required to signal each LSP type are described in other documents and are out of scope for this document. Similarly, the routing extensions and path computation techniques necessary for the establishment of inter-domain LSPs are out of scope. An implementation of a transit LSR is unaware of the options for inter-domain TE LSPs since it sees only TE LSPs. An implementation of a domain border LSR has to decide what mechanisms of inter-domain TE LSP support to include, but must in any case support contiguous inter-domain TE LSPs since this is the default mode of operation for RSVP-TE. Failure to support either or both of nested LSPs or stitched LSPs, restricts the operators options, but does not prevent the establishment of inter-domain TE LSPs.
それぞれのLSPタイプに合図するのに必要である特定のプロトコル拡大は、他のドキュメントで説明されて、このドキュメントのための範囲の外にあります。 同様に、範囲の外に相互ドメインLSPsの設立に必要なルーティング拡大と経路計算のテクニックがあります。 TE LSPsだけを見るので、相互ドメインTE LSPsに、トランジットLSRの実現はオプションに気づきません。 相互ドメインTE LSPサポートのどんなメカニズムを含んだらよいかを決めるために持っていますが、LSRがこれ以来のどんなケースサポートの隣接の相互ドメインTE LSPsでもそうしなければならないドメイン境界の実現はRSVP-TEのためのデフォルト運転モードです。 どちらかか両方をサポートする失敗は、LSPsを入れ子にするか、またはLSPsをステッチしますが、オペレータオプションを制限しますが、相互ドメインTE LSPsの設立を防ぎません。
2.1. Signaling Options
2.1. シグナリングオプション
There are three ways in which an RSVP-TE LSP could be signaled across multiple domains:
複数のドメインの向こう側にRSVP-TE LSPに合図できた3つの方法があります:
Contiguous
A contiguous TE LSP is a single TE LSP that is set up across
multiple domains using RSVP-TE signaling procedures described in
[RFC3209] and [RFC3473]. No additional TE LSPs are required to
create a contiguous TE LSP, and the same RSVP-TE information for
the TE LSP is maintained along the entire LSP path. In
particular, the TE LSP has the same RSVP-TE session and LSP ID at
every LSR along its path.
隣接のA隣接のTE LSPは[RFC3209]と[RFC3473]で説明されたRSVP-TEシグナリング手順を用いる複数のドメインの向こう側にセットアップされる独身のTE LSPです。 どんな追加TE LSPsも隣接のTE LSPを作成する必要はありません、そして、TE LSPのための同じRSVP-TE情報は全体のLSP経路に沿って保守されます。 特に、TE LSPは経路に沿ったあらゆるLSRに同じRSVP-TEセッションとLSP IDを持っています。
Nested
One or more TE LSPs may be nested within another TE LSP as
described in [RFC4206]. This technique can be used to nest one or
more inter-domain TE LSPs into an intra-domain hierarchical LSP
(H-LSP). The label stacking construct is used to achieve nesting
in packet networks. In the rest of this document, the term H-LSP
is used to refer to an LSP that allows other LSPs to be nested
within it. An H-LSP may be advertised as a TE link within the
same instance of the routing protocol as was used to advertise the
TE links from which it was created, in which case it is a
Forwarding Adjacency (FA) [RFC4206].
入れ子にされたOneか、より多くのTE LSPsが[RFC4206]で説明されるように別のTE LSPの中で入れ子にされるかもしれません。 イントラドメインの階層的なLSP(H-LSP)へのより多くの巣1の相互ドメインTE LSPsにこのテクニックを使用できます。 ラベル積み重ね構造物は、パケット網における巣篭もりを達成するのに使用されます。 このドキュメントの残りでは、H-LSPという用語は、他のLSPsがそれの中で入れ子にされるのを許容するLSPについて言及するのに使用されます。 TEリンクとしてそれが作成されたTEリンクの広告を出すのに使用されたルーティング・プロトコルの同じ例の中にH-LSPの広告を出すかもしれません。その場合では、それは例のためのForwarding Adjacency(FA)[RFC4206]です。
Farrel, et al. Standards Track [Page 5] RFC 5151 Inter-Domain MPLS & GMPLS RSVP-TE Extensions February 2008
ファレル、他 標準化過程[5ページ]RFC5151相互ドメインMPLSとGMPLS RSVP-Te拡大2008年2月
Stitched
The concept of LSP stitching as well as the required signaling
procedures are described in [RFC5150]. This technique can be used
to stitch together shorter LSPs (LSP segments) to create a single,
longer LSP. The LSP segments of an inter-domain LSP may be
intra-domain LSPs or inter-domain LSPs.
LSPステッチの概念を必要なシグナリング手順が[RFC5150]で説明されるのと同じくらいよくステッチしました。 シングル、より長いLSPを作成するために、より短いLSPs(LSPセグメント)を一緒に、ステッチするのにこのテクニックを使用できます。 相互ドメインLSPのLSPセグメントは、イントラドメインLSPsか相互ドメインLSPsであるかもしれません。
The process of stitching in the data plane results in a single,
end-to-end contiguous LSP. But in the control plane, each segment
is signaled as a separate LSP (with distinct RSVP sessions) and
the end-to-end LSP is signaled as yet another LSP with its own
RSVP session. Thus, the control plane operation for LSP stitching
is very similar to that for nesting.
データ飛行機でステッチする過程はシングル、終わりから終わりへの隣接のLSPをもたらします。 しかし、制御飛行機では、別々のLSP(異なったRSVPセッションがある)と終わりから終わりへのLSPがさらに別のLSPとしてそれ自身のRSVPセッションで合図されるとき、各セグメントは合図されます。 したがって、巣篭もりに、LSPステッチのためのコントロール飛行機操作はそれと非常に同様です。
An end-to-end inter-domain TE LSP may be achieved using one or more of the signaling techniques described. The choice is a matter of policy for the node requesting LSP setup (the ingress) and policy for each successive domain border node. On receipt of an LSP setup request (RSVP-TE Path message) for an inter-domain TE LSP, the decision of whether to signal the LSP contiguously or whether to nest or stitch it to another TE LSP depends on the parameters signaled from the ingress node and on the configuration of the local node.
終わりから終わりへの相互ドメインTE LSPは、テクニックが説明したシグナリングの1つ以上を使用することで達成されるかもしれません。 選択はLSPセットアップ(イングレス)を要求するノードのための方針とそれぞれの連続したドメイン境界ノードのための方針の問題です。 相互ドメインTE LSPを求めるLSPセットアップ要求(RSVP-TE Pathは通信する)を受け取り次第、別のTE LSPにそれを近接してLSPに合図するかどうか、入れ子にするか、またはステッチするかに関する決定はイングレスノードから合図されたパラメタと、そして、ローカルのノードの構成に依存します。
The stitching segment LSP or H-LSP used to cross a domain may be pre-established or signaled dynamically based on the demand caused by the arrival of the inter-domain TE LSP setup request.
ドメインに交差するのに使用されるステッチセグメントのLSPかH-LSPが相互ドメインTE LSPセットアップ要求の到着で引き起こされた要求に基づいてダイナミックにあらかじめ設立されるか、または合図されるかもしれません。
3. Procedures on the Domain Border Node
3. ドメイン境界ノードの手順
Whether an inter-domain TE LSP is contiguous, nested, or stitched is limited by the signaling methods supported by or configured on the intermediate nodes. It is usually the domain border nodes where this restriction applies since other transit nodes are oblivious to the mechanism in use. The ingress of the LSP may further restrict the choice by setting parameters in the Path message when it is signaled.
隣接で、入れ子にされるか、またはステッチされた相互ドメインTE LSPは方法が支持されたか、または中間的ノードの上で構成したシグナリングによって制限されるのであるかどうか 通常、それは他のトランジットノードが使用中のメカニズムに気づかないのでこの制限が適用されるドメイン境界ノードです。 LSPのイングレスは、それが合図されるときPathメッセージにパラメタをはめ込むことによって、選択をさらに制限するかもしれません。
When a domain border node receives the RSVP Path message for an inter-domain TE LSP setup, it MUST carry out the following procedures before it can forward the Path message to the next node along the path:
ドメイン境界ノードが相互ドメインTE LSPセットアップへのRSVP Pathメッセージを受け取るとき、経路に沿った次のノードにPathメッセージを転送できる前に以下の手順を行わなければなりません:
1. Apply policies for the domain and the domain border node.
These policies may restrict the establishment of inter-domain
TE LSPs. In case of a policy failure, the node SHOULD fail
the setup and send a PathErr message with error code "Policy
control failure"/ "Inter-domain policy failure".
1. ドメインとドメイン境界ノードのために方針を適用してください。 これらの方針は相互ドメインTE LSPsの設立を制限するかもしれません。 政策の失敗の場合には、ノードSHOULDはエラーコード「方針コントロール失敗」/「相互ドメイン政策の失敗」と共にセットアップに失敗して、PathErrメッセージを送ります。
Farrel, et al. Standards Track [Page 6] RFC 5151 Inter-Domain MPLS & GMPLS RSVP-TE Extensions February 2008
ファレル、他 標準化過程[6ページ]RFC5151相互ドメインMPLSとGMPLS RSVP-Te拡大2008年2月
2. Determine the signaling method to be used to cross the domain.
If the ingress node of the inter-domain TE LSP has specified
restrictions on the methods to be used, these MUST be adhered
to. Within the freedom allowed by the ingress node, the
domain border node MAY choose any method according to local
configuration and policies. If no resultant signaling method
is available or allowed, the domain border node MUST send a
PathErr message with an error code as described in Section
4.1.
2. ドメインに交差するのに使用されるべきシグナリング方法を決定してください。 相互ドメインTE LSPのイングレスノードが使用されるべき方法で制限を指定したなら、これらを固く守らなければなりません。 イングレスノードによって許容された自由の中では、地方の構成と方針によると、ドメイン境界ノードはどんな方法も選ぶかもしれません。 どんな結果のシグナリング方法も利用可能でなく、また許容されていないなら、ドメイン境界ノードはセクション4.1で説明されるようにエラーコードがあるPathErrメッセージを送らなければなりません。
Thus, for example, an ingress may request a contiguous LSP
because it wishes to exert maximal control over the LSP's path
and to control when reoptimization takes place. But the
operator of a transit domain may decide (for example) that
only LSP stitching is allowed for exactly the reason that it
gives the operator the chance to reoptimize their own domain
under their own control. In this case, the policy applied at
the entry to the transit domain will result in the return of a
PathErr message and the ingress has a choice to:
このようにして、例えば、それが、LSPの経路の最大限度のコントロールを及ぼして、「再-最適化」がいつ行われるかを制御したがっているのでイングレスは隣接のLSPを要求するかもしれません。 しかし、トランジットドメインのオペレータは、LSPステッチだけがそれら自身のコントロールの下のそれら自身のドメインを再最適化する機会をオペレータに与えるまさに理由で許されていると決めるかもしれません(例えば)。 この場合、エントリーでトランジットドメインに適用された方針はPathErrメッセージの復帰をもたらすでしょう、そして、イングレスは以下に選択を持っています。
- find another path avoiding the transit domain,
- relax his requirements, or
- fail to provide the service.
- または、別の経路がトランジットドメインを避けていると確かめてください--必要条件を緩めてください、--サービスを提供しないでください。
3. Carry out ERO procedures as described in Section 3 in addition
to the procedures in [RFC3209] and [RFC3473].
3. セクション3で[RFC3209]と[RFC3473]の手順に加えて説明されるようにERO手順を行ってください。
4. Perform any path computations as required to determine the
path across the domain and potentially to select the exit
point from the domain.
4. 必要に応じてどんな経路計算も実行して、ドメインの向こう側に経路を決定して、ドメインからエキジットポイントを潜在的に選択してください。
The path computation procedure is outside the scope of this
document. A path computation option is specified in
[RFC5152], and another option is to use a Path Computation
Element (PCE) [RFC4655].
このドキュメントの範囲の外に経路計算手順があります。 経路計算オプションは[RFC5152]で指定されます、そして、別のオプションはPath Computation Element(PCE)[RFC4655]を使用することです。
4a. In the case of nesting or stitching, either find an
existing intra-domain TE LSP to carry the inter-domain TE
LSP or signal a new one, depending on local policy.
4a。 巣ごもるか、またはステッチする場合では、相互ドメインTE LSPを運ぶために既存のイントラドメインTE LSPを見つけるか、または新しいものに合図してください、ローカルの方針によって。
In the event of a path computation failure, a PathErr message
SHOULD be sent with error code "Routing Problem" using an
error value selected according to the reason for computation
failure. A domain border node MAY opt to silently discard the
Path message in this case as described in Section 8.
経路計算失敗の場合、a PathErrはSHOULDを通信させます。計算失敗の理由に従って選択された誤り値を使用することにおけるエラーコード「ルート設定問題」と共に送ってください。 ドメイン境界ノードは、この場合セクション8で説明されるように静かにPathメッセージを捨てるために選ぶかもしれません。
Farrel, et al. Standards Track [Page 7] RFC 5151 Inter-Domain MPLS & GMPLS RSVP-TE Extensions February 2008
ファレル、他 標準化過程[7ページ]RFC5151相互ドメインMPLSとGMPLS RSVP-Te拡大2008年2月
In the event of the receipt of a PathErr message reporting signaling failure from within the domain or reported from a downstream domain, the domain border node MAY apply crankback procedures as described in Section 3.2. If crankback is not applied, or is exhausted, the border node MUST continue with PathErr processing as described in [RFC3209] and [RFC3473].
川下のドメインからドメインから失敗に合図すると報告するか、または報告されたPathErrメッセージの領収書の場合、ドメイン境界ノードはセクション3.2で説明されるようにcrankback手順を当てはまるかもしれません。 crankbackが適用されないか、または消耗しているなら、境界ノードは[RFC3209]と[RFC3473]で説明されるようにPathErr処理を続行しなければなりません。
In the event of successful processing of a Path or Resv message, the domain border node MUST carry out RRO procedures as described in Section 3.3.
PathかResvメッセージのうまくいっている処理の場合、ドメイン境界ノードはセクション3.3で説明されるようにRRO手順を行わなければなりません。
3.1. Rules on ERO Processing
3.1. ERO処理での規則
The ERO that a domain border node receives in the Path message was supplied by the ingress node of the TE LSP and may have been updated by other nodes (for example, other domain border nodes) as the Path message was propagated. The content of the ERO depends on several factors including:
Pathメッセージを伝播したとき、ドメイン境界ノードがPathメッセージで受けるEROをTE LSPのイングレスノードから供給して、他のノード(例えば、他のドメイン境界ノード)で、アップデートしたかもしれません。 依存して、:EROの内容はいくつかの要素に依存します。
- the path computation techniques used,
- the degree of TE visibility available to the nodes performing path
computation, and
- the policy at the nodes creating/modifying the ERO.
- そして、テクニックが使用した経路計算--経路計算を実行するノードに利用可能なTE目に見えることの度、--EROを作成するか、または変更するノードの方針。
In general, H-LSPs and LSP segments are used between domain border nodes, but there is no restriction on the use of such LSPs to span multiple hops entirely within a domain. Therefore, the discussion that follows may be equally applied to any node within a domain although the term "domain border node" continues to be used for clarity.
一般に、H-LSPsとLSPセグメントはドメイン境界ノードの間で使用されますが、複数のホップにかかるために、完全にドメインの中にそのようなLSPsの使用には制限が全くありません。 したがって、「ドメイン境界ノード」という用語は、明快に使用され続けていますが、続く議論は等しくドメインの中のどんなノードにも適用されるかもしれません。
When a Path message reaches the domain border node, the following rules apply for ERO processing and for further signaling.
Pathメッセージがドメイン境界ノードに達すると、以下の規則は、ERO処理とさらに合図するために申し込まれます。
1. If there are any policies related to ERO processing for the
LSP, they MUST be applied and corresponding actions MUST be
taken. For example, there might be a policy to reject EROs
that identify nodes within the domain. In case of
inter-domain LSP setup failures due to policy failures related
to ERO processing, the node SHOULD issue a PathErr with error
code "Policy control failure"/"Inter-domain explicit route
rejected", but MAY be configured to silently discard the Path
message or to return a different error code for security
reasons.
1. 何かLSPのためのERO処理に関連する方針があれば、それらを適用しなければなりません、そして、対応する行動を取らなければなりません。 例えば、ドメインの中でノードを特定するEROsを拒絶する方針があるかもしれません。 相互ドメインLSPセットアップの故障の場合には、政策の失敗が、「相互ドメインの明白なルートは拒絶した」エラーコード「方針コントロール失敗」/でERO処理、ノードSHOULD問題にPathErrに関連しますが、静かにPathメッセージを捨てるか、または安全保障上の理由で異なったエラーコードを返すために構成されますように。
Farrel, et al. Standards Track [Page 8] RFC 5151 Inter-Domain MPLS & GMPLS RSVP-TE Extensions February 2008
ファレル、他 標準化過程[8ページ]RFC5151相互ドメインMPLSとGMPLS RSVP-Te拡大2008年2月
2. Section 8.2 of [RFC4206] describes how a node at the edge of a
region processes the ERO in the incoming Path message and uses
this ERO, to either find an existing H-LSP or signal a new
H-LSP using the ERO hops. This process includes adjusting the
ERO before sending the Path message to the next hop. These
procedures MUST be followed for nesting or stitching of
inter-domain TE LSPs.
2. [RFC4206]のセクション8.2は、EROホップを使用することで領域の縁のノードがどう入って来るPathメッセージでEROを処理して、既存のH-LSPを見つけるか、または新しいH-LSPに合図するのにこのEROを使用するかを説明します。 この過程は、Pathメッセージを次のホップに送る前にEROを調整するのを含んでいます。 相互ドメインTE LSPsを入れ子にするか、またはステッチするためにこれらの手順に従わなければなりません。
3. If an ERO subobject identifies a TE link formed by the
advertisement of an H-LSP or LSP segment (whether numbered or
unnumbered), contiguous signaling MUST NOT be used. The node
MUST use either nesting or stitching according to the
capabilities of the LSP that forms the TE link, the parameters
signaled in the Path message, and local policy. If there is a
conflict between the capabilities of the LSP that forms the TE
link indicated in the ERO and the parameters on the Path
message, the domain border node SHOULD send a PathErr with
error code "Routing Problem"/"ERO conflicts with inter-domain
signaling method", but MAY be configured to silently discard
the Path message or to return a different error code for
security reasons.
3. ERO subobjectがH-LSPかLSPセグメントの広告で形成されたTEリンクを特定するなら(番号付である、または無数であることにかかわらず)、隣接のシグナリングを使用してはいけません。 ノードはTEリンク、Pathメッセージで合図されたパラメタを形成するLSPの能力、およびローカルの方針に従った巣篭もりかステッチのどちらかを使用しなければなりません。 形成するLSPの能力の間の闘争があれば、TEリンクは、Pathメッセージ、SHOULDがエラーコード「ルート設定問題」/があるPathErrを送るドメイン境界ノードに関するEROとパラメタで「EROは相互ドメインシグナリング方法と衝突します」と示しますが、静かにPathメッセージを捨てるか、または安全保障上の理由で異なったエラーコードを返すために構成されるかもしれません。
4. An ERO in a Path message received by a domain border node may
have a loose hop as the next hop. This may be an IP address
or an AS number. In such cases, the ERO MUST be expanded to
determine the path to the next hop using some form of path
computation that may, itself, generate loose hops.
4. ドメイン境界ノードによって受け取られたPathメッセージのEROには、次のホップとしてゆるいホップがあるかもしれません。 これは、IPアドレスかAS番号であるかもしれません。 そのような場合、何らかの形式の経路計算を使用することで次のホップに経路を決定するために広げられて、それはそうするかもしれません、それ自体ということであり、ERO MUSTはゆるいホップを発生させます。
5. In the absence of any ERO subobjects beyond the local domain
border node, the LSP egress (the destination encoded in the
RSVP Session object) MUST be considered as the next loose hop
and rule 4 applied.
5. 局所領域境界ノードを超えたどんなERO subobjectsが不在のとき、次のゆるいホップであるとLSP出口(RSVP Session物でコード化された目的地)をみなさなければなりませんでした、そして、規則4は申し込まれました。
6. In the event of any other failures processing the ERO, a
PathErr message SHOULD be sent as described in [RFC3209] or
[RFC3473], but a domain border router MAY be configured to
silently discard the Path message or to return a different
error code for security reasons.
6. ERO、PathErrメッセージを処理するいかなる他の失敗の場合も、[RFC3209]か[RFC3473]で説明されるようにSHOULDを送って、静かにPathメッセージを捨てるか、または安全保障上の理由で異なったエラーコードを返すためにドメイン境界ルータだけを構成してもよいです。
Farrel, et al. Standards Track [Page 9] RFC 5151 Inter-Domain MPLS & GMPLS RSVP-TE Extensions February 2008
ファレル、他 標準化過程[9ページ]RFC5151相互ドメインMPLSとGMPLS RSVP-Te拡大2008年2月
3.2. LSP Setup Failure and Crankback
3.2. LSPセットアップの失敗とCrankback
When an error occurs during LSP setup, a PathErr message is sent back towards the LSP ingress node to report the problem. If the LSP traverses multiple domains, this PathErr will be seen successively by each domain border node.
誤りがLSPセットアップの間発生するとき、PathErrメッセージは、問題を報告するためにLSPイングレスノードに向かって返送されます。 LSPが複数のドメインを横断すると、このPathErrは相次ぐそれぞれのドメイン境界ノードによって見られるでしょう。
Domain border nodes MAY apply local policies to restrict the propagation of information about the contents of the domain. For example, a domain border node MAY replace the information in a PathErr message that indicates a specific failure at a specific node with information that reports a more general error with the entire domain. These procedures are similar to those described for the borders of overlay networks in [RFC4208].
ドメイン境界ノードは、ドメインのコンテンツの情報の伝播を制限するためにローカルの方針を当てはまるかもしれません。 例えば、ドメイン境界ノードは特定のノードで全体のドメインで、より一般的な誤りを報告する情報で特定の失敗を示すPathErrメッセージの情報を置き換えるかもしれません。 これらの手順は[RFC4208]のオーバレイネットワークの境界に説明されたものと同様です。
However:
しかしながら:
- A domain border node MUST NOT suppress the propagation of a PathErr
message except to attempt rerouting as described below.
- 以下で説明されるようにコースを変更するのを試みる以外に、ドメイン境界ノードはPathErrメッセージの伝播を抑圧してはいけません。
- Nodes other than domain border nodes SHOULD NOT modify the contents
of a PathErr message.
- ドメイン境界ノードSHOULD NOT以外のノードはPathErrメッセージのコンテンツを変更します。
- Domain border nodes SHOULD NOT modify the contents of a PathErr
message unless domain confidentiality is a specific requirement.
- ドメイン境界ノードSHOULD NOTはドメイン秘密性が決められた一定の要求でないならPathErrメッセージのコンテンツを変更します。
Domain border nodes provide an opportunity for crankback rerouting [RFC4920]. On receipt of a PathErr message generated because of an LSP setup failure, a domain border node MAY hold the PathErr and make further attempts to establish the LSP if allowed by local policy and by the parameters signaled on the Path message for the LSP. Such attempts might involve the computation of alternate routes through the domain, or the selection of different downstream domains. If a subsequent attempt is successful, the domain border router MUST discard the held PathErr message, but if all subsequent attempts are unsuccessful, the domain border router MUST send the PathErr upstream toward the ingress node. In this latter case, the domain border router MAY change the information in the PathErr message to provide further crankback details and information aggregation as described in [RFC4920].
ドメイン境界ノードはcrankbackのコースを変更すること[RFC4920]に機会を与えます。 LSPセットアップの故障のために発生するPathErrメッセージを受け取り次第、ローカルの方針とLSPへのPathメッセージで合図されたパラメタによって許容されているなら、ドメイン境界ノードは、PathErrを持って、LSPを設立するさらなる試みをするかもしれません。 そのような試みはドメインを通した代替経路の計算、または異なった川下のドメインの品揃えにかかわるかもしれません。 その後の試みがうまくいくなら、ドメイン境界ルータは保持されたPathErrメッセージを捨てなければなりませんが、すべてのその後の試みが失敗しているなら、ドメイン境界ルータはイングレスノードに向かってPathErr上流を送らなければなりません。 この後者の場合では、ドメイン境界ルータは[RFC4920]で説明されるようにさらなるcrankbackの詳細と情報集合を提供するPathErrメッセージの情報を変えるかもしれません。
Crankback rerouting MAY also be used to handle the failure of LSPs after they have been established [RFC4920].
また、Crankbackのコースを変更することは、彼らが設立された[RFC4920]後にLSPsの失敗を扱うのに使用されるかもしれません。
Farrel, et al. Standards Track [Page 10] RFC 5151 Inter-Domain MPLS & GMPLS RSVP-TE Extensions February 2008
ファレル、他 標準化過程[10ページ]RFC5151相互ドメインMPLSとGMPLS RSVP-Te拡大2008年2月
3.3. RRO Processing across Domains
3.3. ドメイン中のRRO処理
[RFC3209] defines the RRO as an optional object used for loop detection and for providing information about the hops traversed by LSPs.
[RFC3209]はLSPsによって横断されたホップに関して輪の検出と情報を提供するのに使用される任意の物とRROを定義します。
As described for overlay networks in [RFC4208], a domain border node MAY filter or modify the information provided in an RRO for confidentiality reasons according to local policy. For example, a series of identifiers of hops within a domain MAY be replaced with the domain identifier (such as the AS number) or be removed entirely leaving just the domain border nodes.
[RFC4208]のオーバレイネットワークのために説明されるように、ドメイン境界ノードは、ローカルの方針に応じて秘密性理由でRROに提供された情報を、フィルターにかけるか、または変更するかもしれません。 例えば、ドメインの中のホップに関する一連の識別子をドメイン識別子(AS番号などの)に取り替えるかもしれませんか、またはまさしくドメイン境界ノードを完全に残して、取り除いてください。
Note that a domain border router MUST NOT mask its own presence, and MUST include itself in the RRO.
ドメイン境界ルータがそれ自身の存在にマスクをかけてはいけなくて、RROにそれ自体を含まなければならないことに注意してください。
Such filtering of RRO information does not hamper the working of the signaling protocol, but the subsequent information loss may render management diagnostic procedures inoperable or at least make them more complicated, requiring the coordination of administrators of multiple domains.
RRO情報のそのようなフィルタリングがシグナリングプロトコルの働きを妨げませんが、その後の情報の損失で、管理の診断手順を手術不能に表すか、またはそれらを少なくともさらに複雑にするかもしれません、複数のドメインの管理者のコーディネートを必要として。
Similarly, protocol procedures that depend on the presence of RRO information may become inefficient. For example, the Fast Reroute procedures defined in [RFC4090] use information in the RRO to determine the labels to use and the downstream MP.
同様に、RRO情報の存在に依存するプロトコル手順は効率が悪くなるかもしれません。 例えば、Fast Reroute手順は、使用するラベルと川下のMPを決定するために[RFC4090]使用でRROの情報を定義しました。
3.4. Notify Message Processing
3.4. メッセージ処理に通知してください。
Notify messages are introduced in [RFC3473]. They may be sent direct rather than hop-by-hop, and so may speed the propagation of error information. If a domain border router is interested in seeing such messages (for example, to enable it to provide protection switching), it is RECOMMENDED that the domain border router update the Notify Request objects in the Path and Resv messages to show its own address following the procedures of [RFC3473].
メッセージに通知してください。[RFC3473]では、紹介されます。 彼らは、ホップで飛び越すよりむしろダイレクトに送るかもしれないので、エラー情報の伝播を促進するかもしれません。 ドメイン境界ルータがそのようなメッセージ(例えば保護の切り換えを提供するのを可能にする)を見たいなら、ドメイン境界ルータがPathとそれ自身のアドレスが[RFC3473]の手順に従うのを示すResvメッセージでNotify Request物をアップデートするのは、RECOMMENDEDです。
Note that the replacement of a Notify Recipient in the Notify Request object means that some Notify messages (for example, those intended for delivery to the ingress LSR) may need to be examined, processed, and forwarded at domain borders. This is an obvious trade-off issue as the ability to handle notifiable events locally (i.e., within the domain) may or may not outweigh the cost of processing and forwarding Notify messages beyond the domain. Observe that the cost increases linearly with the number of domains in use.
Notify Request物でのNotify Recipientの交換が、いくつかのNotifyメッセージ(例えば配送のためにイングレスLSRに意図するもの)がドメイン境界で調べられて、処理されて、進められる必要であるかもしれないことを意味することに注意してください。 局所的(すなわち、ドメインの中で)に通知すべき出来事を扱う能力が処理とドメインを超えてメッセージをNotifyに転送する費用より重いかもしれないので、これは明白なトレードオフ問題です。 ドメインの数が使用中の状態でコスト増が直線的であることを観測してください。
Farrel, et al. Standards Track [Page 11] RFC 5151 Inter-Domain MPLS & GMPLS RSVP-TE Extensions February 2008
ファレル、他 標準化過程[11ページ]RFC5151相互ドメインMPLSとGMPLS RSVP-Te拡大2008年2月
Also note that, as described in Section 8, a domain administrator may wish to filter or modify Notify messages that are generated within a domain in order to preserve security or confidentiality of network information. This is most easily achieved if the Notify messages are sent via the domain borders.
また、ドメイン管理者がネットワーク情報のセキュリティか秘密性を保持するためにドメインの中で発生するNotifyメッセージをフィルターにかけたいか、またはセクション8で説明されるように変更したがっているかもしれないことに注意してください。 ドメイン境界を通してNotifyメッセージを送るなら、最も容易にこれを達成します。
4. RSVP-TE Signaling Extensions
4. RSVP-Teシグナリング拡大
The following RSVP-TE signaling extensions are defined to enable inter-domain LSP setup.
以下のRSVP-TEシグナリング拡張子は、相互ドメインLSPセットアップを可能にするために定義されます。
4.1. Control of Choice of Signaling Method
4.1. 方法に合図することの選択のコントロール
In many network environments, there may be a network-wide policy that determines which one of the three inter-domain LSP techniques is used. In these cases, no protocol extensions are required.
多くのネットワーク環境には、それが決定する3つの相互ドメインLSPのテクニックで使用されたネットワーク全体の方針があるかもしれません。 これらの場合では、プロトコル拡大は全く必要ではありません。
However, in environments that support more than one technique, an ingress node may wish to constrain the choice made by domain border nodes for each inter-domain TE LSP that it originates.
しかしながら、1つ以上のテクニックをサポートする環境でイングレスノードはそれが溯源するそれぞれの相互ドメインTE LSPのためのドメイン境界ノードによってされた選択を抑制したがっているかもしれません。
[RFC4420] defines the LSP_Attributes object that can be used to signal required attributes of an LSP. The Attributes Flags TLV includes Boolean flags that define individual attributes.
[RFC4420]はLSPの必要な属性に合図するのに使用できるLSP_Attributes物を定義します。 Attributes Flags TLVは個々の属性を定義するブール旗を含んでいます。
This document defines a new bit in the TLV that can be set by the ingress node of an inter-domain TE LSP to restrict the intermediate nodes to using contiguous signaling:
このドキュメントは相互ドメインTE LSPのイングレスノードで中間的ノードを隣接のシグナリングを使用するのに制限するように用意ができることができるTLVで新しいビットを定義します:
Contiguous LSP bit (bit number assignment in Section 9.1)
隣接のLSPビット(セクション9.1の噛み付いている数の課題)
This flag is set by the ingress node that originates a Path message to set up an inter-domain TE LSP if it requires that the contiguous LSP technique is used. This flag bit is only to be used in the Attributes Flags TLV.
この旗は隣接のLSPのテクニックが使用されているのが必要であるなら相互ドメインTE LSPをセットアップするPathメッセージを溯源するイングレスノードによって設定されます。 このフラグビットはAttributes Flags TLVで単に使用されることです。
When a domain border LSR receives a Path message containing this bit set (one), the node MUST NOT perform stitching or nesting in support of the inter-domain TE LSP being set up. When this bit is clear (zero), a domain border LSR MAY perform stitching or nesting according to local policy.
ドメイン境界であるときに、LSRはこの噛み付いているセット(1)を含むPathメッセージを受け取って、ノードはセットアップされる相互ドメインTE LSPを支持してステッチか巣篭もりを実行してはいけません。 このビットが明確であるときに(ゼロ)、LSR MAYが実行するローカルの方針によると、ステッチするか、または巣ごもるドメイン境界です。
This bit MUST NOT be modified by any transit node.
このビットはどんなトランジットノードによっても変更されてはいけません。
Farrel, et al. Standards Track [Page 12] RFC 5151 Inter-Domain MPLS & GMPLS RSVP-TE Extensions February 2008
ファレル、他 標準化過程[12ページ]RFC5151相互ドメインMPLSとGMPLS RSVP-Te拡大2008年2月
An intermediate node that supports the LSP_Attributes object and the Attributes Flags TLV, and also recognizes the "Contiguous LSP" bit, but cannot support contiguous TE LSPs, MUST send a Path Error message with an error code "Routing Problem"/"Contiguous LSP type not supported" if it receives a Path message with this bit set.
このビットがセットした状態でそれがPathメッセージを受け取るなら、LSP_Attributes物とAttributes Flags TLVを支えて、また、「隣接のLSP」ビットを認識しますが、隣接のTE LSPsは支えることができない中間的ノードが、「隣接のLSPタイプは支持しなかった」エラーコード「ルート設定問題」/があるPath Errorメッセージを送らなければなりません。
If an intermediate node receiving a Path message with the "Contiguous LSP" bit set in the Flags field of the LSP_Attributes, recognizes the object, the TLV, and the bit and also supports the desired contiguous LSP behavior, then it MUST signal a contiguous LSP. If the node is a domain border node, or if the node expands a loose hop in the ERO, it MUST include an RRO Attributes subobject in the RRO of the corresponding Resv message (if such an object is present) with the "Contiguous LSP" bit set to report its behavior.
「隣接のLSP」ビットでPathメッセージを受け取る中間的ノードがLSP_AttributesのFlags分野にセットして、物、TLV、およびビットを認識して、また、必要な隣接のLSPの振舞いを支えるなら、それは隣接のLSPに合図しなければなりません。 ノードがドメイン境界ノードである、またはノードがEROでゆるいホップを広くするなら、それは対応するResvメッセージ(そのような物が存在しているなら)のRROに振舞いを報告するように設定された「隣接のLSP」ビットでRRO Attributes subobjectを含まなければなりません。
Domain border LSRs MUST support and act on the setting of the "Contiguous LSP" flag.
ドメイン境界LSRsは「隣接のLSP」旗の設定を支持して、影響しなければなりません。
However, if the intermediate node supports the LSP_Attributes object but does not recognize the Attributes Flags TLV, or supports the TLV but does not recognize this "Contiguous LSP" bit, then it MUST forward the object unmodified.
しかしながら、中間的ノードがLSP_Attributes物を支えますが、Attributes Flags TLVを認識しないか、TLVを支持しますが、またはこの「隣接のLSP」ビットを認識しないなら、それは変更されていなく物を進めなければなりません。
The choice of action by an ingress node that receives a PathErr when requesting the use of a contiguous LSP is out of the scope of this document, but may include the computation of an alternate path.
隣接のLSPの使用を要求するときPathErrを受けるイングレスノードによる動作の選択は、このドキュメントの範囲の外にありますが、代替パスの計算を含むかもしれません。
5. Protection and Recovery of Inter-Domain TE LSPs
5. 相互ドメインTe LSPsの保護と回復
The procedures described in Sections 3 and 4 MUST be applied to all inter-domain TE LSPs, including bypass tunnels, detour LSPs [RFC4090], and segment recovery LSPs [RFC4873]. This means that these LSPs will also be subjected to ERO processing, policies, path computation, etc.
セクション3と4で説明された手順をすべての相互ドメインTE LSPsに適用しなければなりません、迂回トンネル、回り道LSPs[RFC4090]、およびセグメント回復LSPs[RFC4873]を含んでいて。 これは、また、これらのLSPsがERO処理、方針、経路計算などにかけられることを意味します。
Note also that the paths for these backup LSPs need to be either pre-configured, computed, and signaled with the protected LSP or computed on-demand at the PLR. Just as with any inter-domain TE LSP, the ERO may comprise strict or loose hops and will depend on the TE visibility of the computation point into the subsequent domain.
また、これらのための経路がPLRで要求次第であらかじめ設定されるべきであるか、計算された、保護されたLSPと共に合図されるべきであるか、または計算されるべきLSPsの必要性のバックアップをとることに注意してください。 ちょうどどんな相互ドメインTE LSPの場合も、EROは厳しいかゆるいホップを包括するかもしれなくて、その後のドメインへの計算ポイントのTE目に見えることによるでしょう。
If loose hops are present in the path of the backup LSP, ERO expansion will be required at some point along the path: probably at a domain border node. In order that the backup path remains disjoint from the protected LSP(s) the node performing the ERO expansion must
ゆるいホップがバックアップLSPの経路に存在していると、ERO拡大が経路に沿った何らかのポイントで必要でしょう: たぶんドメインでは、ノードに接してください。 バックアップ経路の残りが保護されたLSP(s)からERO拡大がばらばらにならせなければならないノード実行をばらばらにならせるように
Farrel, et al. Standards Track [Page 13] RFC 5151 Inter-Domain MPLS & GMPLS RSVP-TE Extensions February 2008
ファレル、他 標準化過程[13ページ]RFC5151相互ドメインMPLSとGMPLS RSVP-Te拡大2008年2月
be provided with the path of the protected LSPs between the PLR and the MP. This information can be gathered from the RROs of the protected LSPs and is signaled in the DETOUR object for Fast Reroute [RFC4090] and uses route exclusion [RFC4874] for other protection schemes.
PLRとMPの間の保護されたLSPsの経路を提供してください。 この情報は、保護されたLSPsのRROsから集まることができて、Fast Reroute[RFC4090]のためにDETOUR物に示されて、他の保護計画に、ルート除外[RFC4874]を使用します。
5.1. Fast Recovery Support Using MPLS-TE Fast Reroute (FRR)
5.1. 速くMPLS-Teを使用する速い回復支援がコースを変更します。(FRR)
[RFC4090] describes two methods for local protection for a packet TE LSP in case of link, Shared Risk Link Group (SRLG), or node failure. This section describes how these mechanisms work with the proposed signaling solutions for inter-domain TE LSP setup.
[RFC4090]はリンク、Shared Risk Link Group(SRLG)、またはノード障害の場合にパケットTE LSPのために地方の保護のための2つの方法を説明します。 このセクションはこれらのメカニズムが相互ドメインTE LSPセットアップの提案されたシグナリング解決でどう動作するかを説明します。
5.1.1. Failure within a Domain (Link or Node Failure)
5.1.1. ドメインの中の失敗(リンクかノード障害)
The mode of operation of MPLS-TE Fast Reroute to protect a contiguous, stitched, or nested TE LSP within a domain is identical to the existing procedures described in [RFC4090]. Note that, in the case of nesting or stitching, the end-to-end LSP is automatically protected by the protection operation performed on the H-LSP or stitching segment LSP.
ドメインの中に隣接の、または、ステッチされたか、入れ子にされたTE LSPを保護するMPLS-TE Fast Rerouteの運転モードは[RFC4090]で説明された既存の手順と同じです。 終わりから終わりへのLSPが巣ごもるか、またはステッチする場合で自動的にH-LSPに実行されるか、またはセグメントLSPをステッチする保護操作で保護されることに注意してください。
No protocol extensions are required.
プロトコル拡大は全く必要ではありません。
5.1.2. Failure of a Link at a Domain Border
5.1.2. ドメイン境界のリンクの失敗
This case arises where two domains are connected by a TE link. In this case, each domain has its own domain border node, and these two nodes are connected by the TE link. An example of this case is where the ASBRs of two ASs are connected by a TE link.
本件は2つのドメインがTEリンクによってつなげられるところに起こります。 この場合、各ドメインには、それ自身のドメイン境界ノードがあります、そして、これらの2つのノードがTEリンクによって接続されます。 本件に関する例は2ASsのASBRsがTEリンクによって接続されるところです。
A contiguous LSP can be backed up using any PLR and MP, but if the LSP uses stitching or nesting in either of the connected domains, the PLR and MP MUST be domain border nodes for those domains. It will be usual to attempt to use the local (connected by the failed link) domain border nodes as the PLR and MP.
どんなPLRとMPも使用することで隣接のLSPを支援できますが、LSPが接続ドメインのどちらかでステッチか巣篭もりを使用するなら、PLRとMPはそれらのドメインのためのドメイン境界ノードでなければなりません。 PLRとMPとしてローカル(失敗したリンクで、接続される)のドメイン境界ノードを使用するのを試みるのは普通でしょう。
To protect an inter-domain link with MPLS-TE Fast Reroute, a set of backup tunnels must be configured or dynamically computed between the PLR and MP such that they are diversely routed from the protected inter-domain link and the protected inter-domain LSPs.
MPLS-TE Fast Rerouteとの相互ドメインリンクを保護するために、1セットのバックアップトンネルを構成されなければならないか、またはPLRとMPの間でダイナミックに計算しなければならないので、それらは保護された相互ドメインリンクと保護された相互ドメインLSPsからさまざまに発送されます。
Each protected inter-domain LSP using the protected inter-domain TE link must be assigned to an NHOP bypass tunnel that is diverse from the protected LSP. Such an NHOP bypass tunnel can be selected by analyzing the RROs in the Resv messages of the available bypass
保護された相互ドメインTEリンクを使用するそれぞれの保護された相互ドメインLSPを保護されたLSPからさまざまのNHOP迂回トンネルに割り当てなければなりません。 利用可能な迂回に関するResvメッセージでRROsを分析することによって、そのようなNHOP迂回トンネルを選択できます。
Farrel, et al. Standards Track [Page 14] RFC 5151 Inter-Domain MPLS & GMPLS RSVP-TE Extensions February 2008
ファレル、他 標準化過程[14ページ]RFC5151相互ドメインMPLSとGMPLS RSVP-Te拡大2008年2月
tunnels and the protected TE LSP. It may be helpful to this process if the extensions defined in [RFC4561] are used to clearly distinguish nodes and links in the RROs.
トンネルと保護されたTE LSP。 [RFC4561]で定義された拡張子がRROsで明確にノードとリンクを区別するのに使用されるなら、この過程に役立っているかもしれません。
5.1.3. Failure of a Border Node
5.1.3. 境界ノードの失敗
Two border node failure cases exist. If the domain border falls on a link as described in the previous section, the border node at either end of the link may fail. Alternatively, if the border falls on a border node (as is the case with IGP areas), that single border node may fail.
2件の国境のノード障害事件が存在しています。 ドメイン境界が前項で説明されるようにリンクに落ちるなら、リンクのどちらかの端の境界ノードは失敗するかもしれません。 あるいはまた、境界が境界ノードに落ちるなら(IGP領域に関してそうであるように)、そのただ一つの境界ノードは失敗するかもしれません。
It can be seen that if stitching or nesting is used, the failed node will be the start or end (or both) of a stitching segment LSP or H-LSP, in which case protection must be provided to the far end of the stitching segment or H-LSP. Thus, where one of these two techniques is in use, the PLR will be the upstream domain entry point in the case of the failure of the domain exit point, and the MP will be the downstream domain exit point in the case of the failure of the domain entry point. Where the domain border falls at a single domain border node, both cases will apply.
ステッチか巣篭もりが使用されているなら、失敗したノードが始めになるか、またはステッチセグメントの終わり(ともに)がLSPかH-LSPであると考えることができて、その場合、ステッチしているセグメントかH-LSPの遠端に保護を提供しなければなりません。 したがって、PLRはドメインエキジットポイントの失敗に関するケースでこれらの2つのテクニックの1つが使用中であるところで上流のドメインエントリー・ポイントになるでしょう、そして、MPはドメインエントリー・ポイントの失敗の場合で川下のドメインエキジットポイントになるでしょう。 ドメイン境界が単一領域境界ノードに落ちるところでは、両方のケースは適用されるでしょう。
If the contiguous LSP mechanism is in use, normal selection of the PLR and MP can be applied, and any node within the domains may be used to fill these roles.
隣接のLSPメカニズムが使用中であるなら、PLRとMPの通常の選択を適用できます、そして、ドメインの中のどんなノードも、これらの役割をいっぱいにするのに使用されるかもしれません。
As before, selection of a suitable backup tunnel (in this case, an NNHOP backup) must consider the paths of the backed-up LSPs and the available NNHOP tunnels by examination of their RROs.
従来と同様、適当なバックアップトンネル(この場合NNHOPバックアップ)の選択はそれらのRROsの試験で支持されて上がっているLSPsと利用可能なNNHOPトンネルの経路を考えなければなりません。
Note that where the PLR is not immediately upstream of the failed node, error propagation time may be delayed unless some mechanism such as [BFD-MPLS] is implemented or unless direct reporting, such as through the GMPLS Notify message [RFC3473], is employed.
[BFD-MPLS]などの何らかのメカニズムが実行されないか、またはGMPLS Notifyメッセージなどのダイレクト報告[RFC3473]が採用していない場合PLRがすぐに上流でないところで失敗したノードでは、誤り伝播時間が遅れるかもしれないことに注意してください。
5.2. Protection and Recovery of GMPLS LSPs
5.2. GMPLS LSPsの保護と回復
[RFC4873] describes GMPLS-based segment recovery. This allows protection against a span failure, a node failure, or failure over any particular portion of a network used by an LSP.
[RFC4873]はGMPLSベースのセグメント回復について説明します。 これはLSPによって使用されたネットワークのどんな特定の部分にわたっても長さの故障、ノード障害、または失敗に対する保護を許します。
The domain border failure cases described in Section 5.1 may also occur in GMPLS networks (including packet networks) and can be protected against using segment protection without any additional protocol extensions.
セクション5.1で説明されたドメイン国境の失敗事件は、また、GMPLSネットワーク(パケット網を含んでいる)で起こるかもしれなくて、少しも追加議定書拡大なしでセグメント保護を使用することで守ることができます。
Farrel, et al. Standards Track [Page 15] RFC 5151 Inter-Domain MPLS & GMPLS RSVP-TE Extensions February 2008
ファレル、他 標準化過程[15ページ]RFC5151相互ドメインMPLSとGMPLS RSVP-Te拡大2008年2月
Note that if loose hops are used in the construction of the working and protection paths signaled for segment protection, then care is required to keep these paths disjoint. If the paths are signaled incrementally, then route exclusion [RFC4874] may be used to ensure that the paths are disjoint. Otherwise, a coordinated path computation technique such as that offered by cooperating Path Computation Elements [RFC4655] can provide suitable paths.
ゆるいホップが働きの構造に使用されるか、そして、経路がこれらの経路を保つのに必要であるとセグメント保護、当時の注意に合図される保護がばらばらになることに注意してください。 経路が増加して合図されるなら、ルート除外[RFC4874]は使用されて、経路がそうであることを保証するのがばらばらになるということであるかもしれません。 さもなければ、協力関係を持っているPath Computation Elements[RFC4655]によって提供されたそれなどの連携経路計算のテクニックは適当な経路を提供できます。
6. Reoptimization of Inter-Domain TE LSPs
6. 相互ドメインTe LSPsのReoptimization
Reoptimization of a TE LSP is the process of moving the LSP from the current path to a more preferred path. This involves the determination of the preferred path and make-before-break signaling procedures [RFC3209] to minimize traffic disruption.
TE LSPのReoptimizationは現在の経路から、より都合のよい経路へLSPを移す過程です。 これは都合のよい経路と以前開閉しているシグナリング手順[RFC3209]が交通分裂を最小にする決断にかかわります。
Reoptimization of an inter-domain TE LSP may require a new path in more than one domain.
相互ドメインTE LSPのReoptimizationは1つ以上のドメインで新しい経路を必要とするかもしれません。
The nature of the inter-domain LSP setup mechanism defines how reoptimization can be applied. If the LSP is contiguous, then the signaling of the make-before-break process MUST be initiated by the ingress node as defined in [RFC3209]. But if the reoptimization is limited to a change in path within one domain (that is, if there is no change to the domain border nodes) and nesting or stitching is in use, the H-LSP or stitching segment may be independently reoptimized within the domain without impacting the end-to-end LSP.
相互ドメインLSPセットアップメカニズムの本質はどう「再-最適化」を適用できるかを定義します。 LSPが隣接であるなら、[RFC3209]で定義されるイングレスノードで以前開閉している過程のシグナリングを開始しなければなりません。 しかし、「再-最適化」が1つのドメインの中の経路の変化に制限されて(すなわち、ドメイン境界ノードへの変化が全くなければ)、巣篭もりかステッチが使用中であるなら、H-LSPかステッチセグメントが終わりから終わりへのLSPに影響を与えることのないドメインの中で独自に再最適化されるかもしれません。
In all cases, however, the ingress LSR may wish to exert control and coordination over the reoptimization process. For example, a transit domain may be aware of the potential for reoptimization, but not bother because it is not worried by the level of service being provided across the domain. But the cumulative effect on the end-to-end LSP may cause the head-end to worry and trigger an end-to-end reoptimization request (of course, the transit domain may choose to ignore the request).
しかしながら、すべての場合では、イングレスLSRは「再-最適化」の過程の上のコントロールとコーディネートを及ぼしたがっているかもしれません。 例えば、トランジットドメインは、ドメインの向こう側に提供されるサービスのレベルで心配しないので、「再-最適化」の可能性を意識していますが、苦しめないかもしれません。 しかし、終わりから終わりへのLSPへの累積している効果は、ギヤエンドが心配して、終わりから終わりへの「再-最適化」要求の引き金となることを引き起こすかもしれません(もちろん、トランジットドメインは要求を無視するのを選ぶかもしれません)。
Another benefit of end-to-end reoptimization over per-domain reoptimization for non-contiguous inter-domain LSPs is that per-domain reoptimization is restricted to preserve the domain entry and exit points (since to do otherwise would break the LSP!). But end-to-end reoptimization is more flexible and can select new domain border LSRs.
非隣接の相互ドメインLSPsのための1ドメインあたりの「再-最適化」の上の終わりから終わりへの「再-最適化」の別の利益は1ドメインあたりの「再-最適化」がドメインエントリーとエキジットポイントを保持するために制限されるという(別の方法でするのはLSPを壊すでしょう、したがって!)ことです。 しかし、終わりから終わりへの「再-最適化」は、よりフレキシブルであり、新しいドメイン境界LSRsを選択できます。
Farrel, et al. Standards Track [Page 16] RFC 5151 Inter-Domain MPLS & GMPLS RSVP-TE Extensions February 2008
ファレル、他 標準化過程[16ページ]RFC5151相互ドメインMPLSとGMPLS RSVP-Te拡大2008年2月
There may be different cost-benefit analysis considerations between end-to-end reoptimization and per-domain reoptimization. The greater the number of hops involved in the reoptimization, the higher the risk of traffic disruption. The shorter the segment reoptimized, the lower the chance of making a substantial improvement on the quality of the end-to-end LSP. Administrative policies should be applied in this area with care.
終わりから終わりへの「再-最適化」と1ドメインあたりの「再-最適化」の間には、異なった費用・便益分析問題があるかもしれません。 「再-最適化」にかかわるホップの数が大きければ大きいほど、交通分裂のリスクは、より高いです。 再最適化されたセグメントが短ければ短いほど、終わりから終わりの品質より実質的な改善をLSPにするという機会はさらに低いです。 施政方針はこの領域で慎重に適用されるべきです。
[RFC4736] describes mechanisms that allow:
[RFC4736]は以下を許容するメカニズムについて説明します。
- The ingress node to request each node with a loose next hop to
re-evaluate the current path in order to search for a more optimal
path.
- より最適の経路を捜し求めるために現在の経路を再評価するよう次のゆるいホップがある各ノードに要求するイングレスノード。
- A node with a loose next hop to inform the ingress node that a
better path exists.
- より良い経路が存在することをイングレスノードに知らせる次のゆるいホップがあるノード。
These mechanisms SHOULD be used for reoptimization of a contiguous inter-domain TE LSP.
これらのメカニズムSHOULD、隣接の相互ドメインTE LSPの「再-最適化」には、使用されてください。
Note that end-to-end reoptimization may involve a non-local modification that might select new entry / exit points. In this case, we can observe that local reoptimization is more easily and flexibly achieved using nesting or stitching. Further, the "locality principle" (i.e., the idea of keeping information only where it is needed) is best achieved using stitching or nesting. That said, a contiguous LSP can easily be modified to take advantage of local reoptimizations (as defined in [RFC4736]) even if this would require the dissemination of information and the invocation of signaling outside the local domain.
終わりから終わりへの「再-最適化」が新しいエントリー/エキジットポイントを選択するかもしれない非地方の変更にかかわるかもしれないことに注意してください。 この場合、私たちは、地方の「再-最適化」が巣篭もりかステッチを使用することで、より簡単に柔軟に達成されるのを観測できます。 さらに、ステッチか巣篭もりを使用することで「局所性の原則」(すなわち、それがどこだけで必要であるかという情報を保つという考え)を達成するのは最も良いです。 それは言って、これが情報の普及と局所領域の外で合図する実施を必要としても、地方の「再-最適化」([RFC4736]で定義されるように)を利用するように容易に隣接のLSPは変更できます。
7. Backward Compatibility
7. 後方の互換性
The procedures in this document are backward compatible with existing deployments.
手順は本書では既存の展開と互換性があった状態で後方です。
- Ingress LSRs are not required to support the extensions in this
document to provision intra-domain LSPs. The default behavior by
transit LSRs that receive a Path message that does not have the
"Contiguous LSP" bit set in the Attributes Flags TLV of the
LSP_Attributes object or does not even have the object present is
to allow all modes of inter-domain TE LSP, so back-level ingress
LSRs are able to initiate inter-domain LSPs.
- イングレスLSRsは本書では支給イントラドメインLSPsに拡大を支持する必要はありません。 LSP_Attributes物のAttributes Flags TLVに「隣接のLSP」ビットを設定させないか、または物のプレゼントを持ってさえいないPathメッセージを受け取るトランジットLSRsによるデフォルトの振舞いは相互ドメインTE LSPのすべてのモードを許容することです、非常に逆レベルであるので、イングレスLSRsは相互ドメインLSPsを開始できます。
- Transit, non-border LSRs are not required to perform any special
processing and will pass the LSP_Attributes object onwards
unmodified according to the rules of [RFC2205]. Thus, back-level
transit LSRs are fully supported.
- トランジット、非境界LSRsはどんな特別な処理も実行するのが必要でなく、前方へ[RFC2205]の規則に従って変更されていなくLSP_Attributes物を渡すでしょう。 したがって、逆レベルトランジットLSRsは完全に支持されます。
Farrel, et al. Standards Track [Page 17] RFC 5151 Inter-Domain MPLS & GMPLS RSVP-TE Extensions February 2008
ファレル、他 標準化過程[17ページ]RFC5151相互ドメインMPLSとGMPLS RSVP-Te拡大2008年2月
- Domain border LSRs will need to be upgraded before inter-domain TE
LSPs are allowed. This is because of the need to establish policy,
administrative, and security controls before permitting
inter-domain LSPs to be signaled across a domain border. Thus,
legacy domain border LSRs do not need to be considered.
- ドメイン境界LSRsは、相互ドメインTE LSPsが許容される前にアップグレードする必要があるでしょう。 これは方針を確立する必要性のためにあります、管理であり、セキュリティは相互ドメインLSPsがドメイン境界の向こう側に合図されることを許可する前に、制御されます。 したがって、遺産ドメイン境界LSRsは考えられる必要はありません。
The RRO additions in this document are fully backward compatible.
RRO追加は本書では完全に後方です。互換性がある。
8. Security Considerations
8. セキュリティ問題
RSVP does not currently provide for automated key management. [RFC4107] states a requirement for mandatory automated key management under certain situations. There is work starting in the IETF to define improved authentication including automated key management for RSVP. Implementations and deployments of RSVP should pay attention to any capabilities and requirements that are outputs from this ongoing work.
RSVPは現在、自動化されたかぎ管理に備えません。 [RFC4107]は義務的な自動化されたある状況の下でのかぎ管理のための要件を述べます。 RSVPのための自動化されたかぎ管理を含んでいて、IETFで改良された認証を定義し始める仕事があります。 RSVPの実現と展開はこの進行中の仕事から出力であるどんな能力と要件にも注意を向けるべきです。
A separate document is being prepared to examine the security aspects of RSVP-TE signaling with special reference to multi-domain scenarios [MPLS-SEC]. [RFC4726] provides an overview of the requirements for security in an MPLS-TE or GMPLS multi-domain environment.
別々のドキュメントはマルチドメインシナリオ[MPLS-SEC]の特別な参照でRSVP-TEシグナリングのセキュリティ局面を調べるように準備されています。 [RFC4726]はセキュリティのためのMPLS-TEかGMPLSマルチドメイン環境における要件の概観を提供します。
Before electing to utilize inter-domain signaling for MPLS-TE, the administrators of neighboring domains MUST satisfy themselves as to the existence of a suitable trust relationship between the domains. In the absence of such a relationship, the administrators SHOULD decide not to deploy inter-domain signaling, and SHOULD disable RSVP-TE on any inter-domain interfaces.
相互ドメインシグナリングをMPLS-TEに利用するのを選ぶ前に、隣接しているドメインの管理者はドメインの間の適当な信用関係の存在に関して納得しなければなりません。 そのような関係、SHOULDがそうしないと決める管理者が不在のとき、相互ドメインシグナリングを配備してください。そうすれば、SHOULDはどんな相互ドメイン界面のRSVP-TEも無効にします。
When signaling an inter-domain RSVP-TE LSP, an operator MAY make use of the security features already defined for RSVP-TE [RFC3209]. This may require some coordination between the domains to share the keys (see [RFC2747] and [RFC3097]), and care is required to ensure that the keys are changed sufficiently frequently. Note that this may involve additional synchronization, should the domain border nodes be protected with FRR, since the MP and PLR should also share the key.
相互ドメインRSVP-TE LSPに合図するとき、オペレータはRSVP-TE[RFC3209]のために既に定義されたセキュリティ機能を利用するかもしれません。 これはキーを共有するためにドメインの間の何らかのコーディネートを必要とするかもしれません、そして、([RFC2747]と[RFC3097]を見てください)注意が、キーが十分頻繁に変えられるのを保証するのに必要です。 これが追加同期にかかわるかもしれないことに注意してください、ドメイン境界ノードがFRRと共に保護されるなら、また、MPとPLRがキーを共有するはずであるので。
For an inter-domain TE LSP, especially when it traverses different administrative or trust domains, the following mechanisms SHOULD be provided to an operator (also see [RFC4216]):
管理か信用の異なったドメインを横断します、以下のメカニズムSHOULD。相互ドメインTE LSP、特にいつ、オペレータに提供してください(また、[RFC4216]を見てください):
1) A way to enforce policies and filters at the domain borders to
process the incoming inter-domain TE LSP setup requests (Path
messages) based on certain agreed trust and service
levels/contracts between domains. Various LSP attributes such as
bandwidth, priority, etc. could be part of such a contract.
1) あるに基づいて入って来る相互ドメインTE LSPセットアップ要求(経路メッセージ)を処理するためにドメイン境界で方針とフィルタを実施する方法はドメインの信用とサービスレベル/契約を一致させました。 帯域幅、優先権などの様々なLSP属性はそのような契約の一部であるかもしれません。
Farrel, et al. Standards Track [Page 18] RFC 5151 Inter-Domain MPLS & GMPLS RSVP-TE Extensions February 2008
ファレル、他 標準化過程[18ページ]RFC5151相互ドメインMPLSとGMPLS RSVP-Te拡大2008年2月
2) A way for the operator to rate-limit LSP setup requests or error
notifications from a particular domain.
2) レート限界LSPセットアップ要求へのオペレータか特定のドメインからのエラー通知のための方法。
3) A mechanism to allow policy-based outbound RSVP message processing
at the domain border node, which may involve filtering or
modification of certain addresses in RSVP objects and messages.
3) RSVP物とメッセージにおける、あるアドレスのドメイン境界ノード、どれが、フィルターにかけることを伴うかもしれないか、そして、または変更で方針ベースの外国行きのRSVPメッセージ処理を許容するメカニズム。
Additionally, an operator may wish to reduce the signaling interactions between domains to improve security. For example, the operator might not trust the neighboring domain to supply correct or trustable restart information [RFC5063] and might ensure that the availability of restart function is not configured in the Hello message exchange across the domain border. Thus, suitable configuration MUST be provided in an RSVP-TE implementation to enable the operator to control optional protocol features that may be considered a security risk.
さらに、オペレータは、セキュリティを向上させるためにドメインの間のシグナリング相互作用を減少させたがっているかもしれません。 例えば、オペレータは、供給正しいか「信用-可能」な再開情報[RFC5063]に隣接しているドメインを任せないで、再開機能の有用性がドメイン境界の向こう側にHello交換処理で構成されないのを保証するかもしれません。 したがって、オペレータが危険人物であると考えられるかもしれない任意のプロトコル機能を制御するのを可能にするために適当な構成をRSVP-TE実現に提供しなければなりません。
Some examples of the policies described above are as follows:
上で説明された方針のいくつかの例は以下の通りです:
A) An operator may choose to implement some kind of ERO filtering
policy on the domain border node to disallow or ignore hops
within the domain from being identified in the ERO of an
incoming Path message. That is, the policy is that a node
outside the domain cannot specify the path of the LSP inside the
domain. The domain border LSR can make implement this policy in
one of two ways:
a) オペレータは、入って来るPathメッセージのEROで特定されるのでドメインの中でホップを禁じるか、または無視するためにドメイン境界ノードに関するある種のEROフィルタリング政策を実施するのを選ぶかもしれません。 すなわち、方針はドメインの外のノードがドメインの中でLSPの経路を指定できないということです。 LSRが2つの方法の1つでこの政策を実施するのを作ることができるドメイン境界:
- It can reject the Path message.
- それはPathメッセージを拒絶できます。
- It can ignore the hops in the ERO that lie within the
domain.
- それはドメインに属すEROでホップを無視できます。
B) In order to preserve confidentiality of network topology, an
operator may choose to disallow recording of hops within the
domain in the RRO or may choose to filter out certain recorded
RRO addresses at the domain border node.
B) ネットワーク形態の秘密性を保存するために、オペレータは、RROのドメインの中にホップを記録するのを禁じるのを選ぶか、またはドメイン境界ノードで、ある記録されたRROアドレスを無視するのを選ぶかもしれません。
C) An operator may require the border node to modify the addresses
of certain messages like PathErr or Notify originated from hops
within the domain.
C) オペレータは、ドメインの中のホップから溯源されたPathErrやNotifyのようなあるメッセージのアドレスを変更するために境界ノードを必要とするかもしれません。
D) In the event of a path computation failure, an operator may
require the border node to silently discard the Path message
instead of returning a PathErr. This is because a Path message
could be interpreted as a network probe, and a PathErr provides
information about the network capabilities and policies.
D) 経路計算失敗の場合、オペレータは、静かにPathErrを返すことの代わりにPathメッセージを捨てるために境界ノードを必要とするかもしれません。 これがネットワーク徹底的調査としてPathメッセージを解釈できたからであるPathErrはネットワーク能力と方針の情報を提供します。
Farrel, et al. Standards Track [Page 19] RFC 5151 Inter-Domain MPLS & GMPLS RSVP-TE Extensions February 2008
ファレル、他 標準化過程[19ページ]RFC5151相互ドメインMPLSとGMPLS RSVP-Te拡大2008年2月
Note that the detailed specification of such policies and their implementation are outside the scope of this document.
このドキュメントの範囲の外にそのような方針の仕様詳細と彼らの実現があることに注意してください。
Operations, Administration, and Management (OAM) mechanisms including [BFD-MPLS] and [RFC4379] are commonly used to verify the connectivity of end-to-end LSPs and to trace their paths. Where the LSPs are inter-domain LSPs, such OAM techniques MAY require that OAM messages are intercepted or modified at domain borders, or are passed transparently across domains. Further discussion of this topic can be found in [INTERAS-PING] and [MPLS-SEC].
操作、政権、および[BFD-MPLS]と[RFC4379]を含むManagement(OAM)メカニズムは、終わりから終わりへのLSPsの接続性について確かめて、彼らの経路をたどるのに一般的に使用されます。 LSPsが相互ドメインLSPsであるところでは、そのようなOAMのテクニックは、OAMメッセージがドメイン境界で妨害されるか、変更される、またはドメインの向こう側に透明に通過されるのを必要とするかもしれません。 [INTERAS-PING]と[MPLS-SEC]でこの話題のさらなる議論を見つけることができます。
9. IANA Considerations
9. IANA問題
IANA has made the codepoint allocations described in the following sections.
IANAは以下のセクションで説明されたcodepoint配分をしました。
9.1. Attribute Flags for LSP_Attributes Object
9.1. LSP_属性のための属性旗は反対します。
A new bit has been allocated from the "Attributes Flags" sub-registry of the "RSVP TE Parameters" registry.
「RSVP TEパラメタ」登録の「属性旗」サブ登録から新しいビットを割り当てました。
Bit | Name | Attribute | Path | RRO | Reference No | | Flags Path | Flags Resv | | ----+----------------------+------------+------------+-----+---------- 4 Contiguous LSP Yes No Yes [RFC5150]
ビット| 名前| 属性| 経路| RRO| 参照ノー| | 経路に旗を揚げさせます。| Resvに旗を揚げさせます。| | ----+----------------------+------------+------------+-----+---------- 4の隣接のLSPはいいいえはい[RFC5150]
9.2. New Error Codes
9.2. 新しいエラーコード
New RSVP error codes/values have been allocated from the "Error Codes and Globally-Defined Error Value Sub-Codes" sub-registry of the "RSVP Parameters" registry.
「RSVPパラメタ」登録の「エラーコードとグローバルに定義された誤り値のサブコード」サブ登録から新しいRSVPエラーコード/値を割り当てました。
For the existing error code "Policy control failure" (value 2), two new error values have been registered as follows:
既存のエラーコード「方針コントロール失敗」(値2)において、2つの新しい誤り値が以下の通り示されました:
103 = Inter-domain policy failure
104 = Inter-domain explicit route rejected
103 104の=相互ドメインの明白なルートが拒絶した=相互ドメイン政策の失敗
For the existing error code "Routing Problem" (value 24), two new error values have been registered as follows:
既存のエラーコード「ルート設定問題」(値24)において、2つの新しい誤り値が以下の通り示されました:
28 = Contiguous LSP type not supported
29 = ERO conflicts with inter-domain signaling method
28 = 隣接のLSPタイプは相互ドメインシグナリング方法との29回の=ERO闘争を支持しませんでした。
Farrel, et al. Standards Track [Page 20] RFC 5151 Inter-Domain MPLS & GMPLS RSVP-TE Extensions February 2008
ファレル、他 標準化過程[20ページ]RFC5151相互ドメインMPLSとGMPLS RSVP-Te拡大2008年2月
10. Acknowledgements
10. 承認
The authors would like to acknowledge the input and helpful comments from Kireeti Kompella on various aspects discussed in the document. Deborah Brungard and Dimitri Papdimitriou provided thorough reviews.
作者はドキュメントで議論した種々相のKireeti Kompellaから入力と役に立つコメントを承諾したがっています。 デボラBrungardとディミトリPapdimitriouは徹底的なレビューを提供しました。
Thanks to Sam Hartman for detailed discussions of the security considerations.
セキュリティ問題の詳細な論議をサム・ハートマンをありがとうございます。
11. References
11. 参照
11.1. Normative References
11.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S.,
and S. Jamin, "Resource ReSerVation Protocol (RSVP)
-- Version 1 Functional Specification", RFC 2205,
September 1997.
[RFC2205]ブレーデン、R.(エド)、チャン、L.、Berson、S.、ハーツォグ、S.、およびS.ジャマン、「資源予約は(RSVP)について議定書の中で述べます--バージョン1の機能的な仕様」、RFC2205、1997年9月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
V., and G. Swallow, "RSVP-TE: Extensions to RSVP for
LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、バーガー、L.、ガン、D.、李、T.、Srinivasan、V.、およびG.が飲み込まれる、「RSVP-Te:」 「LSP TunnelsのためのRSVPへの拡大」、RFC3209、2001年12月。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions",
RFC 3473, January 2003.
[RFC3473] エドバーガー、L.、RFC3473、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)は資源予約プロトコル交通工学(RSVP-Te)拡大を示す」1月2003日
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths
(LSP) Hierarchy with Generalized Multi-Protocol Label
Switching (GMPLS) Traffic Engineering (TE)", RFC
4206, October 2005.
[RFC4206]Kompella(K.とY.Rekhter)は「一般化されたマルチプロトコルラベルスイッチング(GMPLS)交通工学(Te)で切り換えられた経路(LSP)を階層構造とラベルします」、RFC4206、2005年10月。
[RFC4420] Farrel, A., Ed., Papadimitriou, D., Vasseur, J.-P.,
and A. Ayyangar, "Encoding of Attributes for
Multiprotocol Label Switching (MPLS) Label Switched
Path (LSP) Establishment Using Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE)", RFC 4420,
February 2006.
[RFC4420]ファレル、A.(エド)、Papadimitriou、D.、Vasseur、J.-P.、およびA.Ayyangar、「(MPLS)がラベルするMultiprotocolラベルの切り換えのための属性のコード化は資源予約プロトコル交通工学(RSVP-Te)を使用することで経路(LSP)設立を切り換えました」、RFC4420、2006年2月。
[RFC5150] Ayyangar, A., Kompella, K., and JP. Vasseur, "Label
Switched Path Stitching with Generalized
Multiprotocol Label Switching Traffic Engineering
(GMPLS TE)", RFC 5150, February 2008.
[RFC5150] Ayyangar、A.、Kompella、K.、およびJP。 Vasseur、「一般化されたMultiprotocolラベル切り換え交通工学(GMPLS Te)でステッチされるラベルの切り換えられた経路」、RFC5150、2008年2月。
Farrel, et al. Standards Track [Page 21] RFC 5151 Inter-Domain MPLS & GMPLS RSVP-TE Extensions February 2008
ファレル、他 標準化過程[21ページ]RFC5151相互ドメインMPLSとGMPLS RSVP-Te拡大2008年2月
11.2. Informative References
11.2. 有益な参照
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP
Cryptographic Authentication", RFC 2747, January
2000.
[RFC2747] ベイカーとF.とリンデル、B.とM.Talwar、「RSVPの暗号の認証」、RFC2747、2000年1月。
[RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic
Authentication -- Updated Message Type Value", RFC
3097, April 2001.
[RFC3097] ブレーデンとR.とL.チャン、「RSVPの暗号の認証--メッセージタイプ価値をアップデートする」RFC3097、2001年4月。
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed.,
"Fast Reroute Extensions to RSVP-TE for LSP Tunnels",
RFC 4090, May 2005.
[RFC4090]なべ、P.(エド)、ツバメ、G.(エド)、およびA.Atlas(エド)は「LSP Tunnelsのために速くRSVP-Teに拡大を別ルートで送ります」、RFC4090、2005年5月。
[RFC4105] Le Roux, J.-L., Ed., Vasseur, J.-P., Ed., and J.
Boyle, Ed., "Requirements for Inter-Area MPLS Traffic
Engineering", RFC 4105, June 2005.
[RFC4105]ル・ルー、J.-L.(エド)、Vasseur、J.-P.、エドJ.ボイル(エド)、「相互領域MPLSのための要件は工学を取引します」、RFC4105、2005年6月。
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for
Cryptographic Key Management", BCP 107, RFC 4107,
June 2005.
[RFC4107]Bellovin、S.とR.Housley、「暗号化キー管理のためのガイドライン」BCP107、2005年6月のRFC4107。
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y.
Rekhter, "Generalized Multiprotocol Label Switching
(GMPLS) User-Network Interface (UNI): Resource
ReserVation Protocol-Traffic Engineering (RSVP-TE)
Support for the Overlay Model", RFC 4208, October
2005.
[RFC4208] ツバメ、G.、ドレイク、J.、Ishimatsu、H.、およびY.Rekhter、「一般化されたMultiprotocolはユーザネットワーク・インターフェース(UNI)と切り換え(GMPLS)をラベルします」。 「オーバレイモデルの資源予約プロトコル交通工学(RSVP-Te)サポート」、RFC4208、2005年10月。
[RFC4216] Zhang, R., Ed., and J.-P. Vasseur, Ed., "MPLS Inter-
Autonomous System (AS) Traffic Engineering (TE)
Requirements", RFC 4216, November 2005.
[RFC4216] エドチャン、R.、J.-P。 Vasseur、エド「MPLS相互自律システム(AS)交通は(Te)要件を設計すること」でのRFC4216、2005年11月。
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-
Protocol Label Switched (MPLS) Data Plane Failures",
RFC 4379, February 2006.
[RFC4379] Kompella、K.、およびG.は2006年2月に「マルチプロトコルのラベルの切り換えられた(MPLS)データ飛行機の故障を検出すること」でのRFC4379を飲み込みます。
[RFC4561] Vasseur, J.-P., Ed., Ali, Z., and S. Sivabalan,
"Definition of a Record Route Object (RRO) Node-Id
Sub-Object", RFC 4561, June 2006.
[RFC4561]Vasseur、J.-P.(エド)、アリ、Z.、およびS.Sivabalan、「記録的なルート物(RRO)のノードイドサブ物の定義」RFC4561(2006年6月)。
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", RFC
4655, August 2006.
[RFC4655] ファレル、A.、Vasseur、J.-P.、およびJ.灰、「経路の計算の要素の(PCE)ベースの構造」、RFC4655、2006年8月。
Farrel, et al. Standards Track [Page 22] RFC 5151 Inter-Domain MPLS & GMPLS RSVP-TE Extensions February 2008
ファレル、他 標準化過程[22ページ]RFC5151相互ドメインMPLSとGMPLS RSVP-Te拡大2008年2月
[RFC4726] Farrel, A., Vasseur, J.-P., and A. Ayyangar, "A
Framework for Inter-Domain Multiprotocol Label
Switching Traffic Engineering", RFC 4726, November
2006.
[RFC4726] ファレル、A.、Vasseur、J.-P.、およびA.Ayyangar、「相互ドメインMultiprotocolラベル切り換え交通工学のための枠組み」、RFC4726(2006年11月)。
[RFC4736] Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang,
"Reoptimization of Multiprotocol Label Switching
(MPLS) Traffic Engineering (TE) Loosely Routed Label
Switched Path (LSP)", RFC 4736, November 2006.
[RFC4736]Vasseur(JP)、エド、Ikejiri、Y.、およびR.チャン、「Multiprotocolラベルの切り換え(MPLS)交通工学(Te)のReoptimizationは緩くラベルの切り換えられた経路(LSP)を発送しました」、RFC4736、11月2006
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A.
Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007.
[RFC4873] バーガー、L.、Bryskin、I.、Papadimitriou、D.、およびA.ファレル、「GMPLSセグメント回復」、RFC4873は2007がそうするかもしれません。
[RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude
Routes - Extension to Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE)", RFC 4874, April 2007.
[RFC4874]リー(CY)、ファレル、A.、およびS.De Cnodderは「資源予約プロトコル交通工学(RSVP-Te)までルート--拡大を除きます」、RFC4874、2007年4月。
[RFC4920] Farrel, A., Ed., Satyanarayana, A., Iwata, A.,
Fujita, N., and G. Ash, "Crankback Signaling
Extensions for MPLS and GMPLS RSVP-TE", RFC 4920,
July 2007.
[RFC4920]ファレル、A.(エド)、Satyanarayana、A.、磐田、A.、フジタ、N.、およびG.灰、「MPLSのための拡大とGMPLS RSVP-Teに合図するCrankback」、RFC4920(2007年7月)。
[BFD-MPLS] Aggarwal, R., Kompella, K., Nadeau, T., and G.
Swallow, "BFD For MPLS LSPs", Work in Progress,
February 2005.
[BFD-MPLS] Aggarwal、R.、Kompella、K.、ナドー、T.、およびG.ツバメ、「MPLS LSPsのためのBFD」は進歩、2005年2月に働いています。
[INTERAS-PING] Nadeau, T. and G. Swallow, "Detecting MPLS Data Plane
Failures in Inter-AS and inter-provider Scenarios",
Work in Progress, October 2006.
[INTERAS-PING] ナドーとT.とG.Swallow、「Inter-ASと相互プロバイダーScenariosにMPLS Data Plane Failuresを検出する」Progress(2006年10月)のWork。
[RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang,
"A Per-Domain Path Computation Method for
Establishing Inter-Domain Traffic Engineering (TE)
Label Switched Paths (LSPs)", RFC 5152, February
2008.
[RFC5152]Vasseur(JP)、エド、Ayyangar、A.、エドR.チャン、「相互ドメイン交通工学(Te)ラベルを設立するための1ドメインあたり1つの経路計算方法が経路(LSPs)を切り換えました」、RFC5152、2月2008
[MPLS-SEC] Fang, L., Ed., Behringer, M., Callon, R., Le Roux, J.
L., Zhang, R., Knight, P., Stein, Y., Bitar, N., and
R. Graveman., "Security Framework for MPLS and GMPLS
Networks", Work in Progress, July 2007.
[MPLS-SEC]の牙、L.(エド)、Behringer、M.、Callon、R.、ル・ルー、L.(チャン、R.)がナイト爵を授けるJ.、P.、シタイン、Y.、Bitar、N.、およびR.Graveman、「MPLSのためのセキュリティフレームワークとGMPLSネットワーク」は進行中(2007年7月)で働いています。
[RFC5063] Satyanarayana, A., Ed., and R. Rahman, Ed.,
"Extensions to GMPLS Resource Reservation Protocol
(RSVP) Graceful Restart", RFC 5063, October 2007.
[RFC5063]Satyanarayana、A.(エド)、およびR.ラーマン(エド)、「GMPLS資源予約への拡大は(RSVP)優雅な再開について議定書の中で述べます」、RFC5063、2007年10月。
Farrel, et al. Standards Track [Page 23] RFC 5151 Inter-Domain MPLS & GMPLS RSVP-TE Extensions February 2008
ファレル、他 標準化過程[23ページ]RFC5151相互ドメインMPLSとGMPLS RSVP-Te拡大2008年2月
Authors' Addresses
作者のアドレス
Adrian Farrel Old Dog Consulting
エードリアンのファレルの古い犬のコンサルティング
EMail: adrian@olddog.co.uk
メール: adrian@olddog.co.uk
Arthi Ayyangar Juniper Networks 1194 N. Mathilda Avenue Sunnyvale, CA 94089 USA
Arthi Ayyangar杜松は1194N.マチルダ・Avenueカリフォルニア94089サニーベル(米国)をネットワークでつなぎます。
EMail: arthi@juniper.net
メール: arthi@juniper.net
Jean Philippe Vasseur Cisco Systems, Inc. 300 Beaver Brook Road Boxborough , MA - 01719 USA
ジーンフィリップVasseurシスコシステムズInc.300ビーバーブルック道路Boxborough、MA--01719米国
EMail: jpv@cisco.com
メール: jpv@cisco.com
Farrel, et al. Standards Track [Page 24] RFC 5151 Inter-Domain MPLS & GMPLS RSVP-TE Extensions February 2008
ファレル、他 標準化過程[24ページ]RFC5151相互ドメインMPLSとGMPLS RSVP-Te拡大2008年2月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Farrel, et al. Standards Track [Page 25]
ファレル、他 標準化過程[25ページ]
一覧
スポンサーリンク
