WatsonBruce Ikadega sample 2

An introduction to DirectPath

PROPRIETARY and CONFIDENTIAL. NDA REQUIRED. 10/12/2001 3:49 PM Copyright Ikadega, Inc. All rights reserved.

An introduction to DirectPath (\\docs\techpubs\internal_docs\directpath_intro.doc)

This document contains information that should be useful to those who are new to Ikadega’s DirectPath™ product. It gives a high-level overview of the custom hardware in the system.

Note: This document provides high-level overview information rather than detailed specifications. If there are differences between this introduction and any other DirectPath specification or design document, consider the latter document correct rather than this one.

Note: DirectPath is a new product that is evolving over time. Some of the components and features described in this document may not be in the product until a future release. For many such components, this document notes that they apply to a future version, but others may not be marked this way. Please contact the technical publications department if this document does not describe a future component or feature as such.

How to use this

document If you are new to the DirectPath system, you should read this document from beginning to end. However, if you need to find a specific piece of information, such as the definition of a term, start with the Index on page 26.

Other documentation This document is an overview of DirectPath. You can find more detailed design

information the product’s online (Web-based) documentation, which is organized by the subsystems described on page 22. Additional paper documents are available on various subjects.

Copyright 2001 Ikadega, Inc. All rights reserved. Ikadega and DirectPath are trademarks and/or registered trademarks of Ikadega, Inc. Fibre Channel is a trademark of the Fibre Channel Industry Association.



Document contents

Introduction .........................................................................................................................3 System applications.............................................................................................................4 System components.............................................................................................................4

Components of the IP product.........................................................................................4 Components of the media server product ........................................................................7

Inside the system .................................................................................................................7 Inside an IP system..........................................................................................................7 Inside a media server system...........................................................................................8 Communication pathways ...............................................................................................9 Communication example...............................................................................................11 Flow control ..................................................................................................................12

Linking to other fabric switches ........................................................................................13 About rings ....................................................................................................................14

About FPGAs ....................................................................................................................16 Board and node design ......................................................................................................18

Disk storage boards .......................................................................................................18 IP access nodes..............................................................................................................19 Analog access nodes......................................................................................................20 Supplemental processor nodes ......................................................................................21 About supplemental processors.....................................................................................21 Chassis manager nodes..................................................................................................21

Major subsystems..............................................................................................................22 Application subsystems.................................................................................................22 Core services .................................................................................................................23 Platforms .......................................................................................................................24

For further information......................................................................................................25 Index..................................................................................................................................26



Introduction A DirectPath system might typically be used in one of these ways:

• As an Internet server to provide multimedia content such as movies or sound files, an HTTP server, an FTP server, an RTSP (real-time streaming protocol used by QuickTime™) server, or a server for any protocol that distributes content (such as RealPlayer™ or Windows Media Player™).

• As a hospitality server, providing digital movies or other multimedia content to guests at hotels, hospitals and other facilities.

• As a corporate intranet server, delivering content to employees.

• As a server for data caching or network-attached storage (NAS).

• As an ad insertion system. A typical application would be a local cable TV provider using a DirectPath system to replace the ads showing on some channels with ads of their own. The inserted ads are usually for local businesses.

The flexibility of the DirectPath design makes many other applications possible. The product is ideal for distributing any type of files that are relatively stable. The system is designed for optimal performance in distributing files. Its performance is not optimized for file writing operations. It has no advantage over legacy servers for files that change frequently, but it still can process them.

The DirectPath system delivers content files. A content file is a set of content – for example, a movie, Web site, sound file, multimedia presentation, etc. Each content file can be stored on disk as one or more partitions. The system is designed to take advantage of a few important qualities of content files and partitions:

• Partitions are very large – typically from hundreds of megabytes up to a few gigabytes. Thus the system’s numerous disk drives are typically filled with relatively few big files rather than the tremendous number of small files you might see on a typical PC hard drive. The product is most efficient when delivering large files. The delivery of content involves sending a massive amount of data over a relatively short amount of time. The entire system is designed to keep its disk drives as busy as it can, with file seek times reduced as much as possible.

• Partitions are read far more often than they are written. In a digital movie application, for example, new content files might only be installed on the system a few times a week, while the movies could be played back as much as hundreds of times per day. The DirectPath system is extremely efficient at reading data, and not as effective at writing it, which is OK because its writing operations are comparatively rare in most applications.

A DirectPath system can work in environments with small or mid-sized files, or where files are read and written in more even proportions, but it wouldn’t have as many advantages over conventional systems as it does working with large files that are read far more than written.



System applications

There are several most important uses or applications for DirectPath systems. Ikadega has these separate DirectPath products:

• IP product – delivers content of various types to users over the Internet.

• Media server product – hospitality and ad insertion systems are both media server applications.

• Fibre Channel product (future) – Fibre Channel is a standard infrastructure for high-speed, high-volume data communication. Ikadega is developing a Fibre Channel product.

System components

This section describes the basic components in the IP and media server products. There are a number of similarities but a few important differences.

