home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_n_r / draft-rfced-info-khana-00.txt < prev    next >
Text File  |  1997-08-28  |  17KB  |  378 lines
  1.  
  2. INTERNET-DRAFT             EXPIRES FEBRUARY 1998    INTERNET-DRAFT
  3.                                                     Vimal K. Khanna
  4.                                                     Mindware,
  5.                             31 July, 1997
  6.  
  7.    PPP for Asynchronous PAD to Synchronous X.25 access
  8.       <draft-rfced-info-khana-00.txt>
  9.  
  10. Status of this Memo
  11.  
  12.     Distribution of this memo is unlimited.
  13.  
  14.     This document is an Internet-Draft. Internet-Drafts are working documents 
  15.     of the Internet Engineering Task Force (IETF), its areas, and its working 
  16.     groups. Note that other groups may also distribute working documents as 
  17.     Internet-Drafts.
  18.  
  19.     Internet-Drafts are draft documents valid for a maximum of six months and
  20.     may be updated, replaced, or obsoleted by other documents at any time. It
  21.     is inappropriate to use Internet-Drafts as reference material or to cite
  22.     them other than as "work in progress".
  23.  
  24.     To view the entire list of current Internet-Drafts, please check the
  25.     "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
  26.     Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 
  27.     munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 
  28.     ftp.isi.edu (US West Coast).
  29.  
  30. Abstract
  31.  
  32.     The PPP protocol allows data transfer thru asynchronous or synchronous
  33.     connections. But the prevalent Public Switched Data Networks (PSDNs) 
  34.     support connections between asynchronous and synchronous protocols. This 
  35.     document defines extensions to the PPP protocol to support asynchronous 
  36.     PAD to synchronous X.25 protocols on PSDNs.
  37.  
  38. 1.  Introduction
  39.  
  40.     The X.25 [10] PSDNs consist of a set of Switches and PADs. The 
  41.     multiuser hosts connect to the Synchronous X.25 ports of the switch        
  42.     and the single user PCs generally connect to the Asynchronous PAD
  43.     ports (Fig. 1).
  44.  
  45.     One of the major requirements of the users is to run TCP/IP based
  46.     applications between these PCs and the multiuser hosts on the X.25
  47.     PSDN. Currently the following Internet protocols are available -
  48.  
  49.     a) PPP [7] and SLIP [6] for running TCP/IP between Asynchronous to 
  50.     Asynchronous serial connections.
  51.  
  52.     b) SNDCF [5] for running TCP/IP between Synchronous X.25 to Synchronous
  53.         X.25 connections.
  54.  
  55.     c) Protocol [9] defining PPP framing in X.25. This configuration requires
  56.        PPP to run over Synchronous X.25 to Synchronous X.25 connections.
  57.  
  58.     There is no protocol for the above scenario of TCP/IP access between a
  59.     Asynchronous serial line at one end and a Synchronous X.25 line at
  60.     the other. This memo proposes one such protocol.
  61.  
  62.     +--------------+                                     +------------+
  63.     |              |                                     |            |
  64.     |   MULTIUSER  |                                     |    PC      |
  65.     |      HOST    |                                     |            |
  66.     |              |                                     |            |
  67.     +--------------+                                     +------------+
  68.             |                                                        |
  69.             |          +------------+           +-----------+        |
  70.             |   X.25   |            |    X.25   |           | ASYNC  |
  71.             +----------|    X.25    |-----------|   PAD     |--------+
  72.                        |   SWITCH   |           |           |
  73.                        |            |           |           |
  74.                        +------------+           +-----------+
  75.  
  76.     Fig. 1        A PC accessing a X.25 host through a PAD
  77.  
  78.  
  79. Khanna                                                          [Page 1]
  80.  
  81. DRAFT      PPP for Asynchronous PAD to Synchronous X.25 access     May,1997
  82.  
  83.  
  84. 2.  Requirements from the Protocol
  85.  
  86.     A protocol to be defined for such a purpose must meet the following
  87.     requirements.
  88.  
  89.     1. It must allow transparent TCP/IP access between the PC connected
  90.         to the PAD Async line and the multiuser host connected to the Sync
  91.         X.25 Switch port, under arbitrary segmentation of packets by the
  92.         network.
  93.  
  94.     2.  The protocol must be implementable using the existing set of X.25
  95.         equipments - Switches and PADs.    
  96.  
  97.     3.  The protocol must coexist with other protocol stacks running
  98.         over the underlying X.25 layers, e.g. 3X PAD[2,3,4], SNDCF, PPP framing
  99.     in X.25, etc.
  100.  
  101. 3.    The Protocol    
  102.  
  103.     This protocol is broadly based on the mechanisms defined by the author
  104.     in [1]. Briefly, the protocol works as follows. Async PPP is run over 
  105.     both the PC and the multiuser host (Fig. 2). The TCP/IP layers are made to 
  106.     run over the PPP layer.
  107.     
  108.     Since the PC connects to PAD via the Async serial link and PPP is 
  109.     defined to work over serial links, PPP protocol on PC is made to 
  110.     run directly over this Async link.  The proposed protocol defines 
  111.     mechanisms by which initially a X.25 call is made from the PC Async 
  112.     port to the remote host through the PAD. Once the connection is made, 
  113.     PPP is now made to run over this Async port.
  114.      
  115.     The remote host connects to the network through a X.25 port. Since
  116.     PPP does not work directly over the X.25 layers, the protocol
  117.     defines an extra layer of software which resides between the PPP
  118.     and the underlying X.25 layers. This layer gets incoming packets
  119.     from X.25 stack, breaks them into individual characters and gives
  120.     these to the PPP layer above to be interpreted by the protocol.
  121.  
  122.     Generally, PAD interprets some control characters ( like the PAD escape 
  123.     character ). This is avoided by setting Transparent Profile mode over the 
  124.     PAD Async port.  This sends all characters uninterpreted. The data is 
  125.     forwarded when the PAD buffer becomes full or a delay of 1 second is 
  126.     received between any 2 received characters.
  127.  
  128.     Thus, the above mechanisms ensure that a protocol packet sent by the
  129.     TCP/IP layers on one computer is received in the same format on the
  130.     other, ensuring transparent working of TCP/IP protocol and
  131.     applications between the two. We shall now describe different phases 
  132.     of the protocol in detail.
  133.  
  134.  
  135.  
  136. Khanna                                                          [Page 2]
  137.  
  138. DRAFT       PPP for Asynchronous PAD to Synchronous X.25 access     May,1997
  139.  
  140.  
  141.  
  142.         Multiuser Host                                    PC
  143.  
  144.     +-------------------+                       +-------------------+
  145.     |     TCP/IP        |                       |                   |
  146.     |-------------------|                       |                   |
  147.     |      PPP          |                       |    TCP/IP         |
  148.     |-------------------|       X.25            |                   |
  149.     | PROPOSED PROTOCOL |       PSDN            |                   |
  150.     |      LAYER        |                       |-------------------|
  151.     |-------------------|                       |                   |
  152.     |                   |X.25              ASYNC|                   |
  153.     |       X.25        |----     PAD      -----|     PPP           |
  154.     |                   |                       |                   |
  155.     +-------------------+                       +-------------------+
  156.  
  157.  
  158.     Fig. 2    The protocol layers on the PC and the multiuser host
  159.  
  160.  
  161. Khanna                                                          [Page 3]
  162.  
  163. DRAFT      PPP for Asynchronous PAD to Synchronous X.25 access     May,1997
  164.  
  165.  
  166.  
  167.     3.1 Call Establishment Phase
  168.  
  169.         The protocol must work over the existing PADs. Whenever a PC 
  170.         makes an outgoing call through a PAD, the PAD invariably puts
  171.         the PAD X.29 PID (1,0,0,0) in the first 4 bytes of the X.25 Call 
  172.         Request User Data field. When such an incoming Call Request
  173.         packet is received by the remote host, it invariably invokes the
  174.         3X PAD software to handle the call. This software allows the remote
  175.         login application to run between the PC and the host.
  176.  
  177.         Since the proposed protocol on PC is also making the call
  178.         through a PAD, the same PID will be received at the remote host
  179.         causing the 3X PAD to be run instead of the proposed protocol
  180.         over the remote host.
  181.  
  182.         This problem is solved by following the following mechanism.
  183.         The PC software makes a call through the PAD with the Fast
  184.         Select option. This allows extra data to be sent with the call.
  185.         The first 4 bytes of this extra data are filled with the pattern
  186.         (0,0,0,1). The remote host receives an incoming Fast Select
  187.         call. The PID is same as for any other normal PAD call
  188.         (1,0,0,0). But since it is a Fast Select call, the host is made
  189.         to invoke the proposed protocol instead of the 3X PAD. Also the
  190.         host sends a Fast Select call acceptance packet by changing the
  191.         first 4 bytes to a pattern (0,0,0,2). The PC on receiving this
  192.         acceptance packet compares the data with (0,0,0,2). The PC 
  193.         clears the call if the data does not match, else it sends a
  194.         command to PAD to make it work in Transparent Profile and PPP is 
  195.         invoked over the Async port. Note that if the PAD does not display 
  196.         the data in the Call Accept packet, an alternative approach is
  197.         suggested where the PC accepts the call and then the multiuser
  198.         host software sends the first X.25 Data packet with the above
  199.         pattern. The PC software then compares this data and invokes PPP.
  200.  
  201.         Let us see as to how the proposed protocol coexists with the
  202.         existing set of protocols running over the X.25 stack. Let the
  203.         multiuser host be running only 3X PAD software over it and not
  204.         running our proposed protocol. The above steps must ensure that
  205.         the PPP process on the PC does not incorrectly start a session
  206.         with the 3X PAD remote login process on the multiuser host.
  207.  
  208.  
  209. Khanna                                                          [Page 4]
  210.  
  211. DRAFT       PPP for Asynchronous PAD to Synchronous X.25 access     May,1997
  212.  
  213.  
  214.  
  215.         On receiving an incoming Fast Select call, the remote 3X PAD
  216.         process can behave in any of the following two ways. If it does
  217.         not support the Fast Select facility, it may clear the call.
  218.         Thus no call is established, as desired. Or else if it
  219.         supports Fast Select facility it sends an acceptance packet.
  220.         Since the 3X PAD process protocol is not supposed
  221.         to send any data in the Call Accept User Data field, it may 
  222.         either send this packet without any data or it may simply copy the
  223.         incoming pattern in it, depending on its implementation.
  224.  
  225.         The comparison of this field (0,0,0,1) with pattern (0,0,0,2), as 
  226.         above, fails. Thus the PC clears the call and no session is 
  227.         established.  Thus in no case, incorrect associations can be made 
  228.         due to the proposed protocol. 
  229.  
  230.     3.2 Data Transfer Phase
  231.  
  232.         Once the connection is successfully established, the standard PPP 
  233.         and TCP/IP are running over the connection. The data transfer
  234.         phase of the protocol will ensure that data is received
  235.         correctly even in case of arbitrary segmentation in the X.25
  236.         network.
  237.  
  238.     Since the PPP at the PC end is running in async. mode, the "Octet-
  239.     stuffed framing" mechanism is used [8] for data transfer. The PPP
  240.     layer at the remote host ( running above X.25 ) also uses the same
  241.     method to interpret the data.
  242.         
  243.         The PPP on PC encloses the TCP/IP packets within headers and trailers 
  244.     and transmits the resultant byte stream to the PAD. Let us
  245.         assume that PAD had to send it as 2 X.25 packets.  The packets 
  246.         reach the X.25 stack on the multiuser host which strips the X.25 
  247.         headers and hands over the individual packets to proposed protocol 
  248.         layer above it.
  249.  
  250.         The proposed protocol layer works under the control of PPP 
  251.         running above it. It receives X.25 packets from the underlying 
  252.         X.25 stack, breaks these into individual bytes and hands these
  253.         over to the PPP layer running above it. Each time PPP
  254.         requires a new packet, it asks for individual bytes from
  255.         this layer. The steps taken by this layer  on receiving a 
  256.         request for a byte from PPP are as follow.
  257.  
  258.  
  259.  
  260. Khanna                                                          [Page 5]
  261.  
  262. DRAFT       PPP for Asynchronous PAD to Synchronous X.25 access     May,1997
  263.  
  264.  
  265.  
  266.         1.  If the layer does not possess a X.25 data packet, request
  267.             for one from the underlying X.25 stack. 
  268.  
  269.             Initialise a local pointer to the first byte of the packet.
  270.  
  271.             Extract this byte of the packet and give it to the
  272.             PPP layer above requesting a byte. 
  273.  
  274.         2.  Else, if it already possesses a X.25 data packet,
  275.             give the byte in the packet pointed to by the local
  276.             pointer.
  277.             
  278.         3.  Increment a local pointer to point to the next byte of 
  279.             the packet. If the complete packet has been read,
  280.             discard the packet.
  281.  
  282.         The PPP layer above waits for getting a start flag
  283.         and keeps on requesting bytes from this layer till end
  284.         flag is received. This packet is handed over to TCP/IP layers above it.
  285.         Thus, PPP is oblivious of the fact that its packet has
  286.         been received as multiple X.25 packets. When the packet
  287.         is given to the TCP/IP layers above, it is exactly
  288.         the same as was transmitted by the sending TCP/IP entity.
  289.         
  290.         Thus it is interpreted correctly and networking applications 
  291.         can run successfully across the two systems.
  292.  
  293.         The sending of data from the multiuser host to the PC is also
  294.         similar. The PPP hands over the individual bytes to the
  295.         proposed protocol layer below it. The layer works like a PAD works
  296.         in the Transparent Profile mode, i.e. sends a X.25 packet when
  297.         its buffer is full or a gap of 1 second is received between any
  298.         2 bytes.
  299.  
  300.     3.3 Call Disconnection Phase
  301.  
  302.         When the TCP/IP application on the PC terminates, it sends a 
  303.     management command to PPP asking it to terminate the call. This makes 
  304.     the PPP to pull down the DTR signal on the Async line. This causes the 
  305.     PAD to send a clear packet to the remote, which clears the VC.
  306.  
  307.  
  308. Khanna                                                          [Page 6]
  309.  
  310. DRAFT       PPP for Asynchronous PAD to Synchronous X.25 access     May,1997
  311.  
  312.  
  313.  
  314. 4.  Conclusion
  315.  
  316.     We have a proposed a protocol which allows TCP/IP access between PCs
  317.     connected to a PAD and multiuser hosts connected to a X.25 Switch.
  318.     The protocol works under arbitrary segmentation of packets in the
  319.     X.25 network. It is implementable on existing set of PADs and
  320.     Switches and co-exists with the existing set of protocol stacks
  321.     running over X.25 layers.
  322.  
  323. 5.  References
  324.  
  325.     [1] Vimal K. Khanna, "A suggested protocol for Internet access on PSDNs",
  326.     Journal of Systems Architecture, Elsevier Science, (accepted April 1997).
  327.  
  328.     [2] "Recommendation X.3 - PAD in a Public Data Network", CCITT Blue
  329.     Book Volume VIII, Fascicle VIII.2, CCITT, 1988.
  330.  
  331.     [3] "Recommendation X.28 - DTE/DCE Interface for a Start Stop Mode
  332.     Data Terminal Equipment accessing the PAD Facility in a Public Data
  333.     Network situated in the same country", CCITT Blue Book Volume VIII, 
  334.     Fascicle VIII.2, CCITT, 1988.
  335.  
  336.     [4] "Recommendation X.29 - Procedures for the exchange of control
  337.     information and user data between a PAD facility and a packet mode
  338.     DTE or another PAD", CCITT Blue Book Volume VIII, Fascicle VIII.2, 
  339.     CCITT, 1988.
  340.  
  341.     [5] A.Malis,D.Robinson,R.Ullmann,"RFC 1356 - Multiprotocol
  342.     Interconnect on X.25 and ISDN in the Packet Mode",NIC,1992.
  343.  
  344.     [6] J.L.Romkey,"RFC 1055 - Nonstandard for transmission of IP
  345.     datagrams over serial lines : SLIP", NIC, 1988.
  346.  
  347.     [7] W. Simpson,"RFC 1661 - The Point-to-Point Protocol", NWG, July 1994.
  348.  
  349.     [8] W. Simpson,"RFC 1662 - PPP in HDLC-like framing", NWG, July 1994.
  350.  
  351.     [9] W. Simpson,"RFC 1598 - PPP in X.25", NWG, July 1994.
  352.  
  353.     [10] "Draft revised Recommendation X.25 - Interface between Data
  354.     Terminal Equipment (DTE) and Data Circuit-terminating Equipment
  355.     (DCE) for terminals operating in the packet mode and connected to
  356.     Public Data Networks by dedicated circuit", CCITT, 1992.
  357.  
  358.  
  359.  
  360. 6. Author's Address
  361.  
  362.  
  363.     Vimal K. Khanna,
  364.     Mindware,
  365.     B-60, Okhla Industrial Area Ph-I,
  366.     New Delhi - 110 020, India.
  367.  
  368.    Phone: (91 11) 681 52 04
  369.    Email: vimal@pcl.stpn.soft.net
  370.  
  371. 7. Expiration date of the document
  372.  
  373.    31 January, 1998
  374.  
  375.  
  376. INTERNET-DRAFT               EXPIRES FEBRUARY 1998    INTERNET-DRAFT
  377.  
  378.