rfc1613.txt

RFC 的详细文档！

   An XOT implementation MUST NOT assume that an RNR sent across the TCP
   connection will stop the flow of DATA packets in the other direction.
   An RNR packet received from the TCP connection MAY cause an RNR
   packet to be sent across the local interface; end-to-end flow control
   implementations MAY communicate the P(R) in an RNR packet received
   from the TCP connection by sending an RR packet on the local
   interface.

   An XOT implementation that allows mixed-modulo connections and
   implements end-to-end flow control MUST intervene in the window size
   negotiation process when a modulo 128 Call Request proposes a window
   size of 8 or larger to an XOT connection that serves a modulo 8
   interface.  The intervention MUST either refuse the connection or
   lower the too-large window size(s) to a value valid for the interface
   and indicate the final result of the window size negotiation process
   in the Call Confirm packet returned over the TCP connection.

   For any type of flow control implementation that supports mixed
   modulo connections, both cooperating XOTs MUST interpret the the P(S)
   and P(R) values received from the TCP connection and perform any flow
   control operation appropriate for correct X.25 operation of the local
   interface.  End-to-end flow control implementations MUST translate
   between the two modulos and construct the analogous X.25 header P(S)
   and P(R) fields for DATA, RR and RNR packets.



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


   An XOT implementation MAY support connecting two XOT TCP sessions to
   each other.  If this feature is supported, XOT MUST simply connect
   the two TCP sessions without modifying the data passed.

6.3 Interrupt, and Reset Packets

   Interrupt, Interrupt Confirm, Reset and Reset Confirm packets are
   sent over the TCP connection using the normal X.25 packet formats and
   state transitions.  The end-to-end nature of both the Interrupt and
   Reset services MUST be maintained for correct X.25 operation.

6.4 Restart, DTE Reject, Diagnostics, and Registration

   X.25 packets that have only a local DTE/DCE interface significance
   (Restart, Restart Confirm, DTE Reject, Diagnostic, Registration
   Request and Registration Confirmation) MUST NOT be sent over the TCP
   connection.  If one of these packets is received, then it MUST be
   silently discarded.

