RFC4724 日本語訳
4724 Graceful Restart Mechanism for BGP. S. Sangli, E. Chen, R.Fernando, J. Scudder, Y. Rekhter. January 2007. (Format: TXT=32343 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Sangli
Request for Comments: 4724 E. Chen
Category: Standards Track Cisco Systems
R. Fernando
J. Scudder
Y. Rekhter
Juniper Networks
January 2007
コメントを求めるワーキンググループS.サーングリの要求をネットワークでつないでください: 4724年のE.チェンカテゴリ: 規格は2007年1月にシスコシステムズR.フェルナンドJ.Scudder Y.Rekhter杜松ネットワークを追跡します。
Graceful Restart Mechanism for BGP
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 IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
Abstract
要約
This document describes a mechanism for BGP that would help minimize the negative effects on routing caused by BGP restart. An End-of-RIB marker is specified and can be used to convey routing convergence information. A new BGP capability, termed "Graceful Restart Capability", is defined that would allow a BGP speaker to express its ability to preserve forwarding state during BGP restart. Finally, procedures are outlined for temporarily retaining routing information across a TCP session termination/re-establishment.
このドキュメントはBGP再開で引き起こされたルーティングへのマイナスの効果を最小にするのを助けるBGPのためにメカニズムについて説明します。 RIBのEndマーカーを指定します、そして、ルーティング集合情報を伝えるのに使用できます。 「優雅な再開能力」と呼ばれて、BGPスピーカーがBGP再開の間に推進状態を保持する性能を言い表すことができる新しいBGP能力は定義されます。 最終的に、手順は、TCPセッション終了/再建の向こう側に一時ルーティング情報を保有するために概説されています。
The mechanisms described in this document are applicable to all routers, both those with the ability to preserve forwarding state during BGP restart and those without (although the latter need to implement only a subset of the mechanisms described in this document).
本書では説明されたメカニズムはすべてのルータ(能力(後者は、本書では説明されたメカニズムの部分集合だけを実行する必要がありますが)があるBGP再開とそれらの間の推進状態を保持する両方のそれら)に適切です。
Sangli, et al. Standards Track [Page 1] RFC 4724 Graceful Restart Mechanism for BGP January 2007
サーングリ、他 規格は2007年1月にBGPのためにRFC4724の優雅な再開メカニズムを追跡します[1ページ]。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Specification of Requirements ..............................2
2. Marker for End-of-RIB ...........................................3
3. Graceful Restart Capability .....................................3
4. Operation .......................................................6
4.1. Procedures for the Restarting Speaker ......................6
4.2. Procedures for the Receiving Speaker .......................7
5. Changes to BGP Finite State Machine .............................9
6. Deployment Considerations ......................................11
7. Security Considerations ........................................12
8. Acknowledgments ................................................13
9. IANA Considerations ............................................13
10. References ....................................................13
10.1. Normative References .....................................13
10.2. Informative References ...................................13
1. 序論…2 1.1. 要件の仕様…2 2. 肋材の先端のマーカー…3 3. 優雅な再開能力…3 4. 操作…6 4.1. 再開している議長のための手順…6 4.2. 受信議長のための手順…7 5. BGP有限状態機械への変化…9 6. 展開問題…11 7. セキュリティ問題…12 8. 承認…13 9. IANA問題…13 10. 参照…13 10.1. 標準の参照…13 10.2. 有益な参照…13
1. Introduction
1. 序論
Usually, when BGP on a router restarts, all the BGP peers detect that the session went down and then came up. This "down/up" transition results in a "routing flap" and causes BGP route re-computation, generation of BGP routing updates, and unnecessary churn to the forwarding tables. It could spread across multiple routing domains. Such routing flaps may create transient forwarding blackholes and/or transient forwarding loops. They also consume resources on the control plane of the routers affected by the flap. As such, they are detrimental to the overall network performance.
ルータのBGPが再開するときの通常同輩が検出するセッションが落ちて、次に来たすべてのBGP。 この「下がるか上がる」「ルーティングフラップ」と原因BGPの変遷結果が発送する再計算、BGPルーティングアップデートの世代、および推進テーブルへの不要な攪乳器。 それは複数の経路ドメインの向こう側に広まることができました。 そのようなルーティングフラップは一時的な推進blackholes、そして/または、一時的な推進輪を作成するかもしれません。 また、彼らはフラップで影響を受けるルータの制御飛行機に関するリソースを消費します。 そういうものとして、それらは総合的なネットワーク性能に有害です。
This document describes a mechanism for BGP that would help minimize the negative effects on routing caused by BGP restart. An End-of-RIB marker is specified and can be used to convey routing convergence information. A new BGP capability, termed "Graceful Restart Capability", is defined that would allow a BGP speaker to express its ability to preserve forwarding state during BGP restart. Finally, procedures are outlined for temporarily retaining routing information across a TCP session termination/re-establishment.
このドキュメントはBGP再開で引き起こされたルーティングへのマイナスの効果を最小にするのを助けるBGPのためにメカニズムについて説明します。 RIBのEndマーカーを指定します、そして、ルーティング集合情報を伝えるのに使用できます。 「優雅な再開能力」と呼ばれて、BGPスピーカーがBGP再開の間に推進状態を保持する性能を言い表すことができる新しいBGP能力は定義されます。 最終的に、手順は、TCPセッション終了/再建の向こう側に一時ルーティング情報を保有するために概説されています。
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]で説明されるように本書では解釈されることであるべきですか?
Sangli, et al. Standards Track [Page 2] RFC 4724 Graceful Restart Mechanism for BGP January 2007
サーングリ、他 規格は2007年1月にBGPのためにRFC4724の優雅な再開メカニズムを追跡します[2ページ]。
2. Marker for End-of-RIB
2. 肋材の先端のマーカー
An UPDATE message with no reachable Network Layer Reachability Information (NLRI) and empty withdrawn NLRI is specified as the End- of-RIB marker that can be used by a BGP speaker to indicate to its peer the completion of the initial routing update after the session is established. For the IPv4 unicast address family, the End-of-RIB marker is an UPDATE message with the minimum length [BGP-4]. For any other address family, it is an UPDATE message that contains only the MP_UNREACH_NLRI attribute [BGP-MP] with no withdrawn routes for that <AFI, SAFI>.
BGPスピーカーがセッションの後に初期のルーティングアップデートの完成を同輩に示すのに使用できるRIBのEndマーカーが確立されるとき、届いているNetwork Layer Reachability情報(NLRI)と空のよそよそしいNLRIのないUPDATEメッセージは指定されます。 IPv4ユニキャストアドレス家において、RIBのEndマーカーは最小の長さ[BGP-4]があるUPDATEメッセージです。 いかなる他のアドレス家族にとっても、それはその<AFI(サフィ>)に、よそよそしいルートなしでMP_UNREACH_NLRI属性[BGP-MP]だけを含むUPDATEメッセージです。
Although the End-of-RIB marker is specified for the purpose of BGP graceful restart, it is noted that the generation of such a marker upon completion of the initial update would be useful for routing convergence in general, and thus the practice is recommended.
RIBのEndマーカーはBGPの優雅な再開の目的に指定されますが、初期のアップデートの完成のそのようなマーカーの世代が一般に、ルーティング集合の役に立って、その結果、習慣がお勧めであることに注意されます。
In addition, it would be beneficial for routing convergence if a BGP speaker can indicate to its peer up-front that it will generate the End-of-RIB marker, regardless of its ability to preserve its forwarding state during BGP restart. This can be accomplished using the Graceful Restart Capability described in the next section.
さらに、BGPスピーカーが、RIBのEndマーカーを発生させるのを前払いで同輩に示すことができるなら、ルーティング集合には、有益でしょう、BGP再開の間に推進状態を保持する性能にかかわらず。 次のセクションで説明されたGraceful Restart Capabilityを使用することでこれを達成できます。
3. Graceful Restart Capability
3. 優雅な再開能力
The Graceful Restart Capability is a new BGP capability [BGP-CAP] that can be used by a BGP speaker to indicate its ability to preserve its forwarding state during BGP restart. It can also be used to convey to its peer its intention of generating the End-of-RIB marker upon the completion of its initial routing updates.
Graceful Restart CapabilityはBGPスピーカーがBGP再開の間に推進状態を保持する性能を示すのに使用できる新しいBGP能力[BGP-CAP]です。 また、初期のルーティングアップデートの完成のときにRIBのEndマーカーを発生させるという意志を同輩に伝えるのにそれを使用できます。
This capability is defined as follows:
この能力は以下の通り定義されます:
Capability code: 64
能力コード: 64
Capability length: variable
能力の長さ: 変数
Capability value: Consists of the "Restart Flags" field, "Restart
Time" field, and 0 to 63 of the tuples <AFI, SAFI, Flags for
address family> as follows:
能力値: 以下の「再開旗」分野、「再開時間」分野、およびアドレス家族>のための63 0〜<AFI、tuplesサフィFlagsから成ります:
Sangli, et al. Standards Track [Page 3] RFC 4724 Graceful Restart Mechanism for BGP January 2007
サーングリ、他 規格は2007年1月にBGPのためにRFC4724の優雅な再開メカニズムを追跡します[3ページ]。
+--------------------------------------------------+
| Restart Flags (4 bits) |
+--------------------------------------------------+
| Restart Time in seconds (12 bits) |
+--------------------------------------------------+
| Address Family Identifier (16 bits) |
+--------------------------------------------------+
| Subsequent Address Family Identifier (8 bits) |
+--------------------------------------------------+
| Flags for Address Family (8 bits) |
+--------------------------------------------------+
| ... |
+--------------------------------------------------+
| Address Family Identifier (16 bits) |
+--------------------------------------------------+
| Subsequent Address Family Identifier (8 bits) |
+--------------------------------------------------+
| Flags for Address Family (8 bits) |
+--------------------------------------------------+
+--------------------------------------------------+ | 再開Flags(4ビット)| +--------------------------------------------------+ | 秒(12ビット)にTimeを再開してください。| +--------------------------------------------------+ | アドレスFamily Identifier(16ビット)| +--------------------------------------------------+ | その後のAddress Family Identifier(8ビット)| +--------------------------------------------------+ | Address Family(8ビット)のための旗| +--------------------------------------------------+ | ... | +--------------------------------------------------+ | アドレスFamily Identifier(16ビット)| +--------------------------------------------------+ | その後のAddress Family Identifier(8ビット)| +--------------------------------------------------+ | Address Family(8ビット)のための旗| +--------------------------------------------------+
The use and meaning of the fields are as follows:
分野の使用と意味は以下の通りです:
Restart Flags:
旗を再開してください:
This field contains bit flags related to restart.
この分野は旗が再開するために関係づけたビットを含んでいます。
0 1 2 3
+-+-+-+-+
|R|Resv.|
+-+-+-+-+
0 1 2 3 +-+-+-+-+ |R|Resv| +++++
The most significant bit is defined as the Restart State (R)
bit, which can be used to avoid possible deadlock caused by
waiting for the End-of-RIB marker when multiple BGP speakers
peering with each other restart. When set (value 1), this bit
indicates that the BGP speaker has restarted, and its peer MUST
NOT wait for the End-of-RIB marker from the speaker before
advertising routing information to the speaker.
Restart州(R)ビットと最も重要なビットを定義します。(互いと共にじっと見ている複数のBGPスピーカーが再開するとRIBのEndマーカーを待つことによって引き起こされた可能な行き詰まりを避けるのにそれを使用できます)。 設定されると(値1)、このビットは、BGPスピーカーが再開したのを示します、そして、同輩はルーティング情報の広告を出す前のスピーカーからスピーカーまでRIBのEndマーカーを待ってはいけません。
The remaining bits are reserved and MUST be set to zero by the
sender and ignored by the receiver.
残っているビットを予約されていて、送付者によってゼロに設定されて、受信機で無視しなければなりません。
Restart Time:
再開時間:
This is the estimated time (in seconds) it will take for the
BGP session to be re-established after a restart. This can be
used to speed up routing convergence by its peer in case that
the BGP speaker does not come back after a restart.
これはわざわざ(秒の)ですそれが再開の後にBGPセッションを復職する概算の。 BGPスピーカーが再開の後に戻らせない場合で同輩によるルーティング集合を早くするのにこれを使用できます。
Sangli, et al. Standards Track [Page 4] RFC 4724 Graceful Restart Mechanism for BGP January 2007
サーングリ、他 規格は2007年1月にBGPのためにRFC4724の優雅な再開メカニズムを追跡します[4ページ]。
Address Family Identifier (AFI), Subsequent Address Family
Identifier (SAFI):
家族識別子(AFI)、その後のアドレス家族識別子(サフィ)を記述してください:
The AFI and SAFI, taken in combination, indicate that Graceful
Restart is supported for routes that are advertised with the
same AFI and SAFI. Routes may be explicitly associated with a
particular AFI and SAFI using the encoding of [BGP-MP] or
implicitly associated with <AFI=IPv4, SAFI=Unicast> if using
the encoding of [BGP-4].
組み合わせで占領されたAFIとサフィは、Graceful Restartが同じAFIとサフィと共に広告に掲載されているルートに支持されるのを示します。 [BGP-4]のコード化を使用するなら、ルートは、明らかに[BGP-MP]のコード化を使用する特定のAFIとサフィに関連しているか、またはそれとなく<AFI=IPv4、サフィ=ユニキャスト>に関連しているかもしれません。
Flags for Address Family:
アドレス家族のための旗:
This field contains bit flags relating to routes that were
advertised with the given AFI and SAFI.
この分野は与えられたAFIとサフィと共に広告に掲載されたルートに関連する噛み付いている旗を含んでいます。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|F| Reserved |
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |F| 予約されます。| +-+-+-+-+-+-+-+-+
The most significant bit is defined as the Forwarding State (F)
bit, which can be used to indicate whether the forwarding state
for routes that were advertised with the given AFI and SAFI has
indeed been preserved during the previous BGP restart. When
set (value 1), the bit indicates that the forwarding state has
been preserved.
Forwarding州(F)ビットと最も重要なビットを定義します。(本当に、与えられたAFIとサフィと共に広告に掲載されたルートへの推進状態が前のBGP再開の間、保持されているかどうかを示すのにそれを使用できます)。 設定されると(値1)、ビットは、推進状態が保持されたのを示します。
The remaining bits are reserved and MUST be set to zero by the
sender and ignored by the receiver.
残っているビットを予約されていて、送付者によってゼロに設定されて、受信機で無視しなければなりません。
When a sender of this capability does not include any <AFI, SAFI> in the capability, it means that the sender is not capable of preserving its forwarding state during BGP restart, but supports procedures for the Receiving Speaker (as defined in Section 4.2 of this document). In that case, the value of the "Restart Time" field advertised by the sender is irrelevant.
この能力の送付者が能力でどんな<AFI、サフィ>も入れないと、それは、送付者がBGP再開の間推進状態を保持できないことを意味しますが、Receiving議長のために手順を支持します(このドキュメントのセクション4.2で定義されるように)。 その場合、送付者によって広告に掲載された「再開時間」分野の値は無関係です。
A BGP speaker MUST NOT include more than one instance of the Graceful Restart Capability in the capability advertisement [BGP-CAP]. If more than one instance of the Graceful Restart Capability is carried in the capability advertisement, the receiver of the advertisement MUST ignore all but the last instance of the Graceful Restart Capability.
BGPスピーカーは能力広告[BGP-CAP]でGraceful Restart Capabilityの1つ以上の例を入れてはいけません。 Graceful Restart Capabilityの1つ以上の例が能力広告で運ばれるなら、広告の受信機はGraceful Restart Capabilityの最終審以外のすべてを無視しなければなりません。
Including <AFI=IPv4, SAFI=unicast> in the Graceful Restart Capability does not imply that the IPv4 unicast routing information should be carried by using the BGP multiprotocol extensions [BGP-MP] -- it could be carried in the NLRI field of the BGP UPDATE message.
Graceful Restart Capabilityに<AFI=IPv4、サフィ=ユニキャスト>を含んでいるのは、IPv4ユニキャストルーティング情報がBGP multiprotocol拡張子[BGP-MP]を使用することによって運ばれるべきであるのを含意しません--BGP UPDATEメッセージのNLRI分野でそれを運ぶことができました。
Sangli, et al. Standards Track [Page 5] RFC 4724 Graceful Restart Mechanism for BGP January 2007
サーングリ、他 規格は2007年1月にBGPのためにRFC4724の優雅な再開メカニズムを追跡します[5ページ]。
4. Operation
4. 操作
A BGP speaker MAY advertise the Graceful Restart Capability for an address family to its peer if it has the ability to preserve its forwarding state for the address family when BGP restarts. In addition, even if the speaker does not have the ability to preserve its forwarding state for any address family during BGP restart, it is still recommended that the speaker advertise the Graceful Restart Capability to its peer (as mentioned before this is done by not including any <AFI, SAFI> in the advertised capability). There are two reasons for doing this. The first is to indicate its intention of generating the End-of-RIB marker upon the completion of its initial routing updates, as doing this would be useful for routing convergence in general. The second is to indicate its support for a peer which wishes to perform a graceful restart.
BGPが再開するとそれにアドレス家族のために推進状態を保持する能力があるなら、BGPスピーカーはアドレス家族のために同輩にGraceful Restart Capabilityの広告を出すかもしれません。 さらに、スピーカーにどんなアドレス家族のためにもBGP再開の間に推進状態を保持する能力がなくても、スピーカーが同輩にGraceful Restart Capabilityの広告を出すのは、まだお勧めです(広告を出している能力にどんな<AFI、サフィ>も含んでいないことによってこれをする前に言及するように)。 これをする2つの理由があります。 1番目は初期のルーティングアップデートの完成のときにRIBのEndマーカーを発生させるという意志を示すことです、これをするのが一般に、ルーティング集合の役に立つでしょう、したがって。 2番目は優雅な再開を実行したがっている同輩のサポートを示すことです。
The End-of-RIB marker MUST be sent by a BGP speaker to its peer once it completes the initial routing update (including the case when there is no update to send) for an address family after the BGP session is established.
BGPセッションが確立された後にそれがアドレス家族のために、いったん、初期のルーティングアップデート(送るアップデートが全くないとき、ケースを含んでいる)を終了すると、BGPスピーカーはRIBのEndマーカーを同輩に送らなければなりません。
It is noted that the normal BGP procedures MUST be followed when the TCP session terminates due to the sending or receiving of a BGP NOTIFICATION message.
TCPセッションがBGP NOTIFICATIONメッセージの発信か受信のため終わるとき、正常なBGP手順に従わなければならないことに注意されます。
A suggested default for the Restart Time is a value less than or equal to the HOLDTIME carried in the OPEN.
Restart Timeのための提案されたデフォルトは、よりHOLDTIMEがオープンで運んだ値です。
In the following sections, "Restarting Speaker" refers to a router whose BGP has restarted, and "Receiving Speaker" refers to a router that peers with the restarting speaker.
以下のセクションで、「議長を再出発します」はBGPが再開したルータを示します、そして、「議長を受けます」は再開しているスピーカーと共にじっと見るルータを示します。
Consider that the Graceful Restart Capability for an address family is advertised by the Restarting Speaker, and is understood by the Receiving Speaker, and a BGP session between them is established. The following sections detail the procedures that MUST be followed by the Restarting Speaker as well as the Receiving Speaker once the Restarting Speaker restarts.
アドレス家族のためのGraceful Restart CapabilityがRestarting議長によって広告を出されて、Receiving議長に解釈されて、それらの間のBGPセッションが確立されると考えてください。 以下のセクションはRestarting議長がいったん再開するとRestarting議長とReceiving議長が従わなければならない手順を詳しく述べます。
4.1. Procedures for the Restarting Speaker
4.1. 再開している議長のための手順
When the Restarting Speaker restarts, it MUST retain, if possible, the forwarding state for the BGP routes in the Loc-RIB and MUST mark them as stale. It MUST NOT differentiate between stale and other information during forwarding.
Restarting議長が再開すると、それは、できれば、Loc-RIBのBGPルートへの推進状態を保有しなければならなくて、それらが聞き古したであるマークしなければなりません。 それは推進の間、聞き古した他の情報を区別してはいけません。
To re-establish the session with its peer, the Restarting Speaker MUST set the "Restart State" bit in the Graceful Restart Capability
同輩とのセッションを復職させるために、Restarting議長は「再開状態」ビットをGraceful Restart Capabilityにはめ込まなければなりません。
Sangli, et al. Standards Track [Page 6] RFC 4724 Graceful Restart Mechanism for BGP January 2007
サーングリ、他 規格は2007年1月にBGPのためにRFC4724の優雅な再開メカニズムを追跡します[6ページ]。
of the OPEN message. Unless allowed via configuration, the "Forwarding State" bit for an address family in the capability can be set only if the forwarding state has indeed been preserved for that address family during the restart.
オープンメッセージについて。 本当に、推進状態がそのアドレス家族のために再開の間、保持されていてだけ、構成で許容されていない場合、能力におけるアドレス家族のための「推進状態」ビットを設定できます。
Once the session between the Restarting Speaker and the Receiving Speaker is re-established, the Restarting Speaker will receive and process BGP messages from its peers. However, it MUST defer route selection for an address family until it either (a) receives the End-of-RIB marker from all its peers (excluding the ones with the "Restart State" bit set in the received capability and excluding the ones that do not advertise the graceful restart capability) or (b) the Selection_Deferral_Timer referred to below has expired. It is noted that prior to route selection, the speaker has no routes to advertise to its peers and no routes to update the forwarding state.
Restarting議長とReceiving議長とのセッションがいったん復職すると、Restarting議長は、同輩からBGPメッセージを受け取って、処理するでしょう。 しかしながら、それはアドレス家族のためにそれまでルート選択を延期しなければなりません。(b) (a)がすべての同輩からRIBのEndマーカーを受け取るか(「再開状態」ビットでものを除くのは容認された能力と優雅な再開能力の広告を出さないものを除く際にセットしました)、またはTimerが以下と呼んだSelection_Deferral_は期限が切れました。 ルート選択の前に、スピーカーには推進状態をアップデートするために同輩にもかかわらず、ルートがないのに広告を出さないルートが全くあることに注意されます。
In situations where both Interior Gateway Protocol (IGP) and BGP have restarted, it might be advantageous to wait for IGP to converge before the BGP speaker performs route selection.
Interiorゲートウェイプロトコル(IGP)とBGPの両方が再開した状況で、BGPスピーカーがルート選択を実行する前にIGPが一点に集まるのを待つのは有利であるかもしれません。
After the BGP speaker performs route selection, the forwarding state of the speaker MUST be updated and any previously marked stale information MUST be removed. The Adj-RIB-Out can then be advertised to its peers. Once the initial update is complete for an address family (including the case that there is no routing update to send), the End-of-RIB marker MUST be sent.
BGPスピーカーがルート選択を実行した後に、スピーカーの推進状態をアップデートしなければなりません、そして、どんな以前に著しい聞き古した情報も取り除かなければなりません。 そして、外のAdj-RIBの同輩に広告を出すことができます。 初期のアップデートがいったんアドレス家族にとって完全に(あるケースを含んでいるのが発信するためにアップデートを発送しないで)なると、RIBのEndマーカーを送らなければなりません。
To put an upper bound on the amount of time a router defers its route selection, an implementation MUST support a (configurable) timer that imposes this upper bound. This timer is referred to as the "Selection_Deferral_Timer". The value of this timer should be large enough, so as to provide all the peers of the Restarting Speaker with enough time to send all the routes to the Restarting Speaker.
ルータがルート選択を延期する時間に上限を置くために、実現はこの上限を課す(構成可能)のタイマを支えなければなりません。 このタイマは「選択_延期_タイマ」と呼ばれます。 このタイマの値は十分大きいはずです、すべてのルートをRestarting議長に送ることができるくらいの時間にRestarting議長のすべての同輩を提供するために。
If one wants to apply graceful restart only when the restart is planned (as opposed to both planned and unplanned restart), then one way to accomplish this would be to set the Forwarding State bit to 1 after a planned restart, and to 0 in all other cases. Other approaches to accomplish this are outside the scope of this document.
再開が計画されていて(計画されたものと同様に無計画な再開と対照的に)、次に、達成することにおいて一方通行であるときにだけ、人が優雅な再開を適用したいなら、これは、計画された再開の後の1と、そして、他のすべての場合における0にForwarding州ビットを設定するためのものです。 このドキュメントの範囲の外にこれを達成する他のアプローチがあります。
4.2. Procedures for the Receiving Speaker
4.2. 受信議長のための手順
When the Restarting Speaker restarts, the Receiving Speaker may or may not detect the termination of the TCP session with the Restarting Speaker, depending on the underlying TCP implementation, whether or not [BGP-AUTH] is in use, and the specific circumstances of the restart. In case it does not detect the termination of the old TCP session and still considers the BGP session as being established, it
Restarting議長が再開すると、Receiving議長はRestarting議長とのTCPセッションの終了を検出するかもしれません、基本的なTCP実現によって、[BGP-AUTH]が使用、および再開の特定の事情にあるか否かに関係なく。 場合では、古いTCPセッションの終了を検出しないで、まだBGPセッションが設立することにされるのであるとみなしています、それ
Sangli, et al. Standards Track [Page 7] RFC 4724 Graceful Restart Mechanism for BGP January 2007
サーングリ、他 規格は2007年1月にBGPのためにRFC4724の優雅な再開メカニズムを追跡します[7ページ]。
MUST treat the subsequent open connection from the peer as an indication of the termination of the old TCP session and act accordingly (when the Graceful Restart Capability has been received from the peer). See Section 8 for a description of this behavior in terms of the BGP finite state machine.
古いTCPセッションと行為の終了のしるしとして同輩からその後のオープンな接続をそれに従って(同輩からGraceful Restart Capabilityを受け取ったとき)、扱わなければなりません。 この振舞いの記述に関してBGP有限状態機械に関してセクション8を見てください。
"Acting accordingly" in this context means that the previous TCP session MUST be closed, and the new one retained. Note that this behavior differs from the default behavior, as specified in [BGP-4], Section 6.8. Since the previous connection is considered to be terminated, no NOTIFICATION message should be sent -- the previous TCP session is simply closed.
「善処します」は、前のTCPセッションが閉じなければならなくて、新しい方が保有されていることをこのような関係においては意味します。 [BGP-4]、セクション6.8で指定されるようにこの振舞いがデフォルトの振舞いと異なっていることに注意してください。 前の接続が終えられると考えられるので、NOTIFICATIONメッセージを全く送るべきではありません--前のTCPセッションは単に終えられます。
When the Receiving Speaker detects termination of the TCP session for a BGP session with a peer that has advertised the Graceful Restart Capability, it MUST retain the routes received from the peer for all the address families that were previously received in the Graceful Restart Capability and MUST mark them as stale routing information. To deal with possible consecutive restarts, a route (from the peer) previously marked as stale MUST be deleted. The router MUST NOT differentiate between stale and other routing information during forwarding.
Receiving議長がGraceful Restart Capabilityの広告を出した同輩とのBGPセッションのためにTCPセッションの終了を検出するとき、それは情報を発送する以前に、Graceful Restart Capabilityに受け取られて、彼らが聞き古したであるマークしなければならないすべてのアドレス家族のための同輩から受け取られたルートを保有しなければなりません。 可能な連続した再開に対処するために、以前に聞き古したであるマークされたルート(同輩からの)を削除しなければなりません。 ルータは推進の間、聞き古した他のルーティング情報を区別してはいけません。
In re-establishing the session, the "Restart State" bit in the Graceful Restart Capability of the OPEN message sent by the Receiving Speaker MUST NOT be set unless the Receiving Speaker has restarted. The presence and the setting of the "Forwarding State" bit for an address family depend upon the actual forwarding state and configuration.
セッションを復職させる際に、Receiving議長が再開していない場合、Receiving議長によって送られたオープンメッセージのGraceful Restart Capabilityの「再開状態」ビットを設定してはいけません。 アドレス家族のための「推進状態」ビットの存在と設定は実際の推進状態と構成に依存します。
If the session does not get re-established within the "Restart Time" that the peer advertised previously, the Receiving Speaker MUST delete all the stale routes from the peer that it is retaining.
セッションが同輩が以前に広告を出した「再開時間」中に復職しないなら、Receiving議長はそれが保有している同輩からすべての聞き古したルートを削除しなければなりません。
A BGP speaker could have some way of determining whether its peer's forwarding state is still viable, for example through Bidirectional Forwarding Detection [BFD] or through monitoring layer two information. Specifics of such mechanisms are beyond the scope of this document. In the event that it determines that its peer's forwarding state is not viable prior to the re-establishment of the session, the speaker MAY delete all the stale routes from the peer that it is retaining.
BGPスピーカーは同輩の推進状態がBidirectional Forwarding Detection[BFD]を通して、または、例えば、モニターを通してまだ実行可能であるかどうか決定する何らかの方法に2情報を層にさせることができました。 そのようなメカニズムの詳細はこのドキュメントの範囲を超えています。 同輩の推進状態がセッションの再建の前に実行可能でないことを決定する場合、スピーカーはそれが保有している同輩からすべての聞き古したルートを削除するかもしれません。
Once the session is re-established, if the "Forwarding State" bit for a specific address family is not set in the newly received Graceful Restart Capability, or if a specific address family is not included in the newly received Graceful Restart Capability, or if the Graceful Restart Capability is not received in the re-established session at
特定のアドレス家族のための「推進状態」ビットが新たに受け取られたGraceful Restart Capabilityに設定されないなら、セッションが一度復職するか、特定のアドレス家族が新たに受け取られたGraceful Restart Capabilityに含まれていません、またはGraceful Restart Capabilityは復職しているセッションのときに受け取られません。
Sangli, et al. Standards Track [Page 8] RFC 4724 Graceful Restart Mechanism for BGP January 2007
サーングリ、他 規格は2007年1月にBGPのためにRFC4724の優雅な再開メカニズムを追跡します[8ページ]。
all, then the Receiving Speaker MUST immediately remove all the stale routes from the peer that it is retaining for that address family.
すべて、その時、Receiving議長はすぐに、それがそのアドレス家族のために保有している同輩からすべての聞き古したルートを取り外さなければなりません。
The Receiving Speaker MUST send the End-of-RIB marker once it completes the initial update for an address family (including the case that it has no routes to send) to the peer.
それがアドレス家族(それが持っているケースを含んでいますいいえが発信するために発送する)のためにいったん初期のアップデートを同輩に終了すると、Receiving議長はRIBのEndマーカーを送らなければなりません。
The Receiving Speaker MUST replace the stale routes by the routing updates received from the peer. Once the End-of-RIB marker for an address family is received from the peer, it MUST immediately remove any routes from the peer that are still marked as stale for that address family.
Receiving議長は同輩から受けられたルーティングアップデートに聞き古したルートを置き換えなければなりません。 同輩からアドレス家族のためのRIBのEndマーカーをいったん受け取ると、それはすぐに、同輩からのまだそのアドレス家族にとって聞き古したであるマークされているどんなルートも取り外さなければなりません。
To put an upper bound on the amount of time a router retains the stale routes, an implementation MAY support a (configurable) timer that imposes this upper bound.
ルータが聞き古したルートを保有する時間に上限を置くために、実現はこの上限を課す(構成可能)のタイマを支えるかもしれません。
5. Changes to BGP Finite State Machine
5. BGP有限状態機械への変化
As mentioned under "Procedures for the Receiving Speaker" above, this specification modifies the BGP finite state machine.
上の「受信議長のための手順」の下で言及されるように、この仕様はBGP有限状態機械を変更します。
The specific state machine modifications to [BGP-4], Section 8.2.2, are as follows.
[BGP-4]への特定の州のマシン変更(セクション8.2.2)は以下の通りです。
In the Idle state, make the following changes.
Idle状態では、以下の変更を行ってください。
Replace this text:
本稿を取り替えてください:
- initializes all BGP resources for the peer connection,
- 同輩接続のためにすべてのBGPリソースを初期化します。
with
with
- initializes all BGP resources for the peer connection, other
than those resources required in order to retain routes
according to section "Procedures for the Receiving Speaker" of
this (Graceful Restart) specification,
- 「受信議長のための手順」というこの(優雅なRestart)仕様のセクションによると、ルートを保有するのに必要であるそれらのリソース以外の同輩接続のためにすべてのBGPリソースを初期化します。
In the Established state, make the following changes.
Established状態では、以下の変更を行ってください。
Replace this text:
本稿を取り替えてください:
In response to an indication that the TCP connection is
successfully established (Event 16 or Event 17), the second
connection SHALL be tracked until it sends an OPEN message.
TCP接続は首尾よく確立されます(出来事16かEvent17)、2番目の接続SHALL。指示に対応したそれ、オープンメッセージを送るまで、追跡されます。
with
with
Sangli, et al. Standards Track [Page 9] RFC 4724 Graceful Restart Mechanism for BGP January 2007
サーングリ、他 規格は2007年1月にBGPのためにRFC4724の優雅な再開メカニズムを追跡します[9ページ]。
If the Graceful Restart Capability with one or more AFIs/SAFIs
has not been received for the session, then in response to an
indication that a TCP connection is successfully established
(Event 16 or Event 17), the second connection SHALL be tracked
until it sends an OPEN message.
AFIs/SAFIsは1以上があるGraceful Restart Capabilityであるならセッションのために受け取られていません、そしてTCP接続が首尾よく確立されるという指示(出来事16かEvent17)に対応して、2番目の接続SHALL。オープンメッセージを送るまで、追跡されます。
However, if the Graceful Restart Capability with one or more
AFIs/SAFIs has been received for the session, then in response
to Event 16 or Event 17 the local system:
しかしながら、1以上があるGraceful Restart Capabilityであるなら、セッションのためにAFIs/SAFIsを受け取りました、そしてEvent16かEvent17に対応したローカルシステム:
- retains all routes associated with this connection according
to section "Procedures for the Receiving Speaker" of this
(Graceful Restart) specification,
- 「受信議長のための手順」というこの(優雅なRestart)仕様のセクションによると、この接続に関連しているすべてのルートを保有します。
- releases all other BGP resources,
- 他のすべてのBGPリソースを発表します。
- drops the TCP connection associated with the ESTABLISHED
session,
- TCP接続がESTABLISHEDセッションに関連づけた低下
- initializes all BGP resources for the peer connection, other
than those required in order to retain routes according to
section "Procedures for the Receiving Speaker" of this
specification,
- 「受信議長のための手順」というこの仕様のセクションによると、ルートを保有するのに必要であるもの以外の同輩接続のためにすべてのBGPリソースを初期化します。
- sets ConnectRetryCounter to zero,
- ゼロにConnectRetryCounterを設定します。
- starts the ConnectRetryTimer with the initial value, and
- そして初期の値からConnectRetryTimerを始動する。
- changes its state to Connect.
- 状態をConnectに変えます。
Replace this text:
本稿を取り替えてください:
If the local system receives a NOTIFICATION message (Event 24 or
Event 25), or a TcpConnectionFails (Event 18) from the underlying
TCP, the local system:
ローカルシステムはNOTIFICATIONメッセージ(出来事24かEvent25)を受け取るか、そして、基本的なTCP、ローカルシステムからのTcpConnectionFails(出来事18):
- sets the ConnectRetryTimer to zero,
- ゼロにConnectRetryTimerを設定します。
- deletes all routes associated with this connection,
- この接続に関連しているすべてのルートを削除します。
- releases all the BGP resources,
- すべてのBGPリソースを発表します。
- drops the TCP connection,
- TCP接続を落とします。
- increments the ConnectRetryCounter by 1,
- ConnectRetryCounterを1つ増加します。
- changes its state to Idle.
- 状態をIdleに変えます。
Sangli, et al. Standards Track [Page 10] RFC 4724 Graceful Restart Mechanism for BGP January 2007
サーングリ、他 規格は2007年1月にBGPのためにRFC4724の優雅な再開メカニズムを追跡します[10ページ]。
with
with
If the local system receives a NOTIFICATION message (Event 24 or
Event 25), or if the local system receives a TcpConnectionFails
(Event 18) from the underlying TCP and the Graceful Restart
capability with one or more AFIs/SAFIs has not been received for
the session, the local system:
ローカルシステムは基本的なTCPからTcpConnectionFails(出来事18)を受けるかどうか、そして、AFIs/SAFIsにはセッション、ローカルシステムにおいて、受け取られていていない1つか以上があるローカルシステムはNOTIFICATIONメッセージ(出来事24かEvent25)を受け取るか、そして、Graceful Restart能力:
- sets the ConnectRetryTimer to zero,
- ゼロにConnectRetryTimerを設定します。
- deletes all routes associated with this connection,
- この接続に関連しているすべてのルートを削除します。
- releases all the BGP resources,
- すべてのBGPリソースを発表します。
- drops the TCP connection,
- TCP接続を落とします。
- increments the ConnectRetryCounter by 1, and
- そしてConnectRetryCounterを1つ増加する。
- changes its state to Idle.
- 状態をIdleに変えます。
However, if the local system receives a TcpConnectionFails (Event
18) from the underlying TCP, and the Graceful Restart Capability
with one or more AFIs/SAFIs has been received for the session, the
local system:
しかしながら、ローカルシステムがTcpConnectionFailsを受けるなら、セッションのために基本的なTCP、および1AFIs/SAFIsとGraceful Restart Capabilityからの(出来事18)を受け取りました、ローカルシステム:
- sets the ConnectRetryTimer to zero,
- ゼロにConnectRetryTimerを設定します。
- retains all routes associated with this connection according
to section "Procedures for the Receiving Speaker" of this
(Graceful Restart) specification,
- 「受信議長のための手順」というこの(優雅なRestart)仕様のセクションによると、この接続に関連しているすべてのルートを保有します。
- releases all other BGP resources,
- 他のすべてのBGPリソースを発表します。
- drops the TCP connection,
- TCP接続を落とします。
- increments the ConnectRetryCounter by 1, and
- そしてConnectRetryCounterを1つ増加する。
- changes its state to Idle.
- 状態をIdleに変えます。
6. Deployment Considerations
6. 展開問題
Although the procedures described in this document would help minimize the effect of routing flaps, it is noted that when a BGP Graceful Restart-capable router restarts, or if it restarts without preserving its forwarding state (e.g., due to a power failure), there is a potential for transient routing loops or blackholes in the network if routing information changes before the involved routers complete routing updates and convergence. Also, depending on the
本書では説明された手順は、ルーティングフラップの効果を最小にするのを助けるでしょうが、かかわったルータがルーティングアップデートと集合を終了する前に情報変化を発送するなら、BGP Graceful Restartできるルータが再開するとき、推進状態(例えば、停電による)を保持しないで再開するなら、ネットワークには一時的なルーティングの輪かblackholesの可能性があることに注意されます。 依存、もオン
Sangli, et al. Standards Track [Page 11] RFC 4724 Graceful Restart Mechanism for BGP January 2007
サーングリ、他 規格は2007年1月にBGPのためにRFC4724の優雅な再開メカニズムを追跡します[11ページ]。
network topology, if not all IBGP speakers are Graceful Restart capable, there could be an increased exposure to transient routing loops or blackholes when the Graceful Restart procedures are exercised.
ネットワーク形態、まして、すべてのIBGPスピーカーができるGraceful Restartである、Graceful Restart手順が運動させられるとき、一時的なルーティングの輪かblackholesへの増加する露出があるかもしれません。
The Restart Time, the upper bound for retaining routes, and the upper bound for deferring route selection may need to be tuned as more deployment experience is gained.
Restart Time、ルートを保有するための上限、およびルート選択を延期するための上限は、より多くの展開経験をするのに従って調整される必要があるかもしれません。
Finally, it is noted that the benefits of deploying BGP Graceful Restart in an Autonomous System (AS) whose IGPs and BGP are tightly coupled (i.e., BGP and IGPs would both restart) and IGPs have no similar Graceful Restart Capability are reduced relative to the scenario where IGPs do have similar Graceful Restart Capability.
最終的に、IGPsとBGPによる密結合(すなわち、BGPとIGPsはともに再開する)とIGPsにはどんな同様のGraceful Restart CapabilityもないということであるAutonomous System(AS)でBGP Graceful Restartを配備する利益がIGPsが同様のGraceful Restart Capabilityを持っているシナリオに比例して下げられることに注意されます。
7. Security Considerations
7. セキュリティ問題
Since with this proposal a new connection can cause an old one to be terminated, it might seem to open the door to denial of service attacks. However, it is noted that unauthenticated BGP is already known to be vulnerable to denials of service through attacks on the TCP transport. The TCP transport is commonly protected through use of [BGP-AUTH]. Such authentication will equally protect against denials of service through spurious new connections.
新しい接続がこの提案で古いものを終えさせることができるので、それはサービス不能攻撃を可能にするように思えるかもしれません。 しかしながら、unauthenticated BGPがTCP輸送に対する攻撃によるサービスの否定に傷つきやすいのが既に知られることに注意されます。 TCP輸送は[BGP-AUTH]の使用で一般的に保護されます。 そのような認証は等しく偽りの新しい接続によるサービスの否定から守るでしょう。
If an attacker is able to successfully open a TCP connection impersonating a legitimate peer, the attacker's connection will replace the legitimate one, potentially enabling the attacker to advertise bogus routes. We note, however, that the window for such a route insertion attack is small since through normal operation of the protocol the legitimate peer would open a new connection, in turn causing the attacker's connection to be terminated. Thus, this attack devolves to a form of denial of service.
攻撃者が首尾よく正統の同輩をまねるTCP接続を開くことができると、攻撃者の接続は正統のものに取って代わるでしょう、攻撃者がにせのルートの広告を出すのを潜在的に可能にして。 しかしながら、私たちは、正統の同輩がプロトコルの通常の操作で新しい接続を開くでしょう、したがって、そのようなルート挿入攻撃のための窓が小さいことに注意します、攻撃者の接続が終えられることを順番に引き起こして。 したがって、この攻撃はサービスの否定のフォームへ譲り渡されます。
It is thus concluded that this proposal does not change the underlying security model (and issues) of BGP-4.
この提案がBGP-4の基本的な機密保護モデル(そして、問題)を変えないとこのようにして結論づけられます。
We also note that implementations may allow use of graceful restart to be controlled by configuration. If graceful restart is not enabled, naturally the underlying security model of BGP-4 is unchanged.
また、私たちは、実現が、優雅な再開の使用が構成によって制御されるのを許容するかもしれないことに注意します。 優雅な再開が可能にされないなら、当然、BGP-4の基本的な機密保護モデルは変わりがありません。
Sangli, et al. Standards Track [Page 12] RFC 4724 Graceful Restart Mechanism for BGP January 2007
サーングリ、他 規格は2007年1月にBGPのためにRFC4724の優雅な再開メカニズムを追跡します[12ページ]。
8. Acknowledgments
8. 承認
The authors would like to thank Bruce Cole, Lars Eggert, Bill Fenner, Eric Gray, Jeffrey Haas, Sam Hartman, Alvaro Retana, Pekka Savola Naiming Shen, Satinder Singh, Mark Townsley, David Ward, Shane Wright, and Alex Zinin for their review and comments.
作者は彼らのレビューとコメントについてマークTownsley、デヴィッド・ウォード・ブルース・コール、ラース・エッゲルト、ビル・フェナー、エリック・グレー、ジェフリー・ハース、サム・ハートマン、アルバロ・レタナ、ペッカ・Savola Naimingシン、Satinderシン、シェーン・ライト、およびアレックス・ジニンに感謝したがっています。
9. IANA Considerations
9. IANA問題
This document defines a new BGP capability - Graceful Restart Capability. The Capability Code for Graceful Restart Capability is 64.
このドキュメントは新しいBGP能力を定義します--優雅なRestart Capability。 Graceful Restart CapabilityのためのCapability Codeは64歳です。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[BGP-4] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[BGP-4]Rekhter、Y.、李、T.、およびS.野兎、「ボーダ・ゲイトウェイ・プロトコル4(BGP-4)」、RFC4271 2006年1月。
[BGP-MP] Bates, T., Rekhter, Y., Chandra, R., and D. Katz,
"Multiprotocol Extensions for BGP-4", RFC 2858, June
2000.
[BGP-MP]ベイツ、T.、Rekhter、Y.、チャンドラ、R.、およびD.キャッツ、「BGP-4インチのためのMultiprotocol拡張子、RFC2858、2000年6月。」
[BGP-CAP] Chandra, R. and J. Scudder, "Capabilities Advertisement
with BGP-4", RFC 3392, November 2002.
[BGP-キャップ] チャンドラとR.とJ.Scudder、「BGP-4インチがある能力広告、RFC3392、2002年11月。」
[BGP-AUTH] Heffernan, A., "Protection of BGP Sessions via the TCP
MD5 Signature Option", RFC 2385, August 1998.
[BGP-AUTH] ヘファーナン、A.、「TCP MD5 Signature Optionを通したBGPセッションズの保護」、RFC2385、1998年8月。
[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月。
[IANA-AFI] http://www.iana.org/assignments/address-family-numbers
[IANA-AFI] http://www.iana.org/assignments/address-family-numbers
[IANA-SAFI] http://www.iana.org/assignments/safi-namespace
[IANA-サフィ] http://www.iana.org/assignments/safi-namespace
10.2. Informative References
10.2. 有益な参照
[BFD] Katz, D. and D. Ward, "Bidirectional Forwarding
Detection", Work in Progress.
[BFD] 「双方向の推進検出」というキャッツ、D.、およびD.区は進行中で働いています。
Sangli, et al. Standards Track [Page 13] RFC 4724 Graceful Restart Mechanism for BGP January 2007
サーングリ、他 規格は2007年1月にBGPのためにRFC4724の優雅な再開メカニズムを追跡します[13ページ]。
Authors' Addresses
作者のアドレス
Srihari R. Sangli Cisco Systems, Inc.
Srihari R.サーングリシスコシステムズInc.
EMail: rsrihari@cisco.com
メール: rsrihari@cisco.com
Yakov Rekhter Juniper Networks, Inc.
ヤコフRekhter JuniperはInc.をネットワークでつなぎます。
EMail: yakov@juniper.net
メール: yakov@juniper.net
Rex Fernando Juniper Networks, Inc.
レックスフェルナンドJuniperはInc.をネットワークでつなぎます。
EMail: rex@juniper.net
メール: rex@juniper.net
John G. Scudder Juniper Networks, Inc.
ジョンG.Scudder杜松はInc.をネットワークでつなぎます。
EMail: jgs@juniper.net
メール: jgs@juniper.net
Enke Chen Cisco Systems, Inc.
EnkeチェンシスコシステムズInc.
EMail: enkechen@cisco.com
メール: enkechen@cisco.com
Sangli, et al. Standards Track [Page 14] RFC 4724 Graceful Restart Mechanism for BGP January 2007
サーングリ、他 規格は2007年1月にBGPのためにRFC4724の優雅な再開メカニズムを追跡します[14ページ]。
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機能のための基金は現在、インターネット協会によって提供されます。
Sangli, et al. Standards Track [Page 15]
サーングリ、他 標準化過程[15ページ]
一覧
スポンサーリンク
