Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 5024

ODETTE File Transfer Protocol 2.0

Pages: 135
Obsoletes:  2204
Updated by:  8996
Part 4 of 4 – Pages 100 to 135
First   Prev   None

Top   ToC   RFC5024 - Page 100   prevText

Appendix A. Virtual File Mapping Example

This example demonstrates the mapping of a Virtual File into a sequence of ODETTE-FTP Data Exchange Buffers. Each line in this extract from 'The Rime of the Ancient Mariner' by Coleridge [RIME] is separated by CR-LFs in a file that is being transmitted as a T format file. It is an ancient Mariner, And he stoppeth one of three. "By thy long grey beard and glittering eye, Now wherefore stopp'st thou me? "The Bridegroom's doors are opened wide, And I am next of kin; The guests are met, the feast is set: May'st hear the merry din." He holds him with his skinny hand, "There was a ship," quoth he. "Hold off! unhand me, grey-beard loon!" Eftsoons his hand dropt he. He holds him with his glittering eye-- The Wedding-Guest stood still, And listens like a three years; child: The Mariner hath his will. The Wedding-Guest sat on a stone: He cannot chuse but hear; And thus spake on that ancient man, The bright-eyed Mariner. The ship was cheered, the harbour cleared, Merrily did we drop Below the kirk, below the hill, Below the light-house top. The Exchange Buffers below were built from the above. The top line of each represents the ASCII code, while the two lines below give the hexadecimal value. Note that: . The "D" at the beginning of each Exchange Buffer is the command code.
Top   ToC   RFC5024 - Page 101
     . The "?" preceding each subrecord is the header octet (see the
       hexadecimal value).

     Exchange Buffer 1

     D?It is an ancient Mariner,..And he stoppeth one of three..."By

     t?hy long grey beard and glittering eye,..Now wherefore stopp'st

      ?thou me?...."The Bridegroom's doors are opened wide,..And I am

      ?next of kin;..The guests are met, the feast is set:..May'st he

     a?r the merry din."....He holds him with his skinny hand,.."Ther

     e? was a ship," quoth he..."Hold off! unhand me, grey-beard loon

     !?"..Eftsoons his hand dropt he.....He holds him with his glitte

     r?ing eye--..The Wedding-Guest stood still,..And listens like a

     t?hree years; child:..The Mariner hath his will.....The Wedding-

     G?uest sat on a stone:..He cannot chuse but hear;..And thus spak

     e? on that ancient man,..The bright-eyed Mariner.....The ship wa
Top   ToC   RFC5024 - Page 102
     s? cheered, the harbour cleared,..Merrily did we drop..Below the

      .kirk, below the hill,..Below the light-house top...
Top   ToC   RFC5024 - Page 103

Appendix B. ISO 646 Character Subset

o-----------------------------------------------------------------o | | 7| 0 | 0 | 0 | 0 | 1 | 1 | 1 | 1 | | | B -+-----+-----+-----+-----+-----+-----+-----+-----| | | I 6| 0 | 0 | 1 | 1 | 0 | 0 | 1 | 1 | | | T -+-----+-----+-----+-----+-----+-----+-----+-----| | | 5| 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 | | |----+-----+-----+-----+-----+-----+-----+-----+-----| | | | | | | | | | | | | | | | | | | | | | | |------------| | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | | BIT | | | | | | | | | | | 4 3 2 1 | | | | | | | | | | |============o====o=====+=====+=====+=====+=====+=====+=====+=====| | 0 0 0 0 | 0 | | | SP | 0 | | P | | | |------------|----|-----+-----+-----+-----+-----+-----+-----+-----| | 0 0 0 1 | 1 | | | | 1 | A | Q | | | |------------+----|-----+-----+-----+-----+-----+-----+-----+-----| | 0 0 1 0 | 2 | | | | 2 | B | R | | | |------------+----|-----+-----+-----+-----+-----+-----+-----+-----| | 0 0 1 1 | 3 | | | | 3 | C | S | | | |------------+----|-----+-----+-----+-----+-----+-----+-----+-----| | 0 1 0 0 | 4 | | | | 4 | D | T | | | |------------+----|-----+-----+-----+-----+-----+-----+-----+-----| | 0 1 0 1 | 5 | | | | 5 | E | U | | | |------------+----|-----+-----+-----+-----+-----+-----+-----+-----| | 0 1 1 0 | 6 | | | & | 6 | F | V | | | |------------+----|-----+-----+-----+-----+-----+-----+-----+-----| | 0 1 1 1 | 7 | | | | 7 | G | W | | | |------------+----|-----+-----+-----+-----+-----+-----+-----+-----| | 1 0 0 0 | 8 | | | ( | 8 | H | X | | | |------------+----|-----+-----+-----+-----+-----+-----+-----+-----| | 1 0 0 1 | 9 | | | ) | 9 | I | Y | | | |------------+----|-----+-----+-----+-----+-----+-----+-----+-----| | 1 0 1 0 | 10 | | | | | J | Z | | | |------------+----|-----+-----+-----+-----+-----+-----+-----+-----| | 1 0 1 1 | 11 | | | | | K | | | | |------------+----|-----+-----+-----+-----+-----+-----+-----+-----| | 1 1 0 0 | 12 | | | | | L | | | | |------------+----|-----+-----+-----+-----+-----+-----+-----+-----| | 1 1 0 1 | 13 | | | - | | M | | | | |------------+----|-----+-----+-----+-----+-----+-----+-----+-----| | 1 1 1 0 | 14 | | | . | | N | | | | |------------+----|-----+-----+-----+-----+-----+-----+-----+-----| | 1 1 1 1 | 15 | | | / | | O | | | | o-----------------------------------------------------------------o
Top   ToC   RFC5024 - Page 104

Appendix C. X.25 Specific Information

