Networking IEEE 1394 Clusters via UWB over Coaxial …1394ta.org/wp-content/uploads/2015/07/2006016.pdf · Document number 2006016 Networking IEEE 1394 Clusters via UWB over Coaxial

Document number 2006016

Networking IEEE 1394 Clusters

via UWB over Coaxial Cable—

Part 2: L3 IP Bridges

May 2, 2008

Accepted for publication by

The 1394 Trade Association Board of Directors

Abstract

This technical specification standardizes the model, definition, and behaviors of L3 IP bridges, devices that connect

isolated IEEE 1394 clusters across a network backbone that is not IEEE 1394—in this case, it is coaxial cable. The

L3 IP bridge extends the Internet protocol capabilities of IEEE 1394 devices and the isochronous services of IEEE

1394 beyond the geographic extent of a local IEEE 1394 cluster.

Keywords

bridge, coaxial cable, IEEE 802.15.3, IEEE 1394, IEEE 1394.1, LDP, MPLS, RSTP, Serial Bus

Networking IEEE 1394 Clusters via UWB over Coaxial Cable—Part 2: L3 IP Bridges

Copyright 2008, 1394 Trade Association. All rights reserved. ii

1394 Trade

Association

Technical

Specification

1394 Trade Association Technical Specifications are developed within Working Groups

of the Association, a non-profit industry association devoted to the promotion of and

growth of the market for IEEE 1394-compliant products. Participants in Working Groups

serve voluntarily and without compensation from the Trade Association. Most participants

represent member organizations of the 1394 Trade Association. The technical

specifications developed within the working groups represent a consensus of the expertise

represented by the participants.

Use of a 1394 Trade Association Technical Specification is voluntary. The existence of a

1394 Trade Association Technical Specification is not meant to imply that there are not

other ways to produce, test, measure, purchase, market or provide other goods and

services related to the scope of the 1394 Trade Association Technical Specification.

Furthermore, the viewpoint expressed at the time a technical specification is accepted and

published is subject to change brought about through developments in the state of the art

and comments received from users of the technical specification. Users are cautioned to

check to determine that they have the latest revision of any 1394 Trade Association

Technical Specification.

Comments for revision of 1394 Trade Association Technical Specifications are welcome

from any interested party, regardless of membership affiliation with the 1394 Trade

Association. Suggestions for changes in documents should be in the form of a proposed

change of text, together with appropriate supporting comments.

Questions might arise about the meaning of technical specifications in relationship to

specific applications. When the need for interpretations is brought to the attention of the

1394 Trade Association, the Association will prepare appropriate responses.

Comments on technical specifications and requests for interpretations should be

addressed to the address below:

Editor, 1394 Trade Association

315 Lincoln, Suite E

Mukilteo, WA 98275 USA

1394 Trade Association Technical Specifications are accepted by the association

without regard to patents that might exist on articles, materials or processes or to other

proprietary intellectual property that might exist within technical specifications.

Acceptance of a technical specification by the 1394 Trade Association does not

assume any liability to any patent owner or any obligation whatsoever to those parties

who rely on the technical specifications. Readers of this document are advised to

make an independent determination regarding the existence of intellectual property

rights that might be infringed by conformance to this technical specification.

Published by

1394 Trade Association

315 Lincoln, Suite E

Mukilteo, WA 98275 USA

Copyright © 2008 by 1394 Trade Association

All rights reserved.

Printed in the United States of America


Copyright 2008, 1394 Trade Association. All rights reserved. iii

IEEE-SA

Copyright

Permission

IEEE copyright policy (http://standards.ieee.org/IPR/copyrightpolicy.html) states, in part:

In accordance with the above policy, this Technical Specification includes excerpts from

the following IEEE Standards:

IEEE Std 1394.1-2004, Standard for High Performance Serial Bus Bridges

Royalty Free Permission

IEEE-SA policy holds that anyone may excerpt and publish up to, but not

more than, ten percent (10%) of the entirety of an IEEE-SA Document

(excluding IEEE SIN books) on a royalty-free basis, so long as:

1) proper acknowledgment is provided;

2) the ―heart‖ of the standard is not entirely contained within the

portion being excerpted.

This includes the use of tables, graphs, figures, abstracts and scope

statements from IEEE Documents. Furthermore, the IEEE-SA generally

provides royalty free permission to utilize any templates and individual

definitions provided in an IEEE Document. In these instances, the IEEE-

SA only requests that the user properly reference the title and numeric

designation of the relevant standard(s) being excerpted.

http://standards.ieee.org/IPR/copyrightpolicy.html


Copyright 2008, 1394 Trade Association. All rights reserved. v

Contents

1 Scope and purpose ...................................................................................................................................................... 1 1.1 Scope ................................................................................................................................................................... 1 1.2 Purpose ................................................................................................................................................................ 1 1.3 Context ................................................................................................................................................................ 1

2 Normative references .................................................................................................................................................. 3 2.1 Reference scope ................................................................................................................................................... 3 2.2 Approved references ............................................................................................................................................ 3 2.3 Reference acquisition ........................................................................................................................................... 4

3 Definitions and notation .............................................................................................................................................. 5 3.1 Definitions ........................................................................................................................................................... 5

3.1.1 Conformance................................................................................................................................................. 5 3.1.2 Glossary ........................................................................................................................................................ 5 3.1.3 Abbreviations and acronyms ......................................................................................................................... 7

3.2 Notation ............................................................................................................................................................... 8 3.2.1 Numeric values ............................................................................................................................................. 8 3.2.2 Bit, byte and quadlet ordering....................................................................................................................... 8 3.2.3 Transmission order over IEEE 802.15.3 ....................................................................................................... 9 3.2.4 C pseudocode notation ................................................................................................................................ 10

4 Overview (informative) ............................................................................................................................................ 11 4.1 L3 IP Bridge architecture ................................................................................................................................... 11 4.2 Cycle time distribution and synchronization ...................................................................................................... 12 4.3 Universal time .................................................................................................................................................... 14 4.4 Digital content protection .................................................................................................................................. 14

5 Data structure formats ............................................................................................................................................... 17 5.1 Bridge protocol data unit (BPDU) ..................................................................................................................... 17 5.2 Label distribution protocol (LDP) data unit and messages ................................................................................ 19

5.2.1 LDP data unit .............................................................................................................................................. 19 5.2.2 LDP message .............................................................................................................................................. 20 5.2.3 TLV encoding ............................................................................................................................................. 20 5.2.4 HELLO message ......................................................................................................................................... 21 5.2.5 INITIALIZATION message........................................................................................................................ 21 5.2.6 Path management messages ........................................................................................................................ 22 5.2.7 PATH NOTIFICATION message................................................................................................................ 27 5.2.8 TIME OFFSET message ............................................................................................................................. 28

5.3 DHCP message .................................................................................................................................................. 29 5.4 Cycle master adjustment packet ......................................................................................................................... 31 5.5 MSDU header .................................................................................................................................................... 32 5.6 RTTM command frames .................................................................................................................................... 33 5.7 IEEE 1394 stream service data unit ................................................................................................................... 34 5.8 Common isochronous packet (CIP) data ........................................................................................................... 35 5.9 Expedited FCP data unit (XFC PDU) ................................................................................................................ 37

6 Internet protocol operations ...................................................................................................................................... 41 6.1 Distributed host control protocol (DHCP) ......................................................................................................... 41

6.1.1 IEEE 1394 DHCP client operations ............................................................................................................ 41 6.1.2 BOOTP/DHCP relay agent operations ....................................................................................................... 41

6.2 Address resolution protocol (ARP) .................................................................................................................... 41 6.2.1 IEEE 1394 port ........................................................................................................................................... 42


Copyright 2008, 1394 Trade Association. All rights reserved. vi

6.2.2 Coaxial cable port ....................................................................................................................................... 43 6.3 Link-local address assignment ........................................................................................................................... 43 6.4 Rapid spanning tree protocol (RSTP) ................................................................................................................ 43 6.5 IP datagram routing ........................................................................................................................................... 44

7 Isochronous bridge operations .................................................................................................................................. 47 7.1 MPLS initialization ............................................................................................................................................ 47 7.2 Isochronous path management ........................................................................................................................... 48

7.2.1 PATH ENDPOINT message processing ..................................................................................................... 49 7.2.2 PATH REQUEST message processing ....................................................................................................... 51 7.2.3 PATH MAPPING message processing ....................................................................................................... 54 7.2.4 PATH TEARDOWN message processing ................................................................................................... 55 7.2.5 Autonomous path teardown ........................................................................................................................ 58

7.3 Isochronous operations ...................................................................................................................................... 61 7.3.1 Ingress port isochronous operations............................................................................................................ 61 7.3.2 Egress port isochronous operations ............................................................................................................ 62 7.3.3 Stream SDU aggregation and disaggregation ............................................................................................. 62 7.3.4 Common Isochronous Packet (CIP) header transformations ...................................................................... 63

7.4 Cycle offset synchronization .............................................................................................................................. 63 7.4.1 IEEE 1394 port ........................................................................................................................................... 64 7.4.2 Coaxial cable port ....................................................................................................................................... 66

7.5 Network time ..................................................................................................................................................... 70 7.5.1 TIME_OFFSET message processing .......................................................................................................... 70 7.5.2 BUS_TIME and CYCLE_TIME register modifications ............................................................................. 71

8 Expedited FCP and round-trip timing ....................................................................................................................... 73 8.1 Round-trip timing mode (RTTM) ...................................................................................................................... 73

8.1.1 MLME-RTTM.request ............................................................................................................................... 73 8.1.2 MLME-RTTM.indication ........................................................................................................................... 74 8.1.3 MLME-RTTM.response ............................................................................................................................. 74 8.1.4 MLME-RTTM.confirm ............................................................................................................................... 74

8.2 XFCP command and response registers ............................................................................................................. 75 8.3 Expedited FCP operations ................................................................................................................................. 75

8.3.1 Ingress bridge FCP command frame operations ......................................................................................... 75 8.3.2 Ingress bridge FCP response frame operations ........................................................................................... 76 8.3.3 Egress bridge FCP command and response frame operations ..................................................................... 76

8.4 Round-trip timing mode (RTTM) operations ..................................................................................................... 77 8.4.1 RTTM heuristics (informative) ................................................................................................................... 77 8.4.2 RTTM enable operations ............................................................................................................................ 78 8.4.3 RTTM disable operations ........................................................................................................................... 79

Tables

Table 1 – Path management message initialization matrix ........................................................................................... 26 Table 2 – Common path management procedures ....................................................................................................... 48 Table 3 – L3 IP bridge actions on receipt of a PATH ENDPOINT message ............................................................... 50 Table 4 – L3 IP bridge actions on receipt of a PATH REQUEST message.................................................................. 51 Table 5 – L3 IP bridge actions on receipt of a PATH MAPPING message ................................................................. 54 Table 6 – L3 IP bridge actions on receipt of a PATH TEARDOWN message ............................................................. 56 Table 7 – L3 IP bridge actions upon disconnection of a local IEEE 1394 node .......................................................... 58 Table 8 – L3 IP bridge actions upon disassociation of a peer bridge ........................................................................... 60 Table 9 – Alpha IEEE 1394 port actions to synchronize downstream cycle master .................................................... 65 Table 10 – Cycle time update actions for adjustable cycle masters ............................................................................. 66 Table 11 – Coaxial cable port actions to synchronize cycle offset ............................................................................... 68 Table 12 – Ingress port actions on receipt of a TIME OFFSET message .................................................................... 70


Copyright 2008, 1394 Trade Association. All rights reserved. vii

Table 13 – Nominal CTRqB field values for RTTM CTA ........................................................................................... 78 Table B-1 – Major roles for IEEE 802.15.3 DEVs ...................................................................................................... 83

Table B-2 – MAC frame formats ................................................................................................................................. 83 Table B-3 – MAC sublayer functions .......................................................................................................................... 83 Table B-4 – MAC personal area network information block (PIB) requirements ....................................................... 83 Table C-1 – L3 IP bridge conformance requirements .................................................................................................. 85 Table C-2 – L3 IP bridge IEEE 1394 port conformance requirements ........................................................................ 86 Table C-3 – L3 IP bridge coaxial cable port conformance requirements ..................................................................... 86 Table E-1 – Configuration ROM and CSR data structures and constants .................................................................... 89 Table E-2 – Constants, global port variables and external procedures ........................................................................ 91 Table E-3 – Message data structures and constants ..................................................................................................... 93 Table E-4 – Data structure utility functions ................................................................................................................. 95

Figures

Figure 1 – IEEE 1394 bit order within a byte ................................................................................................................ 8 Figure 2 – IEEE 1394 byte order within a quadlet ........................................................................................................ 8 Figure 3 – IEEE 1394 quadlet order within an octlet .................................................................................................... 8 Figure 4 – IEEE 1394 bit order within a quadlet ........................................................................................................... 9 Figure 5 – IEEE 802.15.3 bit order within a 32-bit number .......................................................................................... 9 Figure 6 – EUI-64 bit transmission orders ................................................................................................................... 10 Figure 7 – L3 IP Bridge architecture ........................................................................................................................... 11 Figure 8 – Symbolic representation of an L3 IP bridge ............................................................................................... 12 Figure 9 – Cycle time phase synchronization between IEEE 1394 clusters ................................................................. 13 Figure 10 – Example residential network topology ..................................................................................................... 15 Figure 11 – RST BPDU format ................................................................................................................................... 17 Figure 12 – LDP data unit format ................................................................................................................................ 19 Figure 13 – LDP message format ................................................................................................................................. 20 Figure 14 – TLV format ............................................................................................................................................... 20 Figure 15 – HELLO message format ........................................................................................................................... 21 Figure 16 – INITIALIZATION message format .......................................................................................................... 22 Figure 17 – Path management message format ............................................................................................................ 23 Figure 18 – PATH NOTIFICATION message format .................................................................................................. 27 Figure 19 – Status code subfields ................................................................................................................................ 27 Figure 20 – TIME OFFSET message format ............................................................................................................... 28 Figure 21 – DHCP request/reply format ...................................................................................................................... 29 Figure 22 – DHCP 1394 mandatory options ................................................................................................................ 30 Figure 23 – Cycle master adjustment packet format .................................................................................................... 31 Figure 24 – Standard MSDU header format ................................................................................................................ 32 Figure 25 – Vendor-specific MSDU header format ..................................................................................................... 33 Figure 26 – RTTM request command frame format .................................................................................................... 33 Figure 27 – RTTM response command frame format .................................................................................................. 33 Figure 28 – IEEE 1394 stream SDU format ................................................................................................................ 34 Figure 29 – Common isochronous packet (CIP) format .............................................................................................. 35 Figure 30 – Two-quadlet CIP header format ................................................................................................................ 36 Figure 31 – Source packet header format .................................................................................................................... 36 Figure 32 – Synchronization time (syt) format ............................................................................................................ 37 Figure 33 – Expedited FCP protocol data unit (XFC PDU) format ............................................................................. 38 Figure 34 – IP1394 ARP request/response format ....................................................................................................... 42 Figure 35 – MSDU with aggregated IEEE 1394 stream SDUs ................................................................................... 62 Figure 36 – Coaxial cable cycle time message format ................................................................................................. 66 Figure 37 – Cycle time synchronization method .......................................................................................................... 67 Figure A-1 – L3 IP bridge IEEE 1394 port unit directory ........................................................................................... 81

Figure F-1 – Path setup operations .............................................................................................................................. 97 Figure F-2 – Path teardown operations ........................................................................................................................ 98


Copyright 2008, 1394 Trade Association. All rights reserved. viii

Figure G-1 – Expedited path for RTT TEST command and ACCEPTED response .................................................. 101

Annexes

Annex A (normative) Minimum node capabilities for L3 IP bridge IEEE 1394 ports ................................................ 81

Annex B (normative) Minimum DEV capabilities for L3 IP bridge coaxial cable ports ............................................ 83

Annex C (normative) Conformance requirements ...................................................................................................... 85

Annex D (normative) Assigned numbers .................................................................................................................... 87

Annex E (normative) Pseudocode constants, data structures and utility functions ..................................................... 89

Annex F (informative) Message sequence charts (MSCs) for path management operations ...................................... 97

Annex G (informative) Message sequence chart (MSC) for expedited FCP (XFCP) operations ............................. 101

Annex H (informative) Bibliography ........................................................................................................................ 105


Copyright 2008, 1394 Trade Association. All rights reserved. ix

Foreword (This foreword is not a normative part of 1394 Trade Association Specification 2006016)

During June, July and August of 2005, a 1394 Trade Association delegation visited a number of multiple system

operators (MSOs). The purpose was straightforward: to determine MSO requirements for IEEE 1394 that, if

satisfied, could speed the deployment of IEEE 1394 in the residential environment. Broadly speaking, the MSOs

require a network capable of distributing multiple program streams from a set-top box (STB) equipped with multiple

tuners to different televisions throughout the residence. In-depth discussion with the MSOs yielded the detailed

requirements below:

– The network has to operate over existing coaxial cable infrastructure without disturbance to incumbent CATV

services or services whose deployment is imminent. The MSOs postulated that a ―typical‖ existing installation

might have a diameter (i.e., the maximum cable distance between any two wall plates) of 100 m and that the

path between any two wall plates might pass through a 4-way signal splitter and up to two 2-way signal

splitters. The network should be able to provide equal quality of service between all possible wall plate

pairings—although remediation, i.e., installation of higher-quality coaxial cable and higher-quality signal

splitters, is tolerable in a small number of cases;

– The network requires sufficient bandwidth to transport up to four HD or SD program streams concurrently.

Allowing for the increased bandwidth requirements of ―trick‖ play, e.g., fast-forward, single frame advance,

etc., the MSOs estimate a minimum requirement of 300 Mb/s of isochronous data;

– The network protocols should support transmission of the program guide from the STB to a television;

– The network has to interconnect clusters of Ethernet devices and permit them to communicate as if they were

connected to the same local-area network; and

– The network has to support communications between IEEE 1394 AV disk drives, STBs, personal video

recorders (PVRs) and televisions—but the MSOs are indifferent with respect to support for other IEEE 1394

devices.

Separate from the MSO requirements, FCC rules mandate that the network protocols support the transport of

commands specified by CEA 775, ―DTV 1394 Interface Specification‖ and CEA 931, ―Remote Control Command

Pass-through Standard for Home Networking‖.

December of that same year saw the launch of the High-Definition Audio-Video Network Alliance (HANA). The

alliance intends to satisfy all of the MSO requirements enumerated above and, in addition, provide network support

for legacy IEEE 1394 AV/C devices—although not necessarily for HANA's initial deployment. HANA is also the key

proponent for CEA 2027-B, ―A User Interface for Home Networks Using Web-based Protocols‖.

Through the development of a comprehensive family of technical specifications (of which this document is a part),

the 1394 Trade Association plans to satisfy both MSO and HANA requirements. Because association member

companies have a large infrastructure investment in contemporary, deployed IEEE 1394 AV/C devices that are not

network-enabled, the newly designed network functionality must be at least as rich as the functionality available

today, within a local cluster, to ―legacy‖ devices. In particular:

– Network-enabled AV/C devices must a) be able to discover and operate with both network-enabled and legacy

AV/C devices within the local cluster and b) additionally be able to discover and operate with network-enabled

AV/C devices connected to the network but not to the local cluster;

– The functionality described above for network-enabled AV/C devices should be made available to legacy AV/C

devices. This may require network-enabled ―helper‖ devices that communicate across bridges on behalf of

legacy AV/C devices;

– Mindful of the latency introduced by bridges, the network must be designed to connect IEEE 1394 clusters

across a maximum of two intervening bridges connected by coaxial cable. If the accumulated latencies are


Copyright 2008, 1394 Trade Association. All rights reserved. x

small enough, it might be possible for remote devices to operate across more than two bridges—but this is

neither guaranteed nor required; and

– The network and network-enabled AV/C devices must together provide digital content protection at least as

robust as that available within a local IEEE 1394 cluster.

Because of the importance of the residential network to future growth in the deployment of IEEE 1394 devices, the

1394 Trade Association Wireless working group commenced development in 2006 of the following set of technical

specifications organized under the family title ― Networking IEEE 1394 Clusters via UWB over Coaxial Cable ―:

– Part 1: Continuous Pulsed Ultra-wideband (C-UWB) PHY

– Part 2: L3 IP Bridges

– Part 3: FCP and CMP over IPv4

– Part 4: AV/C Relay Agents

Part 1 specifies a physical layer (PHY), which is, in combination with the Medium Access Control (MAC) sublayer

specified by IEEE Std 802.15.3b-2006, suitable for the coaxial cable portion of the residential network.

Part 2 (this document) specifies layer 3 (L3) bridges capable of connecting isolated IEEE 1394 clusters into a

residential network via Internet protocol (IP) and subsequently accepting messages to configure the flow of

additional isochronous data from one cluster to another.

Part 3 specifies methods to transport commands (and receive status in return) within the residential network by use of

IPv4 rather than by IEEE 1394-specific methods. It also provides methods to program plug control registers via IP

messages rather than by IEEE 1394-specific methods. These facilities enable AV/C to be used outside of the local

cluster—even to be controlled from locations outside the residence.

Part 4 specifies how third-party devices acting as relay agents for legacy AV/C devices render them capable of

interoperation with AV/C devices in remote clusters.

The Board of Directors of the 1394 Trade Association accepted this technical specification on July 27, 2008. Board

of Directors acceptance of this technical specification does not necessarily imply that all board members voted for

acceptance. At the time the 1394 Trade Association Board of Directors accepted this technical specification, it had

the following members:

Eric Anderson, Chair

Max Bassler, Vice-Chair

Dave Thompson, Secretary

Organization Represented Name of Representative

Apple ....................................................................................................... Eric Anderson

EqcoLogic ................................................................................................ Peter Helfet

Interactive Technology............................................................................. Max Bassler

LSI ........................................................................................................... Dave Thompson

Microsoft ................................................................................................. Mark Slezak

Oxford Semiconductor ............................................................................. Don Harwood

Symwave .................................................................................................. Burke Henehan

Texas Instruments ............................................................................................. Will Harris

WJR Consulting ....................................................................................... Bill Rose


Copyright 2008, 1394 Trade Association. All rights reserved. xi

The Wireless Working Group, which developed and reviewed this technical specification, had the following

participants:

Hans van der Ven, Chair

Michael Scholles, Vice-chair

Allen Heberling, Secretary

Eric Anderson

Yasaman Bahreini

Max Bassler

Les Baxter

Duncan Beadnell

Jack Chaney

Mike Conroy

Zephra Freeman

Robert Fust

Sergio Guillén

Will Harris

Allen Heberling

Peter Helfet

Peter Johansson

Hyunchin Kim

Todd Krein

Francesco Liburdi

Richard Mourn

Knut Odman

Jalil Oraee

Steve Powers

Bill Rose

Kenji Sakamoto

John Santhoff

Hideoki Sato

Tsuyoshi Sawada

Michael Scholles

Mark Slezak

Dave Thompson

Masanori Tsuji

Koen Van den Brande

Hans Van der Ven

Colin Whitby-Strevens

Andy Yanowitz


Copyright 2008, 1394 Trade Association. All rights reserved. 1

Networking IEEE 1394 Clusters

via UWB over Coaxial Cable—


1 Scope and purpose

1.1 Scope

This is a technical specification whose scope is the use of widely deployed coaxial cable infrastructure as a

residential network backbone to extend IEEE 1394 isochronous services and Internet protocol capabilities beyond

the geographic extent of isolated IEEE 1394 clusters. The device that connects an IEEE 1394 cluster to the coaxial

cable backbone is a layer 3 (or L3 IP) bridge that routes both best-effort and isochronous data. An L3 IP bridge

possesses, at a minimum, two interfaces: one to connect to a coaxial cable network and the other to connect to a

different medium, nominally IEEE 1394. More interfaces or different media may conform to, but are beyond the

scope of, this specification. This technical specification standardizes the model, definition, and behaviors of L3 IP

bridges and IEEE 1394 devices that use them.

NOTE – This specification defines the interfaces, functions, and operations necessary to ensure interoperability between

conforming implementations. However, the designer should bear in mind that this specification is a functional description:

an implementation may employ any design whose observable behavior conforms to this specification and any standards

included by reference.

1.2 Purpose

IEEE 1394 is a cost-effective interconnect for two important groups of devices: desktop and notebook computers and

their associated peripherals on the one hand and consumer electronic devices on the other. IEEE 1394 is increasingly

a convergent interconnect between the two groups. However, the use of IEEE 1394 in other environments, e.g., the

transfer of high-speed digital video data between rooms of a house, is hampered by the lack of commercially viable

architectural and protocol specifications for bridges that support the necessary quality of service. This technical

specification addresses these challenges by leveraging existing protocols and physical infrastructure while at the

same time preserving the core virtues of IEEE 1394 that render it desirable to product designers. The overall goal

has been to produce a technically solid solution that is also pragmatic and readily deployable in order to enable a

larger market for IEEE 1394 products.

1.3 Context

This technical specification is part of a larger collection of technical specifications grouped under the title,

―Networking IEEE 1394 Clusters via UWB over Coaxial Cable‖. The documents that form the group are listed

below:

Part 1: Continuous Pulsed Ultra-wideband (C-UWB) PHY


Part 3: FCP and CMP over IPv4

Part 4: AV/C Relay Agents



Implemented in their entirety, the technical specifications provide a comprehensive solution for networking AV

devices in separate rooms of a house. The use of Internet protocol for command-and-control functions offers the

possibility of extending control functionality outside the IEEE 1394 cluster to handheld or desktop Ethernet or WiFi

devices. The isochronous MPLS capabilities of the L3 IP bridges, in combination with the C-UWB PHY throughput

and the IEEE 802.15.3 MAC deterministic quality of service, extend IEEE 1394's high quality of service across the

network. In addition, the provision for ―relay agents‖ guarantees that deployed AV/C devices will not be stranded

with little or no network connectivity.



2 Normative references

2.1 Reference scope

The specifications and standards named in this section contain provisions, which, through reference in this text,

constitute provisions of this 1394 Trade Association Technical Specification. At the time of publication, the editions

indicated were valid. All specifications and standards are subject to revision; parties to agreements based on this

1394 Trade Association Technical Specification are encouraged to investigate the possibility of applying the most

recent editions of the specifications and standards indicated below.

2.2 Approved references

The following approved specifications and standards may be obtained from the organizations that control them.

[R1] 1394 Trade Association, Networking IEEE 1394 Clusters via UWB over Coaxial Cable—Part 1:

Continuous Pulsed Ultra-wideband (C-UWB) PHY

[R2] IEC 61883-1 (2003-01), Consumer audio/video equipment—Digital interface—Part 1: General

[R3] IEEE Std 802.1d-2004, Local and metropolitan area networks—Medium Access Control (MAC) Bridges

[R4] IEEE Std 802.15.3-2003, Wireless Medium Access Control (MAC) and Physical Layer (PHY)

Specifications for Wireless High Rate Personal Networks

[R5] IEEE Std 802.15.3b-2005, Wireless Medium Access Control (MAC) and Physical Layer (PHY)

Specifications for Wireless High Rate Personal Networks—Amendment 1: MAC Sublayer

[R6] IEEE Std 1394-1995, Standard for a High Performance Serial Bus

[R7] IEEE Std 1394a-2000, Standard for a High Performance Serial Bus—Amendment 1

[R8] IEEE Std 1394b-2002, Standard for a High Performance Serial Bus—Amendment 2

[R9] IEEE Std 1394c-2006, Standard for a High Performance Serial Bus—Amendment 3

[R10] IEEE Std 1394.1- 2004, Standard for High Performance Serial Bus Bridges

[R11] IETF RFC 826, An Ethernet Address Resolution Protocol, November, 1982

[R12] IETF RFC 2131, Dynamic Host Configuration Protocol, March 1997

[R13] IETF RFC 2734, IPv4 over IEEE 1394, December 1999

[R14] IETF RFC 2855, DHCP for IEEE 1394, June 2000

[R15] IEEE RFC 3927, Dynamic Configuration of IPv4 Link-Local Addresses, May 2005

[R16] IETF RFC 3031, Multiprotocol Label Switching Architecture, January 2001

[R17] IETF RFC 5036, LDP Specification, October 2007

Throughout this document, the term ―IEEE 1394‖ shall be understood to refer to IEEE Std 1394-1995 as amended

by IEEE Std 1394a-2000, IEEE Std 1394b-2002 and IEEE Std 1394c-2006. Similarly, the term ―IEEE 802.15.3‖

shall be understood to refer to IEEE Std 802.15.3-2003 as amended by IEEE Std 802.15.3b-2005.



2.3 Reference acquisition

The references cited may be obtained from the organizations that control them:

1394 Trade Association, 315 Lincoln, Suite E, Mukilteo, WA 98275 USA; (425) 514-8454 / (425) 710-9971

(FAX); http://www.1394ta.org/

Institute of Electrical and Electronic Engineers (IEEE), 445 Hoes Lane, PO Box 1331, Piscataway, NJ

08855-1331, USA; (732) 981-0060 / (732) 981-1721 (FAX); http://www.ieee.org/

International Electrotechnical Commission (IEC), Case Postale 131, 3, rue de Varembé, CH-1211, Genève 20,

Switzerland/Suisse; http://www.iec.ch/

Internet Engineering Task Force (IETF) Secretariat, c/o NeuStar, Inc., 46000 Center Oak Plaza, Sterling, VA

20166, USA; (571) 434-3500 / (571) 434-3535 (FAX); http://www.ietf.org/rfc.html

http://www.1394ta.org/

http://www.ieee.org/

http://www.iec.ch/

http://www.ietf.org/rfc.html



3 Definitions and notation

3.1 Definitions

3.1.1 Conformance

Several keywords are used to differentiate levels of requirements and optionality, as follows:

expected: A keyword used to describe the behavior of the hardware or software in the design models assumed by this

technical specification. Other hardware and software design models may also be implemented.

ignored: A keyword that describes bits, bytes, quadlets, octlets or fields whose values are not checked by the

recipient.

may: A keyword that indicates flexibility of choice with no implied preference.

reserved: A keyword used to describe objects (bits, bytes, quadlets, octlets and fields) or the code values assigned to

these objects in cases where either the object or the code value is set aside for future standardization. Usage and

interpretation may be specified by future extensions to this or other specifications and technical bulletins. A reserved

object shall be zeroed or, upon development of a future specification or technical bulletin, set to a value specified by

such a specification or technical bulletin. The recipient of a reserved object shall ignore its value. The recipient of an

object defined by this technical specification as other than reserved shall inspect its value and reject reserved code

values.

shall: A keyword that indicates a mandatory requirement. Designers are required to implement all such mandatory

requirements to assure interoperability with other products conforming to this technical specification.

should: A keyword that denotes flexibility of choice with a strongly preferred alternative. Equivalent to the phrase

―is recommended.‖

3.1.2 Glossary

The following terms are used in this technical specification:

adjustable cycle master: A cycle master that recognizes cycle master adjustment packets and, according to the

instruction received, lengthens or shortens the interval to the next cycle start event by a single cycle timer tick.

alpha port: A bridge port that forwards IP datagrams addressed to the prime port. There is at most one alpha port

within a link segment. Within the IEEE 1394 cluster that contains the prime port, there is no alpha port.

NOTE – The phrase ―alpha port‖ should not be confused with the same phrase as used by IEEE 1394 to distinguish the

original data/strobe (DS) signaling (―alpha‖ mode) from the newer, much faster ―beta‖ mode signaling

channel: A relationship that defines a group of local IEEE 1394 devices: zero or one source permitted to transmit

stream packets for the channel and zero or more sinks configured to receive stream packets for the channel. A

number between zero and 63, inclusive, identifies the group. Channel numbers are allocated cooperatively through

isochronous resource management facilities.

cycle master: On a particular IEEE 1394 cluster, the device that transmits the periodic cycle start packet 8000 times

a second. In a network of interconnected clusters, there is a cycle master for each cluster.

downstream: An adjective used to describe the relationship of a node to a particular location within the network.

When used in the context of cycle time synchronization with respect to the network cycle master, a downstream cycle

master or a downstream port has more bridge ports between itself and the network cycle master than the port to



which it is compared. Alternately, in the context of a particular isochronous path, within a bridge the downstream

port is the one with more bridge ports between itself and the source.

egress port: A description applied to a bridge port when it receives an IP datagram or IEEE 1394 stream SDU

forwarded by an ingress port and transmits it over its connected medium, coaxial cable or IEEE 1394.

ingress port: A description applied to a bridge port when it receives an IP datagram or IEEE 1394 stream SDU from

its connected medium, coaxial cable or IEEE 1394, and forwards it to an egress port.

isochronous interval: a period that begins with the transmission of a cycle start packet and ends when a subaction

gap is detected. During an isochronous interval, only isochronous packets may occur. An isochronous interval

nominally begins every 125 µs.

