RFC1356 日本語訳

1356 Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode.A. Malis, D. Robinson, R. Ullmann. August 1992. (Format: TXT=32043 bytes) (Obsoletes RFC0877) (Status: DRAFT STANDARD)

Network Working Group                                           A. Malis
Request for Comments: 1356                            BBN Communications
Obsoletes: RFC 877                                           D. Robinson
                                      Computervision Systems Integration
                                                              R. Ullmann
                                            Process Software Corporation
                                                             August 1992

Malisがコメントのために要求するワーキンググループA.をネットワークでつないでください: 1356のBBNコミュニケーションが以下を時代遅れにします。 RFC877D.ロビンソンComputervisionシステム・インテグレーションR.ウルマンプロセスソフトウェア社の1992年8月

                       Multiprotocol Interconnect
                  on X.25 and ISDN in the Packet Mode


Status of this Memo


   This RFC specifies an IAB standards track protocol for the Internet
   community, and requests discussion and suggestions for improvements.
   Please refer to the current edition of the "IAB Official Protocol
   Standards" for the standardization state and status of this protocol.
   Distribution of this memo is unlimited.

このRFCはIAB標準化過程プロトコルをインターネットコミュニティに指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。



   This document specifies the encapsulation of IP and other network
   layer protocols over X.25 networks, in accordance and alignment with
   ISO/IEC and CCITT standards.  It is a replacement for RFC 877, "A
   Standard for the Transmission of IP Datagrams Over Public Data
   Networks" [1].

このドキュメントはX.25ネットワークの上でIPと他のネットワーク層プロトコルのカプセル化を指定します、ISO/IECとの一致と整列とCCITT規格で。 それはRFC877との交換、「公衆データネットワークの上のIPデータグラムの送信の規格」[1]です。

   It was written to correct several ambiguities in the Internet
   Standard for IP/X.25 (RFC 877), to align it with ISO/IEC standards
   that have been written following RFC 877, to allow interoperable
   multiprotocol operation between routers and bridges over X.25, and to
   add some additional remarks based upon practical experience with the
   specification over the 8 years since that RFC.


   The substantive change to the IP encapsulation is an increase in the
   allowed IP datagram Maximum Transmission Unit from 576 to 1600, to
   reflect existing practice.

IPカプセル化への実質的な変化は、既存の習慣を反映するためには576〜1600年までの許容IPデータグラムMaximum Transmission Unitの増加です。

   This document also specifies the Internet encapsulation for
   protocols, including IP, on the packet mode of the ISDN.  It applies
   to the use of Internet protocols on the ISDN in the circuit mode only
   when the circuit is established as an end-to-end X.25 connection.

また、このドキュメントはISDNのパケット形態でIPを含むプロトコルにインターネットカプセル化を指定します。 回路が終わりから終わりとのX.25接続と書き立てられるときだけ、それは回路モードによるISDNにおけるインターネットプロトコルの使用に適用されます。

Malis, Robinson, & Ullmann                                      [Page 1]

RFC 1356           Multiprotocol Interconnect on X.25        August 1992

RFC1356MultiprotocolがX.25 August 1992でインタコネクトするMalis、ロビンソン、およびウルマン[1ページ]



   RFC 877 was written by J. T. Korb of Purdue University, and this
   document follows that RFC's format and builds upon its text as
   appropriate.  This document was produced under the auspices of the IP
   over Large Public Data Networks Working Group of the IETF.

RFC877がパデュー大学のJ.T.コルプによって書かれて、このドキュメントは、そのRFCの形式に続いて、適切な状態でテキストを当てにします。 このドキュメントはIETFのLarge Public Data Networks作業部会の上にIPの前兆で製作されました。

1. Conventions

1. コンベンション

   The following language conventions are used in the items of
   specification in this document:


   o MUST -- the item is an absolute requirement of the specification.
     MUST is only used where it is actually required for interoperation,
     not to try to impose a particular method on implementors where not
     required for interoperability.

o --項目は仕様に関する絶対条件であるに違いありません。 それがinteroperationに相互運用性に必要でないところで特定のメソッドを作成者に課そうとしないために実際に必要であるところで使用するだけでよいです。

   o SHOULD -- the item should be followed for all but exceptional

o SHOULD--商品はほとんど例外的な事情のために従われるべきです。

   o MAY or optional -- the item is truly optional and may be followed
     or ignored according to the needs of the implementor.

o 5月か任意である、--作成者の必要性に従って、商品は、本当に、任意であり、従われているか、または無視されるかもしれません。

   The words "should" and "may" are also used, in lower case, in their
   more ordinary senses.


2. Introduction

2. 序論

   RFC 877 was written to document the method CSNET and the VAN Gateway
   had adopted to transmit IP datagrams over X.25 networks.  Its success
   is evident in its current wide use and the inclusion of its IP
   protocol identifier in ISO/IEC TR 9577, "Protocol Identification in
   the Network Layer" [2], which is administered by ISO/IEC and CCITT.

RFC877は、ゲートウェイがX.25ネットワークの上にIPデータグラムを送るために採用したメソッドCSNETとVANを記録するために書かれました。 成功はISO/IECとCCITTによって管理されるISO/IEC TR9577、「ネットワーク層におけるプロトコル識別」[2]での現在の広い使用とIPプロトコル識別子の包含で明白です。

   However, due to changes in the scope of X.25 and the protocols that
   it can carry, several inadequacies have become evident in the RFC,
   especially in the areas of IP datagram Maximum Transmission Unit
   (MTU) size, X.25 maximum data packet size, virtual circuit
   management, and the interoperable encapsulation, over X.25, of
   protocols other than IP between multiprotocol routers and bridges.

しかしながら、X.25の範囲の変化とそれが運ぶことができるプロトコルのため、いくつかの不適当がRFCで明白になりました、特にIPデータグラムMaximum Transmission Unit(MTU)サイズの領域、X.25の最大のデータ・パケットサイズ、仮想の回路管理、および共同利用できるカプセル化で、「マルチ-プロトコル」ルータの間のIP以外のプロトコルのX.25とブリッジの上で。

   As with RFC 877, one or more X.25 virtual circuits are opened on
   demand when datagrams arrive at the network interface for
   transmission.  A virtual circuit is closed after some period of
   inactivity (the length of the period depends on the cost associated
   with an open virtual circuit).  A virtual circuit may also be closed
   if the interface runs out of virtual circuits.

データグラムがトランスミッションのためにネットワーク・インターフェースに届くとき、仮想であるより多くのRFC877、1X.25のように、回路は要求に応じて開けられます。 仮想の回路はいつかの期間の不活発の後に閉じられます(期間の長さを開いている仮想の回路に関連している費用に依存します)。 また、インタフェースが仮想の回路を使い果たすなら、仮想の回路は閉じられるかもしれません。

Malis, Robinson, & Ullmann                                      [Page 2]

