RFC4206 日本語訳

Network Working Group                                        K. Kompella
Request for Comments: 4206                                    Y. Rekhter
Category: Standards Track                               Juniper Networks
                                                            October 2005

Kompellaがコメントのために要求するワーキンググループK.をネットワークでつないでください: 4206年のY.Rekhterカテゴリ: 規格は2005年10月に杜松ネットワークを追跡します。

               Label Switched Paths (LSP) Hierarchy with
          Generalized Multi-Protocol Label Switching (GMPLS)
                        Traffic Engineering (TE)

ラベルは一般化されたマルチプロトコルラベルスイッチング(GMPLS)交通工学で経路(LSP)階層構造を切り換えました。(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)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2005).

Copyright(C)インターネット協会(2005)。

Abstract

要約

   To improve scalability of Generalized Multi-Protocol Label Switching
   (GMPLS) it may be useful to aggregate Label Switched Paths (LSPs) by
   creating a hierarchy of such LSPs.  A way to create such a hierarchy
   is by (a) a Label Switching Router (LSR) creating a Traffic
   Engineering Label Switched Path (TE LSP), (b) the LSR forming a
   forwarding adjacency (FA) out of that LSP (by advertising this LSP as
   a Traffic Engineering (TE) link into the same instance of ISIS/OSPF
   as the one that was used to create the LSP), (c) allowing other LSRs
   to use FAs for their path computation, and (d) nesting of LSPs
   originated by other LSRs into that LSP (by using the label stack
   construct).

Generalized Multi-プロトコルLabel Switching(GMPLS)のスケーラビリティを改良するために、そのようなLSPsの階層構造を作成することによってLabel Switched Paths(LSPs)に集めるのは役に立つかもしれません。 (a) Traffic Engineering Label Switched Path(TE LSP)を作成するLabel Switching Router(LSR)と、(b) (c) 他のLSRsが彼らの経路計算にFAsを使用するのを許容して、そのLSP(Traffic Engineering(TE)リンクとしてLSPを作成するのに使用されたものとしてのイシス/OSPFの同じ例にこのLSPの広告を出すのによる)から推進隣接番組(FA)を形成するLSRと、(d) そのような階層構造を作成する方法は他のLSRsによってそのLSPに溯源されたLSPs(ラベルスタック構造物を使用するのによる)の巣篭もりです。

   This document describes the mechanisms to accomplish this.

このドキュメントは、これを達成するためにメカニズムについて説明します。

Kompella & Rekhter          Standards Track                     [Page 1]

RFC 4206              LSP Hierarchy with GMPLS TE           October 2005

Kompella&Rekhter規格はTe2005年10月にGMPLSと共にRFC4206LSP階層構造を追跡します[1ページ]。

Table of Contents

目次

   1. Overview ........................................................2
   2. Specification of Requirements ...................................3
   3. Routing Aspects .................................................4
      3.1. Traffic Engineering Parameters .............................4
           3.1.1. Link Type (OSPF Only) ...............................5
           3.1.2. Link ID (OSPF Only) .................................5
           3.1.3. Local and Remote Interface IP Address ...............5
           3.1.4. Local and Remote Link Identifiers ...................5
           3.1.5. Traffic Engineering Metric ..........................5
           3.1.6. Maximum Bandwidth ...................................5
           3.1.7. Unreserved Bandwidth ................................5
           3.1.8. Resource Class/Color ................................5
           3.1.9. Interface Switching Capability ......................6
           3.1.10. SRLG Information ...................................6
   4. Other Considerations ............................................6
   5. Controlling FA-LSPs Boundaries ..................................7
      5.1. LSP Regions ................................................7
   6. Signalling Aspects ..............................................8
      6.1. Common Procedures ..........................................8
           6.1.1. RSVP-TE .............................................8
           6.1.2. CR-LDP ..............................................9
      6.2. Specific Procedures .......................................10
      6.3. FA-LSP Holding Priority ...................................11
   7. Security Considerations ........................................11
   8. Acknowledgements ...............................................12
   9. Normative References ...........................................12
   10. Informative References ........................................13

1. 概観…2 2. 要件の仕様…3 3. ルート設定局面…4 3.1. 交通工学パラメタ…4 3.1.1. タイプ(OSPF専用)をリンクしてください…5 3.1.2. ID(OSPF専用)をリンクしてください…5 3.1.3. 地方の、そして、リモートなインタフェースIPアドレス…5 3.1.4. 地方の、そして、リモートなリンク識別子…5 3.1.5. 交通工学メートル法…5 3.1.6. 最大の帯域幅…5 3.1.7. 無遠慮な帯域幅…5 3.1.8. リソースクラス/色…5 3.1.9. スイッチング能力を連結してください…6 3.1.10. SRLG情報…6 4. 他の問題…6 5. ファ-LSPs境界を制御します…7 5.1. LSP地方…7 6. 局面に合図します…8 6.1. 常法…8 6.1.1. RSVP-Te…8 6.1.2. CR-自由民主党…9 6.2. 特定の手順…10 6.3. ファ-LSP把持優先権…11 7. セキュリティ問題…11 8. 承認…12 9. 標準の参照…12 10. 有益な参照…13

1.  Overview

1. 概観

   An LSR uses Generalized MPLS (GMPLS) TE procedures to create and
   maintain an LSP.  The LSR then may (under local configuration
   control) announce this LSP as a Traffic Engineering (TE) link into
   the same instance of the GMPLS control plane (or, more precisely, its
   ISIS/OSPF component) as the one that was used to create the LSP.  We
   call such a link a "forwarding adjacency" (FA).  We refer to the LSP
   as the "forwarding adjacency LSP", or just FA-LSP.  Note that an FA-
   LSP is both created and used as a TE link by exactly the same
   instance of the GMPLS control plane.  Thus, the concept of an FA is
   applicable only when an LSP is both created and used as a TE link by
   exactly the same instance of the GMPLS control plane.  Note also that
   an FA is a TE link between two GMPLS nodes whose path transits zero
   or more (G)MPLS nodes in the same instance of the GMPLS control
   plane.

LSRは、LSPを作成して、維持するのにGeneralized MPLS(GMPLS)TE手順を用います。 そして、LSRはTraffic Engineering(TE)リンクとしてLSPを作成するのに使用されたものとしてのGMPLS制御飛行機(より正確にイシス/OSPFの部品)の同じ例にこのLSPを発表するかもしれません(ローカルの構成管理で)。 私たちは、そのようなリンクを「推進隣接番組」(FA)と呼びます。 私たちは「推進隣接番組LSP」の、または、正当なFA-LSPとLSPを呼びます。 FA- LSPがTEリンクとしてGMPLS制御飛行機のまさに同じ例によって作成されて、使用されることに注意してください。 LSPがTEリンクとしてGMPLS制御飛行機のまさに同じ例によって作成されて、使用されるときだけ、したがって、FAの概念は適切です。 また、FAが経路がゼロを通過する2つのGMPLSノードの間のTEリンクであるかGMPLSの同じ例における、より多くの(G)MPLSノードが飛行機を制御することに注意してください。

Kompella & Rekhter          Standards Track                     [Page 2]

RFC 4206              LSP Hierarchy with GMPLS TE           October 2005

