mwg@petrus.UUCP (Mark Garrett) (04/17/86)
> > >Not true! Standard protocols exist for layers 4 and 5. Layers 6 and > > >7 have gone to DIS form (Draft International Standard) and are > > >supposed to go for 6 month ballot in June. There should be > > >International Standards at all 7 layers by the end of 1986.... > > >Doug McCallum Can someone clarify for me how layer 7 can be standardized without knowing the application? I think the difficulty in making higher layer protocols is that you can't optimize them for a variety of services. I'm working from a context of metropolitan area networks (basically grown from LANs) where one hopes to have integrated services (data, voice, video - the usual catch-words). You can't even run these all through the same MAC (physical/data-link) level never mind transport and session layers. What do these proposed layer 4-7 protocols do, and what kinds of traffic do they apply to? -Mark Garrett Bellcore
dougm@ico.UUCP (04/19/86)
> Can someone clarify for me how layer 7 can be standardized without > knowing the application? I think the difficulty in making higher > layer protocols is that you can't optimize them for a variety of > services. I'm working from a context of metropolitan area networks > (basically grown from LANs) where one hopes to have integrated > services (data, voice, video - the usual catch-words). You can't > even run these all through the same MAC (physical/data-link) level > never mind transport and session layers. > > What do these proposed layer 4-7 protocols do, and what kinds of traffic > do they apply to? > > -Mark Garrett > Bellcore There are "classes" of application that are known. For example, File Transfer and Access (FTAM), electronic messaging (X.400), etc. If you look at the function of each layer, you can see that it is possible to standardize a lot of the common functions that are supposed to be done at a particular layer. Session basically manages a transport session and de-multiplexes a transport connection a little further. (Transport gets you to a protocol and session gets you to the application) There is also the possibility of checkpointing a session to avoid having to restart at the beginning in the event of a transport failure. Presentation is supposed to manage data types between the two applications. ASN.1 (part of the presentation protocol) defines an encoding for data that is machine independent (perhaps in a more complex way than is necessary). Character sets, etc. are also handled at this layer. Application is supposed to define a set of common primitives for classes of applications. FTAM defines the protocol for accessing and manipulating files. CASE defines a set of Common Application Service Elements from which other application layer protocols can be built. Other application layer protocols in the works are a "virtual terminal" protocol for remote login and a "directory services" protocol for accessing a network directory. It isn't possible to define a standard for every application yet to be conceived, but it is possible to define them for the common classes of application. There will be a lot of vendor specific protocols providing services which aren't standardized. Some of these vendor specific protocols may eventually become the basis for new standards. With user groups such as the GM-MAP group, standards can gain acceptance and even convince some vendors to support the standards. As a disclaimer, I don't necessarily feel that the OSI standards are better than other network protocols, but it appears that they are gaining acceptance. A LOT of vendors have announced support and a relatively large number have shown implementations at such trade shows as NCC and Autofact. Hope this helps, Doug McCallum {cbosgd, hao, ima}!ico!dougm
mark@cbosgd.UUCP (Mark Horton) (04/24/86)
Sounds like we've got some experts out there who understand FTAM. Let me pose a question I've been wondering about for awhile. How does FTAM compare with network filesystems such as Sun's NFS, AT&T's RFS, and IBM PC type file service networks? Is FTAM a suitable replacement for these systems, or does it do the same thing, just not as well, or is it strictly an FTP replacement? Does anyone care to predict the evolution of remote filesystems as OSI becomes pervasive? Mark