rfc1613.txt

<VC++网络游戏建摸与实现>源代码

Network Working Group                                         J. Forster
Request for Comments: 1613                                       G. Satz
Category: Informational                                         G. Glick
                                                     cisco Systems, Inc.
                                                                  R. Day
                                                                   JANET
                                                                May 1994


                   cisco Systems X.25 over TCP (XOT)

Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

Table of Contents

   1.  Introduction....................................................1
   2.  Conventions.....................................................2
   3.  Relationship Between XOT and X.25...............................2
   4.  Overall Packet Format...........................................3
   4.1   XOT Header....................................................4
   5.  TCP Connection, Port Number, and Logical Channel Numbers (LCNs).4
   6.  XOT Packets.....................................................5
   6.1   Virtual Circuit Setup and Clearing............................5
   6.2   Data and Flow Control.........................................6
   6.3   Interrupt, and Reset Packets..................................8
   6.4   Restart, DTE Reject, Diagnostics, and Registration............8
   6.5   PVC Setup.....................................................8
   7.  Acknowledgments................................................12
   8.  Security Considerations........................................12
   9.  References.....................................................12
  10.  Authors' Addresses.............................................13

1. Introduction

   It is sometimes desirable to transport X.25 over IP internets.  The
   X.25 Packet Level requires a reliable link level below it and
   normally uses LAPB.  This memo documents a method of sending X.25
   packets over IP internets by encapsulating the X.25 Packet Level in
   TCP packets.

   TCP provides a reliable byte stream.  X.25 requires that the layer
   below it provide message semantics, in particular the boundary
   between packets.  To provide this, a small (4-byte) XOT header is
   used between TCP and X.25.  The primary content of this header is a



Forster, Satz, Glick & Day                                      [Page 1]

RFC 1613                  X.25 Over TCP (XOT)                   May 1994


   length field, which is used to separate the X.25 packets within the
   TCP stream.

   In general, the normal X.25 protocol packet formats and state
   transition rules apply to the X.25 layer in XOT.  Exceptions to this
   are noted.

2. Conventions

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

      o   MUST, SHALL, or MANDATORY -- This item is an absolute
          requirement of the specification.

      o   SHOULD or RECOMMEND -- This item should generally be followed
          for all but exceptional circumstances.

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

   In some places in this document, there is parenthetical material
   labeled "DISCUSSION".  This material is intended to give
   clarification and explanation of the preceding text.

3. Relationship Between XOT and X.25

   When a networking device (a host, router, etc.) has an X.25 engine
   (i.e., protocol implementation), that engine  may be connected to
   interface(s) running LAPB, and/or to logical interface(s) running LLC
   or XOT/TCP/IP.  In general, the XOT layer itself is not at all
   sensitive to what kind of packets the X.25 engine passes to it.
   However, to improve interoperability between separate
   implementations, this document in some cases does specify behavior of
   the X.25 engine.

   While this document primarily discusses XOT from the perspective of
   switching X.25 traffic (i.e., connecting an X.25 Virtual Circuit
   between the local X.25 interfaces of two networking devices), this
   should not prevent a host from offering X.25 connectivity using XOT.

   The various X.25 standards may call a given packet type by a
   different name according to the assigned DTE/DCE role of the
   interface that originated the packet.  XOT is intended to be
   insensitive to the DTE/DCE role of the local interfaces at either end
   of an XOT TCP connection, so, for this document, the following terms
   are interchangeable unless stated otherwise:




Forster, Satz, Glick & Day                                      [Page 2]

RFC 1613                  X.25 Over TCP (XOT)                   May 1994


      o  Call, Call Request and Incoming Call
      o  Call Confirm, Call Accepted and Call Connected
      o  Clear, Clear Request and Clear Indication
      o  Clear Confirm, DTE Clear Confirmation and DCE Clear Confirmation
      o  Data, DTE Data and DCE Data
      o  Interrupt, DTE Interrupt and DCE Interrupt
      o  Interrupt Confirm, DTE Interrupt Confirmation and
           DCE Interrupt Confirmation
      o  RR, DTE RR and DCE RR
      o  RNR, DTE RNR and DCE RNR
      o  REJ, Reject and DTE REJ
      o  Reset, Reset Request and Reset Indication
      o  Reset Confirm, DTE Reset Confirmation and DCE Reset Confirmation
      o  Restart, Restart Request and Restart Indication
      o  Restart Confirm, DTE Restart Confirmation and
           DCE Restart Confirmation