isochronous resource manager: Nodes that implement the BUS_MANAGER_ID, BANDWIDTH_AVAILABLE,

CHANNELS_AVAILABLE and BROADCAST_CHANNEL registers (some of which permit the cooperative

allocation of isochronous resources) are capable of being a cluster’s isochronous resource manager. Subsequent to

each bus reset, one isochronous resource manager is selected from all of the cluster’s nodes that implement these

registers. All L3 IP bridge IEEE 1394 ports are required to be isochronous resource manager-capable.

label: In MPLS terminology, the object that uniquely identifies a stream within the context of a particular link

segment. For IEEE 802.15.3 coaxial cable media, the label is the 8-bit Stream Index while for IEEE 1394 media, the

label is the 6-bit channel number.

local: An IEEE 1394 device is local with respect to another IEEE 1394 device if they are part of the same arbitration

domain, i.e., share the same root.

network cycle master: The prime cluster's cycle master; it is the authoritative source of phase synchronization for

all cycle timers in the network.

octet: Eight bits of data (synonymous with byte).

octlet: Eight bytes (64 bits) of data.

port: A point of attachment between an L3 IP bridge and IEEE 1394 or coaxial cable physical medium.

prime cluster: The IEEE 1394 cluster to which the prime port is connected.

prime port: The lowest numbered IEEE 1394 port on the network’s root bridge; the identity of the root bridge is

determined by RSTP algorithms (see [R3]).

quadlet: Four bytes (32 bits) of data.

remote: An IEEE 1394 device is remote with respect to another IEEE 1394 device if one or more L3 IP bridges are

on the route between the two devices.

sink: A device, or an application within a device, that receives isochronous stream data.

source: A device, or an application within a device, that transmits isochronous stream data.

stream: Either asynchronous or isochronous data originated by a source and received by zero or more sinks. An

isochronous stream is uniquely identified by the source's EUI-64 and an index locally unique at the source. An

isochronous stream's parameters include the payload, arbitration overhead and speed.



stream identifier: The concatenation of the source node's EUI-64 and the stream's output plug index within the

context of the source node. Together these two data items uniquely identify a stream within the residential network.

subordinate port: A port that is neither an alpha port nor the prime port; there may be multiple subordinate ports

within a link segment.

upstream: An adjective used to describe the relationship of a node to a particular location within the network. When

used in the context of cycle time synchronization with respect to the network cycle master, an upstream cycle master

or an upstream port has fewer bridge ports between itself and the network cycle master than the port to which it is

compared. Alternately, in the context of a particular isochronous path, within a bridge the upstream port is the one

with fewer bridge ports between itself and the source.

3.1.3 Abbreviations and acronyms

The following abbreviations and acronyms are used in this technical specification:

AKE Authentication and key exchange

BOOTP Bootstrap protocol (see [B5] [B8])

BPDU Bridge protocol data unit (see [R3])

CIP Common isochronous packet (see [R2])

CRC Cyclical redundancy checksum

CSR Control and status register (see [B4])

DEV A device that conforms to IEEE 802.15.3 (see [R4] [R5])

DEVID Device identifier (see [R4] [R5])

DHCP Distributed host control protocol (see [R12])

FEC Forwarding equivalence class (in the context of MPLS)

FCP Function control protocol (see [R2])

FCP/IP FCP over IPv4 (see [B1])

GASP Global asynchronous stream packet (see [R7])

iPCR Input plug control register (see [R2])

IRM Isochronous resource manager (see [R6] et seq.)

LIB Label information base (see [R17])

LDP Label distribution protocol (see [R17])

MAC Medium access control (in the context of communications protocols)

MAC Message authentication code (in the context of cryptography)

MLME MAC-layer management entity

MPLS Multiprotocol label switching (see [R16])

MSDU MAC service data unit

OUI Organizationally unique identifier (see [B4])

oPCR Output plug control register (see [R2])

PDU Protocol data unit

PNC Piconet coordinator (see [R4] [R5])

PSDU PHY service data unit

RSTP Rapid spanning tree protocol (see [R3])

RST BPDU Rapid spanning tree bridge protocol data unit (see [R3])

RTTM Round-trip timing mode

SDU Service data unit

TCP Transmission control protocol (see [B6])

TLV (type, length, value) parameter encoding

UDP User datagram protocol (see [B5])

XFCP Expedited FCP

XFC PDU Expedited FCP data unit



3.2 Notation

3.2.1 Numeric values

Decimal and hexadecimal numbers are used within this specification. By editorial convention, decimal numbers are

most frequently used to represent quantities or counts. Addresses are uniformly represented by hexadecimal numbers.

Hexadecimal numbers are also used when the value represented has an underlying structure that is more apparent in a

hexadecimal format than in a decimal format.

Decimal numbers are represented by Arabic numerals without subscripts or by their English names. Hexadecimal

numbers are represented by digits from the character set 0 – 9 and A – F followed by the subscript 16. When the

subscript is unnecessary to disambiguate the base of the number, it may be omitted. For the sake of legibility,

hexadecimal numbers are separated into groups of four digits separated by spaces.

As an example, 42 and 2A16 both represent the same numeric value.

3.2.2 Bit, byte and quadlet ordering

In order to promote interoperability with transport media that may have different ordering conventions, this

specification defines the order and significance of bits within bytes, bytes within quadlets and quadlets within octlets

in terms of their relative position and not their physically addressed position.

Within a byte, the most significant bit, msb, is transmitted first and the least significant bit, lsb, is transmitted last on

IEEE 1394, as illustrated below. The significance of the interior bits uniformly decreases in progression from msb to

lsb.

Figure 1 – IEEE 1394 bit order within a byte

Within a quadlet, the most significant byte is transmitted first and the least significant byte is transmitted last on

IEEE 1394, as shown below.

Figure 2 – IEEE 1394 byte order within a quadlet

Within an octlet, which is frequently used to contain 64-bit IEEE 1394 addresses, the most significant quadlet is

transmitted first and the least significant quadlet is transmitted last on IEEE 1394, as the figure below indicates.

Figure 3 – IEEE 1394 quadlet order within an octlet

most significant quadlet

least significant quadlet

lsb msb

most significant least significant

interior bits (decreasing significance left to right)

next to least significant byte

second most significant byte


most significant byte least significant byte

most significant

least significant



Without knowledge (outside of the scope of this specification) of the ordering conventions of the other bus, no

assumptions can be made about the ordering (significance within a quadlet) of bytes at the unaligned beginning or

fractional quadlet end of a block transfer that is not quadlet aligned or is not an integral number of quadlets.

3.2.3 Transmission order over IEEE 802.15.3

The bit and byte (octet) significance conventions and transmission order are different for IEEE 802.15.3 and IEEE

1394. Since this specification describes data structures in terms of IEEE 1394 conventions, it is essential to

understand their mapping to IEEE 802.15.3 transmissions on the coaxial cable medium. IEEE 1394 transmits the

most significant bit first while IEEE 802.15.3 transmits the least significant bit first.

For example, consider the numeric value E869 2BD416. Within IEEE 1394, it is as illustrated by Figure 4, with the

bits numbered from zero, the most significant bit, to 31, the least significant bit, and the transmission order as shown.

Figure 4 – IEEE 1394 bit order within a quadlet

IEEE 802.15.3 conventions are the reverse; Figure 5 illustrates the same numeric value, with the bits numbered from

zero, the least significant bit, to 31, the most significant bit, and the transmission order reversed as shown.

Figure 5 – IEEE 802.15.3 bit order within a 32-bit number

Another way to understand this relationship is to describe it in terms of IEEE 1394 addresses and IEEE 802.15.3

transmission order. An octet (byte) whose IEEE 1394 memory address is lower shall be transmitted before another

octet whose memory address is higher. This is true for both media, IEEE 1394 and IEEE 802.15.3, and is true

regardless of the numeric significance relationship between the two octets.

An exception to the foregoing is the transmission of OUI-derived numbers, such as EUI-48 and EUI-64 (see

http://standards.ieee.org/regauth/oui/tutorials). Independent of the significance conventions of the transmission

medium, OUI-derived numbers shall be transmitted in order from their most significant octet to their least significant

octet; the transmission order of bits within an octet is determined by the applicable standard. For example, consider a

hypothetical EUI-64 whose numeric value is ACDE 4823 4567 ABCD16 (its canonical representation is

AC-DE-48-23-45-67-AB-CD).

E869 2BD416


31 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

0 1 1 1 0 1 0 0 0 0 1 1 0 1 0 0 1 0 0 1 0 1 0 1 1 1 1 0 1 0 1 0

transmitted first

E869 2BD416


31 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

0 1 1 1 0 1 0 0 0 0 1 1 0 1 0 0 1 0 0 1 0 1 0 1 1 1 1 0 1 0 1 0

transmitted first

http://standards.ieee.org/regauth/oui/tutorials



Figure 6 – EUI-64 bit transmission orders

3.2.4 C pseudocode notation

This specification normatively describes the operations of an L3 IP bridge both by expository text and by means of

pseudocode that uses the syntax and semantics of the C programming language [B11]. The C pseudocode is not a

normative description of an implementation; it is a normative description of externally observable behaviors.

Different implementations are possible. In case of conflict between the C pseudocode and other text, precedence

shall be given first to the C pseudocode and second to the expository text.

All C pseudocode is to be interpreted as if it could be executed instantaneously, although time can elapse when

conditional expressions are evaluated as part of iterated C pseudocode.

Readers unfamiliar with the syntax and semantics of the C programming language are encouraged to consult [B11].

ACDE 4823 4567 ABCD 16

most significant

least significant

IEEE 1394

1 0 1 0 1 1 0 0 1 1 0 1 1 1 1 0 0 1 0 0 1 0 0 0 1 0 0 1 0 0 0 1

transmitted first

0 1 0 0 0 1 0 1 0 1 1 0 0 1 1 1 1 0 1 0 1 0 1 1 1 1 1 0 0 1 1 0

transmitted next

IEEE 802.15.3

transmitted first

1 0 1 0 1 1 0 0 1 1 0 1 1 1 1 0 0 1 0 0 1 0 0 0 1 0 0 1 0 0 0 1

transmitted next

0 1 0 0 0 1 0 1 0 1 1 0 0 1 1 1 1 0 1 0 1 0 1 1 1 1 1 0 0 1 1 0



4 Overview (informative)

4.1 L3 IP Bridge architecture

As specified by this document, an L3 IP bridge that connects an IEEE 1394 cluster with a coaxial cable network

backbone consists, at a minimum, of an IEEE 1394 port, a coaxial cable port and implementation-dependent memory

and processor capabilities that connect the two ports.1 An L3 IP bridge forwards two categories of traffic between its

ports: a) best-effort IP datagrams conventionally routed by their destination addresses and b) isochronous streams

routed by MPLS techniques according to their labels. Each port of an L3 IP bridge is a fully competent device within

its own link domain and may therefore implement optional functionality in addition to that necessary for L3 IP bridge

operations; such capabilities are beyond the scope of this document.

Figure 7 illustrates an architectural model of an L3 IP bridge; it is not meant to imply any particular implementation.

Figure 7 – L3 IP Bridge architecture

Each port has a globally unique identifier, EUI-64 in the case of the IEEE 1394 port and a MAC-64 in the case of the

coaxial cable port.

Received data and data to be transmitted are multiplexed or demultiplexed between the port hardware and various

queues maintained by the bridge: best-effort IP datagrams, ARP requests and responses, isochronous stream data and

LDP messages. Separate queues for received data and data to be transmitted avoid the possibility of deadlock. Best-

effort IP datagrams are routed according to their destination address. The IP routing functional module and the ARP

functional module share a common database, the ARP cache, which informs all routing decisions. Isochronous

stream data is routed according to its label. The MPLS functional module and the LDP functional module share a

common label database that specifies the path a particular isochronous stream follows through the network.

1 L3 IP bridge architectures with more than a single IEEE 1394 port and a single coaxial cable port are out of scope but not

precluded by this document.

80

2.1

5.3

b M

AC

Coa

xia

l ca

ble

PH

Y

MU

X

MLME

13

94

LIN

K

13

94

TR

AN

13

94

PH

Y

MU

X

Configuration ROM

Serial Bus Management

IP Routing

ARP

ARP cache

Datagram Queue

Datagram Queue

ARP Queue

ARP Queue

LDP Queue

LDP Queue

Isochronous Queue

Isochronous Queue

MPLS

LDP

Label database

Datagram Queue

Datagram Queue

ARP Queue

ARP Queue

LDP Queue

LDP Queue

Isochronous Queue

Isochronous Queue

Cycle Timer

Cycle Time Phase

Synchronization



The independent cycle timer, driven by a 24.576 MHz oscillator, is maintained in phase-lock synchronization with

other IEEE 1394 clusters within the network by a functional module that propagates phase-lock synchronization

across the coaxial cable medium.

Figure 8 illustrates a symbolic representation of an L3 IP bridge that omits the details present in Figure 7. This

condensed symbol is used conventionally within this document for network schematics and other high-level graphics.

Figure 8 – Symbolic representation of an L3 IP bridge

4.2 Cycle time distribution and synchronization

For bridges to transport isochronous streams reliably and on time, it is necessary for all cycle time domains within

the network to maintain frequency synchronization with respect to each other. Without frequency synchronization,

cycle offset drift might grow large enough to cause overrun or underrun as isochronous data traverses bridges. In

practice, the simplest method to obtain frequency synchronization is to maintain a nominal cycle offset phase

difference of zero (phase synchronization) between adjacent cycle time domains. Cycle offset phase synchronization

exists when cycle start events are simultaneous within tolerances inherent to IEEE 1394 cycle time distribution and

measurement.

Just as each IEEE 1394 cluster has a single cycle master that provides uniform cycle time for the cluster, a network

requires a single cycle master to provide cycle offset for the entire network. This singular cycle master is named the

network cycle master; whichever cycle master is part of the prime port's cluster is, de facto, the network cycle master.

Network cycle offset originates at the network cycle master and, via bridges, is ―tunneled‖ through the coaxial cable

segment to other, subordinate, IEEE 1394 clusters within the network. All nodes in the prime port’s cluster obtain

cycle time from the network cycle master.2 The prime port communicates cycle offset to its co-port, which is the

alpha port for the coaxial cable link segment. The alpha coaxial cable port, in turn propagates the network cycle

master’s phase offset to all the subordinate coaxial cable ports. Finally, these subordinate ports pass the phase-offset

information to their IEEE 1394 co-ports, which calculate the phase offset drift experienced by their local cycle

masters and make appropriate corrections.

A cycle time domain is the set of nodes or DEVs all of which obtain their cycle time from the same IEEE 1394 cycle

master. A cycle time domain may span a bridge; the prime port's cluster and the coaxial cable link segment belong to

the same cycle time domain.

For any two adjacent cycle time domains, the one with fewer intervening bridges between itself and the network

cycle master is called the upstream cycle time domain and the other is called the downstream cycle time domain. An

upstream cycle time domain provides cycle offset synchronization to all adjacent downstream cycle time domains.

All alpha ports (except those part of the same bridge as the prime port) are downstream with respect to their co-port's

cycle time domain and are responsible to synchronize cycle offset within their own domain to that of the upstream

cycle time domain. The alpha coaxial cable port is additionally responsible to propagate prime port cycle time (not

just phase offset alignment) to the subordinate coaxial cable ports. An alpha port connected to an IEEE 1394 cluster

may regulate cycle offset for that cluster if either a) it is the cycle master or b) the cycle master is adjustable by

means of ―go fast‖ and ―go slow‖ packets. These cycle master adjustment packets (see 5.3) permit the alpha port to

2 Although the network cycle master and prime port functions are orthogonal to each other, they may reside within the same node.

IEEE 1394 Coaxial cable



instruct its cluster's cycle master to delay or hasten the advent of the next cycle synchronization event by one tick of

its 24.576 MHz cycle timer.

NOTE – If an alpha port is not the cycle master and the cycle master is not adjustable, it is not possible to synchronize the

downstream cycle time domain's cycle offset to that of the upstream cycle time domain. If the difference between the clock

frequencies of the upstream and downstream cycle master is negligible, the resultant problems may be minor. On the other

hand, significant clock drift between the upstream and downstream domains might prevent the satisfactory operation of

demanding applications (e.g., applications with separately sourced audio and video streams); even single-stream

applications could experience periodic disruptions because of underrun or overrun. See 7.4.1 for strategies to mitigate these

problems.

Four items of data are sufficient for an alpha IEEE 1394 port to determine whether a phase adjustment is required:

simultaneous samples3 of CYCLE_TIME.cycle_offset from the downstream and upstream cycle time domains and

the propagation delays between the prime and alpha ports and their cycle masters (upstream and downstream delay,

respectively). Figure 9 illustrates the components of the feedback loop employed to maintain cycle offset phase

synchronization between the prime port’s (upstream) cycle time domain and a downstream IEEE 1394 cycle time

domain.

Figure 9 – Cycle time phase synchronization between IEEE 1394 clusters

The prime cluster (upstream) cycle master is labeled NCM and the downstream cycle master is labeled CM; within

the bridges, the prime, alpha and subordinate ports are identified by p, α and s, respectively. The phase difference

between the two IEEE 1394 cycle time domains can be calculated by the following formula:

(CYCLE_TIME.cycle_offsetalpha + downstream_delay) - (CYCLE_TIME.cycle_offsetprime + upstream_delay)

The prime port and alpha port each measure the propagation delay between it and its cluster’s cycle master by means

of PHY ping packets (see [R7]). The propagation delay is assumed to remain constant over time, within tolerances,

unless the path between the port and the cycle master alters. The propagation delay is half the round-trip delay

measured by a ping packet. At the start of each superframe's beacon, the prime port's CYCLE_TIME register is

sampled and the result adjusted by the upstream propagation delay. Simultaneously, the subordinate coaxial cable

port sample its alpha IEEE 1394 port’s CYCLE_TIME register and adjust the result by the downstream propagation

delay. The alpha coaxial cable port broadcasts the adjusted CYCLE_TIME to the subordinate coaxial cable port.

Upon receipt of the cycle time message, the subordinate coaxial cable port calculates the phase difference between

the prime cluster and its own local cluster according to the formula above. If the resultant phase difference is

negative, the downstream cycle master is running slower than is the net (upstream) cycle master. Otherwise, when a

positive phase difference is observed, the downstream cycle master is too fast. In either case, the phase correction is

evenly distributed over time4 by the alpha IEEE 1394 port, which instructs the cluster's cycle master to speed up or

slow down by no more than one cycle offset tick in any isochronous interval.

NOTE – Although the preceding discussion assumes that the prime port and the net cycle master are distinct nodes and that

the alpha IEEE 1394 port and the downstream cycle master are distinct nodes, the principles are the same if either port is

its cluster's cycle master. In which case, the value of the pertinent propagation delay is zero.

3 The C-UWB PHY does not support measurement of coaxial cable propagation delay, which is ignored in this discussion. 4 The next authoritative CYCLE_TIME sample will be available near the start of the next superframe; therefore, the corrections

are distributed over a time interval equal to superframe duration.

CM

cycle start

cycle adjustment

s α

downstream_delay

NCM p α

upstream_delay



4.3 Universal time

The preceding clause explains the necessity for a single source of cycle time synchronization within the network

(called the network cycle master) and describes how bridge ports distribute synchronized cycle offset. Bridge ports,

however, do not distribute a constant time reference throughout the network. There is no directly accessible universal

time pervasive across the network: BUS_TIME and CYCLE_TIME.cycle_count may—and probably do—vary from

cluster to cluster even though CYCLE_TIME.cycle_offset in all clusters is phase-lock synchronized.

A common time reference is valuable for many applications, whether the need for coordinated action on separate

clusters is coarse-grained (e.g., a set-top box should transmit program material when a PVR expects to receive it) or

more exacting, as when editing or mixing is performed. Although a universal time reference is not directly

maintained within the network, facilities exist to enable applications to derive a common sense of time. All that is

required is a common reference cluster mutually agreed by the applications.

Derivation of universal time is based upon a network management message that permits the time difference, in

cycles, to be measured between any two clusters within the network. Equipped with knowledge of relative time

offsets between particular pairs of clusters, applications located on clusters remote with respect to each other may

calculate a common time; all that is required is a shared point of reference. One such reference is the network cycle

master itself. In order to use time on the prime cluster as the common time reference, applications need only convert

their local time to the equivalent time on the prime cluster and communicate the normalized time to the remote

participant, which can then reconvert it to local time.

With the exception of L3 IP bridges defined by this specification, IEEE 1394 devices connect to a single cycle time

domain, their local cluster, and therefore are inherently incapable of simultaneous sampling of cycle time within

other domains. In actual practice, the relative time offsets for ordered pairs of clusters are obtainable via a network

management message. Each bridge on the route between the source and destination of the message updates the

cumulative time difference carried within the message's body. The update amount is equal to the signed difference

between cycle time as perceived on the message's ingress port and egress port.

Once measured, the relative time difference between two clusters does not change unless the value of BUS_TIME or

CYCLE_TIME.cycle_count on either cluster changes other than because of normal increment—in which case,

devices should measure the relative time offset anew. Bridge ports do not change BUS_TIME or discontinuously

alter CYCLE_TIME.cycle_count except when RSTP (see 8.4) algorithms force the selection of a new network cycle

master.

4.4 Digital content protection

L3 IP bridges specified by this document implement features that support certain components of Digital

Transmission Content Protection (DTCP), whose technical specification can be obtained under license from the

Digital Transmission Licensing Administrator, http://www.DTCP.com. The DTCP authentication and key exchange

(AKE) algorithm has been enhanced for network use to include ―localization‖ (see [B2]5). Localization restricts the

network distance between the source and sink devices to a round-trip time (RTT) less than or equal to 7 ms. RTT is

measured directly from the time the source device transmits a message to the sink until the time the source receives a

response. RTT is difficult to forge because it is part of the cryptographically protected AKE exchange sequence.

5 This informative description of DTCP is available to the public.

http://www.dtcp.com/



Figure 10 – Example residential network topology

Consider Figure 10; in order for a source device, e.g., the HD DVD in the living room, to authenticate a sink device,

e.g., the HDTV in the bedroom, the following steps must take place:

a) The HDTV arbitrates for the bus and transmits an RTT message to its adjacent bridge port (part of the STB).

In the pathological worst-case, with 63 devices in the cluster, arbitration could take 7.75 ms. Even in a more

typical case, with six devices in the living room, arbitration could take 0.75 ms;

b) Although transmission time for the RTT message is brief, the L3 IP bridge must first obtain channel time—

which the PNC can provide no earlier than the next superframe. This introduces worst-case latency equal to

twice the duration of the superframe. Although the size of the superframe is implementation-dependent, a

variety of factors combine to make it exceedingly unlikely that superframe duration would be less than 32 ms.

Clearly, latency over the coaxial cable alone can prevent successful AKE completion—unless RTT messages

are accorded expedited treatment;

c) The sink-adjacent bridge port in the bedroom arbitrates for the bus in order to transmit the RTT message to the

HDTV and consumes a worst-case 0.25 ms in so doing;

d) After processing the message and preparing the response, the HDTV also uses up to 0.25 ms to arbitrate for

the bus;

e) The return of the RTT response message across the coaxial cable incurs similar latency to that experienced by

the outbound RTT message; and, finally

f) The source-adjacent bridge port must also arbitrate for the bus in order to return the RTT response to the

HDTV originator; another 0.75 ms.

As can be readily calculated, there is unavoidable arbitration latency within the IEEE 1394 clusters between 500 µs

and 2 ms—which leaves a latency budget of only 5 ms to 6.5 ms for all the processing delays in the HDTV and

queuing, scheduling and transmission delays in both L3 IP bridges and the coaxial cable that separates them. If

round-trip times less than or equal to 7 ms are to be achievable, the bridges must operate—for a short time—in a

special mode optimized to enable high priority, low latency transmission of the critical RTT messages across the

coaxial cable.

STB

CATV

Home Theater

PVR HDTV HD

DVD FM

Radio DVD HDTV

Analog TV

PC

OUT

IN

OUT

OUT

IN

OUT IN

OUT

OUT

OUT

OUT

169.254.163.218 169.254.161.115 169.254.115.145 169.254.115.100 169.254.181.149 169.254.203.8 169.254.237.39

169.254.54.174

169.254.192.185

169.254.178.129

169.254.54.77

Living room

Bedroom Office

169.254.204.89

169.254.170.18

1



5 Data structure formats

5.1 Bridge protocol data unit (BPDU)

For the sake of convenience, Figure 11 reproduces the format of an RST BPDU (normatively specified by [R3]).6

Figure 11 – RST BPDU format

6 The RST BPDU is the principal BPDU used by bridges that implement RSTP. For backwards compatibility with spanning tree

protocol (STP), other BPDU formats are recognized and transmitted as appropriate; see [R3] for details.

forward_delay

version_1_length

tca


tc

max_age

hello_time

port_identifier

message_age

root_path_cost

bridge_identifier

bpdu_type (2)

root_identifier

protocol_identifier (0)

protocol_version_identifier (2)

proposal port_role learning forwarding agreement



NOTE – Because most of the RST BPDU fields do not align on 32- or 16-bit boundaries, the BPDU is illustrated as a

sequence of octets.

When an RST BPDU or any other BPDU is transmitted within the coaxial cable piconet, it shall be prefixed by an

MSDU header whose Protocol ID field is equal to three (see 5.5).

The value of the protocol_identifier field shall be zero and the value of the protocol_version_identifier field shall be

two; together they indicate that the RST BPDU format conforms to [R3].

The value of the bpdu_type field shall be two to indicate that this is an RST BPDU.

The topology_change bit (designated as tc in the previous figure) shall be set to one when a port's role has changed

such that its IP routing information must be discarded, i.e., a network topology change has occurred that has rendered

routing information invalid. Otherwise, the bit shall be zero.

The proposal bit shall be set to one to indicate that the transmitter of the RST BPDU intends to change its port state

from Discarding to Forwarding and requests permission of the BPDU recipient beforehand. Otherwise, it shall be

zero

The port_role field encodes the current role of the port to which the RST BPDU pertains, as specified by the table

below:

Value Port Role

0 Unknown

1 Alternate or

Backup

2 Root

3 Designated

The learning bit shall be one if the port to which the RST BPDU information pertains is in either the Forwarding

State or the Learning State and zero otherwise.

The forwarding bit shall be one if the port to which the RST BPDU information pertains is in the Forwarding State

and zero otherwise.

The agreement bit shall be set to one to indicate that the transmitter of the RST BPDU agrees to the port role

proposed for a neighboring port in an earlier RST BPDU.

The topology_change_acknowledgment bit (designated as tca in the preceding figure) bit shall be set to one to

indicate that the transmitter of the RST BPDU has discarded IP routing information, as requested by receipt of an

earlier RST BPDU whose topology_change bit was one.

The root_identifier field identifies the root bridge; its value is derived from the root bridge's MAC address.

The value of the root_path_cost field represents, in arbitrary cost units, the transmission speed associated with this

bridge's path to the root. Recommended values are 50 000 when the root port is an L3 IP bridge IEEE 1394 port and

100 000 when the root port is an L3 IP bridge coaxial cable port.

The 64-bit bridge_identifier field identifies the bridge to which the information in the RST BPDU pertains.

NOTE – The root_identifier and bridge_identifier fields consist of three subfields. The most significant four bits are the

bridge's relative priority with respect to other bridges; the next most significant 12 bits are the system ID extension, which



is zero; and the remaining, least significant 48 bits are typically derived from the MAC address of one of the bridge's ports.

For L3 IP bridges, the value of the priority subfield shall be one unless set to zero (superior priority) by management

operation. For L3 IP bridges, the least significant 48 bits of the bridge identifier shall be derived from the L3 IP bridge

coaxial cable port's MAC-64 as follows. Bits 16 through 39, inclusive, shall be equal to the most significant three octets of

the MAC-64; and bits 40 through 63, inclusive, shall be equal to the least significant three octets of the MAC-64.

The 16-bit port_identifier field, which identifies the port to which the information in the RST BPDU pertains,

consists of two subfields: a) the most significant four bits are the port's relative priority with respect to the L3 IP

bridge's other ports and b) the least significant 12 bits are the port number. The priority bits shall be zero for an IEEE

1394 port and nonzero otherwise.

The value of the message_age field represents, in units of 1/256 second, the age of the RST BPDU since it was first

transmitted.

The value of the max_age field represents, in units of 1/256 second, the maximum age an RST BPDU may attain

before it shall be discarded.

The value of the hello_time field represents, in units of 1/256 second, the interval between periodic transmissions of

Configuration Messages by Designated Ports.

The value of the forward_delay field represents, in units of 1/256 second, the delay between the time a Root Port or

a Designated Port is eligible to transition to the Forwarding State, and the time it is actually permitted to make the

transition. This parameter is applicable only to bridges that implement STP.

The value of the version_1_length field shall be zero.

5.2 Label distribution protocol (LDP) data unit and messages

5.2.1 LDP data unit

LDP messages are transmitted within a label distribution protocol data unit (LD PDU), which is the payload of an IP

datagram. An LD PDU, whose format is specified by Figure 12, may contain more than one LDP message within its

payload.

Figure 12 – LDP data unit format

The version field shall be zero to indicate that LDP messages within the LD PDU's payload conform to the

requirements of [R17].

The length field shall specify the size, in octets, of the LD PDU exclusive of the version and length fields.

For messages originated by hosts other than L3 IP bridges, the router_ID field shall be zero. Otherwise, the

router_ID field shall uniquely identify the L3 IP bridge that transmitted the LD PDU. The value of the router_ID

field shall be unique within the domain of link local IP addresses.

router_ID

most significant

least significant

length version (0)

label_space_ID (0)

payload



The label_space_ID field shall be zero.

NOTE – [R17] refers to the router_ID and label_space_ID fields collectively as the LDP Identifier.

The payload field shall contain one or more LDP messages in the format specified by Figure 13. There are no

alignment requirements for any of the octets of an LDP message.

5.2.2 LDP message

LDP messages share the common format specified by Figure 13.

Figure 13 – LDP message format

Upon receipt of a message whose message_type value is unrecognized, if the unknown bit (designated as u in the

preceding figure) is zero, notification shall be returned to the message's originator. Otherwise, when the bit is one,

notification shall not be returned.

The message_type field shall specify the format and usage of the message_parameters field.

The length field shall specify the size, in octets, of the message_parameters field.

The message_ID field shall be initialized by the message's originator and should be unique within the context of the

message's originator. Notifications sent in response to a message should include its message_ID in the notification's

Status TLV.

The message_parameters field shall contain zero or more mandatory and optional parameters as specified by the

message_type field. Mandatory parameters, if any, shall appear in the order specified by message_type; optional

parameters, if any, may appear in any order.

5.2.3 TLV encoding

Much of the information within an LDP message is encoded as (type, length, value) triplets in the format specified by

Figure 14. A (type, length, value) triplet is commonly referred to as a TLV.

Figure 14 – TLV format

u

most significant

least significant

length type f

value

u

most significant

message_length message_type

least significant

message_parameters

message_ID



The unknown bit (designated as u in the preceding figure) specifies processing behavior upon receipt of a TLV

whose type is unrecognized. When the unknown bit is zero, the entire message that contains the unrecognized TLV

shall be ignored and a notification shall be returned to the message's originator. Otherwise, when the unknown bit is

one, no notification shall be returned to the message's originator and only the unrecognized TLV shall be ignored

(i.e., the remainder of the message is processed as if the unrecognized TLV did not exist).

The forward_unknown bit (designated as f in the preceding figure) is meaningful only for an unrecognized TLV

whose unknown bit is one. If the forward_unknown bit is zero, the unrecognized TLV shall not be forwarded.

Otherwise, if the message that contains the unrecognized TLV is to be forwarded and the forward_unknown bit is

one, the unrecognized TLV shall be forwarded as part of the message.

The type field shall specify the format and usage of the value field.

The length field shall specify the size of the value field, in octets.

The value field shall contain information in the format specified by the type field. The value field may itself contain

TLVs, any of which may contain additional nested TLVs ad absurdum.

5.2.4 HELLO message

HELLO messages, whose format is specified by Figure 15, are used to establish adjacency between peer L3 IP

bridges.

Figure 15 – HELLO message format

The message_type field shall have a value of 10016, which identifies a HELLO message.

A HELLO message has one mandatory parameter, the Common HELLO Parameters TLV, which has a type of 40016.

The hold_time field shall have a value of 30, which specifies the time, in seconds, that the recipient L3 IP bridge port

shall maintain the HELLO adjacency.

The targeted_hello bit (designated as t in the preceding figure) shall be zero to indicate a Link HELLO message.

The request_targeted_hello bit (designated as rq in the preceding figure) shall be zero; L3 IP bridges do not request

Targeted HELLO messages.

5.2.5 INITIALIZATION message

INITIALIZATION messages, whose format is specified by Figure 16, are used to establish label exchange sessions

between adjacent L3 IP bridges.