Components of the IP product

The system includes a number of components that communicate over a fabric (also called a switched fabric). The fabric allows simultaneous high-capacity data transmission from many storage devices to numerous clients. Some DirectPath systems consist of two or more connected chassis. The fabric connects all components and chassis together. The fabric connects the following types of components:

• Access nodes handle communication with end users of devices outside of the DirectPath system. Most of this communication is the transmission of content to the end user. In Internet/intranet applications, an access node can support between 10,000 and 50,000 end users. (In hospitality applications, an access node can support up to 8 simultaneous users.)

• Disk storage boards (DSBs) read digital data from disk and send it to the access nodes. Disk storage boards also write content data when the system receives new content, but this happens relatively infrequently (compared to the read frequency). Current DSBs have two sub-nodes, each of which controls one standard ATA hard disk drive. These are double-width boards – they use two chassis slots. For best performance, the system stores content contiguously on disk whenever possible. The system can mirror drives (maintain the same data on two drives, so there’s a backup if something goes wrong with one of them).



• A DirectPath controller (DPC), also called a fabric controller, oversees overall system functioning and inter-board communication. No communication or data transfer can take place on the fabric without the DPC’s direction. There is one DPC per fabric switch. DPCs are located on fabric controller boards (FCBs). These boards also contain hardware for linking fabric switches to each other.

Before any data transfer between boards, the DirectPath Controller provides the sender with path/header information to make sure that the data goes to the correct place. This keeps the message header short, which enhances system performance. A fabric interface connects the DPC to the fabric:

In IP applications, the IP access node is a combination of two boards: an intelligent NIC (iNIC), which transfers data in and out, and an integrated server board (ISB), which manages end-user logins and handles exceptions. There is also an optional port extender board (PEB). In hospitality, the analog access node (so named because it outputs an analog TV signal) is made up of decoder boards and decoder interfaces.

The following illustration shows the communication between these component types to deliver high-bandwidth content. This is a greatly simplified picture that shows only one access node and one disk storage board; it also does not show links between fabric switches.

This is the normal sequence of events when an access node wants to send a block of content to the user (this is also simplified):

1. The access node needs to send out a block of data. It first checks its cache memory, sending a data request to the DirectPath Controller if the data is not in cache. This

DirectPath Controller

Fabric interface

To/from fabric

Fabric

External

users

Access node Disk storage board

DirectPath Controller (DPC)

3b

3a

1 2



request only asks for a file or a block of data starting at a certain offset into the content file. The request does not specify anything about where to find the file or block on the disk, since the access node does not even know which DSB will fill the request (the DirectPath Controller decides this).

2. The DPC knows the contents and the states of all disk drives, including the current location of their read/write heads. It schedules operations for each drive to optimize each disk’s read requests and minimize head seek time. The DPC selects a disk that contains the requested file or block, and schedules the read at the optimal time. At the scheduled time, the DPC sends a read command to the appropriate disk storage board. The DPC schedules all I/O operations on all disks in the chassis, with a goal of reducing the total seek time while still meeting the deadlines for each delivery request.

3. When the disk storage board receives the data request, it first checks for the data in its own cache (separate from the access node cache). If the data is not in cache, the node begins reading the data and sending it directly to the access node. The fabric gives the DSB a direct virtual connection (though not a direct physical connection) to the receiver. This makes the fabric non-blocking: the disk drive can read and send its data payload when it is ready to, without waiting. The fabric creates a virtual path to the receiver, independent of (and not delayed by) any other I/O in progress. The DPC is not involved in moving the actual bytes of data from disk storage board to access node, other than scheduling the operation. This keeps the DPC from becoming a bottleneck, and it is an important part of the system’s high throughput capacity. When the disk storage board begins reading the block, it also sends an acknowledgement message to the DPC (this is step 3b in the figure). Steps 2 and 3 repeat until the content has been fully transmitted (unless it is short enough to fit in one read operation, which is rare). The same access node handles the entire file transmission, but there might be multiple disk storage boards sending it different data blocks when needed, as determined by the DirectPath Controller.

The design allows a large number of these operations to take place at the same time, involving multiple disk storage boards and access nodes, without any of the logical connections being blocked.

The access node only requests the amount of data it can store in its input buffer. This means that it makes numerous data requests for content, and it keeps track of how much of the file has been processed at a given time.

Note: Among the details left out in this explanation is the session that each access node must establish with the DirectPath Controller. A data receiver requests a session before beginning to process a content file. Sessions help the DPC manage the system and schedule disk activity.



1 9

1

Components of the media server product

The media server product is similar to the IP product in many ways, but there are some differences. The biggest difference is that media servers contain analog access nodes rather than IP access nodes. In an analog access node, a decoder board turns digital video data into a TV signal. This signal then goes through a second board called a decoder interface on its way to the facility’s cable plant (and eventually to TV viewers). For more information on the access node, please see Analog access nodes on page 20.