RFC 1356           Multiprotocol Interconnect on X.25        August 1992

RFC1356MultiprotocolがX.25 August 1992でインタコネクトするMalis、ロビンソン、およびウルマン[2ページ]

3. Standards

3. 規格

3.1 Protocol Data Units (PDUs) are sent as X.25 "complete packet
    sequences".  That is, PDUs begin on X.25 data packet boundaries and
    the M bit ("more data") is used to fragment PDUs that are larger
    than one X.25 data packet in length.

3.1 X.25が「パケット系列を完了する」とき、プロトコルData Units(PDUs)を送ります。 すなわち、PDUsはX.25データ・パケット境界で始まります、そして、噛み付いている(「より多くのデータ」)が使用されているMは長さで1つのX.25データ・パケットより大きいPDUsを断片化します。

    In the IP encapsulation the PDU is the IP datagram.


3.2 The first octet in the Call User Data (CUD) Field (the first data
    octet in the Call Request packet) is used for protocol
    demultiplexing, in accordance with the Subsequent Protocol
    Identifier (SPI) in ISO/IEC TR 9577.  This field contains a one-
    octet Network Layer Protocol Identifier (NLPID), which identifies
    the network layer protocol encapsulated over the X.25 virtual
    circuit.  The CUD field MAY contain more than one octet of
    information, and receivers MUST ignore all extraneous octets in the

3.2 Call User Data(CUD)分野(Call Requestパケットにおける最初のデータ八重奏)における最初の八重奏はプロトコル逆多重化に使用されます、ISO/IEC TR9577のSubsequentプロトコルIdentifier(SPI)によると。 この分野は1つの八重奏のNetwork LayerプロトコルIdentifier(NLPID)を含んでいます。(IdentifierはX.25の仮想の回路の上にカプセル化されたネットワーク層プロトコルを特定します)。 CUD分野は情報の1つ以上の八重奏を含むかもしれません、そして、受信機はその分野でのすべての異質な八重奏を無視しなければなりません。

    In the following discussion, the most significant digit of the
    binary numbers is left-most.


    For the Internet community, the NLPID has four relevant values:


    The value hex CC (binary 11001100, decimal 204) is IP [6].
    Conformance with this specification requires that IP be supported.
    See section 5.1 for a diagram of the packet formats.

値の十六進法CC(2進の11001100、10進204)はIP[6]です。 この仕様がある順応は、IPがサポートされるのを必要とします。 パケット・フォーマットのダイヤグラムに関してセクション5.1を見てください。

    The value hex 81 (binary 10000001, decimal 129) identifies ISO/IEC
    8473 (CLNP) [4].  ISO/IEC TR 9577 specifically allows other ISO/IEC
    connectionless-protocol packets, such as ES-IS and IS-IS, to also be
    carried on the same virtual circuit as CLNP.  Conformance with this
    specification does not require that CLNP be supported.  See section
    5.2 for a diagram of the packet formats.

値の十六進法81(2進の10000001、10進129)はISO/IEC8473(CLNP)[4]を特定します。 そして、ISO/IEC TR9577は明確に他のIEC ISO/コネクションレスプロトコルパケットを許容します、あれほど、ある、ES-、また、CLNPと同じ仮想の回路の上に運ばれるために。 この仕様がある順応は、CLNPがサポートされるのを必要としません。 パケット・フォーマットのダイヤグラムに関してセクション5.2を見てください。

    The value hex 82 (binary 10000010, decimal 130) is used specifically
    for ISO/IEC 9542 (ES-IS) [5].  If there is already a circuit open to
    carry CLNP, then it is not necessary to open a second circuit to
    carry ES-IS.  Conformance with this specification does not require
    that ES-IS be supported.

値の十六進法82(2進の10000010、10進130)が特にISO/IEC9542に使用される、(ES存在、)、[5]。 CLNPを運ぶために開いている回路が既にあれば運ぶために2番目の回路を開けるのは必要でない、ES存在 この仕様がある順応がそれを必要としない、ES存在、サポートされてください。

    The value hex 80 (binary 10000000, decimal 128) identifies the use
    of IEEE Subnetwork Access Protocol (SNAP) [3] to further encapsulate
    and identify a single network-layer protocol.  The SNAP-encapsulated
    protocol is identified by including a five-octet SNAP header in the
    Call Request CUD field immediately following the hex 80 octet.  SNAP
    headers are not included in the subsequent X.25 data packets.  Only
    one SNAP-encapsulated protocol may be carried over a virtual circuit

値の十六進法80(2進の10000000、10進128)は、さらにただ一つのネットワーク層プロトコルをカプセル化して、特定するためにIEEE Subnetwork Accessプロトコル(SNAP)[3]の使用を特定します。 十六進法80八重奏に続いて、SNAPによってカプセル化されたプロトコルは、すぐにCall Request CUD分野に5八重奏のSNAPヘッダーを含んでいることによって、特定されます。 SNAPヘッダーはその後のX.25データ・パケットに含まれていません。 1つのSNAPによってカプセル化されたプロトコルだけを仮想の回路の上まで運んでもよいです。

Malis, Robinson, & Ullmann                                      [Page 3]

RFC 1356           Multiprotocol Interconnect on X.25        August 1992

RFC1356MultiprotocolがX.25 August 1992でインタコネクトするMalis、ロビンソン、およびウルマン[3ページ]

    opened using this encoding.  The receiver SHOULD accept the incoming
    call only if it can support the particular SNAP-identified protocol.
    Conformance with this specification does not require that this SNAP
    encoding be supported.  See section 5.3 for a diagram of the packet

このコード化を使用することで、開かれます。 特定のSNAPによって特定されたプロトコルをサポートできる場合にだけ、受信機SHOULDはかかってきた電話を受け入れます。 この仕様がある順応は、このSNAPコード化がサポートされるのを必要としません。 パケット・フォーマットのダイヤグラムに関してセクション5.3を見てください。

    The value hex 00 (binary 00000000, decimal 0) identifies the Null
    encapsulation, used to multiplex multiple network layer protocols
    over the same circuit.  This encoding is further discussed in
    section 3.3 below.

値の十六進法00(2進の00000000、10進0)はNullカプセル化を特定します、同じ回路の上に複数のネットワーク層プロトコルを多重送信するのにおいて、使用されています。 下のセクション3.3でこのコード化についてさらに議論します。

    The "Assigned Numbers" RFC [7] contains one other non-CCITT and
    non-ISO/IEC value that has been in active use for Internet X.25
    encapsulation identification, namely hex C5 (binary 11000101,
    decimal 197) for Blacker X.25.  This value MAY continue to be used,
    but only by prior preconfiguration of the sending and receiving X.25
    interfaces to support this value.  The value hex CD (binary
    11001101, decimal 205), listed in "Assigned Numbers" for "ISO-IP",
    is also used by Blacker and also can only be used by prior
    preconfiguration of the sending and receiving X.25 interfaces.

