Csl

CT

CnI

I

C

1

NBS

PUBLICATIONS

NBSIR 84-2984 '< )

AlllDM 7bSEM

Minutes of the Seventh

Workshop for Implementors of ISO

Open Systems Interconnection

U.S. DEPARTMENT OF COMMERCE

National Bureau of Standards

Institute for Computer Sciences and Technology

Systems and Network Architecture Division

Gaithersburg, MD 20899

September 5-7, 1984

U.S. DEPARTMENT OF COMMERCE

-nc130

.1156

BUREAU OF STANDARDS
ij,

i '.V?
NBSIR 84-2984

MINUTES OF THE SEVENTH

WORKSHOP FOR IMPLEMENTORS OF ISO

OPEN SYSTEMS INTERCONNECTION

kationai BUBEAU

OF STANDABDS

library

Qc/:-o

i 0> C'," / T 6

c

U S. DEPARTMENT OF COMMERCE

National Bureau of Standards

institute for Computer Sciences and Technology

Systems and Network Architecture Division

Gaithersburg, MD 20899

%

September 5-7, 1984

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

NATIONAL BUREAU OF STANDARDS. Eme#t Ambler. Director

MINUTES OF THE SEVENTH NBS WORKSHOP FOR

IMPLEMENTORS of ISO OPEN SYSTEMS

INTERCONNECTION SEPTEMBER 5-7, 1984

Rob Rosenthal of NBS welcomed attendees to the seventh NBS workshop for

implementors of Open Systems Interconnection. He presented a suggested schedule for future workshops (Attachment #1) and pointed

out that the dates, which were selected to have minimum conflict with

standards meetings, are firm but the hosts are tentative. Any

company wishing to host a meeting should contact John Heafner of NBS.

Rob turned the floor over to Maris Graube, the moderator, who

requested attendees to introduce themselves to the workshop, A list

of participants at the 7th workshop is in Attachment #2.

The agenda for the 7th workshop was modi fed by the participants as

in Attachment #3.

The agenda for the 8th workshop as proposed by the participants is

i n Attachment #4.

Several lists of vendors interested in implementing protocols were

circulated solely to determine the eligibility to vote during the

workshop - see Attachment #5 regarding workshop voting privileges.

Organizations voting to implement one or more protocols agreed upon

in general have listed themselves on Attachment #6, Organizations

interested in implementing specific protocols or protocol rnechanisms are shown on Attachments 7, 8, and 9, which name the coordinator of each

specific interest group.

Jim Moulton of NBS presented the changes made to ISO transport at

the June meeting of ISO TC97/SC16 in Copenhagen - see Attachment i^^lQa.

The participants accepted the motion of Laurie Bride of BCS that the

workshop Transport be aligned with the ISO Transport - see Attachment

^lOb.

Jim Moulton then presented a recommendation for enhancing the workshop

Transport by adding expedited data and negotiation during connection

establishment - see Attachment Participants voted to accept

expedited data by a vote of 14 to 0 - see Attachment #12.

Mr. Moulton's detailed proposal for negotiated transport features is

in Attachment #13; it was accepted by a vote of 26 to 0.

Dick Swee of Charles River Data suggested that graceful close be

implemented in the workshop's Transport. Jim Moulton pointed out

that there is a reserved code in the ISO specification for graceful
close; and John Heafner announced that NBS would test gracgfu.1 close

with any vendor who implemented it, A vote was taken resulting in Z

for and 7 against. Dr. Heafner then offered to form a subgroup

of vendors to demonstrate and test graceful close and asked interested

parties to contact him. Mr. Moulton introduced the participants to

the service provided by the Internetwork Protocol in Attachment #14.

Ross Gallon of BBN gave an overview of IP architecture as described

in the ISO document "Internal Organization of the Network Layer" - see Attachment #15.

Next, Dave Oran of DEC gave an overview of the Internetwork protocol

- see Attachment #16.

After lunch, Ross Gallon of BBN outlined the addressing schemes of

the network layer - see Attachment #17.

Several proposals for a subset of IP functions to be implemented by

workshop participants were made.

BCS presented a proposal by Laurie, John Heafner (NBS) and Ross

Gallon (BBN). It is recorded in two attachments, numbers 18 and 19.

Karl Scholl of GM suggested a subset of IP functions to be implemented

as summarized in Attachment #20.

Ben Potter of ICL made a proposal for IP that took into account

requirements for speedy implementation as well as constraints. (A copy

of Ben's transparencies were not obtained during the workshop and

could not be attached to these minutes.)

Francesco Cordera of Olivetti proposed that the workshop version of

I? be the non-segmenting subset (ECMA 92) . (Francesco did not use

a transparency or handout, so none is in the attachments.)

John Heafner of NBS proposed that companies intending to implement

IP use the conformance (for catnets) and inactive subsets (for single

subnetworks).

Mr. Gordera objected to implementing segmentation and made the following

recommendations:

1. do not implement segmentation in IP but let X.25 segment

when necessary;

2. not using segmentation allows the IPDU lifetime to be a simple hop count and thus avoids complex timeout routines;

and

3. the IP addressing scheme should be hierarchical with the

structure: domai n/host/net identifiers.

- 2

-
John Heafner responded that X,25 is not the only wide-area protocol

that IP will work over. Others in the audience pointed out that

segmentation is needed to talk to other implementations and that

originating IP entities can turn off the SP (Segmentation Permitted)

f 1 ag at wi 1

1

.

A vote on John Heafner's proposal to implement the conformance and

inactive subsets of IP resulted in 20 for and 2 against - see Attachment

#21. Thus, the proposal was adopted.

The required protocol functions of IP were considered by the group

which voted on those on which there was a difference of opinion

- see Attachment #22.

Optional protocol functions were considered and voted on with results

in Attachment #23 (Note that for Partial Source Routing the vote was to solicit detailed proposals.)

There were two detailed proposals for addressing in Internet: one by

NBS-BCS-BBN (see the Addressing section of Attachment #19) and one

by Dave Oran of DEC - see Attachment #24. It was decided that

participants needed time to study the proposals but that a decision

had to be made at the next workshop. (There may be additional

proposals, but to be considered they must be fully documented with

supporting text and must be mailed to attendees by the end of October

1984.)

At the evening session on Wednesday, September 5, Roy Cadwallader

of ICL gave a presentation and slide show on the activities of

European vendors participating in the ESPRIT Information Exchange

System - see Attachment #25.

On Thursday, September 6, Kevin Mills of NBS provided an overview of

session layer services and protocols - see Attachment #26.

Jim Berets of BBN gave a presentation of the ISO FTAM - see Attachment

#27.

Pat Amaranth of GM proposed an alignment of ISO FTAM with the NCC

'84 version of FTP - see Attachment #28. Paola Bucciarelli of

Olivetti made another proposal for implementing ISO FTAM - see Attachments #29(a) and #29(b).

It was noted that the two proposals are basically in agreement but

differ in the ability to create and delete files. Roy Cadwallader

of ICL also presented an FTAM proposal - see Attachment #30.

Id's proposal includes file access as an enhancement over the

previous demo, and would be implementable for testing by June 1985.

John Heafner of NBS suggested that Olivetti's FTAM proposal be

adopted for the next event and that file access be implemented in a later workshop phase.

- 3

-
The FTAM implementors voted 16 for and 1 against to adopt the Olivetti

proposal as phase 1, i.e., for the next demo - see Attachment #31.

(Note that Olivetti is to provide a document, clearly indicating the

chosen subset of ISO FTAM, for the next workshop,

A discussion was held on the features of the Session protocol to implement

for the next event. Opinions varied from none (Alan Sciacca of

Foxboro), the minimum to support FTAM (Paola Bucciarelli of Olivetti),

the minimum to support X.400 (Joe St. Amand of Wang), to the union of the

minima to support FTAM and messaging (Kevin Mills of NBS). Dick Swee of

CRDS spoke for the need of session, saying that there was no Session

layer in the July 1984 demo and that it was necessary to distribute

session functions between FTP and Transport. Kevin Mills explained that

the union of minima would make it unnecessary to implement features as shown on Attachment #32. Paola recommended the Basic Combined Subset of

Session as on Attachment #33 for supporting FTAM. Olivetti's proposal was voted on and accepted by a count of 19 for and none against - see Attachment #33). Kevin Mills's Session recommendation as on Attachment

#34 was accepted by a vote of 17 for and 2 against.

A question was raised about which documents contain the standards for

Session and FTAM. Kevin Mills stated that DIS 8326 and DIS 8327 were the

current ISO Session documents. The consensus of the group was that the

Olivetti submission.

Ken Dymond of NBS presented estimates of the cost of implementing Internet,

aligning Transport, and of implementing Session and FTP - see Attachments

#35(a), #35(b), #35(c), #35(d), and #35(e). Kevin Mills prepared a slide

comparing Transport Class 4 and full Session in terms of number of

services, states, transitions, etc. - see Attachment #36.

A discussion of the appropriate forum for the next activity was held.

Maris Graube proposed that a show distributed in time and space rather

than a specific event be selected. He explained that a permanent core location could be chosen where equipment would be more or less permanently

running; various remote showrooms could then be connected as opportunity

offered to vendor equipment at the core. Thus, there would be a show

continuously available on demand. Maris prepared a slide which had as event end points the NCC in July 1985 and the Hanover Trade Fair in April

1986; and which further outlined some commitments - see Attachment #37.

A slide of possible demo events was made and an informal vote taken of

those who might participate tn each event to gauge the opinion of the

group.

The event options considered and the straw vote on each are presented on Attachment #38 and summarized below.

9 for AUTOFAC November 1985

1 for COMDEX Fall /Late Summer 1985

4 for INTEC

13 for a Coordinated Media Event October 1985

- 4-
14 for a Coordinated Media Event

2 for NCC

1 1 for Hanover

0 for ACM

March 1986

July 1985

April 1986

October 1985

Maris suggested that John Heafner prepare a form to be circulated after

the conclusion of the current workshop. Attendees are to identify on the

form which protocols they intend to implement and what systems they would

attach long-term to a multi -organization concatenated network - see Attachment #39. The filled out form must be returned to John Heafner by

Monday, October 29, 1984.

Marls Graube called for the opinion of those interested in UNIX and ISO

layered archi tecture. A consensus was reached that ISO layers not be

implemented in the internals of UNIX, but that the interfaces between ISO

layers and UNIX be worked on. Also, the opinion prevailed that UNIX

standards efforts be kept separate from networking considerations.

Art Pope of BBN then gave a tutorial on the X.400 message protocol of

CCITT and a proposal for features of message handling to be implemented

for a demo - see Attachments #40(a) and #40(b). Art noted that his X.400 demo

proposal requires the Basic Activity Subset (BAS) of Session.

Fred Burg of AT&T presented a tutorial and recommendation on the

Subnetwork Dependent Convergence Protocol (SNDCP) that should be implemented

by anyone wishing to run ISO Internetwork Protocol over X.25 - see Attachment #41.

Ross Cal Ion of BBN also proposed a method of using the ISO IP over X.25 - see Attachments #42{a) and #42(b). A motion was accepted to table the

X.25 proposals for consideration by a special interest group to be

organized and coordinated by Larry Brown of AT&T.

The subject of messaging was then raised again and 3 proposals in addition

to Art Pope's (Attachment #41) were made:

Ian Valentine, ICL - Attachment #43

Joe St. Amand, Wang - Attachment #44

Dave Oran, DEC - Attachment #45

Attendees then decided to table the 4 Messaging proposals and to ask Joe

St. Amand to chair an interim meeting of companies interested in the

X.400 recommendation. The resolutions of the interim meeting will be

submitted to the next workshop.

The group unanimously accepted the suggestion of GM and BCS that FTAM be

demonstrated in 2 phases (a reconfi rmation of the decision noted earlier

in these minutes) and that GM/BCS make a detailed proposal thereon

- see Attachment #46.

Maris Graube asked John Heafner to compile a separate document from the

ongoing minutes that lists the technical decisions adopted by the group.

John agreed to do this.

The workshop adjourned at 3:25 p.m. on September 7, 1984.

- 5-
IMPLEMENTORS OF OSI

WORKSHOP SCHEDULE

Att. #1

The following constitutes the. schedule for NBS/OSI Workshops through

Sept, 1985, The dates are firm. The hosts are not confirmed.

Nov. 7-9

Jan. 22'24

Apr, 16 - 18

June 25 - 27

Sept, 17 - 19

(NBS), Gaithersburg, Md.

(HIS), Phoenix, Ariz.

(BCS), Seattle, Wash,

(NCR), Dayton, Ohio

(NBS), Gai thersburg, Md.
ATTENDANCE LIST FOR THE OSI/NBS WORKSHOP

September 5-7, 19£/;

Jtffltt Bertts

BBN

10 Moulton Ste

Combnldge# MA

03338

Geops® Chang

Bel ] Comrpun i cations

6 Corporate P 1

,

Pieeatawayf NJ

0885a

David E, Lawton

ACC

720 Santa Barbara St,

Sant a Barbara# CA

P3101

Mike Seto

ACC

720 Santa Barbara St,

Santa Barbara# CA

93101

Bob Jones

A 1 1 en-QradI ev Co,

747 A ] oha Or,

Hi ghi and Hei ghts# OH

aai39

Laurence Brown

AT&T Bel 1 Labs

190 Ri ver Rd,

Summ it# N

j

07901

K h i em D , Ho

AT&T Inforrration Systems

307 Mi ddl etown-L i nc rof t Rd,

Lincroft# NJ

07738

Dougl as Kni se 1

y

AT&T-Bell Laboratories

1100 E, Warrenville Rd,

Naperv i lie# IL

60566

Lean Theisen

Bell Communications Research

331 Newman Springs Rd,

Red Bank# NJ

07701

Kun Park

Bell Communications Research

331 Newman Soring Rd,

Red Bank# NJ

07701

Peter Lin

BNR Inc,

685 A E, Middlefield Ro,

Mountain View# CA

9a039

Laurie Bride

Boeing Computer Services

P»0, Box 2a346

Seattle# W A 9813a

Ross Cellon

Bolt# BerBdck & Newman

10 Moulton St,

Cambridge# MA

03378

Arthur Pope

Bolt# Bernaek end Newman

10 Moulton St,

Cambridge# MA

03330

1
Jon Beekop

Buppouohi Copp.

P,0, Box 187a . Southoastapn# PA

19398

Philip 3e 1 vaggi

DCA

I860 Wiehle Ay#,

Reston# VA

22090

Riehapd 3wee

Chaplet Rivtp Data Systems

983 Concopd St,

Fpamlnoham# MA

01701

David Oran

Digital Eouipment

1925 Andove St.

Tewksbury# MA

01876

Ppentiss Yates

Clneinnatf MHacpon

Rt, as & Wesbn Rd,

Lebanon# CH

aS036

Jay Jeyabalan

Ford Motor Co.

ScientW^c Research Lab

Dearborn# Ml

a8121

Chaplas Wade

Codex CoPP. . 20 Cabot B1vd«

Mansfield# MA

o2oas

Robert Yee

Ford Motor Co.

The American Rd,

Dearborn# MI

a 8121

Terence Holt

Compucopp

2211 Michigan Aye,

Santa Monica# CA

9oaoa

K.J, Hawanq

General Electric

P.O. Box 8106

Charlottesvi lie# VA

22906

Mary Jane Strohl

Concord Data Systems

303 Bear Hill Rd.

Waltham# MA

02 isa

Ronald Smith

General Electric

aoi N, Washington St,

Rockville# MD

20850

John Weiss

Data General

aaOO Computer Dr,

Westboro# MA

01580

Richard Fribero

General Electric Co,

P.O, Box 8106

Charlottesville# VA

22906

Edwerd Brady

DCA

1060 Wiehle Aye,

Reston# VA

22090

Barry Dal 1 aval 1

e

General Electric FApD

P.O. Box 8106

Charlottesvi lie# VA

22906

8
C«ry Workrran

C«n#r«l Motor!

A/MD-39 12 Mjio & Mound Rotdi

w«rr!n» Ml

asoea

^•©rst Bankfroff

Hontywal

1

900 MHdlese* TurnPfk#

Blllifica^ MA

01821

Karl Sc hoh

1

Cenaral Motor!

30300 Mound Rd# MD/A»39

Warren# Mj

08090

David wnico*

Gould

1101 E, University St,

Urban# IL

61801

Cathy Burnt

Gould

SVS P.O, Box 3083

Andovor# ma

oieio

Andrew Poupart

Gould Computer Systems

6901 W, Sunrise Blvd,

PI ant at Ion# FL

33313

Raj Khurena

GTE

1700 Research Blvd,

Rockville# MD

20850

Carl Pfeiffer

GTE Government Systems

1700 Research Dr,

Rockvl lie# MO

20850

Rooar Thompion

IBM

1501 Cali f orni a Ave

,

Palo Alto# CA

90306

A, W, Kleltsch

IBM

PTP, NC

27709

Pat Muivey

IBM

P.O, Box 1328

Boca Raton# FL

93a32

Roy Cadwal 1 eder

ICL

Kldscrove# Staffs

UNITED KINGDOM

ST7 ITL

Ian Rvalentine

ICL

Bracknell Berks

UNITED KINGDOM

RG 12 IXX

Frank Hsu

Intel

3200 Lakeside Dr.

Santa Clara# CA

95051

Lyle Welman

Hewlett Packard

19^120 Homstead Rd,

Cupertino# CA

950ia

David Potter

Interlan Inc,

3 Liberty Way

Weatford# md

01886
B«n Potter

International Computer Ltd,

London Street

Reading Berkar LONDON

Debra Tang

NBS

Bldg, 225, Rm. 3226

Gal t hersburg, MD

20699

Sudhi UmarJI

ITT Dialcom Inc,

tlOO Wayne Ave,

Silver Spring#

20910

Mike Wall ace

NBS

Bldg. 225, Rm. 3226

Gal t hersburg, MO

20899

Ray Oenenbero

Library of Conoreei

Network Development Office

Waahinoton# DC

20540

Robert Rosenthal

NBS

Bldg, 225, Rm 0226

Gal thersburg, mq

20899

Jim Clarkson

Motorol

a

2900 South Diablo Way

Tempe# AZ

85282

John Heafner

NBS

Bldg, 225, Rm. 6218

Gel t hersburg, MO

20899

Stephen Nightingale

N6S

Bldg. 225, Rm, 0218

Gaithersburg, mq

20899

Kevin Mt n s NBS

Bldg, 225, Rm, B226

Gal thersburg, md

20899

Ken Dymond

N5S

Bldg, 225, Rm, 0208

Gal thersburg, MD

20899

Wood wiles

NCR

1700 S, Patterson Blvd,

Dayton, OH

45479

Jim Moulton

NBS

Bldg. 225, Rm. 8212

Gel thersburg, MO

20899

David Cdppel

1

NCR Comten

2700 Snel 1 1 ng

Roseville, MN

55113

Bob Blanc

NBS

Bldg, 225, Rm, A231

Gal thersburg, MD

20899

W1 1 1 McDuf f 1e

Network Solutions Inc,

7700 Leesburg Pike

Falls Church, VA

22043

to
P«u1 Mifttpi

Northfpn T«1tcom

2305 Miitioo Colleoe Blvd.

Santa Clara# CA

95050

Oittmar Janatiky

Siamans AG ESTE II

7500 Karlspuhf

GERMANY

Edward B. ^^atthew•

NortHfrn Talacom Inc.

259 Cumbarland Band

Naahvnia, TN

37220

Edward J« O^Connar

Sparry

B©« 500 C2-SEI

Blue Bel 1 # PA

I9a2«

Sartorlo

01 1 vet 1

1

Ivraa (To) 10015

ITALY

Dtrham Eginton

Sparry

2276 Highcrest Dr.

Roseville# mn

S5U3

P. Sued aral 1 1 01 1 vat 1

1

Ivraa (To) 10015

ITALY

J. Gansx

Sperry

P.O. Box 500

Blue Bell # PA

194|a

F, Copdera

OH vatti

10015 Ivraa (To)

ITALY

Richard k. Shifter

Spar ry

P.O, Box 500

Blue Ball # PA

194»|4|

Ml chal a Spina

Priina Computer

500 Old Connecticut Path

Framingharr# MA

01701

Denial J, Ferrara

Sperry

P.O. Box 500

Blue Bell# PA

19429

Ann Jenkins

Prime Computers

Pr i me Park

Natick# MA

01760

Brian Vonn

Square D Co.

4041 N, Richards

Milwaukee# WI

53212

Larry Oaldin

Rolm Corp

30150 Telegraph Rd,

B i rmi ngham# MI

aeolo

Barbara R. Sternick

Systems Development Corp,

7929 Westpark Dr,

McLean# VA

22102

H
Marit Graubf

Taktponf X Box 500

Beaverton# OR ‘ 97077

Atul Bhatnagar

Tektronix Inc#

P,0, Box 500

Beaverton# OR

97077

Dan Moon

Texas Instruments

P,0, Drawer 1255

Johnson Cl ty» TN

37605-1255

Alan Sclacce

The Foxbore Co*

38 Newpowset Ave,

Foxboro# MA

02035

Joseph St* Amand

Wang

1 Industrial Ave*

Lowell, ma

01851

Joseph Holmes

Wang

2 Cross of Commerce

Rollowing Medows# IL

60008

Jagdee Gahlawat

Wang

One Industrial Ave.

Lowel 1 # ma

Clive Everett

Wang

One Industrial Dr*

Lowell# ma

01851

iCU

Herbert 8* Falk

West 1 nghouse

1521 Avis

Madison Heights# MI

A8071

Juan Bulnes

Xerox

3^50 Hillvlew Ave.

Palo Alto# CA

934104

Andrew Huang

Ztel

161 Ball ardual a St * Wilmington* MA

01687
Attachment #3

AGENDA

Seventh Workshop

Open Systems

for Implementors of

Interconnection

Wednesday, September 5 Morning

Welcome and Opening Remarks e.e,...Rob Rosenthal, NBS, IEEE

Opening Remarks by Moderator Maris Graube, Chair. 802

Approval of Agenda .Attendees

Transport: NCC/ISO Alignment ....Jim Moulton, NBS

Transport: Addition of ISO Features ....Jim Moulton, NBS

Internetwork Overview, Services .Jim Moulton, NBS

Wednesday, September 5 Afternoon

Internetwork

Internetwork

Internetwork

Internetwork

Overview, Architecture

Overview, Protocol....

Overview, Addressing..

Proposal s

Implementation Estimates: layer 3, layer 4.........

Ross Gallon, BBN

Dave Oran, DEC

Ross Gallon, BBN

1. 'Laurie Bridge, 3CS

Ross Gallon, BBN

j^ohn Heafner, NBS

2. Karl Scholl, GM

3. Ben Potter, ICL

4. Francesco Cordera, Olivetti

Ken Dymond

Wednesday, September 5 Evening

European Activities: Ray Cadwallader, ICL

Thursday, September 6 Morning

Session Overview, Services and

Session Proposal

FTAM Overview

Protocol . .

.

NBS

NBS

BBN

Thursday, September 6 Afternoon

FTAM Alignment ISO/NCC... , GM

FTAM: Proposals for Addition of ISO Features.......!. Pat Amaranth, GM

2. Paola Bucciarelli

,

Olivetti

3. Ray Cadwallader, ICL

Implementation Estimates: Session and FTAM ..Ken Dymond, NBS

Thursday, September 6 Evening

Determine & Schedule Second OSI Activity. Attendees

13
Friday, September 7 Morning

X®25 Network Dependent Convergence

Protocol Proposal s «, a e ® o .. o ® e e o o o e o o . o ...... c o .1

.

F rod Burg, Bell Labs.

2. Ross Gallon, BBN

Friday, September 7 Afternoon

400

400

Series Overview.

Series

eoe«eoeooo««e9»o«e ...Art Pope, BBN

Art Pope, BBN
Attachment #4

TENTATIVE AGENDA FOR EIGHTH OSI WORKSHOP

Welcome by host organization

Opening Remarks by Moderator Maris Graubej Tektrom”

Approval of Agenda Attendees

1. Responses to NBS Questionnaire John Heafner, NBS

2. ISO Update NBS

3. Resolution of Internet Proposals

a. Addressing

b. Routing

4. Topologies

a. Proposals for networks supported by demo

b. Proposals for addressing support of accepted

topologies

5. FTAM

a. Presentation of Phase 1 specification Olivetti

b. Proposal for Phase 2 BCS/GM

c. File naming proposals (sol 1 cited)

d. Data transfer facility GM

6. X.25

a. Selection of a proposal Attendees voting

b. Determination of specific

X.25 networks " "

7, Messaging

a. Selection of a proposal '* " b. Selection of a Session Services '* "

8. NBS Schedules NBS

a. Tests

b. Cooperative testing

c. Neutral site facility
Attachment #5

IMPLEMENTATION INTEREST GROUPS

These interest groups were identified to establish voti ng rights in the

workshops. The organizations so identified have expressed an interest in

implementing the protocols or mechanisms indicated. There is no expressed

or implied corporate committment at this time to actually provide

implementations. The above statements apply to Attachments #6 through

9 .
GENERAL INTEREST PROTOCOLS

Attachment #6

The organizations named below have expressed an interest in implementing

one or more of the following: IEEE 802.2, IEEE 802.3, IEEE 802,4, NBS/ISO

connectionless IP, NBS/ISO transport class 4, ISO session subset, and/or

ISO FTAM subset.

Also, indicated is whether the organization would implement an end“

system, an internetwork systems or act as a user.

ORGANIZATIONS VOTING TO IMPLEMENT

PROTOCOLS

ORGANIZATION END-SYSTEM INT. -SYSTEM USER

ACC X AT&T Information Systems X

A1 len-Bradl ey X AT&T X Bell Communications Research X Boeing Computer Services X Charles River Data Systems X Codex Corp.

Concord Data Systems X Data General X Digital Equipment X Foxboro X General Electric - FAPD X General Motors

Gould Computer Systems X Gould Prog. Cont. Div. X Hewlitt Packard X Honeywell X IBM X ICL X Motorola X NBS X NCR X NT X Olivetti X Square D X Tektronix X Texas Instruments, ISD X Westinghouse X

X

XX

X

X

X

XX

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X (applications)

ABSTAINED

X

X

X

/7
Attachment #7

ORGANIZATIONS INTERESTED IN IMPLEMENTING A

NETWORK DEPENDENT CONVERGENCE SUBLAYER PROTOCOL BETWEEN

A-B

ATT

CONCOD

D .Ga

GOULD

ICL

X,25 AND ISO C-LESS IP

INTEL

NBS

NCR

NT

OLIVETTI

WANG

%

COORDINATOR: Laurence Brown AT&T

(201)522-6046
Attachment #8

NAME

Bankeroff, George

Bhatnagar, Atul

Cordera, Francesco

Oymond, Ken

Everett, Clive

Falk, Herb

Heafner, John

Huang, Andrew

Jeyabalan, Jay

Jones, Bob

Knisely, Doug

Masters, Paul

Matthews, E.B.

O'Connor, Ed

Pfeiffer, Carl

Potter, Ben

Vonn, Brian

Wade, Chuck

Wei man, Lyle

Wiles, Wood

Workman, Gary

Yates, Prentiss

SPECIAL INTEREST GROUP ON

ROUTING PRINCIPLES

COMPANY PHONE

Honeywe 1

1

Tektronix

01 i vetti

NBS

Wang Labs.

Westi nghouse

NBS

Ztel

Ford Motor Co,

A1 len-Bradley

ATST

NT

Northern Telecom

Sperry

GTE

ICL

Square D Codex Corp.

HP

NCR

6M

Cincinnati Milacron

(617) 671-7476

(503) 627-6833

39(125) 525 ext. 1339

(301) 921-2601

(617) 967-2417

(313) 588-1540

(302) 921-3537

(617) 657-8730

(313) 322-3952

(216) 449-6700

(312) 979-7344

(408) 353-3819

(615) 256-5900

(215) 542-5937

(301) 294-8514

44»734-586244

(414) 332-2000

(617) 364-2000

(408) 725-8111

(513) 445-6635

(313) 575-0632

(513) 494-5367

*The coordinator is Dr, John Heafner of NBS
Attachment #9

SPECIAL INTEREST GROUP ON CCITT X;400

DRAFT RECOMMENDATIONS

Ho, Khiem AT&T Inforhnation Systems (201) 576-6227

Masters, Paul Northern Telecom (408) 988-5550

Morgan, John GE Information Services (301) 294-5556

*St, Amand, Joseph Wang Laboratories (617) 967-5506

Swee, Dick Charles River Data Systems (617) 626-1000

Valentine, Ian ICL +44 344 424842

*The coordinator is Joseph St, Amand

^0
4-loU)

TRANSPORT PROTOCOL

Alignment Changes

There are two changes necessary to bring the demo version In line with

the ISO specification:

1. Octet Ordering - the order of octets in multi octet binary fields

has been changed from least significant octet first to most

significant octet first.

2. Parameter Code - the value of the flow control parameter has

been changed to 1000 1100 make It unique (it had the same value

as another parameter).
Protocol

t‘ OCTfT OR0tt.#Ad^

•fitoM Uas* sijn.Pe^A/r r% A«©tr v«^,PccA'i

feT 14 ^»ui r<'«a%T a/r -

t. pAAi^M€7^4. Co®€

»Ft©W Co«TRdt PARA/yitTTfC CnAa)^^©

