Framing The Discussion
Every class on earth in data communications networking begins approximately the same way -- some formalityies are discussed, and then the discussion is framed in terms of a reference model. This class is surely no different. So, let's start there.
What is a reference model? Well, a model is a framework for understanding something that includes the essential characteristics, while neglecting the characteristics that are not relevant for the intended purpose. A reference is something that is designed to be considered studied, and/or available for continued use. So, a reference model is a framework for understanding something that includes the essential characteristics, is designed to be studied, considered, and/or available for continued use. This is, of course, to be constrasted, for example, from a design or implentation model. This model is just a "reference" model -- something to cite in framing discussions.
The reference models that we'll introduce today will give us a framework for understanding the structure of computer networks -- a framework that we'll keep coming back to. In particular, we'll talk about the ISO-OSI reference model, and the TCP/IP Reference Model.
The OSI-ISO and TCP/IP Reference Models
The TCP/IP Reference Model and the OSI-ISO Reference Model each view the network as consisting of layers, with the lowest layers representing network functions more closely related to hardware, and with the highest layers representing network functions closer to the end-user. The OSI-ISO model has seven (7) layers, each of which is fairly strictly defined. The TCP/IP model contains only five layers, wrapping the top three of the OSI/ISO model into one -- and, the TCP/IP world doesn't take the layering too strictly or define it too tightly. It is, instead, viewed as more of a framework for casual conversation than detailed specification.
Let's take a look at the models, and then take a quick look at each layer:
OSI-ISO Reference Model Layer 7: Application Layer 6: Representation Layer 5: Session Layer 4: Transport Layer 3: Network Layer 2: Link Layer 1: Physical
TCP/IP Reference Model Application Transport Network Link Physical
Notice that the TCP/IP model parallels the OSI-OSI model, except near the top. There the TCP/IP model wraps the top three layers of the OSI/ISO model into one layer. Additionally, it is also important to remember that, althought the OSI-ISO model is carefully specified -- part of the TCP/IP model is that the model is flexible and only loosely defined.
The Physical LayerIn order to communicate, we need to have some shared physical medium by which to do it, and some technique for generating observable signals within it. These are the issues at the heart of the physical layer The phsyical layer describes the hardware and its most fundamental function. The following are the types of concerns specified by physical layer specfications, e.g. protocols:
- What are the characteristics of the media? E.g. What type of fiber or copper? For example, imagine desribing Cat-5e, including the compositon of the wires, sheathing, and connectors.
- How does one generate an observable signal on this media? E.g. Is it a particular color of light? Or a particular electrical pulse?
- How long can the channel be?
The Link LayerOnce we have the ability to generate an observable signal, we have more work to do before that can form successful communication. For example, imagine that we have established a room for a conversation, complete with chairs and microphones. This is great -- but it won't work if we all talk on top of each other, or have no way of distinguishing who is who within the room. We need rules for sharing the air. We need names for identifying each other.
In the context of data communication networks, we need to break messages or streams of data into manageable pieces so that, for example, so we can add error-detection codes to them and, possibly, enable them to be resent in the event of a failure. We need station IDs, such as MAC addresses, so we can identify each other. We need a way of assembling all of these pieces, so everyone can recognize the parts. We need rules about who can transmit, when, and for how long. Depending upon our goals, we may want, also, to have some rules about how much can be sent and when, to avoid having senders send faser than receivers can receive. These are some typical concerns of the link layer. Ethernet, for example, is a commonly discussed link-layer protocol.
Network LayerOnce we have established physical and link layer protocols, communication is possible among those stations that share the common medium. But, not all stations may share the same media. We may want different mediums for different reasons. For example, Wi-Fi, 4G LTE, wired, and satellite communications solve different problems. And, at a certain point, a single channel may just not be able to accomodate more stattions. The end result is that we need to tie local netowrks together to form bigger ones.
Once this happens, we can end up with a graph representign a collection of heterogeneous networks -- and our goal is to be able to communicate from Point-A to Point-B on this graph. This means that we need a global scheme of addressing. And,w e need a way of navigating this graph. We may also want to manage some of the performance consequences of large-scale networks, e.g. manage quality of service. These are typical concerns of the network layer.
Transport LaterIn writing network software, we need not only to get a message from one machine to another machine -- but we need to get a message from one program to another program. And, we need to do this in a way that is convenient to the programmer.
The transport layer is responsible for establishing software visible endpointsm, e.g.
tuples.These endpoints allow applications to communicate in a way that is convenient for the programmer, regardless of the underlying machinery. So, for example, some protocols provide for reliable communication, e.g. TCP, whereas others do not attempt to resend seemingly lost messages, e.g. UDP. Similarly, TCP provides a stream-based model, whereas UDP provides a message (datagram) -based model. The management of congestion, flow control, etc, might also be concerns within the transport layer.
It is important to note that the link layer and transport layer can have similar concerns, because they each provide for end-to-end communication. The transport layer, in some sense, re-establishes end-to-end communication after the network layer provided the large-scale connectivity, and, in the process, can refine or redefine the end-to-end model.
Session LayerThe OSI-ISO model defines a session later that is, essentially, a refined and full-service version of the transport layer. The TCP model doesn't really include this explicitly -- so the functionality is lumped into the appliction layer (see below).
This layer involves making transport-layer connections pretty. It can include things like checkpointing and recovery, in the event they get broken, as well as the perhaps complex set-up, maintenance, and clean-up that result from such functionality.
Presentation LayerThe presentation layer is another layer that is modeled in the OSI-ISO system, but not the TCP/IP way of thinking. It is intended to provide a way of mapping data from the local formats of one system to another to provide a level of system-independence. For example, it might map between ASCII and EBCDIC, or 8-bit binary and 7-bit ASCII, or encrypt and decrypt, etc.
Application LayerWhen the network is actually used to solve a problem, messages will be sent. These messages need to be known in advance -- or the receiver will have no idea what they are or what to do with them. An application layer protocol defines the messages that can be exchanged -- and any other functionality needed beyond whatever is provided by the layer beneath it.