The International Organization for Standardization (ISO) Open Systems Interconnection (OSI) model is the basis for ODETTE-FTP. ODETTE-FTP covers levels 4 to 7, and originally CCITT X.25 was the only recommended telecommunication protocol for OSI's layers 1, 2, 3. ISO Reference Model: +------------------------------+ <==== File Service | Level-7 FTP application | |------------------------------| | Level-6 FTP presentation | |------------------------------| | Level-5 FTP session | |------------------------------| | Level-4 FTP transport | |------------------------------| <==== Network Service | Level-3 X.25 | |------------------------------| | Level-2 X.25 | |------------------------------| | Level-1 X.25 | +------------------------------+

C.1. X.25 Addressing Restrictions

When an X.25 call is made over a PSDN, the Network User Address (NUA) of the destination must be specified in order that the PTT may route the call. The call placed is directed to the termination equipment upon the user's premises. It is possible to provide extra information in the Call Request Packet in addition to the mandatory NUA required by the PTT. This extra information may be of 2 kinds: (a) A subaddress: It is simply an extension to the address and it is put into the called address field of the Call Request Packet. This information (Address + Subaddress) is taken from the destination address field of the F_CONNECT_RQ; therefore, from the user's point of view, there is no distinction between the main address and subaddress parts.
Top   ToC   RFC5024 - Page 105
    (b) User data:

       There is no standard for user data.  Moreover, there is no
       information in the F_CONNECT_RQ from which the ODETTE-entity may
       derive user data to be put in the N_CONNECT_RQ; therefore, user
       data shall not be used.

C.2. Special Logic

The SSID field SSIDSPEC specifies whether special logic must be applied (Y (yes) or N (no)) to the Data Exchange Buffer before the ODETTE-FTP moves the data into the NSDU (Network Service Data Unit) and passes control to the Network Service.

C.2.1. When Special Logic Is Not To Be Used

This logic is not applied to SSRM and SSID commands.

C.2.2. The Need for "Enveloping" Exchange Buffers

The "special-logic" parameter was created in order to allow the use of ODETTE-FTP over asynchronous links. The "special-logic" could be needed to enable terminals to access an X.25 network via an asynchronous entry (through a PAD: Packet Assembly / Disassembly). The "special-logic" is not needed in case of a whole X.25 connection. This "special-logic" realises a CRC function in order to detect errors due to the asynchronous medium. Negotiation of the "special-logic" parameter in the SSID command is as follows: SSID SSID ----------------------------------------------- special-logic=yes ---------------------> <------------------------------------ special-logic=yes or <------------------------------------ special-logic=no special-logic=no ----------------------> <------------------------------------ special-logic=no This logic is activated when the "special-logic" parameter in the SSID specifies Y (yes).
Top   ToC   RFC5024 - Page 106
   Special logic processing, when activated, will function within level
   4 of the OSI model.

          +------------------------------+  <====  File Service
          | Level-7  FTP    application  |
          | Level-6  FTP    presentation |
          | Level-5  FTP    session      |
          | Level-4  FTP    transport    |
          |------------------------------|  <====  Network Service
          | Level-3         X.25         |
          | Level-2         X.25         |
          | Level-1         X.25         |

C.2.3. Responsibilities of Special Logic

When transmitting an Exchange Buffer and special logic is active, layer 4 will wrap the Exchange Buffer in synchronization and delineation characters, then protect the data integrity by means of a block checksum (BCS). When receiving an Exchange Buffer and special logic is active, layer 4 will remove such things as synchronization and delineation characters, etc., before passing the Exchange Buffer to the higher layers.

C.2.4. Extended Exchange Buffer Format

Each envelope has a 1-byte header prefixed to it, and a 2-byte checksum appended to the end. The checksum is derived in a manner specified in the ISO DIS 8073 TRANSPORT LAYER documentation.
Top   ToC   RFC5024 - Page 107
   The layout of the data buffer will be structured as follows:

   | S | B |                                                  | B | C |
   | T | S |         COMPLETE EXCHANGE BUFFER (CEB)           | C | / |
   | X | N |                                                  | S | R |
     A   A                                                      A   A
     |   |                                                      |   |
     |   +-------------  Block sequence number                  |   |
     |                                                          |   |
     +-----------------  Synchronization character              |   |
                                                                |   |
                         Block checksum  -----------------------+   |
                         Delineation character  --------------------+

   The envelope is initialised with an STX and the checksum variables
   are set to 0.  The leading STX is not protected by the checksum
   calculation but is explicitly protected by a character compare at the
   receiver's end.  The Exchange Buffer is processed character by
   character.  As each character is removed from the Exchange Buffer, it
   is put through the checksum calculation and then, prior to its
   insertion in the envelope, it is put through the Shift-out
   transparency logic, which will result in either one or two characters
   being inserted.  When the contents of the Exchange Buffer have been
   entirely processed, then the checksum variables are brought up to
   date by inserting two X'00's through the checksum calculator and the
   two resultant checksum characters forwarded to the Shift-out
   transparency logic for insertion into the envelope.  Finally, a
   carriage return (CR) is appended to the envelope.  The segment is now
   ready for transmission to line.

   Upon receipt of a valid envelope that has the correct sequence
   number, the host should increment his sequence number register ready
   for the next transmission.

   The receiver will initialise his receiving buffer area upon receipt
   of an STX character, place the STX at the beginning of the buffer,
   and reset checksum variables.  All subsequent characters are
   processed using Shift-out logic before they are inserted into the
   buffer, at which point they will NOT be processed by the checksum
   calculator, although the character following the Shift-out (after
   subtracting X'20') will be.  The checksum characters themselves will
   be processed by the checksum calculator by virtue of the design of
   the checksum algorithm.
Top   ToC   RFC5024 - Page 108

C.2.5. Error recovery