「規定番号」RFC[7]はすなわち、インターネットX.25カプセル化識別の能動的使用、Blacker X.25のための十六進法C5(2進の11000101、10進197)にあった1他の非CCITTと非ISO/IEC値を含んでいます。 この値をサポートするために、この値は使用されますが、送受信X.25インタフェースの先の前構成だけでずっとあるかもしれません。 「ISO-IP」の「規定番号」で記載された値の十六進法CD(2進の11001101、10進205)を、また、より黒いことで使用して、また、送受信X.25インタフェースの先の前構成は使用できるだけです。

    Each system MUST only accept calls for protocols it can process;
    every Internet system MUST be able to accept the CC encapsulation
    for IP datagrams.  A system MUST NOT accept calls, and then
    immediately clear them.  Accepting the call indicates to the calling
    system that the protocol encapsulation is supported; on some
    networks, a call accepted and cleared is charged, while a call
    cleared in the request state is not charged.

各システムはそれが処理できるプロトコルのための呼び出しを受け入れるだけでよいです。 あらゆるインターネット・システムがIPデータグラムのためにCCカプセル化を受け入れることができなければなりません。システムは、呼び出しを受け入れて、次に、すぐに、それらをきれいにしてはいけません。 呼び出しを受け入れるのは、プロトコルカプセル化がサポートされるのを呼ぶシステムに示します。 いくつかのネットワークでは、受け入れられて、クリアされた呼び出しは請求されます、要求状態でクリアされた呼び出しが請求されませんが。

    Systems that support NLPIDs other than hex CC (for IP) SHOULD allow
    their use to be configured on a per-peer address basis.  The use of
    hex CC (for IP) MUST always be allowed between peers and cannot be

十六進法CC(IPのための)SHOULD以外のNLPIDsをサポートするシステムは、彼らの使用が1同輩あたり1個のアドレスベースで構成されるのを許容します。 十六進法CC(IPのための)の使用は、同輩の間にいつも許容しなければならなくて、構成できません。

3.3 The NLPID encodings discussed in section 3.2 only allow a single
    network layer protocol to be sent over a circuit.  The Null
    encapsulation, identified by a NLPID encoding of hex 00, is used in
    order to multiplex multiple network layer protocols over one

3.3 セクション3.2で議論したNLPID encodingsは、ただ一つのネットワーク層プロトコルが回路の上に送られるのを許容するだけです。 十六進法00をコード化するNLPIDによって特定されたNullカプセル化は、1個の回路の上に複数のネットワーク層プロトコルを多重送信するのに使用されています。

    When the Null encapsulation is used, each X.25 complete packet
    sequence sent on the circuit begins with a one-octet NLPID, which
    identifies the network layer protocol data unit contained only in
    that particular complete packet sequence.  Further, if the SNAP
    NLPID (hex 80) is used, then the NLPID octet is immediately followed
    by the five-octet SNAP header, which is then immediately followed by
    the encapsulated PDU.  The encapsulated network layer protocol MAY
    differ from one complete packet sequence to the next over the same

Nullカプセル化が使用されているとき、それぞれのX.25の完全なパケット系列は、回路が1八重奏のNLPIDと共に始まるのを転送しました。(NLPIDはその特定の完全なパケット系列だけに含まれたネットワーク層プロトコルデータ単位を特定します)。 さらに、SNAP NLPID(十六進法80)が使用されているなら、NLPID八重奏はすぐに、5八重奏のSNAPヘッダーによって後をつけられています。(次に、ヘッダーはすぐに、カプセル化されたPDUによって続かれています)。 カプセル化されたネットワーク層プロトコルは同じくらい上で1つの完全なパケット系列から次の系列まで異なるかもしれません。

Malis, Robinson, & Ullmann                                      [Page 4]

RFC 1356           Multiprotocol Interconnect on X.25        August 1992

RFC1356MultiprotocolがX.25 August 1992でインタコネクトするMalis、ロビンソン、およびウルマン[4ページ]



    When a receiver is presented with an Incoming Call identifying the
    Null encapsulation, the receiver MUST accept the call if it supports
    the Null encapsulation for any network layer protocol.  The receiver
    MAY then silently discard a multiplexed PDU if it cannot support
    that particular encapsulated protocol.  See section 5.4 for a
    diagram of the packet formats.

Nullカプセル化を特定するIncoming Callを受信機に与えるとき、どんなネットワーク層プロトコルのためにもNullカプセル化をサポートするなら、受信機は呼び出しを受け入れなければなりません。 そして、その特定のカプセル化されたプロトコルをサポートできないなら、受信機は静かに多重送信されたPDUを捨てるかもしれません。 パケット・フォーマットのダイヤグラムに関してセクション5.4を見てください。

    Use of the single network layer protocol circuits described in
    section 3.2 is more efficient in terms of bandwidth if only a
    limited number of protocols are supported by a system.  It also
    allows each system to determine exactly which protocols are
    supported by its communicating partner.  Other advantages include
    being able to use X.25 accounting to detail each protocol and
    different quality of service or flow control windows for different

限られた数のプロトコルだけがシステムによってサポートされるなら、帯域幅ではセクション3.2で説明されたただ一つのネットワーク層プロトコル回路の使用は、より効率的です。 また、それで、各システムは、パートナーを伝えることによってどのプロトコルがサポートされるかをまさに決定できます。 他の利点は、異なったプロトコルのために各プロトコルと異なったサービスの質かフロー制御ウィンドウについて詳述するのにX.25会計を使用できるのを含んでいます。

    The Null encapsulation, for multiplexing, is useful when a system,
    for any reason (such as implementation restrictions or network cost
    considerations), may only open a limited number of virtual circuits
    simultaneously.  This is the method most likely to be used by a
    multiprotocol router, to avoid using an unreasonable number of
    virtual circuits.

どんな理由のシステム(施行規則かネットワーク費用問題などの)も同時に限られた数の仮想の回路を開けるだけであるとき、Nullカプセル化はマルチプレクシングの役に立ちます。 これは「マルチ-プロトコル」ルータによって最も使用された、無理な数の仮想の回路を使用するのを避けそうであるメソッドです。

    If performing IEEE 802.1d bridging across X.25 is desired, then the
    Null encapsulation MUST be used.  See section 4.2 for a further

X.25の向こう側にブリッジするIEEE 802.1dを実行するのが必要であるなら、Nullカプセル化を使用しなければなりません。 さらなる議論に関してセクション4.2を見てください。

    Conformance with this specification does not require that the Null
    encapsulation be supported.


    Systems that support the Null encapsulation SHOULD allow its use to
    be configured on a per-peer address basis.


3.4 For compatibility with existing practice, and RFC 877 systems, IP
    datagrams MUST, by default, be encapsulated on a virtual circuit
    opened with the CC CUD.