Other than the boards described above, the media server product operates much like the IP product. The fabric, disk storage boards, DirectPath Controller, and the basic system operation are the same as described in Components of the IP product on page 4.

Inside the system

The IP and media server products use slightly different chassis because some of their boards have different sizes. The following sections describe the chassis layouts and shows how communication takes place over the fabric.

Inside an IP system

The current IP chassis design has two rows of boards connected to a common backplane, over which the boards communicate with each other. On each side there are 21 slots to house boards. Some boards must go in certain slots, as described below. This is how it looks (when seen from above):

On the “front” side of this chassis, the middle slot is reserved for the fabric controller board, which contains the DPC and the switch elements through which the other boards

Backplane

Slot #:

. . . . . .

10 11 12 13 14 15 21

Fabric ctlr. board

ISB

Areas for disk storage boards

Area for intelligent NIC boards and

PEBs

iNIC board Disk storage bd.

Port extender bd.

21



1 9 15

1

communicate. The slot next to it contains the ISB board. The other slots on the front side can have an arbitrary number of disk storage boards (DSBs).

In the system design, the back half of the chassis holds intelligent NIC (iNIC) boards and port extender boards (PEBs). Current systems can have only one iNIC board, though future versions will support more. The iNIC board must be in the slot opposite from the ISB board. The two boards communicate through a hole in the backplane.

Port extender boards are boards that simply provide an iNIC’s output signals to a different type of connector.

Some types of nodes use one slot (single-width boards), while others use two (double-width boards). The disk storage boards are double-width boards, while the fabric controller board and the port extender boards are single-width boards.

Early versions of the system design specified two types of chassis: a main chassis (whose fabric controller board had a DPC) and an expansion chassis (which had a different fabric board with no DPC). The expansion chassis is not currently a part of the design, and the term “chassis” now applies only to a main chassis.

Inside a media server system

The media server chassis has a similar layout to the IP chassis described in the previous section. Rather than IP access nodes, though, a media server system has analog access nodes, each of which consists of a decoder board and a decoder interface. There is no ISB board, but there is an ITM-LVDS interface board that provides a communication link between the chassis and the customer system where end users select content titles. This board also facilitates a link between the chassis and Ikadega for troubleshooting access. The decoder boards and corresponding decoder interfaces communicate through holes in the backplane, so they must be directly opposite each other. The same is true for the fabric control board and the ITM-LVDS interface.

Backplane

Slot #:

. . . . . .

10 11 12 13 14 21

Area for decoder boards

Area for decoder interfaces and ITM-

LVDS interfaces

Fabric ctlr board

Decoder board

Disk storage board

Decoder IF

21

ITM-LVDS IF

Area for disk storage boards



Communication pathways

The disk storage boards communicate with the iNICs or decoder boards through a series of six input and six output switch elements on the fabric controller board. Each pair of input and output elements handles the I/O for up to six of the boards (typically four) in the chassis. The input and output elements communicate with the boards by sending signals over hard-wired pathways on the backplane. The elements also communicate with each other.

On the fabric controller board, each of the six input elements is electronically connected to all six of the output elements, and vice versa:

(A technical note: the input and output elements are implemented as field-programmable gate arrays [FPGAs]. For more information on this, see About FPGAs on page 16.)

Board 3 Board 2

Board 1 Board 0

Input element

Output element

Via backplane

Via backplane

Output element

A

.

.

.

OE BOE C

OE DOE E

IE BIE C

IE DIE E

IE BIE C

IE DIE E

OE BOE C

OE DOE E

Fabric controller board

On fabric ctlr board

(middle slot)

In other slots

Boards – set A

Boards – set F

Boards – set A

Boards – set F

Output element

F

Input element

A

Input element

F

.

.

.



Below are simplified pictures of input and output elements. From a design standpoint, the two types of elements are very similar, but they have slight differences. Each of them could have up to 15 buffers, though they generally have no more than 5 (four for the attached boards and one for connecting to other chassis, as described on page 13). In an input element, the input buffers are filled with data from the element’s connected boards. In an output element, data is buffered before being sent to the boards.

The DPC, switch elements, and boards communicate with a protocol called Ikadega Transport Mode (ITM). Among other things, the ITM definition includes the addressing method, which identifies the component a message is being sent to. In the header of each message put on the fabric, there are two important addressing items: the final main fabric row and the port. The final main fabric row identifies the element the message will go to once it reaches the correct fabric switch (for more on this, see Linking to other fabric switches on page 13). The port identifies which of the element’s connected boards will receive the message. Sending boards receive these and other addressing parameters from the DPC before sending the message.

Input buffers

From connected boards (up to 15 but usually 5 or

fewer)

To the six output elements . . .

Input element

Output buffers

To connected boards (up to 15 but usually 5 or

fewer)

From the six input elements . . .

Output element



Communication example

What follows is a simplified example where the source and destination boards are in the same fabric switch. Suppose that the second physical board connected to switch element B is a disk storage board, and the DPC tells it to send data to the fourth board connected to switch element D. Based on parameters sent by the DPC, the message sent by the DSB has a final main fabric row of 3 and a port of 3 (the switch elements and ports are numbered from 0 to n-1). The disk storage board sends a message over the backplane to its input element, where the data goes into the element’s second input buffer:

