RFC2090 日本語訳

Network Working Group                                       A. Emberson
Request for Comments: 2090                   Lanworks Technologies Inc.
Category: Experimental                                    February 1997

コメントを求めるワーキンググループA.エンバーソンの要求をネットワークでつないでください: 2090年のLanworks技術株式会社カテゴリ: 実験的な1997年2月

                         TFTP Multicast Option

TFTPマルチキャストオプション

Status of this Memo

このMemoの状態

   This memo defines an Experimental Protocol for the Internet
   community.  This memo does not specify an Internet standard of any
   kind.  Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 このメモはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。

Abstract

要約

   The Trivial File Transfer Protocol [1] is a simple, lock-step, file
   transfer protocol which allows a client to get or put a file onto a
   remote host.

トリビアル・ファイル転送プロトコル[1]はクライアントがリモートホストにファイルを届けるか、または置く簡単で、堅苦しいファイル転送プロトコルです。

   This document describes a new TFTP option. This new option will allow
   the multiple clients to receive the same file concurrently through
   the use of Multicast packets. The TFTP Option Extension mechanism is
   described in [2].

このドキュメントは新しいTFTPオプションについて説明します。 この新しいオプションで、複数のクライアントが同時にMulticastパケットの使用で同じファイルを受け取ることができるでしょう。 TFTP Option Extensionメカニズムは[2]で説明されます。

   Often when similar computers are booting remotely they will each
   download the same image file. By adding multicast into the TFTP
   option  set,  two  or  more  computers  can  download  a  file
   concurrently, thus increasing network efficiency.

同様のコンピュータが離れて穂ばらみであるときに、しばしば、それらはそれぞれ同じイメージ・ファイルをダウンロードするでしょう。 TFTPオプションへのマルチキャストがセットしたと言い足すことによって、2台以上のコンピュータが同時にファイルをダウンロードできます、その結果、ネットワーク効率を増強します。

   This document assumes that the reader is familiar with the
   terminology and notation of both [1] and [2].

このドキュメントは、読者が[1]と[2]の両方の用語と記法に詳しいと仮定します。

Multicast Option Specification

マルチキャストオプション仕様

   The TFTP Read Request packet is modified to include the multicast
   option as follows:

TFTP Read Requestパケットは以下のマルチキャストオプションを含むように変更されます:

      +--------+----~~----+---+--~~--+---+-----------+---+---+
      |  opc=1 | filename | 0 | mode | 0 | multicast | 0 | 0 |
      +--------+----~~----+---+--~~--+---+-----------+---+---+

+--------+----~~----+---+--~~--+---+-----------+---+---+ | opc=1| ファイル名| 0 | モード| 0 | マルチキャスト| 0 | 0 | +--------+----~~----+---+--~~--+---+-----------+---+---+

   opc
      The opcode field contains a 1, for Read Requests, as defined
      in [1].

opcodeがさばくopcは[1]で定義されるようにRead Requestsのための1を含んでいます。

Emberson                      Experimental                      [Page 1]

RFC 2090                 TFTP Multicast Option             February 1997

[1ページ]RFC2090TFTPマルチキャストオプション1997年2月に実験的なエンバーソン

   filename
      The name of the file to be read, as defined in [1]. This is a
      NULL-terminated field.

ファイル名、[1]で定義されるような読まれるファイルの名前。 これはNULLによって終えられた分野です。

   mode
      The mode of the file transfer: "netascii", "octet", or
      "mail", as defined in [1]. This is a NULL-terminated field.

モード、ファイル転送の方法: [1]の"netascii"、「八重奏」、または定義されるとしての「メール。」 これはNULLによって終えられた分野です。

   multicast
      Request  for  multicast  transmission  of  the  file  option,
      "multicast" (case insensitive). This is a NULL-terminated
      field. The value for this option request is a string of zero
      length.

ファイルオプションのマルチキャスト送信のためのマルチキャストRequest、「マルチキャスト。」(大文字と小文字を区別しない) これはNULLによって終えられた分野です。 このオプション要求のための値はゼロ・レングスのストリングです。

   If the server is willing to accept the multicast option, it
   sends an Option Acknowledgment (OACK) to the client including
   the multicast option, as defined in [2]. The OACK to the client
   will specify the multicast address and flag to indicate whether
   that client should send block acknowledgments (ACK).

