REFERENCE publi . cations

NBSIR 84-2855

Proceedings of the Fifth

LAN-Transport Workshop

NAT L INST. OF STAND & TECH

Aiilab 2 b b r

Report of the Fifth Workshop for Local Area Network

Implementors of the NBS Specifications of the

International Standards Organization Transport

Class 4 Protocol

U.S. DEPARTMENT OF COMMERCE

National Bureau of Standards

Institute for Computer Sciences and Technology

Systems and Network Architecture Division

Washington, DC 20234

March 8 - 9, 1 384

—QC

S. DEPARTMENT OF COMMERCE

-riONAL BUREAU OF STANDARDS

103

,U56

34-2355

1984
1
NATION/1.!. BUREAU OF STANDARDS

LIBRARY

NBSIR 84-2855

PROCEEDINGS OF THE FIFTH

LAN-TRANSPORT WORKSHOP

Report of the Fifth Workshop for Local Area Network

Implementors of the NBS Specifications of the

International Standards Organization Transport

Class 4 Protocol

U.S. DEPARTMENT OF COMMERCE

National Bureau of Standards

Institute for Computer Sciences and Technology

Systems and Network Architecture Division

Washington, DC 20234

March 8 - 9, 1984

U.S. DEPARTMENT OF COMMERCE, Malcolm Baldrige, Secretary

NATIONAL BUREAU OF STANDARDS, Ernest Ambler. Director

Table of Contents

Abstract

1. Participants of the Fifth Workshop 1

2. Opening Remarks 3

3. Sub-Group Status Reports 3

4. FTP Problems and Protocol Refinements 3

5. NAPLPS Demo and Files 4

6. FCOPY 5

7. HIS Demo and Files 5

8. FTP Testing and Schedule 5

9. Common Business

10. Arbitration of Technical Points 7

11. Transport Test Status

ATTACHMENTS

A. Vendor Testing 8

B. Transport Test Scenarios 9

C. Current GM FTP Agreements 11

D. DEC Reference Replies to FTP Implementation Questions 12

E. Honeywell - NBS/NCC Demonstation . 13

F. DEC - Test Protocol Data Unit Sender 15

G. HP - FTP Test Scenarios 27

H. GM - FTP Testing 28

ABSTRACT

The National Bureau of Standards Institute for Computer

Sciences and Technology (ICST) has prepared specifications

for the International Organization for Standardization's

(ISO) Class 4 Transport Protocol. At the request of a number

of companies, ICST organized a workshop series for implementors

of these specifications using local area networking technology.

The first workshop focused on implementation techniques and

strategies so that a multivendor demonstration of these

protocols can occur at a major computer conference in 1984

targeted for the NCC 1984. Primarily the details of CSMA/CD

and Transport Class 4 were discussed and parameters were

selected. A second workshop focused on token bus LANs and

file transfer applications to be run at the trageted 1984

demonstration. Agreements on the specifics of the file

transfer protocol were reached at the third workshop. The

fourth workshop covered futher refinements to the file transfer

protocol, testing procedures, and demonstration details.

This report documents the fifth workshop in the series of

LAN/Transport workshops. The fifth workshop defined the

File Transfer Protocol (FTP) testing schedule and minimum

vendors tests, and made minor adjustments to the FTP specification.

Keywords: communication protocols, computer networks, transport protocol,

file transfer protocol, local area networks.

SUMMARY

This report documents the fifth workshop of the LAN-Transport Workshop

series for implementors of the ICST specification of the ISO Class

4 Transport Protocol over IEEE 802 compatible LANs.

At the fifth workshop vendor dependent minimum FTP tests were

agreed to and an FTP schedule was set. All vendors agreed to

implement the FCOPY utility and supply disk space so that

they can participate in the FTP demonstrations. Refinements to the

file transfer protocol were approved and transport protocol testing

experiences were covered. It was announced that a news worthy

event for the business press would be held in the U.S. and ICL

would make a press release in Europe, both events will be in April.

Fifth LAN-Transport Workshop Attendees

Kenneth Aird

Hewlett Packard (HP)

3404 E. Harmony Road

Ft. Collins, CO 80526

Heajong Ahn

NCR Comten

2700 Snelling Avenue, N.

St. Paul, MN 55113

James C. Berets

BBN, Inc.

10 Moulton Street

Cambridge, MA 02238

Robert Blanc

National Bureau of Standards (NBS)

A231, Technology Bldg.

Washington, D.C. 20234

Sheldon Blauman

Boeing Computer Services (BSC)

P.0. Box 24346, MS 7A-05

Seattle, WA 98124

Laurie Bride

Boeing Computer Services (BCS)

P.0. Box 24346, MS 7F-01

Seattle, WA 98124

Allen D. Brown

Gould, Inc.

6901 W. Sunrise Blvd.

Ft. Lauderdale, FL 33313

Courtney Brown

Foxboro Company

Neponset Street

Foxboro, MA 02035

Bruce Carlson

Honeywell Information Systems (HIS)

P.0. Box 8000 H-20

Phoenix, AZ 85029

Edward Deenihan

General Motors (GM)

GM Technical Center A-MD/39

Warren, MI 48090-9040

Edward Efron

Able Computer

1732 Reynolds Avenue

Irvine, CA 92714

Lawrence Gutter

Charles River Data Systems (CRDS)

983 Concord Street

Framingham, MA 01701

Norton Hall

Charles River Data Systems (CRDS)

983 Concord Street

Framingham, MA 01701

Kern Hardman

Boeing Computer Services (BCS)

P.0. Box 24346, MS 7A-05

Seattle, WA 98124

John F. Heafner

National Bureau of Standards (NBS)

3218, Technology Bldg.

Washington, D. C. 20234

Vadivelu Jeyablan

Ford Motor Company