Kompella&Rekhter規格はTe2005年10月にGMPLSと共にRFC4206LSP階層構造を追跡します[2ページ]。

   The nodes connected by a 'basic' TE link may have a routing
   adjacency; however, the nodes connected by an FA would not usually
   have a routing adjacency.  A TE link of any kind (either 'basic' or
   FA) would have to have a signaling adjacency in order for it to be
   used to establish an LSP across it.

'基本的な'TEリンクによって接続されたノードはルーティング隣接番組を持っているかもしれません。 しかしながら、通常、FAによって接続されたノードはルーティング隣接番組を持っていないでしょう。 どんな種類('基本的である'かFAのどちらか)のTEリンクでも、それがそれの向こう側にLSPを証明するのに使用されるために、シグナリング隣接番組がなければならないでしょう。

   In general, the creation/termination of an FA and its FA-LSP could be
   driven either by mechanisms outside of GMPLS (e.g., via configuration
   control on the LSR at the head-end of the adjacency), or by
   mechanisms within GMPLS (e.g., as a result of the LSR at the head-end
   of the adjacency receiving LSP setup requests originated by some
   other LSRs).

一般に、GMPLS(例えば、隣接番組のギヤエンドのLSRにおける構成管理を通した)における外のメカニズム、またはGMPLS(例えば、隣接番組受信のギヤエンドのLSRの結果、ある他のLSRsによって溯源されたLSPセットアップ要求)の中のメカニズムはFAとそのFA-LSPの創造/終了を追い立てることができました。

   ISIS/OSPF floods the information about FAs just as it floods the
   information about any other links.  As a result of this flooding, an
   LSR has in its TE link state database the information about not just
   basic TE links, but FAs as well.

ちょうどいかなる他のリンクの情報もあふれさせるようにイシス/OSPFはFAsの情報をあふれさせます。 この氾濫の結果、LSRはTEリンク州のデータベースに基本的なTEリンクだけではなく、また、FAsの情報を持っています。

   An LSR, when performing path computation, uses not just basic TE
   links, but FAs as well.  Once a path is computed, the LSR uses
   RSVP/CR-LDP [RSVP-TE, CR-LDP] for establishing label binding along
   the path.

経路計算を実行するとき、LSRは基本的なTEリンクだけではなく、また、FAsも使用します。 経路がいったん計算されると、LSRは、経路に沿ってラベル結合を確立するのに、RSVP/CR-自由民主党[RSVP-TE、CR-自由民主党]を使用します。

   In this document we define mechanisms/procedures to accomplish the
   above.  These mechanisms/procedures cover both the routing
   (ISIS/OSPF) and the signalling (RSVP/CR-LDP) aspects.

本書では私たちは、上記を達成するためにメカニズム/手順を定義します。 これらのメカニズム/手順はルーティング(イシス/OSPF)と合図(RSVP/CR-自由民主党)局面の両方をカバーしています。

   Note that an LSP may be advertised as a point-to-point link into ISIS
   or OSPF, to be used in normal SPF by nodes other than the head-end.
   While this is similar in spirit to an FA, this is beyond the scope of
   this document.

LSPが正常なSPFでギヤエンド以外のノードによって使用されるためにポイントツーポイント接続としてイシスかOSPFに広告を出すかもしれないことに注意してください。 精神においてFAと同様ですが、これはこのドキュメントの範囲を超えています。

   Scenarios where an LSP is created (and maintained) by one instance of
   the GMPLS control plane, and is used as a (TE) link by another
   instance of the GMPLS control plane, are outside the scope of this
   document.

LSPがGMPLS制御飛行機の1つの例によって作成されて(そして、維持されます)、(TE)リンクとしてGMPLS制御飛行機の別の例によって使用されるシナリオはこのドキュメントの範囲の外のそうです。

2.  Specification of Requirements

2. 要件の仕様

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, RFC 2119
   [RFC2119].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14RFC2119[RFC2119]で説明されるように本書では解釈されることであるべきです。

Kompella & Rekhter          Standards Track                     [Page 3]

RFC 4206              LSP Hierarchy with GMPLS TE           October 2005

Kompella&Rekhter規格はTe2005年10月にGMPLSと共にRFC4206LSP階層構造を追跡します[3ページ]。

3.  Routing Aspects

3. ルート設定局面

   In this section we describe procedures for constructing FAs out of
   LSPs, and handling of FAs by ISIS/OSPF.  Specifically, this section
   describes how to construct the information needed to advertise LSPs
   as links into ISIS/OSPF.  Procedures for creation/termination of such
   LSPs are defined in Section 5, "Controlling FA-LSPs boundaries".

このセクションで、私たちはLSPsからFAsを組み立てるための手順、およびイシス/OSPFによるFAsの取り扱いについて説明します。 明確に、このセクションはリンクとしてイシス/OSPFにLSPsの広告を出すのに必要である情報を構成する方法を説明します。 「FA-LSPs境界を制御し」て、そのようなLSPsの創造/終了のための手順はセクション5で定義されます。

   FAs may be represented as either unnumbered or numbered links.  If
   FAs are numbered with IPv4 addresses, the local and remote IPv4
   addresses come out of a /31 that is allocated by the LSR that
   originates the FA-LSP; the head-end address of the FA-LSP is the one
   specified as the IPv4 tunnel sender address; the remote (tail-end)
   address can then be inferred.  If the LSP is bidirectional, the
   tail-end can thus know the addresses to assign to the reverse FA.

FAsは無数の、または、番号付のリンクとして表されるかもしれません。 FAsがIPv4アドレスで付番されるなら、地方の、そして、リモートなIPv4アドレスはFA-LSPを溯源するLSRによって割り当てられる/31から出て来ます。 FA-LSPのギヤエンドのアドレスはIPv4が送付者アドレスにトンネルを堀るので指定されたものです。 そして、リモート(末端)アドレスを推論できます。 LSPが双方向であるなら、その結果、末端は、FAを逆に割り当てるためにアドレスを知ることができます。

   If there are multiple LSPs that all originate on one LSR and all
   terminate on another LSR, then at one end of the spectrum all these
   LSPs could be merged (under control of the head-end LSR) into a
   single FA using the concept of Link Bundling (see [BUNDLE]); while at
   the other end of the spectrum each such LSP could be advertised as
   its own adjacency.