C.2.5.1. Mechanism
The error correction scheme is implemented by the definition of three timers and the use of an ASCII NAK (Negative Acknowledgement) character followed by a C/R. The <NAK><C/R> will flow between the two session partners, but only as a consequence of previous bad data. A user of the error recovery correcting extension must always work with a credit value of 1. This can be forced upon any session partner at SSID negotiation. The effect will be to force a simple half-duplex flip-flop protocol. Upon receipt of a bad block, send <NAK><C/R> to the session partner. Upon receipt of a <NAK><C/R>, a session partner should retransmit the last block in its entirety.
C.2.5.2. Timers
The majority of error conditions will be detected by a bad BCS sequence. However, certain conditions cannot be so detected. For example, a corrupt C/R will mean that the receiver will not know that the end of a block has been reached. No matter how long he waits, no more data will come from the sender. Thus, a timer is the only way to detect this type of corruption. There are three timers needed to detect all possible malignant conditions of this type. T1 - Exchange Buffer Time Out (Inactivity or Response) T2 - Inter Character Time Out T3 - Data Carrier Detect Loss Time Out The three timers are in addition to the timer defined in the original protocol. TIMER T1 - RESPONSE TIME OUT (DEFAULT = 45 SECONDS): Used to detect a high-level block Time Out, e.g., the Time Out between an SFID and its associated SFPA or SFNA response. Started - It is started after the last character of an exchange buffer has been sent to the line. Stopped - It is stopped when an STX has been received. Expiry - Retransmit the whole block again, until such time as the retry limit has been reached.
Top   ToC   RFC5024 - Page 109

     Used to detect errors in the reception of individual characters.

      Started - For an asynchronous entity, it is started upon receipt
                of each character while in synchronisation mode.  For an
                X.25 entity, it is started after a received block that
                did not terminate an Exchange Buffer.

      Stopped - Upon receipt of the next character.

      Expiry  - Send a <NAK><C/R>, drop out of synchronised mode, and go
                back and listen to line.


     Used by an asynchronous entity only and is used to detect a
     temporary carrier failure.

      Started - When DCD (Data Carrier Detect) is lost.

      Stopped - When DCD is regained.

      Expiry  - Disconnect the session.

C.2.5.3. Types of Error
Data corruption when it occurs can be categorised in one of five ways: (1) CORRUPT STX (START OF TEXT) In this situation the STX is not seen and synchronisation is not achieved. The terminating C/R is received out of synchronisation and hence the block is not seen by the receiver. A <NAK><C/R> is transmitted to the sender to indicate this. The sender should then retransmit the last block (each implementation will need to set a retry limit to be used for the number of consecutive times it attempts to retransmit a block -- a default limit of 5 is recommended). All data received outside synchronisation (except <NAK><C/R>) are ignored.
Top   ToC   RFC5024 - Page 110
        (A)                                    (B)

    Dropped Start of Text (STX)

          |   | B |         | B | C |
     -----|   | S |  CEB    | C | / |----->  Not sync
          |   | N |         | S | R |

                   | N | C |
             <-----| A | / |-----            Not sync
                   | K | R |

    Exchange Buffer Resent

          | S | B |         | B | C |
     -----| T | S |  CEB    | C | / |----->  Sync
          | X | N |         | S | R |


    This situation manifests itself as an extended period of
    synchronisation with no activity.  The T2 timer will detect this

        (A)                                    (B)

    Corrupt Carriage Return

          | S | B |         | B |   |
     -----| T | S |  CEB    | C |   |----->  No activity
          | X | N |         | S |   |

                   | N | C |                 T2
             <-----| A | / |-----            Timed out
                   | K | R |
Top   ToC   RFC5024 - Page 111
    Exchange Buffer Resent

          | S | B |         | B | C |
     -----| T | S |  CEB    | C | / |----->  Sync
          | X | N |         | S | R |

   (3) BAD DATA

    In this situation, the receiver is unable to tell whether the error
    is bad data or bad BCS.  In either case, the response is to discard
    the Exchange Buffer and send a <NAK><C/R>.

        (A)                                    (B)

    Bad Data/BCS

          | S | B |         | B | C |        Bad data
     -----| T | S |  "%!    | C | / |----->  detected
          | X | N |         | S | R |

                   | N | C |
             <-----| A | / |-----            Discard Block
                   | K | R |

    Exchange Buffer Resent

          | S | B |         | B | C |
     -----| T | S |  CEB    | C | / |----->  Data OK
          | X | N |         | S | R |


    A circular sequential number (0 up to and including 9) is assigned
    to transmitted Exchange Buffers.  This is to aid detection of
    duplicate or out-of-sequence Exchange Buffers.  Once a duplicate
    block is detected, the Exchange Buffer in question is discarded.
    Once an out of sequence block is detected, this should result in a
    protocol violation.
Top   ToC   RFC5024 - Page 112
    Example protocol sequence:

        (A)                                    (B)

    Exchange Buffer Being Sent

          | S |   |         | B | C |        Expecting
     -----| T | 0 |  EERP   | C | / |----->  BSN=0
          | X |   |         | S | R |        Transmission

    Exchange Buffer Being Sent

          | S |   |         | B | C |        Response to
     <----| T | 0 |  RTR    | C | / |-----   Previous
          | X |   |         | S | R |        Block

    Exchange Buffer Being Sent

          +-------------------------+        Expecting
          | S |   |         | B | C |        BSN=1 (Block
     -----| T | 1 |  SFID   | C | / |- // -> lost in
          | X |   |         | S | R |        Transmission)
          +-------------------------+        T1 Timed Out

    Exchange Buffer Being Sent

          | S |   |         | B | C |        Send last
     <----| T | 0 |  RTR    | C | / |-----   Block
          | X |   |         | S | R |        again

    Discard Block
    and start
    Timer T1

    T1 Timed Out
Top   ToC   RFC5024 - Page 113
    Exchange Buffer Resent

          | S |   |         | B | C |        Expecting
     -----| T | 1 |  SFID   | C | / |----->  BSN=1
          | X |   |         | S | R |        Block OK

    Exchange Buffer Being Sent

          | S |   |         | B | C |        Response
     <----| T | 1 |  SFPA   | C | / |-----   BSN=1
          | X |   |         | S | R |        Block OK

    Exchange Buffer Being Sent

          | S |   |         | B | C |
     -----| T | 2 |  DATA   | C | / |----->  Data OK
          | X |   |         | S | R |

   Note: A credit value of 1 must be used to guarantee half-duplex

C.2.6. Sequence of Events for Special Logic Processing