Room E—116, Scientific Research Bldg.

P.0. Box 2053

Dearborn, MI 48121

Jerry Linn

National Bureau of Standards (NBS)

B212, Technology Bldg.

Washington, D. C. 20234

Jerry-Ann C. Meyer

NBI, Inc.

P.0. Box 9001

Boulder, CO 80301

Kevin Miles

Digital Equipment Co.

,

LTD. (Br~

' Acre Road, Reading, 3erks

England RG2 OSU

William Miller

E-Systems /Melpar

7700 Arlington 31 vd.

Falls Church, VA 22046

1
James Moulton

National Bureau of Standards (NBS)

B218, Technology Bldg.

Washington, D. c. 20234

Pat Mulvey

IBM 21Q/B231-2

P.0. Box 1328

Boca Raton, FL 33432

Steve Pearson

ICL

P.0. Box 10276

Stamford, CT 06904

Gail Poulter

Digital Equipment Corporation (DEC)

1925 Andover Street

Tewksbury, MA 01876

James D. Pyles

E-Systems, Inc.

7700 Arlington Blvd.

Falls Church, VA 22046

Lee Quackenboss

Honeywell Information Systems (HIS)

P.0. Box 800 M/S T60

Phoenix, AZ 85066

Allen B. Rochkind

Intel Corporation

3065 Bowers Avenue

Santa Clara, CA 95051

Robert Rosenthal

National Bureau of Standards (NBS)

B226, Technology Bldg.

Washington, D. C. 20234

Alan Sciacca - D351

Foxboro Company

38 Newponset Avenue

Foxboro, MA 02035

Dick Swee

Charles River Data Systems (CRDS;

983 Concord Street

Framingham, MA 01701

Ken Swenson

Boeing Computer Serivces (BCS)

P.0. Box 24346, MS 7A-05

Seattle, WA 98124

Mike Wallace

National Bureau of Standards (NBS)

B226, Technology Bldg.

Washington, D.C. 20234

Lyle Weiman

Hewlett Packard (HP)

19446 Pruneridge Avenue

Cupertino, CA 95014

Prentiss Yates

Cincinnati Milacron

Rt . 48 & Mason Road

Lebanon, OH 45236

Ron Yara

Intel Corporation

5200 Lakeside Drive

Santa Clara, CA 95051

2
2. Opening Remarks

Dr. John Heafner opened the meeting and acted as chairman for Mr. Maris

Graube who did not attend. The agenda was reviewed. An FTP test schedule

and status report of transport testing was added and FTP problems and FTP

differences were merged.

3. Sub-Group Status Reports

3.1 Mr. R.on Yara of Intel presented the CSMA/CD status report. In the

CSMA/CD meeting of March 7 (also attended by GM), both the vendor for

constructing the booth and the style of the booth at the NCG were selected.

The style of the brochure was also selected; fifty thousand copies of the

brochure will be printed. NCR is coordinating this effort. The logo

will be reviewed by NCR and CRDS on April 2.

It was noted that the common cable could not run outside of the booths.

A vendor could, however, act as a gateway and run a separate cable if

desired. The separate cable would be the responsibility of the vendor.

3.2 Mr. Ed Deenihan of GM presented the token bus status report. The

vendor testing schedule, shown as Attachment A, was presented as a proposed

schedule. Vendors must test with NBS before testing with GM (Telenet

encouraged). Confusion as to the number of required NBS test scenarios

was clarified: There are 139 required transport protocol test scenarios

and several optional ones. The complete list is given in Attachment B.

The transport CR and CC were reviewed and it was decided to allow data in

these PDUs. Hence, six tests were added to the 139 test set.

DEC will supply the reference FTP and IBM the reference MSG implementations.

At this point the question of who could be Included in the press release

was raised. The final determination was only those participating in the

booth.

4. FTP Problems and Protocol Refinements

4.1 Ms. Pat Amaranth representing GM spoke on three topics: GM FTP

agreements, open issues and DEC's replies to FTP implementations issues.

John Heafner stated that if there are any changes to the existing FTP

specification, a new document would have to be generated.

4.1 GM FTP Agreements

A copy of Attachment C "Current GM FTP Agreements" was made available to

all attendees. These are agreements to make the FTP implementations on all

machines easier. The following points were brought out in the ensuing

discussion:

o Only one TSAP id for FTP,

o File type not in CC Transport PDU,

o Only two file types,

o FTP document is more current than Proceedings of the 4th LANTransport Workshop,

3
o One FPDU is one TSDU - clarification of document not a change,

o Text file types will have .TXT in filename,

o Buffering is a local issue for TSDU interface does not require it

DEC is buffering but should have enough memory to avoid problems.

It was agreed that items two through seven of Attachment C, would be

adhered to by both groups. Logging (item number eight) was left as an option for the CSMA/CD group.

4.1.

B Open Issues

The error id, error code and diagnostic fields in the open, close and

release are now mandatory and in the order presented. Success or warning

are assumed to have worked properly. The diagnostic field may have a length code of zero.

The question of data in the T_DISC was debated. It was decided that

transport will accept data in the T_DISC (not a protocol violation) but

what it does with it is optional. The data, however, must be an ASCII

string.

The error codes defined under the Error Header Item (p. 35 of FTP Final

Report) overlap. It will, therefore, be up to the implementor to find

out what each means as debugging progresses.

It was agreed that the receipt of an F__CANCEL Request after issuing an F_CANCEL Request would be treated as a confirm (just as transport handles

crossing T. DISC's).

The transport sequence space is assumed to be 31 bits but may be negotiated

to seven bits. Participants will use the NBS not ISO specification. It

has been agreed that 31-bit sequence space will be used in the demonstration.

Implementation of the seven bit sequence space is only being provided for

conformance to the specification.

4.1.

C DEC Replies to FTP Implementation Issues

All issues discussed are shown in Attachment D. There is a need to

solicit questions from implementors, find answers to those questions and

distribute results. Distribution will be through Jerry Linn of NBS (see

section 11).

5. NAPLPS Demo and Files

Mr. Kern Hardman of BCS described the NAPLPS demo (see Attachment E).

BCS will use the HP protocol implementations. The demo will be menu

driven. The data base will be expanded to include all CSMA/CD vendors.

4
The database will be filled in with current (e.g., what is playing at the

hotels) and graphic (e.g., naps) information. NAPLPS files will be retrieved

from the system on which they are stored and displayed on the NAPLPS

terminal. Each vendor's logo and one frame of company information can be

displayed. The company information frame will be a statement already

done by each vendor. The frame is limited to fifteen rows of eighty

characters and is needed by April 2. Company information frames and

logos should be sent to Mr. Kern Hardman, Boeing Computer Services, P.0.

Box 24346, MS 7A-05, Seattle, WA 98124. DEC, Intel, ICL, and Honeywell

volunteered to house the BCS and NBS frames.

The biggest problem envisioned was getting the data files on the appropriate

hosts. BCS had a problem with added carriage return line feeds when they

moved a NAPLPS file from one host to another. This should be cured by

FCOPY (see section 6).

6. FCOPY

Mr. Allen Rochkind of Intel presented a solution to the file loading

problem, the FCOPY utility. FCOPY, which would use FTP in read-mode,

would provide the needed functionality to overcome incompatible media.

It would work like the following (underlined are user supplied);

FCOPY

FTP File Copy Utility

Remote File Owner Name: BCS

FTP File Name: XYZ.Bin.BCS

Local Pathname: /awO/ncc / xyzbb

The file type would come from the FTP File Name. All CSMA/CD vendors

agreed to implement FCOPY.

7. HIS Demo and Files

Mr. Bruce Carlson of Honeywell presented a preliminary proposed application

(see Attachment F). The trivia quiz (e.g., sports, movies, history)

would have each set of questions and answers on a different host.

The problem of the expanding number of file names that would appear,

mostly unneeded, in a FILE. DIR was debated. The resolution was that

FILE. DIR would supply all names and it is up to the requestor to display

them.

ICL will implement the menu described at the Seattle meeting.

8. FTP Testing and Schedule

8.1 DEC FTP Implementation and Tools

Mr. Keven Miles of DEC described the status of two software packages; the

FTP reference implementation and the Test PDU Sender (see Attachment G).

The FTP implementation comes with full logging, multiple concurrent

transfers (multiple copies) and no write/create. The implementation i

5
due at GM on April 9. This is a conforming implementation and does not

inject errors.

The Test PDU Sender can generate incorrect or out of order FPDUs with

full logging. There are no scenario command files at present. DEC will

make available whatever is used to test their FTP. Volunteers were solicited to expand this set. GM will coordinate the collection of

scenarios and generate some. Ken Aird of HP will generate some scenarios

(see Attachment H). Gould will also do some for state transitions

including write create.

8.2 FTP Testing

Ms. Pa.t Amaranth described the GM FTP Testing Agreement (see Attachment

I). The GM tape will be in TAR format.

A discussion of minimum FTP testing was resolved by vendors agreeing to

meet various testing requirements. The testing requirements were:

1. send, receive and compare one file (to DEC and return),

2. send, receive and compare all files in agreed upon set, algorithms

published by James Berets of BBN, "N" lines,

3. send, receive and compare GM file set "N" times,

4. ten concurrent connections of type 3,

5. Test PDU Sender.

The vendors agreed to do the following tests:

TYPE VENDOR

1 Intel

,

Gould, ICL

,

NCR, HP, DEC, HIS

2 Intel, Gould

,

ICL, NCR, HP

3 Intel

,

Gould, ICL, NCR, HP, DEC, HIS

4 Intel

,

Gould

,

ICL, HP, DEC, HIS

5 Intel

,

Gould, ICL NCR, HP, DEC, HIS

An FTP test schedule, at NBS, was agreed to as follows:

April 16-20

May 7-11

May 14-18

May 21-25

May 28-June 1 June 4-8

June 11-15

June 18-22

DEC

HIS

ICL , NCR

Intel, HP, BCS

ACC/CRDS

Full System Tests

Full System Tests

Ship Out

When testing at NBS, vendors will be given a five meter cable which can then be connected to the long cable. Multiplexing of testing has worked

out best.

6
9.

Common Business

The press day scheduled for April 25 is cancelled. In its place a news worthy event will be created by having the Secretary of Commerce, Malcolm

Baldrige, the Director of NBS, Ernest Ambler, the President of BCS, Mr.

Robert Dryden and a Vice President of General Motors sign agreements for

the NCC demo. I CL will issue a press release in Europe like the original

release after checking with NBS and after signing. Vendors who want to

make minor revisions should go through NBS for technical review. Mr.

Robert Blanc is the contact point.

10. Arbitration of Technical Points

NBS was selected as the focal point to arbitrate technical issues and

disseminate answers. Mr. Jerry Linn is the contact point for both

Transport and FTP. Telex is acceptable (Telex number 898493).

11. Transport Testing Experiences

11.1 HP

Mr. Ken Aird's major problems were porting the scenario interpreter and

addressing in the NISL. HP used a 3COM transceiver. The ICL monitor box

was useful but couldn't be used for master scenarios (run all scenarios).

Mr. Stephen Nightingale of JIBS was specifically commended for providing

assistance.

11.2 Gould

Gould's major problem was getting TELENT link service. A line monitor

was useful to see that invalid PDU's came across when expected. Mr.

Jeff Gura of NBS was cited for outstanding service and being available

any hours needed.

Other vendors have completed transport testing with NBS, but did not

provide comments at the workshop.

7
ATTACHMENT A

VENDOR TESTING

FEBRUARY MARCH APRIL MAY JUNE JULY

IBM

DEC

MOTOROLA

HP

GOULD

A-B

n FTP to

G

4-2

TRA

N

FTP

4-9

TRA

N

FTP TEST DATE

TO BE DEFINED

4-16

TRA

N

FTP

4-23

TRA

N

FTP

4-30

TRA

N

/'.FULL >/;

V MULTI -

*'

:"V E N D O R - •

/TESTING X

y y y

y y y y y y y y y*

y*y“'y“*,y'K»>v”k-p*“v^"

y y y

y*yAy^%-“y"y^/~y',‘': /yry-^A'V*'.

WyW/y:/

VVyVVVyVA WvvVy/W?

V^VyVWM

VVvvvvv//

yy

-:/AVv*yV; VvLW//Vv. //•w/vv- V^VtVvLw. - >• V r" *-' y y - T H yyyyyyyyyi.

vVy^y'/X/vV.

yVyV:

N

C

c

J

u

L

Y

9

8
ft>

16 : 0 5 193 4 ATTACHMENT B 133S3C c 2 C S 1

lC * oil! ^3jf fnan, G M

•* r o m J j = r - y L i r n , N 2 S

c

f scenarios

ravished /our list of rec-iired

'= remotes indicate changes.

subject: 'J o o s t e to your list

0 er 3uc conversation, I a v e

y c j n a o sene scenarios t

to you anc the vendors r

n 37 a c >? gp doing

one or .core asterisks in

list or that crcocsed oy

this uill accress any ou

< e r n a i set."

- 5 = i n g those oroviCed 1 3; r

- 1- . Bcng grace f u 1 close jith c as noted 0 e 1 o j . Tnose not

1 1 c a t e variance uith either yo ctecher as roouirec tests, ho

tstandinc cuestions about " j h a

fall

u r o r i

0 e f u 1

1

t is t

y 1 h e

n

7

Transport -scenarios to be t 5 5 * 9 ~ a ± t h ^ a $

M 3 r . : , 19 3 4

« O J >J

t c _ 4 . 4 . 3 3 C

t c _

4 . 4 . 3 3, 1 tc _ 4 . 4 . 3 n 2

t 0,4.4.333

tc, 4.4. 3 04

tc_4.4.3 35

tc ,4.4.306

tc ,4.4. 211

tc_4.4.3!2

*-_4.‘..513

t C , 4 . 4 . 5 0 C TC_4.i.. 5 31

tc_4. 4 . 5 32

. 0(j4

tc_«*.4.535

tc_4 .5.011

tc_4 . 3 . C 1

2

tc_4 . 5.013

tc_4. 5.014

tc _< . 5 . 0 1 5 tc_4 . 5 . 0 16

tC_4 . 5 . 1 3 1 ***

tc_4.5.i'3? ***

tc_4 . 5.103

T c _

4 . 5 . 1 3 4

9

a.

id
* ar 1 6 : 0 5 i a ~ 1-5 i33] p = g e Z

tc_4.4. 101

tC_4.4.102

tc _4 .4.103

i c _4 . < . 1 2 4

tc_4.4.1C5

tc_4 . 4 . 1 1

C

tC_4 .4 . Ill

t C _ 4 . 4 . 1 12

t c _ 4 . 4 • 1 12

tc_4 . 4 . 2 0C

*C — 4.4.4,'jl

t C _ 4 • 4 , 2 0 4 tc_4 .4.202

tc_4.4.912

tC_4.4.914

t c _ 4 . 5 . C 0

1

tc _4 . 5 . Q Q 2

* r- (. C P 0

-3 tc_4. 3.004

tc_4. 5. 005

*c_ 4.5.0 Of

tc_4.3 .0 0 7 tc^4.3.003

tel* . 5.0 0 9

t c 4.3.010

tc

-

tc_4 .6 .203

tC_4.6.204

tc_4.6.20S

4.5.206

_4.£.20T

tC_4.£.2Q3

tc_4 .6 . 209

tc_4 .6.211

tc_4 .6.2 12

* - ' ,t ? 1 c

t C _ 4 .

6

tc 4.6

213

219

optional — c optional - ooticnal -Is with implementation issue

- cats on 2 a t P 2 U C 3

m r?^ jire-renO

- cianc? 1 e n c t h indicator on TP3UI

results o t t e s s re not deterministic —

action of oarser should be to else arc NS

cut it is no* in the specification.

Test hissing the list — use disconnect rather

graceful close

than

— ~ ^ J 2

r~ 7

1 ~ 7 Note: tc 4.2.

tc_4.3.231

n s s tc _4 .3.252

3 5 6

deliberately cn.nit ted

so missing

4.5.105 t c 4 10 6 (variation o arareters

iris x i s t it is a h I

\

2 t n e r s may

should

A H '* not o? considered as

ii', :cn Jill demonstrate

ded from time to time

a set of " exhaustive tests":

potential interopi-aoility.

as needed.

10
ATTACHMENT C

CURRENT GM FTP AGREEMENTS

MARCH 7, 1984

1 . Maximum file size will be limited to 8K octets.

File content is limited to ASCII text characters

Each variable length line of text is terminated by

a CRLF (ASCII carriage return/ line feed pair ). A

single line of text is 2 to 82 octets in length (0

- 80 text chars + CRLF).

A file may be transmitted as one or more FDATA

requests.

Each FDATA request contains an arbitrary partition

of the complete file data and may contain multiple

or partial text lines.

Each FDATA request becomes a single t-DR PDU sent a?

a TDATA request.

Only one file read should be done for each file

connection.

Filenames for FSELECT PDUs and local FILEDIRs are

in the format: filetitle. filet ype. filecwner (eg

FABLE. TXT. MOT)

Each vendor will keep an FTP LOG of connects (CR

and CC) and disconnects with reason code

11
ATTACHMENT D DEC Jt£F€ft£**C£ *EPLIES TO FTP IMPLEMENTATION QUESTIONS

Q.: Mill the r##*f*nct support sort than m« c

M

cumat

FTP incoming and/or outgoing connection?

Yes* but nut multiplexed within the FTP codo.

Mill the rtferenet bo using FTP response timers in

addition to ovont timer* provided in Transport?

I# wo have time we mmy implement timer*.

0: What it the reference behavior if a filename other

than the filename specific* in thm FflFl ECT it

returned in the FSELECT confirm? Xs this an error

resulting in an FA0OPT, does it result in an

FDESELECT and retry, or i% it not an error detected

by the protocol machine?

The reference imp lamentation will ignore this condition* and will net g enerate

this condition. In any case. I would not regard this as an error since the

returned name may the the full filename, e. g. . after defaults have teen

app lied.

0: Is it an error to select a file that dots eiist tut

is not contained in the local FILEDIR? < sae clausa

6. t. 2 of the CM agreements document for description

of FILEDIR)

The reference implementation will not generate an error for this.

<1: re: INTEL'S "NOTE ABOUT IMPLEMENTING MULT I VENDOR

FTP**. January 3. 1904 Does the reference intend te

send DT TPDU's with EOT? Does it expect to receive

only DT TPDU's with EOT? If not. in the case where

an FDR PDU is sent as a series of DT TPDU's. will

only the first DT TP DU te expected to have an FPDU

header or will all of the DT TPDU's have an FP DU

header inserted as in INTEL'S description?

• I havn't seen Intel's document. However, segmentation ef TSOUt is a Transport

Protecei issue end is NOT e Trenspert Service issue. The Transport Service

provides for the transfer of complete TSDUs. An FDR PDU Is a complete TSDU.

The fact that a complete TSDU mau be transferred as a number ef separate TPOUl

should not normally bo reflected at the Service Interface. Thus* if an FPCU is

transferred as a number of DT TPDU*. the responder should enlg see the arrival

of the concatenated FPDU. However, this depends upon the Transport

implementation at the responder.

<0: Haw many times will the reference retrg

establishing a connection?

The Fil'd Transfer Protocol does not include retries. - Thuds It wi J The Transport Service will send up to 4 CRs before It gives up.

12 • •
ATTACHMENT E

HoNeyuus. LL NQS ///cc. ft?vi rt V Dzjbotvsr/z*7-/c*s

APf-LlCfiTtOV

frleun/t

T#

13
MoHWYWBtt, / PAPt*/** PtffSAL

A/SBS> 7® : — XZ&Atf//?/ VBAjSc^J mm® U//LC

S7&&S- git -t- /Qs — ft&m/fi-r T& ' TMtiSFejC /®'W 7®

y&tV&dVS

4VI2-0/. TXT. ???

£*&*/& . T7fK ???

"&LW& H ? (usetv- FMF-&4) F/LFS.

14
ATTACHMENT F

MULTI -VENDOR DEMONSTRATION FILE TRANSFER PROTOCOL

TEST PROTOCOL DATA UNIT SENDER

Digital Equipment Co* Ltd.

Acre Road

Reading

England

5 March 1954

15
rtH

FTP Test PDU Sender

1 . 0 INTRODUCTION

The Test PDU Sender (TPS) is a program that sends and receives FPDUs

to and from a remote FTP implementation. An Event Logger is used to

og all Transport events and data received and transmitted. For

escing purposes TPS can be instructed to send many types of invalid

PDU

,

TPS is designed to emulate a FTP implementation

the FTP implementation being tested. The

between TPS and FTP is that TPS sends and

pre-det ermined sequence of FPDUs and if abort

received FPDUs are not what was expected.

, and is transparent to

significant difference

expects to receive a

s the connection if the

16
FTP Test PDU Sender

2.0 GENERAL DESCRIPTION

TPS is a substitute for the FTP Responder or Initiator. It runs on a Digital Equipment Corporation VAX computer system under the VAX / VMS

operating system. The VAX computer is connected to the Local .Area

Network (LAN) via appropriate hardware.

TPS is run by issuing a DCL (Digital Command Language) command to the

VAX system. When running as the FTP Responder the command is issued

by a DCL command procedure which is invoked by the OSI Transport

implementation. The DCL command to run TPS is described in section

2.1

of this document.

TPS operates with an Event and Data Logger and communicates directly

with the OSI Transport implementation to send and receive FPDJJs.

Commands to control transmission and reception of FFDUs are stored in

a file called the Scenario Command file. The commands used in the

Scenario Command File are described in section 2.2 of this document.

The Scenario Command File is accessed either by a name supplied by the

command to run TPS or, if no name is specified, from the same source

as the command was issued from.

Transport events and all received and transmitted FFDUs are logged to

a Logfile. In the Logfile FFDUs are formatted into the fields that

they contain and are analyzed for some types of error. Had FFDUs are

flagged in the Logfile and their contents are printed in hexadecimal

for further analysis.

The Leaf ile is accessed either by a name supplied with the command to

run TPS or, if no name was specified, it is written to the terminal or

batch log for the job that issued the command.

2 .

i

DCL Command For TPS

Invokes the Test PDU Sender (TPS)

.

TPS runs until either the end of the Scenario Command File is

encountered, or, when executing a scenario, an error is detected,

a Transport Connection is established by the scenario and it has not

been disconnected when TPS has completed, the scenario or the error _ detected, an implicit DISCONNECT command (see section 1.2.2) is issued

to release the Transport Connection.

Format

:

TPS Ct iie-soecJ

Command Qua i i f i e r s Det ault

s

/L0GL"=f ile- spec 3 (see t ext

)

/

C

NO 3 EXECUTE / TT^'P'PTJT'jr

/ UNO 3TIMEQUTE = value

3

/T"r XEOr T= 1 5

17
FTP Test PDU Sender

Command Parameters:

f ile-spec

Specifies the scenario command file to be executed. If not

specified the scenario commands are read from SYS 5 INPUT : (by

default this is either the terminal or the DCL command procedure

that issued the TPS command). If the file specification does not

contain a file type, TPS uses a default file type of COM.

Command Qualifiers:

/ LQGC = f i le- speed

Specifies the file the FTP log output is to be sent to. If this

qualifier is not specified the log output is written to

SYS30UTPUT: (by default this is the terminal or batch log of the

job that issued the TPS command). If you omit the file

specification, TPS gives the log file the same file name as the

scenario command file and a file type of LOG.

/ EXECUTE

/ H0 EXECUTE

Controls whether the scenario commands are executed or only a syntax check of the scenario commands is made. By default the

scenario is executed. If the commands are being executed a bad

command will terminate the scenario. If only a syntax check is

being carried out, bad commands will be flagged and processing

the scenario will continue.

/TIMEOUTC =value3

/MOTI MEOUT

Specifies a timeout to be applied to all network

operations. The value is given in seconds,

specified, the timeout period is infinite. The

period is 15 seconds. The /TIMEOUT qualifier

/ N0EXECUTE qualifier is specified.

r e ad ( receive)

If / MOTI MEO UT i

s

default timecut

s ignored if the

Examples

:

1 . $ TPS

Execute the scenario which is

the command is issued from,

terminal or batch log of the job that issued the TP

The default timeout of 15 seconds is applied to a read operations.

read from the same

The log file is writ

source as

ten to the

3 command.

11 network

18
FTP Test PEU Sender

5 TPS / NOEXECUTE TESTI/LOG

Performs a syntax check of the scenario file TE3T1.COM,

writing the locr to TEST1.LQG. As no network, read, operations

are performed, no timeout is applied to anything.

,s TPS /TIME^kTT = 2 / LOG—FTPLOG . DAT TEET1

COM, writinu the loo

is applied to network

Execute the scenario command file TEST1

.

to FTPLOG. DAT, A timeout of 2 seconds

read operations.

TPS Scenario Commands

The Test PEU Sender uses a series of scenario commands to control its

operation

.

These commands are described in this section. The

commands are stored in a f i i 0 * Each command consists of keywords and pa rameter values which are

separated b;y one or more spaces or t ab s , C ommands may be cor.ti nued

over multiple lines by placing a hyphen as the last- non-comment

character on the line to be continued.

An exclamation point ( ! ) is used to designate a comment. A comment

extends from the exclamation point to the end of the line. A comment

cannot be continued on to the next line. Comments nay also be placed

at the end of a line after a command (or part of a continued command)

.

Command names and keywords may be abbreviated to the

letters. Also some keywords may be left out.

descriptions these words are enclosed by brackets (C3)

f ewe 5 1 un i o u e n c omiTisinci

Certain parameter values are specitied as CTUoted strincrs.

strings may

( " ) , but the

be pudted -with either apostrophes (

' ) or cruosaci

starting and ending quotes must match. A quoted

may not be continued over more than one line of the scenario

file.

marks

s •: r intr

Scenario command files may contain as

between c ommand s for f orma1 1 ing

characters at the beginning of a line

many blank lines as re purposes. Also anv Form

are discarded.

yr a

& czr

19
FTP Test PDU Sender

2.2.1 Connect To Remote FTP

Establishes a transport connection to a remote FTP implementation. No

FFDUs are transmitted.

Format

:

CONNECT remote-id PDU C3IZE3 max-pdu-sice

remote- id Identification of

implementation the

to. It is specified

is *TBS*.

the remote FTP

connection is to be made

as a string. The format

PDU C3IZE2 max-pdu-si e Specifies the maximum length of an FPDU t transmitted over this connection. I specified as a decimal number greater than

The default value is 256.

10 .

20

o

+j
FTP Test PDU Sender

2.2.2 Disconnect From Remote FTP

Disconnects the transport connection to a remote FTP implement

Mo FPDUs are transmitted.

Format

:

DISCONNECT

21
FTP Test PDU Sender

2*2.3 Send FPDUs To The Remote FTP

Euilds a FFDU and transmits it to the remote FTP* If data is to he

transmitted, multiple FFDUs may be transmitted, depending on the

amount of data to be sent, and the maximum PDU size set up with the

CONNECT command.

The send command allows any header fields to be transmitted in any

type of PDU. This facility is provided in order that invalid PDUs may

be transmitted. The header fields are placed in the header in the

order in which they were specified in the command.

If data is transmitted in a PDU and the data type id is specified as

ASCII text; the data consists of the ASCII code sequence from "1"

through and is offset one character into the sequence after every

<CR> <LF> pair. If the data type id is any other, the data consists of

octets containing the values 0 through 255 decimal, and is offset one

octet into the sequence in every consecutive PDU. Both these

sequences are repeated if the end of the sequence is reached.

Format

:

SEND v H i i-type-id

Pdu — t Trp 0 — i h.

SERVICE C SUBSETS 3 e rvi ce — sub s e

t

— id

F I LENAME filename

ERROR error - id

ERROR TYPE error-type- id

D I AGNO ST I C CSTRINGo" diaa-string

DATA TYPE data -type-id

DATA, data-octet -count DATA. LENGTH data-length

Defines the PDU- type id in the header of the

PDU to be transmitted. It is specified as one

of the following strings or as a decimal

number in the ranee 0 to 255.

u’f'D file f’nnnpr*- reqi \ pct

FCC file connect confirm

FRLR file release request

FRLC file release confirm

F3R file select request

FSC file select confirm

FDSR file deselect request

FD3C file deselect confirm

FOR

* file open request

FOC file open confirm

FCLR f close request

FCLC file close confirm

FRR file read reciuest

FRC file read, confirm

FDR f i 2.

0

data request

FDER file data end request

FTER file transfer end request

22
FTP Test PDU Sender

SERVICE C SUBSETS

service- subset -id

FILENAME filename

error type

error — type - id.

ERROR error — id.

DIAGNOSTIC L STRINGS

diag-string

DATA TYPE

data-type- id

DATA, dat a - o c t e t - c cunt

DATA LENGTH

data-length

FTEC file transfer end confirm

FCANR file cancel request

FCANC f i 1 0 cancel confirm

FHR file write request

FWC file write c onf i r

m

FCRR flip rprjtjpqf

FCRC file create confirm

Specifies the subset service id in the service

subset header item. It is specified as a decimal numbe r in the range 0 to 15.

Specifies the f i l ename string in the filename

header item. It is specified as a quoted

string

.

Specifies the error type id in the error type

header item. It is sp<=3 '- if i eb ay a d^^imal

number in the range 0 to 15.

Specifies t he error id in the error header

item. It is specif led as a decimal number in

the ranae 0 t o 15

.

Specifies the diagnostic string in the

diagnostic string header item. It

specified as a quoted string.

Specif

header

number

values

ies the data type id in

item. It is specified

in the rancre 17b to 191

are defined:

he data

El 3 EL The f

type

dec im

ilowi or

176 ASCII text

131 binary dara

any other values are interpreted as specifying

binary data. The default value is ASCII text.

Specifies that data is to be transferred in

this PDU. It is specified as a decimal nun

in the ranae 1 to 65535. If the soecif

number of octets cannot be transferred in one

PDU, multiple PDUs are transmitted. The da :

a

transmitted is yenerated internally and

depends on the data type beincr transmitted.

Specifies the lencrth of the data field in th-'

individual FPDUs transmitted. TPS wi 1 . attempt to put data-length octets of _:ser da -a into each FPDU. Less data will be put in t: FPDU if either the maximum FPDU sice tree.: ; ; in the CONNECT command (see section I. I.

.

would be exceeded, or more data . un *

*

. specified by data— octet - count ; ; c • . ; _ ; transmitted. if the data type for r r.e FrTU

ASCII text, then a <CR><LF pair •

23

h- fr
FTP Test PDU Sender

at

data

5C0C

eoua

the end of the data in each FPDU after

-length octets of text data. It is

ified as a decimal number greater than or

1 to 1

.

24
FTP Tsst PDU Sender

2 . 2.4 Receive FPDUs From The Remote FTP

Receives the next FPDU and checxs its pdu— type - id t or receive.

FPDUs until the nexr FPDU received hss e. specie ied pdu— type - id

.

y—

P

Format

:

RECEIVE pdu -type-id -1 UNTIL pdu- type- id -

2

edd- tvpe-id-1 Defines the PDU— type id of the PDU to

received. If the PDU is not of the specif

type the scenario is terminated and

implicit DISCONNECT is performed. It

specified as one of the f ollowir.cr serines

as a decimal number in the ranee 0 to 25

d. CD

yUNT s D pdu— t ype — i d — 2 no r~

FCR file connect reeuest

per file connect confirm

FRLR f -? 1 ^ r CD | pq CP V PD n' 1 <= r FRLC file y pa 1 co pi r'fint ? v- -m d — file 5 0 i 0 C - C 0 CT LI 0 S L

T“*r* r“» T r\ t -? “I rr Ci 1 a (- 4- .-,7-' f -i ir FDSR f T T - Hpcal art roni’pcr

file n a c p 1 ca <— t“ r* nrvF * FOR file open reeuest

FOC file o k? 0n coni" i

m

u'r'r Zj f 2. l 0 c in^s reeuest

file c l o 5 p conf i rm

P'P Pt file read reeuest

FRC f i i 0 ra^C rnnf 2. If ITi FDR r -i data reeuest

FDER file data end reeuest

FTER d — .L td transfer end reeuest

-~vxrr r -? ~

cd transfer ^nd. '3 mx i n ^ FCANR l i 1

0

cancel reeuest

FCANC flip cancel conf ini?. fwr f Hd yr Ice reciue -

1

FRJC file wr i t e confirm

FrRP C-; i o v- csrjijca - FCRC f

1

y v m h t p !— n ^ r v ^

:ifies that ?DUs of pdu- type- id- 1 are ts be

ived until a ? htt wi * h a U P'U -yp<= » <* t. •j Tj 0 — i £ — 2 i s r8C0 i ir 0d * If ri0

i iv0ri e rm cd i ti ins n t ypp th<=> scenario

tinated and an implicit DISCONNECT i s performed. It is speoioied either

or a decimal number in the ranee

hove for the possible PDU — type - 2 i—

.

25

IT!

.j
FTP Test PDU Sender

Example Scenario Command File

! FTP Responder Test (TPS runs as FTP Initiator)

! This scenario command file first sets up a transport

i connection, then selects, opens and reads the file TEST.

! When the transfer is complete the file is closed and

deselected and finally the transport connection is

1 disc cnne c t ed

.

CONNECT TESTMODE -

PDU SICE 284

Establish Transport Connection to

TESTMODE and use a maximum PDU sice of 284 octets.

SEND FCR SERVICE I ! File

! sub

Connect Request — sec cede is 1 (file

RECEIVE FCC ! File Connect Confirm

SEND F3R - • P T 1 q pa 1 prr CnniiPt;)-

FILENAME "TEST" ! f il enaroe is TEST

RECEIVE ESC ! File Select Confirm

SEND FCR i File Open Request

RECEIVE FOC ! File Open Confirm

SEND FRR ! File Read Request

RECEIVE FRC 1 File Read Confirm

RECEIVE FDR UNTIL FDEP. 1 p_gr p ive FDR PDUs uo to

a FDEP. PDU (File Data

301TV1C9

transfer

)

oinci includi

End Request

ng

) . SEND FTER - File Transfer End Request

ERROR TYPE 0

- ERRCP. 0

- DIAG STRING "

Error Type = Q — Success

Error - 0 — Success

Null Diagnostic String

RECEIVE FTEC

SEND FCLR

q'ESEIT7E C

SEND FDSR

RECEIVE FDSC

SEND FRLR

RECEIVE FRLC

DISCONNECT

File Transier End Confirm

File Close Reciuest

File Close Confirm

File Deselect Request

File Deselect Confirm

File Release Request

File Release Confirm

Release Transport Connection

i End example scenario

t End f descript ion J

26
ATTACHMENT G

F Tip

M-t. -S+clTs- -F r'a-A-si TrcA 4-es^-s

'Ve^* jrr*J~rru~

OuA <rf «^4 «v

c.<^vv_oe- Lr

W> ^ l^yulld ¥M0M..»

Otplrca^e*

K-. VS 7 -t,\. p

«-'Ta-**t'i-

,t **’”

(Ju^ o-'f * Sad. p>*.r«,.*i*fe*

VSy1~£j vTei/^Seci

W 3. 1-eJ^r^

^ C<naLJ w

l^L*c^>-S Ic^TwCJ iVWM.J^tJV'** Cr^tecfrnt

5". E^v^fs

j

*.« p^T «A«- C*d«--»

c

^

e e:ir«rj rw sys-he^ u^d^r f«J

'5

'

27
ATTACHMENT H

Page 2

FTP TESTING

GM vendors have agreed to the testing outline prepared

by Jim Berets of BBN and distributed as Annex D of the

MULTI VENDOR DEMONSTRATION FILE TRANSFER PROTOCOL FINAL

REPORT REVISED* December 1933* with the following

modifications:

1. Section i - Tests of Normal Operation

Test 1 - "Transfer file between like machines"

offsite before coming on-site at GM.

2. Test 2 - "Transfer file between different machines"

Steps 3 and 4 "Comparison" will be accomplished in

the following manner.

— GM will distribute test file tape

- vendor —> ref test* DEC reference will

request the test file suite and compare against

its copy of the test masters.

- ref —> vendor testj DEC reference will

transmit the test file suite. Testing vendor

will compare against its local copy of the test

masters.

- Above tests will be repeated for a specified

number of trials.

3. Section 3 - Tests of Robustness will be

accomplished with the err or — in j ec t ing facilities

provided by the DEC reference implementation.

4. A multi-vendor "Pull loading" test period will be

added to simulate NCC conditions.

28
N8S-114A iREv. 2 -bc

)

U.S. DEPT. OF COMM. BIBLIOGRAPHIC DATA

SHEET (See instructions)

1. PUBLICATION OR

REPORT NO. NBSIR 84-2855

2. Performing Organ. Report No. 3. Publication Date March 1984

4. TITLE AND SUBTITLE

Proceedings of the Fifth LAN-Transport Workshop

5. AUTHOR(S)

Michael A. Wallace

6. PERFORMING ORGANIZATION (If joint or other than N BS, see in struction s)

NATIONAL BUREAU OF STANDARDS

DEPARTMENT OF COMMERCE

WASHINGTON, D.C. 20234

7. Contract/Grant No.

3. Type of Report & Period Covered

9. SPONSORING ORGANIZATION N AMp AND COMPLETE ADDRESS (Street, City, State, ZIP)

Institute for Computer Sciences ana Techno 1 ogy

Systems & Network Architecture Division

National Bureau of Standards

Washington, D. C. 20234

10.

SUPPLEMENTARY NOTES

I | Document describes a computer program; SF-185, FIPS Software Summary, is attached.

11.

ABSTRACT (A 200-word or less factual summary of most significant in formation . If document includes a significant

bi bl iography or literature survey, mention it here) The National Bureau of Standards Institute for Computer Sciences and Technology (ICST)

has prepared specifications for the International Organization for Standardization's

(ISO) Class 4 Transport Protocol. At the request of a number of companies, ICST organized a workshop series for implementors of these specifications using local area networking technology. The first workshop focused on implementation techniques and

strategies so that a multivendor demonstration of these protocols can occur at a major

computer conference in 1984 targeted for the NCC 1984. Primarily the details of CSMA/CD

and Transport Class 4 were discussed and parameters were selected. A second workshop

focused on token bus LANs and file transfer applications to be run at the targeted 1934

demonstration. Agreements on the specifics of the file transfer protocol were reached at

the third workshop. The fourth workshop covered further refinements to the file transfer

protocol, testing procedures, and demonstration details. This report documents the fifth

workshop in the series of LAN/Transport workshops. The fifth workshop defined the File

Transfer Protocol (FTP) testing schedule and minimum vendors tests, made minor adjustments to the FTP and reached agreements on participation in the HIS and BCS demonstrations.

12.

KEY WORDS (Six to twelve entries; alphabetical order; capitalize only proper names; and separate key .vara-. ; , ,-~ communication protocols; computer networks; file transfer protocol; local area networks; transport protocol

13.

AVAILABILITY

i y i Uni imited

1

I For Official Distribution. Do Not Release to NTIS ~ Order From Superintendent of Documents, U.S. Government Printing Office, Washington, D.C

20402.

[jj[] Order From National Technical Information Service (NTIS), Springfield, VA. 22161

14. NO. OF

PRINTED PAGE

15. Pr

4