u

(0)

most significant

message_length (12) message_type (10016)

least significant

hold_time

message_ID

length (4)

reserved

type (40016) u

(0)

f

(0)

t

(0)

rq

(0)



Figure 16 – INITIALIZATION message format

The message_type field shall have a value of 20016, which identifies an INITIALIZATION message.

An INITIALIZATION message has one mandatory parameter, the Common Session Parameters TLV, which has a

type of 50016.

The version field shall be one to indicate that the Common Session Parameters TLV conforms to [R17].

The keep_alive_time field shall have a value of 60 to specify the time, in seconds, that the recipient shall maintain an

active session without receipt of an LD PDU from the peer L3 IP bridge port.

The label_advertisement_discipline bit (designated as a in the preceding figure) shall be zero to specify Downstream

Unsolicited advertisement.

The loop_detection bit (designated as ld in the preceding figure) shall be zero to disable loop detection.

The path_vector_limit field is not meaningful when loop detection is disabled and shall be zero.

The max_PDU_size field specifies the maximum LD PDU size, in octets, for the session. A value less than or equal

to 255 specifies a maximum size of 4096 octets; all other values directly specify the maximum size. The negotiated

value for the session's maximum PDU size shall be the smaller of the max_PDU_size values exchanged by peer L3

IP bridges during session initialization. Prior to the completion of session initialization, the maximum PDU size

defaults to 4096 octets.

For messages transmitted to hosts other than L3 IP bridges, the router_ID field shall be zero. Otherwise, the

router_ID field shall be the IP address of the L3 IP bridge that transmits the INITIALIZATION message.

The label_space_ID field shall be zero.

5.2.6 Path management messages

Although the establishment and utilization of paths for isochronous data through L3 IP bridges is an MPLS

application, the nomenclature for labels and forwarding equivalence classes (FECs) differs from that natively

supported by [R17]. In order to provide messages functionally equivalent to the standard messages defined by LDP

(e.g., label mapping, label request, etc.), this clause defines LDP vendor-private messages with the common format

specified by [R17].

u

(0)

most significant

message_length (12) message_type (20016)

least significant

version (1)

message_ID

length (14)

keep_alive_time

type (50016) u

(0)

f

(0)

a

(0)

ld

(0) max_PDU_size path_vector_limit (0) reserved

router_ID

label_space_ID



Figure 17 – Path management message format

The concatenation of the company_ID and version fields form a CDI-32™ 7 which [R17] refers to as the Version ID

field.

The message_type field shall have a value specified by the table below; with the exception of 3E5016 (see 5.2.8), all

other values in the range 3E0016 through 3EFF16, inclusive, are reserved for future standardization.

7 See http://standards.ieee.org/regauth/oui/tutorials/CDI32.html for more information on CDI-32™.

message_type Message

3E4016 PATH MAPPING

3E4116 PATH REQUEST

3E4216 PATH TEARDOWN

3E4316 PATH ENDPOINT

u

(0)

most significant

message_length (68) message_type

message_ID

length (56) type (3E0016) u

(0)

f

(0)

company_ID (A02D16) version (0)

least significant

sink_EUI_64

x u

source_plug sink_plug

aggregate_payload

latency

source_quantum

window

max_payload

source_bit_rate

lifetime label reserved

source_EUI_64

sink_address

source_address

controller_address

relay_agent_EUI_64

l d

http://standards.ieee.org/regauth/oui/tutorials/CDI32.html



All path management messages have one mandatory parameter, the Path Parameters TLV, which has a type of

3E0016.

The controller_address field shall contain the IPv4 address of the device that originated the path management

message, either an FCP/IP-capable controller or an AV/C relay agent.

The sink_address field shall contain the IPv4 address of the sink (if it is FCP/IP-capable) or the IPv4 address of an

AV/C relay agent (if the sink is legacy AV/C).

The source_address field shall contain the IPv4 address of the source (if it is FCP/IP-capable) or the IPv4 address of

an AV/C relay agent (if the source is legacy AV/C).

When message_type is PATH ENDPOINT, the relay_agent_EUI_64 field shall contain the target surrogate’s

EUI-64, obtained from its bus information block.

The sink_EUI_64 field shall contain the sink’s EUI-64, obtained from its bus information block.

The source_EUI_64 field shall contain the source’s EUI-64, obtained from its bus information block. The stream to

which the path management message pertains is uniquely identified by the pair (source_EUI_64, source_plug),

collectively known as a stream ID. A stream ID is globally unique and is persistent across bus resets and network

topology changes.

NOTE – The sink_EUI_64 and source_EUI_64 fields contain the EUI-64 of the device that is actually receiving or

transmitting, respectively, the isochronous data stream. If the connection requires the use of one or more AV/C relay agents,

their EUI-64s never appear in either of these fields.

The source_plug field shall uniquely identify a stream transmitted by the source within the context of the source

itself. When source_plug is in the range zero to 1E16, inclusive, it identifies an output plug control register (oPCR) or

functionally equivalent object that mediates transmission of the stream. Other values of source_plug are reserved for

future standardization.

The sink_plug field shall uniquely identify a stream received by the sink within the context of the sink itself. When

sink_plug is in the range zero to 1E16, inclusive, it identifies an input plug control register (iPCR) or functionally

equivalent object that mediates reception of the stream. Other values of sink_plug are reserved for future

standardization.

NOTE – Output and input plug control registers are specified by IEC 61883-1 [R2].

The max_payload field shall specify the maximum number of data bytes that the source may transmit in a single

isochronous stream SDU. The value of max_payload does not include the IEEE 1394 packet header, header CRC or

data CRC nor, for media other than IEEE 1394, does not include the SDU header; it counts only bytes within the

data payload.

The latency field shall contain the sum of the isochronous delays, in units of 125 µs, encountered by an isochronous

stream originated by the source and destined for the sink. This field is updated by each ingress port on the path

between the source and sink by a value determined as the path is established.

The window field specifies the size of a smoothing window, in units of 125 µs. The value of window, when combined

with the maximum aggregate payload, could permit a bridge to determine if it is capable of transporting an

isochronous stream whose maximum payload exceeds the bandwidth available to one or both of the bridge’s ports

during a single 125 µs interval. The implementation details of such a bridge are beyond the scope of this

specification. When window is zero, no aggregate payload information is provided.



The meaning of the aggregate_payload field is unspecified when window is zero. Otherwise, during any interval of

window * 125 µs, the isochronous stream's aggregate data payload, in bytes, shall not exceed the value of

aggregate_payload.

A window value of either zero or one describes the same situation: a smoothing window of 125 µs. The only

difference is that a window value of one obligates the values of aggregate_payload and max_payload to be identical.

The source_quantum field specifies the smallest indivisible data size, in bytes, generated by the source of the

isochronous stream; it shall include any encoding format overhead but shall exclude the isochronous header, header

CRC or data CRC that are part of an isochronous stream packet. When source_quantum is zero, no information is

provided.

The meaning of the source_bit_rate field is unspecified when source_quantum is zero. Otherwise, it shall specify the

source’s bit rate, in bits per second and shall include any encoding format overhead but shall exclude the packet

header, header CRC and data CRC that are part of an IEEE 1394 stream packet.

NOTE – For example, the source quantum for an MPEG transport stream encoded per IEEE 61883-4 is 192 bytes,

comprised of a 188-byte transport stream packet (TSP) prefixed by a 4-byte source packet header. If the transport stream’s

bit rate were 19.4 Mb/s, the value of source_bit_rate would be 19.8 Mb/s in order to include the source packet header

overhead.

The label field shall specify the label used on the local link segment to associate the isochronous stream with the

correct FEC. When the local link is IEEE 1394, the label field shall contain the isochronous stream's channel

number. Otherwise, when the local link segment utilizes coaxial cable, the field shall contain the IEEE 802.15.3

Stream Index assigned to the isochronous stream.

The legacy_CMP bit (designated as l in the preceding figure) is meaningful within a PATH REQUEST message.

When zero, L3 IP bridges are responsible to program endpoint PCRs. Otherwise, a value of one, indicates the

presence of a legacy controller in the same cluster as that of the relay agent that originated the PATH REQUEST

message. In the latter case, the legacy controller is responsible to program the relay agent's output or input PCR as

well as the complementary input or output PCR.

The sink_surrogate bit (designated as s in the preceding figure) is meaningful within a PATH ENDPOINT message.

When zero, the relay agent that transmitted the message is a source target surrogate; otherwise it is a sink target

surrogate.

The cycle_sync_error bit (designated as x in the preceding figure) shall be one if the path traverses one or more

IEEE 1394 clusters whose cycle master's cycle offset is not phase locked to that of the net cycle master. The user

should be notified and provided with a vendor-dependent troubleshooting methodology to resolve the problem.

The upstream bit (designated as u in the preceding figure) is meaningful only for a PATH TEARDOWN message.

When the bit is zero, the message shall be propagated downstream, i.e., away from the stream's source. Otherwise,

the message shall be propagated upstream towards the source.

The lifetime field shall specify the time remaining, in seconds, before the stream's terminal egress port shall tear

down the path for the sink.

Not all fields in the Path Parameters TLV are applicable to all message types. Table 1 specifies, for each message

type, which path parameters shall be initialized, which may be initialized and which are not applicable.



Table 1 – Path management message initialization matrix

Path parameter

message_type

PATH

MAPPING

PATH

REQUEST

PATH

TEARDOWN

PATH

ENDPOINT

controller_address M M M M

sink_address M M M M

source_address M M M M

relay_agent_EUI_64 N/A N/A N/A M

sink_EUI_64 M M M M

source_EUI_64 M M M M

source_plug M M M M

sink_plug M M M M

max_payload N/A M N/A M

latency M N/A N/A N/A

window N/A O N/A O

aggregate_payload N/A O N/A O

source_quantum N/A O N/A O

source_bit_rate N/A O N/A O

label M N/A N/A M

legacy_CMP M N/A N/A N/A

sink_surrogate N/A N/A N/A M

cycle_sync_error M M N/A N/A

upstream N/A N/A M N/A

lifetime M M N/A N/A

M Mandatory O Optional N/A Not applicable



5.2.7 PATH NOTIFICATION message

Figure 18 specifies the format of the PATH NOTIFICATION message.

Figure 18 – PATH NOTIFICATION message format

The message_type field shall have a value of 3E4416.

The PATH NOTIFICATION message has a single, mandatory parameter, the Path Status TLV, whose type is 3E3016.

The Path Status TLV unknown and forward_unknown bits (designated as u and f, respectively, in the preceding

figure) shall be zero.

The peer_message_ID field shall contain the message ID of the PATH REQUEST or PATH TEARDOWN message

to which the notification pertains.

The status_code field is subdivided into several subfields, as illustrated by Figure 19.

Figure 19 – Status code subfields

The fatal_error bit (designated as e in the preceding figure) shall be set to one if this is a fatal error and zeroed

otherwise.

The forward_unknown bit (designated as f in the preceding figure) shall be zero.

The status_data subfield shall contain a value enumerated in the table below. The fatal_error bit shall be zeroed or

set to one as indicated.

fatal_error status_data Description

0 0 The operation completed successfully.

1 3F00 3E0016 One or both of the source_plug or sink_plug fields reference a nonexistent

oPCR or iPCR at the source or sink device, respectively.

status_data

u

(0)

most significant

message_length (24) message_type (3E4416)

message_ID


(0)

f

(0)

company_ID (A02D16) version (0)

reserved latency

least significant

lifetime

status_code

peer_message_ID


e f

reserved



fatal_error status_data Description

3F00 3E0116 One or both of the source_address or sink_address fields specify an

unroutable IPv4 address.

3F00 3E0216 Isochronous resources, either IEEE 1394 bandwidth and channel number or

piconet stream resources, are unavailable. Retry the PATH REQUEST later.

3F00 3E0316 The maximum burst isochronous payload is too large to be transported

within a single isochronous packet.

3F00 3E0416 The attempted overlay of an existing isochronous stream failed because the

streams transmission speed is faster than the new sink's maximum speed.

3F00 3E0516 The stream identified by Stream ID does not exist.

3F00 3E0616 The stream does not flow through the cluster to which the relay agent is

connected.

3F00 3EFF16 An internal, unexpected error has occurred.

When status_code is zero, the latency field shall contain the end-to-end isochronous delay, in units of 125 µs,

encountered by an isochronous stream originated by the source and destined for the sink. The value of latency is

unspecified when status_code is nonzero.

When status_code is zero, the lifetime field shall specify the time remaining, in seconds, before the stream's terminal

egress port shall tear down the path to the sink. The value of lifetime is unspecified when status_code is nonzero.

5.2.8 TIME OFFSET message

The TIME OFFSET message is used to calculate the relative time difference, in cycles, between two IEEE 1394

clusters in a network. The format of this message is illustrated by Figure 20.

Figure 20 – TIME OFFSET message format

The message_type field shall have a value of 3E5016.

The delta_cycles field is a 64-bit signed integer in two’s-complement notation that represents the time difference, in

cycles, between cycle time for the sender's cluster and the recipient's cluster. The originator of a TIME OFFSET

message shall zero the delta_cycles field before transmission.

u

(0)

most significant

message_length (20) message_type (3E5016)

message_ID

company_ID (A02D16)


(0)

f

(0)

version (0)

delta_cycles

least significant



5.3 DHCP message

As a convenience to the reader, a brief description of DHCP messages is provided with attention drawn to those

fields and circumstances with requirements particular to IEEE 1394. The format of DHCP messages, requests and

replies, is specified by [R12] and here reproduced as Figure 21.

Figure 21 – DHCP request/reply format

The op field shall specify the BOOTP message type; a value of one indicates BOOTREQUEST and two indicates

BOOTREPLY.

The htype shall specify the hardware type, i.e., the nature of the hardware address found in the chaddr field. For

DHCP requests originated by IEEE 1394 devices, htype shall be equal to 24 (see [R14]).

The hlen shall specify the length, in octets, of the hardware address contained within the 16-octet chaddr field. For

DHCP requests originated by IEEE 1394 devices, hlen shall be zero.

The hops field may be used by BOOTP relay agents. DHCP clients shall zero this field.

The xid field shall be initialized by the DHCP client to a pseudorandom number; the field serves as a transaction ID

that associates a DHCP server response with its matching request.

The secs field may be initialized by the DHCP client with the number of seconds elapsed since the client began the

current address acquisition or lease renewal process.

b secs

giaddr

ciaddr

xid

most significant

least significant

hlen (0) hops

chaddr (0)

op htype (24)

siaddr

yiaddr

sname

reserved

file

options



The broadcast bit (designated as b in the preceding figure) controls the transmission mode of the IP datagram that

contains the DHCP request or reply. If broadcast is equal to one, the datagram shall be broadcast to FF.FF.FF.FF16.

Otherwise, when broadcast is zero, the datagram shall be unicast to the appropriate IP address: ciaddr, yiaddr,

siaddr or giaddr. An IEEE 1394 device that does not have a DHCP-assigned IP address or is not yet responsive to

ARP requests shall set broadcast to one in any DHCPDISCOVER or DHCPREQUEST message it transmits. Once

an IEEE 1394 device has a DHCP-assigned IP address, it shall zero the broadcast bit in all subsequent DHCP

messages and initialize ciaddr with the assigned address (see [R14]).

The ciaddr field, if nonzero, shall specify the client's IP address. The DHCP client shall initialize this field only if it

has a DHCP-assigned IP address, i.e., only if it is in the BOUND, RENEW or REBINDING state and is responsive

to ARP requests.

The yiaddr field, if nonzero, shall specify the IP address offered by the DHCP server (from the server's perspective,

it is ―your‖ IP address).

The siaddr field, if nonzero, shall specify the IP address of the next server to use in the bootstrap process. The field

is meaningful only in DHCPOFFER and DHCPACK server responses.

The giaddr field, if nonzero, shall specify the BOOTP relay agent’s IP address, i.e., the gateway's IP address.

The 16-octet chaddr field shall specify the client hardware address. The format of the field and its usable length are

determined by the htype and hlen fields, respectively. For DHCP requests originated by IEEE 1394 devices, chaddr

shall be zero (see [R14]).

The 64-octet sname field, if nonzero, shall specify the DHCP server host name.

The 128-octet file field, if nonzero, shall specify the bootstrap filename. IEEE 1394 devices typically zero this field.

The options field is variable in length and may contain a variety of optional parameters. [R12] requires a DHCP

Message Type option and [R14] requires a Client Identifier option. For the convenience of the reader, the format of

the minimum set of required options for IEEE 1394 devices is illustrated by Figure 22.

Figure 22 – DHCP 1394 mandatory options

The magic_cookie field identifies the encoding of the options that follow (see [B8]). With few exceptions, the

options are encoded as (type, length, value) triplets.

The first option, whose code value is 53, identifies the DHCP Message Type option. Permitted values for the

dhcp_message_type field, as summarized by the table below:

most significant

least significant

dhcp_message_type pad (0) code (53) len (1)

eui_64

len (9) type (27) pad (0) code (61)

end (FF16) pad (0)

magic_cookie (6382 536316)



Value DHCP Message Type

1 DHCPDISCOVER

2 DHCPOFFER

3 DHCPREQUEST

4 DHCPDECLINE

5 DHCPACK

6 DHCPNAK

7 DHCPRELEASE

The second option8, whose code value is 61, specifies a Client Identifier that the DHCP server and IEEE 1394 use to

identify the client uniquely. The hardware_type field shall have a value of 27 (see [R14] and [B8]). The IEEE 1394

device's unique identifier, its EUI-64, shall be used as the Client Identifier.

The last option, with a code value of FF16, is required to signal the end of the options. It may be followed by zero or

more pad octets.

5.4 Cycle master adjustment packet

A cycle master adjustment packet, illustrated by Figure 23, instructs the recipient to adjust the interval between

successive cycle synchronization events. Cycle master adjustment packets shall not be transmitted except during an

isochronous interval; transmission is optional but shall not exceed a single packet per isochronous interval. No

bandwidth shall be allocated for cycle master adjustment packets.

Figure 23 – Cycle master adjustment packet format

The data_length field shall be zero.

The tag field shall be three.

The channel field shall be 31 (the default broadcast channel).

The tcode field shall be A16 (a stream packet).

The sy field shall indicate the adjustment to be made to the cycle master’s behavior at the time of the next cycle

synchronization event. The adjustment is effected by a temporary override of the threshold value above which

CYCLE_TIME.cycle_offset wraps to zero and causes CYCLE_TIME.cycle_count to increment. An sy value of one,

two or three specifies that the threshold shall be set to 3072, 3071 or 3070, respectively. An sy value of zero is

reserved. If a cycle master observes a cycle master adjustment packet with a zero sy value, it shall ignore the packet

and not adjust the threshold value. Upon the next cycle synchronization event, the threshold value shall be restored

to 3071.

8 Strictly speaking, it is the fourth option. Each pad octet is formally defined as an option, the Pad option. The pad octets are not

required; they have been included solely to make the quadlet-aligned documentation format easier to read.

data_length tag channel tcode sy

header_CRC

most significant

least significant



The cycle master adjustment packet sy values of three and one correspond to ―go fast‖ and ―go slow‖ commands sent

to the cycle master; they hasten or delay, respectively, the next cycle synchronization event by one tick of the cycle

master’s 24.576 MHz oscillator.

Nodes other than the cycle master may ignore cycle master adjustment packets.

Global asynchronous stream packets (GASP) also use the default broadcast channel. In order to identify cycle master

adjustment packets reliably, recipients shall verify that all of the packet header fields have the values specified

above. A GASP is differentiated from a cycle master adjustment packets in two important ways: a) the data_length

field is greater than or equal to eight and b) the sy field is either zero or greater than or equal to four.

5.5 MSDU header

Data transmitted over coaxial cable shall be contained within an IEEE 802.15.3 MSDU whose Frame Type is 1012,

data frame. The first four octets of such a data frame shall contain an MSDU header in the format illustrated by

Figure 24.

octets:2 2

Protocol ID Length

Figure 24 – Standard MSDU header format

The Length field specifies, in octets, the size of the MSDU that follows the MSDU header.

The Protocol ID field specifies the type of protocol data unit (PDU) contained within the MSDU. Assigned values

for Protocol ID are enumerated in the table below. All values of Protocol ID not enumerated in the table are reserved

for future standardization.

Protocol ID Description Reference

0 Reserved; not to be standardized

1 Cycle time message 7.4.2.1

2 IEEE 1394 stream SDU 7.3.3

3 Expedited FCP data unit 5.9

4 RST BPDU 5.1

80016 Internet protocol (IPv4) 6.5

80616 ARP 6.2

E00016 – EFFF16 Vendor-specific

FFFF16 Reserved; not to be standardized

NOTE – Despite the assignment of familiar numbers, e.g., 80016 and 80616, the Protocol ID field is not an etherType; it is

an assigned number administered entirely by the 1394 Trade Association.

When the Protocol ID field has a value in the range E00016 through EFFF16, inclusive, the MSDU header contains

vendor-specific information and uses the longer format illustrated by Figure 25.



octets:3 2 2

OUI Protocol ID Length

Figure 25 – Vendor-specific MSDU header format

The meaning and usage of the first two fields, Length and Protocol ID, remain as described above.

The Protocol ID field shall be immediately followed by a nonzero 24-bit organizationally unique identifier (OUI)

obtained from the IEEE Registration Authority. The OUI field identifies the company or organization responsible to

specify the format, meaning and usage of the remainder of the MSDU.

5.6 RTTM command frames

A bridge uses an RTTM request command to enable or disable another bridge's RTTM or uses an RTTM response

command to confirm its own RTTM to another bridge. The formats of request and response RTTM command frames

are specified by Figure 26 and Figure 27, respectively.

octets:1 1 1 3 2 2

Stream Index Enable RTTM Request ID OUI Length Command Type

Figure 26 – RTTM request command frame format

The value of the Command Type field shall be 10016 for an RTTM request command frame.

The Length field shall specify, in octets, the size of the remainder of the command frame and shall have a value of 6.

The OUI shall have a value of 00A02D16, which identifies the 1394 Trade Association as the organization

responsible for the definition of the RTTM command frames.

In an RTTM command frame, the Request ID field shall contain a value generated by the originating bridge that is

unique within the context of the bridge.

The Enable RTTM field instructs the recipient to disable or enable RTTM according to its zero (FALSE) or nonzero

(TRUE) value.

When Enable RTTM field is TRUE, the Stream Index field shall be equal to the unassigned stream index; otherwise,

the Stream Index field shall contain a valid stream index assigned by the PNC, which shall identify the isochronous

stream to be used for expedited FCP command and response frame transmissions when RTTM is active

octets:1 1 3 2 2

Reason Code Request ID OUI Length Command Type

Figure 27 – RTTM response command frame format

The Command Type field shall be 10116 for an RTTM response command frame.

The Length field shall specify, in octets, the size of the remainder of the command frame and shall have a value of 5.

The value and meaning of the OUI field are unchanged from the RTTM request command frame.



In an RTTM response frame, the value of the Request ID field shall identify the RTTM request command frame to

which the RTTM response command frame pertains.

The value of the Reason Code field shall specify the completion status of the RTTM request, as enumerated in the

table below:

Value Name Description

0 SUCCESS The target bridge and MAC RTTM is enabled or

disabled according to the value of Enable RTTM.

1 INVALID PARAMETER One or more of the parameters has a value outside

its permitted range.

2 NOT ASSOCIATED The peer bridge identified by TrgtID is not

associated with the piconet at present.

3 NOT IMPLEMENTED Some or all of the pertinent DEV components—

bridge entity, MAC entity or MLME—do not

support RTTM.

4 REQUEST DENIED The bridge and MAC RTTM have been enabled

by a different bridge than the originator of the

RTTM request.

5 RESOURCES

UNAVAILABLE

Most commonly, there is insufficient unallocated

time with the superframe—but it might also be

caused by a lack of control structures.

FF16 UNSPECIFIED ERROR An unspecified error has occurred; the request has

not been completed.

5.7 IEEE 1394 stream service data unit

Individual IEEE 1394 stream packets, asynchronous or isochronous, are encapsulated as stream service data units

(stream SDUs) for intermediate transport between L3 IP bridge coaxial cable ports. Figure 28 specifies the format of

a stream SDU. An MSDU may contain multiple stream SDUs for multiple streams but shall not contain data in any

other format. The original IEEE 1394 stream packet (shown shaded in gray) remains intact when encapsulated as a

stream SDU.

Figure 28 – IEEE 1394 stream SDU format

The label field shall contain the MPLS label assigned during path setup.

The isochronous bit (designated as i in the preceding figure) specifies the type of stream packet encapsulated. If the

bit is one, the stream SDU contains an isochronous stream packet. Otherwise, when isochronous is zero, the stream

SDU contains an asynchronous stream packet, in which case the cycle_number field shall be ignored.

cycle_number

data

most significant

least significant

label

data_length tag channel tcode (A16) sy

i d rsv



The data_error bit (designated as d in the preceding figure), when one, indicates that the stream SDU’s data payload

was received by a bridge port with a DATA_ERROR (see [R7]).

The cycle_number field consists of the most significant 20 bits of cycle time: 7-bit second_count and 13-bit

cycle_count. This timestamp serves two purposes: a) an expiration time, after which the IEEE 1394 stream SDU is

discarded and b) a presentation time that regulates isochronous transmission within an IEEE 1394 cluster.9 When an

L3 IP bridge IEEE 1394 port receives an isochronous packet, it adds a stream-dependent adjustment value to the

cycle number observed at the time of the packet's receipt and stores the result in the cycle_number field. The bridge

determines the adjustment value when the path is created; it adjusts for the difference between the bridge’s ingress

and egress ports’ cycle numbers, queuing delays within the bridge and transmission delays (including retries) across

the coaxial cable. Although the adjustment value can vary from stream to stream, it shall remain constant for the

lifetime of a particular stream. The adjusted cycle_number value represents the intended presentation time for the

isochronous stream SDU. When a coaxial cable port receives an isochronous stream SDU, if the current cycle

number obtained from the port's CYCLE_TIME register is later than cycle_number, the port shall discard the

expired isochronous stream packet. Otherwise, cycle_number shall be adjusted by a value appropriate for the next

hop and the stream SDU shall be transferred to the co-port for transmission.

The definition and usage of the data_length, tag, channel, tcode and sy fields are specified by IEEE 1394 (see [R6]

[R7]). The tag field determines the format of the isochronous packet's data payload, as summarized by the table

below.

Multiple IEEE 1394 stream SDUs may be aggregated into a single MSDU, which shall be prefixed by an MSDU

header (see 5.5) whose Protocol ID field shall have a value of two.

5.8 Common isochronous packet (CIP) data

If an isochronous stream packet's tag field has a value of one, the format of the packet's data field conforms to [R2],

as illustrated by Figure 29.The CIP format divides the data payload into two parts: the CIP header and application-

dependent data that follows. Figure 29 illustrates an isochronous stream packet that conforms to [R2].

Figure 29 – Common isochronous packet (CIP) format

9 The cycle_number field is necessary because the MAC affords insufficiently fine control over MSDU lifespan and no control

over MSDU presentation time.

tag Data format

0 Data field format unspecified

1 Data field and sy field specified by IEC 61883-1 (2003-01)

2 – 3 Reserved for future standardization

…

1 data_length

most significant

least significant

channel tcode sy

application data

…

CIP_header



The CIP header is a variable number of quadlets (although only two are shown in the preceding figure). The most

significant bit of each quadlet of the CIP header is called the eoh bit. For an n-quadlet CIP header, eoh is zero for

quadlets zero through n - 2, inclusive, and eoh is one for quadlet n - 1. The next most significant bit of each quadlet

is called the form bit. Together, the eoh and form bits specify the format of the CIP header quadlet. CIP header

formats are defined for form values of zero; form values of one are reserved for future standardization.

The only CIP header format currently defined is a two-quadlet header shown below.

Figure 30 – Two-quadlet CIP header format

The sid, or source ID, field identifies the node whose plug control registers control the source of the isochronous

data.

The dbs, or data block size, field contains the size of each of the application-dependent data blocks that follow the

CIP header. A dbs value of zero encodes a size of 256 quadlets; for all other values of dbs, the number of quadlets is

the value of dbs itself. Individual data blocks are entirely contained within a single IEEE 1394 isochronous packet

(which may encapsulate more than one data block).

The fn, or fraction number, field contains the number of data blocks that form a higher level, application-dependent

object—the isochronous source packet. The number of data blocks that form an isochronous source packet is

specified as 2 fn

; when there is a one-to-one correspondence between isochronous source packets and data blocks fn

is zero.

The qpc, or quadlet padding count, field contains the number of pad quadlets appended to an isochronous source

packet before it is divided into data blocks. The quadlet padding count is less than the data block size and has a value

that results in equal sizes for the data blocks. If fn is zero, qpc is also zero. When qpc is nonzero, the last data block

includes the pad quadlets.

The sph, or source packet header, bit (designated as s in Figure 30) is one if the isochronous source packet begins

with a header quadlet of the format shown below; otherwise, it is zero.

Figure 31 – Source packet header format

The source packet header contains a timestamp encoded in the same fashion as the least significant 25 bits of the

CYCLE TIME register.

The dbc, or data block continuity counter, field contains the sequence number of the isochronous source packet and

the sequence number of the data block within the isochronous source packet. The least significant fn bits of dbc hold

the sequence number of the data block while the most significant 8 - fn bits hold the sequence number of the

isochronous source packet itself. The data block sequence number pertains to the first data block that follows the CIP

header; the sequence numbers of subsequent data blocks are implicit and increase monotonically from the value of

dbc.

fn dbs

cycle_count reserved

most significant

least significant

cycle_offset

0

most significant

least significant

r dbc sid qpc s

fmt-dependent 2 fmt



NOTE – The data block that immediately follows the CIP header is not necessarily the first data block of the isochronous

source packet. The location of the starting data block of an isochronous source packet can be determined from the values of

dbc and fn. Relative to the first data block after the CIP header (counting from zero), the ordinal number of this data block

is given by (2 fn - (dbc modulus 2 fn)) modulus 2 fn. If a source packet header is present (as indicated by the sph bit), it is the

first quadlet of this data block.

The fmt field specifies the formats of both the fmt-dependent field within the same quadlet of the CIP header and the

application-dependent data contained within the common isochronous packets. An fmt value of 3F16 indicates that no

application-dependent data follows the CIP header and that the dbs, fn, qpc fields, the sph bit and the dbc field in the

CIP header shall be ignored. Other values of fmt encode the application-dependent format of the isochronous data,

e.g., DVCR or MPEG. The details of most application-dependent formats are not relevant to L3 IP bridges and are

beyond the scope of this specification. However, the value of fmt specifies the format of the fmt-dependent field

within the same quadlet of the CIP header; this field is meaningful to L3 IP bridges when it contains a timestamp,

since the timestamp is transformed each time the isochronous stream packet traverses an L3 IP bridge. The table

below summarizes the recommended meanings of fmt for L3 IP bridges.

When fmt is in the range zero to 1F16, inclusive, the second quadlet of the CIP header has the format illustrated

below.

Figure 32 – Synchronization time (syt) format

The two fields, cycle_count and cycle_offset, are collectively referred to as the syt, or synchronization time, field.

When syt has a value of FFFF16, no synchronization time information is present. Otherwise, the syt field represents a

timestamp encoded in the same fashion as the least significant 16 bits of the CYCLE_TIME register. Just as in the

case of the CYCLE_TIME register, the value of cycle_offset is constrained to be in the range zero to 3071 inclusive.

Values of syt for which cycle_offset is greater than 3071 are invalid.

5.9 Expedited FCP data unit (XFC PDU)

FCP command and response frames to the expedited are received by an L3 IP bridge as asynchronous block writes

addressed to an XFCP register. For transfer across the coaxial cable medium, the bridge shall encapsulate individual

FCP frames within an expedited FCP data unit (XFC PDU). Figure 33 specifies the format of an XFC PDU.

fmt Description

0 – 1F16 Application data is present; the fmt-dependent field

contains a timestamp defined by syt below

2016 – 3E16 Application data is present; the contents of the fmt-

dependent field are unspecified

3F16 No application data is present

cycle_count fmt-dependent


cycle_offset 2 fmt



Figure 33 – Expedited FCP protocol data unit (XFC PDU) format

The source_IP_address field shall contain the IP address of the device that transmitted the FCP command or

response frame to the L3 IP bridge's XFCP register. The bridge obtains the IP address by reverse lookup of the

transmitter's IEEE 1394 node ID in the bridge's ARP cache.

The destination_IP_address field shall contain the IP address of the intended recipient of the FCP command or

response frame. If the XFC PDU contains an FCP command frame, the bridge uses the address of the XFCP register

that received the command frame to derive destination_IP_address. Otherwise, for an FCP response frame, the

bridge uses information kept for the pending FCP transaction information to derive destination_IP_address.

The type field shall specify the type of FCP frame carried within the XFC PDU, as enumerated by the table below:

When type is equal to one, source_IP_address identifies an AV/C target; the rcode field shall indicate the transaction

completion status of the most recent block write request to the target's FCP command register, as encoded by the

table below. Otherwise, the value of rcode is unspecified.

rcode Name Description

0 Complete The most recent attempt to deliver an FCP command frame to the

target succeeded.

1 – 3 Reserved for future standardization.

4 Conflict error A resource conflict prevented the target from accepting the FCP

command frame; the controller may resend the command frame.

5 Data error A data CRC or hardware error prevented the target from accepting the

FCP command frame; the controller may resend the command frame.

6 Type error The type field in the FCPDU was set to a reserved value.

7 – E16 Reserved for future standardization

F16 Timeout The relay agent received no response from the target.

The frame_length field shall specify the size, in bytes, of the fcp_frame field. The value of frame_length shall not

include pad bytes, if any, at the end of the fcp_frame field. When rcode is nonzero, the value of frame_length shall

be zero.

type Description

0 The fcp_frame field contains an FCP command frame.

1 The fcp_frame field may contain an FCP response frame

2– 3 Reserved for future standardization.

frame_length reserved

source_IP_address

destination_IP_address

most significant

least significant

type rcode

fcp_frame



The size of the fcp_frame field shall be an integral number of quadlets and the field shall contain up to 512 bytes of

FCP command or response frame. When frame_length is equal to zero, the fcp_frame field shall be omitted from the

XFC PDU.

When an L3 IP bridge coaxial cable port transmits an XFC PDU, it shall be prefixed by an MSDU header whose

Protocol ID field is equal to three.



6 Internet protocol operations

6.1 Distributed host control protocol (DHCP)

Because IEEE 1394 devices do not have persistent hardware addresses, DHCP for IEEE 1394 devices (see [R14])

operates somewhat differently than does DHCP for other media, e.g., IEEE 802.3 or IEEE.802.15.3. Clause 5.3

describes the DHCP message format and those fields that require special handling in the case of IEEE 1394 devices,

while clauses 6.1.1 and 6.1.2, respectively, specify IEEE 1394 host device (i.e., DHCP 1394 client) operations and

prohibit L3 IP bridge port operations as a BOOTP relay agent.

NOTE – The authoritative sources of information on DHCP and DHCP for IEEE 1394 devices are the RFCs cited below.

With the exception of 6.1.2, the material in 5.3 and 6.1 restates portions of the pertinent RFCs; it is provided solely for the

reader's convenience. In case of conflict between the text in this document and a referenced RFC, the RFC shall take

precedence.

6.1.1 IEEE 1394 DHCP client operations

IEEE 1394 devices that conform to [R13] (this includes L3 IP bridge IEEE 1394 ports) shall attempt to obtain an IP

address from the local network DHCP server, if present. The IEEE 1394 device is a DHCP client and shall follow the

procedures specified by [R14].

6.1.2 BOOTP/DHCP relay agent operations

Because the scope of L3 IP bridge operations is restricted to the local network, L3 IP bridges shall not function as

BOOTP/DHCP relay agents (see [B9]). Since the purpose of a BOOTP/DHCP relay agent is to forward BOOTP and

DHCP requests and responses across a router barrier, and since an L3 IP bridge does not present such a barrier,

implementation of a BOOTP/DHCP relay agent within an L3 IP bridge would be at the best quixotic and at the worst

problematic.

6.2 Address resolution protocol (ARP)

Address resolution protocol (ARP) resolves a known IP address to its corresponding protocol stack layer 2 (L2)

hardware address. ARP operates transparently over L2 bridges that connect links with compatible hardware

addresses. ARP fails over L2 bridges that connect links with incompatible hardware addresses, e.g., Ethernet and

IEEE 1394.10

L3 IP bridges solve this problem by operating at protocol stack layer 3, Internet protocol. Incoming ARP requests are

parsed and converted to an appropriate ARP format for retransmission by the recipient's co-port; outgoing ARP

responses received from the co-port are parsed and converted back to the appropriate local ARP format. The L3 IP

bridges act as ARP relay agents that translate between different ARP formats. In order to do this, each bridge

maintains data structures that are populated dynamically as ARP requests and responses flow through the bridge.

10 The fundamental problem is unique device identifiers of different lengths. An Ethernet MAC-48 can be mapped to a unique

EUI-64 by the insertion of 16 bits, but it is impossible to derive a unique MAC-48 by removing 16 bits from an EUI-64.



6.2.1 IEEE 1394 port

IEEE 1394 L3 IP bridge ports shall process all ARP requests and responses, whether received from an IP host

connected to the bridge port's IEEE 1394 or received from its co-port. The format of IP1394 ARP requests and

responses is specified by [R13] and informatively reproduced by Figure 34 for the reader's convenience.

Figure 34 – IP1394 ARP request/response format

An L3 IP bridge IEEE 1394 port listens to all global asynchronous stream packets (GASP) received on channel 31,

the default broadcast channel.11

For each ARP request or response received, the bridge port shall update its ARP

cache with the tuple (sender_IP_address, sender_unique_ID, sender_max_rec, sspd, sender_unicast_FIFO). All

ARP responses shall be forwarded to the coaxial cable co-port. Gratuitous ARP requests12

shall not be forwarded to

the coaxial cable co-port. ARP requests resolvable by information in the L3 IP bridge IEEE 1394 port's ARP cache

should not be forwarded to the co-port; the IEEE 1394 port should return an ARP response as described below. All

other ARP requests shall be forwarded to the co-port.

An L3 IP bridge port also receives ARP requests and responses from its coaxial cable co-port. Before it retransmits

the ARP request or response to the IEEE 1394 cluster, the L3 IP bridge IEEE 1394 port shall update its route table

with sender_IP_address. The ARP request or response shall be reformatted as follows:

11 See [R7] and [R13] for details. 12 Gratuitous ARP requests of those for which the sender IP address and target IP address are equal.

L3 IP Bridge Port Data Structure N-tuple Comment

IEEE 1394

ARP cache

IP address

EUI-64

Unicast FIFO

Maximum payload

Maximum speed

Associates the IP address of hosts that

are part of the L3 IP bridge port's IEEE

1394 cluster with the quadruplet

(EUI-64, unicast FIFO, maximum

payload, maximum speed).

Route table IP address

Identifies the IP addresses of remote

hosts that may be reached through this

bridge port.

Coaxial cable Forwarding table IP address

MAC address

Associates the IP address of remote

hosts with the MAC address of the L3

IP bridge coaxial cable port through

which the host may be reached.

sender_unicast_FIFO_hi

sender_IP_address

target_IP_address

sender_unique_ID

most significant

least significant

protocol_type (80016) hardware_type (1816)

hw_addr_len (16) IP_addr_len (4)

sender_max_rec

opcode

sspd

sender_unicast_FIFO_lo



– The hardware_type, protocol_type, hw_addr_len, IP_addr_len and opcode fields shall be initialized as

specified by [R13];

– The sender_unique_ID field shall be set to the value of the L3 IP bridge IEEE 1394 port's EUI-64, the

sender_max_rec field shall be set to the value of max_rec from the port's configuration ROM bus information

block and the sspd field shall encode the lesser of the port's link and PHY speeds;

– The sender_unicast_FIFO_hi and sender_unicast_FIFO_lo fields together shall contain the 48-bit offset of

the L3 IP bridge IEEE 1394 port's FIFO available for the receipt of IP datagrams; and

NOTE – The choice of the sender_unicast_FIFO location is vendor-dependent. An implementation could specify a

different FIFO address to for each remote IP host represented by the L3 IP bridge.

– The sender_IP_address and target_IP_address fields shall be set to values copied from the corresponding

fields in the ARP request or response received from the coaxial cable co-port.

6.2.2 Coaxial cable port

An L3 IP bridge coaxial cable port receives and transmits ARP requests and responses in the standard format

specified by [R11]. ARP requests and responses shall be prefixed by an MSDU header.

When an L3 IP bridge coaxial cable port receives an ARP request from its co-port, it shall transmit the ARP request

to all L3 IP bridge coaxial cable ports in the same piconet. When an ARP response is received, it shall be transmitted

to the coaxial cable port that originated the corresponding ARP request and may be gratuitously transmitted to other

L3 IP bridge ports within the piconet.

When an L3 IP bridge coaxial cable port receives an ARP request or response from another L3 IP bridge in its

piconet, it shall update its forwarding table with the tuple (ar$spa, ar$sha)13

. The forwarding table identifies which

IP addresses are routable through which L3 IP bridge ports within the piconet.

6.3 Link-local address assignment

When a DHCP server is unavailable within the residential network, hosts (which include L3 IP bridge IEEE 1394

ports in their role as a host) shall use the method specified by [R15] to claim and defend an IP address unique within

the context of the residential network. [B10] provides guidance for the detection of a DHCP server.

Link-local address selection specifies that initial selection of an IP address rely on a pseudorandom number generator

whose output has uniform distribution in the range 169.254.1.0 through 169.254.255.255, inclusive. This

specification additionally requires the L3 IP bridge port's EUI-64 or MAC-64, as appropriate, be used as the initial

seed value for the pseudorandom number generation algorithm.

Once a bridge port successfully claims and defends a link-local IP address in the 169.254/16 address family, the

bridge should store it in nonvolatile memory. If the IP address is subsequently abandoned and a new address claimed,

the new address should replace the old in nonvolatile memory. Subsequent to power reset, an L3 IP bridge port

should attempt to claim the last address in use before the power reset. Bridge ports that lack nonvolatile memory

shall seed the pseudorandom number algorithm with their EUI-64 and generate an IP address.

6.4 Rapid spanning tree protocol (RSTP)

L3 IP bridges shall implement RSTP (see [R3]), which serves two purposes: a) the stable creation and maintenance

of a spanning tree for IP datagram routing and b) the selection of a net cycle master for the residential network. The

network's root port shall be an L3 IP bridge IEEE 1394 port and the net cycle master shall be the cycle master of the

IEEE 1394 cluster connected to the root port.

13 The field names are those used by [R11]; ar$spa is the IP address of the IEEE 1394 device that originated the ARP response

and ar$sha is the MAC-64 of the L3 IP bridge port that transmitted the ARP response.



6.5 IP datagram routing

An L3 IP bridge IEEE 1394 port, in its role as an ingress port, may receive IP datagrams in several different ways:

– as a block write request addressed to a unicast FIFO address advertised by the ingress port in an ARP request

or response;

– as a global asynchronous stream packet (GASP) received on the broadcast channel; or

– as an isochronous stream packet received on a channel mutually agreed between the sender and the ingress

port.

Regardless of the mode of receipt, an ingress port shall process an IP datagram as follows:

a) If the destination address is in the broadcast range 240.0.0.0 to 255.255.255.255, inclusive, the ingress port

shall forward the IP datagram to its coaxial cable co-port;

b) If the destination address is in the multicast range 224.0.0.0 to 239.255.255.255, inclusive, the ingress port

shall forward the IP datagram to its coaxial cable co-port;

c) If the destination address matches an entry in the ingress port's route table (see 6.2), the ingress port shall

forward the IP datagram to its coaxial cable co-port; else

d) The ingress port shall either generate an ARP request (in an attempt to resolve the IP address' hardware

address) or discard the IP datagram.

When an L3 IP bridge coaxial cable port receives a broadcast or multicast IP datagram from its co-port, it shall

prefix the IP datagram with an MSDU header and broadcast the IP datagram to all L3 IP bridge coaxial cable ports

connected to the coaxial cable medium. Otherwise, when an L3 IP bridge coaxial cable port receives a unicast IP

datagram from its co-port, it shall search its forwarding table (see 6.2) for an IP address entry that matches the

datagram's destination address. If a match is found, the coaxial cable port shall prefix the IP datagram with an MSDU

header and transmit the IP datagram to the L3 IP bridge coaxial cable port identified by the MAC address in the

forwarding table entry. Otherwise, if no match is found in the forwarding table, the coaxial cable port shall either a)

generate an ARP request in an attempt to resolve the IP address' hardware address or b) discard the IP datagram and

instruct its IEEE 1394 co-port to delete the IP address from the co-port's route table.

NOTE – In order to utilize the coaxial cable bandwidth efficiently, transmissions from one L3 IP bridge coaxial cable port

to another should be aggregated. IP datagrams are eligible for aggregation even if addressed to different IP addresses so

long as they are in transit to the same L3 IP bridge coaxial cable port.

Upon receipt of an IP datagram from the coaxial cable medium, a coaxial cable port shall remove the MSDU header

and transfer the IP datagram to its IEEE 1394 co-port, which, in its role as an egress port, shall process the IP

datagram as follows:

a) If the destination address is in the broadcast range 240.0.0.0 to 255.255.255.255, inclusive, the egress port

shall encapsulate the IP datagram in a GASP for transmission on the broadcast channel;

b) If the destination address is in the multicast range 224.0.0.0 to 239.255.255.255, inclusive, the egress port

shall encapsulate the IP datagram in a GASP for transmission on the broadcast channel;

c) If the destination address matches an entry in the egress port's ARP cache (see 6.2), the egress port shall

encapsulate the IP datagram as specified by [R13] and use a block write request to transmit the datagram to its

final destination; else

d) The egress port shall either generate an ARP request (in an attempt to resolve the IP address' hardware

address) or discard the IP datagram.

An L3 IP bridge port that generates an ARP request upon detection of an unresolved IP address shall retain the IP

datagram for an implementation-dependent time. If the datagram's destination address is resolved by an ARP



response before the time limit expires, the L3 IP bridge port shall forward the IP datagram as specified above.

Otherwise, upon timer expiration the L3 IP bridge port shall discard the IP datagram.



7 Isochronous bridge operations

This section specifies:

a) methods to configure L3 IP bridges to route isochronous stream data from one IEEE 1394 cluster to one or

more other clusters;

b) the operations of an L3 IP bridge to route isochronous stream data subsequent to such configuration;

c) the distribution of cycle time phase-lock synchronization throughout the network; and

d) the transformation of timestamp information as the data traverse L3 IP bridges.

7.1 MPLS initialization

The MPLS and LDP components of an L3 IP bridge rely upon a label information base (LIB) in order to perform

label distribution and label-switched routing of isochronous data. Each L3 IP bridge port maintains a separate LIB,

which consists of:

– HELLO adjacencies with peer L3 IP bridge ports;

– active sessions with peer L3 IP bridge ports; and

– mappings from labels to their associated FEC and next-hop address.

Subsequent to power reset, an L3 IP bridge port's LIB shall be empty. An L3 IP bridge port shall establish active

label distribution sessions with its peer L3 IP bridge ports via a two-step process:

a) peer L3 IP bridge port discovery by means of HELLO messages; and

b) session establishment by means of INITIALIZATION messages.

An L3 IP bridge port shall broadcast, at nominal 5-second intervals, a HELLO message (see 5.2.4) to multicast

address 224.0.0.2 (all routers on the local link segment). The HELLO message shall be encapsulated in an IP

datagram transmitted via UDP to well-known LDP port 646.

When an L3 IP bridge port receives a HELLO message from a peer L3 IP bridge port for which no HELLO

adjacency exists, it shall create an adjacency and set its countdown hold timer to hold_time seconds. Otherwise, for

an existing HELLO adjacency, the countdown hold timer shall be reset to hold_time seconds. If a HELLO

adjacency's hold timer counts down to zero, the adjacency and all sessions dependent upon it shall be deleted from

the LIB.

Upon creation of a HELLO adjacency, an L3 IP bridge port shall attempt to establish a label distribution session with

the peer L3 IP bridge port, as specified by [R17] and briefly described below.

One of the L3 IP bridge ports shall play the active role in session establishment, as determined by the ports’ IP

addresses. The port with the numerically greater IP address shall be active and the other port shall be passive. The

active port initiates TCP connection to well-known LDP port 646 while the passive port awaits connection.

Once a TCP connection is established, the peer L3 IP bridge ports negotiate session parameters through the exchange

of INITIALIZATION messages. A label distribution session remains active so long as neither port's keep-alive timer

counts down to zero; the timer is reset to the value of keep_alive_time upon receipt of any LD PDU. If 15 seconds

elapse without the transmission of an LD PDU to a peer L3 IP bridge port, a KEEP ALIVE shall be transmitted to

reset the peer's keep-alive timer.



7.2 Isochronous path management

Before an isochronous stream may be transferred from a source in one IEEE 1394 cluster to one or more sinks in the

other IEEE 1394 clusters, it is necessary to explicitly establish a path via L3 IP bridges and allocate resources for the

path. Isochronous paths are set up and torn down by the messages described in 5.2.6. This clause contains the

normative specification of L3 IP bridge behavior upon receipt of a path management message. Path management

messages shall be transported by UDP and shall be addressed to well-known LDP port 646.

The C pseudocode that specifies the processing of path management messages uses some common procedures; these

are provided in Table 2 below.

Table 2 – Common path management procedures

#include "csr.h" #include "global.h" #include "packets.h" BOOLEAN allocateResources(PATH_INFO *path, DOUBLET maxPayload, BYTE speed) { DOUBLET packetSize; if (maxPayload == 0) /* Asynchronous stream? */ path->bandwidth = 0; else { packetSize = 3 + (maxPayload + 3) / 4; /* Packet size, in quadlets */ path->bandwidth = 512 + packetSize << (4 - speed); /* Worst-case overhead assumption */ if (!allocateBandwidth(path->bandwidth)) { path->bandwidth = 0; return (FALSE); } } path->channel = allocateChannel(UNASSIGNED); /* Attempt channel allocation */ if (path->channel == UNASSIGNED) { /* No channel available? */ deallocateBandwidth(path->bandwidth); /* Return unneeded bandwidth */ path->bandwidth = 0; return(FALSE); } path->latency = 0; /* No delay for intra-cluster transfers */ path->speed = speed; return(TRUE); /* Success! */ } VOID deallocateResources(PATH_INFO *path) { deallocateBandwidth(path->bandwidth); /* Release bandwidth ... */ deallocateChannel(path->channel); /* ... and channel */ } VOID pathManagement(QUADLET msgDestinationAddress, QUADLET msgSourceAddress, PATH_MSG *pathManagementMsg) { ROUTE_INFO *controllerRoute, *sinkRoute, *sourceRoute; QUADLET erc; controllerRoute = getRoute(pathManagementMsg->controllerAddress); sinkRoute = getRoute(pathManagementMsg->sinkAddress); sourceRoute = getRoute(pathManagementMsg->sourceAddress); switch (pathManagementMsg->messageType) { case PATH_ENDPOINT: if (msgDestinationAddress == ALL_SUBNET_ROUTERS) /* Relay agent multicasts PATH ENDPOINT */ if (controllerRoute == NULL) return; else if (controllerRoute->gatewayAddress != 0) /* Immediately adjacent to relay agent? */ return; /* No, message is for some other L3 IP bridge */ erc = pathEndpoint(pathManagementMsg, controllerRoute, sinkRoute, sourceRoute); if (erc != PENDING) { txNotificationMsg(pathManagementMsg->controllerAddress, pathManagementMsg->messageID, PATH_ENDPOINT, erc); } break;



case PATH_MAPPING: erc = pathMapping(pathManagementMsg, sinkRoute, sourceRoute); if (erc != PENDING) { txNotificationMsg(pathManagementMsg->controllerAddress, pathManagementMsg->messageID, PATH_MAPPING, erc); if (erc && msgDestinationAddress != ALL_SUBNET_ROUTERS) txTeardownMsg(pathManagementMsg->streamID, pathManagementMsg->sinkAddress, UPSTREAM); } break; case PATH_REQUEST: if (msgDestinationAddress == ALL_SUBNET_ROUTERS) /* Controller multicasts PATH REQUEST */ if (sinkRoute == NULL) return; else if (sinkRoute->gatewayAddress != 0) /* Immediately adjacent to sink endpoint? */ return; /* No, message is for some other L3 IP bridge */ erc = pathRequest(pathManagementMsg, sinkRoute, sourceRoute); if (erc != PENDING) { txNotificationMsg(pathManagementMsg->controllerAddress, pathManagementMsg->messageID, PATH_REQUEST, erc); if (erc && msgDestinationAddress != ALL_SUBNET_ROUTERS) txTeardownMsg(pathManagementMsg->streamID, pathManagementMsg->sinkAddress, DOWNSTREAM); } break; case PATH_TEARDOWN: if (msgDestinationAddress == ALL_SUBNET_ROUTERS) /* Controller multicasts PATH TEARDOWN */ if (sinkRoute == NULL) return; else if (sinkRoute->gatewayAddress != 0) /* Immediately adjacent to sink endpoint? */ return; /* No, message is for some other L3 IP bridge */ erc = pathTeardown(pathManagementMsg, sinkRoute, sourceRoute); if (erc != PENDING) txNotificationMsg(pathManagementMsg->controllerAddress, pathManagementMsg->messageID, PATH_TEARDOWN, erc); break; } } VOID txNotificationMsg(QUADLET destinationAddress, QUADLET messageID, DOUBLET messageType, QUADLET status) { NOTIFICATION_MSG notificationMsg; ROUTE_INFO *destinationRoute; if ((destinationRoute = getRoute(destinationAddress)) == NULL) return; memset(&notificationMsg, 0, sizeof(notificationMsg)); notificationMsg.messageType = NOTIFICATION; notificationMsg.messageLength = 14; notificationMsg.messageID = messageID++; notificationMsg.statusTLV.type = STATUS_TLV; notificationMsg.statusTLV.length = 10; notificationMsg.status = status; notificationMsg.peerMessageID = messageID; notificationMsg.peerMessageType = messageType; txLDPDatagram(destinationRoute->port, destinationAddress, &notificationMsg); }

7.2.1 PATH ENDPOINT message processing

When functioning as a target surrogate, a relay agent generates a PATH ENDPOINT when the point-to-point

connection counter one of its target surrogate personae PCRs increments from zero to nonzero. The PATH

ENDPOINT message serves to inform the adjacent bridge of its activation as a stream endpoint. The relay agent

subsequently transmits a PATH REQUEST message on behalf of legacy controller; this message references the actual

source or sink associated with the target surrogate persona as well as its complementary endpoint.

The functional behavior of a bridge port that intercepts a PATH ENDPOINT message is expressed in detail by

Table 3.



Table 3 – L3 IP bridge actions on receipt of a PATH ENDPOINT message

#include "csr.h" #include "global.h" #include "packets.h" QUADLET pathEndpoint(PATH_MSG *pathEndpointMsg, ROUTE_INFO *relayAgentRoute, ROUTE_INFO *sinkRoute, ROUTE_INFO *sourceRoute) { BOOLEAN sinkAdjacent, sourceAdjacent; BYTE sinkSpeed, sourceSpeed; DOUBLET maxPayload; ENDPOINT_INFO *endpoint; NODE_ID sink, source; PATH_INFO *downstreamPath, *upstreamPath; STREAM_INFO *stream; if (relayAgentRoute == NULL || sinkRoute == NULL || sourceRoute == NULL) /* Quick sanity checks */ return(INVALID_ROUTE); if (relayAgentRoute->port->portType != IEEE_1394) return(UNEXPECTED_ERROR); sinkAdjacent = (sinkRoute->gatewayAddress == 0); sourceAdjacent = (sourceRoute->gatewayAddress == 0); if ((pathEndpointMsg->sinkSurrogate && sinkAdjacent) || (!pathEndpointMsg->sinkSurrogate && sourceAdjacent)) return(UNEXPECTED_ERROR); /* Somebody's goofed ... we can't continue */ if (sinkAdjacent) { /* Sanity checks if ONLY sink is immediately adjacent */ if (sinkRoute->port->portType != IEEE_1394 || sourceRoute->port->portType != CABLE) return(UNEXPECTED_ERROR); sink.nodeID = nodeID(pathEndpointMsg->sinkEUI64); iMPR = readInputMasterPlug(sinkRoute->port, sink.phyID); if (pathEndpointMsg->sinkPlug >= iMPR.inputPlugs) return(INVALID_PLUG); sinkSpeed = MIN(pathSpeed(sinkRoute->port, sinkRoute->port->ownPhyID, sink.phyID), iMPR.spd); maxPayload = 2 << (sinkSpeed + 10); if (bridgeCapabilities.maxIsoch != 0) maxPayload = MIN(maxPayload, 2 << bridgeCapabilities.maxIsoch); else maxPayload = MIN(maxPayload, 1024); if (pathEndpointMsg->maxPayload > maxPayload) return(PAYLOAD_TOO_BIG); } else if (sourceAdjacent) { /* Sanity checks if ONLY source is immediately adjacent */ if (sinkRoute->port->portType != CABLE || sourceRoute->port->portType != IEEE_1394) return(UNEXPECTED_ERROR); source.nodeID = nodeID(pathEndpointMsg->sourceEUI64); oMPR = readOutputMasterPlug(sourceRoute->port, source.phyID); if (pathEndpointMsg->sourcePlug >= oMPR.outputPlugs) return(INVALID_PLUG); sourceSpeed = MIN(pathSpeed(sourceRoute->port, source.phyID, sourceRoute->port->ownPhyID), oMPR.spd); maxPayload = 2 << (sinkSpeed + 10); if (bridgeCapabilities.maxIsoch != 0) maxPayload = MIN(maxPayload, 2 << bridgeCapabilities.maxIsoch); else maxPayload = MIN(maxPayload, 1024); if (pathEndpointMsg->maxPayload > maxPayload) return(PAYLOAD_TOO_BIG); } else return(ORRPHAN_SURROGATE); /* Stream's data never gets to this cluster */ if ((stream = findStreamDescriptor(pathEndpointMsg->streamID)) == NULL) { if ((stream = allocateStreamDescriptor()) == NULL) return(RESOURCES_UNAVAILABLE); stream->streamID = pathEndpointMsg->streamID; /* Initialize stream descriptor */ stream->streamParms = pathEndpointMsg->streamParms; upstreamPath = &stream->upstreamPath; upstreamPath->port = sourceRoute->port; downstreamPath = &stream->downstreamPath; downstreamPath->port = sinkRoute->port; } if (pathEndpointMsg->sinkSurrogate) { upstreamPath->localSinks++; /* All of sink surrogate's */ endpoint = allocateEndpointDescriptor(upstreamPath); oPCR = readOutputPlug(sourceRoute->port, source.phyID, pathEndpointMsg->sourcePlug); upstreamPath->channel = oPCR.channel; upstreamPath->speed = oPCR.spd; endpoint->eui64 = pathEndpointMsg->sinkEUI64; endpoint->surrogateEUI64 = pathEndpointMsg->relayAgentEUI64; endpoint->lifetime = pathEndpointMsg->lifetime;



endpoint->plug = pathEndpointMsg->sinkPlug; endpoint->sink = TRUE; endpoint->legacyCMP = TRUE; } else { endpoint = allocateEndpointDescriptor(downstreamPath); iPCR = readInputPlug(sinkRoute->port, sink.phyID, pathEndpointMsg->sinkPlug); downstreamPath->channel = iPCR.channel; endpoint->eui64 = pathEndpointMsg->sourceEUI64; endpoint->surrogateEUI64 = pathEndpointMsg->relayAgentEUI64; endpoint->lifetime = 0; /* Not applicable to source surrogates */ endpoint->plug = pathEndpointMsg->sourcePlug; endpoint->sink = FALSE; endpoint->legacyCMP = TRUE; } return(OK); }

7.2.2 PATH REQUEST message processing

The principal function of a PATH REQUEST message is the allocation of path resources (channel and bandwidth)

and the retention of enough information about the path to permit the reallocation of the resources after bus reset or

their release upon path teardown. Egress ports shall be responsible for both the initial allocation of path resources

and their reallocation subsequent to future bus resets. A secondary use of the PATH REQUEST message is to extend

the path's remaining lifetime for a particular endpoint sink device.

The functional behavior of a bridge port that intercepts a PATH REQUEST message is expressed in detail by

Table 4.

Table 4 – L3 IP bridge actions on receipt of a PATH REQUEST message

#include "csr.h" #include "global.h" #include "packets.h" QUADLET pathRequest(PATH_MSG *pathRequestMsg, ROUTE_INFO *sinkRoute, ROUTE_INFO *sourceRoute) { PATH_INFO *downstreamPath, *upstreamPath; ENDPOINT_INFO *endpoint; BOOLEAN endpointsSameCluster, legacyCMP, sinkAdjacent, sourceAdjacent; QUADLET *gateway; DOUBLET maxPayload; BYTE sinkSpeed, sourceSpeed; NODE_ID sink, source; PATH_MSG pathMappingMsg; STREAM_INFO *stream; if (sinkRoute == NULL || sourceRoute == NULL) /* Are both sink and source routable? */ return(INVALID_ROUTE); sinkAdjacent = (sinkRoute->gatewayAddress == 0); sourceAdjacent = (sourceRoute->gatewayAddress == 0); if (sinkAdjacent && sourceAdjacent) endpointsSameCluster = (sinkRoute->port == sourceRoute->port); if (endpointsSameCluster) { /* Sanity check if BOTH source and sink are adjacent in the same cluster */ if (sourceRoute->port->portType != IEEE_1394) return(UNEXPECTED_ERROR); sink.nodeID = nodeID(pathRequestMsg->sinkEUI64); iMPR = readInputMasterPlug(sinkRoute->port, sink.phyID); source.nodeID = nodeID(pathRequestMsg->sourceEUI64); oMPR = readOutputMasterPlug(sourceRoute->port, source.phyID); if ( pathRequestMsg->sourcePlug >= oMPR.outputPlugs || pathRequestMsg->sinkPlug >= iMPR.inputPlugs) return(INVALID_PLUG); sourceSpeed = sinkSpeed = MIN(pathSpeed(sourceRoute->port, source.phyID, sink.phyID), MIN(oMPR.spd, iMPR.spd)); maxPayload = 2 << (sinkSpeed + 10); if (pathRequestMsg->maxPayload > maxPayload) return(PAYLOAD_TOO_BIG); } else if (sinkAdjacent) { /* Sanity check if ONLY sink is immediately adjacent */ if (sinkRoute->port->portType != IEEE_1394 || sourceRoute->port->portType != CABLE) return(UNEXPECTED_ERROR);