1LSRですべて由来して、別のLSRで終わる複数のLSPsがすべて、あれば、スペクトルの片端では、これらのすべてのLSPsがLink Bundlingの概念を使用することで独身のFAに合併されるかもしれません(ギヤエンドLSRで制御された)([BUNDLE]を見てください)。 スペクトルのもう一方の端にある間、それ自身の隣接番組としてそのような各LSPの広告を出すことができました。

   When an FA is created under administrative control (static
   provisioning), the attributes of the FA-LSP have to be provided via
   configuration.  Specifically, the following attributes may be
   configured for the FA-LSP: the head-end address (if left
   unconfigured, this defaults to the head-end LSR's Router ID); the
   tail-end address; bandwidth and resource colors constraints.  The
   path taken by the FA-LSP may be either computed by the LSR at the
   head-end of the FA-LSP, or specified by explicit configuration; this
   choice is determined by configuration.

運営管理コントロール(静的な食糧を供給する)の下でFAを作成するとき、構成でFA-LSPの属性を提供しなければなりません。 明確に、以下の属性はFA-LSPのために構成されるかもしれません: ギヤエンドのアドレス(非構成されるように残されるなら、これはギヤエンドLSRのRouter IDをデフォルトとします)。 末端アドレス。 帯域幅とリソース色の規制。 FA-LSPによって取られた経路は、FA-LSPのギヤエンドのLSRによって計算されるか、または明白な構成によって指定されるかもしれません。 この選択は構成で決定します。

   When an FA is created dynamically, the attributes of its FA-LSP are
   inherited from the LSP that induced its creation.  Note that the
   bandwidth of the FA-LSP must be at least as big as the LSP that
   induced it, but may be bigger if only discrete bandwidths are
   available for the FA-LSP.  In general, for dynamically provisioned
   FAs, a policy-based mechanism may be needed to associate attributes
   to the FA-LSPs.

FAがダイナミックに作成されるとき、FA-LSPの属性は創造を引き起こしたLSPから引き継がれます。 離散的な帯域幅だけがFA-LSPに利用可能であるなら、FA-LSPの帯域幅がそれを引き起こしていますが、より大きいかもしれないLSPと少なくとも同じくらい大きいに違いないことに注意してください。 一般に、ダイナミックに食糧を供給されたFAsにおいて、方針ベースのメカニズムが、属性をFA-LSPsに関連づけるのに必要であるかもしれません。

3.1.  Traffic Engineering Parameters

3.1. 交通工学パラメタ

   In this section, the Traffic Engineering parameters (see [OSPF-TE]
   and [ISIS-TE]) for FAs are described.

このセクションで、FAsのためのTraffic Engineeringパラメタ([OSPF-TE]と[イシス-TE]を見る)は説明されます。

Kompella & Rekhter          Standards Track                     [Page 4]

RFC 4206              LSP Hierarchy with GMPLS TE           October 2005

Kompella&Rekhter規格はTe2005年10月にGMPLSと共にRFC4206LSP階層構造を追跡します[4ページ]。

3.1.1.  Link Type (OSPF Only)

3.1.1. リンク型(OSPF専用)

   The Link Type of an FA is set to "point-to-point".

FAのLink Typeは「ポイントツーポイント」に用意ができています。

3.1.2.  Link ID (OSPF Only)

3.1.2. IDをリンクしてください。(OSPF専用)

   The Link ID is set to the Router ID of the tail-end of FA-LSP.

Link IDはFA-LSPの末端のRouter IDに設定されます。

3.1.3.  Local and Remote Interface IP Address

3.1.3. 地方の、そして、リモートなインタフェースIPアドレス

   If the FA is to be numbered, the local interface IP address (OSPF) or
   IPv4 interface address (ISIS) is set to the head-end address of the
   FA-LSP.  The remote interface IP address (OSPF) or IPv4 neighbor
   address (ISIS) is set to the tail-end address of the FA-LSP.

FAが番号付であるつもりであるなら、局所界面IPアドレス(OSPF)かIPv4インターフェース・アドレス(イシス)がFA-LSPのギヤエンドのアドレスに設定されます。 リモートインタフェースIPアドレス(OSPF)かIPv4隣人アドレス(イシス)がFA-LSPの末端アドレスに設定されます。

3.1.4.  Local and Remote Link Identifiers

3.1.4. 地方の、そして、リモートなリンク識別子

   For an unnumbered FA, the assignment and handling of the local and
   remote link identifiers is specified in [UNNUM-RSVP], [UNNUM-CRLDP].

[UNNUM-CRLDP]、無数のFAとして、地方の、そして、リモートなリンク識別子の課題と取り扱いは[UNNUM-RSVP]で指定されます。

3.1.5.  Traffic Engineering Metric

3.1.5. 交通工学メートル法です。

   By default the TE metric on the FA is set to max(1, (the TE metric of
   the FA-LSP path) - 1) so that it attracts traffic in preference to
   setting up a new LSP.  This may be overridden via configuration at
   the head-end of the FA.

デフォルトで、FAのメートル法のTEが最大限にするように用意ができている、(1 (FA-LSP経路におけるメートル法のTE)--1) 新しいLSPをセットアップすることに優先して交通を引き付けるように。 これはFAのギヤエンドでの構成でくつがえされるかもしれません。

3.1.6.  Maximum Bandwidth

3.1.6. 最大の帯域幅

   By default, the Maximum Reservable Bandwidth and the initial Maximum
   LSP Bandwidth for all priorities of the FA is set to the bandwidth of
   the FA-LSP.  These may be overridden via configuration at the head-
   end of the FA (note that the Maximum LSP Bandwidth at any one
   priority should be no more than the bandwidth of the FA-LSP).

デフォルトで、FAのすべてのプライオリティのためのMaximum Reservable Bandwidthと初期のMaximum LSP BandwidthはFA-LSPの帯域幅に用意ができています。 これらはFAのヘッド端での構成でくつがえされるかもしれません(どんな優先権でも唯一のMaximum LSP BandwidthがFA-LSPの帯域幅であるべきであることに注意してください)。

3.1.7.  Unreserved Bandwidth

3.1.7. 無遠慮な帯域幅

   The initial unreserved bandwidth for all priority levels of the FA is
   set to the bandwidth of the FA-LSP.

FAのすべての優先順位のための初期の無遠慮な帯域幅はFA-LSPの帯域幅に設定されます。

3.1.8.  Resource Class/Color

3.1.8. リソースクラス/色

   By default, an FA does not have resource colors (administrative
   groups).  This may be overridden by configuration at the head-end of
   the FA.

デフォルトで、FAには、リソース色(管理グループ)がありません。 これはFAのギヤエンドでの構成によってくつがえされるかもしれません。

Kompella & Rekhter          Standards Track                     [Page 5]

RFC 4206              LSP Hierarchy with GMPLS TE           October 2005

Kompella&Rekhter規格はTe2005年10月にGMPLSと共にRFC4206LSP階層構造を追跡します[5ページ]。

3.1.9.  Interface Switching Capability

3.1.9. インタフェーススイッチング能力

   The (near-end) Interface Switching Capability associated with the FA
   is the (near end) Interface Switching Capability of the first link in
   the FA-LSP.

FAに関連している(終わり)のインタフェースSwitching CapabilityはFA-LSPにおける最初のリンクの(終わり頃の)インタフェースSwitching Capabilityです。

   When the (near-end) Interface Switching Capability field is PSC-1,
   PSC-2, PSC-3, or PSC-4, the specific information includes Interface
   MTU and Minimum LSP Bandwidth.  The Interface MTU is the minimum MTU
   along the path of the FA-LSP; the Minimum LSP Bandwidth is the
   bandwidth of the LSP.

(終わり)のインタフェースSwitching Capability分野がPSC-1、PSC-2、PSC-3、またはPSC-4であるときに、特殊情報はInterface MTUとMinimum LSP Bandwidthを含んでいます。 Interface MTUはFA-LSPの経路に沿った最小のMTUです。 Minimum LSP BandwidthはLSPの帯域幅です。

3.1.10.  SRLG Information

3.1.10. SRLG情報

   An FA advertisement could contain the information about the Shared
   Risk Link Groups (SRLG) for the path taken by the FA-LSP associated
   with that FA.  This information may be used for path calculation by
   other LSRs.  The information carried is the union of the SRLGs of the
   underlying TE links that make up the FA-LSP path; it is carried in
   the SRLG TLV in IS-IS or the SRLG sub-TLV of the TE Link TLV in OSPF.
   See [GMPLS-ISIS, GMPLS-OSPF] for details on the format of this
   information.

FA広告はそのFAに関連しているFA-LSPによって取られた経路へのShared Risk Link Groups(SRLG)の情報を含むかもしれません。 この情報は経路計算に他のLSRsによって使用されるかもしれません。 運ばれた情報はFA-LSP経路を作る基本的なTEリンクのSRLGsの組合です。 それがSRLG TLVで中まで運ばれる、-、または、OSPFのTE Link TLVのSRLGサブTLV。 この情報の形式に関する詳細に関して[GMPLS-イシス、GMPLS-OSPF]を見てください。

   It is possible that the underlying path information might change over
   time, via configuration updates or dynamic route modifications,
   resulting in the change of the SRLG TLV.

基本的な経路情報が時間がたつにつれて変化するのは、可能です、構成アップデートかダイナミックなルート変更で、SRLG TLVの変化をもたらして。

   If FAs are bundled (via link bundling), and if the resulting bundled
   link carries an SRLG TLV, it MUST be the case that the list of SRLGs
   in the underlying path, followed by each of the FA-LSPs that form the
   component links, is the same (note that the exact paths need not be
   the same).

FAsが束ねられて(リンクバンドリングを通した)、結果として起こる束ねられたリンクがSRLG TLVを運ぶなら、コンポーネントリンクを形成するそれぞれのFA-LSPsによって続かれた基本的な経路のSRLGsのリストが同じであることは(正確な経路が同じである必要はないことに注意してください)、事実であるに違いありません。

4.  Other Considerations

4. 他の問題

   It is expected that FAs will not be used for establishing ISIS/OSPF
   peering relation between the routers at the ends of the adjacency.

FAsが隣接番組の終わりのルータのイシス/OSPFじっと見る関係を確立するのに使用されないと予想されます。

   It may be desired in some cases to use FAs only in Traffic
   Engineering path computations.  In IS-IS, this can be accomplished by
   setting the default metric of the extended IS reachability TLV for
   the FA to the maximum link metric (2^24 - 1).  In OSPF, this can be
   accomplished by not advertising the link as a regular LSA, but only
   as a TE opaque LSA.

いくつかの場合、Traffic Engineering経路計算だけにFAsを使用するのは必要であるかもしれません。 中、-、これによる広げるのについてデフォルトを設定することによってメートル法で達成されているのが、最大のリンクへのメートル法のFA(2^24--1)のための可到達性TLVであるということであることができます。 OSPFでは、通常のLSAとしてリンクの広告を出すのではなく、単にTEの不透明なLSAとして広告を出すことによって、これを達成できます。

Kompella & Rekhter          Standards Track                     [Page 6]

RFC 4206              LSP Hierarchy with GMPLS TE           October 2005

Kompella&Rekhter規格はTe2005年10月にGMPLSと共にRFC4206LSP階層構造を追跡します[6ページ]。

5.  Controlling FA-LSPs Boundaries

5. ファ-LSPs境界を制御します。

   To facilitate controlling the boundaries of FA-LSPs, this document
   introduces two new mechanisms: Interface Switching Capability (see
   [GMPLS-ISIS, GMPLS-OSPF], and "LSP region" (or just "region").

FA-LSPsの境界を制御するのを容易にするために、このドキュメントは2つの新しいメカニズムを紹介します: Switching Capabilityを連結してください、([GMPLS-イシス、GMPLS-OSPF]を見てください、そして、「LSP領域。」(または、まさしく「領域」)

5.1.  LSP Regions

5.1. LSP地方

   The information carried in the Interface Switching Capabilities is
   used to construct LSP regions and to determine regions' boundaries as
   follows.

Interface Switching Capabilitiesで運ばれた情報は、LSP領域を構成して、以下の領域の境界を決定するのに使用されます。

   Define an ordering among interface switching capabilities as follows:
   PSC-1 < PSC-2 < PSC-3 < PSC-4 < TDM < LSC < FSC.  Given two
   interfaces if-1 and if-2 with interface switching capabilities isc-1
   and isc-2 respectively, say that if-1 < if-2 iff isc-1 < isc-2 or
   isc-1 == isc-2 == TDM, and if-1's max LSP bandwidth is less than if-
   2's max LSP bandwidth.

以下のインタフェーススイッチング能力の中で注文を定義してください: PSC-1<PSC-2<PSC-3<PSC-4<TDM<LSC<FSC。 2つのインタフェースを考えて、それぞれ能力のisc-1とisc-2を切り換えて、インタフェースで、-1であるなら、-2であるなら-1であるならそれを言ってください、<、-2である、iff isc-1<isc-2かisc-1=isc-2=TDM、最大LSP帯域幅が-1であるなら、より少ない、-、2はLSP帯域幅に最大限にします。

   Suppose an LSP's path is as follows: node-0, link-1, node-1, link-2,
   node-2, ..., link-n, node-n.  Moreover, for link-i denote by [link-i,
   node-(i-1)] the interface that connects link-i to node-(i-1), and by
   [link-i, node-i] the interface that connects link-i to node-i.

LSPの経路は以下の通りであると仮定してください: ノード-0、リンク-1、ノード-1、リンク-2、ノード-2…, リンク-n、ノードn。 そのうえ、リンクiに関して、ノード(i-1)にリンクiを接続する[リンクi、ノード(i-1)]インタフェース、および[リンクi、ノードi]で、リンクiをノードiに接続するインタフェースを指示してください。

   If [link-(i+1), node-i)] < [link-(i+1), node-(i+1)], we say that the
   LSP has crossed a region boundary at node-i; with respect to that LSP
   path, the LSR at node-i is an edge LSR.  The 'other edge' of the
   region with respect to the LSP path is node-k, where k is the
   smallest number greater than i such that [link-(i+1), node-(i+1)]
   equal [link-k, node-(k-1)], and [link-k, node-(k-1)] > [link-k,
   node-k].

[(i+1)、ノードiをリンクします]<[(i+1)、ノード(i+1)をリンクする]であるなら、私たちは、LSPがノードiに領域境界に交差したと言います。 そのLSP経路に関して、ノードiのLSRは縁のLSRです。 LSP経路に関する領域の'他の縁'はノードk>[リンクk、ノードk]です。そこでは、kがそのようなiのその[(i+1)をリンクしてください、ノード(i+1)]同輩[リンクk、ノード(k-1)]、および[リンクk、ノード(k-1)]より大きい最も少ない数です。

   Path computation may take region boundaries into account when
   computing a path for an LSP.  For example, path computation may
   restrict the path taken by an LSP to only the links whose Interface
   Switching Capability is PSC-1.

LSPのために経路を計算するとき、経路計算は領域境界を考慮に入れるかもしれません。 例えば、経路計算はLSPによってInterface Switching CapabilityがPSC-1であるリンクだけまで取られた経路を制限するかもしれません。

   Note that an interface may have multiple Interface Switching
   Capabilities.  In such a case, the test is whether if-i < if-j
   depends on the Interface Switching Capabilities chosen for if-i and
   if-j, which in turn determines whether or not there is a region
   boundary at node-i.

インタフェースには複数のInterface Switching Capabilitiesがあるかもしれないことに注意してください。 そして、このような場合には、テストがそうである、-、i、<、-、j、選ばれたInterface Switching Capabilitiesによる、-、i、-、j、領域境界がノードiにあるかどうか順番に決定する。

Kompella & Rekhter          Standards Track                     [Page 7]

RFC 4206              LSP Hierarchy with GMPLS TE           October 2005

Kompella&Rekhter規格はTe2005年10月にGMPLSと共にRFC4206LSP階層構造を追跡します[7ページ]。

6.  Signalling Aspects

6. 合図局面

   In this section we describe procedures that an LSR at the head-end of
   an FA uses for handling LSP setup originated by other LSR.

このセクションで、私たちは取り扱いLSPセットアップへのFAのギヤエンドの用途におけるLSRが他のLSRで溯源した手順について説明します。

   As we mentioned before, establishment/termination of FA-LSPs may be
   triggered either by mechanisms outside of GMPLS (e.g., via
   administrative control), or by mechanisms within GMPLS (e.g., as a
   result of the LSR at the edge of an aggregate LSP receiving LSP setup
   requests originated by some other LSRs beyond LSP aggregate and its
   edges).  Procedures described in Section 6.1, "Common Procedures",
   apply to both cases.  Procedures described in Section 6.2, "Specific
   Procedures", apply only to the latter case.

私たちが以前言及したように、GMPLS(例えば、運営管理コントロールを通した)における外のメカニズム、またはGMPLSの中のメカニズム(例えば、LSP集合とその縁を超えてある他のLSRsによって溯源されたLSPセットアップ要求を受け取る集合LSPの縁のLSRの結果、)によってFA-LSPsの設立/終了は引き起こされるかもしれません。 「常法」というセクション6.1で説明された手順は両方のケースに適用されます。 「特定の手順」というセクション6.2で説明された手順は後者のケースだけに適用されます。

6.1.  Common Procedures

6.1. 常法

   For the purpose of processing the ERO in a Path/Request message of an
   LSP that is to be tunneled over an FA, an LSR at the head-end of the
   FA-LSP views the LSR at the tail of that FA-LSP as adjacent (one IP
   hop away).

FAの上でトンネルを堀られることになっているLSPに関するPath/要求メッセージでEROを処理する目的のために、FA-LSPのギヤエンドのLSRはそのFA-LSPのテールで隣接していた状態で(遠くの1つのIPホップ)LSRを見ます。

   How this is to be achieved for RSVP-TE and CR-LDP is described in the
   following subsections.

これがRSVP-TEとCR-自由民主党のためにどう達成されることになっているかは以下の小区分で説明されます。

   In either case (RSVP-TE or CR-LDP), when an LSP is tunneled through
   an FA-LSP, the LSR at the head-end of the FA-LSP subtracts the LSP's
   bandwidth from the unreserved bandwidth of the FA.

LSPがFA-LSPを通してトンネルを堀られるときのどちらの場合(RSVP-TEかCR-自由民主党)ではも、FA-LSPのギヤエンドのLSRはFAの無遠慮な帯域幅からのLSPの帯域幅を引き算します。

   In the presence of link bundling (when link bundling is applied to
   FAs), when an LSP is tunneled through an FA-LSP, the LSR at the
   head-end of the FA-LSP also needs to adjust Max LSP bandwidth of the
   FA.

また、LSPがFA-LSPを通してトンネルを堀られるときのリンクバンドリング(リンクバンドリングがFAsに適用されるとき)があるとき、FA-LSPのギヤエンドのLSRは、FAのマックスLSP帯域幅を調整する必要があります。

6.1.1.  RSVP-TE

6.1.1. RSVP-Te

   If one uses RSVP-TE to signal an LSP to be tunneled over an FA-LSP,
   then the Path message MUST contain an IF_ID RSVP_HOP object
   [GRSVP-TE, GSIG] instead of an RSVP_HOP object; and the data
   interface identification MUST identify the FA-LSP.

1つがFA-LSPの上でトンネルを堀られるようにLSPに合図するのにRSVP-TEを使用するならPathメッセージが含まなければならない、_ID RSVP_HOPが反対するなら[GRSVP-TE、GSIG]、RSVP_HOPの代わりに、反対してください。 そして、データインタフェース識別はFA-LSPを特定しなければなりません。

   The preferred method of sending the Path message is to set the
   destination IP address of the Path message to the computed NHOP for
   that Path message.  This NHOP address must be a routable address; in
   the case of separate control and data planes, this must be a control
   plane address.

Pathメッセージを送る適した方法はそのPathメッセージのためにPathメッセージの送付先IPアドレスを計算されたNHOPに設定することです。 このNHOPアドレスは発送可能アドレスであるに違いありません。 別々のコントロールとデータ飛行機の場合では、これは規制飛行機アドレスであるに違いありません。

Kompella & Rekhter          Standards Track                     [Page 8]

RFC 4206              LSP Hierarchy with GMPLS TE           October 2005

Kompella&Rekhter規格はTe2005年10月にGMPLSと共にRFC4206LSP階層構造を追跡します[8ページ]。

   Furthermore, the IP header for the Path message MUST NOT have the
   Router Alert option.  The Path message is intended to be IP-routed to
   the tail-end of the FA-LSP without being intercepted and processed as
   an RSVP message by any of the intermediate nodes.

その上、PathメッセージのためのIPヘッダーには、Router Alertオプションがあってはいけません。 PathメッセージはIPによってRSVPメッセージとして中間的ノードのいずれによっても妨害されて、処理されないでFA-LSPの末端に発送されていることを意図します。

   Finally, the IP TTL vs. RSVP TTL check MUST NOT be made.  In general,
   if the IF_ID RSVP_HOP object is used, this check must be disabled, as
   the number of hops over the control plane may be greater than one.
   Instead, the following check is done by the receiver Y of the IF_ID
   RSVP_HOP object:

最終的に、IP TTL対RSVP TTLチェックをしてはいけません。 一般に、_ID RSVP_HOP物が使用されているなら、このチェックを無効にしなければなりません、制御飛行機の上のホップの数が1以上であるかもしれないので。 代わりに、以下のチェックに受信機Yをする、_ID RSVP_HOPが反対するなら:

   1. Make sure that the data interface identified in the IF_ID RSVP_HOP
      object actually terminates on Y.

1. データが特定されていた状態で連結するのを確信しているのに作る、_ID RSVP_HOP物が実際にYで終わるなら。

   2. Find the "other end" of the above data interface, say X.  Make
      sure that the PHOP in the IF_ID RSVP_HOP object is a control
      channel address that belongs to the same node as X.

2. たとえば、上のデータインタフェース、X.Makeの「他の終わり」が確実にそれであると確かめてください、中のPHOP、_ID RSVP_HOP物がXと同じノードに属す規制チャンネル・アドレスであるなら。

   How check #2 is carried out is beyond the scope of this document;
   suffice it to say that it may require a Traffic Engineering Database,
   or the use of LMP [LMP], or yet other means.

チェック#2がどう行われるかはこのドキュメントの範囲を超えています。 それを満足させて、Traffic Engineering Database、またはLMPの使用[LMP]を必要とするか、またはしかし、他の手段を必要とするかもしれないと言ってください。

   An alternative method is to encapsulate the Path message in an IP
   tunnel (or, in the case that the Interface Switching Capability of
   the FA-LSP is PSC[1-4], in the FA-LSP itself), and unicast the
   message to the tail-end of the FA-LSP, without the Router Alert
   option.  This option may be needed if intermediate nodes process RSVP
   messages regardless of whether the Router Alert option is present.

別法がIPトンネル(またはFA-LSPのInterface Switching CapabilityがPSC[1-4]である、FA-LSP自身で)でPathメッセージを要約することであり、ユニキャストはFA-LSPの末端へのメッセージです、Router Alertオプションなしで。 Router Alertオプションが存在しているかどうかにかかわらず中間的ノードがRSVPメッセージを処理するなら、このオプションが必要であるかもしれません。

   A PathErr sent in response to a Path message with an IF_ID RSVP_HOP
   object SHOULD contain an IF_ID HOP object.  (Note: a PathErr does not
   normally carry an RSVP_HOP object, but in the case of separated
   control and data, it is necessary to identify the data channel in the
   PathErr message.)

PathErrがPathメッセージに対応して発信した、ID RSVP_HOP物のSHOULDが含む_、_ID HOPが反対するなら。 (注意: PathErrは通常RSVP_HOP物を運びませんが、切り離されたコントロールとデータの場合では、PathErrメッセージでデータ・チャンネルを特定するのが必要です。)

   The Resv message back to the head-end of the FA-LSP (PHOP) is IP-
   routed to the PHOP in the Path message.  If necessary, Resv Messages
   MAY be encapsulated in another IP header whose destination IP address
   is the PHOP of the received Path message.

FA-LSP(PHOP)のギヤエンドまでのResvメッセージはPathメッセージのPHOPに発送されたIPです。 必要なら、Resv Messagesは送付先IPアドレスが受信されたPathメッセージのPHOPである別のIPヘッダーで要約されるかもしれません。

6.1.2.  CR-LDP

6.1.2. CR-自由民主党

   If one uses CR-LDP to signal an LSP to be tunneled over an FA-LSP,
   then the Request message MUST contain an IF_ID TLV [GCR-LDP] object,
   and the data interface identification MUST identify the FA-LSP.

1つがCR-自由民主党を使用するなら、FA-LSPの上でトンネルを堀られます、次に、Requestメッセージが_ID TLV[GCR-自由民主党]が反対するか、そして、データを含まなければならないということであるようにLSPに合図するには、インタフェース識別はFA-LSPを特定しなければなりません。

Kompella & Rekhter          Standards Track                     [Page 9]

RFC 4206              LSP Hierarchy with GMPLS TE           October 2005

Kompella&Rekhter規格はTe2005年10月にGMPLSと共にRFC4206LSP階層構造を追跡します[9ページ]。

   Furthermore, the head-end LSR must create a targeted LDP session with
   the tail-end LSR.  The Request (Mapping) message is unicast from the
   head-end (tail-end) to the tail-end (head-end).

その上、ギヤエンドLSRは末端LSRとの狙っている自由民主党のセッションを作成しなければなりません。 ギヤエンドの(末端)から末端(ギヤエンド)までRequest(写像する)メッセージはユニキャストです。

6.2.  Specific Procedures

6.2. 特定の手順

   When an LSR receives a Path/Request message, the LSR determines
   whether it is at the edge of a region with respect to the ERO carried
   in the message.  The LSR does this by looking up the interface
   switching capabilities of the previous hop and the next hop in its
   IGP database, and comparing them using the relation defined in this
   section.  If the LSR is not at the edge of a region, the procedures
   in this section do not apply.

LSRがPath/要求メッセージを受け取るとき、LSRは、メッセージで運ばれたEROに関してそれが領域の縁にあるかを決定します。 LSRは、IGPデータベースで前のホップと次のホップのインタフェーススイッチング能力を見上げて、このセクションで定義された関係を使用することでそれらを比較することによって、これをします。 LSRが領域の縁にないなら、このセクションの手順は適用されません。

   If the LSR is at the edge of a region, it must then determine the
   other edge of the region with respect to the ERO, again using the IGP
   database.  The LSR then extracts (from the ERO) the subsequence of
   hops from itself to the other end of the region.

LSRが領域の縁にあるなら、EROに関して領域のもう片方の縁を決定しなければなりません、再びIGPデータベースを使用して。 そして、LSRはホップのそれ自体から領域のもう一方の端までの続きを抽出します(EROから)。

   The LSR then compares the subsequence of hops with all existing FA-
   LSPs originated by the LSR.  If a match is found, that FA-LSP has
   enough unreserved bandwidth for the LSP being signaled, the L3PID of
   the FA-LSP is compatible with the L3PID of the LSP being signaled,
   and the LSR uses that FA-LSP as follows.  The Path/Request message
   for the original LSP is sent to the egress of the FA-LSP, not to the
   next hop along the FA-LSP's path.  The PHOP in the message is the
   address of the LSR at the head-end of the FA-LSP.  Before sending the
   Path/Request message, the ERO in that message is adjusted by removing
   the subsequence of the ERO that lies in the FA-LSP, and replacing it
   with just the end point of the FA-LSP.

そして、LSRはFA- LSPsがLSRで溯源したすべての存在とホップの続きを比べます。 マッチが見つけられるなら、そのFA-LSPには、十分な合図されるLSPに、無遠慮な帯域幅があります、そして、FA-LSPのL3PIDは合図されるLSPのL3PIDと互換性があります、そして、LSRは以下のそのFA-LSPを使用します。 FA-LSPの経路に沿った次のホップではなく、FA-LSPの出口にオリジナルのLSPへのPath/要求メッセージを送ります。 メッセージのPHOPはFA-LSPのギヤエンドのLSRのアドレスです。 Path/要求メッセージを送る前に、そのメッセージのEROは、FA-LSPにあるEROの続きを移して、それをまさしくFA-LSPのエンドポイントに取り替えることによって、調整されます。

   Otherwise (if no existing FA-LSP is found), the LSR sets up a new
   FA-LSP.  That is, it initiates a new LSP setup just for the FA-LSP.
   Note that the new LSP may traverse either 'basic' TE links or FAs.

さもなければ(どんな既存のFA-LSPも見つけられないなら)、LSRは新しいFA-LSPをセットアップします。 すなわち、それはまさしくFA-LSPのために新しいLSPセットアップに着手します。 新しいLSPが'基本的な'TEリンクかFAsのどちらかを横断するかもしれないことに注意してください。

   After the LSR establishes the new FA-LSP, the LSR announces this LSP
   into IS-IS/OSPF as an FA.

LSRが、後に、LSRが新しいFA-LSPを設立するとこのLSPを発表する、-、FAとしての/OSPF。

   The unreserved bandwidth of the FA is computed by subtracting the
   bandwidth of sessions pending the establishment of the FA-LSP
   associated from the bandwidth of the FA-LSP.

FAの無遠慮な帯域幅は、FA-LSPの帯域幅によって関連しているFA-LSPの設立までセッションの帯域幅を引き算することによって、計算されます。

   An FA-LSP could be torn down by the LSR at the head-end of the FA-LSP
   as a matter of policy local to the LSR.  It is expected that the FA-
   LSP would be torn down once there are no more LSPs carried by the
   FA-LSP.  When the FA-LSP is torn down, the FA associated with the
   FA-LSP is no longer advertised into IS-IS/OSPF.

政策の問題としてLSRへの地方のFA-LSPのギヤエンドのLSRはFA-LSPを取りこわすことができました。 FA-LSPによって運ばれたそれ以上のLSPsが全くいったんないとFA- LSPが取りこわされると予想されます。 いつまでFA-LSPを取りこわして、FA-LSPに関連しているFAがもう広告を出さないか、-、/OSPF。

Kompella & Rekhter          Standards Track                    [Page 10]

RFC 4206              LSP Hierarchy with GMPLS TE           October 2005

Kompella&Rekhter規格はTe2005年10月にGMPLSと共にRFC4206LSP階層構造を追跡します[10ページ]。

6.3.  FA-LSP Holding Priority

6.3. 優位に立つファ-LSP

   The value of the holding priority of an FA-LSP must be the minimum of
   the configured holding priority of the FA-LSP and the holding
   priorities of the LSPs tunneling through the FA-LSP (note that
   smaller priority values denote higher priority).  Thus, if an LSP of
   higher priority than the FA-LSP tunnels through the FA-LSP, the FA-
   LSP is itself promoted to the higher priority.  However, if the
   tunneled LSP is torn down, the FA-LSP need not drop its priority to
   its old value right away; it may be advisable to apply hysteresis in
   this case.

FA-LSPの把持優先権の価値はFA-LSPの構成された把持優先権とLSPsがFA-LSPを通してトンネルを堀る把持プライオリティの最小限であるに違いありません(より小さい優先順位の値が、より高い優先度を指示することに注意してください)。 したがって、FA-LSPより高い優先度のLSPがFA-LSPを通してトンネルを堀るなら、FA- LSPは、より高い優先度に促進されます。 しかしながら、トンネルを堀られたLSPを取りこわすなら、FA-LSPはすぐ、古い値の優先権を落とす必要はありません。 この場合ヒステリシスを適用するのは賢明であるかもしれません。

   If the holding priority of an FA-LSP is configured, this document
   restricts it to 0.

FA-LSPの把持優先権が構成されるなら、このドキュメントはそれを0に制限します。

7.  Security Considerations

7. セキュリティ問題

   From a security point of view, the primary change introduced in this
   document is that the implicit assumption of a binding between data
   interfaces and the interface over which a control message is sent is
   no longer valid.

セキュリティ観点から、本書では導入された第一の変化はコントロールメッセージが送られるデータインタフェースとインタフェースの間の結合の暗黙の仮定がもう有効でないということです。

   This means that the "sending interface" or "receiving interface" is
   no longer well-defined, as the interface over which an RSVP message
   is sent may change as routing changes.  Therefore, mechanisms that
   depend on these concepts (for example, the definition of a security
   association) need a clearer definition.

これは、「送付インタフェース」か「受信インタフェース」がもう明確でないことを意味します、RSVPメッセージが送られるインタフェースが変化を発送するとして変化するとき。 したがって、これらの概念(例えば、セキュリティ協会の定義)によるメカニズムは、より明確な定義を必要とします。

   [RFC2747] provides a solution: in Section 2.1, under "Key
   Identifier", an IP address is a valid identifier for the sending (and
   by analogy, receiving) interface.  Since RSVP messages for a given
   LSP are sent to an IP address that identifies the next/previous hop
   for the LSP, one can replace all occurrences of 'sending [receiving]
   interface' with 'receiver's [sender's] IP address' (respectively).
   For example, in Section 4, third paragraph, instead of:

[RFC2747]は解決法を提供します: セクション2.1では、「主要な識別子」の下では、IPアドレスは発信(類推による受信)インタフェースのための有効な識別子です。 LSPのために次か前のホップを特定するIPアドレスに与えられたLSPへのRSVPメッセージを送るので、1つは'受信機[送付者のもの]アドレスのIPもの'(それぞれ)による'発信[受信]インタフェース'のすべての発生に取って代わることができます。 例えば、セクション4の以下の代わりに第3パラグラフ

      "Each sender SHOULD have distinct security associations (and keys)
      per secured sending interface (or LIH).  ...  At the sender,
      security association selection is based on the interface through
      which the message is sent."

「それぞれの送付者SHOULDは安全にされた発信あたりの異なったセキュリティ協会(そして、キー)を連結させます(または、LIH)。」 ... 「送付者では、セキュリティ協会選択はメッセージが送られるインタフェースに基づいています。」

   it should read:

それは読むべきです:

      "Each sender SHOULD have distinct security associations (and keys)
      per secured receiver's IP address. ...  At the sender, security
      association selection is based on the IP address to which the
      message is sent."

「それぞれの送付者SHOULDには、安全にされた受信機のIPアドレスあたりの異なったセキュリティ協会(そして、キー)があります。」 ... 「送付者では、セキュリティ協会選択はメッセージが送られるIPアドレスに基づいています。」

