RFC893 日本語訳

Network Working Group                                  Samuel J. Leffler
Request for Comments: 893                              Michael J. Karels
                                    University of California at Berkeley
                                                              April 1984

コメントを求めるワーキンググループサミュエルのJ.レフラーの要求をネットワークでつないでください: 893 マイケルJ.Karelsカリフォルニア大学バークレイ校1984年4月

                         Trailer Encapsulations

トレーラカプセル化

Status of this Memo

このMemoの状態

   This RFC discusses the motivation for use of "trailer encapsulations"
   on local-area networks and describes the implementation of such an
   encapsulation on various media.  This document is for information
   only.  This is NOT an official protocol for the ARPA Internet
   community.

このRFCはローカル・エリア・ネットワークで「トレーラカプセル化」の使用に関する動機について議論して、様々なメディアでそのようなカプセル化の実装について説明します。 このドキュメントは情報だけのためのものです。 これはARPAインターネットコミュニティのための公式のプロトコルではありません。

Introduction

序論

   A trailer encapsulation is a link level packet format employed by
   4.2BSD UNIX (among others).  A trailer encapsulation, or "trailer",
   may be generated by a system under certain conditions in an effort to
   minimize the number and size of memory-to-memory copy operations
   performed by a receiving host when processing a data packet.
   Trailers are strictly a link level packet format and are not visible
   (when properly implemented) in any higher level protocol processing.
   This note cites the motivation behind the trailer encapsulation and
   describes the trailer encapsulation packet formats currently in use
   on 3 Mb/s Experimental Ethernet, 10 Mb/s Ethernet, and 10 Mb/s V2LNI
   ring networks [1].

トレーラカプセル化は(特に)の4.2BSD UNIXによって使われたリンク・レベルパケット・フォーマットです。 トレーラカプセル化、または「トレーラ」がシステムによって一定の条件の下で取り組みで生成されて、メモリからメモリへのコピーデータ・パケットを処理するとき受信ホストによって実行された操作の数とサイズを最小にするかもしれません。 トレーラは、厳密に、リンクがパケット・フォーマットを平らにするということであり、どんなより高いレベルでも目に見える(適切に実装されると)プロトコル処理ではありません。 この注意は、3Mb/sのExperimentalイーサネット、10Mb/sのイーサネット、および10Mb/s V2LNIのリングネットワーク[1]でトレーラカプセル化の後ろで動機を引用して、現在使用中のトレーラカプセル化パケット・フォーマットについて説明します。

   The use of a trailer encapsulation was suggested by Greg Chesson, and
   the encapsulation described here was designed by Bill Joy.

トレーラカプセル化の使用はグレッグChessonによって勧められました、そして、ここで説明されたカプセル化はビル・ジョイによって設計されました。

Motivation

動機

   Trailers are motivated by the overhead which may be incurred during
   protocol processing when one or more memory to memory copies must be
   performed.  Copying can be required at many levels of processing,
   from moving data between the network medium and the host's memory, to
   passing data between the operating system and user address spaces.
   An optimal network implementation would expect to incur zero copy
   operations between delivery of a data packet into host memory and
   presentation of the appropriate data to the receiving process.  While
   many packets may not be processed without some copying operations,
   when the host computer provides suitable memory management support it
   may often be possible to avoid copying simply by manipulating the
   appropriate virtual memory hardware.

トレーラはメモリコピーへの1つ以上のメモリを実行しなければならないときプロトコル処理の間に被られるかもしれないオーバーヘッドによって動機づけられています。 多くのレベルの処理でコピーを必要とすることができます、ネットワーク媒体とホストの記憶の間の感動的なデータからオペレーティングシステムとユーザアドレス空間の間でデータを通過するまで。 最適のネットワーク実装は、ホストメモリへのデータ・パケットの配送と適切なデータのプレゼンテーションの間のコピー操作を全く受信プロセスへ被らないと予想するでしょう。 多くのパケットは操作をコピーしながら、いくつかなしで処理されないかもしれませんが、ホストコンピュータが適当なメモリ管理サポートを提供するとき、単に適切な仮想記憶ハードウェアを操作することによってコピーするのを避けるのはしばしば可能であるかもしれません。

   In a page mapped virtual memory environment, two prerequisites are
   usually required to achieve the goal of zero copy operations during
   packet processing.  Data destined for a receiving agent must be

1ページ写像している仮想記憶環境で、通常、2つの前提条件が、パケット処理の間、コピー操作がない目標を達成するのに必要です。 受信エージェントのために運命づけられたデータはそうであるに違いありません。

Leffler & Karels                                                [Page 1]

