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.
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.
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...
Troubleshooting IP-centric technologies can be a new challenge for engineers. Often it becomes a case of “You don’t know—what you don’t know,” until it is too late. In addition, once the engineer knows there is a problem,…
As broadcasting moves to highly efficient production lines of the future, understanding business needs is key for engineers, and recognizing the commercial motivations of CEOs and business owners is crucial to building a successful media platform.
Broadcast engineers have a whole plethora of tools available in their kit-bag to integrate systems. The common denominators are SDI, AES and MADI for media exchange, serial and ethernet protocols for control, and the trusted GPI should everything else fail.
Unless you are a greenfield site, have one vendor to meet all your operational and creative needs, or are incredibly lucky, you will at some point need to integrate your Cloud Software-as-a-Service into the broadcast workflows. This is much easier…
There are many benefits to a file-based workflow. One of those is the ability to automatically check video for a laundry list of errors and if the file meets compliance specifications. It is important to understand what can and cannot…