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ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

memcachedを使用する(memcacheライブラリ)

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る