3.4 既存の習慣、およびRFC877台のシステムとの互換性において、デフォルトでCC CUDと共に開けられた仮想の回路の上にIPデータグラムをカプセル化しなければなりません。

    Implementations MAY also support up to three other possible
    encapsulations of IP:


   o IP may be contained in multiplexed data packets on a circuit using
     the Null (multiplexed) encapsulation.  Such data packets are
     identified by a NLPID of hex CC.

o IPは、回路の上の多重送信されたデータ・パケットにNull(多重送信する)カプセル化を使用することで含まれるかもしれません。 そのようなデータ・パケットは十六進法CCのNLPIDによって特定されます。

   o IP may be encapsulated within the SNAP encapsulation on a circuit.
     This encapsulation is identified by containing, in the 5-octet SNAP

o IPは回路の上にSNAPカプセル化の中でカプセル化されるかもしれません。 このカプセル化は、5八重奏にSNAPを含むことによって、特定されます。

Malis, Robinson, & Ullmann                                      [Page 5]

RFC 1356           Multiprotocol Interconnect on X.25        August 1992

RFC1356MultiprotocolがX.25 August 1992でインタコネクトするMalis、ロビンソン、およびウルマン[5ページ]

     header, an Organizationally Unique Identifier (OUI) of hex 00-00-00
     and Protocol Identifier (PID) of hex 08-00.

ヘッダー、十六進法00-00-00のOrganizationally Unique Identifier(OUI)、および十六進法08-00のプロトコルIdentifier(PID)。

   o On a circuit using the Null encapsulation, IP may be contained
     within the SNAP encapsulation of IP in multiplexed data packets.

o Nullカプセル化を使用する回路の上では、IPは多重送信されたデータ・パケットにIPのSNAPカプセル化の中に保管されるかもしれません。

    If an implementation supports the SNAP, multiplexed, and/or
    multiplexed SNAP encapsulations, then it MUST accept the encoding of
    IP within the supported encapsulation(s), MAY send IP using those
    encapsulation(s), and MUST allow the IP encapsulation to send to be
    configured on a per-peer address basis.


3.5 The negotiable facilities of X.25 MAY be used (e.g., packet and
    window size negotiation).  Since PDUs are sent as complete packet
    sequences, any maximum X.25 data packet size MAY be configured or
    negotiated between systems and their network service providers.  See
    section 4.5 for a discussion of maximum X.25 data packet size and
    network performance.

3.5、交渉可能な施設、X.25 MAYでは、使用されてください(例えば、パケットとウィンドウサイズ交渉)。 以来、完全なパケット系列、構成されているかもしれないか、またはシステムの間で交渉されたどんな最大のX.25データ・パケットサイズ、およびそれらのネットワークもプロバイダーを修理するとき、PDUsを送ります。 最大のX.25データ・パケットサイズとネットワーク性能の議論に関してセクション4.5を見てください。

    There is no implied relationship between PDU size and X.25 packet
    size (i.e., the method of setting IP MTU based on X.25 packet size
    in RFC 877 is not used).

PDUサイズとX.25パケットサイズとのどんな暗示している関係もありません(すなわち、X.25パケットサイズに基づくIP MTUをRFC877にはめ込むメソッドは使用されていません)。

3.6 Every system MUST be able to receive and transmit PDUs up to at
    least 1600 octets in length.

3.6 あらゆるシステムが、PDUsを受けて、長さにおける少なくとも1600の八重奏まで伝えることができなければなりません。

    For compatibility with existing practice, as well as
    interoperability with RFC 877 systems, the default transmit MTU for
    IP datagrams SHOULD default to 1500, and MUST be configurable in at
    least the range 576 to 1600.


    This is done with a view toward a standard default IP MTU of 1500,
    used on both local and wide area networks with no fragmentation at
    routers. Actually redefining the IP default MTU is, of course,
    outside the scope of this specification.

視点で1500年の標準のデフォルトIP MTUに向かってこれをします、ともに地方と広域ネットワークでは、断片化なしでルータで使用されています。 この仕様の範囲の外に実際にIPデフォルトMTUを再定義するのがもちろんあります。

    The PDU size (e.g., IP MTU) MUST be configurable, on at least a
    per-interface basis.  The maximum transmitted PDU length SHOULD be
    configurable on a per-peer basis, and MAY be configurable on a per-
    encapsulation basis as well.  Note that the ability to configure to
    send IP datagrams with an MTU of 576 octets and to receive IP
    datagrams of 1600 octets is essential to interoperate with existing
    implementations of RFC 877 and implementations of this

PDUサイズ(例えば、IP MTU)は少なくとも1インタフェースあたり1個のベースで構成可能であるに違いありません。 最大の伝えられたPDUの長さのSHOULDが1同輩あたり1個のベースで構成可能であり、aで構成可能であるかもしれない、-、また、カプセル化基礎。 576の八重奏のMTUがあるIPデータグラムを送って、1600の八重奏のIPデータグラムを受け取るのを構成する能力がRFC877の既存の実装とこの仕様の実装で共同利用するのに不可欠であることに注意してください。

    Note that on circuits using the Null (multiplexed) encapsulation,
    when IP packets are encapsulated using the NLPID of hex CC, then the
    default IP MTU of 1500 implies a PDU size of 1501; a PDU size of

次に、IPパケットが十六進法CCのNLPIDを使用することでカプセルに入れられるときNull(多重送信する)カプセル化を使用する回路の上では、1500年のデフォルトIP MTUが1501年のPDUサイズを含意することに注意してください。 PDUサイズ

Malis, Robinson, & Ullmann                                      [Page 6]

RFC 1356           Multiprotocol Interconnect on X.25        August 1992

RFC1356MultiprotocolがX.25 August 1992でインタコネクトするMalis、ロビンソン、およびウルマン[6ページ]

    1600 implies an IP MTU of 1599.  When IP packets are encapsulated
    using the NLPID of hex 80 followed by the SNAP header for IP, then
    the default IP MTU of 1500 implies a PDU size of 1506; a PDU size of
    1600 implies an IP MTU of 1594.

1600 1599年のIP MTUを含意します。 IPパケットがIPのためにSNAPヘッダーによって後をつけられた十六進法80のNLPIDを使用することでカプセルに入れられると、1500年のデフォルトIP MTUは1506年のPDUサイズを含意します。 1600年のPDUサイズは1594年のIP MTUを含意します。

    Of course, an implementation MAY support a maximum PDU size larger
    than 1600 octets.  In particular, there is no limit to the size that
    may be used when explicitly configured by communicating peers.

もちろん、実装は最大のPDUが1600の八重奏より大きいサイズであるとサポートするかもしれません。 特に、同輩を伝えることによって明らかに構成されると使用されるかもしれないサイズへの限界が全くありません。

3.7 Each ISO/IEC TR 9577 encapsulation (e.g., IP, CLNP, and SNAP)
    requires a separate virtual circuit between systems.  In addition,
    multiple virtual circuits for a single encapsulation MAY be used
    between systems, to, for example, increase throughput (see notes in
    section 4.5).