When it receives the complete message from the disk storage board, the input element sends it across the fabric controller board to output element D:

Input element B (on fabric controller board)

Board 0

Board 1

Board 2

Board 3

Input element B

To OE A

To OE B

To OE C

To OE D

To OE E

To OE F



Output element D receives the message in its buffers and then sends it over the backplane to the receiving board (board 3):

This drawing shows the message’s path through the entire fabric switch:

Flow control Some simple handshaking keeps data flowing efficiently through the system. Before a data transfer can take place, the sender must make sure that the receiver’s CTS (clear to send) indicator is on. Generally, the receiving boards have enough buffer space for not quite two messages at once. An iNIC or decoder board can usually be processing the previous message as the next one is arriving, but it depends on buffer size and on data transfer rates in different parts of the system.

Output element D

Board 0

Board 1

Board 2

Board 3

IE A

IE B

IE C

IE D

OE A

OE B

OE C

OE D

Board 1

Board 3 IE E OE E

IE F OE F

From IE A

From IE B

From IE C

From IE D

From IE E

From IE F



Linking to other fabric switches

Earlier sections of this document describe the movement of data in a single, isolated switch. It’s more complex when multiple switches communicate with each other (for simplicity, this drawing does not show the connections between the input and output elements):


Input elements

Output elements

A

B

C C

D D

E

F

LVDS

B

A

B

E

F

To/from other fabric

switches

LVDS

A


switches



Data enters and exits the chassis through LVDS (low-voltage differential signal) ports. An incoming message from another chassis goes to one of the input elements shown in the drawing. You can think of these connections to the input elements as “pseudo-nodes,” receiving messages from other fabric switches rather than from boards in the local chassis. (These LVDS ports are different from the ITM-LVDS interface board described in Inside a media server system on page 8.)

Similarly, messages bound for other fabric switches move from one of four output elements to an LVDS port. (These connections to the four output elements are also pseudo-nodes.)

About rings DirectPath chassis can connect to one another in an arrangement of rings. A ring is a series of chassis connected in serial. A message moves from one chassis to the next in the ring, until it reaches the destination chassis. Each chassis can be on multiple rings (typically two). This drawing shows several chassis on two rings:

Input element From other

boards

From LVDS port

Fabric switches



Rings are bi-directional data paths. Ikadega has a naming convention for rings and the directions that messages travel on them. A chassis can connect to two rings called the top and bottom rings. On each of these rings, data may travel to other chassis in forward and reverse directions:

If a chassis only connects to a single ring, that ring still has these forward and reverse directions.

Note: The inter-chassis ring connections are implemented by a series of bi-directional ribbon cables connecting to chassis DirectPath controllers (DPCs).

On a fabric controller board, data from each ring and direction enters and exits through a particular switch element:


Input elements

Output elements

A

B

C C

D D

E

F

LVDS

B

A

B

E

F


switches


switches

LVDS

A

Top forward

Top reverse

Bottom forward

Bottom reverse

Top ring

Forward

Reverse

Bottom ring

Forward

Reverse



For example, incoming data from the forward direction of the top ring enters through the first switch element. Remember that each of these ring connections uses a “pseudo-node” in a switch element (as described in Linking to other fabric switches on page 13).

This drawing shows two rings connecting two chassis. Follow the arrows around to identify the bi-directional rings:

Note: This configuration might appear to be unnecessarily redundant, but the overall system is more reliable because there are more links between chassis. This arrangement also would have better performance because there are more pathways for sending data (at the cost of added connecting cable, which is inexpensive).

About FPGAs Much of the work in the DirectPath system is done by field-programmable gate arrays (FPGAs). An FPGA is a chip that can be re-programmed at run time by a PROM or another processor (more on that later). The earlier section Inside the system (page 7) mentioned that the input and output elements are FPGAs. The fabric interfaces, which connect the DirectPath Controller to the fabric at element C, are also FPGAs. These interfaces are on every board that connects to the fabric, including fabric controller boards, disk storage boards, and iNICs/decoder boards.

Forward direction, first ring

Reverse direction, first ring

Forward direction, second ring

Reverse direction, second ring



Below is a simplified view of a fabric controller board, showing the FPGAs and the processor that controls the board’s functions (again, the inter-element links aren’t shown):

Before it is programmed, an FPGA is essentially a collection of a huge number of gates. When programmed, the FPGA contains circuitry for a number of processing components, including multiple processor-like micro-engines:

Why does Ikadega use micro-engines here rather than general-purpose processors? There are speed and cost advantages to doing it this way. The micro-engines perform a limited number of relatively simple functions, so they can be special-purpose processors rather than general-purpose processors (like the meta-server). Special-purpose processors can be designed to run faster than general-purpose processors, and speed is of the utmost importance everywhere in the DirectPath system.