サーバが、マルチキャストオプションを受け入れても構わないと思っているなら、Option Acknowledgment(OACK)をマルチキャストオプションを含むクライアントに送ります、[2]で定義されるように。 クライアントへのOACKは、そのクライアントがブロック承認(ACK)を送るべきであるかどうかを示すためにマルチキャストアドレスと旗を指定するでしょう。

     +-------+-----------+---+-------~~-------+---+
     |  opc  | multicast | 0 | addr, port, mc | 0 |
     +-------+-----------+---+-------~~-------+---+

+-------+-----------+---+-------~~-------+---+ | opc| マルチキャスト| 0 | addr、ポート、mc| 0 | +-------+-----------+---+-------~~-------+---+

   opc
      The  opcode  field  contains  the  number  6,  for  Option
      Acknowledgment, as defined in [2].

opcodeがさばくopcは[2]で定義されるようにOption AcknowledgmentのNo.6を含んでいます。

   multicast
      Acknowledges the multicast option. This is a NULL-terminated
      field.

マルチキャストがゆだねるマルチキャストAcknowledges。 これはNULLによって終えられた分野です。

   addr
      The addr field contains the multicast IP address. This field
      is terminated with a comma.

addrがさばくaddrはマルチキャストIPアドレスを含んでいます。 この分野はコンマで終えられます。

   port
      The port field contains the destination port of the multicast
      packets. The use of Registered Port number 1758 (tftp-mcast)
      is recommended. This field is terminated with a comma.

ポートがさばくポートはマルチキャストパケットの仕向港を含んでいます。 Registered Port No.1758(tftp-mcast)の使用はお勧めです。 この分野はコンマで終えられます。

   mc
      This field will be either 0 or 1, to tell the client whether
      it is the master client, that is, it is responsible for
      sending ACKs to the server. This is NULL-terminated field.

Thisがさばくmcがそれがマスタークライアントであるかどうかクライアントに言うために0か1になる、すなわち、それはACKsをサーバに送るのに責任があります。これはNULLによって終えられた分野です。

Emberson                      Experimental                      [Page 2]

RFC 2090                 TFTP Multicast Option             February 1997

[2ページ]RFC2090TFTPマルチキャストオプション1997年2月に実験的なエンバーソン

Data Transfer

データ転送

   After the OACK is received by the client it will send an ACK for
   packet zero, as in [2]. With the multicast option being accepted this
   ACK will indicate to the server that the client wants the first
   packet. In other words the ACKs may now be seen as a request for the
   n+1th block of data. This enables each a client to request any block
   within the file that it may be missing.

OACKがクライアントによって受け取られた後に、それはパケットゼロのために[2]のようにACKを送るでしょう。 マルチキャストオプションを受け入れていて、このACKは、クライアントが最初のパケットが欲しいのをサーバに示すでしょう。 言い換えれば、ACKsは現在、データのn+最初のブロックに関する要求として目にふれているかもしれません。 これは、クライアントが、ファイルの中でそれがなくなるかもしれないようどんなブロック要求するもそれぞれ可能にします。

   To manage the data transfer the server will maintain a list of
   clients. Typically the oldest client on the list, from here on
   referred to as the Master Client, will be responsible for sending
   ACKs. When the master client is finished, the server will send
   another OACK to the next oldest client, telling it to start sending
   ACKs. Upon receipt of this OACK the new master client will send an
   ACK for the block immediately before the first block required to
   complete its download.

データ転送を管理するために、サーバは顧客リストを維持するでしょう。 通常これからMaster Clientと呼ばれたリストで最も年取ったクライアントは送付ACKsに責任があるでしょう。 マスタークライアントが終わっているとき、サーバは次の最も年取ったクライアントに別のOACKを送るでしょう、ACKsを送り始めるようにそれに言って。 このOACKを受け取り次第、最初のブロックがダウンロードを終了するのが必要である直前新しいマスタークライアントはACKをブロックに送るでしょう。

   Any subsequent clients can start receiving blocks of a file during a
   transfer and then request any missing blocks when that client becomes
   the master client. When the current master client is finished, the
   server will notify the next client with an OACK making it the new
   master client. The new master client can start requesting  missed
   packets.  Each  client  must  terminate  the transfer by sending an
   acknowledgment of the last packet or by sending an error message to
   server. This termination can occur even if the client is not the
   master client.

