RFC3618 日本語訳
3618 Multicast Source Discovery Protocol (MSDP). B. Fenner, Ed., D.Meyer, Ed.. October 2003. (Format: TXT=42238 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group B. Fenner, Ed. Request for Comments: 3618 D. Meyer, Ed. Category: Experimental October 2003
ワーキンググループのB.フェナー、エドをネットワークでつないでください。コメントのために以下を要求してください。 3618 エドD.マイヤー、カテゴリ: 実験的な2003年10月
Multicast Source Discovery Protocol (MSDP)
マルチキャストソース発見プロトコル(MSDP)
Status of this Memo
このMemoの状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
Abstract
要約
The Multicast Source Discovery Protocol (MSDP) describes a mechanism to connect multiple IP Version 4 Protocol Independent Multicast Sparse-Mode (PIM-SM) domains together. Each PIM-SM domain uses its own independent Rendezvous Point (RP) and does not have to depend on RPs in other domains. This document reflects existing MSDP implementations.
Multicast Sourceディスカバリープロトコル(MSDP)は、複数のIPバージョン4プロトコル無党派Multicast Sparse-モード(PIM-SM)ドメインを一緒につなげるためにメカニズムについて説明します。 それぞれのPIM-SMドメインは、それ自身の独立しているRendezvous Point(RP)を使用して、他のドメインのRPsによる必要はありません。 このドキュメントは既存のMSDP実現を反映します。
Table of Contents
目次
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Timers. . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5.1. SA-Advertisement-Timer . . . . . . . . . . . . . . . . . 5
5.2. SA-Advertisement-Timer Processing. . . . . . . . . . . . 5
5.3. SA Cache Timeout (SA-State Timer). . . . . . . . . . . . 5
5.4. Peer Hold Timer. . . . . . . . . . . . . . . . . . . . . 5
5.5. KeepAlive Timer. . . . . . . . . . . . . . . . . . . . . 6
5.6. ConnectRetry Timer . . . . . . . . . . . . . . . . . . . 6
6. Intermediate MSDP Peers . . . . . . . . . . . . . . . . . . . 6
7. SA Filtering and Policy . . . . . . . . . . . . . . . . . . . 6
8. Encapsulated Data Packets . . . . . . . . . . . . . . . . . . 7
9. Other Scenarios . . . . . . . . . . . . . . . . . . . . . . . 7
10. MSDP Peer-RPF Forwarding. . . . . . . . . . . . . . . . . . . 7
10.1. Definitions . . . . . . . . . . . . . . . . . . . . . . 7
10.1.1. Multicast RPF Routing Information Base. . . . . 8
10.1.2. Peer-RPF Route. . . . . . . . . . . . . . . . . 8
1. 序論。 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. 概観。 . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. 手順. . . . . . . . . . . . . . . . . . . . . . . . . . 3 4。 .4 5をキャッシュします。 タイマ。 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5.1. SA広告タイマ.55.2。 SA広告タイマ処理。 . . . . . . . . . . . 5 5.3. SAはタイムアウト(SA-州のタイマ)をキャッシュします。 . . . . . . . . . . . 5 5.4. 同輩保持タイマ。 . . . . . . . . . . . . . . . . . . . . 5 5.5. KeepAliveタイマ。 . . . . . . . . . . . . . . . . . . . . 6 5.6. ConnectRetryタイマ. . . . . . . . . . . . . . . . . . . 6 6。 中間的MSDPは.6 7にじっと見ます。 SAフィルタリングと方針. . . . . . . . . . . . . . . . . . . 6 8。 データ・パケット. . . . . . . . . . . . . . . . . . 7 9をカプセルに入れりました。 他のシナリオ. . . . . . . . . . . . . . . . . . . . . . . 7 10。 MSDP同輩-RPF推進。 . . . . . . . . . . . . . . . . . . 7 10.1. 定義. . . . . . . . . . . . . . . . . . . . . . 7 10.1.1。 マルチキャストRPF経路情報基地。 . . . . 8 10.1.2. 同輩-RPFルート。 . . . . . . . . . . . . . . . . 8
Fenner & Meyer Experimental [Page 1] RFC 3618 MSDP October 2003
[1ページ]RFC3618MSDP2003年10月に実験的なフェナーとマイヤー
10.1.3. Peer-RPF Forwarding Rules . . . . . . . . . . . 8
10.2. MSDP mesh-group semantics . . . . . . . . . . . . . . . 9
11. MSDP Connection State Machine . . . . . . . . . . . . . . . . 9
11.1. Events. . . . . . . . . . . . . . . . . . . . . . . . . 10
11.2. Actions . . . . . . . . . . . . . . . . . . . . . . . . 10
11.3. Peer-specific Events. . . . . . . . . . . . . . . . . . 11
11.4. Peer-independent Events . . . . . . . . . . . . . . . . 11
12. Packet Formats. . . . . . . . . . . . . . . . . . . . . . . . 12
12.1. MSDP TLV format . . . . . . . . . . . . . . . . . . . . 12
12.2. Defined TLVs. . . . . . . . . . . . . . . . . . . . . . 12
12.2.1. IPv4 Source-Active TLV. . . . . . . . . . . . . 13
12.2.2. KeepAlive TLV . . . . . . . . . . . . . . . . . 14
13. MSDP Error Handling . . . . . . . . . . . . . . . . . . . . . 15
14. SA Data Encapsulation . . . . . . . . . . . . . . . . . . . . 15
15. Applicability Statement . . . . . . . . . . . . . . . . . . . 15
15.1. Between PIM Domains . . . . . . . . . . . . . . . . . . 15
15.2. Between Anycast-RPs . . . . . . . . . . . . . . . . . . 15
16. Intellectual Property . . . . . . . . . . . . . . . . . . . . 15
17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
18. Security Considerations . . . . . . . . . . . . . . . . . . . 16
19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
19.1. Allocated TLV Range . . . . . . . . . . . . . . . . . . 17
19.2. Experimental TLV Range. . . . . . . . . . . . . . . . . 17
20. References. . . . . . . . . . . . . . . . . . . . . . . . . . 17
20.1. Normative References. . . . . . . . . . . . . . . . . . 17
20.2. Informative References. . . . . . . . . . . . . . . . . 18
21. Editors' Addresses. . . . . . . . . . . . . . . . . . . . . . 18
22. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 19
10.1.3. 同輩-RPF推進は.810.2を統治します。 MSDPメッシュグループ意味論. . . . . . . . . . . . . . . 9 11。 MSDP接続州のマシン. . . . . . . . . . . . . . . . 9 11.1。 出来事。 . . . . . . . . . . . . . . . . . . . . . . . . 10 11.2. 動作. . . . . . . . . . . . . . . . . . . . . . . . 10 11.3。 同輩特有の出来事。 . . . . . . . . . . . . . . . . . 11 11.4. 同輩から独立しているイベント.11 12。 パケット・フォーマット。 . . . . . . . . . . . . . . . . . . . . . . . 12 12.1. MSDP TLVは.12 12.2をフォーマットします。 TLVsを定義しました。 . . . . . . . . . . . . . . . . . . . . . 12 12.2.1. IPv4のソースアクティブなTLV。 . . . . . . . . . . . . 13 12.2.2. KeepAlive TLV. . . . . . . . . . . . . . . . . 14 13。 MSDPエラー処理. . . . . . . . . . . . . . . . . . . . . 15 14。 SAデータカプセル化. . . . . . . . . . . . . . . . . . . . 15 15。 適用性証明. . . . . . . . . . . . . . . . . . . 15 15.1。 PIMドメイン. . . . . . . . . . . . . . . . . . 15 15.2の間で。 Anycast-RPs. . . . . . . . . . . . . . . . . . 15 16の間で。 知的所有権. . . . . . . . . . . . . . . . . . . . 15 17。 承認. . . . . . . . . . . . . . . . . . . . . . . 16 18。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 16 19。 IANA問題. . . . . . . . . . . . . . . . . . . . . 17 19.1。 割り当てられたTLVは.17 19.2に及びます。 実験的なTLVは及びます。 . . . . . . . . . . . . . . . . 17 20. 参照。 . . . . . . . . . . . . . . . . . . . . . . . . . 17 20.1. 引用規格。 . . . . . . . . . . . . . . . . . 17 20.2. 有益な参照。 . . . . . . . . . . . . . . . . 18 21. エディタのアドレス。 . . . . . . . . . . . . . . . . . . . . . 18 22. 完全な著作権宣言文。 . . . . . . . . . . . . . . . . . . 19
1. Introduction
1. 序論
The Multicast Source Discovery Protocol (MSDP) describes a mechanism to connect multiple PIM Sparse-Mode (PIM-SM) [RFC2362] domains together. Each PIM-SM domain uses its own independent RP(s) and does not have to depend on RPs in other domains. Advantages of this approach include:
Multicast Sourceディスカバリープロトコル(MSDP)は、複数のPIM Sparse-モード(PIM-SM)[RFC2362]ドメインを一緒につなげるためにメカニズムについて説明します。 それぞれのPIM-SMドメインは、それ自身の独立しているRP(s)を使用して、他のドメインのRPsによる必要はありません。 このアプローチの利点は:
o No Third-party resource dependencies on a domain's RP
o ドメインのRPにおけるThird-パーティーリソースの依存関係がありません。
PIM-SM domains can rely on their own RPs only.
PIM-SMドメインはそれら自身のRPsしか当てにすることができません。
o Receiver only Domains
o 受信機Domainsだけ
Domains with only receivers get data without globally advertising
group membership.
グローバルにグループ会員資格の広告を出さないで、受信機だけがあるドメインはデータを得ます。
Note that MSDP may be used with protocols other than PIM-SM, but such usage is not specified in this memo.
MSDPがPIM-SM以外のプロトコルと共に使用されるかもしれませんが、そのような用法がこのメモで指定されないことに注意してください。
Fenner & Meyer Experimental [Page 2] RFC 3618 MSDP October 2003
[2ページ]RFC3618MSDP2003年10月に実験的なフェナーとマイヤー
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 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
2. Overview
2. 概観
MSDP-speaking routers in a PIM-SM domain have a MSDP peering relationship with MSDP peers in another domain. The peering relationship is made up of a TCP connection in which control information is exchanged. Each domain has one or more connections to this virtual topology.
PIM-SMドメインのMSDP-話しルータは別のドメインにMSDP同輩とのMSDPじっと見る関係を持っています。 じっと見る関係は制御情報が交換されるTCP接続で作られます。 各ドメインには、この仮想のトポロジーには1つ以上の接続があります。
The purpose of this topology is to allow domains to discover multicast sources from other domains. If the multicast sources are of interest to a domain which has receivers, the normal source-tree building mechanism in PIM-SM will be used to deliver multicast data over an inter-domain distribution tree.
このトポロジーの目的はドメインが他のドメインからマルチキャストソースを発見するのを許容することです。 マルチキャストソースが受信機を持っているドメインに興味深いなら、PIM-SMの正常なソース木のビルメカニズムは、相互ドメイン分配木の上にマルチキャストデータを送るのに使用されるでしょう。
3. Procedure
3. 手順
When an RP in a PIM-SM domain first learns of a new sender, e.g., via PIM register messages, it constructs a "Source-Active" (SA) message and sends it to its MSDP peers. All RPs, which intend to originate or receive SA messages, must establish MSDP peering with other RPs, either directly or via an intermediate MSDP peer. The SA message contains the following fields:
PIM-SMドメインのRPが最初に例えば、PIMレジスタメッセージで新しい送付者を知っているとき、それは、「ソースアクティブである」(SA)メッセージを構成して、MSDP同輩にそれを送ります。 すべてのRPs(SAメッセージを溯源するつもりであるか、または受け取るつもりである)が他のRPsか直接か中間的MSDP同輩を通してじっと見るMSDPを設立しなければなりません。 SAメッセージは以下の分野を含んでいます:
o Source address of the data source.
o データ送信端末のソースアドレス。
o Group address the data source sends to.
o データ送信端末が発信するアドレスを分類してください。
o IP address of the RP.
o RPのIPアドレス。
Note that an RP that isn't a DR on a shared network SHOULD NOT originate SA's for directly connected sources on that shared network; it should only originate in response to receiving Register messages from the DR.
共有されたネットワークSHOULD NOTの上のDRでないRPがその共用回線網の直接接続されたソースにSAのものを溯源することに注意してください。 DRからRegisterメッセージを受け取ることに対応してそれは由来するだけであるべきです。
Each MSDP peer receives and forwards the message away from the RP address in a "peer-RPF flooding" fashion. The notion of peer-RPF flooding is with respect to forwarding SA messages. The Multicast RPF Routing Information Base (MRIB) is examined to determine which peer towards the originating RP of the SA message is selected. Such a peer is called an "RPF peer". See section 13 for the details of peer-RPF forwarding.
それぞれのMSDP同輩は、「同輩-RPF氾濫」ファッションでRPアドレスから遠くにメッセージを受け取って、転送します。 推進SAメッセージに関して同輩-RPF氾濫の概念があります。 Multicast RPF経路情報基地(MRIB)は、SAメッセージの由来しているRPに向かったどの同輩が選ばれるかを決定するために調べられます。 そのような同輩は「RPF同輩」と呼ばれます。 同輩-RPF推進の詳細に関してセクション13を見てください。
Fenner & Meyer Experimental [Page 3] RFC 3618 MSDP October 2003
[3ページ]RFC3618MSDP2003年10月に実験的なフェナーとマイヤー
If the MSDP peer receives the SA from a non-RPF peer towards the originating RP, it will drop the message. Otherwise, it forwards the message to all its MSDP peers (except the one from which it received the SA message).
MSDP同輩が非RPF同輩からSAを由来しているRPに向かって受け取ると、それはメッセージを落とすでしょう。 さもなければ、それはすべてのMSDP同輩(それがSAメッセージを受け取ったものを除いた)にメッセージを転送します。
When an MSDP peer which is also an RP for its own domain receives a new SA message, it determines if there are any group members within the domain interested in any group described by an (Source, Group), or (S,G) entry within the SA message. That is, the RP checks for a (*,G) entry with a non-empty outgoing interface list; this implies that some system in the domain is interested in the group. In this case, the RP triggers a (S,G) join event towards the data source as if a Join/Prune message was received addressed to the RP itself. This sets up a branch of the source-tree to this domain. Subsequent data packets arrive at the RP via this tree branch, and are forwarded down the shared-tree inside the domain. If leaf routers choose to join the source-tree they have the option to do so according to existing PIM-SM conventions. Finally, if an RP in a domain receives a PIM Join message for a new group G, the RP SHOULD trigger a (S,G) join event for each active (S,G) for that group in its SA cache.
MSDP同輩であるときに、また、どれがそれ自身のドメインへのRPであるかは新しいSAメッセージを受け取って、それは、何かグループのメンバーがSAメッセージの中で何か(ソース、Group)によって説明されたグループ、または(S、G)エントリーに興味を持っていたドメインの中にいるかを決定します。 すなわち、RPは(*、G)エントリーがないかどうか非空の送信するインタフェースリストに問い合わせます。 これは、そのドメインの何らかのシステムがグループに興味を持っているのを含意します。 この場合、RP引き金のa(S、G)はまるでRP自身に記述されていた状態でJoin/プルーンのメッセージを受け取るかのようにデータ送信端末に向かって出来事を接合します。 これはソース木の支店をこのドメインに開設します。 順次データパケットはこの木の枝を通してRPに到着して、ドメインの中で共有された木の下側に送ります。 葉のルータが、ソース木に合流するのを選ぶなら、それらには、既存のPIM-SMコンベンションによると、そうするオプションがあります。 最終的に、ドメインのRPが新しいグループへのPIM Joinメッセージを受け取るなら、G、RP SHOULDの、よりこぎれいなa(S、G)はそのグループのための各能動態(S、G)のためにSAキャッシュに出来事を接合します。
This procedure has been affectionately named flood-and-join because if any RP is not interested in the group, they can ignore the SA message. Otherwise, they join a distribution tree.
この手順は愛情を込めてRPが少しのグループに関心がないなら、彼らがSAメッセージを無視できるので、浸水して、接合していた状態で命名されました。 さもなければ、彼らは分配木に合流します。
4. Caching
4. キャッシュ
A MSDP speaker MUST cache SA messages. Caching allows pacing of MSDP messages as well as reducing join latency for new receivers of a group G at an originating RP which has existing MSDP (S,G) state. In addition, caching greatly aids in diagnosis and debugging of various problems.
MSDPスピーカーはSAメッセージをキャッシュしなければなりません。 キャッシュで、MSDPメッセージを減少がグループGの新しい受信機のためにMSDP(S、G)が述べる存在を持っている由来しているRPで潜在を接合するのと同じくらいよく歩き回らせます。 さらに、キャッシュは様々な問題の診断とデバッグで大いに支援されます。
An MSDP speaker must provide a mechanism to reduce the forwarding of new SA's. The SA-cache is used to reduce storms and performs this by not forwarding SA's unless they are in the cache or are new SA packets that the MSDP speaker will cache for the first time. The SA-cache also reduces storms by advertising from the cache at a period of no more than twice per SA-Advertisement-Timer interval and not less than 1 time per SA Advertisement period.
MSDPスピーカーは、新しいSAのものの推進を抑えるためにメカニズムを提供しなければなりません。 SA-キャッシュは、それらがキャッシュにはあるか、MSDPスピーカーが初めてキャッシュする新しいSAパケットでないなら嵐を減少させるのに使用されて、SAを進めないことによって、これを実行します。 また、二度未満の期間のSA広告タイマ間隔あたりのキャッシュと少なくとも1SA Advertisementあたり1回から以上は広告を出すことによって、SA-キャッシュが嵐を減少させます。
5. Timers
5. タイマ
The main timers for MSDP are: SA-Advertisement-Timer, SA Cache Entry timer, Peer Hold Timer, KeepAlive timer, and ConnectRetry timer. Each is considered below.
MSDPに、メインなタイマは以下の通りです。 SA広告タイマ、SA Cache Entryタイマ、Peer Hold Timer、KeepAliveタイマ、およびConnectRetryタイマ。 それぞれが以下で考えられます。
Fenner & Meyer Experimental [Page 4] RFC 3618 MSDP October 2003
[4ページ]RFC3618MSDP2003年10月に実験的なフェナーとマイヤー
5.1. SA-Advertisement-Timer
5.1. SA広告タイマ
RPs which originate SA messages do so periodically as long as there is data being sent by the source. There is one SA-Advertisement- Timer covering the sources that an RP may advertise. [SA- Advertisement-Period] MUST be 60 seconds. An RP MUST not send more than one periodic SA message for a given (S,G) within an SA Advertisement interval. Originating periodic SA messages is required to keep announcements alive in caches. Finally, an originating RP SHOULD trigger the transmission of an SA message as soon as it receives data from an internal source for the first time. This initial SA message may be in addition to the periodic sa-message forwarded in that first 60 seconds for that (S,G).
ソースによって送られるデータがある限り、SAメッセージを溯源するRPsがあまりに定期的にします。 RPが広告を出すかもしれないソースをカバーする1個のSA-広告タイマがあります。 [SA広告期間]は60秒でなければなりません。 RP MUSTはSA Advertisement間隔以内に当然のことへの1つ以上の周期的なSAメッセージ(S、G)を送りません。 周期的なSAメッセージを溯源するのが、キャッシュで発表を生かすのに必要です。 最終的に、初めて内部のソースからデータを受け取るとすぐに、由来しているRP SHOULDはSAメッセージの伝達の引き金となります。 この初期のSAメッセージは60秒の最初にそれで転送された周期的なsa-メッセージに加えたそれ(S、G)のためのものであるかもしれません。
5.2. SA-Advertisement-Timer Processing
5.2. SA広告タイマ処理
An RP MUST spread the generation of periodic SA messages (i.e., messages advertising the active sources for which it is the RP) over its reporting interval (i.e., SA-Advertisement-Period). An RP starts the SA-Advertisement-Timer when the MSDP process is configured. When the timer expires, an RP resets the timer to [SA-Advertisement- Period] seconds, and begins the advertisement of its active sources. Active sources are advertised in the following manner: An RP packs its active sources into an SA message until the largest MSDP packet that can be sent is built or there are no more sources, and then sends the message. This process is repeated periodically within the SA-Advertisement-Period in such a way that all of the RP's sources are advertised. Note that since MSDP is a periodic protocol, an implementation SHOULD send all cached SA messages when a connection is established. Finally, the timer is deleted when the MSDP process is de-configured.
RP MUSTは周期的なSAメッセージ(すなわち、それがRPである活発なソースの広告を出すメッセージ)の世代を報告間隔(すなわち、SA広告の期間)の上に広げます。 MSDPの過程が構成されるとき、RPはSA広告タイマを始動します。 タイマが期限が切れると、RPは[SA-広告期間]秒までタイマをリセットして、活発なソースの広告を始めます。 以下の方法で活発なソースの広告を出します: RPは送ることができる中で最も大きいMSDPパケットが組立しているか、またはそれ以上のソースが全くないまで活発なソースにSAメッセージに詰め込んで、次に、メッセージを送ります。 この過程はSA広告の期間中に定期的にRPのソースのすべての広告を出すような方法で繰り返されます。 MSDPが周期的なプロトコル(接続が確立されるときSHOULDがすべてのキャッシュされたSAメッセージを送る実現)であるので、それに注意してください。 反-MSDPの過程構成されるときに、最終的に、タイマは削除されます。
5.3. SA Cache Timeout (SA-State Timer)
5.3. SAキャッシュタイムアウト(SA-州のタイマ)
Each entry in an SA Cache has an associated SA-State Timer. A (S,G)-SA-State-Timer is started when an (S,G)-SA message is initially received by an MSDP peer. The timer is reset to [SG-State-Period] if another (S,G)-SA message is received before the (S,G)-SA-State Timer expires. [SG-State-Period] MUST NOT be less than [SA-Advertisement- Period] + [SA-Hold-Down-Period].
SA Cacheの各エントリーには、関連SA-州のTimerがあります。 (S、G)-SAメッセージが初めはMSDP同輩によって受け取られるとき、A(S、G)SA-州タイマは始動されます。 以前別の(S、G)-SAメッセージを受け取るなら[SG州の期間]までタイマをリセットする、(S、G) -SA-州のTimerは期限が切れます。 [SG州の期間]は[SA-広告期間]+[SAは期間を押さえます]より少ないはずがありません。
5.4. Peer Hold Timer
5.4. 同輩保持タイマ
The Hold Timer is initialized to [HoldTime-Period] when the peer's transport connection is established, and is reset to [HoldTime- Period] when any MSDP message is received. Finally, the timer is
Hold Timerは同輩の輸送接続が確立される[HoldTime-期間]まで初期化されて、どんなMSDPメッセージも受信されている[HoldTimeの期間]までリセットされます。 最終的に、タイマはそうです。
Fenner & Meyer Experimental [Page 5] RFC 3618 MSDP October 2003
[5ページ]RFC3618MSDP2003年10月に実験的なフェナーとマイヤー
deleted when the peer's transport connection is closed. [HoldTime- Period] MUST be at least three seconds. The recommended value for [HoldTime-Period] is 75 seconds.
同輩の輸送接続が閉じられるとき、削除されます。 [HoldTimeの期間]は少なくとも3秒でなければなりません。 [HoldTime-期間]のための推奨値は75秒です。
5.5. KeepAlive Timer
5.5. KeepAliveタイマ
Once an MSDP transport connection is established, each side of the connection sends a KeepAlive message and sets a KeepAlive timer. If the KeepAlive timer expires, the local system sends a KeepAlive message and restarts its KeepAlive timer.
MSDP輸送接続がいったん確立されると、接続の各側面は、KeepAliveメッセージを送って、KeepAliveタイマを設定します。 KeepAliveタイマが期限が切れるなら、ローカルシステムは、KeepAliveメッセージを送って、KeepAliveタイマを再開します。
The KeepAlive timer is set to [KeepAlive-Period] when the peer comes up. The timer is reset to [KeepAlive-Period] each time an MSDP message is sent to the peer, and reset when the timer expires.
KeepAliveタイマは同輩が来る[KeepAlive-期間]に設定されます。 タイマが期限が切れるとき、タイマは、MSDPメッセージを同輩に送るたびに[KeepAlive-期間]までリセットされて、リセットされます。
Finally, the KeepAlive timer is deleted when the peer's transport connection is closed.
同輩の輸送接続が閉じられるとき、最終的に、KeepAliveタイマは削除されます。
[KeepAlive-Period] MUST be less than [HoldTime-Period], and MUST be at least one second. The recommended value for [KeepAlive-Period] is 60 seconds.
[KeepAlive-期間]は、[HoldTime-期間]より少なくなければならなく、少なくとも1秒でなければなりません。 [KeepAlive-期間]のための推奨値は60秒です。
5.6. ConnectRetry Timer
5.6. ConnectRetryタイマ
The ConnectRetry timer is used by the MSDP peer with the lower IP address to transition from INACTIVE to CONNECTING states. There is one timer per peer, and the [ConnectRetry-Period] SHOULD be set to 30 seconds. The timer is initialized to [ConnectRetry-Period] when an MSDP speaker attempts to actively open a TCP connection to its peer (see section 15, event E2, action A2 ). When the timer expires, the peer retries the connection and the timer is reset to [ConnectRetry- Period]. It is deleted if either the connection transitions into ESTABLISHED state or the peer is de-configured.
ConnectRetryタイマは低いIPアドレスでMSDP同輩によってINACTIVEからCONNECTING州までの変遷に使用されます。 そこに、ワンタイマーが30へのセットが秒であったなら同輩、および[ConnectRetry-期間]SHOULD単位でありますか? タイマはMSDPスピーカーが活発にTCP接続を同輩に公開するのを試みる(セクション15を見てください、出来事E2、動作A2)[ConnectRetry-期間]まで初期化されます。 タイマが期限が切れると、同輩は接続を再試行します、そして、タイマは[ConnectRetryの期間]までリセットされます。 反-ESTABLISHEDへの変遷が述べる接続か同輩のどちらか構成されるなら、それは削除されます。
6. Intermediate MSDP Peers
6. 中間的MSDP同輩
Intermediate MSDP speakers do not originate periodic SA messages on behalf of sources in other domains. In general, an RP MUST only originate an SA for a source which would register to it, and ONLY RPs may originate SA messages. Intermediate MSDP speakers MAY forward SA messages received from other domains.
中間的MSDPスピーカーは他のドメインのソースを代表して周期的なSAメッセージを溯源しません。 一般に、RP MUSTはそれに登録するソースにSAを溯源するだけです、そして、RPsだけがSAメッセージを溯源するかもしれません。 中間的MSDPスピーカーは他のドメインから受け取られたメッセージをSAに転送するかもしれません。
7. SA Filtering and Policy
7. SAフィルタリングと方針
As the number of (S,G) pairs increases in the Internet, an RP may want to filter which sources it describes in SA messages. Also, filtering may be used as a matter of policy which at the same time can reduce state. MSDP peers in transit domains should not filter SA
(S、G)組の数がインターネットを増やすので、RPはそれがSAメッセージで説明するどのソースをフィルターにかけたがっているかもしれないか。 また、同時に状態を減少させることができるフィルタリングは政策の問題として使用されるかもしれません。 トランジットドメインのMSDP同輩はSAをフィルターにかけるべきではありません。
Fenner & Meyer Experimental [Page 6] RFC 3618 MSDP October 2003
[6ページ]RFC3618MSDP2003年10月に実験的なフェナーとマイヤー
messages or the flood-and-join model can not guarantee that sources will be known throughout the Internet (i.e., SA filtering by transit domains may cause undesired lack of connectivity). In general, policy should be expressed using MBGP [RFC2858]. This will cause MSDP messages to flow in the desired direction and peer-RPF fail otherwise. An exception occurs at an administrative scope [RFC2365] boundary. In particular, a SA message for a (S,G) MUST NOT be sent to peers which are on the other side of an administrative scope boundary for G.
メッセージか浸水している、接合しているモデルが、ソースがインターネット中で知られているのを保証できません(すなわち、トランジットドメインのそばのSAフィルタリングは接続性の望まれない不足を引き起こすかもしれません)。 一般に、方針は、MBGP[RFC2858]を使用することで言い表されるべきです。 これは好ましい方向に流れるメッセージをMSDPに引き起こすでしょう。そうでなければ、同輩-RPFは失敗します。 例外は管理範囲[RFC2365]境界に起こります。 特に、a(S、G)へのSAメッセージを同輩に送ってはいけません(Gのための管理範囲境界の反対側の上にあります)。
8. Encapsulated Data Packets
8. 要約のデータ・パケット
The RP MAY encapsulate multicast data from the source. An interested RP may decapsulate the packet, which SHOULD be forwarded as if a PIM register encapsulated packet was received. That is, if packets are already arriving over the interface toward the source, then the packet is dropped. Otherwise, if the outgoing interface list is non-null, the packet is forwarded appropriately. Note that when doing data encapsulation, an implementation MUST bound the time during which packets are encapsulated.
RP MAYはソースからマルチキャストデータを要約します。 関心があるRPはパケット、どのSHOULDをdecapsulateするかもしれないか。まるでPIMが登録するかのように進めて、要約のパケットを受け取ったということになってください。 すなわち、パケットがインタフェースの上で既にソースに向かって到着する予定であるなら、パケットは落とされます。 さもなければ、送信するインタフェースリストが非ヌルであるなら、適切にパケットを進めます。 カプセル化、実現がしなければならないデータをするとき、縛られて、時間がどのパケットの間要約されるかに注意してください。
This allows for small bursts to be received before the multicast tree is built back toward the source's domain. For example, an implementation SHOULD encapsulate at least the first packet to provide service to bursty sources.
マルチキャスト木がソースのドメインに向かって建てて戻される前にこれは、小さい炸裂が受け取られるのを許容します。 例えば、SHOULDが少なくとも最初のパケットをカプセルに入れる実現はburstyソースに対するサービスを提供します。
9. Other Scenarios
9. 他のシナリオ
MSDP is not limited to deployment across different routing domains. It can be used within a routing domain when it is desired to deploy multiple RPs for the same group ranges such as with Anycast RP's. As long as all RPs have a interconnected MSDP topology, each can learn about active sources as well as RPs in other domains.
MSDPは異なった経路ドメインの向こう側に展開に制限されません。 Anycast RPなどの同じグループ範囲に複数のRPsを配備するのが必要であるときに、経路ドメインの中でそれを使用できます。 すべてのRPsにインタコネクトされたMSDPトポロジーがある限り、それぞれが他のドメインのRPsと同様に活発なソースに関して学ぶことができます。
10. MSDP Peer-RPF Forwarding
10. MSDP同輩-RPF推進
The MSDP Peer-RPF Forwarding rules are used for forwarding SA messages throughout an MSDP enabled internet. Unlike the RPF check used when forwarding data packets, which generally compares the packet's source address against the interface upon which the packet was received, the Peer-RPF check compares the RP address carried in the SA message against the MSDP peer from which the message was received.
規則がMSDP中でメッセージをSAに転送しながら使用されるMSDP Peer-RPF Forwardingはインターネットを可能にしました。 データ・パケットを進めるとき使用されるRPFチェックと異なって、Peer-RPFチェックはSAメッセージでメッセージが受け取られたMSDP同輩に対して運ばれたRPアドレスを比較します。一般に、それは、インタフェースに対してパケットが受け取られたパケットのソースアドレスを比較します。
10.1. Definitions
10.1. 定義
The following definitions are used in the description of the Peer-RPF Forwarding Rules:
以下の定義はPeer-RPF Forwarding Rulesの記述に使用されます:
Fenner & Meyer Experimental [Page 7] RFC 3618 MSDP October 2003
[7ページ]RFC3618MSDP2003年10月に実験的なフェナーとマイヤー
10.1.1. Multicast RPF Routing Information Base
10.1.1. マルチキャストRPF経路情報基地
The Multicast RPF Routing Information Base (MRIB) is the multicast topology table. It is typically derived from the unicast routing table or from other routing protocols such as multi-protocol BGP [RFC2858].
Multicast RPF経路情報基地(MRIB)はマルチキャストトポロジーテーブルです。 それはユニキャスト経路指定テーブルかマルチプロトコルBGP[RFC2858]などの他のルーティング・プロトコルから通常引き出されます。
10.1.2. Peer-RPF Route
10.1.2. 同輩-RPFルート
The Peer-RPF route is the route that the MRIB chooses for a given address. The Peer-RPF route for a SA's originating RP is used to select the peer from which the SA is accepted.
Peer-RPFルートはMRIBが与えられたアドレスに選ぶルートです。 SAの由来しているRPのためのPeer-RPFルートは、SAが受け入れられる同輩を選ぶのに使用されます。
10.1.3. Peer-RPF Forwarding Rules
10.1.3. 同輩-RPF推進規則
An SA message originated by R and received by X from N is accepted if N is the peer-RPF neighbor for X, and is discarded otherwise.
NがXのための同輩-RPF隣人であるなら、受け入れます。別の方法で、NからRによって溯源されて、Xによって受け取られたSAメッセージは、捨てられます。
MPP(R,N) MP(N,X)
R ---------....-------> N ------------------> X
SA(S,G,R) SA(S,G,R)
MPP(R、N)mp(N、X)R---------....------->N------------------>X SA(S、G、R)SA(S、G、R)
MP(N,X) is an MSDP peering between N and X. MPP(R,N) is an MSDP peering path (zero or more MSDP peers) between R and N, e.g., MPP(R,N) = MP(R, A) + MP(A, B) + MP(B, N). SA(S,G,R) is an SA message for source S on group G originated by an RP R.
+ MP(N、X)はNの間をじっと見るMSDPです、そして、X. MPP(R、N)はRとNの間のMSDPじっと見る経路(ゼロか、より多くのMSDP同輩)であり、MP(R、A)+例えば、MPP(R、N)=MP(A、B)はMP(B、N)です。 SA(S、G、R)はRP Rによって溯源されたグループGのソースSへのSAメッセージです。
The peer-RPF neighbor N is chosen deterministically, using the first of the following rules that matches. In particular, N is the RPF neighbor of X with respect to R if
以下の規則の1番目を使用して、合っている同輩-RPF隣人Nは決定論的に選ばれています。 Nは特に、Rに関するXのRPF隣人です。
(i). N == R (X has an MSDP peering with R).
(i)。 N=R(Xで、MSDPはRと共にじっと見ます)。
(ii). N is the eBGP NEXT_HOP of the Peer-RPF route for R.
(ii。) NはRのためのPeer-RPFルートのeBGPネクスト_HOPです。
(iii). The Peer-RPF route for R is learned through a distance-vector
or path-vector routing protocol (e.g., BGP, RIP, DVMRP) and N
is the neighbor that advertised the Peer-RPF route for R
(e.g., N is the iBGP advertiser of the route for R), or N is
the IGP next hop for R if the route for R is learned via a
link-state protocol (e.g., OSPF [RFC2328] or IS-IS
[RFC1142]).
(iii。) または、RのためのPeer-RPFルートが距離ベクトルか経路ベクトルルーティング・プロトコル(例えば、BGP、リップ、DVMRP)を通して学習されて、NがRのためにPeer-RPFルートの広告を出した隣人(例えば、NはRのためのルートのiBGP広告主である)であるかRのためのルートがリンク州のプロトコルで学習されるならNが次がRのために飛び越すIGPである、(例えば、OSPF[RFC2328]、-、[RFC1142。)
(iv). N resides in the closest AS in the best path towards R. If
multiple MSDP peers reside in the closest AS, the peer with
the highest IP address is the rpf-peer.
(iv。) Nは最も良い経路で最も近いASにR.に向かって住んでいます。If複数のMSDP同輩が最も近いASに住んでいて、最も高いIPアドレスをもっている同輩はrpf-同輩です。
(v). N is configured as the static RPF-peer for R.
(v)。 NはRのための静的なRPF-同輩として構成されます。
Fenner & Meyer Experimental [Page 8] RFC 3618 MSDP October 2003
[8ページ]RFC3618MSDP2003年10月に実験的なフェナーとマイヤー
MSDP peers, which are NOT in state ESTABLISHED (i.e., down peers), are not eligible for peer RPF consideration.
同輩RPFの考慮には、MSDP同輩(すなわち、同輩の下側への)は適任ではありません。(その同輩は、州のESTABLISHEDでないところにいます)。
10.2. MSDP mesh-group semantics
10.2. MSDPメッシュグループ意味論
An MSDP mesh-group is a operational mechanism for reducing SA flooding, typically in an intra-domain setting. In particular, when some subset of a domain's MSDP speakers are fully meshed, they can be configured into a mesh-group.
MSDPメッシュグループはSA氾濫を減少させて、通常イントラドメイン設定の操作上のメカニズムです。 ドメインのMSDPスピーカーの何らかの部分集合が完全にかみ合われるとき、特に、メッシュグループに彼らを構成できます。
Note that mesh-groups assume that a member doesn't have to forward an SA to other members of the mesh-group because the originator will forward to all members. To be able for the originator to forward to all members (and to have each member also be a potential originator), the mesh-group must be a full mesh of MSDP peering among all members.
メッシュグループが、創始者がメンバーをすべてに送るのでメンバーがメッシュグループの他のメンバーにSAを送る必要はないと仮定することに注意してください。 メッシュグループのメンバー(各メンバーもいるには、潜在的創始者になってください)がそうしなければならないすべてに送る創始者にとってできるためには、すべてのメンバーの中をじっと見るMSDPの完全なメッシュになってください。
The semantics of the mesh-group are as follows:
メッシュグループの意味論は以下の通りです:
(i). If a member R of a mesh-group M receives a SA message from an
MSDP peer that is also a member of mesh-group M, R accepts
the SA message and forwards it to all of its peers that are
not part of mesh-group M. R MUST NOT forward the SA message
to other members of mesh-group M.
(i)。 メッシュグループMのメンバーRがまたメッシュグループMのメンバーであるMSDP同輩からSAメッセージを受け取るなら、Rは、メッシュグループMの他のメンバーにとってRがSAメッセージを転送してはいけないメッシュグループM.の一部でない同輩のすべてにSAメッセージを受け入れて、それを送ります。
(ii). If a member R of a mesh-group M receives an SA message from
an MSDP peer that is not a member of mesh-group M, and the SA
message passes the peer-RPF check, then R forwards the SA
message to all members of mesh-group M and to any other msdp
peers.
(ii。) メッシュグループMのメンバーRがメッシュグループMのメンバーでないMSDP同輩からSAメッセージを受け取って、SAメッセージが同輩-RPFチェックを通過するなら、RはメッシュグループMのすべてのメンバーと、そして、いかなる他のmsdp同輩にもSAメッセージを転送します。
11. MSDP Connection State Machine
11. MSDP接続州のマシン
MSDP uses TCP as its transport protocol. In a peering relationship, one MSDP peer listens for new TCP connections on the well-known port 639. The other side makes an active connect to this port. The peer with the higher IP address will listen. This connection establishment algorithm avoids call collision. Therefore, there is no need for a call collision procedure. It should be noted, however, that the disadvantage of this approach is that the startup time depends completely upon the active side and its connect retry timer; the passive side cannot cause the connection to be established.
MSDPはトランスポート・プロトコルとしてTCPを使用します。 じっと見る関係では、1人のMSDP同輩がウェルノウンポート639で新しいTCP接続の聞こうとします。 反対側で、能動態はこのポートに接続します。 より高いIPアドレスをもっている同輩は聴くでしょう。 このコネクション確立アルゴリズムは呼び出し衝突を避けます。 したがって、呼び出し衝突手順の必要は全くありません。 そして、しかしながら、このアプローチの不都合が始動時間を完全にアクティブ側に依存するということであることに注意されるべきである、それ、再試行タイマを接続してください。 受け身側で、接続を確立できません。
An MSDP peer starts in the DISABLED state. MSDP peers establish peering sessions according to the following state machine:
MSDP同輩はDISABLED状態で始めます。 MSDP同輩は以下の状態に従ったセッションが機械加工するじっと見ることを設立します:
Fenner & Meyer Experimental [Page 9] RFC 3618 MSDP October 2003
[9ページ]RFC3618MSDP2003年10月に実験的なフェナーとマイヤー
--------------->+----------+
/ | DISABLED |<----------
| ------>+----------+ \
| / |E1->A1 |
| | | |
| | V |E7->A7
| | +----------+ E3->A3 +--------+
| | | INACTIVE |------->| LISTEN |
| | +----------+ +--------+
| | E2->A2| ^ |E5->A5
| | | | |
| |E7->A6 V |E6 |
| \ +------------+ |
| ------| CONNECTING | |
| +------------+ |
E7->A8 | |E4->A4 |
E8->A8 | | |
E9->A8 | V |
\ +-------------+ /
--------------| ESTABLISHED |<---------
+-------------+
| ^
| |
E10->A9 \______/
--------------->+----------+ / | 無能にされます。| <、-、-、-、-、-、-、-、-、--、| ------>+----------+ \ | / |E1>のA1| | | | | | | V|E7>のA7| | +----------+ E3>のA3+--------+ | | | 不活発|、-、-、-、-、-、--、>| 聴いてください。| | | +----------+ +--------+ | | E2>のA2| ^ |E5>のA5| | | | | | |E7>のA6V|6E| | \ +------------+ | | ------| 接続| | | +------------+ | E7>のA8| |E4>のA4| E8>のA8| | | E9>のA8| V| \ +-------------+ / --------------| 設立されます。| <、-、-、-、-、-、-、-、-- +-------------+ | ^ | | E10>A9\______/
11.1. Events
11.1. 出来事
E1) Enable MSDP peering with P
E2) Own IP address < P's IP address
E3) Own IP address > P's IP address
E4) TCP established (active side)
E5) TCP established (passive side)
E6) ConnectRetry timer expired
E7) Disable MSDP peering with P (e.g., when one's own address is
changed)
E8) Hold Timer expired
E9) MSDP TLV format error detected
E10) Any other error detected
1E) Pと共に2)Eじっと見るMSDPを有効にしてください。 IPアドレス<PのIPアドレスを3)E所有してください。 IPアドレス>PのIPアドレスを4)E所有してください。 TCPは(アクティブ側)を設立しました。 5E) TCPは(受け身側)を設立しました。 6E) 7ConnectRetryタイマ満期のE) Pと共にじっと見る(例えば、いつ自分自身のアドレスを変えますか)MSDPを無効にしてください。 8E) 9保持Timer満期のE) 10)E検出されたMSDP TLV形式誤り 検出されたいかなる他の誤り
11.2. Actions
11.2. 動作
A1) Allocate resources for peering with P Compare one's own and
peer's IP addresses
A2) TCP active OPEN Set ConnectRetry timer to
[ConnectRetry-Period]
A3) TCP passive OPEN (listen)
A1) P Compareと共にじっと見るためのリソースに自分自身のを割り当ててください。そうすれば、同輩のIPがA2を記述する、) [ConnectRetry-期間] A3)へのTCPのアクティブなオープンSet ConnectRetryタイマ TCPの受け身のオープン(聴きます)
Fenner & Meyer Experimental [Page 10] RFC 3618 MSDP October 2003
[10ページ]RFC3618MSDP2003年10月に実験的なフェナーとマイヤー
A4) Delete ConnectRetry timer Send KeepAlive TLV
Set KeepAlive timer to [KeepAlive-Period]
Set Hold Timer to [HoldTime-Period]
A5) Send KeepAlive TLV
Set KeepAlive timer to [KeepAlive-Period]
Set Hold Timer to [HoldTime-Period]
A6) Abort TCP active OPEN attempt
Release resources allocated for peering with P
A7) Abort TCP passive OPEN attempt
Release resources allocated for peering with P
A8) Close the TCP connection
Release resources allocated for peering with P
A9) Drop the packet
A4) [KeepAlive-期間]セットHold Timerまで[HoldTime-期間] A5)にConnectRetryタイマSend KeepAlive TLV Set KeepAliveタイマを削除してください。 [HoldTime-期間] A6)への[KeepAlive-期間]セットHold TimerにKeepAlive TLV Set KeepAliveタイマを送ってください。 アクティブなオープン試みReleaseリソースがP A7と共にじっと見るために割り当てたアボートTCP) 受け身のオープン試みReleaseリソースがP A8と共にじっと見るために割り当てたアボートTCP) TCP接続ReleaseリソースがP A9と共にじっと見るために割り当てた閉鎖) パケットを落としてください。
11.3. Peer-specific Events
11.3. 同輩特有の出来事
The following peer-specific events can occur in the ESTABLISHED state, they do not cause a state transition. Appropriate actions are listed for each event.
以下の同輩特有の出来事はESTABLISHED状態に起こることができて、それらは状態遷移を引き起こしません。 適切な行動は各出来事のために記載されています。
*) KeepAlive timer expired:
-> Send KeepAlive TLV
-> Set KeepAlive timer to [KeepAlive-Period]
*) KeepAlive TLV received:
-> Set Hold Timer to [HoldTime-Period]
*) Source-Active TLV received:
-> Set Hold Timer to [HoldTime-Period]
-> Run Peer-RPF Forwarding algorithm
-> Set KeepAlive timer to [KeepAlive-Period] for those peers
the Source-Active TLV is forwarded to
-> Send information to PIM-SM
-> Store information in cache
*) KeepAliveタイマは期限が切れました: ->は[KeepAlive-期間] *)にKeepAlive TLV->Set KeepAliveタイマを送ります。 KeepAlive TLVは受信しました: ->は[HoldTime-期間] *)に保持タイマを設定しました。 ソースアクティブなTLVは受信しました: -キャッシュにおけるPIM-SM->ストア情報へのSourceアクティブなTLVが送られるそれらの同輩のための[KeepAlive-期間]->Send情報への[HoldTime-期間]->Run Peer-RPF Forwardingアルゴリズム->Set KeepAliveタイマへの>セットHold Timer
11.4. Peer-independent Events
11.4. 同輩から独立している出来事
There are also a number of events that affect more than one peering session, but still require actions to be performed on a per-peer basis.
また、1つ以上のじっと見るセッションに影響する多くの出来事がありますが、それでも、動作が1同輩あたり1個のベースに実行されるのを必要であってください。
*) SA-Advertisement-Timer expired:
-> Start periodic transmission of Source-Active TLV(s)
-> Set KeepAlive timer to [KeepAlive-Period] each time a
Source-Active TLV is sent
*) MSDP learns of a new active internal source (e.g., PIM-SM
register received for a new source):
-> Send Source-Active TLV
-> Set KeepAlive timer to [KeepAlive-Period]
*) SG-State-Timer expired (one timer per cache entry):
*) SA広告タイマは期限が切れました: ->はSourceアクティブなTLV(s)の周期的なトランスミッションを始めます。 ->は[KeepAlive-期間] *がSourceアクティブなTLVに送られる各回)にKeepAliveタイマを設定しました。 MSDPは新しい活発な内部のソースを知っています(例えばPIM-SMレジスタは新しいソースに受信されました): ->は[KeepAlive-期間] *)にSourceアクティブなTLV->Set KeepAliveタイマを送ります。 SG州のタイマは(キャッシュエントリーあたりのワンタイマー)を吐き出しました:
Fenner & Meyer Experimental [Page 11] RFC 3618 MSDP October 2003
[11ページ]RFC3618MSDP2003年10月に実験的なフェナーとマイヤー
-> Implementation specific, typically mark the cache entry
for deletion
->実現特有であることで、キャッシュが削除のためのエントリーであると通常マークしてください。
12. Packet Formats
12. パケット・フォーマット
MSDP messages are encoded in TLV format. If an implementation receives a TLV whose length exceeds the maximum TLV length specified below, the TLV SHOULD be accepted. Any additional data, including possible next TLV's in the same message, SHOULD be ignored, and the MSDP session should not be reset.
MSDPメッセージはTLV形式でコード化されます。 実現が長さが以下で指定された最大のTLVの長さ、TLV SHOULDを超えているTLVを受けるなら、受け入れてください。 どんな追加データ、同じメッセージ、SHOULDに可能なTLVの次のものを含んでいるのを無視しました、そして、MSDPセッションをリセットするべきではありません。
12.1. MSDP TLV format
12.1. MSDP TLV形式
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 値… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type (8 bits)
Describes the format of the Value field.
タイプ(8ビット)はValue分野の形式について説明します。
Length (16 bits)
Length of Type, Length, and Value fields in octets. Minimum length
required is 4 octets, except for Keepalive messages. The maximum
TLV length is 9192.
八重奏におけるType、Length、およびValue分野の長さ(16ビット)の長さ。 必要である最小の長さはKeepaliveメッセージ以外の4つの八重奏です。 最大のTLVの長さは9192です。
Value (variable length)
Format is based on the Type value. See below. The length of the
value field is Length field minus 3. All reserved fields in the
Value field MUST be transmitted as zeros and ignored on receipt.
値(可変長)の形式はType値に基づいています。 以下を見てください。 値の分野の長さは3を引いたLength分野です。 Value分野のすべての予約された野原をゼロとして伝えられて、領収書の上で無視しなければなりません。
12.2. Defined TLVs
12.2. 定義されたTLVs
The following TLV Types are defined:
以下のTLV Typesは定義されます:
Code Type
===================================================
1 IPv4 Source-Active
2 IPv4 Source-Active Request
3 IPv4 Source-Active Response
4 KeepAlive
5 Reserved (Previously: Notification)
コードタイプ=================================================== 1 IPv4のソース活発な応答4KeepAlive5が控えたIPv4のソース活発な2IPv4ソース活発な要求3(以前に:、通知)
Fenner & Meyer Experimental [Page 12] RFC 3618 MSDP October 2003
[12ページ]RFC3618MSDP2003年10月に実験的なフェナーとマイヤー
Each TLV is described below.
各TLVは以下で説明されます。
In addition, the following TLV Types are assigned but not described in this memo:
さらに、以下のTLV Typesは割り当てられますが、このメモで説明されません:
Code Type
====================================================
6 MSDP traceroute in progress
7 MSDP traceroute reply
コードタイプ==================================================== 6 進歩7MSDPトレースルート回答におけるMSDPトレースルート
12.2.1. IPv4 Source-Active TLV
12.2.1. IPv4のソースアクティブなTLV
The maximum size SA message that can be sent is 9192 octets. The 9192 octet size does not include the TCP, IP, layer-2 headers.
送ることができる最大サイズSAメッセージは9192の八重奏です。 層-2個のヘッダー、9192年の八重奏サイズはTCP、IPを含んでいません。
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | x + y | Entry Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Sprefix Len | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | Group Address | ) z +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Address | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | x+y| エントリーカウント| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RPアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。| Sprefixレン| \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | グループアドレス| )、z+++++++++++++++++++++++++++++++++/| ソースアドレス| / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
IPv4 Source-Active TLV is type 1.
タイプのIPv4 SourceアクティブなTLVはタイプ1です。
Length x
Is the length of the control information in the message. x is 8
octets (for the first two 32-bit quantities) plus 12 times Entry
Count octets.
. xが8つの八重奏(最初の2つの32ビットの量のための)であるというメッセージの制御情報の長さの長さxのIsと12回のEntry Count八重奏。
Length y
If 0, then there is no data encapsulated. Otherwise an IPv4 packet
follows and y is the value of the total length field in the header
of the encapsulated IP packet. If there are multiple (S,G) entries
in an SA message, only the last entry may have encapsulated data and
it must reflect the source and destination addresses in the header
of the encapsulated IP packet.
データは長さy If0、そこのその時は要約されなかったこと。 さもなければ、IPv4パケットは続きます、そして、yは要約のIPパケットのヘッダーの全長分野の値です。 SAメッセージに複数の(S、G)エントリーがあれば、最後のエントリーだけがデータを要約したかもしれません、そして、それは要約のIPパケットのヘッダーにソースと送付先アドレスを反映しなければなりません。
Fenner & Meyer Experimental [Page 13] RFC 3618 MSDP October 2003
[13ページ]RFC3618MSDP2003年10月に実験的なフェナーとマイヤー
Entry Count
Is the count of z entries (note above) which follow the RP address
field. This is so multiple (S,G)s from the same domain can be
encoded efficiently for the same RP address. An SA message
containing encapsulated data typically has an entry count of 1
(i.e., only contains a single entry, for the (S,G) representing the
encapsulated packet).
エントリーCount Is、RPアドレス・フィールドに続くzエントリー(上では、注意する)のカウント。 これは、同じRPアドレスのために効率的に同じドメインからのsをコード化できるようにとても複数です(S、G)。 すなわち、要約のデータを含むSAメッセージが1のエントリーカウントを通常持っている、((S、G)表す単一のエントリーを含むだけである、要約のパケット)
RP Address
The address of the RP in the domain the source has become active in.
RP Address、ソースがアクティブになったドメインのRPのアドレス。
Reserved
The Reserved field MUST be transmitted as zeros and MUST be ignored
by a receiver.
予約されて、Reserved野原をゼロとして伝えなければならなくて、受信機で無視しなければなりません。
Sprefix Len
The route prefix length associated with source address. This field
MUST be transmitted as 32 (/32).
ソースアドレスに関連しているルート接頭語の長さのSprefixレン。 32(/32)としてこの野原を伝えなければなりません。
Group Address
The group address the active source has sent data to.
グループがソースがデータを送ったアクティブを記述するAddressを分類してください。
Source Address
The IP address of the active source.
IPが記述する活発なソースのソースAddress。
Multiple (S,G) entries MAY appear in the same SA and can be batched for efficiency at the expense of data latency. This would typically occur on intermediate forwarding of SA messages.
複数の(S、G)エントリーが、同じSAに現れるかもしれなくて、データ潜在を犠牲にした効率のためにbatchedされることができます。 これはSAメッセージの中間的推進のときに通常起こるでしょう。
12.2.2. KeepAlive TLV
12.2.2. KeepAlive TLV
A KeepAlive TLV is sent to an MSDP peer if and only if there were no MSDP messages sent to the peer within [KeepAlive-Period] seconds. This message is necessary to keep the MSDP connection alive.
そして、MSDP同輩にKeepAlive TLVを送る、MSDPが全くない場合にだけ、メッセージは[KeepAlive-期間]秒以内に同輩に発信するでしょうに。 このメッセージが、MSDP接続を生かすのに必要です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 | 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4 | 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The length of the message is 3 octets which encompasses the one octet Type field and the two octet Length field.
メッセージの長さはどれが1つの八重奏Type分野を取り囲むか、そして、2八重奏Lengthがさばく3つの八重奏です。
Fenner & Meyer Experimental [Page 14] RFC 3618 MSDP October 2003
[14ページ]RFC3618MSDP2003年10月に実験的なフェナーとマイヤー
13. MSDP Error Handling
13. MSDPエラー処理
If an MSDP message is received with a TLV format error, the session SHOULD be reset with that peer. MSDP messages with other errors, such as unrecognized type code, received from MSDP peers, SHOULD be silently discarded and the session SHOULD not be reset.
MSDPメッセージで受け取るなら、TLVは誤りをフォーマットして、セッションはSHOULDです。その同輩と共にリセットされます。 認識されていないタイプコードなどのようにMSDP同輩から他の誤りを受けているMSDPメッセージ、捨てられて、SHOULDは静かにそうであり、セッションはSHOULDです。リセットされません。
14. SA Data Encapsulation
14. SAデータカプセル化
As discussed earlier, TCP encapsulation of data in SA messages MAY be supported for backwards compatibility with legacy MSDP peers.
SAメッセージのデータの、より早く議論されたTCPカプセル化が後方にように支持されるとき、遺産MSDPとの互換性はじっと見ます。
15. Applicability Statement
15. 適用性証明
MSDP is used primarily in two deployment scenarios:
MSDPは主として2つの展開シナリオで使用されます:
15.1. Between PIM Domains
15.1. PIMドメインの間で
MSDP can be used between PIM domains to convey information about active sources available in other domains. MSDP peering used in such cases is generally one to one peering, and utilizes the deterministic peer-RPF rules described in this spec (i.e., does not use mesh- groups). Peerings can be aggregated on a single MSDP peer, typically from one to hundreds of peerings, similar in scale, although not necessarily consistent, with BGP peerings.
他のドメインに手があいている活発なソースの周りで情報を伝達するのにPIMドメインの間でMSDPを使用できます。 そのような場合使用されるMSDPのじっと見るのは、一般にじっと見る1〜1であり、この仕様(すなわち、メッシュグループを使用しない)で説明された決定論的な同輩-RPF規則を利用します。 独身のMSDP同輩の上でPeeringsを集めることができます、通常1〜何百peeringsまで、スケールにおいて同様です、必ず一貫しているというわけではありませんが、BGP peeringsと共に。
15.2. Between Anycast-RPs
15.2. Anycast-RPsの間で
MSDP is also used between Anycast-RPs [RFC3446] within a PIM domain to synchronize information about the active sources being served by each Anycast-RP peer (by virtue of IGP reachability). MSDP peering used in this scenario is typically based on MSDP mesh groups, where anywhere from two to tens of peers can comprise a given mesh group, although more than ten is not typical. One or more of these mesh- group peers may then also have additional one-to-one peering with msdp peers outside that PIM domain as described in scenario A, for discovery of external sources. MSDP for anycast-RP without external MSDP peering is a valid deployment option and common.
また、それぞれのAnycast-RP同輩(IGPの可到達性による)によって勤められながら、MSDPは活発なソースの情報を同期させるのにPIMドメインの中のAnycast-RPs[RFC3446]の間で使用されます。 このシナリオで使用されるMSDPのじっと見ることはMSDPメッシュグループに通常基づいています、10以上が典型的ではありませんが。(どこでも、そこでは、2〜10人の同輩が、与えられたメッシュグループを包括できます)。 次に、また、これらのメッシュグループの同輩のより多くのひとりに、追加1〜1つがそのPIMドメインの外のmsdp同輩と共にシナリオAで説明されるようにじっと見ながら、あるかもしれません、外部電源の発見のために。 外部のMSDPがじっと見ることのないanycast-RPのためのMSDPは有効な展開オプションであって一般的です。
16. Intellectual Property
16. 知的所有権
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
IETFはどんな知的所有権の正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。いずれもどんなそのような権利も特定するための努力にしました。 そして標準化過程の権利に関するIETFの手順に関する情報。
Fenner & Meyer Experimental [Page 15] RFC 3618 MSDP October 2003
[15ページ]RFC3618MSDP2003年10月に実験的なフェナーとマイヤー
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.
BCP-11で規格関連のドキュメンテーションを見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、または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専務に情報を記述してください。
17. Acknowledgments
17. 承認
The editors would like to thank the original authors, Dino Farinacci, Yakov Rehkter, Peter Lothberg, Hank Kilmer, and Jermey Hall for their original contribution to the MSDP specification. In addition, Bill Nickless, John Meylor, Liming Wei, Manoj Leelanivas, Mark Turner, John Zwiebel, Cristina Radulescu-Banu, Brian Edwards, Selina Priestley, IJsbrand Wijnands, Tom Pusateri, Kristofer Warell, Henning Eriksson, Thomas Eriksson, Dave Thaler, and Ravi Shekhar provided useful and productive design feedback and comments. Toerless Eckert, Leonard Giuliano, Mike McBride, David Meyer, John Meylor, Pekka Savola, Ishan Wu, and Swapna Yelamanchi contributed to the final version of the document.
エディタはMSDP仕様への彼らのオリジナルの貢献について原作者(ディーノ・ファリナッチ)のヤコフRehkter、ピーターLothberg、ハンク・キルマー、およびJermey Hallに感謝したがっています。 さらに、ビルNickless、ジョンMeylor、Limingウェイ、Manoj Leelanivas、マーク・ターナー、ジョンZwiebel、クリスティーナRadulescu-Banu、ブライアン・エドワーズ、Selinaプリーストリー、IJsbrand Wijnands、トムPusateri、クリストファWarell、ヘニング・エリクソン、トーマス・エリクソン、デーヴThaler、およびラービーシェカールは役に立って生産的なデザインにフィードバックとコメントを提供しました。 Toerlessエッケルト、レオナルド・ジュリアーノ、マイク・マックブライド、デヴィッド・マイヤー、ジョンMeylor、ペッカSavola、Ishanウー、およびSwapna Yelamanchiはドキュメントの最終版に貢献しました。
18. Security Considerations
18. セキュリティ問題
An MSDP implementation MUST implement Keyed MD5 [RFC2385] to secure control messages, and MUST be capable of interoperating with peers that do not support it. However, if one side of the connection is configured with Keyed MD5 and the other side is not, the connection SHOULD NOT be established.
MSDP実現は、コントロールメッセージを保証するために、Keyed MD5[RFC2385]を実行しなければならなくて、それを支持しない同輩と共に共同利用できなければなりません。 しかしながら、接続の半面がKeyed MD5によって構成されるか、そして、反対側はそうではありません、接続SHOULD NOT。設立されます。
In addition, to mitigate state explosion during denial of service and other attacks, SA filters and limits SHOULD be used with MSDP to limit the sources and groups that will be passed between RPs [DEPLOY]. These filtering and limiting functions may include, for example, access lists of source or group addresses which should not be propagated to other domains using MSDP, the absolute highest acceptable number of SA-state entries or a rate-limit of for the creation of new SA-state entries after the connection has been established.
サービス、他の攻撃、SAフィルタ、および限界SHOULDの否定の間、州の爆発を緩和するのに、さらに、RPsの間で通過されるソースとグループを制限するMSDPと共に使用されてください[DEPLOY]。 機能をフィルターにかけて、制限すると含まれるかもしれないこれら、例えば、ソースかグループのリストが接続の後に新しいSA-州のエントリーの創造のためにMSDPを使用することで他のドメインにどれを伝播するべきでないか、そして、SA-州のエントリーの絶対最も大きい許容できる数かレート限界を記述するアクセスは確立されました。
If follow-on work is done in this area, a more robust integrity mechanism, such as HMAC-SHA1 [RFC2104, RFC2202] ought to be employed.
この領域でフォローオン仕事をするなら、HMAC-SHA1などの、より強健な保全メカニズム[RFC2104、RFC2202]を使うべきです。
Fenner & Meyer Experimental [Page 16] RFC 3618 MSDP October 2003
[16ページ]RFC3618MSDP2003年10月に実験的なフェナーとマイヤー
19. IANA Considerations
19. IANA問題
This document creates a new namespace called "MSDP TLV Values" that the IANA will manage. The initial seven MSDP TLV values are specified in Section 12.2. The following two sections describe the rules for allocating new MSDP TLV values.
このドキュメントはIANAが管理する「MSDP TLV値」と呼ばれる新しい名前空間を作成します。 7つの初期のMSDP TLV値がセクション12.2で指定されます。 以下の2つのセクションが新しいMSDP TLV値を割り当てるための規則について説明します。
19.1. IANA Allocated TLV Range
19.1. IANAは範囲をTLVに割り当てました。
MSDP TLV values in the range [8,200] (inclusive) are to be allocated using an IESG Approval or Standards Action process [RFC2434].
範囲[8,200](包括的な)のMSDP TLV値はIESG ApprovalかStandards Actionの過程[RFC2434]を使用することで割り当てることです。
19.2. Experimental TLV Range
19.2. 実験TLV範囲
TLV values in the range [201,255] (inclusive) are allocated for experimental use.
実験用のために範囲[201,255](包括的な)のTLV値を割り当てます。
20. References
20. 参照
20.1. Normative References
20.1. 引用規格
[RFC1142] Oran, D., Ed., "OSI IS-IS Intra-domain Routing
Protocol", RFC 1142, February 1990.
[RFC1142] オラン、D.、エド、「OSI、-、イントラドメインルーティング・プロトコル、」、RFC1142、2月1990日
[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月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April
1998.
[RFC2328]Moy、J.、「OSPF、バージョン2インチ、STD54、RFC2328、1998インチ年4月。
[RFC2858] Bates, T., Rekhter, Y., Chandra, R. and D. Katz,
"Multiprotocol Extensions for BGP-4", RFC 2858, June
2000.
[RFC2858] ベイツ、T.、Rekhter、Y.、チャンドラ、R. and D.キャッツ、「BGP-4インチのためのMultiprotocol拡張子、RFC2858、2000年6月。」
[RFC2362] Estrin, D., Farinacci, D., Helmy, A., Thaler, D.,
Deering, S., Handley, M., Jacobson, V., Lin, C.,
Sharma, P. and L. Wei, "Protocol Independent
Multicast - Sparse Mode (PIM-SM): Protocol
Specification", RFC 2362, June 1998.
[RFC2362] Estrin、D.、ファリナッチ、D.、Helmy、A.、ターレル、D.、デアリング、S.、ハンドレー、M.、ジェーコブソン、V.、リン、C.、シャルマ、P.、およびL.ウェイ、「プロトコルの独立しているマルチキャスト--まばらなモード(PIM-Sm):、」 「プロトコル仕様」、RFC2362、1998年6月。
[RFC2365] Meyer, D., "Administratively Scoped IP Multicast",
BCP 23, RFC 2365, July 1998.
[RFC2365] マイヤー、D.、「行政上見られたIPマルチキャスト」、BCP23、RFC2365、1998年7月。
[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月。
Fenner & Meyer Experimental [Page 17] RFC 3618 MSDP October 2003
[17ページ]RFC3618MSDP2003年10月に実験的なフェナーとマイヤー
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", BCP 26, RFC
2434, October 1998.
[RFC2434]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[RFC3446] Kim, D., Meyer, D., Kilmer, H. and D. Farinacci,
"Anycast Rendezvous Point (RP) Mechanism using
Protocol Independent Multicast (PIM) and Multicast
Source Discovery Protocol (MSDP)", RFC 3446, January
2003.
[RFC3446] キム、D.、マイヤー、D.、キルマー、H.、およびD.ファリナッチ、「プロトコルの独立しているマルチキャスト(PIM)とマルチキャストソース発見プロトコル(MSDP)を使用して、Anycastはポイント(RP)メカニズムを集合します」、RFC3446、2003年1月。
20.2. Informative References
20.2. 有益な参照
[DEPLOY] McBride, M., Meylor, J. and D. Meyer, "Multicast
Source Discovery Protocol (MSDP) Deployment
Scenarios", Work in Progress, July 2003.
[展開します] 「マルチキャストソース発見プロトコル(MSDP)展開シナリオ」というマックブライド、M.、Meylor、J.、およびD.マイヤーは進歩、2003年7月に働いています。
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:
Keyed-Hashing for Message Authentication", RFC 2104,
February 1997.
[RFC2104] Krawczyk、H.、Bellare、M.、およびR.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。
[RFC2202] Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and
HMAC-SHA-1", RFC 2202, September 1997.
[RFC2202] チェンとP.とR.グレンと「HMAC-MD5のためのテストケースとHMAC-SHA-1インチ、RFC2202、1997年9月。」
21. Editors' Addresses
21. エディタのアドレス
Bill Fenner AT&T Labs -- Research 75 Willow Road Menlo Park, CA 94025
ビルフェナーAT&T研究室--研究75はメンローパーク、Roadカリフォルニア 94025をウイロにかけます。
EMail: fenner@research.att.com
メール: fenner@research.att.com
David Meyer
デヴィッド・マイヤー
EMail: dmm@1-4-5.net
メール: dmm@1-4-5.net
Fenner & Meyer Experimental [Page 18] RFC 3618 MSDP October 2003
[18ページ]RFC3618MSDP2003年10月に実験的なフェナーとマイヤー
22. Full Copyright Statement
22. 完全な著作権宣言文
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 assignees.
上に承諾された限られた許容は、永久であり、そのインターネット協会、後継者または指定代理人によって取り消されないでしょう。
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機能のための基金は現在、インターネット協会によって提供されます。
Fenner & Meyer Experimental [Page 19]
フェナーとマイヤーExperimentalです。[19ページ]
一覧
スポンサーリンク
