RFC4561 日本語訳

Network Working Group                                 J.-P. Vasseur, Ed.
Request for Comments: 4561                                        Z. Ali
Category: Standards Track                                   S. Sivabalan
                                                     Cisco Systems, Inc.
                                                               June 2006

ワーキンググループJ.-Pをネットワークでつないでください。 エドVasseur、コメントを求める要求: 4561年のZ.アリカテゴリ: 標準化過程S.SivabalanシスコシステムズInc.2006年6月

     Definition of a Record Route Object (RRO) Node-Id Sub-Object

記録的なルート物(RRO)のノードイドサブ物の定義

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 (2006).

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

Abstract

要約

   In the context of MPLS TE Fast Reroute, the Merge Point (MP) address
   is required at the Point of Local Repair (PLR) in order to select a
   backup tunnel intersecting a fast reroutable Traffic Engineering
   Label Switched Path (TE LSP) on a downstream Label Switching Router
   (LSR).  However, existing protocol mechanisms are not sufficient to
   find an MP address in multi-domain routing networks where a domain is
   defined as an Interior Gateway Protocol (IGP) area or an Autonomous
   System (AS).  Hence, the current MPLS Fast Reroute mechanism cannot
   be used in order to protect inter-domain TE LSPs from a failure of an
   Area Border Router (ABR) or Autonomous System Border Router (ASBR).
   This document specifies the use of existing Record Route Object (RRO)
   IPv4 and IPv6 sub-objects (with a new flag defined) thus defining the
   node-id sub-object in order to solve this issue.  The MPLS Fast
   Reroute mechanism mentioned in this document refers to the "Facility
   backup" MPLS TE Fast Reroute method.

MPLS TE Fast Rerouteの文脈では、Merge Point(MP)アドレスが、川下のLabel Switching Router(LSR)でバックアップのトンネルの交差しているa速いreroutable Traffic Engineering Label Switched Path(TE LSP)を選択するのにLocal Repair(PLR)のPointで必要です。 しかしながら、既存のプロトコルメカニズムは、マルチドメインルーティングによるMPアドレスがドメインがInteriorゲートウェイプロトコル(IGP)部門と定義されるネットワークかAutonomous Systemであることがわかるために十分ではありません(AS)。 したがって、Area Border Router(ABR)かAutonomous System Border Router(ASBR)の失敗から相互ドメインTE LSPsを保護するのに現在のMPLS Fast Rerouteメカニズムを使用できません。 このドキュメントは、その結果、この問題を解決するためにノードイドサブ物を定義しながら、既存のRecord Route Object(RRO)IPv4とIPv6サブ物(新しい旗が定義されている)の使用を指定します。 本書では言及されたMPLS Fast Rerouteメカニズムは「施設バックアップ」MPLS TE Fast Reroute方法を示します。

Vasseur, et al.             Standards Track                     [Page 1]

RFC 4561          Definition of RRO Node-Id Sub-Object         June 2006

Vasseur、他 規格はノードイドサブ物の2006年6月に4561年のRROのRFC定義を追跡します[1ページ]。

Table of Contents

目次

   1. Introduction ....................................................2
   2. Terminology .....................................................4
      2.1. Conventions Used in This Document ..........................5
   3. Signaling Node-Ids in RROs ......................................5
   4. Finding Merge Point .............................................6
   5. Security Considerations .........................................7
   6. Acknowledgements ................................................7
   7. References ......................................................7
      7.1. Normative References .......................................7
      7.2. Informative References .....................................8

1. 序論…2 2. 用語…4 2.1. このドキュメントで中古のコンベンション…5 3. RROsのシグナリングノードイド…5 4. 合併するようにわかって、指してください…6 5. セキュリティ問題…7 6. 承認…7 7. 参照…7 7.1. 標準の参照…7 7.2. 有益な参照…8

1.  Introduction