The following functions will be executed in sequence: 1. Calculation of the Block Sequence Number (BSN): BSN is set to zero by SSID. First block will be sent with value zero. Value of BSN is increased by one for each data buffer to be transmitted. When BSN value exceeds 9, counter will be reset to zero. Format: numeric/1 pos. 2. Calculation of the Block Checksum (BCS): Calculation is done as specified in the ISO DIS 8073 TRANSPORT LAYER document. Format: binary/2 pos.
Top   ToC   RFC5024 - Page 114
   3. Shift-out transparency  (See TRANSMIT/RECEIVE logic.)

      To avoid appearance of any control characters in the data stream,
      all the characters of the extended Exchange Buffer (with exception
      of the STX and carriage return characters enveloping the buffer)
      are put through a Shift-out logic, which result in a character
      being inserted (SO) and adding hex value '20' to the control

   4. The carriage return is inserted at the end of the data buffer.

   Note: After adding STX, BSN, BCS, CR, and SO-logic, the data buffer
         may exceed the Data Exchange Buffer size.

C.2.7. Checksum Creation Algorithm

These follow the ISO DIS 8073 TRANSPORT LAYER standard. SYMBOLS: The following symbols are used: C0,C1 Variables used in the algorithm L Length of the complete NSDU X Value of the first octet of the checksum parameter Y Value of the second octet of the checksum parameter ARITHMETIC CONVENTIONS: Addition is performed in one of the two following modes: a) modulo 255 arithmetic b) one's complement arithmetic in which if any of the variables has the value minus zero (i.e., 255) it shall be regarded as though if was plus zero (i.e., 0). ALGORITHM FOR GENERATING CHECKSUM PARAMETERS: . Set up the complete NSDU with the value of the checksum parameter field set to zero. . Initialise C0 and C1 to zero. . Process each octet sequentially from i=1 to L by a) adding the value of the octet to C0, then b) adding the value of C0 to C1.
Top   ToC   RFC5024 - Page 115
     . Calculate X and Y such that

            X = C0 - C1
            Y = C1 - 2*C0

     . Place the values X and Y in the checksum bytes 1 and 2,

C.2.8. Algorithm for checking checksum parameters

. Initialise parameters C0 and C1 to zero. . Process each octet of NSDU sequentially from i=1 to L by a) adding the value of the octet to C0, then b) adding the value of C0 to C1. . If, when all the octets have been processed, either or both C0 and C1 does not have the value zero, then the checksum formulas have not been satisfied. Note that the nature of the algorithm is such that it is not necessary to compare explicitly the stored checksum bytes.

C.2.9. Shift-out Processing

(Transparency for all control characters) TRANSMIT LOGIC (values SO: X'0E' or X'8E') Buffer(1), ... , (n) is a character in the buffer to be sent. FOR i=1 to n /* for all octets of the buffer */ IF ((buffer(i) & X'7F') < X'20') THEN output (SO) output (buffer(i) + X'20') ELSE output (buffer(i))
Top   ToC   RFC5024 - Page 116

    RECEIVE  LOGIC  (values SO: X'0E' or X'8E')

     Buffer(1), ... , (n) is a character in the received buffer.

     drop = false
     FOR i=1 to n                    /* for all octets of the buffer */

         IF    drop = true

         THEN  output (buffer(i)  -  X'20')
               drop = false

         ELSE  IF    buffer(i) = (X'0D'  or  X'8D')
               THEN  Stop
               ELSE  IF    buffer(i) = SO
                     THEN  drop = true
                     ELSE  output (buffer(i))


C.3. PAD Parameter Profile

Before an (ODETTE-FTP) asynchronous entity --> Modem --> PAD --> (ODETTE-FTP) native X.25 link can be established, the target PAD parameters must be set such that correct communication is established. It is strongly recommended that the PAD parameters are set by the X.25 entity. CCITT recommendations X.3, X.28, and X.29 define the PAD parameters and procedures for exchange of control information and user data between a PAD and a packet mode Data Terminal Equipment (DTE). Following is the Parameter list and values used to set the PAD for ODETTE-FTP communication. For further detailed information see the specification for CCITT X.25, X.28, X.29 and X.3. No. Description Value Meaning --------------------------------------------------------------- 1 Escape from Data Transfer 0 Controlled by host 2 Echo 0 No Echo 3 Data Forwarding Signal 2 Carriage Return 4 Selection of Idle Timer Delay 20 1 second 5 Ancillary Device Control 0 X-ON, X-OFF not used 6 PAD Service Signals 1 All except prompt 7 Procedure on Break 2 Reset 8 Discard Output 0 Do not discard 9 Padding after Carriage Return 0 No padding
Top   ToC   RFC5024 - Page 117
   10  Line Folding                    0     No line folding
   11  Terminal Data Rate              -     Read only
   12  Flow Control of the PAD         0     No flow control used
   13  Linefeed Insertion after C/R    0     No linefeed
   14  Linefeed Padding                0     No linefeed padding
   15  Editing                         0     No editing
   16  Character Delete                127   Delete
   17  Line Delete                     24    <CTRL>X
   18  Line Display                    18    <CTRL>R
   19  Editing PAD Service Signals     0     No service signal
   20  Echo Mask                       0     No echo mask
   21  Parity Treatment                0     No parity check
   22  Page Wait                       0     No page wait

   Note 1:

   Refer to CCITT (1984)
   - Parameters 1 - 12 are mandatory and available internationally.
   - Parameters 13 - 22 may be available on certain networks and may
     also be available internationally.
   - A parameter value may be mandatory or optional.

   The ODETTE profile refers only to parameter values which must be
   internationally implemented if the parameter is made available

   The ODETTE-FTP "special-logic" parameter may be impossible on some
   PADs because they do not support of some of the parameters (13 - 22).
   (If the PAD is supporting parity check (21) by default, ODETTE-FTP
   special logic would be impossible.)

   It is a user responsibility to ensure special logic consistency when
   making the PAD subscription.

   Note 2:

   Some parameters may have to be set differently depending on:
   - Make and function of the start-stop mode DTE entity.
   - Start-stop mode DTE entity ODETTE-FTP monitor function.
   - PAD services implemented.
   - Packet mode DTE entity ODETTE-FTP monitor function.
