RFC3478 日本語訳

Network Working Group                                      M. Leelanivas
Request for Comments: 3478                                    Y. Rekhter
Category: Standards Track                               Juniper Networks
                                                             R. Aggarwal
                                                        Redback Networks
                                                           February 2003

Leelanivasがコメントのために要求するワーキンググループM.をネットワークでつないでください: 3478年のY.Rekhterカテゴリ: 標準化過程杜松は2003年2月にR.Aggarwal20ドル紙幣ネットワークをネットワークでつなぎます。

       Graceful Restart Mechanism for Label Distribution Protocol

ラベル分配プロトコルのための優雅な再開メカニズム

Status of this Memo

この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 (2003).  All Rights Reserved.

Copyright(C)インターネット協会(2003)。 All rights reserved。

Abstract

要約

   This document describes a mechanism that helps to minimize the
   negative effects on MPLS traffic caused by Label Switching Router's
   (LSR's) control plane restart, specifically by the restart of its
   Label Distribution Protocol (LDP) component, on LSRs that are capable
   of preserving the MPLS forwarding component across the restart.

このドキュメントはLabel Switching Routerの(LSR)のコントロール飛行機再開で引き起こされたMPLS交通へのマイナスの効果を最小にするのを助けるメカニズムについて説明します、特にLabel Distributionプロトコル(自由民主党)コンポーネントの再開で、再開の向こう側にMPLS推進の部品を保存できるLSRsで。

   The mechanism described in this document is applicable to all LSRs,
   both those with the ability to preserve forwarding state during LDP
   restart and those without (although the latter needs to implement
   only a subset of the mechanism described in this document).
   Supporting (a subset of) the mechanism described here by the LSRs
   that can not preserve their MPLS forwarding state across the restart
   would not reduce the negative impact on MPLS traffic caused by their
   control plane restart, but it would minimize the impact if their
   neighbor(s) are capable of preserving the forwarding state across the
   restart of their control plane and implement the mechanism described
   here.

本書では説明されたメカニズムはすべてのLSRs(能力(後者は、本書では説明されたメカニズムの部分集合だけを実行する必要がありますが)がある自由民主党の再開とそれらの間の推進状態を保持する両方のそれら)に適切です。 支持、(部分集合、)、ここで再開の向こう側に彼らのMPLS推進状態を保持できないLSRsによって説明されたメカニズムが彼らのコントロール飛行機再開で引き起こされたMPLS交通への負の衝撃を減少させないでしょうが、それは、彼らの隣人ができるなら彼らの制御飛行機の再開の向こう側に推進状態を保持するのについて衝撃を最小にして、ここで説明されたメカニズムを実行するでしょう。

   The mechanism makes minimalistic assumptions on what has to be
   preserved across restart - the mechanism assumes that only the actual
   MPLS forwarding state has to be preserved; the mechanism does not
   require any of the LDP-related states to be preserved across the
   restart.

メカニズムは再開の向こう側に保存されなければならないことに関するminimalistic仮定をします--メカニズムは、実際のMPLS推進状態だけが保持されなければならないと仮定します。 メカニズムは、自由民主党関連の州のどれかが再開の向こう側に保存されるのを必要としません。

Leelanivas, et al.          Standards Track                     [Page 1]

RFC 3478           Graceful Restart Mechanism for LDP      February 2003

Leelanivas、他 規格は2003年2月に自由民主党のためにRFC3478の優雅な再開メカニズムを追跡します[1ページ]。

   The procedures described in this document apply to downstream
   unsolicited label distribution.  Extending these procedures to
   downstream on demand label distribution is for further study.

本書では説明された手順は川下の求められていないラベル分配に適用されます。 さらなる研究には川下のオンデマンドのラベル分配にこれらの手順を広げるのがあります。

Specification of Requirements

要件の仕様

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

1. Motivation

1. 動機

   For the sake of brevity in the context of this document, by "the
   control plane" we mean "the LDP component of the control plane".

簡潔にするためにこのドキュメントの文脈では、「制御飛行機」で、私たちは「制御飛行機の自由民主党の部品」を言っています。

   For the sake of brevity in the context of this document, by "MPLS
   forwarding state" we mean either <incoming label -> (outgoing label,
   next hop)> (non-ingress case), or <FEC->(outgoing label, next hop)>
   (ingress case) mapping.

簡潔にするためにこのドキュメントの文脈では、「MPLS推進状態」で、私たちは<入って来るラベル->(出発しているラベル、次のホップ)>(非イングレスケース)か<FEC->(出発しているラベル、次のホップ)>(イングレスケース)マッピングのどちらかを言っています。

   In the case where a Label Switching Router (LSR) could preserve its
   MPLS forwarding state across restart of its control plane,
   specifically its LDP component [LDP], it is desirable not to perturb
   the LSPs going through that LSR (specifically, the LSPs established
   by LDP).  In this document, we describe a mechanism, termed "LDP
   Graceful Restart", that allows the accomplishment of this goal.

Label Switching Router(LSR)がMPLSを保存できた制御飛行機、明確に自由民主党コンポーネント[自由民主党]の再開の向こう側に状態を進める場合では、そのLSR(明確に自由民主党によって設立されたLSPs)を通るLSPsを混乱させないのは望ましいです。 本書では、私たちはこの目標の達成を許す「自由民主党の優雅な再開」と呼ばれたメカニズムについて説明します。

   The mechanism described in this document is applicable to all LSRs,
   both those with the ability to preserve forwarding state during LDP
   restart and those without (although the latter need to implement only
   a subset of the mechanism described in this document).  Supporting (a
   subset of) the mechanism described here by the LSRs that can not
   preserve their MPLS forwarding state across the restart would not
   reduce the negative impact on MPLS traffic caused by their control
   plane restart, but it would minimize the impact if their neighbor(s)
   are capable of preserving the forwarding state across the restart of
   their control plane and implement the mechanism described here.