1. 序論

   MPLS Fast Reroute (FRR) [FAST-REROUTE] is a fast recovery local
   protection technique used to protect Traffic Engineering LSPs from
   link/node/Shared Risk Link Group (SRLG) failure.  One or more backup
   tunnels are pre-established to protect against the failure of a
   link/node/SRLG.  In case of failure, every protected TE LSP
   traversing the failed resource is rerouted onto the appropriate
   backup tunnel.

MPLS Fast Reroute(FRR)[FAST-REROUTE]はローカルの保護のテクニックがリンク/ノード/共有されたRisk Link Group(SRLG)の故障からTraffic Engineering LSPsを保護するのに使用した速い回復です。 1つ以上のバックアップトンネルが、リンク/ノード/SRLGの失敗から守るためにあらかじめ確立されます。 失敗の場合には、失敗したリソースを横断するあらゆる保護されたTE LSPが適切なバックアップトンネルに別ルートで送られます。

   There are several requirements on the backup tunnel path that must be
   satisfied.  First, the backup tunnel must not traverse the element
   that it protects.  In addition, a primary tunnel and its associated
   backup tunnel should intersect at least at two points (nodes): Point
   of Local Repair (PLR) and Merge Point (MP).  The former is the head-
   end LSR of the backup tunnel, and the latter is the tail-end LSR of
   the backup tunnel.  The PLR is where FRR is triggered when
   link/node/SRLG failure happens.

いくつかの要件が満たさなければならないバックアップトンネル道にあります。 まず最初に、バックアップトンネルはそれが保護する要素を横断してはいけません。 さらに、第一のトンネルとその関連バックアップトンネルは少なくとも2ポイント(ノード)で横切られるはずです: 局部的修繕(PLR)とマージポイント(MP)のポイント。 前者はバックアップトンネルのヘッド終わりのLSRです、そして、後者はバックアップトンネルの末端LSRです。 PLRはリンク/ノード/SRLGの故障が起こるときFRRが引き起こされるところです。

   There are different methods for computing paths for backup tunnels at
   a given PLR.  Specifically, a user can statically configure one or
   more backup tunnels at the PLR with an explicitly configured path, or
   the PLR can be configured to automatically compute a backup path or
   to send a path computation request to a PCE (see [PCE-ARCH]).

バックアップトンネルに経路を計算するための異なった方法が与えられたPLRにあります。 明確に、ユーザが静的に明らかに構成された経路があるPLRの1つ以上のバックアップトンネルを構成できますか、または自動的にバックアップ道を計算するか、または経路計算要求をPCEに送るためにPLRは構成できます([PCE-ARCH]を見てください)。

   Consider the following scenario (Figure 1).

以下のシナリオが(図1)であると考えてください。

   Assumptions:

仮定:

   - A multi-area network made of three areas: 0, 1, and 2.

- マルチ領域ネットワークは3で領域を作りました: 0、1、および2。

   - A fast reroutable TE LSP T1 (TE LSP signaled with the "Local
     Protection Desired" bit set in the SESSION-ATTRIBUTE object or the
     FAST-REROUTE object) from R0 to R3.

- 速いR0からR3までのreroutable TE LSP T1(「地方の保護必要な」ビットで合図されたTE LSPはSESSION-ATTRIBUTE物かFAST-REROUTE物にセットしました)。

Vasseur, et al.             Standards Track                     [Page 2]

RFC 4561          Definition of RRO Node-Id Sub-Object         June 2006

Vasseur、他 規格はノードイドサブ物の2006年6月に4561年のRROのRFC定義を追跡します[2ページ]。

   - A backup tunnel B1 from R1 to R2, not traversing ABR1, and
     following the R1-ABR3-R2 path.

- R1からABR1を横断して、R1-ABR3-R2経路に続かないR2までのバックアップトンネルB1。

   - The PLR R1 reroutes any protected TE LSP traversing ABR1 onto the
     backup tunnel B1 in case of ABR1's failure.