Kompella & Rekhter          Standards Track                    [Page 11]

RFC 4206              LSP Hierarchy with GMPLS TE           October 2005

Kompella&Rekhter規格はTe2005年10月にGMPLSと共にRFC4206LSP階層構造を追跡します[11ページ]。

   Note that CR-LDP does not have this issue, as CR-LDP messages are
   sent over TCP sessions, and no assumption is made that these sessions
   are to direct neighbors.  The recommended mechanism for
   authentication and integrity of LDP message exchange is to use the
   TCP MD5 option [LDP].

CR-自由民主党にはこの問題がないことに注意してください、TCPセッションの間、CR-自由民主党メッセージを送って、これらのセッションが隣人を指示することであるという仮定を全くしないとき。 自由民主党交換処理の認証と保全のためのお勧めのメカニズムはTCP MD5オプション[自由民主党]を使用することです。

   Another consequence (relevant to RSVP) of the changes proposed in
   this document is that IP destination address of Path messages be set
   to the receiver's address, not to the session destination.  Thus, the
   objections raised in Section 1.2 of [RFC2747] should be revisited to
   see if IPSec AH is now a viable means of securing RSVP-TE messages.

本書では提案された変化の別の結果(RSVPに関連している)はPathメッセージの受信者IPアドレスがセッションの目的地ではなく、届け先に設定されるということです。 したがって、[RFC2747]のセクション1.2で上げられた反論は、現在IPSec AHがRSVP-TEメッセージを保証する実行可能な手段であるかどうか確認するために再訪するべきです。