レフラーとKarels[1ページ]

RFC 893                                                       April 1984

RFC893 1984年4月

   aligned on a page boundary and must have a size which is a multiple
   of the hardware page size (or filled to a page boundary).  The latter
   restriction assumes virtual memory protection is maintained at the
   page level; different architectures may alter these prerequisites.

ページ・バウンダリに並んで、ハードウェアページ・サイズ(または、ページ・バウンダリにいっぱいにされる)の倍数であるサイズを持たなければなりません。 後者の制限は、仮想記憶保護がページレベルで維持されると仮定します。 異なったアーキテクチャはこれらの前提条件を変更するかもしれません。

   Data to be transmitted across a network may easily be segmented in
   the appropriate size, but unless the encapsulating protocol header
   information is fixed in size, alignment to a page boundary is
   virtually impossible.  Protocol header information may vary in size
   due to the use of multiple protocols (each with a different header),
   or it may vary in size by agreement (for example, when optional
   information is included in the header).  To insure page alignment the
   header information which prefixes data destined for the receiver must
   be reduced to a fixed size; this is normally the case at the link
   level of a network.  By taking all (possibly) variable length header
   information and moving it after the data segment a sending host may
   "do its best" in allowing the receiving host the opportunity to
   receive data on a page aligned boundary.  This rearrangement of data
   at the link level to force variable length header information to
   "trail" the data is the substance of the trailer encapsulation.

ネットワークの向こう側に伝えられるべきデータは適切なサイズで容易に区分されるかもしれませんが、要約のプロトコルヘッダー情報がサイズで修理されていない場合、ページ・バウンダリへの整列は実際には不可能です。 プロトコルヘッダー情報が複数のプロトコル(異なったヘッダーがあるそれぞれ)の使用のため大小の差があるかもしれませんか、またはそれは申し合わせて大小の差があるかもしれません(任意の情報が例えばヘッダーに含まれているとき)。 ページがえを保障するために、データが受信機のためにどの接頭語を運命づけたかというヘッダー情報を固定サイズまで減らさなければなりません。 通常、これはネットワークのリンク・レベルにおいてそうです。 すべての(ことによると)可変な長さのヘッダー情報を取って、データ・セグメントの後にそれを動かすことによって、送付ホストは1ページ並べられた境界に関するデータを受け取る機会を受信ホストに許容する際に「最善をつくすかもしれません」。 可変長ヘッダー情報がデータを「引きずること」を強制するリンク・レベルにおけるデータのこの配列換えはトレーラカプセル化の物質です。

   There are several implicit assumptions in the above argument.

上の議論におけるいくつかの暗黙の仮定があります。

      1. The receiving host must be willing to accept trailers.  As this
      is a link level encapsulation, unless a host to host negotiation
      is performed (preferably at the link level to avoid violating
      layering principles), only certain hosts will be able to converse,
      or their communication may be significantly impaired if trailer
      packets are mixed with non-trailer packets.

1. 受信ホストは、トレーラを受け入れても構わないと思っているに違いありません。 これがリンク・レベルカプセル化であるので、交渉を主催するホストが実行されないと(レイヤリング原則に違反するのを避ける望ましくはリンク・レベルで)、確信しているホストだけが話すことができるでしょうか、またはトレーラパケットが非トレーラパケットに混ぜられるなら、彼らのコミュニケーションはかなり損なわれるかもしれません。

      2. The cost of receiving data on a page aligned boundary should be
      comparable to receiving data on a non-page aligned boundary.  If
      the overhead of insuring proper alignment is too high, the savings
      in avoiding copy operations may not be cost effective.

2. 1ページ並べられた境界に関するデータを受け取る費用は非ページの並べられた限界に関するデータを受け取るのに匹敵しているべきです。 適切な整列を保障するオーバーヘッドが高過ぎるなら、コピー操作を避けることにおける貯蓄は費用効率がよくないかもしれません。

      3. The size of the variable length header information should be
      significantly less than that of the data segment being
      transmitted. It is possible to move trailing information without
      physically copying it, but often implementation constraints and
      the characteristics of the underlying network hardware preclude
      merely remapping the header(s).

3. 可変長ヘッダー情報のサイズはデータ・セグメントのものよりかなり伝えられるべきではありません。 物理的にそれをコピーしないで引きずっている情報を動かすのが可能ですが、しばしば、基本的なネットワークハードウェアの実装規制と特性は、単にヘッダーを再写像するのを排除します。

      4. The memory to memory copying overhead which is expected to be
      performed by the receiver must be significant enough to warrant
      the added complexity in the both the sending and receiving host
      software.

