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