1394 Standards and Specifications Summary Michael D

1394 Standards and Specifications Summary Michael D. Johas Teener Chief Technical Officer Zayante, Inc. 269 Mt. Herman Rd. #201 Scotts Valley, CA 95066-4000 [email protected] Introduction

With the quickening introduction of products based on IEEE 1394 (Firewire or iLink depending on your religious preferences) has come a proliferation of specifications, standards, architectures, and guidelines for these products. This article is intended to be a guidebook to those various documents, with an emphasis on how they should be applied to design and build products. There are two parts to this paper: a summary of the standards and some idea of their relationship with each other, and a detailed listing of the standards themselves along with appropriate references. This detailed listing is maintained by Burke Henehan, the 1394 HW Engineering Lead at Texas Instruments ([email protected]), with help from the author of this paper. Any corrections to this paper are gratefully solicited, and should be sent to both the author and Mr. Henehan.

Why so many 1394 specifications?

At last count, there were over 70 documents that attempt to define the characteristics of 1394-based devices. This is not necessarily an indication of complexity, it is instead an indication of the vast number of applications of 1394. There are, in fact, only a few specifications that all designers must be aware of: the original IEEE 1394-1995 document and its “a”, “b”, and “dot one” extensions as well as IEEE 1212-1991 (ISO 13213) and its revision. The other 60-odd specifications cover the various applications of 1394, particularly in the consumer electronics and PC product spaces.

HAVi, UPnP content protection, “5C” VHS AV/C panel AVC audio AVC DVD tuner AVC DV D8 MD CD HD PC 99, MacOS platform specs Device Bay Device Open HCI Open DPP IP/1394 RBC PWG AV/C tape AV/C disk recorder

SBP-2 AV/C general IEC 61882 1-5

IEEE 1394-1995, P1394.1 P1394a, P1394b IEEE 1212, p1212r

Figure 1 Overview 1394 specification structure Ð note that many more specs exist

The primary specification for 1394 is the original IEEE 1394-1995 document. It specifies the architecture and fundamental transport services, along with a host of lower-level details including physical specifications of the standard 6-pin connector, test specifications, detailed timing and signal levels, and bus management. This document is over 400 pages long, and is largely self-contained. The one exception is the addressing and common register architecture, which is ISO 13212 (but largely known by its previous name, IEEE 1212-1991). Some of the 1394 concepts depend on 1212, particularly the addressing and configuration ROM (used by bus management) architecture. These two documents were the basis of the first actual implementations, but a number of shortcomings and inconsistencies were discovered in both (particularly in 1212), and so a small number of follow-on projects were started shortly after 1394 became an official standard in 1995.

P1394a: basic improvements

The first of these documents is known as “P1394a” (the “P” means that it is a project, not a completed standard). This is a supplement to the original Ð1995 document, with both improvements and corrections. The improvements include: 1. Arbitration accelerations which greatly improve efficiency of the bus, particularly in smaller systems (fewer than 63 nodes). 2. Reset improvements which greatly reduce the disruption caused when nodes are added and removed from the bus. 3. Support for fine-grained power management which is particularly useful in portable computing applications. A number of other important changes are part of the p1394a document, including specification of the 4-pin connector and vastly improved specification of the PHY-Link interface (most 1394 implementations have separate PHY and Link Ics, and interoperability between PHYs and Links of different vendors was viewed as an important feature). The IEEE is about to start second ballot of the draft document, and we expect it to be approved this year.

P1394b: new technology