fooo (loo
///.

TRANSPORT PROTOCOL

Added Features

There were two features of the transport protocol which would enhance the

demo version:

1. Expedited Data - The expedited data service and the associated

protocol mechanisms were not included in the demo, for the next

demo it would be appropriate to include expedited data especially

considering the multinetworlc approach,

2. Negotiation During Connection Establishment » for the first

demo, parameter values were selected to avoid negotiation. In

the next demo it would be approppriate to include full parameter

negotiation utilizing the connect negotiation rules.

^TfOU

3 . rsou
m*!»

Tj^ANSPoct

AOO(TO FOkT^j^^TS

i. Expeoireo Data

•« H

* O/VJC uAiACiCep AT A TiMr

• HAY oveftTAvcT rsjoA/MAU DATA

2. fOc^oTj A*noAi Ou<%/A}^ Co^^wtfcr^cAi €*srAdU5^A<fA»r

* Potu«w XSo (iuUs

- TPOm %t?t,

- w*t€ op €hP€0/7TQ

• QOS 9fiAAMe7f4.f

" «St oF CnrcKSM/H

nrs Do '^C'&s’

QoS

pcj"

\z oc^U.'h

T fi'/tXjtrT

0unA

hiiA.

Ab>«. i/«.luas

T» iMrestwe^

i^cM^sir A-FTSi» Se^js.

9

>
H*1}

(t/3i

'T?^ "SI if

ITSO

OPnoA^c

Q if 4^^*fAifO

°D€mq

a/3i ca.V>fiU; wsgsl W

«^l«

^ S/“9

Cryife/u

Tfeu,

Sit

^ U8 Au-ow WHU# ?iir m

^

AiUjAYf AilT^. OouM> T?e«4* PettftW -AmI^S

S^cuJunr oPn«MOAC- wSF/^

OtPirvc4

^oTVi <VvVXS\

rs*V vx.^^

ACU. TiMc CP*no<kjAu

*rt\AA

PavoA,^

"TAjOa^Ht ]

oAtioMiw

Ah iMf

A*«(T 9fMO m CATPOUfc j

I'f

A«CflMt4

H«94aiC4*iw€'i

'^UtysArkV^VvAA on

AfjuAiVi'^ 'Alt

^ ty»«A.l% Vt

o0o\^ C9^%/vt.Vc

^\A.t04Som 'f A4gixtS^A^

Cr$o

Acri m CA^'TPSVX;

'|noAt I?

CX50 s )

ys^

^ ^

Aiw T?

oAX^wooJk^ 'b»^ X5 ^ Aaa^aA

ULiCt. "^OwS-A. '*S Q^TiOA^AU

CA-T^Oa* TfDU^

^ if^pbewcnW-^on »kow»-U

Ttr^ °, CO.V pAtpOA*-^

4©

(oAWti bM ISO ^>-UO
Internetworlc Protocol

Services Provided

The internetwork protocol (IP) provides a connectionless service. That

is to say, it does not depend on the establishment of connections or

virtual circuits between peer entities. The service provided is on a per request basis. There is no explicit or implicit relationship between

service requests. Additionally, there is no confirmation of success or failure to the service requestor.

Tne service provided by the IP consists of one service interaction:

Associated with the service primitives are Quality of Service Parameters

(QOS). Each parameter describes a characteristic that is provided by the

service.

1. Transit delay « the time between a request and indication,

2. Protection from Unauthorized Access - the extent to which

protection is provided,

t 3. Cost,

4. Residual Error Probability - the likelihood that an NSDU will be

lost, duplicated, or incorrectly delivered,

5. Priority, and

Source Routing - a specification of the path an NSDU is to take.

JC

5.
/f#.

ll.Ccil/^n !i)rt J/C/n^

INTERNAL ORGANIZATION OF THE NETWRK LAYER

DEFINES architectural ORGANIZATION OF THE NETWRK LAYER

'

PROVIDES MAPPING OF ABSTRACT ORGANIZATION TO ”REAL W3RLD"

CCMPONENTS 1 _

IDENTIFIES ANT) CATEGORIZES THE FUNCTIONS PERFORMED BY - NETWORK LA\TR PROTOCOLS

PROVIDES A UNIFORM FRAMEWORK FOR DESCRIPTION OF THE

OPER_\TION OF THE iNfETWORK LAYER

EXTENDS TERMINOLOGY

DE.\LS WITH CCMPLEX "REAL WORLD”
ROLES OF NETWRK LAYER PROTOCOLS

SUBNETWORK I>JDEPENDENT CONVERGENCE PROTOCOLS (SNICP)

OFFERS OS I NETWORK SERVICE ON SUBNETWORK

INDEPENDENT BASIS

MAY BE INTERNETWORK PROTOCOL, SET OF RULES FOR

COORDINATING SUBNETTORK SERVICES. OR NULL

SUBNETWORK DEPENDENT CQN\T:RGENCE PROTOCOLS ( SNDCP )

- PROVIDES SERVICE REQUIRED BY SNICP, OR

PROVIDES OS I NETWORK SERVICE

- OPERATES OVER SHkc? I

- MAY BE:

- EXPLICIT PROTOCOL

- SET OF RULES (E.G., FOR RUNNING CLIP OVER X.25)

- NULL
ROLES OF NETWRK LAYER PROTOCOLS (CONT'D)

SL'BNETWRK ACCESS PROTOCOLS (SNAcP) : _

- \VHATEVER IS USED TO ACCESS A SPECIFIC SUBI^ETWDRK

- MAY BE:

- EXISTING SUBNETWRK PROTOCOL (ARPANET 1822, .,-7)

- ST.^NDARD PROTOCOL (X.25, ...)

- NULL ( IEEE 802, , . , )

- PRESENT ONLY DLTRING CONNECTION EST.ABLI SiftffiNT AND

TERMINATION (X,21)

- OR ...

GENERALLY

- AT LEAST ONE NETTORK LAYER PROTOCOL MUST BE PRESENT

RECURSIVE USE OF PROTOCOL ROLES IS POSSIBLE
APPROACHES TO NETWRK LAYER INTERCONNECTION

HOP BY HOP ENHANCEMENT

- SNDCP INDIVIDUALLY ENHANCES EACH SUBNETWRK IN A

CHAIN TO OFFER OS I NETVSDRK SERVICE

- SNICP CONSISTS OF RELAY AND ROUTING RULES FOR

CONCATENATING SUBNETVORK SERVICES

- COULD IN PRINCIPLE BE CONNECTIONLESS OR CO>(NECT I ON -MODE

- IMPLICIT CONNECT I ON-M3DE (X.25) ORIENTATION

INTERNETWRK PROTOCOL

- OPERATES AS END-TO-END PROTOCOL

- SUBNETWORKS MAY BE DIVERSE

- SNDCP MAY BE REQUIRED IN SCME CASES (E.G.,

RULES TO MANAGE X.25 CONNECTIONS)

- COLT-D IN PRINCIPLE BE CONNECTIONLESS OR CONN-ECT I ON -xMDDE

- CURRENTLY IMPLICITLY INTENDED FOR CONNECTIONLESS

PROTOCOL (DIS 8473)

lOOTNL DOCLMENT GIVES EQUAL TREATMENT OF BOTH APPROACHES

JO
EXAMPLE ARCHITECTURE FOR INTESNETWDRK PRCfTOCOLi:

SNICP < —> CONNECTIONLESS INTERNETWORK PROTOCOL :t I SO DI S 8473 )

{ NULL (OVER LANS)

SNDCP <--> < RULES FOR CONNECTION MANaGEVENT," ETC (OVER PDNS

)

I ETC ...

SNAcP < ss > NULL (OVER LANS)

X.25 PACKET LE\EL ( 0\ER PDNS)

ETC . .

.
N>
Use

of

Internetwork

Protocol

for

Interconnecting

Local

Area

Hetwork

with

Public

Data

Network

* * *

50 X

C •

CB

Q> o o

n

50 rr C

5 c- S (9<

3 (D OO I-* 3

O

<

(9nX

N3Us

6

33
Use

of

Internetwork

Protocol

for

Interconnecting

Two

Local

Area

Networks

Via a

Public

Data

Network

* *

*» X c

I—> NJ

(6 VJ1

ca

i-n 03 o n

(9 JO rr c5 t-* 3 (0 3 iO OO I-*

N9Ol

JV
CONNECTIONLESS INTERNETWORK PROTOCOL

OVERVIEW
PROPERTIES

f DRAFT INTERNATIONAL STANDARD

• CONCATENATION OF DIFFERENT SUBNETl^ORK TECHNOLOGIES

i SIMPLE. EFFICIENT PROTOCOL
SERVICES

• PROVIDED TO TRANSPORT LAYER

- UNIT DATA SEND

- UNIT DATA RECEIVE

• PROVIDED BY THE NETWORK LAYER

- UNIT DATA SEND

- UNIT DATA RECEIVE

• PROVIDED BY THE LOCAL ENVIRONMENT

- TIMER REQUEST

- TIMER REPONSE

- TIMER CANCEL

I

31
REQUIRED PROTOCOL FUNCTIONS

• PDU COMPOSITION

• PDU DECOMPOSITION

• HEADER ANALYSIS

f LIFE TIME BOUNDING

• ROUTING

f FORWARDING

• SEGMENTING

• REASSEMBLING

i DISCARDING

9 ERROR REPORTING

9 ERROR DETECTION

9 PADDING
OPTIONAL PROTOCOL FUNCTION

• SECURITY

• SOURCE ROUTING

• ROUTE RECORDING

• QUALITY OF SERVICE

3i
PDU STRUCTURE

f FIXED FIELDS

• ADDRESSES

• SEGMENTATION

• OPTIONS

t USER DATA

PDU TYPES

f DATA

• ERROR REPORTS

^6
FORMAL DESCRIPTION

• EXTENDED FINITE STATE MACHINE LANGUAGE

• STATE TRANSITIONS PLUS PASCAL

• MODELS A SINGLE SERVICE REQUEST

CONFORMANCE

• FULL PROTOCOL

CHECKSUMS

• OVER THE HEADER ONLY

• GENERATING CHECKSUMS

• CHECKING CHECKSUMS

• ALTERING CHECKSUMS
NETWRK LAYER ADDRESSING

CONCEPTS AND TERMINOLOGY

PRINCIPLES FOR CREATING THE NETWRK LAYER ADDRESSING SCHEME

NETWRK ADDRESS SEMANTIC STRUCTURE

REPRESENTATION AS BINARY AND DECIMAL

RELATIONSHIP BETWEEN SEMANTICS. REPRESENTATION. AND ENCODING
BASIC PRINCIPLES OF THE

NETWRK LAYER ADDRESSING SCHEVIE

HIERARCHICAL STRUCTURE OF NSAP ADDRESSES

- ROUTING

- AEMINISTRATION OF ADDRESS SPACE

- MULTI-LEVEL HIERARCHY

- CONCEPT OF ADDRESS ’’DCMAINS” AhJD ” SUBDCMA INS '

GLOBAL IDENTIFICATION OF ANY NSaP

ROUTE AND SERVICE TYPE INDEPENDENCE

BINARY' AND DECIMAL ADDRESSES ACCOvMDDATED

variable length addresses UP TO a DEFINED MAXMM SIZE
NETWRK ADDRESS SEMAOTIC STRUCTURE

INITIAL DCMAIN PART ( IDP

)

- AUTHORITY AND FORMAT IDENTIFIER (AFI)

- CONVEYS FORMAT, LENGTH, AND ’’ABSTRACT SYNTAX”

OF THE REST OF NSAP ADDRESS

- SPECIFIES AUTHORITY RESPONSIBLE FOR ALLOCATI>JG

THE INITIAL DCMAIN IDENTIFIER

- INITIAL DCMAIN IDENTIFIER ( IDI )

« FOLLCKVS ONE OF EIGHT FORMATS

(SEE NEXT VIEWSRAPH)

- SPECIFIES THE NET^RK ADDRESSING SUBDCMAIN FRCM

^HICH values OF THE DSP ARE .ALLOCATED

- SPECIFIES THE AUTHORITY’ RESPONSIBLE FOR

ALLOCATING VALUES OF THE DSP

DCMAIN SPECIFIC P.ART (DSP)

- SEMANTICS IS (LOCALLY) SIGNIFICANT IN THE CCS^TEXT

SPECIFIED BY THE IDP

- MAY BE BASED OS DECIMAL, BINARY, CHARACTTER, OR

-NATIONAL CHARACTER”
INITIAL DOMAIN IDENTIFIER FOiSvlATS

X.121-DTE

- IDI IS AN X.121 ADDRESS (UP TO 14 DIGITS)

X. 121 -DCC

- IDI IS AN X.121 DATA (X)UNTRY CODE (3 DIGITS)

F.69

- IDI IS A TELEX NIMBER ( UP TO 8 DIGITS)

E.163

- IDI IS A TELEPHC»IE NETWORK (PSTN) NIMBER (UP TO 1 2 DIGITS)

E. 164

- IDI IS AN ISDN NUMBER (UP TO 13 DECIMAL DIGITS)

ISO-6523

- IDI IS ALLOCATED ACCORDING TO ISO 6523. CQNS1STI>JG OF

A 4 DIGIT INTERNATIONAL CODE DESIQslATOR ( ICD) , FOLLOWED

BY UP TO 28 DIGITS DERIVED FRCM AN ORGANIZATION CODE

ISO-6523-ICD

- IDI IS ALLOCATED ACCOIU3ING TO THE ICD FRCM ISO 6323

LOCAL

IDI IS NULL (FOR USE IN A CLOSED COMMUNITY)
RELATIONSHIP BETWEEN

SEMANTICS, REPRESENTATION, AND ENCODING

WHAT HAVE WE STANDARDIZED?

- SEMANTICS:

- AFI (TWO DECIMAL DIGITS)

- IDI (VARIABLE DEPENDING ON AFI, DECIMAL DIGITS)

» DSP (VARIABLE. BASED ON DECIMAL, BINARY, CHARACTER,

OR NATIONAL CHARACTER)

= PURE DECIMAL REPRESENTATION

- PURE BINARY REPRESENTATION

- ALGORITH^IIC TRANSFORMATIONS

WHAT IS ENCODED IN PROTOCOL HEADERS?

- UP TO PROTOCOL DEFINITION (NOT ADDRESS STANDARD)

- MUST CONVEY SEMANTICS OF ADDRESS STRUCTURE

- MAY USE PURE DECIMAL OR BINARY REPRESENTATION

- MAY DEFINE OTHER WAY TO CCX'IVEY SEMANTICS

(E.G., SHORTHAND FOR LCXIAL ADDRESSES

)
ACCCMVO3ATI0M OF BINARY AND DECIMAL

BINARY OR DECIMAL ADDRESS ISSUE HAS BEEN CCNTROVERSIAL

- IEEE 802 AND MANY PRIVATE NETWRK ADDRESSES BASED

GN B INARY

- X.121. PSTN, AND TELEX ADDRESSES BASED ON DECIMAL

DECISION TO ACCO^^DATE BOTH

- ADDRESS IDP (AFI AND IDI ) BASED ON DECIMAL

- DSP BASED ON DECIMAL, BINARY, CH.ARACTER, OR NATION.^L

CRAR.-\CTER

- EVERY address CAN BE FULLY REPRESe^ED IN BOTH

PURE BINARY A>® PURE DECIMAL

- ALGORITIMIC CONVERSICN BETWEEN PURE BINARY AND PURE

DECIMAL I EPRESENTATI(»IS DEFINED

INTERNETWRK PROTOCOL USES BINARY' REPRESENTATION, CARRIES

DECIMAL BASED FIELDS AS BCD

- TRANSFOIMATK^JS NOT REQUIRED IN THIS CASE

^7
Proposal for a Useful Connectionless Internetwork Protocol

BASIC PROPOSAL

The conformance (full) protocol Is proposed according to the ISO D.I.S.

for the Data Communications Protocol for Providing the Connectionless-mode

Network Service. (See the attachment on Conformance and the Provision of

Functions for Conformance, extracted from the D.I.S.)

It is proposed that only type 1 functions be Implemented for a timely

and useful service. (See the attachment on function types, extracted

from the D.I.S.)

SUBNEmORk USER DATA

If source and destination end systems are on the same 802.3 or 802.4

subnetwork, then the same size restrictions as applied to the 1984 NCC

demo should prevail. (In this case, the Inactive Network Layer Protocol

Subset is being employed.) If the full protocol is being used to

concatenate subnetworks then the maximum user data size of 64+K should be

permitted, corresponding to the IP specification. Practically, no statement need be made about minimum user data sizes, since it is expected

that the transport class 4 header and transport user data will be of nontrivial length.

PDU LIFETIME

For purposes of concatenating LANs, typically an intermediate system

might subtract one from the lifetime field. This represents 500 milliseconds

for transit between intermediate systems and processing by one intermediate

system. Thus, it is recommended that source end systems insert an initial

value corresponding to the width of the catnet plus two. This should

safely allow the destination end system to process the received POU.

For purposes of a useful exercise it is recommended that fixed routing

tables be used. It is suggested that implementations provide operator

control to manipulate routing tables, since the exact topology for any

demonstration may be subject to last minute modifications.

ROUTING
SEGMENTATION AND REASSEMBLY

* 2 •

Destination end systems must be able to reassemble® Source end

systems must either fit the transport POU plus IP header into a single

subnetwork service data unit or be able to segment® Reassembly by

Intermediate systems Is not recommended » however they must be able to

segment. Setting of the segmentation permitted flag should be at the

discretion of the source end system, however It Is suggested that the

flag be set to allow segmenting.

ERROR REPORTING '

"

NOTE: THIS RECOMMENDATION AMENDS AND STRENGTHENS THE SASIC PROPOSAL

SECTION REGARDING CONFORMANCE. If the error report flag is on and a PDU

of type 3 Is discarded because it is not supported, then an error report

should be returned even though this is not strictly required for conformance.

This Is recommended for purposes of debugging. It is further suggested,

for debugging, that implementations log all error reports. The error

report data field should contain the entire errant POU, truncated only

If necessary.

IDENTIFICATION

The protocol id. of 1000 0001 is used in the catnet situation with a version number of 0000 0001. For the single subnetwork case, the protocol

id. Is 0000 0000.

CHECKSUM

Although checksum of the header is optional it is recommended that

the checksum be used, since emphasis should be on a useful IP rather than

simply on a demonstration. It may also be useful for debugging. '

ADDRESSING

Binary representation should be used, since the IP header is binary

based. (See attached table from the ISO d.p. on addressing.)

TOPOLOGIES

Various topologies are considered below. LAN refers either to 802.3

or 802.4, interchangeably. WAN refers to PON X.25, 1984. Pri refers to

any private (vendor propritary) subnetwork.
- 3 -

Cases considered:

a) LAN

b) LAN-LAN

c) LAN-WAN-LAN

d) WAN-LAN

e) Pri-LAN

f) LAN-Pri-LAN

g) Pri-WAN-LAN

LAN Addressing

The Inactive Network Layer Protocol subset is used with identifier

of 0000 0000.

LAN-LAN Addressing

Source and destination addresses in the IP header are of

identical construction. The first octet is local binary, hexidecimal

49. The second octet is the subnetwork identifier. Assign 802.3

LANs beginning with 0000 0001 and 802.4 LANs beginning with 1000

0001. Octets three through eight comprise the 48 bit station address.

Octet nine is the 8 bit network service access point.

LAN-WAN-LAN Addressing

Source and destination addresses are of identical construction.

The first octet is hexidecimal 49, signifying local binary format.

The subnetwork identifer octet, interpreted by intermediate systems

via a routing table, yields an X.121 DTE address. The subnetwork

identifier octet is followed by a station address and NSAP as described in the LAN-LAN case.

WAN-LAN Addressing

Considering the source address on the LAN and the destination

address on the WAN, the source address has the format described in

the LAN-WAN-LAN case. The first octet of the d estination address is

hexidecimal 25 (X.121 DTE, binary). Octets two through eight encode

the 14 decimal digit X.121 DTE address in BCD. Octet nine is the NSAP.

Where the LAN is the destination and the WAN the source, the

above format is reversed.
- 4 -

Pr1-LAN Addressing

If source end system Is on the private subnetwork and destination

end system on the LAN, then the source address Is; hex1dec1ma1 49,

subnetwork Identifier of the LAN, station address of the gateway, followed

by the private address of the source end system on the private subnetwork

(The private address on the private subnetwork Is Interpretable only by

the private subnetwork.) Note that the three Items preceding the private

address specify the Intermediate system coupling the private network and

LAN. This constitutes routing, not addressing. This may be useful for a demonstration but Is not recommended as a general solution. The destination

address is: hexidecimal 49, subnetwork identifier of the LAN, station

address on the LAN, followed by the one octet NSAP. For POUs traveling

from LAN to private subnetwork the formats are Interchanged,

LAN-Pr1»LAN Addressing

This structure Is the same as the LAN-WAN-LAN addressing.

Pr1-WAN«LAN Addressing

Where the source end system is on the private subnetwork, the source address is hexidecimal 25, seven octets of X.121 address of

the gateway between the private and PDN subnetworks, followed by the

private subnetwork end system address. Here again, the X‘25* and

X.121 address specifies particular routing information. It may or

may not be desirable to do this for. a demonstration, but it is not

advised as a general solution. The destination address is hexidecimal

49, the LAN identifier, the station address, and the NSAP, PDU flow

in the reverse direction formats the source and destination addresses

in the opposite format.

If the format is hexidecimal 25 then the X.121 address is either

this system's or some other system's. If it is this system's, then

Interpret the information after the X,121 address. If it Is some other

system's, then send to the PDN.

If the format is hexidecimal 49 then check the subnetwork address.

If it is some other subnetwork's then look up In the routing table. If

it is this subnetwork's then broadcast it on this LAN,

ROUTING TABLE LOGIC

yv

Attachment
PAGE 70

COKTORHANCZ

For conformaacfl Co this locernacional Scandard, Che ablllcj co

origlnaCe, manipulace, and receive PDUs in accordance wich Che

full prococol (as opposed co ,Che ’’non-s egmencing " or "InacCive

NeCwork Layer 'ProCocol** subsecs) is required. •

Addi cioaally , Che provision of Che opcional funccicns described

in Section 6.17 and enuaeraced in Table S--! busc seec Che

requireaenes described cherein.

AddiCionally , conforaance Co Che Standard requires adherence to

the foraal description of Section 8 and to Che structure and

encoding of PDUs of Section 7.

If and only if the above requireaenes are net is there

conforaance to chis International Standard.

.PROVISION OF FUNCTIONS FOR CONFORHANCE

The following table categorizes Che functions in Section 6 wich

respect to the type of systen providing the function:

Function Send Forward Receive

. PDU Composition M

PDU Cecoaposi tion M - M

Header Format Analysis - M M

PDU Lifetime Control M I

Route PDU - M - Forward PDU M M - Segment PDU M (note 1

)

- Reassemble PDU - I M

Discard PDU - ' M M

Error Reporting - M \t PDU Header Error Detection M M M

Padding (note 2) (note 2) (note 2

)

Security — (note 3

)

(note 3

)

Complete Source Routing - (note 3

)

- Partial Source Routing — (note 4

)

- Record Route - (note 4

)

- QoS Maintenance (note 4

)

•

Table ,9-1. Categorization of Functions
PAGE 23

Table 6-1 shows how the fuacClons divid«4 late €h«s« eh“r««

cacegorles:

Function

PDU Composition 1

POD Decomposition 1

Header Format Analysis 1

PDD Lifetime Control 1

Route PDU 1

Forward PDU 1

Segment PDU 1

Reassemble PDU 1

Discard PDU 1

Error Reporting 1 (note 1) —

PDU Header Error Detection 1 (note 1)

Padding 1 (notes I & 2)

Security 2

Complete Source Routing 2

Partial Source Routing 3

Priority 3

Record Route 3

Quality of Service Maintenance 3

Table 6-1. Ca cego ri za tion of Prococol FuacClons

Notes

1) While the Padding, Error Reporting, and Header Error

Detection functions must be provided, they are provided

onlj when selected bj the sending Network Service user.

2) The correct treatment of the Padding function involves no

processing. Therefore, this could equally be described as

a Type 3 function.

3)

The rationale for the inclusion of type 3 functions is chat

in the case of some functions it is more important to

forward the PDDs between intermediate systems or deliver

them to an end-system chan it is to support the functions.

Type 3 functions should* be used in those cases where they

are of an advisory nature and should not be the cause of

Che discarding of a PDU when not supported.
« At i

TA3LS 8-1 ! AFI ALLOCATIONS

00-09 Reserved - »111 not De allocated^-'*

• • 10-19 Reserved for future allocation by Joint

agreement of ISO and CCITT

20-51 Allocated and assigned to tne IDI formats

defined in clause 8. 2. 1.2

52-59 Reserved for future allocation by Joint

agreement of ISO and CCITT

60-69 Allocated for assignment to nev IDI formats

by ISO

70-79 ' Allocated for assignment to nea IDI formats

by CCITT

80-99 Reserved for future allocation by Joint

agreement of ISO and CCITT

8. 2. 1.2 FORMAT AND ALLOCATION OF THE IDI

A specific combination of IDI format and DSP syntax is associated aitn

each allocated AFI value, as summarized in Table 8-2:

TAStg APT Values

'‘N^pSP syn- lOI

/orsac

Ceiiaal ' airary

Craaractar (ISO 646)National

CTiaractar

X.i21-CCC 20 21

X.121-0TE 24 25 •.•.•.•.••26

f.%% 28 29

£.163 32 33 ‘35

j

£.164 36 37

ISO 6323 40 41 42 43

ISO 6523-rcO 44 45 46 47

Local 48 49 50 51

X> ' W7T /

/7a# neea zo asscrlca OSP syntsxos Irwilvlng cnarxtars cr nacjaiaj cnarx^

c/vse IDT fames fias not ossn esCaoJIsfied ana Is far furener seusy

rnuumm
CONNECTIONLESS IP

PROPOSAL

ALL TYPE 1 FUNCTIONS

- COMPOSITION

- DECOMPOSITION

- HEADER ANALYSIS

- LIFE TIME BOUNDING

- ROUTING

- FORWARDING

- SEGMENTING

- REASSEMBLING

- DISCARD

- ERROR REPORTING

- ERROR DETECTION

- PADDING
• OPTIONAL TYPE 2. 5 FUNCTIONS

- SECURITY

- COMPLETE SOURCE ROUTING

- PARTIAL SOURCE ROUTING

- PRIORITY

- ROUTE RECORDING

- QOS
ADDITIONAL RECOMMENDATIONS

• SUBNETVIORK USER DATA

• PDU LIFETIME

• ROUTING

• SEGMENTATION S REASSEMBLY

• ERROR REPORTING

• PROTOCOL AND VERSION ID trs ;» XiO

• CHECKSUM
ADDRESSING

1 - SINGLE LAN

• INACTIVE NETWORK LAYER PROTOCOL

(no ip header addresses)

• 48 BIT STATION ADDRESS

• 8 BIT NSAP

2 - LAN-LAN

• XM9' FORMAT TYPE

• 8 BIT SUBNETWORK IDENTIFIER

9 48 BIT STATION ADDRESS

• 8 BIT NSAP

3 - LAN-WAN-LAN

• XM9' FORMAT TYPE

9 8 BIT SUBNET ID

(table pointer to X,121 DTE address)

9 48 BIT STATION ADDRESS

9 8 BIT NSAP
ADDRESSING cont.

A - WAN-LAN

• LAN-to-WAN

SOURCE: - X' 49'

8 BIT SUBNET ID

48 BIT STATION ADDRESS

- 8 BIT NSAP

DESTINATION:

- X' 25'

- 7 OCTET X.121 DTE ADDRESS

— 8 BIT NSAP

5 - PRIVATE-LAN

• PRI-to-LAN

SOURCE; - X' 49'

8 BIT SUBNET ID

48 BIT STATION ADDRESS

(of intermediate system)

PRIVATE ADDRESS

NOTE; THE FIRST THREE ITEMS CONSTITUTE ROUTING

AND YOU MAY NOT WANT TO DO THAT.

DESTINATION:

- X' 49'

- 8 BIT SUBNET ID

- 48 BIT STATION ADDRESS

- 8 BIT NSAP
ADDRESSING cont.

6 - LAN-PRI-LAN

9 SAME AS LAN-WAN-LAN

7 - PRI-WAN-LAN

f PRI-to-LAN

SOURCE: - X' 25^

- 7 OCTETS X.121 DTE ADDRESS

- PRIVATE ADDRESS

NOTE: THE FIRST TWO ITEMS CONSTITUTES ROUTING

AND YOU MAY NOT WANT TO DO THAT.

DESTINATION:

- X' 49'

- 48 BIT STATION ADDRESS

- 8 BIT NSAP

^0
ROUTING
MATRIX CF TT-E CX>C FROTCCCL INFLEMENTATICN FEATURES

SCUCITED FRC3VISICNS BY GENERAL MOTORS

0. ^^0

POU COMPOSITION

(type 1)

POU DECOMPOSITION

(type 1)

HOR FORMAT ANALY

(type 1)

PDU LIFETIME

(type 1)

ROUTE POU

(type 1)

FORWARD PDU

(type 1)

SEGMENTATION

(type 1)

REASSEMBLY

(type 1)

DISCARD

(type 1)

ERROR REPORT

(type 1)

HDR ERROR DETECT

(type 1)

SECURITY

(type 2)

COMP. SOURCE RTING

(type 2)

PART SOURCE RTING

(type 3)

PRIORITY

(type 3)

RECORD OF ROUTE

(type 3)

QOS

(type 3)

PADDING

(type 3)

IT'FLEMENT

THEN SUPRESSJ

6^ £5 f/s'/rr

REQUIRED PROTOCOL FUNCTIONS

• PDU COMPOSITION

( PDU DECOMPOSITION

• HEADER ANALYSIS

• LIFE TIME BOUNDING C> ^

• ROUTING

( FORWARDING

( SEGMENTING

• REASSEMBLING

• DISCARDING C'Si

» ERROR REPORTING

• ERROR DETECTION

• PADDING

Fe*

Fe«

«9H8,

"3 ;( "Zn/m

S'* ^

33)9

^

S4fT9u»^

PF«vJt»9A3.

^a, 7^3-n*H«r u©^ 9\9ia^zffo F&w® . S&®«, X a4swa<^ #©%<

/y m.c,.
OPTIONAL PROTOCOL FUNCTION

• SECURITY O'i

• SOURCE ROUTING

• ROUTE RECORDING C*

)

• QUALITY OF SERVICE )

(J) Pcrt. tsw**.

j Au'u 3L7/[^

T«'3

«0 **dT W4mT^

Am t‘^TTWH‘9 ^

.*. J«aoT \u

’Z'\t^n 9 ,Sttc|kC3 S-©wTf . &S7aiv#S 12.7^

; 9u(*^9A7 Zr7/c

I ^

(M)

CD

27/c

•M

l>i» A

*<6 ?/y/yy
A C ^AA \^rc>^OSS|

Co c>'a\s ;

0 Cory\^\, uii^U \ttTt.'- ( a'lA "Soir;-^ -

;

-.C -/cr^ h- . 0 - i„SC) 0. c /* ^

'.‘: ! A

sO rf\aW 6n^-5Y6‘W<t ''eccS^'^

tfVo”V t\e-tied "Vo do ne.aSCrvsw^l’^

% 8t e«y

S) Sc. osakk y)T&cioC'^S

^ fee eTde^sjUU io toco.^pOr^'W.

p^'^ccoV^ c.<^ ^) >4«-o>oOJi UA>* C.l-Jja7®x

^ SU^JI^ OMr'n 9f>»^

(^O'
rO *Rov5^1 ''<

* C'a:^e‘.oe^ )vi>€ if*4:lc V tnco 0

"f

P

'•6<r\|€5

to ail (Se.'itwaYS Kl«rs.^«i>;es.l

cHe/otH p^V,i^ d«Sif<<l

i-ssVe^N^ ^now "two places oP ^>T0<' rm-ll oo

^ prtort '.

0 "TTietr ouA Ccof-ipl^e) <\<iAreS-S

^ TKc e,^ ^

€c^cto^

r

c

f^<i 5ssr©v\j Roode c>s ^olleuS;

K5S5«i-5;a<. < ILjsiU

and r>© ”n>cn

% IaosC^vOC

50.^ \i6\«^

5l^<^ ^o\\ HccJ^ r % GccVCK^a7

D6 *ikky
• noA-tS OO e. LRKJ hfX's-e. Wast (yt<.

CkAAress oV* 4oc(«^ ;

ftPi-- Tc.is-'Cre / i5wrt i>sf

lb^.» XU\ WiresS

T«P - 3ie€€ LfiXJ cidrfss

+ ^ octtr

* lsioAc5 <X tnay C>5e. ».Um«

W LRKi oAi^rtii 'M rn>+ <4S\§,t^e«l

^

V5oi« Oo

y

bvj4 txA C)0 a, LfyV^

Xr>Ky U '' -faked \3^.'' to W?.

^

Ass'i<,r> pn€n 1 cP

> c^rc. CJvSSijo^i XA'll adArc^*^

Lf^lO c>rc c^s^i^DeJ "iV)^ V/l^^

cc&<"4>‘^ 4o "^q P^ oi«.o Oy

OO fA/o^
One ^1 o6se£.

Cc^ft Itfl. ptr4 0-p «(ic}re<i)

T<^»^ Sci"eu%v

» K)e>\ po««;U€ oo

Easy 0*^ LfHi via Qe^Uity tvTol^Ctsf

^<) l^ci''^ OT Qe.\zufi.yi

• po-s&iU«

* £<\Sy ©n U^lO \},t^ QcW«^ •‘loHiCvi'T

C Sea R.

Co-%/y»

• ^ei’cacJ" Qwa£(iu5 P^D

• Rtoarse ct:^ '?<3r«*{./-(^iA^ !'''T0^

0^ ^/iiA^
C'ase C

0.

^

OsTn^ P^50"5

^o
's,a\

of

fto

Case. "Z

C»%6e 3

oP GC<»'Se. S’

E <2~

^

)^ti(

21 gtf #/4>W
laplfBtntation of OSI pfctocols In tht ESPRIT

Inforaotlon Exchang* Systaa

|y|!S2£3 :

3ITTLEST0N (2)/ R. CAOWALLAOER C3)^

A« DIEOIW <2), M. ELIE (1)^ J, UOVELUCK <1)^

F. LUNG (4), S, NIESS C6)/ S. POZZANA <5)

The Esprit Information Exchange System (EIES) recently

renamed ROSE for "Research Open Systems for Europe" is an

1 n f rast ructure to support collaborative R and 0 projects in

information technology within the European Strategic Program

in Information Technology (ESPRIT) launched in 1934 by the

European Economic Commission. The work is being carried out

by a consortium of 6 industrial partners.

The EIES will provide the electronic mail/ teleconferencing/ document handling and transfer/ file transfer/

remote login services which are necessary for cooperative R and D work.

The project aims at a maximum connectivity of potential

users through the use of Open Systems Interconnect i on ISO

services and protocols/ and starts with an implementation

under the UNIX* operating system.

After a short description of the objectives of the project/ the paper presents the work presently carried out and

planned for the following years. It describes the architecture chosen for the interconnection of local area and wide

area networks/ the addressing scheme used and some considerations is given to the management aspects of the network. Finally the main choices made for the implementation

under UNIX are outlined.

UNIX is a Trademark of Sell Laboratori es

.

August 17/ 1984
arcMtfcturt/ Esorit/ EIES^ 1 molt/Bt ntit ion'/ ' nettaork^

Standard/ UNIX/ istssage handling systtm/ filt transftr*

(1) 3ULL 68/ rout# d# V#f$aili#s * 3P 3

78430 Louv#citnn#s CFRANCS)

(2) SEC SEC Hirst Rtstareh Ctntrt

East lant

U«nb 1 ty

Middlesex HA9 7PP (ENGLAND)

(3) ICL West avenue

<i dsgrove

Stoke-on*t re nt (ENSLAND)

(4) INt^IA Donaine de Voluceau

Rocquencourt • BP 105

73150 Le chesnay (FRANCE)

(5) OLIVETTI Via Jervis/ 77

10015 Ivrea (ITALIE)

(6) SIEMENS SIEMENS AG ZTI SQF 43

Otto Hahn Ring 6

D-3000 Muenchen 83 (RFA)

August 17/ 1934

^3
apchitectur*/ Ssorit/ EI£S/ Imoltmentatlorv# - n«taor)«

standard/ UNIX/ mtssage handling systtm/ file tr'ansfer.

Cl) 3ULL 63/ route de Versailles * 3P 3

78430 Louveeiennes (FRANCE)

€2) GEC GEC Hirst Research Centre

East lane

Wenb ley

Middlesex HA9 7PP (ENGLAND)

C35 ICL West avenue

Ki dsgrove

Stoke-on-t rent (ENGLAND)

(4) IN9IA Doitaine de Voluceau

Rocquencourt - SP 105

78150 Le chesnay (FRANCE)

C5) OLIVETTI Via Jervis/ 77

10015 Ivrea (ITALIE)

(6) SIE.'IENS SIEMENS AG ZTI SOF 43

Otto Hahn Ring 6

D-3000 Muenchen 83 (RFA)

August 17/ 1934
In a first st«9/ UNIX Is used as a starter operating

systtn on different machines from each contractor^ in

order to provide a basis for Initial portable' "develop*

ments. The SOL operating system Is used at^a possible

alternative to UNIX* SOL Is a European UNIX *l1ke sys*

tern developed by INeiA In France^ which offers a UNIX

compatible software environment COIE

August 17# 1934

7

^
1* Introduction

In this section ^e summarise the objectives .of-the EXES

project/ the Implementation strategy and the starrdards to be

Implemented* Later sections discuss In more detail the EXES

ar ch 1 tectur al and 1 mo I enent at 1 on choices* Full details are

contained In the EIES Technical Specif 1 catl ons CEIE S43*

1«1« Functional objectives of EIES

Overall ala of EXES

EIES Is to provide services to the ESPRIT programme/

and will be potentially available to support collaborative P S D projects of other kinds throughout the European Commun1 ty.

It addresses the requirements and recommendations of

the lES Panel Report CISS 32). These can be summarised as providing the following set of services between heterogene*

ous machines and terminals located within the memoer states

with a maximum use of public networks and services:

message passing

document transfer

file transfer

remote login and job execution

software transfer

These requirements have been recently enhanced by the

lES workplan published by the Commission (ISS 84)*

The project Is performed by a consortium of six

partners Bull/ GEC/ ICL/ INRIA/ Olivetti and Siemens with

subcontracts to University of York/ University College Dublin/ and the Stichting Jiathemat 1 ca I Centrum of Amsterdam/ as

a pilot project of the ESPRIT programme.

Project overview

The project Is essentially a software development and

Integration project. It Implements an operational network

providing the services listed In 1*1.1 between the contractors* After a phase of timing and debugging It Is intended

to be made available to all ESPRIT programme contractors and

subcontractors* Its target connectivity is shown in figure

1/ and can be described as follows:

August 17/ 1934
Mgurt 1 - LOGICAL CONNSCTIVITY OF EISS

I I lOTHER RESEARCH |

I NETWORKS I

I I

I

I

I I

I GATE I

|NON«OSI PROPRIETARY | INETWORK ARCHITECTURES f

I ilES

r**— j ad/RinIstratIv#

IGATS I domain

r

• r "1 • • •

1 1 ! _ _ I

1 1 I I

1 1 1 1 r*

1 1 1 1 1 1

1 1 1 11 r "*"i 1 1 1

1 1 1 1 1 1 1 1 1 1 INON-OSI 1 1 1 UNIX 1 I UNIX 1 1 1 NON-UNIX

1 UNIX 11 1 1 1 1 1 ICOMPATIBLE | 1 2 1 OSI

1 NACHINESr

1 1 *1 GATSI

I I

1 {MACHINES I {MACHINES 1

1 I

1 - {

r*r*lMACHIN£S

1 1

1 I

1 1

1

1

1 1

1 1

i

1 1

1

1 1

1 1 1 1 I 1 1— 1 L 1 1 1 1—

no gate 1 -

1

I

\

I I

I

1

!

I

I I ! I (GATE I 4 IGATE |

I .....I

no gate

IPSDN I I PSTN I IPAD 1 I

I ! 1

I I II I ITELETEX 1 {VIDEOTEX MFACSI.MILE |

I I 11 n I

I I II - 11 -1

PIT Telematic services

I I

I asynchronous terminals | jor systems emulating 1 {them I

I ..I

August 17# 1934

-V7
Initial connectivity Is provided between UNIX or UNIX

like systems by UNIX soecific facilities Ccu/vucp) used

over X2S public data networks* This "safeguards

existing UNIX applications for communication (mail^

news •• •)

In parallels an OSI session service interface is

developed/ relying on ISO session and transport proto*

cols and on X25/ in order to give to UNIX the visibility of an ISO Open System.

This allows for the imolementation over this interface

of CCITT/ISO defined applications such as file

transfer/ message handling system •*• and enables communication with non-UNIX systems implementing OSI protocols/ without a need for a gateway function/ as shown

on figure 1/ point 2.

A store and forward service to non cI£S UNIX systems

using PSTN/ is provided through the Stichting Mathematical Centre of Amsterdam/ as shown on figure 1/ point

1/ which already provides this service for the European

UNIX Users Group (EUNET).

Asynchronous terminals/ or systems emulating them/ can

connect through PSTN or the PAD service of PSDN.

PTT telematic services teletex/ videotex and facsimile

will be directly connected up to the point where they

support OSI protocols. Specific gateway developments

will take into account differences/ as shown on figure

1/ point 4.

Connection to proprietary network a rch i t ec tur es not

offering an OSI visibility will be possible through

gateways/ depending upon the needs of Esprit users/ as well as connection to other non-OSI networks of use in

P and D projects/ as shown on figure 1/ point 3.

New applications will be made available to lES users

when needed/ conferencing software/ distribution service/ .... The work of other ESPRIT projects dealing with software

engineering/ such as PCTE/ or other sulajects/ will be

integrated into lES.

New communication media (satellite/ broadband communication/ ISDN/ ...) will be used.

lES will include tools for administration and maintenance/ such as a Control Center/ and a distributed name

server.

August 17/ 1984
‘Flgurt 2 a. EVOLUTION OF THE SERVICES PSOVIDID BY iliS Cytaf 0)

PREPARATORY YEAR 0

UNIX ONL'' —><• UNIX OSl

> PSTN X.25 ETHERNET

NAIL# NEWS

file transfer

UUCP

CU

V21

NAIL# NEWS I FILE TRANSFER!

I UUCP

ISO

TRANSPORT

CLASS 2/3

NAIL# NEWS

UUCP

ISO

TRANSPORT

CLASS 4

LAN

CSNA/CD

I ! ISO i

I tSESSION C3CS) !

I I TR I TR

I I I

I I CL2/3! CL 4

I S I

I I I

i I !

I I X25 I LAN

I I jCSNA/CO!

II ! I

Figure 2 b. EVOLUTION OF THE SERVICES PROVIDED SY EIES IN YEAR 1.

1 1 \

1 N H S 1 FTAM 1

1 1 1

1 .1 1

1 ISO f

I

1 SESSION OAS + 8SS> 1

I

1 TR 1 1 I

1 1 TR 1 SATEWAYS 1

1 CL 2/3 1 1. ,1

1 _ I CL4 ! 1

1

1

1

1

^0 ..I

1

!

1

1 X25 1 LAN 1 1

1 1 CSNA/CD 1 1

1 « 49 9 4» « -1

August 17# 1984
1«2« Phastd lapltutntatlon

Tht Implementation plan for ISO standards alloys a pro*

grtssivt migration of users and appll catl ons^to new services •

In year 0 of the project (1934) the users can use

existing UNIX communi eat 1 on tools uucp/ cu and applications/

such as mall/ on asynchronous or PAD to PAD connection/ to

communicate among themselves* At the same time (see figure

2a) the project develops uuep on an ISO transport/ using X25

NAN or CSMA-CD LAN/ LAN-WAN 1 nter connec 1 1 on/ and a basic ISO

session service and protocol just used by test programs*

In year 1 of the project (1985)/ year 0 developments

are made available to the users who can tnen Interconnect

their UNIX systems through X25 public data networks or to a LAN/ and use the same applications they were using over

asynchronous lines* During this period (see figure 2b) the

project develops new enhanced applications In accordance

with the International standardi satlon/ such as File

Transfer and a Message Handling Systems* This will allow the

distribution of these applications over a set of UNIX and

non-UNIX computer systems*

1*3« List of standards applicable to year 0 and 1 of EIES

general

This section gives a list of all the standard protocols

which are used In the EIES project during year 0 and year 1 of the project*

Presently the set of standards used for EIES is a subset of the set of OSI standards which a group of 12 European

manuf acturers proposes to support in their products* They

will be the basis of the ’•lES standard conventions'* to be

puolished by the Commission*

1.3.2. X.2S

The X*25 protocols used In the EIES project are the

protocols defined for physical link and network layer by

CCITT In its X 25 recommendat i on CCCI 303* The only significant definition for the EIES project is the Network Level

standard: for the Lower Layers no definition has been provided / It is possible to use the data link LAP and/or LAP3

and the physical interface X*21 and/or X*21 bIs/ provided

that tht system is able to connect to all the national X*25

packet switching data networks that are involved In the project*

August 17/ 1934
Th# addressing structure used through tht Network Layer

Is the one defined by CCITT In Its rt co«!aenda 1 1 on X.121#

C C C I 3 0 3

1.3«3* Terainal access

Asynchronous terminal access through X25 networks conforms to X3/ X28/ X29 standards for Packet Assembly

Olsassembly(PAO)#

1«3«4. LA:i protocols and LAH-UAH gateway

The LAN ^-“^tocols used In the SISS project are the protocols descr.i.-d In EC.'IA aO/’SI and 32* Reliable transport

over the LAN 1$ provided by using ISO transport class 4 and

LAN/WAN 1 nterc onnec t1 on Is achieved according to cCNA TR 21

C=CN 213

1.3«5« Internet

The Internet standard defines the protocol to be used

in the network layer 3c to interconnect several Local Area

Networks. The current stable reference Is ECMA92r the

corresponding ISO standard being considered to be insuffici ent ly stable.

1.3.6. Transport

The Transport protocol used in the SIES project is the

one defined in the ISO OIS 3073 ( DIS 8072 for the Transport

Service) ! CISO 72 and 733. In particular/’ class 2 and 3 is

implemented over the X.25 envi ronment /- and class 4 is implemented over the CSMA/CD environment. Special care is taken

through implementation rules to provide for a maximum efficiency of the protocol on the LAN while preserving full conf ormance.

ISO Transport Class 0 will also be implemented in year

1x in order to sucport Teletex.

I.3.7. Session

The Session protocol used in the EIES project is the

one defined in ISO OIS 8327 (OIS 3326 for the session service); the Sasic Combined Subset <3CS) as defined in the ISO

OIS 3327 is implemented CISO 26 and 273 during year 0.

The 3CS includes the following Functional Units;

August 17/ 1984
a) Kffnsl functional unit *

b) half-duplex functional unit/