それぞれのISO/IEC TR9577カプセル化(例えば、IP、CLNP、およびSNAP)はシステムの間の別々の仮想の回路を必要とします。3.7 さらに、ただ一つのカプセル化のための複数の仮想の回路が、例えば、スループットを増強するのにシステムの間で使用されるかもしれません(セクション4.5の注意を見てください)。

    Receivers SHOULD accept multiple incoming calls with the same
    encapsulation from a single system.  Having done so, receivers MUST
    then accept incoming PDUs on the additional circuit(s), and SHOULD
    transmit on the additional circuits.

受信機SHOULDは同じカプセル化でただ一つのシステムから複数のかかってきた電話を受け入れます。 そうしたので、次に、受信機は追加回路の上の入って来るPDUsを受け入れなければなりません、そして、SHOULDは追加回路の上に伝わります。

    Shedding load by refusing additional calls for the same
    encapsulation with a X.25 diagnostic of 0 (DTE clearing) is correct
    practice, as is shortening inactivity timers to try to clear


    Receivers MUST NOT accept the incoming call, only to close the
    circuit or ignore PDUs from the circuit.


    Because opening multiple virtual circuits specifying the same
    encapsulation is specifically allowed, algorithms to prevent virtual
    circuit call collision, such as the one found in section of
    ISO/IEC 8473 [4], MUST NOT be implemented.


    While allowing multiple virtual circuits for a single protocol is
    specifically desired and allowed, implementations MAY choose (by
    configuration) to permit only a single circuit for some protocols to
    some destinations.  Only in such a case, if a colliding incoming
    call is received while a call request is pending, the incoming call
    shall be rejected.  Note that this may result in a failure to
    establish a connection.  In such a case, each system shall wait at
    least a configurable collision retry time before retrying.  Adding a
    random increment, with exponential backoff if necessary, is

ただ一つのプロトコルのための複数の仮想の回路を許容するのが明確に必要で許容されている間、実装は、いくつかのプロトコルのためにただ一つの回路だけをいくつかの目的地に可能にするのを選ぶかもしれません(構成で)。 発呼要求が未定ですが、衝突かかってきた電話が受け取られている場合にだけ、このような場合には、かかってきた電話は拒絶されるものとします。 これが取引関係を築かないことをもたらすかもしれないことに注意してください。 このような場合には、各システムは再試行する前の再試行時間に少なくとも構成可能な衝突を待つものとします。 必要なら、指数のbackoffで無作為の増分を加えるのはお勧めです。

3.8 Either system MAY close a virtual circuit.  If the virtual circuit
    is closed or reset while a datagram is being transmitted, the
    datagram is lost.  Systems SHOULD be able to configure a minimum
    holding time for circuits to remain open as long as the endpoints

3.8 どちらのシステムも仮想の回路を閉じるかもしれません。 データグラムが送られている間、仮想の回路が閉じられるか、またはリセットされるなら、データグラムは無くなっています。 システムSHOULD、回路が終点と同じくらい長い間開いたままで残る最小の把持時間を構成できてください。

Malis, Robinson, & Ullmann                                      [Page 7]

RFC 1356           Multiprotocol Interconnect on X.25        August 1992

RFC1356MultiprotocolがX.25 August 1992でインタコネクトするMalis、ロビンソン、およびウルマン[7ページ]

    are up. (Note that holding time, the time the circuit has been open,
    differs from idle time.)

上はそうですか? (把持時間(回路が開いている時)が遊休時間と異なっていることに注意してください。)

3.9 Each system MUST use an inactivity timer to clear virtual circuits
    that are idle for some period of time.  Some X.25 networks,
    including the ISDN under present tariffs in most areas, charge for
    virtual circuit holding time.  Even where they do not, the resource
    SHOULD be released when idle.  The timer SHOULD be configurable; a
    timer value of "infinite" is acceptable when explicitly configured.
    The default SHOULD be a small number of minutes.  For IP, a
    reasonable default is 90 seconds.

3.9 各システムは、いつかの期間の間使用されていない仮想の回路をきれいにするのに不活発タイマを使用しなければなりません。 ほとんどの領域の現在の関税の下でISDNを含むX.25ネットワークの中には仮想の回路把持時間に充電されるものもあります。 活動していないときに、そうしないで、リソースがSHOULDであるところでさえリリースされます。 タイマSHOULD、構成可能であってください。 明らかに構成されると、「無限」のタイマ値は許容できます。 デフォルトSHOULD、少ない数の分になってください。 IPにおいて、合理的なデフォルトは90秒です。

3.10 Systems SHOULD allow calls from unconfigured calling addresses
     (presumably not collect calls, however); this SHOULD be a
     configuration option.  A system accepting such a call will, of
     course, not transmit on that virtual circuit if it cannot determine
     the protocol (e.g., IP) address of the caller.  As an example, on
     the DDN this is not a restriction because IP addresses can be
     determined algorithmically based upon the caller's X.121 address

3.10に、システムSHOULDは非構成された呼ぶアドレス(しかしながら、おそらくコレクトコールでない)から呼び出しを許します。 このSHOULD、設定オプションになってください。 訪問者のプロトコル(例えば、IP)アドレスを決定できないと、そのような呼び出しを受け入れるシステムはもちろんその仮想の回路の上に送られないでしょう。 例として、IPアドレスが訪問者のX.121アドレス[7、9]に基づく断固としたalgorithmicallyであるかもしれないので、これはDDNにおける、制限ではありません。

     Allowing such calls helps work around various "helpful" address
     translations done by the network(s), as well as allowing
     experimentation with various address resolution protocols.


3.11 Systems SHOULD use a configurable hold-down timer to prevent calls
     to failed destinations from being immediately retried.


3.12 X.25 implementations MUST minimally support the following features
     in order to conform with this specification: call setup and
     clearing and complete packet sequences.  For better performance
     and/or interoperability, X.25 implementations SHOULD also support:
     extended frame and/or packet sequence numbering, flow control
     parameter negotiation, and reverse charging.

3.12 X.25実装はこの仕様に従うために以下の特徴を最少量でサポートしなければなりません: セットアップ、開拓地、および完全なパケット系列に電話をしてください。 また、より良い性能、そして/または、相互運用性のために、X.25実装SHOULDは以下をサポートします。 拡張フレーム、そして/または、パケット系列付番と、フロー制御パラメタ交渉と、逆の充電。

3.13 The following X.25 features MUST NOT be used: interrupt packets and
     the Q bit (indicating qualified data).  Other X.25 features not
     explicitly discussed in this document, such as fast select and the
     D bit (indicating end-to-end significance) SHOULD NOT be used.

