RFC4781 日本語訳

Network Working Group                                         Y. Rekhter
Request for Comments: 4781                                   R. Aggarwal
Category: Standards Track                               Juniper Networks
                                                            January 2007

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

              Graceful Restart Mechanism for BGP with MPLS

MPLSとBGPのための優雅な再開メカニズム

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

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

Abstract

要約

   A mechanism for BGP that helps minimize the negative effects on
   routing caused by BGP restart has already been developed and is
   described in a separate document ("Graceful Restart Mechanism for
   BGP").  This document extends this mechanism to minimize the negative
   effects on MPLS forwarding caused by the Label Switching Router's
   (LSR's) control plane restart, and specifically by the restart of its
   BGP component when BGP is used to carry MPLS labels and the LSR is
   capable of preserving the MPLS forwarding state across the restart.

BGP再開で引き起こされたルーティングへのマイナスの効果を最小にするのを助けるBGPのためのメカニズムは、既に開発されて、別々のドキュメント(「BGPのための優雅な再開メカニズム」)で説明されます。 このドキュメントは、BGPがMPLSラベルを運ぶのに使用されて、LSRが再開の向こう側にMPLS推進状態を保持できるときのLabel Switching Routerの(LSR)のコントロール飛行機再開、および特にBGPの部品の再開で引き起こされたMPLS推進へのマイナスの効果を最小にするためにこのメカニズムを広げています。

   The mechanism described in this document is agnostic with respect to
   the types of the addresses carried in the BGP Network Layer
   Reachability Information (NLRI) field.  As such, it works in
   conjunction with any of the address families that could be carried in
   BGP (e.g., IPv4, IPv6, etc.).

本書では説明されたメカニズムはBGP Network Layer Reachability情報(NLRI)分野で運ばれたアドレスのタイプに関して不可知論者です。 そういうものとして、それはBGP(例えば、IPv4、IPv6など)で運ぶことができたアドレス家族のどれかに関連して働いています。

Rekhter & Aggarwal          Standards Track                     [Page 1]

RFC 4781           Graceful Restart Mechanism for BGP       January 2007

Rekhter&Aggarwal規格は2007年1月にBGPのためにRFC4781の優雅な再開メカニズムを追跡します[1ページ]。

Table of Contents

目次

   1. Introduction ....................................................2
      1.1. Specification of Requirements ..............................3
   2. General Requirements ............................................3
   3. Capability Advertisement ........................................4
   4. Procedures for the Restarting LSR ...............................4
      4.1. Case 1 .....................................................4
      4.2. Case 2 .....................................................5
      4.3. Case 3 .....................................................5
   5. Alternative Procedures for the Restarting LSR ...................6
   6. Procedures for a Neighbor of a Restarting LSR ...................6
   7. Comparison between Alternative Procedures for the
      Restarting LSR ..................................................7
   8. Security Considerations .........................................8
   9. Acknowledgments .................................................9
   10. References .....................................................9
      10.1. Normative References ......................................9
      10.2. Informative References ....................................9

1. 序論…2 1.1. 要件の仕様…3 2. 一般要件…3 3. 能力広告…4 4. 再開しているLSRのための手順…4 4.1. ケース1…4 4.2. ケース2…5 4.3. ケース3…5 5. 再開しているLSRのための交替手続き…6 6. 再開LSRの隣人のための手順…6 7. 再開しているLSRのための交替手続きでの比較…7 8. セキュリティ問題…8 9. 承認…9 10. 参照…9 10.1. 標準の参照…9 10.2. 有益な参照…9

1.  Introduction

1. 序論

   In the case where a Label Switching Router (LSR) could preserve its
   MPLS forwarding state across restart of its control plane, and
   specifically its BGP component, and BGP is used to carry MPLS labels
   (e.g., as specified in [RFC3107]), it may be desirable not to perturb
   the LSPs going through that LSR (and specifically, the LSPs
   established by BGP) after failure or restart of the BGP component of
   the control plane.  In this document, we describe a mechanism that
   allows this goal to be accomplished.  The mechanism described in this
   document works in conjunction with the mechanism specified in
   [RFC4724].  The mechanism described in this document places no
   restrictions on the types of addresses (address families) that it can
   support.

Label Switching Router(LSR)が制御飛行機の再開の向こう側に状態を進めるMPLS、および明確にそのBGPの部品を保存できて、BGPがMPLSラベルを運ぶのに使用される(例えば、[RFC3107]で指定されるように)場合では、制御飛行機のBGPの部品の失敗か再開の後にそのLSR(そして、明確にBGPによって設立されたLSPs)を通るLSPsを混乱させないのは望ましいかもしれません。 本書では、私たちはこの目標が達成されるのを許容するメカニズムについて説明します。 本書では説明されたメカニズムは[RFC4724]で指定されたメカニズムに関連して動作します。 本書では説明されたメカニズムはそれがサポートできるアドレス(アドレス家族)のタイプに関して制限を全く課しません。

   The mechanism described in this document is applicable to all LSRs,
   both those with the ability to preserve forwarding state during BGP
   restart and those without it (although the latter need to implement
   only a subset of this mechanism).  Supporting a subset of the
   mechanism described here by the LSRs that cannot preserve their MPLS
   forwarding state across the restart would not reduce the negative
   impact on MPLS traffic caused by their control plane restart.
   However, the impact would be minimized if their neighbor(s) are
   capable of preserving the forwarding state across the restart of
   their control plane, and if they implement the mechanism described
   here.  The subset includes all the procedures described in this
   document, except the procedures in Sections 4.1, 4.2, 4.3, and 5.

本書では説明されたメカニズムはLSRs、BGP再開の間に推進状態を保持する能力があるそれらとそれのないそれらのすべての両方に適切です(後者は、このメカニズムの部分集合だけを実行する必要がありますが)。 ここで再開の向こう側に彼らのMPLS推進状態を保持できないLSRsによって説明されたメカニズムの部分集合をサポートする場合、彼らのコントロール飛行機再開で引き起こされたMPLS交通への負の衝撃は減少しないでしょう。 しかしながら、彼らの隣人がそれらの制御飛行機の再開の向こう側に推進状態を保持できて、彼らがここで説明されたメカニズムを実行するなら、衝撃は最小にされるでしょう。 部分集合はセクション4.1、4.2、4.3、および5の手順を除いて、本書では説明されたすべての手順を含んでいます。

Rekhter & Aggarwal          Standards Track                     [Page 2]

RFC 4781           Graceful Restart Mechanism for BGP       January 2007

Rekhter&Aggarwal規格は2007年1月にBGPのためにRFC4781の優雅な再開メカニズムを追跡します[2ページ]。

   For the sake of brevity, by "MPLS forwarding state" we mean one of
   the following mappings:
      <incoming label -> (outgoing label, next hop)>
      <Forwarding Equivalence Class (FEC) -> (outgoing label, next hop)>
      <incoming label -> label pop, next hop>
      <incoming label, label pop>

簡潔にするために、「MPLS推進状態」で、私たちは以下のマッピングの1つを言っています: <の入って来るラベル->(出発しているラベル、次のホップ)><Forwarding Equivalence Class(FEC)->(出発しているラベル、次のホップ)の<の入って来るラベル->ラベル>ポップス、次に、>の<の入って来るラベル、ラベルポップス>は跳びます。

   In the context of this document, the forwarding state that is
   referred to in [RFC4724] means MPLS forwarding state, as defined
   above.  The term "next hop" refers to the next hop as advertised in
   BGP.

このドキュメントの文脈では、[RFC4724]で言及される推進州はMPLS推進状態を意味します、上で定義されるように。 「次のホップ」という用語はBGPの広告に掲載されている次のホップについて言及します。

1.1.  Specification of Requirements

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

2.  General Requirements

2. 一般要件

   First of all, an LSR MUST implement the Graceful Restart Mechanism
   for BGP, as specified in [RFC4724].  Second, the LSR SHOULD be
   capable of preserving its MPLS forwarding state across the restart of
   its control plane (including the restart of BGP).  Third, for the
   <Forwarding Equivalence Class (FEC) -> label> bindings distributed
   via BGP, the LSR SHOULD be able either (a) to reconstruct the same
   bindings as the LSR had prior to the restart (see Section 4), or (b)
   to create new <FEC -> label> bindings after restart, while
   temporarily maintaining MPLS forwarding state corresponding to both
   the bindings prior to the restart, as well as to the newly created
   bindings (see Section 5).  Fourth, as long as the LSR retains the
   MPLS forwarding state that the LSR preserved across the restart, the
   labels from that state cannot be used to create new local label
   bindings (but could be used to reconstruct the existing bindings, as
   per procedures in Section 4).  Finally, for each next hop, if the
   next hop is reachable via a Label Switched Path (LSP), then the
   restarting LSR MUST be able to preserve the MPLS forwarding state
   associated with that LSP across the restart.

まず、LSR MUSTはBGPのために[RFC4724]で指定されるようにGraceful Restart Mechanismを実行します。 2番目、LSR SHOULD、制御飛行機の再開の向こう側にMPLS推進状態を保持できてください(BGPの再開を含んでいて)。 BGP、LSR SHOULDを通して広げられた<Forwarding Equivalence Class(FEC)->ラベル>結合において3番目に、できてください。LSRと同じ結合を再建する(a)は再開の後に再開(セクション4を見る)、または(b)の前に再開の前に両方の結合に対応する状態を進めながら一時MPLSを維持している間、新しい<FEC->ラベル>結合を作成しなければなりませんでした、よく新たに作成された結合のように(セクション5を見てください)。 4番目に、LSRがLSRが再開の向こう側に保持したMPLS推進状態を保有する限り、新しい地方のラベル結合(しかし、セクション4の手順に従って既存の結合を再建するのに使用できた)を作成するのにその状態からのラベルを使用できません。 次のホップがLabel Switched Path(LSP)、当時の再開しているLSR MUSTを通して届くなら次が飛び越すそれぞれに関して、最終的に、再開の向こう側にそのLSPに関連しているMPLS推進状態を保持できてください。

   In the scenario where label binding on an LSR is created/maintained
   not only by the BGP component of the control plane, but also by other
   protocol components (e.g., LDP, RSVP-TE), and where the LSR supports
   restart of the individual components of the control plane that
   create/maintain label binding (e.g., restart of BGP, but no restart
   of LDP), the LSR MUST be able to preserve across the restart the
   information about which protocol has assigned which labels.

LSRにおけるラベル結合が制御飛行機のBGPの部品だけではなく、他のプロトコルコンポーネント(例えば、自由民主党、RSVP-TE)によって作成されるか、または維持されて、LSRサポートが再開するラベル結合が(例えば、BGPの再開にもかかわらず、自由民主党を再開がありません)であると作成するか、または主張する制御飛行機の個々の部品、LSR MUSTのシナリオでは、再開の向こう側にプロトコルがどのラベルを割り当てた情報を保存できてください。

Rekhter & Aggarwal          Standards Track                     [Page 3]

RFC 4781           Graceful Restart Mechanism for BGP       January 2007

Rekhter&Aggarwal規格は2007年1月にBGPのためにRFC4781の優雅な再開メカニズムを追跡します[3ページ]。

   After the LSR restarts, it MUST follow the procedures as specified in
   [RFC4724].  In addition, if the LSR is able to preserve its MPLS
   forwarding state across the restart, the LSR SHOULD advertise this to
   its neighbors by appropriately setting the Flag for Address Family
   field in the Graceful Restart Capability for all applicable AFI/SAFI
   pairs.

LSRが再開した後に、それは[RFC4724]の指定されるとしての手順に従わなければなりません。 さらに、LSRが再開の向こう側にMPLS推進状態を保持できるなら、LSR SHOULDは、適切にAddress Family分野へのFlagをGraceful Restart Capabilityにすべての適切なAFI/サフィ組はめ込むことによって、隣人にこれの広告を出します。

3.  Capability Advertisement

3. 能力広告

   An LSR that supports the mechanism described in this document
   advertises this to its peer by using the Graceful Restart Capability,
   as specified in [RFC4724].  The Subsequent Address Family Identifier
   (SAFI) in the advertised capability MUST indicate that the Network
   Layer Reachability Information (NLRI) field carries not only
   addressing Information, but also labels (see [RFC3107] for an example
   of where NLRI carries labels).

本書では説明されたメカニズムをサポートするLSRはGraceful Restart Capabilityを使用することによって、同輩にこれの広告を出します、[RFC4724]で指定されるように。 広告を出している能力におけるSubsequent Address Family Identifier(サフィ)は、Network Layer Reachability情報(NLRI)野原が情報だけではなく、ラベルも記述しながら運ばれるのを示さなければなりません(NLRIがラベルを運ぶところに関する例に関して[RFC3107]を見てください)。

4.  Procedures for the Restarting LSR

4. 再開しているLSRのための手順

   Procedures in this section apply when a restarting LSR is able to
   reconstruct the same <FEC -> label> bindings as the LSR had prior to
   the restart.

再開LSRがLSRとしての>結合が再開の前に持っていた同じ<FEC->ラベルを再建できるとき、このセクションの手順は適用されます。

   The procedures described in this section are conceptual and do not
   have to be implemented precisely as described, as long as the
   implementations support the described functionality and their
   externally visible behavior is the same.

このセクションで説明された手順は、概念的であり、まさに説明されるように実行される必要はありません、実現が説明された機能性を支持して、彼らの外部的に目に見える振舞いが同じである限り。

   Once the LSR completes its route selection (as specified in Section
   4.1, "Procedures for the Restarting Speaker", of [RFC4724]), then in
   addition to the those procedures, the LSR performs one of the
   following:

に加えて一度、LSRはルート選択(セクション4.1、「再開している議長のための手順」で指定される[RFC4724]の)を終了します、そしてそれらの手順、LSRは以下の1つを実行します:

4.1.  Case 1

4.1. ケース1

   The following applies when (a) the best route selected by the LSR was
   received with a label, (b) that label is not an Implicit NULL, and
   (c) the LSR advertises this route with itself as the next hop.

(c) (a) ラベルでLSRによって選択された中で最も良いルートを受け取ったとき、以下は適用されます、そして、(b) そのラベルはImplicit NULLではありません、そして、LSRは次のホップとしてそれ自体でこのルートの広告を出します。

   In this case, the LSR searches its MPLS forwarding state (the one
   preserved across the restart) for an entry with <outgoing label, next
   hop> equal to the one in the received route.  If such an entry is
   found, the LSR no longer marks the entry as stale.  In addition, if
   the entry is of type <incoming label, (outgoing label, next hop)>
   rather than <Forwarding Equivalence Class (FEC), (outgoing label,
   next hop)>, the LSR uses the incoming label from the entry when
   advertising the route to its neighbors.  If the found entry has no
   incoming label, or if no such entry is found, the LSR allocates a new

この場合、LSRは、<の出発しているラベル、容認されたルートによるものと等しい次のホップ>とのエントリーに状態(再開の向こう側に保存されたもの)を送りながら、MPLSを捜します。 そのようなエントリーが見つけられるなら、LSRは、もうエントリーが聞き古したであるマークしません。 隣人にルートの広告を出すとき、さらに、エントリーがタイプ<入って来るラベル、<Forwarding Equivalence Class(FEC)、(出発しているラベル、次のホップ)>よりむしろ(出発しているラベル、次のホップ)>のものであるなら、LSRはエントリーから入って来るラベルを使用します。 備え付けることのエントリーではどんな入って来るラベルもないか、またはどれかそのようなエントリーが当たられないなら、LSRが新しい状態でaを割り当てます。

Rekhter & Aggarwal          Standards Track                     [Page 4]

RFC 4781           Graceful Restart Mechanism for BGP       January 2007

Rekhter&Aggarwal規格は2007年1月にBGPのためにRFC4781の優雅な再開メカニズムを追跡します[4ページ]。

   label when advertising the route to its neighbors (assuming that
   there are neighbors to which the LSR has to advertise the route with
   a label).

隣人にルートの広告を出すとき(LSRがラベルでルートの広告を出さなければならない隣人がいると仮定して)、ラベルします。

4.2.  Case 2

4.2. ケース2

   The following applies when (a) the best route selected by the LSR was
   received either without a label, with an Implicit NULL label, or the
   route is originated by the LSR; (b) the LSR advertises this route
   with itself as the next hop; and (c) the LSR has to generate a (non-
   Implicit NULL) label for the route.

(a) Implicit NULLラベルでラベルなしでLSRによって選択された中で最も良いルートを受け取ったか、またはLSRがルートを溯源するとき、以下は適用されます。 (b) LSRは次のホップとしてそれ自体でこのルートの広告を出します。 (c) そして、LSRは(非内在しているNULL)ラベルをルートに発生させなければなりません。

   In this case, the LSR searches its MPLS forwarding state for an entry
   that indicates that the LSR has to perform label pop, and the next
   hop equal to the next hop of the route in consideration.  If such an
   entry is found, then the LSR uses the incoming label from the entry
   when advertising the route to its neighbors.  If no such entry is
   found, the LSR allocates a new label when advertising the route to
   its neighbors.

この場合、LSRは、LSRが考慮でラベルポップス、および次のホップ同輩をルートの次のホップに実行しなければならないのを示すエントリーに状態を送りながら、MPLSを捜します。 隣人にルートの広告を出すとき、そのようなエントリーが見つけられるなら、LSRはエントリーから入って来るラベルを使用します。 隣人にルートの広告を出すとき、どれかそのようなエントリーが見つけられないなら、LSRは新しいラベルを割り当てます。

   The description in the above paragraph assumes that the LSR generates
   the same label for all the routes with the same next hop.  If this is
   not the case and the LSR generates a unique label per each such
   route, then the LSR needs to preserve across the restart not only
   <incoming label, (outgoing label, next hop)> mapping, but also the
   Forwarding Equivalence Class (FEC) associated with this mapping.  In
   such a case the LSR would search its MPLS forwarding state for an
   entry that (a) indicates label pop (means no outgoing label), (b)
   indicates that the next hop equal to the next hop of the route, and
   (c) has the same FEC as the route.  If such an entry is found, then
   the LSR uses the incoming label from the entry when advertising the
   route to its neighbors.  If no such entry is found, the LSR allocates
   a new label when advertising the route to its neighbors.

記述は、LSRが同じくらいが次のルートが飛び越すすべてのために同じラベルを発生させると前の段落で仮定します。 これがそうでなく、LSRがそのような各ルートあたり1個のユニークなラベルを発生させるなら、LSRは、再開の向こう側に<の入って来るラベル、(出発しているラベル、次のホップ)>マッピングだけではなく、このマッピングに関連しているForwarding Equivalence Class(FEC)も保存する必要があります。 このような場合にはLSRは状態をエントリーに送る(a)がポップス(どんな出発しているラベルも意味しない)を分類するのを示すMPLSを捜して、(b)は、ルートの次のホップへの次のホップ同輩、および(c)にはルートと同じFECがあるのを示します。 隣人にルートの広告を出すとき、そのようなエントリーが見つけられるなら、LSRはエントリーから入って来るラベルを使用します。 隣人にルートの広告を出すとき、どれかそのようなエントリーが見つけられないなら、LSRは新しいラベルを割り当てます。

4.3.  Case 3

4.3. ケース3

   The following applies when the LSR does not set BGP next hop to self.

LSRがどんなセットBGPにも自己への次のホップをしないと、以下は適用されます。

   In this case, the LSR, when advertising its best route for a
   particular NLRI, just uses the label that was received with that
   route.  And if the route was received with no label, the LSR
   advertises the route with no label as well.  Either way, the LSR does
   not allocate a label for that route.

この場合特定のNLRIのために最も良いルートの広告を出すとき、LSRはただそのルートで受け取られたラベルを使用します。 そして、ラベルなしでルートを受け取ったなら、LSRはまた、ラベルなしでルートの広告を出します。 いずれにせよ、LSRはそのルートにラベルを割り当てません。

Rekhter & Aggarwal          Standards Track                     [Page 5]

RFC 4781           Graceful Restart Mechanism for BGP       January 2007

Rekhter&Aggarwal規格は2007年1月にBGPのためにRFC4781の優雅な再開メカニズムを追跡します[5ページ]。

5.  Alternative Procedures for the Restarting LSR

5. 再開しているLSRのための交替手続き

   In this section, we describe an alternative to the procedures
   described in Section "Procedures for the restarting LSR".

このセクションで、私たちは「再開しているLSRのための手順」というセクションで説明された手順に代替手段を説明します。

   Procedures in this section apply when a restarting LSR does not
   reconstruct the same <FEC -> label> bindings as the LSR had prior to
   the restart, but instead creates new <FEC -> label> bindings after
   restart, while temporarily maintaining MPLS forwarding state
   corresponding to both the bindings prior to the restart, as well as
   to the newly created bindings.

再開LSRが同じ<FEC->ラベル>結合を再建しないとき、このセクションの手順はLSRが再開の前に再開の後に代わりに再開の前に両方の結合に対応する状態を進めながら一時MPLSを維持している間新しい<FEC->ラベル>結合を作成して、新たに作成された結合に適用されます。

   The procedures described in this section require that for the use by
   BGP graceful restart, the LSR SHOULD have (at least) as many
   unallocated labels as labels allocated for the <FEC -> label>
   bindings distributed by BGP.  The latter forms the MPLS forwarding
   state that the LSR managed to preserve across the restart.  The
   former is used for allocating labels after the restart.

このセクションで説明された手順は、BGPの優雅な再開による使用のために、LSR SHOULDがBGPにラベルが<FEC->ラベル>結合のために割り当てたのと同じくらい多くの「非-割り当て」られたラベルを分配させるのを(少なくとも)必要とします。 後者はLSRが再開の向こう側に何とか保持したMPLS推進状態を形成します。 前者は、再開の後にラベルを割り当てるのに使用されます。

   To create (new) local label bindings after the restart, the LSR uses
   unallocated labels (this is pretty much the normal procedure).

再開の後に(新しい)の地方のラベル結合を作成するために、LSR用途はラベルを「非-割り当て」ました(これはほとんど正常な手順です)。

   The LSR SHOULD retain the MPLS forwarding state that the LSR
   preserved across the restart at least until the LSR sends an
   End-of-RIB marker to all of its neighbors (by that time the LSR
   already completed its route selection process, and also advertised
   its Adj-RIB-Out to its neighbors).  The LSR MAY retain the forwarding
   state even a bit longer (the amount of extra time MAY be controlled
   by configuration on the LSR), so as to allow the neighbors to receive
   and process the routes that have been advertised by the LSR.  After
   that, the LSR SHOULD delete the MPLS forwarding state that it
   preserved across the restart.

LSRがRIBのEndマーカーに隣人のすべてに行かせるまで(その時までには、LSRは既にルート選択の過程を完了して、また、外のAdj-RIBの隣人に広告を出しました)、LSR SHOULDはLSRが少なくとも再開の向こう側に保持したMPLS推進状態を保有します。 LSR MAYは少し長い間さえ、推進状態を保有します(延長時間の量はLSRでの構成によって制御されるかもしれません)、隣人がLSRによって広告に掲載されているルートを受け取って、処理するのを許容するために。 その後に、LSR SHOULDはそれが再開の向こう側に保持したMPLS推進状態を削除します。

   Note that while an LSR is in the process of restarting, the LSR may
   have not one, but two local label bindings for a given BGP route --
   one that was retained from prior to restart, and another that was
   created after the restart.  Once the LSR completes its restart, the
   former will be deleted.  However, both of these bindings would have
   the same outgoing label (and the same next hop).

LSRが再開の途中にある間LSRには1、しかし、与えられたBGPルートとの2つの地方のラベル結合がないかもしれないことに注意してください--それが再開の前に保有された1、および再開の後に作成された別のもの。 LSRがいったん再開を終了すると、前者は削除されるでしょう。 しかしながら、これらの結合の両方には、同じ出発しているラベル(そして、同じ次のホップ)があるでしょう。

6.  Procedures for a Neighbor of a Restarting LSR

6. 再開LSRの隣人のための手順

   The neighbor of a restarting LSR (the receiving router terminology
   used in [RFC4724]) follows the procedures specified in [RFC4724].  In
   addition, the neighbor treats the MPLS labels received from the
   restarting LSR the same way that it treats the routes received from
   the restarting LSR (both prior and after the restart).

再開LSR(用語が[RFC4724]で使用した受信ルータ)の隣人は[RFC4724]で指定された手順に従います。 添加、MPLSラベルが再開しているLSRから受けた隣人の御馳走では、それが扱うのと同じように、ルートは再開LSR(優先的と再開の後の)から受信されました。

Rekhter & Aggarwal          Standards Track                     [Page 6]

RFC 4781           Graceful Restart Mechanism for BGP       January 2007

Rekhter&Aggarwal規格は2007年1月にBGPのためにRFC4781の優雅な再開メカニズムを追跡します[6ページ]。

   Replacing the stale routes by the routing updates received from the
   restarting LSR involves replacing/updating the appropriate MPLS
   labels.

再開しているLSRから受けられたルーティングアップデートに聞き古したルートを置き換えるのは、適切なMPLSラベルを取り替えるか、またはアップデートすることを伴います。

   In addition, if the Flags in the Graceful Restart Capability received
   from the restarting LSR indicate that the LSR wasn't able to retain
   its MPLS state across the restart, the neighbor SHOULD immediately
   remove all the NLRI and the associated MPLS labels that it previously
   acquired via BGP from the restarting LSR.

さらに、再開しているLSRから受け取られたGraceful Restart CapabilityのFlagsが、LSRが再開の向こう側にMPLS状態を保有できなかったのを示すなら、隣人SHOULDはすぐに、それが以前に再開しているLSRからのBGPを通して獲得したすべてのNLRIと関連MPLSラベルを取り外します。

   An LSR, once it creates a binding between a label and a Forwarding
   Equivalence Class (FEC), SHOULD keep the value of the label in this
   binding for as long as the LSR has a route to the FEC in the binding.
   If the route to the FEC disappears and then re-appears again later,
   then this may result in using a different label value, as when the
   route re-appears, the LSR would create a new <label, FEC> binding.

LSR、それがラベルとForwarding Equivalence Class(FEC)の間でいったん結合を作成すると、LSRが結合でFECにルートを持っている限り、SHOULDはこの結合における、ラベルの値を保ちます。 FECへのルートが後で見えなくなって、次に、再び再現するなら、これは異なったラベル値を使用するのに結果として生じるかもしれません、ルートが再現すると、LSRが新しい<ラベルを作成するだろうというとき、FEC>結合。

   To minimize the potential misrouting caused by the label change, when
   creating a new <label, FEC> binding, the LSR SHOULD pick up the least
   recently used label.  Once an LSR releases a label, the LSR SHALL NOT
   re-use this label for advertising a <label, FEC> binding to a
   neighbor that supports graceful restart for at least the Restart
   Time, as advertised by the neighbor to the LSR.  This rule SHALL
   apply to any label release at any time.

拘束力があった状態で新しい<ラベル、FEC>を作成するときラベル変化によって引き起こされた潜在的misroutingを最小にするために、LSR SHOULDは最も最近でない中古のラベルを拾います。 LSRがいったんラベルを放出すると、LSR SHALL NOTは<ラベルの広告を出すのにこのラベルを再使用します、少なくともRestart Timeのために優雅な再開を支持する隣人とのFEC>結合、隣人によってLSRに広告に掲載されているように。 この規則SHALLはいつでも、どんなラベルリリースにも適用します。

7.  Comparison between Alternative Procedures for the Restarting LSR

7. 再開しているLSRのための交替手続きでの比較

   Procedures described in Section 4 involve more computational overhead
   on the restarting router than do the procedures described in Section
   5.

セクション4で説明された手順は再開ルータに関するセクション5で説明された手順をするよりコンピュータのオーバーヘッドを伴います。

   Procedures described in Section 5 require twice as many labels as
   those described in Section 4.

ものがセクション4で説明したようにセクション5で説明された手順は2倍のラベルを必要とします。

   Procedures described in Section 4 cause fewer changes to the MPLS
   forwarding state in the neighbors of the restarting router than the
   procedures described in Section 5.

手順はセクション4原因で再開ルータの隣人で状態を進めるMPLSへの変化よりセクション5で説明された手順について説明しました。

   In principle, it is possible for an LSR to use procedures described
   in Section 4 for some AFI/SAFI(s) and procedures described in Section
   5 for other AFI/SAFI(s).

原則として、LSRがセクション4でいくらかのAFI/サフィに説明された手順とセクション5で他のAFI/サフィに説明された手順を用いるのは、可能です。

Rekhter & Aggarwal          Standards Track                     [Page 7]

RFC 4781           Graceful Restart Mechanism for BGP       January 2007

Rekhter&Aggarwal規格は2007年1月にBGPのためにRFC4781の優雅な再開メカニズムを追跡します[7ページ]。

8.  Security Considerations

8. セキュリティ問題

   The security considerations pertaining to the BGP protocol [RFC4271]
   remain relevant.

BGPプロトコル[RFC4271]に関係するセキュリティ問題は関連していたままで残っています。

   In addition, the mechanism described here renders LSRs that implement
   it vulnerable to additional denial-of-service attacks as follows:

さらに、ここで説明されたメカニズムは以下の追加サービス不能攻撃に傷つきやすい状態でそれを実行するLSRsをレンダリングします:

      An intruder may impersonate a BGP peer in order to force a failure
      and reconnection of the TCP connection, where the intruder sets
      the Forwarding State (F) bit (as defined in [RFC4724]) to 0 on
      reconnection.  This forces all labels received from the peer to be
      released.

侵入者はTCP接続の失敗と再接続を強制するためにBGP同輩をまねるかもしれません、侵入者が再接続のときにForwarding州(F)ビット([RFC4724]で定義されるように)を0に設定するところで。 これによって、同輩から受け取られたすべてのラベルがやむを得ず放出されます。

      An intruder could intercept the traffic between BGP peers and
      override the setting of the Forwarding State (F) bit to be set to
      0.  This forces all labels received from the peer to be released.

侵入者は、0に設定されるためにBGP同輩の間の交通を妨害して、Forwarding州(F)ビットの設定をくつがえすことができました。 これによって、同輩から受け取られたすべてのラベルがやむを得ず放出されます。

   All of these attacks may be countered by use of an authentication
   scheme between BGP peers, such as the scheme outlined in [RFC2385].

これらの攻撃のすべてがBGP同輩の間の認証計画の使用で打ち返されるかもしれません、[RFC2385]に概説された計画などのように。

   As with BGP carrying labels, a security issue may exist if a BGP
   implementation continues to use labels after expiration of the BGP
   session that first caused them to be used.  This may arise if the
   upstream LSR detects the session failure after the downstream LSR has
   released and re-used the label.  The problem is most obvious with the
   platform-wide label space and could result in misrouting of data to
   destinations other than those intended; and it is conceivable that
   these behaviors may be deliberately exploited, either to obtain
   services without authorization or to deny services to others.

BGPがラベルを運んでいる場合、BGP実現が、最初にそれらを使用したBGPセッションの満了の後にラベルを使用し続けているなら、安全保障問題は存在するかもしれません。 ラベルを放出して、再使用した後に上流のLSRがセッション失敗を検出するなら、これは起こるかもしれません。 問題は、プラットホーム全体のラベルスペースで最も明白であり、意図するものを除いて、目的地へのデータのmisroutingをもたらすかもしれません。 そして、これらの振舞いが認可なしでサービスを得るか、または他のものに対するサービスを否定するのに故意に利用されるのが想像できます。

   In this document, the validity of the BGP session may be extended by
   the Restart Time, and the session may be re-established in this
   period.  After the expiry of the Restart Time, the session must be
   considered to have failed, and the same security issue applies as
   described above.

本書では、BGPセッションの正当性はRestart Timeによって広げられるかもしれません、そして、セッションはこの時代に復職するかもしれません。 Restart Timeの満期の後に、失敗したとセッションを考えなければなりません、そして、同じ安全保障問題は上で説明されるように申し込まれます。

   However, the downstream LSR may declare the session as failed before
   the expiration of its Restart Time.  This increases the period during
   which the downstream LSR might reallocate the label while the
   upstream LSR continues to transmit data using the old usage of the
   label.  To reduce this issue, this document requires that labels are
   not re-used until at least the Restart Time.

しかしながら、川下のLSRはRestart Timeの満了の前に失敗されているとしてセッションを宣言するかもしれません。 これは上流のLSRが、ラベルの古い慣習を使用することでデータを送り続けている間の川下のLSRがラベルを再割当てするかもしれない期間、増加します。 この問題を減少させるために、このドキュメントは、ラベルが少なくともRestart Timeまで再使用されないのを必要とします。

Rekhter & Aggarwal          Standards Track                     [Page 8]

RFC 4781           Graceful Restart Mechanism for BGP       January 2007

Rekhter&Aggarwal規格は2007年1月にBGPのためにRFC4781の優雅な再開メカニズムを追跡します[8ページ]。

9.  Acknowledgments

9. 承認

   We would like to thank Chaitanya Kodeboyina and Loa Andersson for
   their review and comments.  The approach described in Section 5 is
   based on the idea suggested by Manoj Leelanivas.

彼らのレビューとコメントについてChaitanya KodeboyinaとLoaアンデションに感謝申し上げます。 セクション5で説明されたアプローチはManoj Leelanivasによって勧められた考えに基づいています。

10.  References

10. 参照

10.1.  Normative References

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

   [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
             Signature Option", RFC 2385, August 1998.

[RFC2385] ヘファーナン、A.、「TCP MD5 Signature Optionを通したBGPセッションズの保護」、RFC2385、1998年8月。

   [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
             Protocol 4 (BGP-4)", RFC 4271, January 2006.

[RFC4271]Rekhter、Y.、李、T.、およびS.野兎、「ボーダ・ゲイトウェイ・プロトコル4(BGP-4)」、RFC4271 2006年1月。

   [RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y.
             Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724,
             January 2007.

[RFC4724]サーングリとS.とチェンとE.とフェルナンドとR.とScudder、J.とY.Rekhter、「BGPのための優雅な再開メカニズム」RFC4724(2007年1月)。

10.2.  Informative References

10.2. 有益な参照

   [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in
             BGP-4", RFC 3107, May 2001.

「BGP-4インチ、RFC3107、2001年5月にラベル情報を運ぶ」[RFC3107]Rekhter、Y.、およびE.ローゼン。

Authors' Addresses

作者のアドレス

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

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

   EMail: yakov@juniper.net

メール: yakov@juniper.net

   Rahul Aggarwal
   Juniper Networks
   1194 N.Mathilda Ave
   Sunnyvale, CA 94089

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

   EMail: rahul@juniper.net

メール: rahul@juniper.net

Rekhter & Aggarwal          Standards Track                     [Page 9]

RFC 4781           Graceful Restart Mechanism for BGP       January 2007

Rekhter&Aggarwal規格は2007年1月にBGPのためにRFC4781の優雅な再開メカニズムを追跡します[9ページ]。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The IETF Trust (2007).

IETFが信じる著作権(C)(2007)。

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

Acknowledgement

承認

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

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

Rekhter & Aggarwal          Standards Track                    [Page 10]

Rekhter&Aggarwal標準化過程[10ページ]