- PLR R1はABR1の失敗の場合にバックアップトンネルB1にABR1を横断するどんな保護されたTE LSPも別ルートで送ります。

             <--- area 1 --><---area 0---><---area 2--->
                R0-----R1-ABR1--R2------ABR2--------R3
                       \        /
                        \      /
                          ABR3

<。--- 領域1--><。---領域0---><、-、--領域2--->R0-----R1-ABR1--R2------ABR2--------R3\/\/ABR3

      Figure 1: Use of Fast Reroute to protect a TE LSP against an ABR
                failure with MPLS Traffic Engineering Fast Reroute

図1: MPLS Traffic Engineering Fast Rerouteと共にABRの故障に対してTE LSPを保護するFast Rerouteの使用

   When T1 is first signaled, the PLR R1 needs to dynamically select an
   appropriate backup tunnel intersecting T1 on a downstream LSR.
   However, existing protocol mechanisms are not sufficient to
   unambiguously find the MP address in a network with inter-domain TE
   LSP.  This document addresses these limitations.

T1が最初に合図されるとき、PLR R1は、川下のLSRでダイナミックに適切なバックアップトンネル交差T1を選択する必要があります。 しかしながら、既存のプロトコルメカニズムは、相互ドメインTE LSPと共にネットワークでMPアドレスを明白に見つけるために十分ではありません。 このドキュメントはこれらの制限を記述します。

   R1 needs to select an existing backup tunnel with the following
   properties:

R1は、以下の特性がある既存のバックアップトンネルを選択する必要があります:

      1. The backup tunnel intersects with the primary tunnel at the MP.
         For the sake of illustration, in Figure 1, R1 needs to
         determine that T1 and B1 intersect at the node R2.

1. バックアップトンネルはMPの第一のトンネルに横切られます。 イラストのために、図1では、R1は、T1とB1がノードR2で交差することを決定する必要があります。

      2. The backup tunnel satisfies the primary LSP's request with
         respect to the bandwidth protection request (i.e., bandwidth
         guaranteed for the primary tunnel during failure), and the type
         of protection (link or node failure), as specified in
         [FAST-REROUTE].

2. バックアップトンネルは[FAST-REROUTE]の指定されるとしての帯域幅保護要求(すなわち、失敗の間に第一のトンネルに保証された帯域幅)、および保護のタイプ(リンクかノード障害)に関して第一のLSPの要望に応じます。

   One technique for the PLR to ensure that condition (1) is met
   consists of examining the Record Route Object (RRO) of the primary
   tunnel to see whether any of the addresses specified in the RRO
   correspond to the MP.  That said, as per [RSVP-TE], the addresses
   specified in the RRO IPv4 or IPv6 sub-objects sent in Resv messages
   can be node-ids and/or interface addresses.  Hence, in Figure 1,
   router R2 may specify interface addresses in the RROs for T1 and B1.
   Note that these interface addresses are different in this example.

PLRが、条件(1)が満たされるのを保証する1つのテクニックがRROで指定されたアドレスのどれかがMPに文通されるかどうか確認するために、第一のトンネルのRecord Route Object(RRO)を調べるのから成ります。 それは言いました、[RSVP-TE]に従って、とアドレスがRRO IPv4で指定したか、またはIPv6サブ物は、Resvメッセージがノードイド、そして/または、インターフェース・アドレスであるかもしれないことを送りました。 したがって、図1では、ルータR2はT1とB1のためのRROsのインターフェース・アドレスを指定するかもしれません。 これらのインターフェース・アドレスがこの例において異なっていることに注意してください。

   The problem of finding the MP using the interface addresses or node-
   ids can be easily solved in the case of a single IGP area.
   Specifically, in the case of a single IGP area, the PLR has the
   knowledge of all the interfaces attached to the tail-end of the
   backup tunnel.  This information is available in PLR's IGP topology