Top   ToC   RFC5024 - Page 118

Appendix D. OFTP X.25 over ISDN Recommendation

This appendix describes the recommendation of ODETTE Group 4 (1) for the use of OFTP (2) over X.25 over ISDN. (1) ODETTE Group 4 is responsible for the specification of Telecommunications standards and recommendations for use within the Automotive Industry. (2) OFTP (ODETTE File Transfer Protocol) is the communications standard specified by ODETTE Group 4 designed for the transfer of both EDI and non-EDI data. This document offers an introductory overview of a technical subject. It is structured to contain the ODETTE recommendation, together with introductory information for the person not familiar with ISDN, and notes on the issues associated with the implementation of the recommendation. The first section provides the detailed ODETTE recommendation, which is followed by a general discussion. If you are not familiar with the terminology, please read the subsequent sections first. How far an existing X.25 Line adapter may be replaced by an ISDN line adapter in an installation depends on the opportunities in view of connections (X.25 or ISDN) of the involved partners for file transfer. Companies that keep many connections to external partners (for example, car manufacturing companies) may use the OFTP file transfer in view of compatibility, which must always be considered anyway only in parallel to the X.25 network. It is not the aim of this recommendation to remove the OFTP file transfer generally from the X.25 network to the ISDN network. This will not always be possible for international connections because of technical reasons, and this does not always make sense for connections with a low size of data to be transmitted. Certainly, the use of ISDN, when exchanging a high volume of data (for example, CAD/CAM files), is very much cheaper than the use of an X.25 network. For such cases, this recommendation shall provide a cost-effective possibility for file transfer. This appendix is organized as follows. D.1 defines the ODETTE recommendation in these terms, D.2 introduces the ISDN environment to the unfamiliar reader, D.3 describes the various methods of connecting to ISDN, and D.4 covers implementation issues.
Top   ToC   RFC5024 - Page 119

D.1. ODETTE ISDN Recommendation

X.25: Level 2 ISO 7776 Protocol Level 3 ISO 8208 Protocol Packet Size 128 Level 2 7 Window Size Level 3 7 Window Size First LCN 1 Number of LCNs 1 Facilities Window Size and Packet Size negotiation shall be supported by everybody. Call User Data should not be required. Calling NUA Optionally provided by the call initiator. Called NUA Should be set to a value where the last 'n' digits can be specified by the called party. ISDN: Apart from requesting a 64K unrestricted digital call, no ISDN features shall be required. Timeout control: To avoid connections (B channels) within the circuit-switched ISDN network remaining active but unused for a long time, the adapter should include a timeout control. An ISDN connection (B channel) should be released if no X.25 packets have been transmitted on this connection for a longer time. For flexibility a variable user definable timer should be incorporated into the adapter.
Top   ToC   RFC5024 - Page 120
                       In the event of a timeout situation the adapter
                       has to release the ISDN connection and notify the
                       local OFTP by the transmission of a clear packet.

   The pages that follow are informational and do not form part of this

D.2. Introduction to ISDN

The use of digital encoding techniques over such high-quality, error-free backbone networks has allowed the PTTs to offer high bandwidths to the end user. The service is named ISDN (Integrated Services Digital Network). The increasing need to transfer larger volumes of EDI data, in particular CAD/CAM drawings, has focused attention upon high-speed, low-cost communication. The traditional X.25 over a Packet Switched Data Network (PSDN) has been a good general purpose communications subsystem. Unfortunately, its cost and transfer speed make PSDN expensive for the new requirement. X.25 over the new ISDN provides both the transfer speed and cost benefits to satisfy the new requirements. We include the following terminology because for us to make sense of ISDN and X.25, it is important that we use definitions precisely and avoid the abuses of the past. ISDN: Integrated Services Digital Network X.25: X.25 is a communications protocol. It defines the structure of data packets that comprise the protocol and the manner in which they are used. PSDN: A PSDN (Packet Switched Data Network) is a network over which the X.25 protocol is operated. PSPDN: A PSPDN (Packet Switched Public Data Network) is a PSDN operated by the PTTs. PSPDNs are given trade names, such as PSS in the UK, Datex-P in Germany, and Transpac in France. BRI: Basic Rate Interface, also known as Basic Rate Access, defines an ISDN facility with 2 x 64 K B channels. PRI: Primary Rate Interface, also known as Primary Rate Access, defines an ISDN facility with 30 x 64 K B channels.
Top   ToC   RFC5024 - Page 121
   Channels:    ISDN is typically brought into a consumer's premises
                using a twisted pair of wire.  Over this wire, data can
                be transmitted in frequency bands.  These frequency
                bands are allocated as channels.

   B channels:  The B channels are the data channels and operate at 64
                Kb.  The two end users of a connection will communicate
                over a B channel.

   D channel:   Signalling on ISDN is performed over the D channel.
                Signalling is used to set up and release connections on
                the B channels.  In some countries, the D channel can
                also be used for limited X.25 access to the PTTs' PSDN.

                The D channel operates at the lower speed of 16 Kb as it
                is normally used only at the beginning and end of a

                                         Bandwidth Allocation:
                     2 Wire                 B2 - 64 Kb
                     Twisted Pair           B1 - 64 Kb
                                         D Channel - 16 Kb

                The standard for the operation of the D channel is
                called ETSI and is used in most European countries.
                However, some countries that started the introduction
                very early used proprietary standards, for example:

                     1TR6 - Used in Germany
                     BTNR - Used in the UK

                Although there are D channel variations, this will not
                affect communications over the B channels as the
                communication over the D channel is between the
                subscriber and the ISDN service provider.

                However, the consumer's equipment must be able to handle
                the channel D signalling operated by the ISDN service
                provider and so there may be a problem of equipment
                availability and certification.

                All the PTTs have committed to migrate to ETSI (also
                known as EURO-ISDN and Q.931) and many are currently
                supporting both their national variant and ETSI.  It is
                advisable that in this situation the subscriber select
                the ETSI variant to avoid unnecessary equipment