General-purpose processor

FPGA

Unprogrammed FPGA

……………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………

Vast array of gates

Programmed FPGA

Processing components,

including micro-engines

becomes:


Input elements

Output elements

A

B

C C

D D

E

F

LVDS

B

A

B

E

F

LVDS

A

Fabric interface

DPC Buffer

C Fabric



The cost factor is significant, too. Another approach for making a special-purpose processor is to design an application-specific integrated circuit (ASIC). However, it costs so much to produce a prototype ASIC that companies usually wait until its design is certain. Since the design of these components has changed frequently during the product development process, it’s much cheaper for Ikadega to use FPGAs at this point.

Board and node design

This section describes the types of boards currently available in the DirectPath system (other than the fabric controller and the backplane). These boards are unaware of the specifics of communicating with other boards – they only know how to communicate with the local DirectPath Controller. When boards need to send data to other boards in the system, the DPC and fabric are the only components that know where the destination board is. One effect of this is that the workings of the ITM protocol can change – indeed, they have changed during the product design phase – without affecting the board.

Disk storage boards

Disk storage boards (DSBs) handle all disk input and output. Their primary purpose is to read blocks of content data to send over the fabric to iNICs or decoder boards. The diagram below shows the node components.

ATA is an industry standard for communicating with disk drives. The indicator LED lights up to show activity on the board. The board-fabric interface engine is an FPGA (see About FPGAs on page 16 for more information on this). The temperature monitor is an important part of all boards. In the unlikely event of a board overheating (say because of a problem with a disk drive), the system can take the drive or board offline for a time to cool it down.

The external RAM is on the board but not in the processor itself.

Fabric Board-fabric

interface engine (BFIFE)

External RAM

Temperature monitor Indicator LED Board ID

ATA

Sub-node 0

Sub-node 1



IP access nodes

An IP access node is a combination of two boards:

• An intelligent NIC or iNIC (also called an IP access board or LAN/WAN card) sends digital content to external IP network users, using Ethernet ports to connect to the outside world (the Internet or an intranet), and

• An integrated server board (ISB) contains a supplemental processor that oversees the activities on the intelligent NIC.

In addition to the board-fabric interface engine, the iNIC’s FPGA also hosts the content transfer engine (CTE), which performs the normal sending of data from the disk storage boards to external users and vice versa. The CTE is a DirectPath subsystem – see Platforms on page 24 for more information.

A single intelligent NIC can support a large number of concurrent users – as many as tens of thousands. The data transfer work for this many users would overwhelm the supplemental processor, so the CTE sends the data directly to the Ethernet port by itself, without involving the supplemental processor. The processor only becomes involved in exception handling and other tasks that are more complex than simple data transfer, such as user session setup and maintenance.

Note: A chassis may have multiple iNICs, though early versions of the IP product do not.

Fabric

External RAM

Ethernet ports

Supplemental processor

Ethernet port

Outside world

BFIFE

Content transfer engine

External RAM

Intelligent NIC ISB



Analog access nodes

Like IP access nodes, the current product’s analog access nodes contain two boards acting together:

• A decoder board converts digital video image data to analog TV signals, and

• A decoder interface makes the signal available through the type of physical connector used by the customer.

The eight decoder sub-nodes each contain an MPEG video decoder, an audio decoder, a graphics accelerator, and a central processor. Most of this functionality comes from third-party chips installed on the decoder board.

There is a 1:1 correspondence between decoder boards and decoder interfaces. The boards plug into the backplane directly opposite to each other.

Fabric Board-fabric interface engine (BFIFE)

External RAMDecoder

sub-node 0

Decoder sub-node 7

Decoder board

. . .

Decoder IF

Cable plant



Supplemental processor nodes

Note: Supplemental processor nodes will not be in the DirectPath product until a future version.

One task of a supplemental processor is to oversee content transfer engines. (It also has other functions, as explained in the next section.) A future version of the system may include a supplemental processor by itself on a supplemental processor node:

About supplemental processors

In addition to overseeing the operation of content transfer engines, a supplemental processor can host these functions:

• Open source environment (OSE) – this is a conventional computing environment within the system. For more information, see Major subsystems on page 22.

• Manager – this is Ikadega’s application for configuring and managing the system. In the media server product, the Manager also processes the video playback commands (play, stop, pause, etc.). For more information, see Major subsystems on page 22.

• Server software – standard and commonly available Internet servers that run Web sites, send multi-media streaming data, and implement services such as FTP, NFS and Internet e-mail.

Chassis manager nodes

Note: Chassis manager nodes will not be in the DirectPath product until a future version.

A chassis manager node is an optional watchdog board whose purpose is to keep the hardware in a chassis working. The board is not involved in content delivery; it just monitors the hardware in its chassis. If it detects hardware that is working incorrectly, and if it’s a problem the board is equipped to handle, it fixes the problem. For example, if a DirectPath Controller’s boot image (the code the DPC runs at boot time) becomes corrupted, a chassis manager node could detect that the processor is not working correctly, re-load the image into the DPC’s flash memory, and initiate a system boot.