本書では説明されたメカニズムはすべてのLSRs(能力(後者は、本書では説明されたメカニズムの部分集合だけを実行する必要がありますが)がある自由民主党の再開とそれらの間の推進状態を保持する両方のそれら)に適切です。 支持、(部分集合、)、ここで再開の向こう側に彼らのMPLS推進状態を保持できないLSRsによって説明されたメカニズムが彼らのコントロール飛行機再開で引き起こされたMPLS交通への負の衝撃を減少させないでしょうが、それは、彼らの隣人ができるなら彼らの制御飛行機の再開の向こう側に推進状態を保持するのについて衝撃を最小にして、ここで説明されたメカニズムを実行するでしょう。

   The mechanism makes minimalistic assumptions on what has to be
   preserved across restart - the mechanism assumes that only the actual
   MPLS forwarding state has to be preserved.  Clearly this is the
   minimum amount of state that has to be preserved across the restart
   in order not to perturb the LSPs traversing a restarting LSR.  The
   mechanism does not require any of the LDP-related states to be
   preserved across the restart.

メカニズムは再開の向こう側に保存されなければならないことに関するminimalistic仮定をします--メカニズムは、実際のMPLS推進状態だけが保持されなければならないと仮定します。 明確に、これは再開LSRを横断するLSPsを混乱させない命令における再開の向こう側に保持されなければならない最小の量の状態です。 メカニズムは、自由民主党関連の州のどれかが再開の向こう側に保存されるのを必要としません。

Leelanivas, et al.          Standards Track                     [Page 2]

RFC 3478           Graceful Restart Mechanism for LDP      February 2003

Leelanivas、他 規格は2003年2月に自由民主党のためにRFC3478の優雅な再開メカニズムを追跡します[2ページ]。

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

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

   The procedures described in this document apply to downstream
   unsolicited label distribution.  Extending these procedures to
   downstream on demand label distribution is for further study.

本書では説明された手順は川下の求められていないラベル分配に適用されます。 さらなる研究には川下のオンデマンドのラベル分配にこれらの手順を広げるのがあります。

2. LDP Extension

2. 自由民主党の拡大

   An LSR indicates that it is capable of supporting LDP Graceful
   Restart, as defined in this document, by including the Fault Tolerant
   (FT) Session TLV as an Optional Parameter in the LDP Initialization
   message.  The format of the FT Session TLV is defined in [FT-LDP].
   The L (Learn from Network) flag MUST be set to 1, which indicates
   that the procedures in this document are used.  The rest of the FT
   flags are set to 0 by a sender and ignored on receipt.

LSRは、自由民主党Graceful Restartを支持できるのを示します、本書では定義されるように、Optional Parameterとして自由民主党初期設定メッセージにFault Tolerant(FT)セッションTLVを含んでいることによって。 FT Session TLVの書式は[FT-自由民主党]で定義されます。 L(Networkから、学ぶ)旗を1に設定しなければなりません。(それは、手順が本書では使用されているのを示します)。 FT旗の残りは、送付者によって0に設定されて、領収書の上で無視されます。

   The value field of the FT Session TLV contains two components that
   are used by the mechanisms defined in this document: FT Reconnect
   Timeout, and Recovery Time.

FT Session TLVの値の分野は本書では定義されたメカニズムによって使用される2つのコンポーネントを含んでいます: フィートはタイムアウト、および回復時間を再接続します。

   The FT Reconnect Timeout is the time (in milliseconds) that the
   sender of the TLV would like the receiver of that TLV to wait after
   the receiver detects the failure of LDP communication with the
   sender.  While waiting, the receiver SHOULD retain the MPLS
   forwarding state for the (already established) LSPs that traverse a
   link between the sender and the receiver.  The FT Reconnect Timeout
   should be long enough to allow the restart of the control plane of
   the sender of the TLV, and specifically its LDP component to bring it
   to the state where the sender could exchange LDP messages with its
   neighbors.

FT Reconnect Timeoutは受信機が送付者との自由民主党コミュニケーションの失敗を検出した後にTLVの送付者がそのTLVの受信機を待ちたがっている時間(ミリセカンドによる)です。 待っている間、受信機SHOULDは送付者と受信機とのリンクを横断する(既に確立する)のLSPsのために状態を進めるMPLSを保有します。FT Reconnect TimeoutはTLVの送付者の制御飛行機の再開、および明確にその自由民主党コンポーネントが送付者が自由民主党メッセージを隣人と交換できた状態にそれをもたらすのを許容できるくらい長いはずです。

   Setting the FT Reconnect Timeout to 0 indicates that the sender of
   the TLV will not preserve its forwarding state across the restart,
   yet the sender supports the procedures, defined in Section 3.3,
   "Restart of LDP communication with a neighbor LSR" of this document,
   and therefore could take advantage if its neighbor to preserve its
   forwarding state across the restart.

0にFT Reconnect Timeoutを設定するのが、TLVの送付者が再開の向こう側に推進状態を保持しないのを示して、しかし、送付者は、このドキュメントについてセクション3.3、「隣人LSRとの自由民主党コミュニケーションの再開」で定義された手順をサポートして、したがって、推進を保存する隣人が横切って再開を述べるなら、利点を活用するかもしれません。

   For a restarting LSR, the Recovery Time carries the time (in
   milliseconds) the LSR is willing to retain its MPLS forwarding state
   that it preserved across the restart.  The time is from the moment
   the LSR sends the Initialization message that carries the FT Session