ただ一つのIGP領域の場合で容易に、インターフェース・アドレスかノードイドを使用することでMPを見つけるという問題を解決できます。 明確に、ただ一つのIGP領域の場合では、PLRはすべてのインタフェースに関する知識をバックアップトンネルの末端に添付させます。 この情報はPLRのIGPトポロジーで利用可能です。

Vasseur, et al.             Standards Track                     [Page 3]

RFC 4561          Definition of RRO Node-Id Sub-Object         June 2006

Vasseur、他 規格はノードイドサブ物の2006年6月に4561年のRROのRFC定義を追跡します[3ページ]。

   database.  Thus, the PLR can unambiguously determine whether a backup
   tunnel intersecting a protected TE LSP on a downstream node exists
   and can also find the MP address regardless of how the addresses
   carried in the RRO IPv4 or IPv6 sub-objects are specified (i.e.,
   whether using the interface addresses or the node-ids).  However,
   such routing information is not available in the case of inter-domain
   environments.  Hence, unambiguously making sure that condition (1)
   above is met in the case of inter-domain TE LSPs is not possible with
   existing mechanisms.

データベース。 したがって、PLRはバックアップが交差にトンネルを堀るか否かに関係なく、川下のノードの上の保護されたTE LSPが存在することを明白に決定できて、アドレスがRRO IPv4で運ばれたか、またはIPv6サブ物がどう指定されているかにかかわらずまた、MPアドレスを見つけることができます(すなわち、インターフェース・アドレスかノードイドを使用するか否かに関係なく)。 しかしながら、そのようなルーティング情報は相互ドメイン環境の場合で利用可能ではありません。 相互ドメインTE LSPsの場合で上の状態(1)に会うのをしたがって、明白に確実にするのは既存のメカニズムで可能ではありません。

   In this document, we define extensions to and describe the use of
   Resource Reservation Protocol (RSVP) [RSVP, RSVP-TE] to solve the
   above-mentioned problem.  Note that the requirement for the support
   of the fast recovery technique specified in [FAST-REROUTE] to inter-
   domain TE LSPs has been specified in [INTER-AREA-TE-REQS] and
   [INTER-AS-TE-REQS].

本書では、私たちは、上記の問題を解決するためにResource予約プロトコル(RSVP)[RSVP、RSVP-TE]について拡大を定義して、使用について説明します。 [FAST-REROUTE]で相互ドメインTE LSPsに指定された速いリカバリ技術のサポートのための要件が[INTER-AREA-TE-REQS]と[INTER-AS-TE-REQS]で指定されたことに注意してください。

2.  Terminology

2. 用語

   Area Border Routers (ABRs): Border routers used to connect two
   Interior Gateway Protocol (IGP) areas (areas in OSPF or levels in
   IS-IS).

境界ルータ(ABRs): 境界ルータが以前はよく2Interiorゲートウェイプロトコル(IGP)部門をつなげていた、(OSPFの領域か中のレベル、-、)

   Autonomous System Border Router (ASBRs): Border routers used to
   connect to another AS of a different or the same Service Provider via
   one or more links inter-connecting between ASes.

自律システム境界ルータ(ASBRs): 境界ルータは、ASesの間で内部連絡しながら、1個以上のリンクを通して異なるか同じService Providerの別のASに接続していました。

   Backup Tunnel: The LSP that is used to back up one of the many LSPs
   in many-to-one backup.

トンネルのバックアップをとってください: 1つへの多くにおけるLSPsがバックアップをとる多くのうちの1つを支援するのに使用されるLSP。

   Inter-AS TE LSP: A TE LSP that crosses an AS boundary.

相互、Te LSP: AS境界に交差するTE LSP。

   Inter-area TE LSP: A TE LSP that crosses an IGP area.

相互領域Te LSP: IGP領域に交差するTE LSP。

   LSR: Label Switching Router.

LSR: 切り換えルータをラベルしてください。

   LSP: Label Switched Path.

