8/3/2019 01094702_1

1/8

IEEE TRANSACTIONS .ON COMMUNICATIONS, VOL. COM-28, NO. 4, PRIL 1980 4 2 5

OS1Reference Model-The IS0 Model of Architecture forOpen Systems Interconnection

HUBERT ZIMMERMANN(Invited Paper)

Abs tru ctx on sid eri ng the urgency of the need for standards whichwould llow consti tution of heterogeneous omputernetworks, IS 0created a new subcommittee for Open Systems Interconnection IsO/TC97/SC16) in 1977. The first priori ty f subcommittee 16 was to developan architecture for open systems interconnectionwhich could serve as aframework for theefinition ofstand ard protocols. As a resultf 18monthsof studies and iscussions, SC16 adopted layered architecture comprisingseven ayers (Physical, Data Link, Network, Transport, Session, Pres-entation, ndApplication). n uly 1979 the specifications of thisarchitecture, established by SC16, were passed u nder the name of OS1Reference Model to Technical Committee 97 Data Processing alongwith recomme ndations to start fficially, on this basis, aset of protocolsstandardization projects to cover the most urgent needs. These recom-mendations were adoptedby TC97 at the end f 1979as he basis for thefollowing development of stand ards for Open Systems Interconnectionwithin ISO. The OS1 Reference Model was also recognized by CCITTRapporteursGroup on Layered Model forPublicDataNetworkServices.

This paper presents themodel of archit ecture for Open Systems Inte r-connection devel oped by SC16. Some indications ar e also given on theinitial setof pro tocols which will likelybe developed in this OS1ReferenceModel.

I. INTRODUCTIONI ISO)N 1977, the International Organization for Standardizationrecognized the special and urgent need for standardsfor heterogeneous informatic networks and decided to createanew subcomm ittee (SC16) for Open System s ntercon -nection.