c) full-duplax functional unit.

Tht full session protocol and services aill be implemented during year 1.

1 . 3 «S« ^933390 handling

1-3.9-

Standards from the X4XX set of CCITT recommendations/

which are now stable/ will be implemented/ namely

X409 Message Handling systems: presentation transfer syntax

and notation

X411 Message Handling systems: message transfer layer

X410 Message Handling systems: Remote Operations and Reliable Transfer Server

X420 Message Handling systems: In t e rpe r sona I Messaging User

Agent Layer.

lo'i.iGfl rile Transfer

The File Transfer and Manipulation ISO draft standard

OP 8571 will be used for the file transfer implementation

under UNIX.

1.3.11. Adaini St rat 1 on

While adrai ni st rat i on is restrained in the first year to

local statistical information gathering/ care is taken that

the information contents is in line with current ISO TC97

SC16 UG4 work.

2. EIES Architectural Choices.

The £I£S Network Architecture is strictly derived from

the ISO-OSI Reference Model / nevertheless/ it was necessary

to make some choices in particular areas such as LANs and

the Global Network Layer/ which are described in this section.

The rationale for these choices has been derived mainly

August 17/ 1934
from cC«A TC24 documents/ In particular/ float of tht definitions used throughout this section havt been taktn frora th#

£C.hA TR 21 CECM 213.

2.1.

LANs In thf EZZS project.

2.1.1.

EIES LANs and th« 0S2 Reforsno® ^od®l®

Ti<o alternative solutions exist for LAM integration in

an OSI environment :

1) A LAM exists as the information transfer means betvetn

the various elements comprising an End System or a number of End Systems.

2) The LAN exists as a subnetwork of the OSI Global network for the purposes of i nt erconnect 1 ng complete End

Sy s t ems

.

EIcS conforms to the rec ommenda 1 1 on of SCMA TR/14 CECfi

143 which defines ''protocol sets"/ to avoid incompatibility

where internetworkingl s required between equipment from different suppliers attached to the same CSi^A/CD baseband LAM

subne t work

.

The project decided to use the ISO 8072/73 Class 4 protocol on LANs/ and to adopt a back-to-back transport class

2-3/class 4 gateway for LAN- WAN interconnection; this

corresponds to Case 1/ retaining the LAM as an externally

invisible component of an End System.

Following this approach/ the gateway between the End

System LAM and the Global Network incorporates a Transport

Layer Relay masking all protocols at and below the Transport

Layer in the LAN.

The Transport Layer Relay is not externally visible; it

may be regarded/ in effect/ as an element of a distributed

form of End System Transport entity externally visible as

any other End System Transport entity.

The orotocols operating on the LAN above the Transport

Layer become externally visible and must conform to OSI

St andar ds

.

2.I.2. End Systt® Archi teeture.

The combination of regarding the LANs as a single End

System and of using the protocols defined in the document

CECM 143 has as a consequence that the EIES view of a LAN in

an OSI network conforms with that described in CECM 213;

August 17/ 1934
som« concepts taktn from this document ar® r$call®d in tha

following.

In such an «nv1ronratnt/ th# End Systara Is- hierarchically divided Into two physical components# the division at

tht layers 5/4 boundary offers a convenient separation of

functions# and It Is attractive to consider an Interface

mechanism based on a LAN using layer 4-1 protocols.

The most important component of the Distributed End

System is the Gateway (called Distributed System

Interuorki ng-UnI t (DSI) in the following).

The DSI conforms to the applicable provisions of ECNA

TS/20 CSCN 205, A DSI# together with its associated distributed End System components# is addressed like a normal End

System) the relay function In the DSI determines the mapping

of the externally known Transport Addresses onto the

addressing scheme used internally on the LAN.

In the case of a connection request made from a system

on the LAN to an external system# the DSI must be given sufficient information for it to determine the Transport

Address of that external system.

2.2. Global EXES Network Layer.

2.2.1. The Network Layer structure.

The Network Layer has the goal of dealing with all the

problems related to the different sub-networks which belong

to the overall network# providing a homogeneous service to

the Transport Layer. The Network Layer is curreritly divided

into three sublayers 3a# 3b and 3c.

An X.25 subnetwork includes a layer 3a with lower

layers# it provides more services than those needed to support the standard global Network Service) all these services

will not be made available to the global Network Service

users in order not to complicate the Transport Proto co l#‘ and

in order to avoid the need for enhancement of any possible

further subnetwork that does not provide these services.

2.2.2. The EIES Network Layer.

The EIES project will use Public Data Networks (PONs)

such as: ITAPAC# EURONET# TSANSPAC# OATEX-P# PSS# etc.)

these follow the CCITT X.25 R ecomraendat i on and are to be

interconnected via relay systems# according to the interface

specified in the CCITT X.75 Recommendation (the interface

between two PONs specified in X.75 is quite similar to that

August 17# 1934
In X.25)

.

Using this addPtssIng facility/ tha HIES network nay

set all the different r»ONs as a single subnet work .

As previously defined/ the EIES LANs are not seen as

subnetworks (or better: are not seen at all) and so It Is

possible to say that the EIES network has only one subnet*

work; therefore/ the Global EIES Network Layer consists of

just a single 3a layer.

3. Addressing In the EIES.

The EIES network uses only standard protocols and con*

forns to them exactly/ when- implementing a re^l network it

1s/ however/ necessary to define a number of details/ taking

Into account the final users requi rements/ the physical configuration/ the kind of service to be provioed and so on; in

doing this/ great imoortance must be given to the definition

of the addressing structure.

In this section the addressing structure of the EIES

network is descrioed/ In particular/ the elements (Names and

Addresses) which are going to be used through the different

layers are specified/ and the transf ormati ons which will

apply to them.

For the first year/ the project is concerned with the

protocols up to the Session only/ therefore only the

addressing problems related to the first 5 layers have been

taken into cons i der at i on; in the following/ the users of the

Session are generally referred to as ”Appli cations’* or

"Users’*.

As a first choice/ it has been decided to support only

a single type of address at the User interface (the Session

Layer interface) to simplify the address mcnagement in the

Communication Layers.

It has to be noted that a single address type does not

impose any real restriction on the Application Layer; the

chosen type is general enough to support any reasonable

addressing policy/ and it is possible to implement Application Level Servers which translate the address type a User

wants to use into the EIES one; such translations will not

be provided during the first year.

3.1. Th® address type at the User Interface*.

Several address types may be taken into consideration

when defining a network implementation ;

August 17/ 1934
a) ?lat Address: an address with no inttrnal structurt

which Is conscructtd without reftrenc® to any lowtp

lay^raddrtss.

b) Hierarchic Address: an address which Is constructed

relative to a Lower layer address; It consists of

the lower layer address plus a selector component

as suffix <1t specifies a Service Access Point

relative to a lower layer Service Access Point).

c) Partitioned Address: An address built from a set of

nested addressing domains which Is constructed

without reference to any lower layer address.

The SI£S project has adopted the hierarchic address

type; this means that/ at the Session Layer Interface/ the

three address elements must be specified which are necessary

to Identify the remote S-SAP/ the remote T-SAP and the

remote N-SAP.

The reasons for adopting this solution are the following;

a) It Is natural/ given the network architecture EIES is

going to have (in particular/ the T-SA? Information is

necessary to indicate to the Remote Transport Layer

which Session Entity on which Distributed End System

Component it is required to connect);

b) It has a general meaning/ so It is easy to map onto It

whichever policy EIES decides to implement at Application Level;

c) It is easier for the communication software to manage

such an organization because the translations are Halted to the ralnimumy and they are only on a one-to-one

basis (names to addresses).

3.2. Addressing and Nasing in the Coaauni cat Ion Layers.

The address elements which are passed through the

Interface with the upper layer are described/ then an explanation of their use Is given/ including the transformations

which are applied to them.

A set of definitions is listed below in order to make

clear the symbolic addressing names used in the following;

- A = Session User;

- 3 = Transport Service User in the LAH;

(host in the LAN + TS user on the host)

August 17/ 1934
c » sitt;

3C = Transport S«rv1c« Usor in th® global network/

- 0 * DTE address in the X.25 subnetwork/

£ a Ethernet address in the LAN/

The corresponding OSI terms are;

- S.SA? a A3C;

- T.SAP a 3c;

- N.SAP = 0.

On a given host/ there may be a numoer of Transport

Service users (Session/ UUCP/ PAD/ These will be

referred to collectively as 'Session Entities' in what follows.

3.2.I. Session Layer.

The Session Layer receives from the upper layer three

address elements/ named ”A'*/ ”3’* and **C”.

”A'* is used by the Session to identify the remote

Application with which a Session Connection must be established/ the Session will keep it until an adequate Transport Connection is available and will put it into the Connect SPDU which will be sent through the Transport Connection.

The receiving Session Entity will use it to identify

the local Application to which the Connect Indication should

be delivered.

’'3'* is used to identify the remote Session Entity with

which a Transport Connection is required; it may assume two

values:

* Case 1: *'3'’ = 0 or missing

this means that the session user has to connect to a user

local to the same system "S'*/ without passing through the

Transport and the X.25 subnetwork; in this case the session entity gives an S. CONNECT indication to the session

user "A**.

* Case 2; "9** <> 0

this means that the session user wants to connect to a user resident on a remote System/ in this case the session entity issues a T. CONNECT request to the lower

entity (the Relay and/or the Transport Class 4); "3" is

August 17/ 1934

g'n
3 lvfn by th® S«s3lor> to th® Transpopt,

**C* is used to logically identify the remote__Snd System

and is given by the Session to the Transpopt# ^ -

The Session Entity dots not pepfopra any tPans fopmati on on the addpess eleaents it manages.

3«2«2« Transport La/er (Class 2 and 33o

The Transport Layer (Class 2 and 3) receives from its

users (the Session and/or the Relay) two address elements/

named ’*3‘* and "C'*.

An internal table is searched for the physical OTE-ID

associated with ”C'*/ and this is compared with the physical

DTE-IO associated with the local system. Two cases may

arise;

* Case 1; physical OTS-ID correspondi ng to "C* = Local Site

physical OTE-IO;

this means that the connection to be made is to a user on the local site/ a TC-i ndi cati on/ with the ('*a"/ ”C")

parameters supplied/ is sent by Transport to the Relay

Ent i ty

.

* Case 2; physical OTE-ID correspondi ng to "C'* <> Local

Site physical DTE-IO;

this means that the connection to be made is to a user on

a Remote Site/ passing through the X.25 subnetwork. In

this case/ when an adequate Network Connection is available/ the Transport will keep ”3" and '*C'*/ put them

together (to form ”3C**) which will be included in the

Connect TPOU to be sent through the Network Connection.

The receiving Transport Entity will use '*3'* to identify

the Session Entity local to the End System to whici the Connect Indication is delivered,

**C” is transformed by the sending Transport Entity into

the Network Address "O", This transformation has been

introduced to isolate the upper communication layers/ and

the high level addressing schemes/ from the possible Slo'oal

Network conf i gur a t i on changes.

"O’* is given to the Network Layer to identify the

remote Transport Entity with which a Network Connection is

r equi red.

3.2.3« Network Layer.

The Network Layer receives from the upper layer one

August 17/ 1984
a-dr«5s na:ned '*0**.

"O” Is used by th? Network to identify the remote Tran*

sport Entity with which a Network Connection must be established; the Network will put it into the Connect NPOU which

will be sent through the Global Networko

The Global Network will use it to identify the Transport Entity to which th® Connect Indication should be

delivered.

The Network Entity does not perform any transf ormat i oon the address elements.

3.2«4. Transport Layer (Class 4)«

The Transport Layer (Class 4) receives from its users

(the Session and/or the Relay) two address elements/ named

and "C*.

It tests

* Case 1: "C” = 0 or missing

this means that the connection to be made is to a user on

the Local Site/ which can be made without passing through

the X.25 subnetwork. In this case/ an internal table is

searched for the Ethernet address '*S” associated with

"B'*/ and this is compared with the Ethernet address of

the Local System. Two cases arise;

Case 1a: Ethernet address correspondi ng to ”3” = Local

System Ethernet address;

this means that the connection to be made is to a user

on the Local system. In this cast/ the Transport

Entity sends a TC-i ndi cat i on to the Session Entity/

supplying the **3** parameter.

- Case 1b; Ethernet address corr espondi ng to ”3^* <>

Local System Ethernet address;

this means that the connection to be made is to a user

on a different system on the Local Site/ without passing through the X.25 subnetwork. In this case/ the

Transport Entity sends a CR-TPOU to the Transport

Entity/ identified by the Remote System Name ”3’*/

directly through the Ethernet. The Transport Entity

will keep ”3” and "C”/ put them together (to form

'*3C'*) and include the result in the Connect TPDU which

will be sent through the Ethernet Link.

CASE 2; '*C'* <> 0:

this means that the User has to connect to a User

resident on a remote Site/ passing through the X.25 subnetwork.

August 17/ 1934
In this th# TfanspoPt Entity will k««p ”9'' and '*C** and put tham togsthap (making "3C'*). Aftarwapds tha

TpanspOPt Entity will sand a CS-TPOU to the- -Transpopt

Entity of th» Gateway/ using its "well. known" Ethernet

addpess "£"/ specifying in the Called T.SA? field the

"3C" parameter.

3.2.S. Relay Entity

Th® relay Entity receives inputs from its user/ that is

the Session layer/ and from the lower Entities (Transport

Class 3 and/or Class 4). It always receives two address

elements/ "3" and "C". The Relay behaviour is different

depending on whether a TC-request is received from the Session Entity or a TC-i ndi cat i on is received from the Transport Class 3 or from the Transport Class 4. This behaviour

is described in detail in CEIE 343.

3*3. Ham® and Address Formats.

In this section/ the formats for all the address elements identified in the previous sections are described.

For each address element/ the format conforms to that

specified in the ISO or CCITT documents/ when available.

The length of the Session User Address "A” is 16 bytes maximum CISC 273; there is no internal structure.

The System Name (in the Global Network) "3C" length is

not defined CISO 733; the EIES project uses a length of 16

bytes. "B" is 8 bytes long as is the site name "C". They

have no internal structure.

The length of the c a 1 1 ed/ c a 1 1 i ng DTE international data

number is 15 digits maximum (CCITT Document AP V)l-No. 11-

£). It has an internal structure.

The Ethernet Address "E" length is 6 bytes CECM 323;

its internal structure is defined in the standard and the

EIES project conforms to it.

4. Network Management Software for the first year.

Within the OSI architecture/ the needs for managing the

addressing structure and for gathering statistics is related

to the special problems of initiating/ terminating/ and monitoring of activities for harmonious operations; these needs

are collectively addressed by the network management components of the OSI architecture.

The software which performs all these network

August 17/ 1984
nana functions flay Of d 1 v 1 d<Jd Into two d 1 ff?r?nt

•3 r 0 u 0 s :

1 ) th® software which has to b« sflOedded in th^ communica“

tion software to interact with the protocol entities^

2 ) the software which is outside the communication environment and which manages the different tables in which the

flanagement items have to oe stored and collected/ . updating and modifying them/ it also provides a (Management

Service through a User Interface to a local Network

•Manager*

The Network Management Architecture for the first year

is very simple/ it just provides a local operator with an

interface to access the services provided by two System

Management Application Entities (SMAEs)/ which allows a User

to control the different tables*

The different SMAEs are not connected among themselves/

neither through the X*25 subnet work 'nor through the local

LAN.

SMAEs

Communication

Software

+ - + -+ —--- +

1 I +

j -4*--- + —4.

j I 4. 4. -4.

I

1 j

1 Tables

} ]

I+ Operator

!

5. Mon Standard Usage ©f the Network.

EIES users will have access to services other than

those based on the Session Layer/ and such facilities will

be suoported by the Transport Layer* In particular/ for the

year 0 EIES software/ UUC? is implemented over the Transport

Layer/ and we describe below how this is done. In addition/

in year 1 of EIES/ PAD connections over transport will be'

supported/ using the X.29 protocol/ and this will be accomplished in a similar manner to that used for UUCP,

August 17/ 1934

n
20

5«1« UUCP

UUCP is ussd during th« first year of th» ,oroject as the only file transfer available in the £I£S network; from

the point of view of layered cofsmuni cat i on protocols it is

seen by the Transport layer as another Session Entity; this

means that any instance of UUCP/ both on a Single end System

or on a OS Component must be associated with a T-SAP. I It is clear that these T-SAPs are completely separated

from the others used by the Session Entities/ and it will

never be possible to establish a Transport Connection

between two T-SAPs belonging to the two groups.

The address management tools available for the EIES

project are able to manage this second T-SAP group too/ out

no tool is provided to avoid an attempt at interworking

between the two groups.

6« EIES lapleaentation Overview.

6.1. Oeneralo

In this section the major choices for the implementation of EIES services under Unix are descrioed; perhaps the

most important choice which has had to be made was to decide

which of the services should be implemented in the Unix kerne landwhichshould not*

The choice must balance the increased performance of a kernel i mp leaent at i on against the danger of reducing the

overall efficiency of the operating system by overburdening

the kernel.

Because of their intimate links to the hardware and the

need for high performance/ the X.23 and Ethernet drivers

must be implemented in the kernel; there are also good reasons for preferring a kernel implementation of the transport

service: again on the ground of efficiency and also because

the required multiplexing and de-multiplexing are easier to

implement.

A flexible approach has been adopted/ which includes

the following features:

a) Two implementations of the ISO transport service class

4 are proposed/ one in the kernel and one in the user

environment: this will cater for small kernel Unix

machines on a LAN and will also allow a comparison of

performance of the two implementations.

August 17/ 1984
o) The archltectuPf for the User level strvless Is sueh

that modules can be moved from kernel to user level in

a relatively straightforward way. '

c) A homogeneous aporoach to the user level services has

been adopted/ based on an Inter-Process-Communi cati on

mechanism; again this results in great flexibility*

d) Crucial features of the c ommun i c a t i on s between different user level processes will be implemented as kernel devices; these drivers will be used by all user

level services/ so that a small investment in kernel

code is effectively used.

Finally/ a phased implementati on strategy has been

adooted/ and in fact/ features c) and d) are not generally

iipLemented in the first phase/ although a prototype implementation is being carried out.

A further important criterion concerns the portability

of the Unix i mole mentation; it is relatively straightforward

to add new drivers to the Unix kernel; in particular/ this

can be done without having access to the source code of the

existing Unix kernel/ consequentely kernel modifications

have ceen limited to the addition of drivers/ which can then

be readily installed on other machines.

The implementation proposals are based on Version 7

Unix; however/ as a further aid to portaoility/ upward compatibility with System III and System V Unix has been aimed

at; when features were required which are not part of standard Version 7 Unix/ these later versions of Unix have been

used as a model.

As a further aid to portability/ and to facilitate

eventual changes in implementation details/ procedural

interfaces to each service have been defined/ which can be

readily mapped onto either Unix system calls/ if the service

is implemented in the kernel/ or onto a set of primitives

for communication between user processes.

In the first phase of the i mp I ement a t i on/ a standard

UNIX system call interface to the kernel communications services will be provided. However/ Version 7 Unix (and/ to a lesser extent/ System III and System V Unix) lack certain

features which would facilitate the implementation of communications software. This will affect especially later

phases of the project/ when a number of user-level processes

will be present. In order to make up for these deficiencies/

it is planned/ during a second phase/ and as a prototype

during the first phase/ to implement two Unix pseudo-device

drivers to permit Inter-Proc ess Communication and .'Memory

,Management. These are described below.

August 17/ 1 93A
6.3« SISS ?39udo

In our softuar® archltfctur® th© task 1 mo L am^nt 1 ng tha

OSI n-antity Is related to the (n+1)-entity by a server /

user relat lonshi 0 / and again the too level entity is the

server of the final user.

In order to allow for a common process interaction

scheme with such a relat i onsh i p/ an Inter Process Communication mechanism has been introduced. IPC is one of the two

functions of the '*£I£S driver'*/ the second one is to provide

an eventually non-blocking interaction mechanism between a task at user level and a server in the kernel. The IPC

mechanism introduces a multiple wait scheme/ so that a server is never blocked waiting for a particular event/ but

eventually only on all events it must serve.

In our environment/ each entity which implements a protocol is provided with a special port with a '’port name"

known by any other entity that has to interact with it; this

special port is used by the entity to receive special messages/ that is/ newly created port names or system messages.

Each entity is always able to listen on such a port; that

is/ a message on that port is always delivered to the

entity.

An entity at user level (in the Unix sense) is allowed

to interact with its server only through the £I£S driver; in

particular/ if the server is in the kernel/ the EI£S driver

interface will mask an access to the specific Protocol

Handler.

Xarnel Memory nanageaent Pseudo Device.

The purpose of this pseudo device is to avoid multiple

copying of data; data is copied into a chain of buffers once

only/ and thereafter it is manipulated using a chain identifier; the transfer of information between user processes

is accomplished by passing the appropriate chain identifier.

A number of primitive functions for the creation/ destruction/ assembling and fragmentation of chains of data

will be provided by the memory management pseudo device.

On t r ansmi s s i on/ an application process copies data to

the memory management pseudo device; this copy creates a chain of data buffers and a chain identifier is returned.

The commun i cation services use this chain identifier to

add headers/ fragment data/ etc. before the data is passed

eventually to communications hardware.

On reception/ the memory management pseudo device

August 17/ 1 934
copies data into a chain of buffers and prsvidts a chain

Identifier to the lowest layer of the c om-'sun 1 c a 1 1 on protocol

services.

The different protocol layers re.i9 0 ve their headers and

possibly concatenate data before passing a chain identifier

to the next higher protocol layer; eventually the user data

is copied into user space by the application process; thus/

only one data copy is required for both transiaission and

recepti on.

7« Conclusions.

A survey of the main implementation choices made for

the EI6S has been made. It is to be noted that these choices

are fully in line with the set of OSX standards recommended

by the group of twelve European manuf acturers.

It should be noted that only in the next years of the

oroject will OSI applications become availaOle/ thus allowing distributed applications with non UNIX systems implementing OSI protocols.

S« References*

CCI 10 CCITT AP VII-No, 10-S "Recomraendat i on X.75'*

CCI 11 CCITT AP VII-No. 11-E ’’Recommendation X.121.

Int ernat i ona I numbering plan for Public Data Networks'*

CCI 30 CCITT VIII. 2 Rec. X.25 "Interface Between DTE and

DCE for ..."

CCI 84 CCITT Draft Recommendat 1 ons X.4XX: "Message Handling Systems"

ECM 30 Local Area Networks (CSMA/CD baseband)

Sasic cable systera

ECM 31 Local Area Networks (CSMA/CD baseband)

Physicallayer

ECM 82 Local Area Networks (CSMA/CD baseband)

Link layer

ECM 92 Connectionless Internetwork Protocol

August 17/ 1934
SCM 13 Network prirvclplss

EC.-^ 14 Local Area Networks Lay«r 1 to 4 archir«ctur« and

protocols "

ECM 20 Lay«r 4 to 1 addressing

SC.M 21 Local Area Networks Distributed system Interworking Units June 1983

EIE 34 SIES Technical Specifications (version 2)

GIE 33 GISN

SOL: A UNIX environment In PASCAL Jan,83

lES 84a Panel 6 ESPSIT Inf rast ructure Preliminary Draft

Repcr

t

lES 34b lES Workplan (ESPRIT area 6,1)

I5S 32 JEPE-IT ESPRIT-IES Panel final report

ISO 26 ISO DIS 8326

Basic connection oriented session service definition

ISO 27 ISO DIS 3327 Basic connection oriented session

protocol sped f i cat ion

ISO 72 ISO OIS 3072

Transport service

ISO 73 ISO DIS 3073

Transport protocol

ISO 71 ISO OP 3671

File Transfer and Manipulation

ISO 93 ISO DP 74 93

Reference model

U3I 33 U3IES Final Report by CII-H3/ GEC^ ICL^ SIEMENS

August 17y 1934
ITU lm8m®4s©f^

CCJTT }fT®»m«5©r®a! T^is^nssfl ^ 7s»fc»oh©n® CimuhatJv* Comrrin*«

iSQ Jnssw^#w®j 3tso^w^ OrgafK^jcfl

C5PT C^5ft^sfrssTc« ef lurop^sn WTi

iCMA f^%fHjfec:ufef5 Assccjation

IRP Fs'^f^ticn te? Jn^OfmaTion Procasawrvg

ef S^spwS©^#* (US)

Sriti^ Siar^d^rda Iwdtuticn

AFN03 frsf}«3®8

A^fiS< Amafkafi Nftscjmt StandarsJa tn#dtuta

3CTA §iiaiir!«@3 Squipmant Trad« A«5ocs»tion

TEi^A T®}©csfnmuirjjcatton Sc^uipfTvwt P^nufacturars AMOcittkxi

CCTA Csfrts^ Ccmputftf and T^i®cs?rnfT?un^t>of?« A9'«>cy MOO Mf«!«?ry c# D®f®f^G«

on D^®rtrnarrt of Tra^ artd Imfuatry

f i;^ I « 1 lalstioaahip of Or ge s i s a t i ona

'TC2S'

'Tcan
iOC
GuToC^OA or

SLV £V

VlS X

IKU

^Urop®s,A

5

UNIX

•t

OSS

% E.S £A^C H

0PEtv5

SVCTEK X3LS"

EUB,0?E ^saa - Ca\uu Ulifi,6?oi,£lEfj

1 addrass ) 1 2.400 1

1 manager | 1 Sesaaja | ISO FILE TRANSFER I ] statist ]

1 i 1 dandling | tTTAJT) 1 I'lC

1 i

I

1

1

! 1

1 account i

r 1 i i 1 1 ias 1

1 one? 1

1 1

i SSSSIOl

1

1 1

1 1

1

1

1 package |

1 1

1 user 1 «v«l

I cr«a«|porc

I Cla«« 4

f u a cr 1 av ei 1

I transport }

I C 1 a s 3 3

j Distributs^ 1

I SsrTer/Di r sc tory I

I SIRS

I DSIVS2

inter I process I communication |

r?"24

~!

I Comas I

I Driver I

I Hatvork |

I I^anajcr 1 —user- ---interface-- —

I Transport 1 Class 4 i l~ ———

,

I-- I —-I Transport !

! i I Class 3 i

! Clasa3/4 ! I

! Gatevaj ! (X2S) I !----- I --- ! I/F to connection orientated 1

I internet |

I ISTS1!?ET !

1 connectionless network service I

I I i

' 1 ZTHSRHST I I X29 | 225 I DRIVSIt II I I

I I DRIVER I

I I di r ec

t

coupl er }

i 1 225 ! Asynch ! PROSIT ! Comma | E3D I Driver 1

I 1

\ ROYAAB

/oq

PROTOCOL

LAYCRS

5

TO7
OSI Session Service

• CONCEPTS

0 GENERAL RULES

t CONNECTION ESTABLISHMENT

9 DATA TRANSFER

0 CONNECTION RELEASE

• COLLISION RESOLUTION
CONCEPTS

• TOKENS

e SYNCHRONIZATION S DIALOGUE UNITS

9 ACTIVITIES

9 RESYNCHRONIZATION

9 FUNCTIONAL UNITS S SUBSETS

• NEGOTIATION

9 DATA CATEGORIES

t

///
TOKENS

% PERMIT ALTERNATING CONTROL OF SERVICES

9 FOUR SESSION TOKENTS

- DATA

- RELEASE

- SYNCH-MINOR

- MAJOR -ACTIVITY

• TOKEN STATES

- AVAILABLE

- NOT AVAILABLE

• AVAILABLE SUB-STATES

- ASSIGNED

- NOT ASSIGNED
SYNCHRONIZATION S DIALOGUE UNITS

0 SYNCHRONIZATION POINT TYPES

- MINOR

- MAJOR

f MAJOR SYNCH POINTS DELIMIT DIALOGUE UNITS

9 MINOR SYNCH POINTS DELIMIT SUB-UNITS

9 CONFIRMATION

- EXPLICIT FOR MAJOR SYNCH

- MAY BE EXPLICIT FOR MINOR SYNCH

9 NO SEMANTICS ASSOCIATED WITH SYNCH POINTS
ACTIVITIES

« DISTINGUISH DIFFERENT PIECES OF LOGICAL WORK

« CONSIST OF ONE OR MORE DIALOGUE UNITS

t ONE ACTIVITY ON A CONNECTION AT ONE TIME

e SEVERAL ACTIVITIES MAY USE A CONNECTION SEQUENTIALLY

) AN ACTIVITY. MAY SPAN MORE THAN ONE SESSION CONNECTION

9 ACTIVITIES MAY BE INTERRUPTED AND RESUMED

0 USERS MAY SEND DATA OUTSIDE AN ACTIVITY

9 ACTIVITY END = MAJOR SYNCH POINT
RESYNCHRONIZATION

t SETS SESSION CONNECTION TO A DEFINED STATE

- TOKENS

- SYNCH POINT SERIAL NUMBER

» PURGES ALL UNDELIVERED DATA

• THREE OPTIONS

- ABANDON

- RESTART

- SET

9 SEMANTICS ARE USER DEFINED
FUNCTIONAL UNITS i SUBSETS

0 FUNCTIONAL UNITS ARE LOGICAL GROUPINGS OF RELATED SERVICES

9 FUNCTIONAL UNITS ARE INDIVIDUALLY NEGOTIABLE AT CONNECTION

ESTABLISHMENT

• CERTAIN FUNCTIONAL UNITS IMPLY TOKEN AVAILABILITY

• TOKEN MANAGEMENT SERVICES ARE REQUIRED WITH TOKEN AVAILABILITY

9 SUBSETS ARE COMBINATIONS OF THE KERNEL FUNCTIONAL UNIT TOGETHER

WITH ANY OTHER SET OF FUNCTIONAL UNITS

9 SUBSETS HAVE NO MEANING IN THE SESSION PROTOCOL
FUNCTIONAL UNITS

f KERNEL

• DUPLEX

• HALF-DUPLEX

9 NEGOTIATED RELEASE

d EXPEDITED DATA

• TYPED DATA

9 CAPABILITY DATA

e MINOR SYNCH

s MAJOR SYNCH

9 RESYNCH

® EXCEPTIONS

$ ACTIVITY MANAGEMENT

//V
PREDEFINED SUBSETS

f BASIC COMBINED SUBSET

- KERNEL

- DUPLEX OR HALF-DUPLEX

® BASIC SYNCHRONIZED SUBSET

- KERNEL

- NEGOTIATED RELEASE

- HALF-DUPLEX

- TYPED DATA

- MINOR & MAJOR SYNCH

- RESYNCH

• BASIC ACTIVITY SUBSET

- KERNEL

- HALF-DUPLEX

- TYPED DATA & CAPABILITY DATA

- MINOR SYNCH

- EXCEPTIONS

- ACTIVITY MANAGEMENT
NEGOTIATION

« OCCURS DURING CONNECTION ESTABLISHMENT

9 FUNCTIONAL UNITS ON CONNECTION

9 INITIAL TOKEN SETTINGS

9 INITIAL SYNCH POINT SERIAL NUMBER
DATA CATEGORIES

§ NORMAL

• EXPEDITED

9 TYPED

9 CAPABILITY
GENERAL RULES

4 TOKEN RESTRICTIONS

• NEGOTIATION RULES

« PRIMITIVE SEQUENCE

0 SYNCH POINT SERIAL NUMBER MANAGEMENT
TOKEN RESTRICTIONS

• INITIATE RELEASE

- ALL AVAILABLE TOKENS ASSIGNED

9 SEND DATA

- DATA TOKEN ASSIGNED (HALF-DUPLEX)

- DATA TOKEN UfWVAILASLE (DUPLEX)

9 GIVE TOKEN REQUEST

- TOKEN ASSIGNED

9 PLEASE TOKEN REQUEST

- TOKEN UNASSIGNED

9 ACTIVITY START, RESUME, END

- DATA & SYNCH MINOR TOKEN UNAVAILABLE

OR ASSIGNED

- MAJOR -ACTIVITY TOKEN ASSIGNED
TOKEN RESTRICTIONS (CONTINUED)

• ACTIVITY INTERRRUPT, DISCARD

- MAJOR-ACTIVITY TOKEN ASSIGNED

f 'MINOR SYNCH REQUEST

- DATA TOKEN UNAVAILABLE OR ASSIGNED

- MINOR SYNCH TOKEN ASSIGNED

4 MAJOR SYNCH REQUEST

- DATA & SYNCH MINOR TOKENS ASSIGNED OR

UNAVAILABLE

- MAJOR-ACTIVITY TOKEN ASSIGNED

9 EXCEPTION REPORT REQUEST

- DATA TOKEN UNASSIGNED

® CAPABILITY DATA

- DATA & SYNCH MINOR TOKENS ASSIGNED

OR UNAVAILABLE

- MAJOR -ACTIVITY TOKEN ASSIGNED
FUNCTIONAL UNIT NEGOTIATION

• REQUESTOR PROPOSES A SET OF FUNCTIONAL UNITS

t ACCEPTOR ALSO PROPOSES A SET OF FUNCTIONAL UNITS

9 HALF-DUPLEX & DUPLEX MAY NOT BOTH BE PROPOSED BY

ACCEPTOR

9 CAPABILITY DATA MAY BE PROPOSED ONLY IF ACTIVITY

MANAGEMENT IS PROPOSED

f EXCEPTION REPORTING MAY BE PROPOSED ONLY IF HALF-DUPLEX

IS PROPOSED

• SELECTED FUNCTIONAL UNITS ARE THE INTERSECTION OF THE

REQUESTOR AND ACCEPTOR PROPOSALS
INITIAL SYNCH POINT SERIAL NUMBER

• PROPOSED WITH MINOR SYNCH, MAJOR SYNCH, OR RESYNCH

FUNCTIONAL UNITS WHEN ACTIVITY MANAGEMENT IS NOT

PROPOSED

9 ACCEPTOR SELECTING ANY OF THE PROPOSED FUNCTIONAL

UNITS RETURNS A VALUE THAT WILL BE INITIAL SYNCH

POINT FOR CONNECTION

§ ACTIVITY MANAGEMENT FUNCTIONAL UNIT IMPLIES INITIAL

SYNCH POINT SERIAL NUMBER OF ONE
INITIAL TOKEN ASSIGNMENTS

9 WHEN A FUNCTIONAL UNIT REQUIRING TOKEN IS PROPOSED AN

INITIAL TOKEN LOCATION IS ALSO PROPOSED

9 POSSIBILITIES: CALLING SIDE, CALLED SIDE, CALLED CHOICE

9 WHEN FUNCTIONAL UNIT IS SELECTED TOKEN REVERTS TO SIDE

PROPOSED BY CALLER EXCEPT -

9 IF CALLER SAID CALLED CHOICE, TOKEN REVERTS TO SIDE

PROPOSED BY CALLED USER
PRIMITIVE SEQUENCING

• USER REQUESTS & RESPONSES ARE DELIVERED 3Y PROVIDER IN THE

ORDER SUBMITTED EXCEPT -

e SEVERAL REQUESTS WHICH MAY BE DELIVERED EARLIER THAN NORMAL

0 EXCEPTIONS INCLUDE;

S-EXPEDITED-DATA

S-RESYNCHRONIZE

S-ACTIVITY-INTERRUPT

S-ACTIVITY-DISCARD

S-U-ABORT

/^7
SYNCH POINT SERIAL NUMBER MANAGEMENT

9 DEFINED AS OPERATIONS ON FOUR ABSTRACT VARIABLES - V(M), V(A), V(R), Vsc

0 V(A) - LOWEST SERIAL NUMBER TO WHICH SYNCH POINT

CONFIRMATION IS EXPECTED

• V(M) - NEXT SERIAL NUMBER TO BE USED

9 V(R) - LOWEST SERIAL NUMBER TO WHICH RESYNCH RESTART

IS PERMITTED

s Vsc - CONTROLS RIGHT OF USER TO ISSUE MINOR SYNCH

POINT CONFIRMATIONS

9 SYNCH & RESYNCH REQUESTS, RESPONSES, INDICATIONS, S

CONFIRMATIONS EXAMINE THESE VARIABLES AND CAUSE OPERATIONS