再開LSRに関しては、Recovery TimeはLSRが、それが再開の向こう側に保持したMPLS推進状態を保有しても構わないと思う時代(ミリセカンドによる)に運びます。 時間がLSRがFT Sessionを運ぶ初期設定メッセージを送る瞬間からあります。

Leelanivas, et al.          Standards Track                     [Page 3]

RFC 3478           Graceful Restart Mechanism for LDP      February 2003

Leelanivas、他 規格は2003年2月に自由民主党のためにRFC3478の優雅な再開メカニズムを追跡します[3ページ]。

   TLV after restart.  Setting this time to 0 indicates that the MPLS
   forwarding state was not preserved across the restart (or even if it
   was preserved, is no longer available).

再開の後のTLV。 今回0にセットするのは、MPLS推進状態が再開の向こう側に保持されなかったのを示します(それが保存され、もう利用可能でなくても)。

   The Recovery Time SHOULD be long enough to allow the neighboring
   LSR's to re-sync all the LSP's in a graceful manner, without creating
   congestion in the LDP control plane.

Recovery Time SHOULD、隣接しているLSRのものがLSPのすべてのものを優しい物腰で再同期させるのを許容できるくらい長くいてください、自由民主党制御飛行機で混雑を作成しないで。

3. Operations

3. 操作

   An LSR that supports functionality described in this document
   advertises this to its LDP neighbors by carrying the FT Session TLV
   in the LDP Initialization message.

本書では説明された機能性を支持するLSRは、自由民主党初期設定メッセージでFT Session TLVを運ぶことによって、自由民主党の隣人にこれの広告を出します。

   This document assumes that in certain situations, as specified in
   section 3.1.2, "Egress LSR", in addition to the MPLS forwarding
   state, an LSR can also preserve its IP forwarding state across the
   restart.  Procedures for preserving an IP forwarding state across the
   restart are defined in [OSPF-RESTART], [ISIS-RESTART], and [BGP-
   RESTART].

このドキュメントは、また、ある状況セクション3.1.2、「出口LSR」で指定されることMPLS推進状態に加えてLSRが再開の向こう側にIP推進状態を保持できると仮定します。 再開の向こう側にIP推進状態を保持するための手順は[OSPF-RESTART]、[イシス-RESTART]、および[BGP- RESTART]で定義されます。

3.1. Procedures for the restarting LSR

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

   After an LSR restarts its control plane, the LSR MUST check whether
   it was able to preserve its MPLS forwarding state from prior to the
   restart.  If not, then the LSR sets the Recovery Time to 0 in the FT
   Session TLV the LSR sends to its neighbors.

LSRが制御飛行機を再開した後に、LSR MUSTは、再開の前にそれがそうであったかどうかMPLS推進状態を保持できてチェックします。 そうでなければ、そして、LSRはLSRが隣人に送るFT Session TLVに0へのRecovery Timeをはめ込みます。

   If the forwarding state has been preserved, then the LSR starts its
   internal timer, called MPLS Forwarding State Holding timer (the value
   of that timer SHOULD be configurable), and marks all the MPLS
   forwarding state entries as "stale".  At the expiration of the timer,
   all the entries still marked as stale SHOULD be deleted.  The value
   of the Recovery Time advertised in the FT Session TLV is set to the
   (current) value of the timer at the point in which the Initialization
   message carrying the FT Session TLV is sent.

推進状態が保持されたなら、LSRは内部のタイマを始動します、呼ばれたMPLS Forwarding州Holdingタイマ、(値、タイマSHOULDは構成可能です)、すべてのMPLS推進州のエントリーが「聞き古したである」マークします。 タイマの満了、聞き古したSHOULDとしてまだ示されているすべてのエントリーでは、削除されてください。 FT Session TLVの広告に掲載されたRecovery Timeの値はFT Session TLVを運ぶ初期設定メッセージが送られるポイントのタイマの(現在)の値に設定されます。

   We say that an LSR is in the process of restarting when the MPLS
   Forwarding State Holding timer is not expired.  Once the timer
   expires, we say that the LSR completed its restart.

私たちは、MPLS Forwarding州Holdingタイマが満期でないとき再開することの途中にLSRがあると言います。 タイマがいったん期限が切れると、私たちは、LSRが再開を終了したと言います。

   The following procedures apply when an LSR is in the process of
   restarting.

LSRが再開の途中にあるとき、以下の手順は適用されます。

3.1.1. Non-egress LSR

3.1.1. 非出口LSR

   If the label carried in the newly received Mapping message is not an
   Implicit NULL, the LSR searches its MPLS forwarding state for an

新たに受け取られたMappingメッセージで運ばれたラベルがImplicit NULLでないなら、LSRは、状態を進めながら、MPLSを捜します。

Leelanivas, et al.          Standards Track                     [Page 4]

RFC 3478           Graceful Restart Mechanism for LDP      February 2003

Leelanivas、他 規格は2003年2月に自由民主党のためにRFC3478の優雅な再開メカニズムを追跡します[4ページ]。

   entry with the outgoing label equal to the label carried in the
   message, and the next hop equal to one of the addresses (next hops)
   received in the Address message from the peer.  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 <FEC, (outgoing label, next hop)>), the LSR associates
   the incoming label from that entry with the FEC received in the Label
   Mapping message, and advertises (via LDP) <incoming label, FEC> to
   its neighbors.  If the found entry has no incoming label, or if no
   entry is found, the LSR follows the normal LDP procedures.  (Note
   that this paragraph describes the scenario where the restarting LSR
   is neither the egress, nor the penultimate hop that uses penultimate
   hop popping for a particular LSP.  Note also that this paragraph
   covers the case where the restarting LSR is the ingress.)