The init ial development of computer networks had beenfostered by experimentalnetworkssuch as ARPANET [11or CYCLADES [2],mmediately followedy computermanufacturers 3] , [4]. While experimentalnetworks wereconceived as heterogeneous rom he verybeginning, eachmanufacturer developed his own set of conve ntions for inter-connecting his own quipments, referring to these as hisnetwork architecture.The universal need fornterconnectingystemsro mdifferent manufacturers rapidly became apparent [SI , eadingI S 0 to decide for the creation of SC16 with the objective t ocome upwithstanda rds required for Open Systems nter-connection. The term open was chosen to emphasize thefact hatbyconforming o hose nternationalstandards, asystem will be open to all other systems obeying he samestandards throughout the world.The first meeting of SC16 was held in March 19 78, and

Manuscript received August 5, 1979; revised January 16,1980.The author is with IRIA/Laboria, Rocquencourt , France.

initial discussions revealed [ 6] hat a onsensus could ereached rapidly on a layered architecture wh ich would satisfymost requirementsofOpenSystems nterconnectionwithth ecapacityof being expanded ater t o meet new equire-ments. C16 ecided to give the highest prior ityohedevelopment of standard Model of Architecturewhich wouldconstitute he ramew ork or he development of tandardprotocols.After less than 18 monthsof discussions, thistask was completed, ndhe IS 0 Model of Architecturecalled th e Reference Model of Open Systems Interconnection[7] was transmittedby SC16 to it sparent TechnicalCom-mittee on Data Processing (TC97) along with recommen da-tions to officially start a nu mber of projects for developingon this basis an initial setofstandardprotocols orOpenSystemsnterconnection. These recommen dations wereadopted by TC97 at the end of 1979 s th e basis for followingdevelopmen t of standards for Open Systems Interconnectionwithin ISO. The OS1 Reference Model was also recognized byCCITT R apporteurs Group on Public Data Network Services.

The presentpaperdescribes the OSI Architecture Modelas it has been ransmitted to TC97. Sections 11-V introducecon cepts of a layered architecture, along with the associatedvocabulary defined by SC16. Specific use of h ose concep tsin he OS1 seven layers architecture are then presented inSection VI. Finally, some ndications on the likely develop-ment ofOS1 standard protocols aregiven in Section VII.

No te on n Ynterconnection ArchitectureThe basic objective of SC16 is to standa rdize the rules ofinteractionbetween nterconnected systems. Thus ,only he

external behavior ofOpenSystemsmustconform o OS1Architecture, while the internal organization and functioningof each individual O pen System i s out of the sc0p.e of OS1standards since these are no t visible from other systems withwhich it is interconnected [8] .It should benote d hat he same principle of restrictedvisibility is used n any manufacturers n etwork architecturein order to permit interconnection of systems with differentstructures within theame network.

These considerations leadSC16 to prefer theerm fOpen SystemsnterconnectionArchitecture (OSIA) tothe ermof Open SystemsArch tecture which hadbeenused previously and w as felt to b e possibly misleading. How-ever, for uncleareasons, C16inallyelected theitleReference Model of Open Systemsnterconnect ionorefer to this Interconnection Architecture.

0090-6778/80/0400-0425$00.750 1980 IEEE

8/3/2019 01094702_1

2/8

426 IEEE TRANSACTIONS ON COM MUNICATIONS, VOL. COM-28, NO. 4, APRIL 1980

Fig. 2. An example of OS1 representation o f layering.Fig. 1 . Networkayering.

11.GENE RAL PRINCIPLES O F LAYERINGLayering is a structuringechnique which permitshenetwork of O pen S ystems to be viewed as logically composedof a succession of layers, each wrapping th e lower layers andisolating the m from the higher ayers, as exemplified n Fig.

1.An alternative but equivalent illustration of layering, used

inparticularbySC 16 is iven in Fig. 2 where successivelayers are' represented in a vertical sequence, with thephysicalmedia for Open Systems Interconnection at the bottom.

Each ndividual syste m itself is viewed as being logicallycomp osed of a succession of subsystem s, each correspon dingto the intersection o f the system w ith a layer. In other wo rds,a lay er is viewed as being logically comp osed of subsystem sof hesame. ankof all interconnec ted systems.Each sub-system is, in urn, viewed as being made of'o ne or severalentities. In other words, each layers made of entities, each o fwhich belongs to one system. Entities in th e same layer aretermed peer entities.

For simplicity,any layer is referred to as he (N ) layer,while its next lower and next higher layers are referred to asthe (N - 1) layer and he (N + 1) layer, respectively. Thesamenota tion is used to designate all concepts relating tolayers, e.g., ent ities in the (N ) layer are termed (N ) entities,as illustrated in Figs. 3an d 4.Th e basic idea of layering is tha t each layer adds value toservices provided by the set of lower layers in suchway thatth e highest layer is offer ed the set of services needed t o ru ndistributed applications.ayering th us 'divides theotalprob lem into smaller pieces. A nother basic principle o f layeringis to ensu re indep ende nce of each layer by defining servicesprovided by a layer to the ne xt higher layer, independent ofhow these services are performe d. This permits changes to' bemade in the way a layer or a set of layers operate, providedthey still offer hesame -service. to th enex t higher ayer.(A more comprehensive.list of criteria for laye riniis given inSection VI.) This technique is similar to th eone used instructured programming where only the functions performedby a mo dule (and n ot its internal functioning) are kno wn byits users.Exce pt or he highest ayer whichoperates or tsow npurpose, (N ) entitiesdistributedamong he nterconnectedOpenSystemswork collectively to provide the (N ) service

Highest layer

Fig. 3 . Systems, ayers,and ervices.

to (N + 1) entities as illustrated in Fig. 4. In other words, the(N ) entities add value to th e ( N - 1) service they get from the(N - 1) layer andoffe r his value-added service, i.e., the(N) service to th e (N + 1) entities.

Communication between the N + 1)entities make xclusiveuse of he (N ) services. Inparticular,directcommunicationbetween he (N + 1) entities in th e same system , 'e.g., forsharing resources, is no t visible fro m out side of the syst em andthus is no t covered by the OS1 Architecture . Entities' in thelowest ayer com mun icate hrou gh he Physical Media forOSI, which could be considered as formin g the (0) ayer oft,he OS1 Architecture. Cooperationbetween he (N ) entitiesis ruled by the (N ) protocols which precisely defin e how the(N ) entities work together using the (N - 1) services to per-form the (N ) functions which add value to th e N - 1) servicein order to offer the N) service to th e ( N . + 1) entities.The (N ) services are offe red to h e (N + 1) entitiesatth e (N ) service access points, or (N ) SAP3 for short, whichrepresent th e logical interf aces betw een the (N ) entities andthe (N + 1) entities. An (N) S A P can be served b y only one