4. 受信機によって実行されると予想されるオーバーヘッドをコピーするメモリへのメモリは発信と受信がソフトウェアをホスティングするのを両方の加えられた複雑さに保証できるくらい重要でなければなりません。

   The first point is well known and the motivation for this note.

最初のポイントは、よく知られていてこの注意に関する動機です。

Leffler & Karels                                                [Page 2]

レフラーとKarels[2ページ]

RFC 893                                                       April 1984

RFC893 1984年4月

   Thought has been given to negotiating the user of trailers on a per
   host basis using a variant of the Address Resolution Protocol [2]
   (actually augmenting the protocol), but at present all systems using
   trailers require hosts sharing a network medium to uniformly accept
   trailers or never transmit them.  (The latter is easily carried out
   at boot time in 4.2BSD without modifying the operating system source
   code.)

考えはしかし、Address Resolutionプロトコル[2](実際に、プロトコルを増大させます)のホスト基礎使用あたり1つの異形、現在のところすべてのシステムの上のトレーラの交渉へのユーザを考えて、トレーラを使用するのが、ネットワーク媒体を共有しているホストが一様にトレーラを受け入れるか、またはそれらを決して伝えないのを必要とするということです。 (オペレーティングシステムソースコードを変更しないで、後者が4.2BSDのブート時間で容易に行われます。)

   The second point is (to our knowledge) insignificant.  While a host
   may not be able to take advantage of the alignment and size
   properties of a trailer packet, it should nonetheless never hamper
   it.

2番目のポイントはこと(私たちが知っている限り)です。無意味に。 ホストがトレーラパケットの整列とサイズの特性を利用できないかもしれない間、それはそれにもかかわらず、それを決して妨げるべきではありません。

   Regarding the third point, let us assume the trailing header
   information is copied and not remapped, and consider the header
   overhead in the TCP/IP protocols as a representative example [3].  If
   we assume both the TCP and IP protocol headers are part of the
   variable length header information, then the smallest trailer packet
   (generated by a VAX) would have 512 bytes of data and 40+ bytes of
   header information (plus the trailer header described later).  While
   the trailing header could have IP and/or TCP options included this
   would normally be rare (one would expect most TCP options, for
   example, to be included in the initial connection setup exchange) and
   certainly much smaller than 512 bytes.  If the data segment is
   larger, the ratio decreases and the expected gain due to fewer copies
   on the receiving end increases.  Given the relative overheads of a
   memory to memory copy operation and that of a page map manipulation
   (including translation buffer invalidation), the advantage is
   obvious.

3番目のポイントに関して、引きずっているヘッダー情報がコピーされて、再写像されないと思わせてください、そして、TCP/IPプロトコルにおけるヘッダーオーバーヘッドを代表している例[3]と考えてください。 私たちが、両方がTCPであると思って、IPプロトコルヘッダーが可変長ヘッダー情報の一部であるなら、最も小さいトレーラパケット(VAXによって生成される)には、512バイトのデータと40+バイトのヘッダー情報(後で説明されたトレーラヘッダー)があるでしょう。 引きずっているヘッダーはIP、そして/または、TCPオプションを含んだかもしれない間、確かに、通常、これが、まれであって(例えば、人は初期の接続設定交換に含まれるようにほとんどのTCPオプションを予想するでしょう)、512バイトよりはるかに小さいでしょう。 データ・セグメントが、より大きいなら、比率は減少します、そして、より少ないコピーによる予想された利得は受ける側になって上がります。 メモリコピー操作へのメモリの相対的なオーバーヘッドとページマップ操作のものを考えて(翻訳バッファ無効化を含んでいて)、利点は明白です。

   The fourth issue, we believe, is actually a non-issue.  In our
   implementation the additional code required to support the trailer
   encapsulation amounts to about a dozen lines of code in each link
   level "network interface driver".  The resulting performance
   improvement more than warrants this minor investment in software.

私たちは、4番目の問題が実際にどうでもいい問題であると信じています。 私たちの実装では、追加コードがカプセル化が各リンク・レベルのコードの1ダースの行に関して達するトレーラに「ネットワーク・インターフェースドライバー」をサポートするのが必要です。 これほど小さい方の証明書より多くの結果として起こる性能改良、ソフトウェアへの投資。

   It should be recognized that modifying the network (and normal link)
   level format of a packet in the manner described forces the receiving
   host to buffer the entire packet before processing.  Clever
   implementations may parse protocol headers as the packet arrives to
   find out the actual size (or network level packet type) of an
   incoming message.  This allows these implementations to avoid
   preallocating maximum sized buffers to incoming packets which it can
   recognize as unacceptable.  Implementations which parses the network
   level format on the fly are violating layering principles which have
   been extolled in design for some time (but often violated in
   implementation).  The problem of postponing link level type