Shortly after the P1394a project started, a number of companies in both the consumer and PC space stated their desire to improve both the speed and reach of a 1394 interconnect. The P1394b working group was formed to address those requirements. The existing P1394b draft specifies the following features: 1. Speeds up to 1.6 Gbit/sec, with architectural changes that allow future specifications to go over 3.2 Gbit/sec. 2. Node-to-node distances to over 100m using various media. 100 Mbit/sec is supported for category 5 unshielded twisted pair (CAT-5 UTP), 200 Mbit/sec over plastic optical fiber, and a full 3.2 Gbit/sec using 50 µm multimode glass fiber. 3. Cost reductions over the existing 1394-1995 and p1394a implementations are possible since the new “pure beta” mode specified by P1394b allow simple galvanic isolation, greatly reducing the complexity of the analog circuitry and allowing simple integration of the PHY and Link components. 4. The “pure beta” copper connector is almost as small as the existing 4-pin connector, yet is capable of carrying power, indicating speed capabilities of the media, and is capable of carrying a full 3.2 Gbit/sec signal. The current draft (0.70) is quite stable, and the working group expects to forward the document to the IEEE for balloting early next year. There are already a number of test implementations of quite high sophistication. Lucent has demonstrated a “bilingual PHY” at 800 Mbit/sec (“bilingual” means that it will

© 1999Zayante, Inc. Permission to copy granted so long as this notice is retained. Page 2 connect both in the existing data-strobe signaling method used in the existing specs and in the “beta mode” signaling method invented for P1394b, Omneon Video Networks has demonstrated a 300 meter 800 Mbit/sec connection using multimode glass fiber, and NEC has shown a plastic optical fiber system as well. Almost-production-ready systems will be demonstrated later this year and early the next, with full production of both home-network-based S100 and S200 systems and professional 800 Mbit/sec and 1.6 Mbit/sec versions a year later.

P1394.1: networks!

Another in the series of fundamental specification upgrades is P1394.1, which specifies the connection between multiple 1394 busses. This allows more than 63 nodes to be communicating with each other, and also allows high-bandwidth subnets to be clustered together without affect the performance of the overall interconnect. Another nice attribute of P1394.1 is that bus resets and other management traffic tends to be isolated within a single bus. The basic model for P1394.1 is a “two portal” bridge, where multiport bridges appear to be multiple two portal bridges from a protocol point of view. There is a lot of work left to do on P1394.1, so we do not expect stability until late 2000!

P1212r: fixing the foundation

One of the major difficulties with building a 1394-based product using existing standards is that the 1212 document is wrong in some details and, more importantly, conflicts with both IEEE 1394-1995 and existing practice. This has led to a number of misinterpretations, which has slowed the introduction of several products, including the 1394 support for the major computer platforms. To address these concerns, the IEEE reconstituted the 1212 working group to make a major revision to that document. These revisions include: 1. Configuration ROM updates with improved functional descriptions, using feature and instance directories and extended keys. These allow many of the application-based specifications to extend the configuration ROM formats without confusion. The configuration ROM descriptions have also been vastly improved for readability. 2. Many of the specifications for standardized registers have been updated to match existing practice, both in the various 1394x drafts and products in the field.

Application-based specs

The other broad category of specifications are those that are particular to a single application area. In 1394, there are two major applications: consumer electronics and computers. Most of the rest of this section discusses those areas, but there are a number of new applications that may become important in their own right, and will be lightly covered at the end of this paper.

Consumer-based

The initial high volume applications of 1394 were in consumer digital video, and most of the consumer- based specifications can be traced back to the original “DVC blue book” which defined how the first DV camcorders were controlled using 1394, and the format of the data packets transmitted on 1394. This large group of specifications is known as the “AV/C” specs (for “Audio/Video Compatibility”). Also needed in much of the consumer space are the content protection specifications. With the advent of digital media, perfect copies are now readily possible, unless a combination of technical and legal safeguards are provided. One of the original planned applications for 1394 was the direct connection between imaging devices, such as cameras and printers, and scanners and printers. The “Direct Printing Protocol” (DPP) has been invented to meet that requirement.

© 1999Zayante, Inc. Permission to copy granted so long as this notice is retained. Page 3 Finally, there is are attempts to unify all of the consumer devices in a true distributed processing system. HAVi and Universal Plug and Play fall into this category.

AV/C is world of its own!

In the AV/C world, there are 30 specs so far, and the end is not in sight! Most of this is due to the vast number of planned 1394 consumer devices, but this is still and extremely large number! How are we going to test all this for interoperability? Fortunately, some work is going on to converge on device classes… for example, all the various camcorders and VCRs are being combined into a “tape recorder” class along with possible future audio recorders, and the various mass storage devices such as CDs, DVDs, MDs, and hard disks have been combined into a “disk” class. All this is basically a good start with a simple fundamental design and some promising future directions, particularly the “general object descriptors” defined in the latest master spec: “AV/C General 3.0”. These provide universal ways to describe both static and dynamic characteristics and controls of devices. Unfortunately, the descriptors are not well described, and there is considerable confusion about exactly how they are used. This has the effect of different AV/C working groups selecting different (and not entirely compatible) ways to use the descriptors … and even leading the camera group to propose an entirely different way to provide a directory. We believe this is a temporary condition, as the leaders of the AV/C community are aware of the problem and are starting to address the problem.

Content protection

A particularly important set of standards are those that provide content protection. Since 1394 provides a powerful all digital interconnect, it is possible to do simple and very high speed perfect copies of any information. This is unacceptable to many of the content providers, so there has been a strong effort to come up with a way to provide copy controls that are strong enough for the providers, yet convenient for the consumers and low cost for the equipment makers. The leading alternative is the so-called “5C” proposal, called that because five companies (Intel, Hitachi, Sony, Matsushita, and Toshiba) joined their various proposals together in a legal/technical structure to meet the needs of both consumer electronics and the PC industry. The technology, a combination of encryption and key management, is implemented without too much difficulty or excessive memory or logic requirements. Since much of the protection structure is based on legal systems, the technology is strongly protected by a number of patents. These patents can be licensed in a very straight-forward way, with the primary requirement being design rules for products that will not allow the decrypted content to be easily copied. Products using the 5C technology will require both hardware and software changes, but the good news is that but no changes are needed to the 1394-specific software or hardware. The main competition for 5C is a Zenith/Thomson proposal called XCA. Unlike the 5C design, XCA uses a smart card for validation/billing. This is not a very popular option in the USA, since external validation systems universally fail in the marketplace (the recent DIVX format is a good example). There are a number of other alternatives for content protection, but they are not receiving much support.

Direct Printing Protocol

One of the more interesting standards for consumer products is the direct printing protocol (DPP). Originally developed by a number of Japanese firms led by Canon, FujiFilm, Fuji Xerox, and Sharp. It provides a symmetric, peer-to-peer data transport along with a scalable image model. A full demonstration of this protocol was shown recently in Japan with a scanner, camera, printer, multifunction imager, and PC all interconnected.

One of the more promising developments is the effort to create a lightweight distributed object system appropriate for consumer electronics. There are two primary efforts: HAVi and UpnP. HAVi (“Home Audio Video interoperability”) is led by 8 consumer electronics companies: Grundig, Hitachi, Matsushita, Philips, Sharp, Sony, Thomson and Toshiba. They have defined a set of APIs and associated protocols that have the potential of providing a fair amount of “future proofing” consumer devices. Recently, the HAVi consortium has teamed with Sun’s Jini for a fully dynamically-bound distributed object system. Microsoft’s UpnP (“Universal Plug and Play”), on the other hand, does not necessarily define APIs. Instead, it defines a set of protocols based on existing and proposed IETF (internet) standards. The current versions of the specification only have details for IP-based networks (requiring all participating devices to support an internet protocol stack), but direct 1394 versions are likely in the near future. Even though HAVi and UPnP have sometimes been seen as competitors, and in some ways, they are (they use wildly different registration, discovery, and messaging protoocols … and UPnP doesn’t provide a Java- based “universal driver” scheme), but they serve somewhat different markets and have somewhat different goals. It is likely that there can be bridging between the two, and the creation of the bridging technology may be cooperative between the two sponsoring organizations. Regardless of which distributed system is implemented, it is going to be a big job to get it working, but once it’s done, support for new devices becomes much easier, much more “future-proof”.

PC Specifications

There are two primary categories of specifications for PC applications: platform specs, and general standards. The platform specs are generally lists of applicable standards and details of their use for particular operating systems. The most complete specifications are available from Microsoft and Apple. Both companies are shipping extensive support for 1394 in their latest OS’, Windows 98 SE and MacOS 8.6. The general specifications are architectures for communication with other devices, and the primary two are SBP-2 for typical peripherals such as printers, scanners, and mass storage; and IP/1394 for peer-to-peer networking using legacy internet protocol higher layer services. A special type of general specifications are interface standards which define software, hardware, and/or mechanical interfaces for PC implementations of 1394. The two most prominent interface standards are the 1394 OpenHCI and DeviceBay.

SBP-2

SBP-2 (“Serial Bus Protocol”, 2nd version)is the best model for computer peripherals. Its use is strongly preferred by both Microsoft and Apple, largely because it greatly reduces interrupt load on the CPU, and provides a scalable DMA model. The general architecture provides a command and data transport mechanism that exports the command processing and queuing to the peripheral, effectively making each device a powerful scriptable DMA device. This is done by mapping some area of the CPU’s memory directly to 1394’s memory space, building a linked-list of commands and pointers to data buffers in that area, and then giving the address of that list to the device. The device then reads the commands directly from the CPU and takes the appropriate action, including reading data from or writing data directly to CPU memory. The actual command format is not specified in SBP-2. That is left to more device-specific documents.

RBC for mass storage

The RBC (“Reduced Block Commands”) document describes a subset of SCSI commands used for mass storage devices. It provides the same kind of logical block addressing and commands used by all modern

© 1999Zayante, Inc. Permission to copy granted so long as this notice is retained. Page 5 computer systems. Indeed, the mass storage devices already in use for Mac OS 8.6 are RBC devices, and Windows 98 and 2000 provide a disk class driver for 1394 that also uses RBC for disks.

PWG for imaging peripherals

The other major use for SBP-2 is for imaging peripherals. The “Printer Working Group” in the USA has defined a data and command transport using SBP-2.This is a particularly interesting specification since it demands fuller use of SBP-2 services that does RBC. Since printers are more likely to require asynchronous notifications (“paper out”, “printer jam”, “ink reservoir empty”, etc), a peripheral has to keep track of both notification buffers and the command/data buffers. Microsoft has endorsed this concept, writing a printer class driver that takes advantage of SBP-2. Until recently, the PWG has not defined the details of the commands or data, since they wanted to make use of the existing legacy formats … and there was considerable resistance to standardizing on one command set. There have been recent moves, however, to reconsider the idea of common commands and image formats, similar to the approach used by the DPP community.

IP/1394

The IP/1394 specification details how to carry internet protocol (IP) streams on 1394 busses. It currently specifies IPv4 only, but also specifies how DHCP works on 1394 (so that devices can dynamically get their IP numbers). The standardization of this document will be complete in 1999, with interoperability demos scheduled for November.

Sidebar: A note on printing

The astute reader will note that we have three possible protocols for printing: DPP, SBP-2, and AV/C … and it’s even possible to add IP printing to the mix. Did this have to happen? Probably it did. This is one of those cases that product schedules got ahead of the standards process. The three protocols all were defined in the last year or so: 1. PCs need a memory mapped buffer model to reduce interrupt processing. They require the printer to do scheduling, fetching of image and commands. The PC O/S must organize buffers and commands, and cannot do command-by-command processing requiring interrupts. There are lots of legacy image formats and command sets, but PC users accept the need to have custom drivers for each printer (even if they don’t like it). This meant that the PC community spent all its time working on an efficient master-slave protocol, but not on imaging formats. 2. On the other hand, consumer devices needed peer-to-peer processing (typically each image source only has to talk to one image sink at a time). They also needed a common image and command model, because the typical camera customer would not be sympathetic to needing device drivers (FujiFilm and Kodak and Afga decided long ago to use the same developer chemistry for this very reason). The data transport for these printers needed to send large amounts of data asynchronously, and there was no such mechanism in AV/C, so they had to invent a whole new protocol: DPP. 3. Once the AV/C people got their camcorders going and were looking at building more sophisticated systems, they quickly agreed that they needed a printer model … but they didn’t want to use an incompatible connection and command model, such as DPP. So they developed (somewhat later) a different bulk asynchronous data transport mechanism, and an associated printer command set. Damn. Now we have three different printer protocols. That’s life in the real world.

OpenHCI

The OpenHCI effort grew out of Microsoft’s frustration with all the drivers that need to be written to support the various I/O interfaces. SCSI and Ethernet, for example, typically require a custom driver for each of the adapters provided by the various vendors. Since 1394 is intended to be a motherboard

© 1999Zayante, Inc. Permission to copy granted so long as this notice is retained. Page 6 implementation, Microsoft wanted to use a single programming model to access all link-layer implementations. In order to do this, Microsoft joined with Compaq, DEC, Apple, Sun and Intel to write a standard interface document. Perhaps because all of the participants were engineers, the effort was remarkably successful and produced a detailed 1.0 document within a year. There are now a multitude of highly interoperable OpenHCI implementations, and there is even an effort to update the document to a 1.1 version to improve performance and remove ambiguities.

Device Bay

Another interface specification is Device Bay, which defines how to build user-replacable modules with 1394 and USB interfaces that directly insert into a PC or similar-sized desktop system. The Device Bay specifications are complete and a wide variety of prototype systems and peripherals have been demonstrated. A smaller version, “CardBay”, that uses PC-card mechanical specs (like CardBus) is also under development.

Other specs

There are three new areas of promising work on 1394 specifications: industrial, instrumentation, and automotive.

Industrial

In the industrial regime, most of the work has been done with vision systems. In fact, one of the original 1394 products was Sony’s DCM 250 industrial video camera. These industrial cameras provide variable format uncompressed video streams appropriate for quality control and other machine vision systems. Some additional work has started on robotic systems, but there have been no public proposals yet.

Instrumentation

One of the more natural further applications for 1394 is as a replacement for the very expensive and very slow IEEE 488 General Purpose Interface Bus that is heavily used in the instrumentation industry. There is a fast-moving effort in the 1394 Trade Association that is defining how the IEEE 488.2 command structure can be transmitted using 1394. To our great delight, the people working this document have chosen not to invent a new protocol, and are making a conscious effort to work with the AV/C asynchronous connections working group to define a common protocol.

Automotive

Automotive applications are taking advantage of three developments: 1) the large number of home entertainment systems using 1394 can be easily adapted to a automotive environment, 2) the instrumentation people are defining protocols that would ideal for diagnostics and servicing of the very digital-electronic-intensive nature of new cars, and 3) the new p1394b media choices are more appropriate for the difficult electrical and physical environment in automotive applications. Detailed listings