8/3/2019 01094702_1

3/8

ZIMMERMANN: I S 0 MODEL FOR OPEN SYSTEMS INTERCONNECTION 427

( N + I ) - e o t i l )

(N)-SAV. ..... (s)-r.bw

(N) entityand used byonlyon e (N + 1) ent i ty,bu tone(N ) entity can serve several ( N ) S A P s and one(N + 1) entitycan use several (N) SAPS,A common service offeredby all layersconsists ofpro-viding associations between peer SAPS which can be used inparticular to tra nsfer data (it can , for instan ce, also be used

tosync hron ize he served entitiesparticipating in the asso-ciation). More precisely (see Fig. S), th e (N ) layer ffers(N) connections between (N) SAPs as part of the (N ) services.Th emost usual type f onne ction is the point-to-pointconnection, uthere are also multiendpoint connectionswhich correspo nd to multiple associations betweenentities(e.g., broadc ast omm unication).The nd of an (N ) con-nection at an (N ) S A P s called an (N ) connection endpoint or(N) CEP for short. Several connections may coexist betwee nthe samepair (or n-tuple) of SAP s .N o t e : In the following, for the sake of simplicity, we willconsider only point-to-point connections.

III. IDENTIFIERSObjects w ithin a layer or a t the boundary between adjacentlayers need to be uniquely identifiable, e.g., in order to es tab-lish a connectionbetw een wo SAPs, onemustbe able toidentify them uniquely. The OS1 Architectu re defines identi-

fiers for entities, SAPS , and connec tions as well as relationsbetwee n these identifiers, as briefly outlin ed below .Each (N ) enti ty is identified with a global itle which isunique and dentifies he same (N ) ent i ty from anywhere nthe netw ork of Ope n Systems. Within more limited domains,an (N ) entity can be identified with local title which uniquelyidentifies the (N ) entityonly n hedomain.For nstance,within the domain corresponding to th e (N ) layer, (N) entitiesare identified with (N ) global titles which are unique withinth e (N ) layer.

Each (N ) S A P is identified with an (N ) address whichuniquely identifies the ( N ) - S A P at heboundarybetweenth e (N ) layer and the (N + 1) layer.

The oncepts f titles and addresses re du stra ted inFig. 6 .Binding between (N ) entities and the (N - 1) SAPs theyuse (i.e., SAPs through which they can access each other andcommunicate) are translated into the concept of N) directorywhichndicates correspondenceetween global titlesf(N ) entitiesan d (N ) addresses through which theycanbereache d, as illustrated in Fig. 7 .

1 The term title has been preferred to the term name which isviewed as bearing a more general meaning. A title is equivalent to anentity name.

Fig. 5. Connectio ns and connectio n endpoint s (CEPs).( N ) - l a Y e r

Fig. 6 . Titles,addresses, and CEP-identifiers.

23 7IE I 01 5-ig. 7. Exampleofan (A)-directory.

Correspondence between (N ) addresses served byan (N )entityand he (N - 1) addresses used for hispurpose isperformedbyan (N) mapping unction. In addi t ion to thesimplest case of one-to-on e mapping, mapping may, in p articu-lar,be hierarchical with he (N ) addressbeing made of an(N - 1) addressand an (N) suffix. Mapping may also beperform ed by table.Those three ypesof mapping reillustrated in Fig. 8.Each (N ) CEP is uniq uely identified within ts (N ) S A Pby an (N> CEP dentifier which is used by the (N ) entity andth e (N + 1) entity on both sides of the (N ) SAP to identifyth e (N) connection as illustrated n Fig. 6 . This is necessarysince several (N) connections may end at theam e (N ) SAP.IV . OPERATION OF CONNEdTIONS

A . Establishment and ReleaseWhen an (N + 1) ent ity requests the establishment of an(N ) connection from one of the (N ) SAP s it uses to another(N ) SAP, it must provide at the local (N ) S A P th e (N ) address

of the distant (N) S A P . When th e (N ) connec tion is established,bo th the (N + 1) entity and the (N ) ent ity will use the (N)CEPidentifier to designate th e (N)onnection.(N ) connec tions may be established and released dynamicallyon opof (N - 1) connections. Establishmentof an (N )connec tion implies th e availability of an (N - 1 ) connectionbetween the two entities. If not available, the (N - 1) con-nec tion mus t be established. This requires the availability ofan (N - 2) connection. The same consideration applies down-wards until an available connection is encou ntere d.

In some cases, the (N ) connection may be establishedsimultaneouslv with its sumortingI!- ) connec tion movided