TO BE PERFORMED ON THEM
SESSION CONNECT PARAMETERS

« CONNECTION INDENTIFIER

0 CALLING/CALLED SSAP

• RESULT

« QOS

« SESSION FUNCTIONAL UNIT REQUIREMENTS

0 INITIAL SYNCH POINT SERIAL NUMBER

d INITIAL TOKEN ASSIGNMENTS

® USER DATA (TO 512 OCTETS)
SESSION DATA TRANSFER

f UNLIMITED NORMAL DATA PER SOU

0 EXPEDITED SDU 1 TO 14 OCTETS

« UNLIMITED TYPED DATA PER SDU

• CAPABILITY DATA SDU 1 to 512 OCTETS

9 NORMAL DATA SUBJECT TO TOKEN RESTRICTIONS

® CAPABILITY DATA SUBJECT TO TOKEN RESTRICTIONS

AND ACTIVITY CONTEXT

9 TYPED & EXPEDITED DATA ARE FULL-DUPLEX
TOKEN MANAGEMENT

9 PLEASE TOKENS

- LIST OF REQUESTED TOKENS

- UP TO 512 OCTETS USER DATA

9 GIVE TOKENS

- LIST OF SURRENDERED TOKENS

9 GIVE CONTROL

- SURRENDERS ALL AVAILABLE TOKENS

- ONLY PERMITTED WHEN ACTIVITY MANAGEMENT

IS SELECTED AND NO ACTIVITY IS IN PROGRESS
SYNCH POINTS

0 MINOR SYNCH POINT

- EXPLICIT OR OPTIONAL CONFIRMATION

- SERIAL NUMBER

- UP TO 512 OCTETS USER DATA

• MAJOR SYNCH POINT

- SERIAL NUMBER

- UP TO 512 OCTETS USER DATA

• RESYNCH

- TYPE: ABANDON, RESTART, SET

- SERIAL NUMBER

T TOKENS S LOCATIONS

- UP TO 512 OCTETS USER DATA
EXCEPTION REPORTING

• PROVIDER EXCEPTION

- REASON

- NO DATA TRANSFER OR SYNCH POINTS

UNTIL ERROR IS CLEARED

- CLEARED 8Y RESYNCH, ABORT, INTERRUPT,

DISCARD, OR GIVING DATA TOKEN

$ USER EXCEPTION

- REASON

- UP TO 512 OCTETS USER DATA

- WORKS ONLY IN HALF-DUPLEX MODE

- NO DATA TRANSFER OR SYNCH POINTS

UNTIL ERROR IS CLEARED

- SAME CLEARING PROCEDURES AS FOR PROVIDER

EXCEPTION
ACTIVITY MANAGEMENT

« START

- ACTIVITY IDENTIFIER

- UP TO 512 OCTETS USER DATA

9 END

- SERIAL NUMBER

- UP TO 512 OCTETS USER DATA

- EQUIVALENT TO MAJOR SYNCH POINT

0 DISCARD

- REASON

- DATA WILL BE LOST

0 INTERRUPT

- REASON

- UNDELIVERED DATA WILL BE LOST

9 RESUME

- NEW & OLD ACTIVITY IDENTIFIERS

- SERIAL NUMBER ,

- OLD SESSION CONNECTION IDENTIFIER

- UP TO 512 OCTETS USER DATA
COMNECTION RELEASE

0 ORDERLY RELEASE

- RESPONSE RESULT (IF NEGOTIATED)

- UP TO 512 OCTETS USER DATA

0 USER ABORT

- UP TO 9 OCTETS USER DATA

0 PROVIDER ABORT

- REASON
COLLISION KESOLUTION

9 HIERARCHY OF REQUESTS

- ABORT

- DISCARD

- INTERRUPT

- RESYNCH (ABANDON)

- RESYNCH (SET)

- RESYNCH (RESTART)

- USER EXCEPTION

9 RESYNCH (ABANDON) COLLISIONS RESOLVED

IN FAVOR OF CALLING USER

• RESYNCH (RESTART) COLLISIONS RESOLVED IN

FAVOR OF LOWEST SERIAL NUMBER OR CALLING

USER FOR EQUAL SERIAL NUMBERS

• RESYNCH (SET) COLLISIONS RESOLVED IN FAVOR

OF CALLING USER
ISO File Transfer, Access, and Management':

Model, Services, and Protocol

James C. Berets

Bolt Beranek and Newman Inc.
STATUS OF FTAM

Work internationally progressing in

ISO/TC97/SC21/WG5 (recently moved

from SC16).

Work in U.S. progressing in ANSI/X3T5.5.

FTAM recently balloted as ISO Draft

Proposal 8571.

« Second DP ballot probable in early 1985.

Mapping to Session pass-through services

still under discussion.
THE VIRTUAL FILESTORE

Descriptive model to uniformly represent

the properties of filestores and the files

contained in those filestores.

Allows differences in filestore

implementation to be absorbed into a local

mapping.

Virtual filestore representation not limited

to real filestores.

Virtual filestore defines: file access

structure, file and activity attributes,

actions on files.
File access structure

Files contain one or more Data Units

possibly related in some fashion (e.g.,

sequential, network, relational, or

hierarchical).'

Virtual filestore provides a tree structure

(called the access structure to represent the

relation between Data Units.

Subtree of the access structure is known as

a File Access Data Unit (FADU).

Essentially a hierarchical model.

Two special cases of access structure:

unstructured files and flat files.
FADU

Access Structure
File Attributes

Kernel subset

Filename

Presentation context

Access structure type

Presentation structure name

Current filesize

Storage subset

Accoimt

Date and time of creation

Date and time of last modification

Date and time of last read access

Identity of creator

Identity'V of last modifier

Identity of last reader

File availability

Possible access type

Future filesize

Security subset

Access control

Encryption name

Legal qualifications
Activity Attributes

Kernel subset

Requested access

Location of initiator

Current access structure type

Current presentation context

Storage subset

Current account

Current access context

Concurrency control

Security subset

Identity of initiator

Password
THE FTAM SERVICE

Based on establishing and disestablishing a

series of regimes.

Entering regimes builds up the operational

context of the entities step-by-step.

Asymmetric model

Initiating' and responding entities

during application connection, file

selection, and open regimes.

Sending and receiving entities during

data transfer regime.

Reliable and user-correctable services.
App]lcal1o?i connection regime

Connect Release

FTAM REGIME NESTING
Service Subsets

File Transfer Service Subset

File Access Service Subset

Limited File Management Service Subset

Enhanced File Management Service Subse
File Transfer Service Subset

CONNECT

Establish an application association

with the specified FTAM entity.

SELECT

Select the file on which actions are to

be performed.

OPEN

Open the selected file and negotiate the

context in which its contents will be

interpreted.

READ / WRITE

Establish the direction of the data

transfer.

DATA

Transfer the data.

DATA_END

All data has been sent.

/-^7
TRANSFER_END

Data transfer is complete.

CLOSE

Close the open file.

DESELECT

Release the selected file.

RELEASE

Release the application association.

CANCEL

Cancel the data transfer in progress.

ABORT

Release the application association

unconditionally, abandoning any

activity in progress.

BEGIN_GROUP

Indicate the start of a set of

concatenated requests.

END_GROUP

Indicate the end of a set of

concatenated requests.
File Access Service Subset

LOCATE

Locate the specified FADU.

ERASE

Erase the specified FADU.
Limited File Management Service Subset

CREATE

Create a new file with the specified

attributes and select that file.

DELETE

Delete and deselect the selected file.

READ_ATTRIB

Obtain information about the selected

file.
Enhanced File Management Service Subset

CHANGE_ATTRIB

Modify the attributes of the selected

file.
Error Recovery Service Subset

RECOVER

Recreate the open regime following a

failure.

CHECK

Mark / acknowledge transferred data.

RESTART

Interrupt data transfer and negotiate

restart point.
THE FTAM PROTOCOL

Relies on underlying services of OSI

Presentation Layer.

Uses OSI Session Layer pass-through

services to provide checkpointing and

recovery.

Currently provided are basic and error

recovery protocol.

Basic protocol provides for the

establishment and disestablishment of

regimes and the movement of data.

Error recovery protocol provides a standard

set of error recovery procedures.

Non-standard error recovery procedures

may be implemented by using the usercorrectable service.
FTAM Session Layer Requirements (First DP)

Kernel functional unit

S_CONNECT (req, ind, resp, conf)

S_DATA (req, ind)

S_RELEASE (req, ind. resp, conf)

S_U_ABORT (req, ind)

S_P_ABORT (ind)

Duplex functional unit

Minor synchronize fimctional unit

S_SYNC_MINOR (req, ind, resp, conf)

S_TOKEN_GIVE (req. ind)

S_TOKEN_PLEASE (req, ind)

Resynchronize functional unit

S_RESYNCHRONIZE (req, ind, resp, conf)
FTAM Protocol Data Units

FTAM protocol data units (PDUs) specified

in notation based on that used in CCITT

X.409.

More complex structures defined in terms of

a set of primitive and constructor types

(e.g, BOOLEAN, INTEGER, OCTET

STRING, SET).

Pmles for encoding the specified abstract

syntax are independent of the abstract

syntax itself.

At least one set of encoding rules will be

specified by ISO.
FABORTrequest ::= SET {

originator [0] INTEGER {

fileServiceUserlnitiated (0),

fileServiceProvidedInitiated (1)},

diagnostic Diagnostic}

Diagnostic ::= [APPLICATION 2j IMPLICIT SET {

errorTypeldentifier [0] ErrorTypeldentifier.

errorldentifier [ij Errorldentifier,

snggestedDelay [2; INTEGER OPTIONAL,

furtherDetails CHOICE {

humanReadable [3] ACharString,

machineReadable [4j OCTET STRING} OPTIONAL}

Errorldentifier INTEGER {

noFLeascnProvided (0),

mandatoryParameter (2),

illegalParameterValne (3),

unsupportedParameterValue (4)}

ErrorTypeldentifier INTEGER {

success (0),

warning (1),

recoverableError (2),

unrecoverableError (3)}
AREAS FOR FUTURE EXPANSION

Filestore and file management.

File access.

Manipulation of groups of files

simultaneously.
FURTHER TUTORIAL MATERIAL

D. Lewan, and H.G. Long, "The OSI File

Service," Proceedings of the IEEE, Volume

71, Number 12, pp. 1414-1419, December

1983.

P.F. Linington, "The Virtual Filestore

Concept," Computer Networks, Volume 8,

Number 1, pp. 13-16, February 1984.

,
Gn FILE TRANSFER PROPOSAL

SEPTEMBER 6, 1984

1. UPGRADE NCC'S4 FTP TO I3Q FILE TRANSFER

SERVICE SUBSET FOR INTERNET DEMO

- REQ'D CHANGES FOR ISO COMPATIBILITY

- SUPPORT FOP F_READ AND FJNRITE

- BINARY AND TEXT FILES

complete ISC FTAM IMPLEMEMTaTCN for LONGER

range time frame

~ FILE ACCESS SERVICE SUBSET

- FILE management SERVICE SUBSETS

’ (LIMITED Ai--fC ENHANCED;-

- ER;9.d'R RECQvERV SERVICE SUBSET

- ViR 1 UAa !' i (jRE 5 i ’JKA'^E b’-JLSE~

p/l
ISO FTP SUBSET FOR INTERNET DENO

1.0 SERVICE PRIMITIVES

1. F^CONNECT/ F_RELEA5E. F_AcCR 1

2. F_SELECT, F_DESELECT

3. F_OPEN. F^CLOSE

4. F_READ AND FJJRITE *

5. F__DATA, F_DATA_END. F_TR ANSFER

6. r_CANCEL

-T

/ F_BEGIN_5RGUP -v. F_£ND__Gr. OUF •*

/<cO
IL

Ll

2.0 CHANGES ftEGUIRED FOR ISO CCriPATID ILiT_Y

1. X. 409 ENCODING (ASNl) FOR FTP PDUs

- NCC'84 format was INTERIM CHOICE TO BE

COMPATIBLE WITH LOWER LAYERS

ADDITION OF CONCATENATION CONTROL

- BEGIN, END GROUP PRIMITIVES AND

SUPPORTING PCI

~ REaD Ow WR I I c. AC i Iv I ! Y I N I I i A ! EL' A'a A

SEQUENCE;

dEGIN__GROUP F_bEi_r.C >. F__Ci-Li.‘‘i h_HE.-0 r __^fr.ND_GRi-'UP

GEvCTN^GROUP F_S£LECT F_GP£N F_WRITE F_END_GRGU

- FILE RELEASED AS A SEQUENCE;

V" ijE'.iiN GROUP, F ClS'SE.' F DE;SELECT, F END GPOUr

q ISO FTP 3UB 3i=.i RE3TRICTIC.NS

A hILE SELEC I ION R.tGIMc. M.AY HAVt. AT MOST

ONE OPEN AND ONE READ OR WRITE ACTIVITY

wNLY LOMPL.fc.i c. > I LwS MAt’ Bfc. i ;LA!"-iLjFE.'’;h'c.D
ISO FTAM IMPLSr^SNTATIQN DEilO

4.0 ADDITIONAL SERVICE PRIMITIVES

1. F^LOCATE, F_ERASE

2. F_CREATE, F_DELETE, F_R£AD_ATTR I BUTE

3. F_CHANGE_ATTRIE-UTE

5. 0 ERROR RECOVER'/ SERVICE PRIMITIVES

1. F_RECQVER

2. F_CHECK

3. P_PESTAtRT

4. F_CANC£L

o. 0 IMPLEMENTATION OF VIRTUAL. FI;_£5Ti:RE

- DEFINITION OF i-TLS STRUCTURE

- ALLOWS “RECORD LEVEL" FILE ACCESS
ju:v:Tt: -c? an iso :p impl = m-£ht atio.'^ *«

CO'^ Vec^ |S<2 V£On P. «»4« i ' c7l\y6"TTJ

Via

\e\ l25 -

: ti 6^ i4

\qoi^ 0'®'^ - iTnu^

5225^^

avN

T ni 3 aoc'w.nvrn- p'* ; :-A---i : --.'rr Irt c'*tjc? o s ^iie

franiT^r anp j-, ,i ^ :- r. ^r, - •_.*rv:.3,- “c ti d^ncnitrato ?t the

I i jH;*; -r, .t> "r :i ppr. icPi jf th ? ISC

.- 7 ^ii j? Tijj'; je-,.p?c‘ p"' DP.-'c- PC preside ijch 2 user

3 sPV»Cs«

i.n ora^r \ j 2v^_j .pi pr, v r StnOdoPC j£iC/ ATi'j »n] — c for ;n-= xTc "-T^' rir t-:^ s'

fnis prepoi^x d5rriwe= rr,-*- 2 ^r.. _i'i_n:ry

: a - n a c .1 a 1 r. - n 3 ^ i > / . . t .

' i “ ^jjjximsntutiAn i't-rix (:;p-xi:ir. ; aoxc u5£r ~i " ». o 7 n j a c £ u :i t - i j r ; < T 1 . = .1 a ^

aiip/t-OT and tnt

j£? th- term

n G a r d . t •- c‘ y IT n d T. '. V con”

w-t ncniniii'n; tne

-' r 1 c r, i! n d r - m a r < ”

a e d l . 1 '. T

- -.F

j e w d : L - - w -I w . i 'T :p

1- i ai idiOix- dZ Oxl

In. “ir d^CVdj*:?j X j.t x: -'rvCC_'j« I'^r

co.ncxitx xT :. ^

•; -. of cc’” r.:. _ _ t rcx = t?>i a COT. IT. an j Giej dc rad-d:t a^ryi.c

froiT. a t ar nine

The T c X 1 c w 1 r a ; ^ ; _ a ; .i : « ; t .n .• _ . : t c f c d r

" a s 3 c c X a t a c X n ^ ^ : c r _ .t : r •> . n .1 * o ? r a n c t tne rT”. A cixrt cjr::r_cc^;r, pj jccn co”'canc

IS oxsa ci./*n«

j e r xnt?rfoce

ranetera, istn

1 Ids invokec

ncc i'dtn the

rs r?tjrned oy

nd cs''='neter5
f r

I coaaaod

SiaD

B3C3IT3

paxaaetecs Ecturas

local file Odse

host DdBC

ceaote file niae

effect

local file uaae

host oaL€

reaote file case

effect

transfer identifier

retarr. code

transfer identifier

cet'irii code

CREATE 'r^\yjrr\ cO(^t,

CA3C3I tra«af€E identifier ratnxn code

911373 boat naae

reiote file naae

pasavoxd (s)

return code

Y“<5‘tovn code.

i transfer identifier return code

'’eUlc i ; T"T l/vi^e *-i|cc C

(Tcnr\rA-i<?r\ol5 /VAej^A^i^’^

££SP io e-K^oxt ^f.?e Iron-. ^Ve j . leS'! i+c,w, ji-l^evt

"to c Ce/w^ots _^»\e ‘^<.|Vtcrrv.

' to VAV'jiO't.V d ^v0/»^ c. re/\'V'»0^« io ,.^2,

le si^ote^ locci 'to

C: t, AT fc

•. io C'TCeic C/v\ ^ 0^ c>i"<?A>%oie sydcr*'VVi

I^e L&i ^ : io deieVe a JjvCt cj ro ^-v'ote \y^TCAvi

: io dbo^t Q- f^t’CElv'6 ol.\avcVvs

\ A\. ec4 .

to OiK c\iOo't Ke o| <S i^tXAn 0 u,^» ^ £ NiD Or "RcO^lV^E opev^rHoA^
Tii 0 aeaning of the

local fil« na««

loat

rsiote £ile aaaa

paaasord (s)

traaafor id<saUfi®r

ratara co4®

Fdcaa«ters is cipiciaed ia tl% foUo^iiig list:

identiiier c£ tha local

B3C2IVZ orc-raticn.

liaae of the reaote host

tioQ.

iila, both io SEND sci

iDvclvod ia th€ operaideatiiiar of the remote

and 5EC£iVZ opecdtion*

file, both in SJM'

indication oi the cp

usoc «<aats to ejcecute

eraticn type shich

on accesseu file . adaittad destinatica effects are;

Ti.e

* 8-S^3 if the destiaatioa file do-iis not

eaist/ it will be created^ yith the

specified file aaie, the contents and

attributes of the source file^ as a copy of the source*

If the file exists, an error ^ill be

returned.

22PL1CS it the file exists, the entire file

is rebuilt, according to source file

organization, attributes and coittents.

If the file does not exist, an ecccc is cet'irned.

bay ¥ord tor accessing the remote file

ideatifier of the transfer request, it is assigned tj the fir tc the SiSD of

user request.. So algoritnas ace descrired fo'*

identifier, the onl^ restriction being that it aust be unique. it aast be issued by the user for af ^tf r

I result of the user re^^uest, Tha list of possible faiues of return codes is provided in

<Wcxi/wa/W d o>se/- \o <t

/
U

1.1

Tne a.jovc :5rv.Ci.- i.

ji.:h n« fil .- iin , _-' t :;

j _ ^ r 3 vi :ic--j ts XTa js^r

Tn« til»3 j'*'^ \ ix\ r:it' zcntjioio;: fljCII ciara-. Of ki'nar

T n ^ T w ^ • * %i • y

No re.cv«r> T^nct-on i ’ c, V 1 a j j f 2 c.-i-jh occurs

a-r^nj tr. r cr^n^Tir/ ;r. . *r',---f-r iiii rsat^rt from tns

osi^rnin^ coo jnj.r *. >, --A.I..C'. t. u = sr r^qu^it. i

racovar/ *unCwiorv x.'; i.r ctui-o i:;- .-rjiiy crc/idao is trs

capao.iii/ r*“r::c:i.-£n t*i£ -niciel con.-iiiion in

c 3 3 i or 3 f .. 1 i a r ' , 7 r. r 1 r .- ? v=. i o .-• i ji f i I & t r = n s f e r is

1 - c 0 c 3 s r ^ 1

1

•/ 1 = r n . n : c - c ; r 1 o i ; rot 1 ? a v £ any o s n ; i i n g jii^aCion. Til.- .ro.:=-.'l ojrr«itly doas net offer this

cataoil-ty -c-'T^ter = 'IZ R 3 L>fACO.

..r ' /

i' : r 1 n 1 i

’ ; - j • j Toil O '. 1 C

••^ :n.y :n lise cf ''L;L:Tr'

'. '-5-3 0 0

'* C 3 .
2m ^ it P 1 4 T * ,M

In in j ^r ^ u ^ r i } ^ d thi sjbjers'and th®

jptioni of *nfe IjC ;.P /‘nj ril® $tor®

(par’i 111 sr. G 11 ;r tnc- .’/ r.':-j«:t-v?ly) jj-urh ?r® n®c 9 »"

sary to juppor: tn - .-7r a*-, rv:.;?; p-cocied in j-cta1«

rn« rliM CP (^'rt IV jf t^. j C;-^) aiil o®

dir®ot-.y oeCsr.T^Ptjo )y t.-i® cncicj.*. jj cn j-^rvicss and

Virtja* “ix« I'CTc.

Thi ijjj^on i-irv*.:.i r_-dj«r.j :o s^p^crt tni* C'>l»cted SGosat

of rfA^ j P w ^ 1 i. j s i.jCi:it.

«ot« tna: tn^ ro.io.ii;/ ;r. -f tn« I 10 FTA^ JP

aiaxiT. iG Olio t.-rvi rr, r-.T?rrc':i -it n no ^urt.nsr sxolana ti on

.

a*X* XO M.^Z^jkMMM

i i r / i ; e T yc r ; ” ^ > r r r > . ,j 1 - : r v i o ?

'*

jervxCr ^ 'X : "-i., T - r n .- r •. r olxt '*L *.t. o t id Fila

1 a i“i a 5 ® ^ ^ t

' m

rn-rii «rc*wGr ti". * j.rv.w - r:T-i*;v.-%:

of be ^.O.oled

W f.Aftoa-r. TWi I>P a>^ cUe^

Vw c^wo to

cK'

^

WtrVt . TW

'P'Va

^ Q,«g-^ olyWC^

t.eAWCfSL

1
1*X« Jt J £1 ^

•jivin; zn -r rT- j-trv.c.j ’j.'nz zc ~3f';v:.ci-? Ait". “tne coiistraidtj i" 1.1/ i,",

.ii'r.'iTTjtjr', 3f *ij *TiM

jp 3 -it r \/ X z e A'.vfe.., ic.T j-i i''C7u'\ -an;! ifet as '^vlIojSi T.na cnsica* ir i Pcac-*, .-c jn r Cip/ of t'la liO

docu.^«nt a.ia itt.-;;nij flTT^CHrigv/T 1^

t r * .j u - c i j j ^ ^ M Tna c-t triii j’ ^ ^ -•i7.-;i

oliinaci "cx -risr," ^.r

V .- ; car, b _ C 5 t i-

.flle attributes

fllanaoa

\ So presentation context " 7 acX<iA ' ^Ai+rvcrurerjl access structure type

presentation structure naae current filaalze

activity attributes

requested access location of initiator

current access structure type

current presentation context
C'^o OUi'STn srapo5.<sl ^

nftR ^

T^t, dre ^roAw i^e 1 «0 '-si^fl b?

.

TWe^ C(^nlcv/tv. tvit ’ sa'i-oisa o| <,ulo4eU

(jt/WcU< VvfSe fe-ee/w gtfHCt«dL^jv»^/AA.«^^ "^c ' “At t'^C'^Y~'

Wi'tA-; u. pole.

^"5:^ CXOb^tAi^

^

*t^d ^l*/V\(^€/ v>t Aria'S, -^.eO^'C^

/i^U^ « *1 oi_*(^S OLll^^TTl ,

T. COHVkSCT;
9. 1.2.1 Called Address The called address is the address used by the

calling service user to identify the filestore to which the connection is

to oe established. The value is an address.

9. 1.2.2 Calling Address The calling address is the address from which the

connection is established. The value of this parameter is assigned to the

"location of initiator" activity attribute associated with the connection.

The value is an address.

9. 1.2.3 Responding Address The responding address is the address which

should be used in re-establishing the connection after failure. It is not

necessarily textually Identical to the Called Address. It aay differ, for

example, if generic addressing or redirection are in use. The value is an address.

9. 1.2.4 Servioe Type The service type parameter takes the value "reliable

service" or "user oorrectable service", depending on the service offered, — I I I mm

• 9. 1.2.5 Service Subsets The service subsets parameter conveys the file

service subset to be used (see clause 7). The value consists of two parts.

The fir it indicates the set of optional service features which ar e required

on this connection. The values may belTialt ed^jj^ HanagemenT? Enhanced

File Management, Access or, for the user oorrectable service. Error

Recovery, The second indioates th% set of optional virtue

features which are required from the filestore provider on this connection.

The values may be Storage or Security (see part II, clause 10). Either set

aay be empty, in \^ich case the (.kernel subset is used.

9. 1.2.6 Communication Qu>i>ity of Servic.^^**fhe consnunication quality of

servioe parameter conveys 'the qua]J,>y of service associated with the

connection. On the request and xmdi;j4tion primitives, it indicates the

quality of servioe requested, andxCn\the response and confirm primitives it

indicates the quality of s^j^ce abWeved. The values taken by the

oommunication Quality of Sel^ice paramebs^ are defined in the Presentation

Service definition.

9. 1.2.7 Rollback Availability The rollback availability parameter indicates

whether or not the file service user can support transaction rollback after

failure. The values of the parameter are "no rollback" and "rollback

available"

.

iO

L - •

no
XH lat DP Part III

9 .

2

Application connection taraination (ordarly)

9.2.1 Funotlop

An application connsction nay b® t®nalnat®<i by an cschanga of F-HELEAS2

prialtlvea. Thla exchanga is initiated by the initiating umr. Such an

exohanga will not bo co*apletad until any aetiona prevloualj requested have

boon ocmploted.

9.2.2 Typoa of priaitlvoa and paraaotora

Tho following table Indlcataa th® typos of priaitlvs and th® pars2i«ters

needed for orderly connection termination,

IF-RSLEASS !F-H£LEASE [F-HELEASS 1?»HSLEASE | Par.-joeter I request i indication 1 respona© I confirm ! S3aX33XaX3SaaZSa3a3XS3S:S3S32tS:SSSa33SSS3SS3S3 33SSS;SXSai33I3SSSS:S3:S

i ! ! ! i

} ^

Qp±d£aal.»l_.

9.2.2. 1 Charging The charging\para2^ar conveyp information on th® costs

incurred during th® connect^sn/^ The yalua of the parasoter is a list of

triples; the oleaents of each ^Mpl® are: a character string resourca

identifier, a character string2 has|ing unit and an integer charge valus,

9.2.3

Sequence of prlaitiYea

The F-S2LSAS2 request prlaitive can be issued by the file transfer

initiator' (the issuer of the F-CONHECT request) at any time after the

receipt of an F-C0NHSC7 confirmation priaitive, providing no file is

selected. The issue of an ?-»P^LEASE request does not inply the success cf

any previous activity. Indications of success or failure are gives on the

cctapletlon of each activity. The sequence of events in a succsssfu orderly

connection termination is as follows.

P“5?ELZASE

cCTiUrm

/ 7/
FTAM 1at DP Pii

9,3 Application connaotlon tarainatlon (abruct)

9.3.1 Function -

Eithar fila sarrica usar say iaaua an F-ABORT raquast priaitiva at any tiaa

aftar an F-COHHECT raquast priaitiva haa baan iaauad, or an F-COHNECT

icdioation prlaitiva haa baan racaivad. Tha F-ABORT priaitivaa tarainata

tha oonnoction unconditionally, abandoning any fila activity that was in

prograaa and leaving tha aalactad fila in an undafinad atata. Tha uaars of

tha fila sarvloa say agraa that tha fila activity is to ba rolled back in

this cirotaistanca. If error racovarv is •to ba parforaed, tha , h-m»y fftg tlitimt the recovery ^ies vith tha initiator. . Once an F-ABORT request prlaltiva has bean issued, tha connection will be

taninatad; tha request cannot be rejected.

The filestore provider perforas the close file and deselect file actions on receipt of an F-ABORT indication if the file is open, and tha deselect file

action if tha file is closed but selected. However, no cccaitaent sesantics

should ba associated with such an autc«atic close.

9.3.2 Types of prlaitives and paraaetara

The following table indicates the types of prlaitives and paraaetara needed

for dastruotiva connaotlon tantlnation.

Paraaeter | F-ABORT request! F-ABORT indication!

2SSa3XXS33X3X3aaX333S3ZXXSa333X33S3X33333Xa3Sa

I ! I Originator! ! Mandatory !

< ! i Diagnostic! Mandatory I Mandatory !

9.3.2.

1

Originator The originator paraaeter indicates the source of the

teralnation. Its value indicates either File Service User or File Service

Provider initiated teralnation.

9 . 3. 2.

2

Diagnostic The diagnostic paraaeter conveys the reason for the

breakdown of the conne<^tion. The possible values for the diagnostic

paraaeter are given in Annex A.

9.3.3 Sequence of prlaitives

The sequence of events in a user initiated abrupt teralnation is defined in

the following tiae sequence diagraa.

F-ASORT

request

nu

F-ABOBT

indication
FTAH l3t D?

I F-5SL3CT j F-SSI*SCT i F-SELZCT I F-SEL2CT

Partia«t«r I r«qu«at I ir:dicationl rsspons-s 'I eonfira

ssassMaisa3 33xa32aas3xa3a3ai2S3sa3S33sa3^sss!s'»3S2iS3ss3ssss

I I I I ! Pllenasa I Mandator7 l

I I I I !

C^ataol \

-’ nn±-j^nfg—{

-Cenrbrol I I I

..2;^MMWG£dB I I

I ! ijM^eac—^ 1 I ,^4^jgfgrg }' Op'SlCiiST^'rnjp'SloQ^^

I !

-A<c-JW>aa^E:3"i“

Dia$nostid OptioQal 1 Optional

10 . 1 . 2.1 Fllsnaae Ths filenaaa parsa©t@r idsntiflas tha fila saleoted. In

th® rs<;n®3 t and indication priaitiTsa it indicatan tha fila raquired, and

in the r«spofU3© and coaflra prisiltiT^a it indicatas tha fila actually

3«leot«d. If, for example, th© raqustst®d gava a gsuaric naxa or a generation naao, the nssa selected sight differ frea that requested.

10 . 1 . 2.2 Attributes Th^ attributaa parasst4r provides attribute valuos for

use in IZiotlfying mm file to b@ sa^cted. The attributes which aay be

referenced and the rangk of values thsy nay take aro defin<Kl in the virtual

filestore definition (Parst II of th^ standard)

.

10 . 1 . 2.3 Concurrency Contr^ Ths ^neurrsney control paraneter indicates

the relation' "of" thi'a to other activity on the saae file. The

value is a vector whose indicate, for each of the claaaea of

access control (see 10 . 1 . 2 . 4 ) ^^ether the access ia shared or exclusive.

10 . 1 . 2.4 Access Control The /cca^ control parameter indicates the basis on which the fils ia being ^lecte^ The value gives ^ a vector the actions

to be perforae>d during th^selectiOT. The sleiaents of the vector correspond

to the read, insert, yreplacs, ^ase, extend, read attribute, change

attribute and delete actions, am each aleoent indicates whether the

action is required OiVnot, The value Nof the paraaoter detsralnes the value

of the requested acc^s activity attri^te associated with the connection.

10 . 1 . 2.5 Access Pa^s^rds The access pa^'^'ords paraneter provides passwords

associated with t^e actions specified in fthe access control paraneter. The

value of the par^eter determines the v^ue of the password activity

attribute, andythe range of values the par^eter cay taka is equal to that

defined for the attribute.
FTAM 1st DP

J

10.2.2 T7~P«a of prlaltlvsa and paraasttrs

Th« following tablo Indlostaa the types of prialtives end the peraaseters

needed for file seleotion.

IP-DESELSCT 1P-DBSEL2CT jP-DESZLECT i?-DESEL2CT I Paraaeter I request I indication i . response I oonfira I sasassssasaaasaasaassBSxaasassaaaaasasxsassamasasBaaaaaxaaaa

I I I i I

. ^ j p Op tioBsl—}--ny^«wes; S

! I I I I

'' Diagnostic I ! I Optional I Optional I

I I I I I

10.2.2.1 Charging The charging j»ra^ter conveys inforaation on the costs

incxirred during this file se)l>wtlon. The fora of the paraaeter value is

specified in clause 9.2.2 \

10.2.2.2 Diagnostic The diagnostic paraaeter indicates the reason for any

failure. The possible values for the diagnostic paraaeter are given in

Annex A. The selection regiae is teminated whatever the value of the

diagnostic paraaeter.

10.2.3 Sequence of priaitives

The sequence of events in a successful deselection is defined in the

following tine sequence diagraa.

10.3 File creation

10.3.1 Function

The F-CHEATE primitives cause a file to be created and establish a selection of the newly created file. They may only be used if there is no currently selected file.
h.\H l3t DP fzrt 111

Th« fllaatort proYid-sr p«rforas tha flla aiction recsiving th&

F-CPEAT2 Indication priaitiYs, and bafors issuing tbi f-CBSATS r^aponaa

priaitiva vith a diagnostic parasot^r indicating succsss.

^ A ^ iT! €

10 . 3.2 Typ«3 of prlaitiYea and parma^tars \ w n

Th« following tabls indicates th© typsa of pnisitiv^s and th@ pi^raasters

needed for filo creation.

6^

f \V«. (^VnO\C^

I F-C2ZATE

Ptranetar ! ro<?ue3t

sax's 3S3SX£3SSSSSSS3333a

I Fllenaae I Mandatory

Attributes {Optional

I

I —C-wwtsrrsTra!?' f"' Cp'tl Jn-Jir

Control !

Control

Passwords

Diagnostic

F-CHZATE {F-CHILITE |F»CH£ATF

indication! response ! confirm

3333aSS3S333S3233S3S333S333SSSS33

Mandatory

Optional

I Options! ! Optional

Optional i Optional !

10.3.2.1 Filesaae., Concurrency, Control. Accouating and Diagncatic , The

filenaas, concurrency control, accounting and diagnostic paraaeters are

defined in clauso 10.1.2.

10.3.2.2 Attributes The attributes parsaster gives a list of attribute

naaas and values tc b© associated with th® nevly created file. Tne

attributes are defined in tha virtual filestore definition (Part II of this

standard) . Th® attributes which say b® sat by these priaitivss are listed

in Annex 3 to this Part.

10 . 3 . 2.3 Access Control and^ecesa Password^ The access control attribute is

deflntjd in clausa 10,. 1 .2. password attribute has elements

matching those of th© access eont^^C^btribute, plas an additional element

which may be required by provider to permit the specified

file to be created.

10.3.3 Sequence of primitives

7h® sequence of events in a succassfal creation is defined in the following

time sequence diagram. An F-CHSATE Indication is rejected by using an F-C3SATE response with a diagnostic parameter with an error type more

severs than warning.
-H

•j

1

.--I

•r I *« «•t

\.

\

F7AM 1st DP Part

r~c!iZATS

rsqueait \

10.4 Flla delation

10.4,1 Function

The F»DSLZT2 priaitivea release an existing selection in such a way that

the selected file ceases to exist, and is not available for reselection.

Tife priaitives nay only be issued while a file is selected. Zven if the

deletion -fails, the file is deselected.

The filestore provider perforas the delete file action after receiving the

P-D2L3TS Indication, and before issuing the F-DELET2 response priaitive.

The delete file action can be perforaed only if the initiating entity has

the "delete file" access control peraission (see clause 10.1.2.4).

10,4,2 Types of prlaitlves and paraaeters

The following table indicates the types of priaitives

needed for file deletion.

Tand the paraaeters

P-DSLETE IF-DEL2TS IP-DELSTE

Paraoeter I request {indication! response

33333 3SX3=3SS3X3S3= 3X3SaC3 3 3 3X3S3:

-Ae eeea ! Op-fi ifteol ! Cyii ieettSr

Control

Access

Password

! Optional i Optional

-CharsiBgDlagnostic

nrnil

Optional

P-DSLSTS

conflra

3333333333

Oprinn-al.

Optional

10.4.2.1 Access Control, Access Password The access control and access password parameters are a subset of the paraaeters defined in clause

10.1.2, having only the elenent controlling the "delete file" action.

/ 75

'
rTAH lat D?

\

ParV’

1 ?-R2AD-ATTI?I3 1 ?-HSAH«»ATTRI3 ! F.=*HEA.D»ATTHI3 ! F^HEAD-ATTRIB

!

Paraaatar I r«quaat 1 indicafcloa 1 r^^spcns® _ 1. confirm 1 3X33X3B3333a»nS33aS3S333S3SS3SS3SS23:SSZ333aSS33S33SS33333»S323iS3SSSa8 \

Attrlbuta I H-aindatory 1 Mandatory 1 Haaea I

I 1

Attributes 1

I Diagnostic I

! Mandatory j l-llandatory I

I I I

! Optional i Optional |

11.1,2.1 Attribute Hataea Tb<§ attrlbuta nsmm para^ater indicates wblcb

attributes frea the s«t givan in th© virtual filestore dofinltion am to be

read. Tba paraasoter aay indicate ”all attributes'* or it say bs a list, each

olecaent of which names an attribute defined in pa.rt II of this standard.

11.1.2.2 Attributes The ^attributes para^ater returns a list of the naass

and values of the r^questod attributes. The ¥alu«ta say either bs a value

doflntsd in part II of this standard cr ®n indication that no value is

available.

11.1.2.3 Diagnostic Th® diagnostic pmras@tor indicataa ths success or

failure of the oporatioa, and the reason for any failure. The possible

values for th® diagnostic pari^otar are givss in Annes A.

11.1.3 . Sequence of prlaitivoa

The sequaac® of events in a successful reading of attributes is defined In

the following tise sequence diagram.
Part III

/

7

/mw 1st DP f.

I F-OPEH I F-OPEH 1 F-OPSH I F-OiSM 1 Paraaatar I request ! indication I response I confira ! sssaasasaaasxasxxsxsasssassaasxsxxasaaasa as 333333 X 3 X 333 *

Processing

Mode

Access

Context

Presentation

Context

Mandatory

! Optional

I Optional

I

t

t

I

*i" 6e«eupf» eneyl Optii^nal-

-CeffCT^ !

" gcmmitaent-l OptieneiDiagnostic !

Mandatory

Optional

Optional

OpfcisnalOp fa

i

Offal

Optional

^p tional1= redd .jrc^;L* m

Optional

Opfaicnal

i Optional I Optional

Additional parameters In the user correctable service

Identifier

Rooovery

Mode

,2at;l'3nal„

Ortir.nal

12.1.2.1 Processing Mode The processing acde parameter indicates the

possible operations to be performed as a result of data transfer requests;

this determines the filestore actions which the filestore entity can perform. The parameter value Indicates whether F-PEAD or F-WRITE

primitives are to bo permitted* and, for the F-WRI7E primitive, whether the

data unit operations^replace"

^ ^insert'), and ’^^extand " ^are to be permitted.

12.1.2.2 Access context The access context parameter specifies a view cf

the file content access structure which is to be used during this open

regime. The parameter value is one of the four views;

- access context 1: access to all DUs within

structuring information.

each FADU, together with all

- access context 2: access to all DUs within

structuring information.

each FADU, but without any

- access context 3: access only to the DU associated with the root of each

FADU

- access context 4; access to all the DUs in a given level of the addressed

FADU, but without any structuring information.

1
7 rTAM 1st DP Part III

12.1.3 3«quenc« of* prlaitivaa - '

Tha saquanca of ovanta in a succassful cpan la dsfinsd in. tha following

tiaa aaquanca diagram. An F-OPSS indication is raject^d by uaa of an F“0?2N

raaponaa with a diagnostic paraaatar indicating failure.

12.2.1 Function

Tha F-CLOSE priaitlToa release an existing file open reglae. Once a clcs®

procedura has been initiated, the file will be closed; the requaet cannot

be rejected.

F-CL03S Indication priaitlV'e, and before issuing the F-CLOSS response

priaitive.

The following table indicates the types of prisitives and the paraneters

needed for file closing.

12.2.2.1 Diagnostic The diagnostic pararaeter indicatas the reason for any

failure. The possible values for the diagnostic parameter are given In

Annex A. The close regime is terainated notwithstanding the value of the

diagnostic parameter. Dsa of the diagnostic parameter on the request allows

the file service initiator to cause rollback cf tha activity.

request

ocscxlrma

F-OFEN

ixkdicsiti'

F“-CF^

idicsiticsa

12.2 File close

Tha filestore provider performs the close file action after receiving the

I F-CLOSE j F-CLOSE i F^CLOSE 1 F-CLOSE 1 Parameter ! request ' indication! response 1 confirm 1

Diagnostic I Optional I Optional I Optional I Optional 1
FTAH 1st DP Part III

13,1.2

Typ^s of prlaltlv«3 and paraaetars

The following table Indicates the types of priaitives and the parameters

needed for data item transfer.

N Parameters IF-DA7A request i F-DA7A indication! sssassaxsasassasxsasxxxaassssssssasssassssxsaasxass

F-Data Item Type j Mandatory

:! F-Data Item Value! Mandatory

Mandatory (a)

Mandatory (a)

13.1.2.1 F-Data Item Type The 7-Data Item Type parameter indicates, for the

data item transferred, the data item type and thus the set of values which

are possible. The F-data it«a type must be within the set implied by the

value of the presentation context file attribute.

13.1.2.2 F-Data Item Value The F-Data Item Value parameter indicates, for

the data item transferred, the value taken by the data item in this

instance. The value must be within the set of permitted values for the

specified data type.

13.2

End of data transfer

13.2.1

Function

The completion of the data transfer is indicated by the F-DATA-END

primitives. The sender Issues an F-DATA-E)TD request primitive when it has

sent all the necessary data; receipt of the F-TSA)IS?EH-END indication or confirm as appropriate informs the sender that no further error recovery

actions will be requested.

13.2.2

Types of primitives and parameters

The following table indicates the types of primitives and the parameters

needed to end a data transfer.

! F-DATA-END ! F-DATA-END ! Parameter ! request ! indication ! SSS=SS3333SSSSSrSS3S==SS==SSS=3=S=SS

> * !

I 1 i Diagnostic ! Optional ! Optional |

! . ! !

13.2.2.1

Diagnostic The diagnostic parameter indicates the success or

failure of the data transfer, and the reason for any failure. It also

Indicates whether a failure is amenable to recovery or not. The possible

values of the diagnostic parameter are listed in Annex A.
f

///TAM l 3 t DP

13,4 Vrlta fila access data unit

13.4.1

Funotlon

?srt III

Th« F-WPIT2 group of prlaltiv«s spooifits a data transfer frcs th« fllo

3or7lc« Initiator _to__ tha fllsstoro » 1 filo aujt pr®v lously. have

been opened, and ojily^ons ?*-¥H2Tl procodur® say be la progrosa at any tiso.

The file stor® provider p-erforaa tho loo^tt® fils acooss data unit action

before ijsuirus tho F-TOIT?. roapoQ&e, and auba@qu®ntly p^rforsa the insert,

replace or ostond actions as data is r^accived depending on th® data unit

operation specified. Tho dirsetioa of data flo5^ establishod centiauos until

the exohango of P-T2AIJ3F2B~IifD pri^itivts. An indication can be

rejected by including a diajgnoatic parameter id,th error typ® sore severe

than a warains is tho response* If tho transfer is rojsctsd, no data

transfer takas plac® and the fils is not changed.

13.4.2

Types of priaitlvea sad oarmaeters

The following table indicatss the typos of prlsitivos and the paroaetors

needed for a writ© 3,ntsrsctioao

Paraffleter

?11 © Access

Data Unit

Operation

File Access

Data Unit

Identity

Point

F»WBITi:

request

F»WBIT1 ! indication!

F»’iHITZ F»¥Bm

response { confira

Mandatory! Handatoryj

felCOii

/

Cj. /

>fendatory| Mandatory 1

-

Diagnostic Optional I Optional

Additional paraiaetsrs of th© user correctable service —1—CptlanaJL

13.4.2.1 File Access Data Unit Operation The file access data unit

operation paraaetar indicatas the action to- be taken by the filestore

provider on receipt of the data transferred. Possible values are "replace",

"insert" or "eistaad*.

13.4.2.2

Fila Access Data Unit Identity The flla access data unit Identity

par^etar gives the identity of the file access data unit to (or frea)

which the transferred data is to be associated. The value of the paraaecar

is either:

a) "firs_^" or "last", in teras of the preferred traversal sequence for

'tEa'’^rue ture

,
Part III

/

/ FTAH 1st DP

13.5.2 Types of prlnltivga and paraaatars f.ara2:>

The following table- indicates the types of priaitives and the

needed for a read file access data unit interaction.

paraaeters

Paraaeter

F-READ

request

I F-SEAD

! indication

F-READ

response confira

333X3333333S3S3a3333=S3323a33=3Z3=SX333SS3S3SX2ZS:S3XZSSS

File Access! I I Data Unit I Mandatory! Mandatory!

Identity ! ! I —

S

qffcon' ancy i Opliuiul }~ Cpiunal I vXoeti ol"^ ! i !

Diagnostic Optional Optional

Additional parameters of the user correctable service

*euu»«r"j \ Optional 1 -Op hi a nal i Point 1 I !

I I (

'I3.5.2.I Data (Jnlt Identity, Concurrency Control. Diagnostic, Recovery

Point The data unit identity, concurrency control and recovery point

paraaeters are as defined in clause 13.4. except that the data is being

-read from the filestore, and not written into it.

13.6 Erase file accesh data unit

13.6.1 Function

The F-SHASE group of priaitives specifies the identity of a file access

data unit which is to be erased by the filestore provider.

The filestore provider perforas the erase action after receiving the

F-EHASE indication, and before issuing the F-SHASE response priaitive.
rTAH 1st D?

?srt llV

13 , 6.2 of priaitive3._3nd,W3aai^ i - ^ ^

followln* t»bl. lndic3t« th* WPa. of prl.ltlvas abd tba para^ator,

needed for an erase interaction.

1 r-ESASI I F-SSA3S I F-EHASE I F-^HA^ 1 P.rMs.tsr 1 request llndloitlonl rssponsa , oonflra 1

Handatof:^'

(s) 1

File Access!

Data Unit 1 Mandatory

Identity

^

^ ,-eaTiCDrrFnTtT^“^'F®^

Control '

'

Diagnostic

1

I Optional I Optional

I

^

•.<. 1. t ^ T ri «.«>•? Ccnc'Urr sncy Contr o 1 ^

parasetsrs are defined In olaus® 13. «•

13.6.3 Sequence of pri ^jiMZSH.

The sequeneo of events in a successful erase is defined by the .ollowlng

tine sequence diagram.

13,7 End o f transfer

13 , 7.1 F\2 nction

The completion of a transfer Is Indicated ‘>F tr eschan^e of F-TSAH^

primitives. This exchanse is initiated by the

„r r-cel'vi-j the

or received an F-»DATa\-.£HD primitive. After issuing or r>.cei/i..5

F=4)m-€^D primitive the F-mHSF£R-^:}iD request primitive with ^a dlaancs.i.

parameter !wre severe than a warning oust be used If the transiar Is .o rejected.
/ rrjM i3t DP

,. ./ - - Part III

/

’^**^*^ T^S33 Of prlaltlv93 and param^tgra US?^

The follo%ring table indlcatea the types of Driaitlv«a and needed for data transfer ending.

^ ^ laitlves and the parameters

I F-TRANSFES | F-TRANSFER | F-TRANSFER | F-TRANSFER

|

I -EHD I -£ND I -end I -CUD I P.r«.t.r I r.<p«.t lindlo.tlon! r«pon„ | oon«ra |

Miiirnl ^ni nr

Optional

J Optional J Optional | Optional '

13.7.2,1 Conaitaent Control users of the service to

structure of which the files

parameter is a string (see A

control parameter allows the formation relating to any cocsaitment

may form a part. The value of the

.1.0 Indlc.tM th. reason for an? fa^J^rf ‘’anaf.r. It

diagnoatio parametar are given d [nn« I:

;

!

13.7.3 Sequence of prlmitivwi^

The sequence of events in a sequence diagrams in clauses

successful transfer end is defined by the

13.8 and 13.9.

time

I
MGT

trH t O’

T> „

'i~\ 4^ fi

r ^ O’
?TAM l 3 t D? Pan

13.10 CAno^lllng data tranafap _ - \

13.10.1 Punotlon

Zlthar of th« aarrioo us«rs aay oaco«I a data transfer aotirlt/ by issuing

an ?-CAHCZL request priaitlTe. The P-CAUCZL prlaitive aay be issued at any

tiae after the issue or receipt of an F-READ or F-WRITZ response or oonfira

and before the issue or receipt of an F-OATA-ENS request or indication.

After an F-.CAKCSL procedure the two users aay have different riewa of the

state of the acti-rity. The F-CAHCZL prlaitives interrupt any actirity in

progress (including an ?«RZ2TART sequence) and any undelivered indications

or confiraa aay be discarded. The file reaains open after a sequence of

F-CAKCZL prlaitives, although the result of Interrupted opei*ations is not

defined. Further ?«HSAD or F^WRITE operations, not related to any previous

read or write atteapt, aay be attaaptad after the coapletion of the

sequence of F-CAHCZL prlaitives has disposed of any previous activity.

13.10.2 Types of prlaitives and oaraaeters ?. cAbJCSL

The following table Indioates the types of prlaitives and the peraaeters

needed to cancel data transfer.

I F-CAHCSL I F-C1HC2L | F-CANCSL I F-CAMC2L I Faraaeter ! request ! indication! response I confira ' Bsxsssaaxssassxasxssxxxasxaxaxaaxsxxaxssaaxxaaaxaxssssaxssas

I i I I I Diagnostic I Mandatory I Mandatory ! Mandatory I Mandatory I

13.10.2.1 Diagnostic The diagnostic pairaaeter indicates the reason for the

cancellation. In the user correctable service, it also indicates %<hether

the transfer nay be recovered or not. The possible values for the

diagnostic paraaeter are listed in Annas A.

13.10.3 Sequence of prlaitives

The sequence of events for a successful cancel procedure is defined in the

followixig time sequence diagram.

F-CANCSL

request

P-C\NCSL

ocofirm
l-.E. :
TEXl ov- -=fiies I

I

, (jHSTRUC lUf\EO

HO Rtcoveay

Cwdy be roll . j

, NO i^\Lb hcces S

/n I
A/ TO

TH £T
. SEND

. RECEIVE

• C R E ftT E

« DELE I E

• c RriCEL

.£>TftTUS

I

I

I

m^ibi I

I

I

t>/I

I

I

H

I

I

I

I

I

I

I
0

0

0

0

0

0

0

0

0

i^Q-i

mjCRCoroeiTs

VIRTUAL FILESTOI£ fWING

MAPPING TO IMERLYING SERVICE(SESSICJI, DWIV PREWJIffi)

FILE OTICE imWACE

FILE PRJIOCCL ENGIIE

SLES:TnNG

FILE TRAflSFER SEWICE m PffiTCCCi

FILE WIdSS Mild AND Pf^COIL

LIMre FILE MANA©®!T SERVICE AND PROTOCOL

ENHANCcI) FILE WlAffleiT M3 PKJTfXOL

ERROR ECMRf SUBSET OF USER CCRR:CTAEL£ FILE ^RVICE

•S’/
ISO FILE TiwisFER. ACCESS

* mfmmiHm)

PROVIDES

0 FILE TRANSFER

0 FILE CREATION

0 FILE DELETICN

0 TOIPllATICN OF DATA WITHIN FILES

0 mmm of indivioial files

ojRiefr nm specification

0 SOEDULED FOR REVISION IN OCTdER. EALLOT IN JANUAr|
/?5
/f/.

UNION OMITS

NEGOTTATED RELEASE

EXPEDITED DATA

TYPED DATA

CAPABILITY DATA

MAJOR SYNCHRONIZE

ALSO OMIT

EXTENDED CONCATENATION
JSi
€53

m

/

(X,

VaiX

Keuft cp-f 7^c

C.0Kcd^d(<^h 0-j^ 5P()(jj$ j^iZ)

ell'll

</n f/^^r
LAYER 3 - INTERNETS TIME. RESOURCES ESTIMATES

~ IP: DEMO SUBSET OF CONFORMANCE SUBSET (NO TYPE 2 OR

TYPE 3 FUNCTIONS i.e.. NO SECURITY. SOURCE

ROUTING. PRIORITY. ROUTE RECORDING. QOS. OR

PRIORITY FUNCTIONS)

COMPLETE: 2/1/85 (INSTALLED AND RUNNING. READY FOR

PROTOCOL TESTING BY NBS)

- IP TEST BED

ARCHITECTURES

TEST CASES
0 TEST BED ARCHITECTURES

ENCODER/DECODER

REFERENCE IMPLEMENTATION (RI) WITH TEST HARNESS

0 ENCODER/DECODER

CAN CONSTRUCT. RECOGNIZE ALL TYPE OF VALID IPDUs

CAN CONSTRUCT. RECOGNIZE ERRONEOUS IPDUs

0 RI WITH TEST HARNESS (SCENARIO INTERPRETER AND

TRANSPORT OVER IP)

CAN CONSTRUCT A SUBSET OF VALID PDUs (ONLY THOSE

INDUCIBLE VIA THE IP SERVICE INTERFACE)
ENCODER/DECODERm

XMIT/RCV

-

SENDER/RECEIVER
SI

-

SCENARIO

INTERPRETER

RSI

-

REMOTE

SCENARIO

INTERPRETER

EG

-

EXCEPTION

GENERATOR

LOT

-

LAYER

UNDER

TEST

IP

RI

-

INTERNET

PROTOCOL

REFERENCE

IMPLEMENTATION
LAYER 3 TIME. RESOURCE ESTIMATES

0 ACCURACY: PROBLEMATIC

0 5 SECTIONS:

» TASK AND CRITICAL PATH TIME

” ASSUMPTIONS

- LIKELY SLIPPAGE
RI WITH TEST HARNESS

ITEM

TIME-TQ-COMPLETE (PM)

DESIGN. CODE. CRITICAL CRITICAL PATH

SPECIFY UNIT TEST PATH TIME COMPLETE DATE

MODIFY INTERFACES

FOR IP ^

MODIFY PDU LOG

ANALYSIS TOOLS ^

TEST CASES 1

PORT TEST HARNESS TO

32-BIT ENVIRONS

1 2

1 2

1

2

10/31/8^

10/31/84

12/31/84

INTEGRATION TESTING 2/28/85

INTERNET PROTOCOL TESTING 1 3/31/85

INSTALLATION TESTING.

DISTRIBUTION TO TEST 1

CENTERS. FIELD TESTING

4/30/85
0 ^\wnm\

RI Wlin TEST MESS

/ /

1) MAXira l,£vEL CF STPFFLMG (AT LEAST 1 STPFF/'ERITEM)

2) mximcTORFeo

3) START DATE 9/V8^1

4) AVAILABILITY CF MBS VAX E€VEH)Fi£i\T SYSTB1 BY START DATE

(EARLIEST DELIVER/ D.ATE; OaCEER '84. EARLIEST AVAILABLE

EATE: NGVETBER '8^1)

5) S7ARATE EVELDFTeT PATH FOR IITIERNEJ WITH IP IMSTALLH]

AM) RUINING (READY FOR PROTOCOL TESTING) BY 2/1/85

6) SEPARATE IBELCfTEIT PATES FOR EXTENDING. UPDATING

TP«P0RT AND FOR FTP; SEPARATE TESTING CF TDDIFIED

^ TRANSPORT AND CF FTP.

0 LIKELY SLIPPAGE;

3 iTOES (FOR ASSlAPTIdl #4) TO 7/31/85.

0.
ENCODER/DECODER

TIME-TO-COMPLETE (PM)

DESIGN. CODE. . CRITICAL CRITICAL PATH

SPECIFY UNIT TEST PftTH TIME COMPLETE DATE

m 2 2 4 ]

E/D 2 2

COMPARATOR 2 2 4

XMIT/RCV 2 2 4

> 12/31/84

LOG ANALYZERS 2 2 4

RER 2 2 4

USER COmAND LANGUAGE 1

TEST CASES 1

INTEGRATION TESTING 1 1/31/85

IP TESTING 1 2/28/85

INSTALLATION TESTING. 1 3/31/85

DISTRIBUTION TO TEST

CENTERS. FIELD TESTING
ENCODER/DECODER

0 ASSUMPTIONS:

1 ) MAXIMUM LEVEL OF STAFFING (AT LEAST 1 STAFF PER ITEM),

2) MAXIMUM DEGREE OF CONCURRENCY

3) START DATE: 9/4/84

4) AVAILABILITY OF MBS VAX DEVELOPMENT SYSTEM BY START