ラベルと等しい出発しているラベルによるエントリーはメッセージで運ばれました、そして、アドレス(次のホップ)の1つへの次のホップ同輩は同輩からのAddressメッセージで受信しました。 そのようなエントリーが見つけられるなら、LSRは、もうエントリーが聞き古したであるマークしません。 さらに、LSRはエントリーがタイプ<入って来るラベル、(出発しているラベル、次のホップ)>(<FEC、(出発しているラベル、次のホップ)>よりむしろ)のものであるなら、入って来るラベルをそのエントリーからLabel Mappingメッセージに受け取るFECに関連づけて、<の入って来るラベル(隣人へのFEC>)の広告を出します(自由民主党を通して)。 備え付けることのエントリーではどんな入って来るラベルもないか、またはエントリーが全く当たられないなら、LSRが正常な自由民主党手順に従います。 (このパラグラフが再開しているLSRが出口も特定のLSPのために飛び出す終わりから二番目のホップを使用しない終わりから二番目のホップであるのもシナリオについて説明することに注意してください。 また、このパラグラフが再開しているLSRがイングレスであるケースをカバーすることに注意してください。)

   If the label carried in the Mapping message is an Implicit NULL
   label, the LSR searches its MPLS forwarding state for an entry that
   indicates Label pop (means no outgoing label), and the next hop equal
   to one of the addresses (next hops) received in the Address message
   from the peer.  If such an entry is found, the LSR no longer marks
   the entry as stale, the LSR associates the incoming label from that
   entry with the FEC received in the Label Mapping message from the
   neighbor, and advertises (via LDP) <incoming label, FEC> to its
   neighbors.  If the found entry has no incoming label, or if no entry
   is found, the LSR follows the normal LDP procedures.  (Note that this
   paragraph describes the scenario where the restarting LSR is a
   penultimate hop for a particular LSP, and this LSP uses penultimate
   hop popping.)

Mappingメッセージで運ばれたラベルがImplicit NULLラベルであるなら、LSRはLabelが飛び出すのを(どんな出発しているラベルも意味しません)示すエントリーに状態を送りながら、MPLSを捜します、そして、アドレス(次のホップ)の1つへの次のホップ同輩は同輩からのAddressメッセージで受信しました。 そのようなエントリーが見つけられるなら、LSRが、もうエントリーが聞き古したであるマークしないで、LSRは入って来るラベルをそのエントリーからLabel Mappingメッセージに隣人から受け取るFECに関連づけて、<の入って来るラベル(隣人へのFEC>)の広告を出します(自由民主党を通して)。 備え付けることのエントリーではどんな入って来るラベルもないか、またはエントリーが全く当たられないなら、LSRが正常な自由民主党手順に従います。 (このパラグラフが特定のLSPのために、再開しているLSRが終わりから二番目のホップであるシナリオについて説明することに注意してください。そうすれば、このLSPは終わりから二番目のホップの飛び出しを使用します。)

   The description in the above paragraph assumes that the restarting
   LSR generates the same label for all the LSPs that terminate on the
   same LSR (different from the restarting LSR), and for which the
   restarting LSR is a penultimate hop.  If this is not the case, and
   the restarting LSR generates a unique label per each such LSP, then
   the LSR needs to preserve across the restart, not just the <incoming
   label, (outgoing label, next hop)> mapping, but also the FEC
   associated with this mapping.  In such case, the LSR searches its
   MPLS forwarding state for an entry that (a) indicates Label pop
   (means no outgoing label), (b) indicates the next hop equal to one of
   the addresses (next hops) received in the Address message from the
   peer, and (c) has the same FEC as the one received in the Label
   Mapping message.  If such an entry is found, the LSR no longer marks
   the entry as stale, the LSR associates the incoming label from that
   entry with the FEC received in the Label Mapping message from the
   neighbor, and advertises (via LDP) <incoming label, FEC> to its
   neighbors.  If the found entry has no incoming label, or if no entry
   is found, the LSR follows the normal LDP procedures.

記述は、再開しているLSRが同じLSR(再開しているLSRと異なった)で終わって、再開しているLSRが終わりから二番目のホップであるすべてのLSPsのために同じラベルを発生させると前の段落で仮定します。 これがそうでなく、再開しているLSRがそのような各LSPあたり1個のユニークなラベルを発生させるなら、LSRは、まさしく<の入って来るラベル、(出発しているラベル、次のホップ)ではなく再開の向こう側に>マッピングを保存する必要がありますが、FECはこのマッピングと交際もしましたも。 そのような場合では、LSRは(a)が、Labelが飛び出すのを(どんな出発しているラベルも意味しません)示すエントリーに状態を送りながら、MPLSを捜します、そして、(b)はAddressメッセージに同輩から受け取られたアドレス(次のホップ)の1つに次のホップ同輩を示します、そして、(c)には、Label Mappingメッセージに受け取られたものと同じFECがあります。 そのようなエントリーが見つけられるなら、LSRが、もうエントリーが聞き古したであるマークしないで、LSRは入って来るラベルをそのエントリーからLabel Mappingメッセージに隣人から受け取るFECに関連づけて、<の入って来るラベル(隣人へのFEC>)の広告を出します(自由民主党を通して)。 備え付けることのエントリーではどんな入って来るラベルもないか、またはエントリーが全く当たられないなら、LSRが正常な自由民主党手順に従います。