以下のX.25が特徴とする3.13を使用してはいけません: パケットとQビットを中断してください(適切なデータを示して)。 他のX.25の特徴は明らかに本書ではそのようなものについて議論しませんでした。高速セレクトとDビット(終わりから終わりへの意味を示す)SHOULD NOTとして、使用されてください。

     Use of the D bit will interfere with use of the M bit (more data
     sequences) required for identification of PDUs.  In particular, as
     subscription to the D bit modification facility (X.25-1988, section
     3.3) will prevent proper operation, this user facility MUST NOT be

Dビットの使用はビット(より多くのデータ系列)がPDUsの識別のために必要としたMの使用を妨げるでしょう。 特に、D噛み付いている変更施設(X.25-1988、セクション3.3)の購読が適切な操作を防ぐのでこの利用者機能を申し込んではいけません。

3.14 ISO/IEC 8208 [11] defines the clearing diagnostic code 249 to
     signify that a requested protocol is not supported.  Systems MAY

3.14 ISO/IEC8208[11]は、要求されたプロトコルがサポートされないのを意味するようにクリアしている診断コード249を定義します。 システム5月

Malis, Robinson, & Ullmann                                      [Page 8]

RFC 1356           Multiprotocol Interconnect on X.25        August 1992

RFC1356MultiprotocolがX.25 August 1992でインタコネクトするMalis、ロビンソン、およびウルマン[8ページ]

     use this diagnostic code when clearing an incoming call because the
     identified protocol is not supported.  Non-8208 systems more
     typically use a diagnostic code of 0 for this function.  Supplying
     a diagnostic code is not mandatory, but when it is supplied for
     this reason, it MUST be either of these two values.

特定されたプロトコルがサポートされないのでかかってきた電話をクリアするときにはこの診断コードを使用してください。 非8208システムはこの機能に0の診断コードをより典型的に使用します。 診断コードを供給するのは義務的ではありませんが、この理由にそれを供給するとき、それはこれらの2つの値のどちらかであるに違いありません。

4. General Remarks

4. 概評

   The following remarks are not specifications or requirements for
   implementations, but provide developers and users with guidelines and
   the results of operational experience with RFC 877.


4.1 Protocols above the network layer, such as TCP or TP4, do not
    affect this standard.  In particular, no attempt is made to open
    X.25 virtual circuits corresponding to TCP or TP4 connections.

ネットワーク層を超えたTCPかTP4などの4.1のプロトコルはこの規格に影響しません。 TCPかTP4接続において、対応するX.25仮想の回路を開けるのを試みを全く特に、しません。

4.2 Both the circuit and multiplexed encapsulations of SNAP may be used
    to contain any SNAP encapsulated protocol.  In particular, this
    includes using an OUI of 00-00-00 and the two octets of PID
    containing an Ethertype [7], or using IEEE 802.1's OUI of hex 00-
    80-C2 with the bridging PIDs listed in RFC 1294, "Multiprotocol
    Interconnect over Frame Relay" [8].  Note that IEEE 802.1d bridging
    can only be performed over a circuit using the Null (multiplexed)
    encapsulation of SNAP, because of the necessity of preserving the
    order of PDUs (including 802.1d Bridged PDUs) using different SNAP

4.2 回路とSNAPの多重送信されたカプセル化の両方が、プロトコルであるとカプセル化されたどんなSNAPも含むのに使用されるかもしれません。 特に、これが、Ethertype[7]を含む00-00-00のOUIとPIDの2つの八重奏を使用するのを含んでいるか、またはブリッジすると共にIEEE802.1の十六進法00- 80-C2のOUIを使用して、PIDsはRFC1294(「Multiprotocolはフレームリレーの上で内部連絡する」[8])に記載しました。 異なったSNAPヘッダーを使用することでPDUs(802.1d Bridged PDUsを含んでいる)の注文を保存するという必要性のために回路の上にSNAPのNull(多重送信する)カプセル化を使用することでIEEE 802.1dのブリッジすることを実行できるだけであることに注意してください。

4.3 Experience has shown that there are X.25 implementations that will
    assign calls with CC CUD to the X.29 PAD (remote login) facility
    when the IP layer is not installed, not configured properly, or not
    operating (indeed, they assume that ALL calls for unconfigured or
    unbound X.25 protocol IDs are for X.29 PAD sessions).  Call
    originators can detect that this has occurred at the receiver if the
    originator receives any X.25 data packets with the Q bit set,
    especially if the first octet of these packets is hex 02, 04, or 06
    (X.29 PAD parameter commands).  In this case, the originator should
    clear the call, and log the occurrence so that the misconfigured
    X.25 address can be corrected.  It may be useful to also use the
    hold-down timer (see section 3.11) to prevent further attempts for
    some period of time.

4.3 経験は、IP層が適切に構成されるのではなく、インストールもされませんし、作動もしていないとき(本当に、それらは非構成されたか無限のX.25プロトコルIDのためのすべての呼び出しがX.29 PADセッションの間あると仮定します)X.29 PAD(リモート・ログイン)施設にCC CUDとの呼び出しを割り当てるX.25実装があるのを示しました。 創始者がQビットで何かX.25データ・パケットを受けるなら、これが受信機に起こったという創始者が検出できる要求はセットしました、特にこれらのパケットの最初の八重奏が十六進法02、04、または06である(X.29 PADパラメタコマンド)なら。 この場合、創始者は、misconfigured X.25アドレスを修正できるように呼び出しをクリアして、発生を登録するべきです。 また、いつかの期間の間、さらなる試みを防ぐのに、抑制タイマ(セクション3.11を見る)を使用するのは役に立つかもしれません。

4.4 It is often assumed that a larger X.25 data packet size will result
    in increased performance.  This is not necessarily true: in typical
    X.25 networks it will actually decrease performance.

4.4 しばしばサイズがもたらすより大きいX.25データ・パケットが性能を増強したと思われます。 これは必ず本当であるというわけではありません: 典型的なX.25ネットワークでは、それは実際に性能を減少させるでしょう。

    Many, if not most, X.25 networks completely store X.25 data packets
    in each switch before forwarding them.  If the X.25 network requires
    a path through a number of switches, and low-speed trunks are used,

それらを進める前に、X.25がネットワークでつなぐ多く(大部分でなくても)が各スイッチにX.25データ・パケットを完全に保存します。 X.25ネットワークが多くのスイッチを通して経路を必要として、低速トランクスが使用されているなら

Malis, Robinson, & Ullmann                                      [Page 9]

RFC 1356           Multiprotocol Interconnect on X.25        August 1992

RFC1356MultiprotocolがX.25 August 1992でインタコネクトするMalis、ロビンソン、およびウルマン[9ページ]

    then negotiating and using large X.25 data packets could result in
    large transit delays through the X.25 network as a result of the
    time required to clock the data packets over each low-speed trunk.
    If a small end-to-end window size is also used, this may also
    adversely affect the end-to-end throughput of the X.25 circuit.  For
    this reason, segmenting large IP datagrams in the X.25 layer into
    complete packet sequences of smaller X.25 data packets allows a
    greater amount of pipelining through the X.25 switches, with
    subsequent improvements in end-to-end throughput.

