Bitzenbytes.com

Introduction

If you've been around networking for any amount of time and have encountered more than one kind of network, the theoretical OSI model is a leg up on being able to understand the similarities and differences between different network architectures. The OSI (Open Systems Interconnection) reference model is a basic foundation for people who are new to networking; for them, it is a fundamental structure on which to hang new concepts.  While this universally recognized model is an extremely important concept to bring to the understanding of networks and networking, it will teach you little about the nuts and bolts of actually networking.  HOWEVER, be forewarned that proceeding to the nuts and bolts section of networking without a firm grasp on this theoretical part will probably result in your making a lot of mistakes.  The model will teach you two very important things: a common terminology and organization of the material under discussion.

While most of this material is a generic explanation of the OSI Model, my known bias, towards anything called Ethernet, uh, and those others that go by the names Windows and TCP/IP, will probably show up in this document.  I'll try to keep it clear when they creep in, maybe.  You have been warned.

The ISO OSI model (circa 1983-1984) specifies a network protocol stack.  A protocol is a rule or agreed-upon method of transmitting data between two devices.  Protocols may determine:

• format or structure of data
• method of error checking
• method of data compression
• required control information
• method of indicating that a message is finished
• method of indicating that a message is received
• other required information

One mnemonic phrase used to remember the names of the layers in the OSI model is   "All People Seem To Need Data Processing."  That's seven words with seven leading letters to recall Application, Presentation, Session, Transmission, Network, Data Link, and Physical... ...the seven OSI layers in correct descending order.  There are so many protocols for network communications that were some organization and modularization not imposed on them, the resulting monolithic glut would be quite difficult to handle, alter, and maintain.   Protocols are delivered in layers as a guideline for modularization of the code that implements the protocols.  Be aware that often the classification of the layers is often imposed on the protocol after the protocol has been established.  The reality of where the protocol operates may not quite fit the model.

Pay attention to both the names of the layers in the OSI model protocol stack and the numbers of the layers along with their functions.   The industry often uses layer numbers as a shorthand method of describing function and may interchange that description with the name of a layer.  Routers, for instance, are considered to be "layer 3" network devices operating at the "Network layer".  While that statement expresses a concept in a redundant manner, the phrasing is accurate.

The OSI model is not a specification but is a generally descriptive model for a generic Network Architecture.  In fact, by imposition, it is a descriptive model for any Network Architecture.  By comparing a given network architecture to the model, we are able to describe and compare diverse Network Architectures that are fleshed out with real protocols and real implementations.  The model is a framework for discussion.  Without the model as a guide, chaos tends to reign.  The model is a good place to start when learning about something new to you, and be prepared to depart from it somewhat when you begin to acquire in-depth knowledge.  The people who build networks, while respectful of the need for organization and order, will depart from the rules to get the job done.

"The world is a jungle in general, and the networking game contributes many animals." - David C. Plummer, RFC 826.

The OSI model was created to meet some basic organizational and design requirements.  Each layer of the OSI model is designed so that it performs a well defined function where that function can be clearly exposed by a set of standardized protocols.   Layers are established to accommodate different levels of data abstraction.   Layers should be as small as possible for the elegance and ease-of-use delivered by simplicity, and should be large enough to accommodate the functional requirements of the layer.  Layer boundaries are established at points where a minimum flow of data must pass the boundary.   Boundaries are sometimes established by programming interfaces.
 

Comparison of IEEE Project 802 Model Layers with OSI Model Layers

The seven layers of the OSI model can be divided into upper layers and lower layers.   Simply put, however, layers in the OSI model are like links in a chain.  Break any of the links and network communications at some level will fail.  Each layer communicates, with layers above and below itself, through transfer of Service Data Units (SDU). SDU's are used to assemble packets.  A SDU is the unit of data that is exchanged between adjacent layers in a single system.  A Protocol Data Unit (PDU), on the other hand, is a unit of data exchanges between peer layers of a source host and a destination host.

Flow of Data in an OSI Protocol Stack