LSP: ラベルは経路を切り換えました。

   Local Repair: Techniques used to repair TE LSPs quickly when a link,
   an SRLG, or a node along the TE LSP fails.

局部的修繕: TE LSPに沿ったリンク、SRLG、またはノードが失敗するとき、テクニックは以前はすぐによくTE LSPsを修理していました。

   PCE: Path Computation Element.  An entity (component, application, or
   network node) that is capable of computing a network path or route
   based on a network graph and applying computational constraints.

PCE: 経路計算要素。 ネットワーク経路かルートを計算できる実体(コンポーネント、アプリケーション、またはネットワーク・ノード)はグラフと適用のコンピュータの規制をネットワークに基礎づけました。

   MP: Merge Point.  The LSR where one or more backup tunnels rejoin the
   path of the protected LSP downstream of the potential failure.

MP: ポイントを合併してください。 1つ以上のバックアップがトンネルを堀るLSRは起こりうる失敗の保護されたLSP川下の経路に再び加わります。

Vasseur, et al.             Standards Track                     [Page 4]

RFC 4561          Definition of RRO Node-Id Sub-Object         June 2006

Vasseur、他 規格はノードイドサブ物の2006年6月に4561年のRROのRFC定義を追跡します[4ページ]。

   Protected LSP: An LSP is said to be protected at a given hop if it
   has one or multiple associated backup tunnels originating at that
   hop.

保護されたLSP: それには1つがあるか、またはおまけに、由来する複数の関連バックアップトンネルが跳ぶなら、LSPは与えられたホップに保護されると言われます。

   PLR: Point of Local Repair.  The head-end of a backup tunnel.

PLR: 局部的修繕のポイント。 バックアップトンネルのギヤエンド。

   Reroutable LSP: Any LSP for which the "Local Protection Desired" bit
   is set in the Flag field of the SESSION_ATTRIBUTE object of its Path
   messages.

Reroutable LSP: 「望まれていた地方の保護」に噛み付いたどんなLSPもPathメッセージのSESSION_ATTRIBUTE物のFlag分野で用意ができています。

   TE LSP: Traffic Engineering Label Switched Path.

Te LSP: 交通工学ラベルは経路を切り換えました。

2.1.  Conventions Used in This Document

2.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]で説明されるように本書では解釈されることであるべきですか?

3.  Signaling Node-Ids in RROs

3. RROsのシグナリングノードイド

   As mentioned above, the limitation that we need to address is the
   generality of the contents of the RRO IPv4 and IPv6 sub-objects, as
   defined in [RSVP-TE].  [RSVP-TE] defines the IPv4 and IPv6 RRO sub-
   objects.  Moreover, two additional flags are defined in
   [FAST-REROUTE]: the "Local Protection Available" and "Local
   Protection in Use" bits.

以上のように、私たちが記述する必要がある制限は[RSVP-TE]で定義されるようにRRO IPv4とIPv6サブ物のコンテンツの一般性です。 [RSVP-TE]はIPv4とIPv6 RROサブ物を定義します。 そのうえ、2個の追加旗が[FAST-REROUTE]で定義されます: 「利用可能な地方の保護」と「使用中の地方の保護」ビット。

   In this document, we define the following new flag:

本書では、私たちは以下の新しい旗を定義します:

   Node-id: 0x20

ノードイド: 0×20

      When set, this indicates that the address specified in the RRO's
      IPv4 or IPv6 sub-object is a node-id address, which refers to the
      "Router Address" as defined in [OSPF-TE], or "Traffic Engineering
      Router ID" as defined in [ISIS-TE].  A node MUST use the same
      address consistently.  Once an address is used in the RRO's IPv4
      or IPv6 sub-object, it SHOULD always be used for the lifetime of
      the TE LSP.

