RFC 5024
ODETTE File Transfer Protocol 2.0
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.
. 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
4347267266266666672467666720046626627767767626662662767662002472
4F9409301E01E395E40D129E52CDA1E4085034F005480FE50F6048255EDA2290
t?hy long grey beard and glittering eye,..Now wherefore stopp'st
7367266662676726667626662666776766626762004672766766676277677277
4F890CFE70725902512401E407C944529E70595CDAEF70785256F25034F00734
?thou me?...."The Bridegroom's doors are opened wide,..And I am
2376672663000025662476666766627266677267626766662766620046624266
0F48F50D5FDADA248502294572FFD7304FF2301250F05E5407945CDA1E40901D
?next of kin;..The guests are met, the feast is set:..May'st he
2366772662666300566267677726762667227662666772672767300467277266
0FE5840F60B9EBDA485075534301250D54C04850651340930354ADAD19734085
a?r the merry din."....He holds him with his skinny hand,.."Ther
6372766266777266622000046266667266627676266727666672666620025667
1F204850D5229049EE2DADA8508FC43089D07948089303B9EE9081E4CDA24852
e? was a ship," quoth he..."Hold off! unhand me, grey-beard loon
6327672627667222776762662002466626662276666626622676726667626666
5F07130103890C2015F48085EDA28FC40F66105E81E40D5C07259D251240CFFE
!?"..Eftsoons his hand dropt he.....He holds him with his glitte
2320046776667266726666267677266200004626666726662767626672666776
1F2DA5643FFE30893081E4042F04085EDADA8508FC43089D07948089307C9445
r?ing eye--..The Wedding-Guest stood still,..And listens like a
7366626762200566256666662476772776662776662004662667766726666262
2F9E70595DDDA485075449E7D75534034FF40349CCCDA1E40C9345E30C9B5010
t?hree years; child:..The Mariner hath his will.....The Wedding-
7367662766773266666300566246766672667626672766620000566256666662
4F8255095123B0389C4ADA4850D129E52081480893079CCEDADA485075449E7D
G?uest sat on a stone:..He cannot chuse but hear;..And thus spak
4376772767266262776663004626666672667762677266673004662767727766
7F553403140FE01034FE5ADA85031EEF4038535025408512BDA1E4048530301B
e? on that ancient man,..The bright-eyed Mariner.....The ship wa
6326627667266666672666200566267666726766246766672000056627667276
5F0FE0481401E395E40D1ECDA4850229784D59540D129E52EDADA48503890071
s? cheered, the harbour cleared,..Merrily did we drop..Below the
7326666766227662667667726666766200467766726662762676700466672766
3F03855254C048508122F5203C51254CDAD5229C90494075042F0DA25CF70485
.kirk, below the hill,..Below the light-house top...
2B667622666672766266662004666727662666672667762767200
03B92BC025CF70485089CCCDA25CF704850C9784D8F53504F0EDA
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
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.
(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).
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 |
| SPECIAL LOGIC PROCESSING |
|------------------------------| <==== 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.
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.
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.
TIMER T2 - INTER CHARACTER TIME OUT (DEFAULT = 7 SECONDS):
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.
TIMER T3 - DATA CARRIER TEMPORARY LOSS (DEFAULT = 1 SECOND):
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.
(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 |
+-------------------------+
(2) CORRUPT TERMINATION (C/R)
This situation manifests itself as an extended period of
synchronisation with no activity. The T2 timer will detect this
condition.
(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 |
+-------+
Exchange Buffer Resent
+-------------------------+
| S | B | | B | C |
-----| T | S | CEB | C | / |-----> Sync
| X | N | | S | R |
+-------------------------+
(3) BAD DATA
(4) BAD BCS (BLOCK CHECK SUM)
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 |
+-------------------------+
(5) BAD BLOCK SEQUENCE NUMBER (BSN)
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.
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
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
flip-flop.
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.
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
character.
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.
. 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,
respectively.
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))
NEXT:
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))
NEXT:
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
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
internationally.
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.
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.
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.
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
recommendation.
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.
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
connection.
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
obsolescence.
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.
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.
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 PerformanceD.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.
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.
Such variation of X.25 NUA, in particular the changing prefix, can
be difficult to be accommodated by X.25 routing logic in many
products.
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
number.
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.
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.
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.
The symptoms of a packet size mismatch could work in some scenarios,
but would otherwise issue error codes indicating invalid packet
sizes.
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
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.
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.
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.
Acknowledgements
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.
[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.
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: info@odette.org URL: http://www.odette.orgAuthor'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: ieuan.friend@dip.co.uk
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 www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 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 http://www.ietf.org/ipr. 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 ietf-ipr@ietf.org.