Top   ToC   RFC5024 - Page 122
   Services:    The high-speed service is provided in two forms, Basic
                and Primary.

                Basic: 2+D, the D 2B channel operates at 16 Kb.  The
                Basic Rate access is normally provided to the subscriber
                over simple twisted pair cable.

                Primary: 30B+D, the D channel operates at 64 Kb.
                Primary Rate access is normally provided to the
                subscriber over shielded coaxial cable.  Note that the
                bandwidth for Primary is 2.048 Mbit/s.

   Protocols:   The B channel is a binary channel and is transparent to
                the flow of data.  Therefore, all of the currently
                available protocols can operate over a B channel.  The
                most common protocol is X.25.

   X.25:        The X.25 protocol is a primary protocol for open
                computer-to-computer communication.

   Passive Bus: It is possible to have an ISDN service enter a building
                and then have an 8-core cable laid within the building
                with multiple ISDN junction points, in the same way as
                one would have multiple telephone points (extensions)
                for a particular external telephone line.

   Connection Setup

      The adapter is responsible for analysing the outgoing X.25 call
      request and making an ISDN call to a derived ISDN address,
      establishing a new X.25 level-2 and level-3, and then propagating
      the X.25 Call Request Packet.

   Connection Termination

      The termination phase of the X.25 call is made with a Clear
      Request and finalised with a Clear Confirmation.  The recipient of
      the Clear Confirm should then close down the ISDN connection.

      The clear down of the ISDN connection should only be made if there
      are no other Switched Virtual Circuits (SVCs) active on the ISDN
      connection; note that the usage of multiple simultaneous SVCs is
      only by virtue of bilateral agreement.
Top   ToC   RFC5024 - Page 123

D.3. Equipment Types

There are a number of ways in which ISDN/X.25 access can be made. Integrated Adapter This is normally a PC-based ISDN adapter inside a PC. It is normal in such an environment that the OFTP application has the ability to manipulate the ISDN and X.25 aspects of the session independently and therefore have complete control. Equally important is that the speed of communication between the adapter and the application are at PC BUS speeds. It is therefore more likely that the effective transmission speed will be nearer the 64K limit. The other benefit of such a direct linkage is that both 64K B channels may be used in parallel and both able to operate at 64Kb. Elementary Terminal Adapter In this scenario, the computer has an integral X.25 adapter communicating X.21 with a Terminal Adapter that fronts the ISDN network. This allows a host with a X.25 capability to interface to ISDN, normally on a one-to-one basis. The interface between the Terminal Adapter and the PC will typically only support one 64K B channel. This is obviously an inefficient usage of the ISDN service. Because the linkage between the computer and the Terminal Adapter is only X.25, then some modification/configuration may be needed inside the Terminal Adapter when new users are added. X.25 Switch This solution is normally found inside the larger corporates where an internal X.25 network is operated or where dual X.25 and ISDN is required. The main benefit of a switch is to support both PSDN and ISDN simultaneously. Also, multiple X.21 lines may be implemented between the X.25 switch and the computer. This solution normally requires more effort to configure and may require obligations to be placed upon how incoming callers specify routing.
Top   ToC   RFC5024 - Page 124

D.4. Implementation

The adoption of ISDN as an additional subsystem to support OFTP communications has associated implementation problems, which can be categorised as below: X.25/ISDN Addressing Making a Call Receiving a Call Logical Channel Assignment Facilities Negotiation ISDN Call Attributes Homologation Issues Growth Performance

D.4.1. X.25/ISDN Addressing

The original OFTP was designed to work over the X.25 networks provided by the PTTs (PSPDNs). The national X.25 networks were interconnected to provide a global X.25 network, and a common addressing scheme was adopted by all. Although there were a few differences in addressing within a national network, the interface to other countries was quite rigid and normalised. PSPDN Numbering The addressing scheme adopted in X.25 is a 15-digit number (Network User Address, NUA) where the first three identify the country, the fourth digit identifies the network within the country, and the remainder specify the individual subscriber plus an optional subaddress. In the UK where a full X.25 numbering scheme is adopted, a NUA is, e.g., 234221200170, where 2342 is the DNIC (Data Network Identification Code) and 21200170 is the subscriber number. ISDN Numbering ISDN is an extension of the normal telephone system; consequently, it adopts (or rather is) the same numbering scheme as the telephone system (PSTN). The Numbering Conflict The PSDN and PSTN numbering schemes are two totally different numbering schemes. There is no relationship between them. It is this conflict that is at the heart of the matter.
Top   ToC   RFC5024 - Page 125

D.4.2. Making a Call