設定されると、これは、RROのIPv4かIPv6サブ物で指定されたアドレスがノードイドアドレスであることを示します。(それは、[OSPF-TE]で定義される「ルータアドレス」、または[イシス-TE]で定義される「交通工学Router ID」について言及します)。 ノードは一貫して同じアドレスを使用しなければなりません。 かつて、アドレスはRROのIPv4かIPv6サブ物で使用されて、それはSHOULDです。いつもTE LSPの生涯に使用されます。

   An IPv4 or IPv6 RRO sub-object with the node-id flag set is also
   called a node-id sub-object.  The problem of finding an MP address in
   a network with inter-domain TE LSP is solved by inserting a node-id
   sub-object (an RRO "IPv4" and "IPv6" sub-object with the 0x20 flag
   set) in the RRO object carried in the RSVP Resv message.

また、ノードイド旗のセットによるサブ物のIPv4かIPv6 RROがノードイドサブ物と呼ばれます。 相互ドメインTE LSPと共にネットワークでMPアドレスを見つけるという問題がノードイドサブ物を挿入することによって解決されている、(RRO、「IPv4"と「0×20旗のセット) RRO物がRSVP Resvメッセージで運んだコネによるサブ物のIPv6"。」

Vasseur, et al.             Standards Track                     [Page 5]

RFC 4561          Definition of RRO Node-Id Sub-Object         June 2006

Vasseur、他 規格はノードイドサブ物の2006年6月に4561年のRROのRFC定義を追跡します[5ページ]。

   An implementation may decide to either:

実現はどちらかに決めるかもしれません:

   1) Add the node-id sub-object in the RRO carried in an RSVP Resv
      message and, when required, also add another IPv4/IPv6 sub-object
      to record interface address.

1) RROのサブ物のノードイドがRSVP Resvメッセージで運ばれたと言い足してください、そして、また、必要であったら、インターフェース・アドレスを記録するためにはサブ物の別のIPv4/IPv6を言い足してください。

      Example: an inter-domain fast reroutable TE LSP would have the
      following two sub-objects in the RRO carried in Resv message: a
      node-id sub-object and a label sub-object.  If recording the
      interface address is required, then an additional IPv4/IPv6 sub-
      object is added.

例: 相互ドメインの速いreroutable TE LSPはResvメッセージで運ばれたRROでサブ物であるのに以下の2を持っているでしょう: ノードイドサブ物とラベルサブ物。 インターフェース・アドレスを記録するのが必要であるなら、追加IPv4/IPv6サブ物は加えられます。

   or

または

   2) Add an IPv4/IPv6 sub-object recording the interface address and,
      when required, add a node-id sub-object in the RRO.

2) インターフェース・アドレスを記録して、IPv4/IPv6サブ物を加えてください、そして、必要であったら、RROのサブ物のノードイドを加えてください。

      Example: an inter-domain fast reroutable TE LSP would have the
      following three sub-objects in the RRO carried in Resv message: an
      IPv4/IPv6 sub-object recording interface address, a label sub-
      object, and a node-id sub-object.

例: 相互ドメインの速いreroutable TE LSPはResvメッセージで運ばれたRROでサブ物であるのに以下の3を持っているでしょう: インターフェース・アドレスを記録するIPv4/IPv6サブ物、ラベルサブ物、およびノードイドサブ物。

   Note also that the node-id sub-object may have other applications
   than Fast Reroute backup tunnel selection.  Moreover, it is
   RECOMMENDED that an LSR recording a node-id address in an IPv4/IPv6
   RRO sub-object also set the node-id flag.

また、Fast Reroute以外のアプリケーションがノードイドサブ物でトンネル選択のバックアップをとるかもしれないことに注意してください。 そのうえ、また、ノードイドアドレスをIPv4/IPv6 RROサブ物に記録するLSRがノードイド旗を設定したのは、RECOMMENDEDです。

4.  Finding Merge Point

4. マージがポイントであることがわかります。

   Two cases should be considered:

2つのケースが考えられるべきです:

   - Case 1: If the backup tunnel destination is the MP's node-id, then
     a PLR can find the MP and suitable backup tunnel by simply
     comparing the backup tunnel's destination address with the node-id
     included in the RRO of the primary tunnel.