You write a letter so that someone can read it.  First, you create data and transcribe it to letter paper.  Next, you place the letter in an envelope and you put an address label on the envelope.  The envelope goes into a mail box.  The post man opens the mailbox and picks up the envelope and places it in a bundle; he labels the bundle with an SCF name.  Another post man places the bundle in a bag and labels the bag with a regional distribution center name.  Another postman places the bag in a truck and hads the driver a manifest with instructions to go to a national distribution point.   When the truck arrives, a postman looks at the labels on the bags and then takes the bags to other trucks headed for regional distribution centers.  Upon arrival, a postman takes the bag out of the truck.   Another post man takes the bundle out of the bag.  Another postman takes the envelope out of the bundle and puts it in a mail box.  Somebody takes the envelope out of the mail box and gives it to the recipient.  Finally, the recipient takes the letter out of the envelope and reads it.  The data (what you wrote in the letter)  was successively encapsulated in an envelope in a bundle in a bag in a truck. Even with all that handling, only you knew what the data in the letter was before the recipient got it, and then after the recipient got the letter, only you and the recipient knew about the data.  In spite of all those people handling the data, it was handled without anybody knowing what the content of the data was, and without most of them knowing what the final destination of the data was going to be.

In the process of making the data transfer, only you and the recipient handled the letter.  Every one else handled a container that held the letter.  Along the way there was one person at each end who handled the envelope.  And there was a different person at each end who handled the bundle.  And there was yet another person at each end who handled the bag.  Trucks with bags depart and arrive at post offices all day long.

For that analogy, each of the people handling the letter (data), however it may have been encapsulated, is like one of the layers in a protocol stack.  The sender and the receiver are like application programs--they are the only ones to see and use the data.   Each device used to encapsulate the data was labeled by somebody at the source end... ...so that people, at the destination end, would know what to do with the various containers received.  Once the data was encapsulated in each device, each device functioned like a PDU (Protocol Data Unit.)

Similarly, at each layer in a network protocol stack the data is encapsulated (RFC 894, RFC 1042) and labeled at the source.  At the destination, each layer in the network protocol stack will decapsulate the packet until the data is delivered.

Before transmission, at each layer, information is added to the data to form a packet.  For instance, an Application Header is added to the data at Application layer.  The combined header and data make a PDU (Protocol Data Unit) -- or is that SDU (Service Data Unit?)  I think the label depends on the context.  The Application layer PDU becomes the data (SDU?) for the Presentation layer while the Presentation layer PDU becomes the data for the Session layer.  Each layer is never concerned about the contents or internal format of the data that it receives from the layer above. 

After receipt by the destination, at each layer, the information, that was added at the source, is stripped away from the data.

At each layer, in the network protocol stack on the source system, the data is handled by the same protocol that will handle the data at the corresponding layer in the destination system.  Any given layer in a network protocol stack on the receiving end handles the data according to the information given in the header for that layer. This type of communication, among peer protocols, is called peer-to-peer communication.  At the physical layer, just about anything can happen to this datagram -- it can be combined with other datagrams into large packets before shipping over media, or it can be sliced into smaller packets before shipping over media, or the datagram can be formed in a manner that conforms to the size of the packet that will be formed at the physical layer.  This is inconsequential as long as the physical layer on the receiving end reconstitutes the datagrams in a way that allows them to be processed up through the protocol stack on the receiving end.

Remember that this is a discussion about theory.  While there have been efforts made to produce real working OSI protocols, the major use of the OSI protocol stack, that we call the OSI model, is to look at it in comparison to the network architecture and the associated protocols being used.  By making this comparison, we have a reference by which we can compare the data delivery systems in dissimilar network architectures. We also have learned an organization that will locate parts of the total process, for data delivery in any network architecture, without immediately requiring us to know the details of the other parts.  You should also understand that, in the real world, there is some disagreement about where the distinctions between layers should be drawn.  There is also some argument about where, at what layers, some protocols operate.  If this sounds a bit fuzzy to you, it is fuzzy.  Don't worry, be happy.  Anybody's list of protocols that operate at various layers is, um, more-or-less correct.

The only purpose for the table above is to show that there exists many protocols from many network architectures that can be viewed through the lens of the OSI model.  Take nothing more away from this table.

The effort to make real working OSI protocols was undertaken by the ISO.  Don't confuse these OSI working protocols with the model.  Few organizations even attempted to run them.  In the 1980's, the US government produced a standards document called GOSIP (Government Open Standards Interconnect Profile) and told its suppliers that their products had to comply with those standards.  This was supposed to make computer products sold to the government completely compatible and interchangable.  It never happened.