Leelanivas, et al.          Standards Track                     [Page 5]

RFC 3478           Graceful Restart Mechanism for LDP      February 2003

Leelanivas、他 規格は2003年2月に自由民主党のためにRFC3478の優雅な再開メカニズムを追跡します[5ページ]。

3.1.2. Egress LSR

3.1.2. 出口LSR

   If an LSR determines that it is an egress for a particular FEC, the
   LSR is configured to generate a non-NULL label for that FEC, and that
   the LSR is configured to generate the same (non-NULL) label for all
   the FECs that share the same next hop and for which the LSR is an
   egress, the LSR searches its MPLS forwarding state for an entry that
   indicates Label pop (means no outgoing label), and the next hop equal
   to the next hop for that FEC.  (Determining the next hop for the FEC
   depends on the type of the FEC.  For example, when the FEC is an IP
   address prefix, the next hop for that FEC is determined from the IP
   forwarding table.)  If such an entry is found, the LSR no longer
   marks this entry as stale, the LSR associates the incoming label from
   that entry with the FEC, and advertises (via LDP) <incoming label,
   FEC> to its neighbors.  If the found entry has no incoming label, or
   if no entry is found, the LSR follows the normal LDP procedures.

LSRが、特定のFECに関して、LSRがそのFECのために非NULLラベルを発生させるように構成されて、LSRが同じくらい(非NULL)を発生させるように構成されるのが、出口であることを決定するなら、すべてには、次のホップ、出口、LSRがLSRがどれであるかためにLabelが飛び出すのを(どんな出発しているラベルも意味しません)示すエントリーに状態を送りながらMPLSを捜すか、そして、およびそのFECのための次のホップへの次のホップ同輩と同じように共有するFECsをラベルしてください。 (FECのために次のホップを決定するのはFECのタイプにかかっています。 FECがIPアドレス接頭語であるときに、例えば、そのFECのための次のホップはIP推進テーブルから断固としています。) そのようなエントリーが見つけられるなら、LSRが、もうこのエントリーが聞き古したであるマークしないで、LSRは入って来るラベルをそのエントリーからFECに関連づけて、<の入って来るラベル(隣人へのFEC>)の広告を出します(自由民主党を通して)。 備え付けることのエントリーではどんな入って来るラベルもないか、またはエントリーが全く当たられないなら、LSRが正常な自由民主党手順に従います。

   If an LSR determines that it is an egress for a particular FEC, the
   LSR is configured to generate a non-NULL label for that FEC, and that
   the LSR is configured to generate a unique label for each such FEC,
   then the LSR needs to preserve across the restart, not just the
   <incoming label, (outgoing label, next hop)> mapping, but also the
   FEC associated with this mapping.  In such case, the LSR would search
   its MPLS forwarding state for an entry that indicates Label pop
   (means no outgoing label), and the next hop equal to the next hop for
   that FEC associated with the entry (Determining the next hop for the
   FEC depends on the type of the FEC.  For example, when the FEC is an
   IP address prefix, the next hop for that FEC is determined from the
   IP forwarding table.)  If such an entry is found, the LSR no longer
   marks this entry as stale, the LSR associates the incoming label from
   that entry with the FEC, and advertises (via LDP) <incoming label,
   FEC> to its neighbors.  If the found entry has no incoming label, or
   if no entry is found, the LSR follows the normal LDP procedures.

LSRが、特定のFECに関して、LSRがそのFECのために非NULLラベルを発生させるように構成されて、LSRがそのような各FECのためにユニークなラベルを発生させるように構成されるのが、出口であることを決定するなら、LSRは、まさしく<の入って来るラベル、(出発しているラベル、次のホップ)ではなく再開の向こう側に>マッピングを保存する必要がありますが、FECはこのマッピングと交際もしましたも。 そのような場合では、LSRは、Labelが飛び出すのを(どんな出発しているラベルも意味しません)示すエントリー、および次のホップ同輩のためにエントリーに関連しているそのFECのための次のホップに状態を送りながら、MPLSを捜すでしょう。(FECのために次のホップを決定するのはFECのタイプにかかっています。 FECがIPアドレス接頭語であるときに、例えば、そのFECのための次のホップはIP推進テーブルから断固としています。) そのようなエントリーが見つけられるなら、LSRが、もうこのエントリーが聞き古したであるマークしないで、LSRは入って来るラベルをそのエントリーからFECに関連づけて、<の入って来るラベル(隣人へのFEC>)の広告を出します(自由民主党を通して)。 備え付けることのエントリーではどんな入って来るラベルもないか、またはエントリーが全く当たられないなら、LSRが正常な自由民主党手順に従います。

   If an LSR determines that it is an egress for a particular FEC, and
   the LSR is configured to generate a NULL (either Explicit or
   Implicit) label for that FEC, the LSR just advertises (via LDP) such
   label (together with the FEC) to its neighbors.

LSRが、それが特定のFECのための出口であることを決定して、LSRがそのFECのためにNULL(ExplicitかImplicitのどちらか)ラベルを発生させるように構成されるなら、LSRはただ、そのようなラベル(FECに伴う)の隣人に広告を出します(自由民主党を通して)。

3.2. Alternative procedures for the restarting LSR

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

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

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

   The procedures described in this section assumes that the restarting
   LSR has (at least) as many unallocated as allocated labels.  The
   latter form the MPLS forwarding state that the LSR managed to
   preserve across the restart.

