home *** CD-ROM | disk | FTP | other *** search
/ Internet Access: To the Information Highway / InternetAccessToTheInformationHighway1994.disc1of1.iso / internet / rfc4 / rfc1356.txt < prev    next >
Text File  |  1994-05-29  |  33KB  |  788 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                           A. Malis
  8. Request for Comments: 1356                            BBN Communications
  9. Obsoletes: RFC 877                                           D. Robinson
  10.                                       Computervision Systems Integration
  11.                                                               R. Ullmann
  12.                                             Process Software Corporation
  13.                                                              August 1992
  14.  
  15.  
  16.                        Multiprotocol Interconnect
  17.                   on X.25 and ISDN in the Packet Mode
  18.  
  19. Status of this Memo
  20.  
  21.    This RFC specifies an IAB standards track protocol for the Internet
  22.    community, and requests discussion and suggestions for improvements.
  23.    Please refer to the current edition of the "IAB Official Protocol
  24.    Standards" for the standardization state and status of this protocol.
  25.    Distribution of this memo is unlimited.
  26.  
  27. Abstract
  28.  
  29.    This document specifies the encapsulation of IP and other network
  30.    layer protocols over X.25 networks, in accordance and alignment with
  31.    ISO/IEC and CCITT standards.  It is a replacement for RFC 877, "A
  32.    Standard for the Transmission of IP Datagrams Over Public Data
  33.    Networks" [1].
  34.  
  35.    It was written to correct several ambiguities in the Internet
  36.    Standard for IP/X.25 (RFC 877), to align it with ISO/IEC standards
  37.    that have been written following RFC 877, to allow interoperable
  38.    multiprotocol operation between routers and bridges over X.25, and to
  39.    add some additional remarks based upon practical experience with the
  40.    specification over the 8 years since that RFC.
  41.  
  42.    The substantive change to the IP encapsulation is an increase in the
  43.    allowed IP datagram Maximum Transmission Unit from 576 to 1600, to
  44.    reflect existing practice.
  45.  
  46.    This document also specifies the Internet encapsulation for
  47.    protocols, including IP, on the packet mode of the ISDN.  It applies
  48.    to the use of Internet protocols on the ISDN in the circuit mode only
  49.    when the circuit is established as an end-to-end X.25 connection.
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Malis, Robinson, & Ullmann                                      [Page 1]
  59.  
  60. RFC 1356           Multiprotocol Interconnect on X.25        August 1992
  61.  
  62.  
  63. Acknowledgements
  64.  
  65.    RFC 877 was written by J. T. Korb of Purdue University, and this
  66.    document follows that RFC's format and builds upon its text as
  67.    appropriate.  This document was produced under the auspices of the IP
  68.    over Large Public Data Networks Working Group of the IETF.
  69.  
  70. 1. Conventions
  71.  
  72.    The following language conventions are used in the items of
  73.    specification in this document:
  74.  
  75.    o MUST -- the item is an absolute requirement of the specification.
  76.      MUST is only used where it is actually required for interoperation,
  77.      not to try to impose a particular method on implementors where not
  78.      required for interoperability.
  79.  
  80.    o SHOULD -- the item should be followed for all but exceptional
  81.      circumstances.
  82.  
  83.    o MAY or optional -- the item is truly optional and may be followed
  84.      or ignored according to the needs of the implementor.
  85.  
  86.    The words "should" and "may" are also used, in lower case, in their
  87.    more ordinary senses.
  88.  
  89. 2. Introduction
  90.  
  91.    RFC 877 was written to document the method CSNET and the VAN Gateway
  92.    had adopted to transmit IP datagrams over X.25 networks.  Its success
  93.    is evident in its current wide use and the inclusion of its IP
  94.    protocol identifier in ISO/IEC TR 9577, "Protocol Identification in
  95.    the Network Layer" [2], which is administered by ISO/IEC and CCITT.
  96.  
  97.    However, due to changes in the scope of X.25 and the protocols that
  98.    it can carry, several inadequacies have become evident in the RFC,
  99.    especially in the areas of IP datagram Maximum Transmission Unit
  100.    (MTU) size, X.25 maximum data packet size, virtual circuit
  101.    management, and the interoperable encapsulation, over X.25, of
  102.    protocols other than IP between multiprotocol routers and bridges.
  103.  
  104.    As with RFC 877, one or more X.25 virtual circuits are opened on
  105.    demand when datagrams arrive at the network interface for
  106.    transmission.  A virtual circuit is closed after some period of
  107.    inactivity (the length of the period depends on the cost associated
  108.    with an open virtual circuit).  A virtual circuit may also be closed
  109.    if the interface runs out of virtual circuits.
  110.  
  111.  
  112.  
  113.  
  114. Malis, Robinson, & Ullmann                                      [Page 2]
  115.  
  116. RFC 1356           Multiprotocol Interconnect on X.25        August 1992
  117.  
  118.  
  119. 3. Standards
  120.  
  121. 3.1 Protocol Data Units (PDUs) are sent as X.25 "complete packet
  122.     sequences".  That is, PDUs begin on X.25 data packet boundaries and
  123.     the M bit ("more data") is used to fragment PDUs that are larger
  124.     than one X.25 data packet in length.
  125.  
  126.     In the IP encapsulation the PDU is the IP datagram.
  127.  
  128. 3.2 The first octet in the Call User Data (CUD) Field (the first data
  129.     octet in the Call Request packet) is used for protocol
  130.     demultiplexing, in accordance with the Subsequent Protocol
  131.     Identifier (SPI) in ISO/IEC TR 9577.  This field contains a one-
  132.     octet Network Layer Protocol Identifier (NLPID), which identifies
  133.     the network layer protocol encapsulated over the X.25 virtual
  134.     circuit.  The CUD field MAY contain more than one octet of
  135.     information, and receivers MUST ignore all extraneous octets in the
  136.     field.
  137.  
  138.     In the following discussion, the most significant digit of the
  139.     binary numbers is left-most.
  140.  
  141.     For the Internet community, the NLPID has four relevant values:
  142.  
  143.     The value hex CC (binary 11001100, decimal 204) is IP [6].
  144.     Conformance with this specification requires that IP be supported.
  145.     See section 5.1 for a diagram of the packet formats.
  146.  
  147.     The value hex 81 (binary 10000001, decimal 129) identifies ISO/IEC
  148.     8473 (CLNP) [4].  ISO/IEC TR 9577 specifically allows other ISO/IEC
  149.     connectionless-protocol packets, such as ES-IS and IS-IS, to also be
  150.     carried on the same virtual circuit as CLNP.  Conformance with this
  151.     specification does not require that CLNP be supported.  See section
  152.     5.2 for a diagram of the packet formats.
  153.  
  154.     The value hex 82 (binary 10000010, decimal 130) is used specifically
  155.     for ISO/IEC 9542 (ES-IS) [5].  If there is already a circuit open to
  156.     carry CLNP, then it is not necessary to open a second circuit to
  157.     carry ES-IS.  Conformance with this specification does not require
  158.     that ES-IS be supported.
  159.  
  160.     The value hex 80 (binary 10000000, decimal 128) identifies the use
  161.     of IEEE Subnetwork Access Protocol (SNAP) [3] to further encapsulate
  162.     and identify a single network-layer protocol.  The SNAP-encapsulated
  163.     protocol is identified by including a five-octet SNAP header in the
  164.     Call Request CUD field immediately following the hex 80 octet.  SNAP
  165.     headers are not included in the subsequent X.25 data packets.  Only
  166.     one SNAP-encapsulated protocol may be carried over a virtual circuit
  167.  
  168.  
  169.  
  170. Malis, Robinson, & Ullmann                                      [Page 3]
  171.  
  172. RFC 1356           Multiprotocol Interconnect on X.25        August 1992
  173.  
  174.  
  175.     opened using this encoding.  The receiver SHOULD accept the incoming
  176.     call only if it can support the particular SNAP-identified protocol.
  177.     Conformance with this specification does not require that this SNAP
  178.     encoding be supported.  See section 5.3 for a diagram of the packet
  179.     formats.
  180.  
  181.     The value hex 00 (binary 00000000, decimal 0) identifies the Null
  182.     encapsulation, used to multiplex multiple network layer protocols
  183.     over the same circuit.  This encoding is further discussed in
  184.     section 3.3 below.
  185.  
  186.     The "Assigned Numbers" RFC [7] contains one other non-CCITT and
  187.     non-ISO/IEC value that has been in active use for Internet X.25
  188.     encapsulation identification, namely hex C5 (binary 11000101,
  189.     decimal 197) for Blacker X.25.  This value MAY continue to be used,
  190.     but only by prior preconfiguration of the sending and receiving X.25
  191.     interfaces to support this value.  The value hex CD (binary
  192.     11001101, decimal 205), listed in "Assigned Numbers" for "ISO-IP",
  193.     is also used by Blacker and also can only be used by prior
  194.     preconfiguration of the sending and receiving X.25 interfaces.
  195.  
  196.     Each system MUST only accept calls for protocols it can process;
  197.     every Internet system MUST be able to accept the CC encapsulation
  198.     for IP datagrams.  A system MUST NOT accept calls, and then
  199.     immediately clear them.  Accepting the call indicates to the calling
  200.     system that the protocol encapsulation is supported; on some
  201.     networks, a call accepted and cleared is charged, while a call
  202.     cleared in the request state is not charged.
  203.  
  204.     Systems that support NLPIDs other than hex CC (for IP) SHOULD allow
  205.     their use to be configured on a per-peer address basis.  The use of
  206.     hex CC (for IP) MUST always be allowed between peers and cannot be
  207.     configured.
  208.  
  209. 3.3 The NLPID encodings discussed in section 3.2 only allow a single
  210.     network layer protocol to be sent over a circuit.  The Null
  211.     encapsulation, identified by a NLPID encoding of hex 00, is used in
  212.     order to multiplex multiple network layer protocols over one
  213.     circuit.
  214.  
  215.     When the Null encapsulation is used, each X.25 complete packet
  216.     sequence sent on the circuit begins with a one-octet NLPID, which
  217.     identifies the network layer protocol data unit contained only in
  218.     that particular complete packet sequence.  Further, if the SNAP
  219.     NLPID (hex 80) is used, then the NLPID octet is immediately followed
  220.     by the five-octet SNAP header, which is then immediately followed by
  221.     the encapsulated PDU.  The encapsulated network layer protocol MAY
  222.     differ from one complete packet sequence to the next over the same
  223.  
  224.  
  225.  
  226. Malis, Robinson, & Ullmann                                      [Page 4]
  227.  
  228. RFC 1356           Multiprotocol Interconnect on X.25        August 1992
  229.  
  230.  
  231.     circuit.
  232.  
  233.     When a receiver is presented with an Incoming Call identifying the
  234.     Null encapsulation, the receiver MUST accept the call if it supports
  235.     the Null encapsulation for any network layer protocol.  The receiver
  236.     MAY then silently discard a multiplexed PDU if it cannot support
  237.     that particular encapsulated protocol.  See section 5.4 for a
  238.     diagram of the packet formats.
  239.  
  240.     Use of the single network layer protocol circuits described in
  241.     section 3.2 is more efficient in terms of bandwidth if only a
  242.     limited number of protocols are supported by a system.  It also
  243.     allows each system to determine exactly which protocols are
  244.     supported by its communicating partner.  Other advantages include
  245.     being able to use X.25 accounting to detail each protocol and
  246.     different quality of service or flow control windows for different
  247.     protocols.
  248.  
  249.     The Null encapsulation, for multiplexing, is useful when a system,
  250.     for any reason (such as implementation restrictions or network cost
  251.     considerations), may only open a limited number of virtual circuits
  252.     simultaneously.  This is the method most likely to be used by a
  253.     multiprotocol router, to avoid using an unreasonable number of
  254.     virtual circuits.
  255.  
  256.     If performing IEEE 802.1d bridging across X.25 is desired, then the
  257.     Null encapsulation MUST be used.  See section 4.2 for a further
  258.     discussion.
  259.  
  260.     Conformance with this specification does not require that the Null
  261.     encapsulation be supported.
  262.  
  263.     Systems that support the Null encapsulation SHOULD allow its use to
  264.     be configured on a per-peer address basis.
  265.  
  266. 3.4 For compatibility with existing practice, and RFC 877 systems, IP
  267.     datagrams MUST, by default, be encapsulated on a virtual circuit
  268.     opened with the CC CUD.
  269.  
  270.     Implementations MAY also support up to three other possible
  271.     encapsulations of IP:
  272.  
  273.    o IP may be contained in multiplexed data packets on a circuit using
  274.      the Null (multiplexed) encapsulation.  Such data packets are
  275.      identified by a NLPID of hex CC.
  276.  
  277.    o IP may be encapsulated within the SNAP encapsulation on a circuit.
  278.      This encapsulation is identified by containing, in the 5-octet SNAP
  279.  
  280.  
  281.  
  282. Malis, Robinson, & Ullmann                                      [Page 5]
  283.  
  284. RFC 1356           Multiprotocol Interconnect on X.25        August 1992
  285.  
  286.  
  287.      header, an Organizationally Unique Identifier (OUI) of hex 00-00-00
  288.      and Protocol Identifier (PID) of hex 08-00.
  289.  
  290.    o On a circuit using the Null encapsulation, IP may be contained
  291.      within the SNAP encapsulation of IP in multiplexed data packets.
  292.  
  293.     If an implementation supports the SNAP, multiplexed, and/or
  294.     multiplexed SNAP encapsulations, then it MUST accept the encoding of
  295.     IP within the supported encapsulation(s), MAY send IP using those
  296.     encapsulation(s), and MUST allow the IP encapsulation to send to be
  297.     configured on a per-peer address basis.
  298.  
  299. 3.5 The negotiable facilities of X.25 MAY be used (e.g., packet and
  300.     window size negotiation).  Since PDUs are sent as complete packet
  301.     sequences, any maximum X.25 data packet size MAY be configured or
  302.     negotiated between systems and their network service providers.  See
  303.     section 4.5 for a discussion of maximum X.25 data packet size and
  304.     network performance.
  305.  
  306.     There is no implied relationship between PDU size and X.25 packet
  307.     size (i.e., the method of setting IP MTU based on X.25 packet size
  308.     in RFC 877 is not used).
  309.  
  310. 3.6 Every system MUST be able to receive and transmit PDUs up to at
  311.     least 1600 octets in length.
  312.  
  313.     For compatibility with existing practice, as well as
  314.     interoperability with RFC 877 systems, the default transmit MTU for
  315.     IP datagrams SHOULD default to 1500, and MUST be configurable in at
  316.     least the range 576 to 1600.
  317.  
  318.     This is done with a view toward a standard default IP MTU of 1500,
  319.     used on both local and wide area networks with no fragmentation at
  320.     routers. Actually redefining the IP default MTU is, of course,
  321.     outside the scope of this specification.
  322.  
  323.     The PDU size (e.g., IP MTU) MUST be configurable, on at least a
  324.     per-interface basis.  The maximum transmitted PDU length SHOULD be
  325.     configurable on a per-peer basis, and MAY be configurable on a per-
  326.     encapsulation basis as well.  Note that the ability to configure to
  327.     send IP datagrams with an MTU of 576 octets and to receive IP
  328.     datagrams of 1600 octets is essential to interoperate with existing
  329.     implementations of RFC 877 and implementations of this
  330.     specification.
  331.  
  332.     Note that on circuits using the Null (multiplexed) encapsulation,
  333.     when IP packets are encapsulated using the NLPID of hex CC, then the
  334.     default IP MTU of 1500 implies a PDU size of 1501; a PDU size of
  335.  
  336.  
  337.  
  338. Malis, Robinson, & Ullmann                                      [Page 6]
  339.  
  340. RFC 1356           Multiprotocol Interconnect on X.25        August 1992
  341.  
  342.  
  343.     1600 implies an IP MTU of 1599.  When IP packets are encapsulated
  344.     using the NLPID of hex 80 followed by the SNAP header for IP, then
  345.     the default IP MTU of 1500 implies a PDU size of 1506; a PDU size of
  346.     1600 implies an IP MTU of 1594.
  347.  
  348.     Of course, an implementation MAY support a maximum PDU size larger
  349.     than 1600 octets.  In particular, there is no limit to the size that
  350.     may be used when explicitly configured by communicating peers.
  351.  
  352. 3.7 Each ISO/IEC TR 9577 encapsulation (e.g., IP, CLNP, and SNAP)
  353.     requires a separate virtual circuit between systems.  In addition,
  354.     multiple virtual circuits for a single encapsulation MAY be used
  355.     between systems, to, for example, increase throughput (see notes in
  356.     section 4.5).
  357.  
  358.     Receivers SHOULD accept multiple incoming calls with the same
  359.     encapsulation from a single system.  Having done so, receivers MUST
  360.     then accept incoming PDUs on the additional circuit(s), and SHOULD
  361.     transmit on the additional circuits.
  362.  
  363.     Shedding load by refusing additional calls for the same
  364.     encapsulation with a X.25 diagnostic of 0 (DTE clearing) is correct
  365.     practice, as is shortening inactivity timers to try to clear
  366.     circuits.
  367.  
  368.     Receivers MUST NOT accept the incoming call, only to close the
  369.     circuit or ignore PDUs from the circuit.
  370.  
  371.     Because opening multiple virtual circuits specifying the same
  372.     encapsulation is specifically allowed, algorithms to prevent virtual
  373.     circuit call collision, such as the one found in section 8.4.3.5 of
  374.     ISO/IEC 8473 [4], MUST NOT be implemented.
  375.  
  376.     While allowing multiple virtual circuits for a single protocol is
  377.     specifically desired and allowed, implementations MAY choose (by
  378.     configuration) to permit only a single circuit for some protocols to
  379.     some destinations.  Only in such a case, if a colliding incoming
  380.     call is received while a call request is pending, the incoming call
  381.     shall be rejected.  Note that this may result in a failure to
  382.     establish a connection.  In such a case, each system shall wait at
  383.     least a configurable collision retry time before retrying.  Adding a
  384.     random increment, with exponential backoff if necessary, is
  385.     recommended.
  386.  
  387. 3.8 Either system MAY close a virtual circuit.  If the virtual circuit
  388.     is closed or reset while a datagram is being transmitted, the
  389.     datagram is lost.  Systems SHOULD be able to configure a minimum
  390.     holding time for circuits to remain open as long as the endpoints
  391.  
  392.  
  393.  
  394. Malis, Robinson, & Ullmann                                      [Page 7]
  395.  
  396. RFC 1356           Multiprotocol Interconnect on X.25        August 1992
  397.  
  398.  
  399.     are up. (Note that holding time, the time the circuit has been open,
  400.     differs from idle time.)
  401.  
  402. 3.9 Each system MUST use an inactivity timer to clear virtual circuits
  403.     that are idle for some period of time.  Some X.25 networks,
  404.     including the ISDN under present tariffs in most areas, charge for
  405.     virtual circuit holding time.  Even where they do not, the resource
  406.     SHOULD be released when idle.  The timer SHOULD be configurable; a
  407.     timer value of "infinite" is acceptable when explicitly configured.
  408.     The default SHOULD be a small number of minutes.  For IP, a
  409.     reasonable default is 90 seconds.
  410.  
  411. 3.10 Systems SHOULD allow calls from unconfigured calling addresses
  412.      (presumably not collect calls, however); this SHOULD be a
  413.      configuration option.  A system accepting such a call will, of
  414.      course, not transmit on that virtual circuit if it cannot determine
  415.      the protocol (e.g., IP) address of the caller.  As an example, on
  416.      the DDN this is not a restriction because IP addresses can be
  417.      determined algorithmically based upon the caller's X.121 address
  418.      [7,9].
  419.  
  420.      Allowing such calls helps work around various "helpful" address
  421.      translations done by the network(s), as well as allowing
  422.      experimentation with various address resolution protocols.
  423.  
  424. 3.11 Systems SHOULD use a configurable hold-down timer to prevent calls
  425.      to failed destinations from being immediately retried.
  426.  
  427. 3.12 X.25 implementations MUST minimally support the following features
  428.      in order to conform with this specification: call setup and
  429.      clearing and complete packet sequences.  For better performance
  430.      and/or interoperability, X.25 implementations SHOULD also support:
  431.      extended frame and/or packet sequence numbering, flow control
  432.      parameter negotiation, and reverse charging.
  433.  
  434. 3.13 The following X.25 features MUST NOT be used: interrupt packets and
  435.      the Q bit (indicating qualified data).  Other X.25 features not
  436.      explicitly discussed in this document, such as fast select and the
  437.      D bit (indicating end-to-end significance) SHOULD NOT be used.
  438.  
  439.      Use of the D bit will interfere with use of the M bit (more data
  440.      sequences) required for identification of PDUs.  In particular, as
  441.      subscription to the D bit modification facility (X.25-1988, section
  442.      3.3) will prevent proper operation, this user facility MUST NOT be
  443.      subscribed.
  444.  
  445. 3.14 ISO/IEC 8208 [11] defines the clearing diagnostic code 249 to
  446.      signify that a requested protocol is not supported.  Systems MAY
  447.  
  448.  
  449.  
  450. Malis, Robinson, & Ullmann                                      [Page 8]
  451.  
  452. RFC 1356           Multiprotocol Interconnect on X.25        August 1992
  453.  
  454.  
  455.      use this diagnostic code when clearing an incoming call because the
  456.      identified protocol is not supported.  Non-8208 systems more
  457.      typically use a diagnostic code of 0 for this function.  Supplying
  458.      a diagnostic code is not mandatory, but when it is supplied for
  459.      this reason, it MUST be either of these two values.
  460.  
  461. 4. General Remarks
  462.  
  463.    The following remarks are not specifications or requirements for
  464.    implementations, but provide developers and users with guidelines and
  465.    the results of operational experience with RFC 877.
  466.  
  467. 4.1 Protocols above the network layer, such as TCP or TP4, do not
  468.     affect this standard.  In particular, no attempt is made to open
  469.     X.25 virtual circuits corresponding to TCP or TP4 connections.
  470.  
  471. 4.2 Both the circuit and multiplexed encapsulations of SNAP may be used
  472.     to contain any SNAP encapsulated protocol.  In particular, this
  473.     includes using an OUI of 00-00-00 and the two octets of PID
  474.     containing an Ethertype [7], or using IEEE 802.1's OUI of hex 00-
  475.     80-C2 with the bridging PIDs listed in RFC 1294, "Multiprotocol
  476.     Interconnect over Frame Relay" [8].  Note that IEEE 802.1d bridging
  477.     can only be performed over a circuit using the Null (multiplexed)
  478.     encapsulation of SNAP, because of the necessity of preserving the
  479.     order of PDUs (including 802.1d Bridged PDUs) using different SNAP
  480.     headers.
  481.  
  482. 4.3 Experience has shown that there are X.25 implementations that will
  483.     assign calls with CC CUD to the X.29 PAD (remote login) facility
  484.     when the IP layer is not installed, not configured properly, or not
  485.     operating (indeed, they assume that ALL calls for unconfigured or
  486.     unbound X.25 protocol IDs are for X.29 PAD sessions).  Call
  487.     originators can detect that this has occurred at the receiver if the
  488.     originator receives any X.25 data packets with the Q bit set,
  489.     especially if the first octet of these packets is hex 02, 04, or 06
  490.     (X.29 PAD parameter commands).  In this case, the originator should
  491.     clear the call, and log the occurrence so that the misconfigured
  492.     X.25 address can be corrected.  It may be useful to also use the
  493.     hold-down timer (see section 3.11) to prevent further attempts for
  494.     some period of time.
  495.  
  496. 4.4 It is often assumed that a larger X.25 data packet size will result
  497.     in increased performance.  This is not necessarily true: in typical
  498.     X.25 networks it will actually decrease performance.
  499.  
  500.     Many, if not most, X.25 networks completely store X.25 data packets
  501.     in each switch before forwarding them.  If the X.25 network requires
  502.     a path through a number of switches, and low-speed trunks are used,
  503.  
  504.  
  505.  
  506. Malis, Robinson, & Ullmann                                      [Page 9]
  507.  
  508. RFC 1356           Multiprotocol Interconnect on X.25        August 1992
  509.  
  510.  
  511.     then negotiating and using large X.25 data packets could result in
  512.     large transit delays through the X.25 network as a result of the
  513.     time required to clock the data packets over each low-speed trunk.
  514.     If a small end-to-end window size is also used, this may also
  515.     adversely affect the end-to-end throughput of the X.25 circuit.  For
  516.     this reason, segmenting large IP datagrams in the X.25 layer into
  517.     complete packet sequences of smaller X.25 data packets allows a
  518.     greater amount of pipelining through the X.25 switches, with
  519.     subsequent improvements in end-to-end throughput.
  520.  
  521.     Large X.25 data packet size combined with slow (e.g., 9.6Kbps)
  522.     physical circuits will also increase individual packet latency for
  523.     other virtual circuits on the same path; this may cause unacceptable
  524.     effects on, for example, X.29 connections.
  525.  
  526.     This discussion is further complicated by the fact that X.25
  527.     networks are free to internally combine or split X.25 data packets
  528.     as long as the complete packet sequence is preserved.
  529.  
  530.     The optimum X.25 data packet size is, therefore, dependent on the
  531.     network, and is not necessarily the largest size offered by that
  532.     network.
  533.  
  534. 4.5 Another method of increasing performance is to open multiple virtual
  535.     circuits to the same destination, specifying the same CUD.  Like
  536.     packet size, this is not always the best method.
  537.  
  538.     When the throughput limitation is due to X.25 window size, opening
  539.     multiple circuits effectively multiplies the window, and may
  540.     increase performance.
  541.  
  542.     However, opening multiple circuits also competes more effectively
  543.     for the physical path, by taking more shares of the available
  544.     bandwidth.  While this may be desirable to the user of the
  545.     encapsulation, it may be somewhat less desirable to the other users
  546.     of the path.
  547.  
  548.     Opening multiple circuits may also cause datagram sequencing and
  549.     reordering problems in end systems with limited buffering (e.g., at
  550.     the TCP level, receiving segments out of order, when a single
  551.     circuit would have delivered them in order). This will only affect
  552.     performance, not correctness of operation.
  553.  
  554.     Opening multiple circuits may also increase the cost of delivering
  555.     datagrams across a public data network.
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Malis, Robinson, & Ullmann                                     [Page 10]
  563.  
  564. RFC 1356           Multiprotocol Interconnect on X.25        August 1992
  565.  
  566.  
  567. 4.6 This document does not specify any method of dynamic IP to X.25 (or
  568.     X.121) address resolution.  The problem is left for further study.
  569.  
  570.     Typical present-day implementations use static tables of varying
  571.     kinds, or an algorithmic transformation between IP and X.121
  572.     addresses [7,9].  There are proposals for other methods.  In
  573.     particular, RFC 1183 [10] describes Domain Name System (DNS)
  574.     resource records that may be useful either for automatic resolution
  575.     or for maintenance of static tables.  Use of these method(s) is
  576.     entirely experimental at this time.
  577.  
  578. 5. Packet Formats
  579.  
  580.    For each protocol encoding, the diagrams outline the call request and
  581.    the data packet format. The data packet shown is the first of a
  582.    complete packet (M bit) sequence.
  583.  
  584. 5.1 IP Encapsulation
  585.  
  586.     Call Request:
  587.  
  588.     +----------------+-----------+------------+----+
  589.     | GFI, LCN, type | addresses | facilities | CC |
  590.     +----------------+-----------+------------+----+
  591.  
  592.     X.25 data packets:
  593.  
  594.     +----------------+------------------------+
  595.     | GFI, LCN, I    | IP datagram            |
  596.     +----------------+------------------------+
  597.  
  598. 5.2 CLNP, ES-IS, IS-IS Encapsulation
  599.  
  600.     Call Request:
  601.  
  602.     +----------------+-----------+------------+----+
  603.     | GFI, LCN, type | addresses | facilities | 81 |
  604.     +----------------+-----------+------------+----+
  605.  
  606.     X.25 data packets:
  607.  
  608.     +----------------+--------------------------------+
  609.     | GFI, LCN, I    | CLNP, ES-IS, or IS-IS datagram |
  610.     +----------------+--------------------------------+
  611.  
  612.     (Note that these datagrams are self-identifying in their
  613.     first octet).
  614.  
  615.  
  616.  
  617.  
  618. Malis, Robinson, & Ullmann                                     [Page 11]
  619.  
  620. RFC 1356           Multiprotocol Interconnect on X.25        August 1992
  621.  
  622.  
  623. 5.3 SNAP Encapsulation
  624.  
  625.     Call Request:
  626.  
  627.     +----------------+-----------+------------+----+-----------------+
  628.     | GFI, LCN, type | addresses | facilities | 80 | SNAP (5 octets) |
  629.     +----------------+-----------+------------+----+-----------------+
  630.  
  631.     X.25 data packets:
  632.  
  633.     +----------------+-------------------------------------+
  634.     | GFI, LCN, I    | Protocol Data Unit (no SNAP header) |
  635.     +----------------+-------------------------------------+
  636.  
  637. 5.4 Null (Multiplexed) Encapsulation
  638.  
  639.     Call Request:
  640.  
  641.     +----------------+-----------+------------+----+
  642.     | GFI, LCN, type | addresses | facilities | 00 |
  643.     +----------------+-----------+------------+----+
  644.  
  645.     X.25 data packets:
  646.  
  647.     +----------------+-----------------+---------------------+
  648.     | GFI, LCN, I    | NLPID (1 octet) | Protocol Data Unit  |
  649.     +----------------+-----------------+---------------------+
  650.  
  651.     Examples of data packets:
  652.  
  653.     Multiplexed IP datagram:
  654.  
  655.     +----------------+----+-----------------------+
  656.     | GFI, LCN, I    | CC | IP datagram           |
  657.     +----------------+----+-----------------------+
  658.  
  659.     Multiplexed CLNP datagram:
  660.  
  661.     +----------------+----+-------------------------+
  662.     | GFI, LCN, I    | 81 | CLNP datagram           |
  663.     +----------------+----+-------------------------+
  664.  
  665.     Multiplexed SNAP PDU:
  666.  
  667.     +----------------+----+-----------------+--------------------+
  668.     | GFI, LCN, I    | 80 | SNAP (5 octets) | Protocol Data Unit |
  669.     +----------------+----+-----------------+--------------------+
  670.  
  671.  
  672.  
  673.  
  674. Malis, Robinson, & Ullmann                                     [Page 12]
  675.  
  676. RFC 1356           Multiprotocol Interconnect on X.25        August 1992
  677.  
  678.  
  679. 6. Security Considerations
  680.  
  681.    Security issues are not discussed in this memo.
  682.  
  683. 7. References
  684.  
  685.    [1]  Korb, J., "A Standard for the Transmission of IP Datagrams Over
  686.         Public Data Networks", RFC 877, Purdue University, September
  687.         1983.
  688.  
  689.    [2]  ISO/IEC TR 9577, Information technology - Telecommunications and
  690.         Information exchange between systems - Protocol Identification
  691.         in the network layer, 1990 (E) 1990-10-15.
  692.  
  693.    [3]  IEEE, "IEEE Standard for Local and Metropolitan Area Networks:
  694.         Overview and Architecture", IEEE Standards 802-1990.
  695.  
  696.    [4]  ISO/IEC 8473, Information processing systems - Data
  697.         communications - Protocol for providing the connectionless- mode
  698.         network service, 1988.
  699.  
  700.    [5]  ISO/IEC 9542, Information processing systems -
  701.         Telecommunications and information exchange between systems -
  702.         End system to intermediate system routeing protocol for use in
  703.         conjunction with the protocol for providing the connectionless-
  704.         mode network service (ISO/IEC 8473), 1988.
  705.  
  706.    [6]  Postel, J., Editor., "Internet Protocol - DARPA Internet Program
  707.         Protocol Specification", RFC 791, USC/Information Sciences
  708.         Institute, September 1981.
  709.  
  710.    [7]  Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1340,
  711.         USC/Information Sciences Institute, July 1992.
  712.  
  713.    [8]  Bradley, T., Brown, C., and A. Malis, "Multiprotocol
  714.         Interconnect over Frame Relay", RFC 1294, Wellfleet
  715.         Communications and BBN Communications, January 1992.
  716.  
  717.    [9]  "Defense Data Network X.25 Host Interface Specification",
  718.         contained in "DDN Protocol Handbook", Volume 1, DDN Network
  719.         Information Center 50004, December 1985.
  720.  
  721.   [10]  Everhart, C., Mamakos, L., Ullmann, R, and P. Mockapetris,
  722.         Editors, "New DNS RR Definitions", RFC 1183, Transarc,
  723.         University of Maryland, Prime Computer, USC/Information Sciences
  724.         Institute, October 1990.
  725.  
  726.   [11]  ISO/IEC 8208, Information processing systems - Data
  727.  
  728.  
  729.  
  730. Malis, Robinson, & Ullmann                                     [Page 13]
  731.  
  732. RFC 1356           Multiprotocol Interconnect on X.25        August 1992
  733.  
  734.  
  735.         communications - X.25 Packet Level Protocol for Data Terminal
  736.         Equipment, 1987.
  737.  
  738. 8. Authors' Addresses
  739.  
  740.    Andrew G. Malis
  741.    BBN Communications
  742.    150 CambridgePark Drive
  743.    Cambridge, MA 02140
  744.    USA
  745.  
  746.    Phone: +1 617 873 3419
  747.    Email: malis@bbn.com
  748.  
  749.  
  750.    David Robinson
  751.    Computervision Systems Integration
  752.    201 Burlington Road
  753.    Bedford, MA 01730
  754.    USA
  755.  
  756.    Phone: +1 617 275 1800 x2774
  757.    Email: drb@relay.prime.com
  758.  
  759.  
  760.    Robert L. Ullmann
  761.    Process Software Corporation
  762.    959 Concord Street
  763.    Framingham, MA 01701
  764.    USA
  765.  
  766.    Phone: +1 508 879 6994
  767.    Email: ariel@process.com
  768.  
  769.  
  770.  
  771.  
  772.  
  773.  
  774.  
  775.  
  776.  
  777.  
  778.  
  779.  
  780.  
  781.  
  782.  
  783.  
  784.  
  785.  
  786. Malis, Robinson, & Ullmann                                     [Page 14]
  787.  
  788.