The following pages provide a detailed listing of standards, grouping those standards for particular product areas:

Table 1

Name Abstract Who needs it? Status More information

IEEE 1394-1995 Mother of all 1394 Everyone doing any Released, supplemented IEEE web page: Standards, defines 1394 by P1394a http://standards.ieee.org fundamental /catalog architecture, services, hardware and software partitioning, etc

IEEE P1394a Enhancements and Everyone doing 1394 In Ballot Review, ftp://ftp.symbios.com/p Supplement corrections to 1394- preliminary products ub/standards/io/1394/p1 1995, especially to available, expected 394a physical layer, power approval this year management, and software details

IEEE 1212 or IEC Control and Status All 1394 uses it, but Released, in periodic http://standards.ieee.org 13213 Register Standard. primarily software update (1212r) /catalog Used by 1394. driver writers need a copy

IEEE 1212r Extensive update to All 1394 uses it, but In Committee http://www.zayante.co Control and Status only software driver m/p1212r Register Standard 1212 writers need it. This is a very important update, everyone should have a copy

1394 TA Power Spec Describes how nodes All 1394 Nodes Submitted to 1394 TA http://www.1394- Part 1: Cable Power should supply, limit, for acceptance pcwg.org/ Distribution pass, and consume cable power from 1394 cables for multiple ports

