There are a couple of “models”, which categorize network communication as belong to a specific “layer”. The more commonly referenced model is the “OSI Model”.

The OSI Model is commonly reference by network technicians who may make a reference to something like “layer two” network traffic. Really, the only layers that most network technicians care much about are the bottom four layers: Simply knowing the names (and orders) of the higher layers is generally sufficient for passing industry certification examinations. (Such examinations might often not ask for other details on the upper layers.) The distinctions between the upper layers may be of more interest to computer programmers who need to make sure that such functionality is properly implemented.

Knowing the distinctions between the lower four layers is rather critical to understanding how different addresses are handled. For instance, a “switch” is listed as a “Layer 2” device, and switches do use the “Layer 2” information (MAC-48 addresses). A switch does not really do any special processing related to a UDP port number, which is no surprise since a UDP port number is considered to be “Layer 4” information.

So, learning the values of these charts can help people to rapidly gain some familiarity with how certain equipment operates with certain data.

Note: A lot of this information was created simply from using some knowledge about how certain technologies work. (Some of this knowledge may have originated from when the author had received a formal college education related to computer networking.) The names of the OSI Model layers, and their orders, are clearly recognized and so should not be disputed. Some of the rest of this content may be debated/disagreed by some experienced industry experts. It is the opinion of the author of this text that this information is mostly accurate, and helpful. However, as a broad example, some people may be able to provide intelligently arguable reasoning on why a specific protocol or piece of hardware may often have qualities to classify the device at a different layer. Much of the rest of this list is not anywhere close to being an officially-recognized, standardized list. Regardless of the non-official (and, in some cases, possibly logically debatable) status of some of this information, these details are likely to generally be good and useful. Becoming familiar with the contents on this page is likely to help provide some useful understandings of many helpful details.

Layer by layer communication theory

There is a theory that each layer may be implemented by different pieces of software, and the software that implements each individual layer should be able to perform the task without needing to communicate to any of the other layers except for adjacent layers. So, Layer 3 should only need to communicate with Layer 4 and the LLC sublayer of Layer 2. There should be no need for Layer 4 to directly communicate with Layer 2 at all.

Well, that's the theory anyway. In practice, the actual separation of layers is not necessarily strictly adhered to. Doing so simply does not optimize things well. Especially the Presentation layer is typically implemented within the Layer 7 software. And the layer 7 software typically has some understanding of what network addresses may look like (which should, ideally, be a Layer 3 issue). Most network stacks may come with a “TCP/IP” implementation that really implements both Layer 3 and Layer 4 with the same software. So, people should not start to think that these layers are implemented separately. The reasons for all this non-adherence may often have to do with perceived simplicity/easy/quickness of software design, or some optimizations (such as speed in processing).

Reality of layering

The way things are actually implemented may be a bit closer to another widely-used model, which is named “the TCP/IP model”. That model has fewer layers, combining OSI layers 5 through 7 into a single layer named &ldqou;Application”. And, in reality, it is probably true that most software programs (also called software “applications”) handle all that functionality. However, even if the “TCP/IP model” reflects some common programming practices, the functionality provided by each of the OSI Model layers is functionality that needs to be addressed. If Layer 6 is completely ignored and computers are using different standards, communication does not work. Therefore, there may still be a point in studying each of these individual layers. Especially splitting up the four lower layers: even if the network stacks built into computer operating systems might combine some of those layers, a lot of existing hardware can be clearly identified as working primarily at the Layer 3 level of the OSI Model, and not at the Layer 4 level of that model, so learning those layers is especially useful (even to be able to better understand documentation related to software that combines the functionality).

Advantages of the layering