8/3/2019 01094702_1

4/8

428 IEEE TRANSACTIONS ON COMMUNICATIONS, VOL. COM -28, NO. 4, PRIL 1980

one-to-one Hierarchical By t a b l eFig. 8 . Mapping between addresses.

th e (N - 1 ) connection stablishment service permits (N)entities to exchange information necessary to establish the(N ) connection.B.Multiplexing and Splitting

Three particular types of construction of (N ) connectionso n t o p o fN - 1) connections aredistinguished.

1 ) One-to-one correspondence w here each (N) connectionis built on one (N - 1) connection.

2) Multiplexing referred t o as ''upward multiplexing" in[ 7 ] )where several (N ) connections are multiplexed on onesingle (N - ) connection.

3) Splitting (referred to as "downwardmultiplexing" in[ 7 ] ) where one single (N) connection is built on top ofeveral(N - 1 ) connection, the traffic on th e (N) connection beingdivided between thevarious (N - 1 ) connections.These three types of correspondence between connectionsin adjacent layers are illustrated in ig. 9 .C.Data Transfer

Inform ation is transferred n various types of dataunitsbetween eer ntities nd etween ntities ttached to aspecific service access poin t. The da ta units ar e defined belowand the interrelatio nship among several of them is illustratedin Fig. 10.(N ) Protocol Control Information is informatio n exchangedbetween wo (N) entities, using an (N - 1 ) connection, tocoordinate their joint operation.(N ) UserData is thedata ransferredbetween wo (N )entities on behalf of the (N + 1) entit ies for whom the (N )entities areproviding services.An (N ) Protocol Data Unit is a unit of data w hich contains(N ) ProtocolControlnform ation nd possibly (N ) UserData.

(N) nterface Control Information is information exchangedbetween an (N + 1 ) entity and an (N ) ent i ty o coordinatetheir joint operation.(N ) Interface Data is informationransferred rom n(N + 1 ) entity to a n (N) entity or transmission to a cor-respondent (N + 1 ) entity over an (N ) connection, or con-

versely, inform ation ransfe rred rom an (N ) entity to an(N + 1 ) entitywhichha sbee n received over an (N ) con-nection from a correspondent (N+ 1) entity.(N ) Interface Data Unit is the unit of information transfer-red across the service access point between an (N + 1 ) entityan dan (N ) entity in a single interaction.The size of (w

MultiplexingplittingFig. 9. Correspondencebetween onnect ions .

Icon ro n a t a Combined

t

L I I 1Fig. 10. Interrelationshipbetween data units.

interface data units is not necessarily the same at each end o fthe connect ion.(N - 1 ) Service Data Unit is the ' amount of (N - 1 ) inter-face data whose identity is preserved fromon een dofan(N - 1) connection to the other . Data may be he ld wi thin aconnection until a complete service data unit is put into theconnection.Expedited (N - 1) service datauni t is a small (N - 1)service dat a uni t whose transfer is expedited.The ( N - 1)layer ensure s that an ex pedited data u nit will not be deliveredafter any subsequent service data unit or expedited data unitsent on that connection. An expedited ( N - 1 ) service dataunit may also be referred to as an (N - 1) expedited dataunit .No t e : An (N ) protocol data unit may be mapped one-to-one onto an (N ) service data un it (see Fig. 1 1 ) .

V. MANAGEMENT ASPECTSEven tho ugh a nu mb er of resources are managed locally,

Le., w ithout involving coop eration betwe en distinct system s,some management functions do.Examples of such managem ent functions reconfiguration information,cold start/termination,monitoring,diagnostics,reconfiguration, etc.The OS1 Architecture considers managem ent functions as

applications of aspecific type. Management entities ocatedin the highest layer of the archite cture may use the comple teset of services offered to all applications in order to perform

8/3/2019 01094702_1

5/8

ZIMMERMANN: I S 0 MODELO RPE N 4 2 9

1ICI = P r n t o c o l - c n n t r o l - i n f ~ ~ ~ ~ t i ~ PD U = P r o t o c o l - d a t a - u n i tSDU = S c r v i c e - d a t a - u n i t

Fig. 11. Logical relationship between data units in adjacent layers.

management functions. Thisrganization of managementfunctionswithin he OS1 Architecture is illustrated in Fig.12 .

VI. THE SEVEN LAYERS OF THE OS1 ARCHITECTUREA . Justification of the Seven LayersI S 0 determined a numberof principles to be considered

for defining the specific set of layers in the OS1 architecture,and applied those principles to com e up with the seven layersof theOS1 Architecture.

Principles to be onsidered are as follows.1) Do not create so man y layers as to make difficult thesystem engineerin? task describing andntegrating theselayers.2) Create a bou ndary at a point w here the services descrip-tion can be small and the number of interactions across the