It is a consequence of PSDN and PSTN being based upon different and unconnected numbering schemes that the key problem arises. For X.25 to work over ISDN, three main methods of addressing are available: Un-mapped: The X.25 called NUA is used as the PSTN number. Thus, an X.25 call to 0733394023 will result in a PSTN call to 0733394023 and the call request that consequently flows will also be to 0733394023. Manipulated: The X.25 called NUA is manipulated by the subtraction and/or addition of digits to derive a resultant PSTN number. Thus, 2394023 could be manipulated to derive a PSTN number of 00944733394023, where the prefix 2 is deleted and replaced by 00944733. Mapped: The X.25 called NUA is used as a look-up into a table of PSTN numbers. Thus, an X.25 call to 234221200170 could be mapped to and result in a PSTN call to 0733394023 and the call request that consequently flows will remain as 234221200170. Un-mapped Calls Un-mapped calls are where the host-specified X.25 NUA is converted directly to the corresponding ISDN number. Thus, an X.25 call issued by the host to X.25 NUA 0733394023 will result in an ISDN call to the PSTN number 0733394023. After the call has been established, then HDLC/X.25 protocol setup will be established after which an X.25 call request will be transferred with the NUA 0733394023. When a PSTN call is made, the number of digits in the called number vary depending upon the location of the called party. When a number is called, it may be local, national, or international. local: 394023 national: 0733 394023 international: 009 44 733 394023 Depending upon where a call originates, the corresponding X.25 NUA in the call request packet will vary dramatically.
Top   ToC   RFC5024 - Page 126
      Such variation of X.25 NUA, in particular the changing prefix, can
      be difficult to be accommodated by X.25 routing logic in many

      When an international PSTN call is being made, then it is likely
      that the PSTN number exceeds 15 digits, which is the maximum
      length of an X.25 NUA.  Therefore, using un-mapped addressing may
      make some international calls impossible to make.

   Manipulated Calls

      The X.25 called NUA is manipulated by the subtraction and/or
      addition of digits to derive a resultant PSTN number.

      Let us assume that by internal convention we have identified the
      prefix '2' to indicate an international ISDN call.  Thus, an X.25
      call request of 244733394023 could be manipulated to derive a PSTN
      number of 00944733394023, where the prefix '2' is deleted and
      replaced by '009' (the international prefix).

      The X.25 called NUA would typically be left in its un-manipulated
      state.  As individual internal conventions vary, the X.25 called
      NUA will vary.  In the case above, it would be 244733394023, but
      another installation might have the convention where a prefix of
      '56' specifies the UK and so the NUA will be 56733394023, where
      the '56' is deleted and replaced with '00944' to derive the PSTN

   Mapped Calls

      The mapped method offers maximum flexibility in that:

         The PSTN number can exceed 15 digits.

         The X.25 NUA and PSTN number can be totally different.

      The problem with mapped calls is administrative.  IBM mainframes
      can't handle X.25 over ISDN at all, let alone support mapping.
      For the mainframe solution to work, an external X.25/ISDN router
      box is required and it is the responsibility of the external box
      to provide any mapping necessary.

      This means that any changes or addition of OFTP partners over ISDN
      will require access to the computer room or special configuration
      equipment to change the tables inside the external X.25/ISDN
      router box.
Top   ToC   RFC5024 - Page 127

D.4.3. Receiving a Call

We have seen from the previous section that the called X.25 NUA from an ISDN incoming call may vary considerably. If ISDN/X.25 is confined to a national boundary, then such variation will not be so great as most calls will have matching called X.25 NUA and PSTN numbers. X.25 switches and X.25 adapters normally route/accept/reject calls based upon their X.25 called NUA. In particular, routing is made upon the X.25 called NUA subaddress. To derive this subaddress, there are 2 methods: 1) the last 'n' digits are analysed. 2) the base X.25 NUA of the line is removed from the called NUA. For example, if the called X.25 NUA is 23422120017010 and the PSDN subscriber NUA is 234221200170, then the subaddress derived from subtraction is 10. Obviously, the second method will not work if the incoming NUA varies. ISDN Features ISDN, like X.25, has a core set of features that are then enriched with options. In the original OFTP X.25 specification, it was decided that the Q-bit and D-bit options were not common to all networks or applications; they were therefore positively excluded from the specification. It is proposed that apart from the core ISDN features necessary to establish a call, no other features be used. Subaddressing There are two forms of ISDN subaddressing, overdialled and specific. The overdial method allows an ISDN number to be artificially extended. A typical case would be where a private exchange has been installed in a larger company. Assume that the base number is 394023 and the computer is on internal extension 1234, then by specifying an ISDN number of 3940231234, direct access may be made to the internal extension.
Top   ToC   RFC5024 - Page 128
    The problem with this method is that it extends to called number and
    may, especially for international access, exceed the ISDN numbering
    limits between countries.

    The other method of subaddressing is where a discrete subaddress is
    placed in a specific field in the ISDN call setup.

    The problem with this method, is that it requires the caller to
    place the subaddress in the ISDN call setup.  Not all ISDN
    implementations will allow this insertion.

    In conclusion, subaddressing of any kind should be avoided.

D.4.4. Logical Channel Assignment

An X.25 dataline will have associated with it a number of logical channels. The number of channels is a part of the agreement between the PTT and the subscriber. The number of channels subscribed to is important; call failure and similar problems will result if the number of logical channels defined at the two remote ends are different. If a DTE makes a call out, then the highest defined logical channel number will be selected. If the remote Data Communications Equipment (DCE) does not have the same number of logical channels defined, then an invalid logical channel is being used from the perspective of the recipient DCE and the call will be rejected.

D.4.5. Facilities Negotiation

In the PSPDN environment, it is possible to subscribe to negotiation of window size and packet size. Although this negotiation requested by the originator's DTE may be propagated to the remote DTE at the discretion of the originator's DCE, it is a local responsibility between the DTE and DCE pair. In the ISDN scenario where it is a DTE-DTE type connection, the window size and packet size may be left at the default value and consequently the values may be omitted from the call request. If no values are specified, then it is vital that both DTEs have configured themselves to the recommended defaults. The symptom of a window size mismatch is a hang situation without any informational error codes.
Top   ToC   RFC5024 - Page 129
    The symptoms of a packet size mismatch could work in some scenarios,
    but would otherwise issue error codes indicating invalid packet

   Window Size

      The CCITT X.25 window size has a default value of '2', although
      subscribers may have other default window sizes, e.g., '7', by
      virtue of agreement with the PTT.

      Window size negotiation can be explicitly requested by specifying
      the requested window size in the Facilities fields in the Call
      Request packet.

   Packet Size

      The CCITT X.25 packet size has a default value of '128' octets,
      although subscribers may have other default values, e.g., '1024',
      agreed with the PTT.

D.4.6. ISDN Call Setup

The initial setup of an ISDN call is initiated with the transmission of a Q.931 SETUP command. Apart from requesting that a call be established, the SETUP command can optionally carry information about the calling party, the called party, routing information, the type of circuit required (e.g., voice or data), and information about the protocols that are requested to be established. Setup Parameters: Bearer capability Information transfer and access attributes Called Party number Destination's network address Called Party subaddress Destination's complete address Calling Party number Source's network address Low-layer compatibility Layer 1-3 indication High-layer compatibility Layer 4-7 indication
Top   ToC   RFC5024 - Page 130