そのクライアントがマスタークライアントになると、どんなその後のクライアントも、転送の間、ファイルのブロックを受け取り始めて、次に、どんななくなったブロックも要求できます。 現在のマスタークライアントが終わっているとき、サーバはOACKがそれを新しいマスタークライアントにしている次のクライアントに通知するでしょう。 新しいマスタークライアントは、逃されたパケットを要求し始めることができます。 各クライアントは、最後のパケットの承認を送るか、またはエラーメッセージをサーバに送ることによって、転送を終えなければなりません。この終了はクライアントがマスタークライアントでなくても起こることができます。

   Any subsequent OACKs to a client may have an empty multicast address
   and port fields, since this information will already be held by that
   client. In the event a client fails to respond in a timely manner to
   a OACK enabling it as the master client, the server shall select the
   next oldest client to be the master client. The server shall
   reattempt to send a OACK to the non- responding client when the new
   master client is finished. The server may cease communication with a
   client after a reasonable number of attempts.

クライアントへのどんなその後のOACKsも空のマルチキャストアドレスを持って、野原を移植するかもしれません、この情報がそのクライアントによって既に保持されるので。 クライアントがマスタークライアントとしてそれを可能にするOACKに直ちに反応させないイベントでは、サーバは、次の最も年取ったクライアントがマスタークライアントであることを選択するものとします。 サーバは、新しいマスタークライアントが終わっているとき、非応じているクライアントにOACKを送るために「再-試み」られるものとします。 サーバは相当な数の試みの後にクライアントとのコミュニケーションをやめるかもしれません。

   Each transfer will be given a multicast address for use to distribute
   the data packets. Since there can be multiple servers on a given
   network or a limited number of addresses available to a given server,
   it is possible that their might be more than one transfer using a
   multicast address. To ensure that a client only accepts the correct
   packets, each transfer must use a unique port on the server. The
   source IP address and port number will identify the data packets for
   the transfer. Thus the server must send the unicast OACK packet to
   the client using the same port as will be used for sending the
   multicast data packets.

使用がデータ・パケットを分配するように、マルチキャストアドレスを各転送に与えるでしょう。 複数のサーバが当然のことのサーバに利用可能なアドレスの当然のことのネットワークか限られた数にあることができるので、それらの力がマルチキャストアドレスを使用する1回以上の転送であることが可能です。 クライアントが正しいパケットを受け入れるだけであるのを保証するのに、各転送はサーバのユニークなポートを使用しなければなりません。ソースIPアドレスとポートナンバーは転送のためにデータ・パケットを特定するでしょう。 したがって、サーバは、マルチキャストデータ・パケットを送るのに使用するように同じポートを使用することでユニキャストOACKパケットをクライアントに送らなければなりません。

Emberson                      Experimental                      [Page 3]

RFC 2090                 TFTP Multicast Option             February 1997

[3ページ]RFC2090TFTPマルチキャストオプション1997年2月に実験的なエンバーソン

   At any point if a client, other than the master client, sends a ACK
   to the server, the server will respond with another OACK with the mc
   field holding a value of zero. If this client persists in sending
   erroneous ACKs, the server may send an error packet to the client,
   discontinuing the file transfer for that client.

任意な点では、マスタークライアントを除いて、クライアントがACKをサーバに送ると、mc分野がゼロの値を保持している状態で、サーバが別のOACKと共に反応するでしょう。 このクライアントが送付の誤ったACKsに固執するなら、サーバは誤りパケットをクライアントに送るかもしれません、そのクライアントのためにファイル転送を中止して。

   The server may also send unicast packets to a lone client to reduce
   adverse effects on other machines. As it is possible that machines
   may be forced to process many extraneous multicast packets when
   attempting to receive a single multicast address.