sink.nodeID = nodeID(pathRequestMsg->sinkEUI64); iMPR = readInputMasterPlug(sinkRoute->port, sink.phyID); if (pathRequestMsg->sinkPlug >= iMPR.inputPlugs) return(INVALID_PLUG); sinkSpeed = MIN(pathSpeed(sinkRoute->port, sinkRoute->port->ownPhyID, sink.phyID), iMPR.spd); maxPayload = 2 << (sinkSpeed + 10); if (bridgeCapabilities.maxIsoch != 0) maxPayload = MIN(maxPayload, 2 << bridgeCapabilities.maxIsoch); else maxPayload = MIN(maxPayload, 1024); if (pathRequestMsg->maxPayload > maxPayload) return(PAYLOAD_TOO_BIG); } else if (sourceAdjacent) { /* Sanity check if ONLY source is immediately adjacent */ if (sinkRoute->port->portType != CABLE || sourceRoute->port->portType != IEEE_1394) return(UNEXPECTED_ERROR); source.nodeID = nodeID(pathRequestMsg->sourceEUI64); oMPR = readOutputMasterPlug(sourceRoute->port, source.phyID); if (pathRequestMsg->sourcePlug >= oMPR.outputPlugs) return(INVALID_PLUG); sourceSpeed = MIN(pathSpeed(sourceRoute->port, source.phyID, sourceRoute->port->ownPhyID), oMPR.spd); maxPayload = 2 << (sinkSpeed + 10); if (bridgeCapabilities.maxIsoch != 0) maxPayload = MIN(maxPayload, 2 << bridgeCapabilities.maxIsoch); else maxPayload = MIN(maxPayload, 1024); if (pathRequestMsg->maxPayload > maxPayload) return(PAYLOAD_TOO_BIG); } if ((stream = findStreamDescriptor(pathRequestMsg->streamID)) == NULL) { if ((stream = allocateStreamDescriptor()) == NULL) return(RESOURCES_UNAVAILABLE); stream->streamID = pathRequestMsg->streamID; /* Initialize stream descriptor */ stream->streamParms = pathRequestMsg->streamParms; upstreamPath = &stream->upstreamPath; upstreamPath->port = sourceRoute->port; downstreamPath = &stream->downstreamPath; downstreamPath->port = (endpointsSameCluster) ? NULL : sinkRoute->port; } if (endpointsSameCluster) { if ((endpoint = findEndpointDescriptor(upstreamPath, pathRequestMsg->sinkEUI64)) != NULL) { endpoint->lifetime += pathRequestMsg->lifetime; /* Extend lifetime of existing stream branch */ return(OK); } oPCR = readOutputPlug(sourceRoute->port, source.phyID, pathRequestMsg->sourcePlug); if (upstreamPath->channel == UNASSIGNED) { if (oPCR.broadcastConnection || oPCR.pointToPointConnections > 0) { upstreamPath->speed = oPCR.spd; upstreamPath->channel = oPCR.channel; } else if (allocateResources(upstreamPath, stream->maxPayload, sourceSpeed)) { oPCR.spd = sourceSpeed; oPCR.channel = upstreamPath->channel; } else return(RESOURCES_UNAVAILABLE); } else if (upstreamPath->speed > sourceSpeed || pathRequestMsg->maxPayload > stream->maxPayload) return(STREAM_CONFLICT); if ((endpoint = findEndpointDescriptor(upstreamPath, pathRequestMsg->sourceEUI64)) == NULL) { endpoint = allocateEndpointDescriptor(upstreamPath); endpoint->eui64 = pathRequestMsg->sourceEUI64; endpoint->address = pathRequestMsg->sourceAddress; endpoint->plug = pathRequestMsg->sourcePlug; } oPCR.pointToPointConnections++; programOutputPlug(sourceRoute->port, source.phyID, endpoint->plug, oPCR); upstreamPath->localSinks++; /* Set up new stream branch */ endpoint = allocateEndpointDescriptor(upstreamPath); endpoint->eui64 = pathRequestMsg->sinkEUI64; endpoint->address = pathRequestMsg->sinkAddress; endpoint->lifetime = pathRequestMsg->lifetime; endpoint->plug = pathRequestMsg->sinkPlug; iPCR = readInputPlug(sinkRoute->port, sink.phyID, endpoint->plug); iPCR.pointToPointConnections++; iPCR.channel = upstreamPath->channel; programInputPlug(sourceRoute->port, sink.phyID, endpoint->plug, iPCR); } else if (sinkAdjacent) { if ((endpoint = findEndpointDescriptor(downstreamPath, pathRequestMsg->sinkEUI64)) != NULL) { endpoint->lifetime += pathRequestMsg->lifetime; /* Extend lifetime of existing stream branch */



return(OK); } if ((endpoint = findEndpointDescriptor(downstreamPath, pathRequestMsg->sourceEUI64)) == NULL) legacyCMP = FALSE; else legacyCMP = (endpoint->surrogateEUI64 == 0) ? FALSE : pathRequestMsg->legacyCMP; if (downstreamPath->channel == UNASSIGNED) { if (allocateResources(downstreamPath, stream->maxPayload, sinkSpeed)) { endpoint = allocateEndpointDescriptor(downstreamPath); endpoint->eui64 = sinkRoute->port->ownEUI64; endpoint->plug = assignOutputPlug(sinkRoute->port); endpoint->sink == FALSE; endpoint->legacyCMP == legacyCMP; oPCR = readOutputPlug(sinkRoute->port, sinkRoute->port->ownPhyID, endpoint->plug); oPCR.channel = downstreamPath->channel; oPCR.spd = downstreamPath->speed; oPCR.pointToPointConnections++; programOutputPlug(sinkRoute->port, sinkRoute->port->ownPhyID, endpoint->plug, oPCR); } else return(RESOURCES_UNAVAILABLE); } else if (downstreamPath->speed > sinkSpeed || pathRequestMsg->maxPayload > stream->maxPayload) return(STREAM_CONFLICT); else if (!legacyCMP) { endpoint = findEndpointDescriptor(downstreamPath, sinkRoute->port->ownEUI64); oPCR = readOutputPlug(sourceRoute->port, sinkRoute->port->ownPhyID, endpoint->plug); oPCR.pointToPointConnections++; programOutputPlug(sinkRoute->port, sinkRoute->port->ownPhyID, endpoint->plug, oPCR); } downstreamPath->localSinks++; /* Set up new stream branch */ endpoint = allocateEndpointDescriptor(downstreamPath); endpoint->eui64 = pathRequestMsg->sinkEUI64; endpoint->address = pathRequestMsg->sinkAddress; endpoint->lifetime = pathRequestMsg->lifetime; endpoint->plug = pathRequestMsg->sinkPlug; endpoint->sink == TRUE; endpoint->legacyCMP == legacyCMP; if (!endpoint->legacyCMP) { /* Bridge manages isochronous resources? */ iPCR = readInputPlug(sinkRoute->port, sink.phyID, endpoint->plug); iPCR.pointToPointConnections++; iPCR.channel = downstreamPath->channel; programInputPlug(sinkRoute->port, sink.phyID, endpoint->plug, iPCR); } if (upstreamPath->streamIndex == UNASSIGNED) { /* Grafting onto existing branch? */ txLDPDatagram(sourceRoute->port, sourceRoute->gatewayAddress, pathRequestMsg); /* Send upstream */ return(PENDING); } } else if (sourceAdjacent) { downstreamPath->port = sinkRoute->port; /* In case this is first use ... */ if ((endpoint = findEndpointDescriptor(downstreamPath, pathRequestMsg->sinkEUI64)) == NULL) legacyCMP = FALSE; else legacyCMP = (endpoint->surrogateEUI64 == 0) ? FALSE : endpoint->legacyCMP; if (downstreamPath->streamIndex == UNASSIGNED) { if (createStream(downstreamPath, &stream->streamParms)) { oPCR = readOutputPlug(sourceRoute->port, source.phyID, pathRequestMsg->sourcePlug); if (upstreamPath->channel == UNASSIGNED) { if (oPCR.broadcastConnection || oPCR.pointToPointConnections > 0) { upstreamPath->speed = oPCR.spd; upstreamPath->channel = oPCR.channel; } else if (allocateResources(upstreamPath, stream->maxPayload, sourceSpeed)) { oPCR.spd = sourceSpeed; oPCR.channel = upstreamPath->channel; } else return(RESOURCES_UNAVAILABLE); } else if (upstreamPath->speed > sourceSpeed || pathRequestMsg->maxPayload > stream->maxPayload) return(STREAM_CONFLICT); if ((endpoint = findEndpointDescriptor(upstreamPath, pathRequestMsg->sourceEUI64)) == NULL) { endpoint = allocateEndpointDescriptor(upstreamPath); endpoint->eui64 = pathRequestMsg->sourceEUI64; endpoint->address = pathRequestMsg->sourceAddress; endpoint->plug = pathRequestMsg->sourcePlug; endpoint->sink = FALSE; endpoint->legacyCMP == legacyCMP; } if (!legacyCMP) { oPCR.pointToPointConnections++;



programOutputPlug(sourceRoute->port, source.phyID, endpoint->plug, oPCR); } upstreamPath->localSinks++; /* Set up new stream branch */ endpoint = allocateEndpointDescriptor(upstreamPath); endpoint->eui64 = sourceRoute->port->ownEUI64; endpoint->plug = assignInputPlug(sourceRoute->port); endpoint->sink = TRUE; iPCR = readInputPlug(sourceRoute->port, sourceRoute->port->ownPhyID, endpoint->plug); iPCR.pointToPointConnections++; iPCR.channel = upstreamPath->channel; programInputPlug(sourceRoute->port, sourceRoute->port->ownPhyID, endpoint->plug, iPCR); } else return(RESOURCES_UNAVAILABLE); } else if (!streamOverlayOK(downstreamPath, &pathRequestMsg->streamParms)) return(STREAM_CONFLICT); if ((gateway = findGatewayDescriptor(downstreamPath, sinkRoute->gatewayAddress)) == NULL) { gateway = allocateGatewayDescriptor(downstreamPath); *gateway = sinkRoute->gatewayAddress; } memset(&pathMappingMsg, 0, sizeof(pathMappingMsg)); /* Inform intermediate downstream sink */ pathMappingMsg.messageType = PATH_MAPPING; pathMappingMsg.messageLength = 68; pathMappingMsg.messageID = messageID++; pathMappingMsg.companyID = 0xA02D; pathMappingMsg.version = 0; pathMappingMsg.pathTLV.type = PATH_TLV; pathMappingMsg.pathTLV.length = 56; pathMappingMsg.controllerAddress = pathRequestMsg->controllerAddress; pathMappingMsg.sinkAddress = pathRequestMsg->sinkAddress; pathMappingMsg.sourceAddress = pathRequestMsg->sourceAddress; pathMappingMsg.sinkEUI64 = pathRequestMsg->sinkEUI64; pathMappingMsg.sourceEUI64 = pathRequestMsg->sourceEUI64; pathMappingMsg.sourcePlug = pathRequestMsg->sourcePlug; pathMappingMsg.sinkPlug = pathRequestMsg->sinkPlug; pathMappingMsg.legacyCMP = pathRequestMsg->legacyCMP; pathMappingMsg.streamParms = stream->streamParms; pathMappingMsg.linkStreamID = downstreamPath->linkStreamID; pathMappingMsg.latency = upstreamPath->latency + downstreamPath->latency; txLDPDatagram(downstreamPath->port, sinkRoute->gatewayAddress, &pathMappingMsg); return(PENDING); } }

7.2.3 PATH MAPPING message processing

The function of a PATH MAPPING message is to communicate a Stream Index to an L3 IP bridge ingress port. The

functional behavior of a bridge port that intercepts a PATH MAPPING message is expressed in detail by Table 5.

Table 5 – L3 IP bridge actions on receipt of a PATH MAPPING message

#include "csr.h" #include "global.h" #include "packets.h" QUADLET pathMapping(PATH_MSG *pathMappingMsg, ROUTE_INFO *sinkRoute, ROUTE_INFO *sourceRoute) { PATH_INFO *downstreamPath, *upstreamPath; ENDPOINT_INFO *endpoint; BOOLEAN legacyCMP, sinkAdjacent, sourceAdjacent; NODE_ID sink; STREAM_INFO *stream; if (sinkRoute == NULL || sourceRoute == NULL) /* Are both sink and source routable? */ return(INVALID_ROUTE); sinkAdjacent = (sinkRoute->gatewayAddress == 0); sourceAdjacent = (sourceRoute->gatewayAddress == 0); if ( (sinkAdjacent && sinkRoute->port->portType != IEEE_1394) /* Do the upstream and downstream ports ... */ || (!sinkAdjacent && sinkRoute->port->portType != CABLE) /* ... have the expected media types? */ || (sourceAdjacent && sourceRoute->port->portType != IEEE_1394) || (!sourceAdjacent && sourceRoute->port->portType != CABLE)) return(UNEXPECTED_ERROR);



if ((stream = findStreamDescriptor(pathMappingMsg->streamID)) == NULL) return(UNEXPECTED_ERROR); upstreamPath = &stream->upstreamPath; downstreamPath = &stream->downstreamPath; upstreamPath->localSinks++; /* Count ourself (a coaxial cable bridge port) as a sink */ upstreamPath->streamIndex = pathMappingMsg->linkStreamID; /* Receive stream data on this Stream Index */ upstreamPath->gatewayAddress[0] = sourceRoute->gatewayAddress; pathMappingMsg->latency += 2; /* Message carries accumulated latency */ endpoint = findEndpointDescriptor(downstreamPath, pathMappingMsg->sourceEUI64); legacyCMP = (endpoint == NULL) ? FALSE : legacyCMP; /* Legacy CMP applicable if surrogate present */ if ((endpoint = findEndpointDescriptor(downstreamPath, pathMappingMsg->sinkEUI64)) != NULL) return(OK); /* Sink iPCR already programmed */ if ((endpoint = allocateEndpointDescriptor(downstreamPath)) == NULL) return(UNEXPECTED_ERROR); endpoint->eui64 = pathMappingMsg->sinkEUI64; /* Initialize endpoint particulars */ endpoint->address = pathMappingMsg->sinkAddress; endpoint->lifetime = pathMappingMsg->lifetime; endpoint->plug = pathMappingMsg->sinkPlug; endpoint->sink = TRUE; endpoint->legacyCMP = legacyCMP; sink.nodeID = nodeID(endpoint->eui64); iPCR = readInputPlug(sinkRoute->port, sink.phyID, endpoint->plug); if (iPCR.broadcastConnection == 0 && iPCR.pointToPointConnections == 0) iPCR.channel = downstreamPath->channel; else if (iPCR.channel != downstreamPath->channel) return(STREAM_CONFLICT); if (!pathMappingMsg->legacyCMP) { /* If a legacy controller is present, let it program the iPCR */ iPCR.pointToPointConnections++; programInputPlug(sinkRoute->port, sink.phyID, endpoint->plug, iPCR); } return(OK); }

7.2.4 PATH TEARDOWN message processing

Under most circumstances, a controller originates an upstream PATH TEARDOWN message to terminate a path

between an endpoint sink and an endpoint source; this operation is graceful and leaves overlaid connections between

the source and other endpoint sinks intact. Rarely, an endpoint source may transmit a downstream PATH

TEARDOWN message—but this is rather clumsy, because path connections to all endpoint sinks are severed. Lastly,

an L3 IP bridge that discovers the disconnection of one or more devices on a stream's path shall transmit downstream

or upstream PATH TEARDOWN messages, as appropriate, to release resources associated with the now defunct

stream paths.

Independent of the circumstances of its transmission, the function of a PATH TEARDOWN message is the

deallocation of path resources (channel and bandwidth for IEEE 1394 segments or streams for coaxial cable

segments) and the release of any internal resources used by the bridge. The processing of a PATH TEARDOWN

message by a bridge port depends upon whether its direction is upstream (towards the stream's endpoint source) or

downstream (towards all of the stream's endpoint sinks).

An upstream PATH TEARDOWN message received by an egress port indicates that no downstream sinks—either

endpoint sinks or ingress ports—remain on the path through the former ingress port that transmitted the message.

There is no longer any reason to transmit the stream to that particular ingress port. Path resources for the connection

to the local sink device shall be released, along with associated bridge resources. The downstream sink device shall

be removed from the egress port's list of active local sinks. If no local sink devices remain, the bridge shall forward

the PATH TEARDOWN message to the next-hop egress port for the stream. This process may continue, repetitively,

until the PATH TEARDOWN message reaches an L3 IP bridge immediately adjacent to the endpoint source. If no

downstream sinks remain on any downstream egress ports and no local sinks remain within the source's IEEE 1394

cluster, the bridge shall program the source's oPCR to reflect a disconnected state and shall return previously

allocated isochronous resources, channel and bandwidth.

A downstream PATH TEARDOWN message received by a stream's ingress port instructs it to tear down all

downstream paths to all downstream sinks and release all associated path and bridge resources. The message directs



the bridge to reprogram its egress port's oPCR and the endpoint sinks' iPCRs to reflect a disconnected state and to

transmit a notification message with the appropriate status code to the controller associated with each endpoint sink.

The functional behavior of an L3 IP bridge port that receives a PATH TEARDOWN message is expressed in detail

by Table 6.

Table 6 – L3 IP bridge actions on receipt of a PATH TEARDOWN message

#include "csr.h" #include "global.h" #include "packets.h" QUADLET pathTeardown(PATH_MSG *pathTeardownMsg, ROUTE_INFO *sinkRoute, ROUTE_INFO *sourceRoute) { PATH_INFO *downstreamPath, *upstreamPath; ENDPOINT_INFO *endpoint,*ownEndpoint; BOOLEAN endpointsSameCluster, sinkAdjacent, sourceAdjacent; INT i; NODE_ID sink, source; STREAM_INFO *stream; if (sinkRoute == NULL || sourceRoute == NULL) /* Are both sink and source routable? */ return(INVALID_ROUTE); sinkAdjacent = (sinkRoute->gatewayAddress == 0); sourceAdjacent = (sourceRoute->gatewayAddress == 0); if (sinkAdjacent && sourceAdjacent) endpointsSameCluster = (sinkRoute->port == sourceRoute->port); /* Sink and source in same cluster? */ if ( (sinkAdjacent && sinkRoute->port->portType != IEEE_1394) /* Upstream and downstream ports ... */ || (!sinkAdjacent && sinkRoute->port->portType != CABLE) /* ... have the expected media types? */ || (sourceAdjacent && sourceRoute->port->portType != IEEE_1394) || (!sourceAdjacent && sourceRoute->port->portType != CABLE)) return(UNEXPECTED_ERROR); stream = findStreamDescriptor(pathTeardownMsg->streamID); /* Locate pertinent stream descriptor */ return(UNEXPECTED_ERROR); upstreamPath = &stream->upstreamPath; downstreamPath = &stream->downstreamPath; if (pathTeardownMsg->upstream) { if (endpointsSameCluster) { if ((endpoint = findEndpointDescriptor(upstreamPath, pathTeardownMsg->sinkEUI64)) != NULL) { sink.nodeID = nodeID(endpoint->eui64); iPCR = readInputPlug(sinkRoute->port, sink.phyID, endpoint->plug); if (iPCR.pointToPointConnections > 0) { iPCR.pointToPointConnections--; programInputPlug(sinkRoute->port, sink.phyID, endpoint->plug, iPCR); } deallocateEndpointDescriptor(endpoint); if (upstreamPath->localSinks > 0) upstreamPath->localSinks--; } if (upstreamPath->localSinks == 0) { if ((endpoint = findEndpointDescriptor(upstreamPath, pathTeardownMsg->sourceEUI64)) != NULL) { source.nodeID = nodeID(endpoint->eui64); oPCR = readOutputPlug(sourceRoute->port, source.phyID, endpoint->plug); if (oPCR.pointToPointConnections > 0) { oPCR.pointToPointConnections--; programOutputPlug(sourceRoute->port, source.phyID, endpoint->plug, oPCR); } if (oPCR.pointToPointConnections == 0) deallocateResources(upstreamPath); } deallocateStreamDescriptor(stream); } } else if (sinkAdjacent) { if ((endpoint = findEndpointDescriptor(downstreamPath, pathTeardownMsg->sinkEUI64)) != NULL) { if (!endpoint->legacyCMP) { /* Leave PCRs alone if legacy controller lurks nearby */ sink.nodeID = nodeID(endpoint->eui64); iPCR = readInputPlug(sinkRoute->port, sink.phyID, endpoint->plug); if (iPCR.pointToPointConnections > 0) { iPCR.pointToPointConnections--; programInputPlug(sinkRoute->port, sink.phyID, endpoint->plug, iPCR); } } deallocateEndpointDescriptor(endpoint);



if (downstreamPath->localSinks > 0) downstreamPath->localSinks--; } if ((endpoint = findEndpointDescriptor(downstreamPath, pathTeardownMsg->sourceEUI64)) != NULL) if (endpoint->surrogateEUI64 != 0) /* Deallocate target surrogate endpoint, if present */ deallocateEndpointDescriptor(endpoint); if (downstreamPath->localSinks == 0) { deallocateResources(downstreamPath); txLDPDatagram(sourceRoute->port, sourceRoute->gatewayAddress, pathTeardownMsg); deallocateStreamDescriptor(stream); return(PENDING); } } else if (sourceAdjacent) { for (i = 0; i <= LAST(downstreamPath->gatewayAddress); i++) if (downstreamPath->gatewayAddress[i] == sinkRoute->gatewayAddress) { downstreamPath->gatewayAddress[i] = 0; if (downstreamPath->localSinks > 0) downstreamPath->localSinks--; } if (downstreamPath->localSinks == 0) { memset(downstreamPath, 0, sizeof(downstreamPath)); downstreamPath->streamIndex = UNASSIGNED; if ((endpoint = findEndpointDescriptor(upstreamPath, sourceRoute->port->ownEUI64)) != NULL) { iPCR = readInputPlug(sourceRoute->port, sourceRoute->port->ownPhyID, endpoint->plug); if (iPCR.pointToPointConnections > 0) { iPCR.pointToPointConnections--; programInputPlug(sourceRoute->port, sourceRoute->port->ownPhyID, endpoint->plug, iPCR); } deallocateEndpointDescriptor(endpoint); if (upstreamPath->localSinks > 0) upstreamPath->localSinks--; } if (upstreamPath->localSinks == 0) { if ((endpoint = findEndpointDescriptor(upstreamPath, pathTeardownMsg->sourceEUI64)) != NULL) { if (!endpoint->legacyCMP) { source.nodeID = nodeID(endpoint->eui64); oPCR = readOutputPlug(sourceRoute->port, source.phyID, endpoint->plug); if (oPCR.pointToPointConnections > 0) { oPCR.pointToPointConnections--; programOutputPlug(sourceRoute->port, source.phyID, endpoint->plug, oPCR); if (oPCR.pointToPointConnections == 0) deallocateResources(upstreamPath); } } } deallocateStreamDescriptor(stream); } } } } else { /* Downstream PATH TEARDOWN message */ if ((ownEndpoint = findEndpointDescriptor(downstreamPath, sinkRoute->port->ownEUI64)) != NULL) oPCR = readOutputPlug(sinkRoute->port, sinkRoute->port->ownPhyID, endpoint->plug); for (i = 0; i <= LAST(downstreamPath->endpoint); i++) { if ((endpoint = &downstreamPath->endpoint[i]) == ownEndpoint) continue; if (!endpoint->legacyCMP) { sink.nodeID = nodeID(endpoint->eui64); iPCR = readInputPlug(sinkRoute->port, sink.phyID, endpoint->plug); if (iPCR.pointToPointConnections > 0) { iPCR.pointToPointConnections--; programInputPlug(sinkRoute->port, sink.phyID, endpoint->plug, iPCR); } } if (oPCR.pointToPointConnections > 0) oPCR.pointToPointConnections--; } if (ownEndpoint != NULL) { /* Do we know our own oPCR? */ programOutputPlug(sourceRoute->port, sourceRoute->port->ownPhyID, endpoint->plug, oPCR); if (oPCR.pointToPointConnections == 0) /* Caution! Any purely local connections? */ deallocateResources(downstreamPath); } deallocateStreamDescriptor(stream); } }



7.2.5 Autonomous path teardown

Most of the time, isochronous path teardown is an orderly process initiated by an endpoint sink device when it

transmits an upstream PATH TEARDOWN message to the endpoint source device. However, other circumstances

require L3 IP bridges to tear down all or part of a path, as enumerated below.

– the path lifetime (for a particular sink) expires;

– the path from a coaxial cable egress port to a coaxial cable ingress port breaks because one or both become

disassociated or fail to maintain their mutual LDP session;

– the connection between a source and an ingress port breaks; or

– the connection between an egress port and an endpoint sink breaks.

An IEEE 1394 egress port monitors path lifetimes for endpoint sinks in its local cluster. When a path’s lifetime

decrements to zero, the egress port shall create a PATH TEARDOWN message formatted as if originated by the

controller that requested the path and process it as if it had been received from the sink (see 7.2.4).

All of the other events that trigger autonomous path teardown involve the unexpected disconnection or disassociation

of one or more devices from the local cluster or piconet. The actions taken by the port that detects the loss of

connectivity are determined by its role with respect to the stream, egress or ingress.

7.2.5.1 Disconnection of an IEEE 1394 node

Subsequent to a bus reset, an IEEE 1394 port shall determine the EUI-64s of nodes that have been disconnected; and

shall remove corresponding entries from its database of endpoint sinks or sources. For any stream for which no

endpoint sinks remain connected, the port shall transmit an upstream PATH TEARDOWN message to the endpoint

source. In similar fashion, for each disconnected source, the port shall transmit a downstream PATH TEARDOWN

message to all endpoint sinks associated with the source.

Table 7 specifies the functional behavior of an IEEE 1394 L3 IP bridge port upon notification that a local node is no

longer connected.

Table 7 – L3 IP bridge actions upon disconnection of a local IEEE 1394 node

#include "csr.h" #include "global.h" #include "packets.h" VOID nodeUnplugged(PORT_INFO *eventPort, OCTLET unpluggedEUI64) { PATH_INFO *downstreamPath, *upstreamPath; ENDPOINT_INFO *endpoint, *sourceEndpoint; INT i; STREAM_INFO *stream; for (i = 0; i < MAX_STREAMS; i++) { /* Search all active streams */ if ((stream = &streamDescr[i])->sourceEUI64 == 0) continue; /* Skip inactive stream descriptors */ upstreamPath = &stream->upstreamPath; downstreamPath = &stream->downstreamPath; if (upstreamPath->port == eventPort) { /* Node disconnected from upstream path? */ if ((endpoint = findEndpointDescriptor(upstreamPath, unpluggedEUI64)) == NULL) continue; if (endpoint->surrogateEUI64 != 0) { /* Relay agent acting as a sink surrogate? */ if ((sourceEndpoint = findEndpointDescriptor(upstreamPath, stream->sourceEUI64)) == NULL); continue; multicastTeardownMsg(stream->streamID, sourceEndpoint, endpoint); deallocateEndpointDescriptor(endpoint); /* Delete relay agent from the database */ } else if (!endpoint->sink) { /* Was the source disconnected? */ for (i = 0; i <= LAST(downstreamPath->gatewayAddress); i++) if (downstreamPath->gatewayAddress[i] != 0) txTeardownMsg(stream->streamID, downstreamPath->gatewayAddress[i], DOWNSTREAM);



deallocateStreamDescriptor(stream); } else { deallocateEndpointDescriptor(endpoint); /* Delete sink from the database */ if (upstreamPath->localSinks > 0) upstreamPath->localSinks--; if (upstreamPath->localSinks == 0) deallocateStreamDescriptor(stream); } } else if (downstreamPath->port == eventPort) { /* Node disconnected from downstream path? */ if ((endpoint = findEndpointDescriptor(downstreamPath, unpluggedEUI64)) == NULL) continue; deallocateEndpointDescriptor(endpoint); /* Delete sink from the database */ if (downstreamPath->localSinks > 0) downstreamPath->localSinks--; if (downstreamPath->localSinks == 0) { txTeardownMsg(stream->streamID, upstreamPath->gatewayAddress[0], UPSTREAM); deallocateStreamDescriptor(stream); } } } } VOID multicastTeardownMsg(FEC streamID, ENDPOINT_INFO *sourceEndpoint, ENDPOINT_INFO *sinkEndpoint) { ROUTE_INFO *sinkRoute; PATH_MSG teardownMsg; if ((sinkRoute = getRoute(sinkEndpoint->address)) == NULL) return; memset(&teardownMsg, 0, sizeof(teardownMsg)); teardownMsg.messageType = PATH_TEARDOWN; teardownMsg.messageLength = 68; teardownMsg.messageID = messageID++; teardownMsg.companyID = 0xA02D; teardownMsg.version = 0; teardownMsg.pathTLV.type = PATH_TLV; teardownMsg.pathTLV.length = 56; teardownMsg.streamID = streamID; teardownMsg.sinkAddress = sinkEndpoint->address; teardownMsg.sourceAddress = sourceEndpoint->address; teardownMsg.sinkPlug = sinkEndpoint->plug; teardownMsg.sourcePlug = sourceEndpoint->plug; teardownMsg.upstream = TRUE; txLDPDatagram(sinkRoute->port, ALL_SUBNET_ROUTERS, &teardownMsg); } VOID txTeardownMsg(FEC streamID, QUADLET gatewayAddress, BOOLEAN upstream) { ROUTE_INFO *gatewayRoute; PATH_MSG teardownMsg; if ((gatewayRoute = getRoute(gatewayAddress)) == NULL) return; memset(&teardownMsg, 0, sizeof(teardownMsg)); teardownMsg.messageType = PATH_TEARDOWN; teardownMsg.messageLength = 68; teardownMsg.messageID = messageID++; teardownMsg.companyID = 0xA02D; teardownMsg.version = 0; teardownMsg.pathTLV.type = PATH_TLV; teardownMsg.pathTLV.length = 56; teardownMsg.streamID = streamID; teardownMsg.upstream = upstream; txLDPDatagram(gatewayRoute->port, gatewayAddress, &teardownMsg); }

7.2.5.2 Disassociation of a coaxial cable DEV

L3 IP bridge coaxial cable ports shall monitor the device Association information periodically broadcast by the PNC

in order to detect the disassociation of a peer L3 IP bridge port. Coaxial cable port shall also monitor HELLO

adjacencies established with peer L3 IP bridge ports. When communications are lost with another coaxial cable



bridge port, either due to disassociation or to loss of HELLO adjacency, a coaxial cable port shall remove all

corresponding entries from its database of gateway sinks or resources. For any stream for which no gateway sinks

remain, the port shall, if possible, terminate the stream and instruct its co-port to remove its connection to the

stream's source. In similar fashion, for each stream disconnected from its gateway source, the port shall instruct its

co-port to teardown all downstream connections to endpoint sinks associated with the stream.

Table 8 specifies the functional behavior of a coaxial cable L3 IP bridge port upon discovery that a peer coaxial

cable port has disassociated from the piconet or has failed to maintain a HELLO adjacency.

Table 8 – L3 IP bridge actions upon disassociation of a peer bridge

#include "csr.h" #include "global.h" #include "packets.h" VOID devDisassociated(PORT_INFO *eventPort, OCTLET disassociatedMAC64) { PATH_INFO *downstreamPath, *upstreamPath; ENDPOINT_INFO *endpoint, *ownEndpoint; QUADLET gatewayAddress, *gateway; INT i; NODE_ID sink, source; STREAM_INFO *stream; gatewayAddress = getGatewayAddress(disassociatedMAC64); for (i = 0; i < MAX_STREAMS; i++) { /* Search all active streams */ if ((stream = &streamDescr[i])->sourceEUI64 == 0) continue; /* Skip inactive stream descriptors */ upstreamPath = &stream->upstreamPath; downstreamPath = &stream->downstreamPath; if (upstreamPath->port == eventPort) { /* Lost contact with our source? */ if ((gateway = findGatewayDescriptor(upstreamPath, gatewayAddress)) == NULL) continue; if ((ownEndpoint = findEndpointDescriptor(downstreamPath, downstreamPath->port->ownEUI64)) != NULL) oPCR = readOutputPlug(downstreamPath->port, downstreamPath->port->ownPhyID, endpoint->plug); for (i = 0; i <= LAST(downstreamPath->endpoint); i++) { if ((endpoint = &downstreamPath->endpoint[i]) == ownEndpoint) continue; if (endpoint->legacyCMP) /* PCRs managed by legacy controller? */ continue; sink.nodeID = nodeID(endpoint->eui64); iPCR = readInputPlug(downstreamPath->port, sink.phyID, endpoint->plug); if (iPCR.pointToPointConnections > 0) { iPCR.pointToPointConnections--; programInputPlug(downstreamPath->port, sink.phyID, endpoint->plug, iPCR); } if (oPCR.pointToPointConnections > 0) oPCR.pointToPointConnections--; } if (ownEndpoint != NULL) { /* Did we read our own oPCR? */ programOutputPlug(upstreamPath->port, upstreamPath->port->ownPhyID, endpoint->plug, oPCR); if (oPCR.pointToPointConnections == 0) /* Any local lurking listeners? */ deallocateResources(downstreamPath); } deallocateStreamDescriptor(stream); } else if (downstreamPath->port == eventPort) { /* Lost contact with cable sink(s)? */ if ((gateway = findGatewayDescriptor(downstreamPath, gatewayAddress)) == NULL) continue; if (downstreamPath->localSinks > 0) downstreamPath->localSinks--; deallocateGatewayDescriptor(downstreamPath, gateway); } if (downstreamPath->localSinks == 0) { terminateStream(downstreamPath); deallocatePathDescriptor(downstreamPath); if ((endpoint = findEndpointDescriptor(upstreamPath, upstreamPath->port->ownEUI64)) != NULL) { iPCR = readInputPlug(upstreamPath->port, upstreamPath->port->ownPhyID, endpoint->plug); if (iPCR.pointToPointConnections > 0) { iPCR.pointToPointConnections--; programInputPlug(upstreamPath->port, upstreamPath->port->ownPhyID, endpoint->plug, iPCR); } if (upstreamPath->localSinks > 0) upstreamPath->localSinks--;



} if (upstreamPath->localSinks == 0) { if ((endpoint = findEndpointDescriptor(upstreamPath, stream->sourceEUI64)) != NULL) { source.nodeID = nodeID(endpoint->eui64); oPCR = readOutputPlug(upstreamPath->port, source.phyID, endpoint->plug); if (oPCR.pointToPointConnections > 0) { oPCR.pointToPointConnections--; programOutputPlug(upstreamPath->port, source.phyID, endpoint->plug, oPCR); } if (oPCR.pointToPointConnections == 0) deallocateResources(upstreamPath); } deallocateStreamDescriptor(stream); } } } }

7.3 Isochronous operations

7.3.1 Ingress port isochronous operations

Ingress ports shall be configured to receive stream packets for all active labels, as established by the receipt of PATH

MAPPING messages. Isochronous data experiences a delay (latency) between its receipt by the ingress port and its

eventual reception by an endpoint or intermediate sink connected to the egress port's medium. Although latency may

vary from one stream to another and is dependent upon the direction of data flow, it shall remain fixed for the

duration of a stream's lifetime. When a sink device is connected to a medium, e.g., coaxial cable, with an inherently

higher error rate than IEEE 1394, time allocated for retransmission both increases the latency and makes the exact

arrival time of a particular SDU impossible to predict. In order to provide behavior equivalent to IEEE 1394, the

stream SDUs shall be time stamped with a ―presentation time‖. Presentation time is calculated by adding the next-

hop latency (expressed as a count of 125 µs isochronous intervals) to the cycle number during which the ingress port

