There is a core set of protocols critical to the operation of computer networks. Some of the most important protocols include IP, Transmission Control Protocol (TCP), Address Resolution Protocol (ARP) and Internet Control Message Protocol (ICMP). Of course, these protocols are critical to broadcasters as well since many broadcast facilities now rely on computer networks.
Ethernet
Ethernet is both a protocol and a hardware specification. The Ethernet standard specifies the electrical signals and voltages on the wire (or the RF transmission scheme in the case of wireless), but it also lays out the way Ethernet packets are built and what the Ethernet headers contain. You have probably heard of these standards — IEEE 802-x, where “x” designates various parts of the standard. For example, 802-3 covers wired networks, while 802-11 covers wireless Ethernet.
Ethernet addresses, which are inserted into each Ethernet packet header, are different from IP addresses. Ethernet addresses refer to a particular physical device; they are similar to a Vehicle Identification Number that is used to uniquely identify a specific automobile. This is significantly different from IP addresses, where the end user can assign a particular IP address to any IP network device.
IP
IP is a core protocol, whether you are talking about IT or broadcast applications. IP's job is to get datagrams from one device to another, and IP packets typically ride on top of Ethernet networks, although IP data can travel over other physical networks as well. (Note: A datagram is a self-contained, independent entity of data carrying sufficient information to be routed from the source to the destination computer, without reliance on earlier exchanges between the source and destination computers and the transporting network.)
It is the job of the IP layer to interface to these lower layers, while presenting a uniform computer network-addressing scheme to the layers above it. The IP layer prepares data sent to it by higher protocols for transmission across a specific logical network, taking into account things such as the packet length, hardware addressing structure and how data should be split across multiple packets.
User Datagram Protocol
User Datagram Protocol (UDP) is used to send datagrams from one application running on a computer to an application running on another computer. The UDP header contains a port number. The port number is typically used to indicate that the packet is destined for a particular application on the receiving computer. You probably already know, for example, that port 80 is typically used for HTTP in web applications.
It is important to know that nothing in the UDP protocol guarantees that packets sent across the network will reach the other end. In fact, UDP explicitly does not check to see that packets have been received (as compared to TCP, which does ask for the retransmission of missing packets). The up side of this is that UDP is an extremely lightweight protocol to implement, and it is very fast. Furthermore, UDP does not introduce delays while it requests and subsequently receives lost packets.
The size of UDP packets can vary, and, in some cases, they can be large. This brings up the issue of fairness. Large UDP packets may hog bandwidth on a network, causing other traffic to suffer. For this reason, and for other security reasons, some system administrators choose not to permit UDP traffic to cross their firewalls. This can cause headaches for broadcasters.
Real-time Transport Protocol
As the name implies, Real-time Transport Protocol (RTP) is a protocol intended for the transmission of data in real time. Quoting directly from the Internet Engineering Task Force Request For Comment 3550 (IETF RFC 3550), “RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services.”
As with other protocols described in this article, RTP contains a payload and an associated header. The RTP header contains two significant items. The first is a sequence number. This number is incremented for each RTP packet that is transmitted during a session. If you are an RTP receiver, and you miss a sequence number, you know that a packet has been dropped. It is then up to the receiving application to decide what to do.
RFC 3550 includes a retransmission mechanism within a sub-part called the RTP Control Protocol (RTCP). However, in many video applications, retransmission is not an option. By the time a receiver notices that a packet has been dropped, requests a replacement packet and decodes and prepares the content for display, it will be too late. In this case, FEC or concealment may be reasonable alternatives, since neither of these require lost-packet retransmission.
RTP provides one other facility that is critical for the reconstruction of real-time data, and that is a timestamp field. When a video feed is presented to a computer for transmission, that feed is isochronous; it is coming in at a fixed rate that does not vary. But, when these packets arrive at a receiver, the inter-packet arrival time can vary tremendously depending upon congestion, routing and many other factors. The RTP timestamp allows a receiving application to recreate the stream with the same pacing as was present at the input to the sender.
Encapsulation
Many computer protocols build upon one another. The process starts with an application passing data to a network protocol stack. The top protocol in the stack takes this data and puts it into the payload section of a packet. Then, it pre-appends a header. The header typically contains information about the payload, information about the source and destination of the packet, or both.
Figure 1 shows how this encapsulation process works. Assuming we start with a streaming application, video and audio is MPEG compressed and put into MPEG TS packets. As part of the process of creating the MPEG TS packets, headers are created. These, among other things, describe the video and audio contained within the MPEG TS packets. These MPEG TS packets are placed in the payload portion of RTP packets. Note that all of the MPEG content, including the MPEG headers, are enclosed in the payload section of the RTP packets. The RTP packets, including headers, are then encapsulated in the payload section of a UDP packet. UDP headers then are added. The UDP headers are simple and include information about the source port, the destination port, packet length and a checksum. UDP packets are inserted into the payload section of IP packets, and IP headers are added. The IP headers, among other things, contain the sender and receiver's IP logical network addresses. Finally, the IP packets are inserted into Ethernet packets, and Ethernet headers are added. The Ethernet headers contain the source and destination Media Access Control (MAC) addresses.
At first, this may seem like an incredibly inefficient way of getting an MPEG stream from one place to another — and from a pure efficiency standpoint, you would be correct. But, it is important to realize that each layer has a job to do. In a well-designed system, it should be possible to replace equipment that operates at one layer with equipment from another vendor that operates at the same layer without having to rebuild the entire system. Encapsulation allows system designers to separate network functions, and to present information contained in the headers at the appropriate layer of the network.
As broadcasters build more IT-based facilities, certain core protocols are emerging as critical for our industry. Encapsulation is the key that will allow us to change and adapt these protocols as our industry matures in this area.
Brad Gilmer is executive director of the Advanced Media Workflow Association, executive director of the Video Services Forum, and president of Gilmer & Associates.
Send questions and comments to: brad.gilmer@penton.com