受信ホストが方法によるパケットの平らな形式が説明したネットワーク(そして、正常なリンク)を変更するので処理の前にやむを得ず全体のパケットをバッファリングすると認められるべきです。 パケットが入力メッセージの実サイズ(平らなパケットタイプをネットワークでつなぐ)を見つけるために到着するとき、賢明な実装はプロトコルヘッダーを分析するかもしれません。 これで、これらの実装は、それが容認できないとして認識できる入って来るパケットに最大の大きさで分けられたバッファを「前-割り当て」るのを避けることができます。 急いでネットワークレベル形式を分析する実装がしばらく(しかし、実装でしばしば違反される)デザインで持てはやされているレイヤリング原則に違反しています。 リンク・レベルタイプを延期するという問題

Leffler & Karels                                                [Page 3]

レフラーとKarels[3ページ]

RFC 893                                                       April 1984

RFC893 1984年4月

   recognition is a valid criticism.  In the case of network hardware
   which supports DMA, however, the entire packet is always received
   before processing begins.

認識は妥当な批評です。 しかしながら、DMAをサポートするネットワークハードウェアの場合では、処理が始まる前に全体のパケットをいつも受け取ります。

Trailer Encapsulation Packet Formats

トレーラカプセル化パケット・フォーマット

   In this section we describe the link level packet formats used on the
   3 Mb/s Experimental Ethernet, and 10 Mb/s Ethernet networks as well
   as the 10 Mb/s V2LNI ring network.  The formats used in each case
   differ only in the format and type field values used in each of the
   local area network headers.

私たちが説明するこのセクションでは、リンク・レベルパケット・フォーマットは3Mb/s Experimentalイーサネット、および10Mb/sで10Mb/s V2LNIのリングネットワークと同様にイーサネットネットワークを使用しました。 その都度使用される形式は、形式だけにおいて異なって、ローカル・エリア・ネットワークヘッダー各人で使用される分野値をタイプします。

   The format of a trailer packet is shown in the following diagram.

トレーラパケットの書式は以下のダイヤグラムで示されます。

      +----+-------------------------------------------------+----+
      | LH |                     data                        | TH |
      +----+-------------------------------------------------+----+
           ^                    (  ^  )                      ^

+----+-------------------------------------------------+----+ | 左手| データ| th| +----+-------------------------------------------------+----+ ^ ( ^ ) ^

      LH:

左手:

         The fixed-size local network header.  For 10 a Mb/s Ethernet,
         the 16-byte Ethernet header.  The type field in the header
         indicates that both the packet type (trailer) and the length of
         the data segment.

固定サイズ企業内情報通信網ヘッダー。 10のa Mb/sイーサネット、16バイトのイーサネットヘッダーのために。 ヘッダーのタイプ分野は、両方のパケットが(トレーラ)とデータ・セグメントの長さをタイプするのを示します。

         For the 10 Mb/s Ethernet, the types are between 1001 and 1010
         hexadecimal (4096 and  4112 decimal). The type is calculated as
         1000 (hex) plus the number of 512-byte pages of data.  A
         maximum  of 16 pages of data may be transmitted in a single
         trailer packet (8192 bytes).

10Mb/sのイーサネットのために、タイプは1001年から1010 16進(4096と4112小数)です。 タイプは512バイトのページのデータの1000(十六進法)と数として計算されます。 最大16ページのデータは単一のトレーラパケット(8192バイト)で送られるかもしれません。

      data:

データ:

         The "data" portion of the packet.  This is normally only data
         to be delivered to the receiving processes (i.e. it contains no
         TCP or IP header information).  Data size is always a multiple
         of 512 bytes.

パケットの「データ」一部。 通常、これは受信プロセスに提供されるデータにすぎません(すなわち、それはどんなTCPもIPヘッダー情報も含んでいません)。 いつもデータサイズは512バイトの倍数です。

      TH:

第:

         The "trailer".  This is actually a composition of the original
         protocol headers and a fixed size trailer prefix which defines
         the type and size
         of the trailing data.  The format of a trailer is shown below.

「トレーラ。」 これは実際に引きずっているデータのタイプとサイズを定義するオリジナルのプロトコルヘッダーと固定サイズトレーラ接頭語の構成です。 トレーラの書式は以下に示されます。

   The carats (^) indicate the page boundaries on which the receiving
   host would place its input buffer for optimal alignment when

カラット(^)は、受信ホストが入力を置くページ・バウンダリが最適の整列のためにいつをバッファリングするかを示します。