このセクションで説明された手順は、再開しているLSRがラベルを割り当てるので(少なくとも)同じくらい多くを「非-割り当て」させると仮定します。 後者はLSRが再開の向こう側に何とか保持したMPLS推進状態を形成します。

Leelanivas, et al.          Standards Track                     [Page 6]

RFC 3478           Graceful Restart Mechanism for LDP      February 2003

Leelanivas、他 規格は2003年2月に自由民主党のためにRFC3478の優雅な再開メカニズムを追跡します[6ページ]。

   After an LSR restarts its control plane, the LSR MUST check whether
   it was able to preserve its MPLS forwarding state from prior to the
   restart.  If no, then the LSR sets the Recovery Time to 0 in the FT
   Session TLV the LSR sends to its neighbors.

LSRが制御飛行機を再開した後に、LSR MUSTは、再開の前にそれがそうであったかどうかMPLS推進状態を保持できてチェックします。 いいえなら、LSRはLSRが隣人に送るFT Session TLVに0へのRecovery Timeをはめ込みます。

   If the forwarding state has been preserved, then the LSR starts its
   internal timer, called MPLS Forwarding State Holding timer (the value
   of that timer SHOULD be configurable), and marks all the MPLS
   forwarding state entries as "stale".  At the expiration of the timer,
   all the entries still marked as stale SHOULD be deleted.  The value
   of the Recovery Time advertised in the FT Session TLV is set to the
   (current) value of the timer at the point when the Initialization
   message carrying the FT Session TLV is sent.

推進状態が保持されたなら、LSRは内部のタイマを始動します、呼ばれたMPLS Forwarding州Holdingタイマ、(値、タイマSHOULDは構成可能です)、すべてのMPLS推進州のエントリーが「聞き古したである」マークします。 タイマの満了、聞き古したSHOULDとしてまだ示されているすべてのエントリーでは、削除されてください。 FT Session TLVを運ぶ初期設定メッセージを送るとき、ポイントのタイマの(現在)の値にFT Session TLVの広告に掲載されたRecovery Timeの値を設定します。

   We say that an LSR is in the process of restarting when the MPLS
   Forwarding State Holding timer is not expired.  Once the timer
   expires, we say that the LSR completed its restart.

私たちは、MPLS Forwarding州Holdingタイマが満期でないとき再開することの途中にLSRがあると言います。 タイマがいったん期限が切れると、私たちは、LSRが再開を終了したと言います。

   While an LSR is in the process of restarting, the LSR creates local
   label binding by following the normal LDP procedures.

LSRが再開の途中にありますが、LSRは、正常な自由民主党手順に従うことで地方のラベル結合を作成します。

   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 FEC - 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.  Both of these bindings though would have the same
   outgoing label (and the same next hop).

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

3.3. Restart of LDP communication with a neighbor LSR

3.3. 隣人LSRとの自由民主党コミュニケーションの再開

   When an LSR detects that its LDP session with a neighbor went down,
   and the LSR knows that the neighbor is capable of preserving its MPLS
   forwarding state across the restart (as was indicated by the FT
   Session TLV in the Initialization message received from the
   neighbor), the LSR retains the label-FEC bindings received via that
   session (rather than discarding the bindings), but marks them as
   "stale".

LSRがそれを検出するとき、隣人との自由民主党のセッションが落ちて、LSRが、隣人が再開の向こう側にMPLS推進状態を保持できるのを知っていて(隣人から受け取られた初期設定メッセージでFT Session TLVによって示されたように)、LSRは、そのセッション(結合を捨てるよりむしろ)で受けられたラベル-FEC結合を保有しますが、それらが「聞き古したである」マークします。

   After detecting that the LDP session with the neighbor went down, the
   LSR tries to re-establish LDP communication with the neighbor
   following the usual LDP procedures.

隣人との自由民主党のセッションが下った検出の後に、LSRは普通の自由民主党手順に従う隣人との自由民主党コミュニケーションを復職させようとします。

   The amount of time the LSR keeps its stale label-FEC bindings is set
   to the lesser of the FT Reconnect Timeout, as was advertised by the
   neighbor, and a local timer, called the Neighbor Liveness Timer.  If
   within that time the LSR still does not establish an LDP session with
   the neighbor, all the stale bindings SHOULD be deleted.  The Neighbor

Neighbor Liveness Timerは、LSRが聞き古したラベル-FEC結合を保つ時間はFT Reconnect Timeoutについて、より少なく決められます、隣人、および地方のタイマによって広告に掲載されたように呼びました。 その時中にLSRはまだ隣人との自由民主党のセッションを確立していません、すべての聞き古した結合SHOULD。削除されます。 隣人

Leelanivas, et al.          Standards Track                     [Page 7]

RFC 3478           Graceful Restart Mechanism for LDP      February 2003

Leelanivas、他 規格は2003年2月に自由民主党のためにRFC3478の優雅な再開メカニズムを追跡します[7ページ]。

   Liveness Timer is started when the LSR detects that its LDP session
   with the neighbor went down.  The value of the Neighbor Liveness
   timer SHOULD be configurable.

活性TimerはLSRがそれを検出すると始められて、隣人との自由民主党のセッションが落ちたということです。 値、Neighbor LivenessタイマSHOULDでは、構成可能であってください。

   If the LSR re-establishes an LDP session with the neighbor within the
   lesser of the FT Reconnect Timeout and the Neighbor Liveness Timer,
   and the LSR determines that the neighbor was not able to preserve its
   MPLS forwarding state, the LSR SHOULD immediately delete all the
   stale label-FEC bindings received from that neighbor.  If the LSR
   determines that the neighbor was able to preserve its MPLS forwarding
   state (as was indicated by the non-zero Recovery Time advertised by
   the neighbor), the LSR SHOULD further keep the stale label-FEC
   bindings, received from the neighbor, for as long as the lesser of
   the Recovery Time advertised by the neighbor, and a local
   configurable value, called Maximum Recovery Time, allows.