4. Overall Packet Format

   The entire encapsulated packet has the following format:

                  ---------------------------------
                  |                               |
                  |       IP Header               |
                  |                               |
                  ---------------------------------
                  |                               |
                  |       TCP Header              |
                  |                               |
                  ---------------------------------
                  |                               |
                  |       XOT Header              |
                  |                               |
                  ---------------------------------
                  |                               |
                  |       X.25  Packet            |
                  |                               |
                  ---------------------------------

   RFC convention is that a packet format is represented graphically
   with the data sent first above the data sent later.  This convention
   is followed in this document, and therefore, while we refer to X.25
   being transported over TCP, we draw the packet format with the X.25
   portion of the packet lower on the page than the TCP portion.







Forster, Satz, Glick & Day                                      [Page 3]

RFC 1613                  X.25 Over TCP (XOT)                   May 1994


4.1 XOT Header

   The XOT header has the format:

       0                   1                   2                   3
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Version              |           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Version (2 octets)

         The version number of the XOT protocol is encoded in the first
         two octets.  The version number MUST be 0.  Other values of
         this field are reserved for future use.  If a value other than
         0 is received, then the TCP connection MUST be closed.

      Length (2 octets)

         The length of the X.25 packet is encoded in the second two
         octets.  Values must be legal X.25 packet lengths.  If the
         Length field has an illegal value, then the TCP connection MUST
         be closed.

5. TCP Connection, Port Number, and Logical Channel Numbers (LCNs)

   A separate TCP connection MUST be used for each X.25 virtual circuit.
   All connections MUST be made to TCP port number 1998.  This port
   number is an IANA Registered Port Number registered by cisco Systems;
   cisco has designated it for use by XOT.

   The TCP connection MUST be created before the virtual circuit can be
   established.  The TCP connection MAY be maintained after the virtual
   circuit has been cleared.  Data MUST NOT be passed along with the TCP
   SYN packet.

   The Logical Channel Number (LCN) field in the X.25 header has no
   significance and has arbitrary values.  A corollary of this is that
   there is no assignment of one side of the connection to be DTE and
   another to be DCE.

   DISCUSSION

      Consider three devices A, B and C, where A and B both conduct XOT
      sessions to C.  It's possible that C could receive two calls with
      the same LCN and, unless the X.25 engine could tell that they were
      received on different logical (XOT) interfaces, here would a
      danger of call collision (indeed a valid LCN on one interface may



Forster, Satz, Glick & Day                                      [Page 4]

RFC 1613                  X.25 Over TCP (XOT)                   May 1994


      not even be valid on a different interface).  It is therefore
      necessary for C's X.25 engine to distinguish between the two
      streams, but the LCN field is not sufficient to do this.  The XOT
      protocol design decision was to expect the XOT layer to
      communicate the stream identification to the X.25 layer.

6. XOT Packets

   For each X.25 packet received from the TCP connection to be sent out
   a local interface, an XOT implementation MUST set the packet's
   logical channel number to that used on the outgoing interface.  For
   the purposes of this RFC, a logical channel number is the 12 bit
   field confusingly defined by the X.25 Recommendations as the high-
   order 4 bit "logical channel group number" and low-order 8 bit
   "logical channel number", where the latter phrase is used to refer to
   both the aggregated 12 bits and the low-order 8 bits.

   An XOT implementation SHOULD NOT modify the X.25 packet header
   information received on a local interface to be transmitted over the
   TCP connection.

   An XOT implementation MUST modify the X.25 packet header information
   as required for proper X.25 protocol operation for packets received
   on a TCP connection to be transmitted over a local interface.

   An XOT implementation MAY support connection between interfaces that
   use different flow control modulos.  If this feature is supported,
   XOT MUST modify the packet General Format Identifier on all packets
   received over the TCP connection to set the proper modulus
   identifier.

