RFC2226 日本語訳
2226 IP Broadcast over ATM Networks. T. Smith, G. Armitage. October 1997. (Format: TXT=30661 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group T. Smith
Request for Comments: 2226 IBM Corporation
Category: Standards Track G. Armitage
Lucent Technologies
October 1997
コメントを求めるワーキンググループT.スミスの要求をネットワークでつないでください: 2226年のIBM社のカテゴリ: 標準化過程G.アーミテージルーセントテクノロジーズ1997年10月
IP Broadcast over ATM Networks
気圧ネットワークの上で放送されたIP
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1997). All Rights Reserved.
Copyright(C)インターネット協会(1997)。 All rights reserved。
Abstract
要約
This memo describes how the IP multicast service being developed by the IP over ATM working group may be used to support IP broadcast transmission. The solution revolves around treating the broadcast problem as a special case of multicast, where every host in the subnet or cluster is a member of the group.
このメモはATMワーキンググループの上でIPによって開発されるIPマルチキャストサービスがIP放送送信をサポートするのにどう利用されるかもしれないかを説明します。 ソリューションは特殊なものとして放送問題を扱いながら、マルチキャストを中心題目とします、サブネットかクラスタのすべてのホストがグループのメンバーであるところで。
An understanding of the services provided by RFC 2022 is assumed.
RFC2022によって提供されたサービスの理解は想定されます。
1. Introduction.
1. 序論。
The IETF's first step in solving the problems of running IP over Asynchronous Transfer Mode (ATM) technology is described in RFC 1577 [1]. It provides for unicast communication between hosts and routers within Logical IP Subnets (LISs), and proposes a centralized ATM ARP Server which provides IP to ATM address resolution services to LIS members.
Asynchronous Transfer Mode(ATM)技術にIPを経営しているという問題を解決することにおけるIETFの第一歩はRFC1577[1]で説明されます。 それは、Logical IP Subnets(LISs)の中にホストとルータとのユニキャストコミュニケーションに備えて、LISメンバーへのATMアドレス解決サービスにIPを提供する集結されたATM ARP Serverを提案します。
Two classes of IP service were omitted - multicast and broadcast transmissions. Multicasting allows a single transmit operation to cause a packet to be received by multiple remote destinations.
2つのクラスのIPサービスは省略されました--マルチキャストと放送送信。 マルチキャスティングは、パケットが複数の遠く離れた目的地によって受け取られることを引き起こすためにシングルが伝えるaに操作を許します。
Smith & Armitage Standards Track [Page 1] RFC 2226 IP Broadcast over ATM Networks October 1997
1997年10月に気圧ネットワークの上で放送されたスミスとアーミテージ標準化過程[1ページ]RFC2226IP
Broadcasting typically allows a single transmit operation to cause a packet to be received by all IP hosts that are members of a particular 'subnet'.
通常放送するのはシングルを許容します。操作を伝えて、パケットが特定の'サブネット'のメンバーであるすべてのIPホストによって受け取られることを引き起こしてください。
To address the need for multicast support (represented by
transmission to IP addresses in the Class D space), RFC 2022
("Support for Multicast over UNI 3.0/3.1 based ATM Networks") [2] was
created. This memo creates an analog of the RFC 1577 ARP Server - a
new entity known as the MARS (Multicast Address Resolution Server).
The MARS operates as a centralized registry and distribution
mechanism for mappings between IP multicast addresses and groups of
ATM unicast addresses. Host behavior is also defined for establishing
and managing point to multipoint VCs, based on the information
returned by the MARS, when hosts wish to transmit packets to a
multicast group.
マルチキャストサポート(Class DスペースのIPアドレスへのトランスミッションで、表される)の必要性を扱うために、RFC2022(「UNI3.0/3.1の上のMulticastのサポートはATM Networksを基礎づけた」)[2]は作成されました。 このメモはRFC1577ARP Serverのアナログを作成します--火星(マルチキャストAddress Resolution Server)として知られている新しい実体。 火星はATMユニキャストアドレスのIPマルチキャストアドレスとグループの間のマッピングのための集結された登録と分配メカニズムとして作動します。 また、ホストの振舞いは多点VCsにポイントを確立して、管理するために定義されます、火星で返された情報に基づいて、ホストがマルチキャストグループにパケットを伝えたがっているとき。
This memo aims to show how RFC 2022 may be used to emulate IP broadcast within Logical IP Subnets. While the broadcast technique does not align itself well with the underlying point-to-point nature of ATM, clearly, some applications will still wish to use IP broadcasts. Client-server applications where the client searches for a server by sending out a broadcast is one scenario. Routing protocols, most notably RIP, are other examples.
このメモは、RFC2022がLogical IP Subnetsの中で放送されたIPを見習うのにどう使用されるかもしれないかを示すことを目指します。 放送のテクニックはATMの基本的な二地点間本質にそれ自体をよく一直線にしませんが、それでも、明確に、いくつかのアプリケーションがIP放送を使用したくなるでしょう。 クライアントが放送を出すことによってサーバを捜し求めるクライアント/サーバアプリケーションは1つのシナリオです。 ルーティング・プロトコル(最も著しくRIP)は他の例です。
2. Review of Unicast and Multicast.
2. ユニキャストとマルチキャストのレビュー。
Both the unicast and multicast cases take advantage of the point-to- point and point-to-multipoint capabilities defined in the ATM Forum UNI 3.1 document [4]. A unicast IP address has a single ATM level destination. Unicast transmissions occur over point to point Virtual Channels (VCs) between the source and destination. The ARP Server holds mappings between IP destination addresses and their associated ATM destination address. Hosts issue an ARP_REQUEST to the ARP Server when they wish to ascertain a particular mapping. The ARP Server replies with either an ARP_REPLY containing the ATM address of the destination, or an ARP_NAK when the ARP Server is unable to resolve the address. If the request is successful the host establishes a VC to the destination interface. This VC is then used to forward the first (and subsequent) packets to that particular IP destination. RFC 1577 describes in further detail how hosts are administratively grouped in to Logical IP Subnets (LISs), and how the ARP Server establishes the initial mappings for members of the LIS it serves.
ユニキャストとマルチキャストケースの両方がATM Forum UNI3.1ドキュメント[4]で定義されたポイントからポイントとポイントツーマルチポイント能力を利用します。 ユニキャストIPアドレスには、単一のATM平らな目的地があります。 ユニキャスト送信はソースと目的地の間のポイント・ツー・ポイントVirtual Channels(VCs)の上に起こります。 ARP Serverは受信者IPアドレスとそれらの関連ATM送付先アドレスの間にマッピングを保持します。 彼らが特定のマッピングを確かめたがっているとき、ホストはアルプ_REQUESTをARP Serverに発行します。 ARP Serverがアドレスを決議できないとき、ARP Serverは目的地のATMアドレスを含むアルプ_REPLYかARP_NAKのどちらかと共に返答します。 要求がうまくいくなら、ホストは目的地のインタフェースにVCを設立します。 そして、このVCは、1番目の、そして、(その後)のパケットをその特定のIPの目的地に送るのに使用されます。 RFC1577は、詳細でホストでどのように行政上Logical IP Subnets(LISs)に分類されるか、そして、ARP Serverがそれが役立つLISのメンバーのためにどのように初期のマッピングを確立するかを説明します。
The basic host behavior for multicasting is similar - the sender must establish and manage a point to multipoint VC whose leaf nodes are the group's actual members. Under UNI 3.1 these VCs can only be established and altered by the source (root) interface.
マルチキャスティングのための基本的なホストの振舞いは同様です--送付者は、葉のノードがグループの実際のメンバーである多点VCにポイントを確立して、管理しなければなりません。 UNI3.1の下では、ソースの(根)インタフェースはこれらのVCsを設立して、変更できるだけです。
Smith & Armitage Standards Track [Page 2] RFC 2226 IP Broadcast over ATM Networks October 1997
1997年10月に気圧ネットワークの上で放送されたスミスとアーミテージ標準化過程[2ページ]RFC2226IP
The MARS is an evolution of the ARP Server model, and performs two key functions. The first function is the maintenance of a list of ATM addresses corresponding to the members for each group. This list is created by a host registration process which involves two messages - a MARS_JOIN which declares that a host wishes to join the specified group(s), and a MARS_LEAVE which indicates that a host wishes to leave the specified group(s).
火星は、ARP Serverモデルの発展であり、2つの主要な機能を実行します。 最初の機能はそれぞれのグループのメンバーにとって、対応するATMアドレスのリストのメインテナンスです。 このリストは2つのメッセージを伴うホスト登録手続で作成されます--ホストが指定されたグループに加わりたがっていると宣言する_JOIN火星、およびホストが指定されたグループを(s)に出たがっているのを示す_LEAVE火星。
MARS_JOIN and MARS_LEAVE messages are also redistributed to all members of the group so that active senders may dynamically adjust their point to multipoint VCs accordingly.
また、活発な送付者がダイナミックにそれに従って、多点VCsに彼らのポイントを調整できるように、火星_JOINと火星_LEAVEメッセージをグループのすべてのメンバーに再配付します。
The other major function is the retrieval of group membership from MARS (analogous to the ARP Server providing unicast address mappings). When faced with the need to transmit an IP packet with a Class D destination address, a host issues a MARS_REQUEST to the MARS. If the group has members the MARS returns a MARS_MULTI (possibly in multiple segments) carrying a set of ATM addresses. The host then establishes an initial point to multipoint VC using these ATM addresses as the leaf nodes. If the MARS had no mapping it would return a MARS_NAK.
もう片方の主要な機能は火星(ユニキャストアドレス・マッピングを提供するARP Serverに類似の)からのグループ会員資格の検索です。 Class D送付先アドレスでIPパケットを伝える必要性が直面されていると、ホストは_REQUEST火星を火星に発行します。 グループにメンバーがいるなら、火星は、1セットのATMアドレスを運びながら、_MULTI(ことによると複数のセグメントの)火星を返します。 そして、ホストは、葉のノードとしてこれらのATMアドレスを使用することで初期のポイントを多点VCに確立します。 火星に写像でないのがあるなら、それは_NAK火星を返すでしょうに。
(RFC 2022 also discusses how the MARS can arrange for Class D groups to be supported by either multicast servers, or meshes of point to multipoint VCs from host to host. However, from the host's perspective this is transparent, and is not central to this discussion of IP broadcast support.)
(また、火星が、Class Dグループがホスティングするホストからの多点VCsへのポイントのマルチキャストサーバかメッシュのどちらかによってサポートされるようにどう手配できるかについてRFC2022は議論します。 しかしながら、ホストの見解から、これは、透明であり、IP放送サポートのこの議論に主要ではありません。)
This memo describes how a host may utilize the registration and group management functions in an existing MARS based IP/ATM network to emulate IP broadcasts.
このメモはホストがIP放送を見習うのに既存の火星ベースのIP/ATMネットワークでどう登録とグループ管理機能を利用するかもしれないかを説明します。
3. Broadcast as a special case of Multicast.
3. 特殊なものとしてMulticastについて放送してください。
Many of the problems that occur when implementing a broadcast solution also occur in when implementing a multicast solution. In fact, broadcast may be considered a special case of multicast. That is, broadcast is a multicast group whose members include all members in the LIS.
またマルチキャストソリューションを実現するときソリューションが起こる放送を実装するとき起こる問題の多く。 事実上、放送はマルチキャストの特別なケースであると考えられるかもしれません。 すなわち、放送はメンバーがLISのすべてのメンバーを含んでいるマルチキャストグループです。
There are two broadcast groups which this memo addresses:
このメモが演説する2つの放送グループがあります:
1) 255.255.255.255 - "All ones" broadcast
1) 255.255.255.255 --「すべてのもの」放送
2) x.z - CIDR-prefix (subnet) directed broadcast
2)x.z--CIDR-接頭語(サブネット)の指示された放送
Smith & Armitage Standards Track [Page 3] RFC 2226 IP Broadcast over ATM Networks October 1997
1997年10月に気圧ネットワークの上で放送されたスミスとアーミテージ標準化過程[3ページ]RFC2226IP
Broadcast (1) is sometimes referred to as a limited broadcast to this physical network. Broadcast (2) can be thought of as the the broadcast for subnets or networks in the old paradigm. As described in [6] and [7], the notion of subnets and networks is being replaced with a more efficient utilization of the routing address space known as Classless Inter-Domain Routing. The CIDR-prefix (x) is the combination of IP address and subnet mask that denotes the subnet number. The host portion of the address (z) is all ones. One should note that while these broadcasts have different scopes at the IP or network layer, they have precisely the same scope at the link layer -- namely that all members of the LIS will receive a copy.
放送(1)は時々この物理ネットワークへの限られた放送と呼ばれます。 サブネットかネットワークのための放送として古い発想で放送(2)を考えることができます。 [6]と[7]で説明されるように、サブネットとネットワークの概念をClassless Inter-ドメインルート設定として知られているルーティングアドレス空間の、より効率的な利用に取り替えています。 CIDR-接頭語(x)はサブネット番号を指示するIPアドレスとサブネットマスクの組み合わせです。 アドレス(z)のホスト部分はすべてものです。 これらの放送がIPかネットワーク層で異なった範囲を持っている間、リンクレイヤに正確に同じ範囲を持っています--すなわち、LISのすべてのメンバーがコピーを受け取ることに注意するべきです。
These addresses may be used in two environments:
これらのアドレスは2つの環境で使用されるかもしれません:
o Broadcasting to all members of a given LIS where
a priori knowledge of a host's IP address and
subnet mask are known (e.g. the CIDR-prefix directed
broadcast).
o ホストのIPアドレスとサブネットマスクに関する先験的な知識が知られている与えられたLIS(例えば、CIDR-接頭語の指示された放送)のすべてのメンバーに放送します。
o Broadcasting to all members of a physical network
without knowledge of a host's IP address and
subnet mask (e.g. the all ones broadcast).
o ホストのIPアドレスとサブネットマスクに関する知識なしで物理ネットワークのすべてのメンバーに放送する、(例えば、すべてのもの放送)
On a broadcast medium like Ethernet, these two environments result in the same physical destination. That is, all stations on that network will receive the broadcast even if they are on different logical subnets, or are non-IP stations. With ATM, this may not be the case. Because ATM is non-broadcast, a registration process must take place. And if there are stations that register to some broadcast groups, but not others, then the different broadcast groups will have different memberships. The notion of broadcast becomes inconsistent.
イーサネットのような放送媒体では、これらの2つの環境が同じ物理的な目的地をもたらします。 そのネットワークのすなわちすべてのステーションが、それらが異なった論理的なサブネットにあっても放送を受けるか、または非IPステーションです。 ATMと共に、これはそうでないかもしれません。 ATMが非放送するので、登録手続は行われなければなりません。 そして、他のものではなく、いくつかの放送グループに登録されるステーションがあると、異なった放送グループには異なった会員資格があるでしょう。 放送の概念は矛盾するようになります。
One case that requires the use of the all ones broadcast is that of the diskless boot, or bootp client, where the host boots up, and does not know its own IP address or subnet mask. Clearly, the host does not know which subnet it belongs to. So, to send a broadcast to its bootp server, the diskless workstation must use the group which contains no subnet information, i.e. the 255.255.255.255 broadcast group. Carrying the example a little further, the bootp server, after receiving the broadcast, can not send either a directed frame nor a subnet directed broadcast to respond to the diskless workstation. Instead, the bootp server must also use the 255.255.255.255 group to communicate with the client.
それが使用を必要とするある場合、すべてのもの放送がディスクレスブーツ、bootpクライアント、ホストがどこで起動して、それ自身のIPアドレスを知らないか、そして、またはサブネットマスクのものです。 明確に、ホストは、それがどのサブネットに属すかを知りません。 それで、bootpサーバに放送を送るのに、ディスクレスワークステーションはサブネット情報を全く含まないグループを使用しなければなりません、すなわち、255.255に、.255が放送する.255が分類されます。 もう少し、放送を受けた後に、bootpサーバが指示されたフレームを送ることができないで、サブネットが指示した例を運ぶのは、ディスクレスワークステーションに応じるために放送されました。 また、代わりに、bootpサーバは、クライアントとコミュニケートするのに255.255.255.255グループを使用しなければなりません。
While the all ones broadcast is required at the IP layer, it also has relevance at the link layer when deciding which broadcast group to register with in MARS. In other words, a bootp client wishing to register for a link layer broadcast, can only register for
すべてのもの放送がIP層で必要です、また、火星の中にどの放送グループについてともに記名したらよいかを決めるとき、それはリンクレイヤに関連性を持っています。 言い換えればそうすることができるだけであることをリンクレイヤ放送のためのレジスタに願っているのが登録するbootpクライアント
Smith & Armitage Standards Track [Page 4] RFC 2226 IP Broadcast over ATM Networks October 1997
1997年10月に気圧ネットワークの上で放送されたスミスとアーミテージ標準化過程[4ページ]RFC2226IP
255.255.255.255 in the MARS address space because the client's subnet is unknown at the time. Given that some applications must use the all ones address in MARS for their broadcast group, and that we wish to minimize the number of broadcast groups used by LIS members, the all ones group in MARS MUST be used by all members of the LIS when registering to receive broadcast transmissions. The VCC used for transmitting any broadcast packet will be based on the members registered in the MARS under the 255.255.255.255 address position. This VCC will be referred to as the "broadcast channel" through the remainder of this memo.
255.255.255.255、火星アドレス空間、クライアントのサブネットが当時、未知であるので。 考えて、いくつかのアプリケーションがそれらの放送グループ、およびそれのための火星の中の数を最小にしたいと思うすべてのものアドレスを使用しなければならないのがLISメンバーによって使用されたグループを放送した、放送送信を受けるために登録するとき、LISのすべてのメンバーが火星の中のすべてのものグループを使用しなければなりません。 どんな放送パケットも伝えるのに使用されるVCCは255.255.255.255アドレスの位置の下の火星の中に登録されたメンバーに基づくでしょう。 このVCCはこのメモの残りを通して「放送チャンネル」と呼ばれるでしょう。
4. The MARS role in broadcast.
4. 放送における火星の役割。
Many solutions have been proposed, some of which are listed in Appendix A. This memo addresses a MARS solution which appears to do the best job of solving the broadcast problem.
多くのソリューションが提案されました、メモが放送問題を解決する最も良い仕事をするように見える火星ソリューションを扱うAppendix A.Thisに記載されているもののいくつか。
There are a number of characteristics of the MARS architecture that should be kept intact. They include:
完全に保たれるべきである火星アーキテクチャの多くの特性があります。 それらは:
o MARS contains no knowledge of subnet prefixes and subnet masks.
Each group address registered with MARS is managed independently.
o 火星はサブネット接頭語とサブネットマスクに関する知識を全く含んでいません。 火星に登録されたそれぞれのグループアドレスは独自に管理されます。
o A MARS may only serve one LIS. This insures that the
broadcast group 255.255.255.255 is joined by hosts from one
LIS, keeping its scope bound to conventional interpretation.
o 火星は1LISしか役立たないかもしれません。 これが、放送が分類されるのを保障する、255.255、.255、.255、従来の解釈に範囲を縛り続けて、ホストによって1LISから加わられます。
o The Multicast Server (MCS) described in [2] may be used to service
the broadcast groups defined in this memo without modification.
The MCS will reduce the number of channels used by the network.
o [2]で説明されたMulticast Server(MCS)は放送グループが変更なしでこのメモで定義したサービスに使用されるかもしれません。 MCSはネットワークによって使用されたチャンネルの数を減少させるでしょう。
The MARS needs no additional code or special algorithms to handle the
resolution of IP broadcast addresses. It is simply a general database
that holds {Protocol address, ATM.1, ATM.2, ... ATM.n} mappings, and
imposes no constraints on the type and length of the 'Protocol
address'. Whether the hosts view it as Class D or 'broadcast' (or
even IP) is purely a host side issue.
火星は、IP放送演説の解決を扱うためにどんな追加コードも特別なアルゴリズムも必要としません。 それは、単に{アドレスについて議定書の中で述べてください、ATM.1、ATM.2… ATM.n}というマッピングを保持する一般的なデータベースであり、'プロトコルアドレス'のタイプと長さに規制を全く課しません。 Class Dであるとそれをみなすか、または'放送する'(または、IPさえ)にかかわらず、純粋にホストは副次的な問題ですか?
It is likely that end points will want to use the IP broadcast emulation described here in order to support boot time location of the end point's IP address. This leads to the observation that the MARS should NOT expect to see both the IP source and ATM source address fields of the MARS_JOIN filled in. This is reasonable, since only the ATM source address is used when registering the end point as a group member.
エンドポイントはブート時間がエンドポイントのIPアドレスの位置であるとサポートするためにここで説明されたIP放送エミュレーションを使用したくなりそうでしょう。 これは火星が、IPソースと_JOIN火星のATMソースアドレス・フィールドの両方が記入されるのを見ると予想するはずがないという観測に通じます。 グループのメンバーとしてエンドポイントを示すとき、ATMソースアドレスだけが使用されているので、これは妥当です。
The MARS architecture is sufficient to insure the integrity of the broadcast group list without any modification.
火星アーキテクチャは、少しも変更なしで放送グループリストの保全を保障するために十分です。
Smith & Armitage Standards Track [Page 5] RFC 2226 IP Broadcast over ATM Networks October 1997
1997年10月に気圧ネットワークの上で放送されたスミスとアーミテージ標準化過程[5ページ]RFC2226IP
5. Host Requirements for Broadcast.
5. 放送のための要件を接待してください。
The following list of bullets describes additional characteristics of a MARS-compliant host. These characteristics are required to take advantage of the broadcast function.
弾丸の以下のリストは火星対応することのホストの追加特性について説明します。 これらの特性が、放送機能を利用するのに必要です。
o A host must register as a MARS client.
o ホストは火星クライアントとして登録しなければなりません。
o A host, soon after registration MUST issue a MARS_JOIN to the
all ones broadcast address (i.e. 255.255.255.255) with the
mar$flags.layer3grp reset.
o ホスト、すぐ後に登録がもの放送のアドレスに_JOIN火星を発行しなければならない、(すなわち、255.255、.255、.255)、flags.layer3grpがリセットした$を損なってください。
o When transmitting packets, the host should map all IP layer
broadcasts to the VCC (broadcast channel) created and maintained
based on the all ones entry in MARS.
o パケットを伝えるとき、ホストが作成されて、ベースに維持されたVCC(放送チャンネル)にすべてのIP層の放送を写像するべきである、すべてのものエントリー、火星の中で。
o A host MUST monitor the MARS_JOIN/MARS_LEAVE messages
for 255.255.255.255 to keep the broadcast channel current.
o ホストは255.255への火星_JOIN/火星_LEAVEメッセージをモニターしなければなりません。.255 .255 放送チャンネル電流を保つために。
o A broadcast channel should be torn down after a period of
inactivity. The corresponding timeout period MAY be specified
with a minimum value of one minute, and a RECOMMENDED
default value of 20 minutes.
o 不活発の期間の後に放送チャンネルを取りこわすべきです。 対応するタイムアウト時間は1分の最小値、および20分のRECOMMENDEDデフォルト値で指定されるかもしれません。
One should note that while every member participating in the broadcast MUST be a member of the all ones group, not all members will choose to transmit broadcast information. Some members will only elect to receive broadcast information passively. Therefore, in a LIS with n stations, there may be less than n channels terminated at each station for broadcast information. Further reductions may be gained by adding a Multicast Server (MCS) to the broadcast environment which could reduce the number of VCs to two (one incoming, one outgoing), or one for a station that only wishes to listen.
それがaがメンバーであったに違いないなら放送に参加するすべてのメンバーをゆったり過ごすことに注意するべきである、すべてのものグループ、すべてのメンバーが放送情報を伝えるのを選ぶというわけではないでしょう。 何人かのメンバーが、放送情報を受け身に受け取るのを選ぶだけでしょう。 したがって、nステーションがあるLISに、放送情報のための各ステーションで終えられたnチャンネルがあるかもしれません。 VCsの数を2まで減少させることができた放送環境にMulticast Server(MCS)を加えることによって一層の減少を獲得するかもしれない、(ある入来、1、外向的である、)、または、聴くだけでありたいステーションへの1。
It is well understood that broadcasting in this environment may tax the resources of the network and of the hosts that use it. Therefore, an implementer MAY choose to provide a mechanism for retracting the host's entry in the broadcast group after it has been established or prior to joining the group. The MARS_LEAVE is used to request withdrawal from the group if the host wishes to disable broadcast reception after it has joined the group. The default behavior SHALL be to join the all ones broadcast group in MARS.
この環境で放送するのがそれを使用するネットワークとホストのリソースに税をかけるかもしれないのがよく理解されています。 したがって、implementerは、それが設立された後に放送グループでホストのエントリーを引っ込めるか、またはグループに加わる前にメカニズムを提供するのを選ぶかもしれません。 グループに加わった後にホストが放送レセプションを無効にしたいなら、_LEAVE火星は、グループから退出を要求するのに使用されます。 デフォルトの振舞いSHALLはもの放送のグループに火星で加わることになっています。
Smith & Armitage Standards Track [Page 6] RFC 2226 IP Broadcast over ATM Networks October 1997
1997年10月に気圧ネットワークの上で放送されたスミスとアーミテージ標準化過程[6ページ]RFC2226IP
6. Implications of IP broadcast on ATM level resources.
6. ATMで放送されたIPの含意はリソースを平らにします。
RFC 2022 discusses some of the implications of large multicast groups on the allocation of ATM level resources, both within the network and within end station ATM interfaces.
RFC2022はATMの平らなリソース(ネットワークと終わりのステーションのATMインタフェースの中の両方)の配分に関する大きいマルチキャストグループの含意のいくつかについて議論します。
The default mechanism is for IP multicasting to be achieved using meshes of point to multipoint VCs, direct from source host to group members. Under certain circumstances system administrators may, in a manner completely transparent to end hosts, redirect multicast traffic through ATM level Multicast Servers (MCSs). This may be performed on an individual group basis.
デフォルトメカニズムはIPマルチキャスティングが多点VCsにポイントのメッシュを使用することで達成されることです、送信元ホストからグループのメンバーまでダイレクトです。 確信している事情システム管理者の下では、ホストを終わらせるために完全に見え透いた方法で、ATMレベルMulticast Servers(MCSs)を通してマルチキャストトラフィックを向け直すかもしれません。 これは個々グループベースに実行されるかもしれません。
It is sufficient to note here that the IP broadcast 'multicast group' will constitute the largest consumer of VCs within your ATM network when it is active. For this reason it will probably be the first multicast group to have one or more ATM MCSs assigned to support it. However, there is nothing unique about an MCS assigned to support IP broadcast traffic, so this will not be dealt with further in this memo. RFC 2022 contains further discussion on the possible application of multiple MCSs to provide fault-tolerant architectures.
ここでそれがアクティブであるときに、IP放送'マルチキャストグループ'があなたのATMネットワークの中でVCsの最も大きい消費者を構成することに注意するのは十分です。 この理由で、それはたぶんそれをサポートするために1ATM MCSsを割り当てさせる最初のマルチキャストグループになるでしょう。 しかしながら、IP放送トラフィックをサポートするために割り当てられたMCSに関してユニークなものは何もないので、これはこのメモで、より遠くに対処されないでしょう。 RFC2022は、フォールトトレラントアーキテクチャを提供するために複数のMCSsの可能なアプリケーションにさらなる議論を含んでいます。
7. Further discussion.
7. さらなる議論。
A point of discussion on the ip-atm forum revolved around "auto configuration" and "diskless boot". This memo describes a broadcast solution that requires the use of the MARS. Therefore, at a minimum, the ATM address of the MARS must be manually configured into a diskless workstation. Suggestions such as universal channel numbers, and universal ATM addresses have been proposed, however, no agreement has been reached.
ip-気圧フォーラムについての議論のポイントは「自動構成」と「ディスクレスブーツ」を中心題目としました。 このメモは火星の使用を必要とする放送対策を説明します。 したがって、最小限で、手動で火星のATMアドレスをディスクレスワークステーションに構成しなければなりません。 しかしながら、普遍的な論理機番や、普遍的なATMアドレスのような提案が提案されて、合意に達していません。
Another topic for discussion is multiprotocol support. MARS is designed for protocol independence. This memo specifically addresses the IP broadcast case, identifying which addresses are most effective in the IP address space. However, the principles apply to any layer 3 protocol. Further work should be performed to identify suitable addresses for other layer 3 protocols.
議論のための別の話題は「マルチ-プロトコル」サポートです。 火星はプロトコル独立のために設計されています。 IPアドレス空間でどのアドレスが最も効果的であるかを特定して、このメモは明確にIP放送ケースを扱います。 しかしながら、原則は3プロトコルをどんな層にも適用します。 他の層3のプロトコルのための適当なアドレスを特定するためにさらなる仕事をするべきです。
Finally, there has been support voiced for a link layer broadcast that would be independent of the layer 3 protocol. Such a solution may provide a simpler set of rules through which broadcast applications may be used. In addition, some solutions also provide for more efficient use of VCCs.
最終的に、層3のプロトコルから独立しているリンクレイヤ放送のために声に出されたサポートがありました。 そのようなソリューションは全面散布が使用されるかもしれないより簡単なセットの規則を提供するかもしれません。 また、さらに、何らかの解決法はVCCsの、より効率的な使用に備えます。
Smith & Armitage Standards Track [Page 7] RFC 2226 IP Broadcast over ATM Networks October 1997
1997年10月に気圧ネットワークの上で放送されたスミスとアーミテージ標準化過程[7ページ]RFC2226IP
Security Considerations
セキュリティ問題
This memo addresses a specific use of the MARS architecture and components to provide the broadcast function. As such, the security implications are no greater or less than the implications of using any of the other multicast groups available in the multicast address range. Should enhancements to security be required, they would need to be added as an extension to the base architecture in RFC 2022.
このメモは、放送機能を提供するために火星アーキテクチャとコンポーネントの特定的用法を扱います。 そういうものとして、セキュリティ含意は、よりすばらしくないか、またはマルチキャストアドレスで利用可能な他のマルチキャストグループのどれかを使用する含意以下が及びます。 セキュリティへの増進が必要であるなら、それらは、拡大としてRFC2022のベースアーキテクチャに追加される必要があるでしょう。
Acknowledgments
承認
The apparent simplicity of this memo owes a lot to the services provided in [2], which itself is the product of much discussion on the IETF's IP-ATM working group mailing list. Grenville Armitage worked on this document while at Bellcore.
このメモの見かけの簡単さはそれ自体でIETFのIP-ATMワーキンググループメーリングリストについての多くの議論の成果である[2]に提供されたサービスからいろいろな事を借りています。 Bellcoreにある間、グレンビルアーミテージはこのドキュメントに取り組みました。
References
参照
[1] Laubach, M., "Classical IP and ARP over ATM", RFC 1577,
December 1993.
[1]Laubachと、M.と、「気圧での古典的なIPとARP」、RFC1577、12月1993日
[2] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM
Networks", RFC 2022, November 1995.
[2] アーミテージ、G.、「UNI3.0/3.1の上のMulticastのサポートはATM Networksを基礎づけた」RFC2022、1995年11月。
[3] Deering, S., "Host Extensions for IP Multicasting", STD 5,
RFC 1112, August 1989.
[3] デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、STD5、RFC1112、1989年8月。
[4] ATM Forum, "ATM User-Network Interface Specification Version
3.0", Englewood Cliffs, NJ: Prentice Hall, September 1993.
[4] 気圧フォーラム、「気圧ユーザネットワーク・インターフェース仕様バージョン3インチ、イングルウッドがけ、ニュージャージー:」 1993年9月の新米のホール。
[5] Perez, M., Liaw, F., Grossman, D., Mankin, A., Hoffman, E. and
A. Malis, "ATM Signaling Support for IP over ATM", RFC 1755,
February 1995.
[5] ペレスとM.とLiawとF.とグロースマンとD.とマンキンとA.とホフマン、E.とA.Malis、「気圧でのIPの気圧シグナリングサポート」RFC1755(1995年2月)。
[6] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-
Domain Routing (CIDR): an Address Assignment and Aggregation
Strategy", RFC 1519, September 1993.
[6] フラー、V.、李、T.、ユー、J.、およびK.Varadhan、「以下を掘る(CIDR)階級のない相互ドメイン」 「アドレス課題と集合戦略」、RFC1519、9月1993日
[7] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812,
June 1995.
[7] ベイカー、F.、「IPバージョン4ルータのための要件」、RFC1812、1995年6月。
[8] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels, BCP 14, RFC 2119, March 1997.
[8] ブラドナー、S.、「Indicate Requirement Levels、BCP14、RFC2119、1997年3月までのRFCsにおける使用のためのキーワード。」
Smith & Armitage Standards Track [Page 8] RFC 2226 IP Broadcast over ATM Networks October 1997
1997年10月に気圧ネットワークの上で放送されたスミスとアーミテージ標準化過程[8ページ]RFC2226IP
Authors' Addresses
作者のアドレス
Timothy J. Smith Network Routing Systems, International Business Machines Corporation. N21/664 P.O.Box 12195 Research Triangle Park, NC 27709
ティモシーJ.スミスネットワークルート設定システム、IBM社。 N21/664私書箱12195リサーチトライアングル公園、NC 27709
Phone: (919) 254-4723 EMail: tjsmith@vnet.ibm.com
以下に電話をしてください。 (919) 254-4723 メールしてください: tjsmith@vnet.ibm.com
Grenville Armitage Bell Labs, Lucent Technologies. 101 Crawfords Corner Rd, Holmdel, NJ, 07733
グレンビルアーミテージベル研究所、ルーセントテクノロジーズ。 101Crawfordsが追い詰める、Holmdel、ニュージャージー 07733番目
EMail: gja@lucent.com
メール: gja@lucent.com
Smith & Armitage Standards Track [Page 9] RFC 2226 IP Broadcast over ATM Networks October 1997
1997年10月に気圧ネットワークの上で放送されたスミスとアーミテージ標準化過程[9ページ]RFC2226IP
Appendix A. Broadcast alternatives
付録A.Broadcast代替手段
Throughout the development of this memo, there have been a number of alternatives explored and discarded for one reason or another. This appendix documents these alternatives and the reason that they were not chosen.
このメモの開発の間中、何らかの理由のために探られて、捨てられた多くの選択肢がありました。 この付録はこれらの代替手段とそれらが選ばれなかった理由を記録します。
A.1 ARP Server Broadcast Solutions.
A.1 ARPサーバはソリューションを放送しました。
The ARP Server is a good candidate to support broadcasting. There is an ARP Server for every LIS. The ARP Server contains the entire LIS membership. These are fundamental ingredients for the broadcast function.
ARP Serverは放送をサポートする良い候補です。 あらゆるLISのためのARP Serverがあります。 ARP Serverは全体のLIS会員資格を含んでいます。 これらは放送機能のための基本的な成分です。
A.1.1 Base Solution without modifications to ARP Server.
A.1.1はARP Serverへの変更なしでソリューションを基礎づけます。
One may choose as an existing starting point to use only what is available in RFC 1577. That is, a host can easily calculate the range of members in its LIS based on its own IP address and subnet mask. The host can then issue an ARP Request for every member of the LIS. With this information, the host can then set up point-to-point connections with all members, or can set up a point-to-multipoint connection to all members. There you have it, the poor man's broadcast.
既存の出発点としてRFC1577で利用可能なことだけを使用するのを選ぶかもしれません。 すなわち、ホストはそれ自身のIPアドレスとサブネットマスクに基づくLISで容易にメンバーの範囲について計算できます。 そして、ホストはLISのすべてのメンバーのためにARP Requestを発行できます。 この情報で、ホストは、次に、すべてのメンバーと共に二地点間接続をセットアップできるか、またはすべてのメンバーにポイントツーマルチポイント接続をセットアップできます。 貧者は、そこでは、あなたがそれを持っているのを放送しました。
While this solution is very straight forward, it suffers from a number of problems.
このソリューションは前方で非常にまっすぐですが、それは多くの問題に苦しみます。
o The load on the ARP Server is very large. If all stations on
a LIS choose to implement broadcasting, the initial surge of ARP
Requests will be huge. Some sort of slow start sequence would be
needed.
o ARP Serverの上の負荷は非常に大きいです。 LISの上のすべてのステーションが、放送を実装するのを選ぶと、ARP Requestsの初期の大波は巨大になるでしょう。 ある種の遅れた出発系列が必要でしょう。
o The amount of resource required makes this a non-scalable
solution. The authors believe that broadcasting will require an
MCS to reduce the number of channel resources required to support
each broadcast 'group'. Using the ARP Server in this manner does
not allow an MCS to be transparently introduced. (Basic RFC1577
interfaces also do not implement the extended LLC/SNAP
encapsulation required to safely use more than one MCS).
o 必要であるリソースの量はこれを非スケーラブルなソリューションにします。 作者は、放送が、MCSがそれぞれの放送'グループ'をサポートするのに必要であるチャンネルリソースの数を減少させるのを必要とすると信じています。 ARP Serverを使用するのは、この様にMCSが透過的に導入されるのを許容しません。 (基本的なRFC1577インタフェースも、拡張LLC/SNAPが安全に1MCSを使用するのに必要であるカプセル化であると実装しません。)
o The diskless boot solution can not function in this environment
because it may be unable to determine which subnet to which it
belongs.
o 属するどのサブネットを決定できないかもしれないかので、ディスクレスブーツソリューションはこの環境で機能できません。
Smith & Armitage Standards Track [Page 10] RFC 2226 IP Broadcast over ATM Networks October 1997
1997年10月に気圧ネットワークの上で放送されたスミスとアーミテージ標準化過程[10ページ]RFC2226IP
A.1.2 Enhanced ARP Server solution.
A.1.2はARP Serverソリューションを高めました。
This solution is similar to the base solution except that it takes some of the (MARS) multicast solution and embeds it in the ARP Server. The first enhancement is to add the MARS_MULTI command to the set of opcodes that the ARP Server supports. This would allow a host to issue a single request, and to get back the list of members in one or more MARS_REPLY packets. Rather than have a registration mechanism, the ARP Server could simply use the list of members that have already been registered. When a request comes in for the subnet broadcast address, the ARP Server would aggregate the list, and send the results to the requester.
(火星)マルチキャストソリューションのいくつか取って、それをARP Serverに埋め込むのを除いて、このソリューションは基礎液と同様です。最初の増進は火星_MULTIコマンドをARP Serverがサポートするopcodesのセットに追加することです。 これで、ホストは、ただ一つの要求を出して、1つ以上の火星_REPLYパケットで会員名簿を取り戻すでしょう。 むしろ、ARP Serverは登録メカニズムを持っているより単に既に登録されたメンバーのリストを使用できました。 要求がサブネット放送演説を相続するとき、ARP Serverはリストに集めて、結果をリクエスタに送るでしょう。
This suffers from two drawbacks.
これは2つの欠点に苦しみます。
1) Scalability with regard to number of VCs is still an issue.
One would eventually need to add in some sort of multicast
server solution to the ARP Server.
1) VCsの数に関するスケーラビリティは問題です。 人は、結局、ある種のマルチキャストサーバソリューションをARP Serverに加える必要があるでしょう。
2) The diskless boot scenario is still broken. There is no
way for a station to perform a MARS_MULTI without first
knowing its IP address and subnet mask.
2) ディスクレスブーツシナリオはまだ壊れています。 ステーションが最初にそのIPアドレスとサブネットマスクを知らないで_MULTI火星を実行する方法が全くありません。
The diskless boot problem could be solved by adding to the ARP Server a registration process where anyone could register to the 255.255.255.255 address. These changes would make the ARP Server look more and more like MARS.
だれでも.255.255アドレスを255.255に登録できた登録手続をARP Serverに加えることによって、ディスクレスブーツ問題を解決できるでしょう。 これらの変化で、ARP Serverはますます火星に似ているでしょう。
A.2 MARS Solutions.
A.2はソリューションを損ないます。
If we wish to keep the ARP Server constant as described in RFC 1577, the alternative is to use the Multicast Address Resolution Server (MARS) described in [2].
RFC1577で説明されるようにARP Serverを一定に保ちたいと思うなら、代替手段は[2]で説明されたMulticast Address Resolution Server(火星)を使用することです。
MARS has three nice features for broadcasting.
火星には、放送のための3つの良い特徴があります。
1) It has a generalized registration approach which allows
for any address to have a group of entities registered.
So, if the subnet address is not known, a host can
register for an address that is known (e.g. 255.255.255.255).
1) それには、どんなアドレスでも実体のグループを登録するのを許容する一般化された登録アプローチがあります。 したがって、サブネットアドレスが知られていないなら、ホストが知られているアドレスに登録できる、(例えば、255.255 .255 .255)。
2) The command set allows for lists of members to be passed
in a single MARS_MULTI packet. This reduces traffic.
2) コマンドセットで、メンバーの繰返し要素の並びは単一の火星_MULTIパケットを通ります。 これはトラフィックを減少させます。
3) MARS contains an architecture for dealing with the
scalability issues. That is, Multicast Servers (MCSs)
may be used to set up the point-to-multipoint channels
3) 火星はスケーラビリティ問題に対処するためのアーキテクチャを含んでいます。 すなわち、Multicast Servers(MCSs)は、ポイントツーマルチポイントチャンネルをセットアップするのに使用されるかもしれません。
Smith & Armitage Standards Track [Page 11] RFC 2226 IP Broadcast over ATM Networks October 1997
1997年10月に気圧ネットワークの上で放送されたスミスとアーミテージ標準化過程[11ページ]RFC2226IP
and reduce the number of channels that a host needs to
set up to one. Hosts wishing to broadcast will instead
send the packet to the MCS who will then forward it to
all members of the LIS.
そして、ホストが1つを設定する必要があるチャンネルの数を減少させてください。 放送したがっているホストが代わりに次にLISのすべてのメンバーにそれを送るMCSにパケットを送るでしょう。
A.2.1. CIDR-prefix (Subnet) Broadcast solution.
A.2.1。 CIDR-接頭語(サブネット)は解決策を放送しました。
One of the earliest solutions was to simply state that broadcast support would be implemented by using a single multicast group in the class D address space -- namely, the CIDR-prefix (subnet) broadcast address group. All members of a LIS would be required to register to this address, and use it as required. A host wishing to use either the 255.255.255.255 broadcast, or the network broadcast addresses would internally map the VC to the subnet broadcast VC. The all ones and network broadcast addresses would exist on MARS, but would be unused.
最も初期の解決策の1つは放送サポートがクラスDアドレス空間にただ一つのマルチキャストグループを使用することによって実行されると単に述べることでした--すなわち、CIDR-接頭語(サブネット)放送演説グループ。 LISのすべてのメンバーが、このアドレスに登録して、必要に応じてそれを使用するのに必要でしょう。 255.255.255.255放送かネットワーク放送アドレスのどちらかを使用したがっているホストは内部的にサブネット放送VCにVCを写像するでしょう。 すべてのものとネットワーク放送アドレスは、火星に存在しているでしょうが、未使用でしょう。
The problem with this approach goes back to the diskless workstation problem. Because the workstation may not know which subnet it belongs to, it doesn't know which group to register with.
このアプローチに関する問題はディスクレスワークステーション問題に戻ります。 ワークステーションが、それがどのサブネットに属すかを知らないかもしれないので、それは、どのグループについてともに記名したらよいかを知りません。
A.2.2. All one's first, subnet broadcast second
A.2.2。 最初にサブネットが2番目に、放送したすべてのもの
This solution acknowledges that the diskless boot problem requires a generic address (one that does not contain CIDR-prefix (subnet) information) to register with and to use until subnet knowledge is known. In essence, all stations first register to the 255.255.255.255 group, then as they know their subnet information, they could optionally de-register from the all one's group and register to the CIDR-prefix (subnet) broadcast group.
この解決策は、ディスクレスブーツ問題がサブネット知識が知られるまで使用と使用に登録するために、一般的なアドレス(CIDR-接頭語(サブネット)情報を含まないもの)を必要とすると認めます。 本質では、すべてが255.255.255.255グループに最初のレジスタを配置します、そして、彼らが自分達のサブネット情報を知っているように任意に反-登録していた状態で分類できた、CIDR-接頭語(サブネット)放送へのすべての人のグループとレジスタは分類されます。
This solution would appear to solve a couple of problems:
この解決策は2、3の問題を解決するように見えるでしょう:
1) The bootp client can function if the server remains
registered to the all one's group continuously.
1) サーバが登録されたままで残っているならbootpクライアントが機能できる、すべての1つが絶え間なく分類します。
2) There will be less traffic using the all ones group
because the preferred transactions will be on the
subnet broadcast channel.
2) 使用されるより少ない交通がある、サブネット放送チャンネルの上に都合のよい取引があるので、すべてのものが分類されます。
Unfortunately the first bullet contains a flaw. The server must continually be registered to two groups -- the all ones group and the subnet broadcast group. If this server has multiple processes that are running different IP applications, it may be difficult for the link layer to know which broadcast VC to use. If it always uses the all ones, then it will be missing members that have removed themselves from the all ones and have registered to the subnet broadcast. If it always uses the subnet broadcast group, the
残念ながら、最初の弾丸は欠点を含んでいます。 絶えずサーバを2つのグループまで登録しなければなりません--、すべてのものグループとサブネット放送は分類されます。 このサーバに異なったIPアプリケーションを実行している複数の過程があるなら、リンクレイヤに、どの放送VCを使用したらよいかを知るのは難しいかもしれません。 そして、いつも使用する、すべてのもの、次に、立ち退いて、行方不明のそうしたメンバーになる、すべてのもの、サブネット放送に登録しました。 いつもサブネット放送を使用するなら、分類してください。
Smith & Armitage Standards Track [Page 12] RFC 2226 IP Broadcast over ATM Networks October 1997
1997年10月に気圧ネットワークの上で放送されたスミスとアーミテージ標準化過程[12ページ]RFC2226IP
diskless boot scenario gets broken. While making the decision at the link layer may require additional control flows be built into the path, it may also require the rewriting of application software.
ディスクレスブーツシナリオは壊れています。 リンクレイヤで決定をするのが追加コントロール流れを必要としているかもしれない間、経路は組み込まれてください、そして、また、それはアプリケーション・ソフトの書き直しを必要としてもよいです。
In some implementations, a simple constant is used to indicate to the link layer that this packet is to be transmitted to the broadcast "MAC" address. The assumption is that the physical network broadcast and the logical protocol broadcast are one and the same. As pointed out earlier, this is not the case with ATM. Therefore applications would need to specifically identify the subnet broadcast group address to take advantage of the smaller group.
いくつかの実現では、簡単な定数は、このパケットが「Mac」という放送アドレスに伝えられることになっているのをリンクレイヤに示すのに使用されます。 仮定は物理ネットワーク放送と論理的なプロトコル放送が全く同じであるということです。 より早く指摘されるように、これはATMがあるそうではありません。 したがって、アプリケーションは、より小さいグループを利用するために明確にサブネット放送グループアドレスを特定する必要があるでしょう。
These problems could be solved in a number of ways, but it was thought that they added unnecessarily to the complexity of the broadcast solution.
多くの方法でこれらの問題を解決できましたが、不必要に放送対策の複雑さに加えたと思われました。
Appendix B. Should MARS Be Limited to a Single LIS?
付録、B. 火星は独身のLISに制限されるべきですか?
RFC 2022 explicitly states that a network administrator MUST ensure that each LIS is served by a separate MARS, creating a one-to-one mapping between cluster and a unicast LIS. But, it also mentions that relaxation of this restriction MAY occur after future research warrants it. This appendix discusses some to the potential implications to broadcast should this restriction be removed.
RFC2022は、ネットワーク管理者が、各LISが別々の火星のそばで役立たれているのを保証しなければならないと明らかに述べます、クラスタとユニキャストの間でLISを写像する一対一を作成して。 しかし、また、それは、今後の研究がそれを保証した後にこの制限の緩和が起こるかもしれないと言及します。 この制限を取り除くなら、この付録は、放送するために潜在的含意といくつかについて議論します。
The most obvious change would be that the notion of a cluster would span more than one LIS. Therefore, the broadcast group of 255.255.255.255 would contain members from more than one LIS.
最も明白な変化はクラスタの概念が1LISにかかっているだろうということでしょう。 したがって、放送は255.255を分類します。.255 .255 1LISからのメンバーを含むでしょう。
It also should be emphasized that the one LIS limitation is not a restriction of the MARS architecture. Rather, it is only enforced if an administrator chooses to do so.
また、1つのLIS制限が火星構造の制限でないと強調されるべきです。 むしろ、管理者が、そうするのを選ぶ場合にだけ、それは実施されます。
Smith & Armitage Standards Track [Page 13] RFC 2226 IP Broadcast over ATM Networks October 1997
1997年10月に気圧ネットワークの上で放送されたスミスとアーミテージ標準化過程[13ページ]RFC2226IP
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1997). All Rights Reserved.
Copyright(C)インターネット協会(1997)。 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 implmentation may be prepared, copied, published andand 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.
それに関するこのドキュメントと翻訳をコピーして、他のものに提供するかもしれません、そして、そうでなければ、implmentationを批評するか、それについて説明するか、または補助する派生している作品は全体か一部分配された、準備されて、コピーされて、発行されたandandであるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネット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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Smith & Armitage Standards Track [Page 14]
スミスとアーミテージ標準化過程[14ページ]
一覧
スポンサーリンク