Fabric Supplemental processor BFIFE

External RAM



The Ikadega Manager application does not run on a chassis manager node, nor does any third-party software. System operators are not aware of the board – it’s a failsafe tool that can be accessed by field service personnel via the Internet or telnet (dial-up modem). There is at most one chassis manager node per chassis. This is the node’s internal structure:

Major subsystems

This section lists and describes the basic subsystems in the DirectPath design. The subsystems fall into three basic categories: application subsystems, core services, and platforms.

Application subsystems

The application subsystems are the highest-level components.

Internetdelivery Manager

Analogdelivery

These are the current application subsystems:

• Internet delivery – this subsystem sends content to IP users on the Internet or an intranet. It can support tens of thousands of concurrent sessions. Its most important components are the intelligent NICs and the integrated server boards (page 19).

• Analog delivery – a subsystem delivering digital video to a cable plant connected locally to the system, used in a hospitality application. Its key component is the analog access node (see page 20).

• Manager – in both IP and media server product applications (see System applications on page 4 for more information), system administrators use this component to configure and manage the system. In the media server, the Manager component also processes video playback commands (play, pause, stop, etc.).

As Ikadega applies its design to other uses and markets, there might be new application subsystems. For example, future versions of the product could add support for network-attached storage (NAS) and storage area networks (SANs).

Fabric Processor BFIFEEthernet port

Serial port



Core services The following services support the application subsystems. Each layer is at a lower level than the one above it.


File accessIP messagingVolume access

Traffic & array control

ITM

Analogdelivery

The core services are:

• File access – this allows DirectPath to access and work with directories and the smaller, more numerous files generally transmitted by the Internet delivery subsystem. Files have more attributes than volumes – items such as access permission data, modification and access dates, checkpoint information, etc.

• Volume access – this subsystem provides access to large files called volumes. A volume can be one large block of data (such as a digital movie or other rich content). It can also be a collection of the smaller, more numerous files processed by the file access subsystem, though the volume access subsystem sees this as a single volume.

• IP messaging – some applications need to communicate with IP-style messages rather than the ITM messaging used more commonly in the DirectPath system. This subsystem supports IP messaging, which is mostly needed by the media server version of the Manager, Web browsers running in the system, and anything else running in the open source environment (OSE).

• Traffic and array control – a subsystem that schedules and controls activity on the fabric and the array of storage devices. The subsystem, implemented mostly in software running in a DirectPath Controller, strives to fulfill all data transfer requests by their deadlines. It employs a number of strategies to make the most efficient resource use possible while overseeing the transfer of massive amounts of data.

• Ikadega Transport Mode (ITM) – ITM specifies the low-level details of how various components communicate with each other over the fabric.



Platforms Platforms support both the application subsystems and the core services:


File accessIP messagingVolume access

Traffic & array control

ITM

Platforms:

Content transfer engine (CTE)

Controller event engine (CEE)Open source environment (OSE)MPEG platform (MPP)

Analogdelivery

Core services

Application subsystems

Content transfer engine extension (CTEX)

The application subsystems are supported in different ways by both the core services and the platforms. Platforms run (execute the code of) the other components.

• Content transfer engine (CTE) – the main task of the CTE is to support the Internet delivery subsystem by overseeing the receipt and transmission of data to external network users. CTE is the platform for the Internet delivery subsystem – it executes Internet delivery’s code. The CTE runs in an FPGA on an intelligent NIC. It handles content independently, communicating with a supplemental processor only when there is an exception it cannot process.

• Content transfer engine extension (CTEX) – The CTEX is similar to the CTE. It runs in on a supplemental processor and supports the more complex protocol processing not handled by the CTE.

• Controller event engine (CEE) – the CEE is the platform on which several of the application-layer subsystems run. The subsystems it supports are file access, volume access, IP messaging, and traffic and array control. The CEE runs in a DirectPath Controller.

• Open source environment (OSE) – an environment within the system, complete with a conventional operating system, which runs traditional applications not coded for the DirectPath proprietary hardware. This includes the media server version of the Manager as well as various customer applications. The customer applications are not aware of any hardware or software outside the OSE.

• MPEG platform (MPP) – a platform that executes some functions of the analog delivery subsystem.



In the following table, a check mark ( ) indicates that a subsystem has objects that run in a particular platform.

Application component or core service

Platform CTE CTEX CEE OSE MPP

Internet delivery

Analog delivery * *

Manager * *

File access

Volume access

IP messaging

Traffic/array control * indicates that the application-layer component uses the platform’s services only to route

messages to other components. The component itself knows nothing about the data it routes.

For further information

Other documents have additional DirectPath overview information available. Instead, there is online Web-based documentation for each of the subsystems described in Major subsystems (page 22). This documentation contains everything from high-level overviews to low-level implementation details. Please see this Web-based documentation for more information about the product.



Index

A

accelerators, graphic, 20 access nodes. See also intelligent NICs