DATE (EARLIEST DELIVERY DATES OCTOBER '84. EARLIEST

AVAILABLE DATE: NOVEMBER '84)

5 ) SEPARATE DEVELOPMENT PATH FOR INTERNET WITH IP

INSTALLED AND RUNNING (READY FOR PROTOCOL TESTING)

BY 2/1/85.

6) SEPARATE DEVELOPMENT PATHS FOR EXTENDING. UPDATING

TRANSPORT AND FOR FTP: SEPARATE TESTING OF MODIFIED

TRANSPORT AND OF FTP.

0 LIKELY SLIPPAGE:

3 MONTHS ( FOR ASSUMPTION #4) TO 6/30/85

+4 MONTHS (FOR ASSUMPTIONS #1. #2) TO 10/31/85

nr:
18

Basic

IPDU

Tvpes

IPDUs

NLPID=81

(hex)

(Leaves

of

Tree)

by

Structural

Taxonomy c

I! 1IIIIIIIII«IB

IIII

ijOhdi UJe ha.i/e '

l. /(iheckin^ 5ervlce-'^r^'mi-/->'\>^S

* Ccmetrhn

-'p,^T<a 'TmAnsf<s.r

• ^^PBclUe.^ Tra.n$fer

X, S^mi- y'Ccnneitiffn Orien'^&‘^

9

9

9

ljil>

-fo 3 c^hctcrren^ csnnec/;^^/)^

ff\M he in:ii'c<fec/ fna.ntta.f/^

dtfefyni ne ^^ccc<^b.

3. 370 ^ce-f\c^r\ 05

c^t>
’\X}hsjf l/Oe Iskc. TO

9 ITi^re oMoT<>xh'&n csitsecu4iye

hm0t htervenr>m

• /??j>te i-tsu/* SAnl^^a

, (khrf^atsi A^S'nj of r.nl-frpk conoutf^i-

•XL^StS

^ S } .

«is» fPOoniJ l^^-iriuif^rt^onoa

peto v^ulRe

JC5

0 /Mlock!n^P<--

'hidmurJ r> ne^ot;oJ-!en

L4 C/ianf& odei orJeHn^

tAroete'r i. Cceje

® Ch^n'se c^nito j

s Scen^rsOS-*kior-e 6h?^sfer

9/d/^
'Tj'/sie T&^f’

rr\cr\4hs

•Jest a.^hync,h'Gr\

1

^ ^3

//

'c/

_ ;^^3 ifisyi'hh^

^ /;2.-/ 3

> rr\oAihi^ ^

JVC
!it^ ?44f

'*€<^

yU4^

T^/'

- s_ 5

-’ I Uj^ f^y

J

4/^ P^

Sfi9!«/} PP-^So/stf/" X.ys>0 1% PX7
4tf.

4^

pTT^Sf

j AHc^:yi_

PlatHU^f 4c^>^

/ttr/ pH \f}sftPvaf pie

Uhhh PO^A/tcHpinifijhi

PPO AHcaPf^e-PecHpeH s#/ra#y/r

SHt^leHetHf"oe<ip9CHlmad'iH-ei

h*,6i/iHpriaai ;

- - ^-e/iee* *>xHJr

/s~nP^

I

i

/HtD n/i/rv
9'. : Tif^'^P/ / pj^OUP^ !'‘i fr. ^f-lr»4 h-'

I T X ‘{00 7^^/^ 7^/ <7 /tC^'

JpA €r<:> GPts /

i/i^^ 5 ?

f Jecs>/er so'Mwoff

T/i?//^-7v'’

fGiG

>,An

-p i /^/Y)

i- //h

3 /^'J^

iP/yj

A A/>)

/o /Yyj

e^Y>?

i~yp7

/ tP]!) } rCy

/? /y{? /V/7 r-^ / j)PO 'UcAf l y^jy / fp? h/’^y

/[yA(jy/ ^

/y?A'y

eyipyi /h/) T^

OfAn^'-dA^ ;

-cPji-^fpni/ cCAf u fi><’,(p/) s Tr'if/^'?/^.

'^/6

I/* A#.

OSI WORKSHOP; Request for Information "

Please provide the information requested below by Monday, October 29, 1S84

to:

John Heafner

National Bureau of Standards

8218 Technology

Gaithersburg, MD 20899

This Info^nnation is needed for planning and promoting the development of

OSI implementations. It will be made public. A 11st of the organizations

submitting the information will be made public but organizations (-nil not

be individually identified with the information they provide.

1. My organization Kdll make prototype implementations available for

multi -organization testing by the following dates.

- Subnet’works (identify which, e.g., 802.3, X.25)

(Please provide dates.)

“ The conformance subset of the ISO connectionless internetwork protocol.

(Please provide date.)

- The ISO transport class 4.

(Please provide date.)

“ The ISO session protocol

(Please provide date.)

- The ISO FTAfI subset chosen by the workshop participants,

(Please provide date.)

- The CCITT 400 series draft recoiniiendations for messaging.

(Please provide date.)

2 . My organization is willing to participate in one or more of the following

exhibitiens. (Please indicate which protocols will be available for ooch o.:hi;

NCC: ^ d Intec:

Autofac:

ACM:

Hanover Fair:

July, 1985

August, 1985

Oetreb^w^-l 985 ^ ~ ^

October, 1935

April, 1986

3. The organization participating in the NBS OSI impl emientation workshops j..! ; to construct a multi -organization concatenated network and leave their • attached for perhaps 24 to 36 months for the purposes of: a) dcvplo; ' g r testing OSI protocols, and b) demonstrating OSI. My organization will o a system(s) on the foUcvnnq date,

(Please give date.)

The protocols available for mul ti -erganizati on testing will be avai'a:-l-_

system on the dates given in item 1 above.
CC!TT Message Handling System

Model, Services and Protocol

September 7, I Q54

Arthur R. Pope

Bolt Bersnek snd Newmsn Inc.
CCITT X.4Q(13Qnm

jghl Draft Rscommendatlons form the X.^'OO

eries on Message Handling Systems;

X.400 - System Model— SerYke Elements

X.401 - Basic Service Elements and Optional

User Fadllliss

X.408 ~ Encoded Information Type

Conversion Rules

X.409 ~ Presentation Transfer Syntax and

Holalion

X.410 - Remote Operations and Reliable

Transfer Server

X.41 1 - Message Transfer Layer

X.420 ” Interpersonal Messaging User Agent

Layer

I X.430 ” Access Protocol for Telsles

Terminals
CCITT X.4Q0 Tutorial - Outline

1. What is a Message Handling System?

2. What services are provided by a Message Handling

System?

3. How are the users of Message Handling Systems

named?

4. Where does a Message Handling System belong In the

Basic Reference Model for Open Systems

Interconnection?

5. What Is the X.409 presentation transfer syntax?

6. What are the protocols used In a Message Handling

System?

7. Special topics:

a) How Teletex users may access Message Handling

Systems.

b) How Message Handling Systems facilitate

communication between different kinds of devices.

c) The Reliable Transfer Server and Its use of the

Session Service.

d) Areas for future consideration.
Flectronic mail : Users exchange messages—

analogous to postal seryice.

A collection of

computer systems, interconnected so as to

provide an electronic mail service.

A Message Handling System provides fast,

effidsnl, message-oriented commurslcallon,

within a building or around the ¥#orld.

Ml
Functional Model of a Message

Handling System '

The functional components of a Message

Handling System are:

User Agents (UAs). which help users

prepare and receive messages.

Message Transfer Agents (MTAs). which

transport messages across the network.

The Message Transfer Agents are interconnected

to form a Message Transfer System (MTS) .

The Message Transfer System provides a

general, application-independent, slore-andforward message transfer service.

An originator sends a message through a process

called submission. A recipient receives it

through a process called delivery.

A message consists of a message content and a

message envelope .

The message envelope contains the information

necessary to route and deliver the message to

its recipients. The message content is generally

transferred without change by the Message

Transfer System.
The !nterD8rsQDa]Jtesaamg_„Sy£tm

The intsrDersQi^LMgS5gqmti.Sv5i^liEBSl

builds on Ihe Message Transfer System,

supplying services of parikylar use to

individuals.

The Interpersonal Messaglog System comprises

the Message Transfer System and a specific

class of cooperating User Agents.

The messages exchanged by users of the iPMS

are of a certain form, called IP-messages .

IP-messages are analogous to typical office

memoranda. Each has a heading and a body .

The heading Includes such information as "to:',

“from:", “subject:", "cc:“.
Functional riodel of an MHS
PMslca

A Message Transfer Agent resides In a

computer system.

A User Agent may reside In a computer

system, an Inlslligenl lermlnal, or be

dislribuled among both.

A User Agent may reside in the same computer

system as a Message Transfer Agent, or in a

physically separate compulsr system.

Many User Agents may be co-residenl with a

single Message Transfer Agent.
Organizational Mapping -

A collection of at least one Message Transfer

Agent and zero or more User Agents owned by

an organization constitutes a Management

Domain .

Administration Mangement Domains (ADMDs)

are operated by PTTs and RPOAs.

Private Management Domains (PRMDs) are

operated by other organizations.

Message Transfer Service

Basic message transfer, including:

Message identification.

Non-delivery notification.

Delivery notification.

Submission and delivery time stamps.

Urgent, non-urgent or normal delivery.

Multi-destination delivery.

Disclosure of other recipients.

Alternate recipient allowed.

Deferred delivery.

Deferred delivery cancellation.

Return of message contents.

Conversion of message body, including:

Explicit conversion.

Implicit conversion.

Probe.

Hold for delivery.
Basic interpspsona'

’ 8 e »

Primary, copy s

CrossBody er?

• B) « Q «

S i d S ^d i a s
Whafs in a name?

Users of the Message Handling System are

identified by originator/redpient names (0/R

names).

An 0/R name is a set of attributes, where an

attribute is either assigned by some naming

authority or chosen to be descriptive of the

thing being named.

Personal attributes : personal name.

Geographical attributes : street, town, country.

Organizational attributes : org. name, position.

Architectural attributes : X. 121, MD name.

Each 0/R name must include, at minimum,

attributes which identify the Management

Domain to which the user subscribes. This is

the base attribute set.

Initially, two forms of base attribute set are to

be supported by every Management Domain:

Country name and MD name.

X.121 address.

Additional attributes, such as organization and

personal name, identify the user within the

Management Domain.

:230
Services ara classineo see

may hP:

for a per

sekcle

for a

ceilvery

srsioo, hold for

relurn of cenlenls are additional

ne

r~C

and sensitivity

•§ • i
Layered Description of the IPMS

UHL

lUTL

SBflillUAE

IVI I A 1_

lili! '

*

^ MTAEl^ liiiii

P2

Pi MTAE P3

is:: UAEI

lirxnnxa

li

Both MHS layers lie within the Application Layer

of the OSI Reference Model.

Definitions

UAE — User Agent Entity

MTAE — Message Transfer Agent Entity

SDE — Submission and Delivery Entity

PI — Message Transfer Protocol

P2 — Interpersonal Messaging Protocol

P3 — Submission and Delivery Protocol
Presentatio n

CCilT Drsfl Rscommendalioii X.409 defines an

encoding scheme for protocol data units, and a

nolaiion for describing protocol data units.

Simple primifJve types: BOCIEAI^, INTE6ER,

BIT STRIN6, OCTET STRIHS.

Combined using conslriictor types: CHOICE,

SET, SEQUEMCE.

Using this convention, one can describe the

form of arbitrarily complex protocol data

units.

Each type is encoded as:

a particular identifier of one or mors

octets.

the leri-gth of the encoded type. In one or

more octsls.

the contents of the type, encoded in a form

according to the type.

For example, the value TRUE of type BOOLEAN

is encoded as:

identifier - 01

length ^ 0

1

1 g

content =FF|g
The Message Transfer Protocol

Denoted Ei. Its protocol data units are hPDIJs.

specified in notation defined in CCITT Draft

Recommendation X.409.

Relies on underlying Basic Activity Subset of

Session Service (CCITT Draft Recommendation

X.215).

Carries messages, probes and delivery reports

from one Message Transfer Agent to another.

MPDU CHOICE {UserMPDU,

DeliveryRepcrtMPDU,

ProbeMPDU}

UserMPDU ::= SEQUENCE {Envelope, Content}

Envelope ::= SET {

MPDUldentifier,

originator ORName,

priority INTEGER

(normal (0), nonurgent (1), Urgent (2)1

recipients SEQUENCE OF ORName}

ORName SEQUENCE OF Attribute

Content ::= OCTET STRING
interpersonal Messaging Protocol

Denoted £2- Its protocol data units are

UAPPUs. specified in notation defined In CCiTT

Draft Recommendation X.409.

Relies on the Message Transfer Service to

transfer UAPDUs between User Agents.

UAPDUs are IP-messages and status reports

(receipt and non-receipt notifications).

UAPDU CHOICE {!P-Message, SiatusReport}

IP-Message SEQUENCE {Heading, Body)

Heading :;= SET {

! P-Message-ldenti fi er

,

originator ORName OPTIONAL

,

primaryRecipients SEQUENCE OF ORName,

copyRecipients SEQUENCE OF ORName,

blindCopyRecipients SEQUENCE OF ORName,

subject OCTET STR1N6 OPTIONAL,

crossReferences SEQUENCE OF

IP-Message-Idenli fieri

Body ::= SEQUENCE OF BodyPart

BodyPart ::= OCTET STR1N6
Submission and Delivery Protocol

Denoted It is in the style of a Remote

Procedure Cali protocol, where the operations

(remote procedure calls) are specified in the

notation defined in CCITT Draft

Recommendations X.409 and X.410.

Relies on underlying Basic Activity Subset of

Session Service (CCITT Draft Recommendation

X.215).

Has operations for;

Submitting a message or probe

Cancelling a previously-submitted message

Delivering a message

Notifying of message (non-)delivery

Changing subscription parameters

There is also a mechanism for access control,

based on passwords.
Teletex Access to a MHS

Teletex users may access a Message Handling

System through the Teletex system,

CCITT Draft Recommendation X.430.

A Teletex Access Unit CTTXAU) is a gateway

between a Teletex system and an MHS.

Using the Teletex system, the TTXAU

exchanges documents with a Teletex user. The

form of these documents and the manner in

which they are exchanged are called the

Teletex Access Protocol (P5) .

P5 is based upon S.62.

The TTXAU is co-resident with an MTAE, from

which it obtains the Message Transfer Service.

It uses this service, and the P2 protocol, to

exchange messages with User Agents, on

behalf of the Teletex user.

The TTXAU may provide document storage for

the Teletex user.
Different Kinds of Devices

User Agents may differ in their capabilities for

rendering different information representations:

text, facsimile, videotex, voice, structured

documents.

These different representations are called

encoded information types .

The body of an IP-message may be represented

using one or a mixture of different encoded

information types.

Each User Agent may register with the Message

Transfer Service the encoded information types

it can accept.

The Message Transfer Service can convert among

encoded information types.

Conversion may be:

invoked explicitly by the user,

performed by the Message Transfer System

if it is found to be necessary, or,

prohibited by the user.

Examples of conversions described in X.408:

text to facsimile

structured document to text
The Reliable Transfer Server

The Message Transfer Protocol and the

Submission and Delivery Protocol both use a

mechanism called the Reliable Transfer Server

(RTS), described in CCiTT Draft

Recommendation X.410.

The Reliable Transfer Server is a functional

entity that resides in a computer system. It

uses the Session Service to reliably move

application layer protocol data units from one

system to another.

The Reliable Transfer Server takes care of;

establishing and releasing sessions

negotiating the use of checkpoints

inserting checkpoints in the data stream it

sends

recovering lost sessions

resuming data transfer at a recent

checkpoint

A small amount of protocol is exchanged

between the Reliable Transfer Server and its

peer in accomplishing this.
Areas for Future Consideration

User-friendly 0/R names.

Directory services to support user-friendly

names.

Compatibility with ISO Message-Oriented Text

Interchange System standards.
MHS Demonstration Proposal -

Message Transfer Service and Interpersonal Messaging

Service.

Each participant supplies one or more Management

Domains.

Each Management Domain contains:

one or more Message Transfer Agents; and

zero or more User Agents.

PI implemented by all participants.

P2 implemented by some participants.

P3 and P5 need not be implemented.

All essential optional user facilities Implemented.

Additional optional user facilities need not be

implemented.

0/R name contains Management Domain name and^

possibly^ personal name.

User Agents support lASText encoded information type.

Participants are free to construct User Agent user

interfaces as they wish.

I Participants must implement Basic Activity Subset of

Session Service.
4tV.

SNPCP

FDR X. a S’

To PKDVIOS

THE CLN S

PFTIT- / S
•THf'

£.#VV£7i

c^93
CMP

^ P^^Ticuir^^ ^uB^rrw©AX
Rote'S OF

)

N6Ty^$RK

PKDTOCdL

- $^^c?

- SN^CP ^ Si^xcp

fi ML PRdTOCSt FHiPiCL

pm n4B%^ ncc€^ 0^ ?Mnvju^ ^irmnoM

ryp" hPtM^ PROTOCOL PULpiLC

^XPPSR^T R0LS1> P- VlPP^€7^T

^(TUpTidN ^ S!N&€ ML PROTOCOL PfM-Y ^0^)^

PtKX THe PU0CTIOMS OP PROTOCOLS

ePeRPT^M^ iN 7M€ ROLL’S

1

??15'V
WHY S/yDCPi?

sNficPs> P^yipr ViPPe^r c^p^u770 R^pecr Tc rye

^€TPi$kK ^eRV/ce (c$^ ca/s)

T :—

3k
WHAr B30UT SNICPsl

- AiSuMPT7e<V5 A/ifi-oe a-b^t

UNpeiKLi//ii(r iSTRi/ices a-rbI cr^O

;

THrV NST^ 6/^ TUB %T7CS Mi T>MTICHLM

* PR0TOCOC 715

Ct^S (^>2^ S¥73)

clhs

DXS SMT3

P/S

sbt op shoo

VlXH CTlM$j

NO PROTOcet

H

^^.dTOtOt 7*0

n^owip€‘ Ci^A^S

f" i~

?

x»

^^

pricer l^sl

pa^tdcoc
PATA trmsfer

• pfK^Krr

IZir Ocrers-j

• M-B/T ?OR se&fifMT7m ^

IP CL-P0U>IZ9

• D-siTj a-®/?*! H^r

(PI$CA».6 P-0»t)

I NTe mm rnMSFE^

• WOT //rs'^6^

• 0/5C^RO
FLOW COMTnOL

*2-, Mirw0i^ rtsr

AVAltASti”

Pee*^ kEcewi-mr^^e^^y

_i*2*!i^^-a5i»

- /^€>g VfkTUM^ CfH^UtT

- aari^r

^ xas* T© ^A7T

STAWS
R£S£T

•PISCAP-P

TP'MiMlWeD/ l^eCSiVSD

hv2>lT‘ $Siet)AS>iCe it>6MS

©y |SX.^S‘ SMCK«^ L^£t)

VficA^p kSisr mstCi^T)*^

cJ2-6
OPT^O

F^ciLine’

' MOM

P Bi%€^

« CkO^CD &^§UP

pE^piiA^r

HVLHTT ^'KPuP

# Ol^L* UP

J^2
PfiCKgT IBVeL

Tm

Tts/Rts

AtrN^T

r^7/ Rt*?

V©r

NOT

'c^u 5cr« ^

( Rf$?75

(WiNPcyi) . 0

Cm7€%%iiPT)

MSCD . iRr^rcr)

u^ro

c Br^/3rRA77#^)

«^rP

• Lo^iCPtL tHMN^l,

( Hrxr vffir)
^OPs

t^c/^OC
CmsBjVIfiCr WFO

0 (^B), ^€:>r^T I Uf) PACHi^

STPAT€^V;P/scA^^

NAi WANT To NONtroA

?©«^tOW/^^ C4U5C5.’

- X>Tt 0^)^m^T€p

' Ov^r ©? ©1^1? S’

A

“ pT€ ops^mm

- Nu^»3^eR

- ftccc^s

- NsTwfAX O^PAV^Al

“ N€T)fi^k^ CS^C^T/®;^

^ Nrr^^^K ©«T os»p«^

>/

>/

y

Rtf

PVeT5V£.

y

y

/

v/

c:2^r
X.IS" CALL S£ruP

• 1^0 HU 3TiHUiLyf$

* SHPC. PIAHCTI^N

Av^ltf^Sl^C Lt^ P€$T:

^p'SNo Hms atis^J

Jti'7
Chii

• HO HL sTi^UU

% SHOO ptxNcrioM

- 1^0 PAT^ ^©A

•• N^CP hH&TH€R i.C

^ — pvo o<> yo

- iMWT'TINi

c^5
x\i\hvVfkE^5 xpmn^i • RrMVS: c4, p

« c/vp ^vsT^s.* a,c

X^^T1^5 X)Zl

I^CV^* Xa!

a

I

P?^Z'i7

fieejJTS

IfiT^

Ji<f!

^5^^ -2^
X.X5 L£M€l^ i + X

tCVCt

• i.AP8

• PAAMB

' T2. : ;#%, gia, c^J-a > t^)

- T3: x^ic i73j^T±) mr U3^p

^

• r^5 ^S5«a^C€'

• A?i

* ^

/b/7"4)

etrrrs

- j srtftrj

• NutrTCfJiM

h^UkA l^i-^nc):

pmd’^c
C‘>)

Proposal for Implementors of OSI for Use of the

Connectionless Internetwork Protocol (ISO DIS 8473)

Over X.25 Subnetworks

August 1984

1 . General ^

This paper briefly describes the operation of a subnetwork

dependent convergence function to provide a connectionless

subnetwork service (as required by the Protocol for Providing

the Connectionless-Mode Network Service. DIS 8473) over an X.25

subnetwork. The method described here may be generalized for

use over other connection-oriented subnetworks This paper is

specifically oriented towards use in a proposed internetwork

demonstration making use of a variety of subnetworks

interconnected using the protocol defined in DIS 8473.

To avoid confusion, in this paper the Protocol for Providing

the Connectionless-Mode Network Service las described in DIS 8473)

will be referred to as the Internetwork Protocol or "IP".

2 Management of Logical Channels

The most difficult issue to be considered is when to open

and close X.25 logical channels (subnetwork connections).

Opening of logical channels can be initiated by three

events (1) The arrival of a data unit (or data request from a user in an end system) to be transmitted over the X.25 subnetwork

where, there is no appropriate logical channel available; (2)

Additional logical channels may be opened when the local queue

exceeds a certain threshold size, (3) Logical Channels may be

opened by intervention of the network management system (possibly

by explicit human interaction).

Closing of logical channels can similarly be initiated by

three events; (1) The expiration of a timeout period following

transmission of one or more PDUs , (2) The need to use a specific

interface to open an alternate logical channel from the local

Network Layer entity to a different remote Network Layer entity.

(3) explicit intervention by the network management system

(possibly by explicit human intervention).

The timeout period for closing logical channels may. in

general, be chosen by economic and implementation specific means.

For example, if there is no duration charge for leaving a logical

channel open, and if there is a large charge or time delay in

opening logical channels, then the timeout period may be very

large (or even infinite). The timeout period may vary with the

time of day, traffic load (averaged over the recent past), or other factors. The timeout period for additional logical

channels (opened when there is an excessive queue of data units

waiting for the first channel) may be shorter than the timeout

.M3
period for the first channel (for example, some implementations

may choose to close all additional logical channels if the queue

reaches zero). In the simplest implementation, the timeout

period may be a fixed period of time.

For demonstration purposes, it is proposed that logical

channels be classified into two categories "Type A" logical

channels are left open "semi -permanent ly" (for the duration of

the demonstration), and can be closed only by human action.

"Type B" logical channels are closed when either end system

determines that there has been no traffic on that channel in

either direction for a duration of five minutes.

3. Addressing

In general, the IP does not constrain the addressing scheme

used by underlying subnetworks. Thus the addresses used in

subnetwork service requests will be precisely the addresses to be

used in the X.25 call request packet, and are separate from the

NSAP addresses used in the IP header Routing tables are used to

determine the subnetwork on which to transmit the data unit, and

the subnetwork address to be used on that subnetwork.

More specifically, at each source and intermediate system

along the path followed by a particular d-ata unit, there are two

possibilities. (1) the next IP entity to handle the data unit

will be located within a gateway on a local subnetwork, or (2)

the next IP entity to handle the data unit will be located within

the destination of the data unit. In case (1), the subnetwork to

be used and the subnetwork address of the gateway are both

determined from routing tables. In case (2), The subnetwork and

destination address on that subnetwork to use are both identified

by the destination NSAP address

4. Data Transfer

Data Transfer over logical channels occurs in a full

duplex (two-way) manner

The service requires that the subnetwork be capable of

carrying a data unit of up to 255 octets in length. It will be

desirable in many cases to carry data units larger than this, if

necessary by use of the M bit facility.

5. Quality of Service Maintenance

It is proposed that for the purposes of the demonstration,

no specific quality of service maintenance functions are

necessary. This implies that the "QOS Maintenance” and

"Security" optional fields of the IP header are not used.
6. Detailed Spec i f i cat i on of SNDCF Operation r.

This section provides a detailed specification of the

operation of the subnetwork dependent convergence function.

81 Service Provided by the SNDCF

The subnetwork service provided by the SNDCF is precisely

the service required by the IP. and is abstractly summarized by

the following table of service primitives:

Primitives Parameters

I SN_UN1 TDATA„reques t j SN„Des 1 1 na t i on_„Addr ess |

1 SN_UNITDATA„i ndi cat i on 1 SN_Source_Address |

I 1 SN„Qua 1 i ty_o f „Serv I ce |

I

1 SN„Userdata |

The SN_Source_Address and SN_Dest mat i on„Address are

subnetwork dependent. Thus, in this case, these are the

X 121 addresses used by the X.25 subnetwork. The SN_Userdata

parameter carries user data up to a specified maximum size.

6.2 SNDCF Operations

The protocol actions described here are ali performed within

the SNDCF, and are therefore logically separate from actions of

the IP entities. Thus, for example, the destination address

parameter in the SN_UNI TDATA_reques t is the immediate address

on the local subnetwork to which the pdu is to be sent. No

additional routing table within the SNDCF is necessary except

to determine which logical channel to use for a particular

destination address. The subnetwork itself is likely to perform

routing internally, but this again is independent of the SNDCF.

The operations initiated by an SN_UNI TDATA_r eques t are complex enough that they will be described using a sort of

pseudo-code. The operations initiated by the management

function, or by timeout, are simple enough that they can be

informally described in English text.
6 2.1 Operations Initiated by an SN_UNITDATA_request

begin

check destination X.12I address to logical channel mapping

if (existing logical channel is available) then

begin

add outgoing pdu to queue for existing logical channel;

reset the timer for the logical channel,

if (queue length exceeds threshold) then

open an additional logical channel.

end

.

else if (new logical channel can be opened) then

begin

open new channel (note; this may require closing

an existing channel),

start the timer for the new logical channel,

add pdu to queue for the new channel,

end

.

else

discard data unit;

end

.

6.2.2 Operations Initiated by The Management Function

When requested by the management function, the SNDCF may

open a new logical channel, clear an existing logical channel.,

reset an existing logical channel, restart all logical channels

over a given interface, or provide status information

62.3 Operations Initiated by Timeout

When a timeout occurs on a given logical channel, the channel

IS closed.
I'F even P9"r

CLOStf^St 40S/OI4.

MT V£^*)

- Tg)n‘Pc‘R0liY VAT^

•‘C^osS •* /?4.£ y

- fi"»VlTlOKfAt - ¥^H£s^ (S

^

-CcoS£ ** © — C ^£'PL£

"' **£ ^7^)a 7~07^ 0C9££ t~c

?/9"P£fiy 099»Tt^»^t^ ^C. “8T OTf*^ c:9f?^^

B’PyR£Sf£f «3g*i«»^ ^5<?;?
- FULU. ’^)4Fc£ X

M9/r >^rt€X€

S£t,€c,T
6 » T9 %

h>>h ^ Ds^q V ^4i?iP.

n Oof 6«e4 ^TS. 5-«rv/i#5 P)

C»^A l/M-c^

^

5*«ry/«#5 o#»«^ ^2

/ir9i*^*f

I /'2 $Aov/il

5y-^ffr4#< Oasti ^ ii )ti9/ti»)nt ca^^# &//#/*•

$i«»l«l ^««(4

^

Cr^uh'^n c^iri^y

3J ^ ^

3*® 'i't ^mp *ni^9 &0

S

^ ^ TSa^s^/k OP£A^r/j^'

/*^f^»S*pAu,

"~ io •)

^ ^Jspi Si^AU.

c»»t V4^/|*0H5

fi

^

4" 0 ^ 9 a >^ , “

C/l»4 A^J t'^J^fi,hA-^^ hrrjA

XCJs-X!/ 9/?/ry

M‘?
V/ Hr ^ ^ Su/l f9^r ^ s

^

^9-t, ^^^9

fr* ^*fi h»

¥'f’^9t}sf)$* (/s* r

pf^

0 fr>^i*'fir>^

e^^/»i>u Jmi-SL

7'€/>^ Ij^

K*plu /© Oi*ri

p9r4AAC*

th%

~~ ^*Jt4 *^^*r HiA

^7C

jra-J"/ ‘i!^
/^J2 5£a^C TrsLfi%f^r

/)/ 0 T Dz^o — Pfi.oB^ — C OA/Ke'AS#«»v

' P^toRiTV

”

^fffs^^so dsuv^^y

”

K^ivtii *f c»r»^*/*yi

^ )lh± !n '9^*^ m i