- ケース1: バックアップトンネルの目的地がMPのノードイドであるなら、PLRは、単に第一のトンネルのRROに含まれていたノードイドとバックアップトンネルの送付先アドレスを比べることによって、MPと適当なバックアップトンネルを見つけることができます。

   - Case 2: If the backup tunnel terminates at an address different
     from the MP's node-id, then a node-id sub-object MUST also be
     included in the RRO of the backup tunnel.  A PLR can find the MP
     and suitable backup tunnel by simply comparing the node-ids present
     in the RROs of both the primary and backup tunnels.

- ケース2: また、バックアップトンネルがMPのノードイドと異なったアドレスで終わるなら、バックアップトンネルのRROにノードイドサブ物を含まなければなりません。 PLRは、予備選挙とバックアップトンネルの両方のRROsで単にノードイドを比較するのによるMPと適当なバックアップトンネルに出席しているのを見つけることができます。

   It must be noted that although the technique described in this
   document for selecting an appropriate backup tunnel using the node-id
   sub-object applies to the case of Inter-area and Inter-AS, in the
   case of Inter-AS, the assumption is made that the MP's node-id (of
   the downstream domain) does not overlap with any LSR's node-id
   present in the PLR's AS.

ノードイドサブ物を使用することで本書では適切なバックアップトンネルを選択するために説明されたテクニックがInter-領域とInter-ASに関するケースに適用されますが、Inter-ASの場合では、MPのノードイド(川下のドメインの)がPLRのASでのどんなLSRのノードイドプレゼントにも重ならないという仮定がされることに注意しなければなりません。

Vasseur, et al.             Standards Track                     [Page 6]

RFC 4561          Definition of RRO Node-Id Sub-Object         June 2006

Vasseur、他 規格はノードイドサブ物の2006年6月に4561年のRROのRFC定義を追跡します[6ページ]。

   When both IPv4 node-id and IPv6 node-id sub-objects are present, a
   PLR may use any or both of them in finding the MP address.

IPv4ノードイドとIPv6ノードイドサブ物の両方が存在しているとき、PLRはMPアドレスを見つける際にそれらのいずれか両方を使用するかもしれません。

5.  Security Considerations

5. セキュリティ問題

   This document does not introduce new security issues.  The security
   considerations pertaining to [RSVP] and [RSVP-TE] remain relevant.

このドキュメントは新しい安全保障問題を紹介しません。 [RSVP]と[RSVP-TE]に関係するセキュリティ問題は関連していたままで残っています。

6.  Acknowledgements

6. 承認

   We would like to acknowledge input and helpful comments from Carol
   Iturralde, Anca Zamfir, Reshad Rahman, Rob Goguen, and Philip
   Matthews.  A special thanks to Adrian Farrel for his thorough review
   of this document.

キャロル・イトゥラルデ、アンカZamfir、Reshadラーマン、ロブGoguen、およびフィリップ・マシューズから入力と役に立つコメントを承諾したいと思います。 彼のこのドキュメントの徹底的なレビューのためのエードリアン・ファレルのおかげで特別番組。

7.  References

7. 参照

7.1.  Normative References

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

   [RSVP]               Braden, R., Zhang, L., Berson, S., Herzog, S.,
                        and S. Jamin, "Resource ReSerVation Protocol
                        (RSVP) -- Version 1 Functional Specification",
                        RFC 2205, September 1997.

[RSVP] ブレーデン、R.、チャン、L.、Berson、S.、ハーツォグ、S.、およびS.ジャマン、「資源予約は(RSVP)について議定書の中で述べます--バージョン1の機能的な仕様」、RFC2205、1997年9月。

   [RSVP-TE]            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.

