The Enterprise Deployment Scenario

A final, working streaming media system is the realization of a vision. As in previous sections of the book, we will start by describing the complete scenario. Then we will spend the rest of the section exploring how a company builds the scenario from the ground up. Again, we will not attempt to describe every possible solution.

This scenario is based on a fictitious company, Fabrikam Transportation, that manufactures mass transportation vehicles such as buses and tram cars. The company is headquartered in Toronto, with important subsidiary facilities in the United States, Mexico, and several countries in Europe.

Keeping the lines of communications open and flowing is vital to the success of the company. Assembly and manufacturing operations in Toronto, Detroit, Stuttgart, and D sseldorf can move smoothly only if the information is current, complete, and correct—if parts are held up in Detroit, Toronto needs to know that now. The sales and marketing division in New York cannot be held up because of slow network connections to Toronto. E-mail and the telephone provide instant one-to-one communication, and today streaming media provides instant one-to-many communication.

Figure 14.1 shows a simplified topology of the Fabrikam streaming media system. Fabrikam has 15,000 employees and contractors internationally. Streaming media reaches 9,400 desktops. The main data center in Toronto, which is the company’s manufacturing center, serves the bulk of the workforce. Multiple remote data centers throughout North America and Europe connect to Toronto through a wide area network (WAN) that uses Asynchronous Transfer Mode (ATM) technology. The remote data centers then serve nearly 100 remote work sites.

Figure 14.1: The network topology used for streaming media at Fabrikam.

Sites that are local to a remote data center enjoy a high-bandwidth connection. Bandwidth available to remote sites varies depending on the type of connection. Medium-bandwidth sites typically connect with DSL; low-bandwidth sites and employees connecting to the corporate network through remote access typically use dial-up or 56 Kbps frame relay connections. Other users connect wirelessly with laptop computers and Pocket PCs.

Fabrikam Network Resources

There are three Windows Media servers and three Web servers in the Toronto data center. The two sets of servers are configured with the Network Load Balancing (NLB) service. These server clusters are referred to as the Windows Media and Web server farms. Each server has a 1000 Base-T connection to the data center backbone for providing streaming content to users. Each also has a separate 100 Base-T connection to internal management systems, and the Windows Media servers have 100 Base-T connections for receiving content from live and on-demand encoding computers and production workstations.

A Windows Media server located in the data center perimeter network (also known as the “DMZ”) provides streaming content to special users, such as partners and customers, on the Internet. This is referred to as the company’s “extranet.”

Most end-users view streaming presentations on their desktop computers. Employees without desktop computers connected to the corporate LAN (such as those in the plants, remote sales staff working on laptops, and home users) can view streaming media content on computers, on Windows Media-enabled set-top boxes in resource centers located near manufacturing areas, and in meeting rooms with video projection systems.

The Origin Servers

Designing a streaming media system is an additive process, starting with a core system and building outward as needed. The core of a Windows Media distribution system is a server. The server sits in the center. Content is sent from one or more encoding computers to the server, and content is streamed from the server to one or more client computers.

At Fabrikam, the intranet origin servers are actually server farms that appear to the client as a single Web or Windows Media server. Single servers could be used, but connecting multiple servers together in a cluster using NLB enhances the availability and scalability of the servers.

• Availability means that there are enough servers to handle the load if one should fail. By using NLB, a server can be removed from the farm for maintenance with no system downtime. The only service disruption is to the users who were streaming from the server at the time it was taken offline.

• Scalability means that a server can grow to meet increasing performance demands. Multiple servers that have been configured as a cluster to act as a single server provide a high level of scalability. To further enhance scalability, you can easily add more servers, storage, and processors to the cluster as the need arises. For example, a storage area network (SAN) could be added to increase storage capacity and reduce the load on the servers.

The Web server farm delivers Web content to users’ browsers and to other programs, such as Windows Media Player. Web servers are included in a discussion of Windows Media Services because there are many instances in which Web servers are used in conjunction with streaming Windows Media-based content. On-demand PowerPoint presentations and the Media Guide are two examples that will be described later.

A user requests Windows Media-based content using the URL of the cluster, such as rtsp://WMServer/content.wmv. The NLB cluster receives the request and the NLB service uses a statistical mapping algorithm, which is distributed on each server, to determine which server will handle the request. The determination is based on the current load across all servers in the cluster.

By using computers with multiple NICs, the gigabit Ethernet network can be dedicated to servicing client requests. Server management functions are moved from the main network to separate network systems, so that more network resources are dedicated to handling user traffic. A Virtual LAN (VLAN) can be created to logically isolate management functions.