1394 TA Power Spec Describes how the Phy designers, Power Submitted to 1394 TA http://www.1394- Part 2: power saving Management SW pcwg.org Suspend/Resume mechanisms of writers suspend/resume should be implemented and used.

1394 TA Power Spec Describes the Model to System designers, Node In committee http://www.1394- Part 3: Power State be used for managing SW writers pcwg.org Management power states within a 1394 node and across a 1394 bus.

Table 2

Name Abstract Who needs it? Status More information

IEEE P1394b Higher speed, longer Profession video/audio, In committee, to http://www.zayante.co distance version of PC high performance, stabilize this summer, m/p1394b 1394, can be backward home/multimedia ballot to start in 2000 compatible with 1394a, networking, industrial will minimize changes control, instrumentation above PHY

IEEE 1394.1 Bridging Issues and Home network devices, In committee http://grouper.ieee.org/ standardization of industrial devices, etc groups/1394/1/ requirements for bridging one 1394 bus to another 1394 bus

Standards for Digital Video Consortium (DVC) Video

Table 3

Name Abstract Who needs it? Status More information “DVC Blue Book”: Companies designing Complete, but ??? Standard for HW and DVC software that somewhat obsolete, protocols used for must be compatible IEC 61883 and 61834 Digital Video with older devices are updates Consortium Devices IEC-61883 Part 1 Standard that Transport of Released http://www.iec.ch/cs1oi describes: Isochronous isochronous data when -e.htm Plug Control Registers, using AV/C, DVC, Connection MPEG, AMP Management Protocol (CMP), Function Control Protocol (FCP), Common Isochronous Packet (CIP) headers