Layers

 
Application Layer – Layer 7 -  At the top level of the OSI model, in the application layer, communication with the network is initiated.  End User processes, commonly called End User Application Programs, operate above the OSI model Application Layer.  Users interact with an application program and the application program, in turn, interacts with an application service that runs at the application layer of the network protocol stack.  The end user application, using the Application Layer, may instruct the network to deliver data to an application running on another host.  The network, therefore, is a tool for an End User Application Program.  End User application programs, in general, don't function in the operation of the network.   Applications "invoke" the network.

In a way, you could say that there is another layer, above layer 7, that operates between layer 7 and the end user--but that is not part of the OSI model.

Application programs are only concerned that data, to be sent to the network, is transmitted, and that data, needed from the network, is received.  Services, at the Application Layer of the OSI model, provide the communication capability needed by End User Application programs.   Some of the services provided by the Application Layer include file transfer, file management, and message handling for electronic mail.   Programs operating at application layer include e-mail servers, e-mail clients, web servers, web browsers, ftp servers, ftp clients, telnet, SNMP (simple network management protocol), BBS (bulletin board systems), EDI (Electronic Data Interchange), finger, ping, etc.  Most of these programs work for the end-user both automatically and interactively. File services, Print services, Message services, Database services, and Application services are supported at the Application layer.

The Application Layer provides network transparency for user applications--that is, the use of the network does not require much effort on the part of the user, and the performance of the program does not seem to suffer for communicating with the network.

Presentation Layer – Layer 6 - The Presentation Layer provides the Application Layer with a familiar local representation of data independent of the format used on the network.  The Presentation Layer ensures messages, exchanged between two application processes, share the same semantic representation of the data (shared semantics).  Different systems format data in different ways.  Data compression techniques, encryption, alternate representations for security reasons, as well as different native methods of formatting data, require that communicating processes agree on how the data will be encoded.  ASCII, EBCIDC and UNICODE, for instance, are different methods of formatting similar data. The result of processing at Presentation Layer is that two different systems that use two different data formats can communicate by transforming the different data formats into one common transfer syntax.

The Presentation Layer communicates with the Application Layer above and the Session Layer below.  The Presentation Layer is responsible for data encryption, and compression, as well as unencryption and decompression.

Session Layer – Layer 5 - The Session Layer establishes, manages, and terminates sessions between computer systems.    A variety of protocols exist at the session layer, including Remote Procedure Calls (RPCs), the Network File System (NFS), SQL, and the AppleTalk Zone Information Protocol (ZIP).  Sockets operate at the Session Layer.  The Session Layer:

• Manages dialog control
  • Simplex
  • Half-duplex (tokens)
  • Full-duplex
• Detects and handles disconnectivity
  • Robust communications even with changes of end-point addresses
  • Synchronization (data checkpoints)

Transport Layer – Layer 4 -  The Transport Layer of the OSI model communicates with the Session Layer above and the Network Layer below.  For multitasking operating systems, the Transport layer ensures that packets are delivered to the correct application processes.  The Transport layer breaks up data into smaller units (message fragmentation and reassembly) if this is required to meet the specifications of the three layers below.  The Transport Layer provides both "reliable" and "unreliable" transport protocols.    Error detection and data recovery are employed to ensure that the packet sent by the application program on the source host is the same as the packet delivered to the destination host (end-to-end error detection and recovery.) 

Multitasking computers create a need for additional addressing.  Because several processes, that might communicate with the network at the same time, are running concurrently, the protocol stack must be able to identify which process gets which packet.   The OSI model assigns a SAP (service access point) to each communicating process.   The delivery of a packet depends on a physical address, a network address, and a SAP.  A SAP is an an address for a process and is equivalent to a port for TCP/IP.   For TCP/IP, the combination of an IP address and a port is called a socket--a socket is used to deliver a packet to a specific application process.  The availability of a SAP allows the Transport Layer to transmit data from several processes without waiting for any one process to complete communications before being able to transmit for another process.

The services provided by the Transport Layer to upper layer protocols are:

• Packet sequencing for fragmentation of data packets and remote reassembly
• Error Handling to ensure that the data transmitted arrives intact
• Positive or negative acknowledgement to ensure that data is retransmitted when needed
• Flow control to make sure that only as much data as can be handled by the receiving device will be transmitted
• Multiplexing control to combine data from several sources for transmission over one data path
• Creation of virtual circuits to establish sessons between communicating end nodes.

Network Layer – Layer 3 - The Network Layer of the OSI model communicates with the Transport Layer above, and with the Data-Link Layer below.  Unlike the Data-link Layer, the Network Layer does not care about point-to-point physical communication--does not care about direct physical communication between hosts on any one physical network.  The Network Layer makes sure that packets get delivered across an organized internet.  The Network Layer ensures that packets get from the source network to the destination network.

Router operate at the Network Layer.  Networks in an internet are connected by routers; it is the responsibility of the routers to ensure that a packet is delivered from the source host on a source network to a destination host on a destination network.

The Network Layer is responsible for two key functions – logical addressing and routing.  For TCP/IP networks, the Network Layer provides the source IP address and the destination IP address.  Other network architectures or protocol suites may have their own method of addressing.

The Network Layer:

• Routes packets across an internetwork.
• Defines and uses Logical Network Addressing
• Establishes and releases connections and paths between two networks
• Transfers data for other computers
• Generates and Confirms receipts
• Supplies connection-oriented and connectionless services for the Transport Layer

The Network Layer does not concern itself with reliability of the data transfer, because that’s the responsibility of the Transport layer.  It is the responsibility of the Network Layer to know where the packet is going and how it is going to get there.

Data Link Layer – Layer 2 - The Data Link Layer of the OSI Model communicates with the Network Layer above, and with the Physical Layer below, and provides for reliable transmission of data across a point-to-point or multipoint physical data link.  In other words, the Data-link Layer provides the mechanism for delivering a packet from one host to another host on a single physical network.  As far as the Data-link Layer is concerned, it KNOWS where the final destination is because it will be in direct contact with that final destination.  The Data-link Layer doesn't do the transmitting and receiving; It provides for reliable transmission.  Simply speaking, it delivers, uh, message units between network devices (nodes.)  You can start calling message units, uh, datagrams, uh packets, uh...  ...you can call them frames at this level.

Bridges and Switches operate at the Data Link Layer of the network because they deliver packets based on the MAC address included by the Data-link layer in every packet.

The data link layer provides for reliable transmission by segmenting upper layer datagrams (aka packets) into frames that are sized according to the requirements of the communications hardware.  It orders the bits in the Network Layer PDU in a frame so that the frame can be reliably transmitted at the Physical Layer.  Essentially, the Data-link Layer creates a bit stream. 

The Data-link layer takes care of physical addressing, accomodation of the network topology, physical link management, error notification, delimiting frames, sequencing of frames, the ordered delivery of frames, and flow control.

If your network runs Ethernet, then the Data-link Layer will format the data according to Ethernet Protocol specifications, and will follow the rules of Ethernet transmission on the network.  It is not guaranteed that this layer will not change during the transmission of the data over an internet.  Movement of the data from Ethernet to Token Ring to FDDI to ATM and back to Token Ring might occur.  However, the same peer functions will be performed at this layer.  The process of getting across those networks might involve a number of Data Link layer changes to the packet.

The Data Link layer, for Ethernet (Project 802), is made up of two sub-layers: LLC and MAC.  The LLC (Logical Link Control) layer identifies and interacts with the upper-level Layer 3 (Network Layer) protocol being used. The MAC (Media Access Control) layer controls access to the physical network media.  ...and obviously, there is communication between these two sub-layers.

The Logical Link Control (LLC) layer (IEEE 802.2) provides type 1 (connectionless) and type 2 (connection-oriented) data links.  It uses the MAC layer to deliver these two types of services to the physical layer.

• Type 1 services, aka LLC1 services, are services that are used when no error detection or flow control is needed.  These are generally very small packets that go one way.  The system doesn't really care if they are received or not.  No reliability is intended or needed.
• Type 2 services, aka LLC2 services, aka balanced-mode connection-oriented services, require error detection and data recovery capability.

LLC services come in two classes:

• Class 1 services are connectionless services that do not supply error detection or flow control.
• Class 2 services can be either type 1 or type 2 data transfer services.   The LLC provides error detection, data recovery, flow control, and resequencing services required for connection-oriented data transfer.

The LLC interface allows applications to use multiple adapters by requiring that an adapter number be supplied when commands are issued to the protocol by the application.   The binding of LLC adapter numbers to logical boards can be either implicit (default) or explicit (configured by the user.) 

ODI (Open Data-Link Interface - Novell, Apple - ) or NDIS (Network Device Interface Specification - Microsoft, 3COM - 1988) drivers live at LLC layer, and provide a common programming interface between MAC drivers and "transport" drivers.  While ODI and NDIS provide similar functions, ODI has been mostly replaced by NDIS.   Prior to ODI and NDIS standards, systems manufacturers often supplied NICs that would only work with their systems and would only work with the protocol stack supplied by them.  One monolithic driver might implement all layers of the protocol stack and disallowed multiple protocol stacks bound to a single NIC.  NDIS was developed so that vendors of network transport protocol implementations could interface to a standard API implemented by a driver supplied by the NIC Mfg. 

NDIS (and ODI) provides some notable benefits:

1. You can bind multiple protocol stacks to a network card
2. Programmers don't need to the details of interfacing to the MAC layer
3. You get a bigger choice of NICs from more Mfg.'s that you can use

Novell's ODI protocol stack loaded modular drivers at each layer, any of which could be replaced by a substitute depending on the hardware interface and the protocol stack to be loaded. The drivers were:

• Network interface card (NIC) drivers (MLIDs or Multiple Link Interface Drivers) were implemented with a hardware specific driver, e.g., NE2000.EXE for an NE2000 NIC, and loaded at the MAC Layer.
• The ODI Link Support Layer driver implemented by LSL.EXE, and loaded at LLC Logical Link Control Layer.
• Programs that loaded a specific network transport protocol such as either IPX/SPX or TCP/IP loaded at Network Layer and above.

One of the indications that ODI forms the foundation for the modular stack at the Logical Link Control Layer is that the ODI LSL driver was loaded first, followed by MLIDs, and then followed by specific network transport protocols.

 

The Media Access Control (MAC) layer uses a media access control method (CSMA/CD for Ethernet) to provide service for the LLC layer.   The MAC driver is the bottom software layer in the stack and MAC lyer is the lower sub-layer of the Data-link Layer in the OSI model.  This layer also provides the MAC address of the node for use in communication.

 

Loopback - To the Network Layer, the Loopback interface appears to be just another link layer.  This is useful for testing or for when client processes use the TCP/IP interface to communicate with server processes on the same machine.  The standard loopback IP address is 127.0.0.1 and the standard loopback host name is "localhost".

Physical Layer – Layer 1 - The physical layer of the OSI Model is implemented in hardware and communicates with the Data Link Layer above and the media below.   This layer is responsible for transmission and receipt of data.  

The Physical Layer receives a bit stream from the Data-link layer in the form of a completely formatted frame.  The Physical Layer is responsible for bit synchronization and the clear identification of a single bit element as being a 1 or a zero.  At the source, the physical layer receives the bit stream from the data link layer, electrically encodes the data, and transmits the encoded signal on the medium.  At the destination, the physical layer receives the encoded signal from the medium, decodes the electrical signal into bits, and sends a bit stream to the data link layer.

The physical and electrical characterisitics of the network are defined at this layer.  The Physical Layer is concerned with characteristics like voltage, wave formation, bit time, where what signal goes for a divided medium, whether communication is simplex, duplex, or full duplex, and similar stuff.

Repeaters and hubs operate at the physical layer of the network.  The Ethernet Protocol is used at this layer, or another physical interface might be used, such as Token Ring (also defined by the IEEE.)

The Layer below the Physical Layer

What follows, regarding the Physical Layer or Not-the-Physical Layer, is just conversation.  You won't gain much from reading it, and I've included it only because I've experienced some frustration with making clear distinctions (...and no less with getting other people to make clear distinctions...)  about what the OSI model includes when it comes to the Physical Layer.   This warning is advice that you can safely skip down to the DoD Model heading in this document, without any loss of knowledge.   No, really, there's nothing in this section worth reading.