また、サーバは、他のマシンへの悪影響を抑えるためにユニキャストパケットをひとりのクライアントに送るかもしれません。 ただ一つのマルチキャストアドレスを受け取るのを試みるとき、マシンがやむを得ず多くの異質なマルチキャストパケットを処理するのが、可能であるときに。

Example

例

           clients                                      server  message
           ------------------------------------------------------------
    1  C1  |1|afile|0|octet|0|multicast|0|0| ->                  RRQ
    2                C1 <- |6|multicast|224.100.100.100,1758,1|  OACK
    3  C1  |4|0| ->                                              ACK
    4                          M <- |3|1|1| 512 octets of data|  DATA
    5  C1  |4|1| ->                                              ACK
    6                          M <- |3|2|1| 512 octets of data|  DATA
    7  C2  |1|afile|0|octet|0|multicast|0|0| ->                  RRQ
    8                C2 <- |6|multicast|224.100.100.100,1758,0|  OACK
    9  C2  |4|0| ->                                              ACK
   10  C1  |4|2| ->                                              ACK
   11                          M <- |3|3|1| 512 octets of data|  DATA
   12  C3  |1|afile|0|octet|0|multicast|0|0| ->                  RRQ
   13                C3 <- |6|multicast|224.100.100.100,1758,0|  OACK
   14  C1  |4|3| ->                                              ACK
   15  C2  |4|0| ->                                              ACK
   16              M (except C2) <- |3|4|1| 512 octets of data|  DATA
   17  C1  |4|4| ->                                              ACK
   18                          M <- |3|5|1| 512 octets of data|  DATA
   19  C1  |4|5| ->                                              ACK
   20                          M <- |3|6|1| 100 octets of data|  DATA
   21  C1  |4|6| ->                                              ACK
   22                                   C2 <- |6|multicast|,,1|  OACK
   23  C2  |4|0| ->                                              ACK
   24                          M <- |3|1|1| 512 octets of data|  DATA
   25  C2  |4|1| ->                                              ACK
   26                          M <- |3|2|1| 512 octets of data|  DATA
   27  C2  |4|3| ->                                              ACK
   28                          M <- |3|4|1| 512 octets of data|  DATA
   29  C2  |4|6| ->                                              ACK
   30                                   C3 <- |6|multicast|,,1|  OACK
   31  C3  |4|2| ->                                              ACK
   32                          M <- |3|3|1| 512 octets of data|  DATA
   33  C3  |4|6| ->                                              ACK

クライアントサーバメッセージ------------------------------------------------------------ 1 C1|1|afile|0|八重奏|0|マルチキャスト|0|0| ->RRQ2C1<。|6|マルチキャスト|224.100.100.100,1758,1| OACK3C1|4|0| ->ACK4M<。|3|1|1| データの512の八重奏| データ5C1|4|1| ->ACK6M<。|3|2|1| データの512の八重奏| データ7C2|1|afile|0|八重奏|0|マルチキャスト|0|0| ->RRQ8C2<。|6|マルチキャスト|224.100.100.100,1758,0| OACK9C2|4|0| ->ACK10C1|4|2| ->ACK11M<。|3|3|1| データの512の八重奏| データ12C3|1|afile|0|八重奏|0|マルチキャスト|0|0| ->RRQ13C3<。|6|マルチキャスト|224.100.100.100,1758,0| OACK14C1|4|3| ->ACK15C2|4|0| ->ACK16M(C2を除いた)<。|3|4|1| データの512の八重奏| データ17C1|4|4| ->ACK18M<。|3|5|1| データの512の八重奏| データ19C1|4|5| ->ACK20M<。|3|6|1| データの100の八重奏| データ21C1|4|6| ->ACK22C2<。|6|マルチキャスト|,,1| OACK23C2|4|0| ->ACK24M<。|3|1|1| データの512の八重奏| データ25C2|4|1| ->ACK26M<。|3|2|1| データの512の八重奏| データ27C2|4|3| ->ACK28M<。|3|4|1| データの512の八重奏| データ29C2|4|6| ->ACK30C3<。|6|マルチキャスト|,,1| OACK31C3|4|2| ->ACK32M<。|3|3|1| データの512の八重奏| データ33C3|4|6| ->ACK