IEC-61883 Part 2 Standard that describes Devices transporting Released http://www.iec.ch/cs1oi SD-DVCR Transport SD-DVCR over 1394 -e.htm Protocol across 1394 (current camcorders) IEC-61883 Part 3 Standard that describes Devices transporting Released http://www.iec.ch/cs1oi HD-DVCR Transport HD-DVCR over 1394 -e.htm Protocol across 1394

IEC-61883 Part 4 Standard that describes Devices transporting Released http://www.iec.ch/cs1oi MPEG Transport MPEG over 1394 -e.htm Streams (TS) (including (Digital TV, STB, etc) DVB TS) across 1394

IEC-61883 Part 5 Standard that describes Devices transporting Released http://www.iec.ch/cs1oi SDL-DVCR Transport SDL-DVCR over 1394 -e.htm Protocol across 1394 (High compression DV) IEC-61883 Part 6 Standard that describes Devices transporting Released, updates http://www.iec.ch/cs1oi Audio/Music Transport formatted Audio or proposed -e.htm Protocol across 1394 Music streams over 1394

© 1999Zayante, Inc. Permission to copy granted so long as this notice is retained. Page 9 Name Abstract Who needs it? Status More information AV/C General Defines general Home audio/video Accepted by 1394 TA http://www.1394ta.org/ Specification commands used to devices, SW driver (version 3), updates Technology/specificatio control consumer writers. proposed ns audio/video electronics. Utilizes 1394 Unit architectures. AV/C VCR Subunit Enhancements to AV/C AV/C DVC Camcorder Accepted by TA, http://www.1394ta.org/ for an AV/C controlled and VCR vendors, SW updates proposed, Technology/specificatio VCR. More documents driver writers. replaced by Tape ns for extensions for Recorder subunit DVHS

Standards for MPEG Video

IEC-61883 section 1 & 4 (see Table 3) Digital Content Protection (see Table 6) AV/C General Specification (see Table 3) Table 4

Name Abstract Who needs it? Status More information DSS Transmission on Standard that describes Devices that transport To be voted by 1394 http://www.1394ta.org 1394 MPEG2-TS (DSS DSS MPEG2 over 1394 TA AVWG members only section Transport Stream) (Digital TV, STB, etc) across 1394

Standards for Digital TV

All Standards for MPEG (see Table 3) All Standards for DV (see Table 3) Table 5