boun dary is minimized.3) Create separate ayers to handle func tions whicharemanifestlydifferent n he process perform edor he ech-nology involved.

4) Collect similar fun ctio ns into the ame layer.5) Select boundaries at a point wh c h past experience hasdemonstrated to be successful.6 ) Create a ayer of easily localized fun ctions so that thelayer c ould be totaly redesigned and its protocols changed inamajor way o ake advantages of new advances inarchi-tectural, hardware, or software echnology without changingthe services and interfaces with the adjacentayers.7) Create a boundary where it may beuseful at some pointin time to have the correspo nding interface standardized.8) Create a layer when there is a need for a differe nt levelof bstraction in the handling f data , e.g., morphology,synta x, semantics.

9) Enable changes of functions or p rotocols within a layerwithout affecting the otherayers.10) Create for each ayer interfaceswith tsupperan dlower layer only.11) Cre ate furthe r subgrouping and organization of func-tions to form sublayers within a layer in cases where d istinctcommunication services need it.12) Create , where needed , wo or more sublayers with a

Fig. 12 . A representation of management functions.common, ndhereforeminimum,unctionalityo allowinterface operation withadjacent layers.

13) Allow bypassing o f sublayers.B. SpecificLayers

The following is abrief explanationofhow he layerswere chosen.

1) It is essential that he arch itectu re perm its usage of arealistic variety o f physical media for nter con nec tionwithdifferentcontrolprocedu res (e.g., V.24,V.35,X.21,etc.).Application of principles 3 , 5, and 8 leads to identificationof a Physical Laye r as the lowest layer in the architecture.

2)Some physical comm unications media (e.g., telephon eline) require specific technique s to be used in order to trans-mit data betw een systems despite a relatively high error rate(i.e., anerror rate notacceptable or he great majorityofapplications). These specific technique s are used in data-linkcontrol procedures which have been studied and standardizedfor a nu mbe r of years. It mus t also be recognized th at newphysical communications media (e.g., fiberoptics) will re-quireifferentata-linkontr ol procedures. pplicationof principles 3, 5 , an d 8 leads to identificationof a Datalink Layer on top of the hysical Layer in the architecture .3) In heOpenSystemsArchitecture, somesystems willact as final destination of data. Some systems may act only sintermed iate nodes (forwarding d ata to o the r systems). Appli-cation of principles 3 , 5, and 7 leads to dentification of aNe m ork Lay er o n t o p f the Data ink Layer. Netw ork-oriente dprotocols such as routing, for example, will be grouped in thislayer. T hus, the Netw ork Layer will provide a conn ectio n p ath(network onnection)between a pair of ransportentities(see Fig. 13).4) Con trol of data transp ortation from source end systemto destination end system (which ne ed not be performed in

8/3/2019 01094702_1

6/8

IEEE TRANSACTIONS ON COMMUNICATIONS, VOL. COM -28, NO. 4, APRIL 1980

Fig. 1 3 . The seven layers OS1architecture.

intermediate nodes) is the last function o be perfo rmed inorder to provide the otality of he ransport service. Thus,the upper layer in the transport-service part of the architec-ture is the Transport La yer, s i t t ing on top of the Networkayer.This Transpo rt L ayer relieves higher layer entities from anyconcern with the transportation of data between them.5) Inorder obind/unbinddistrib uted activities into alogical relationship that ontro lshe ata exchange withrespect to synchronization ndtructure,he need for adedicated ayerha sbeen dentified. So the pplicationofprinciples 3 an d 4 leads to he es tabl ishment of hesess ionLayer which is on top of the Transpor tayer.6) The remaining set of general interest functions are thoserelated to representationndmanipulationftructureddata or hebenefitof pplication programs. Applicationof principles 3 an d 4 leads to identification of a PresentationLayer o n t o p o f t h eession Layer.