analog access nodes. See analog access nodes chassis slots used by, 8 IP access nodes. See IP access nodes

acknowledgement messages, 6 ad insertion, 3 analog access nodes. See also hospitality

applications and analog delivery subsystem, 22 components of, 7, 20 in media server systems, 8 introduction to, 5

analog delivery subsystem, 22 Analog delivery subsystem, 25 application subsystems, 22. See also core services,

platforms applications, for DirectPath, 4 application-specific integrated circuit. See ASICs array control. See traffic and array control subsystem ASICs, 18 ATA (disk access method), 18 attributes, of files, 23 audio decoders, 20

B

backplane, of chassis, 7, 8, 9 BFIFEs. See board-fabric interface engines blades. See boards blocks, of data, 6 board ID, on board, 18 board-fabric interface engines

and the fabric, 5 as FPGAs, 16 in IP access nodes, 19 on disk storage boards, 18

boards, in system. See decoder boards, decoder interfaces, disk storage boards, fabric controller boards, integrated server boards, intelligent NICs, PCI-LVDS interfaces, port extender boards

bottom rings, 15 browsers, Web, 23 buffers, in switch elements, 10, 12

C

cable TV providers, 3 cache memory, 5 cards, in system. See boards CEE. See controller event engine subsystem chassis manager nodes, 21 chassis, of system. See also rings

cooling of, 18 in IP systems, 7 in media server systems, 8 introduction to, 4 monitoring equipment in, 21

clear-to-send indicator, 12 communication, inside system, 9, 11 configuring a DirectPath system, 21, 22 connections, virtual or physical, 6 content files. See files content transfer engine (CTE) subsystem, 19, 24 content transfer engine extension (CTEX), 24 contiguous data storage, 4 controller event engine (CEE) subsystem, 24 conventional operating systems, 24 core services, of system, 23. See also application

subsystems, platforms CTEs. See content transfer engine subsystem CTEX. See content transfer engine extension CTS. See clear-to-send indicator customer applications, 24

D

data caching, 3 decoder boards

and analog access nodes, 20 and changes in ITM design, 18 buffers in, 12 FPGAs on, 16 function of, 7 introduction to, 5 where installed in chassis, 8

decoder interfaces and analog access nodes, 20 function of, 7 introduction to, 5 where installed in chassis, 8

decoders, 20 digital movies, 3



DirectPath Controllers (DPCs) and board-board communications, 18 and chassis types, 8 and fabric interfaces, 5, 16 and ITM changes, 18 and traffic/storage array control, 23 as disk activity schedulers, 6 as source of message parameters, 10 basic operation of, 5 how they connect to fabric, 5, 17 in the media server product, 7 introduction to, 5 what board they’re on, 7

DirectPath file system (DPFS), 23 DirectPath system

and Ikadega Transport Mode, 10 backplane of, 7, 9 changes for future versions, 4, 21 chassis of. See chassis configuring and managing, 21, 22 content transfer engines in, 19 disk drives of. See disk drives disk storage boards of. See disk storage boards documentation for, 1, 25 file system of, 23 FPGAs in. See FPGAs future versions of, 4, 21 how it works, 3 intelligent NICs of. See intelligent NICs introduction to, 3 IP version of. See IP product Manager application of. See Manager media server version of. See media server product non-blocking feature of, 6 number of users supported by, 4 online (Web-based) documentation for, 1, 25 performance of, 3, 16, 17 products of, 4 repairing hardware in, 21 rings in, 14 subsystems of, 22 temperature issues with, 18 uses for, 3

disk drivers, 18 disk drives. See also disk storage boards

keeping busy, 3 number of, on disk storage boards, 4 overheating of, 18 scheduling activity on, 23 status of, and scheduling, 6

disk shuttles. See disk storage boards

disk storage boards (DSBs) acknowledgement message sent by, 6 and changes in ITM design, 18 as double-width boards, 8 cache memory of, 6 chassis slots used by, 8 design of, 18 FPGAs on, 16 function of, 5 in the IP product, 4 in the media server product, 7 introduction to, 4

documentation, for system, 1, 25 double-width boards, 4, 8 DPCs. See DirectPath Controllers DPFS. See DirectPath file system DSBs. See disk storage boards

E

elements. See switch elements e-mail servers, 21 engines. See board-fabric interface engines, content

transfer engines, controller event engines, micro-engines

Ethernet ports, 19 expansion chassis, 8

F

fabric function of, 5 how DPCs connect to it, 5, 17 in the media server product, 7 introduction to, 4 scheduling activity on, 23

fabric controller boards (FCBs) as single-width boards, 8 chassis slot used by, 7, 8 communication pathways on, 9 communications with other switches, 13 components of, 17 FPGAs on, 16 how rings connect to, 14, 15 how they communicate with fabric, 5 in the IP product, 7 in the media server product, 8

fabric controllers. See DirectPath Controllers fabric interfaces. See board-fabric interface engines fabric switches. See chassis FCBs. See fabric control boards Fibre Channel product, 4