Name Abstract Who needs it? Status More information CEMA R4.8 1394 Describes the digital Designers of Digital Released http://www.tiaonline.or Interface Subcommittee interconnection TVs and 1394 devices g/standards/ required for Digital TV that source digital data to digital TVs CEMA R4.8 1394 Report documenting Designers needing a Draft Report in http://www.cemacity.or Interface SC, Copy amendments needed to comparison of copy committee g/works/comm/avcis Protection WG2 EIA-775, 761 and 762 protection schemes needed by each of the CP approaches. Effect of the CP approaches on CE devices.

AV/C Tuner General AV/C controls for Devices doing video Accepted by TA, http://www.1394ta.org/ Model analog and digital video tuning controlled across updates proposed Technology/Specificati tuners, several 1394 ons subdocuments cover different modes. AV/C Tuner DVB AV/C control Devices doing DVB Accepted by TA http://www.1394ta.org/ Video Model enhancements for video tuning controlled Technology/Specificati digital video broadcast across 1394 ons (DVB) video tuners

© 1999Zayante, Inc. Permission to copy granted so long as this notice is retained. Page 10 Name Abstract Who needs it? Status More information AV/C Tuner DSS AV/C control Devices doing DVB In work http://www.1394ta.org/ Video Model enhancements for video tuning controlled members only section digital satellite system across 1394 (DSS) video tuners AV/C Tuner Analog AV/C control Devices doing analog Accepted by TA http://www.1394ta.org/ Video Model enhancements for video tuning controlled Technology/Specificati analog video tuners across 1394 ons/index.htm

AV/C Tuner Analog AV/C control Devices doing analog Accepted by TA http://www.1394ta.org/ Audio Model enhancements for audio tuning controlled Technology/Specificati analog audio tuners across 1394 ons/index.htm AV/C DTV Command AV/C control CMDs DTV designers and SW In work http://www.1394ta.org/ General Model enhancements for driver writers Technology/Specificati digital TVs ons/index.htm

Copy Protection

Table 6

Name Abstract Who needs it? Status More information “5C” Digital Third party licensing All silicon providers Demonstrated ins http://www.dtcp.com/ Transmission Licensing authority created to and end equipment working silicon, Authority license the Intel, Sony, makers wishing to proposed to R-4.8, has Matsushita (MEI), implement the “5C” (5 issued keys, setting up Hitachi and Toshiba company) copy plugfests, etc. (“5C”) digital protection for content transmission copy protection of video and protection mechanism. perhaps audio. “XCA” Digital Copy protection All end equipment Demonstrated, http://www.cemacity.or Transmission Copy mechanism that utilizes makers wishing to proposed to R4.8 g/works/comm/avcis Protection Mechanism “smart cards”. implement the “XCA” copy protection mechanisms.

“OCPS” Digital Proposed Open Copy Silicon providers and Proposed to R4.8 http://www.cemacity.or Transmission Copy Protection system with end equipment makers g/works/comm/avcis Protection Mechanism. only 1 token IP wishing to implement component for license this copy protection purposes. Uses DES system. encryption.

“NDS” Digital Copy protection Silicon providers and Proposed to R4.8 http://www.cemacity.or Transmission Copy mechanism by NDS. end equipment makers g/works/comm/avcis Protection Mechanism wishing to implement this copy protection system. “MRJ” Digital Copy protection All silicon providers Proposed to R4.8 http://www.cemacity.or Transmission Copy mechanism by MRJ. and end equipment g/works/comm/avcis Protection Mechanism makers wishing to implement this copy protection system.

AV/C Conditional Provides the Nodes requiring Accepted by 1394 TA http://www.1394ta.org Access Subunit functionality for an conditional access members only section AV/C Unit to descramble video/audio streams

P1394a (see Table 1) Table 7

Name Abstract Who needs it? Status More information

Personal Computer Proposed 1394 Computer vendors Available from Intel & http://www.microsoft.c Design Guidelines requirements for Microsoft om/hwdev/desguid.htm 1999, Chapter 8 personal computers from Microsoft & Intel

Intel Mobile Power Proposed Power Mobile computer Available from Intel http://developer.intel.co Guidelines 2000 budgets for mobile vendors m/design/mobile/Intelp computers ower/int_mpg.htm 1394 Plug & Play Design reference to aid Computer peripheral Published by Microsoft http://www.microsoft.c Specification consistent vendors, SW writers om/hwdev/respec/pnps implementation of pecs.htm devices compliant with IEEE 1394 to ensure interoperability Open Host Controller Defines common Silicon vendors, SW Released, version 1.1 ftp://ftp.austin.ibm.com Interface v1.0 register sets and writers to chips close /pub/chrptech/1394ohci services for a generic compliant to OHCI. host controller using DMA. Most implementations use PCI