8.  Acknowledgements

8. 承認

   Many thanks to Alan Hannan, whose early discussions with Yakov
   Rekhter contributed greatly to the notion of Forwarding Adjacencies.
   We would also like to thank George Swallow, Quaizar Vohra and Ayan
   Banerjee.

ヤコフRekhterとの早めの議論がForwarding Adjacenciesの概念に大いに貢献したアラン・ハナンをありがとうございます。 また、ジョージSwallow、Quaizar Vohra、およびアヤンバネルジーに感謝申し上げます。

9.  Normative References

9. 引用規格

   [GCR-LDP]     Ashwood-Smith, P. and L. Berger, "Generalized Multi-
                 Protocol Label Switching (GMPLS) Signaling Constraint-
                 based Routed Label Distribution Protocol (CR-LDP)
                 Extensions", RFC 3472, January 2003.

[GCR-自由民主党]Ashwood-スミス(P.とL.バーガー)は、「ConstraintのベースのRouted Label Distributionプロトコル(CR-自由民主党)拡大に合図しながら、MultiプロトコルLabel Switching(GMPLS)を一般化しました」、RFC3472、2003年1月。

   [GMPLS-ISIS]  Kompella, K., Ed., and Y. Rekhter, Ed., "Intermediate
                 System to Intermediate System (IS-IS) Extensions in
                 Support of Generalized Multi-Protocol Label Switching
                 (GMPLS)", RFC 4205, October 2005.

