Documentation Part 2: Designing and Documenting an IP Architecture
IP networks require an entirely new method of documentation.
Some engineers can maintain their current SDI systems armed with little more than a foggy memory of how things are interconnected. But with IP networks, such a philosophy guarantees panic if something fails. When it comes to properly documenting an IP network, ignore this task at your peril.
IP-Network topology is multi-dimensional. The infrastructure of a typical network has a core that includes a firewall, router and core switch. In addition then here are intermediate switches and then edge switches. In each instance there can be redundancies. The backbone will have higher bandwidth than the individual switches or the connection to the networked attached device. Many devices have multiple network connections for media and may provide for in band and out of band management.
OK, first terminology challenge? What is the meaning of In band and Out Of Band?
- In-Band management in the IP network means that control and management is on the same network segment as media and other services. If one fails they all fail.
- Out-Of-Band is a segregated network or separate network segment used only for management. KVM over IP is typically Out-of-Band and provides direct access to a server. This provides another way to access the device to solve a problem.
Above is a diagram of a constructed network. How would this be used to solve a problem or make a change to the system? First you need the right diagram.
Designing and documenting the network
Let’s start here. First how many networks do we have and how are they connected? LAN, WAN, WLAN and SAN, and I would be remiss if I left out Fiber Channel. What about proprietary IP networks that some vendors are promoting? And of course we now have SDN (Software Defined Networks). Having an SDN doesn’t change the number of parameters and connections, but it does introduce a management layer and could reduce the number of network devices that need to be configured. All of these devices and their configurations need to be maintained. You can’t just update one switch, you have to update all of them, SDN changes that. Either way don’t forget to keep accurate records because someday you will need to know which version of software is running on each one.
How are the enterprise and media networks going to be segregated or will they? I recommend they be segregated. OK, we settled that! Will they share an Internet connection and how will certain traffic cross between them? Are we going with a top-of-rack edge device topology? How many device locations do we need to support? Are we locating switches at each location? Are they in the same physical location or is there geographical separation between network segments? Where will the most traffic and bandwidth intensive traffic be located?
Documenting a network begins with a spreadsheet or database combined with a new type of line drawing. The interconnections between switches and devices can be both copper and fiber. While there may be few connections between devices, each connection can host multiple network segments (VLAN, Subnet) and each port can be configured differently.
Network system drawing. This line drawing is insufficient for software troubleshooting. (Click to enlarge.)
We use line drawings to show device placement and how they connect to the network. However because there are different types of networks, each has their own configurations. For that, a line drawing may not be the best tool.
So, where to begin? Start with the big boxes, then add the little boxes. What is going to be the core of the network? Typically this is a router with a firewall, the router can be part of the core switch (Layer 3). The router assigns IP addresses, configures port assignments, assigns and manages VLAN and SUBNETS sets network optimization parameters. To illustrate this, a line drawing is inadequate. Instead, use a spreadsheet or database. It needs to be consistently maintained and updated. Don’t forget to document important network parameters like QoS and shortest path.
Case Study
One of my projects involved more than 3,000 network connected media devices. The devices were spread among three buildings, over five floors with 54 working production areas. One key 50 floor building needed connectivity and access to the content being created.
Some of the work product was delivered via Web, IPTV and full broadcast to internal and external sources. The master IP document was a 20-tab spreadsheet developed by the broadcast team and delivered to the IT team for implementation. The IT team architected the network topology, switch locations and wiring design and produced virtually no documentation.
Because this was happening during a renovation, they allowed the architects and engineers to physically place the local switches and edge switches. That team assigned drops like adding electrical distribution, and the physical locations show up on the electrical low-voltage drawings as a small blue triangle. In the production spaces, the integrator added additional drops that were included on engineering drawings and in the wirelist.
Documenting IP
There will still be line drawings showing the interconnections and cabling between devices, elevations and equipment placement. These interconnections can be both fiber optic and copper. The fiber can be multimode and single mode. What about some of the new optical technologies that multiplex different wavelengths on a single strand of fiber? How is that shown on a line drawing? And what about the devices that convert between optical and electrical? What happens when a device is dual-homed or has separate ports for management and media and there is no labeling on the physical connection? Is it handled in software, but where does that get documented?
The IP network is complex with a lot of things happening on a single copper or fiber connection. The switches and routers in a distributed architecture are connected by one topology on the back plane and a different topology on the front plane. All this needs to be documented and maintained.
In the next article, I will tackle software documentation.
Editor’s Note: Gary Olson has a book on IP technology, “Planning and Designing the IP Broadcast Facility – A New Puzzle to Solve”, which is available at bookstores and online.
You might also like...
IP Security For Broadcasters: Part 1 - Psychology Of Security
As engineers and technologists, it’s easy to become bogged down in the technical solutions that maintain high levels of computer security, but the first port of call in designing any secure system should be to consider the user and t…
Demands On Production With HDR & WCG
The adoption of HDR requires adjustments in workflow that place different requirements on both people and technology, especially when multiple formats are required simultaneously.
If It Ain’t Broke Still Fix It: Part 2 - Security
The old broadcasting adage: ‘if it ain’t broke don’t fix it’ is no longer relevant and potentially highly dangerous, especially when we consider the security implications of not updating software and operating systems.
Standards: Part 21 - The MPEG, AES & Other Containers
Here we discuss how raw essence data needs to be serialized so it can be stored in media container files. We also describe the various media container file formats and their evolution.
NDI For Broadcast: Part 3 – Bridging The Gap
This third and for now, final part of our mini-series exploring NDI and its place in broadcast infrastructure moves on to a trio of tools released with NDI 5.0 which are all aimed at facilitating remote and collaborative workflows; NDI Audio,…