次に、大きいX.25データ・パケットを交渉して、使用すると、時間の結果、X.25ネットワークを通した遅れがそれぞれの低速トランクでデータ・パケットの時間を計るのを必要とした大きいトランジットはもたらされるかもしれません。 また、また、終わりから妻窓への小さいサイズが使用されるなら、これは終わりから終わりへのX.25回路に関するスループットに悪影響を与えるかもしれません。 この理由で、X.25層の中で大きいIPデータグラムをより小さいX.25データ・パケットの完全なパケット系列に区分すると、より大きい量のパイプライン処理がX.25スイッチに通ることを許されます、終わりから終わりへのスループットにおけるその後の改良で。

    Large X.25 data packet size combined with slow (e.g., 9.6Kbps)
    physical circuits will also increase individual packet latency for
    other virtual circuits on the same path; this may cause unacceptable
    effects on, for example, X.29 connections.

また、遅い(例えば、9.6Kbps)実回線に結合された大きいX.25データ・パケットサイズは同じ経路の他の仮想の回路に個々のパケット潜在を増強するでしょう。 これは例えば、X.29接続への容認できない効果を引き起こすかもしれません。

    This discussion is further complicated by the fact that X.25
    networks are free to internally combine or split X.25 data packets
    as long as the complete packet sequence is preserved.


    The optimum X.25 data packet size is, therefore, dependent on the
    network, and is not necessarily the largest size offered by that


4.5 Another method of increasing performance is to open multiple virtual
    circuits to the same destination, specifying the same CUD.  Like
    packet size, this is not always the best method.

4.5 性能を増強する別のメソッドは同じCUDを指定して、複数の仮想の回路を同じ目的地に開けることです。 パケットサイズのように、これはいつも最も良いメソッドであるというわけではありません。

    When the throughput limitation is due to X.25 window size, opening
    multiple circuits effectively multiplies the window, and may
    increase performance.


    However, opening multiple circuits also competes more effectively
    for the physical path, by taking more shares of the available
    bandwidth.  While this may be desirable to the user of the
    encapsulation, it may be somewhat less desirable to the other users
    of the path.

しかしながら、複数の回路を開けると、また、物理的な経路は、利用可能な帯域幅の、より多くのシェアを取ることによって、より効果的に競争されます。 カプセル化のユーザにとって、これが望ましいかもしれない間、経路の他のユーザには、それはいくらか望ましくないかもしれません。

    Opening multiple circuits may also cause datagram sequencing and
    reordering problems in end systems with limited buffering (e.g., at
    the TCP level, receiving segments out of order, when a single
    circuit would have delivered them in order). This will only affect
    performance, not correctness of operation.

また、複数の初めの回路が限られたバッファリングでエンドシステムのデータグラム配列と再命令問題を引き起こすかもしれません(例えば、TCPの平らで、受信しているセグメントでは、故障しています、ただ一つの回路であるときに、整然とした状態でそれらを提供したでしょう)。 これは操作の正当性ではなく、性能に影響するだけでしょう。

    Opening multiple circuits may also increase the cost of delivering
    datagrams across a public data network.


Malis, Robinson, & Ullmann                                     [Page 10]

RFC 1356           Multiprotocol Interconnect on X.25        August 1992

RFC1356MultiprotocolがX.25 August 1992でインタコネクトするMalis、ロビンソン、およびウルマン[10ページ]

4.6 This document does not specify any method of dynamic IP to X.25 (or
    X.121) address resolution.  The problem is left for further study.

4.6 このドキュメントはX.25(または、X.121)アドレス解決にダイナミックなIPの少しのメソッドも指定しません。 問題はさらなる研究に発たれます。

    Typical present-day implementations use static tables of varying
    kinds, or an algorithmic transformation between IP and X.121
    addresses [7,9].  There are proposals for other methods.  In
    particular, RFC 1183 [10] describes Domain Name System (DNS)
    resource records that may be useful either for automatic resolution
    or for maintenance of static tables.  Use of these method(s) is
    entirely experimental at this time.

典型的な現代の実装は異なった種類の静的なテーブル、またはIPとX.121アドレス[7、9]の間のアルゴリズムの変換を使用します。 他のメソッドのための提案があります。 特に、RFC1183[10]は自動解決か静的なテーブルのメインテナンスの役に立つかもしれないドメインネームシステム(DNS)リソース記録について説明します。 これらのメソッドの使用はこのとき、完全に実験的です。

5. Packet Formats

5. パケット・フォーマット

   For each protocol encoding, the diagrams outline the call request and
   the data packet format. The data packet shown is the first of a
   complete packet (M bit) sequence.

それぞれのプロトコルコード化のために、ダイヤグラムは発呼要求とデータパケット・フォーマットについて概説します。 見せられたデータ・パケットは完全なパケット(Mは噛み付いた)系列の1番目です。

5.1 IP Encapsulation

5.1 IPカプセル化

    Call Request:


    | GFI, LCN, type | addresses | facilities | CC |

+----------------+-----------+------------+----+ | GFI(LCN)はタイプします。| アドレス| 施設| CC| +----------------+-----------+------------+----+

    X.25 data packets:


    | GFI, LCN, I    | IP datagram            |

+----------------+------------------------+ | GFI、LCN、I| IPデータグラム| +----------------+------------------------+

5.2 CLNP, ES-IS, IS-IS Encapsulation


    Call Request:


    | GFI, LCN, type | addresses | facilities | 81 |

+----------------+-----------+------------+----+ | GFI(LCN)はタイプします。| アドレス| 施設| 81 | +----------------+-----------+------------+----+

    X.25 data packets:


    | GFI, LCN, I    | CLNP, ES-IS, or IS-IS datagram |

+----------------+--------------------------------+ | GFI、LCN、I| CLNP、ES存在、-、データグラム| +----------------+--------------------------------+

    (Note that these datagrams are self-identifying in their
    first octet).


Malis, Robinson, & Ullmann                                     [Page 11]

RFC 1356           Multiprotocol Interconnect on X.25        August 1992

RFC1356MultiprotocolがX.25 August 1992でインタコネクトするMalis、ロビンソン、およびウルマン[11ページ]

5.3 SNAP Encapsulation

5.3 即座のカプセル化

    Call Request:


    | GFI, LCN, type | addresses | facilities | 80 | SNAP (5 octets) |

+----------------+-----------+------------+----+-----------------+ | GFI(LCN)はタイプします。| アドレス| 施設| 80 | SNAP(5つの八重奏)| +----------------+-----------+------------+----+-----------------+

    X.25 data packets:


    | GFI, LCN, I    | Protocol Data Unit (no SNAP header) |

+----------------+-------------------------------------+ | GFI、LCN、I| プロトコルData Unit(SNAPヘッダーがありません)| +----------------+-------------------------------------+