> %AfpUrsn^ffi 4mf% !i\ ^$fs)^n'fi'»r}

, ,^7 /

4th

0

"70

« ro-es6(X<^€ is S-et^+

^eT u) e.-e.v\ fr)"T s ^

^ecjoe^(L€. 0-? SSbO's oo

^ SesS\c.vi Co<^r)ec\): 6vr|

_ |f)^^5

<\r<. dt\-!koI

® 1\s 0> ^C<“kV ^ TCS osec^ -fo^ mTPi

oes5'iC)r)5 (Arc. (Allovsei^ "^0 Sor\ilv;2

C)i A *1 tr) C^OrtO'tc.TIi'c'^

Ji-ns

/ /
o I C

(y» %

iv. ^

f^\ I$n

u

ft\

Cl§

<5 AO

'll

>1

^2

iS

fs» Is

J-IH ^

(/

9yp//l.

IlfffX

99^1/
•T/"-

"Ose^<^ ,f osr sw^^‘

^'

'tiXlf ZCt iyt

ZcP’c.'zf^ .* T" Z T^

<J \-3^

^^4ex C(^/p

B/,J

X7S'
TRANSPORT PROTOCOL

Alignment Changes

There are two changes necessary to bring the demo version in line with

the ISO specification:

1. Octet Ordering - the order of octets in multi octet binary fields

has been changed from least significant octet first to most

significant octet first.

2. Parameter Code - tne value of the flow control parameter has

been cnanged to 1000 1100 make it unique (it nad tne same value

as another parameter).
Proposal for Demonstration of

Message Handling System Standards

Overview

A Message Handling System is a collection of computer systems, interconnected so as

to provide a service whereby users may exchange electronic mail messages. The CCITT

have produced a series of Draft Recommendations the X 400 series, that define

standard ways in which Message Handling Systems may be interconnected. Herein we

propose a cooperative demonstration of a practical Message Handling System based on

the CCITT X.400 series of Draft Recommendations.

Background

The CCITT X.400 series specifies the service elements and protocols for Message

Handling Systems There are two message handling services. the Message Transfer

Service and the Inter-personal Messaging Service. The Message Transfer Service is sufficiently general that any application can use it to transfer data in a store-andforward manner. The protocols used to provide the Message Transfer Service are

specified in Draft Recommendation X.411.

While any application can use the Message Transfer Service, the CCITT recognized that

normally the Message Transfer Service would be used by individuals to send messages

to each other Accordingly the CCITT developed an Interpersonal Messaging Service to accomodate this kind of communication. The Interpersonal Messaging Service is implemented using the facilities of the Message Transfer Service. Tne protocols used

to provide this service are specified in Draft Recommendation X.42C

The CCITT views a Message Handling System as comprising Message Transfer Agents

responsible for routing and transferring messages and User Agents responsible for

supporting users in their roles as message originators and recipients A. collection of

Message Transfer .Agents and User Agents provided by a single organization is called a Management Domain The CCITT concerns itself with stanaardizing the communication

between Management Domains (such as communication between Message Transfer Agents

in different Management Domains) but the standards it develops may be used within

Management Domains as well

The Message Transfer Agents in one Management Domain communicate with .Message

Transfer Agents in other Management Domains by means of the standard protocol P1

defined in Draft Recommendation X4ii. User Agents communicate by means of the

standard protocol P2, defined in Draft Recommendation X 420. Finally, a User Agent

may communicate with a Message Transfer Agent by means of the standard protocol PT

defined in Draft Recomimendation X.411. PI and P3 make use of a F.elxablc Trans^r^

Service, defined in Draft Recommendation X.410. that reliably transfers data using the

Session Service.
Users of the Message Handling System are assigned names so that they may be

identified as the originators and recipients of messages. These are called 0/R names

CCITT Draft Recommendation X.400 prescribes two forms of 0/R name; one containing

the name of the Management Domain which serves the user, and the other containing an X.121 address identifying the user's point of attachment to a public data network.

This latter form is intended primarily for naming users who access the Message

Handling Service via Teletex terminals. They make use of the Message Handling System

indirectly, by means of the Teletex service and a standard protocol Po. defined in

CCITT Draft Recommendation X.430.

Draft Recommendation X.401 lists the service elements of the Message

and the Interpersonal Messaging Service. The basic service elements

are defined in Sections 2.1 and 3 1 of that document. In Recommendation X.401 defines service elements that are optional for

but essential for the service provider to implement. These are

optional user facilities. There are also service elements that may

implemented. These are called additional optional ziser facilities

Transfer Service

of both services

addition. Draft

the user to use

called essential

or may not be

The service elements of the Interpersonal Messaging Service are further categorized as essential or additional for each of the sending and receiving User .Agents. There are certain service elements that a svstem need not provide for its users who originate

messages but that it must recognize in messages it. receives Tables 1 X.401 through

4 'X401 list the essential and optional user facilities for the Message Transfer Service

and the Interpersonal Messaging Service There are aisc local functions of the

Interpersonal Messaging Service, such as a message editing capability or a user alert

wnen a new message arrives, that are not subject to standardization but will be

provided in most implementations

The Message Transfer Service makes extensive use of the Basic Activity Subset of the

Session Service described in CCITT Draft Recommendation X.215 The following

functional units of the Session Service are used, kernal functional unit, half-duplex

functional unit, minor synchronize functional unit, exceptions functional unit and

activity management functional unit. The use of the Session Service is described in

Section 4 of Draft Recommendation X.410.

Proposal

We propose a demonstration of a practical Message Handling System based on the

CCITT X.400 series of Draft Recommendations. The demonstration would involve a number of participants each contributing some portion of the overall Message Handling

System. It would serve to demonstrate both the utility of the Recommendations and

the ability of each participant to implement the Recommendations

The scope of the proposed demonstration is described below It defines the minimum

degree of functionality which would be supported by each participant in the

demonstration, individual participants would not be constrained from exceeding this

minimum, for example by supporting additional optional services or protocols

jn
1. The demonstration would illustrate the Message Transfer Service and the

Interpersonal Messaging Service

2. Each participant would supply one or more Management Domains

3. Each Management Domain would comprise one or more Message Transfer

Agents and zero or more User Agents Each participant would therefore

implement Pi If the Management Domainlsi contributed by a participant

included User Agents, that participant would also implement P2. Participants

need not implement P3 or P5.

4 Participants would implement all essential optional user facilities They ma>’' implement additional optional user facilities at their own discretion.

5. O.-'R names would be restricted to those forms that, contain a Management

Domain name and, perhaps, a personal name

6 Each User Agent would support the "lASText” encoded information type (: e.. simple text messages) Participants may implement other encoded

information types, such as facsimile or voice at their own discretion

7. Access 10 the Message Transfer Service by means of the Teietex service,

using the P5 protocol and procedures defined in Draft Recommendation

X.430. would not be included in the demonstration.

0. Participants would be free to design and build their User Agents user

interfaces as they wish

9, Each participant would implement the Basic Activity Subset of the Session

Service, including the functional units listed in the previous section

References

[l] Draft Recommendanon X.27 5. Session Service Definition

CCITT. 1984.

Draft Recommendation X 400 Message Handling Systems: System Model

Service Elements

CCITT. 1984.

[3]

Draft Recommendation X 401 Message Handling Systems. Sasic Service Elemeniz

and Optional User Facilities

CCITT. 1984.

[ 4

]

Draft Recommendation X 410 Message Handling Systems. Remote Operations end

Reliable Transfer Server

CCITT, 1984.

[5]

Draft Recommendation X.41 1 . Message Handling Systems. Message Transfer

Layer

CCITT, 1984

[6]

Draft recommendation X.420: Message Handling Systems. Interpersonal

Messaging User Agent Layer

CCITT, 1984.

[<] Draft Recommendation X 430. Message Handling Systems. Access Protocol for

Teietex Terminals

CCITT. 1984
CONNECTIONLESS INTERNETWORK PROTOCOL

OVERVIEW
PROPERTIES

• DRAFT INTERNATIONAL STANDARD

• CONCATENATION OF DIFFERENT SUBNETWORK TECHNOLOGIES

8

• SIMPLE, EFFICIENT PROTOCOL
SERVICES

• PROVIDED TO TRANSPORT LAYER

- UNIT DATA SEND

- UNIT DATA RECEIVE

• PROVIDED BY THE NETWORK LAYER

- UNIT DATA SEND

- UNIT DATA RECEIVE

• PROVIDED BY THE LOCAL ENVIRONMENT

- TIMER REQUEST

- TIMER REPONSE

- TIMER CANCEL
REQUIRED PROTOCOL FUNCTIONS

• PDU COMPOSITION

• PDU DECOMPOSITION

• HEADER ANALYSIS

• LIFE TIME BOUNDING

• ROUTING

• FORWARDING

• SEGMENTING

• REASSEMBLING

• DISCARDING

• ERROR REPORTING

• ERROR DETECTION

I PADDING

J-i'3
OPTIONAL PROTOCOL FUNCTION

• SECURITY

• SOURCE ROUTING

• ROUTE RECORDING

• QUALITY OF SERVICE
PDU STRUCTURE

• FIXED FIELDS

• ADDRESSES

• SEGMENTATION

OPTIONS

• USER DATA

PDU TYPES

• DATA

ERROR REPORTS
FORMAL DESCRIPTION

• EXTENDED FINITE STATE MACHINE LANGUAGE

• STATE TRANSITIONS PLUS PASCAL

• MODELS A SINGLE SERVICE REQUEST

CONFORMANCE

• FULL PROTOCOL

CHECKSUMS

• OVER THE HEADER ONLY

• GENERATING CHECKSUMS

• CHECKING CHECKSUMS

• ALTERING CHECKSUMS
MINUTES OF THE SIXTH WORKSHOP FOR IMPLEMENTORS OF OSI

U.S. Department of Commerce

National Bureau of Standards

Institute for Computer Sciences and Technology

Systems and Network Architecture Division

Gaithersburg, MD 20899

August 8-9, 1984

* Minutes of the first workshops were entitled "Proceedings of the

LAN/Transport Workshop Series."
CONTENTS

Ab s t r a.c t

S umma r y

1 . We I come

2. Approval of agenda

3. Recapitulation of 1?84 NCC demonstration

4. The target markets

5. Group objectives

6. S t r a t eg i e s / t ac t i cs to achieve objectives

7. Schedule of workshops

At tachment s

1. Attendance list

2. Approved Agenda

3. Vang proposal for future activities

4. GM Presentation

5. Priority list for future activities

6. Documentation Contacts

7. Proposed Workshop Objectives

8. Proposed Workshop Goals

9. Proposed Agenda for nest meeting

10. Goals for nest meeting

11. Special Interest Registration Form

12. Press Coverage Summary
ABSTRTACT

The National Bureau of Standards, Institute for

Computer Sciences and Technology (ICST) has sponsored a series of five LAN-Transport workshops for local area

network implementors of International Organisation for

Standardisation's (ISO) Class 4 Transport Protocol,

ISO's File Transfer and Access Manipulation, and the

Institute of Electrical and Electronics Engineers

(IEEE) 802 compatible local area networks. The

workshops focused on implementation techniques and

strategies so that a multi-vendor demonstration of

these protocols could occur at the 1984 National

Computer Conference. As a follow-up to the LANTransport Workshops, ICST sponsored the Sixth OSI

Implementor's Workshop to discuss the continued

development of OSI computer network protocols.

Keywords: communication protocols; computer networks; local

area networks; open systems interconnection;

SUMMARY

This report documents the Sixth OSI Implementors

Workshop, one of a series of workshops for implementors

of international standard protocols. The workshop

reviewed the recent multi-vendor demonstration at the

1984 NCC, and began work on objectives for a second

activity based upon additional international standard

protocols. Work also began on a plan for a second

workshop series to further develop Open Systems

I n t e r connec t i on

.
1

.

WELCOME

John Heafner, NBS , welcomed the attendees to the workshop

and introduced Marls Graube, Chairman of IEEE 802, as the

workshop moderator. Maris gave a brief summary of the

history of the past LAM-Transpo r t Workshops.

An attendance list is included in Attachment 1.

2

.

APPROVAL OF AGENDA

The agenda was reviewed and the following additions were

incorporated

o European activities was added to item 5.

o Performance aspects of protocols was added to item 6.

The final agenda is included in Attachment 2.

3.

RECAPITULATION OF 1934 NCC DEMO

Ron Yara, Intel, presented the following objectives

developed for the 802.3 booth.

o Establish the ISO protocol suite as a "must" suite.

o Establish awareness of commitment to transport in

particular and the OSI in general.

o Demonstrate that de jure standards work.

0 Educate editors, OEMs and end users.

o Demonstrate that multiple vendors can work together.

Laurie Bride, BCS, stated that BCS is seeking a migratory

path to the use of standards in their networks Their goal

is to use fully integrated networks. They were interested in
feedback from the NCC demonstration. They were satisfied

with the outcome of the demonstration and are fully

committed to continuing the work begun in previous

wo r k sho p s . Ron Floyd presented GM ' s objectives for the demonstration:

o Support of Standards; IEEE 802.4 Token Bus and

MBS/ISO Class IV Transport,

o To make other computer equipment suppliers and other

industrial users aware of MAP,

o Qualify a group of equipment suppliers for

consideratin for GM MAP pilots, and

o Provide a focal po int / dead 1 ine for this work.

GM was pleased with the results of the demonstration.

John Heafner presented the NBS objectives for the NCC

Demonstration as follows:

o Those objectives for the SQ2.3 booth listed

software, tests; and

o Bring users and suppliers together to determine the

impo r t ance I p r i o r i t y of QSI protocols.

NBS is pleased with the results of the demonstration and is

looking forward to future activities.

ICL has been trying to develop support in Europe for the

activities of the workshop. They feel that the deadline of

the demonstration helped to provide a focus for their

efforts. The demonstration received some publicity in

Europe and is expected to generate participation by European

compani es

.

Charles River Data Systems sought to extend their use of

standards. They were pleased with the progress made, but

were aware that there is still much work to do.

previously by Ron Yara;

o Transfer test methodology: architecture, support
DEC was interested in establishing OSI as de facto standards

not just de jure standards, and in demonstrating DEC'S

commitment to OSI. DEC also believes that selecting the

proper options for the various protocols is important. DEC

feels that the momentum generated by the demonstration

should be maintained.

IBM sought to advance their understanding of standard

protocols. IBM wanted to promote the use of standards and

were pleased with the progress made through the

demons t r a t i on

.

NCR wanted to increase their understanding of standards.

NCR felt that the demonstration was successful in helping to

achieve this goal, however it was only the beginning. NCR

looks forward to future workshops to reinforce the work

being done in the standards bodies.

Concord Data Systems sought publicity of standards. They

felt that this goal was achieved and that the effort had

benefitted their company.

A1 1 en-Br ad 1 ey wanted to show support for MAP and establish

their reputation as a communications vendor. They felt the

their goals were achieved in the demonstration.

Honeywell wanted to demonstrate their commitment to

standards and to develop momentum for the standards process.

They felt that their goals were accomplished and want to

maintain the momentum for future work.

Motorola wanted to develop in-house expertise in standard

protocols. They were pleased with the progress made toward

thisgoal.

Intel wanted to show their support for standards in their

products. They felt that this was achieved through the

d emons t r a t i on

.

Resources Invested

Bob Blanc, NBS , stated that between $160,000 and $170,000

were spent for the booth and the brochure for the 802.3

demons t r a t i on

.

ICL estimated that they invested 157,000 British Pounds to

participate in the demonstration. This did not include much

of the work already done on the development of an ISO

Transport implementation or participation in standards

meetings. A considerable portion of their expenses was in
travel

.

Intel invested 50 man-months in the development of products

and 9 man-months specific to the demonstration.

Charles River Data Systems invested 24 man-months in the

demons t r a t i on

.

GM stated that its costs for the demonstration were very

difficult to identify because the costs were integrated into

corporate plans.

Leads Genera ted

GM reported that it had received 500 requests for MAP

specifications and 2000 requests for literature.

NBS reported that they received about 600 requests for

information. Many of the requests included requests for

protocol specifications.

Eon Yara, Intel, said that the mailing labels were being

made and would be distributed to the vendors as soon as possible

.

Press Coverage

The signing ceremony for the cooperative agreement generated

more press coverage than anticipated.

ICL requested a summary of press activity concerning

workshop and demonstration activities. MBS said that it

would provide this summary. Copies of the press kit and the

press activity summary were distributed. The press summary

is included in Attachment 12.

Residual Benef i ts

A residual benefit of the demonstration enpressed was that

the demonstration "got the ball rolling" for standards

implementation. It was also noted that the demonstration

caught the attention of PSX and other vendors, as displayed

by their attendance at this meeting,

C r i t i c i sms

The criticisms of the two booths centered around the need
for continuing work and were as follows;

o The most recurrent criticism was that the protocols

demonstrated were not products.

o The booths were not interconnected.

o The FTP demonstrated was not rich enough in

capab i 1 i t ies

.

o The model demonstrated in the 302.3 booth was not

clear

.

o The transport implemented was a subset of the full

protocol

.

Gary Vorkman, CM, made a presentation, on GM's position on

future participation in the workshops. (See attachment 5).

P e r f o rma nc a Data

MBS collected data from all four days of the demonstration

in the 802.3 booth. Rob Rosenthal, MBS, said that MBS had

not analyzed the data from the demonstration. He offered

copies of the data to those who were interested in

performing their own analyses.

4. THE TARGET MARKETS

Sheldon Blauman, BCS , enpressed interest

the CSMA/CD booth and the token bus

booth would model the e ng i ne e r i ng / o f f i c

e

in interconnecting

booth. The CSMA/CD

environment with a c 0 nne c t i o n t 0 the token bus booth mo del 1 i ng the factory

env i r onme n t

.

BCS has many LANs with a wide geographic

separation 0 f f ac i 1 i t i e s . The ISO internet protocol is

vital to their use of ne two r fc s

.

5 . GROUP OBJECTIVES

BCS suggested that development of the ISO internet and

enhanced FTP should be the focus of future workshop

activities. DEC expressed a desire that the primary

emphasis of the workshop be protocol product development,

with a secondary emphasis on demonstrations.

Joe St Amand Wang, presented proposal for future
workshop activity (see Attachment 3) as a strawman for

discussion. Several changes and additions were made, as

shown in the attachment.

A straw ballot was taken for interest in participation in a demonstration sometime in 198S. Twenty-one vendors

expressed intrest in a show. Sixteen would participate if

no changes were made to the old show with six of these

sixteen being new vendors.

Ken Dymond, MBS, and John Heafnee described the plans for

Internet Protocol (IP) implementation and testing at MBS.

The current estimate for having IP testing available is

August 1985. MBS was interested in being an ISO

intermediate system coupling IEEE 802.3 and IEEE 802.4 with

measurement capabilities at the next demonstration.

MBS noted that there have recently been changes to the ISO

Transport Standard. MBS will distribute the update

information for Transport.

James Isaak, Charles River Data Systems, noted that the IEEE

is forming a committee to standardise UNIX. Maris Craube,

Tektronix, suggested incorporating ISO protocols into this

standardisation effort. (See Attachment 9, September 7 of

agenda .

)

Using the Wang proposal as a basis and after considerable

discussion, a priority list for future workshop activity was

produced (Attachment 5). The list incorporated updates and

enhancements to the protocols already developed and various

special interest subnets and applications.

John Heafner offered to provide contacts for protocol

specifications. A list of addresses for contacts for the

various standards documentations was distributed (see

At tachment & ) .

6. STRATEGIES /TACTICS TO ACHIEVE OBJECTIVES

A proposed set of workshop objectives and goals are included

in Attachments 7 and 8. Decision on a final set of

objectives was deferred to the next meeting.

7. SCHEDULE OF WORKSHOPS

A desire for tutorial sessions to help bring

participants up to date was expressed

attendees interested in participating in such

new workshop

Th e numb • r of

sessions did
not seem to justify the effort required. As an alternative,

John Heafner said he will distribute a recent paper on

eaperiences gained from transport and FTP testing for the

1984 NCC demonstrations.

A proposed agenda for the next workshop was developed (see

Attachment 9). The nent meeting was scheduled for September

5-7, 1984 in Gaithersburg, Maryland.

The goals for the neat meeting are included in Attachment

to. The tutorial will be defered to a later meeting,

however the paper John Heafner will distribute will cover

many of the issues.

Those interested in attending the the Special Intrest Croup

Meetings should fill out and return the Special Interest

Registration Form, Attachment 11, to allow planning of

required meeting space.

I
ATTACHMENT 1.

OSI/NBS V/orkshop

REVISED

August 8, 1984

AC&C

Mike Seto

ALLEN BRADLEY

Bob Jones

AT&T

Lawrence Brown

Fred Burg

Doug Knisely

Steve Milton

Charles Young

BELL COMMUNICATIONS RESEARCH

George Chang

A. T. Gain

BOEING

Sheldon Blauman

Laurie Bride

BURROUGHS

Jon Becker

CHARLES RIVER DATA SYSTEMS

James Isaak

Richard Swee

CODEX

Paula Bel air

Charles Wade

COMSAT

Mark Nelbert

CONCORD DATA SYSTEMS

Mike Champa

DATA GENERAL

Lyman Chapin

DIGITAL EQUIPMENT

Tony Lauck

Gall Poulter

FORD MOTOR CO.

Jay Jeyabalan

FLORIDA STATE LEGISLATURE

Ed Levine

Glenn Mayne

GENERAL MOTORS

Ron Floyd

Mike Kaminski

Gary Workman

GOULD

Allen Brown

GOULD CSD

John Capurro

HONEYWELL

Bruce Carlson

Lea Quackenboss

S. Wales

ICL

Roy Cadwallder

IBM

A. W, Kleitsch

Jim Miller

Bob Yingling

LIBRARY OF CONGRESS

Ray Denenberg
MACC3M WANG _ David Rods Joseph Holmes

Joseph St. Amand

MOTOROLA Gerard White

Jim Clarkson XEROX

NCR Juan Bulnes

Gerald Brinda

Wood Wiles

NBS

Paul Amer

Bob Blanc

Ken Dymond

John Heafner

Dan Rorrer

Rob Rosenthal

Robert Toense

Mike Wallace

Evette Meni

NORTHERN TELECOM

Paul W. Masters

Edward Matthews

OLIVETTI

Francesco Cordera

SPERRY

W. P. Engstrom

Daniel Farrara

J. G. Nemanich

SYSTEMS DEVELOPMENT CORP.

Barbara Sternick

TEKTRONICS

Marls Graube
ATTACHMENT 2

August 8 & 9, 1984

AGENDA

Implementors of ISO/NBS Open Systems Interconnection

Wednesday a.m,

1. Welcome (by John Heafner) and introduction of Moderator, Mr. Maris Graube

2. Approval of agenda

3. Recapitulation of 1984 NCC demo

0 Stated objectives (OSI, transport)

0 Resources invested

0 Leads generated (T ^

^

/

0 Press coverage

0 Residual benefits

0 Were objectives achieved ?

0 Criticisms (Lack of products, limited FTP)

Wednesday p.m.

4. The target markets

\ 0 What is the office systems model ?

0 What is the factory model ?

Wednesday p.m. & Thursday a.m.

5. Group Objectives

0 OSI and ISO/NBS protocols

0 Development of products, visibility of standards efforts, information/

educational activities

0 Assuring multi -vendor compatibility

0 Follow-on activity
<\

Thursday p.m.

6, Strategies /tactics to achieve objectives

0 Workshop structure

0 Laboratory resources

0 Other resources

7, Schedule for workshops

c c
ATTACHMENT 3

Ci5*)

4.3:)

(E)

^oVi.ow*no n

(Wa.n.cv

•+0 VA - LAW WAV ^“Wl^v

4y

(crv.O)io^ A^Van'^'c. ^acA^ %c)

•comm* 3^ V

0. *Vc c e»\

5

— \so s^o’xJ^Caa/ C\OA)c/s ) — \SoStOZ.Z Cllc X

o

, *V VSo Conn.ec'\\ontcs5yx. 3, P — \%o/i^3S

V5o f^s2- UA'tefe "7

• Ql \C aTAOYl *^VO‘VoCo\ 5

2 , —\SO 'oPOatC Amo -syirvat

P*^Se»>*T PPtfTeCoU - CC \ TT X . Hero

pA 'Sosser

S3*^ i»«4Po. ftsne.Xev'^u

• \

^ TTlOvs-+V\S lead

* r\2^oocms‘ ^K>o-r j^sr- ppoTi.'php^

SO!
ATTACHMENT 4

AeS* WORKSHOPFO^ OSI

IMPLEFENTORS

AUGUST8THAMD 9TH 1984

CMPFESEMrAnm
GM INTENDS TO PARTICPATE IN

n-E NBS INTTERNET WORKSJ-DPS

AND n-E MULTI-VENDOR

DEMONSTRATION BECAUSE OF: 1.