7) Finally, there are application s consisting of applicationprocesses whichperform nform ation processing. A porti onof heseapplication processes and heprotocolsbywhichthey omm unicate comprise the ApplicationLayer as thehighest layer of the a rchitecture.Th e resulting arch itectu re with seven layers, illustrated inFig. 13 obeysprinciples 1 an d 2 .A moredetaileddefinitionof each of he seven layersidentified above is given in the following ections, startingfrom the top with the application layer described in SectionVI-C1) down to th e physical layer described in Section VI-C7).C. Overview of he Seven Layers of he OSI Architecture

1) The Application Layer: This is the highest laye r in theOS1 Architectu re. Protoco ls of this layer directly erve the enduser by providing the distributed nformation service appro-priate toanapplication, to it smanagement,and to sys temmanagement. Management of Open Systems Interconnectioncomprises thoseunctions required to initiate,maintain,terminate,and record dataconcerning heestablishmentofconnect ions ordata ransferamongapplication processes.The other ayers exist only to support this layer.

An application is composed of cooperating applicationprocesses which ntercommunicate according to applicationlayer protoco ls. Applicatio n processes are the ultimate sourceand sink for data exchanged.A portion of an application process is manifested in theapplication layer as the xecu tionof pplicationprotocol(i.e., application entity). The rest of the application process

is considered beyo nd the scope of the present layered mod el.Applications orapplication processes may be of anykind(manual, computerized, industrial, or hysical).

2 ) The PresentationLayer: The purpose of the PresentationLayer is to provide the set of services which may be selectedby the Application Layer to enable it to interpret themeaningof the data exchanged. These services are for the managementof heentry exchange,display, andcontrol of structureddata.The resentation service is location-in depen dent nd isconsidered to be on to p of th e Session Layer which providesthe service of linking a pairof presentation entities.It is thro ugh the use of services provided by th e Presenta-tion Layer tha t applications nan OpenSystems ntercon-nection environment can com municate without unacceptablecosts n interface variability, transform ations,or applicationmodification.

3) The Session Layer: The purpo se o f th e Session Layer isto assist in the supp ort of the interactions between, coope ratingpresentation entities.Todo his, he Session Layerprovidesservices which are classified int o the ollowing two categories.

a) Binding two presentation entities into a relationshipan dunbind ing hem. This is called session administrationservice. b)Contro l f ata exchange, delimiting , nd yn-chronizing data operations between two presentation entities.This is called session dialogue service.

To mplem ent he transfer ofdatabetweenpresentationentities , the Session Layer may emp loy the services providedby the TransportLayer.

4) The Transport Layer: The Transport Layer exists to pro-vide a universal transp ort service in association with the und er-lying services provided b y lower layers.The Transpo rt Layer provides transparen t transfer of databetween session entities.TheTransp ort Layer relieves thesesession entities roman yconcernwith hedetailedway inwhich reliable and cost-effective transfer of data s achieved.TheTransport Layer is required to optimize he use ofavailable communications services to provide the performancerequired foreachconnectionbetween session entitiesat aminimum cost.

5 ) The Network Layer: The Network Layer provides func-tional ndprocedural means to exchange network servicedataunitsbetween wo ransport ntities over a networkconnection. It provides transport entities with ndependencefrom routing and witching considerations.

6 ) The Data Link Layer: he purpose of the Dataink Layeris to provide the functional and procedural meanso establish,maintain , and release data link s betw een n etwork entities.

7) The Physical Layer: The Physical Layer provides mech -anical, lectrical, function al, nd rocedu ral characteristicsto establish, ma intain , and release physical con nectio ns (e.g.,data circuits) between data link e ntities.VII. OS1 PROTOCOLS DEVELOPMENTS