LSRがFT Reconnect TimeoutとNeighbor Liveness Timerについて、より少ない中の隣人との自由民主党のセッションを復職させて、LSRが、隣人がMPLS推進状態を保持できなかったことを決定するなら、LSR SHOULDはすぐに、その隣人から受けられたすべての聞き古したラベル-FEC結合を削除します。 LSRが、隣人がMPLS推進状態を保持できたことを決定するなら(隣人によって広告に掲載された非ゼロRecovery Timeによって示されたように)、Maximum Recovery Timeと呼ばれる隣人、および地方の構成可能な値が許容する広告に掲載されたRecovery Timeが、より少ない限り、LSR SHOULDはさらに隣人から受けられた聞き古したラベル-FEC結合を保ちます。

   The LSR SHOULD try to complete the exchange of its label mapping
   information with the neighbor within 1/2 of the Recovery Time, as
   specified in the FT Session TLV received from the neighbor.

LSR SHOULDは1/2Recovery Timeの中で隣人とのラベルマッピング情報の交換を終了しようとします、隣人から受け取られたFT Session TLVで指定されるように。

   The LSR handles the Label Mapping messages received from the neighbor
   by following the normal LDP procedures, except that (a) it treats the
   stale entries in its Label Information Base (LIB) as if these entries
   have been received over the (newly established) session, (b) if the
   label-FEC binding carried in the message is the same as the one that
   is present in the LIB, but is marked as stale, the LIB entry is no
   longer marked as stale, and (c) if for the FEC in the label-FEC
   binding carried in the message there is already a label-FEC binding
   in the LIB that is marked as stale, and the label in the LIB binding
   is different from the label carried in the message, the LSR just
   updates the LIB entry with the new label.

LSRは隣人から正常な自由民主党手順に従うことで受け取られたLabel Mappingメッセージを扱います、(a) まるで(新設されます)セッションの間、これらのエントリーを受けているかのようにLabel Information基地(LIB)の中で聞き古したエントリーを扱うのを除いて、(b) メッセージで運ばれたラベル-FEC結合がLIBに存在しているものと同じであるなら; しかし、聞き古したです、LIBエントリーがもう聞き古したである示されないで、(c) メッセージで運ばれたラベル-FEC結合におけるFECのために、聞き古したであるマークされるLIBで拘束力があるラベル-FECが既にあって、LIB結合におけるラベルがメッセージで運ばれたラベルと異なるなら、LSRが新しいラベルでただLIBエントリーをアップデートするので、マークされます。

   An LSR, once it creates a <label, FEC> binding, 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, 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、それがいったん拘束力があった状態で<ラベル、FEC>を作成すると、LSRが結合でFECにルートを持っている限り、SHOULDはこの結合における、ラベルの値を保ちます。 FECへのルートが後で見えなくなって、次に、再び再現するなら、これは異なったラベル値を使用するのに結果として生じるかもしれません、ルートが再現すると、LSRが新しい<ラベルを作成するだろうというとき、FEC>結合。

   To minimize the potential mis-routing 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 SHOULD
   NOT re-use this label for advertising a <label, FEC> binding to a
   neighbor that supports graceful restart for at least the sum of the
   FT Reconnect Timeout plus Recovery Time, as advertised by the
   neighbor to the LSR.

拘束力があった状態で新しい<ラベル、FEC>を作成するときラベル変化によって引き起こされた潜在的誤ルーティングを最小にするために、LSR SHOULDは最も最近でない中古のラベルを拾います。 LSRがいったんラベルを放出すると、LSR SHOULD NOTは<ラベルの広告を出すのにこのラベルを再使用します、FEC>がFT Reconnect TimeoutとRecovery Timeの合計のための優雅な再開を支持する隣人に固まって、隣人によってLSRに広告に掲載されているように。

Leelanivas, et al.          Standards Track                     [Page 8]

RFC 3478           Graceful Restart Mechanism for LDP      February 2003

Leelanivas、他 規格は2003年2月に自由民主党のためにRFC3478の優雅な再開メカニズムを追跡します[8ページ]。

4. Security Consideration

4. 警備上の配慮

   The security considerations pertaining to the original LDP protocol
   [RFC3036] remain relevant.

オリジナルの自由民主党プロトコル[RFC3036]に関係するセキュリティ問題は関連していたままで残っています。

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

添加、ここで説明されたメカニズムを実行するLSRsを条件としているコネ、以下の追加サービス不能攻撃に:

      An intruder may impersonate an LDP peer in order to force a
      failure and reconnection of the TCP connection, but where the
      intruder sets the Recovery Time to 0 on reconnection.  This forces
      all labels received from the peer to be released.

TCP接続の失敗と再接続を強制しますが、侵入者が0へのRecovery Timeを再接続にけしかけるところで侵入者は自由民主党の同輩をまねるかもしれません。 これによって、同輩から受け取られたすべてのラベルがやむを得ず放出されます。

      An intruder could intercept the traffic between LDP peers and
      override the setting of the Recovery Time to be set to 0.  This
      forces all labels received from the peer to be released.