Leffler & Karels                                                [Page 4]

レフラーとKarels[4ページ]

RFC 893                                                       April 1984

RFC893 1984年4月

   receiving a trailer packet.  The link level receiving routine is able
   to locate the trailer using the size indicated in the link level
   header's type field.  The receiving routine is expected to discard
   the link level header and trailer prefix, and remap the trailing data
   segment to the front of the packet to regenerate the original network
   level packet format.

トレーラパケットを受けます。 リンク・レベル受信ルーチンは、リンク・レベルヘッダーのタイプ分野で示されたサイズを使用することでトレーラの場所を見つけることができます。 受信ルーチンがリンク・レベルヘッダーとトレーラ接頭語を捨てると予想されて、元のネットワークレベルパケット・フォーマットを作り直すパケットの前部への引きずっているデータ・セグメントはremapが予想されます。

Trailer Format

トレーラ形式

   +----------------+----------------+------~...~----------+
   |      TYPE      |  HEADER LENGTH |  ORIGINAL HEADER(S) |
   +----------------+----------------+------~...~----------+

+----------------+----------------+------~...~----------+ | タイプ| ヘッダ長| オリジナルのヘッダー(S)| +----------------+----------------+------~...~----------+

   Type:        16 bits

以下をタイプしてください。 16ビット

      The type field encodes the original link level type of the
      transmitted packet.  This is the value which would normally be
      placed in the link level header if a trailer were not generated.

タイプ分野は伝えられたパケットの元のリンク・レベルタイプをコード化します。 これはトレーラが生成されないなら通常、リンク・レベルヘッダーに置かれる値です。

   Header length:       16 bits

ヘッダ長: 16ビット

      The header length field of the trailer data segment.  This
      specifies the length in bytes of the following header data.

トレーラデータ・セグメントのヘッダ長分野。 これは以下のヘッダー・データのバイトで表現される長さを指定します。

   Original headers: <variable length>

オリジナルのヘッダー: <可変長>。

      The header information which logically belongs before the data
      segment.  This is normally the network and transport level
      protocol headers.

データ・セグメントの前に論理的に属するヘッダー情報。 通常、これはネットワークであり、輸送レベルはプロトコルヘッダーです。

Summary

概要

   A link level encapsulation which promotes alignment properties
   necessary for the efficient use of virtual memory hardware facilities
   has been described.  This encapsulation format is in use on many
   systems and is a standard facility in 4.2BSD UNIX.  The encapsulation
   provides an efficient mechanism by which cooperating hosts on a local
   network may obtain significant performance improvements.  The use of
   this encapsulation technique currently requires uniform cooperation
   from all hosts on a network; hopefully a per host negotiation
   mechanism may be added to allow consenting hosts to utilize the
   encapsulation in a non-uniform environment.

仮想記憶ハードウェア施設の効率的な使用に必要な整列の特性を促進するリンク・レベルカプセル化は説明されます。 このカプセル化形式は、多くのシステムの上で使用中であり、4.2BSD UNIXの標準の施設です。 カプセル化はホストと協力して、企業内情報通信網が顕著な性能改良を得るかもしれない効率的なメカニズムを提供します。 このカプセル化技術の使用は現在、ネットワークのすべてのホストから一定の協力を必要とします。 うまくいけば、ホスト交渉メカニズムあたりのaは、不均等な環境でカプセル化を利用するために同意にホストを許容するために加えられるかもしれません。

Leffler & Karels                                                [Page 5]

レフラーとKarels[5ページ]

RFC 893                                                       April 1984

RFC893 1984年4月

References

参照

   [1]  "The Ethernet - A Local Area Network", Version 1.0, Digital
   Equipment Corporation, Intel Corporation, Xerox Corporation,
   September 1980.

[1]、「イーサネット--、ローカル・エリア・ネットワーク、」、バージョン1.0、ディジタルイクイップメント社、インテル社、ゼロックス社、9月1980

   [2]  Plummer, David C., "An Ethernet Address Resolution Protocol",
   RFC-826,  Symbolics Cambridge Research Center, November 1982.

1982年11月の[2] プラマー、デヴィッドC.、「イーサネットアドレス解決プロトコル」RFC-826、Symbolicsケンブリッジリサーチセンター。

   [3]  Postel, J., "Internet Protocol", RFC-791, USC/Information
   Sciences Institute, September 1981.

[3] ポステル、J.、「インターネットプロトコル」、RFC-791、科学が1981年9月に設けるUSC/情報。

Leffler & Karels                                                [Page 6]

レフラーとKarels[6ページ]