Open Host Controller Update to OHCI 1.0 OHCI Silicon vendors In committee ftp://ftp.austin.ibm.com Interface v1.1 including standard and SW writers /pub/chrptech/1394ohci power management mechanisms, refinements to operation, and clarifications to OHCI 1.0

Serial Bus Protocol 2 A transport protocol Computer peripherals Released through T10 ftp://ftp.symbios.com/p (SBP-2) for asynchronous or other heavy ub/standards/io/x3t10/d commands or data, now asynchronous data rafts/sbp2/ widely adopted by users computer peripherals.

1394 Printer Working Provides the details to 1394 Imaging Devices In committee (PWG) http://www.pwg.org/p1 Group (PWG) Imaging utilize the SBP-2 394/index.html Device Communication transport protocol for Specification printers, scanners, and other imaging devices Device Bay Architecture to easily PC vendors, PC Submitted to TA for http://www.device- upgrade and customize peripheral vendors standardization bay.org/ PCs. Upgrading a computer is as easy as inserting a tape in a VCR. Remote Device Bay USB based device bay PC peripheral vendors, Released http://www.usb.org/dev Controller controller class SW writers elopers/ specification. Directed toward remote device bay implementation (separate box).

© 1999Zayante, Inc. Permission to copy granted so long as this notice is retained. Page 12 Name Abstract Who needs it? Status More information CardBay PC Card slots Future portable Initial requirements http://www.devicebay.o supporting both IEEE computer and specification. rg 1394 and USB in the lightweight peripheral existing 68-pin designers Mr. Ken Stufflebeam connector. May be (mailto:ken.stufflebeam backwards compatible @compaq.com) is the with CardBus. Chair of the CardBay Working Group in the PCMCIA.

Standards for Mass Storage

SBP-2 (see Table 7) AV/C General Specification (see Table 3) Table 8

Name Abstract Who needs it? Status More information Reduced Block RBC provides a Storage Devices using Released through T10 ftp://ftp.symbios.com/p Commands (RBC) command set of SBP2 committee ub/standards/io/x3t10/d reduced requirements rafts/rbc from SCSI CMDs The initial focus is devices attached to the IEEE 1394 Bus and utilizing SBP-2.

AV/C disk general Enhancements to Disk storage using In committee http://www.1394ta.org specification AV/C for mass storage AV/C commands members only section disk units AV/C MiniDisk subunit Enhancement of AV/C Minidisk devices In Committee http://www.1394ta.org disc model for minidisk utilizing AV/C members only section format. commands

AV/C hard disk drive Enhancement of AV/C Hard disk devices In Committee http://www.1394ta.org subunit disk model for hard utilizing AV/C members only section disk drives format. commands AV/C compact disk Enhancement of AV/C Compact Disk devices In committee http://www.1394ta.org subunit disc model for compact utilizing AV/C members only section disk format. commands

AV/C storage object Abstraction of a Disk devices utilizing In committee http://www.1394ta.org descriptor subunit descriptor for storage AV/C commands members only section class devices

More specifications

Table 9

Name Abstract Who needs it? Status More information

Direct Printing Protocol to enable peer Nodes doing peer to Accepted by 1394 TA http://www.1394ta.org/ Protocol to peer connections for peer printing or Technology/Specificati image sources and sinks communicating with ons and nodes that do peer to http://www2.tokyoweb. peer printing or.jp/ieee1394pwgc

© 1999Zayante, Inc. Permission to copy granted so long as this notice is retained. Page 13 Name Abstract Who needs it? Status More information Internet Protocol over Defines the transport of Devices using IP over Submitted for 1394 Internet Protocol 1394 publication to IETF http://www.ietf.org/htm Version 4 (IPv4) l.charters/ip1394- datagrams. Defines the charter.html necessary methods, data structures and codes. Also DHCP protocols.

Open Cable Digital Cable Television Set-top Box makers In review http://www.opencable.c STB Std Laboratories has om/ specified IEEE 1394 as the link between OpenCableª digital set- top boxes and devices such as TV sets and DVD players

Home Audio Video lightweight distributed Next generation Beta 1.0 spec complete, http://www.havi.org Interoperability object system for CE & consumer electronic final expected this year Architecture (HAVi) computing devices, devices and associated highly compatible with infrastructure current generation AV/C devices

HAVi Command This document that Devices using the In committee http://www.1394ta.org Transaction Set (CTS) defines the allowable HAVi Architecture members only section, Command set codes to http://www.havi.org be used with HAVi, i.e. a list of acceptable sets. Universal Plug and Set of of specifications Smart devices Largely existing IETF http://www.upnp.org Play (UPnP for registration, connected in a standards, but dynamic discovery, and Microsoft environment. discovery and communication between Potentially useful in a registration protocols devices in a local much wider space. are new. network. Details only exist for IP networks, but direct 1394 attachments are proposed. 1394 Digital Video Defines the functions, Designers of DV Accepted by 1394 TA http://www.1394ta.org/ Conferencing Camera services, and registers of Conferencing cameras, (updated to 1.2, further Technology/Specificati Specification an uncompressed digital and SW driver writers updates proposed ons video conferencing for DV Conferencing camera cameras.