6.5 PVC Setup

   An XOT implementation MAY support connecting a PVC via XOT.

      DISCUSSION

      X.25 PVCs are Virtual Circuits that are presumed to be available
      when the X.25 service is available (i.e., in the R1 state).
      Connecting a PVC via XOT is complicated because no Call, Call
      Confirm, Clear or Clear Confirm packets are transferred (or
      allowed) across the X.25 interface--PVCs are simply available
      because they have been provisioned by the network provider as
      contracted for by the network users.

      Supporting a PVC using XOT requires a data exchange between the
      XOT entities that is outside the scope of the X.25 standards, and
      must provide for a number of error conditions.

   The setup of a PVC between two XOT entities is performed by
   exchanging a non-standard X.25 packet type (encapsulated in an XOT
   Header); the PVC setup exchange takes place immediately after a new
   TCP XOT connection has been established.  The XOT implementation that
   initiated the TCP connection is the initiator; the other XOT is the
   responder.








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


   The PVC Setup packet includes the X.25 General Format Identifier, LCN
   and Packet Type Identifier fields followed by additional data.  This
   non-standard packet type takes the form:

   +--+--+--+--+--+--+--+--+--+
   | X.25 GFI  |  X.25 LCN    |
   +--+--+--+--+              +
   |                          |
   +--+--+--+--+--+--+--+--+--+
   |        X.25 PTI          | PVC setup PTI (= 0xF5)
   +--+--+--+--+--+--+--+--+--+
   |                          | version (= 0x81)
   +--+--+--+--+--+--+--+--+--+
   |                          | status
   +--+--+--+--+--+--+--+--+--+
   |                          | initiator interface name length (N)
   +--+--+--+--+--+--+--+--+--+
   |                          | initiator LCN (high octet)
   +--+--+--+--+--+--+--+--+--+
   |                          | initiator LCN (low octet)
   +--+--+--+--+--+--+--+--+--+
   |                          | responder interface name length (M)
   +--+--+--+--+--+--+--+--+--+
   |                          | responder LCN (high octet)
   +--+--+--+--+--+--+--+--+--+
   |                          | responder LCN (low octet)
   +--+--+--+--+--+--+--+--+--+
   |                          | sender incoming window
   +--+--+--+--+--+--+--+--+--+
   |                          | sender outgoing window
   +--+--+--+--+--+--+--+--+--+
   |                          | sender incoming max. packet size
   +--+--+--+--+--+--+--+--+--+
   |                          | sender outgoing max. packet size
   +--+--+--+--+--+--+--+--+--+
   |                          | initiator interface name (N octets)
   |                          |
   +--+--+--+--+--+--+--+--+--+
   |                          | responder interface name (M octets)
   |                          |
   +--+--+--+--+--+--+--+--+--+

   DISCUSSION

      The PVC setup packet was designed so that the responder could
      simply modify a few fields of the received packet and send it back
      to the initiator.




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


      The Packet Type Identifier was chosen from the unused X.25 PTI
      values so it is distinct from the standard X.25 Packet Type
      Identifiers.

      The PVC setup version value was chosen to prevent connections with
      prior experimental implementations.

   The PVC status field has the following values defined:

   Status    Meaning
   ------    --------------------------------------
    0x00     Waiting to connect

    0x08     Destination disconnected
    0x09     PVC/TCP connection refused
    0x0A     PVC/TCP routing error
    0x0B     PVC/TCP connect timed out

    0x10     Trying to connect via TCP
    0x11     Awaiting PVC-SETUP reply
    0x12     Connected
    0x13     No such destination interface
    0x14     Destination interface is not up
    0x15     Non-X.25 destination interface
    0x16     No such destination PVC
    0x17     Destination PVC configuration mismatch
    0x18     Mismatched flow control values
    0x19     Can't support flow control values
    0x1A     PVC setup protocol error

   DISCUSSION

      Not all of the PVC status values are appropriate for a PVC setup
      packet; these values represent a particular implementation that
      chose to assign values in three groups that correspond to a short
      timer for a connect attempt (0x00 through 0x07), a long timer for
      a connect attempt (0x08 through 0x0F) and no attempt to connect
      (greater than 0x0F).  The values that are appropriate for a PVC
      setup packet are 0x00 and those values greater than 0x12.

      Most of the PVC status error values that may be found in a setup
      message are self-explanatory, with a few exceptions.  The value
      0x17, "Destination PVC configuration mismatch" may returned in the
      case that the targeted PVC already has an XOT PVC connection
      active.  The value 0x19, "Can't support flow control values", may
      be returned when the flow control values match but, for instance,
      a modulo 8 interface is requested to set up a PVC with a window
      size greater than 7 or an interface is requested to set up a PVC



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


      with a maximum packet size that is too large for its data link
      layer to transfer.

   An XOT MAY retry a failed PVC setup; if implemented the XOT SHOULD
   wait between attempts (5 minutes is suggested).

   Each XOT PVC is configured with the identity of the other XOT (i.e.,
   IP address), the name of the interface to connect to, the Logical
   Channel Number on that interface and the flow control values to use.
   These data are present in the PVC setup packets and the responding
   XOT verifies the configurations are compatible.

   The interface name fields are the ASCII names of the two interfaces
   involved.  These names SHOULD be case-insensitive.  There MUST NOT be
   any padding or trailing zero octets between or after the interface
   names.

   The flow control values are the values from the perspective of the
   local interface of the XOT implementation that sent the PVC setup
   packet.  The maximum packet size values are encoded as they are in
   the packet size facility, (i.e., the base-2 log of the size in
   octets, so 7 represents a maximum packet size of 128 octets).  If the
   responding XOT implements end-to-end flow control, it will require
   that the configured flow control values be complimentary, so a
   returned status of 0x18 will indicate the values required by the
   responding XOT (note that the incoming value of one local interface
   corresponds to the outgoing value of the connecting local interface,
   and vice-versa).

   After establishing the TCP connection the initiator sends a PVC setup
   packet, the status value MUST be 0x00; the responder will reply with
   its own PVC setup packet or by closing the TCP connection.  An XOT
   PVC setup is successful if the responder returns a status of 0x00.
   Once the XOT PVC connection is successfully established, each XOT
   MUST complete a Reset procedure on the local interface, so if each
   local interface LCI is in state D1, a Reset packet would be generated
   both to the local interface and the XOT TCP connection.

   An XOT PVC connection is broken by simply closing the TCP connection;
   X.25 packets that are not legal for PVCs MUST NOT be transferred
   across an XOT PVC connection.  When a local interface undergoes the
   Restart procedure, the XOT PVC connections MUST be either perform a
   Reset (which is appropriate if the interface remains in state R1) or
   close the XOT PVC connection.







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


   DISCUSSION

      An XOT implementation SHOULD also consider how a PVC setup
      collision will be handled.  Receipt of an XOT PVC setup for a PVC
      that is itself attempting to setup an XOT connection could either
      accept a (valid) setup attempt and, if two TCP XOT connections
      result, simply use one connection to send XOT data (XOT MUST NOT
      send traffic over both) and accept XOT data on either, or it can
      close the incoming attempt and, if no connections result, retry
      the connection after waiting for a random interval.  If two
      connections are allowed for a PVC, closure of one SHOULD result in
      the closure of the other.

7. Acknowledgments

   Greg Satz is the original designer and implementor of X.25 over TCP.
   Aviva Garrett of cisco Systems reviewed the specification and made
   many editorial corrections.

8. Security Considerations

   Security issues are not discussed in this memo.

9. References

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

   [2] CCITT, Blue Book Volume VIII--Fascicle VIII.2, "Data
       Communication Networks: Services and Facilities, Interfaces";
       Recommendation X.25, "Interface Between Data Circuit-Terminating
       Equipment (DCE) for Terminals Operating in the Packet Mode and
       Connected to Public Data Networks by Dedicated Circuit", 1989,
       Geneva.

















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


10. Authors' Addresses

       James R. Forster
       Engineering Dept.
       cisco Systems
       1525 O'Brien Dr.
       Menlo Park. CA. 94025

       Phone: [phone]
       Fax:   [phone]
       EMail: [e-mail]


       Greg Satz
       Engineering Dept.
       cisco Systems
       1525 O'Brien Dr.
       Menlo Park. CA. 94025

       Phone: [phone]
       Fax:   [phone]
       EMail: [e-mail]


       Gilbert Glick
       Engineering Dept.
       cisco Systems
       1525 O'Brien Dr.
       Menlo Park. CA. 94025

       Phone: [phone]
       Fax:   [phone]
       EMail: [e-mail]


       Bob Day
       Joint Network Team
       c/o Rutherford Appleton Laboratory
       Chilton
       Didcot
       Oxfordshire OX11 0QX
       United Kingdom

       Phone: [phone]
       Fax:   [phone]
       EMail: [e-mail]





Forster, Satz, Glick & Day                                     [Page 13]