侵入者は、自由民主党の同輩の間の交通を妨害して、0に設定されるためにRecovery Timeの設定をくつがえすことができました。 これによって、同輩から受け取られたすべてのラベルがやむを得ず放出されます。

   All of these attacks may be countered by use of an authentication
   scheme between LDP peers, such as the MD5-based scheme outlined in
   [LDP].

これらの攻撃のすべてが自由民主党の同輩の間の認証計画の使用で打ち返されるかもしれません、[自由民主党]に概説されたMD5ベースの計画などのように。

   As with LDP, a security issue may exist if an LDP implementation
   continues to use labels after expiration of the 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 mis-routing data to other than intended
   destinations, and it is conceivable that these behaviors may be
   deliberately exploited to either obtain services without
   authorization or to deny services to others.

自由民主党なら、自由民主党の実現が、最初にそれらを使用したセッションの満了の後にラベルを使用し続けているなら、安全保障問題は存在するかもしれません。 ラベルを放出して、再使用した後に上流のLSRがセッション失敗を検出するなら、これは起こるかもしれません。 意図している目的地を除いて、データが広さのプラットホームで、スペースをラベルして、誤ルーティングに結果として生じることができたのが明白な状態で問題はだいたいです、そして、これらの振舞いが認可なしでサービスを得るか、または他のものに対するサービスを否定するのに故意に利用されるのが想像できます。

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

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

   However, the downstream LSR may declare the session as failed before
   the expiration of its Reconnection Timeout.  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 not be re-used until at least the sum of Reconnect Timeout
   plus Recovery Time.

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

Leelanivas, et al.          Standards Track                     [Page 9]

RFC 3478           Graceful Restart Mechanism for LDP      February 2003

Leelanivas、他 規格は2003年2月に自由民主党のためにRFC3478の優雅な再開メカニズムを追跡します[9ページ]。

5. Intellectual Property Considerations

5. 知的所有権問題

   This section is taken from Section 10.4 of [RFC2026].

[RFC2026]のセクション10.4からこのセクションを取ります。

   The IETF takes no position regarding the validity or scope of any
   intellectual property 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; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication 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 implementors or users of this specification can
   be obtained from the IETF Secretariat.

IETFはどんな知的所有権の正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。いずれもどんなそのような権利も特定するための努力にしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、またはIETF事務局からこの仕様のユーザを得ることができます。

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.

IETFはこの規格を練習するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 IETF専務に情報を記述してください。

   The IETF has been notified of intellectual property rights claimed in
   regard to some or all of the specification contained in this
   document.  For more information consult the online list of claimed
   rights.

IETFは本書では含まれた仕様いくつかかすべてに関して要求された知的所有権について通知されました。 詳しい情報に関しては、要求された権利のオンラインリストに相談してください。

6. Acknowledgments

6. 承認

   We would like to thank Loa Andersson, Chaitanya Kodeboyina, Ina
   Minei, Nischal Sheth, Enke Chen, and Adrian Farrel for their
   contributions to this document.

このドキュメントへの彼らの貢献についてLoaアンデション、Chaitanya Kodeboyina、伊奈Minei、Nischal Sheth、Enkeチェン、およびエードリアン・ファレルに感謝申し上げます。

7. Normative References

7. 引用規格

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

   [FT-LDP]       Farrel, A., "Fault Tolerance for the Label
                  Distribution Protocol (LDP)", RFC 3479, February 2003.

[フィート自由民主党]ファレル、A.、「ラベル分配プロトコル(自由民主党)のための耐障害性」、RFC3479、2003年2月。

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

Leelanivas, et al.          Standards Track                    [Page 10]

RFC 3478           Graceful Restart Mechanism for LDP      February 2003

Leelanivas、他 規格は2003年2月に自由民主党のためにRFC3478の優雅な再開メカニズムを追跡します[10ページ]。

   [RFC2026]      Bradner, S., "The Internet Standards Process --
                  Revision 3", BCP 9, RFC 2026, October 1996.

[RFC2026] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」

8. Informative References

8. 有益な参照

   [OSPF-RESTART] "Hitless OSPF Restart", Work in Progress.

[OSPF-再開] 「無安打OSPFは再開する」処理中の作業。

   [ISIS-RESTART] "Restart signaling for ISIS", Work in Progress.

[イシス-RESTART] 「イシスのための再開シグナリング」、ProgressのWork。

   [BGP-RESTART]  "Graceful Restart Mechanism for BGP", Work in
                  Progress.

[BGP-再開] 「BGPのための優雅な再開メカニズム」、処理中の作業。

9. Authors' Addresses

9. 作者のアドレス

   Manoj Leelanivas
   Juniper Networks
   1194 N. Mathilda Ave
   Sunnyvale, CA 94089

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

   EMail: manoj@juniper.net

メール: manoj@juniper.net

   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
   Redback Networks
   350 Holger Way
   San Jose, CA 95134

Rahul Aggarwal20ドル紙幣は350オルガーWayサンノゼ(カリフォルニア)95134をネットワークでつなぎます。

   EMail: rahul@redback.com

メール: rahul@redback.com

Leelanivas, et al.          Standards Track                    [Page 11]

RFC 3478           Graceful Restart Mechanism for LDP      February 2003

Leelanivas、他 規格は2003年2月に自由民主党のためにRFC3478の優雅な再開メカニズムを追跡します[11ページ]。

10.  Full Copyright Statement

10. 完全な著作権宣言文

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Copyright(C)インターネット協会(2003)。 All rights reserved。

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Acknowledgement

承認

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

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

Leelanivas, et al.          Standards Track                    [Page 12]

Leelanivas、他 標準化過程[12ページ]