(arS INTE31ESTIN THE

INTERNETWORKING OF LANS

AND WANS.

2.

GMS INTEREST IN THE

DEMONSTRATION OF CONTINUED

MAP EVOLUTION AND

DEVELOPMENTS.

3.

(MS INTEREST IN EXPEDITING

IDENTICAL VENDOR

IMPLEMENTATIONS OF OSI

NETWORKING SOFTWARE
GM BEUEVES Tl-E I^^^EF^^ET

WOFJKSHCPS SHOULD BEGIN AS

SOON AS POSSIBLE.

GM BELIEVES THE 1985 NCC

WOULD BE THE IDEAL FORUM FOR

AN INTERNETWORK PROTOCOL

DEMONSTRATION. (CLNS

PROTOCOL)

GM PROPOSES TQ

1 . OBTAIN BOOTO SPACE AT THE 1365 HOC.

(already applied POR)

2. PERPOSN REFERENCE TESTING TOR THE MAP

(TOKEN-BUS LAN) PAKHCIPANrS IN THE

DiH(»?ST&ATICN.

3. INVOLVE PBE VIHDORS TO IMPLEMENT INTERNET

ROUTER CAPABILITIES.

(DISCUSSIONS ALREADY HELD WITH FOUR PBE

HANUFACTTURERS WHO HAVE EXPRESSED

INTEREST IN COOPERATING WITH GM IN THIS

DEVELOPMENT EFFORT.)

4. COORDINATE NCC BOOTO ACTIVmES.

JcY
pfixum

QATEWAY^gmB

caj.cEvica

GATEWAY/ROUTER CONNECTION PBX-MAP TAN
/

CELL DEVICES

B/>g<aCNE

GATEWAY/ROUTER CONNECTION PBX-MAP LAN

3o(p
GM'S PROPOSAL FOR 1985 NCC

DEMONSTRATION

FOR ALL PARTICIPANTS

1.

CLNS PROTOCOL

2. ENHANCED PILE TRANSFER CaPAHUTTES

CWXTEE/CREATE, TRANSFER OF BIT STREAM

PILES, CCFTT MHSX409 PDO ENCODING)

3. "COMPLETE" TRANSPORT IMPIBlENTaTICH

FOR MAP PARTICIPANTS

1. SIMPLE DIRECTORY INQUIRY CAPABILITY

2. TRIVIAL NETWORK MANAOEMElfr CAPABHJTY

3. UPGRADE OF TIM CTOKEN INTERFACE MODULE)

HDLC INTERFACE

4. MODOICATK^fS TO IHE MAP MESSAGING

PROTOCOL

Non MAP participsnts may want to implement the MAP

messaging capability.
FUTURE CONCERNS

- PERFORMANCE ISSUES

- INTERFtTWORK MANAGENENT

- INTERNETWORK DIRECTORY

SERVICES

- FILE TRANSFER UPGRADES

- VIRTUAL TERMINAL

CAPABILITIES

- SESSION AFO PRESENTATION

PROTOCOLS
ATTACHMENT 5

A- ^

2- Tr<^ Af^>^

f• /«iy#r

Hrr <

» S^4 r«/

^ftVe

%tt%J

t

«

#

«

2.

3

Zf S' ^

)(*tr £a<^v

» Sfulf ^£f SuSict

9 KAp

>9
ATTACHMENT 6

ANSI

ATTN: Ms. Fran Schrotter

ISO TC97/SC6: SECRETARIAT

1430 Broadway

New York. NY 10018

(212) 354-3343

ISO Internet Documents Status

Network Service Definition DIS 8348

Addendum to NSD Covering

Connectionless Data Transimission

DIS 8348

DADl

Addendum to NSD Covering

Network Layer Addressing

DP8348

DAD2

Internal Organization of

Network Layer

WD

Protocol for Providing the

Connectionless Network Service DIS 8473

*DAD = Draft Addendum

IS0/TC97/SC6

N2990

N3152

N3134

N3141

N3154

3/0
X, X'

X, H<) X

X, f Xf

J

C-^oi) J"7^- / 7

/ /Ca^ ^

3ry^-

// ^?.j y
l/AU I iiry ?0W ep liC

I

s'mNiA*s>p ?/'.• I

A- T^C}^>Cf(-U

I

^A4\4 Ptop. ")^ , iMW-p’MffNT: *

>) TU^ TXAtni'PS'i^

3^ ^fSCijU, ))orffAFSrS

Fst^bus A»Hfr ?asc<?ss pafev*

COAiPUMlt^TlNe- Ve U.s?fts

"

VP "nStH^orOJi-Pw^kazP

nD. J>5!\)'gi.«>? 7*Ao^U<.-rs

"

( YSrAfW JA0«<SMTU«4 Pp

*

•m Acc'bwwo 4>]ioce^ss

A/AjAAcS-F^
ATTACHMENT 8

2 /'A

wI

I

I

I

cr

I

I

I

^t>uc4T0‘ ^5yjiS •» O^AJjio^s

I

I

I

tPocrss

Dgfrto^asr^PAT^>^ A®

/50 T"0

AfU m• \) C<ii»HT^>l'^

TPST I fa 0-

Pri>iSSS OF £X-,€n.

5* ^/»^P6-/AJ6- ST/4/aMA*S 1?

Fo>uh

v./i
ATTACHMENT 9

3^i

• Ll*»r '<• "3^ user

. STT\^^Arr99

^

TyuSj

2^ OA'f

^<A»M,3wr f%EV\SNaJ

CA,W3i\iVTV ©S^ViCti;

i iMvrCelo

fcr

^VI^UVUA ! SCMSSkJLSS ,
(»
ATTACHMENT 10

Whast

* "^vix^w ?o\K»TS

K)X3

^ ©w rrsH^o^^

^T^cJiM. '?ap\€.r

• "n^ST PLA JO

J/<;
t-.

SPECIAL INTEREST GROUP REGISTRATION

Name :

Or gani za t t on

Please check the Special Interest Croup meetings you plan to

attend.

t Sp,e^„U_i Interest Groups ___ IEEE 8Q2 .

2

__ IEEE 8Q2 . 3 __ IEEE 802.4 __ 3C . 25 for WAN

Laver 2. Special Interest Groups __ A. 400 Series Message Subset ___ GM MAP

UNIX

Please return as soon as possible to:

QSI WORKSHOP SERIES

Attn: Mary Lou Fahey

or Joan Wyrwa

National Bureau of Standards

Bldg. 225, Rm B2 2 d Gaithersburg, MD 20899
Press coverage of NBS/industry program on networking standards

28 reporters attended the April 24 press briefing, including Business Week ,

Computerworld , New Scientist , UPI, WRC-TV, Business Times, and National

Public Radio.

Over 50 reporters have made follow-up Inquiries.

Following is a list of some of the general media that have carried stories:

Wall Street Journal (circulation 780,000)

Wall Street Journal (Wash., D.C. edition, 162,000)

Wall Street Journal (Chicago edition, 523,000)

Wall Street Journal (Cleveland edition, 523,000)

Wall Street Journal (European edition, circulation not available)

Business Week (900,000)

Discover (monthly, 506,300)

New York Times (873,255)

Financial Times (daily, London, England)

UPI business and finance wire (the UPI wire story was carried in newspapers

across the country such-.ias , Sacramento, Ca. Union , 111 ,650, aodiRal.ei gh , N.C.

News and Observer. , 130,000)

San Francisco Examiner (150,000)’

Dallas Times Herald (269,410)

Toronto, Qnt. Globe & Mail (330,000)

Business Times Entertai nment and Sports Progratnning Network (ESPN is the larges

cable network in the country reaching 30 million homes daily. Daily, over 300,000 business executives watch Business Times.)

National Public Radio

Washington Post (750,000)

Dow Jones Wire

WRC-TV, NBC in Washington, D.C.

KGW-TV, NBC in Portland, Ore.

Following is a list of some of the trade and technical press that have carried

stories:

Computerworld (102,100) SUMMARY OF ARTICLES PUBLISHED:

Elecironics (in two separate issues, 94,600)

New Scientist (London, England)

MIS Week [T70 , 000

)

Mini Micro Systems (95,400)

Electronic News (70,000)

Computer Decisions (129,400)

Computer Design (67 , 000

)

Modern Materials Handling (109,450)

Electronic Design (101 ,276

)

Information Systems News (100,500)

Purchasing (95.000)

Systems & Software (50,000)

Digital Design (56,000)

Trade & Technical - 46

Business - 15

General - 2^

Total Articles 87
Or'l i-ILiz TRANSFC.R FRGRGSAL

GEPTEhBER b, 1^34

UPGRADE NCC''S4 FTP TO ISO FIL

SERVICE SUBSET FOR INTERNET DEM

- REQ'D CHANGES FCR ISC CCMPATIB ILITV

“ SUPPQR'' FOi< r__i<EAD AT-ID !”__vvRITE “ BINARY AiND TEXT FILES

CCriPLETE ISC FTAM IMPLEMEMTaTQN FOR LONG

RANGE TIME FRAME

“ FILE AijCESb SERViLi duBbET

'bat

(LIMITED ENiH.ANCEB' 1

L,i'<KUR. r;s.CQ'v ::.R Y 3-ai^V'I SUBSET

111 a
ISO FT? SUBSET FG? INTERNET DENG

1.0 ShRvICE PRInlilvES

1. F__CONiN£CT/ F_hEL£A£Ej *“ aSGRT

2. F_3ELECT, F_DESELECT

3. F_OP£N, F_CLOSE

4. F_REAO AND FJNFITE v5. F_DATA, F_DATA_END, F_TR ANSFER_E^4I

6. F_CANCEL

7. F BEGIN GROUP F END GPC-UP

INDICAfES ADDIt:,:':
LiJ

LU

i:ij.

rn

CHANGES REGUi'-iED FOR I5G CGMFaTIB ILITV

1. X. 409 tNCODIiNG (ASNl) FOR i-sF PDUs

~ ^4CC''S4 FORMAT WAS iriTE.RIM CHGiCb fu 3l

CGMPATISLE WITH LOWER LAYERS

2. ADDITION OF CONCATENATION CONTROL

“ BEGIN, Er-4D GROUP PRIMITIVES AND

SUPPORTING PCI

” Rb,AD LJR v-iH .L i E aCTIvI i V INI ! i A ! Li.' Ao A

SEQUENCE;

G I N_^G R uUP F__S ELECT F jF EN F_R £A 0 F_j~ ND GR

GIN GROUP F SELECT F OPEN F WRITE F END Q

- FILE RELEASED AS A SEQUENCE;

r bciUlN GROUP, F C'Lu'SS.* F DESELECT, F Sh'D GROUP

r, TpnSO pFTP SUBSET RESTRICTIONS

'ILE SSLEC T lOC'i R=.GIMiz, MAY iiAVt. I -U'CV I uNb OPEN AND Gi''b. READ OR i.-jRITb AC ! I VI , Y

2. UNLY GUP1;’^Lc. I 1~ j, i_bS MA Y bb l i’!A'MGi'tz.:'<h''Z.D

rj

a.
ISC FTAM IMPLCr'ENTATICN DE/’G

4.0 ADDITIONAL SERVICE 'PRIMITIVES

i. F_LQCATE, F_ERASE

cL. rt A I E » z. L_ c. I i !' h! z 1-^ ij I i R I ij UT

3. F_CHA.NGE_ATTR 1 3UTE

5. C ERROR RECGVERV SERVICE PRIMITI’-ES

1. ~_PLC‘jVtr<

2. -_CHECF.

3 . !*_R£STArT

4. F_CAr-iCEL

5. C INPLEMENTATICL OF v!R“UAz FI;_E3TGPE

- cefinitign of *tle structure

- auLGwS •‘RECORD i_EVEL" FILE ACCESS

jji^
INTERNAL ORGANIZATION OF 'mE NETWORK LAYER

DEFINES ARCHITECTURAL ORGANIZATION OF THE NETWORK LAYER

PROVIDES MAPPING OF ABSTRACT ORGANIZATION TO "REAL WORLD”

CCMPOI^ENTS

IDENTIFIES AND CATEGORIZES THE FUNCTIONS PERFORMED BY

JJETWORK LAYER PROTOCOLS

PROVIDES A UNIFORM FRAMEWORK FOR DESCRIPTION OF THE

OPERATION OF TTTE NETWORK LAYER

EXTENDS TERMINOLOGY

DEALS WITH CCMPLEX "REAL WORLD”
ROLES OF NETWRK LAYER PROTOCOLS

SUBNETW)BK INDEPENDENT CONVERGENCE PROTOCOLS (SNICP)

« OFFERS OS I NETWRK SERVICE ON SUBNETWORK

INDEPENDENT BASIS

- MAY BE INTERNETWORK PROTOCOL, SET OF RULES FOR

COORDINATING SU’BNETWORK SERVICES, OR NULL

SUBN*ETWORK DEPENDENT CONVERGENCE PROTOCOLS ( SNDCP

)

- PROVIDES SERVICE REQUIRED BY SNICP, OR

PROVIDES OS I NETWORK SERVICE

- OPERATES OVER SNAcP

- MAY BE:

- EXPLICIT PROTOCOL

- SET OF RULES (E.G., FOR RUNNIIMG CLIP OVTR X.25)

- NULL
ROLES OF NET?iOBK LAYER PROTOCOLS (CONT’D)

SUBNETWORK ACCESS PROTOCOLS (SNAcP)

- WHATEVER IS USED TO ACCESS A SPECIFIC SUBNETWORK

- MAY BE:

~ EXISTING SUBNETWORK PROTOCOL (ARPANET 1822, ...)

- STANDARD PROTOCOL (X.25,

- NULL ( IEEE 802, » , .

)

- PRESET ONLY DURING CONNECTION ESTABL I SIMENT AND

TERMINATION (X.21)

- OR . .

e

GENERALLY

- AT LEAST ONE NETWORK LAYER PROTOCOL MUST BE PRESENT

" RECURSIVE USE OF PROTOCOL ROLES IS POSSIBLE
APPROACHES TO NETTORK LAYER INTERCONNECTION

HOP BY HOP ENHANCEMENT

- SNDCP INDIVIDUALLY ENHANCES EACH SUBNETVDRK IN A

CHAIN TO OFFER OS I NETWRK SERVICE

- SNICP CONSISTS OF RELAY AND ROUTING RULES FOR

COJCATENATING SUBNETVORK SERVICES

- COULD IN PRINCIPLE BE CONNECTIONLESS OR CQNNECTI ON -Nt©E

- IMPLICIT CONNECT I ON-M)DE (X.25) ORIENTATION

INTERN’ETWRK PROTOCOL

- OPERATES AS END-TO-END PROTOCOL

- SUBNETWORKS MAY BE DIVERSE

- SNDCP MAY BE REQUIRED IN SCME CASES (E.G..

RULES TO MANAGE X.25 CONNECTIONS)

- COULD IN PRINCIPLE BE CONNECTIONLESS OR CONNECT I ON -xMODE

- CURRENTLY IMPLICITLY INTENDED FOR CONN-ECTIONLESS

PROTOCOL (DIS 8473)

lOOTNL DOCIMENT GIVES EQUAL TREATMENT OF BOTH APPROACHES
EXAMPLE ARCHITECTURE FOR IKTEKNETWRK PROTOCOL

SNICP <==> CONNECTIONLESS INTERNETWRK PROTOCOL (ISO DIS 8473)