[GMPLS-イシス]Kompella、K.(エド)、およびY.Rekhter(エド)、「中間システムへの中間システム、(-、)、一般化されたマルチプロトコルを支持した拡大が切り換え(GMPLS)をラベルする、」、RFC4205(2005年10月)

   [GMPLS-OSPF]  Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF
                 Extensions in Support of Generalized Multi-Protocol
                 Label Switching (GMPLS)", RFC 4203, October 2005.

[GMPLS-OSPF]Kompella、K.(エド)、およびY.Rekhter(エド)、「一般化されたマルチプロトコルを支持したOSPF拡張子は切り換え(GMPLS)をラベルします」、RFC4203、2005年10月。

   [GRSVP-TE]    Berger, L., "Generalized Multi-Protocol Label Switching
                 (GMPLS) Signaling Resource ReserVation Protocol-Traffic
                 Engineering (RSVP-TE) Extensions", RFC 3473, January
                 2003.

[GRSVP-Te] バーガー、L.、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)シグナリング資源予約プロトコル交通工学(RSVP-Te)拡大」、RFC3473、2003年1月。

   [GSIG]        Berger, L., "Generalized Multi-Protocol Label Switching
                 (GMPLS) Signaling Functional Description", RFC 3471,
                 January 2003.

[GSIG] バーガー、L.、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)のシグナリングの機能的な記述」、RFC3471、2003年1月。

   [ISIS-TE]     Smit, H. and T. Li, "Intermediate System to
                 Intermediate System (IS-IS) Extensions for Traffic
                 Engineering (TE)", RFC 3784, June 2004.