The Windows Media server farm hosts on-demand and broadcast unicast content and multicast streams. To receive unicast content, Toronto-based clients connect directly to the origin servers; clients outside Toronto connect to cache/proxy servers. For more details on how the origin servers are configured, see chapter 17.

The Corporate Network

Clients connected to the main LAN in Toronto enjoy a 100 Mbps Fast Ethernet network. Clients there can stream VHS-quality video directly from the origin servers. Care is taken, however, to make sure the total aggregate bit rate from the origin servers does not overwhelm the network. Most of the time, the total bit rate is moderate. Windows Media server client logs give the company a picture of bandwidth usage. Fabrikam logs show that during business hours, the average streaming media bandwidth usage on the Toronto LAN is less than 15 megabits—roughly 50 clients connected concurrently viewing a 300 Kbps unicast stream. Of course, over a period of a day that can amount to thousands of viewers.

There are situations when unicast connections could exceed the capabilities of the network. For example, an archive of a live broadcast of the CEO announcing the year’s profits is timely enough that many users will want to play the stream at the same time. To handle the load, the company sets limits on the server. When the bandwidth limit is reached, the server starts denying client connections.

This method effectively limits load on the network and servers. But it does not limit the frustration of users who cannot receive a stream. Therefore, broadcast content and on-demand content that is expected to receive a high number of concurrent connections will be delivered using multicast streaming to help eliminate network traffic problems. To help manage unicast traffic, the company will employ remote servers.

Remote Networks

Desktop computers at each branch location are also connected to 100 Mbps LANs, which provide more than enough bandwidth to support e-mail and intranet needs within the LANs. Bottlenecks, however, can occur over many of the WAN circuits. Users in New York access a North American data center in Detroit through an ATM network, which provides a high-bandwidth, 25-Mbps connection. European data centers, on the other hand, use a frame relay connection, which provides only 128 Kbps of bandwidth for local users in Stuttgart and London. As you can see, many unicast connections could quickly consume much of the bandwidth in the segments serving the data centers. A frame relay connection could barely handle one stream.

To protect the bandwidth in the WANs, usage must be reserved for critical data exchange, such as sales and production documents. Streaming media is therefore handled by using remote servers with cache/proxy plug-ins and by content management.

Cache/Proxy Servers

Cache and proxy service functions are most often hosted on a single server, called a cache/proxy server. These are computers or devices that intercept and handle client requests made to origin servers. For example, a system can be set up so that, when a client makes a request to stream a file or open a Web page from an origin server, a cache/proxy server that is closer to the client intercepts the request and delivers the content from its cache. By using cache/proxy servers, you can ease the demand on the origin server and the network segments that converge around it. The result is a more efficient use of network resources and bandwidth, and a better user experience because there is likely to be less buffering.

Fabrikam uses cache/proxy servers to help move content closer to users so that the load is taken off of the WAN, the network segments leading up to the origin servers, and the origin severs themselves. End users and clients are often referred to as being at the “edge” of a network because that is where the requests originate; likewise, when cache/proxy servers are used to move content closer to the edge, they are sometimes called “edge servers.”

Edge devices and servers are the key components of a decentralized network topology, the type of network topology that is being used for the Fabrikam scenario. A centralized topology with one origin server handling all requests works on small or medium-sized networks. However, on medium or large, complex networks that are made up of network segments of different types and bandwidths, it makes more sense to distribute content through edge servers that cache and proxy content. The alternative would be to upgrade the entire network infrastructure to handle the increased bandwidth demand, which would not be an economical option for Fabrikam at this time.

This decentralized network is called a content delivery network (CDN). Within an enterprise, this type of network is sometimes called an eCDN. Several methods are used to move the content from the origin server to an edge server, and then from the edge server to a client. If the content is a file, it can be cached automatically, or copied in advance of demand. Copying content in anticipation of an end-user request is sometimes called prestuffing or preloading. If the content is a live stream, it can be split by an edge server. All of these methods are detailed in chapter 20.

Content Management

Managing Windows Media-based content is simple if you have only a handful of files to stream. However, a company that understands the value of communicating with audio and video will, over time, accumulate many hundreds of files that need to be made available online. In addition to streaming audio and video, the company must be able to handle all the different types of content that go into a rich-media production, such as images, text, Web pages, script, and metafiles. And if a decentralized topology is used, the files must be made available on multiple remote edge servers as well as on the origin server.

The CDN system used by Fabrikam does more than decentralize the topology; it includes systems for helping the company manage its on-demand content on the network. There are basically three ways to move content from the origin server to the remote servers:

• Manual distribution. An administrator manually copies the files to remote caches. Obviously, with 100 or more edge devices, this may not be the most effective solution. However, it can be used to quickly copy files to a new server.

• Scheduled distribution. A third-party or custom program is used to automatically copy files according to a schedule. Using scheduled distribution, you can work around time zone differences and prestuff files after business hours when there is low traffic on the WAN.

• Automatic caching. Most cache/proxy solutions use this method. With automatic caching, content is not added to the remote cache until a user requests it. The first time a file is requested, it is played from the origin server and concurrently sent to the cache. Subsequent requests play the file from the cache.

Most CDN systems enable an administrator to use a combination of automatic, manual, and scheduled distribution. For example, you might decide to prestuff a file that you know will receive many plays, such as a quarterly financial report.

Perimeter Network Servers

At Fabrikam, like many enterprises, the data center has a perimeter network that contains Web and Windows Media servers that are accessible to users on the Internet. The perimeter network sits between the corporate network and the Internet. Firewalls surround the perimeter network servers and filter network traffic based on protocols and ports to keep Internet users from gaining unauthorized access to internal intranet computers.

Figure 14.2 shows how the firewalls are used. Internal users can copy files and distribute live streams through the first firewall to the perimeter network Windows Media server. External users can request and play content from the perimeter network server, but are prevented by the second firewall from gaining access to other applications on the server, and by the first firewall from gaining access to the corporate network.

Figure 14.2: Locations of firewalls on the Fabrikam network.

Many firewalls are configured by default to block streaming media packets sent using the UDP protocol. In order for Internet users to stream content, the ports needed for UDP traffic can be opened on the firewall. However, if the ports cannot be opened, Windows Media Player is configured by default to roll over, or switch to receiving a stream using the TCP protocol automatically. The TCP protocol and port 80 are used for most Internet traffic.

At Fabrikam, the Windows Media server on the perimeter network enables Internet users to play files, such as maintenance training videos, public financial reports, and marketing information. Authentication and authorization plug-ins are enabled on the server to restrict access to a select group of users who are part of the company’s extranet, including partners, dealers, and repair facilities.

Production Workstations

One set of encoding stations is indicated in the topology. In practice, however, live and on-demand content can be delivered to the servers from multiple encoding computers over the corporate network. For example, a remote encoding station can be set up in Stuttgart to encode on-demand content. The content can then be hosted on the Toronto origin servers. Most often, videos are produced in the production facilities of the Media department in Toronto. The department creates most of the live and on-demand content using its studio and editing facilities.

Also, PowerPoint slides can be synchronized to recorded video of a presenter by using Microsoft Producer. The resulting presentation can be packaged into a final on-demand video. These Producer presentations can be recorded and edited by the Media department or in a special mini-studio like the one described in chapter 18. The studio provides users who have little knowledge of video production with the tools to produce their own videos. The finished presentations can then be uploaded to the Web server and Windows Media server for international distribution.

Media Guide Portal

The Media Guide portal is an intranet Web site on which end users can link to live streams, and search for and link to on-demand content. The portal is built on Microsoft SharePoint Portal Server, so it is modular and extensible. In addition to providing a one-stop location for accessing streaming content, the Media Guide portal provides a simple way for users to upload material destined for the Windows Media server. Users can also request production resources and help, and schedule live broadcast time. SharePoint and the Media Guide are described in chapter 16.

Multicast Broadcasting

Multiple users can connect to a single broadcast delivered using multicast streaming, and bandwidth usage is no more than that of one user. Because bandwidth usage is low, producers can offer users a choice of bit rates with little additional impact on network bandwidth. For example, two encoders can be used to record single streams that support different bit rates, such as 100 Kbps and 300 Kbps.

After a live event, producers can use multicast to broadcast an archived file of the event from server-side playlists. The playlists can be set to loop repeatedly so users can tune in and view the event at any time. Again, thousands of users can connect without adversely affecting the available bandwidth on the network. Playlists are described in chapter 11.

Before a company can broadcast using multicast, the entire network must be multicast-enabled. In an enterprise the size of Fabrikam, routers are used to connect large network segments, and on many of the routers multicasting may be disabled by default. Also, many hubs and switches may not be designed to segment multicast traffic and might need to be replaced. Token ring configurations also present barriers to multicast. to address thse issues, Fabrikam studied the network infrastructure to identify and reconfigure devices to handle multicast traffic. On those segments of the network that could not be enabled, unicast delivery was used. Chapter 22 describes how Fabrikam enabled multicast streaming.