received the stream SDU. The presentation time cycle number shall be expressed in terms of the destination cycle

time domain, which may differ from the ingress port's cycle time domain.

NOTE – Cycle time domain boundaries exist between all ports, IEEE 1394 and coaxial cable, within all L3 IP bridges

except the bridge that contains the prime port. There is no cycle time domain boundary between the prime port and the

bridge's alpha coaxial cable port(s).

Under nominal conditions, SDUs arrive at an intermediate sink (ingress port) in advance of their presentation time,

in which case the SDUs may be queued for transmission by the egress port so long as the presentation time is

adjusted by the intra-bridge latency. Received SDUs whose presentation time is less than the current cycle number

are expired and shall be discarded. If there is a cycle time domain boundary between the ingress and egress ports and

the data payload conforms to the CIP format, then its embedded timestamps shall be transformed in accordance with

7.3.4 before being queued for transmission by the egress port.

NOTE – Latency across an L3 IP bridge is strongly influenced by the direction of the isochronous data flow. When data is

transferred from an IEEE 1394 ingress port, through a coaxial cable egress port and to another L3 IP bridge's coaxial cable

ingress port, source to sink latency could approach 50 ms. In the opposite direction, from a coaxial cable ingress port,

through an IEEE 1394 egress port and to an endpoint sink, latency is dramatically shorter. Once the coaxial cable ingress

port has accurately received isochronous data, the remaining delays within the L3 IP bridge and over IEEE 1394 are both

deterministic and brief; latency in this direction could be as little as 250 µs.

An L3 IP bridge ingress port shall route isochronous data SDUs according to their labels. For IEEE 1394, the label is

the IEEE 1394 channel number located in the packet header; for coaxial cable, the label is the IEEE 802.15.3 Stream

Index located in the stream SDU header. The label, together with the identity of the ingress port, determines the

stream SDU's forwarding equivalence class (FEC), which determines the egress port or ports and identifies the label

to be employed for the next-hop transmission.



7.3.2 Egress port isochronous operations

L3 IP bridges shall maintain queues of isochronous packets whose labels (channel number or Stream Index, as

appropriate) match established paths. The packets shall be scheduled for transmission by the egress port to satisfy

next-hop fixed latency determined at the time the path was created. In the case of an IEEE 1394 egress port, each

isochronous stream packet shall be transmitted during a particular isochronous interval whose cycle number matches

the presentation time cycle number calculated by the ingress port.

Similar requirements hold for coaxial cable egress ports, however, the ingress port shall have calculated a

presentation time far enough into the future that there is adequate time for retransmissions necessitated by receive

errors encountered by the next-hop ingress port. In order to maximize time available for retransmission, a coaxial

cable egress port should transmit all queued stream SDUs as soon as possible.

Before a stream SDU may be retransmitted, the egress port shall relabel the data with the appropriate label, channel

number or Stream Index. The labels are obtained from the path information in the bridge's label information base

(LIB), which has been updated by PATH MAPPING messages during path establishment. For IEEE 1394 egress

ports, the path information also includes the speed at which the isochronous stream packet shall be transmitted. If the

packet's data payload exceeds the maximum data payload specified by the most recent PATH REQUEST message,

the stream packet shall be discarded. If the packet's data payload conforms to the CIP format, then its embedded

timestamps shall be transformed in accordance with 7.3.4 before transmission.

7.3.3 Stream SDU aggregation and disaggregation

Preceding clauses 7.3.1 and 7.3.2 discuss the transformation and routing of individual 1394 stream SDUs as they

traverse the network from the source device to the sink device. However, because of the relatively large inter-frame

spacing of the coaxial cable PHY, it is not feasible to transmit an MSDU whose payload consists of a solitary IEEE

1394 stream SDU (see 5.5). For the sake of conservative and efficient use of a shared resource—coaxial cable

bandwidth—coaxial cable egress ports should aggregate multiple stream SDUs into a single MSDU for transmission.

Multiple MSDUs may be further aggregated into a single PSDU. Coaxial cable ingress ports, upon receipt of a

PSDU, disaggregate its component MSDUs and their component stream SDUs before forwarding the SDUs to the

co-port. The structure of a PSDU that contains multiple IEEE 1394 stream SDUs is illustrated by Figure 35.

Octets: 4 Ln 4 varies Ln 4 4 10

FCS Payload Stream SDU Header … Payload Stream SDU Header MSDU Header MAC Header

PSDU

NON-SECURE MAC FRAME BODY MAC HDR

FCS MSDU

IEEE 1394 STREAM SDU … IEEE 1394 STREAM SDU MSDU HDR

Figure 35 – MSDU with aggregated IEEE 1394 stream SDUs

Each stream SDU consists of its header followed by the payload—, which is an image of an IEEE, 1394 isochronous

packet. Because the isochronous packet header contains the length of the data that follows, the aggregated stream

SDUs are easily parsed. Note that an MSDU header (see 5.5) follows the MAC header. Although not illustrated,

additional MSDU headers could be present to delimit multiple MSDUs aggregated into the same PSDU. Secure data

transmission is permitted, although not shown in the example above.



7.3.4 Common Isochronous Packet (CIP) header transformations

Isochronous stream packets that conform to the Common Isochronous Packet (CIP) two-quadlet header format

specified by [R1] (see 5.8) require additional transformations of source physical ID and timestamp data contained

within the packet's data payload. The CIP transformations are explained below.

Isochronous packets with a two-quadlet CIP header contain a field, sid, which shall be set to the physical ID of the

AV/C relay agent that is part of the isochronous stream path or, if no relay agent is involved, the physical ID of the

egress port.

CIP timestamps, whether syt- or sph-based, are absolute values that specify a future cycle count. Since isochronous

stream packets experience a constant delay, latency, when they traverse an L3 IP bridge, it is both necessary and

sufficient to transform the timestamps by the addition of latency plus the difference in cycle times between the two

ports of the bridge. Isochronous latency was determined by the L3 IP bridge when the path was set up. The

difference in cycle count between the two sides of the bridge, delta, although measured by implementation-

dependent means, is specifically defined by the following formula (shown in C pseudocode notation):

delta = CYCLE_TIME.cycle_countEGRESS_PORT - CYCLE_TIME.cycle_countINGRESS_PORT;

When the syt field contains timestamp information, the transformation shall be performed by applying the following

formula:

sytTRANSMITTED = (sytOBSERVED + ((latency + delta) << 12)) & 0x0000FFFF;

Because IEEE 1394 constrains cycle_count to the range zero to 7999, inclusive, the transformation of the

cycle_count component of the source packet header differs. The addition of the constant isochronous delay to the

cycle_count shall be performed modulus 8000, as shown below:

cycle_countTRANSMITTED = (cycle_countOBSERVED + latency + delta) % 8000;

When the sph bit in the CIP header is one, there may be zero, one or multiple source packets (each with its own

header) within a single isochronous stream packet.

7.4 Cycle offset synchronization

IEEE 1394 isochronous timing (see [R6]) is based upon cycle time synchronization shared by all of a cluster's nodes.

Each node's cycle timer is independent of all the other nodes' cycle timers. Cycle time is driven by input from a

freely running 24.576 MHz oscillator, which increments cycle offset. An 8 kHz cycle count is derived from the

oscillator by means of cycle synchronization events that occur when cycle offset wraps from 3071 to zero. Because

cycle synchronization events mediate the transmission and reception of isochronous stream data, it is essential that

they remain aligned notwithstanding drift in the 24.576 MHz oscillators.

Within a local IEEE 1394 cluster, cycle time synchronization is accomplished by cycle start packets transmitted by

the cycle master every 125 µs. A cycle slave's cycle time is overwritten by the value contained in a cycle start packet.

This method achieves highly accurate cycle time synchronization; maximum clock slew between cycle master and

cycle slave is roughly 80 ns.14

The significant observation is that this is well under the 4 µs threshold for phase

differences perceptible to the human ear.

Within a network, cycle time synchronization is hierarchical: a singular, authoritative cycle offset source, the network

cycle master, shall provide synchronization information for all the other clusters' cycle masters, which in turn shall

14 The worst case occurs when cycle start transmission is delayed because the bus is busy; this potentially lengthens the interval

between successive cycle start packets to 175 µs. If the cycle master and cycle slave diverge from each other at the rate of

200 ppm, they could be misaligned by 35 ns. The cycle start packet itself can correct with accuracy no better than 40.69 ns. If

propagation delays are ignored, the two cycle timers' phase misalignment cannot exceed 75.69 ns.



synchronize all of the other nodes within their respective clusters. Because the network cycle master cannot transmit

cycle start packets to other clusters' cycle masters, L3 IP bridges shall maintain phase-lock synchronization between

the network cycle master and all other cycle masters. Phase lock exists when the CYCLE_TIME.cycle_offset value is

identical, within tolerances inherent to IEEE 1394, for adjacent cycle time domains. An L3 IP bridge synchronizes

the downstream cycle time domain to the upstream domain by first measuring cycle_offset difference between the

two domains. For IEEE 1394 domains, the measured difference shall be corrected to account for propagation delay

between the bridge port and the cycle master. When the difference is nonzero, the downstream port either adjusts its

own cycle time or transmits a cycle master adjustment packet to its cycle master. Because of cycle master adjustment

packet transmission delays, the instantaneous cycle_offset difference between adjacent cycle time domains can

exhibit variations that center on zero.

L3 IP bridge ports shall be capable of synchronizing their downstream cycle time domain to their upstream cycle

time domain (see 7.4.1 or 7.4.2, as appropriate). IEEE 1394 ports shall be adjustable cycle master-capable (see

7.4.1.2).

7.4.1 IEEE 1394 port

7.4.1.1 Alpha port regulation of the local cycle master

An alpha IEEE 1394 port shall adjust its cluster's cycle master in order to maintain phase-lock cycle offset

synchronization with the upstream cycle time domain. Whenever the measured difference in cycle_offset is nonzero,

the alpha port shall adjust its cycle master as specified below.

If the alpha port is not itself the cycle master and the downstream cycle master is not adjustable, the alpha port shall

transmit a PHY configuration packet to cause itself to be selected as root and shall initiate an arbitrated (short) bus

reset in an attempt to become cycle master. As described by [R10] for identical circumstances, this should be done

promptly and regardless of the recommendations of [R7] with respect to minimum intervals between successive bus

resets. An alpha port shall not attempt to transfer root and cycle master responsibilities to itself unless it is more

capable than the current root (see [R7]).

When an alpha port encounters a device that does not conform to [R7] in that it persistently attempts to maintain

itself as the cluster's cycle master even though it is less capable than the alpha port, the alpha port shall abandon its

own efforts to become cycle master until the recalcitrant device is disconnected. An alpha port that is neither cycle

master nor connected to a cluster whose cycle master is adjustable shall set the cycle_sync_error bit to one in any

path management message that passes through the bridge.

Once each isochronous interval, the alpha port shall add a previously calculated per interval drift correction (see

7.4.2.2) to the accumulated unapplied drift correction. Whenever the magnitude of the unapplied drift correction is

greater than or equal to 40.69 ns (one tick of the alpha port's 24.576 MHz cycle timer), the alpha port shall adjust the

downstream cycle master. The sign, positive or negative, of the unapplied drift correction determines the direction of

the adjustment. A positive drift correction indicates that the downstream cycle master is drifting behind the upstream

cycle master and must run faster; a negative drift correction indicates that the downstream cycle master is drifting

ahead of the upstream cycle master and must run slower. The magnitude of the unapplied drift correction shall be

decreased by 40.69 ns.

If the alpha port is also cycle master, it shall adjust its own threshold value in accordance with the sign of the

unapplied drift correction and shall not transmit a cycle master adjustment packet. Otherwise, if an adjustment is to

be applied, the alpha port shall transmit, within the current or the immediately subsequent isochronous interval, a

cycle master adjustment packet with the appropriate sy value. Alpha ports should not transmit cycle master

adjustment packets whose sy value is zero. The alpha port shall transmit the cycle master adjustment packet at the

fastest speed permitted by the capabilities of the alpha port, the downstream cycle master and the PHYs of any

intervening nodes. Only an alpha port may transmit cycle master adjustment packets.

The algorithm for the adjustment of the downstream cycle master is expressed in more detail in Table 9.



Table 9 – Alpha IEEE 1394 port actions to synchronize downstream cycle master

The procedure adjustDownstreamCycleMaster() executes on the bridge’s alpha port each time an

LK_CYCLE.indication is generated locally. This insures that an adjustment is made once and only once each 125 µs

isochronous interval. The input parameter to the procedure, driftCorrection, represents the time, in picoseconds,

by which the cycle master's current isochronous interval shall be shortened or lengthened. The value of

driftCorrection shall be between zero and 40,690 ps. Because the cycle master cannot be adjusted in increments

smaller than 40.69 ns, fractional drift corrections are accumulated into accumulatedCorrection. Once the

accumulated correction equals or exceeds 40.69 ns, a one-tick adjustment, fast or slow, shall be performed and

accumulatedCorrection shall be updated accordingly. When the alpha port is also the downstream cycle master,

an adjustment to the global variable cycleOffsetThreshold directly affects the next cycle synchronization event

at the alpha port (see Table 10). Otherwise, a cycle master adjustment packet is constructed and signaled to the alpha

port’s link for isochronous transmission to the downstream cycle master.

NOTE – The phase-offset differences are cumulative across a sequence of bridges. Theoretically, this might result in a

significant phase offset difference between the net cycle master and distant downstream cycle time domains. In practice,

random variation in cycle timer slew rates—some fast, some slow—tends to mitigate the problem. Furthermore, even in the

pathological case, in which the cycle timers are either all fast or all slow, more than 100 hops are required before the

cumulative phase offset difference approaches half an isochronous interval. Since the constraint of the 100 ms AV/C

command/response timeout limits the number of hops to the single digits, cumulative phase offset differences should never

be a problem.

7.4.1.2 Cycle master adjustment

An active, adjustable cycle master that observes a cycle master adjustment packet shall temporarily override the

threshold value at which CYCLE_TIME.cycle_offset wraps around to zero and causes CYCLE_TIME.cycle_count

to increment. The sy field in the packet shall indicate the override value, as specified by clause 5.3. If no cycle

master adjustment packet is observed by the cycle master during an isochronous period, CYCLE_TIME shall behave

as specified by IEEE 1394: an increment to CYCLE_TIME.cycle_offset from the value of 3071 shall cause it to wrap

around to zero and increment the cycle count.

An IEEE 1394 node can be both an L3 IP bridge port and cycle master; these roles are orthogonal to each other.

Cycle master adjustment packets received in such a node's cycle master role shall be processed as described in this

clause but shall not be forwarded by the bridge port to its co-port.

Cycle master implementations that recognize and act upon cycle master adjustment packets shall be designed to

insure that cycle synchronization events are not lost because of a temporary override of the threshold value.

#include "csr.h" #include "math.h" #include "global.h" VOID adjustDownstreamCycleMaster(INT driftCorrection) { STATIC INT accumulatedCorrection = 0; /* Pending correction (picoseconds) to apply downstream */ INT adjustment; accumulatedCorrection += driftCorrection; /* Increase magnitude of pending correction */ if (abs(accumulatedCorrection) >= CYCLE_TICK) { /* Enough credit to make a one-tick correction? */ adjustment = (accumulatedCorrection > 0) ? -1 : 1; accumulatedCorrection = adjustment * (abs(accumulatedCorrection) - CYCLE_TICK); if (stateSet.cmstr) /* Are we the cycle master? */ cycleOffsetThreshold = 3071 + adjustment; /* Yes, alter our own threshold */ else /* No, transmit adjustment packet to cycle master */ LK_ISO.request(3, DEFAULT_BROADCAST_CHANNEL, /* Send the adjustment packet isochronously */ 2 - adjustment, 0, NULL, S100); } }



The temporary override value for the threshold remains in effect until the next cycle synchronization event, as

specified by Table 10. For nodes that implement cycle master adjustment capability, Table 10 supersedes the

corresponding pseudocode in [R6].

Table 10 – Cycle time update actions for adjustable cycle masters

#include "csr.h" BOOLEAN cycleSynchQueued; /* Need cycle start if we're cycle master */ VOID updateCycleTime() { /* Executed 24,576,000 times per second */ if (cycleTime.cycleOffset >= cycleOffsetThreshold) { cycleTime.cycleOffset = 0; /* Wrap cycle offset back to zero */ cycleOffsetThreshold = 3071; /* Restore threshold to nominal value */ if (cycleTime.cycleCount == 7999) { cycleTime.cycleCount = 0; /* Wrap cycle count back to zero */ busTime.secondsCount++; /* Count another second */ cycleTime.secondsCount = busTime.secondsCountLo; /* Least significant bits */ } else cycleTime.cycleCount++; LK_CYCLE.indication = TRUE; /* Indicate cycle synch event to interested parties */ if (stateSet.cmstr) /* Are we the cycle master? */ cycleSynchQueued = TRUE; /* Yes, request a cycle start packet */ } else cycleTime.cycleOffset++; }

In Table 10, cycleOffsetThreshold is a global link variable that shall be updated as soon as possible but before

the second cycle synchronization event after receipt of a cycle master adjustment packet. An alpha port that is a cycle

master may also directly update the variable (see Table 9). The power reset value of cycleOffsetThreshold shall

be 3071.

NOTE – The normative requirements of this clause are behavioral; the intent is to permit the occurrence of the next cycle

synchronization event to be advanced or retarded by at most one cycle timer tick. Alternative, compliant implementations

may exist.

7.4.2 Coaxial cable port

Architecturally, an L3 IP bridge that contains an alpha coaxial cable belongs to a single cycle time domain, that of its

IEEE 1394 port's cycle timer. Although implementations may vary, it is assumed that the coaxial cable port is able to

access the IEEE 1394 port's BUS_TIME and CYCLE_TIME registers. Alpha coaxial cable ports are responsible to

transmit information to subordinate coaxial cable ports within the piconet so that they, in turn, can synchronize their

cycle time domains to that of the alpha port.

7.4.2.1 Cycle time broadcast

An L3 IP bridge’s alpha coaxial cable port functions like a cycle master within the alpha port's piconet. Once each

superframe, it shall broadcast a message the format specified by Figure 36. The MSDU that contains the message

shall be prefixed by an MSDU header whose Protocol ID field is equal to one (see 5.5).

octets: 2 4 4

Beacon Number Cycle Time Bus Time

Figure 36 – Coaxial cable cycle time message format



The Bus Time and Cycle Time fields shall contain the value of the bridge’s BUS_TIME and CYCLE_TIME

registers, respectively, as of the transmission or reception time15

of the first symbol of the PHY preamble of the

beacon identified by Beacon Number. The sampled values shall be adjusted to compensate for propagation delay

between the IEEE 1394 port and the upstream cycle master as well as for any delay between the first symbol of the

beacon’s PHY preamble and the actual time the samples are obtained.

The Beacon Number field shall contain the value of the beacon number provided by the

MLME-BEACON-EVENT.indication that caused BUS_TIME and CYCLE_TIME to be sampled.

7.4.2.2 Cycle time synchronization with MLME-BEACON-EVENT support

Highly accurate cycle offset synchronization relies upon the concurrent detection of the first symbol of the beacon’s

PHY preamble by all coaxial cable ports, alpha and subordinate, within the piconet.16

This provides a common

reference point that serves as a synchronization event, notification of which is provided by the MLME-BEACON-

EVENT service (see [R5]). A coaxial cable port activates the synchronization facility with an MLME-BEACON-

EVENT.request; successful activation is signaled by an MLME-BEACON-EVENT.confirm response of SUCCESS.

Subsequently, whenever a beacon is either transmitted or received, an MLME-BEACON-EVENT.indication is

generated.

The coordinated cycle offset samples obtained by the alpha port and all subordinate ports are the foundation of

vendor-dependent synchronization algorithms. Figure 37 illustrates the operating principles of the algorithm.

Figure 37 – Cycle time synchronization method

Whenever an L3 IP bridge coaxial cable port receives an MLME BEACON EVENT.indication, it shall sample its

co-port’s BUS_TIME and CYCLE_TIME registers and save their values along with the Sequence Number parameter

provided by the indication. The sampled values shall be corrected to reflect a) the propagation delay, as measured by

PHY ping packets, between the upstream cycle master and the bridge’s IEEE 1394 port and its cluster’s cycle master

15 All the coaxial cable bridge ports sample their cycle time at superframe T0. For the PNC, this is triggered by transmission of the

beacon's PHY preamble but for all other DEVs the event is triggered by reception of the beacon's PHY preamble. 16 The propagation delay caused by the length of coaxial cable that separates the transmitter and receiver may be ignored

cycle_timen

oscillator

CYCLE_TIME

local_cycle_timen

oscillator

CYCLE_TIME

cycle_timen

information n

Beacon n PHY preamble

cycle_timen n

Cycle time message PHY preamble

MLME-BEACON-EVENT.indication MLME-BEACON-EVENT.indication

Alpha coaxial cable port Subordinate coaxial cable port

comparator

predictive

update

MAC-ASYNC-DATA.indication



and b) any implementation-dependent delay (cf. BEACON_EVENT_DELAY in Table 11) between the actual time

the first symbol of the beacon’s PHY preamble and the receipt of the associated

MLME-BEACON-EVENT.indication.. The piconet’s alpha port shall transmit the corrected information in the next

cycle time message. An L3 IP bridge subordinate port shall save the sampled values and the identifying beacon

number for subsequent use to synchronize its CYCLE_TIME register with that of the alpha port. The sampling

algorithm is explained in more detail by the beaconEvent() function in Table 11 below.

A MAC-ASYNC-DATA.indication whose TrgtID parameter specifies group address 01A02D00 0000001F16 heralds

the receipt of a cycle time message, since all cycle time messages and only cycle time messages are transmitted to

that group address. Upon receipt of a cycle time message in the format specified by 7.4.2.1, an L3 IP bridge

subordinate coaxial cable port shall search previously obtained samples of its own cycle timer for one whose beacon

number matches the beacon number in the cycle time message. If there is a match, the subordinate port shall compute

the phase offset between the two cycle timers:

drift = SUBORDINATE_CYCLE_OFFSETN - ALPHA_CYCLE_OFFSETN

In the formula above, N is equal to both the cycle time message’s Beacon Number field and the beacon number

parameter associated with a local cycle timer sample, SUBORDINATE_CYCLE_OFFSETN is the value of the

subordinate port's CYCLE_TIME.cycle_offset, sampled at the time of the MLME-BEACON-EVENT.indication

identified by N and ALPHA_CYCLE_OFFSETN is the value of the cycle offset from the cycle time message’s Cycle

Time field. Because the subordinate portal might fail to observe one or more beacons, the value of drift, a number

of cycle ticks, might represent phase divergence accumulated over more than one superframe—in which case drift

shall be normalized to cycle ticks per superframe:

drift = drift / sample_interval

When drift is positive, the subordinate (downstream) cycle master is running faster than the alpha (upstream) cycle

master is and must have some number of its isochronous intervals lengthened by 40.69 ns apiece until phase-offset

synchronization is achieved. Contrariwise, if drift is negative, the subordinate cycle master is running slower than

the alpha cycle master is and must be speeded up temporarily. Adjustments shall be evenly distributed during any

arbitrarily selected interval whose duration is equal to that of the piconet's superframe. As a consequence, the pro

rata adjustment might be a fraction of a tick of the 24.576 MHz cycle timer, in which case sufficient fractional

adjustments shall accumulate before a ±1 tick adjustment shall be applied to the downstream cycle master. The

behavioral requirements of the sampling and drift correction algorithms are specified in more detail by Table 11

below:

Table 11 – Coaxial cable port actions to synchronize cycle offset

#include "csr.h" #include "math.h" #include "global.h" struct { /* Cycle time samples taken by MLME-BEACON-EVENT interrupt service routine */ DOUBLET beaconNumber; /* Identifies when the sample was taken */ DOUBLET sampleInterval; /* Number of superframes since most recent sample */ BUS_TIME busTime; CYCLE_TIME cycleTime; } cycleTimeSample[2]; INT driftCorrection = 0; /* Drift correction, in picoseconds, to apply downstream every 125 µs */ /* Positive correction: downstream cycle timer is drifting behind */ /* Negative correction: downstream cycle timer is drifting ahead */ VOID beaconEvent(DOUBLET beaconNumber) { CYCLE_TIME_MSG cycleTimeMessage; STATIC BOOLEAN firstTime = TRUE; STATIC INT i = LAST(cycleTimeSample), sampleInterval; if (firstTime) { /* Is this our very first sample? */ sampleInterval = 0; /* Yes, it's essentially instantaneous */ firstTime = FALSE; } else {



sampleInterval = beaconNumber - cycleTimeSample[i].beaconNumber; if (sampleInterval >= MAX_LOST_BEACONS) /* Too many beacons missed? */ sampleInterval = 0; } i = (i + 1) % (LAST(cycleTimeSample) + 1); /* Advance pointer from previous sample */ cycleTimeSample[i].beaconNumber = beaconNumber; /* Label the sample */ cycleTimeSample[i].sampleInterval = sampleInterval; cycleTimeSample[i].busTime = busTime; /* Read from BUS_TIME and ... */ cycleTimeSample[i].cycleTime = cycleTime; /* ... CYCLE_TIME registers in IEEE 1394 link */ cycleTimeSample[i].cycleTime.cycleOffset = (cycleTimeSample[i].cycleTime.cycleOffset + 3072 - BEACON_EVENT_DELAY) % 3072; /* Adjust for delays */ if (stateSet.cmstr) /* Are we the cycle master? */ cycleTimeSample[i].cycleTime.cycleOffset -= downstreamDelay; /* No, adjust for propagation delay */ if (cablePort.cycleTimeRole == alpha) { /* Alpha port also transmits cycle time message */ cycleTimeMessage.busTime = cycleTimeSample[i].busTime; cycleTimeMessage.cycleTime = cycleTimeSample[i].cycleTime; cycleTimeMessage.beaconNumber = cycleTimeSample[i].beaconNumber; MAC_ASYNC_DATA.request(cycleTimeID, ownDEVID, 0, NO_ACK, 0, sizeof(cycleTimeMessage), &cycleTimeMessage); } } VOID calculateDriftCorrection(CYCLE_TIME_MSG *cycleTimeMessage) { INT adjustmentsPerSuperframe = superframeDuration / 125; /* Adjustment OK once each isochronous interval */ INT downstreamOffset, drift, i, upstreamOffset; for (i = 0; i <= LAST(cycleTimeSample); i++) if (cycleTimeMessage->beaconNumber == cycleTimeSample[i].beaconNumber) break; if (i > LAST(cycleTimeSample)) /* Sample of downstream cycle timer available? */ return; /* No, leave drift correction unchanged */ upstreamOffset = cycleTimeMessage->cycleTime.cycleOffset; downstreamOffset = cycleTimeSample[i].cycleTime.cycleOffset; drift = downstreamOffset - upstreamOffset; /* Positive drift --> faster downstream cycle timer */ if (abs(drift) > 1536) /* Is there a shorter path to phase-lock convergence? */ drift += (drift < 0) ? 3072 : -3072; /* Yes, reverse direction */ drift /= cycleTimeSample[i].sampleInterval; /* Normalize drift to one superframe */ driftCorrection -= drift * CYCLE_TICK / adjustmentsPerSuperframe; /* Picoseconds to adjust every 125 µs */ if (abs(driftCorrection) > CYCLE_TICK) /* Drift correction exceeds limits? */ driftCorrection = (driftCorrection > 0) ? CYCLE_TICK : -CYCLE_TICK; /* Yes, throttle it back */ }

In beaconEvent() above, each coaxial cable port calculates the time, in superframes, that has elapsed since the

previous sample. Next, the port samples its co-port's (i.e., the IEEE 1394 link's) BUS_TIME and CYCLE_TIME

registers. The cycle time sample is adjusted to compensate for the constant, implementation-dependent delay from

the actual start of the beacon's PHY preamble to the MLME-BEACON-EVENT.indication that invoked the

procedure. If the IEEE 1394 link is not cycle master within its own cluster, the cycle time sample shall also be

adjusted to compensate for the propagation delay between it and the cycle master. If the coaxial cable port is the

alpha port, it broadcasts a cycle time message that contains the cycle time sample and identifying beacon number.

Receipt of a cycle time message by a subordinate coaxial cable port invokes calculateDriftCorrection().The

procedure attempts to match the alpha port's cycle time sample with one of its own, previously obtained, cycle time

samples. If there is no corresponding cycle time sample, the current drift correction is left unchanged and will

continue to be applied by adjustDownstreamCycleMaster() until driftCorrection is recalculated. The

procedure tests the initially calculated drift to see if it is greater than 62.5 µs and, if so, converts the drift to its

complement in the opposite direction. The drift is also adjusted for the size of the sample interval before it is used to

update the current drift correction. In order to evenly distribute cycle time adjustments throughout a superframe

interval, the drift correction is expressed as a number of picoseconds less than or equal to 40.69 ns (one tick of the

24.576 MHz cycle timer). Fractional tick drift corrections are accumulated in adjustDownstreamCycleMaster()

until sufficient time has occurred to perform a one tick adjustment.



7.5 Network time

7.5.1 TIME_OFFSET message processing

Although the procedures described above permit all cycle timers within a network to be synchronized to the network

cycle master, they are not sufficient to permit nodes on different clusters to share a common time. Common time is

relative between any two clusters; the TIME OFFSET message specified in 5.2.7 permits the time difference between

arbitrary clusters to be measured. The relative time difference, measured in isochronous cycles, between any two

clusters does not change so long as neither the value of BUS_TIME nor the combined value of

CYCLE_TIME.second_count and CYCLE_TIME.cycle_count on either cluster changes other than because of

normal increment.

NOTE – ―Normal increment‖ occurs when CYCLE_TIME.cycle_offset reaches a threshold value, resets to zero and causes

CYCLE_TIME.cycle_count to increment. Transient changes to the threshold value caused by receipt of a cycle master

adjustment packet do not affect this definition.

A TIME OFFSET request is intercepted and processed by all bridge ports on the route between the two clusters

whose relative time difference is to be measured. Each bridge updates a cumulative cycle count difference

maintained in the message with the relative difference between its two ports. The direction of the adjustment is

determined by the relationship of the ingress and egress ports, as shown by Table 12.

Table 12 – Ingress port actions on receipt of a TIME OFFSET message

The procedure timeOffset() processes an intercepted TIME OFFSET message. The first input parameter is the

interface (port) upon which the message was received, the next two input parameters are the sourceAddress and

destinationAddress fields from the IP header and the fourth is the TCP datagram payload (the TIME OFFSET

message itself). The remaining input parameters to the procedure, ingressBusTime, ingressCycleCount,

egressBusTime and egressCycleCount, represent the observed values of BUS_TIME.seconds and

CYCLE_TIME.cycle_count, respectively, as seen on the ingress and egress port’s clusters, respectively. It is essential

that these values be sampled simultaneously.

Although the procedure shows the calculation of the relative time difference between the bridge’s ports each time a

TIME OFFSET message is intercepted, implementations may sample this difference less frequently.

#include "global.h" #include "packets.h" VOID timeOffset(PORT_INFO *rxPort, QUADLET destinationAddress, QUADLET sourceAddress, TIME_OFFSET_MSG *timeOffsetMsg, QUADLET ingressBusTime, QUADLET egressBusTime, DOUBLET ingressCycleCount, DOUBLET egressCycleCount) { ROUTE_INFO *destinationRoute, *sourceRoute; if ( (sourceRoute = getRoute(sourceAddress)) == NULL /* Are both source and ... */ || (destinationRoute = getRoute(destinationAddress)) == NULL) { /* ... destination routable? */ txNotificationMsg(sourceAddress, timeOffsetMsg->messageID, TIME_OFFSET, INVALID_ROUTE); return; } if (rxPort == sourceRoute->port) { timeOffsetMsg->deltaCycles += (egressCycleCount - ingressCycleCount) + 8000 * (egressBusTime - ingressBusTime); txLDPDatagram(destinationRoute->port, destinationAddress, timeOffsetMsg); } else txLDPDatagram(sourceRoute->port, sourceAddress, timeOffsetMsg); }



7.5.2 BUS_TIME and CYCLE_TIME register modifications

Neither the BUS_TIME register nor CYCLE_TIME register should be modified except as the result of normal

increment. Whenever the BUS_TIME register's least significant seven bits wrap to zero or a device is connected to

the cluster, the bus manager (or, in the absence of a bus manager, the isochronous resource manager), should

broadcast the value of its BUS_TIME register.

NOTE – [R6] specifies that only the bus manager or, in its absence, the isochronous resource manager, is permitted to

initialize another device's BUS_TIME register. The preceding clarifies the circumstances under which the BUS_TIME

register should be updated.



8 Expedited FCP and round-trip timing

Expedited FCP (XFCP) is a protocol that solves the coaxial cable latency problems described in 4.4. Without the