Emberson                      Experimental                      [Page 4]

RFC 2090                 TFTP Multicast Option             February 1997

[4ページ]RFC2090TFTPマルチキャストオプション1997年2月に実験的なエンバーソン

      Comments:
         1  request from client 1
         2  option acknowledgment
         3  acknowledgment for option acknowledgment,
            or request for first block of data
         4  first data packet sent to the multicast address
         7  request from client 2
         8  option acknowledgment to client 2,
            send no acknowledgments
         9  OACK acknowledgment from client 2
         15 OACK acknowledgment from client 3
         16 client 2 fails to receive a packet
         21 client 1 acknowledges receipt of the last block,
            telling the server it is done
         23 option acknowledgment to client 2,
            now the master client
         25 client 2 acknowledging with request for first block
         27 client 2 acknowledges with request for missed block
         29 client 2 signals it is finished
         31 client 3 is master client and asks for missing blocks
         33 client 3 signals it is finished

コメント: 1 クライアント1 2オプション承認からオプション承認のための3承認を要求するか、最初に、データ・パケットがマルチキャストアドレス7に送った4がクライアントからクライアント2に2 8オプション承認を要求するようデータの最初のブロックに要求してください、そして、またはクライアント3 16クライアント2からのクライアント2 15OACK承認からの9OACK承認が受けない承認に全く21クライアント1が、最終領収書が妨げると認めるパケットを送ってください; 23オプション承認をクライアント2にするとサーバに言って、最初に、ブロック27クライアント2が、行方不明のブロック29クライアント2信号に関する要求でそれが終わっている31クライアント3であると認めるので、現在の要求によるマスタークライアント25クライアント2承認は、マスタークライアントであり、3が終わるのをそれに示すなくなったブロック33クライアントを求めます。

Conclusion

結論

   With the use of the multicast and blocksize[3] options TFTP will be
   capable of fast and efficient downloads of data. Using TFTP with the
   multicast option will maintain backward compatibility for both
   clients and servers.

マルチキャストとblocksize[3]オプションの使用で、TFTPはデータの速くて効率的なダウンロードができるでしょう。 マルチキャストオプションがあるTFTPを使用すると、後方の互換性はクライアントとサーバの両方のために維持されるでしょう。

Security Considerations

セキュリティ問題

   Security issues are not discussed in this memo.

このメモで安全保障問題について議論しません。

References

参照

   [1] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC
       1350, MIT, July 1992.

[1]Sollins、K.、「TFTPプロトコル(改正2)」、STD33、RFC1350、MIT、1992年7月。

   [2] Malkin, G., and A. Harkin, "TFTP Option Extension", RFC
       1782, Xylogics, Inc., Hewlett Packard Co., March 1995.

[2] マルキン、G.とA.ハーキン、「TFTPオプション拡張子」、RFC1782、Xylogics Inc.、ヒューレットパッカード社、1995年3月。

   [3] Malkin, G., and A. Harkin, "TFTP Blocksize Option", RFC
       1783, Xylogics, Inc., Hewlett Packard Co., March 1995.

[3] マルキン、G.とA.ハーキン、「TFTP Blocksizeオプション」、RFC1783、Xylogics Inc.、ヒューレットパッカード社、1995年3月。

Emberson                      Experimental                      [Page 5]

RFC 2090                 TFTP Multicast Option             February 1997

[5ページ]RFC2090TFTPマルチキャストオプション1997年2月に実験的なエンバーソン

Author's Address

作者のアドレス

   A. Thomas Emberson
   Lanworks Technologies, Inc.
   2425 Skymark Avenue
   Mississauga, Ontario
   Canada L4W 4Y6

A.トーマスエンバーソンLanworks技術Inc.2425Skymark Avenueオンタリオミシソーガ(カナダ)L4W 4Y6

   Phone: (905) 238-5528
   EMail: tom@lanworks.com

以下に電話をしてください。 (905) 238-5528 メールしてください: tom@lanworks.com

Emberson                      Experimental                      [Page 6]

エンバーソンExperimentalです。[6ページ]