AV/C Asynchronous Provides a means of devices that need to Accepted by TA, http://www.1394ta.org/ Connection making, breaking, and interoperate with AV/C updates proposed Technology/Specificati Management monitoring async devices but need ons connections in a similar asynchronous data way isochronous transfer connections are managed. AV/C Asynchronous Provides a means of All AV/C devices using Accepted by TA, Connections efficiently moving data asynchronous data updates proposed http://www.1394ta.org/ using asynchronous transfer Technology/specificatio connections with AV/C ns commands.

AV/C Asynchronous Provides a means of All AV/C devices using In work http://www.1394ta.org Flow Control efficiently managing asynchronous data members only section Async flow control with transfer for data? AV/C commands.

AV/C Isochronous Provides a means of AV/C devices that can In work http://www.1394ta.org Rate Control managing Isochronous vary their isoch data members only section rate control with AV/C rates to meet system commands. requirements

© 1999Zayante, Inc. Permission to copy granted so long as this notice is retained. Page 14 Name Abstract Who needs it? Status More information AV/C Printer Subunit Enhancements to AV/C AV/C Printer vendors, In committee http://www.1394ta.org for an AV/C controlled SW driver writers members only section printer.

AV/C Camera Subunit Enhancements to AV/C AV/C Digital Camera In committee http://www.1394ta.org for an AV/C controlled vendors, SW driver members only section digital camera. writers AV/C Panel Subunit Provides On-Screen GUI developers for Submitted for 1394 TA http://www.1394ta.org Display to enable AV/C device control voting members only section presentation to the user. presentation

AV/C Monitor Subunit Enhancements to AV/C AV/C Monitor Makers In Committee http://www.1394ta.org for controlling a video and SW driver writers. members only section monitor. AV/C Audio Control Provides control for Audio Instrument HW In committee http://www.1394ta.org Model audio functions across and SW designers members only section 1394 using AV/C commands. AV/C Super Audio CD Provides control for Super Audio Instrument In committee http://www.1394ta.org Model super audio CD HW and SW designers members only section functions across 1394 using 1394 using AV/C commands. AV/C Changer Subunit Provides standard HW and SW designers In committee http://www.1394ta.org means for controlling of AV/C device using members only section changer units (like for changers CDs) AV/C Tape Recorder Provides standard HW and SW designers In committee http://www.1394ta.org Subunit means for controlling of AV/C devices using members only section tape recorder units using tape recorders AV/C commands, replaces VCR subunits, has profiles for DV, 8mm, DVHS, etc.

AV/C Timer Operation Provides Timing and GUI developers for In committee http://www.1394ta.org scheduling for events AV/C device control members only section and tasks across 1394 for AV/C devices

AV/C Preset Subunit Provide a standard Target device SW In committee http://www.1394ta.org means of establishing developers for AV/C members only section presets across 1394 for device control AV/C devices AV/C Diagnostics Provide a standard AV/C device control In committee http://www.1394ta.org Subunit means of starting and SW writers members only section reporting the results of self test across 1394 for AV/C devices

AV/C Resource Provides know location AV/C device HW and In committee http://www.1394ta.org Information Subunit to place scheduled SW designers members only section events and tasks across 1394 for AV/C devices

Music LAN (MLAN) Architecture to Musical Instrument Completed by Yamaha http://www.yamaha.co.j implement IEC-61883-6 Makers, SW writers. p/tech/1394mLAN/mla along with how to n.html distribute sampling clocks and manage nodes

© 1999Zayante, Inc. Permission to copy granted so long as this notice is retained. Page 15 Name Abstract Who needs it? Status More information Industrial & Communication Industrial automation & In 1394 TA Working ftp://fcext3.external.hp. Instrumentation protocol similar to instrumentation vendors Group com/dist/mxd/ieee1394/ Control Protocol AV/C for industrial ii-wg/ automation and instrumentation communications IEEE 488 over 1394 Protocol to transport Industrial & In 1394 TA I&I ftp://fcext3.external.hp. Industrial & IEEE 488 commands Instrumentation HW Working Group com/dist/mxd/ieee1394/ Instrumentation over IEEE 1394 and SW designers ii-wg/ Control Protocol Video Electronics Creating a document Home Networking White paper completed http://www.vesa.org/co Standards Association describing the physical Vendors mmittees.html Home Network layers, data link layers, mid-layer protocols and associated services for a Home Network DVB Integrated Home Home network for Home Networking ?? ?? Digital Network DVB systems Vendors