The mod el of OS1 Arch tecture defines th e services pro-vided by each layer to the next higher layer, and offers con-

8/3/2019 01094702_1

7/8

ZIMMERMANN: IS 0 MODEL F O R OPENYSTEMSNTERCONNECTION 43 1cepts to be used to specify how ach layer erformstsspecific functions.Detailed functioning of each lay er is defined by th e proto -cols specific t o th e layer in the fra mewo rk of the Arch itecturemodel.

Most o f the initial effo rt within IS0 hasbeen placed onthe mod el of OSI. The next step consists of he definitionof standard protocols for each layer.This se ction contains a brief description of a likely initialse tofprotoco ls, corresponding to specific standard izationprojects recommended by SC16.

A . Protocols in the Physical LayerStandard s already exist within CCITT defining:1) interfaces with physical m edia for OSI, an d2) rotocolsor establishing, controlling , nd releasingSuch standards are described n other papers in this issueThe only wor k to be don e will consist of clearly relating

switched data circuits.[9 ] , [ l o] e .g. , X.21, V.24, V.35 , etc.those standards to theOS1 Architecture model.B, Protocols in the Data Link Layer

Standardprotocols or heData ink Layer have alreadybeen eveloped within ISO, which re escribedn otherpapers within this issue [111 , [121 .The most popular Data link Layer protocol is likely t o beHDLC [131 , witho ut ruling ou t the possibility of using alsoother character-oriented standards.Just as for he PhysicalLayer, the remaining work willconsistmainly o f clearlyelatinghese xisting standard st o t h eOS1 Architecture model.C. rotocols in the Netw orkLayer

An important basis for protocols n he network layer islevel 3 of he X.25 interface 14] defined by CCITT anddescribed in another paper in this issue. It will have to beenhanced n particular to permit nterconnection of privateand public networks.

Other ypesofprotocols areikely tobe tandardizedlater in this layer, and in particular, protocols correspondingto Datagram networks [101 .D. Protocols in the Transport Layer

No standard exists at present for this layer; a large amountof experience has been accum ulated in this area and severalproposals are available.The most widely kn own proposal is the T ransport P rotocol

proposedby FIPandknown as INWG 96 .1 15 ], whichcould serve as a basis for defining an internation al standard .E. Protocols fo r th e Session Layer

No standard exists andno proposal hasbeen urrently1 available, since in mostetworks, session function s wereoften considered as partof higher ayer function s uch asVirtual Terminal an d File Transfer.A standard Session Layer Prot ocol can easily be extractedfrom existing higher layer protoco ls.

F. Presentation Layer Pro tocolSo far, Virtual Terminal Prot ocols and part of Virtual Fileare considered. the most urgen t protocols to be developed inthe Presentation Layer.A num ber of VTPs are available (e.g., [161 , [17]) , many

of them being very similar, and it should be easy to derive aStandar d VTP from these proposals, also making use o f theIS 0 standardorExtendedControl Charactersor I/ OImaging Devices [181 . These protocols are reviewed inanother paper n this issue [19 1 .Th e situa tion is similar for File Transfer Protocols.G. Management Protocols

Most o f the work within IS0 has been done so far on th earchitecture of management function s,and very littleworkhas been done on management protocols themselves. There-fore, t is to o early to give indications on the likely esultsof the S0 work in this area.

VIII. CONCLUSIONThe development of OS1 Standards i s a very big challenge,

the result of which will impact all futurecomputercom-munication developments. If standards come too late or areinadequate, nterconnectionofheter oge neou s systems willnot bepossible o r will be very costly.

The wo rk collectively achieved so far by SC16membersis very promising, and additiona l efforts should be expen dedto capitalize on these initial results and com e up rapidly withthe most urgently nee ded set of standards which will supportinitial usage of OS1 (mainly erminals accessing services andfile transfers). Th e extset f tand ards, including OS1management and access to distributed ata, will have tofollow very soon .

Commontandards etween I S 0 and CCITT are alsoessential to th e success of stand ardiz ation , since new servicesannouncedby PTTs an dco mm on carriers are very similarto data processing services offered as comp uter manu facturerproducts,nduplication ofow compatibletandardscould simply cause the standardiz ation effort t o fail. In hisregard, acceptanceof he OS1 Reference Model by CCITTRapporteurs Group on Layered Architectureor PublicData Networks Services is most promising.It is essential that all partners in thistandardizationprocess expend their best effort so it will be successful, andth ebenefits can be shared by all users, man ufact urersofterminals and com pute rs, an d th e TTs/common carriers.

ACKNOWLEDGMENTThe OS1 Architectu re mod el briefly described in this paperresults from the work of more than 100 experts from manycountriesndnternation al organizations. Participation inthis collective work was really a fascinating experience for theauthorwho acknowledges the numerouscontributions fromSC16 member s which have been merged n the final version

of theOS1 Architectu rebriefly presented here.

8/3/2019 01094702_1

8/8

43 2 IEEE TRANSACTIONS ON COMM UNICATIONS,VOL. COM-28 , NO. 4 , AP RIL 1980

[31[41

[71

REFERENCESL. G . Roberts and B. D. Wessler, Computer network development toachieve resource sharing, in Proc. SJCC, 1970, pp. 543-549.L. Pouzin, Presentation and major design aspects of the CYCLADEScomputer network, in Proc. 3rdACM-IEEECommun. Symp . , Tampa,FL, Nov. 1973, pp. 80-87..J. H. McFayden, Systems network architecture: An overview, IBMSysr.J. . ,vol. 15 , no. I , pp. 4-23, 1976.G. E. Conant andS . Wecker, DNA, An Architecture for heterogeneouscomputernetworks, n Proc.. ICCC. Toronto, Ont., Canada,AI1976, pp. 618-625.H. Zimmermann, High level protocols standardization: Technical andpolitical issues, inProc. ICCC. Toronto, Ont ., Canada, Aug. 1976, p,373-376.ISO/TC97/SC16, Provisional model of open systems architecture,Doc. N34, Mar. 1978.ISO/TC97/SC 16, Reference model of open systemsnterconnection,Doc. N227, June 1979.H. Zimmermann and N. Naffah, On open systems architecture, nProc. ICCC, Kyoto, Japan, Sept. 1978, pp. 669-674.H. V.Bertine, Physical level protocols. this issue pp. 433-444.H. C. Folts, Procedures for circuit-switched service n synchronouspublic data networks, nd X.25 transaction-orientedeatures-Datagram and fast select, this issue, pp. 48%496.J . W. Conard, Character oriented data ink control protocols, hisissue, pp. 445-454.pp.455-467.D. E. Carlson, Bit-,oriented data link control procedures. this issue,ISO, High level data link control-elements of procedure, IS 4335,1977.

[141 CCITT, X25. OrangeBook, vol. VIII-2, 1977, pp. 7CIO8.[151 IFIP-WG 6. , Proposal for annternetwork nd-to-endransportprotocol, INWG Note 96. ; also, doc. ISO/TC97 SC161N24, 46 pp.,Mar. 1978.[161 IFIP-WG 6. , Proposal for a standard virtual terminal protocol. doc.ISO/TC97/SC16/N23,56 pp.. Feb. 1978.[I71 EURONET.Dataentryvirtual erminalprotocol for EURONET.VTP/D-Issue 4. doc. EEClWGSl165.[181 ISO, Extended control characters fo r 1/0 imaging devices, DP6429.

[I91 J. Day, Terminal protocols, this ssue, pp. 585-593.

Hubert Zimmermann receiveddegrees n engi-neering from Ecole Polytechnique. Paris, France, in1963, and from Ecole Nationale Superieure desele-communications, Paris, France, in 1966.

He s presently n charge of the computer com-munications group at IRIA,Rocquencourt, France.He was involved in development of command andcontrol systems before joining IRIA in 1972 to starttheCYCLADESproject with L. Pouzin.WithinCYCLADES, he was mainly responsible for designand implementationof host protocols.

Dr. Zimmermann s a memberof FIPWG 6.1 [InternationalNetworkWorking Group (INWG)]. He also chaired heProtocolSubgroupand co-authored severalroposals for internationalrotocols.Hesn activeparticipant in the development of standards for Open Systems Interconnection(0.51) within ISO, where hechairs the working group onOS1 architecture.