D.4.7. Homologation Issues

Homologation procedures were adopted and vigorously enforced by the PTTs with respect to the quality and conformance of communications equipment connected to the services provided by the PTTs. In particular, commercial X.25 products had to be tested and approved before they could be connected to the PTTs' PSPDN. The advantage of this to the subscriber was that there was very little chance of the approved equipment not working. With ISDN, similar approval standards are still enforced. So the subscriber has the same confidence in their ISDN equipment. Wrong, the ISDN equipment itself is approved, but the X.15 protocol that operates on top of ISDN is now outside of the scope of approval services. This means that quality of conformance to standards of X.25 over ISDN is subject to the variable quality procedures within the various ISDN equipment manufacturers. Although it is likely that commercial reputation will place pressure upon the manufacturers with a programming bug to correct such errors, it still requires the subscribers that do not communicate well to put time and effort into finding the party with the error. So far, tests have shown a number of subtle errors, such as timing problems, that have taken many days to find, prove, and fix.

D.4.8. Growth

Primary Rate Access If a user decides to plan for growth from the beginning, then the Primary Rate Access has apparent financial benefits. Such apparent savings are usually lost due to the increased cost of user hardware to support such an interface. The BRI for data usage is very common and cards/adapters are low in cost, whereas the PRI cards/adapters are few and far between and consequently highly priced. Basic Rate Access One way to grow with ISDN is to buy multiple BRI lines, increasing slowly in units of 2 x B channels. The PTTs will be able to provide the same subscriber number for all the lines provided in a similar way to the traditional hunting group associated with PSTN type working.
Top   ToC   RFC5024 - Page 131

D.4.9. Performance

The obvious benefit of ISDN is speed; unfortunately, the majority of computer systems in use today have a finite amount of computing power available. The attachment of multiple active high-speed communication lines used in file transfer mode could take a significant amount of CPU resource to the detriment of other users on the system. Connecting an ISDN line with the default 2 B channels to your computer using an X.21 interface is going to give a consistent 64 Kb throughput only if one of the B channels is active at any one time. If there are two 64 Kb channels active and contending for a single 64 Kb X.21 interface, then effective throughput will be reduced significantly to just over 50%. Mainframe issues: Users with a mainframe front-end are also going to find cost an issue. The scanners that scan the communications interfaces are based upon aggregate throughput. A 64 Kb interface takes up a lot of cycles. Determining 'DTE' or 'DCE' Characteristics The following section is an extract from the ISO/IEC 8208 (International Standards Organization, International Electrotechnical Commission) (1990-03-15) standard, which is an ISO extension of the CCITT X.25 standard. The restart procedure can be used to determine whether the DTE acts as a DCE or maintains its role as a DTE with respect to the logical channel selection during Virtual Call establishment and resolution of Virtual Call collision. When prepared to initialise the Packet Layer, the DTE shall initiate the restart procedure (i.e., transmit a RESTART REQUEST packet). The determination is based on the response received from the data exchange equipment (DXE) as outlined below. a) If the DTE receives a RESTART INDICATION packet with a restarting cause code that is not 'DTE Originated' (i.e., it came from a DCE), then the DTE shall maintain its role as a DTE.
Top   ToC   RFC5024 - Page 132
     b) If the DTE receives a RESTART INDICATION packet with a
        restarting cause code of 'DTE Originated' (i.e., it came from
        another DTE), then the DTE shall confirm the restart and act as
        a DCE.

     c) If the DTE receives a RESTART INDICATION packet with a
        restarting cause code of 'DTE Originated' (i.e., it came from
        another DTE) and it does not have an unconfirmed RESTART REQUEST
        packet outstanding (i.e., a restart collision), then the DTE
        shall consider this restart procedure completed but shall take
        no further action except to transmit another RESTART REQUEST
        packet after some randomly chosen time delay.

     d) If the DTE issues a RESTART REQUEST packet that is subsequently
        confirmed with a RESTART CONFIRMATION packet, then the DTE shall
        maintain its role as a DTE.


This document draws extensively on revision 1.4 of the ODETTE File Transfer Specification [OFTP]. Many people have contributed to the development of this protocol and their work is hereby acknowledged.

Normative References

[CMS-Compression] Gutmann, P., "Compressed Data Content Type for Cryptographic Message Syntax (CMS)", RFC 3274, June 2002. [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004. [ISO-646] International Organisation for Standardisation, ISO Standard 646:1991, "Information technology -- ISO 7-bit coded character set for information interchange", 1991. [PKCS#1] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003. [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006. [UTF-8] Yergeau, F., "UTF-8, A Transformation Format of ISO 10646", STD 63, RFC 3629, November 2003.
Top   ToC   RFC5024 - Page 133
   [ZLIB]     Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format
              Specification version 3.3", RFC 1950, May 1996.

Informative References

[ISO-6523] International Organisation for Standardisation, ISO Standard 6523:1984, "Data interchange -- Structures for the identification of organisations", 1984. [OFTP] Organisation for Data Exchange by Tele Transmission in Europe, Odette File Transfer Protocol, Revision 1.4, April 2000. [FTP] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985. [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RIME] Coleridge, Samuel Taylor, "The Rime of the Ancient Mariner", 1817. [X.509] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. [RFC3850] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling", RFC 3850, July 2004.
Top   ToC   RFC5024 - Page 134

ODETTE Address

The ODETTE File Transfer Protocol is a product of the Technology Committee of Odette International. The Technology Committee can be contacted via the ODETTE Central Office: ODETTE INTERNATIONAL Limited Forbes House Halkin Street London SW1X 7DS United Kingdom Phone: +44 (0)171 344 9227 Fax: +44 (0)171 235 7112 EMail: URL:

Author's Address

Ieuan Friend Data Interchange Plc Rhys House The Minerva Business Park Lynchwood Peterborough PE2 6FT United Kingdom Phone: +44 (0)1733 371 311 EMail:
Top   ToC   RFC5024 - Page 135
Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78 and at, and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on an

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at