latency reductions afforded by XFCP, a DTCP-conformant source device would have little chance of measuring a

round-trip time less than or equal to 7 ms between itself and a remote sink device. XFCP relies upon a special

operating mode for the bridge and MAC entities, a method of identification for FCP command and response frames

to be expedited and its own protocols for using these facilities—all of which are described in detail below.

8.1 Round-trip timing mode (RTTM)

Each L3 IP bridge's MLME provides implementation-dependent services that support expedited transmission of FCP

command and response frames. Specifically, the MLME provides a method to activate, configure or deactivate a

special MAC operating mode called ―round-trip timing mode‖ (RTTM). Peer MAC entities synchronize their

activation of RTTM through the exchange of RTTM command frames (see 5.6). The parameters enumerated in the

table below control the MLME-RTTM service primitives that mediate the transmission and reception of RTTM

command frames.

Name Type Valid Range Description

EnableRTTM Boolean FALSE, TRUE Disables or enables the recipient

DEV's RTTM.

OrigID Integer 1 – EC16 The request originator's DEVID.

ReasonCode Enumeration INVALID PARAMETER,

NOT ASSOCIATED,

NOT IMPLEMENTED,

RESOURCES UNAVAILABLE,

SUCCESS,

UNSPECIFIED ERROR

Unless a timeout has occurred, this

parameter determines the FAILURE

or SUCCESS value of ResultCode.

If an error has occurred, it specifies

the cause.

RequestID Integer 0 – 255 Uniquely identifies the request

amongst the originating DEV's

outstanding requests.

ResultCode Enumeration FAILURE, SUCCESS,

TIMEOUT

Specifies the completion status of

the request.

StreamIndex Integer 1 – FC16,

FE16

For MLME-RTTM.request, the

unassigned stream index. Otherwise,

a stream index assigned by the PNC

that identifies the stream to be used

for RTTM operations.

Timeout Integer 0 – 65535 The maximum time, in milliseconds,

allowed the target to return a

response.

TrgtID Integer 1 – EC16 The intended recipient's DEVID.

NOTE – Although different vendors might implement RTTM and the service primitives that control it in different ways, the

externally observable functional behaviors of bridge, MLME and MAC entities are normative and shall conform to this

specification.

8.1.1 MLME-RTTM.request

The syntax and semantics of the request are as follows:



MLME-RTTM.request( TrgtID, RequestID, Timeout, EnableRTTM, StreamIndex)

The bridge entity issues this request to cause the MLME to enable or disable RTTM within the DEV and the peer

bridge identified by TrgtID.

Upon receipt of an MLME-RTTM.request, if EnableRTTM is TRUE, the MLME requests creation of an

isochronous stream for use with RTTM. If the PNC assigns a stream index, the MLME transmits a vendor-specific

command frame to the DEV identified by TrgtID; this message communicates the stream index for use with RTTM

and requests the peer bridge to enable RTTM. The peer bridge is expected to transmit a vendor-specific response

frame to the originating DEV. If the response frame's Result Code indicates SUCCESS, the MLME places the MAC

into RTTM and reports SUCCESS to the bridge entity. Otherwise, if the peer bridge has not enabled RTTM, the

MLME terminates the just-created stream and reports FAILURE to the bridge entity.

When EnableRTTM is FALSE, the MLME transmits an RTTM command frame to the DEV identified by TrgtID.

The peer bridge disables RTTM and transmits a vendor-specific response frame to the originating DEV. Upon receipt

of the response frame, the originating bridge disables RTTM within the MAC and terminates the stream identified by

StreamIndex.

8.1.2 MLME-RTTM.indication

The syntax and semantics of the indication are as follows:

MLME-RTTM.indication( OrigID, RequestID, EnableRTTM, StreamIndex)

The recipient of an RTTM request command frame disables or enables its MAC entity RTTM according to the value

of EnableRTTM, after which the MLME provides this indication to the bridge entity. The MLME also transmits an

RTTM response command frame to the bridge that originated the RTTM request command frame.

8.1.3 MLME-RTTM.response

The syntax and semantics of the response are as follows:

MLME-RTTM.response( OrigID, RequestID, ReasonCode)

The bridge entity issues this response to confirm that the DEV's RTTM is disabled or enabled in accordance with the

request's EnableRTTM parameter. The service primitive causes the transmission of an RTTM response command

frame from the target DEV to the DEV that originated the RTTM command.

8.1.4 MLME-RTTM.confirm

The syntax and semantics of the confirmation are as follows:

MLME-RTTM.confirm( TrgtID, RequestID, StreamIndex, ResultCode, ReasonCode)



Upon receipt of an RTTM response command frame, the originating bridge's MLME signals this confirmation to the

bridge entity to communicate the stream index to be used with RTTM and to confirm the success or failure of the

RTTM request identified by RequestID. If the bridge's MAC entity has enabled RTTM and the ResultCode is either

FAILURE or TIMEOUT, the bridge's MLME instructs the MAC entity to disable RTTM.

8.2 XFCP command and response registers

Within a local IEEE 1394 cluster, AKE and round-trip timing messages are transported by Function Control Protocol

(FCP). As specified by [R2], FCP command and response frames are transmitted as IEEE 1394 asynchronous block

write requests addressed to a target's command register or a controller's response register, respectively. The command

and response registers are located at well-known addresses FFFF F000 0B0016 and FFFF F000 0D0016, respectively,

and can accommodate FCP frames of up to 512 bytes.

In order to differentiate expedited from non-expedited data traffic, FCP command and response frames used in the

AKE and localization procedure shall be written to XFCP command and response registers, which are indiscernible

from conventional FCP registers except for their addresses. For XFCP command frames, an L3 IP bridge shall

instantiate a unique XFCP command register for each remote AV/C device on whose behalf the bridge has previously

transmitted an ARP response. The address of the register shall be unicast_FIFO + 4096, where unicast_FIFO is the

address to which IP datagrams destined for the remote device are written. For XFCP response frames, an L3 IP

bridge shall instantiate a single XFCP response register at FFFF F000 0D0016. The XFCP command registers shall be

used solely for the transport of AKE and round-trip timing commands. L3 IP bridges shall ignore and silently discard

all other FCP command frames addressed to an XFCP command register. Any type of FCP response frame may be

written to the FCP response register.

8.3 Expedited FCP operations

When RTTM is disabled, XFCP operations, in fact, are not particularly expedited. During non-expedited operations,

a bridge may receive an FCP command or response frame via one of its XFCP command registers or its FCP

response register, respectively. Although command and response frame processing differ significantly, the routing

decisions for the FCP frame rely upon using the bridge's ARP cache to convert from an IEEE 1394 node ID to an IP

address and vice versa.

NOTE – This algorithm presupposes a one-to-one mapping between IEEE 1394 node ID and IP address. If the node that

contains the source device implements additional IP-capable devices, unpredictable behavior might occur if XFCP is used,

since the L3 IP bridge might map the IEEE 1394 node ID to an incorrect IP address.

The clauses that follow describe operations from the perspective of bridge functional roles, ingress (an AV/C device

transmits an FCP frame to the bridge) or egress (the bridge transmits an FCP frame to an AV/C device), for normal,

non-expedited mode and as modified by RTTM.

NOTE – The reader might find the MSC and accompanying narrative in informative Annex G helpful in understanding the

normative text in the clauses that follow.

8.3.1 Ingress bridge FCP command frame operations

Whenever an L3 IP bridge transmits an ARP response on behalf of a remote device in some other IEEE 1394 cluster,

it provides the address of an input FIFO register within its own address space. This unicast_FIFO, intended for the

reception of unicast IP datagrams, is present in the ARP response as part of the hardware address to which the target

IP address resolves. At the same time the bridge allocates virtual address space for the unicast FIFO, it also allocates

virtual address space for an FCP command register located at unicast_FIFO + 4096. Thus, a device that has

discovered a remote device's hardware address has also indirectly discovered the address of an FCP command

register usable for AV/C commands that require expedited processing, i.e., those involved in AKE and localization.

When an FCP command frame is written to an XFCP command register, the bridge shall encapsulate the FCP

command frame in an XFC PDU. The bridge shall use the source device's IEEE 1394 node ID and information in its



ARP cache to determine the XFC PDU source_IP_address. The bridge shall determine the XFC PDU

destination_IP_address from the address of the XFCP command register. The bridge shall initialize the other fields

of the XFC PDU as specified by 5.9, after which the bridge shall use MAC-ASYNC-DATA.request to queue the

XFC PDU for transmission to the bridge that routes traffic for destination_IP_address.

An L3 IP bridge monitors all the FCP command frames written to one of its XFCP command registers. If a command

frame contains an RTT SETUP command, this is a signal for the bridge and one of its peers to enable RTTM. The

bridge transmits the RTT SETUP command frame as described above and, in parallel, initiates the transition to

RTTM, as described below.

8.3.2 Ingress bridge FCP response frame operations

When the bridge receives an FCP response frame via its FCP response register, the bridge shall encapsulate the FCP

response frame in an XFC PDU. The bridge shall use the source device's IEEE 1394 node ID and information in its

ARP cache to determine the XFC PDU source_IP_address. Next, the bridge shall search its pending transaction

database for an entry whose target_IP_address is equal to the just-derived source_IP_address. If no pending

transaction matches, the bridge shall ignore and silently discard the FCP response frame. Otherwise, the XFC PDU

destination_IP_address shall be set to the value of controller_IP_address from the pending transaction information.

The bridge shall initialize the other fields of the XFC PDU as specified by 5.9, after which the bridge shall use

MAC-ASYNC-DATA.request to queue the XFC PDU for transmission to the bridge that routes traffic for

destination_IP_address.

8.3.3 Egress bridge FCP command and response frame operations

An MSDU that contains an XFC PDU can be received asynchronously or isochronously, as signaled by either a

MAC-ASYNC-DATA.indication or a MAC-ISOCH-DATA.indication, respectively. In either case, the bridge shall

extract the FCP command or response frame from the XFC PDU and then shall use destination_IP_address and

information in its ARP cache to determine the IEEE 1394 node ID of the device to which the FCP frame shall be

transmitted. Dependent upon the value of the XFC PDU type field, zero or one, the bridge shall use an IEEE 1394

asynchronous block write request to transmit the FCP frame to the target device's FCP command or response register,

respectively. In the case of an FCP command frame, the bridge shall create a (controller_IP_address,

target_IP_address, fcp_frame) entry in a database of pending FCP transactions. The entry's IP addresses correspond

to the XFC PDU source_IP_address and destination_IP_address fields, respectively. Pending transactions may be

deleted from the database after 200 ms.

The above procedures are modified when the bridge's most recent XFCP action was the transmission of a XFC PDU

that contained an RTT SETUP command frame. In this case, the type of XFC PDU determines whether the bridge

and its peer complete the transition. If the rcode is nonzero, there has been an error in the delivery of the RTT

SETUP command frame to the target device; consequently, it has not calculated message authentication codes and is

not ready to perform round-trip timing. The bridge that initiated RTTM shall generate MLME-RTTM.request to

disable RTTM, and return the stream resources to the PNC.

Otherwise, if the XFC PDU contains an ACCEPTED response frame, the bridge shall temporarily ―pocket‖ the

ACCEPTED response frame and await a beacon that announces a CTA for the stream index to be used for RTTM.

Once the bridge is aware of the time the CTA will occur in the superframe, it can calculate when to transmit the

ACCEPTED response frame to the AV/C controller. Processing delays within the controller, arbitration delays within

the IEEE 1394 cluster and queuing delays within the L3 IP bridge determine how much "lead-time" should be

afforded the AV/C controller. See 8.4.1 for a discussion of CTA duration and lead-time and their combined effect on

the probability of successful RTT measurement less than or equal to 7 ms.



8.4 Round-trip timing mode (RTTM) operations

RTTM is an implementation-dependent mode of operation, designed to afford the highest possible priority and incur

the lowest possible latency in L3 IP bridge transmission of time-critical AV/C command and response frames. Active

RTTM modifies the MAC's normal processing of queued and received MSDUs as follows:

– MSDUs that contain an XFC PDU, which are identifiable by their MSDU header (see 5.5) shall be transmitted

with an ACK policy type of Imp-ACK, implied acknowledge.

– Transmission of an expedited MSDU shall be granted preemptive priority above all other MSDUs. When the

CTA for the expedited stream starts, the source MAC shall immediately transmit whatever expedited MSDU is

queued for the stream and shall not transmit any other MSDUs. If the expedited stream transmit queue is

empty, the MAC shall not transmit any other MSDUs but shall wait for an expedited MSDU to be queued and

shall then transmit it. After transmitting the expedited MSDU, the source MAC shall switch its PHY to receive

mode in anticipation of an implied ACK from the target bridge.

– Reception of an expedited MSDU shall be granted preemptive priority above all other MSDUs. The details are

implementation-dependent, but might involve dedicating all MAC resources to the reception of the anticipated

MSDU. Upon receipt of the expedited MSDU, the MAC shall immediately provide a

MAC-ISOCH-DATA.indication to the bridge and shall then await a MAC-ISOCH-DATA.request from the

bridge. If the request's Stream Index parameter matches the stream index for which RTTM has been activated,

the MAC shall immediately transmit the expedited MSDU and await an Imm-ACK from the source bridge.

– Once an expedited FCP transaction has completed, the MACs may use the remainder of the CTA, as well as

the remainder of the superframe, in any way permitted by IEEE 802.15.3.

8.4.1 RTTM heuristics (informative)

The goal of RTTM is to improve the probability that an RTT TEST command frame originated by an AV/C

controller and the corresponding ACCEPTED response frame returned by an AV/C target could both be transmitted

across the coaxial cable medium during a single CTA whose duration is nominally 7 ms or less.

One can maximize the odds of success by the application of two independent heuristics, one intended to reduce

"dead time", i.e., the time from the beginning of the CTA until the start of UWB transmission of the RTT TEST

command frame and the other to increase the CTA duration.

Every microsecond that elapses from the start of the CTA until the transmission of the RTT TEST command frame

represents a reduction in the usable duration of the CTA. On the other hand, every microsecond that elapses from the

time an RTT TEST command frame is queued and ready for transmission is wasted time while the round-trip timer is

running. In both cases, the solution is to arrange matters so that the AV/C controller transmits the RTT TEST

command frame as close in time as possible to the start of the CTA. This is done by adjusting the lead-time for the

transmission of the ACCEPTED response frame that corresponds to the RTT SETUP command frame. If the AV/C

controller transmits the RTT TEST command frame after the start of the CTA, increase the lead-time to give the

AV/C controller more time to respond to the ACCEPTED response frame and transmit the RTT TEST command

frame. Contrariwise, if the RTT TEST command frame is ready for transmission before the CTA starts, decrease the

lead-time.

If RTT TEST start of transmission and the start of the CTA align within ± 125 µs, but the source-adjacent bridge's

MAC entity fails to observe an ACCEPTED response that corresponds to the RTT TEST command frame, one

should apply the second heuristic. If resources permit, increase the CTA duration in 125 µs increments while

watching for an ACCEPTED response frame from the sink-adjacent bridge. Stop the increments when the either an

ACCEPTED response is observed or the total CTA duration reaches its maximum of 7 ms.

Implementers should consider the following:



– When adjusting lead-time or CTA duration, hysteresis should be applied to the corrections in order to avoid

the possibility of oscillatory feedback;

– Many of the factors that contribute to latency along the transmission path are highly variable and transient,

with the result that the lead-time or CTA duration calculated based upon the most recent RTTM activation of

might be dramatically inappropriate for the upcoming RTTM activation; and

– Suggested initial values for lead-time and CTA duration are 2 ms and 3 ms, respectively. One should make

corrections in increments of 125 µs. This is the duration of an IEEE 1394 isochronous interval and, if there is

a quantum jump in observed start of transmission for an RTT TEST command frame, it is most likely to be a

multiple of 125 µs.

Other strategies towards meeting the goal of 7 ms round-trip time may be feasible and implementers are encouraged

to explore their possible existence.

8.4.2 RTTM enable operations

When a bridge detects an RTT SETUP command frame, it shall initiate the transition to RTTM by issuing an

MLME-RTTM.request. This causes the MLME to attempt the creation of an isochronous stream that consists of a

single 2 ms to 7 ms CTA per superframe. The MLME accomplishes this by transmitting a Channel Time request

control frame to the PNC. The fields in the Channel Time request block should be initialized as described in

Table 13; this is one way to obtain a CTA of the desired length.

Table 13 – Nominal CTRqB field values for RTTM CTA

Parameter Value Comment

Num Targets 1 Only one other bridge DEV can participate in RTTM

Target ID List Non-broadcast,

non-multicast DEVID DEVID of peer bridge RTTM partner

DSPS Set Index 0 L3 IP bridges are mains-powered and do not participate

in power saving sets

Stream Request ID 0 – 255 Generated by the originator of the Channel Time request

control frame to uniquely identify the request

Stream Index FE16 The PNC assigns a Stream Index if the Channel Time

request is successful

User Priority 7 RTTM is network control

PM CTRq Type 0 An ACTIVE CTA is requested

CTA Type DYNAMIC There is no need for a pseudo-static CTA

CTA Rate Type 0 Sub-rate CTA

Target ID List Type 1 Isochronous CTA requested

CTA Rate Factor 1 One CTA per superframe

CTRq TU 1000 – 7000

Because Minimum and Desired TUs are both set to one,

CTRq TU becomes the total Channel Time allocation

requested, from 1 ms to 7 ms.

Minimum TUs

Desired TUs 1

Setting the minimum and desired TUs to the same value

guarantees an all or nothing allocation and setting that

value to one guarantees that all the time will be

allocated in a single CTA.



Once the PNC has confirmed the allocation of a suitable CTA, the bridge's MLME transmits a vendor-specific

request command frame (see 5.6) to communicate Stream Index to the peer bridge that routes traffic for the target

device and to request that the peer bridge enable RTTM. Receipt of the command frame causes the MLME to enable

RTTM for its MAC entity and to communicate Stream Index to the bridge entity. The peer bridge's MLME confirms

the success or failure of these operations by transmitting a vendor-specific response command frame to the

originating bridge. If the originating bridge fails to receive the command frame within the request timeout limit or

ReasonCode is other than the SUCCESS, the bridge shall disable RTTM, terminate stream and returned to normal,

non-expedited operations.

Otherwise, when ReasonCode is SUCCESS, the peer bridges are synchronized with respect to RTTM. Both expect to

use the CTA in the next superframe to accomplish expedited transmission of the RTT TEST command and

ACCEPTED response. This will require the bridge that initiated RTTM to modify the normal, non-expedited

processing of an XFC PDU as described in 8.3.3.

8.4.3 RTTM disable operations

Once the bridge that initiated RTTM has completed an FCP transaction using RTTM, it shall use

MLME-TERMINATE-STREAM.request to return the channel time allocation to the PNC and shall use

MLME-RTTM.request to disable RTTM in both itself and its peer bridge. The bridge returns to normal, non-

expedited operations in which it monitors FCP command frames for an RTT SETUP command that would initiate

RTTM once again.



Annex A

(normative)

Minimum node capabilities for L3 IP bridge IEEE 1394 ports

In addition to the minimum capabilities defined by IEEE 1394 for isochronous resource manager-capable nodes, this

annex specifies other capabilities or restrictions mandated by this specification for L3 IP bridge IEEE 1394 ports.

An IEEE 1394 bridge port shall be capable of receiving and transmitting primary packets whose data payload is less

than or equal to 512 bytes; the max_rec field in a bridge port’s bus information block shall be greater than or equal to

eight. This capability applies to requests and responses addressed to or originated by the bridge port.

An IEEE 1394 bridge shall implement adjustable cycle master capability (see [R10]). This entails both the ability to

be controlled by received cycle master adjustment packets and the ability to calculate and transmit synchronization

adjustments when another node is the cycle master. Correct implementation of the cycle master adjustment

algorithms also requires an IEEE 1394 bridge port to implement support for the PHY ping packet (see [R7]).

A bridge port shall be capable of initiating write requests and shall report this by setting the drq bit in the

Node_Capabilities entry in configuration ROM to one. Consequently, bridge ports shall implement the dreq bit in the

STATE_CLEAR and STATE_SET registers. The value of STATE_CLEAR.dreq shall be unaffected by a bus reset.

Bridge ports may autonomously set dreq to zero (request initiation enabled) upon a power reset or a command reset.

While initializing after a power reset, a bridge port whose link layer is active shall either respond to quadlet read

requests addressed to FFFF F000 040016 with a response data value of zero or acknowledge the request subaction

with ack_tardy. This indicates that the remainder of configuration ROM, as well as other bridge port CSRs, is not

accessible.

Configuration ROM, when accessible to read requests, shall contain a Unit Directory that identifies the L3 IP bridge

IEEE 1394 port's capabilities, as specified by Figure A-1.

Figure A-1 – L3 IP bridge IEEE 1394 port unit directory

The Specifier_ID and Version entries, with key field values of 1216 and 1316, respectively, specify that the L3 IP

bridge conforms to this 1394 Trade Association Technical Specification.

The Bridge_Capabilities entry, with a key field value of 3816, specifies some of the L3 IP bridge's capabilities, as

described below.

The max_isoch field specifies the maximum data payload the L3 IP bridge supports in a single stream SDU, as

determined by the IEEE 1394 port's link and PHY speed capabilities. When max_isoch is zero, the bridge’s

maximum isochronous payload is not specified. Otherwise, the maximum isochronous payload is defined as

2 max_isoch + 1

bytes. The value of max_isoch shall be the same for all for a bridge's ports.

least significant

7 Unit directory CRC (calculated)

rsv

most significant

streams

version (02 000016)

latency

specifier_ID (00 A02D16) 1216

1316

max_isoch 3816



The streams field specifies the maximum number of concurrently active isochronous streams supported by the

bridge. A value of zero indicates that the bridge does not support isochronous streams. The value of streams shall be

the same for both ports of a bridge.

NOTE – There is no guarantee that the number of concurrently active isochronous streams will attain the value reported in

the streams field. For example, the aggregate bandwidth required by a small number of high-bandwidth streams might

consume nearly all of the bridge's resources and preclude the creation of additional streams, even if of modest bandwidth.

The latency field specifies the constant delay that isochronous stream SDUs incur once they are received by the

bridge's IEEE 1394 port until they are received by the next-hop ingress port in the coaxial cable domain connected to

an egress port. The value of latency shall be zero either if the L3 IP bridge does not implement support for

isochronous streams (i.e., the streams field is zero) or if individual isochronous streams can incur differing constant

delays. Otherwise, the latency field shall specify the delay in units of 125 µs. The latency experienced by

isochronous streams received by a bridge's coaxial cable port and transmitted to an endpoint sink or next-hop ingress

port in the IEEE 1394 domain may differ from the value reported by the latency field.



Annex B

(normative)

Minimum DEV capabilities for L3 IP bridge coaxial cable ports

This annex specifies minimum IEEE 802.15.3 DEV capabilities required for a conformant implementation of an L3

IP bridge coaxial cable port.

The requirements in Table B-1 through Table B-3, inclusive, reference the IEEE 802.15.3 protocol implementation

conformance statements (PICS). The mandatory, normative requirements of [R4] and [R5] are not reduced; the tables

below identify the PICS items that are optional within IEEE 802.15.3 but mandatory or recommended for devices

that claim conformance with this technical specification.

Table B-1 – Major roles for IEEE 802.15.3 DEVs

Table B-2 – MAC frame formats

PICS Item Description Implementation Status

MF2.8 Non-secure data Mandatory

Table B-3 – MAC sublayer functions


MLF16.6 Implied acknowledge Mandatory

MLF27 a Beacon event service Mandatory

a The beacon event service was unintentionally omitted from the IEEE Std 802.15.3b PICS. Its

inclusion is anticipated in a future IEEE corrigendum, amendment or revision of the standard.

The requirements in Table B-4 reference the IEEE 802.15.3 MAC personal area network information block (PIB).

Table B-4 – MAC personal area network information block (PIB) requirements

Object Definition Minimum Recommended

MACPIB_SuperframeDuration Duration of the superframe 25 000 µs

MACPIB_PNCCapable TRUE if the DEV has the capability to

become the PNC, FALSE otherwise TRUE

MACPIB_PNCDesMode TRUE if it is desired that the DEV be the

PNC TRUE


FD2 DEV is PNC-capable Mandatory

FD4 a Continuous pulsed UWB PHY [R1] Mandatory

a The FD4 designator does not appear in the IEEE Std 802.15.3b PICS. Its inclusion is

anticipated in a future IEEE amendment or revision of the standard.



Object Definition Minimum Recommended

MACPIB_MaxAssociatedDEVs Maximum number of concurrently

associated DEVs supported by the PNC 2 8

MACPIB_MaxCTRqBs The number of channel time request

blocks implemented by the PNC 36 72

MACPIB_PiconetMaxStreams a Maximum number of concurrently active

streams supported within the piconet 8 16

MACPIB_MaxStreams Maximum number of concurrently active

streams supported by the DEV 2 6

MACPIB_PowerSource TRUE if the DEV is mains-powered,

FALSE otherwise TRUE

MACPIB_ImpACKCapable

TRUE if the DEV is capable of using

implied- ACK (Imp-ACK) as the source,

FALSE otherwise

TRUE

a This new object is proposed for inclusion in a future corrigendum, amendment or revision of IEEE Std 802.15.3.

A conformant L3 IP bridge coaxial cable port implementation requires the MAC to provide the following services:

Primitive

Service Name request indication response confirm

MAC-ASYNC-DATA X X X

MAC-ISOCH-DATA X X X

MLME-RESET X

MLME-SCAN X X

MLME-START X X

MLME-STOP X X

MLME-ASSOCIATE X X X X

MLME-DEV-ASSOCIATION-INFO X

MLME-DISASSOCIATE X X X

MLME-CREATE-STREAM X X

MLME-TERMINATE-STREAM X X X

MLME-BEACON-EVENT X X X

MLME-RTTM X X X X

The MAC shall not fragment MSDUs unless an MSDU is larger than pMaxTransferUnitSize. In order to make the

best use of channel time allocation when frame retransmission is necessary, the MAC should fragment MSDUs larger

than pMaxTransferUnitSize into fragments of equal size.



Annex C

(normative)

Conformance requirements

This annex is intended to assist designers, implementers and conformance test developers; it provides a concise

summary of mandatory and optional features and, for each feature, reference to the governing normative clauses.

L3 IP bridge conformance requirements are divided into two groups: a) requirements that apply to the bridge as a

whole or to the bridge's ports regardless of port type and b) port type-dependent requirements for individual IEEE

1394 or coaxial cable ports.

The conformance requirements for each of the groups are presented in separate tables below. Related features are

grouped together and identified by a block ID. Subsidiary clauses inherit the implementation requirements of their

parent clause. Within a block, if any optional feature is implemented, optional features within the same block shall be

implemented. If an optional feature is implemented, it shall conform to all of the requirements of the governing

normative clauses.

Table C-1 – L3 IP bridge conformance requirements

Block Feature Implementation Reference

B1 a Data and message formats

Bridge protocol data unit (BPDU)

Label distribution protocol (LDP) messages

DHCP message

IEEE 1394 stream service data unit

Common isochronous packet (CIP) data

Mandatory

Mandatory

Mandatory

Optional

Optional

5.1

5.2

5.3

5.7

5.8

B2 Internet protocol operations

Distributed host control protocol (DHCP)

Address resolution protocol (ARP)

Link-local address assignment

Rapid spanning tree protocol (RSTP)

IP datagram routing

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

6.1

6.2

6.3

6.4

6.5

B3 Isochronous operations

MPLS initialization

Isochronous path management

Ingress and egress port isochronous operations

Common Isochronous Packet (CIP) header transformations

Cycle time synchronization

Network time

Mandatory

Optional

Optional

Optional

Optional

Optional

7.1

7.2

7.3.1, 7.3.2

7.3.4

7.4

7.5

B4 a Expedited FCP (XFCP) operations Optional 8

a An L3 IP bridge that implements the optional features of feature block B3, isochronous operations, shall also

implement feature blocks B1 and B4 in their entirety.

Some of the clauses referenced in Table C-1 include, by inheritance, subsidiary clauses particular to IEEE 1394 or

coaxial cable ports. The implementation requirements for such clauses are specified by Table C-2 or Table C-3, as

appropriate.

In addition to the basic requirements of Table C-1, an L3 IP bridge IEEE 1394 port shall conform to Table C-2.



Table C-2 – L3 IP bridge IEEE 1394 port conformance requirements

An L3 IP bridge IEEE 1394 port that implements feature block SB4, isochronous operations, shall set the isc bit in

its configuration ROM bus information block to one.

In addition to the base requirements of Table C-1, an L3 IP bridge coaxial cable port shall conform to Table C-3.

Table C-3 – L3 IP bridge coaxial cable port conformance requirements


CX1 Minimum DEV capabilities for L3 IP bridge coaxial cable ports Mandatory Annex B

CX2 c Data and message formats

MSDU header

RTTM command frames

Expedited FCP data unit (XFC PDU)

Mandatory

Optional

Optional

5.5

5.6

5.9

CX3 Internet protocol operations


Mandatory

6.2.2

CX4 c Isochronous operations


Optional

7.4.2

CX5 c Expedited FCP (XFCP) operations Optional 8

c The coaxial cable port of an L3 IP bridge that implements the optional features of feature block B3, isochronous

operations, shall also implement feature blocks CX2, CX4 and CX5 in their entirety.


SB1 Minimum node capabilities for L3 IP bridge IEEE 1394 ports Mandatory Annex A

SB2 b Data and message formats

Cycle master adjustment packet

Optional

5.4

SB3 Internet protocol operations

IPv4 over IEEE 1394

IEEE 1394 DHCP client operations


Mandatory

Mandatory

Mandatory

[R13]

6.1.1

6.2.1

SB4 b Isochronous operations


BUS_TIME and CYCLE_TIME register modifications

Optional

Optional

7.4.1

7.5.2

b The IEEE 1394 port of an L3 IP bridge that implements the optional features of feature block B3, isochronous

operations, shall also implement feature blocks SB2 and SB4 in their entirety.



Annex D

(normative)

Assigned numbers

This specification uses assigned numbers generated from the 1394 Trade Association Organizationally Unique

Identifier (OUI), whose 24-bit value is 00A02D16. The table below summarizes information for all assigned numbers

used within this document; consult the reference citation for more detail:

Type Value Reference Description

CDI-32™ 00A02D0016 5.2.6 Within the context of [R17], this number identifies

Vendor-private Messages defined by this specification.

CDI-40™ 00A02D010016

00A02D010116

5.6 Command Types for IEEE 802.15.3 vendor-specific

command frames used for RTTM.

EUI-48™ 00A0 2D20000016 Annex A Within the context of [B4], this number (Specifier_ID

concatenated with Version) identifies an L3 IP bridge

IEEE 1394 port that conforms to this specification.

CDI-32™, CDI-40™ and EUI-48™ are trademarks of the IEEE Standards Association. Tutorials on their use are

available at http://standards.ieee.org/regauth/oui/tutorials/CDI32.html.

http://standards.ieee.org/regauth/oui/tutorials/CDI32.html



Annex E

(normative)

Pseudocode constants, data structures and utility functions

Throughout this specification, C-like pseudocode is employed to permit more accurate specification of behaviors

than is otherwise afforded by simple narration. Many of the variables used are defined and described in the functions

themselves, but others are globally accessible to any functional block within a node. The definitions of those data

structures and constants are gathered in this annex for convenience of reference.

E.1 Configuration ROM and control and status registers

When reference is made to the formal name of a CSR as specified by IEEE 1394 or this specification, for example

BANDWIDTH_AVAILABLE, it shall be understood to mean the base address of the CSR within the node’s memory

space. Thus, BANDWIDTH_AVAILABLE represents a value of FFFF F000 022016. When it is necessary to refer to

the current value of a CSR at the node itself, the formal name of the CSR is transformed into a similar name that is

applied to a pseudocode variable or data structure, as set out in Table E-1. Only those CSRs referenced in the

pseudocode are included.

Table E-1 – Configuration ROM and CSR data structures and constants

/* Configuration ROM */ struct { /* Bus information block */ BYTE busName[4]; /* ASCII "1394" for IEEE 1394 */ struct { BOOLEAN irmc:1; BOOLEAN cmc:1; BOOLEAN isc:1; BOOLEAN bmc:1; BOOLEAN pmc:1; BOOLEAN adjustable:1; BYTE reserved:2; } capabilities; BYTE cycleClkAcc; BYTE maxRec:4; BYTE reserved:2; BYTE maxROM:2; BYTE generation:4; BOOLEAN bridgeAware:1; BYTE linkSpd:2; OCTLET eui64; } busInfoBlock; struct { /* Bridge_Capabilities entry */ BYTE key; BYTE reserved:2; BYTE maxIsoch:4; BYTE streams:6; DOUBLET latency:12; } bridgeCapabilities; /* CSR definitions */ struct { /* STATE_SET register (0xFFFFF0000004)*/ BYTE cmstr:1; } stateSet; typedef struct { /* CYCLE_TIME register (0xFFFFF0000200) */ QUADLET secondsCount:7; /* Least significant portion of BUS_TIME.secondsCount */ QUADLET cycleCount:13; /* Cycles (1/8000 second) count */ QUADLET cycleOffset:12; /* Ticks of 24.576 MHz clock (nominal 40 ns) */ } CYCLE_TIME; CYCLE_TIME cycleTime;



