For today’s post, we’ll look at the OSI framework and its 7 layers. This is exciting stuff, at least when it comes to how you document […]

The 7 Layer Guide to Network Documentation

For today’s post, we’ll look at the OSI framework and its 7 layers. This is exciting stuff, at least when it comes to how you document […]


For today’s post, we’ll look at the OSI framework and its 7 layers. This is exciting stuff, at least when it comes to how you document the network, so hold on to your seats…

What is the OSI?

The Open Systems Interconnection (OSI) was created by The International Organization for Standardization (ISO) as a framework for standardizing the communication between two endpoints in a network. In a nutshell, OSI divides the process of communication between two endpoints into seven different groups of related functions (aka layers). For example, if a message is sent between two computers: data flows throughout the 7 layers (or functions) across the network to the receiving computer.

Each layer somehow services the layer above through utilizing the services of the layer below. The concept of the 7 distinct layers is important here. Having different layers allows communication between systems at any level without impacting lower level layers.

You could easily explain this to someone by talking about how a city functions. You could start with water, sewage, roads, rubbish disposal and move on to public safety and education: all of these different systems work together to support the people who live in the city. Like the 7 layer system, you can’t have rubbish disposal without roads in place (one layer supports another), and yet you can make changes to the rubbish disposal or roads without heavily impacting the other.


History Lesson: How did the OSI Model Come About?
It’s not a well known story…ok, ok: it doesn’t exactly have mass appeal. That being said, it’s interesting to us (and maybe you). The origin of the OSI model can be traced to a group, tasked with the design and development of prototype systems, over at Honeywell Information Systems. It was the early 1970’s: Charlie Bachman served and the principal technical lead and Mike Canepa headed this groundbreaking group.

At first, the work of this Honeywell crew was largely focused on database design and then, distributed database design. As their work progressed into the mid-1970’s, they realized that to adequately distributed access and database machines, some kind of standardized structure for communications architecture was needed.

They studied solutions available at the time such as protocols for ARPANET, IBM’s system architecture and other concepts being worked on for database systems at the time. Through this work, in 1977, they zeroed in on a seven-layer architecture system that, at the time, they informally called the Distributed Systems Architecture (DSA).

Across the sea that same year, the British Standards Institute made the case to the ISO that a standard architecture was necessary for defining communications infrastructure for distributed processing. The American National Standards Institute (ANSI) was tasked with generating some proposals, long story short, Bachman and Canepa presented their 7 layer system to the ANSI.

The ISO group met in March of 1978 and the 7 layer system was accepted as it met most of the requirements of the OSI with the capacity to expand for new requirements.

And the rest, as they say, is…history.

So, now that you’ve got the historic backdrop, what are all 7 layers that come into play for network documentation?

Layer 1: Physical
This is where most of your documentation happens. Here, you’ll want to describe each device in your network (switches, routers, hardware, etc) as well as patch panels and cabling – and, depending upon the size of your network, building maps.

Layer 2: Data Link
This is the layer that makes communication between network and physical layers happen. You’ll want to have topology maps here that show both your links and how everything is connected. As every network adapter has a unique address, a major specification that happens in this layer is the hardware addresses (MAC address); you’ll want to document these.

Layer 3: Network
Your network layer establishes how data is communicated in your network and with other networks. Here, your documentation should include your IP addresses, VPN and RAS servers, WAN links and internet connections – as well as summarization plans for LANs and WANs.

Layer 4: Transport
What ports do your applications use? This layer carries the responsibility for packets getting to their endpoint, with no errors and in the proper sequence: it’s crucial for the security of your network (such as firewalls). Two primary protocols are at play here: TCP and UDP. Here, you’ll want to document the port numbers that your firewalls allow.

Layer 5: Session
This layer ensures that a system can open communications connections with remote systems and that data can flow back and forth between the two. Examples of protocols used here? SSH, SNMP, Telnet and SSL. Your network documentation for this layer should include SSL-enabled sites and your policy for enabling SNMP for network monitoring and management.

Layer 6: Presentation
This layer takes your data and translates it into a format that’s understandable to its recipient. Any necessary encryption or decryption happens in the presentation layer. As far as network documentation goes, this isn’t really where the party’s at, but if you have an application that requires certificates, it’s a good idea to document those.

Layer 7: Application
Your application layer controls any applications that are used to send or receive information (such as your email system).Document the applications that live here, the owners of these applications, which versions they are and any support contracts you may hold.

To sum up, maybe this post hasn’t been as exciting as, say, a recipe for a 7 layer dip, but we hope you’ve gotten a fuller view of where the 7 layer system originates from, how it works and how it comes into play when it’s time to document your network.

If you’re considering beginning some network documentation, you can check out this blog post all about where to begin – or maybe netTerrain Logical (our 100% browser based network documentation software).

Hannah Ash
Hannah Ash
Hannah Ash is a marketing specialist who loves thinking, writing and speculating about the future of the data center.

1 Comment

  1. sanekpen says:

    Showing switches and specific port connections of critical assets is very important in the network documentation process. Assets that are fairly static, like switches, routers, access points, servers, UPS equipment, should be included in the port-level documentation. Other more dynamic assets, like workstations and IoT devices, are more difficult to include in port-level network documentation as they can move around. This is why it s important to automate as much of your documentation as possible to ensure the documentation is always up to date when you need it.

Leave a Reply

Your email address will not be published. Required fields are marked *