6.1 Virtual Circuit Setup and Clearing

   Once a TCP connection has been established, the X.25 Call packet is
   sent by the XOT that initiated the TCP connection.  Eventually a Call
   Confirm or Clear packet is received, or the X.25 T11/T21 timeout
   occurs or the XOT TCP connection is closed.  The usual X.25 state
   transitions are followed.

   Any legal X.25 facilities from the family of X.25 protocols
   (including but not limited to the 1980, 1984 and 1988 CCITT X.25
   Recommendations) MAY be included in the Call, Call Confirm and Clear
   packets.  Receipt of an unknown or unsupported X.25 facility received
   from the TCP connection SHOULD be ignored (i.e., not presented in the
   packet sent out the local interface) or treated as an error as
   defined by the X.25 standard implemented.





Forster, Satz, Glick & Day                                      [Page 5]

RFC 1613                  X.25 Over TCP (XOT)                   May 1994


   To simplify end-to-end flow control, the packet size and window size
   are always sent explicitly as facilities in the Call packet.   The
   Call packet MUST contain both Packet Size and Window Size facilities.
   The Call Confirm packet MAY contain these facilities.  The handling
   of a Call received over a TCP connection that does not encode one or
   both of the flow control facilities is a local matter--if the XOT
   accepts such a Call, it MUST encode the missing flow control facility
   values that apply to the connection in the returned Call Confirm
   packet.

   DISCUSSION

      X.25 interfaces normally have a concept of network default values
      for packet size and window size.  It was thought that when
      connecting diverse sites over a TCP/IP network this concept would
      be difficult to achieve in practice.  If there is no network
      default, then each call must state the packet size and window
      size.  This is the reason for requiring the packet size and window
      size facilities.  It is expected that this can be achieved either
      by the XOT layer itself, or by configuring the X.25 engine such
      that there no network default on this interface.

   After sending a Clear the TCP connection MAY be closed immediately
   without waiting for the Clear Confirm.  A Clear Confirm received on
   the TCP connection MAY be silently discarded.

   A packet with an invalid X.25 Packet Type Identifier (PTI) received
   over the TCP connection before a Call has been received (i.e., while
   in the P1 state) MUST be silently discarded.

6.2 Data and Flow Control

   DISCUSSION

      The implementation of X.25 flow control is a local matter, but
      different implementation choices affect XOT behavior.

      An XOT implementation may implement either end-to-end flow
      control, where DATA, RR and RNR packets are sent over the TCP
      connection as received over the local interface, or local flow
      control, where flow control packets (RR, RNR and, if supported,
      REJ) are sent on a VC according to local criteria, a complete
      packet sequence of DATA packets may be fragmented or combined, and
      data packet numbering normally has only local DTE-DCE
      significance.

      Existing implementations of XOT perform end-to-end flow control.
      Data and flow control packets are simply transferred between the



Forster, Satz, Glick & Day                                      [Page 6]

RFC 1613                  X.25 Over TCP (XOT)                   May 1994


      two local interfaces via the TCP connection, adjusting the X.25
      header data as necessary for mixed modulo operation.  This does
      not preclude an XOT implementation that performs local flow
      control, but interoperability requires that a local flow control
      implementation conduct the XOT session such that a connecting
      end-to-end flow control implementation receives Data packets of
      the proper size and flow control fields with appropriate P(S) and
      P(R) values.

      An X.25 implementation that performs local flow control similarly
      may set up a Call between two local interfaces where each logical
      channel has its own packet and window sizes and Data packets must
      be fragmented or collected between the interfaces and each
      interface manages distinct packet sequence numbers; XOT operation
      is simply an extension to this operation as a VC is connected
      between the local interface and an XOT/TCP virtual interface, each
      of which have distinct window and packet sizes.

   An XOT that implements local flow control MUST send data packet
   acknowledgements across the TCP connection for the DATA packets it
   receives from the TCP connection, using the received packet numbers,
   and MUST observe the maximum packet sizes agreed to across the TCP
   connection.