#define CYCLE_TICK 40690 /* Interval between ticks, in picoseconds */ UNSIGNED cycleOffsetThreshold; /* Initialized to 3071 for nominal 125 us interval */ typedef union { /* BUS_TIME register (0xFFFFF0000204) */ QUADLET secondsCount; struct { QUADLET secondsCountHi:25; QUADLET secondsCountLo:7; }; } BUS_TIME; BUS_TIME busTime; /* PCR addresses and definitions */ #define OMPR 0xFFFFF0000900 #define OPCR 0xFFFFF0000904 #define IMPR 0xFFFFF0000980 #define IPCR 0xFFFFF0000984 typedef struct { /* Output master plug register (oMPR 0xFFFFF0000900) */ BYTE spd:2; BYTE broadcastBase:6; BYTE nonpersistentExt; BYTE persistentExt; BYTE reserved:1; BYTE xspd:2; BYTE outputPlugs:5; } OMPR_CSR; OMPR_CSR oMPR; typedef struct { /* Output plug control register (oPCR 0xFFFFF0000904) */ BYTE online:1; BYTE broadcastConnection:1; BYTE pointToPointConnections:6; BYTE xspd:2; BYTE channel:6; BYTE spd:2; BYTE overhead:4; DOUBLET payload:10; } OPCR_CSR; OPCR_CSR oPCR; typedef struct { /* Input master plug register (iMPR 0xFFFFF0000980) */ BYTE spd:2; BYTE reserved1:6; BYTE nonpersistentExt; BYTE persistentExt; BYTE reserved2:1; BYTE xspd:2; BYTE inputPlugs:5; } IMPR_CSR; IMPR_CSR iMPR; typedef struct { /* Input plug control register (iPCR 0xFFFFF0000984) */ BYTE online:1; BYTE broadcastConnection:1; BYTE pointToPointConnections:6; BYTE xspd:2; BYTE channel:6; BYTE spd:2; BYTE overhead:4; QUADLET payload:10; } IPCR_CSR; IPCR_CSR iPCR;



E.2 Global port variables and external procedures

Common constant and type definitions, global bridge port variables and external procedures are contained in

Table E-2.

Table E-2 – Constants, global port variables and external procedures

/* Useful preprocessor macros */ #define LAST(array) ((sizeof(array) / sizeof(array[0])) - 1) #define MAX(x, y) (((x) > (y)) ? (x) : (y)) #define MIN(x, y) (((x) < (y)) ? (x) : (y)) /* Common constants and type definitions */ #define BEACON_EVENT_DELAY 0 /* Delay, in units of 40.69 ns, from superframe start ... */ /* ... to MLME-BEACON-EVENT.indication (nonzero in real life) */ #define ALL_SUBNET_ROUTERS 0xE0000002 /* Multicast address 224.0.0.2 */ #define MAX_BRIDGES 8 /* IMPLEMENTATION-DEPENDENT: Maximum bridges in a piconet */ #define MAX_LEGACY 8 /* IMPLEMENTATION-DEPENDENT: Maximum concurrentlylegacy controllers */ #define MAX_LOST_BEACONS 4 #define MAX_STREAMS 64 /* IMPLEMENTATION-DEPENDENT: Report this value in configuration ROM */ #define NO_ACK 2 /* Acknowledgment policy for multicast */ #define UNASSIGNED 0xFF /* Link stream ID not yet assigned */ #define DEFAULT_BROADCAST_CHANNEL 31 #define DOWNSTREAM 0 #define UPSTREAM 1 typedef struct { OCTLET eui64; /* Permit detection of endpoint disconnection */ OCTLET surrogateEUI64; /* If nonzero, endpoint represented by a surrogate */ QUADLET address; /* IPv4 address of the endpoint */ QUADLET lifetime; /* Limit this stream branch's lifetime in case controller disconnects */ BYTE plug; /* PCR index for sink or source plug */ BOOLEAN sink; /* Differentiate sinks from sources */ BOOLEAN legacyCMP; /* If TRUE, legacy controller manages endpoint's PCR */ } ENDPOINT_INFO; typedef struct { /* Forwarding equivalence class (FEC) */ OCTLET sourceEUI64; /* Uniquely identifies stream (together with sourcePlug) */ BYTE sourcePlug; } FEC; typedef union { DOUBLET nodeID; struct { DOUBLET busID:10; BYTE phyID:6; }; } NODE_ID; typedef struct { OCTLET ownEUI64; /* Also MAC address in IEEE 802.15.3 parlance */ enum {IEEE_1394=0, /* Link medium for this interface */ CABLE=1} portType; enum {subordinate=0, /* Port's function in the distribution of CYCLE_TIME phase lock */ alpha=1, prime=2} cycleTimeRole; union { BYTE ownDEVID; /* For cable ports, assigned by PNC */ struct { BYTE ownPhyID; /* Our own PHY ID from NODE_IDS.phyID */ BYTE ownSpeed; /* Slower of our own link or PHY speed */ }; }; } PORT_INFO; typedef struct path_info { PORT_INFO *port; /* Interface for which the path information is valid */ BYTE localSinks; /* Count of sinks, bridge or endpoint, for this stream and port */ union { BYTE linkStreamID; /* Channel or Stream Index, dependent upon context */ BYTE channel; /* For resource reallocation after bus reset */



BYTE streamIndex; /* PNC-assigned upstream or downstream Stream Index */ }; enum {S100=0, /* For IEEE 1394, only, TX speed for egress ports */ S200=1, S400=2, S800=3, S1600=4, S3200=5} speed; BYTE reserved1; DOUBLET latency; /* Accumulated transmission delay from route to adjacent nodes/DEVs*/ DOUBLET reserved2; union { QUADLET gatewayAddress[MAX_BRIDGES]; struct { /* Elements pertinent to IEEE 1394 ports */ QUADLET bandwidth; /* For resource reallocation after bus reset */ ENDPOINT_INFO endpoint[63]; }; }; } PATH_INFO; typedef struct { PORT_INFO *port; /* Interface for which the route information is valid */ QUADLET hostAddress; /* Host IP address routed through the interface */ QUADLET gatewayAddress; /* If nonzero, next hop IP address en route to host */ } ROUTE_INFO; typedef struct { DOUBLET maxPayload; /* Maximum data payload isochronous SDU, in bytes */ DOUBLET latency; /* Accumulated delay from endpoint source to ingress port */ DOUBLET window; /* Size of smoothing window, in units of 125 µs */ DOUBLET aggregatePayload; /* Maximum aggregate data payload during any smoothing window */ DOUBLET sourceQuantum; /* Smallest quantity of source data in a single isochronous SDU, in bytes */ QUADLET sourceBitRate; /* Source data rate, in b/s */ } STREAM_PARMS; typedef struct { union { FEC streamID; /* Unique stream root identifier */ struct { /* Individual components of stream ID */ OCTLET sourceEUI64; BYTE sourcePlug; }; }; union { STREAM_PARMS streamParms; /* See definitions above */ struct { DOUBLET maxPayload; DOUBLET latency; DOUBLET window; DOUBLET aggregatePayload; DOUBLET sourceQuantum; QUADLET sourceBitRate; }; }; PATH_INFO upstreamPath; /* Receives data from the stream's source device */ PATH_INFO downstreamPath; /* Transmits data from the stream's source device */ } STREAM_INFO; /* Global bridge port variables */ PORT_INFO cablePort; /* Coaxial cable port information */ PORT_INFO ieee1394Port; /* IEEE 1394 port information */ BYTE cycleTimeID; /* DEVID associated with group address 0x00A02D */ DOUBLET downstreamDelay; /* Propagation delay from cycle master to bridge port */ QUADLET messageID; /* Unique LDP message identifier */ STREAM_INFO streamDescr[MAX_STREAMS]; /* Maximum concurrently active streams for this bridge */ DOUBLET superframeDuration; /* Duration of the piconet's superframe, in microseconds */ /* External procedures */ BOOLEAN allocateBandwidth(QUADLET bandwidth); BYTE allocateChannel(BYTE channel); ENDPOINT_INFO *allocateEndpointDescriptor(PATH_INFO *path); QUADLET *allocateGatewayDescriptor(PATH_INFO *path); PATH_INFO *allocatePathDescriptor(); BOOLEAN allocateResources(PATH_INFO *path, DOUBLET maxPayload, BYTE speed);



STREAM_INFO *allocateStreamDescriptor(); BYTE assignInputPlug(PORT_INFO *port); BYTE assignOutputPlug(PORT_INFO *port); BOOLEAN createStream(PATH_INFO *path, STREAM_PARMS *streamParms); VOID deallocateBandwidth(QUADLET bandwidth); VOID deallocateChannel(BYTE channel); VOID deallocateEndpointDescriptor(ENDPOINT_INFO *endpoint); VOID deallocateGatewayDescriptor(PATH_INFO *path, QUADLET *gatewayAddress); VOID deallocatePathDescriptor(PATH_INFO *path); VOID deallocateResources(PATH_INFO *path); VOID deallocateStreamDescriptor(VOID *stream); VOID deletePathInfo(STREAM_INFO *stream, PATH_INFO *path); QUADLET getGatewayAddress(OCTLET mac64); ROUTE_INFO *getRoute(QUADLET ipAddress); ENDPOINT_INFO *findEndpointDescriptor(PATH_INFO *path, OCTLET eui64); QUADLET *findGatewayDescriptor(PATH_INFO *path, QUADLET gatewayAddress); PATH_INFO *findPathDescriptor(STREAM_INFO *stream, PORT_INFO *port); STREAM_INFO *findStreamDescriptor(FEC streamID); VOID multicastTeardownMsg(FEC streamID, ENDPOINT_INFO *sourceEndpoint, ENDPOINT_INFO *sinkEndpoint); DOUBLET nodeID(OCTLET eui64); QUADLET pathEndpoint(VOID *pathMappingMsg, ROUTE_INFO *controllerRoute, ROUTE_INFO *sinkRoute, ROUTE_INFO *sourceRoute); QUADLET pathMapping(VOID *pathMappingMsg, ROUTE_INFO *sinkRoute, ROUTE_INFO *sourceRoute); QUADLET pathRequest(VOID *pathRequestMsg, ROUTE_INFO *sinkRoute, ROUTE_INFO *sourceRoute); QUADLET pathTeardown(VOID *pathTeardownMsg, ROUTE_INFO *sinkRoute, ROUTE_INFO *sourceRoute); BYTE pathSpeed(PORT_INFO *port, BYTE phyID1, BYTE phyID2); INT pop(); VOID programInputPlug(PORT_INFO *port, BYTE phyID, BYTE plugIndex, IPCR_CSR data); VOID programOutputPlug(PORT_INFO *port, BYTE phyID, BYTE plugIndex, OPCR_CSR data); VOID push(INT phyID); IMPR_CSR readInputMasterPlug(PORT_INFO *port, BYTE phyID); IPCR_CSR readInputPlug(PORT_INFO *port, BYTE phyID, BYTE plugIndex); OMPR_CSR readOutputMasterPlug(PORT_INFO *port, BYTE phyID); OPCR_CSR readOutputPlug(PORT_INFO *port, BYTE phyID, BYTE plugIndex); VOID releaseInputPlug(BYTE plug); VOID releaseOutputPlug(BYTE plug); VOID resetBus(); BOOLEAN streamOverlayOK(PATH_INFO *path, STREAM_PARMS *streamParms); BOOLEAN terminateStream(PATH_INFO *path); VOID txNotificationMsg(QUADLET ipAddress, QUADLET messageID, DOUBLET messageType, QUADLET status); VOID txTeardownMsg(FEC streamID, QUADLET gatewayAddress, BOOLEAN upstream); VOID txLDPDatagram(PORT_INFO *port, QUADLET ipAddress, VOID *message);

E.3 Message and packet formats

The data structures for cycle time and path management messages are contained in Table E-3.

Table E-3 – Message data structures and constants

typedef struct { /* Multicast by alpha coaxial cable port once per superframe */ BUS_TIME busTime; /* Samples of alpha port's BUS_TIME and ... */ CYCLE_TIME cycleTime; /* ... CYCLE_TIME registers as of the start of the PHY preamble for ... */ DOUBLET beaconNumber; /* ... the superframe identified by this beacon number */ } CYCLE_TIME_MSG; typedef struct { enum {NOTIFICATION=0x3E44, PATH_REQUEST=0x3E40, PATH_MAPPING=0x3E41, PATH_TEARDOWN=0x3E42, PATH_ENDPOINT=0x3E43, TIME_OFFSET=0x3E50} messageType; DOUBLET messageLength; QUADLET messageID; } LDP_MSG_HDR; typedef struct { enum {STATUS_TLV=0x400, PATH_TLV=0x3E00} type; DOUBLET length; } TLV_HDR; typedef struct {



LDP_MSG_HDR; QUADLET companyID:24; BYTE version; TLV_HDR pathTLV; union { /* IPv4 address of the FCP/IP-capable device that issued the message*/ QUADLET controllerAddress; QUADLET relayAgentAddress; }; QUADLET sinkAddress; /* IPv4 address of either the sink or its AV/C relay agent */ QUADLET sourceAddress; /* IPv4 address of either the source or its AV/C relay agent */ OCTLET controllerEUI64; OCTLET relayAgentEUI64; OCTLET sinkEUI64; union { FEC streamID; /* Unique stream root identifier */ struct { /* Individual components of stream ID */ OCTLET sourceEUI64; BYTE sourcePlug; BYTE sinkPlug; }; }; union { STREAM_PARMS streamParms; /* See definitions above */ struct { DOUBLET maxPayload; DOUBLET latency; DOUBLET window; DOUBLET aggregatePayload; DOUBLET sourceQuantum; QUADLET sourceBitRate; }; }; union { struct { BYTE linkStreamID; BYTE reserved:3; BOOLEAN legacyCMP; BOOLEAN sinkSurrogate:1; BYTE cycleSyncError:1; BOOLEAN upstream:1; }; QUADLET lifetime:17; }; } PATH_MSG; typedef struct { LDP_MSG_HDR; TLV_HDR statusTLV; QUADLET peerMessageID; enum {INVALID_PLUG=0xBF003E00, ORRPHAN_SURROGATE=0xBF003E06, PAYLOAD_TOO_BIG=0xBF003E03, RESOURCES_UNAVAILABLE=0xBF003E02, INVALID_ROUTE=0xBF003E01, UNEXPECTED_ERROR=0xBF003EFF, INVALID_STREAM=0xBF003E05, STREAM_CONFLICT=0xBF003E04} status; DOUBLET peerMessageType; DOUBLET latency; QUADLET reserved:15; QUADLET lifetime:17; } NOTIFICATION_MSG; #define OK ((QUADLET) 0) #define PENDING ((QUADLET) 0xFFFFFFFF) typedef struct { LDP_MSG_HDR; TLV_HDR timeOffsetTLV; OCTLET deltaCycles; /* Cumulative time difference between two buses */ } TIME_OFFSET_MSG;



E.4 Data structure utility functions

Utility functions for routine data structure ―housekeeping‖ (allocation, deallocation, search, etc.) are contained in

Table E-4.

Table E-4 – Data structure utility functions

#include "csr.h" #include "global.h" #include "packets.h" ENDPOINT_INFO *allocateEndpointDescriptor(PATH_INFO *path) { INT i; for (i = 0; i <= LAST(path->endpoint); i++) if (path->endpoint[i].eui64 == 0) return(&path->endpoint[i]); return(NULL); } STREAM_INFO *allocateStreamDescriptor() { UNSIGNED i; for (i = 0; i <= LAST(streamDescr); i++) /* Search for free stream descriptor */ if (streamDescr[i].sourceEUI64 == 0) { streamDescr[i].upstreamPath.linkStreamID = UNASSIGNED; streamDescr[i].downstreamPath.linkStreamID = UNASSIGNED; return(&streamDescr[i]); } return(NULL); /* No stream descriptor available */ } VOID deallocateEndpointDescriptor(ENDPOINT_INFO *endpoint) { memset(endpoint, 0, sizeof(endpoint)); /* Mark endpoint descriptor available */ } VOID deallocateStreamDescriptor(STREAM_INFO *stream) { memset(stream, 0, sizeof(stream)); /* Mark stream descriptor available */ } ENDPOINT_INFO *findEndpointDescriptor(PATH_INFO *path, OCTLET eui64) { INT i; for (i = 0; i <= LAST(path->endpoint); i++) if (path->endpoint[i].eui64 == eui64 || path->endpoint[i].surrogateEUI64 == eui64) return(&path->endpoint[i]); return(NULL); } STREAM_INFO *findStreamDescriptor(FEC streamID) { INT i; for (i = 0; i <= LAST(streamDescr); i++) if (memcmp(&streamDescr[i].streamID, &streamID, sizeof(streamID)) == 0) return(&streamDescr[i]); return(NULL); }



Annex F

(informative)

Message sequence charts (MSCs) for path management operations

Message sequence charts are frequently used to clarify sequence relationships in the exchange of messages between

two or more agents. [B12] formally specifies MSC, which consists of two parts: graphic symbols and an

accompanying systems definition language (SDL). This annex loosely adopts—and adapts—MSC graphic notation

to illustrate the nominal sequence of events for common path management operations.

Figure F-1 – Path setup operations

NOTE – The MSC above uses a simple, two-hop topology to illustrate path management operations. Other topologies

might be feasible but are beyond the scope of this specification.

Isochronous connection set up begins when a controller (e.g., an HDTV) initializes and transmits a PATH REQUEST

message that specifies a source device (a DVD player) and a sink device (the HDTV itself).17

The message is

initialized as specified by 5.2.6 and multicast as an IP datagram to all subnet routers’ well-known LDP port 346.

17 Because sink devices often possess a display—hence a relatively rich user interface capability—it is common for controller

functionality to be co-located within a sink device.

Program oPCR

Path

Mgt Link

HDTV 169.254.187.39

Allocate bandwidth and channel

MLME-CREATE-STREAM

MAC

PNC

Link

IRM

MAC

L3 IP Bridge Path

Mgt Link Path

Mgt Link

DVD 169.254.163.218

MAC

L3 IP Bridge Path

Mgt Link Link

IRM

Allocate bandwidth and channel

PATH REQUEST 224.0.0.2

PATH REQUEST 169.254.54.174

PATH MAPPING 169.254.178.129

NOTIFICATION 169.254.237.39

Program iPCR



Upon receipt of the PATH REQUEST message, only the bridge with a port that connects directly to the sink device

processes the message. First, the bridge attempts to allocate a channel number and bandwidth from the IEEE 1394

isochronous resource manager. If both allocations succeed, the information is entered into the bridge's label-

information base (LIB) and the PATH REQUEST is transmitted to the upstream bridge en route to the source device.

Receipt of the PATH REQUEST message causes the upstream bridge to request the coaxial cable piconet controller

(PNC) to create an isochronous stream; the MLME-CREATE-STREAM parameters are derived from the information

in the PATH REQUEST message. If the PNC creates the stream, the bridge records the Stream Index in its LIB and

checks the isochronous resource allocation status within the source device's cluster. If the source device's output plug

control register (oPCR) indicates that isochronous resources have yet to be allocated, the bridge attempts to allocate

channel number and bandwidth from the isochronous resource manager. If successful, the bridge programs the source

device's oPCR with the channel number and bandwidth acquired, programs its own iPCR with the channel number

and then increments the point-to-point connection counters of both plug control registers in order to establish a

connection. At this point, the necessary resources have been allocated for the stream’s entire path.

All that remains to complete path setup is to distribute the ―labels‖ (channel number for IEEE 1394 and Stream

Index for coaxial cable) that identify the stream in each segment. The bridge adjacent to the source device generates

a PATH MAPPING message (see 5.2.6) for transmission to the bridge adjacent to the sink device. The message

contains the Stream Index that identifies the stream within the piconet. The PATH MAPPING message is

encapsulated as an IP datagram addressed to the adjacent downstream bridge. When the bridge receives the PATH

MAPPING message, it updates its LIB with the association between unique stream identifier and Stream Index.

Finally, the bridge programs the sink device's iPCR with the channel number used by the stream within the IEEE

1394 cluster and increments the point-to-point connection counters of its own oPCR and the sink's iPCR. Finally, the

bridge transmits a Status TLV NOTIFICATION message to the controller to confirm the path's successful setup.

Figure F-2 – Path teardown operations

NOTIFICATION 169.254.187.39

Path

Mgt Link

HDTV 169.254.187.39

Release bandwidth and channel

MAC

PNC

Link

IRM

MAC

L3 IP Bridge Path

Mgt Link Path

Mgt Link

DVD 169.254.163.218

MAC

L3 IP Bridge Path

Mgt Link Link

IRM

PATH TEARDOWN 224.0.0.2

Program oPCR

MLME-TERMINATE-STREAM

Release bandwidth and channel

Program IPCR

PATH TEARDOWN 19.254.54.174



Isochronous connection teardown begins when a controller (e.g., an HDTV) initializes and transmits a PATH

TEARDOWN message that identifies a sink device (e.g., the HDTV itself) and a source device (e.g., a DVD player)

for which the controller previously establish the connection. The PATH TEARDOWN message is initialized as

specified by 5.2.6 and multicast as an IP datagram to all subnet routers, well-known LDP port 346. L3 IP bridges

ignore all multicast PATH TEARDOWN messages unless their IEEE 1394 port connects to the cluster that contains

the sink device. Upon receipt of the PATH TEARDOWN message, the bridge decrements the point-to-point

connection counters of the sink device's iPCR and the bridge's oPCR. If the bridge’s point-to-point connection

counter is nonzero, other nodes are still utilizing the stream and it cannot be terminated for the cluster. In this

example, however, the HDTV is assumed the only listener for the stream. The bridge releases the channel number

and bandwidth allocated during path setup. The appropriate entries in the bridge's LIB are cleared and the PATH

TEARDOWN is transmitted to the next upstream bridge. Receipt of the PATH TEARDOWN message causes the

bridge to delete the path to the downstream bridge. If no other downstream coaxial cable bridges are listening to the

stream, the bridge uses MLME-TERMINATE-STREAM to release the piconet resources reserved for the stream and

updates its LIB accordingly. Since (in this example) no downstream listeners remain, the bridge programs the source

device's oPCR and the bridge's own iPCR to render them inactive before it releases the channel number and

bandwidth that had been in use. Path teardown is complete and the bridge transmits a Status TLV NOTIFICATION

message to the controller that originated the PATH TEARDOWN MESSAGE.



Annex G (informative)

Message sequence chart (MSC) for expedited FCP (XFCP) operations

Figure G-1 – Expedited path for RTT TEST command and ACCEPTED response

Beacon

1394

Source

1394

Sink

Coax 1394

L3 IP Bridge

Compute MAC1B, MAC2B

XFC PDU Data Frame ACCEPTED [nonce]

Imm-ACK

FCP Response Frame ACCEPTED [nonce]

ack_complete

Compute MAC1A, MAC2A

FCP Command Frame RTT SETUP [nonce]

ack_complete

Challenge-Response portion of AKE completed; RTT READY commands and responses exchanged

1394 Coax

L3 IP Bridge

Create stream

resp_complete

FCP Command Frame RTT SETUP [nonce]

Imm-ACK

XFC PDU Data Frame RTT SETUP [nonce]

ack_complete

ack_complete

resp_complete

FCP Command Frame RTT TEST[MAC1A]

FCP Response Frame ACCEPTED [MAC2B]

FCP Command Frame RTT TEST[MAC1A]

Me

asu

red

RT

T

XFC PDU Data Frame RTT TEST [MAC1A]

Execute RTT TEST

resp_complete

FCP Response Frame ACCEPTED[MAC2B]

Terminate stream

resp_complete

FCP Response Frame ACCEPTED[nonce]

Initiate RTT TEST

Lead-time

Stream CTA

Imm-ACK

Command Frame RTTM Rq [ENABLE]

Command Frame RTTM Rsp [SUCCESS]

Imm-ACK

Imm-ACK

Command Frame RTTM Rq [DISABLE]

Command Frame RTTM Rsp [SUCCESS]

Imm-ACK

XFC PDU Data Frame ACCEPTED [MAC2B]

Imm-ACK



The MSC in Figure G-1 excerpts the relevant portion of the AKE and round-trip timing command and response

exchange between DTCP-conformant source and sink devices; it shows in detail only that part of the exchange

necessary for a single attempt at round-trip time measurement. The sequence starts when the source device selects a

nonce from which it calculates two cryptographic message authentication codes, MAC1A and MAC2A, and then

transmits the nonce to the sink device via an RTT SETUP command. The sink device in turn calculates message

authentication codes MAC1B and MAC2B before transmitting an ACCEPTED response that contains the nonce back

to the source device. The RTT SETUP command frame is addressed to the XFCP command register associated with

the sink device, i.e. the XFCP command register located at unicast_FIFO + 4096 in the source-adjacent bridge's

address space, where unicast_FIFO is part of the sink device's hardware address, as provided by the source-adjacent

bridge in an earlier ARP response transmitted on behalf of the sink device. The ACCEPTED response frame is

addressed to the XFCP response register located at FFFF F000 0D0016 in the sink-adjacent bridge's address space.

The L3 IP bridges inspect all command and response frames as they pass through. A bridge silently discards FCP

command or response frames if they contain an AV/C command that is not eligible for XFCP, i.e. not one of the

commands used for AKE and localization.

When the source-adjacent bridge receives an eligible FCP command frame, the bridge encapsulates the command

frame as an XFC PDU and transmits it as a data frame to the bridge that routes traffic for the sink device. If the FCP

command frame contains an RTT SETUP command, the bridge uses MLME-RTTM.request to obtain a contiguous

channel time allocation in the approximate range of 2 ms to 7 ms and to transmit a vendor-specific request command

frame that instructs the sink-adjacent bridge to enable RTTM. Once the PNC responds that the CTA will appear in

the next superframe, the source-adjacent bridge awaits receipt of the XFC PDU that contains the ACCEPTED

response frame that completes the RTT SETUP transaction.

NOTE – Although conservative implementations might request the PNC to allocate 7 ms in a single CTA, empirical results

might permit its reduction. Heuristics to adjust for transient conditions, e.g., heavily congested conditions within the source

or sink devices' IEEE 1394 clusters, might also be possible.

When the sink-adjacent bridge receives an XFC PDU that contains an RTT SETUP command, RTTM is not yet

active. The sink-adjacent bridge simply extracts the RTT SETUP command frame from the XFC PDU, derives the

sink device's IEEE 1394 node ID from its IP address and writes the FCP command frame to the device's FCP

command register. The sink device executes the RTT SETUP command and writes an ACCEPTED response frame to

the bridge's FCP response register. Because all FCP response frames are written to the same XFCP register, the sink-

adjacent bridge uses information saved from the immediately prior command frame XFC PDU to correlate the sink

device's IP address with the IP address of the source device to which the response should be transmitted. Once this

lookup is complete, the bridge encapsulates the response frame as an XFC PDU and transmits it as a data frame to

the bridge that routes traffic for the source device.

Stream creation by the source-adjacent bridge has proceeded in parallel with RTT SETUP command execution by

the sink device. By the time the source-adjacent bridge receives the XFC PDU that contains the ACCEPTED

response, the PNC has probably created the stream. If not, the bridge awaits its creation.

Two conditions must be met before the source-adjacent bridge MLME can confirm to its bridge entity that RTTM is

enabled: a) the source-adjacent bridge has received the ACCEPTED response that corresponds to the RTT SETUP

command18

and b) a stream has been created, whose single CTA, sometime in the next superframe, can be used to

minimize transmission latency between the source device and the sink device. In order to make use of the anticipated

CTA, the source-adjacent bridge enters ―round-trip timing mode‖ (RTTM)

RTTM is an implementation-dependent operational mode that affects both the bridge entity and the MAC. While it is

active, the MAC affords highest priority and lowest latency to data frames transmitted or received via the

isochronous stream created by the source-adjacent bridge. The bridge entity, for its part, uses MAC-ISOCH-DATA to

18 By inference, both the source device and the sink device have completed the time-consuming calculation of message

authentication codes and therefore are ready to promptly execute a round-trip timing exchange



transmit, via the stream created by the source-adjacent bridge, those command frame XFC PDUs originated by the

source device and those response frame XFC PDUs originated by the sink device.

The earliest the requested CTA can become available is the next superframe. The source-adjacent bridge waits for a

beacon that announces the desired CTA.

In order to take maximal advantage of the CTA and complete the entire RTT TEST transaction within its duration,

the source-adjacent bridge attempts to manage the behavior of the source device so that the RTT TEST command

frame is received by the bridge as close as possible to the start of the CTA. The bridge attempts this coordination by

―pocketing‖ the ACCEPTED response frame from the sink device and not transmitting it to the source device until

some implementation-dependent lead-time before the start of the CTA. The lead-time should be chosen to reflect

processing delays within the bridge, IEEE 1394 arbitration delays for both the bridge's IEEE 1394 port and the sink

device and processing delays within the sink device between the time it receives the ACCEPTED response frame and

the time it transmits the RTT TEST command frame.

NOTE – Although the estimation of lead-time is implementation-dependent, the source-adjacent bridge might incorporate

heuristics that respond to an extraordinarily slow or fast source device or to congestion within the IEEE 1394 cluster. If the

MAC's receipt of the RTT TEST XFC PDU precedes the start of the CTA, lead-time could be shortened by the same

number of microseconds the next time RTTM is activated. A similar heuristic could be applied to the duration of the CTA,

which could be lengthened if the sink device's ACCEPTED XFC PDU was queued for transmission after the CTA

terminated.

If timing alignment works as anticipated, the source-adjacent bridge should receive the RTT TEST command frame

shortly after the CTA has commenced and should be able to transmit it to the sink-adjacent bridge with effectively

zero latency. Since RTTM is active, the bridge uses MAC-ISOCH-DATA to queue the RTT TEST XFC PDU for

transmission; the MAC transmits the data frame with an ACK policy type of Imp-ACK. Implied acknowledgment

policy permits the sink-adjacent bridge to transmit the ACCEPTED XFC PDU during the same CTA.

When the sink-adjacent bridge receives the RTT TEST XFC PDU, it immediately extracts the RTT TEST command

frame and writes it to the sink device's FCP command register. Shortly thereafter, the sink device transmits its

ACCEPTED response frame to the sink-adjacent bridge's XFCP response register. The bridge encapsulates the

response frame within an XFC PDU and uses MAC-ISOCH-DATA to queue it for transmission to the source-

adjacent bridge.

Upon receipt of the XFC PDU that contains the ACCEPTED response frame, the source-adjacent bridge

immediately writes the FCP response frame to the source device's FCP response register. Next, the bridge deactivates

RTTM and uses the MLME-RTTM.request service primitive to take its MAC out of RTTM. The request also causes

the MAC to transmit a vendor-specific request command frame to the sink-adjacent bridge, which causes its MAC

and bridge entity to disable RTTM.

If the source device measures a round-trip time is less than or equal to 7 ms, it may register the sink device,

otherwise, round-trip time may be measured again with a different nonce (up to 1024 attempts are permitted to obtain

a round-trip time of less than or equal to 7 ms).



Annex H (informative)

Bibliography

[B1] 1394 Trade Association, Networking IEEE 1394 Clusters via UWB over Coaxial Cable—Part 3: FCP and

CMP over IPv4

[B2] Digital Transmission Licensing Administrator, Digital Transmission Content Protection Specification—

Volume 1 (Informational Version), Revision 1.2a, February 25, 2002

[B3] IEC 61883-4 (2004-08), Consumer audio/video equipment—Digital interface—Part 4: MPEG2-TS data

transmission

[B4] IEEE Std 1212-2001, Standard for a Control and Status Registers (CSR) Architecture for microcomputer

buses

[B5] IETF RFC 768, User Datagram Protocol, August 1980

[B6] IETF RFC 793, Transmission Control Protocol, September 1981

[B7] IETF RFC 951, Bootstrap Protocol (BOOTP), September 1985

[B8] IETF RFC 1533, DHCP Options and BOOTP Vendor Extensions, October 1993

[B9] IETF RFC 1542, Clarifications and Extensions for the Bootstrap Protocol, October 1993

[B10] IETF RFC 4436, Detecting Network Attachment in IPv4 (DNAv4), March 2006

[B11] ISO/IEC 9899:1999, Programming Languages—C

[B12] ITU-T Recommendation Z.120 (2004-04), Message sequence chart (MSC)