( NULL (OVER LANS)

SNDCP <==> < RULES FOR CCH>(NECr I ON MANAGEMENT, ETC (OVER PDNS

)

( ETCo.e

(

NULL (OVER LANS)

SNAeP <=-> < Xo2S PACKET LEVEL (0\TER PDNS)

( ETC. e

.
3n
Use

of

Internetwork

Protocol

for

Interconnecting

Local

Area

Network

with

Public

Data

Network

*

c o M NJ

(C Ut «

cN as o n

H ^(0 ?3 rr C <

3 m W H* W*3O<

CNSUS
Use

of

Internetwork

Protocol

for

Interconnecting

Two

Local

Area

Networks

Via a

Public

Data

Network

UJ

* *

c • (-• M

U1

CDhn ta o o

(0 ja rr c

3 r* 3 m

p. < 3 n> cw H* a

o<

(0X•N>

KJ1

U>

^3a
TRANSPORT PROTOCOL

Added Features

There were two features of the transport protocol which would enhance the

demo version;

Expedited Data - The expedited data service and the associated

protocol mechanisms were not included In the demo, for the next

demo it would be appropriate to Include expedited data especially

considering the multi network approach,

2. Negotiation During Connection Establishment » for the first

demo, parameter values were selected to avoid negotiation. In

the next demo it would be approppriate to include full parameter

negotiation utilizing the connect negotiation rules.

Ssf
Internetwork Protocol

Services Provided

The internetwork protocol (IP) provides a connectionless service. That

is to say, it does not depend on the estaol i shment of connections or

virtual circuits between peer entities. The service provided is on a per request basis. There is no explicit or implicit relationship between

service requests. Additionally, there is no confirmation of success or failure to the service requestor.

The service provided by the IP consists of one service interaction:

Associated with the service primitives are Quality of Service Parameters

(QOS). Each parameter describes a characteri sti c that is provided by the

service.

1. Transit delay - the time between a request and indication,

2. Protection from Unauthorized Access - tne extent to which

protection is provided,

3. Cost,

4. Residual Error Probability - the likelihood that an NSDU will be

lost, duplicated, or incorrectly delivered,

5. Priority, and

6. Source Routing - a specification of the path an NSDU is to take.
OSI Session Service

« CONCEPTS

i GENERAL RULES

• CONNECTION ESTABLISHMENT

« DATA TRANSFER

§ CONNECTION RELEASE

t COLLISION RESOLUTION
CONCEPTS

t TOKENS

• SYNCHRONIZATION & DIALOGUE UNITS

• ACTIVITIES

• RESYNCHRONIZATION

• FUNCTIONAL UNITS & SUBSETS

• NEGOTIATION

• DATA CATEGORIES

SS'f
TOKENS

• PERMIT ALTERNATING CONTROL OF SERVICES

0 FOUR SESSION TOKENTS

- DATA

- RELEASE

- SYNCH-MINOR

- MAJOR-ACTIVITY

0 TOKEN STATES

- AVAILABLE

- NOT AVAILABLE

0 AVAILABLE SUB-STATES

- ASSIGNED

- NOT ASSIGNED
SYNCHRONIZATION & DIALOGUE UNITS

f SYNCHRONIZATION POINT TYPES

- MINOR

- MAJOR

• MAJOR SYNCH POINTS DELIMIT DIALOGUE UNITS

• MINOR SYNCH POINTS DELIMIT SUB-UNITS

• CONFIRMATION

- EXPLICIT FOR MAJOR SYNCH

- MAY BE EXPLICIT FOR MINOR SYNCH

• NO SEMANTICS ASSOCIATED WITH SYNCH POINTS

J34'
ACTIVITIES

« DISTINGUISH DIFFERENT PIECES OF LOGICAL WORK

t CONSIST OF ONE OR MORE DIALOGUE UNITS

• ONE ACTIVITY ON A CONNECTION AT ONE TIME

t SEVERAL ACTIVITIES MAY USE A CONNECTION SEQUENTIALLY

• AN ACTIVITY MAY SPAN MORE THAN ONE SESSION CONNECTION

t ACTIVITIES MAY BE INTERRUPTED AND RESUMED

§ USERS MAY SEND DATA OUTSIDE AN ACTIVITY

t ACTIVITY END = MAJOR SYNCH POINT

331
RESYNCHRONIZATION

• SETS SESSION CONNECTION TO A DEFINED STATE

- TOKENS

- SYNCH POINT SERIAL NUMBER

• PURGES ALL UNDELIVERED DATA

%

• THREE OPTIONS

- ABANDON

- RESTART

- SET

t SEMANTICS ARE USER DEFINED
FUNCTIONAL UNITS & SUBSETS

• FUNCTIONAL UNITS ARE LOGICAL GROUPINGS OF RELATED SERVICES

• FUNCTIONAL UNITS ARE INDIVIDUALLY NEGOTIABLE AT CONNECTION

ESTABLISHMENT

t CERTAIN FUNCTIONAL UNITS IMPLY TOKEN AVAILABILITY

§ TOKEN MANAGEMENT SERVICES ARE REQUIRED WITH TOKEN AVAILABILITY

« SUBSETS ARE COMBINATIONS OF THE KERNEL FUNCTIONAL UNIT TOGETHER

WITH ANY OTHER SET OF FUNCTIONAL UNITS

• SUBSETS HAVE NO MEANING IN THE SESSION PROTOCOL
FUNCTIONAL UNITS

• KERNEL

f DUPLEX

• HALF-DUPLEX

• NEGOTIATED RELEASE

• EXPEDITED DATA

• TYPED DATA

• CAPABILITY DATA

• MINOR SYNCH

• MAJOR SYNCH

• RESYNCH

• EXCEPTIONS

• ACTIVITY MANAGEMENT

^ / /O
PREDEFINED SUBSETS

t BASIC COMBINED SUBSET

» KERNEL

» DUPLEX OR HALF-DUPLEX

t BASIC SYNCHRONIZED SUBSET

- KERNEL

- NEGOTIATED RELEASE

- HALF-DUPLEX

- TYPED DATA

- MINOR S MAJOR SYNCH

« RESYNCH

• BASIC ACTIVITY SUBSET

- KERNEL

- HALF-DUPLEX

- TYPED DATA & CAPABILITY DATA

- MINOR SYNCH

- EXCEPTIONS

- ACTIVITY MANAGEMENT
NEGOTIATION

§ OCCURS DURING CONNECTION ESTABLISHMENT »

• FUNCTIONAL UNITS ON CONNECTION

• INITIAL TOKEN SETTINGS

t INITIAL SYNCH POINT SERIAL NUMBER
DATA CATEGORIES

t NORMAL

« EXPEDITED

§ TYPED

t CAPABILITY
GENERAL RULES

t TOKEN RESTRICTIONS

t NEGOTIATION RULES

• PRIMITIVE SEQUENCE

• SYNCH POINT SERIAL NUMBER MANAGEMENT
TOKEN RESTRICTIONS

• INITIATE RELEASE

» ALL AVAILABLE TOKENS ASSIGNED

t SEND DATA

» DATA TOKEN ASSIGNED (HALF«»DUPLEX)

» DATA TOKEN UNAVAILABLE (DUPLEX)

f GIVE TOKEN REQUEST

» TOKEN ASSIGNED

i PLEASE TOKEN REQUEST

» TOKEN UNASSIGNED

• ACTIVITY START, RESUME, END

« DATA & SYNCH MINOR TOKEN UNAVAILABLE

OR ASSIGNED

» MAJOR -ACTIVITY TOKEN ASSIGNED
TOKEN RESTRICTIONS (CONTINUED)

t ACTIVITY INTERRRUPT, DISCARD

- MAJOR-ACTIVITY TOKEN ASSIGNED

t MINOR SYNCH REQUEST

- DATA TOKEN UNAVAILABLE OR ASSIGNED

- MINOR SYNCH TOKEN ASSIGNED

• MAJOR SYNCH REQUEST

- DATA & SYNCH MINOR TOKENS ASSIGNED OR

UNAVAILABLE

- MAJOR -ACTIVITY TOKEN ASSIGNED

• EXCEPTION REPORT REQUEST

- DATA TOKEN UNASSIGNED

• CAPABILITY DATA

- DATA & SYNCH MINOR TOKENS ASSIGNED

OR UNAVAILABLE

- MAJOR-ACTIVITY TOKEN ASSIGNED
FUNCTIONAL UNIT NEGOTIATION

t REQUESTOR PROPOSES A SET OF FUNCTIONAL UNITS

« ACCEPTOR ALSO PROPOSES A SET OF FUNCTIONAL UNITS

« HALF-DUPLEX & DUPLEX MAY NOT BOTH BE PROPOSED SY

ACCEPTOR

t CAPABILITY DATA MAY BE PROPOSED ONLY IF ACTIVITY

MANAGEMENT IS PROPOSED

$ EXCEPTION REPORTING MAY BE PROPOSED ONLY IF HALF-DUPLEX

IS PROPOSED

• SELECTED FUNCTIONAL UNITS ARE THE INTERSECTION OF THE

REQUESTOR AND ACCEPTOR PROPOSALS
INITIAL SYNCH POINT SERIAL NUMBER

• PROPOSED WITH MINOR SYNCH, MAJOR SYNCH, OR RESYNCH

FUNCTIONAL UNITS WHEN ACTIVITY MANAGEMENT IS NOT

PROPOSED

• ACCEPTOR SELECTING ANY OF THE PROPOSED FUNCTIONAL

UNITS RETURNS A VALUE THAT WILL BE INITIAL SYNCH

POINT FOR CONNECTION

• ACTIVITY MANAGEMENT FUNCTIONAL UNIT IMPLIES INITIAL

SYNCH POINT SERIAL NUMBER OF ONE

^^5
INITIAL TOKEN ASSIGNMENTS

t WHEN A FUNCTIONAL UNIT REQUIRING TOKEN IS PROPOSED AN

INITIAL TOKEN LOCATION IS ALSO PROPOSED

i POSSIBILITIES: CALLING SIDE, CALLED SIDE, CALLED CHOICE

• WHEN FUNCTIONAL UNIT IS SELECTED TOKEN REVERTS TO SIDE

PROPOSED BY CALLER EXCEPT -

f IF CALLER SAID CALLED CHOICE, TOKEN REVERTS TO SIDE

PROPOSED 8Y CALLED USER
PRIMITIVE SEQUENCING

• USER REQUESTS & RESPONSES ARE DELIVERED BY PROVIDER IN THE

ORDER SUBMITTED EXCEPT -

t SEVERAL REQUESTS WHICH MAY BE DELIVERED EARLIER THAN NORMAL

• EXCEPTIONS INCLUDE:

S-EXPEDITED-DATA

S-RESYNCHRONIZE

S-ACTIVITY-INTERRUPT

S-ACTIVITY-DISCARD

S-U-ABORT
SYNCH POINT SERIAL NUMBER MANAGEMENT

t DEFINED AS OPERATIONS ON FOUR ABSTRACT VARIABLES - V(M), V(A), V(R), Vsc

t V(A) » LOWEST SERIAL NUMBER TO WHICH SYNCH POINT

CONFIRMATION IS EXPECTED

« V(M) - NEXT SERIAL NUMBER TO 8E USED

• V(R) » LOWEST SERIAL NUMBER TO WHICH RESYNCH RESTART

IS PERMITTED

« Vsc » CONTROLS RIGHT OF USER TO ISSUE MINOR SYNCH

POINT CONFIRMATIONS

« SYNCH & RESYNCH REQUESTS, RESPONSES, INDICATIONS, &

CONFIRMATIONS EXAMINE THESE VARIABLES AND CAUSE OPERATIONS

TO BE PERFORMED ON THEM
SESSION CONNECT PARAMETERS

t CONNECTION INDENTIFIER

• CALLING/CALLED SSAP

• RESULT

f QOS

0 SESSION FUNCTIONAL UNIT REQUIREMENTS

0 INITIAL SYNCH POINT SERIAL NUMBER

0 INITIAL TOKEN ASSIGNMENTS

0 USER DATA (TO 512 OCTETS)
SESSION DATA TRANSFER

t UNLIMITED NORMAL DATA PER SOU

« EXPEDITED SOU 1 TO 14 OCTETS

• UNLIMITED TYPED DATA PER SOU

i CAPABILITY DATA SDU 1 to 512 OCTETS

c NORMAL DATA SUBJECT TO TOKEN RESTRICTIONS

t CAPABILITY DATA SUBJECT TO TOKEN RESTRICTIONS

AND ACTIVITY CONTEXT

• TYPED & EXPEDITED DATA ARE FULL-DUPLEX

2 ^^
TOKEN MANAGEMENT

t PLEASE TOKENS

- LIST OF REQUESTED TOKENS

- UP TO 512 OCTETS USER DATA

t GIVE TOKENS

- LIST OF SURRENDERED TOKENS

• GIVE CONTROL

- SURRENDERS ALL AVAILABLE TOKENS

- ONLY PERMITTED WHEN ACTIVITY MANAGEMENT

IS SELECTED AND NO ACTIVITY IS IN PROGRESS
SYNCH POINTS

9 MINOR SYNCH POINT

- EXPLICIT OR OPTIONAL CONFIRMATION

» SERIAL NUMBER

» UP TO 512 OCTETS USER DATA

9 MAJOR SYNCH POINT

« SERIAL NUMBER

- UP TO 512 OCTETS USER DATA

• RESYNCH

» TYPE: ABANDON, RESTART, SET

- SERIAL NUMBER

- TOKENS & LOCATIONS

- UP TO 512 OCTETS USER DATA

2Sb
EXCEPTION REPORTING

• PROVIDER EXCEPTION

- REASON

- NO DATA TRANSFER OR SYNCH POINTS

UNTIL ERROR IS CLEARED

- CLEARED 8Y RESYNCH, ABORT, INTERRUPT,

DISCARD, OR GIVING DATA TOKEN

• USER EXCEPTION

- REASON

- UP TO 512 OCTETS USER DATA

- WORKS ONLY IN HALF-DUPLEX MODE

- NO DATA TRANSFER OR SYNCH POINTS

UNTIL ERROR IS CLEARED

-.SAME CLEARING PROCEDURES AS FOR PROVIDER

EXCEPTION
ACTIVITY MANAGEMENT

« START

- ACTIVITY IDENTIFIER

» UP TO 512 OCTETS USER DATA

• END

» SERIAL NUMBER

» UP TO 512 OCTETS USER DATA

» EQUIVALENT TO MAJOR SYNCH POINT

« DISCARD

» REASON

» DATA WILL BE LOST

t INTERRUPT

» REASON

« UNDELIVERED DATA WILL BE LOST

i RESUME

» NEW & OLD ACTIVITY IDENTIFIERS

» SERIAL NUMBER

- OLD SESSION CONNECTION IDENTIFIER

- UP TO 512 OCTETS USER DATA
CONNECTION RELEASE

0 ORDERLY RELEASE

- RESPONSE RESULT (IF NEGOTIATED)

- UP TO 512 OCTETS USER DATA

0 USER ABORT

- UP TO 9 OCTETS USER DATA

0 PROVIDER ABORT

- REASON
COLLISION RESOLUTION

• HIERARCHY OF REQUESTS

« ABORT

» DISCARD

- INTERRUPT

- RESYNCH (ABANDON)

- RESYNCH (SET)

- RESYNCH (RESTART)

- USER EXCEPTION

§ RESYNCH (ABANDON) COLLISIONS RESOLVED

IN FAVOR OF CALLING USER

« RESYNCH (RESTART) COLLISIONS RESOLVED IN

FAVOR OF LOWEST SERIAL NUMBER OR CALLING

USER FOR EQUAL SERIAL NUMBERS

• RESYNCH (SET) COLLISIONS RESOLVED IN FA /OR

OF CALLING USER
Proposal for Sessions

Protocol

we are not currently working on a Session imolenientatlon, Trfs

section gives our ”ballDark'' estimates o^ How long a reasonaolv

fxperlenced Imolementor would take for a hand coded version,

PTAN**s uaace of the Session layer is In a state of confusion.

However# If we take as a given that atthe worksnoo we snoulc

support the A\si position, then TTA'^ will reaulre the following

Session "functlonalunlts":

Kernel functional unit

S.CO^JNECT Creo# Ino, reso# conf)

S.DATA (red, Inc)

5. RELEASE free# InC, reso# con<)

S^U.ASGRT (reo# ina)

S.P.ABCPT Cine)

Duplex functional unit

Hinor synchronize functional unit

S^SYMC.MINOR Crec, Ino, reso# cenf)

5.TCJKEN.GIVE (reO/ Inn!

S.TOKEh.PLEASE (rec, Inn)

Resynch ron 1 ze functional unit

S^PESYVCHRQMZE (red# 1"c» reso# conf)

TneSe redulrements are documented on page 5 of I3D DR 857i/a,

The y,y00 series reculres the much more comolex 9AS subset of

session. Specifically the following features are reaulred:

Kernel functional unit

S^CONMECT (red# Ind, reso# conf)

S.DATA (red# Inc)

S^'RELEASE (red, Ina, reso# conf)

S^U^ASORT (red# Ind)

S.P.AaCRT (Inc)

Hal^-duplex functional unit

S.TUt^Ef'-.GIVE (red, Ind)

S.TOKEfJ. PLEASE (red, InH)

^-^Inor synchronize functional unit

S^SYNC^^IMOR (red, Ind, reso, conf)

S^TOKEN.GIVE (red, Ind)

S.TOKEN.PLEASE (red, Ind)

Exceptions functional unit

S.P. EXCEPTION. RERdPi fine)

S.U_EXCEPTIO^j_RE°CPT free, Inc)
Activity fuf^Ct<on§1 unit

S. ACTIVITY. STACT (rea#

sIaCTIVITY. 9ESLM£ (rea, ind)

s”aCT IVITY.I'.'TF.RRUPT (res# 1nd» rese, eonf)

S*ACT I V I TY«D I SC ARD Cr^e» <nd« reie#

sIaCT IVITyIenO (fee# <nd, fcse, eenf3

sItQKEN.GIVE C»*e<3r

sItO'^EN.PLEASE C“««r

S*CO<^TRaL«GIVE

Thea« reau i refrent a are docutfle^ted ©n page CCITT OR X.410

Imp 1 arrent at i on of the union of these two subsets of session

omits the negotiated release# e»oedited data# tyoed data*

cacaoility data exchange and major synchreniie functional units

In addition# Me assume that the implementation will not include

the extended concat enat i on capability (which is an ootional#

negotiated feature of a sessioni.
GMPf^S£NTA77CNFOR 7?^NATIONAL BU^U

OFSTANDAfSyS SPONSOREDMUL 77-VENDOR

^VOfffCSHCP ONOSrSTANDAROS

IMFin^NTATia^

SEP7ENSER5, 1964

GAIThERSEUta Ml

Si-^
CLNS FfKfTOCCL

DOCUr^NTSf^VlEWm

i OCTOBER 1983^SUEOFISO

COti^CnOhLESSIP

Z MAY, 1984 ISSUEOF ISODIS 8473 17^

DATA CCPS^UECATICNSPROTOCOL FOR

PROVIDING THECCM^CnCtEESS-MOC^

NETWOM<SBiVICE"

3. JUL Y13, 1984 ANSIX3S3384-169 "DRAFT

US CCM^4EN7S ONISOD^8473"

J'C.S
TYPES a= CLASSIFICATIONS 0= FOiCTICNS

TYPE 1: MUST BE SUFPCfiTED OKTRINSIC)

TYPE 2: IF NOT SU^POTTED, FSTl^ BTOR PCU

AM) DISCARD PCU SENT.

- TYPE 3: POJ NOT DISCARIS) F Fl>JCTICN NOT

NOTE: ALL CPTIOS IN T>£ E^DCL^SNT AJS C^E

OF ThE AEOVE TYPES.

TIE INTE3^ETWCf3<ING PPOTCCO- (IP) TTTLE

HAS BEEN CHANCE TO;

T>E DATA COf.^UNICATICNS PPOTCCCL FOR

PROVIDING THE CO^ECTIC^tESS-MaD£

KETWC^ SERVICE"
TYPES OF CLASSIBTCATIONS OF FUNCTIONS CCONTT))

IN REGARD TO THE TYPE 3 FUNCTIONSj

THE RETURN CP AN ERIUDR_PDU WHEN THESE FUNCTIONS ARE NOT SUPPORTED IS A

VICLATIDN OF THE SPEOFICATiaN- IT WOULD BE BENEFICIAL, HOWEVER, IF ALL

ENIhSYSTEMS WOULD MELEMENT THE XEeiTICAL ^T OF THE^ TYPE 3 FUNCTIONS,

WHICH WILL BE OUTLINED LATER, IN iUDDmON, TIffi XJSEFUL ERROR__PDU LET HAS

BEEN EXPANTED TO INCLUEE THESE TYPE 3 mRCR_TYPES FOR FUTURE USE.

BECAUSE OF THIS, TYPE 3 FUNCTIONS WfflCH ARE NOT SUPPORTED BY EITHER AN END

OR INTERMEDIATE SYSTEM SHOULD RETURN AN ERRQR_PDU FOR THIS rSVELOPMENT

WORK, WHICH MUST BE SUPRE3SED AT THE COMPLETION OF SUCH WORK IN QRTER TO

MEET ALL STANDARDS WITHIN THE SKCmCATION.
SEEdFICATlGN GF THE PROTCCC3.

TTEE 1 FUNCTIONS

SOLICITED JPROVISIDNS BY (SNERAL MOTORS

1. FDIX Compositkcu - ocncexTts gxv^ at ANSI X3S3^

~ format is acceptable

2. FDU Deconpositicn: ~ concerns given at ANSI X3S3^

” format is acceptable

3. Hiearier Fermat AztalTsis: - indicate a standard Cfirst^ version of the protocol via the netvxx*^ laTcr

protocol ID. ' format is acceptable

4. PDU Lifetime Central Fundkn: - lifetime agreed upon by all originating netverk-entities (500 ms units) - based cn the topology of the network as well as routing algcrithms to be

applied ~ based <n worst case performance criteria, numbers of nodes and/cr hops

~ without it, we may parse a packet forever

5.

Route FDU Rmdicn:

- need for this fundicn is inherent in any network layer inplementaticn

-* without this function, we have no fundional pio)tocol
6. Fcrvard FDU Functkn: - need £cr this functkan is inhererrt in any la^ inipten^^

~ requires segtnentaticn/reasseirbly functicns to be urplemented

7» Segrnentaticn Functicsu ~ needed fcr fcr>«:d FDIJ Function xinless a ixBxiznum Data FDU size v^iich is

acceptable by alL participating subnets is enforced. - unr^listic to perfcrnt the above, so inplennent this function

8.

Reassembly F\sictJon: - imidied as segnentatkn is used, ve must rer-form the Initial PDU, vAveth^

Data cr Errcr ^rpe - requires the correct selection of PrUJ lifetime such that all transmitted

PDU*s that were segnnunted will be reassembled within this **reascnable"

timeframe » also implies azieed fer ezror reporting

9. Discard PDU Functkn:

-required if any errors will ocoir, this mechanism must be provided to

«»ble a standard ncavery procedure. - format acceptable

10. Error Bepcrtnig Functkn: - win be extremely useful fcr diagnostic purposes " the source netwcrk entity must set the error report flag to "one" - the errcr^ types m section 8.3JL, along with those in ANSI X3S3.3 &4-169

should suffice fcr ezplainatkn of these types, but we may wish to aki

additional non standard ezrcr^types fcr diagnostic pimposes, vmich may be

deleted after a functional network is provided for.
n. FDU Header ErrcrDetecticn

ezTcr rate of LAN is low already " the endrend checksum is not required at transport, not here either ~ the LANs have checksums in effect at the Data Link Layer already, and this

is adequate fcr our needs. - obviously, we vQl accept and process all incoming checksums according

" no checksum provided ficr Data FDU Cbecause not in xpcrt iirpLemexitatkn) - if header is being altered inadveratantly in the course cf processing, the

mechanism provided fcr checksum is good, especially page 84, section C5. ~ useful fcr debugging and system dervelopment ~ therefcre, set the two octets to "zero" fcr this Functicsi, but we are open

to utnJzing the functksi fcr this system development wcrk, providing its

overbad as well as its function can be supressed after this wcrk is

ccn^leted.

12. Padding Functicn: - is a type 3 function, as outlined in note 2, p. 25

3(, ^
SEECinCATIDN C3F THE EROTOCCL

TYPE 2 FUNCTIONS

SCLICITED PROVISIDNS BY GENERAL MOTORS

1. Seeuri^ Functkn: - we have z» requgement to impleinent at the presez^ time ” we would like to discard incctning PDUs, and th^tgr return an error ?DU

"unsuppcrted_security_ppticfi”

2. OompLete Source Routing Functkn: - we have x» need to implNnent at the present time ~ the functkn is a good mtermediate system dfagnostic tooL, and we are open

Its utRizatkn fcr this purpose, as Icng as the parameter can be supressed

after Imllal development work.
SEECIFICATION GF THE EROTOCO,

TTFE 3 FUNCTIONS

SOLICITED PROVISIONS BY GENERAL MOTORS 1.

Padding Functicn: - useful for ease of inpl^nsntaticn, diagnostic tool - viseful for screening or ccnvnentizig-out any un^plicable data fields - izrplenent this function

2. Pailial Source Routing Function: as Complete source routing, it is xoseful as a diagnostic tool - not as useful for the above as complete source routing - do not implennent

3. Priority Function: - this is iirportant in the LAN - VAN scenarios

-there win be messages vAiich are of greater impcrtance than others - we need a mechanism to support this requirement, so that they win be

processed first - the format of 16 priority levels is acceptable - we would like the highest prioity to be processed first, FIFO within any

given priority level - implement this functicn

4. Recording of Route Functicn: - not required at this time - useful fcr diagnostics, especially in ccnjuncticzi with complete source routing - do not implunent, \mless a great need fcr additional diagnostic tools is

fcrseen. Supress after development wcrlc is completed.

S-?d
5. QCS Maizitenance Fuxurtxaa:

useful fcr ccantmued qos cn a LAN-WAN ceamectkin - iinpcrtant fcr ccntinued qps within intermediate systeins - assignment of another to a requested qps is acceptable - implunent this function

S7/
MATRIX OF 71-E CLNS PROTOCO- IMPLEN£NTATICN FEATURES

PDU COMPOSITION

PDU DECOMPOSITION

HDR FORMAT ANALY

PDU LIFETIME

ROUTE PDU

FORWARD PDU

SEGMENTATION

REASSEMBLY

DISCARD

ERROR REPORT

HDR ERROR DETECT

SECURITY

XIMP. SOURCE RTING

PART SOURCE RTING

PRIORITY

RECORD OF ROUTE

QOS

PADDING

SOLICITED PROVISIOvS BY GE^ERAL MOTORS

I^f=LE^CNT

IMPLEMEN I r' r SUPRESS

iiii

YES, VERSION im

SYESiii

a»iil iiiiiigi

i , ^

IliPI

>ilaif<^!r-»i^ii>‘>^'T^ Hiipg ^a^a«feii

SSii*

MiplM SgiHiia T?7t7T'TTT/7TjTtv5TTT^T ^ ^

i,,i rfiilSSiltia

kr(§iS;^&1^,^SSSh'i5’ [ppop^ ;ip»

r i

L'tt-ar ^^PSip^ US [^222' IjSSspuSp

SSu-f^SSyl«avr^’‘'^ij i^P YES ;<>)».>]^v >^iMMi>«Ni«*MM^^ YESm &«s\\v:j45
ISO File Transfer, Access, and Management

Model, Services, and Protocol

James C. Berets

Bolt Beranek and Newman Inc.

31S
STATUS OF FTAM

Work internationally progressing in

ISO/TC97/SC21/WG5 (recently moved

from SC16).

Work in U.S. progressing in ANSI/X3T5.5.

FTAM recently balloted as ISO Draft

Proposal 8571.

Second DP ballot probable in early 1985.

Mapping to Session pass-through services

still under discussion.
THE VIRTUAL FILESTORE

Descriptive model to imiformly represent

the properties of filestores and the files

contained in those filestores.

Allows differences in filestore

implementation to be absorbed into a local

mapping.

Virtual filestore representation not limited

to real filestores.

Virtual filestore defines: file access

strucmre, file and activity attributes,

actions on files.
File access structure

Files contain one or more Data Units

possibly related in some fashion (e.g.,

sequential, network, relational, or

hierarchical).

Virtual filestore provides a tree structure

(called the access structure to represent the

relation between Data Units.

Subtree of the access structure is known as

a File Access Data Unit (FADU).

Essentially a hierarchical model.

Two special cases of access structure:

unstructured files and fiat files.
^ADU

Access Structure

Using Tree Notation

S'J'l
File Attributes

Kernel subset

Filename

Presentation context

Access structure type

Presentation structure name

Current filesize

Storage subset

Account

Date and time of creation

Date and time of last modification

Date and time of last read access

Identity of creator

Identity of last modifier

IdentityK/ of last reader

File ayailability

Possible access type

Future filesize

Security subset

Access control

Encryption name

Legal qualifications
Activity Attributes

Kernel subset

Requested access

Location of initiator

Current access structmre type

Current presentation context

Storage subset

Current account

Current access context

Concurrency control

Security subset

Identity of initiator

Password

J7?
THE FTAM SERVICE

Based on establishing and disestablishing a

series of regimes.

Entering regimes builds up the operational

conteod of the entities step-by-step.

Asymmetric model

Initiating and responding entities

during application connection, file

selection, and open regimes.

Sending and receiving entities during

data transfer regime.

Reliable and user-correctable services.
Application connection regime

File selection regime

Open regime

Data transfer

Read/mrfte

Open

Select

Connect

Transfer End

Close

Deselect

Release

FTAM RHGTMK NESTING
Service Subsets

File Transfer Service Subset

File Access Service Subset

Limited File Management Service Subset

Enhanced File Management Service Subset
File Transfer Service Subset

CONNECT

Establish an application association

with the specified FTAM entity.

SELECT

Select the file on which actions are to

be performed.

OPEN

Open the selected file and negotiate the

context in which its contents will be

interpreted.

READ / WRITE

Establish the direction of the data

transfer.

DATA

Transfer the data.

DATA_END

All data has been sent.
TRANSFER__END

Data transfer is complete.

CLOSE

Close the open file.

DESELECT

Release the selected file.

RELEASE

Release the application association.

CANCEL

Cancel the data transfer in progress.

ABORT

Release the application association

unconditionally, abandoning any

activity in progress.

BEGIN_GROUP

Indicate the start of a set of

concatenated requests.

END_GROUP

Indicate the end of a set of

concatenated requests.
File Access Service Subset

LOCATE

Locate the specified FADU.

ERASE

Erase the specified FADU.
. Limited File Management Service Subset

CREATE

Create a new file with the specified

attributes and select that file.

DELETE “ “ '

Delete and deselect the selected file.

READ_ATTRIB

Obtain information about the selected

file.
Enhanced File Management Service Subset

CHANGE_ATTRIB

Modify the attributes of the selected

file.

2^1
Error Recovery Service Subset

RECOVER

Recreate the open regime following a

failinre.

CHECK

Mark / acknowledge transferred data.

RESTART

Interrupt data transfer and negotiate

restart point.
THE FTAM PROTOCOL

Relies on underlying services of OSI

Presentation Layer.

Uses OSI Session Layer pass-through

services to provide checkpointing and

recovery.

Currently provided are basic and error

0 recovery protocol.

Basic protocol provides for the

establishment and disestablishment of

regimes and the movement of data.

Error recovery protocol provides a standard

set of error recovery procedures.

Non-standard error recovery procedures

may be implemented by using the usercorrectable service.
FTAM Session Layer Requirements (First DP)

Kernel fimctional unit

S_CONNECT (req, ind, resp, conf)

S_DATA (req, ind)

S_RELEASE (req, ind, resp, conf)

S_U_ABORT (req, ind)

S_P_ABORT (ind)

Duplex functional unit

Minor synchronize functional unit

S_SYNC_MINOR (req, ind, resp, conf)

S_TOKEN_GIVE (req. ind)

S_TOKEN_PLEASE (req, ind)

Resynchronize functional unit

S RESYNCHRONIZE (req, ind, resp, conf)
FTAM Protocol Data Units

FTAM protocol data units (PDUs) specified

in notation based on that used in CCITT

X.409.

More complex structures defined in terms of

a set of primitive and constructor types

(e.g, BOOLEAN, INTEGER, OCTET

STRING, SET).

Rules for encoding the specified abstract

syntax are independent of the abstract

syntax itself.

At least one set of encoding rules will be

specified by ISO.

39/
FABORTrequest ::= SET {

originator [0] INTEGER {

fileServiceUserInitiated (0),

fileServiceProvidedlnitiat^ (I)}?

diagnostic Diagnostic}

Diagnostic ::= [APPLICATION 2] IMPLICIT SET {

errorTypeldentifier [0] ErrorTypeldentifier.

errorldentifier [Ij Errorldentifier,

suggestedDelay [2] INTEGER OPTIONAL,

furtherDetails CHOICE {

humanReadable [3] ACharString,

machineReadable [4] OCTET STRING) OPTIONAL)

Errorldentifier INTEGER {

noReasonProvided (0),

mandatoryParameter (2),

illegalParameterValue (3),

unsupportedParameterValue (4)}

ErrorTypeldentifier INTEGER {

success (0),

warning (1),

recoverableError (2),

unrecoverableError (3)}

39L
AREAS FOR FUTURE EXPANSION

Filestore and file management.

File access.

Manipulation of groups of files

simultaneously.
FURTHER TUTORIAL MATERIAL

D. Lewan, and H.G. Long, "The OSI File

Service," Proceedings of the IEEE, Volume

71, Number 12, pp. 1414-1419, December

1983.

P.F. Linington, "The Virtual Filestore

Concept," Computer Networks, Volume 8,

Number 1, pp. 13-16, February 1984.
Proposal for a Useful Connectionless Internetwork Protocol

BASIC PROPOSAL

The conformance (full) protocol is proposed according to the ISO D.I.S.

for the Data Communications Protocol for Providing the Connectionless-mode

Network Service. (See the attachment on Conformance and the Provision of

Functions for Conformance, extracted from the D.I.S.)

It is proposed that only type 1 functions be implemented for a timely

and useful service. (See the attachment on function types, extracted

from the D.I.S.)

SUBNETWORK USER DATA

If source and destination end systems are on the same 802.3 or 802.4

subnetwork, then the same size restrictions as applied to the 1984 NCC

demo should prevail. (In this case, the Inactive Network Layer Protocol

Subset is being employed.) If the full protocol is being used to

concatenate subnetworks then the maximum user data size of 64+K should be

permitted, corresponding to the IP specification. Practically, no statement need be made about minimum user data sizes, since it is expected

that the transport class 4 header and transport user data will be of nontrivial length.

PDU LIFETIME

For purposes of concatenating LANs, typically an intermediate system

might subtract one from the lifetime field. This represents 500 milliseconds

for transit between intermediate systems and processing by one intermediate

system. Thus, it is recommended that source end systems insert an initial

value corresponding to the width of the catnet plus two. This should

safely allow the destination end system to process the received PDU.

ROUTING

For purposes of a useful exercise it is recommended that fixed routing

tables be used, .It is suggested that implementations provide operator

control to manipulate routing tables, since the exact topology for any

demonstration may be subject to last minute modifications.
SEGMENTATION AND REASSEMBLY

Destination end systems must be able to reassemble. Source end

systems must either fit the transport PDU plus IP header into a single

subnetwork service data unit or be able to segment. Reassembly by

intermediate systems is not recommended, however they must be able to

segment. Setting of the segmentation permitted flag should be at the

discretion of the source end system, however it is suggested that the

flag be set to allow segmenting.

ERROR REPORTING

NOTE: THIS RECOMMENDATION AMENDS AND STRENGTHENS THE BASIC PROPOSAL

SECTION REGARDING CONFORMANCE. If the error report flag is on and a PDU

of type 3 is discarded because it is not supported, then an error report

should be returned even though this is not strictly requi red for conformance.

This is recommended for purposes of debugging. It is further suggested,

for debugging, that implementations log all error reports. The error

report data field should contain the entire errant PDU, truncated only

if necessary.

IDENTIFICATION

The protocol id. of 1000 0001 is used in the catnet situation with a version number of 0000 0001. For the single subnetwork case, the protocol

id. is 0000 0000.

CHECKSUM

Although checksum of the header is optional it is recommended that

the checksum be used, since emphasis should be on a useful IP rather than

simply on a demonstration. It may also be useful for debugging.

ADDRESSING

Binary representation should be used, since the IP header is binary

based. (See attached table from the ISO d.p. on addressing.)

TOPOLOGIES

Various topologies are considered below. LAN refers either to 802.3

or 802.4, interchangeably. WAN refers to PDN X.25, 1984. Pri refers to

any private (vendor propritary) subnetwork.
Cases considered:

a) LAN

b ) LAN-LAN

c) LAN-WAN-LAN

d) WAN-LAN

e) Pri-LAN

f ) LAN-Pri -LAN

g) Pri -WAN-LAN

LAN Addressing

The Inactive Network Layer Protocol subset is used with identifie

of 0000 0000.

LAN-LAN Addressing

Source and destination addresses in the IP header are of

identical construction. The first octet is local binary, hexidecimal

49. The second octet is the subnetwork identifier. Assign 802.3

LANs beginning with 0000 0001 and 802.4 LANs beginning with 1000

0001. Octets three through eight comprise the 48 bit station address.

Octet nine is the 8 bit network service access point.

LAN-WAN-LAN Addressing

Source and destination addresses are of identical construction.

The first octet is hexidecimal 49, signifying local binary format.

The subnetwork identifer octet, interpreted by intermediate systems

via a routing table, yields an X.121 DTE address. The subnetwork

identifier octet is followed by a station address and NSAP as described in the LAN-LAN case.

WAN-LAN Addressing

Considering the source address on the LAN and the destination

address on the WAN, the source address has the format described in

the LAN-WAN-LAN case. The first octet of the destination address is

.hexidecimal 25 (X.121 DTE, binary). Octets two through eight encode

the 14 decimal digit X.121 DTE address in BCD. Octet nine is the NSAP

Where the LAN is the destination and the WAN the source, the

above format is reversed.
Pri-LAN Addressing

If source end system is on the private subnetwork and destination

end system on the LAN, then the source address is: hexidecimal 49,

subnetwork identifier of the LAN, station address of the gateway, followed

by the private address of the source end system on the private subnetwork.

(The private address on the private subnetwork is interpretable only by

the private subnetwork.) Note that the three items preceding the private

address specify the intermediate system coupling the private network and

LAN, This constitutes routing, not addressing. This may be useful for a demonstration but is not recommended as a general solution. The destination

address is: hexidecimal 49, subnetwork identifier of the LAN, station

address on the LAN, followed by the one octet NSAP. For PDUs traveling

from LAN to private subnetwork the formats are interchanged.

LAN-Pri-LAN Addressing _

This structure is the same as the LAN-WAN-LAN addressing.

Pri-WAN"LAN Addressing _

Where the source end system is on the private subnetwork, the source address is hexidecimal 25, seven octets of X.121 address of

the gateway between the private and PDN subnetworks, followed by the

private subnetwork end system address. Here again, the X'25‘ and

X.121 address specifies particular routing information. It may or

may not be desirable to do this for a demonstration, but it is not

advised as a general solution. The destination address is hexidecimal

49, the LAN identifier, the station address, and the NSAP. POU flow

in the reverse direction formats the source and destination addresses

in the opposite format.

ROUTING TABLE LOGIC

If the format is hexidecimal 25 then the X.121 address is either

this system's or some other system's. If it is this system's, then

interpret the information after the X.121 address. If it is some other

system's, then send to the PDN.

If the format is hexidecimal 49 then check the subnetwork address.

If it is some other subnetwork's then look up in the routing table. If

it is this subnetwork's then broadcast it on this LAN.

Attachment
C0N70RMANCE

For conformance to this International Standard, the ability to

originate, manipulate, and receive PDUs in accordance with the

full protocol (as opposed to the ’’non-segmenting” or "Inactive

Network Layer Protocol" subsets) is required*

Additionally, the provision of the optional functions described

in Section 6.17 and enumerated in Table 9-1 must meet the

requirements described therein.

* Additionally, conformance to the Standard requires adherence to

the formal description of Section 8 and to the structure and

encoding of PDUs of Section 7.

If and only if the above requirements are met is there

conformance to this International Standard.

.PROVISION OF FUNCTIONS FOR CONFORHANCE

The following table categorises the functions in Section 6 vich

respect to the type of system providing the function:

Function Send Fo rward Receive

PDU Composition M

PDU Decomposition M - V

Header Format Analysis

PDU Lifetime Control

•• M

M I Route PDU - M - Forward PDU M M - Segment PDU M (note 1

)

- Reassemble PDU - I V

Discard PDU - M M

Error Reporting - M U

PDU Header Error Detection M V V4 « Padding (note 2

)

(note 2

)

(note 2

)

Security - (note 3

)

(note 3

)

Complete Source Routing - (note 3

)

- Partial Source Routing - (note 4

)

- Record Route - (note 4

)

* QoS Maintenance * (note 4

)

—

Table 9-1. Categori ration of Functions.
Table 6-1 shows how the functions are divided into these thTee

categories

;

Function Type

PDU Composition 1 PDU Decomposition 1 Header Format Analysis 1 PDU Lifetime Control 1 Route PDU 1 Forward PDU 1 Segment PDU 1 Reassemble PDU 1 Discard PDU 1 Error Reporting 1 (note 1)

PDU Header Error Detection 1 (note 1

)

Padding 1 (notes 1 & 2)

Security 2

Complete Source Routing , 2

Partial Source Routing 3

Priority 3

Record Route 3

Quality of Service Maintenance 3

Table 6-1. Categorization of Protocol Functions

Notes:

1) While the Padding, Error Reporting, and Header Error

Detection functions must be provided, they are provided

only when selected by the sending Network Service user.

2) The correct treatment of the Padding function involves no

processing. Therefore, this could equally be described as

a Type 3 functio'n.

3) The rationale for the inclusion of type 3 functions is that

in the case of some functions it is more Important to

forward the PDUs between intermediate systems or deliver

them to an end-system than it is to support the functions.

Type 3 functions should' be used in those cases where they

are of an advi, sory nature and should not be the cause of the discarding of a PDU when not supported.
TABLE 8~l! AFI ALLOCATIONS

00-09 Reserved - will not oe allocated

10»19 Reserved for future allocation by Joint

agreeinent of ISO and CCITT

20-51 Allocated and assigned to the IDI formats

defined in clause 8.2.l«2

52-59 Reserved for future allocation by Joint

agreement of ISO and CCITT

$ 0-69 Allocated for assignment to new IDI formats

by ISO

70-79 ' Allocated for assignment to new IDI formats

by CCITT

80-99 Reserved for future allocation by Joint

agreement of ISO and CCITT

S.2.1,2 FORMAT AND ALLOCATION OF THE IDI

A specific combination of IDI format and DSP syntax is associated witn

each allocated AFI value^ as summarized in Table 8-2:

TABLg 8-2; AFt Values
IMPLEMENTORS OF OSI

WORKSHOP SCHEDULE

Nov. 7-9 (INTEL)

Jan, 22 - 24 (HIS)

Apr. 16 - 18 (NBS)

June 25 - 27 (NBS)

Sept. 17 - 19 (NBS)
CONNECTIONLESS IP

PROPOSAL

ALL TYPE 1 FUNCTIONS

- COMPOSITION

- DECOMPOSITION

- HEADER ANALYSIS

- LIFE TIME BOUNDING

- ROUTING

- FORWARDING

- SEGMENTING

- REASSEMBLING

- DISCARD

- ERROR REPORTING

- ERROR DETECTION

- PADDING
• OPTIONAL TYPE 1 . 3 FUNCTIONS

- SECURITY

- COMPLETE SOURCE ROUTING

- PARTIAL SOURCE ROUTING

- PRIORITY

- ROUTE RECORDING

- QOS
ADDITIONAL RECOMMENDATIONS

• SUBNETWORK USER DATA

• PDU LIFETIME

• ROUTING

• SEGMENTATION & REASSEMBLY

• ERROR REPORTING

• PROTOCOL AND VERSION ID

• CHECKSUM
ADDRESSING

1

- SINGLE LAN

• INACTIVE NETWORK LAYER PROTOCOL

(no ip header addresses)

• 48 BIT STATION ADDRESS

• 8 BIT NSAP

2

- LAN-LAN

• X' 49^ FORMAT TYPE

• 8 BIT SUBNETWORK IDENTIFIER

• 48 BIT STATION ADDRESS

• 8 BIT NSAP

3

- LAN-WAN-LAN

• FORMAT TYPE

f 8 BIT SUBNET ID

(table pointer to X.121 DTE address)

• 48 BIT STATION ADDRESS

• 8 BIT NSAP
ADDRESSING cont.

4 - WAN-LAN

LAN-to-WAN

SOURCE: - 49^

- 8 BIT SUBNET ID

- 48 BIT STATION ADDRESS

- 8 BIT NSAP

DESTINATION:

» X' 25^

» 7 OCTET X.121 DTE ADDRESS

- 8 BIT NSAP

5 - PRIVATE-LAN

i PRI-to-LAN

SOURCE; » X' 49'

- 8 BIT SUBNET ID

- 48 BIT STATION ADDRESS

(of intermediate system)

- PRIVATE ADDRESS

NOTE: THE FIRST THREE ITEFIS CONSTITUTE ROUTING

AND YOU MAY NOT WANT TO DO THAT.

DESTINATION:

- X' 49'

- 8 BIT SUBNET ID

- 48 BIT STATION ADDRESS

- 8 BIT NSAP
ADDRESSING cont.

6 - LAN-PRI-LAN

• SAME AS LAN-WAN-LAN

7 - PRI-WAN-LAN

• PRI-to-LAN

SOURCE: - X' 25'

- 7 OCTETS X.121 DTE ADDRESS

9 - PRIVATE ADDRESS

NOTE: THE FIRST TWO ITEMS CONSTITUTES ROUTING

AND YOU MAY NOT WANT TO DO THAT.

DESTINATION:

- X' 49'

- 48 BIT STATION ADDRESS

- 8 BIT NSAP

^03
ROUTING

iol
LAYER 3 - INTERNET: TIME. RESOURCES ESTIMATES

WHAT

- IP; DEMO SUBSET OF CONFORMANCE SUBSET (NO TYPE 2 OR

TYPE 3 FUNCTIONS i.e.. NO SECURITY. SOURCE

ROUTING. PRIORITY. ROUTE RECORDING. QOS. OR

PRIORITY FUNCTIONS)

COMPLETE: 2/1/85 (INSTALLED AND RUNNING. READY FOR

PROTOCOL TESTING BY NBS)

- IP TEST BED

ARCHITECTURES

TEST CASES
0 TEST BED ARCHITECTURES

ENCODER/DECODER

REFERENCE IMPLEMENTATION (RI) WITH TEST HARNESS

0 ENCODER/DECODER

CAN CONSTRUCT. RECOGNIZE ALL TYPE OF VALID IPDUs

CAN CONSTRUCT. RECOGNIZE ERRONEOUS IPDUs

0 RI WITH TEST HARNESS (SCENARIO INTERPRETER AND

TRANSPORT OVER IP)

CAN CONSTRUCT A SUBSET OF VALID PDUs (ONLY THOSE

INDUCIBLE VIA THE IP SERVICE INTERFACE)
u

t/1

error

PDUs
RI WIIH TEST HARNESS

0 ASSUMPTIONS; /

/ / 1) mxiTM LEVEL OF STAFING (AT LEAST 1 STAF/'PERITeD

2) MlAXTM (BICURRBICY

.3) START DATE 9/V84

4) AVAILABILITY OF

^

VAX DEVELORWT SYSTH1 BY START DATE

(EARLIEST DELIVER DATE; OCTOBER '84. EARLIEST AVAIU^LE

DATE: NOVEMBER '84)

5) SEPARATE DMUDPMEMT PATH FOR INTERNET WITH IP INSTALLED

AND RUNNING (READY FOR PROTOCOL TESTING) BY 2/1/85

6) SEPARATE IBELOPmff PATHS FOR EXTENDING. UPDATING

TRAIOTRT AND FOR FTPj SEPApATE TESTING OF MODIFIED

tra-nisport and of n?.

0 LIKELY SLIPPAGE;

3 MOmiS (FOR ASSUMPTION #4) TO 7/31/85.
RI WITH TEST HARNESS

ITEM

TIME-TQ-CQMPLETE (PM)

DESIGN. CODE. CRITICAL CRITICAL PATH

SPECIFY UNIT TEST PATH TIME COMPLETE DATE

MODIFY INTERFACES

FOR IP ^

MODIFY PDU LOG

ANALYSIS TOOLS ^

TEST CASES 1

PORT TEST HARNESS TO

32-BIT ENVIRONS

INTEGRATION TESTING

INTERNET PROTOCOL TESTING

INSTALLATION TESTING.

DISTRIBUTION TO TEST

CENTERS. FIELD TESTING

10/31/8A

10/31/84

12/31/84

2/28/85

3/31/85

4/30/85
ENCODER/DECODER

0 ASSUMPTIONS:

1) MAXIMUM LEVEL OF STAFFING (AT LEAST 1 STAFF PER ITEM).

2) MAXIMUM DEGREE OF CONCURRENCY

3) START DATE; 9/A/84

4) AVAILABILITY OF NBS VAX DEVELOPMENT SYSTEM BY START

DATE (EARLIEST DELIVERY DATES OCTOBER '84. EARLIEST

AVAILABLE DATE: NOVEMBER '84)

5 ) SEPARATE DEVELOPMENT PATH FOR INTERNET WITH IP

INSTALLED AND RUNNING (READY FOR PROTOCOL TESTING)

BY 2/1/85.

6) SEPARATE DEVELOPMENT PATHS FOR EXTENDING. UPDATING

TRANSPORT A^ND FOR FTP: SEPARATE TESTING OF MODIFIED

TRANSPORT AND OF FTP.

0 LIKELY SLIPPAGE;

3 MONTHS ( FOR ASSUMPTION #4) TO 6/30/85

+4 MONTHS (FOR ASSUMPTIONS #1. #2) TO 10/31/85
ENCODER/DECODER

TIME-TO-CONPLETE (PM)

DESIGN. CODE. CRITICAL CRITICAL PATH

SPECIFY UNIT TEST PATH TIME COMPLETE DATE

m 2 2 ' ^ n

E/D 2 2- A

COMPARATOR 2 2

XMIT/RCV

LOG ANALYZERS

2 2 4

> 12/31/8A

2 2 4

RER 2 2 4

USER COMMAND LANGUAGE 1

TEST CASES 1 . INTEGRATION TESTING 1 1/31/85

IP TESTING 1

• 2/2S/85

INSTALLATION TESTING. 1 3/31/85

DISTRIBUTION TO TEST - CENTERS. FIELD TESTING
LAYER 3 TIME. RESOURCE ESTIMATES

0 ACCURACY; PROBLEMATIC

0 3 SECTIONS:

- TASK AND CRITICAL PATH TIME

- ASSUMPTIONS

» LIKELY SLIPPAGE
SI

-

SCENARIO

INTERPRETER

RSI

-

REMOTE

SCENARIO

INTERPRETER

EG

-

EXCEPTION

GENERATOR

LOT

-

LAYER

UNDER

TEST

IP

RI

-

INTERNET

PROTOCOL

REFERENCE

IMPLEMENTATION
ENCODER/DECODER

i/9

E/D

-

ENCODER/DECODER

LUT

-

LAYER

UNDER

TEST

(IP)

XMIT/RCV

-

SENDER/RECEIVER

I
NETWRK LAYER ADDRESSING

CX)NCEPTS AND TERMINOLOGY

PRINCIPLES FOR CREATING THE NETWRK LAYER ADDRESSING SCHEME

NETWORK ADDRESS SEMANTIC STRUCTLTE

REPRESENTATION AS BINARY AND DECIMAL I

REL-^TIONSHI P BETWEEN SEMANTICS. REPRESENTATION. AND ENCODING
BASIC PRINCIPLES OF THE

NTTWRK LAYER ADDRESSING SCHEME

HIERARCHICAL STRUCTURE OF NSAP ADDRESSES

- ROUTING

- AEMINISTRATION OF ADDRESS SPACE

. MULTI -LE\T:L HIERARCHY*

- CONCEPT OF ADDRESS "DCMAINS” AND "SL^DCMAINS”

GLOB.AL IDENTIFICATION OF ANY NSAP

ROUTE AM) SERVICE TYPE INDEPENDENCE

BINARY AND DECIMAL ADDRESSES ACCOMVDDATED

VARLABLE length .ADDRESSES UP TO A DEFINTD MAXIMLM SIZE
NETWRK ADDRESS SEMANTIC STRUCTURE

INITIAL DCMAIN PART ( IDP )

- AUTHOR I TY ANT) FORMAT I DENT I F I ER I .AF I )

- CONVTYS . FORMAT . LENGTH. ANT) ”.ABSTR.ACT S'i’NTAX”

OF THE REST OF NSAP .ADDRESS

- SPECIFIES AUTHOR I Tk* RESPONSIBLE FOR ALLOCATING

THE INITIAL DCMAIN IDENTIFIER

- INITI.AL DCMAIN IDENTIFIER IIDI)

- FOLLC^VS ONT OF EIGHT FORMATS

(SEE NEXT VIEW3R.APH)

- SPECIFIES THE NTTVORK .ADDRESSING SUBDCMAIN FRCM

NVHICH VaLUTS of THE DSP .ARE .ALLOC.ATED

- SPECIFIES THE .AlTHOR I Ti' RESPONSIBLE FOR

ALLOCATING V.ALUTS OF THE DSP

DCMAIN SPECIFIC P.ART ( DSP »

- S EMANT ICS IS ( LOC.ALLY ) S I GN I F I CANT I N THE CONTEXT

SPECIFIED BY THE IDP

- MAY BE BASED ON DECIMAL. BIN.ARY. CHAJUaCTER . OR

”NATION.AL CHAJUACTER”
INITIAL DOMAIN IDENTIFIER FORMATS

X. 121 -DTE

- IDI IS AN X.121 ADDRESS (UP TO 14 DIGITS)

X. 121 -DCC

- IDI IS AN X.121 DATA COUNTRY CODE (3 DIGITS)

F.69

- IDI IS A TELEX NLMBER ( UP TO 8 DIGITS)

E. 163

- IDI IS A TELEPHONE NETV^RK (PSTN) NLMBER (UP TO 12 DIGITS)

E. 164

- IDI IS .AN ISDN NTMBER (UP TO 15 DECIMAL DIGITS'

ISO- 65 2

3

- IDI IS ALLOCATED ACCORDING TO ISO 6523. CONSISTING OF

A 4 DIGIT INTERNATIONAL CODE DESIGNATOR ( I CD »

.

FOLLOWED

BY UP TO 2 8 DIGITS DERIVED FROM AN ORGAN I Z.\T I ON (TODE

ISO-6523- ICD

- IDI IS ALLOCATED ACCORDING TO THE I (TD FROM ISO 65 23

LOC.AL

- IDI IS NULL (FOR USE IN A CLOSED COVMLNIT^)
ACCX2vM)DATION OF BINARY AND DECIMAL

BINARY OR DECIMAL ADDRESS ISSUE HAS BEEN CC^TRO\TRS I AL

- IEEE 8 02 AND MAN\’ PRIVATE NTTWRIC ADDRESSES BASED

ON BINARY

- X.121. PSTN. .VND TELEX ADDRESSES BASED ON DECIMAL

DECISION TO ACCOvMDDATE BOTH

- ADDRESS IDP (-AF1 AND IDI ) BASED ON DECIMAL

- DSP BASED ON DECIMAL. BINARY. CRAR.ACTER . OR NATION.AL

CHARACTER

- EATRY .ADDRESS CAN BE FLT,LY REPRESENTED IN BOTH

PURE BIN.ARY AND PURE DECIMAL

- .ALGORITHvIIC CONVERSION BETVAEEN PURE BINARY .AND PLRE

DECIMAL REPRESENTATIONS DEFINTD

INTERNTTVAORK PROTOCOL USES BINARY REPRESENT.AT I ON . CARRIES

DECIMAL BASED FIELDS AS BCD

- TRANSFORMATIONS NOT REQ^'IRED IN THIS CASE
RELATIONSHIP BETWEEN

SBVIAOTICS. REPRESENTATION, AND O'JCODING

WHAT HA\'E WE STANDARDIZED^

- S^IANTICS:

- (TWO DECIMAL DIGITS)

- IDI (VARIABLE DEPENDING ON AFI , DECIMAL DIGITS)

- DSP (VARIABLE, BASED ON DECIMAL, BINARY. CHARACTER.

OR NATIONAL CHARACTER)

- PURE DECIMAL REPRESENTATION

» PURE BINARY REPRESENTATION

= ALGORITIMIC TR.ANS FORMAT IONS

WHAT IS ENCODED IN PROTOCOL HEADERS

- UP TO PROTOCOL DEFINITION (NOT ADDRESS STANDARD)

- MUST CONATY SEMANTICS OF ADDRESS STRUCTURE

- MAY USE PURE DECIMAL OR BINARY REPRESENTATION

- MAY DEFINE OTHER WAY TO CONVEY SEMANTICS

(E,G., SHORTHAND FOR LOCAL .ADDRESSES)
gaI (3fr.v^ ifcu . v r- r ? i :j v » iot fjtenii

1;;

'

, '

s* ?

' ’V

t 4' '

.

i 14*^

M/fX) .‘

*>4“=**.‘^- ^

.

y <iu /

’ iiL, , l^i:.

.-4-01 S“* '

v<% i

f -:

vtJfTATVJltNm'

' v‘

^

"$w;-
NBS»n 4A (REV. 2«ec) U.S. DEPT. OF COMM.

BIBLIOGRAPHIC DATA

SHEET (See /n struct/on s(

1. PUBLICATION OR

REPORT NO.

NBSIR 84-2984

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

4. TITLE AND SUBTITLE

Minutes of the Seventh MBS Workshop for Implenentors of ISO Open Systems

Interconnection September 5-7, 1984

5. AUTHOR(S)

Kenneth Dymond

6. PERFORMING ORGANIZATION (If joint or other than NBS, see instructions)

national bureau of standards

DEPARTMENT OF COMMERCE

WASHINGTON, D.C. 20234

7. Contract/Grant No.

8. Type of Report & Period Covered

9.

SPONSORING ORGANIZATION NAME AND COMPLETE ADDRESS (Street, City. State. ZIP)

10.

SUPPLEMENTARY NOTES

I 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 information. If document includes a significant

bi bliography or literature survey, mention it here)

The National Bureau of Standards has so far (September 1984) hosted seven in a series of workshops. for computer manufacturers and other organizations

implementing ISO protocols for computer communications. The minutes of the

seventh workshop— held September 5-7, 1984, in Gaithersburg , MD--are presented.

The minutes include a brief summary of the three days' discussion, but the great

bulk comprises attachments prepared by participants detailing proposals for

implementing various protocols and for demonstrating their interworking

.

Agreements reached by participants are recorded.

12. KEY WORDS (Six to twelve entries; alphabetical order; capitalize only proper names; and separate key ^ords by le-'ic -Jo" Computer communications; ISO (International Organization for Standardization)

protocols; OSI (Open Systems Interconnection); NBS-OSI Workshops.

13. AVAILABILITY

I I Unlimited

|jlC| For Official Distribution, Do Not Release to NTIS

I I Order From Superintendent of Documents, U.S. Government Printing Office, Washington, D.C. 20402.

f -Order From National Technical Information Service (NTIS), Springfield, VA. 22161

14 . ‘jO. OF

PRiNTtO PAGES

15. Pfic<

I3c . ^0

j- c . O . .4 . >.» .0
sa ^

>w»^>o4Tvi»HrfWn .1 :(4^ ^ ,f '-, ,ST -

^T^ «

' '

' Vf ?. 'M jPtlTRO®^’

v::sa:_rii

tVCktt* '-'K'- f M

' «n

' ''

. "oSJr

4r4ip^!W!iM*7’„ -^'

•

teiTs: **rjr ic-

.1

1. « J

_w

j'" .>;«(fS'.

•p'’.. .• Vt' •j's"?-

T.

t«t««

A

•i -4 rt!i f *i«A Tv*rrv^

A^, jtl

- • T;r4 ,j:

• •V ..i,-.'.. 4

,jU .' ' ii.^d»-‘4 ’-'

I

;

' r« i'-rt ^

' 1

•

‘ r

.' 'S^^l' -.: .!-l' '>' I. .'^*1 ;, (_, 7 , i

|k‘!i> ’ T

' 1^1

h>".f-iil«ftfiKj ...

3re*.^, ^1 ‘%*ti *'-l" » ,” -r' « r,-'.-'^r»i i’Ci*- '

" niT^

Jf ', .V*. «.< 4(i>4P%,'-n ' ^'J

ift ,-«#»%

«iT» ' Ml*? ,#- . II i*> ,mi>>* Vr;.