I've had some argument, with various people, over whether media is covered by the physical layer or not, and I haven't done the research for this paper to say whether it is or not.  I can find lots of non-canonical, but seemingly respectable, references that will tell me whatever it is that I want to hear. 

The difference in opinions seems to lie in whether or not the physical layer of the OSI model discusses more than a theoretical abstraction of the data.  Maybe.  I don't even know what I mean by that.  One would think, though, regarding theoretical abstraction, uh, NOT.  I don't know what I mean by that.  That doesn't mean that people don't talk a lot about the stuff that the Physical Layer covers.  There's a lot of that, but the OSI model is never mentioned in those conversations even though the concept of a Physical Layer seems to indicate that the OSI model is being invoked.

In reading various sources, however, it seems clear that the physical layer for a specific real network architecture receives data from the Data Link Layer (or equivalent) and transmits that data over media.  At the other end, the physical layer will receive data from the media and pass it up to the Data Link Layer.

Meanwhile, discussion of the media itself seems to be randomly included or left out of real network architecture physical layer discussions.  That is, in conversation about media, there's rarely mention that the content of the conversation is about a physical layer.   However, in the process of talking about such a physical layer, it seems that electrical properties and characteristics are defined...  ...covering things like frequency, amplitude, phase, and modulation that are to be controlled at the physical layer.   These, of course, can't be specified in the absence of specifications for the media.  Hence, my confusion.  Because of this, most of the people, who I talk to, consider the specification for the media to be part of the physical layer whether that's really true or not.   Without prejudicing the discussion here, I've heard both opinions from people, er, maybe even the same people.

I guess it's possible that the media could be left out of the authority and responsibility of the physical layer because with the aid of other network devices, such as bridges, the media for the sending and receiving stations may be different.  In other words, the peer relationship that seems to clearly exist between the same layers for the other six layers, is not so clear at the physical layer.  If the media is the same between the two physical layers, there is probably some argument for a peer relationship.  If it changes, maybe not.  Not until, that is, the Data Link PDU is extracted and passed to that layer.  Well, maybe not until the LLC.  Ok, The model specifies a clear peer relationship between the upper 5 layers.  I think.   No wait, it's the model, not the real thing--the model does specify a peer relationship between all the layers.  Doesn't it?

For practical purposes, it seems that discussion of the physical layer should include the transmission media as well as the characteristics of the signal used to send encoded bits over the network from source to destination.  For the physical layer in a real network architecture, wiring, connectors, signalling method, voltage levels, media distance limitations, and much more are described.  While the transmission method may vary from source to destination, the data remains unchanged.

Some people get around this confusion, by specifying yet another not-in-the-OSI-model layer under the physical layer, The Layer-below-the-Physical Layer, which they call the "physical link" or the "Media Layer" or "the cable."   The last of those is the easiest to argue with just by including wireless transmission, but the argument on that basis would be missing the point, which is non-inclusion of something required in the last layer specified in the model. 

Then, other people may join the discussion, about physical layer protocols and cable, and never clearly make a distinction about what belongs where in what layer.  They are either wisely, ignorantly, fearfully, or benignly avoiding making the distinction.  In fact, protocols like Ethernet Protocol, Fast Ethernet Protocol, Gigabit Ethernet Protocol, ATM, and RS-232 each have physical layer components.  I think that's about the best description I'm gonna get.

I guess the ISO could tell me.  Someday I'm gonna do the research.   Meanwhile, while you are building your home network, you can argue with yourself about it.

Or become an engineer.  Engineers talk about dividing the physical layer into the Physical Coding sub-layer, the Physical Medium Attachment sub-layer, the Physical Medium Dependent sub-layer, and the Medium Dependent Interface (MDI).  But these layers don't exist for all protocols, and for instance, for 10 Mbps Ethernet, the data is handed off directly to the Physical Medium Attachment and thence to the wire.  Well, just about.

But for home networkers, my advice is: plug in the cables, and just mumble a little for the benefit of the audience.

DoD Model (AKA Internet Model - 1974)

The Model followed for the TCP/IP suite of network protocols is the DoD model.  A look at the diagrams below may serve as some orientation.