When wireless started becoming much more widespread, the IPv4 implementations and all higher layers really required no changes at all. When IPv4 exhaustion started necessitating the use of IPv6, the physical sublayer needed absolutely no changes, TCP was perfectly usable exactly as it had been implemented, and so applications utilizing TCP required very little changes. (If they used DNS, no changes at all might have actually worked. Otherwise, in many cases all that was needed were some slight changes in understanding the format of an IP address's format.) The changes were able to be so painless because of the flexibility provided by the layering.

(From an experienced computer programmer's perspective, these examples are simply instances of the benefits of “modularity”.)

Layer names: OSI Model and TCP/IP Model

There are two main models of communications layers that are often taught.

Comparing the models

The OSI Model and TCP/IP Model do, in practice (even if not in theory), correspond to each other at the Transport layer, and somewhat at the next lower layer.

There is some objection to the idea: Wikipedia's article for “Internet protocol suite”: 6:33 10 June 2010 revision states, “The IETF makes no effort to follow the OSI model although RFCs sometimes refer to it.” Wikipedia's article for “Internet protocol suite”: 23:31 18 Nov 2007 revision notes that attempts to relate the models come from “secondary sources that contravene the intent of RFC1122 and other IETF primary sources. The IETF has repeatedly stated that Internet protocol and architecture development is not intended to be OSI-compliant.” (Hyperlink added to quoted text.)

However, despite these objections, some of the general/broad purposes intended by various layers do have enough similarities that making such comparisions can make memorization of the TCP/IP model easier. For people who are learning the terminology as a study of basic networking, having this comparison can make things easier.

The TCP/IP Model might be defined by RFC 1122: “Requirements for Internet Hosts -- Communication Layers”. RFC 3439 (“Some Internet Architectural Guidelines and Philosophy) section 3: “Layering Considered Harmful” points out that strictly handling tasks within a single layer may limit optimization opportunities.


Not only is there disagreement as to whether the TCP/IP model should be mapped to the OSI model, but there is even some inconsistency as to the names of at least some individual layers of the TCP/IP Model, and even how many layers there are. (Claims have been made of 5 layers, or 3 layers.) See: Wikipedia's article on “Internet protocol suite”: section called “Layer names and number of layers in the literature”. The names shown below are a rather general/rough consensus/summary.

Following is the list of layer numbers and layer names in the the OSI Model. Also included are some names for the TCP/IP Model, showing which layers of the OSI Model have quite a bit of functionality similar to what the TCP/IP Model layers provide.
OSI Layer Number OSI Layer Name TCP/IP Model Layer Name
7 (Seven) Application Application
6 (Six) Presentation
5 (Five) Session
4 (Four) Transport Transport
3 (Three) Network Internet
2 (Two) Data Link Network Interface/Access
1 (One) Physical
OSI Layer Number OSI Layer Name TCP/IP Model Layer Name

Further commentary

Layer two is sometimes shown a bit varied, such as “Data-Link” or “DataLink”. Wikipedia's article for “OSI Model”: “History section” states, “The OSI standards documents are available from the ITU-T as the X.200-series of recommendations.” Then, Wikipedia's article for “OSI Model” “External links” section states that ITU-T X.200 are “the same contents as from ISO”, and refers to ITU-T X.200 (PDF file format), which identifies this as “Data Link”.

What is accomplished at each layer
OSI Layer Num OSI Layer Name Benefit/Purpose Method/Approach of achieving benefit
7 (Seven) Application Everything / Application(s) Software that uses networking, but also typically performs a substantial task beyond just communicating with other network-aware devices. Interacts with humans or, in some other fashion, the world.
6 (Six) Application Mutual Understanding/Agreement Negotiate to ensure common methods to interpret data
5 (Five) Session Session Create a connection, and keep track of it. This reduces the need to re-negotiate communication parameters as more data keeps getting sent. Can help with providing benefits such as TCP's sequencing and reliability features.
4 (Four) Transport Conversations
Have (network data) traffic identified, so recipient knows its purpose
3 (Three) Network Logical addressing. This often also permits routing, which allows WANs Assign logical addresses. This can make routing much more feasible, and has enabled humanity to make more complex networks including the Internet.
2 (Two) Data Link Create LANs with individually addressable computers Identify individual machines with unique addresses (such as a network card's physical address)
1 (One) Physical Connectivity, ability to communicate Provides physical connectivity. Enables some form of communication (even if very basic).
OSI Layer Num OSI Layer Name Benefit/Purpose Method/Approach of achieving benefit
Numbers used at each layer
OSI Layer Num OSI Layer Name Communicated Numbers/Values How this is implemented (e.g. actual identifiers) Actual example implementations of numbers Protocol Data Unit (PDU)
7 (Seven) Application All kinds, nothing standardized (Data)
6 (Six) Application Examples: keys, code pages, negotiated options

Ensuring that devices have a mutual understanding of the data format, so that data is interpreted the same way. For example:

Code pages, encryption, and compression

Code pages
A DSA key
5 (Five) Session None. A network stack (bunch of networking software, bundled in as part of modern popular operating systems) may create a “socket”. So that may be a number related to the Session Layer, although that is generally internal and not communicated across the network. The specifics about sockets vary by local implementation. e.g., many operating systems use what is called a UNIX socket. Often such a socket contains an IP address and port number. Something like: (Connection)
4 (Four) Transport Port numbers The Layer 4 protocol uses “port numbers” to identify conversations. This way, incoming data can be identified, in order to determine what program the data is meant for.
  • TCP port 443 (represents HTTPS)
  • TCP port 80 (represents HTTP)
  • TCP port 25 (represents (E)SMTP)
  • UDP port 57 (represents DNS)
TCP segments
and (for other protocols) datagrams
3 (Three) Network Logical addresses IPv6 address, IPv4 address, IPX address fd00::1 (an IPv6 address) (an IPv4 address)
2 (Two) Data Link Physical addresses MAC-48 0E-12-34-56-78-90 or 0E:12:34:56:78:90 or 0e12.3456.7890 or 0E1234567890 Frames
1 (One) Physical Voltage levels (Electricity) Logical bits.
(Measurements of physical electric signals.)
A bit can be 0 or 1 Bit
OSI Layer Num OSI Layer Name Communicated Numbers/Values How this is implemented (e.g. actual identifiers) Actual example implementations of numbers Protocol Data Unit (PDU)


Things negotiated at the Layer 6 level
What is negotiated Why How this may be implemented
Code pages When computers transmit numbers, those numbers are often converted to letters or other text symbols. They do this by using an agreed-upon chart. If computers are using different charts, they will need to convert. Some example code pages are: ASCII, Unicode, EBCDIC, Code Page 437, UTF-8
Encryption The methods of encrypting/decrypting, as well as any secret information (such as keys), need to match. Otherwise, the communication will likely lack any useful meaning. DSA keys or RSA keys (may be thousands of characters long)
Compression Data can often be compressed. However, both sides need to be using matching compression(/decompression) methods. Otherwise, the compressed data transmitted will not be understandable. Protocols may often assign a standard number to known compression algorithms. That number may be transmitted to acknowledge support for a certain compression method.
PDU names

The term PDU stands for “Protocol Data Unit”.


Generally a Layer 4 PDU is called a “datagram” (especially with UDP), although with TCP this is usually more properly referred to as a “segment”. However, even RFC 793: TCP regularly calls them datagrams (and also calls them segments). RFC 1122 (“Requirements for Internet Hosts - Communications Layers”) page 10 identifies communication on the “Internet Layer” as using a “datagram”, while they are more commonly called a “packet”. RFC 791: IPv4 (on page 14), in the section about TTL, even refers to TTL, refers to the Layer 3 PDU as a “datagram”. That usage is not consistent with this chart. So, these terms have definitely not been strictly adhered to.

Usage of the word “segment” for TCP is consistent with RFC 1122 (“Requirements for Internet Hosts - Communications Layers”) Page 17 (in Section 1.3.3: “Terminology”), and RFC 1180: “A TCP/IP Tutorial”, section 2.2: “Terminology”. The latter also identifies terminology of UDP datagrams, IP packets, and Ethernet frames.

PDUs of Layers 4, 5 and 6

This is a bit less defined/standardized than some of the others chart entries.

PDUs for Layer 6

The term “Streams” was decided for this chart. The logic used to come to that conclusion was: When this layer is working as intended, the end result of successful communication may often be that network data streams and files are successfully created on the receiving end.

PDUs for Layer 5

What was selected here is “Connection” The “Connection” doesn't get “transmitted”. However, the result of the layer is that (after any required negotiation/handshaking) the receiving computer has an active connection.

PDUs for Layer 4

This answer is a bit less “made up fiction” compared to the last couple of layers mentioned.

TCP PDUs can be referred to as segments. (Sometimes they may also be referred to as datagrams: the RFC 791: TCP specification actually uses both terms.) If just one term had to be selected, then “segment” may be most appropriate, perhaps because it is most unique. Typically, other protocols at this layer (most especially including UDP) use a PDU called a “datagram”.

Implementation Note: Layer 4

The chart shows “Port numbers”. Port numbers are commonly utilized for the purpose stated in the chart (identifying the type of traffic so the traffic handling can be determined).

This can, in theory (and in practice, to some extent) be done with the “Next Header” field of IPv6 or the “Protocol” field of IPv4. However, a TCP port number or a UDP port number ends up being a much more common implementation.

Software/Protocols and hardware used at each layer
OSI Layer Num OSI Layer Name Hardware Software/Protocols/Communication
7 (Seven) Application Many printers can connect to networks. The primary function and purpose that people think of, when they think about such a device, does not have to be to enhance the networking experience. Example: A paper scanner. Web browsers (including all sorts of browser plug-ins/add-ons), games, or anything else people use which uses networking
6 (Six) Application Specialized Encryption/Decyrption Devices Code pages, encryption software (e.g. VPN connectivity)
5 (Five) Session A device that handles connections? (A device designed to handle multiple dial-up modem connections? A VPN concentrator (although, if that handles encryption, it may be Layer 6)?) Telnet has been described as a sort of half-layer-5, half-layer-4 protocol.
4 (Four) Transport Traditional/simple firewalls often involve configuring rules based on port numbers. (So, dedicated/specialized firewall hardware may be classified at Layer 4.) The protocol that handles the most network traffic is TCP. UDP may be used more frequently (mostly due just to DNS). Another example is SCTP, and another is DCCP, and another is RSVP (Reservatin Protocol).
3 (Three) Network Routers. A “layer 3 switch” (or “multi-layer switch”)
IPv6, IPv4
IPX(/SPX), AppleTalk
2 (Two) Data Link
Switches send traffic out network ports based on the destination “physical address”
Ethernet, Wi-Fi
Token Ring, AppleTalk?
1 (One) Physical
  • Media (cables (e.g. copper or fiber-optic), airwaves (helps Wi-Fi and lungs), beams of light (e.g. infrared))
  • NICs (primary purpose is physical connectivity)
  • couplers (wire connectors)
  • repeaters/relays (like a coupler, but powered, amplifies signal)
  • A hub may often be considered to be a layer 1 device (as it essentially just relays the electrical signals, and does not benefit by attempting to effectively utilize any information from a MAC-48 addresses)
  • A hardware bridge is essentially a two-port hub.
CSMA/CD (Carrier Sense Multi(ple) Access: Collision Detection), CSMA/CA (Carrier Sense Multi(ple) Access: Collision Avoidance),
OSI Layer Num OSI Layer Name Hardware Software/Protocols/Communication


Firewall as layer 4

Some people like to classify a firewall as a Layer 7 device, because some firewalls have support for “deep packet inspection” and may make decisions based on information that is part of the Layer 7 payload. However, simple/traditional/basic firewalls, with simple firewall configurations, often support making decisions based on port numbers.

Data Link has sublayers

In the OSI Model, this is officially broken down into two sub-layers.

Logical Link Control

Interfaces with the next higher layer (Layer 3: Network Layer). For example, a driver that helps to communicate to the card, and provides the MAC address to the “operating system”/“TCP/IP network stack” may be the LLC portion of the Data Link layer.

Media Access Control

Interfaces with the next lower layer (Layer 1: Physical Layer). For instance, when Ethernet is mucking around with CSMA/CD and responding to a jamming signal, the Layer 2 Ethernet protocol is interacting with the lower layer.

Wikipedia's article for “Presentation layer”: section called “Sublayers” identifies two sublayers: the “common application service element” (“CASE”) and the “specific application service element” (“SASE”). However, (perhaps as a result of the whole Presentation Layer not being nearly as important), this is typically not considered to be a major objective, and is not typically covered to nearly the extent of Layer 2's sublayers. Layer 2's sublayers are more widely viewed as being important enough that they are more likely to be covered by a knowledge examination.
Large Chart

This has been moved: see: OSI Model Chart.