[RSVP-Te] Awduche、D.、バーガー、L.、ガン、D.、李、T.、Srinivasan、V.、およびG.が飲み込まれる、「RSVP-Te:」 「LSP TunnelsのためのRSVPへの拡大」、RFC3209、2001年12月。

   [FAST-REROUTE]       Pan, P., Swallow, G., and A. Atlas, "Fast
                        Reroute Extensions to RSVP-TE for LSP Tunnels",
                        RFC 4090, May 2005.

[速く、コースを変更します] なべ(P.、ツバメ、G.、およびA.Atlas、「LSP Tunnelsのために速くRSVP-Teに拡大を別ルートで送ってください」、RFC4090)は、2005がそうするかもしれません。

   [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月。」

   [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月)

Vasseur, et al.             Standards Track                     [Page 7]

RFC 4561          Definition of RRO Node-Id Sub-Object         June 2006

Vasseur、他 規格はノードイドサブ物の2006年6月に4561年のRROのRFC定義を追跡します[7ページ]。

7.2.  Informative References

7.2. 有益な参照

   [INTER-AREA-TE-REQS] Le Roux, J.-L., Vasseur, J.-P., and J. Boyle,
                        "Requirements for Inter-Area MPLS Traffic
                        Engineering", RFC 4105, June 2005.

[相互領域Te REQS] ル・ルー、J.-L.、Vasseur、J.-P.、およびJ.ボイル、「相互領域MPLS交通工学のための要件」、RFC4105、2005年6月。

   [INTER-AS-TE-REQS]   Zhang, R. and J.-P. Vasseur, "MPLS Inter-
                        Autonomous System (AS) Traffic Engineering (TE)
                        Requirements", RFC 4216, November 2005.

[相互、Te REQS、]、チャン、R.、およびJ.-P。 Vasseur、「MPLS相互自律システム(AS)交通工学(Te)要件」、RFC4216、2005年11月。

   [PCE-ARCH]           Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
                        Computation Element (PCE) Based Architecture",
                        Work in Progress, April 2006.

[PCE-アーチ] ファレル、A.、Vasseur、J.-P.、J.灰、「経路計算要素(PCE)は構造を基礎づけたこと」が進歩、2006年4月に働いています。

Vasseur, et al.             Standards Track                     [Page 8]

RFC 4561          Definition of RRO Node-Id Sub-Object         June 2006

Vasseur、他 規格はノードイドサブ物の2006年6月に4561年のRROのRFC定義を追跡します[8ページ]。

Authors' Addresses

作者のアドレス

   J.-P. Vasseur (Editor)
   Cisco Systems, Inc.
   1414 Massachusetts Avenue
   Boxborough , MA - 01719
   USA

J.-P。 マサチューセッツ通りBoxborough、Vasseur(エディタ)シスコシステムズInc.1414MA--01719米国

   EMail: jpv@cisco.com

メール: jpv@cisco.com

   Zafar Ali
   Cisco Systems, Inc.
   100 South Main St. #200
   Ann Arbor, MI 48104
   USA

ZafarのアリシスコシステムズInc.100の南Main聖#200MI48104アナーバー(米国)

   EMail: zali@cisco.com

メール: zali@cisco.com

   Siva Sivabalan
   Cisco Systems, Inc.
   2000 Innovation Drive
   Kanata, Ontario, K2K 3E8
   Canada

ドライブKanata、K2K3の8EのシバSivabalanシスコシステムズInc.2000Innovationオンタリオ(カナダ)

   EMail: msiva@cisco.com

メール: msiva@cisco.com

Vasseur, et al.             Standards Track                     [Page 9]

RFC 4561          Definition of RRO Node-Id Sub-Object         June 2006

Vasseur、他 規格はノードイドサブ物の2006年6月に4561年のRROのRFC定義を追跡します[9ページ]。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2006).

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

   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 provided by the IETF
   Administrative Support Activity (IASA).

RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。

Vasseur, et al.             Standards Track                    [Page 10]

Vasseur、他 標準化過程[10ページ]