[イシス-Te] スミット、H.、およびT.李、「中間システムへの中間システム、(-、)、交通工学(Te)のための拡大、」、RFC3784(2004年6月)

Kompella & Rekhter          Standards Track                    [Page 12]

RFC 4206              LSP Hierarchy with GMPLS TE           October 2005

Kompella&Rekhter規格はTe2005年10月にGMPLSと共にRFC4206LSP階層構造を追跡します[12ページ]。

   [LDP]         Andersson, L., Doolan, P., Feldman, N., Fredette, A.,
                 and B. Thomas, "Label Distribution Protocol", RFC 3036,
                 January 2001.

[自由民主党] アンデションとL.とDoolanとP.とフェルドマンとN.とFredette、A.とB.トーマス、「ラベル分配プロトコル」、RFC3036、2001年1月。

   [OSPF-TE]     Katz, D., Kompella, K., and D. Yeung, "Traffic
                 Engineering (TE) Extensions to OSPF Version 2", RFC
                 3630, September 2003.

[OSPF-Te] キャッツ、D.、Kompella、K.、およびD.Yeung、「(Te)拡大をOSPFにバージョン2インチ設計する交通、RFC3630、2003年9月。」

   [UNNUM-CRLDP] Kompella, K., Rekhter, Y., and A. Kullberg, "Signalling
                 Unnumbered Links in CR-LDP (Constraint-Routing Label
                 Distribution Protocol)", RFC 3480, February 2003.

[UNNUM-CRLDP] Kompella、K.、Rekhter、Y.、およびA.Kullberg、「CR-自由民主党(規制ルート設定ラベル分配プロトコル)で無数のリンクに合図します」、RFC3480(2003年2月)。

   [UNNUM-RSVP]  Kompella, K. and Y. Rekhter, "Signalling Unnumbered
                 Links in Resource ReSerVation Protocol - Traffic
                 Engineering (RSVP-TE)", RFC 3477, January 2003.

[UNNUM-RSVP] Kompella、K.、およびY.Rekhter、「資源予約に基づく合図の無数のリンクは議定書を作ります--交通工学(RSVP-Te)」、RFC3477、2003年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月。

   [RFC2747]     Baker, F., Lindell, B., and M. Talwar, "RSVP
                 Cryptographic Authentication", RFC 2747, January 2000.

[RFC2747] ベイカーとF.とリンデル、B.とM.Talwar、「RSVPの暗号の認証」、RFC2747、2000年1月。

10.  Informative References

10. 有益な参照

   [BUNDLE]      Kompella, K., Rekhter, Y., and L. Berger, "Link
                 Bundling in MPLS Traffic Engineering (TE)", RFC 4201,
                 October 2005.

[バンドル]Kompella、K.、Rekhter、Y.、およびL.バーガー、「MPLS交通工学(Te)におけるリンクバンドリング」、RFC4201、2005年10月。

   [LMP]         Lang, L., Ed., "Link Management Protocol (LMP)", RFC
                 4204, October 2005.

[LMP] ラング、L.、エド、「リンク管理プロトコル(LMP)」、RFC4204、10月2005日

Authors' Addresses

作者のアドレス

   Kireeti Kompella
   Juniper Networks, Inc.
   1194 N. Mathilda Ave
   Sunnyvale, CA 94089

Kireeti Kompella杜松はInc.1194N.マチルダ・Aveサニーベル、カリフォルニア 94089をネットワークでつなぎます。

   EMail: kireeti@juniper.net

メール: kireeti@juniper.net

   Yakov Rekhter
   Juniper Networks, Inc.
   1194 N. Mathilda Ave
   Sunnyvale, CA 94089

ヤコフRekhter JuniperはInc.1194N.マチルダ・Aveサニーベル、カリフォルニア 94089をネットワークでつなぎます。

   EMail: yakov@juniper.net

メール: yakov@juniper.net

Kompella & Rekhter          Standards Track                    [Page 13]

RFC 4206              LSP Hierarchy with GMPLS TE           October 2005

Kompella&Rekhter規格はTe2005年10月にGMPLSと共にRFC4206LSP階層構造を追跡します[13ページ]。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2005).

Copyright(C)インターネット協会(2005)。

   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 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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

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に情報を記述してください。

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Kompella & Rekhter          Standards Track                    [Page 14]

Kompella&Rekhter標準化過程[14ページ]