home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc1613 < prev    next >
Text File  |  1994-05-11  |  29KB  |  732 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         J. Forster
  8. Request for Comments: 1613                                       G. Satz
  9. Category: Informational                                         G. Glick
  10.                                                      cisco Systems, Inc.
  11.                                                                   R. Day
  12.                                                                    JANET
  13.                                                                 May 1994
  14.  
  15.  
  16.                    cisco Systems X.25 over TCP (XOT)
  17.  
  18. Status of this Memo
  19.  
  20.    This memo provides information for the Internet community.  This memo
  21.    does not specify an Internet standard of any kind.  Distribution of
  22.    this memo is unlimited.
  23.  
  24. Table of Contents
  25.  
  26.    1.  Introduction....................................................1
  27.    2.  Conventions.....................................................2
  28.    3.  Relationship Between XOT and X.25...............................2
  29.    4.  Overall Packet Format...........................................3
  30.    4.1   XOT Header....................................................4
  31.    5.  TCP Connection, Port Number, and Logical Channel Numbers (LCNs).4
  32.    6.  XOT Packets.....................................................5
  33.    6.1   Virtual Circuit Setup and Clearing............................5
  34.    6.2   Data and Flow Control.........................................6
  35.    6.3   Interrupt, and Reset Packets..................................8
  36.    6.4   Restart, DTE Reject, Diagnostics, and Registration............8
  37.    6.5   PVC Setup.....................................................8
  38.    7.  Acknowledgments................................................12
  39.    8.  Security Considerations........................................12
  40.    9.  References.....................................................12
  41.   10.  Authors' Addresses.............................................13
  42.  
  43. 1. Introduction
  44.  
  45.    It is sometimes desirable to transport X.25 over IP internets.  The
  46.    X.25 Packet Level requires a reliable link level below it and
  47.    normally uses LAPB.  This memo documents a method of sending X.25
  48.    packets over IP internets by encapsulating the X.25 Packet Level in
  49.    TCP packets.
  50.  
  51.    TCP provides a reliable byte stream.  X.25 requires that the layer
  52.    below it provide message semantics, in particular the boundary
  53.    between packets.  To provide this, a small (4-byte) XOT header is
  54.    used between TCP and X.25.  The primary content of this header is a
  55.  
  56.  
  57.  
  58. Forster, Satz, Glick & Day                                      [Page 1]
  59.  
  60. RFC 1613                  X.25 Over TCP (XOT)                   May 1994
  61.  
  62.  
  63.    length field, which is used to separate the X.25 packets within the
  64.    TCP stream.
  65.  
  66.    In general, the normal X.25 protocol packet formats and state
  67.    transition rules apply to the X.25 layer in XOT.  Exceptions to this
  68.    are noted.
  69.  
  70. 2. Conventions
  71.  
  72.    The following language conventions are used in the items of
  73.    specification in this document:
  74.  
  75.       o   MUST, SHALL, or MANDATORY -- This item is an absolute
  76.           requirement of the specification.
  77.  
  78.       o   SHOULD or RECOMMEND -- This item should generally be followed
  79.           for all but exceptional circumstances.
  80.  
  81.       o   MAY or OPTIONAL -- This item is truly optional and may be
  82.           followed or ignored according to the needs of the implementor.
  83.  
  84.    In some places in this document, there is parenthetical material
  85.    labeled "DISCUSSION".  This material is intended to give
  86.    clarification and explanation of the preceding text.
  87.  
  88. 3. Relationship Between XOT and X.25
  89.  
  90.    When a networking device (a host, router, etc.) has an X.25 engine
  91.    (i.e., protocol implementation), that engine  may be connected to
  92.    interface(s) running LAPB, and/or to logical interface(s) running LLC
  93.    or XOT/TCP/IP.  In general, the XOT layer itself is not at all
  94.    sensitive to what kind of packets the X.25 engine passes to it.
  95.    However, to improve interoperability between separate
  96.    implementations, this document in some cases does specify behavior of
  97.    the X.25 engine.
  98.  
  99.    While this document primarily discusses XOT from the perspective of
  100.    switching X.25 traffic (i.e., connecting an X.25 Virtual Circuit
  101.    between the local X.25 interfaces of two networking devices), this
  102.    should not prevent a host from offering X.25 connectivity using XOT.
  103.  
  104.    The various X.25 standards may call a given packet type by a
  105.    different name according to the assigned DTE/DCE role of the
  106.    interface that originated the packet.  XOT is intended to be
  107.    insensitive to the DTE/DCE role of the local interfaces at either end
  108.    of an XOT TCP connection, so, for this document, the following terms
  109.    are interchangeable unless stated otherwise:
  110.  
  111.  
  112.  
  113.  
  114. Forster, Satz, Glick & Day                                      [Page 2]
  115.  
  116. RFC 1613                  X.25 Over TCP (XOT)                   May 1994
  117.  
  118.  
  119.       o  Call, Call Request and Incoming Call
  120.       o  Call Confirm, Call Accepted and Call Connected
  121.       o  Clear, Clear Request and Clear Indication
  122.       o  Clear Confirm, DTE Clear Confirmation and DCE Clear Confirmation
  123.       o  Data, DTE Data and DCE Data
  124.       o  Interrupt, DTE Interrupt and DCE Interrupt
  125.       o  Interrupt Confirm, DTE Interrupt Confirmation and
  126.            DCE Interrupt Confirmation
  127.       o  RR, DTE RR and DCE RR
  128.       o  RNR, DTE RNR and DCE RNR
  129.       o  REJ, Reject and DTE REJ
  130.       o  Reset, Reset Request and Reset Indication
  131.       o  Reset Confirm, DTE Reset Confirmation and DCE Reset Confirmation
  132.       o  Restart, Restart Request and Restart Indication
  133.       o  Restart Confirm, DTE Restart Confirmation and
  134.            DCE Restart Confirmation
  135.  
  136. 4. Overall Packet Format
  137.  
  138.    The entire encapsulated packet has the following format:
  139.  
  140.                   ---------------------------------
  141.                   |                               |
  142.                   |       IP Header               |
  143.                   |                               |
  144.                   ---------------------------------
  145.                   |                               |
  146.                   |       TCP Header              |
  147.                   |                               |
  148.                   ---------------------------------
  149.                   |                               |
  150.                   |       XOT Header              |
  151.                   |                               |
  152.                   ---------------------------------
  153.                   |                               |
  154.                   |       X.25  Packet            |
  155.                   |                               |
  156.                   ---------------------------------
  157.  
  158.    RFC convention is that a packet format is represented graphically
  159.    with the data sent first above the data sent later.  This convention
  160.    is followed in this document, and therefore, while we refer to X.25
  161.    being transported over TCP, we draw the packet format with the X.25
  162.    portion of the packet lower on the page than the TCP portion.
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Forster, Satz, Glick & Day                                      [Page 3]
  171.  
  172. RFC 1613                  X.25 Over TCP (XOT)                   May 1994
  173.  
  174.  
  175. 4.1 XOT Header
  176.  
  177.    The XOT header has the format:
  178.  
  179.        0                   1                   2                   3
  180.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  181.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  182.       |          Version              |           Length              |
  183.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  184.  
  185.       Version (2 octets)
  186.  
  187.          The version number of the XOT protocol is encoded in the first
  188.          two octets.  The version number MUST be 0.  Other values of
  189.          this field are reserved for future use.  If a value other than
  190.          0 is received, then the TCP connection MUST be closed.
  191.  
  192.       Length (2 octets)
  193.  
  194.          The length of the X.25 packet is encoded in the second two
  195.          octets.  Values must be legal X.25 packet lengths.  If the
  196.          Length field has an illegal value, then the TCP connection MUST
  197.          be closed.
  198.  
  199. 5. TCP Connection, Port Number, and Logical Channel Numbers (LCNs)
  200.  
  201.    A separate TCP connection MUST be used for each X.25 virtual circuit.
  202.    All connections MUST be made to TCP port number 1998.  This port
  203.    number is an IANA Registered Port Number registered by cisco Systems;
  204.    cisco has designated it for use by XOT.
  205.  
  206.    The TCP connection MUST be created before the virtual circuit can be
  207.    established.  The TCP connection MAY be maintained after the virtual
  208.    circuit has been cleared.  Data MUST NOT be passed along with the TCP
  209.    SYN packet.
  210.  
  211.    The Logical Channel Number (LCN) field in the X.25 header has no
  212.    significance and has arbitrary values.  A corollary of this is that
  213.    there is no assignment of one side of the connection to be DTE and
  214.    another to be DCE.
  215.  
  216.    DISCUSSION
  217.  
  218.       Consider three devices A, B and C, where A and B both conduct XOT
  219.       sessions to C.  It's possible that C could receive two calls with
  220.       the same LCN and, unless the X.25 engine could tell that they were
  221.       received on different logical (XOT) interfaces, here would a
  222.       danger of call collision (indeed a valid LCN on one interface may
  223.  
  224.  
  225.  
  226. Forster, Satz, Glick & Day                                      [Page 4]
  227.  
  228. RFC 1613                  X.25 Over TCP (XOT)                   May 1994
  229.  
  230.  
  231.       not even be valid on a different interface).  It is therefore
  232.       necessary for C's X.25 engine to distinguish between the two
  233.       streams, but the LCN field is not sufficient to do this.  The XOT
  234.       protocol design decision was to expect the XOT layer to
  235.       communicate the stream identification to the X.25 layer.
  236.  
  237. 6. XOT Packets
  238.  
  239.    For each X.25 packet received from the TCP connection to be sent out
  240.    a local interface, an XOT implementation MUST set the packet's
  241.    logical channel number to that used on the outgoing interface.  For
  242.    the purposes of this RFC, a logical channel number is the 12 bit
  243.    field confusingly defined by the X.25 Recommendations as the high-
  244.    order 4 bit "logical channel group number" and low-order 8 bit
  245.    "logical channel number", where the latter phrase is used to refer to
  246.    both the aggregated 12 bits and the low-order 8 bits.
  247.  
  248.    An XOT implementation SHOULD NOT modify the X.25 packet header
  249.    information received on a local interface to be transmitted over the
  250.    TCP connection.
  251.  
  252.    An XOT implementation MUST modify the X.25 packet header information
  253.    as required for proper X.25 protocol operation for packets received
  254.    on a TCP connection to be transmitted over a local interface.
  255.  
  256.    An XOT implementation MAY support connection between interfaces that
  257.    use different flow control modulos.  If this feature is supported,
  258.    XOT MUST modify the packet General Format Identifier on all packets
  259.    received over the TCP connection to set the proper modulus
  260.    identifier.
  261.  
  262. 6.1 Virtual Circuit Setup and Clearing
  263.  
  264.    Once a TCP connection has been established, the X.25 Call packet is
  265.    sent by the XOT that initiated the TCP connection.  Eventually a Call
  266.    Confirm or Clear packet is received, or the X.25 T11/T21 timeout
  267.    occurs or the XOT TCP connection is closed.  The usual X.25 state
  268.    transitions are followed.
  269.  
  270.    Any legal X.25 facilities from the family of X.25 protocols
  271.    (including but not limited to the 1980, 1984 and 1988 CCITT X.25
  272.    Recommendations) MAY be included in the Call, Call Confirm and Clear
  273.    packets.  Receipt of an unknown or unsupported X.25 facility received
  274.    from the TCP connection SHOULD be ignored (i.e., not presented in the
  275.    packet sent out the local interface) or treated as an error as
  276.    defined by the X.25 standard implemented.
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Forster, Satz, Glick & Day                                      [Page 5]
  283.  
  284. RFC 1613                  X.25 Over TCP (XOT)                   May 1994
  285.  
  286.  
  287.    To simplify end-to-end flow control, the packet size and window size
  288.    are always sent explicitly as facilities in the Call packet.   The
  289.    Call packet MUST contain both Packet Size and Window Size facilities.
  290.    The Call Confirm packet MAY contain these facilities.  The handling
  291.    of a Call received over a TCP connection that does not encode one or
  292.    both of the flow control facilities is a local matter--if the XOT
  293.    accepts such a Call, it MUST encode the missing flow control facility
  294.    values that apply to the connection in the returned Call Confirm
  295.    packet.
  296.  
  297.    DISCUSSION
  298.  
  299.       X.25 interfaces normally have a concept of network default values
  300.       for packet size and window size.  It was thought that when
  301.       connecting diverse sites over a TCP/IP network this concept would
  302.       be difficult to achieve in practice.  If there is no network
  303.       default, then each call must state the packet size and window
  304.       size.  This is the reason for requiring the packet size and window
  305.       size facilities.  It is expected that this can be achieved either
  306.       by the XOT layer itself, or by configuring the X.25 engine such
  307.       that there no network default on this interface.
  308.  
  309.    After sending a Clear the TCP connection MAY be closed immediately
  310.    without waiting for the Clear Confirm.  A Clear Confirm received on
  311.    the TCP connection MAY be silently discarded.
  312.  
  313.    A packet with an invalid X.25 Packet Type Identifier (PTI) received
  314.    over the TCP connection before a Call has been received (i.e., while
  315.    in the P1 state) MUST be silently discarded.
  316.  
  317. 6.2 Data and Flow Control
  318.  
  319.    DISCUSSION
  320.  
  321.       The implementation of X.25 flow control is a local matter, but
  322.       different implementation choices affect XOT behavior.
  323.  
  324.       An XOT implementation may implement either end-to-end flow
  325.       control, where DATA, RR and RNR packets are sent over the TCP
  326.       connection as received over the local interface, or local flow
  327.       control, where flow control packets (RR, RNR and, if supported,
  328.       REJ) are sent on a VC according to local criteria, a complete
  329.       packet sequence of DATA packets may be fragmented or combined, and
  330.       data packet numbering normally has only local DTE-DCE
  331.       significance.
  332.  
  333.       Existing implementations of XOT perform end-to-end flow control.
  334.       Data and flow control packets are simply transferred between the
  335.  
  336.  
  337.  
  338. Forster, Satz, Glick & Day                                      [Page 6]
  339.  
  340. RFC 1613                  X.25 Over TCP (XOT)                   May 1994
  341.  
  342.  
  343.       two local interfaces via the TCP connection, adjusting the X.25
  344.       header data as necessary for mixed modulo operation.  This does
  345.       not preclude an XOT implementation that performs local flow
  346.       control, but interoperability requires that a local flow control
  347.       implementation conduct the XOT session such that a connecting
  348.       end-to-end flow control implementation receives Data packets of
  349.       the proper size and flow control fields with appropriate P(S) and
  350.       P(R) values.
  351.  
  352.       An X.25 implementation that performs local flow control similarly
  353.       may set up a Call between two local interfaces where each logical
  354.       channel has its own packet and window sizes and Data packets must
  355.       be fragmented or collected between the interfaces and each
  356.       interface manages distinct packet sequence numbers; XOT operation
  357.       is simply an extension to this operation as a VC is connected
  358.       between the local interface and an XOT/TCP virtual interface, each
  359.       of which have distinct window and packet sizes.
  360.  
  361.    An XOT that implements local flow control MUST send data packet
  362.    acknowledgements across the TCP connection for the DATA packets it
  363.    receives from the TCP connection, using the received packet numbers,
  364.    and MUST observe the maximum packet sizes agreed to across the TCP
  365.    connection.
  366.  
  367.    An XOT implementation MUST NOT assume that an RNR sent across the TCP
  368.    connection will stop the flow of DATA packets in the other direction.
  369.    An RNR packet received from the TCP connection MAY cause an RNR
  370.    packet to be sent across the local interface; end-to-end flow control
  371.    implementations MAY communicate the P(R) in an RNR packet received
  372.    from the TCP connection by sending an RR packet on the local
  373.    interface.
  374.  
  375.    An XOT implementation that allows mixed-modulo connections and
  376.    implements end-to-end flow control MUST intervene in the window size
  377.    negotiation process when a modulo 128 Call Request proposes a window
  378.    size of 8 or larger to an XOT connection that serves a modulo 8
  379.    interface.  The intervention MUST either refuse the connection or
  380.    lower the too-large window size(s) to a value valid for the interface
  381.    and indicate the final result of the window size negotiation process
  382.    in the Call Confirm packet returned over the TCP connection.
  383.  
  384.    For any type of flow control implementation that supports mixed
  385.    modulo connections, both cooperating XOTs MUST interpret the the P(S)
  386.    and P(R) values received from the TCP connection and perform any flow
  387.    control operation appropriate for correct X.25 operation of the local
  388.    interface.  End-to-end flow control implementations MUST translate
  389.    between the two modulos and construct the analogous X.25 header P(S)
  390.    and P(R) fields for DATA, RR and RNR packets.
  391.  
  392.  
  393.  
  394. Forster, Satz, Glick & Day                                      [Page 7]
  395.  
  396. RFC 1613                  X.25 Over TCP (XOT)                   May 1994
  397.  
  398.  
  399.    An XOT implementation MAY support connecting two XOT TCP sessions to
  400.    each other.  If this feature is supported, XOT MUST simply connect
  401.    the two TCP sessions without modifying the data passed.
  402.  
  403. 6.3 Interrupt, and Reset Packets
  404.  
  405.    Interrupt, Interrupt Confirm, Reset and Reset Confirm packets are
  406.    sent over the TCP connection using the normal X.25 packet formats and
  407.    state transitions.  The end-to-end nature of both the Interrupt and
  408.    Reset services MUST be maintained for correct X.25 operation.
  409.  
  410. 6.4 Restart, DTE Reject, Diagnostics, and Registration
  411.  
  412.    X.25 packets that have only a local DTE/DCE interface significance
  413.    (Restart, Restart Confirm, DTE Reject, Diagnostic, Registration
  414.    Request and Registration Confirmation) MUST NOT be sent over the TCP
  415.    connection.  If one of these packets is received, then it MUST be
  416.    silently discarded.
  417.  
  418. 6.5 PVC Setup
  419.  
  420.    An XOT implementation MAY support connecting a PVC via XOT.
  421.  
  422.       DISCUSSION
  423.  
  424.       X.25 PVCs are Virtual Circuits that are presumed to be available
  425.       when the X.25 service is available (i.e., in the R1 state).
  426.       Connecting a PVC via XOT is complicated because no Call, Call
  427.       Confirm, Clear or Clear Confirm packets are transferred (or
  428.       allowed) across the X.25 interface--PVCs are simply available
  429.       because they have been provisioned by the network provider as
  430.       contracted for by the network users.
  431.  
  432.       Supporting a PVC using XOT requires a data exchange between the
  433.       XOT entities that is outside the scope of the X.25 standards, and
  434.       must provide for a number of error conditions.
  435.  
  436.    The setup of a PVC between two XOT entities is performed by
  437.    exchanging a non-standard X.25 packet type (encapsulated in an XOT
  438.    Header); the PVC setup exchange takes place immediately after a new
  439.    TCP XOT connection has been established.  The XOT implementation that
  440.    initiated the TCP connection is the initiator; the other XOT is the
  441.    responder.
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Forster, Satz, Glick & Day                                      [Page 8]
  451.  
  452. RFC 1613                  X.25 Over TCP (XOT)                   May 1994
  453.  
  454.  
  455.    The PVC Setup packet includes the X.25 General Format Identifier, LCN
  456.    and Packet Type Identifier fields followed by additional data.  This
  457.    non-standard packet type takes the form:
  458.  
  459.    +--+--+--+--+--+--+--+--+--+
  460.    | X.25 GFI  |  X.25 LCN    |
  461.    +--+--+--+--+              +
  462.    |                          |
  463.    +--+--+--+--+--+--+--+--+--+
  464.    |        X.25 PTI          | PVC setup PTI (= 0xF5)
  465.    +--+--+--+--+--+--+--+--+--+
  466.    |                          | version (= 0x81)
  467.    +--+--+--+--+--+--+--+--+--+
  468.    |                          | status
  469.    +--+--+--+--+--+--+--+--+--+
  470.    |                          | initiator interface name length (N)
  471.    +--+--+--+--+--+--+--+--+--+
  472.    |                          | initiator LCN (high octet)
  473.    +--+--+--+--+--+--+--+--+--+
  474.    |                          | initiator LCN (low octet)
  475.    +--+--+--+--+--+--+--+--+--+
  476.    |                          | responder interface name length (M)
  477.    +--+--+--+--+--+--+--+--+--+
  478.    |                          | responder LCN (high octet)
  479.    +--+--+--+--+--+--+--+--+--+
  480.    |                          | responder LCN (low octet)
  481.    +--+--+--+--+--+--+--+--+--+
  482.    |                          | sender incoming window
  483.    +--+--+--+--+--+--+--+--+--+
  484.    |                          | sender outgoing window
  485.    +--+--+--+--+--+--+--+--+--+
  486.    |                          | sender incoming max. packet size
  487.    +--+--+--+--+--+--+--+--+--+
  488.    |                          | sender outgoing max. packet size
  489.    +--+--+--+--+--+--+--+--+--+
  490.    |                          | initiator interface name (N octets)
  491.    |                          |
  492.    +--+--+--+--+--+--+--+--+--+
  493.    |                          | responder interface name (M octets)
  494.    |                          |
  495.    +--+--+--+--+--+--+--+--+--+
  496.  
  497.    DISCUSSION
  498.  
  499.       The PVC setup packet was designed so that the responder could
  500.       simply modify a few fields of the received packet and send it back
  501.       to the initiator.
  502.  
  503.  
  504.  
  505.  
  506. Forster, Satz, Glick & Day                                      [Page 9]
  507.  
  508. RFC 1613                  X.25 Over TCP (XOT)                   May 1994
  509.  
  510.  
  511.       The Packet Type Identifier was chosen from the unused X.25 PTI
  512.       values so it is distinct from the standard X.25 Packet Type
  513.       Identifiers.
  514.  
  515.       The PVC setup version value was chosen to prevent connections with
  516.       prior experimental implementations.
  517.  
  518.    The PVC status field has the following values defined:
  519.  
  520.    Status    Meaning
  521.    ------    --------------------------------------
  522.     0x00     Waiting to connect
  523.  
  524.     0x08     Destination disconnected
  525.     0x09     PVC/TCP connection refused
  526.     0x0A     PVC/TCP routing error
  527.     0x0B     PVC/TCP connect timed out
  528.  
  529.     0x10     Trying to connect via TCP
  530.     0x11     Awaiting PVC-SETUP reply
  531.     0x12     Connected
  532.     0x13     No such destination interface
  533.     0x14     Destination interface is not up
  534.     0x15     Non-X.25 destination interface
  535.     0x16     No such destination PVC
  536.     0x17     Destination PVC configuration mismatch
  537.     0x18     Mismatched flow control values
  538.     0x19     Can't support flow control values
  539.     0x1A     PVC setup protocol error
  540.  
  541.    DISCUSSION
  542.  
  543.       Not all of the PVC status values are appropriate for a PVC setup
  544.       packet; these values represent a particular implementation that
  545.       chose to assign values in three groups that correspond to a short
  546.       timer for a connect attempt (0x00 through 0x07), a long timer for
  547.       a connect attempt (0x08 through 0x0F) and no attempt to connect
  548.       (greater than 0x0F).  The values that are appropriate for a PVC
  549.       setup packet are 0x00 and those values greater than 0x12.
  550.  
  551.       Most of the PVC status error values that may be found in a setup
  552.       message are self-explanatory, with a few exceptions.  The value
  553.       0x17, "Destination PVC configuration mismatch" may returned in the
  554.       case that the targeted PVC already has an XOT PVC connection
  555.       active.  The value 0x19, "Can't support flow control values", may
  556.       be returned when the flow control values match but, for instance,
  557.       a modulo 8 interface is requested to set up a PVC with a window
  558.       size greater than 7 or an interface is requested to set up a PVC
  559.  
  560.  
  561.  
  562. Forster, Satz, Glick & Day                                     [Page 10]
  563.  
  564. RFC 1613                  X.25 Over TCP (XOT)                   May 1994
  565.  
  566.  
  567.       with a maximum packet size that is too large for its data link
  568.       layer to transfer.
  569.  
  570.    An XOT MAY retry a failed PVC setup; if implemented the XOT SHOULD
  571.    wait between attempts (5 minutes is suggested).
  572.  
  573.    Each XOT PVC is configured with the identity of the other XOT (i.e.,
  574.    IP address), the name of the interface to connect to, the Logical
  575.    Channel Number on that interface and the flow control values to use.
  576.    These data are present in the PVC setup packets and the responding
  577.    XOT verifies the configurations are compatible.
  578.  
  579.    The interface name fields are the ASCII names of the two interfaces
  580.    involved.  These names SHOULD be case-insensitive.  There MUST NOT be
  581.    any padding or trailing zero octets between or after the interface
  582.    names.
  583.  
  584.    The flow control values are the values from the perspective of the
  585.    local interface of the XOT implementation that sent the PVC setup
  586.    packet.  The maximum packet size values are encoded as they are in
  587.    the packet size facility, (i.e., the base-2 log of the size in
  588.    octets, so 7 represents a maximum packet size of 128 octets).  If the
  589.    responding XOT implements end-to-end flow control, it will require
  590.    that the configured flow control values be complimentary, so a
  591.    returned status of 0x18 will indicate the values required by the
  592.    responding XOT (note that the incoming value of one local interface
  593.    corresponds to the outgoing value of the connecting local interface,
  594.    and vice-versa).
  595.  
  596.    After establishing the TCP connection the initiator sends a PVC setup
  597.    packet, the status value MUST be 0x00; the responder will reply with
  598.    its own PVC setup packet or by closing the TCP connection.  An XOT
  599.    PVC setup is successful if the responder returns a status of 0x00.
  600.    Once the XOT PVC connection is successfully established, each XOT
  601.    MUST complete a Reset procedure on the local interface, so if each
  602.    local interface LCI is in state D1, a Reset packet would be generated
  603.    both to the local interface and the XOT TCP connection.
  604.  
  605.    An XOT PVC connection is broken by simply closing the TCP connection;
  606.    X.25 packets that are not legal for PVCs MUST NOT be transferred
  607.    across an XOT PVC connection.  When a local interface undergoes the
  608.    Restart procedure, the XOT PVC connections MUST be either perform a
  609.    Reset (which is appropriate if the interface remains in state R1) or
  610.    close the XOT PVC connection.
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618. Forster, Satz, Glick & Day                                     [Page 11]
  619.  
  620. RFC 1613                  X.25 Over TCP (XOT)                   May 1994
  621.  
  622.  
  623.    DISCUSSION
  624.  
  625.       An XOT implementation SHOULD also consider how a PVC setup
  626.       collision will be handled.  Receipt of an XOT PVC setup for a PVC
  627.       that is itself attempting to setup an XOT connection could either
  628.       accept a (valid) setup attempt and, if two TCP XOT connections
  629.       result, simply use one connection to send XOT data (XOT MUST NOT
  630.       send traffic over both) and accept XOT data on either, or it can
  631.       close the incoming attempt and, if no connections result, retry
  632.       the connection after waiting for a random interval.  If two
  633.       connections are allowed for a PVC, closure of one SHOULD result in
  634.       the closure of the other.
  635.  
  636. 7. Acknowledgments
  637.  
  638.    Greg Satz is the original designer and implementor of X.25 over TCP.
  639.    Aviva Garrett of cisco Systems reviewed the specification and made
  640.    many editorial corrections.
  641.  
  642. 8. Security Considerations
  643.  
  644.    Security issues are not discussed in this memo.
  645.  
  646. 9. References
  647.  
  648.    [1] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
  649.        USC/Information Sciences Institute, July 1992.
  650.  
  651.    [2] CCITT, Blue Book Volume VIII--Fascicle VIII.2, "Data
  652.        Communication Networks: Services and Facilities, Interfaces";
  653.        Recommendation X.25, "Interface Between Data Circuit-Terminating
  654.        Equipment (DCE) for Terminals Operating in the Packet Mode and
  655.        Connected to Public Data Networks by Dedicated Circuit", 1989,
  656.        Geneva.
  657.  
  658.  
  659.  
  660.  
  661.  
  662.  
  663.  
  664.  
  665.  
  666.  
  667.  
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674. Forster, Satz, Glick & Day                                     [Page 12]
  675.  
  676. RFC 1613                  X.25 Over TCP (XOT)                   May 1994
  677.  
  678.  
  679. 10. Authors' Addresses
  680.  
  681.        James R. Forster
  682.        Engineering Dept.
  683.        cisco Systems
  684.        1525 O'Brien Dr.
  685.        Menlo Park. CA. 94025
  686.  
  687.        Phone: 1.415.688.8245
  688.        Fax:   1.415.688.8282
  689.        EMail: forster@cisco.com
  690.  
  691.  
  692.        Greg Satz
  693.        Engineering Dept.
  694.        cisco Systems
  695.        1525 O'Brien Dr.
  696.        Menlo Park. CA. 94025
  697.  
  698.        Phone: 1.415.688.8245
  699.        Fax:   1.415.688.8282
  700.        EMail: satz@cisco.com
  701.  
  702.  
  703.        Gilbert Glick
  704.        Engineering Dept.
  705.        cisco Systems
  706.        1525 O'Brien Dr.
  707.        Menlo Park. CA. 94025
  708.  
  709.        Phone: 1.415.688.8245
  710.        Fax:   1.415.688.8282
  711.        EMail: gglick@cisco.com
  712.  
  713.  
  714.        Bob Day
  715.        Joint Network Team
  716.        c/o Rutherford Appleton Laboratory
  717.        Chilton
  718.        Didcot
  719.        Oxfordshire OX11 0QX
  720.        United Kingdom
  721.  
  722.        Phone: 44.235.44.5163
  723.        Fax:   44.235.44.6251
  724.        EMail: R.Day@jnt.ac.uk
  725.  
  726.  
  727.  
  728.  
  729.  
  730. Forster, Satz, Glick & Day                                     [Page 13]
  731.  
  732.