5.4 Null (Multiplexed) Encapsulation

5.4 ヌル(多重送信する)のカプセル化

    Call Request:


    | GFI, LCN, type | addresses | facilities | 00 |

+----------------+-----------+------------+----+ | GFI(LCN)はタイプします。| アドレス| 施設| 00 | +----------------+-----------+------------+----+

    X.25 data packets:


    | GFI, LCN, I    | NLPID (1 octet) | Protocol Data Unit  |

+----------------+-----------------+---------------------+ | GFI、LCN、I| NLPID(1つの八重奏)| プロトコルデータ単位| +----------------+-----------------+---------------------+

    Examples of data packets:


    Multiplexed IP datagram:


    | GFI, LCN, I    | CC | IP datagram           |

+----------------+----+-----------------------+ | GFI、LCN、I| CC| IPデータグラム| +----------------+----+-----------------------+

    Multiplexed CLNP datagram:


    | GFI, LCN, I    | 81 | CLNP datagram           |

+----------------+----+-------------------------+ | GFI、LCN、I| 81 | CLNPデータグラム| +----------------+----+-------------------------+

    Multiplexed SNAP PDU:


    | GFI, LCN, I    | 80 | SNAP (5 octets) | Protocol Data Unit |

+----------------+----+-----------------+--------------------+ | GFI、LCN、I| 80 | SNAP(5つの八重奏)| プロトコルデータ単位| +----------------+----+-----------------+--------------------+

Malis, Robinson, & Ullmann                                     [Page 12]

RFC 1356           Multiprotocol Interconnect on X.25        August 1992

RFC1356MultiprotocolがX.25 August 1992でインタコネクトするMalis、ロビンソン、およびウルマン[12ページ]

6. Security Considerations

6. セキュリティ問題

   Security issues are not discussed in this memo.


7. References

7. 参照

   [1]  Korb, J., "A Standard for the Transmission of IP Datagrams Over
        Public Data Networks", RFC 877, Purdue University, September


   [2]  ISO/IEC TR 9577, Information technology - Telecommunications and
        Information exchange between systems - Protocol Identification
        in the network layer, 1990 (E) 1990-10-15.

[2] ISO/IEC TR9577(情報技術(システムの間のテレコミュニケーションと情報交換))はネットワーク層(1990(E)1990年10月15日)でIdentificationについて議定書の中で述べます。

   [3]  IEEE, "IEEE Standard for Local and Metropolitan Area Networks:
        Overview and Architecture", IEEE Standards 802-1990.

[3] IEEE、「地方とメトロポリタンエリアネットワークのIEEE規格:」 「概要とアーキテクチャ」、IEEE規格802-1990。

   [4]  ISO/IEC 8473, Information processing systems - Data
        communications - Protocol for providing the connectionless- mode
        network service, 1988.

[4] ISO/IEC8473(情報処理システム(データ通信))は、コネクションレスなモードネットワーク・サービス、1988を提供するために議定書を作ります。

   [5]  ISO/IEC 9542, Information processing systems -
        Telecommunications and information exchange between systems -
        End system to intermediate system routeing protocol for use in
        conjunction with the protocol for providing the connectionless-
        mode network service (ISO/IEC 8473), 1988.

[5] ISO/IEC9542(情報処理システム(システムの間のテレコミュニケーションと情報交換))はプロトコルに関連したコネクションレスなモードネットワーク・サービス(ISO/IEC8473)、1988を提供する使用の中間システムrouteingプロトコルへのシステムを終わらせます。

   [6]  Postel, J., Editor., "Internet Protocol - DARPA Internet Program
        Protocol Specification", RFC 791, USC/Information Sciences
        Institute, September 1981.

[6] ポステル、J.、エディタ、「インターネットは議定書を作ります--DARPAインターネットはプロトコル仕様をプログラムする」RFC791、科学が設けるUSC/情報、9月1981日

   [7]  Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1340,
        USC/Information Sciences Institute, July 1992.


   [8]  Bradley, T., Brown, C., and A. Malis, "Multiprotocol
        Interconnect over Frame Relay", RFC 1294, Wellfleet
        Communications and BBN Communications, January 1992.


   [9]  "Defense Data Network X.25 Host Interface Specification",
        contained in "DDN Protocol Handbook", Volume 1, DDN Network
        Information Center 50004, December 1985.

[9] 「ディフェンスデータ網X.25ホスト・インターフェース仕様」は「DDNプロトコルハンドブック」、Volume1、DDN Networkにインフォメーション・センター50004(1985年12月)を含みました。

  [10]  Everhart, C., Mamakos, L., Ullmann, R, and P. Mockapetris,
        Editors, "New DNS RR Definitions", RFC 1183, Transarc,
        University of Maryland, Prime Computer, USC/Information Sciences
        Institute, October 1990.

[10] USC/情報科学が1990年10月に任命するエバーハートとC.とMamakosとL.とウルマン、RとP.Mockapetris、エディターズ、「新しいDNS RR定義」、RFC1183、Transarc、メリーランド大学、プライムコンピュータ。

  [11]  ISO/IEC 8208, Information processing systems - Data

[11] ISO/IEC8208、システム--データを処理する情報

Malis, Robinson, & Ullmann                                     [Page 13]

RFC 1356           Multiprotocol Interconnect on X.25        August 1992

RFC1356MultiprotocolがX.25 August 1992でインタコネクトするMalis、ロビンソン、およびウルマン[13ページ]

        communications - X.25 Packet Level Protocol for Data Terminal
        Equipment, 1987.

コミュニケーション--Data Terminal Equipment、1987年のX.25 Packet Levelプロトコル。

8. Authors' Addresses

8. 作者のアドレス

   Andrew G. Malis
   BBN Communications
   150 CambridgePark Drive
   Cambridge, MA 02140

アンドリューG.Malis BBNコミュニケーション150CambridgePark Drive MA02140ケンブリッジ(米国)

   Phone: +1 617 873 3419
   Email: malis@bbn.com

以下に電話をしてください。 +1 3419年の617 873メール: malis@bbn.com

   David Robinson
   Computervision Systems Integration
   201 Burlington Road
   Bedford, MA 01730

デイビッド・ロビンソンのComputervisionシステム・インテグレーション201バーリントンRoad MA01730ベッドフォード(米国)

   Phone: +1 617 275 1800 x2774
   Email: drb@relay.prime.com

以下に電話をしてください。 +1 1800年の617 275x2774メール: drb@relay.prime.com

   Robert L. Ullmann
   Process Software Corporation
   959 Concord Street
   Framingham, MA 01701


   Phone: +1 508 879 6994
   Email: ariel@process.com

以下に電話をしてください。 +1 6994年の508 879メール: ariel@process.com

Malis, Robinson, & Ullmann                                     [Page 14]




 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 


Got a packet bigger than 'max_allowed_packet' bytes