field-programmable gate arrays. See FPGAs file access subsystem, 23, 24, 25 files. See also volumes

and disk storage boards, 5 attributes of, 23 compared to volumes, 23 how accessed most often, 3 how delivered, 5 introduction to, 3

final main fabric row (parameter), 10 flow control, 12 forward (data travel direction), 15 FPGAs, 9, 16, 24 FTP, 3, 21 future versions, of the product, 4, 21

G

gates, 17. See also FPGAs general-purpose processors, in system, 17 graphics accelerators, 20

H

handshaking, in system, 12 hardware monitoring and repair, 21 heads, of disk drives, 6 hospitality applications, of system, 3, 4, 22 hotel applications. See hospitality HTTP, 3

I Ikadega Transport Mode (ITM), 10, 18, 23 indicator LEDs, 18 industry-std server platform (ISSP) boards. See

integrated server boards iNICs. See intelligent NICs input buffers, 6 input elements

and DPCs, 17 and inter-switch communication, 13 as FPGAs, 17 description of, 9 design of, 10

integrated server boards (ISBs) as an IP access node component, 19 introduction to, 5 subsystem they belong to, 22 where located in chassis, 8

intelligent NICs (iNICs) and changes in ITM design, 18

(continued)

intelligent NICs (iNICs) (cont.) and content transfer engines, 24 as an IP access node component, 19 buffers in, 12 cache memory of, 5 chassis slots used by, 8 FPGAs on, 16 function of, 5 introduction to, 5 subsystem they belong to, 22

interfaces. See fabric interfaces Internet delivery subsystem, 22, 25 Internet e-mail, 21 Internet, use of system on, 3, 21, 24 IP access nodes, 19. See also intelligent NICs IP messaging subsystem, 23, 24, 25 IP networks, 3, 22, 24 IP product, 4, 7 ISBs. See integrated server boards ISSP boards. See integrated server boards ITM. See Ikadega Transport Mode ITM-LVDS interface board, 8

L

LAN/WAN cards. See intelligent NICs LEDs, 18 low-voltage differential signal. See LVDS ports LVDS ports, 14, 17

M

main chassis. See chassis main fabric boards. See fabric controller boards Manager subsystem

and IP messaging, 23 and other subsystems, 22, 25 where it runs, 21, 24

media server product and IP messaging, 23 and the Manager, 21 components of, 7 inside the product, 8 introduction to, 4

messaging, IP. See IP messaging subsystem micro-engines, 17 mirroring drives, 4 movies, digital, 3 MPEG, 20, 22. See also analog delivery subsystem MPEG platform subsystem, 24 MPP. See MPEG platform



N

NAS. See network-attached storage network-attached storage (NAS), 3, 22 NFS servers, 21 nodes. See analog access nodes, chassis manager

nodes, IP access nodes, supplemental processor nodes

non-blocking feature, 6

O

online (Web-based) product documentation, 1, 25 open source environment (OSE), 21, 23, 24 operating systems, conventional, 24 OSE. See open source environment output elements

and inter-switch communication, 13 as FPGAs, 17 description of, 9 design of, 10

overheating, of system, 18

P

partitions, 3. See also content files PEBs. See port extender boards performance, of system, 3, 16, 17 physical connections, 6 platforms, for subsystems, 24. See also application

subsystems, core services port (message parameter), 10 port extender boards (PEBs)

as single-width boards, 8 in the IP product, 5, 8

processing components, in FPGAs, 17 processor, supplemental. See supplemental

processors products, of DirectPath line, 4 protocols used in system, 10 pseudo-nodes, 14

Q

QuickTime, 3

R

read operations, from disk, 3 real-time streaming protocol (RTSP), 3 rear transition boards. See port extender boards reference software. See server software

repairing hardware, 21 reverse (data travel direction), 15 rings, 14, 15 RTBs. See port extender boards RTSP. See real-time streaming protocol

S

SANs. See storage area networks seek time, 6 server software, 21 sessions, with DPC, 6 shuttles. See disk storage boards single-width boards, 8 special-purpose processors, in system, 17 storage area networks (SANs), 22 storage array control. See traffic and array control

subsystem storage nodes. See disk storage boards sub-nodes, of disk storage boards, 4, 18 subsystems, of DirectPath, 22 supplemental processor nodes, 21 supplemental processors, 19, 21, 24 switch elements

and inter-switch communication, 13 connection to boards, 9 design of, 10 introduction to, 7

switched fabric. See fabric

T

temperature monitors, 18 top rings, 15 traffic and array control subsystem, 23, 24, 25 TV access nodes. See analog access nodes TV delivery subsystem. See analog delivery

subsystem

V

virtual connections, 6 volume access subsystem, 23, 24, 25 volumes, 23. See also files

W

WAN cards. See intelligent NICs Web browsers, running in system, 23 Web delivery. See Internet delivery subsystem write operations, to disk, 3

WatsonBruce Ikadega sample 2

Documents

Transcript of WatsonBruce Ikadega sample 2