RFC2771 日本語訳
2771 An Abstract API for Multicast Address Allocation. R. Finlayson. February 2000. (Format: TXT=20954 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Finlayson Request for Comments: 2771 LIVE.COM Category: Informational February 2000
コメントを求めるワーキンググループR.フィンリースン要求をネットワークでつないでください: 2771年のLIVE.COMカテゴリ: 情報の2000年2月
An Abstract API for Multicast Address Allocation
マルチキャストアドレス配分のための抽象的なAPI
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
Abstract
要約
This document describes the "abstract service interface" for the dynamic multicast address allocation service, as seen by applications. While it does not describe a concrete API (i.e., for a specific programming language), it describes - in abstract terms - the semantics of this service, including the guarantees that it makes to applications.
このドキュメントはダイナミックなマルチキャストアドレス配分サービスのためにアプリケーションで見られるように「抽象的なサービスインタフェース」について説明します。 具体的なAPI(すなわち、スペシフィック・プログラミング言語のための)について説明しませんが、抽象名辞でこのサービスの意味論について説明します、それがアプリケーションにする保証を含んでいて。
Additional documents (not necessarily products of the IETF) would describe concrete APIs for this service.
追加ドキュメント(必ずIETFの製品であるというわけではない)はこのサービスのために具体的なAPIについて説明するでしょう。
1. Introduction
1. 序論
Applications are the customers of a multicast address allocation
service, so a definition of this service should include not only the
inter-node network protocols that are used to implement it, but also
the 'protocol' that applications use to access the service. While
APIs ("application programming interfaces") for specific programming
languages (or operating systems) are outside the domain of the IETF,
it is appropriate for us to define - in abstract terms - the semantic
interface that this service presents to applications. Specific APIs
would then be based upon this abstract service interface.
アプリケーションがマルチキャストアドレス配分サービスの顧客であるので、このサービスの定義はそれを実装するのに使用される節間ネットワーク・プロトコルだけではなく、アプリケーションがサービスにアクセスするのに使用する'プロトコル'も含むべきです。 IETFのドメインの外にスペシフィック・プログラミング言語(または、オペレーティングシステム)のためのAPI(「アプリケーションプログラミングインターフェース」)がありますが、私たちが抽象名辞でこのサービスがアプリケーションに提示する意味インタフェースを定義するのは、適切です。 そして、特定のAPIはこの抽象的なサービスインタフェースに基づくでしょう。
Note that it is possible to implement the multicast address allocation service in at least two different ways. The first (and perhaps most common) way is for end nodes to allocate addresses by communicating with a separate "Address Allocation Server" node, using the "Host to Address Allocation Server" network protocol (MADCAP) [1][7]. Alternatively, an "Address Allocation Server" implementation
マルチキャストアドレスが配分サービスであると少なくとも2つの異なった方法で実装するのが可能であることに注意してください。 1番目の、そして、(恐らく最も一般的)の道はエンドノードが「アドレス配分サーバ」という別々のノードとコミュニケートすることによってアドレスを割り当てることです、「配分がサーバであると扱うホスト」ネットワーク・プロトコル(MADCAP)[1][7]を使用して。 あるいはまた、「アドレス配分サーバ」実装
Finlayson Informational [Page 1] RFC 2771 Abstract API for Multicast Address Allocation February 2000
マルチキャストアドレス配分2000年2月のためのフィンリースンの情報[1ページ]のRFC2771の抽象的なAPI
might be co-located (along with one or more applications) on an end node, in which case some other, internal, mechanism might be used to access the server. In either case, however, the abstract service interface (and, presumably, any specific APIs) would remain the same.
内部です、メカニズムは、サーバにアクセスするのに使用されるかもしれません。エンドノードにどの場合に共同位置しているかもしれないか、(1つ以上のアプリケーションに伴う)ある他のしかしながら、どちらの場合ではも、抽象的なサービスインタフェース(おそらくどんな特定のAPIも)は同じままで残っているでしょう。
The remainder of this document describes the abstract interface.
このドキュメントの残りは抽象的なインタフェースについて説明します。
Note that this interface is intended only for the allocation of dynamic multicast addresses, as used by the traditional multicast service model [2]. Future multicast service models might allocate or assign multicast addresses in other ways, but this is outside the scope of this document.
このインタフェースがダイナミックなマルチキャストアドレスの配分のためだけに意図することに注意してください、伝統的なマルチキャストサービスモデル[2]によって使用されるように。 将来のマルチキャストサービスモデルは、他の方法でマルチキャストアドレスを割り当てるか、または割り当てるかもしれませんが、このドキュメントの範囲の外にこれはあります。
2. Abstract Data Types
2. 抽象データ型
The interface described below uses the following abstract data types:
インタフェースは用途の下で以下の抽象データ型を説明しました:
- AddressFamily: e.g., IPv4 or IPv6
- AddressFamily: 例えば、IPv4かIPv6
- MulticastAddress: An actual multicast address (i.e., that could
subsequently be used as the destination of a datagram)
- MulticastAddress: 実際のマルチキャストアドレス(次に、データグラムの目的地としてすなわち、それを使用できました)
- MulticastAddressSet: A set of "MulticastAddress"es
- MulticastAddressSet: 「MulticastAddress」esの1セット
- LanguageTag: The code for a (human) language, as defined in [4]
- LanguageTag: 中で定義されるとしての(人間)の言語のためのコード[4]
- Scope: An "administrative scope" [3] from which multicast
addresses are to be allocated. Each scope is a
"MulticastAddressSet", with an associated set of
(character-string) names - indexed by "LanguageTag". (Each
language tag has at most one corresponding name, per
scope.) For each scope, a (language tag, name) pair may be
defined to be the 'default' name for this scope. (See the
section "Querying the name of a scope" below.)
- 範囲: 割り当てられるマルチキャストアドレスがことである「管理範囲」[3]。 各範囲は関連セットの(文字列)名がある"MulticastAddressSet"です--"LanguageTag"によって索引をつけられます。 (それぞれの言語タグは1範囲あたり1つの対応する名前に最も攻撃します。) 各範囲に関しては、(言語タグ、名前)組は、この範囲への'デフォルト'名になるように定義されるかもしれません。 (下の「範囲の名前について質問する」というセクションを見てください。)
(An implementation of this abstract data type might also
include other information, such as a default TTL for the
scope.)
(また、この抽象データ型の実装は範囲へのデフォルトTTLの他の情報を含むかもしれません。)
- Time: An (absolute) event time. This is used for specifying the
"lifetime" of multicast addresses: the period of time during
which allocated multicast addresses are guaranteed to be
available. (It is also used to specify the desired start
time for an "advance allocation".)
- 時間: (絶対)のイベント時間。 これはマルチキャストアドレスの「生涯」を指定するのに使用されます: 割り当てられたマルチキャストアドレスが利用可能になるように保証される期間。 (また、それは「前売りの配分」のための必要な開始時刻を指定するのに使用されます。)
Finlayson Informational [Page 2] RFC 2771 Abstract API for Multicast Address Allocation February 2000
マルチキャストアドレス配分2000年2月のためのフィンリースンの情報[2ページ]のRFC2771の抽象的なAPI
Note that a concrete API might prefer to specify some of
these times as relative times (i.e., relative to the current
time-of-day), rather than absolute time. (Relative times
have the advantage of not requiring clock synchronization.)
具体的なAPIが、絶対時間よりむしろ相対的な時勢(すなわち、現在の時刻に比例した)としてこれらの回のいくつかを指定するのを好むかもしれないことに注意してください。 (相対的な時勢には、時計同期を必要としない利点があります。)
- Lease: A compound data type that describes the result of a
(successful) multicast address allocation. It consists of:
- 以下を賃貸してください。 (うまくいく)のマルチキャストアドレス配分の結果について説明する合成データ型。 それは以下から成ります。
- [MulticastAddressSet] The set of addresses that were
allocated;
- [MulticastAddressSet] 割り当てられたアドレスのセット。
- [AddressFamily] The address family of these addresses
- [AddressFamily] これらのアドレスのアドレスファミリー
- [Time] The lifetime of these addresses (the same for
each address)
- [時間] これらのアドレスの生涯(各アドレスのための同じくらい)
- [Time] The "start time" of the allocation. (See the
discussion of "advance allocation" below.) (A concrete
API would likely also include a MADCAP "Lease
Identifier" [1].)
- [時間] 配分の「開始時刻。」 (以下の「前売りの配分」の議論を見てください。) (また、具体的なAPIはおそらくMADCAP「リース識別子」[1]を含んでいるでしょう。)
- NestingRelationship: A binary data type that describes whether or
not two scopes nest. Two scopes nest if
traffic sent sent to a multicast group within
one scope could be seen by all hosts present
within the other scope were they to join the
multicast group within the first scope. This
value would be "False" for overlapping scopes
where only some (or none) of the hosts within
the second scope could see traffic sent to an
address due to the presence of an
administratively scoped boundary. In cases
where the first and second scopes are
topologically identical this value would be
"True."
- NestingRelationship: 2が巣を見るかどうか説明するバイナリ・データタイプ。 送られたトラフィックが1つの範囲の中のマルチキャストグループに発信するなら、彼らが最初の範囲の中でマルチキャストグループに加わるなら、もう片方の範囲の中に出席しているすべてのホストが2範囲巣を見ることができるでしょうに。 2番目の範囲の中の何人かのホストだけ(または、なにも)が、トラフィックが行政上見られた境界の存在のためアドレスに送られるのを見ることができた範囲を重ね合わせるのにおいて、この値は「誤っているでしょう」。 1番目と2番目の範囲による同じであるのが、位相的に、「本当に」というこれが、評価することであるということである場合で。
- Status: A result code.
- 状態: 結果コード。
Finlayson Informational [Page 3] RFC 2771 Abstract API for Multicast Address Allocation February 2000
マルチキャストアドレス配分2000年2月のためのフィンリースンの情報[3ページ]のRFC2771の抽象的なAPI
3. The Abstract Interface
3. 抽象的なインタフェース
3.1 Allocating multicast addresses:
3.1 マルチキャストを割り当てると、以下は扱われます。
alloc_multicast_addr(in AddressFamily family,
in Scope scope,
in Integer minDesiredAddresses,
in Integer maxDesiredAddresses,
in Time minDesiredStartTime,
in Time maxDesiredStartTime,
in Time minDesiredLifetime,
in Time maxDesiredLifetime,
out Lease multicastAddressSetLease,
out Status status)
alloc_マルチキャスト_addr(Status状態からのAddressFamilyファミリー、Scope範囲、Integer minDesiredAddresses、Integer maxDesiredAddresses、Time minDesiredStartTime、Time maxDesiredStartTime、Time minDesiredLifetime、Time maxDesiredLifetimeの出ているLease multicastAddressSetLease)
This operation attempts to allocate a set of multicast addresses (the
size of this set is in the range [minDesiredAddresses,
maxDesiredAddresses]) within the given address family and scope, and
within a given range of desired lifetimes. ("minDesiredStartTime"
and "maxDesiredStartTime" are used to specify "advance allocation";
this is described in more detail below.)
この操作は、与えられたアドレスファミリーと範囲以内と与えられた範囲の必要な生涯以内に1セットのマルチキャストアドレス(このセットのサイズが範囲[minDesiredAddresses、maxDesiredAddresses]にある)を割り当てるのを試みます。 ("minDesiredStartTime"と"maxDesiredStartTime"は「前売りの配分」を指定するのに使用されます; これはさらに詳細に以下で説明されます。)
If the address allocation succeeds, the result is returned in "multicastAddressSetLease" (with "status" = OK).
アドレス配分が成功するなら、結果は"multicastAddressSetLease"(「状態」=OKがある)で返されます。
During the lifetime of this lease, the allocation service will make a "best-effort" attempt to not allocate any of these addresses to others. (However, once the lease's lifetime has expired, any of its addresses can be allocated to others.)
このリースの生涯、配分サービスはこれらのアドレスのいずれも他のものに割り当てない「ベストエフォート型」の試みをするでしょう。 (しかしながら、リースの寿命がいったん期限が切れると、アドレスのどれかを他のものに割り当てることができます。)
Multicast addresses are allocated for a limited lifetime. An application may attempt to extend this lifetime, but this operation may fail. Therefore, an application must be prepared for the possibility it will not be able to use the same addresses for as long as it desires. In particular, the application must be prepared to either quit early (because its original multicast address assignments have expired), or, alternatively, to occasionally 'renumber' its multicast addresses (in some application or higher-level-protocol dependent way), by making a new allocation. However, if an application needs to consider 'renumbering', it will always know this in advance, at the time it acquired its current address(es) - by checking the lifetime in the returned lease. An application will never need to be notified asynchronously of the need to 'renumber'.
限られた生涯マルチキャストアドレスを割り当てます。 アプリケーションは、この生涯を広げるのを試みるかもしれませんが、この操作は失敗するかもしれません。 したがって、同じくらいが同じくらい長い間望んでいるように扱う使用にできるようにならない可能性のためにアプリケーションを準備しなければなりません。 特に、または、あるいはまた、マルチキャストアドレス(何らかのアプリケーションか、よりハイレベルのプロトコルの依存する方法で)に時折'番号を付け替えさせる'ために早さに(オリジナルのマルチキャストアドレス課題が期限が切れたので)やめるようにアプリケーションを準備しなければなりません、新しい配分をすることによって。 しかしながら、アプリケーションが、'番号を付け替える'と考える必要があると、あらかじめいつもこれを知るでしょう、返されたリースに基づく生涯をチェックすることによって現在のアドレス(es)を習得したとき。 アプリケーションは、決して'番号を付け替えさせる'必要性について非同期に通知される必要がないでしょう。
Finlayson Informational [Page 4] RFC 2771 Abstract API for Multicast Address Allocation February 2000
マルチキャストアドレス配分2000年2月のためのフィンリースンの情報[4ページ]のRFC2771の抽象的なAPI
Possible errors:
可能な誤り:
- bad address family
- bad scope
- bad desired number of addresses (e.g., max < min)
- bad desired lifetimes (e.g., max < min)
- errors with the two "start time" parameters (see
"Advance allocation" below)
- no addresses can be allocated (for the requested parameters)
- 悪いアドレスファミリー--悪い範囲--悪い必要な数のアドレス(例えば、最大<分)--悪い必要な生涯(例えば、最大<分)--2つの「開始時刻」パラメタ(以下の「前売りの配分」を見る)がある誤り--アドレスを全く割り当てることができません。(要求されたパラメタのための)
An allocation attempt can also fail with a result "status" code of TRY_LATER, indicating that the requested allocation cannot be made at this time, but that it might succeed if the caller retries the attempt at some future time. (This future time is returned in the "start time" field of the
また、TRY_LATERの結果「状態」コードに応じて、配分試みは失敗できます、このとき、要求された配分をすることができませんが、訪問者が何らかの将来の時間への試みを再試行するならそれが成功するかもしれないのを示して。 (「開始時刻」がさばくコネをこの将来の時間に返します。
"multicastAddressSetLease";
the other parts of this lease are undefined.)
"multicastAddressSetLease"。 このリースの他の部品は未定義です。)
Note that a concrete (i.e., programming language-specific) API for multicast address allocation will probably include additional, specialized variants of this general allocation operation. For instance, it may include separate operations for:
マルチキャストアドレス配分のための具体的な(すなわち、プログラミング言語詳細)APIがたぶんこの一般的な配分操作の追加していて、専門化している異形を含むことに注意してください。 例えば、それは以下のために別々の操作を含むかもしれません。
- allocating only a single address
(i.e., minDesiredAddresses = maxDesiredAddresses = 1);
- (attempting to) allocate an address with a single, fixed
lifetime (i.e., minDesiredLifetime = maxDesiredLifetime);
- (attempting to) allocate an address for immediate use
(i.e., minDesiredStartTime = maxDesiredStartTime = 'now')
- シングルだけを割り当てて、(maxDesiredAddressesすなわち、minDesiredAddresses==1)を扱ってください。 - (試みます) 単一の、そして、固定された生涯があるアドレスを割り当ててください(すなわち、minDesiredLifetimeはmaxDesiredLifetimeと等しいです)。 - (試みます) 即座の使用のためのアドレスを割り当ててください。('現在'のすなわち、minDesiredStartTime=maxDesiredStartTime=)
3.2 Changing multicast addresses' lifetime:
3.2 変化しているマルチキャストアドレスの生涯:
change_multicast_addr_lifetime(in Lease multicastAddressSetLease,
in Time minDesiredLifetime,
in Time maxDesiredLifetime,
out Time lifetime)
変化_マルチキャスト_addr_生涯(Lease multicastAddressSetLease、Time minDesiredLifetime、Time maxDesiredLifetimeのアウトTime生涯)
This operation attempts to change the lifetime of previously allocated multicast addresses. Unless an error occurs, it returns the new lifetime (which might remain unchanged).
この操作は、以前に割り当てられたマルチキャストアドレスの生涯を変えるのを試みます。 誤りが発生しない場合、それは新しい生涯(変わりがないかもしれない)を返します。
Possible errors:
可能な誤り:
- bad address family
- bad durations (e.g., max < min)
- 悪いアドレスファミリー--悪い持続時間(例えば、最大<分)
Finlayson Informational [Page 5] RFC 2771 Abstract API for Multicast Address Allocation February 2000
マルチキャストアドレス配分2000年2月のためのフィンリースンの情報[5ページ]のRFC2771の抽象的なAPI
- the addresses' lifetime could not be changed
(and the existing lifetime was not in the requested range
[minDesiredLifetime,maxDesiredLifetime])
- the addresses were not ones that we had allocated
(see section 5.9) - or they have already expired
- アドレスの生涯を変えることができませんでしたか(既存の寿命が要求された範囲[minDesiredLifetime、maxDesiredLifetime]にありませんでした)(アドレスは私たちが割り当てたもの(セクション5.9を見る)ではありませんでした)、またはそれらは既に期限が切れました。
3.3 Deallocating multicast addresses:
3.3 Deallocatingマルチキャストアドレス:
deallocate_multicast_addr(in Lease multicastAddressSetLease) This operation attempts to deallocate previously allocated multicast addresses.
deallocate_マルチキャスト_はdeallocateへの試みが以前にマルチキャストアドレスを割り当てたこの操作をaddrします(Lease multicastAddressSetLeaseで)。
Possible errors:
可能な誤り:
- bad address family
- the addresses were not ones that we had allocated
(or they have already expired)
- 悪いアドレスファミリー--アドレスは私たちが割り当てたものではありませんでした。(彼らは既に期限が切れました)
3.4 Querying the set of usable multicast address scopes:
3.4 使用可能なマルチキャストアドレスのセットについて質問するのは見られます:
get_multicast_addr_scopes(in AddressFamily family,
out "set of" Scope)
_マルチキャスト_addr_範囲を手に入れてください。(「セットされて」AddressFamilyの家族の、そして、出ているScopeの)
This operation returns the set of administrative multicast address scopes that are defined for this node.
この操作はこのノードのために定義される管理マルチキャストアドレスの範囲のセットを返します。
Possible errors:
可能な誤り:
- bad address family
- 悪いアドレスファミリー
3.5 Querying the name of a scope:
3.5 範囲の名前について質問します:
get_scope_name(in Scope scope,
in LanguageTag language,
out String name,
out LanguageTag languageForName)
_範囲_名前を得てください。(ScopeがStringの名義の、そして、出ているLanguageTag languageForNameからLanguageTag言語で見るコネ)
This operation returns a character-string name for a given scope. If the scope has a name in the specified "language", then this name (and language) is returned. Otherwise, the scope's default (language, name) pair is returned.
この操作は文字列名を与えられた範囲に返します。 範囲に指定された「言語」による名前があるなら、この名前(そして、言語)を返します。 さもなければ、範囲のデフォルト(言語、名前)組を返します。
Possible errors:
可能な誤り:
- bad scope.
- 悪い範囲。
Finlayson Informational [Page 6] RFC 2771 Abstract API for Multicast Address Allocation February 2000
マルチキャストアドレス配分2000年2月のためのフィンリースンの情報[6ページ]のRFC2771の抽象的なAPI
3.6 Querying the nesting state of known usable multicast address scopes:
3.6 知られている使用可能なマルチキャストアドレスの巣篭もり事情について質問するのは見られます:
get_scope_nesting_state(in "set of" Scope,
out "matrix of" NestingRelationship)
_範囲_に_状態を入れ子にさせてください。(外の「セットされて」Scope、「」 NestingRelationshipのマトリクス)
Possible errors:
可能な誤り:
- bad scope.
- nesting state undetermined at this time.
- 悪い範囲。 - 巣篭もり状態はこのとき、非決定しました。
This operation would return a matrix that shows the current nesting relationships between the supplied set of scopes which would have previously been supplied via the get_multicast_addr_scopes(...) function.
を通してこの操作がどれが以前に供給されたかを供給されたセットの範囲の間の現在の巣篭もり関係に示すマトリクスを返すだろう、_マルチキャストの_のaddr_範囲(…)に機能を得てください。
3.7 Querying the set of scopes that a given scope is known to nest inside:
3.7 与えられた範囲がそうである範囲のセットについて以下で巣に知られていた質問すること。
get_larger_scopes(in Scope,
out "set of" Scope)
_より大きい_範囲を手に入れてください。(Scopeの「セットされて」出ているScope)
This operation returns the set of administrative multicast address scopes that are known to encompass the supplied Scope.
この操作は供給されたScopeを取り囲むのが知られている管理マルチキャストアドレスの範囲のセットを返します。
Possible errors:
可能な誤り:
- bad scope.
- nesting state undetermined at this time.
- 悪い範囲。 - 巣篭もり状態はこのとき、非決定しました。
3.8 Querying the set of scopes that are known to nest inside a given scope:
3.8 与えられた範囲の中の巣に知られている範囲のセットについて質問します:
get_smaller_scopes(in Scope,
out "set of" Scope)
_より小さい_範囲を手に入れてください。(Scopeの「セットされて」出ているScope)
This operation returns the set of administrative multicast address scopes that are known to nest inside the supplied Scope (NB this would include those scopes that are topologically identical to the supplied scope).
この操作が供給されたScopeの中で巣に知られている管理マルチキャストアドレスの範囲のセットを返す、(ネブラスカ、これが供給された範囲と同じ状態で位相的にそうであるそれらの範囲を含んでいるだろう、)
Possible errors:
可能な誤り:
- bad scope.
- nesting state undetermined at this time.
- 悪い範囲。 - 巣篭もり状態はこのとき、非決定しました。
Finlayson Informational [Page 7] RFC 2771 Abstract API for Multicast Address Allocation February 2000
マルチキャストアドレス配分2000年2月のためのフィンリースンの情報[7ページ]のRFC2771の抽象的なAPI
3.9 Note: The decision as to who is allowed to deallocate (or change
the lifetime of) a previously allocated multicast address set lease
is implementation-specific, and depends upon the security policy of
the host system. Thus it is not specified in this abstract API.
One possible starting point, however, is the following:
3.9注意: または、だれがdeallocateに許容されているかに関する決定、(生涯を変える、)、以前に割り当てられたマルチキャストアドレスセットリースは、実装特有であり、ホストシステムの安全保障政策によります。 したがって、それはこの抽象的なAPIで指定されません。 しかしながら、1つの可能な出発点が以下です:
A previously allocated multicast address can be deallocated (or
have its lifetime queried or changed) by the same "principal", and
on the same node, as that which originally allocated it.
("principal" might, for example, be a "user" in the host operating
system.)
同じ「主体」の近くと、そして、同じノードの上に以前に割り当てられたマルチキャストアドレスは「反-割り当て」ることができます(生涯を質問されるか、または変えるように持ってください)、元々それを割り当てたそれとして。 (例えば、「主体」はホスト・オペレーティング・システムの「ユーザ」であるかもしれません。)
3.10 Advance allocation
3.10 前売りの配分
By specifying "minDesiredStartTime = maxDesiredStartTime = 'now'",
the address allocation operation - "alloc_multicast_addr" -
described above can be used to request a set of multicast
addresses that can be used *immediately* (and until their lifetime
expires). During this whole time, the addresses are not available
for allocation to others.
「minDesiredStartTimeは'現在'のときにmaxDesiredStartTime=と等しいこと」によって、指定している*すぐに使用できる1セットのマルチキャストアドレスを要求するのに「alloc_マルチキャスト_addr」という上で説明されたアドレス配分操作は使用できます。*(彼らの寿命が期限が切れるまで)。 この全部の時間の間、他のものには、アドレスは配分に利用可能ではありません。
It is also possible - using the "minDesiredStartTime" and
"maxDesiredStartTime" parameters - to allocate multicast addresses
*in advance* - i.e., so that they have a future "start time" as
well as an expiration time. Before the start time, the multicast
addresses may be allocated to others.
また、"minDesiredStartTime"と"maxDesiredStartTime"パラメタを使用して、それも可能であるので(マルチキャストを割り当てるのは*あらかじめ、*を扱います)、それらには、すなわち、満了時間と同様に将来の「開始時刻」があります。 開始時刻の前に、マルチキャストアドレスを他のものに割り当てるかもしれません。
Advance allocation is convenient for allocating addresses for
events that begin far in the future - e.g., several weeks or
months away. Without advance allocation, it would be necessary to
allocate addresses for a long period of time - even when it will
not be used. Such a request would not only be a wasteful use of
the multicast address space, but it may also be difficult to
implement (especially since address allocations are expected to
remain valid in spite of topology changes).
将来遠くに始まるイベントのためのアドレスを割り当てるのは前売りの配分は都合がよいです--例えば、数週間か何カ月も後で。 それが使用さえされないとき、前売りの配分がなければ、長い年月の間アドレスを割り当てるのが必要でしょう。 そのような要求はマルチキャストアドレス空間の無駄な使用であるだけではないでしょうが、また、それは実装するのも難しいかもしれません(特にアドレス配分がトポロジー変化にもかかわらず、有効なままで残っていると予想されて)。
Advance allocation requests can produce the following errors (in
addition to those defined earlier):
事前の配分要求は以下の誤り(より早く定義されたものに加えた)を起こすことができます:
- bad start time durations (e.g., max < min)
- requested start times conflict with requested lifetimes
(i.e., min start time > max lifetime)
- 悪い開始時刻持続時間(例えば、最大<分)--回が衝突する要求された始めは生涯を要求しました。(すなわち、開始時刻>分は生涯に最大限にします)
Finlayson Informational [Page 8] RFC 2771 Abstract API for Multicast Address Allocation February 2000
マルチキャストアドレス配分2000年2月のためのフィンリースンの情報[8ページ]のRFC2771の抽象的なAPI
The following operation is also defined:
また、以下の操作は定義されます:
change_multicast_addr_start_time(in Lease multicastAddressSetLease,
in Time minDesiredStartTime,
in Time maxDesiredStartTime,
out Time startTime)
変化_マルチキャスト_addr_スタート_時間(リースmulticastAddressSetLease、時間minDesiredStartTime、時間maxDesiredStartTimeのアウト時間startTime)
This operation attempts to change the start time of previously
allocated multicast addresses. Unless an error occurs, it returns
the new start time (which might remain unchanged).
この操作は、以前に割り当てられたマルチキャストアドレスの開始時刻を変えるのを試みます。 誤りが発生しない場合、それは再スタート時間(変わりがないかもしれない)を返します。
Possible errors: the same as "change_multicast_addr_lifetime"
可能な誤り: 「変化_マルチキャスト_addr_生涯」と同じくらい
4. Security Considerations
4. セキュリティ問題
As noted in section 5.9 above, each implementation of this abstract API should define a security policy that specifies when (and by whom) previously allocated multicast addresses can be deallocated (or queried, or have their lifetime changed).
以前にマルチキャストアドレスを割り当てるとき(そしてだれが)、指定する上では、この抽象的なAPIの各実装が定義するべきであるセクション5.9で同じくらい有名な安全保障政策は「反-割り当て」ることができます(質問するか、または彼らの生涯を変えさせてください)。
Because multicast addresses are a finite resource, there is a
potential for a "denial of service" attack by allocating a large
number of multicast addresses without deallocating them. Preventing
such an attack, however, is not the role of the API, but rather by
the underlying MAAS ("Multicast Address Allocation Server(s)" [6]).
マルチキャストアドレスが有限リソースであるので、それらを「反-割り当て」ないで多くのマルチキャストアドレスを割り当てるのによる「サービスの否定」攻撃の可能性があります。 むしろ基本的なマースのそばでしかしながら、そのような攻撃を防ぐのは、APIの役割であるのではなく役割です。(「マルチキャストアドレス配分サーバ」[6])。
5. Acknowledgements
5. 承認
Many thanks to other participants in the "MALLOC" working group - in particular Steve Hanna, Dave Thaler, Roger Kermode, and Pavlin Radoslavov - for their valuable comments.
彼らの貴重なコメントのために"MALLOC"ワーキンググループ(特にスティーブ・ハンナ、デーヴThaler、ロジャー・カーモード、およびパブリン・ラドスラーボフ)で他の関係者をありがとうございます。
6. References
6. 参照
[1] Hanna, S., Patel, B. and M. Shah, "Multicast Address Dynamic
Client Allocation Protocol (MADCAP)", RFC 2730, December 1999.
[1] ハンナとS.とパテルとB.とM.シャー、「マルチキャストのアドレスのダイナミックなクライアント配分プロトコル(向こう見ず)」、RFC2730、1999年12月。
[2] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC
1112, August 1989.
[2] デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、STD5、RFC1112、1989年8月。
[3] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC
2365, July, 1998.
[3] マイヤー、D.、「行政上見られたIPマルチキャスト」、BCP23、RFC2365、1998年7月。
[4] Alvestrand, H., "Tags for the Identification of Languages", RFC
1766, March 1995.
Alvestrand(H.)が「言語の識別のためにタグ付けをする」[4]、RFC1766、1995年3月。
Finlayson Informational [Page 9] RFC 2771 Abstract API for Multicast Address Allocation February 2000
マルチキャストアドレス配分2000年2月のためのフィンリースンの情報[9ページ]のRFC2771の抽象的なAPI
[5] Handley, M. and V. Jacobson, "SDP: Session Description Protocol",
RFC 2327, April 1998.
[5] ハンドレー、M.、およびV.ジェーコブソン、「SDP:」 「セッション記述プロトコル」、RFC2327、1998年4月。
[6] Estrin, D., Handley, M. and D. Thaler, "The Internet Multicast
Address Allocation Architecture", Work in Progress.
[6] 「インターネットマルチキャストアドレス配分アーキテクチャ」というEstrin、D.、ハンドレー、M.、およびD.ターレルは進行中で動作します。
[7] Kermode, R., "MADCAP Multicast Scope Nesting State Option", Work
in Progress.
[7] カーモード、R.、「向こう見ずなマルチキャスト範囲巣篭もり州のオプション」が進行中で働いています。
7. Author's Address
7. 作者のアドレス
Ross Finlayson, Live Networks, Inc. (LIVE.COM)
ロスフィンリースン、ライブネットワークInc.(LIVE.COM)
EMail: finlayson@live.com WWW: http://www.live.com/
メール: finlayson@live.com WWW: http://www.live.com/
Finlayson Informational [Page 10] RFC 2771 Abstract API for Multicast Address Allocation February 2000
マルチキャストアドレス配分2000年2月のためのフィンリースンの情報[10ページ]のRFC2771の抽象的なAPI
8. Full Copyright Statement
8. 完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Finlayson Informational [Page 11]
フィンリースン情報です。[11ページ]
一覧
スポンサーリンク
