RFC 2204
ODETTE File Transfer Protocol
4. Protocol Specification 4.1 Overview The ODETTE-FTP protocol is divided into five operating phases. Start Session Start File Data Transfer End File End Session After the End File phase an ODETTE-FTP entity may enter a new Start File phase or terminate the session via the End Session phase. ODETTE-FTP peers communicate by sending and receiving messages in Exchange Buffers via the Network Service. Each Exchange Buffer contains one of the following commands. SSRM Start Session Ready Message SSID Start Session SFID Start File SFPA Start File Positive Answer SFNA Start File Negative Answer DATA Data CDT Set Credit EFID End File EFPA End File Positive Answer EFNA End File Negative Answer ESID End Session CD Change Direction EERP End to End Response RTR Ready To Receive The remainder of this section describes the protocol flows. Section five details the command formats. 4.2 Start Session Phase The Start Session phase is entered immediately after the network connection has been established. 4.2.1 Entity Definition The ODETTE-FTP entity that took the initiative to establish the network connection becomes the Initiator. It's peer becomes the Responder.
4.2.2 Protocol Sequence The first message must be sent by the Responder. 1. Initiator <-------------SSRM -- Responder Ready Message -- SSID ------------> Identification <------------ SSID -- Identification 4.3 Start File Phase 4.3.1 Entity Definition The Initiator from the Start Session phase is designated the Speaker while the Responder becomes the Listener. The roles are reversed by the Speaker sending a Change Direction command to the Listener. 4.3.2 Protocol Sequence 1. Speaker -- SFID ------------> Listener Start File <------------ SFPA -- Answer YES 2. Speaker -- SFID ------------> Listener Start File <------------ SFNA -- Answer NO Go To 1 Note: The User Monitor should take steps to prevent a loop situation occurring. 2. Speaker -- CD --------------> Listener Change Direction Listener <------------ EERP -- Speaker End to End Response -- RTR -------------> Ready to Receive <------------ SFID -- Start File 4.3.3 Restart Facilities The Start File command includes a count allowing the restart of an interrupted transmission to be negotiated. If restart facilities are not available the restart count must be set to zero. The sender will start with the lowest record count + 1. 4.3.4 Broadcast Facilities The destination in a Start File command can be specified as follows. 1. An explicitly defined destination.
2. A group destination that allows an intermediate location to
broadcast the Virtual File to multiple destinations.
The Listener will send a negative answer to the Speaker when the
destination is not known.
4.3.5 Priority
The prioritisation of files for transmission is left to the local
implementation. To allow some flexibility, a change direction
mechanism is available in the End File phase.
4.3.6 End To End Response (EERP)
The End to End Response (EERP) command notifies the originator of a
Virtual File that it has been successfully delivered to it's final
destination. This allows the originator to perform house keeping
tasks such as deleting copies of the delivered data.
A Response Command must be sent from the location performing the
final processing or distribution of the data to the originator. The
Response is mandatory and may be sent in the same or in any
subsequent session.
When an intermediate location broadcasts or distributes a Virtual
File it must receive a Response command from all the locations to
which it forwarded the data before sending it's own Response. This
ensures that the Response received by the Virtual File's originator
accounts for all the destination locations. An intermediate location
therefore needs to track the status of files it processes over time.
Example: Point to Point
Location A sends file Ba to Location B which will send an EERP to
location A after it successfully receives the file.
o----------o o-----------o
| Loc. A |----------- S1 ---------->| Loc. B |
| | | |
| [Ba] |<---------- R2 -----------| [Ba] |
+----------o o-----------o
Key:
S - File Transfer R - Response EERP [Ba] - File for B from A
Example: Data distribution
Location A sends a Virtual File containing data for distribution to
locations B and C via clearing centres E1 and E2. Clearing centre E1
must wait for a response from E2 (for file Ba) and location C before
it sends it's response, R8, to location A. Clearing centre E2 can
only send response R7 to E1 when location B acknowledges file Ba with
response R6.
o---------o o---------o o---------o o---------o
| Loc. A |-- S1 ->| Loc. E1 |-- S2 ->| Loc. E2 |-- S5 ->| Loc. B |
| | | | | | | |
| [Ba,Ca] |<- R8 --| [Ba,Ca] |<- R7 --| [Ba] |<- R6 --| [Ba] |
o---------o o---------o o---------o o---------o
A |
| | o---------o
| +----- S3 ->| Loc. C |
| | |
+--------- R4 --| [Ca] |
o---------o
Example: Data collection
Locations A and B send files Ca and Cb to clearing centre E1 which
forwards both files to location C in a single Virtual File. When it
receives response R4 from C, clearing centre E1 sends response R5 to
location A and R6 to location B.
o---------o o---------o o---------o
| Loc. A |-- S1 ->| Loc. E1 |-- S3 ->| Loc. C |
| | | | | |
| [Ca] |<- R5 --| [Ca,Cb] |<- R4 --| [Ca,Cb] |
o---------o o---------o o---------o
A |
o---------o | |
| Loc. B |-- S2 -----+ |
| | |
| [Cb] |<- R6 ---------+
o---------o
4.3.7 Ready To Receive Command (RTR)
In order to avoid congestion between two adjacent nodes caused by a
continuous flow of EERP's, a Ready To Receive (RTR) command is
provided. The RTR acts as an EERP acknowledgement for flow control
but has no end-to-end significance.
Speaker -- EERP ------------> Listener End to End Response
<------------- RTR -- Ready to Receive
-- EERP ------------> End to End Response
<------------- RTR -- Ready to Receive
-- SFID ------------> Start File
or
-- CD --------------> Exchange the turn
After sending an EERP, the Speaker must wait for an RTR before
sending any other commands.
4.4 Data Transfer Phase
Virtual File data flows from the Speaker to the Listener during the
Data Transfer phase which is entered after the Start File phase.
4.4.1 Protocol Sequence
To avoid congestion at the protocol level a flow control mechanism is
provided via the Credit (CDT) command.
A Credit limit is negotiated in the Start Session phase, this
represents the number of Data Exchange Buffers that the Speaker may
send before it is obliged to wait for a Credit command from the
Listener.
The available credit is initially set to the negotiated value by the
Start File positive answer, which acts as an implicit Credit command.
The Speaker decreases the available credit count by one for each data
buffer sent to the Listener.
When the available credit is exhausted, the Speaker must wait for a
Credit command from the Listener otherwise a protocol error will
occur and the session will be aborted.
The Listener should endeavour to send the Credit command without
delay to prevent the Speaker blocking.
1. Speaker -- SFID ------------> Listener Start File
<------------ SFPA -- Answer YES
2. If the Credit Value is set to 2
Speaker -- Data ------------> Listener Start File
-- Data ------------>
<------------- CDT -- Set Credit
-- Data ------------>
-- EFID ------------> End File
4.5 End File Phase
4.5.1 Protocol Sequence
The Speaker notifies the Listener that it has finished sending a
Virtual File by sending an End File (EFID) command. The Listener
replies with a positive or negative End File command and has the
option to request a Change Direction command from the Speaker.
1. Speaker -- EFID ------------> Listener End File
<------------ EFPA -- Answer YES
2. Speaker -- EFID ------------> Listener End File
<------------ EFPA -- Answer YES + CD
-- CD --------------> Change Direction
Listener <------------ EERP -- Speaker End to End Response
-------------- RTR -> Ready to Receive
Go to Start File Phase
3. Speaker -- EFID ------------> Listener End File
<------------ EFNA -- Answer NO
4.6 End Session Phase
4.6.1 Protocol Sequence
The Speaker terminates the session by sending an End Session (ESID)
command.
1. Speaker -- EFID ------------> Listener End File
<------------ EFPA -- Answer YES
-- CD --------------> Change Direction
Listener <------------ ESID -- Speaker End Session
4.7 Problem Handling Error detection and handling should be done as close as possible to the problem. This aids problem determination and correction. Each layer of the reference model is responsible for it's own error handling. ODETTE-FTP can detect protocol errors through the construction of it's state machine, and uses activity timers to detect session hang conditions. These mechanisms are separate from the End to End controls. 4.7.1 Protocol Errors If a protocol error occurs the session will be terminated and application activity aborted. Both locations enter the IDLE state. 4.7.2 Timers To protect against application and network hang conditions ODETTE-FTP uses activity timers for all situations where a response is required. The timers and actions to be taken if they expire are described in section 8, the Protocol State Machine. 4.7.3 Clearing Centres The use of clearing centres introduces the possibility of errors occurring as a result of data processing activities within the centre. Such errors are not directly related to ODETTE-FTP or the communication network and are therefore outside the scope of this specification. 5. Commands and Formats ODETTE-FTP entities communicate via Exchange Buffers. The Command Exchange Buffers are described below. Virtual File data is carried in Data Exchange Buffers which are described in Section 6. 5.1 Conventions 5.1.1 Representation unit: The basic unit of information is an octet, containing eight bits. 5.1.2 Values and Characters: The ISO 646 IRV 7-bit coded character set [ISO-646] is used to encode constants and strings within command exchange buffers.
5.2 Commands A Command Exchange Buffer contains a single command starting at the beginning of the buffer. Commands and data are never mixed within an Exchange Buffer. Each command has a fixed length and can not be compressed. Components: 1. Command identifier: The first octet of an Exchange Buffer is the Command Identifier and defines the format of the buffer. 2. Parameter(s): Command parameters are stored in fixed fields within a Command Exchange Buffer. All values are required. 5.3 Command Formats The ODETTE-FTP commands are described below using the following definitions. Position (Pos.) Field offset within the command exchange buffer, relative to a zero origin. Field The name of the field. Description A description of the field. Format F - A field containing fixed values. All allowable values for the field are enumerated in the command definition. V - A field with variable values within a defined range. For example the SFIDFSIZ field may contain any integer value between 0000000 and 9999999. X(n) - An alphanumeric field of length n octets.
9(n) - A numeric field of length n octets.
All attributes are in character format.
A String contains alphanumeric characters from the following set:
The numerals: 0 to 9
The upper case letters: A to Z
The following special set: / - . & ( ) space.
Space is not allowed as an embedded character.
Numeric fields are always right justified and left padding with
zeros must be done when needed.
5.3.1 SSRM - Start Session Ready Message
o-------------------------------------------------------------------o
| SSRM Start Session Ready Message |
| |
| Start Session Phase Initiator <---- Responder |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | SSRMCMD | SSRM Command, 'I' | F X(1) |
| 1 | SSRMMSG | Ready Message, 'ODETTE FTP READY ' | F X(17) |
| 18 | SSRMCR | Carriage Return | F X(1) |
o-------------------------------------------------------------------o
SSRMCMD Command Code Character
Value: 'I' SSRM Command identifier.
SSRMMSG Ready Message String(17)
Value: 'ODETTE FTP READY '
SSRMCR Carriage Return Character
Value: Character with hex value '0D' or '8D'.
5.3.2 SSID - Start Session o-------------------------------------------------------------------o | SSID Start Session | | | | Start Session Phase Initiator <---> Responder | |-------------------------------------------------------------------| | Pos | Field | Description | Format | |-----+-----------+---------------------------------------+---------| | 0 | SSIDCMD | SSID Command 'X' | F X(1) | | 1 | SSIDLEV | Protocol Release Level | F 9(1) | | 2 | SSIDCODE | Initiator's Identification Code | V X(25) | | 27 | SSIDPSWD | Initiator's Password | V X(8) | | 35 | SSIDSDEB | Exchange Buffer Size | V 9(5) | | 40 | SSIDSR | Send / Receive Capabilities (S/R/B) | F X(1) | | 41 | SSIDCMPR | Compression Indicator (Y/N) | F X(1) | | 42 | SSIDREST | Restart Indicator (Y/N) | F X(1) | | 43 | SSIDSPEC | Special Logic Indicator (N) | F X(1) | | 44 | SSIDCRED | Credit | V 9(3) | | 47 | SSIDRSV1 | Reserved | F X(5) | | 52 | SSIDUSER | User Data | V X(8) | | 60 | SSIDCR | Carriage Return | F X(1) | o-------------------------------------------------------------------o SSIDCMD Command Code Character Value: 'X' SSID Command identifier. SSIDLEV Protocol Release Level Numeric(1) Value: '1' ODETTE-FTP protocol release level 1. Future release levels will have higher numbers. The protocol release level is negotiable, with the lowest level being selected. SSIDCODE Initiator's Identification Code String(25) Format: See Identification Code (Section 5.4) Uniquely identifies the Initiator (sender) participating in the ODETTE-FTP session. SSIDPSWD Password String(8) Key to authenticate the sender. Assigned by bilateral agreement.
SSIDSDEB Exchange Buffer Size Numeric(5)
Minimum: 128
Maximum: 99999
The length, in octets, of the largest Exchange Buffer that
can be accepted by the location. The length includes the
command octet but does not include the Stream Transmission
Header.
After negotiation the smallest size will be selected.
SSIDSR Send / Receive Capabilities Character
Value: 'S' Location can only send files.
'R' Location can only receive files.
'B' Location can both send and receive files.
Sending and receiving will be serialised during the
session, so parallel sessions will not take place.
An error occurs if adjacent locations both specify the send
or receive capability.
SSIDCMPR Compression Indication Character
Value: 'Y' The location can handle compressed data.
'N' The location can not handle compressed data.
Compression is only used if supported by both locations.
The compression mechanism is described in Section 6.2
SSIDREST Restart Indication Character
Value: 'Y' The location can handle the restart of a partially
transmitted file.
'N' The location can not restart a file.
SSIDSPEC Special Logic Indication Character
Value: 'N' Only valid value for TCP.
The Special Logic extensions are only useful in an X.25
environment and are not supported for TCP/IP.
SSIDCRED Credit Numeric(3)
Maximum: 999
The number of consecutive Data Exchange Buffers sent by the
Speaker before it must wait for a Credit (CDT) command from
the Listener.
The credit value is only applied to Data flow in the Data
Transfer phase.
The Speaker's available credit is initialised to SSIDCRED
when it receives a Start File Positive Answer (SFPA)
command from the Listener. It is zeroed by the End File
(EFID) command.
After negotiation, the smallest size must be selected in
the answer of the Responder, otherwise a protocol error
will abort the session.
Negotiation of the "credit-window-size" parameter.
Window Size m -- SSID ------------>
<------------ SSID -- Window Size n
(n less or equal m)
Note: negotiated value will be "n".
SSIDRSV1 Reserved String(5)
This field is reserved for future use.
SSIDUSER User Data String(8)
May be used by the ODETTE-FTP in any way. If unused it
should be initialised to spaces. It is expected that a
bilateral agreement exists as to the meaning of the data.
SSIDCR Carriage Return Character
Value: Character with hex value '0D' or '8D'.
5.3.3 SFID - Start File o-------------------------------------------------------------------o | SFID Start File | | | | Start File Phase Speaker ----> Listener | |-------------------------------------------------------------------| | Pos | Field | Description | Format | |-----+-----------+---------------------------------------+---------| | 0 | SFIDCMD | SFID Command, 'H' | F X(1) | | 1 | SFIDDSN | Virtual File Dataset Name | V X(26) | | 27 | SFIDRSV1 | Reserved | F X(9) | | 36 | SFIDDATE | Virtual File Date stamp, (YYMMDD) | V X(6) | | 42 | SFIDTIME | Virtual File Time stamp, (HHMMSS) | V X(6) | | 48 | SFIDUSER | User Data | V X(8) | | 56 | SFIDDEST | Destination | V X(25) | | 81 | SFIDORIG | Originator | V X(25) | | 106 | SFIDFMT | File Format, (F/V/U/T) | F X(1) | | 107 | SFIDLRECL | Maximum Record Size | V 9(5) | | 112 | SFIDFSIZ | File Size, 1K blocks | V 9(7) | | 119 | SFIDREST | Restart Position | V 9(9) | o-------------------------------------------------------------------o SFIDCMD Command Code Character Value: 'H' SFID Command identifier. SFIDDSN Virtual File Dataset Name String(26) Dataset name of the Virtual File being transferred, assigned by bilateral agreement. No general structure is defined for this attribute. See Virtual Files - Identification (Section 1.5.2) SFIDRSV1 Reserved String(9) This field is reserved for future use. SFIDDATE Virtual File Date stamp String(6) Format: 'YYMMDD' 6 decimal digits representing the year, month and day respectively [ISO-8601]. Date stamp assigned by the Virtual File's Originator indicating when the file was made available for transmission. See Virtual Files - Identification (Section 1.5.2)
SFIDTIME Virtual File Time stamp String(6)
Format: 'HHMMSS' 6 decimal digits representing hours, minutes
and seconds respectively [ISO-8601].
Time stamp assigned by the Virtual File's Originator
indicating when the file was made available for
transmission.
See Virtual Files - Identification (Section 1.5.2)
SFIDUSER User Data String(8)
May be used by the ODETTE-FTP in any way. If unused it
should be initialised to spaces. It is expected that a
bilateral agreement exists as to the meaning of the data.
SFIDDEST Destination String(25)
Format: See Identification Code (Section 5.4)
The Final Recipient of the Virtual File.
This is the location that will look into the Virtual File
content and perform mapping functions. It is also the
location that creates the End to End Response (EERP)
command for the received file.
SFIDORIG Originator String(25)
Format: See Identification Code (Section 5.4)
Originator of the Virtual File.
It is the location that created (mapped) the data for
transmission.
SFIDFMT File Format Character
Value: 'F' Fixed format binary file.
'V' Variable format binary file.
'U' Unstructured binary file.
'T' Text
Virtual File format. Used to calculate the restart
position. (Section 1.5.3)
SFIDLRECL Maximum Record Size Numeric(5)
Maximum: 99999
Length in octets of the longest logical record which may be
transferred to a location. Only user data is included.
If SFIDFMT is 'T' or 'U' then this attribute must be set to
'00000'.
SFIDFSIZ File Size Numeric(7)
Maximum: 9999999
Space in 1K (1024 octet) blocks required at the Originator
location to store the Virtual File.
This parameter is intended to provide only a good estimate
of the Virtual File size.
SFIDREST Restart Position Numeric(9)
Maximum: 999999999
Virtual File restart position.
The count represents the:
- Record Number if SSIDFMT is 'F' or 'V'.
- File offset in 1K (1024 octet) blocks if SSIDFMT is
'U' or 'T'.
The count will express the transmitted user data (i.e.
before compression, header not included).
After negotiation between adjacent locations,
retransmission will start at the lowest value.
5.3.4 SFPA - Start File Positive Answer
o-------------------------------------------------------------------o
| SFPA Start File Positive Answer |
| |
| Start File Phase Speaker <---- Listener |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | SFPACMD | SFPA Command, '2' | F X(1) |
| 1 | SFPAACNT | Answer Count | V 9(9) |
o-------------------------------------------------------------------o
SFPACMD Command Code Character
Value: '2' SFPA Command identifier.
SFPAACNT Answer Count Numeric(9)
The Listener must enter a count lower or equal to the
restart count specified by the Speaker in the Start File
(SFID) command. The count expresses the received user
data. If restart facilities are not available, a count of
zero must be specified.
5.3.5 SFNA - Start File Negative Answer
o-------------------------------------------------------------------o
| SFNA Start File Negative Answer |
| |
| Start File Phase Speaker <---- Listener |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | SFNACMD | SFNA Command, '3' | F X(1) |
| 1 | SFNAREAS | Answer Reason | F 9(2) |
| 3 | SFNARRTR | Retry Indicator, (Y/N) | F X(1) |
o-------------------------------------------------------------------o
SFNACMD Command Code Character
Value: '3' SFNA Command identifier.
SFNAREAS Answer Reason Numeric(2)
Value: '01' Invalid filename.
'02' Invalid destination.
'03' Invalid origin.
'04' Storage record format not supported.
'05' Maximum record length not supported.
'06' File size is too big.
'10' Invalid record count.
'11' Invalid byte count.
'12' Access method failure.
'13' Duplicate file.
'99' Unspecified reason.
Reason why transmission can not proceed.
SFNARRTR Retry Indicator Character
Value: 'N' Transmission should not be retried.
'Y' The transmission may be retried latter.
This parameter is used to advise the Speaker if it should
retry at a latter point in time due to a temporary
condition at the Listener site, such as a lack of storage
space. It should be used in conjunction with the Answer
Reason code (SFNAREAS).
An invalid file name error code may be the consequence of a
problem in the mapping of the Virtual File on to a real
file. Such problems cannot always be resolved immediately.
It it therefore recommended that when a SFNA with Retry = Y
is received the User Monitor attempts to retransmit the
relevant file in a subsequent session.
5.3.6 DATA - Data Exchange Buffer
o-------------------------------------------------------------------o
| DATA Data Exchange Buffer |
| |
| Data Transfer Phase Speaker ----> Listener |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | DATACMD | DATA Command, 'D' | F X(1) |
| 1 | DATABUF | Data Exchange Buffer payload | V X(n) |
o-------------------------------------------------------------------o
DATACMD Command Code Character
Value: 'D' DATA Command identifier.
DATABUF Data Exchange Buffer payload String(n)
Variable length buffer containing the data payload. The
Data Exchange Buffer is described in Section 6.
5.3.7 CDT - Set Credit o-------------------------------------------------------------------o | CDT Set Credit | | | | Data Transfer Phase Speaker <---- Listener | |-------------------------------------------------------------------| | Pos | Field | Description | Format | |-----+-----------+---------------------------------------+---------| | 0 | CDTCMD | CDT Command, 'C' | F X(1) | | 1 | CDTRSV1 | Reserved | F X(2) | o-------------------------------------------------------------------o CDTCMD Command Code Character Value: 'C' CDT Command identifier. CDTRSV1 Reserved String(2) This field is reserved for future use. 5.3.8 EFID - End File o-------------------------------------------------------------------o | EFID End File | | | | End File Phase Speaker ----> Listener | |-------------------------------------------------------------------| | Pos | Field | Description | Format | |-----+-----------+---------------------------------------+---------| | 0 | EFIDCMD | EFID Command, 'T' | F X(1) | | 1 | EFIDRCNT | Record Count | V 9(9) | | 10 | EFIDUCNT | Unit Count | V 9(12) | o-------------------------------------------------------------------o EFIDCMD Command Code Character Value: 'T' EFID Command identifier. EFIDRCNT Record Count Numeric(9) Maximum: 999999999 For SSIDFMT 'F' or 'V' the exact record count. For SSIDFMT 'U' or 'T' zeros.
The count will express the real size of the file (before
compression, header not included). The total count is
always used, even during restart processing.
EFIDUCNT Unit Count Numeric(12)
Maximum: 999999999999
Exact number of units (octets) transmitted.
The count will express the real size of the file. The
total count is always used, even during restart processing.
5.3.9 EFPA - End File Positive Answer
o-------------------------------------------------------------------o
| EFPA End File Positive Answer |
| |
| End File Phase Speaker <---- Listener |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | EFPACMD | EFPA Command, '4' | F X(1) |
| 1 | EFPACD | Change Direction Indicator, (Y/N) | F X(1) |
o-------------------------------------------------------------------o
EFPACMD Command Code Character
Value: '4' EFPA Command identifier.
EFPACD Change Direction Indicator Character
Value: 'N' Change direction not requested.
'Y' Change direction requested.
This parameter allows the Listener to request a Change
Direction (CD) command from the Speaker.
5.3.10 EFNA - End File Negative Answer
o-------------------------------------------------------------------o
| EFNA End File Negative Answer |
| |
| End File Phase Speaker <---- Listener |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | EFNACMD | EFNA Command, '5' | F X(1) |
| 1 | EFNAREAS | Answer Reason | F 9(2) |
o-------------------------------------------------------------------o
EFNACMD Command Code Character
Value: '5' EFNA Command identifier.
EFNAREAS Answer Reason Numeric(2)
Value: '01' Invalid filename.
'02' Invalid destination.
'03' Invalid origin.
'04' Storage record format not supported.
'05' Maximum record length not supported.
'06' File size is too big.
'10' Invalid record count.
'11' Invalid byte count.
'12' Access method failure.
'13' Duplicate file.
'99' Unspecified reason.
Reason why transmission can not proceed.
5.3.11 ESID - End Session
o-------------------------------------------------------------------o
| ESID End Session |
| |
| End Session Phase Speaker ----> Listener |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | ESIDCMD | ESID Command, 'F' | F X(1) |
| 1 | ESIDREAS | Reason Code | F 9(2) |
| 3 | ESIDCR | Carriage Return | F X(1) |
o-------------------------------------------------------------------o
ESIDCMD Command Code Character
Value: 'F' ESID Command identifier.
ESIDREAS Reason Code Numeric(2)
Value '00' Normal session termination
'01' Command not recognised
An Exchange Buffer contains an invalid command code
(1st octet of the buffer).
'02' Protocol violation
An Exchange Buffer contains an invalid command for
the current state of the receiver.
'03' User code not known
A Start Session (SSID) command contains an unknown or
invalid Identification Code.
'04' Invalid password
A Start Session (SSID) command contained an invalid
password.
'05' Local site emergency close down
The local site has entered an emergency close down
mode. Communications are being forcibly terminated.
'06' Command contained invalid data
A field within a Command Exchange buffer contains
invalid data.
'07' Exchange Buffer size error
The length of the Exchange Buffer as determined by
the Stream Transmission Header is different to the
length implied by the Command Code.
'08' Resources not available
The request for connection has been denied due to a
resource shortage. The connection attempt should be
retried later.
'09' Time out
'10' Mode or capabilities incompatible
'99' Unspecified Abort code
An error was detected for which no specific code is
defined.
ESIDCR Carriage Return Character
Value: Character with hex value '0D' or '8D'.
5.3.12 CD - Change Direction
o-------------------------------------------------------------------o
| CD Change Direction |
| |
| Start File Phase Speaker ----> Listener |
| End File Phase Speaker ----> Listener |
| End Session Phase Initiator <---> Responder |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | CDCMD | CD Command, 'R' | F X(1) |
o-------------------------------------------------------------------o
CDCMD Command Code Character
Value: 'R' CD Command identifier.
5.3.13 EERP - End to End Response
o-------------------------------------------------------------------o
| EERP End to End Response |
| |
| Start File Phase Speaker ----> Listener |
| End File Phase Speaker ----> Listener |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | EERPCMD | EERP Command, 'E' | F X(1) |
| 1 | EERPDSN | Virtual File Dataset Name | V X(26) |
| 27 | EERPRSV1 | Reserved | F X(9) |
| 36 | EERPDATE | Virtual File Date stamp, (YYMMDD) | V X(6) |
| 42 | EERPTIME | Virtual File Time stamp, (HHMMSS) | V X(6) |
| 48 | EERPUSER | User Data | V X(8) |
| 56 | EERPDEST | Destination | V X(25) |
| 81 | EERPORIG | Originator | V X(25) |
o-------------------------------------------------------------------o
EERPCMD Command Code Character
Value: 'E' EERP Command identifier.
EERPDSN Virtual File Dataset Name String(26)
Dataset name of the Virtual File being transferred,
assigned by bilateral agreement.
No general structure is defined for this attribute.
See Virtual Files - Identification (Section 1.5.2)
EERPRSV1 Reserved String(9)
This field is reserved for future use.
EERPDATE Virtual File Date stamp String(6)
Format: 'YYMMDD' 6 decimal digits representing the year, month
and day respectively [ISO-8601].
Date stamp assigned by the Virtual File's Originator
indicating when the file was made available for
transmission.
See Virtual Files - Identification (Section 1.5.2)
EERPTIME Virtual File Time stamp String(6)
Format: 'HHMMSS' 6 decimal digits representing hours, minutes
and seconds respectively [ISO-8601].
Time stamp assigned by the Virtual File's Originator
indicating when the file was made available for
transmission.
See Virtual Files - Identification (Section 1.5.2)
EERPUSER User Data String(8)
May be used by the ODETTE-FTP in any way. If unused it
should be initialised to spaces. It is expected that a
bilateral agreement exists as to the meaning of the data.
EERPDEST Destination String(25)
Format: See Identification Code (Section 5.4)
Originator of the Virtual File.
This is the location that created (mapped) the data for
transmission.
EERPORIG Originator String(25)
Format: See Identification Code (Section 5.4)
Final Recipient of the Virtual File.
This is the location that will look into the Virtual File
content and perform mapping functions. It is also the
location that creates the EERP for the received file.
5.3.14 RTR - Ready To Receive
o-------------------------------------------------------------------o
| RTR Ready To Receive |
| |
| Start File Phase Initiator <---- Responder |
| End File Phase Initiator <---- Responder |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | RTRCMD | RTR Command, 'P' | F X(1) |
o-------------------------------------------------------------------o
RTRCMD Command Code Character
Value: 'P' RTR Command identifier.
5.4 Identification Code
The Initiator (sender) and Responder (receiver) participating in an
ODETTE-FTP session are uniquely identified by an Identification Code
based on [ISO 6523], Structure for the Identification of
Organisations (SIO). The locations are considered to be adjacent for
the duration of the transmission.
The SIO has the following format.
o-------------------------------------------------------------------o
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | SIOOID | ODETTE Identifier | F X(1) |
| 1 | SIOICD | International Code Designator | V 9(4) |
| 5 | SIOORG | Organisation Code | V X(14) |
| 19 | SIOCSA | Computer Sub-Address | V X(6) |
o-------------------------------------------------------------------o
SIOOID ODETTE Identifier Character
Value: 'O' Indicates ODETTE assigned Organisation Identifier.
Other values may be used for non-ODETTE codes.
SIOICD International Code Designator String(4)
A code forming part of the Organisation Identifier.
SIOORG Organisation Code String(14)
A code forming part of the Organisation Identifier. This
field may contain the letters A to Z, the digits 0 to 9,
apace and hyphen characters.
SIOCSA Computer Sub-Address String(6)
A locally assigned address which uniquely identifies a
system within an organisation (defined by an Organisation
Identifier).
6. ODETTE-FTP Data Exchange Buffer
6.1 Overview
Virtual Files are transmitted by mapping the Virtual File records
into Data Exchange Buffers, the maximum length of which was
negotiated between the ODETTE-FTP entities via the Start Session
(SSID) commands exchanged during the Start Session Phase of the
protocol. The format is based on the Network Independent File
Transfer Protocol [NIFTP].
Virtual File records may be of arbitrary length. A simple
compression scheme is defined for strings of repeated characters.
An example of the use of the Data Exchange Buffer can be found in
Appendix A.
6.2 Data Exchange Buffer Format
For transmission of Virtual File records, data is divided into
Subrecords, each of which is preceded by a one octet Subrecord
Header.
The Data Exchange Buffer is made up of the initial Command character,
o--------------------------------------------------------
| C | H | | H | | H | | /
| M | D | SUBRECORD | D | SUBRECORD | D | SUBRECORD | /_
| D | R | | R | | R | | /
o-------------------------------------------------------
CMD
The Data Exchange Buffer Command Character, 'D'.
HDR
A one octet Subrecord Header defined as follows:
0 1 2 3 4 5 6 7
o-------------------------------o
| E | C | |
| o | F | C O U N T |
| R | | |
o-------------------------------o
Bits
0 End of Record Flag
Set to indicate that the next subrecord is the last
subrecord of the current record.
Unstructured files are transmitted as a single record, in
this case the flag acts as an end of file marker.
1 Compression Flag
Set to indicate that the next subrecord is compressed.
2-7 Subrecord Count
The number of octets in the Virtual File represented by the
next subrecord expressed as a binary value.
For uncompressed data this is simply the length of the
subrecord.
For compressed data this is the number of times that the
single octet in the following subrecord must be inserted in
the Virtual File.
As six bits are available, the next subrecord may
represent between 0 and 63 octets of the Virtual File.
6.3 Buffer Filling Rules
An Exchange Buffer may be any length up to the value negotiated in
the Start Session exchange.
Virtual File records may be concatenated within one Exchange Buffer
or split across a number of buffers.
A subrecord is never split between two Exchange Buffers. If the
remaining space in the current Exchange Buffer is insufficient to
contain the next 'complete' subrecord one of the following strategies
should be used:
1. Truncate the Exchange Buffer, and put the complete
subrecord (preceded by its header octet) in a new Exchange Buffer.
2. Split the subrecord into two, filling the remainder of the
Exchange Buffer with the first new subrecord and starting a new
Exchange Buffer with the second.
A record of length zero may appear anywhere in the Exchange Buffer.
A subrecord of length zero may appear anywhere in the record and/or
the Exchange Buffer.
7. Stream Transmission Buffer (TCP only)
7.1 Introduction
The ODETTE-FTP was originally designed to utilise the ISO Network
Service, specifically the X.25 specification. It relies on the fact
that the network service will preserve the sequence and boundaries of
data units transmitted through the network and that the network
service will pass the length of the data unit to the receiving
ODETTE-FTP. The TCP offers a stream based connection which does not
provide these functions.
In order to utilise the TCP stream without disruption to the existing
ODETTE-FTP a Stream Transmission Buffer (STB) is created by adding a
Stream Transmission Header (STH) to the start of all Command and Data
Exchange Buffers before they are passed to the TCP transport service.
This allows the receiving ODETTE-FTP to recover the original Exchange
Buffers.
STH - Stream Transmission Header
OEB - ODETTE-FTP Exchange Buffer
The Stream Transmission Buffer comprises of a STH and OEB.
o-----+-----------------+-----+--------------------+-----+------
| STH | OEB | STH | OEB | STH | OEB/
o-----+-----------------+-----+--------------------+-----+----
7.2 Stream Transmission Header Format The Stream Transmission Header is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Flags | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version Value: 0001 (binary) Stream Transmission Header version number. Flags Value: 0000 (binary) Reserved for future use. Length Range: 5 - 100003 (decimal) The length of the Stream Transmission Buffer (STH+OEB). The smallest STB is 5 octets consisting of a 4 octet header followed by a 1 octet Exchange Buffer such as a Change Direction (CD) command. The maximum Exchange Buffer length that can be negotiated is 99999 octets (Section 5.3.2) giving a STB length of 100003. The length is expressed as a binary number with the most significant bit on the left. It is expected that implementations of this protocol will follow the Internet robustness principle of being conservative in what is sent and liberal in what is accepted.
(next page on part 3)
