DVJ Perspective On: Timing and Synchronization for Time-Sensitive

JggDvj2005Apr16 1 March 5, 2007 2 3 4 5 6 7 8 9 10 11 DVJ Perspective on: 12 13 Timing and synchronization for 14 15 time-sensitive applications in bridges 16 17 local area networks 18 19 20 21 Draft 0.225 22 23 Contributors: 24 See page xx. 25 26 27 28 29 Abstract: This working paper provides background and introduces possible higher level concepts 30 for the development of Audio/Video bridges (AVB). 31 Keywords: audio, visual, bridge, Ethernet, time-sensitive 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 1 JggDvj2005Apr16/D0.225 WHITE PAPER CONTRIBUTION TO March 5, 2007

1 IEEE Standards documents are developed within the IEEE Societies and the Standards Coordinating Committees of 2 the IEEE Standards Association (IEEE-SA) Standards Board. The IEEE develops its standards through a consensus 3 development process, approved by the American National Standards Institute, which brings together volunteers repre- 4 senting varied viewpoints and interests to achieve the final product. Volunteers are not necessarily members of the Insti- 5 tute and serve without compensation. While the IEEE administers the process and establishes rules to promote fairness in the consensus development process, the IEEE does not independently evaluate, test, or verify the accuracy of any of 6 the information contained in its standards. 7 8 Use of an IEEE Standard is wholly voluntary. The IEEE disclaims liability for any personal injury, property or other 9 damage, of any nature whatsoever, whether special, indirect, consequential, or compensatory, directly or indirectly 10 resulting from the publication, use of, or reliance upon this, or any other IEEE Standard document. 11 The IEEE does not warrant or represent the accuracy or content of the material contained herein, and expressly disclaims 12 any express or implied warranty, including any implied warranty of merchantability or fitness for a specific purpose, or 13 that the use of the material contained herein is free from patent infringement. IEEE Standards documents are supplied 14 “AS IS.” 15 The existence of an IEEE Standard does not imply that there are no other ways to produce, test, measure, purchase, mar- 16 ket, or provide other goods and services related to the scope of the IEEE Standard. Furthermore, the viewpoint expressed 17 at the time a standard is approved and issued is subject to change brought about through developments in the state of the 18 art and comments received from users of the standard. Every IEEE Standard is subjected to review at least every five 19 years for revision or reaffirmation. When a document is more than five years old and has not been reaffirmed, it is rea- 20 sonable to conclude that its contents, although still of some value, do not wholly reflect the present state of the art. Users are cautioned to check to determine that they have the latest edition of any IEEE Standard. 21 22 In publishing and making this document available, the IEEE is not suggesting or rendering professional or other services 23 for, or on behalf of, any person or entity. Nor is the IEEE undertaking to perform any duty owed by any other person or 24 entity to another. Any person utilizing this, and any other IEEE Standards document, should rely upon the advice of a 25 competent professional in determining the exercise of reasonable care in any given circumstances. 26 Interpretations: Occasionally questions may arise regarding the meaning of portions of standards as they relate to spe- 27 cific applications. When the need for interpretations is brought to the attention of IEEE, the Institute will initiate action 28 to prepare appropriate responses. Since IEEE Standards represent a consensus of concerned interests, it is important to 29 ensure that any interpretation has also received the concurrence of a balance of interests. For this reason, IEEE and the 30 members of its societies and Standards Coordinating Committees are not able to provide an instant response to interpretation requests except in those cases where the matter has previously received formal consideration. 31 32 Comments for revision of IEEE Standards are welcome from any interested party, regardless of membership affiliation 33 with IEEE. Suggestions for changes in documents should be in the form of a proposed change of text, together with 34 appropriate supporting comments. Comments on standards and requests for interpretations should be addressed to: 35 Secretary, IEEE-SA Standards Board 36 445 Hoes Lane 37 P.O. Box 1331 38 Piscataway, NJ 08855-1331 39 USA. 40 41 Note: Attention is called to the possibility that implementation of this standard may require use of subject matter 42 covered by patent rights. By publication of this standard, no position is taken with respect to the existence or validity 43 of any patent rights in connection therewith. The IEEE shall not be responsible for identifying patents for which a 44 license may be required by an IEEE standard or for conducting inquiries into the legal validity or scope of those 45 patents that are brought to its attention. 46 47 Authorization to photocopy portions of any individual standard for internal or personal use is granted by the Institute of 48 Electrical and Electronics Engineers, Inc., provided that the appropriate fee is paid to Copyright Clearance Center. To 49 arrange for payment of licensing fee, please contact Copyright Clearance Center, Customer Service, 222 Rosewood 50 Drive, Danvers, MA 01923 USA; (978) 750-8400. Permission to photocopy portions of any individual standard for educational classroom use can also be obtained through the Copyright Clearance Center. 51 52 53 54

Contribution from: [email protected]. 2 This is an unapproved working paper, subject to change. AVB BRIDGING JggDvj2005Apr16/D0.225 March 5, 2007

Editors’ Foreword 1 2 3 Comments on this draft are encouraged. PLEASE NOTE: All issues related to IEEE standards presen- 4 tation style, formatting, spelling, etc. should be addressed, as their presence can often obfuscate 5 relevant technical details. 6 7 By fixing these errors in early drafts, readers can devote their valuable time and energy to comments that 8 materially affect either the technical content of the document or the clarity of that technical content. 9 Comments should not simply state what is wrong, but also what might be done to fix the problem. 10 11 Information on 802.1 activities, working papers, and email distribution lists etc. can be found on the 802.1 12 Website: 13 14 http://ieee802.org/1/ 15 16 Use of the email distribution list is not presently restricted to 802.1 members, and the working group has had 17 a policy of considering ballot comments from all who are interested and willing to contribute to the devel- 18 opment of the draft. Individuals not attending meetings have helped to identify sources of misunderstanding 19 and ambiguity in past projects. Non-members are advised that the email lists exist primarily to allow the 20 members of the working group to develop standards, and are not a general forum. 21 22 Comments on this document may be sent to the 802.1 email reflector, to the editors, or to the Chairs of the 23 802.1 Working Group and Interworking Task Group. 24 25 This draft was prepared by: 26 27 David V James 28 JGG 29 3180 South Court 30 Palo Alto, CA 94306 31 +1.650.494.0926 (Tel) 32 +1.650.954.6906 (Mobile) 33 Email: [email protected] 34 35 Chairs of the 802.1 Working Group and Audio/Video Bridging Task Group:. 36 37 38 Michael Johas Teener Tony Jeffree 39 Chair, 802.1 Audio/Video Bridging Task Group Chair, 802.1 Working Group 40 Broadcom Corporation 11A Poplar Grove 41 3151 Zanker Road Sale 42 San Jose, CA Cheshire 43 95134-1933 M33 3AX 44 USA UK +1 408 922 7542 (Tel) +44 161 973 4278 (Tel) 45 +1 831 247 9666 (Mobile) +44 161 973 6534 (Fax) 46 Email:[email protected] Email: [email protected] 47 48 49 50 51 52 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 3 JggDvj2005Apr16/D0.225 WHITE PAPER CONTRIBUTION TO March 5, 2007

1 Introduction to IEEE Std 802.1AS™ 2 3 (This introduction is not part of P802.1AS, IEEE Standard for Local and metropolitan area networks— 4 Timing and synchronization for time-sensitive applications in bridged local area networks.) 5 6 This standard specifies the protocol and procedures used to ensure that the synchronization requirements are 7 met for time sensitive applications, such as audio and video, across bridged and virtual bridged local area 8 networks consisting of LAN media where the transmission delays are fixed and symmetrical; for example, 9 IEEE 802.3 full duplex links. This includes the maintenance of synchronized time during normal operation 10 and following addition, removal, or failure of network components and network reconfiguration. The design 11 is based on concepts developed within the IEEE Std 1588, and is applicable in the context of IEEE Std 12 802.1D and IEEE Std 802.1Q. 13 14 Synchronization to an externally provided timing signal (e.g., a recognized timing standard such as UTC or 15 TAI) is not part of this standard but is not precluded. 16 17 Version history 18 19 20 21 Version Date Edits by Comments 22 0.082 2005Apr28 DVJ Updates based on 2005Apr27 meeting discussions 23 24 25 0.085 2005May11 DVJ – Updated list-of-contributors, page numbering, editorial fixes. 26 27 0.088 2005Jun03 DVJ – Application latency scenarios clarified. 28 0.090 2005Jun06 DVJ – Misc. editorials in bursting and bunching annex. 29 30 0.092 2005Jun10 DVJ – Extensive cleanup of Clause 5 subscription protocols. 31 0.121 2005Jun24 DVJ – Extensive cleanup of clock-synchronization protocols. 32 33 0.127 2005Jul04 DVJ – Pacing descriptions greatly enhanced. 34 0.200 2007Jan23 DVJ Removal of non time-sync related information, initial layering proposal. 35 36 0.207 2007Feb01 DVJ Updates based on feedback from Monterey 802.1 meeting. 37 – Common entity terminology; Ethernet type code expandability. 38 0.216 2007Feb17 DVJ Updates based on feedback from Chuck Harrison: 39 – linkDelay based only on syntonization to one’s neighbor. 40 – Time adjustments based on observed grandMaster rate differences. 41 0.224 2007Mar03 DVJ Updates for whiplash free PLL cascading. 42 43 —TBD—— 44 45 46 47 48 49 50 51 52 53 54

Contribution from: [email protected]. 4 This is an unapproved working paper, subject to change. AVB BRIDGING JggDvj2005Apr16/D0.225 March 5, 2007

Formats 1 2 In many cases, readers may elect to provide contributions in the form of exact text replacements and/or 3 additions. To simplify document maintenance, contributors are requested to use the standard formats and 4 provide checklist reviews before submission. Relevant URLs are listed below: 5 General: http://grouper.ieee.org/groups/msc/WordProcessors.html 6 Templates: http://grouper.ieee.org/groups/msc/TemplateTools/FrameMaker/ 7 Checklist: http://grouper.ieee.org/groups/msc/TemplateTools/Checks2004Oct18.pdf 8 9 Topics for discussion 10 11 Readers are encouraged to provide feedback in all areas, although only the following areas have been identi- 12 fied as specific areas of concern. 13 14 a) Layering. Should be reviewed. 15 16 TBDs 17 18 Further definitions are needed in the following areas: 19 20 a) How are leap-seconds handled? 21 b) How are rate differences distributed? Avoid whiplash? 22 c) When the grand-master changes, should the new clock transition to it free-run rate instantaneously 23 or migrate there slowly over time? 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 5 JggDvj2005Apr16/D0.225 WHITE PAPER CONTRIBUTION TO March 5, 2007

1 Contents 2 3 List of figures...... 8 4 5 List of tables...... 9 6 7 1. Overview...... 11 8 9 1.1 Scope ...... 11 10 1.2 Purpose ...... 11 11 1.3 Introduction ...... 11 12 13 2. References...... 13 14 15 3. Terms, definitions, and notation ...... 14 16 17 3.1 Conformance levels...... 14 18 3.2 Terms and definitions...... 14 19 3.3 State machines...... 15 20 3.4 Arithmetic and logical operators ...... 17 21 3.5 Numerical representation...... 17 22 3.6 Field notations ...... 18 23 3.7 Bit numbering and ordering...... 19 24 3.8 Byte sequential formats ...... 20 25 3.9 Ordering of multibyte fields ...... 20 26 3.10 MAC address formats...... 21 27 3.11 Informative notes...... 22 28 3.12 Conventions for C code used in state machines ...... 22 29 30 4. Abbreviations and acronyms ...... 23 31 32 5. Architecture overview ...... 24 33 34 5.1 Application scenarios ...... 24 35 5.2 Design methodology...... 25 36 5.3 Time-synchronization facilities...... 26 37 5.4 Rate-normalization requirements ...... 28 38 5.5 Duplex-link delays...... 29 39 5.6 Time synchronization ...... 30 40 5.7 Distinctions from IEEE Std 1588...... 34 41 42 6. Frame-relay abstractions...... 35 43 44 6.1 Overview ...... 35 45 6.2 MAC-relay interface model...... 35 46 6.3 timedSync frames ...... 36 47 6.4 TimeSyncMaster state machine...... 39 48 6.5 TimeSyncSlave state machine...... 42 49 50 7. Duplex-link state machines...... 45 51 52 7.1 Overview ...... 45 53 7.2 Link-dependent indications ...... 45 54 7.3 timeSync frame format...... 46

Contribution from: [email protected]. 6 This is an unapproved working paper, subject to change. AVB BRIDGING JggDvj2005Apr16/D0.225 March 5, 2007

7.4 TimeSyncReceive state machine...... 47 1 7.5 TimeSyncTransmit state machine ...... 50 2 3 Annex A (informative) Bibliography...... 55 4 5 Annex B (informative) Time-scale conversions ...... 56 6 7 Annex C (informative) Bridging to IEEE Std 1394...... 57 8 9 C.1 Hybrid network topologies...... 57 10 11 Annex D (informative) Review of possible alternatives...... 59 12 13 D.1 Clock-synchronization alternatives ...... 59 14 15 Annex E (informative) Time-of-day format considerations ...... 61 16 17 E.1 Possible time-of-day formats...... 61 18 19 Annex F (informative) C-code illustrations...... 63 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 7 JggDvj2005Apr16/D0.225 WHITE PAPER CONTRIBUTION TO March 5, 2007

1 List of figures 2 3 Figure 1.1—Topology and connectivity...... 12 4 Figure 3.1—Bit numbering and ordering ...... 19 5 6 Figure 3.2—Byte sequential field format illustrations ...... 20 7 Figure 3.3—Multibyte field illustrations ...... 20 8 Figure 3.4—Illustration of fairness-frame structure ...... 21 9 Figure 3.5—MAC address format ...... 21 10 11 Figure 3.6—48-bit MAC address format...... 22 12 Figure 5.1—Garage jam session...... 24 13 Figure 5.2—Possible looping topology ...... 25 14 Figure 5.3—Timing information flows ...... 26 15 16 Figure 5.4—Grand-master precedence flows ...... 27 17 Figure 5.5—Grand-master selector...... 27 18 Figure 5.6—Hierarchical flows ...... 28 19 Figure 5.7—Rate-adjustment effects ...... 28 20 21 Figure 5.8—Timer snapshot locations...... 29 22 Figure 5.9—Cascaded PLL designs...... 31 23 Figure 6.1—MAC-relay interface model ...... 35 24 Figure 6.2—MAC-relay frame components...... 35 25 26 Figure 6.3—timedSync frame format...... 36 27 Figure 6.4—Global-time subfield format ...... 37 28 Figure 6.5—precedence subfields...... 37 29 Figure 6.6—clockID format...... 38 30 31 Figure 6.7—Global-time subfield format ...... 38 32 Figure 6.8—errorTime format ...... 39 33 Figure 6.9—localTime format ...... 39 34 Figure 6.10—Clock-master interface model ...... 39 35 36 Figure 6.11—Clock-slave interface model...... 42 37 Figure 7.1—Paths of duplex-link indications...... 45 38 Figure 7.2—Contents of duplex-link indications ...... 45 39 Figure 7.3—timeSync frame format...... 46 40 41 Figure C.1—IEEE 1394 leaf domains ...... 57 42 Figure C.2—IEEE 802.3 leaf domains ...... 57 43 Figure C.3—Time-of-day format conversions ...... 58 44 Figure C.4—Grand-master precedence mapping ...... 58 45 46 Figure 5.1—Global-time subfield format ...... 61 47 Figure E.2—IEEE 1394 timer format...... 61 48 Figure E.3—IEEE 1588 timer format...... 62 49 Figure E.4—EPON timer format...... 62 50 51 52 53 54

Contribution from: [email protected]. 8 This is an unapproved working paper, subject to change. AVB BRIDGING JggDvj2005Apr16/D0.225 March 5, 2007

List of tables 1 2 Table 3.1—State table notation example...... 16 3 4 Table 3.2—Special symbols and operators...... 17 5 Table 3.3—Names of fields and sub-fields ...... 18 6 Table 3.4—wrap field values ...... 19 7 Table 6.1—TimeSyncMaster state machine table ...... 41 8 9 Table 6.2—TimeSyncSlave state machine table ...... 44 10 Table 7.1—Clock-synchronization intervals ...... 47 11 Table 7.2—TimeSyncReceive state machine table ...... 49 12 Table 7.3—TimeSyncTransmit state machine table...... 52 13 14 Table B.1—Time-scale conversions...... 56 15 Table D.1—Protocol comparison ...... 59 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 9 JggDvj2005Apr16/D0.225 WHITE PAPER CONTRIBUTION TO March 5, 2007

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 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54

Contribution from: [email protected]. 10 This is an unapproved working paper, subject to change. AVB BRIDGING JggDvj2005Apr16/D0.225 March 5, 2007

1 DVJ Perspective on: Timing and 2 3 synchronization for time-sensitive 4 5 applications in bridges local area 6 7 networks 8 9 10 11 1. Overview 12 13 1.1 Scope 14 15 This draft specifies the protocol and procedures used to ensure that the synchronization requirements are met 16 for time sensitive applications, such as audio and video, across bridged and virtual bridged local area 17 networks consisting of LAN media where the transmission delays are fixed and symmetrical; for example, 18 IEEE 802.3 full duplex links. This includes the maintenance of synchronized time during normal operation 19 and following addition, removal, or failure of network components and network reconfiguration. It specifies 20 the use of IEEE 1588 specifications where applicable in the context of IEEE Std 802.1D and IEEE Std 21 802.1Q. Synchronization to an externally provided timing signal (e.g., a recognized timing standard such as 22 UTC or TAI) is not part of this standard but is not precluded. 23 24 25 1.2 Purpose 26 27 This draft enables stations attached to bridged LANs to meet the respective jitter, wander, and time synchro- 28 nization requirements for time-sensitive applications. This includes applications that involve multiple 29 streams delivered to multiple endpoints. To facilitate the widespread use of bridged LANs for these applica- 30 tions, synchronization information is one of the components needed at each network element where 31 time-sensitive application data are mapped or demapped or a time sensitive function is performed. This stan- 32 dard leverages the work of the IEEE 1588 WG by developing the additional specifications needed to address 33 these requirements. 34 35 36 1.3 Introduction 37 38 1.3.1 Background 39 40 Ethernet has successfully propagated from the data center to the home, becoming the wired home computer 41 interconnect of choice. However, insufficient support of real-time services has limited Ethernet’s success as 42 a consumer audio-video interconnects, where IEEE Std 1394 Serial Bus and Universal Serial Bus (USB) 43 have dominated the marketplace. Success in this arena requires solutions to multiple topics: 44 a) Discovery. A controller discovers the proper devices and related streamID/bandwidth parameters to 45 allow the listener to subscribe to the desired talker-sourced stream. 46 b) Subscription. The controller commands the listener to establish a path from the talker. 47 Subscription may pass or fail, based on availability of routing-table and link-bandwidth resources. 48 c) Synchronization. The distributed clocks in talkers and listeners are accurately synchronized. 49 Synchronized clocks avoid cycle slips and playback-phase distortions. 50 51 d) Pacing. The transmitted classA traffic is paced to avoid other classA traffic disruptions. 52 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 11 JggDvj2005Apr16/D0.225 WHITE PAPER CONTRIBUTION TO March 5, 2007

1 This draft covers the “Synchronization” component, assuming solutions for the other topics will be devel- 2 oped within other drafts or forums. 3 4 1.3.2 Interoperability 5 6 AVB time synchronization interoperates with existing Ethernet, but the scope of time-synchronization is 7 limited to the AVB cloud, as illustrated in Figure 1.1; less-precise time-synchronization services are 8 available everywhere else. The scope of the AVB cloud is limited by a non-AVB capable bridge or a 9 half-duplex link, neither of which can support AVB services. 10 11 AVB AVB AVB “cloud” device device 12 Peer device is 13 device not AVB capable AVB bridge 14 AVB bridge 15 AVB 16 Ethernet bridge bridge AVB 17 device 18 Half-duplex link 19 device can’t do AVB AVB 20 device AVB Ethernet AVB device device 21 hub 22 23 24 device 25 26 Figure 1.1—Topology and connectivity 27 28 Separation of AVB devices is driven by the requirements of AVB bridges to support subscription (bandwidth 29 allocation) and pacing of time-sensitive transmissions, as well as time-of-day clock-synchronization. 30 31 1.3.3 Document structure 32 33 The clauses and annexes of this working paper are listed below. 34 35 — Clause 1: Overview 36 — Clause 2: References 37 — Clause 3: Terms, definitions, and notation 38 — Clause 4: Abbreviations and acronyms 39 — Clause 5: Architecture overview 40 — Clause 7: Duplex-link state machines 41 — Annex A: Bibliography 42 — Annex C: Bridging to IEEE Std 1394 43 — Annex D: Review of possible alternatives 44 — Annex E: Time-of-day format considerations 45 — Annex F: C-code illustrations 46 47 48 49 50 51 52 53 54

Contribution from: [email protected]. 12 This is an unapproved working paper, subject to change. AVB BRIDGING JggDvj2005Apr16/D0.225 March 5, 2007

2. References 1 2 The following documents contain provisions that, through reference in this working paper, constitute provi- 3 sions of this working paper. All the standards listed are normative references. Informative references are 4 given in Annex A. At the time of publication, the editions indicated were valid. All standards are subject to 5 revision, and parties to agreements based on this working paper are encouraged to investigate the possibility 6 of applying the most recent editions of the standards indicated below. 7 8 ANSI/ISO 9899-1990, Programming Language-C.1,2 9 10 IEEE Std 802.1D-2004, IEEE Standard for Local and Metropolitan Area Networks: Media Access Control 11 (MAC) Bridges. 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50

1 51 Replaces ANSI X3.159-1989 52 2ISO documents are available from ISO Central Secretariat, 1 Rue de Varembe, Case Postale 56, CH-1211, Geneve 20, Switzer- land/Suisse; and from the Sales Department, American National Standards Institute, 11 West 42 Street, 13th Floor, New York, NY 53 10036-8002, USA 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 13 AVB BRIDGING JggDvj2005Apr16/D0.225 March 5, 2007

3. Terms, definitions, and notation 1 2 3 3.1 Conformance levels 4 5 Several key words are used to differentiate between different levels of requirements and options, as 6 described in this subclause. 7 8 3.1.1 may: Indicates a course of action permissible within the limits of the standard with no implied 9 preference (“may” means “is permitted to”). 10 11 3.1.2 shall: Indicates mandatory requirements to be strictly followed in order to conform to the standard and 12 from which no deviation is permitted (“shall” means “is required to”). 13 14 3.1.3 should: An indication that among several possibilities, one is recommended as particularly suitable, 15 without mentioning or excluding others; or that a certain course of action is preferred but not necessarily 16 required; or that (in the negative form) a certain course of action is deprecated but not prohibited (“should” 17 means “is recommended to”). 18 19 3.2 Terms and definitions 20 21 For the purposes of this working paper, the following terms and definitions apply. The Authoritative 22 Dictionary of IEEE Standards Terms [B2] should be referenced for terms not defined in the clause. 23 24 3.2.1 bridge: A functional unit interconnecting two or more networks at the data link layer of the OSI 25 reference model. 26 27 3.2.2 clock master: A bridge or end station that provides the link clock reference. 28 29 3.2.3 clock slave: A bridge or end station that tracks the link clock reference provided by the clock master. 30 31 3.2.4 cyclic redundancy check (CRC): A specific type of frame check sequence computed using a 32 generator polynomial. 33 34 3.2.5 grand clock master: The clock master selected to provide the network time reference. 35 36 3.2.6 link: A unidirectional channel connecting adjacent stations (half of a span). 37 38 3.2.7 listener: A sink of a stream, such as a television or acoustic speaker. 39 40 3.2.8 local area network (LAN): A communications network designed for a small geographic area, 41 typically not exceeding a few kilometers in extent, and characterized by moderate to high data transmission 42 rates, low delay, and low bit error rates. 43 44 3.2.9 MAC client: The layer entity that invokes the MAC service interface. 45 46 3.2.10 medium (plural: media): The material on which information signals are carried; e.g., optical fiber, 47 coaxial cable, and twisted-wire pairs. 48 49 3.2.11 medium access control (MAC) sublayer: The portion of the data link layer that controls and 50 mediates the access to the network medium. In this working paper, the MAC sublayer comprises the MAC 51 datapath sublayer and the MAC control sublayer. 52 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 14 AVB BRIDGING JggDvj2005Apr16/D0.225 March 5, 2007

3.2.12 network: A set of communicating stations and the media and equipment providing connectivity 1 among the stations. 2 3 3.2.13 plug-and-play: The requirement that a station perform classA transfers without operator intervention 4 (except for any intervention needed for connection to the cable). 5 6 3.2.14 protocol implementation conformance statement (PICS): A statement of which capabilities and 7 options have been implemented for a given Open Systems Interconnection (OSI) protocol. 8 9 3.2.15 span: A bidirectional channel connecting adjacent stations (two links). 10 11 3.2.16 station: A device attached to a network for the purpose of transmitting and receiving information on 12 that network. 13 14 3.2.17 topology: The arrangement of links and stations forming a network, together with information on 15 station attributes. 16 17 3.2.18 transmit (transmission): The action of a station placing a frame on the medium. 18 19 3.2.19 unicast: The act of sending a frame addressed to a single station. 20 21 22 3.3 State machines 23 24 3.3.1 State machine behavior 25 26 The operation of a protocol can be described by subdividing the protocol into a number of interrelated 27 functions. The operation of the functions can be described by state machines. Each state machine represents 28 the domain of a function and consists of a group of connected, mutually exclusive states. Only one state of a 29 function is active at any given time. A transition from one state to another is assumed to take place in zero 30 time (i.e., no time period is associated with the execution of a state), based on some condition of the inputs to 31 the state machine. 32 33 The state machines contain the authoritative statement of the functions they depict. When apparent conflicts 34 between descriptive text and state machines arise, the order of precedence shall be formal state tables first, 35 followed by the descriptive text, over any explanatory figures. This does not override, however, any explicit 36 description in the text that has no parallel in the state tables. 37 38 The models presented by state machines are intended as the primary specifications of the functions to be 39 provided. It is important to distinguish, however, between a model and a real implementation. The models 40 are optimized for simplicity and clarity of presentation, while any realistic implementation might place 41 heavier emphasis on efficiency and suitability to a particular implementation technology. It is the functional 42 behavior of any unit that has to match the standard, not its internal structure. The internal details of the 43 model are useful only to the extent that they specify the external behavior clearly and precisely. 44 45 46 47 48 49 50 51 52 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 15 AVB BRIDGING JggDvj2005Apr16/D0.225 March 5, 2007

3.3.2 State table notation 1 2 3 4 NOTE—The following state machine notation was used within 802.17, due to the exactness of C-code 5 conditions and the simplicity of updating table entries (as opposed to 2-dimensional graphics). Early state table descriptions can be converted (if necessary) into other formats before publication. 6 7 Each row of the table is preferably provided with a brief description of the condition and/or action for that 8 row. The descriptions are placed after the table itself, and linked back to the rows of the table using numeric 9 tags. 10 11 State machines may be represented in tabular form. The table is organized into two columns: a left hand side 12 representing all of the possible states of the state machine and all of the possible conditions that cause transi- 13 tions out of each state, and the right hand side giving all of the permissible next states of the state machine as 14 well as all of the actions to be performed in the various states, as illustrated in Table 3.1. The syntax of the 15 expressions follows standard C notation (see 3.12). No time period is associated with the transition from one 16 state to the next. 17 18 19 Table 3.1—State table notation example 20 21 Current Next 22 23 state conditionRow action state 24 25 START sizeOfMacControl > spaceInQueue 1 — START 26 passM == 0 2 27 28 — 3 TransmitFromControlQueue(); FINAL 29 FINAL SelectedTransferCompletes() 4 — START 30 31 — 5 — FINAL 32 33 34 Row 3.1-1: Do nothing if the size of the queued MAC control frame is larger than the PTQ space. 35 Row 3.1-2: Do nothing in the absence of MAC control transmission credits. 36 Row 3.1-3: Otherwise, transmit a MAC control frame. 37 38 Row 3.1-4: When the transmission completes, start over from the initial state (i.e., START). 39 Row 3.1-5: Until the transmission completes, remain in this state. 40 41 Each combination of current state, next state, and transition condition linking the two is assigned to a 42 different row of the table. Each row of the table, read left to right, provides: the name of the current state; a 43 condition causing a transition out of the current state; an action to perform (if the condition is satisfied); and, 44 finally, the next state to which the state machine transitions, but only if the condition is satisfied. The symbol 45 “—” signifies the default condition (i.e., operative when no other condition is active) when placed in the 46 condition column, and signifies that no action is to be performed when placed in the action column. 47 Conditions are evaluated in order, top to bottom, and the first condition that evaluates to a result of TRUE is 48 used to determine the transition to the next state. If no condition evaluates to a result of TRUE, then the state 49 machine remains in the current state. The starting or initialization state of a state machine is always labeled 50 “START” in the table (though it need not be the first state in the table). Every state table has such a labeled 51 state. 52 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 16 AVB BRIDGING JggDvj2005Apr16/D0.225 March 5, 2007

Each row of the table is preferably provided with a brief description of the condition and/or action for that 1 row. The descriptions are placed after the table itself, and linked back to the rows of the table using numeric 2 tags. 3 4 5 3.4 Arithmetic and logical operators 6 7 In addition to commonly accepted notation for mathematical operators, Table 3.2 summarizes the symbols 8 used to represent arithmetic and logical (boolean) operations. Note that the syntax of operators follows 9 standard C notation (see 3.12). 10 11 Table 3.2—Special symbols and operators 12 13 14 Printed character Meaning 15 16 && Boolean AND 17 || Boolean OR 18 19 ! Boolean NOT (negation) 20 & Bitwise AND 21 22 | Bitwise OR 23 ^ Bitwise XOR 24 25 <= Less than or equal to 26 >= Greater than or equal to 27 28 == Equal to 29 != Not equal to 30 31 = Assignment operator 32 // Comment delimiter 33 34 35 3.5 Numerical representation 36 37 38 39 NOTE—The following notation was taken from 802.17, where it was found to have benefits: 40 – The subscript notation is consistent with common mathematical/logic equations. 41 – The subscript notation can be used consistently for all possible radix values. 42 Decimal, hexadecimal, and binary numbers are used within this working paper. For clarity, decimal numbers 43 are generally used to represent counts, hexadecimal numbers are used to represent addresses, and binary 44 numbers are used to describe bit patterns within binary fields. 45 46 Decimal numbers are represented in their usual 0, 1, 2, … format. Hexadecimal numbers are represented by 47 a string of one or more hexadecimal (0-9,A-F) digits followed by the subscript 16, except in C-code 48 contexts, where they are written as 0x123EF2 etc. Binary numbers are represented by a string of one or 49 more binary (0,1) digits, followed by the subscript 2. Thus the decimal number “26” may also be represented 50 as “1A ” or “11010 ”. 51 16 2 52 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 17 AVB BRIDGING JggDvj2005Apr16/D0.225 March 5, 2007

MAC addresses and OUI/EUI values are represented as strings of 8-bit hexadecimal numbers separated by 1 hyphens and without a subscript, as for example “01-80-C2-00-00-15” or “AA-55-11”. 2 3 4 3.6 Field notations 5 6 3.6.1 Use of italics 7 8 level myMacAddress All field names or variable names (such as or ), and sub-fields within variables (such as 9 thisState.level ) are italicized within text, figures and tables, to avoid confusion between such names and 10 similarly spelled words without special meanings. A variable or field name that is used in a subclause 11 heading or a figure or table caption is also italicized. Variable or field names are not italicized within C code, 12 however, since their special meaning is implied by their context. Names used as nouns (e.g., subclassA0) are 13 also not italicized. 14 15 3.6.2 Field conventions 16 17 This working paper describes fields within packets or included in state-machine state. To avoid confusion 18 with English names, such fields have an italics font, as illustrated in Table 3.3. 19 20 Table 3.3—Names of fields and sub-fields 21 22 23 Name Description 24 25 newCRC Field within a register or frame 26 thisState.level Sub-field within field thisState 27 28 thatState.rateC[n].c Sub-field within array element rateC[n] 29 30 31 Run-together names (e.g., thisState) are used for fields because of their compactness when compared to 32 equivalent underscore-separated names (e.g., this_state). The use of multiword names with spaces (e.g., 33 “This State”) is avoided, to avoid confusion between commonly used capitalized key words and the 34 capitalized word used at the start of each sentence. 35 36 A sub-field of a field is referenced by suffixing the field name with the sub-field name, separated by a 37 period. For example, thisState.level refers to the sub-field level of the field thisState. This notation can be 38 continued in order to represent sub-fields of sub-fields (e.g., thisState.level.next is interpreted to mean the 39 sub-field next of the sub-field level of the field thisState). 40 41 Two special field names are defined for use throughout this working paper. The name frame is used to 42 denote the data structure comprising the complete MAC sublayer PDU. Any valid element of the MAC 43 sublayer PDU, can be referenced using the notation frame.xx (where xx denotes the specific element); thus, 44 for instance, frame.serviceDataUnit is used to indicate the serviceDataUnit element of a frame. 45 46 Unless specifically specified otherwise, reserved fields are reserved for the purpose of allowing extended 47 features to be defined in future revisions of this working paper. For devices conforming to this version of 48 this working paper, nonzero reserved fields are not generated; values within reserved fields (whether zero or 49 nonzero) are to be ignored. 50 51 52 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 18 AVB BRIDGING JggDvj2005Apr16/D0.225 March 5, 2007

3.6.3 Field value conventions 1 2 This working paper describes values of fields. For clarity, names can be associated with each of these 3 defined values, as illustrated in Table 3.4. A symbolic name, consisting of upper case letters with underscore 4 separators, allows other portions of this working paper to reference the value by its symbolic name, rather 5 than a numerical value. 6 7 8 Table 3.4—wrap field values 9 10 Value Name Description 11 12 0 STANDARD Standard processing selected 13 14 1 SPECIAL Special processing selected 15 2,3 — Reserved 16 17 18 Unless otherwise specified, reserved values allow extended features to be defined in future revisions of this 19 working paper. Devices conforming to this version of this working paper do not generate nonzero reserved 20 values, and process reserved fields as though their values were zero. 21 22 A field value of TRUE shall always be interpreted as being equivalent to a numeric value of 1 (one), unless 23 otherwise indicated. A field value of FALSE shall always be interpreted as being equivalent to a numeric 24 value of 0 (zero), unless otherwise indicated. 25 26 27 3.7 Bit numbering and ordering 28 29 Data transfer sequences normally involve one or more cycles, where the number of bytes transmitted in each 30 cycle depends on the number of byte lanes within the interconnecting link. Data byte sequences are shown in 31 figures using the conventions illustrated by Figure 3.1, which represents a link with four byte lanes. For 32 multi-byte objects, the first (left-most) data byte is the most significant, and the last (right-most) data byte is 33 the least significant. 34 35 36 bit bit 0 31 37 38 data[n+0] data[n+1] data[n+2] data[n+3] 39 data[n+4] data[n+5] data[n+6] data[n+7] 40 41 42 43 Figure 3.1—Bit numbering and ordering 44 45 Figures are drawn such that the counting order of data bytes is from left to right within each cycle, and from 46 top to bottom between cycles. For consistency, bits and bytes are numbered in the same fashion. 47 48 NOTE—The transmission ordering of data bits and data bytes is not necessarily the same as their counting order; the 49 translation between the counting order and the transmission order is specified by the appropriate reconciliation sublayer. 50 51 52 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 19 AVB BRIDGING JggDvj2005Apr16/D0.225 March 5, 2007

3.8 Byte sequential formats 1 2 Figure 3.2 provides an illustrative example of the conventions to be used for drawing frame formats and 3 other byte sequential representations. These representations are drawn as fields (of arbitrary size) ordered 4 along a vertical axis, with numbers along the left sides of the fields indicating the field sizes in bytes. Fields 5 are drawn contiguously such that the transmission order across fields is from top to bottom. The example 6 shows that field1, field2, and field3 are 1-, 1- and 6-byte fields, respectively, transmitted in order starting 7 with the field1 field first. As illustrated on the right hand side of Figure 3.2, a multi-byte field represents a 8 sequence of ordered bytes, where the first through last bytes correspond to the most significant through least 9 significant portions of the multi-byte field, and the MSB of each byte is drawn to be on the left hand side. 10 11 12 1 field1 byte[0] 13 14 1 field2 byte[1] 15 6 field3 byte[2] 16 6 field4 byte[3] 17 2 field5 byte[4] 18 19 byte[5] 2 field6 Transmission 20 order n field7 21 22 4 field8 23 24 Figure 3.2—Byte sequential field format illustrations 25 26 NOTE—Only the left-hand diagram in Figure 3.2 is required for representation of byte-sequential formats. The 27 right-hand diagram is provided in this description for explanatory purposes only, for illustrating how a multi-byte field 28 within a byte sequential representation is expected to be ordered. The tag “Transmission order” and the associated arrows are not required to be replicated in the figures. 29 30 31 3.9 Ordering of multibyte fields 32 33 In many cases, bit fields within byte or multibyte objects are expanded in a horizontal fashion, as illustrated 34 in the right side of Figure 3.3. The fields within these objects are illustrated as follows: left-to-right is the 35 byte transmission order; the left-through-right bits are the most significant through least significant bits 36 respectively. 37 38 39 byte[0] MSB LSB 40 fourByteField 41 byte[1] field representation 42 byte[2] 43 byte[0] byte[1] byte[2] byte[3] 44 byte[3] byte representation 45 byte[4] MSB LSB 46 47 twoByteField byte[5] 48 field representation 49 byte[4] byte[5] 50 51 byte representation 52 53 Figure 3.3—Multibyte field illustrations 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 20 AVB BRIDGING JggDvj2005Apr16/D0.225 March 5, 2007

The first fourByteField can be illustrated as a single entity or a 4-byte multibyte entity. Similarly, the second 1 twoByteField can be illustrated as a single entity or a 2-byte multibyte entity. 2 3 4 5 NOTE—The following text was taken from 802.17, where it was found to have benefits: 6 The details should, however, be revised to illustrate fields within an AVB frame header serviceDataUnit. 7 To minimize potential for confusion, four equivalent methods for illustrating frame contents are illustrated in 8 Figure 3.4. Binary, hex, and decimal values are always shown with a left-to-right significance order, 9 regardless of their bit-transmission order. 10 11 12 13 da_hi 14 6 da 15 da_lo sa_hi 6 sa 16 2 protocolType sa_lo 17 1 subType protocolTypesubType hopCount 18 1 hopcount 19 (…) 20 a) Sequential-byte format b) Field names 21 22 23 AC DE 48 2316 1010 1100 1101 1110 0100 1000 0010 00112 24 45 67 AC DE 0100 0101 0110 0111 1010 1100 1101 1110 16 16 2 2 25 48 76 54 3216 0100 1000 0111 0110 0101 0100 0011 00102 26 FA CE16 0116 0316 1111 1010 1100 11102 0000 00012 0000 00112 27 28 c) Hexadecimal values d) Binary values 29 30 31 Figure 3.4—Illustration of fairness-frame structure 32 33 34 3.10 MAC address formats 35 36 The format of MAC address fields within frames is illustrated in Figure 3.5. 37 38 MSB LSB 39 40 6 l g 41 oui dependentID 42 43 Legend: 44 l: locallyAdministered (called the ‘U/L address bit’ or ‘universally or locally administered bit in IEEE 802) 45 g: groupAddress 46 (called the ‘I/G address bit’ or ‘individual/group bit’ in IEEE 802) 47 48 Figure 3.5—MAC address format 49 50 3.10.1 oui: A 24-bit organizationally unique identifier (OUI) field supplied by the IEEE/RAC for the 51 purpose of identifying the organization supplying the (unique within the organization, for this specific 52 context) 24-bit dependentID. (For clarity, the locallyAdministered and groupAddress bits are illustrated by 53 the shaded bit locations.) 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 21 AVB BRIDGING JggDvj2005Apr16/D0.225 March 5, 2007

3.10.2 dependentID: An 24-bit field supplied by the oui-specified organization. The concatenation of the 1 oui and dependentID provide a unique (within this context) identifier. 2 3 To reduce the likelihood of error, the mapping of OUI values to the oui/dependentID fields are illustrated in 4 Figure 3.6. For the purposes of illustration, specific OUI and dependentID example values have been 5 assumed. The two shaded bits correspond to the locallyAdministered and groupAddress bit positions illus- 6 trated in Figure 3.5. 7 8 9 OUI value: AC-DE-48 Organization assigned extension: 23-45-67 10 11 MSB LSB 12

6 AC16 DE16 4816 2316 4516 6716 13 byte transmission order 14 15 Figure 3.6—48-bit MAC address format 16 17 18 3.11 Informative notes 19 20 Informative notes are used in this working paper to provide guidance to implementers and also to supply 21 useful background material. Such notes never contain normative information, and implementers are not 22 required to adhere to any of their provisions. An example of such a note follows. 23 24 NOTE—This is an example of an informative note. 25 26 3.12 Conventions for C code used in state machines 27 28 Many of the state machines contained in this working paper utilize C code functions, operators, expressions 29 and structures for the description of their functionality. Conventions for such C code can be found in 30 Annex F. 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 22 AVB BRIDGING JggDvj2005Apr16/D0.225 March 5, 2007

4. Abbreviations and acronyms 1 2 3 4 NOTE—This clause should be skipped on the first reading (continue with Clause 5). 5 This text has been lifted from the P802.17 draft standard, which has a relative comprehensive list. 6 Abbreviations/acronyms are expected to be added, revised, and/or deleted as this working paper evolves. 7 This working paper contains the following abbreviations and acronyms: 8 9 10 AP access point 11 AV audio/video 12 13 AVB audio/video bridging 14 AVB network audio/video bridged network 15 16 BER bit error ratio 17 BMC best master clock 18 19 BMCA best master clock algorithm 20 CRC cyclic redundancy check 21 22 FIFO first in first out 23 IEC International Electrotechnical Commission 24 25 IEEE Institute of Electrical and Electronics Engineers 26 IETF Internet Engineering Task Force 27 28 ISO International Organization for Standardization 29 ITU International Telecommunication Union 30 31 LAN local area network 32 LSB least significant bit 33 34 MAC medium access control 35 MAN metropolitan area network 36 37 MSB most significant bit 38 OSI open systems interconnect 39 40 PDU protocol data unit 41 PHY physical layer 42 43 PLL phase-locked loop 44 PTP Precision Time Protocol 45 46 RFC request for comment 47 RPR resilient packet ring 48 49 VOIP voice over internet protocol 50 51 52 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 23 AVB BRIDGING JggDvj2005Apr16/D0.225 March 5, 2007

5. Architecture overview 1 2 3 5.1 Application scenarios 4 5 5.1.1 Garage jam session 6 7 As an illustrative example, consider AVB usage for a garage jam session, as illustrated in Figure 5.1. The 8 audio inputs (microphone and guitar) are converted, passed through a guitar effects processor, two bridges, 9 mixed within an audio console, return through two bridges, and return to the ear through headphones. 10 11 t3 = 1 ms 12 processing 13 delay 14 15 16 17 18 19 20 21 t10 = T 22 t0 = 1 ms 23 A/D conversion delay 24 25 t12 = 6 ms t7 = 2 ms (air delay for t11 = 1 ms processing 26 6’ distance) D/A conversion delay 27 delay 28 29 30 Figure 5.1—Garage jam session 31 32 Using Ethernet within such systems has multiple challenges: low-latency and tight time-synchronization. 33 Tight time synchronization is necessary to avoid cycle slips when passing through multiple processing 34 components and (ultimately) to avoid under-run/over-run at the final D/A converter’s FIFO. The challenge 35 of low-latency transfers is being addressed in other forums and is outside the scope of this draft. 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 24 AVB BRIDGING JggDvj2005Apr16/D0.225 March 5, 2007

5.1.2 Looping topologies 1 2 Bridged Ethernet networks currently have no loops, but bridging extensions are contemplating looping 3 topologies. To ensure longevity of this standard, the time-synchronization protocols are tolerant of looping 4 topologies that could occur (for example) if the dotted-line link were to be connected in Figure 5.2. 5 6 AVB AVB AVB “cloud” 7 device device Peer device is 8 device not AVB capable AVB 9 bridge AVB 10 bridge AVB 11 Ethernet bridge 12 bridge AVB device 13 Half-duplex link 14 device can’t do AVB 15 AVB device 16 AVB Ethernet AVB device device hub 17 18 19 device 20 21 Figure 5.2—Possible looping topology 22 23 Separation of AVB devices is driven by the requirements of AVB bridges to support subscription (bandwidth 24 allocation) and pacing of time-sensitive transmissions, as well as time-of-day clock-synchronization. 25 26 27 5.2 Design methodology 28 29 5.2.1 Assumptions 30 31 This working paper specifies a protocol to synchronize independent timers running on separate stations of a 32 distributed networked system, based on concepts specified within IEEE Std 1588-2002. Although a high 33 degree of accuracy and precision is specified, the technology is applicable to low-cost consumer devices. 34 The protocols are based on the following design assumptions: 35 a) Each end station and intermediate bridges provide independent clocks. 36 b) All clocks are accurate, typically to within ±100PPM. 37 38 c) Details of the best time-synchronization protocols are physical-layer dependent. 39 40 5.2.2 Objectives 41 42 With these assumptions in mind, the time synchronization objectives include the following: 43 a) Precise. Multiple timers can be synchronized to within 10’s of nanoseconds. 44 b) Inexpensive. For consumer AVB devices, the costs of synchronized timers are minimal. 45 (GPS, atomic clocks, or 1PPM clock accuracies would be inconsistent with this criteria.) 46 c) Scalable. The protocol is independent of the networking technology. In particular: 47 48 1) Cyclical physical topologies are supported. 49 2) Long distance links (up to 2 kM) are allowed. 50 d) Plug-and-play. The system topology is self-configuring; no system administrator is required. 51 52 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 25 AVB BRIDGING JggDvj2005Apr16/D0.225 March 5, 2007

5.2.3 Strategies 1 2 Strategies used to meet these objectives include the following: 3 a) Precision is achieved by calibrating and adjusting grandTime clocks. 4 5 1) Offsets. Offset value adjustments eliminate immediate clock-value errors. 6 2) Rates. Rate value adjustments reduce long-term clock-drift errors. 7 b) Simplicity is achieved by the following: 8 1) Concurrence. Most configuration and adjustment operations are performed concurrently. 9 2) Feed-forward. PLLs are unnecessary within bridges, but possible within applications. 10 3) Frequent. Frequent (nominally 100 Hz) interchanges reduces needs for overly precise clocks. 11 12 13 5.3 Time-synchronization facilities 14 15 5.3.1 Grand-master overview 16 17 Clock synchronization involves streaming of timing information from a grand-master timer to one or more 18 slave timers. Although primarily intended for non-cyclical physical topologies (see Figure 5.3a), the 19 synchronization protocols also function correctly on cyclical physical topologies (see Figure 5.3b), by 20 activating only a non-cyclical subset of the physical topology. 21 22 23 24 S S S S 25 26 G G 27 S S 28 29 30 Legend: Legend: 31 G grand master otherS slave G grand master otherS slave established synchronization flow established synchronization flow 32 33 a) Non-cyclical grand-master topologies a) Cyclical grand-master topologies 34 35 Figure 5.3—Timing information flows 36 37 38 In concept, the clock-synchronization protocol starts with the selection of the reference-timer station, called 39 a grand-master station (oftentimes abbreviated as grand-master). Every AVB-capable station is grand-master 40 capable, but only one is selected to become the grand-master station within each network. To assist in the 41 grand-master selection, each station is associated with a distinct preference value; the grand-master is the 42 station with the “best” preference values. Thus, time-synchronization services involve two subservices, as 43 listed below and described in the following subclauses. 44 45 a) Selection. Looping topologies are isolated (from a time-synchronization perspective) into a 46 spanning tree. The root of the tree, which provides the time reference to others, is the grand master. 47 b) Distribution. Synchronized time is distributed through the grand-master’s spanning tree. 48 49 50 51 52 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 26 AVB BRIDGING JggDvj2005Apr16/D0.225 March 5, 2007

5.3.2 Grand-master selection 1 2 As part of the grand-master selection process, stations forward the best of their observed preference values 3 to neighbor stations, allowing the overall best-preference value to be ultimately selected and known by all. 4 The station whose preference value matches the overall best-preference value ultimately becomes the 5 grand-master. 6 7 The grand-master station observes that its precedence is better than values received from its neighbors, as 8 illustrated in Figure 5.4a. A slave stations observes its precedence to be worse than one of its neighbors and 9 forwards the best-neighbor precedence value to adjacent stations, as illustrated in Figure 5.4b. To avoid 10 cyclical behaviors, a hopCount value is associated with preference values and is incremented before the 11 best-precedence value is communicated to others. 12 13 14 15 16 thisPrecedence hopCount +=1 thisPrecedence hopCount +=1 17 MinimumValue MinimumValue 18 19 20 21 22 a) Grand-master station flows b) Clock-slave station flows 23 24 Figure 5.4—Grand-master precedence flows 25 26 27 5.3.3 Grand-master preference 28 29 Grand-master preference is based on the concatenation of multiple fields, as illustrated in Figure 5.5. The 30 port value is used within bridges, but is not transmitted between stations. 31 32 MSB LSB 33 priority1 class timeSrc variance priority2 clockID hop port 34 35 precedence tie-breaker 36 preference 37 Legend: timeSrc: timeSource hop: hopCount 38 39 40 41 Figure 5.5—Grand-master selector 42 43 This format is similar to the format of the spanning-tree precedence value, but a wider clockID is provided 44 for compatibility with interconnects based on 64-bit station identifiers. 45 46 47 48 49 50 51 52 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 27 AVB BRIDGING JggDvj2005Apr16/D0.225 March 5, 2007

5.3.4 Synchronized-time distribution 1 2 Clock-synchronization information conceptually flows from a grand-master station to clock-slave stations, 3 as illustrated in Figure 5.6a. A more detailed illustration shows pairs of synchronized clock-master and 4 clock-slave components, as illustrated in Figure 5.6b. The active clock agents are illustrated as 5 black-and-white components; the passive clock agents are illustrated as grey-and-white components. 6 7 8 9 c0 c1 c2 c3 c0 c1 c2 c3 10 S S a0 f0 11 b0 e0 b0 e0 12 GS b1 e1 b1 e1 13 S S a2 d1 d2 f2 14 b2 e2 b2 e2 15 S S a3 f3 b3 e3 b3 e3 16 17 Legend: Legend: 18 G grand-masterS clock slave grand master slave station streaming data master agent slave agent 19 internal coupling clock-synch flow 20 a) Clock synchronization flow b) Agents along the synchronization path 21 22 23 Figure 5.6—Hierarchical flows 24 25 26 Internal communications distribute synchronized time from clock-slave agents b1, c1, and e1 to the other 27 clock-master agents on bridgeB, bridgeC, and bridgeE respectively. Within a clock-slave, precise time 28 synchronization involves adjustments of timer value and rate-of-change values. 29 30 Time synchronization yields distributed but closely-matched grandTime values within stations and bridges. 31 No attempt is made to eliminate intermediate jitter with bridge-resident jitter-reducing phase-lock loops 32 (PLLs,) but application-level phase locked loops (not illustrated) are expected to filter high-frequency jitter 33 from the supplied grandTime values. 34 35 5.4 Rate-normalization requirements 36 37 If the absence of rate adjustments, significant grandTime errors can accumulate between periodic updates, as 38 illustrated in Figure 5.7. The 2 µs deviation is due to the cumulative effect of clock drift, over the 10 ms 39 send-period interval, assuming clock-master and clock-slave crystal deviations of −100 PPM and +100 PPM 40 respectively. 41 42 grandTime 2 µs 43 deviation 44 45 6 ns 46 time 47 460 ms 470 ms 480 ms 490 ms 500 ms 510 ms 520 ms 530 ms 48 49 50 Figure 5.7—Rate-adjustment effects 51 52 While this regular sawtooth is illustrated as a highly regular (and thus perhaps easily filtered) function, 53 irregularities could be introduced by changes in the relative ordering of clock-master and clock-slave 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 28 AVB BRIDGING JggDvj2005Apr16/D0.225 March 5, 2007 transmissions, or transmission delays invoked by asynchronous frame transmissions. Tracking peaks/valleys 1 or filtering such irregular functions are thought unlikely to yield similar grandTime deviation reductions. 2 3 To reduce such time deviations, a lower-rate (currently assumed to be 80 ms) activity measures the ratio of 4 each station’s frequency to that of its adjacent neighbor. When these calibration factors are applied, the 5 effects of rate differences are easily be reduced to less than 1 PPM, based on the aforementioned 6 time-accuracy assumptions. At this point, the timer-offset measurement errors (not clock-drift induced 7 errors) dominate the clock-synchronization error contributions. 8 9 10 5.5 Duplex-link delays 11 12 On some forms of duplex-link media, time-synchronization involves periodic not-necessarily synchronized 13 packet transmissions between adjacent stations, as illustrated in Figure 5.8a. The transmitted frame contains 14 the following information: 15 precedence—Specifies the grand-master precedence. 16 grandTime—An estimation of the grand-master time. 17 localTime—A sampling of the neighbor’s local time. 18 thatTxTime—The adjacent link’s timeSync transmit time. 19 thatRxTime—The adjacent link’s timeSync receive time. 20 21 22 23 rxB2 rxB1 rxB2 rxB1 24 sendA txA rxB0 sendA txA rxB0 25 ~10ms ~10ms packB rxA0 26 ~10ms ~10ms packA rxA0 27 rxA0 txB sendB rxA0 txB sendB 28 precedence precedence rxA1 rxA2 rxA1 rxA2 29 grandTime grandTime 30 stationA stationB stationA stationB localTime localTime 31 thatTxTime thatTxTime 32 thatRxTime thatRxTime 33 34 a) Basic time-sync messages b) Relevant snap-shot storage 35 36 Figure 5.8—Timer snapshot locations 37 38 39 Snapshots are taken when packets are transmitted (illustrated as txA and txB) and received (illustrated as rxA 40 and rxB), as illustrated in Figure 5.8b. The receive snapshot is double buffered, in that the value of rxB0 is 41 copied to rxB1 when the rxB0 snapshot is taken. Similarly, the value of rxA0 is copied to rxA1 when the 42 rxA0 snapshot is taken. 43 44 The physical entity that triggers the received-frame and transmitted-frame snapshot operations is 45 deliberately left ambiguous. Mandatory jitter-error accuracies are sufficiently loose to allow transmit/receive 46 snapshot circuits to be located with the MAC. Vendors may elect to further reduce timing jitter by latching 47 the receive/transmit times within the PHY, where the uncertain FIFO latencies can be more easily avoided. 48 49 The the timeSync frame arrives from stationA, the frame’s localTime value is copied to the rxB2 register, 50 and is simultaneously available with the updated rxB1 snapshot value. Similarly, when the timeSync frame 51 arrives from stationB, the frame’s localTime value is copied to the rxA2 register, and is simultaneously avail- 52 able with the updated rxA1 snapshot value. 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 29 AVB BRIDGING JggDvj2005Apr16/D0.225 March 5, 2007

For stationB, the values inserted into each frame include the following: 1 localTime—The txB value, representing the last timeSync frame-transmission time on this link. 2 thatTxTime—The rxB2 value, representing a timeSync frame-transmission time on the other link. 3 thatRxTime—The rxB1 value, representing a timeSync frame-reception time on the other link. 4 grandTime—The computed grand-master time associated with the co-resident localTime value. 5 6 For stationA, the values inserted into each frame include the following: 7 localTime—The txA value, representing the last timeSync frame-transmission time on this link. 8 thatTxTime—The rxA2 value, representing a timeSync frame-transmission time on the other link. 9 thatRxTime—The rxA1 value, representing a timeSync frame-reception time on the other link. 10 grandTime—The computed grand-master time associated with the co-resident localTime value. 11 12 Assuming the local stationA and stationB timers have the same frequencies and the two links on the span 13 have identical delays, the link delay can be computed at stationB and stationA, based on the contents of the 14 most-recently received timeSync frame, as specified by Equation 5.1 and Equation 5.2 respectively. 15 16 linkDelayB = ((rxB1 - frame.thatTxTime) - (frame.localTime - frame.thatRxTime))/2; (5.1) 17 linkDelayA = ((rxA1 - frame.thatTxTime) - (frame.localTime - frame.thatRxTime))/2; (5.2) 18 19 If the stationA-to-stationB and stationB-to-stationA links have different propagation delays, these linkDelay 20 calculations do not correspond to the different propagation delays, but represent the average of the two link 21 delays. Implementers have the option of manually specifying the link-delay differences via MIB-accessible 22 parameters, within tightly-synchronized systems where this inaccuracy might be undesirable. 23 24 5.6 Time synchronization 25 26 5.6.1 Gain-peaking avoidance 27 28 A transient phenomenon associated with cascaded PLLs is called whiplash or gain-peaking, depending on 29 how the phenomenon is observed. A whiplash effect is visible as ringing after a injected spike and/or a step 30 change in frequency. The gain-peaking effect is visible as a frequency gain, that becomes increasingly larger 31 through cascaded PLLs, for selected frequencies. For basic cascaded PLLs (see Figure 5.9a), this phenome- 32 non is unavoidable, although its effects can be reduced through careful design or manual tuning of peaking 33 frequencies. 34 35 To avoid this phenomenon when passing through multiple bridges, two signal values are transmitted over 36 intermediate hops: grandTime and errorTime (see Figure 5.9a). For stability, the grandTime value corre- 37 sponds to an interpolated DELAY time in the past (DELAY is typically assumed to be four transmission 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 30 AVB BRIDGING JggDvj2005Apr16/D0.225 March 5, 2007 intervals). For accuracy, the errorTime value represents errors due to differences in DELAY, as measured by 1 local-clock and syntonized-clock timers. 2 3 4 grandTime interpolation slopes 5 time clock clock 6 bridge bridge master slave DELAY 7 relay[n-1] relay[n-1] relay[n] current A BCDerrorTime time 8 9 a) Cascaded PLL-error propagation b) Interpolation in the “past” 10 11 Figure 5.9—Cascaded PLL designs 12 13 Within the context of Figure 5.9a, the clock-master stationA could send time-varying grandTime values and 14 a zero-valued errorTime value. The stationB bridge outputs a revised rate-interpolated whiplash-free 15 grandTime value, along with nonzero errorTime values. 16 17 The stationC bridge behaves similarly; producing a whiplash-free grandTime output along with revised 18 errorTime values. The propagation of (relatively DC-free) errorTime values is deferred for a DELAY-time 19 interval, so that new values can be conveniently interpolated between past-observed values. 20 21 The concept of whiplash-free interpolation assumes the presence of relatively stable clock rates. The next 22 grandTime output value out[m] is computed by interpolating between the last grandTime output value 23 out[m-1] and the most-recent relay[n]-supplied grandTime values, as illustrated in Figure 5.9b. To 24 compensate for the back-in-time error, the value of out[m]+DELAY is transmitted as the current grandTime 25 value. 26 27 From an intuitive perspective, the whiplash-free nature of the back-in-time interpolation is attributed to the 28 use of interpolation (as opposed to extrapolation) protocols. Interpolation between input values never 29 produces a larger output value, as would be implied by a gain-peaking (larger-than-unity gain) algorithm. 30 The downside of back-in-time interpolation is the requirement for a side-band errorTime communication 31 channel, over which the difference between nominal and rate-normalized DELAY values can be transmitted. 32 33 A more detailed discussion of the back-in-time interpolation calculations is provided in the following sub- 34 clauses (see 5.6.2, 5.6.2, and 5.6.2). The formal specification of these algorithms is specified by formal state 35 machines (see Clause 7) and formal C code (see Annex F). 36 37 5.6.2 Received timeSync computations 38 39 The baseline link-delay calculations of 5.5 are sufficient for 802.11v and other interconnects wherein the 40 timeSync turn-around latencies are tightly controlled by the MAC. For 802.3 and other interconnects, the 41 turnaround times can be done above the MAC and can be much larger than the packet-transmission times. 42 For such media, the duplex-link delay calculations must be compensated by measured differences in 43 adjacent-station clock rates, as discussed within this subclause. 44 45 Assuming the local stationA and stationB timers have the different frequencies and the two links on the span 46 have identical delays, the link delay can be computed at stationB based on the contents of the most-recently 47 received timeSync frame, as specified by Equation 5.3. 48 49 50 51 52 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 31 AVB BRIDGING JggDvj2005Apr16/D0.225 March 5, 2007

1 // Computing the link delay at station B, based on neighbor-syntonized values (5.3) 2 // This code summarizes the behavior of MacToRelay() in Annex F. #define TICK T10ms // Tx timeSync period 3 if (rxB1-rxShot0 >= 2*TICK && rxB1-rxShot1 >= 4*TICK) { // Every 4’th cycle 4 rated = (frame.thatTxTime - txTime1) / (rxB1 - rxShot1); // Computed rated value 5 rxShot1 = rxShot0; // Save rxB1[n-8] 6 rxShot0 = rxB1; // Save rxB1[n-4] 7 txTime1 = txTime0; // Saved txTime[n-8] txTime0 = frame.thatTxTime; // Saved txTime[n-4] 8 } 9 roundTrip = rxB1–frame.thatTxTime; // Round-trip time minus 10 turnRound = frame.localTime – frame.thatRxTime; // turnaround is due to 11 linkDelay = (roundTrip – (rated * turnRound)) / 2; // the two cable delays 12 relay.grandTime = frame.grandTime + linkDelay; // Adjusted grand-time relay.localTime = rxB1; // Received local-time 13 14 NOTE—The rating portion of the linkDelay computation is based on the station-local time within adjacent-neighbor 15 exchanges and is therefore unaffected by discontinuities in the distributed grand-master time reference. 16 17 NOTE—The C code within Annex x has not tracked recent changes to this behavioral summary. 18 19 5.6.3 Relayed timeSync computations 20 21 At the bridge’s co-resident clock-master ports, an update is performed each time relayed information is 22 received. The update provides a target 40ms-delayed future value, towards which the grandTime advances, 23 as summarized in Equation 5.4. 24 25 // Update information when relayed frames arrives. (5.4) 26 // This code summarizes the behavior of RelayToFrame() in Annex F. #define THIS_TICK T10ms // Tx timeSync period 27 #define THAT_TICK T10ms // Rx timeSync period 28 #define TOCK (2 * (THIS_TICK + MIN(THIS_TICK, THAT_TICK))) // Interpolation interval 29 #define CLIP_RATE (x, d) ( x > ONE+d ? ONE+d : (x < ONE-d ? ONE-d : x)) 30 delta0 = relay.localTime - localTime0; // Changed localTime 31 if (delta0 > TOCK && delta1 >= 2*TOCK) { // TOCK-interval updates grandTime1 = grandTime0; // Saved grandTime[n-1] 32 localTime1 = localTime0; // Saved localTime[n-1] 33 grandRate1 = grandRate0; // Saved grandRate[n-1] 34 errorRate1 = errorRate0; // Saved errorRate[n-1] 35 grandRated = (relay.grandTime - grandTime0) / localDelta; // Estimate grandRated 36 grandRate0 = CLIP_RATE(grandRated, PPM250); // clip to grandRate[n] errorRate0 = (relay.errorTime - errorTime0) / localDelta; // Estimate errorRate 37 grandTime0 = relay.grandTime; // Saved grandTime[n] 38 localTime0 = relay.localTime; // Saved localTime[n] 39 errorTime0 = relay.errorTime; // Saved errorTime[n] 40 } 41 42 NOTE—The C code within Annex x has not tracked recent changes to this behavioral summary. 43 44 45 46 47 48 49 50 51 52 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 32 AVB BRIDGING JggDvj2005Apr16/D0.225 March 5, 2007

5.6.4 Transmitted timeSync computations 1 2 At the bridge’s co-resident clock-master port, the current grandTime value is estimated by interpolating a 3 fixed local-timer amount (40 ms) into the past, as summarized by Equation 5.5. The input error value is 4 similarly interpolated into the past and incremented by the local-error contribution. 5 6 // Update information when transmitted frame is formed. (5.5) 7 // This code summarizes the behavior of FrameToMac() in Annex F. #define DELAY (TOCK - ((THIS_TICK + THAT_TICK) / 2)) // Ensures interpolation 8 lapseTime = txB - DELAY; // Back-in-time location 9 if (lapseTime < localTime0) { // Remote interpolation: 10 grandRated = grandRate1; // based on grand rate; 11 errorRated = errorRate1; // based on rate 12 } else { // Recent interpolation: grandRated = grandRate1; // based on grand rate; 13 errorRated = errorRate1; // based on recent rate 14 } 15 grandTime = grandTime1 + (lapseTime-localTime1)*grandRated; // Grand-time estimate 16 errorTime = errorTime1 + (lapseTime-localTime1)*errorRated; // Error-time estimate 17 errorPlus = errorTimer + DELAY * (rating - ONE); // adds to cumulative frame.grandTime = grandTimer; // Extrapolate to future 18 frame.localTime = txB; // Transmit snapshot 19 frame.errorTime = (errorTime + errorPlus); // adds to cumulative 20 21 NOTE—The C code within Annex x has not tracked recent changes to this behavioral summary. 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 33 AVB BRIDGING JggDvj2005Apr16/D0.225 March 5, 2007

5.7 Distinctions from IEEE Std 1588 1 2 Advantageous properties of this protocol that distinguish it from other protocols (including portions of 3 IEEE Std 1588) include the following: 4 a) Synchronization between grand-master and local clocks occurs at each station: 5 6 1) All bridges have a lightly filtered synchronized image of the grand-master time. 7 2) End-point stations have a heavily filtered synchronized image of the grand-master time. 8 b) Time is uniformly represented as scaled integers, wherein 40-bits represent fractions-of-a-second. 9 1) Grand-master time specifies seconds within a more-significant 40-bit field. 10 2) Local time specifies seconds within a more-significant 8-bit field. 11 c) Locally media-dependent synchronized networks don’t require extra time-snapshot hardware. 12 13 d) Error magnitudes are linear with hop distances; PLL-whiplash and O(n2) errors are avoided. 14 e) Multicast (one-to-many) services are not required; only nearest-neighbor addressing is required. 15 f) A relatively frequent 100 Hz (as compared to 1 Hz) update frequency is assumed: 16 1) This rate can be readily implemented (in today’s technology) for minimal cost. 17 2) The more-frequent rate improves accuracy and reduces transient-recovery delays. 18 3) The more-frequent rate reduces transient-recovery delays. 19 20 g) Only one frame type simplifies the protocols and reduces transient-recovery times. Specifically: 21 1) Cable delay is computed at a fast rate, allowing clock-slave errors to be better averaged. 22 2) Rogue frames are quickly scrubbed (2.6 seconds maximum, for 256 stations). 23 3) Drift-induced errors are greatly reduced. 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 34 JggDvj2005Apr16/D0.225 WHITE PAPER CONTRIBUTION TO March 5, 2007

1 6. Frame-relay abstractions 2 3 4 6.1 Overview 5 6 This clause specifies the state machines that support duplex-link 802.3-based bridges. The operations are 7 described in an abstract way and do not imply any particular implementations or any exposed interfaces. 8 There is not necessarily a one-to-one correspondence between the primitives and formal procedures and the 9 interfaces in any particular implementation. 10 11 6.2 MAC-relay interface model 12 13 The time-synchronization service model assumes the presence of one or more time-synchronized AVB ports 14 communicating with a MAC relay, as illustrated in Figure 6.1. A received MAC frame is associated with 15 link-dependent timing information, processed within the TimeSync state machine, and passed to the MAC 16 relay by the TimeSyncTransmit state machine. The preference of the relayed frame is determines whether 17 the frame is dropped by the TimeSyncReceive state machines or modified and queued for periodic 18 transmission on the receiving PHY. 19 20 21 MAC relay TimeSync 22 IS S S IS ync 23 MAC (timedSync) S MAC 24 Time 25 26 27 28 link-dependent 29 PHY PHY 30 31 32 Figure 6.1—MAC-relay interface model 33 34 All components are assumed to have access to a common free-running (not adjustable) local timer. There is 35 not necessarily a one-to-one correspondence between the primitives and formal procedures and the inter- 36 faces in any particular implementation. 37 38 The MAC-relay frame transports a source-port identifier, a leapSeconds time-conversion parameter, 39 hops&precedence information for grand-master selection, a globally synchronized grandTime, 40 neighbor-syntonized localTime, and a cumulative errorTime, as illustrated in Figure 6.2. A clock-slave 41 end-point is expected to low-pass filter the sum of grandTime and errorTime values, thereby yielding its 42 synchronized image of the grand-master’s current grandTime value. 43 44 port leapSeconds hops 45 source: conversion: distance: 46 precedence: priority1 class timeSrc variance priority2 clockID 47 48 grandTime: seconds fraction 49 50 localTime: seconds fraction 51 subfraction 52 errorTime: 53 54 Figure 6.2—MAC-relay frame components

Contribution from: [email protected]. 35 This is an unapproved working paper, subject to change. AVB BRIDGING JggDvj2005Apr16/D0.225 March 5, 2007

6.3 timedSync frames 1 2 6.3.1 timedSync frame format 3 4 The relayed timedSync (relayed time-synchronization) frame transports specific time-synchronization 5 related information, as illustrated in Figure 6.3. 6 7 8 6 da — Destination MAC address 9 10 6 — Source MAC address sa 11 2 protocolType — Distinguishes AVB frames from others 12 1 function — Distinguishes timeSync from other AVB frames 13 1 version — Distinguishes between timeSync frame versions 14 15 14 precedence — Precedence for grand-master selection 16 17 10 grandTime — Transmitter global-time snapshot (1 cycle delayed) 18 19 4 errorTime — Frame check sequence 20 21 1 portID — A (sequence number) count of time-sync frames 22 1 hopCount — Hop count from the grand master 23 2 leapSeconds — Additional seconds are introduced as time passes 24 6 localTime — Transmitter local-time snapshot (1 cycle delayed) 25 26 6 tickTime — Nominal timeSync transmission interval 27 28 Figure 6.3—timedSync frame format 29 30 NOTE—The grandTime field has a range of approximately 36,000 years, far exceeding expected equipment life-spans. 31 The localTime and linkTime fields have a range of 256 seconds, far exceeding the expected timeSync frame transmission 32 interval. These fields have a 1 pico-second resolution, more precise than the expected hardware snapshot capabilities. 33 Future time-field extensions are therefore unlikely to be necessary in the future. 34 35 6.3.1.1 da: A 48-bit (destination address) field that allows the frame to be conveniently stripped by its 36 downstream neighbor. The da field contains an otherwise-reserved group 48-bit MAC address (TBD). 37 38 6.3.1.2 sa: A 48-bit (source address) field that specifies the local station sending the frame. The sa field 39 contains an individual 48-bit MAC address (see 3.10), as specified in 9.2 of IEEE Std 802-2001. 40 41 6.3.1.3 protocolType: A 16-bit field contained within the payload that identifies the format and function of 42 the following fields. 43 44 6.3.1.4 function: An 8-bit field that distinguishes the timeSync frame from other AVB frame type. 45 46 6.3.1.5 version: An 8-bit field that identifies the format and function of the following fields (see xx). 47 48 6.3.1.6 precedence: A 14-byte field that has specifies precedence in the grand-master selection protocols 49 (see 6.3.3). 50 51 6.3.1.7 grandTime: An 80-bit field that specifies the grand-master synchronized time within the source 52 station, when the previous timeSync frame was transmitted (see 6.3.5). 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 36 JggDvj2005Apr16/D0.225 WHITE PAPER CONTRIBUTION TO March 5, 2007

1 6.3.1.8 errorTime: A 32-bit field that specifies the cumulative grand-master synchronized-time error. 2 (Propagating errorTime and grandTime separately eliminates whiplash associated with cascaded PLLs.) 3 4 6.3.1.9 portID: An 8-bit field that identifies the port that sourced the ppSync frame. 5 6 6.3.1.10 hopCount: An 8-bit field that identifies the maximum number of hops between the talker and 7 associated listeners. 8 9 6.3.1.11 localTime: A 48-bit field that specifies the local free-running time within this station, when the 10 previous timeSync frame was received (see 6.3.7). 11 12 6.3.1.12 frameCount: An 8-bit field that is incremented by one between successive timeSync frame trans- 13 mission. 14 15 6.3.1.13 leapSeconds: A 16-bit field that specifies the number of seconds that should be added to the 16 grandTime value, when converting between xx and yy values. (In IEEE-1588, this is the UTCOffset field.) 17 18 6.3.1.14 localTime: A 48-bit field that specifies the local free-running time within the source station, when 19 the previous timeSync frame was transmitted (see 6.3.7). 20 21 6.3.1.15 tickTime: A 48-bit field that specifies the nominal period between timeSync frame transmissions. 22 23 NOTE—The tickTime value is a port-specific constant value which (for apparent simplicity) has been illustrated as a 24 relayed frame parameter. Other abstract communication techniques (such as access to shared design constants) might be 25 selected to communicate this information, if requested by reviewers for consistency with existing specification methodologies. 26 27 6.3.2 Version format 28 29 For compatibility with existing 1588 time-snapshot, a single bit within the version field is constrained to be 30 zero, as illustrated in Figure 6.4. The remaining versionHi and versionLo fields shall have the values of 0 31 and 1 respectively. 32 33 MSB LSB 34 versionHi0 versionLo 35 8 bits 36 37 Figure 6.4—Global-time subfield format 38 39 6.3.3 precedence subfields 40 41 The precedence field includes the concatenation of multiple fields that are used to establish precedence 42 between grand-master candidates, as illustrated in Figure 6.5. 43 44 MSB LSB 45 priority1 class timeSrc variance priority2 clockID 46 47 Figure 6.5—precedence subfields 48 49 6.3.3.1 priority1: An 8-bit field that can be configured by the user and overrides the remaining 50 precedence-resident precedence fields. 51 52 6.3.3.2 class: An 8-bit precedence-selection field defined by the like-named IEEE-1588 field. 53 54

Contribution from: [email protected]. 37 This is an unapproved working paper, subject to change. AVB BRIDGING JggDvj2005Apr16/D0.225 March 5, 2007

6.3.3.3 timeSrc: An 8-bit precedence-selection field defined by the like-named IEEE-1588 field. 1 2 6.3.3.4 variance: A 16-bit precedence-selection field defined by the like-named IEEE-1588 field. 3 4 6.3.3.5 priority2: A 8-bit field that can be configured by the user and overrides the remaining 5 precedence-resident clockID field. 6 7 6.3.3.6 clockID: A 64-bit globally-unique field that ensures a unique precedence value for each potential 8 grand master, when {priority1, class, variance, priority2} fields happen to have the same value (see 6.3.4). 9 10 6.3.4 clockID subfields 11 12 The 64-bit clockID field is a unique identifier. For stations that have a uniquely assigned 48-bit macAddress, 13 the 64-bit clockID field is derived from the 48-bit MAC address, as illustrated in Figure 6.6. 14 15 16 MSBmacAddress LSB oui ouiDependent 17 18 19 FFFE 16 20 21 ouiextension ouiDependent 22 23 24 Figure 6.6—clockID format 25 26 6.3.4.1 oui: A 24-bit field assigned by the IEEE/RAC (see 3.10.1). 27 28 6.3.4.2 extension: A 16-bit field assigned to encapsulated EUI-48 values. 29 30 6.3.4.3 ouiDependent: A 24-bit field assigned by the owner of the oui field (see 3.10.2). 31 32 6.3.5 Global-time subfield formats 33 34 Time-of-day values within a frame are based on seconds and fractions-of-second values, consistent with 35 IETF specified NTP[B7] and SNTP[B8] protocols, as illustrated in Figure 6.7. 36 37 MSB LSB 38 seconds fraction 39 40 bits 40 bits 40 41 Figure 6.7—Global-time subfield format 42 43 6.3.5.1 seconds: A 40-bit signed field that specifies time in seconds. 44 45 6.3.5.2 fraction: A 40-bit unsigned field that specifies a time offset within each second, in units of 2-40 46 second. 47 48 The concatenation of these fields specifies a 96-bit grandTime value, as specified by Equation 6.1. 49 50 grandTime = seconds + (fraction / 240)(6.1)51 52 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 38 JggDvj2005Apr16/D0.225 WHITE PAPER CONTRIBUTION TO March 5, 2007

1 6.3.6 errorTime format 2 3 The error-time values within a frame are based on a selected portion of a fractions-of-second value, as 4 illustrated in Figure 6.8. The 40-bit signed fraction field specifies the time offset within a second, in units of 5 2-40 second. 6 7 MSB LSB 8 subFraction 9 32 bits 10 11 Figure 6.8—errorTime format 12 13 6.3.7 localTime formats 14 The localTime value within a frame are based on a fractions-of-second value, as illustrated in Figure 6.9. 15 -40 16 The 40-bit fraction field specifies the time offset within the second, in units of 2 second. 17 18 MSB LSB seconds fraction 19 20 8 bits 40 bits 21 Figure 6.9—localTime format 22 23 24 6.4 TimeSyncMaster state machine 25 26 6.4.1 Function 27 28 The time-synchronization service model assumes the presence of one or more grand-master capable entities 29 communicating with a MAC relay, as illustrated on the left side of Figure 6.10. A grand-master capable port 30 may also provide clock-slave functionality, so that any non-selected clock-master capable station can 31 synchronize to the selected grand-master station. 32 33 34 slaveSync 35 slavePoke 36 masterSync 37 MAC relay TimeS 38 IS S S IS ync Sync S 39 e MAC ync (timedSync) e MAC im m 40 T Ti 41 42 43 44 45 link-dependent PHY PHY 46 47 48 Figure 6.10—Clock-master interface model 49 50 The TimeSyncMaster state machine is responsible for monitoring its port’s rxSync indications, receiving 51 MAC-relay frames, and sending MAC-relay frames. The sequencing of this state machine is specified by 52 Table 6.1; details of the computations are specified by the C-code of Annex F. 53 54 NOTE—The remaining text within 6.4 represents cut-and-paste text; extensive modifications are needed.

Contribution from: [email protected]. 39 This is an unapproved working paper, subject to change. AVB BRIDGING JggDvj2005Apr16/D0.225 March 5, 2007

6.4.2 State machine definitions 1 2 NULL 3 A constant indicating the absence of a value that (by design) cannot be confused with a valid value. 4 queue values 5 Enumerated values used to specify shared FIFO queue structures. 6 Q_MR_HOP—The queue identifier associated with MAC frames sent into the relay. 7 Q_RX_MAC—The queue identifier associated with the received MAC frames. 8 Q_RX_SYNC—The queue identifier associated with rxSync, sent from the lower levels. 9 10 6.4.3 State machine variables 11 12 curentTime 13 A shared value representing current time. There is one instance of this variable for each station. 14 Within the state machines of this standard, this is assumed to have two components, as follows: 15 seconds—An 8-bit unsigned value representing seconds. 16 fraction—An 40-bit unsigned value representing portions of a second, in units of 2-40 second. 17 frame 18 The contents of a MAC-supplied frame. 19 info 20 A contents of a lower-level supplied time-synchronization poke indication, including the following: 21 localTime—The value of currentTime associated with the last timeSync packet arrival. 22 frameCount—The value of the like-named field within the last timeSync packet arrival. 23 port 24 A data structure containing port-specific information comprising the following: 25 rxFrame—The last received frame. 26 rxFrameCount—The value of frameCount within the last received frame. 27 rxPokeCount—The value of info.frameCount saved from the last poke indication. 28 rxSnapShot0—The info.snapShot field value from the last receive-port poke indication. 29 rxSnapShot1—The value of the port.rxSnapShot1 field saved from the last poke indication. 30 rxSyncFrame—The value of the previously observed timeSync frame. 31 32 6.4.4 State machine routines 33 34 Dequeue(queue) 35 Returns the next available frame from the specified queue. 36 frame—The next available frame. 37 NULL—No frame available. 38 Enqueue(queue) 39 Places the frame at the tail of the specified queue. 40 MacToRelay(pPtr, frame) 41 Computes the average link-delay, based on neighbor-syntonized timers. 42 The averaged link-delay value is added to the frame, which is then forwarded over the MAC-relay. 43 TimeSyncFrame(frame) 44 Checks the frame contents to identify timeSync frame. 45 TRUE—The frame is a timeSync frame. 46 FALSE—Otherwise. 47 48 49 50 51 52 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 40 JggDvj2005Apr16/D0.225 WHITE PAPER CONTRIBUTION TO March 5, 2007

1 6.4.5 TimeSyncMaster state machine table 2 3 The TimeSyncMaster state machine associates PHY-provided sync information with arriving timeSync 4 frames and forwards adjusted frames to the MAC-relay function, as illustrated in Table 6.1. 5 6 7 Table 6.1—TimeSyncMaster state machine table 8 9 Current Next 10 11 state conditionRow action state 12 13 START (info = Dequeue(Q_CM_SYNC)) 1 port.rxSnapShot1 = port.rxSnapShot0; PASS 14 != NULL port.rxSnapShot0 = currentTime; 15 (frame = Dequeue(Q_RX_MAC)) 2— TEST 16 != NULL 17 —3—START 18 19 TEST !TimeSyncFrame(frame) 4 Enqueue(Q_MR_HOP, frame); START 20 frame.hopCount == LAST_HOP 5 — 21 22 frame.count != 6 port.rxFrameCount = frame.count; 23 port.rxFrameCount+1 24 — 7 port.rxFrame = frame; PASS 25 port.rxFrameCount = frame.count; 26 27 PASS port.rxFrame.frameCount != 8— START port.rxSnapCount 28 29 — 9 Enqueue(Q_RX_ISS, 30 MacToRelay(&port, port.rxFrame)); 31 port.rxLastTime = currentTime; 32 33 34 Row 7.2-1: Update snapshot values on timeSync frame arrival. 35 Row 7.2-2: Initiate inspection of frames received from the lower-level MAC. 36 Row 7.2-3: Wait for the next change-of-state. 37 38 Row 7.2-4: The non-timeSync frames are passed through. 39 Row 7.2-5: Discard obsolete timeSync frames. 40 Row 7.2-6: Non-sequential frames are discarded. 41 Row 7.2-7: Sequential timeSync frames are processed. 42 43 Row 7.2-8: Inhibit processing when the frame and snap-shot counts are different. 44 Row 7.2-9: Broadcast nrevised timeSync frames over the MAC-relay . 45 46 47 48 49 50 51 52 53 54

Contribution from: [email protected]. 41 This is an unapproved working paper, subject to change. AVB BRIDGING JggDvj2005Apr16/D0.225 March 5, 2007

6.5 TimeSyncSlave state machine 1 2 6.5.1 Function 3 4 The time-synchronization service model assumes the presence of one or more clock-slave capable entities 5 communicating with a MAC relay, as illustrated on the right side of Figure 6.11. A listener-only clock-slave 6 capable entity is not required to be grand-master capable. 7 8 9 10 slaveSync 11 slavePoke 12 MAC relay 13 TimeS TimeSy ISS 14 ISS ync MAC (timedSync) MAC n 15 c TimeSync 16 17 18 19 20

link-dependent 21 PHY PHY 22 23 Figure 6.11—Clock-slave interface model 24 25 The TimeSyncSlave state machine is responsible for saving time parameters from relayed timedSync frames 26 and servicing time-sync requests from the attached clock-slave interface. The sequencing of this state 27 machine is specified by Table 6.2; details of the computations are specified by the C-code of Annex F. 28 29 NOTE—The remaining text within 6.5 represents cut-and-paste text; extensive modifications are needed. 30 31 6.5.2 State machine definitions 32 33 NULL 34 A constant indicating the absence of a value that (by design) cannot be confused with a valid value. 35 queue values 36 Enumerated values used to specify shared FIFO queue structures. 37 Q_MR_HOP—The queue identifier associated with frames sent from the relay. 38 Q_TX_MAC—The queue identifier associated with frames sent to the MAC. 39 Q_TX_SYNC—The queue identifier associated with txSync, sent from the lower levels. 40 T10ms 41 A constant the represents a 10 ms value. 42 T50ms 43 A constant the represents a 50 ms value. 44 T100ms 45 A constant the represents a 100 ms value. 46 WORST 47 All ones, the worst-possible grand-master selection preference, equivalent to: (uint64_t)–1 48 49 50 51 52 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 42 JggDvj2005Apr16/D0.225 WHITE PAPER CONTRIBUTION TO March 5, 2007

1 6.5.3 State machine variables 2 3 curentTime 4 A shared value representing current time. There is one instance of this variable for each station. 5 Within the state machines of this standard, this is assumed to have two components, as follows: 6 seconds—An 8-bit unsigned value representing seconds. 7 fraction—An 40-bit unsigned value representing portions of a second, in units of 2-40 second. 8 frame 9 The contents of a MAC-supplied frame. 10 info 11 A contents of a lower-level supplied time-synchronization poke indication, including the following: 12 localTime—The value of currentTime associated with the last timeSync packet arrival. 13 frameCount—The value of the like-named field within the last timeSync packet arrival. 14 port 15 A data structure containing port-specific information comprising the following: 16 txSnapShot—The value of the info.time field saved from the last transmit-port poke indication. 17 txSyncFrame—The value of the next to-be-transmitted timeSync frame. 18 txSeenTime—The currentTime value when the last timeSync frame was received. 19 txSentTime—The currentTime value when the last timeSync frame enqueued for transmission. 20 21 6.5.4 State machine routines 22 23 Dequeue(queue) 24 Returns the next available frame from the specified queue. 25 frame—The next available frame. 26 NULL—No frame available. 27 Enqueue(queue) 28 Places the frame at the tail of the specified queue. 29 FrameToMac(pPtr, frame) 30 Transfers the frame to the MAC, as specified by the C code of Annex F. 31 RelayToFrame(pPtr, frame) 32 Copies a high-preference MAC-relay frame to port storage, as specified by the C code of Annex F. 33 (Low preference MAC-relay frames are simply discarded.) 34 TimeSyncFrame(frame) 35 Checks the frame contents to identify timeSync frame. 36 TRUE—The frame is a timeSync frame. 37 FALSE—Otherwise. 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54

Contribution from: [email protected]. 43 This is an unapproved working paper, subject to change. AVB BRIDGING JggDvj2005Apr16/D0.225 March 5, 2007

6.5.5 TimeSyncSlave state machine table 1 2 The TimeSyncSlave state machine includes a media-dependent timeout, which effectively disconnects a 3 clock-slave port in the absence of received timeSync frames, as illustrated in Table 6.2. 4 5 6 Table 6.2—TimeSyncSlave state machine table 7 8 Current Next 9 10 state conditionRow action state 11 12 START (frame = Dequeue(Q_MR_HOP)) 1— SINK 13 != NULL 14 (currentTime – port.txSentTime) > 2 port.txLastTime = currentTime; SEND 15 T10ms 16 17 (currentTime – port.txSeenTime) > 3 port.bestPreference.precedence = LOW; START 4 * port.txTickTime port.bestPreference.hopCount = 0; 18 port.rxLastTime = currentTime; 19 20 (info = Dequeue(Q_TX_SYNC)) 4 port.txSnapShot = info.localTime; 21 != NULL port.txSnapCount = info.frameCount; 22 —5— 23 24 SINK !TimeSyncFrame(frame) 6 RelayToMac(&port, frame); START 25 RelayToFrame(&port, frame) == 7 port.txSentTime = currentTime; 26 TRUE 27 —8— 28 29 SEND port.txFrame.hopCount == 9— START 30 LAST_HOP 31 — 10 Enqueue(Q_TX_MAC, 32 FrameToMac(&port, port.txFrame)); 33 34 35 Row 7.3-1: Relayed frames are further checked before being processed. 36 Row 7.3-2: Transmit periodic timeSync frames. 37 Row 7.3-3: The absence of relayed timeSync frames forces a port-timeout update. 38 Row 7.3-4: Update snapshot values on timeSync frame departure. 39 Row 7.3-5: Wait for the next change-of-state. 40 41 Row 7.3-6: Non-timeSync frames are retransmitted in the standard fashion. 42 Row 7.3-7: High-precedence timeSync parameters are saved for the next periodic transmission. 43 Row 7.3-8: Low-precedence timeSync parameters are ignored and discarded. 44 45 Row 7.3-9: Discard obsolete timeSync frames. 46 Row 7.3-10: Form the next timeSync frame and enqueue this frame for immediate transmission. 47 48 49 50 51 52 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 44 AVB BRIDGING JggDvj2005Apr16/D0.225 March 5, 2007

7. Duplex-link state machines 1 2 3 7.1 Overview 4 5 This clause specifies the state machines that support duplex-link 802.3-based bridges. The operations are 6 described in an abstract way and do not imply any particular implementations or any exposed interfaces. 7 There is not necessarily a one-to-one correspondence between the primitives and formal procedures and the 8 interfaces in any particular implementation. 9 10 7.2 Link-dependent indications 11 12 The duplex-link TimeSync state machines are provided with snapshots of timeSync-frame reception and 13 transmission times, as illustrated within the left-side port of Figure 7.1. These link-dependent indications 14 can be different for bridge ports attached to alternative media, as illustrated by distinct dotted-line indica- 15 tions within the right-side port of Figure 7.1. 16 17 18 MAC relay 19 TimeS ISS 20 ISS MAC ync (ppSync) eSync MAC 21 im T 22 23 24 rxSync 25 txSync 26

PHY PHY 27 28 29 Figure 7.1—Paths of duplex-link indications 30 31 The rxSync and txSync indications provide a tag (to reliably associate them with MAC-supplied timeSync 32 frames) and a localTime stamp indicating when the associated timeSync frame was received, as illustrated 33 within Figure 7.2. 34 35 36 count seconds fraction 37 tag localTime 38 39 Figure 7.2—Contents of duplex-link indications 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 45 JggDvj2005Apr16/D0.225 WHITE PAPER CONTRIBUTION TO March 5, 2007

1 7.3 timeSync frame format 2 3 7.3.1 timeSync fields 4 5 Duplex-link time-synchronization (timeSync) frames facilitate the synchronization of neighboring 6 clock-master and clock-slave stations. The frame, which is normally sent at 10ms intervals, includes 7 time-snapshot information and the identity of the network’s clock master, as illustrated in Figure 7.3. The 8 gray boxes represent physical layer encapsulation fields that are common across Ethernet frames. 9 10 11 6 da — Destination MAC address 12 13 6 sa — Source MAC address 14 2 protocolType — Distinguishes AVB frames from others 15 1 function — Distinguishes timeSync from other AVB frames 16 1 version — Distinguishes between timeSync frame versions 17 18 14 precedence — Precedence for grand-master selection 19 20 10 grandTime — Transmitter grand-time snapshot (1 cycle delayed) 21 22 4 errorTime — Back-prediction error for grandTime computation 23 — A (sequence number) count of time-sync frames 24 1 frameCount — Hop count from the grand master 25 1 hopCount 26 2 leapSeconds — Additional seconds are introduced as time passes 27 6 localTime — Transmitter local-time snapshot (1 cycle delayed) 28 29 6 thatTxTime — Opposing link’s frame transmission time 30 31 6 thatRxTime — Opposing link’s frame reception time 32 4 fcs — Frame check sequence 33 34 70 bytes total 35 36 Figure 7.3—timeSync frame format 37 38 NOTE— Existing 1588 time-snapshot hardware captures the values between byte-offset 34 and 45 (inclusive). The location of the frameCount field (byte-offset 44) has been adjusted to ensure this field can be similarly captured for the 39 purpose of unambiguously associating timeSync-packet snapshots (that bypass the MAC) and timeSync-packet contents 40 (that pass through the MAC). 41 42 The 48-bit da (destination address), 48-bit sa (source address) field, 16-bit protocolType, 8-bit function, 43 8-bit version, 14-byte precedence, 80-bit grandTime, 32-bit errorTime, 8-bit hopCount, 44 16-bit leapSeconds, and 6-byte localTime field are specified in 6.3. 45 46 7.3.1.1 frameCount: An 8-bit field that is incremented by one between successive timeSync frame 47 transmission. 48 49 7.3.1.2 thatTxTime: A 48-bit field that specifies the local free-running time within the source station, when 50 the previous timeSync frame was transmitted on the opposing link (see 6.3.7). 51 52 7.3.1.3 thatRxTime: A 48-bit field that specifies the local free-running time within the target station, when 53 the previous timeSync frame was received on the opposing link (see 6.3.7). 54

Contribution from: [email protected]. 46 This is an unapproved working paper, subject to change. AVB BRIDGING JggDvj2005Apr16/D0.225 March 5, 2007

7.3.1.4 fcs: A 32-bit (frame check sequence) field that is a cyclic redundancy check (CRC) of the frame. 1 2 7.3.2 Clock-synchronization intervals 3 4 Clock synchronization involves synchronizing the clock-slave clocks to the reference provided by the grand 5 clock master. Tight accuracy is possible with matched-length duplex links, since bidirectional messages can 6 cancel the cable-delay effects. 7 8 Clock synchronization involves the processing of periodic events. Multiple time periods are involved, as 9 listed in Table 7.1. The clock-period events trigger the update of free-running timer values; the period affects 10 the timer-synchronization accuracy and is therefore constrained to be small. 11 12 13 Table 7.1—Clock-synchronization intervals 14 15 Name Time Description 16 17 clock-period < 20 ns Resolution of timer-register value updates 18 19 send-period 10 ms Time between sending of periodic timeSync frames between adjacent stations 20 slow-period 100 ms Time between computation of clock-master/clock-slave rate differences 21 22 23 The send-period events trigger the interchange of timeSync frames between adjacent stations. While a 24 smaller period (1 ms or 100 µs) could improve accuracies, the larger value is intended to reduce costs by 25 allowing computations to be executed by inexpensive (but possibly slow) bridge-resident firmware. 26 27 The slow-period events trigger the computation of timer-rate differences. The timer-rate differences are 28 computed over two slow-period intervals, but recomputed every slow-period interval. The larger 100 ms (as 29 opposed to 10 ms) computation interval is intended to reduce errors associated with sampling of 30 clock-period-quantized slow-period-sized time intervals. 31 32 33 7.4 TimeSyncReceive state machine 34 35 7.4.1 Function 36 37 The TimeSyncReceive state machine is responsible for monitoring its port’s rxSync indications, receiving 38 MAC-relay frames, and sending MAC-relay frames. The sequencing of this state machine is specified by 39 Table 7.2; details of the computations are specified by the C-code of Annex F. 40 41 7.4.2 State machine definitions 42 43 NULL 44 A constant indicating the absence of a value that (by design) cannot be confused with a valid value. 45 queue values 46 Enumerated values used to specify shared FIFO queue structures. 47 Q_MR_HOP—The queue identifier associated with MAC frames sent into the relay. 48 Q_RX_MAC—The queue identifier associated with the received MAC frames. 49 Q_RX_SYNC—The queue identifier associated with rxSync, sent from the lower levels. 50 51 52 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 47 JggDvj2005Apr16/D0.225 WHITE PAPER CONTRIBUTION TO March 5, 2007

1 7.4.3 State machine variables 2 3 curentTime 4 A shared value representing current time. There is one instance of this variable for each station. 5 Within the state machines of this standard, this is assumed to have two components, as follows: 6 seconds—An 8-bit unsigned value representing seconds. 7 fraction—An 40-bit unsigned value representing portions of a second, in units of 2-40 second. 8 frame 9 The contents of a MAC-supplied frame. 10 info 11 A contents of a lower-level supplied time-synchronization poke indication, including the following: 12 localTime—The value of currentTime associated with the last timeSync packet arrival. 13 frameCount—The value of the like-named field within the last timeSync packet arrival. 14 port 15 A data structure containing port-specific information comprising the following: 16 rxFrame—The last received frame. 17 rxFrameCount—The value of frameCount within the last received frame. 18 rxPokeCount—The value of info.frameCount saved from the last poke indication. 19 rxSnapShot0—The info.snapShot field value from the last receive-port poke indication. 20 rxSnapShot1—The value of the port.rxSnapShot1 field saved from the last poke indication. 21 rxSyncFrame—The value of the previously observed timeSync frame. 22 23 7.4.4 State machine routines 24 25 Dequeue(queue) 26 Returns the next available frame from the specified queue. 27 frame—The next available frame. 28 NULL—No frame available. 29 Enqueue(queue) 30 Places the frame at the tail of the specified queue. 31 MacToRelay(pPtr, frame) 32 Computes the average link-delay, based on neighbor-syntonized timers. 33 The averaged link-delay value is added to the frame, which is then forwarded over the MAC-relay. 34 TimeSyncFrame(frame) 35 Checks the frame contents to identify timeSync frame. 36 TRUE—The frame is a timeSync frame. 37 FALSE—Otherwise. 38 39 NOTE—The C code within Annex F has not tracked recent changes to Clause 5 behavioral summary. 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54

Contribution from: [email protected]. 48 This is an unapproved working paper, subject to change. AVB BRIDGING JggDvj2005Apr16/D0.225 March 5, 2007

7.4.5 TimeSyncReceive state machine table 1 2 The TimeSyncReceive state machine associates PHY-provided sync information with arriving timeSync 3 frames and forwards adjusted frames to the MAC-relay function, as illustrated in Table 7.2. 4 5 6 Table 7.2—TimeSyncReceive state machine table 7 8 Current Next 9 10 state conditionRow action state 11 12 START (info = Dequeue(Q_RX_SYNC)) 1 port.rxSnapShot1 = port.rxSnapShot0; PASS 13 != NULL port.rxSnapShot0 = info.localTime; 14 port.rxSnapCount = info.frameCount; 15 (frame = Dequeue(Q_RX_MAC)) 2— TEST 16 != NULL 17 18 —3—START 19 TEST !TimeSyncFrame(frame) 4 Enqueue(Q_MR_HOP, frame); START 20 21 frame.hopCount == LAST_HOP 5 — 22 frame.count != 6 port.rxFrameCount = frame.count; 23 port.rxFrameCount+1 24 — 7 port.rxFrame = frame; PASS 25 port.rxFrameCount = frame.count; 26 27 PASS port.rxFrame.frameCount != 8— START 28 port.rxSnapCount 29 — 9 Enqueue(Q_RX_ISS, 30 MacToRelay(&port, port.rxFrame)); 31 port.rxLastTime = currentTime; 32 33 34 Row 7.2-1: Update snapshot values on timeSync frame arrival. 35 Row 7.2-2: Initiate inspection of frames received from the lower-level MAC. 36 Row 7.2-3: Wait for the next change-of-state. 37 38 Row 7.2-4: The non-timeSync frames are passed through. 39 Row 7.2-5: Discard obsolete timeSync frames. 40 Row 7.2-6: Non-sequential frames are discarded. 41 Row 7.2-7: Sequential timeSync frames are processed. 42 43 Row 7.2-8: Inhibit processing when the frame and snap-shot counts are different. 44 Row 7.2-9: Broadcast nrevised timeSync frames over the MAC-relay . 45 46 47 48 49 50 51 52 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 49 AVB BRIDGING JggDvj2005Apr16/D0.225 March 5, 2007

7.5 TimeSyncTransmit state machine 1 2 7.5.1 Function 3 4 The TimeSyncTransmit state machine is responsible for saving time parameters from relayed timedSync 5 frames and forming timeSync frames for transmission over the attached link. 6 7 7.5.2 State machine definitions 8 9 NULL 10 A constant indicating the absence of a value that (by design) cannot be confused with a valid value. 11 queue values 12 Enumerated values used to specify shared FIFO queue structures. 13 Q_MR_HOP—The queue identifier associated with frames sent from the relay. 14 Q_TX_MAC—The queue identifier associated with frames sent to the MAC. 15 Q_TX_SYNC—The queue identifier associated with txSync, sent from the lower levels. 16 T10ms 17 A constant the represents a 10 ms value. 18 T50ms 19 A constant the represents a 50 ms value. 20 T100ms 21 A constant the represents a 100 ms value. 22 WORST 23 All ones, the worst-possible grand-master selection preference, equivalent to: (uint64_t)–1 24 25 7.5.3 State machine variables 26 27 curentTime 28 A shared value representing current time. There is one instance of this variable for each station. 29 Within the state machines of this standard, this is assumed to have two components, as follows: 30 seconds—An 8-bit unsigned value representing seconds. 31 fraction—An 40-bit unsigned value representing portions of a second, in units of 2-40 second. 32 frame 33 The contents of a MAC-supplied frame. 34 info 35 A contents of a lower-level supplied time-synchronization poke indication, including the following: 36 localTime—The value of currentTime associated with the last timeSync packet arrival. 37 frameCount—The value of the like-named field within the last timeSync packet arrival. 38 port 39 A data structure containing port-specific information comprising the following: 40 txSnapShot—The value of the info.time field saved from the last transmit-port poke indication. 41 txSyncFrame—The value of the next to-be-transmitted timeSync frame. 42 txSeenTime—The currentTime value when the last timeSync frame was received. 43 txSentTime—The currentTime value when the last timeSync frame enqueued for transmission. 44 45 7.5.4 State machine routines 46 47 Dequeue(queue) 48 Returns the next available frame from the specified queue. 49 frame—The next available frame. 50 NULL—No frame available. 51 Enqueue(queue) 52 Places the frame at the tail of the specified queue. 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 50 AVB BRIDGING JggDvj2005Apr16/D0.225 March 5, 2007

FrameToMac(pPtr, frame) 1 Transfers the frame to the MAC, as specified by the C code of Annex F. 2 RelayToFrame(pPtr, frame) 3 Copies a high-preference MAC-relay frame to port storage, as specified by the C code of Annex F. 4 (Low preference MAC-relay frames are simply discarded.) 5 TimeSyncFrame(frame) 6 Checks the frame contents to identify timeSync frame. 7 TRUE—The frame is a timeSync frame. 8 FALSE—Otherwise. 9 10 NOTE—The C code within Annex F has not tracked recent changes to Clause 5 behavioral summary. 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 51 AVB BRIDGING JggDvj2005Apr16/D0.225 March 5, 2007

7.5.5 TimeSyncTransmit state machine table 1 2 The TimeSyncTransmit state machine includes a media-dependent timeout, which effectively disconnects a 3 clock-slave port in the absence of received timeSync frames, as illustrated in Table 7.2. 4 5 6 Table 7.3—TimeSyncTransmit state machine table 7 8 Current Next 9 10 state conditionRow action state 11 12 START (frame = Dequeue(Q_MR_HOP)) 1— SINK 13 != NULL 14 (currentTime – port.txSentTime) > 2 port.txLastTime = currentTime; SEND 15 T10ms 16 17 (currentTime – port.txSeenTime) > 3 port.bestPreference.precedence = LOW; START 4 * port.txTickTime port.bestPreference.hopCount = 0; 18 port.rxLastTime = currentTime; 19 20 (info = Dequeue(Q_TX_SYNC)) 4 port.txSnapShot = info.localTime; 21 != NULL port.txSnapCount = info.frameCount; 22 —5— 23 24 SINK !TimeSyncFrame(frame) 6 RelayToMac(&port, frame); START 25 RelayToFrame(&port, frame) == 7 port.txSentTime = currentTime; 26 TRUE 27 —8— 28 29 SEND port.txFrame.hopCount == 9— START 30 LAST_HOP 31 — 10 Enqueue(Q_TX_MAC, 32 FrameToMac(&port, port.txFrame)); 33 34 35 Row 7.3-1: Relayed frames are further checked before being processed. 36 Row 7.3-2: Transmit periodic timeSync frames. 37 Row 7.3-3: The absence of relayed timeSync frames forces a port-timeout update. 38 Row 7.3-4: Update snapshot values on timeSync frame departure. 39 Row 7.3-5: Wait for the next change-of-state. 40 41 Row 7.3-6: Non-timeSync frames are retransmitted in the standard fashion. 42 Row 7.3-7: High-precedence timeSync parameters are saved for the next periodic transmission. 43 Row 7.3-8: Low-precedence timeSync parameters are ignored and discarded. 44 45 Row 7.3-9: Discard obsolete timeSync frames. 46 Row 7.3-10: Form the next timeSync frame and enqueue this frame for immediate transmission. 47 48 49 50 51 52 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 52 AVB BRIDGING JggDvj2005Apr16/D0.225 March 5, 2007

Annexes 1 2 3 4 Annex A 5 6 (informative) 7 8 Bibliography 9 10 11 1 [B1] IEEE 100, The Authoritative Dictionary of IEEE Standards Terms, Seventh Edition. 12 13 [B2] IEEE Std 802-2002, IEEE Standards for Local and Metropolitan Area Networks: Overview and 14 Architecture. 15 16 [B3] IEEE Std 801-2001, IEEE Standard for Local and Metropolitan Area Networks: Overview and 17 Architecture. 18 19 [B4] IEEE Std 802.1D-2004, IEEE Standard for Local and Metropolitan Area Networks: Media Access 20 Control (MAC) Bridges. 21 22 [B5] IEEE Std 1394-1995, High performance serial bus. 23 24 [B6] IEEE Std 1588-2002, IEEE Standard for a Precision Clock Synchronization Protocol for Networked 25 Measurement and Control Systems. 26 27 [B7] IETF RFC 1305: Network Time Protocol (Version 3) Specification, Implementation and Analysis, 28 2 David L. Mills, March 1992 29 30 [B8] IETF RFC 2030: Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI, D. Mills, 31 October 1996. 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 1IEEE publications are available from the Institute of Electrical and Electronics Engineers, 445 Hoes Lane, P.O. Box 1331, Piscataway, 52 NJ 08855-1331, USA (http://standards.ieee.org/). 53 2IETF publications are available via the World Wide Web at http://www.ietf.org. 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 55 JggDvj2005Apr16/D0.225 WHITE PAPER CONTRIBUTION TO March 5, 2007

1 Annex B 2 3 (informative) 4 5 6 Time-scale conversions 7 8 The synchronized value of grandTime (grand-master time) is based on the Precision Time Protocol (PTP). 9 Time is measured in international seconds since the start of January 1, 1970 Greenwich Mean Time (GMT). 10 Other representations of time can be readily derived from the values of grandTime and the communicated 11 value of leapSeconds, as specified in Table B.1. 12 13 14 Table B.1—Time-scale conversions 15 16 Acronym Name offset Algorithm

17 Row 18 19 PTP Precision Time protocol 1 0 time = grandTime + offset; 20 GPS global positioning satellite 2 –315 964 819 21 22 UTC Coordinated Universal Time 3 TBD time = grandTime + offset – leapSeconds; 23 NTP Network Time Protocol 4 +2 208 988 800 24 25 26 NOTE—The PTP time is commonly used in POSIX algorithms for converting elapsed seconds to the ISO 8601-2000 27 printed representation of time of day. 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54

Contribution from: [email protected]. 56 This is an unapproved working paper, subject to change. AVB BRIDGING JggDvj2005Apr16/D0.225 March 5, 2007

Annex C 1 2 (informative) 3 4 5 Bridging to IEEE Std 1394 6 7 To illustrate the sufficiency and viability of the AVB time-synchronization services, the transformation of 8 IEEE 1394 packets is illustrated. 9 10 11 C.1 Hybrid network topologies 12 13 14 C.1.1 Supported IEEE 1394 network topologies 15 16 This annex focuses on the use of AVB to bridge between IEEE 1394 domains, as illustrated in Figure C.1. 17 The boundary between domains is illustrated by a dotted line, which passes through a SerialBus adapter 18 station. 19 20 21 22 23 24 25 26 IEEE 1394 IEEE 802.3 IEEE 1394 27 28 Figure C.1—IEEE 1394 leaf domains 29 30 C.1.2 Unsupported IEEE 1394 network topologies 31 32 Another approach would be to use IEEE 1394 to bridge between IEEE 802.3 domains, as illustrated in 33 Figure C.2. While not explicitly prohibited, architectural features of such topologies are beyond the scope of 34 this working paper. 35 36 37 38 39 40 41 42 IEEE 802.3 IEEE 1394 IEEE 802.3 43 44 Figure C.2—IEEE 802.3 leaf domains 45 46 47 48 49 50 51 52 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 57 JggDvj2005Apr16/D0.225 WHITE PAPER CONTRIBUTION TO March 5, 2007

1 C.1.3 Time-of-day format conversions 2 3 The difference between AVB and IEEE 1394 time-of-day formats is expected to require conversions within 4 the AVB-to-1394 adapter. Although multiplies are involved in such conversions, multiplications by con- 5 stants are simpler than multiplications by variables. For example, a conversion between AVB and 6 IEEE 1394 involves no more than two 32-bit additions and one 16-bit addition, as illustrated in Figure C.3. 7 8 MSB LSB 9 seconds fraction 10 11 a 12 b = (a*125)>>7; 13 b 14 cycles fraction 15 16 c 17 Notes: d = (c*3)>>6; 18 Two 32-bit additions for b: d 19 b = ((a<<7) - (a<<2) + a) >> 7; One 16-bit additions for d: 20 d = ((c<<2) + c) >> 6; seconds cycleCount cycleOffset 21 22 23 Figure C.3—Time-of-day format conversions 24 25 C.1.4 Grand-master precedence mappings 26 27 Compatible formats allow either an IEEE 1394 or IEEE 802.3 stations to become the network’s grand-mas- 28 ter station. While difference in format are present, each format can be readily mapped to the other, as illus- 29 trated in Figure C.4: 30 31 MSB 32 LSB sp systemIDmacAddressHi pad macAddressLo 33 34 35 36 eui64 37 38 39 0 40 sp systemID macAddressHi pad macAddressLo 41 42 43 Figure C.4—Grand-master precedence mapping 44 45 46 47 48 49 50 51 52 53 54

Contribution from: [email protected]. 58 This is an unapproved working paper, subject to change. AVB BRIDGING JggDvj2005Apr16/D0.225 March 5, 2007

Annex D 1 2 (informative) 3 4 5 Review of possible alternatives 6 7 8 D.1 Clock-synchronization alternatives 9 10 NOTE—This tables has not been reviewed for considerable time and is thus believed to be inaccurate. 11 However, the list is being maintained (until it can be updated) for its usefulness as talking points. 12 13 A comparison of the AVB and IEEE 1588 time-synchronization proposals is summarized in Table D.1. 14 15 16 Table D.1—Protocol comparison 17 18 Properties Descriptions 19 20 stateRow AVB-SG 1588 21 22 timeSync MTU <= Ethernet MTU 1 yes 23 No cascaded PLL whiplash 2 yes 24 25 Number of frame types 3 1 > 1 26 Phaseless initialization sequencing 4 yes no 27 28 Topology 5 duplex links general 29 Grand-master precedence parameters 6 spanning-tree like special 30 31 Rogue-frame settling time, per hop 7 10 ms 1 s 32 Arithmetic complexity numbers 8 64-bit binary 2 x 32-bit binary 33 34 negatives 9 2’s complement signed 35 Master transfer discontinuities rate 10 gradual change 36 37 offset limitations 11 duplex-cable match 38 sampling error 39 Firmware friendly no delay constraints 12 yes 40 41 n-1 cycle sampling 13 yes 42 Time-of-day value precision offset resolution 14 233 ps 43 44 overflow interval 15 136 years 45 46 47 Row 1: The size of a timeSync frame should be no larger than an Ethernet MTU, to minimize overhead. 48 AVB-SG: The size of a timeSync frame is an Ethernet MTU. 49 1588: The size of a timeSync frame is (to be provided). 50 51 Row 2: Cascaded phase-lock loops (PLLs) can yield undesirable whiplash responses to transients. 52 AVB-SG: There are no cascaded phase-lock loops. 53 1588: There are multiple initialization phases (to be provided). 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 59 JggDvj2005Apr16/D0.225 WHITE PAPER CONTRIBUTION TO March 5, 2007

1 Row 3: There number of frame types should be small, to reduce decoding and processing complexities. 2 AVB-SG: Only one form of timeSync frame is used. 3 1588: Multiple forms of timeSync frames are used (to be provided). 4 5 Row 4: Multiple initialization phases adds complexity, since miss-synchronized phases must be managed. 6 AVB-SG: There are no distinct initialization phases. 7 1588: There are multiple initialization phases (to be provided). 8 9 Row 5: Arbitrary interconnect topologies should be supported. 10 AVB-SG: Topologies are constrained to point-to-point full-duplex cabling. 11 1588: Supported topologies include broadcast interconnects. 12 13 Row 6: Grand-master selection precedence should be software configurable, like spanning-tree parameters. 14 AVB-SG: Grand-master selection parameters are based on spanning-tree parameter formats. 15 1588: Grand-master selection parameters are (to be provided). 16 17 Row 7: The lifetime of rogue frames should be minimized, to avoid long initialization sequences. 18 AVB-SG: Rogue frame lifetimes are limited by the 10 ms per-hop update latencies. 19 1588: Rogue frame lifetimes are limited by (to be provided). 20 21 Row 8: The time-of-day formats should be convenient for hardware/firmware processing. 22 AVB-SG: The time-of-day format is a 64-bit binary number. 23 1588: The time-of-day format is a (to be provided). 24 25 Row 9: The time-of-day negative-number formats should be convenient for hardware/firmware processing. 26 AVB-SG: The time-of-day format is a 2’s complement binary number. 27 1588: The time-of-day format is a (to be provided). 28 29 Row 10: The rate discontinuities caused by grand-master selection changes should be minimal. 30 AVB-SG: Smooth rate-change transitions with a 2.5 second time constant is provided. 31 1588: (To be provided). 32 33 Row 11: The time-of-day discontinuities caused by grand-master selection changes should be minimal. 34 AVB-SG: Maximum time-of-day errors are limited by cable-length asymmetry and time-snapshot 35 errors. 36 1588: (To be provided). 37 38 Row 12: Firmware friendly designs should not rely on fast response-time processing. 39 AVB-SG: Response processing time have no significant effect on time-synchronization accuracies. 40 1588: (To be provided). 41 42 Row 13: Firmware friendly designs should not rely on immediate or precomputed snapshot times. 43 AVB-SG: Snapshot times are never used within the current cycle, but saved for next-cycle transmission. 44 1588: (To be provided). 45 46 Row 14: The fine-grained time-of-day resolution should be small, to facilitate accurate synchronization. 47 AVB-SG: The 64-bit time-of-day timer resolution is 233 ps, less than expected snapshot accuracies. 48 1588: (To be provided). 49 50 Row 15: The time-of-day extent should be sufficiently large to avoid overflows within one’s lifetime. 51 AVB-SG: The 64-bit time-of-day timer overflows once every 136 years. 52 1588: (To be provided). 53 54

Contribution from: [email protected]. 60 This is an unapproved working paper, subject to change. AVB BRIDGING JggDvj2005Apr16/D0.225 March 5, 2007

Annex E 1 2 (informative) 3 4 5 Time-of-day format considerations 6 7 To better understand the rationale behind the ‘extended binary’ timer format, various possible formats are 8 described within this annex. 9 10 11 E.1 Possible time-of-day formats 12 13 14 E.1.1 Extended binary timer formats 15 16 The extended-binary timer format is used within this working paper and summarized herein. The 64-bit 17 timer value consist of two components: a 40-bit seconds and 40-bit fraction fields, as illustrated in 18 Figure 5.1. 19 20 MSB LSB 21 seconds fraction 22 40 bits 40 bits 23 24 Figure 5.1—Global-time subfield format 25 26 The concatenation of 40-bit seconds and 40-bit fraction field specifies an 80-bit time value, as specified by 27 Equation E.1. 28 29 time = seconds + (fraction / 240)(E.1)30 Where: 31 seconds is the most significant component of the time value. 32 fraction is the less significant component of the time value. 33 34 E.1.2 IEEE 1394 timer format 35 36 37 An alternate “1394 timer” format consists of secondCount, cycleCount, and cycleOffset fields, as illustrated 38 in Figure E.2. For such fields, the 12-bit cycleOffset field is updated at a 24.576MHz rate. The cycleOffset 39 field goes to zero after 3171 is reached, thus cycling at an 8kHz rate. The 13-bit cycleCount field is 40 incremented whenever cycleOffset goes to zero. The cycleCount field goes to zero after 7999 is reached, thus 41 restarting at a 1Hz rate. The remaining 7-bit secondCount field is incremented whenever cycleCount goes to 42 zero. 43 MSB LSB 44 secondCount cycleCount cycleOffset 45 46 7 bits 13 bits 12 bits 47 48 Figure E.2—IEEE 1394 timer format 49 50 51 52 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 61 JggDvj2005Apr16/D0.225 WHITE PAPER CONTRIBUTION TO March 5, 2007

1 E.1.3 IEEE 1588 timer format 2 3 IEEE Std 1588-2002 timer format consists of seconds and nanoseconds fields components, as illustrated in 4 Figure E.3. The nanoseconds field must be less than 109; a distinct sign bit indicates whether the time repre- 5 sents before or after the epoch duration. 6 7 MSB LSB 8 seconds s nanoSeconds 9 10 Legend: s: sign 11 12 Figure E.3—IEEE 1588 timer format 13 14 15 E.1.4 EPON timer format 16 17 The IEEE 802.3 EPON timer format consists of a 32-bit scaled nanosecond value, as illustrated in 18 Figure E.4. This clock is logically incremented once each 16 ns interval. 19 20 MSB LSB 21 nanoTicks 22 seconds = nanoTicks/62500000 23 24 Figure E.4—EPON timer format 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54

Contribution from: [email protected]. 62 This is an unapproved working paper, subject to change. JggDvj2005Apr16/D0.225, March 5, 2007 WHITE PAPER CONTRIBUTION TO AVB BRIDGING Annex F 1 2 (informative) 3 4 5 C-code illustrations 6 7 NOTE—This annex is provided as a placeholder for illustrative C-code. Locating the C code in one loca- 8 tion (as opposed to distributed throughout the working paper) is intended to simplify its review, extraction, 9 compilation, and execution by critical reviewers. 10 Also, placing this code in a distinct Annex allows the code to be conveniently formatted in 132-character 11 landscape mode. This eliminates the need to truncate variable names and comments, so that the resulting 12 code can be better understood by the reader. 13 14 This Annex provides code examples that illustrate the behavior of AVB entities. The code in this Annex is purely for informational purposes, and should not be construed 15 as mandating any particular implementation. In the event of a conflict between the contents of this Annex and another normative portion of this standard, the other 16 normative portion shall take precedence. 17 18 The syntax used for the following code examples conforms to ANSI X3T9-1995. 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 Contribution from: [email protected]. This is an unapproved working paper, subject to change. 63 JggDvj2005Apr16/D0.225, March 5, 2007 WHITE PAPER CONTRIBUTION TO AVB BRIDGING // ********************************************************************************************************************************* 1 // 1 1 1 1 2 // 1 2 3 4 5 6 7 8 9 0 1 2 3 //3456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012 3 4 // NOTE--The following code is portable with respect to endian ordering, // but (for clarity and simplicity) assumes availability of 64-bit integers. 5 6 #include #include 7 8 // typedef unsigned char uint8_t; // 1-byte unsigned integer // typedef unsigned short uint16_t; // 2-byte unsigned integer 9 // typedef unsigned int uint32_t; // 4-byte unsigned integer 10 // typedef unsigned long long uint64_t; // 8-byte unsigned integer 11 // typedef signed char int8_t; // 1-byte signed integer 12 // typedef signed short int16_t; // 2-byte signed integer // typedef signed int int32_t; // 4-byte signed integer 13 // typedef signed long long int64_t; // 8-byte signed integer 14 15 // ************************************************************************************* 16 // Revise the following timeSync frame parameters as the actual values become known // ************************************************************************************* 17 #define NEIGHBOR 0 // Neighbor multicast address. 18 #define AVB_TYPE 0 // The protocolType for AVB. #define TIME_SYNC 0 // The timeSync function. 19 #define VERSION_A 1 // The timeSync version. 20 #define FALSE 0 21 #define TRUE 1 22 #define TIMEOUT TRUE #define MIN(a, b) ((a) > (b) ? (b) : (a)) // Minimum value definition 23 #define ABS(a) ((a) < 0 ? (-a) : (a)) // Minimum value definition 24 #define ONE ((uint64_t)1 << 40) // Scaled fraction for 1.0 #define PPM250 ((ONE * 250) / 1000000) // Scaled 250PPM fraction. 25 #define CLIP_RATE(x, y) ((x) > ONE+(y) ? ONE+(y) : ((x) < ONE-(y) ? ONE-(y) : (x))) // Clip within specified rate. 26 #define CLIP_SIZE(x, y) ((x) > (y) ? (y) : ((x) < (y) ? (y) : (x))) // Clip within specified value. #define LAST_HOP 255 // Largest hop-count value 27 #define T10ms (ONE / 100) // A 10ms error interval 28 #define THIS_TICK (T10ms) // 10ms Tx timeSync interval #define THAT_TICK (T10ms) // 10ms Rx timeSync interval 29 #define DELAY (2 * ((THIS_TICK) + (THAT_TICK))) // Interpolation assurance 30 #define MASK(bits) (((uint64_t)1 << bits) - 1) #define BITS(type) (8 * sizeof(type)) 31 32 #define FieldToSigned(fPtr, field) \ FrameToValue(fPtr, (uint8_t *)(&(fPtr->field)), sizeof fPtr->field, TRUE) // Convert field to signed 33 #define FieldToUnsigned(fPtr, field) \ 34 FrameToValue(fPtr, (uint8_t *)(&(fPtr->field)), sizeof fPtr->field, FALSE) // Convert field to unsigned #define BigToFrame(value, fPtr, field) \ 35 ValueToFrame(value, fPtr, (uint8_t *)(&(fPtr->field)), sizeof fPtr->field) // Convert field to unsigned 36 #define LongToFrame(value, fPtr, field) \ 37

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 64 JggDvj2005Apr16/D0.225, March 5, 2007 WHITE PAPER CONTRIBUTION TO AVB BRIDGING ValueToFrame(LongToBig(value), fPtr, (uint8_t *)(&(fPtr->field)), sizeof fPtr->field) 1 typedef struct 2 { // Double-precise integers 3 int64_t upper; // Most-significant portion uint64_t lower; // Less significant portion 4 } BigNumber; 5 typedef uint8_t Boolean; 6 typedef uint8_t Class; 7 typedef uint8_t Hops; typedef uint8_t Port; 8 typedef uint16_t Variance; 9 typedef int16_t LeapSeconds; typedef uint32_t Priorities; 10 typedef int64_t LocalTime; 11 typedef BigNumber GrandTime; typedef BigNumber Preference; // Fields {priorities,clockID} 12 typedef BigNumber Precedence; // Fields {preference,hops,port} 13 typedef struct // Time-sync frame parameters 14 { 15 uint8_t da[6]; // Destination address uint8_t sa[6]; // Source address 16 uint8_t protocolType[2]; // Protocol identifier 17 uint8_t function[1]; // Identifies timeSync frame uint8_t version[1]; // Specific format identifier 18 uint8_t precedence[14]; // Grand-master precedence 19 uint8_t grandTime[10]; // Grand-master time (for last frame) uint8_t errorTime[4]; // Cumulative GM-time errors 20 uint8_t frameCount[1]; // Transmit count (sequence number) 21 uint8_t hopCount[1]; // Hop-count from the grand master uint8_t leapSeconds[2]; // Leap seconds compensation 22 uint8_t localTime[6]; // Transmitted timeSync time 23 uint8_t thatTxTime[6]; // Opposite-link transmit time uint8_t thatRxTime[6]; // Opposite-link received time 24 uint8_t fcs[4]; // CRC integrity check 25 } TimeSync; #define sourcePort frameCount // Alternative source identifier 26 27 typedef struct // Port entity state { 28 uint64_t macAddress; // MAC address of the port 29 uint8_t portID; // Destinctive port identifier 30 uint8_t rxPokeCount; // The information-poke count 31 uint8_t rxFrameCount; // The timeSync frame count LocalTime rxSnapShot0; // This frame’s arrival time 32 LocalTime rxSnapShot1; // Past frame’s arrival time 33 LocalTime rxThisTxTime; // Frame transmission time LocalTime rxThisRxTime; // Frame reception time 34 TimeSync rxSyncFrame; // Received timeSync frame 35 LocalTime rxLocalTime0; // Same as rxSnapShot[n-2] LocalTime rxCronyTime0; // Same as frame.localTime[n-2] 36 LocalTime rxLocalTime1; // Same as rxSnapShot[n-1] 37 Contribution from: [email protected]. This is an unapproved working paper, subject to change. 65 JggDvj2005Apr16/D0.225, March 5, 2007 WHITE PAPER CONTRIBUTION TO AVB BRIDGING LocalTime rxCronyTime1; // Same as frame.localTime[n-1] 1 uint64_t rxRated; // Rate difference from neighbor 2 LocalTime txSnapshot; // Transmit frame snapshot 3 uint8_t txFrameCount; // The timeSync frame count. 4 BigNumber txPreference; // Grand-master preference 5 GrandTime txGrandTimed; // Relayed grandTime information 6 LocalTime txLocalTimed; // Relayed localTime information LocalTime txErrorTimed; // Relayed errorTime information 7 GrandTime txGrandTimer; // Back-in-time grandTime estimate 8 LocalTime txLocalTimer; // Back-in-time localTime estimate LocalTime txErrorTimer; // Back-in-time errorTime estimate 9 } PortData; 10 typedef struct // Returned values for TsTx() 11 { 12 uint8_t hop_count; // Updated hop count BigNumber precedence; // Grand-master precedence 13 GrandTime gm_time; // Grand-master time 14 uint16_t leap_seconds; // Leap-seconds for time. } TxFields; 15 16 typedef struct { 17 Hops hop_count; 18 Precedence precedence; GrandTime gm_time; 19 LeapSeconds leap_seconds; 20 } RxFields; 21 22 // Basic interface routines TimeSync MacToRelay(PortData *, TimeSync, Boolean ok); 23 Boolean RelayToFrame(PortData *, TimeSync); 24 void FrameToMac(PortData *, TimeSync *); 25 // A minimalist double-width integer library 26 BigNumber BigAddition(BigNumber, BigNumber); int BigCompare(BigNumber, BigNumber); 27 BigNumber BigShift(BigNumber, int8_t); 28 BigNumber BigSubtract(BigNumber, BigNumber); int64_t MultiplyHi(uint64_t, int32_t); 29 int64_t DivideHi(int64_t, int64_t); 30 // Other routines 31 Precedence FieldsToPrecedence(uint8_t, uint8_t, uint16_t, uint8_t, uint64_t); 32 BigNumber FrameToValue(TimeSync *, uint8_t *, uint16_t, Boolean); BigNumber FormPreference(BigNumber, uint8_t, uint8_t); 33 BigNumber LongToBig(LocalTime); 34 Port PreferenceToPort(Preference); Hops PreferenceToHops(Preference); 35 TimeSync PsTx(PortData *pPtr); 36 void ValueToFrame(BigNumber, TimeSync *, uint8_t *, uint16_t); 37

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 66 JggDvj2005Apr16/D0.225, March 5, 2007 WHITE PAPER CONTRIBUTION TO AVB BRIDGING 1 // ************************************************************************************* // Port-specific routines, called by corresponding state machines. 2 // ************************************************************************************* 3 TimeSync 4 MacToRelay(PortData *pPtr, TimeSync rxFrame, Boolean late) 5 { TimeSync result, *rxPtr, *txPtr; 6 GrandTime grandTime; 7 LocalTime thisDelta, localTime, thatTxTime, thatRxTime; LocalTime nextDelay, cableDelay, error, cronyTime, localDelta, cronyDelta, localDelay, cronyDelay; 8 uint8_t hopCount; 9 assert(pPtr != NULL); 10 rxPtr = &rxFrame; 11 txPtr = &result; result = rxFrame; 12 13 hopCount = FieldToUnsigned(rxPtr, hopCount).lower; // Hops from the GM station. grandTime = FieldToSigned(rxPtr, grandTime); // Grand-master time. 14 cronyTime = FieldToSigned(rxPtr, localTime).lower; // Frame transmission time. 15 thatTxTime = FieldToSigned(rxPtr, thatTxTime).lower; // Opposing transmit time thatRxTime = FieldToSigned(rxPtr, thatRxTime).lower; // Opposing received time. 16 17 assert(hopCount != 255); thisDelta = (pPtr->rxSnapShot1 - pPtr->rxLocalTime0); // Wait a longer interval before. 18 if (thisDelta >= (4 * THIS_TICK)) // computing the rate difference. 19 { localDelta = pPtr->rxSnapShot1 - pPtr->rxLocalTime1; // Neighbor’s timer changes 20 cronyDelta = cronyTime - pPtr->rxCronyTime1; // Neighbor’s timer changes 21 pPtr->rxRated = DivideHi(localDelta, cronyDelta); // Compute rate difference. pPtr->rxLocalTime1 = pPtr->rxLocalTime0; // The local-time snapshot. 22 pPtr->rxCronyTime1 = pPtr->rxCronyTime0; // The grand-master snapshot. 23 pPtr->rxLocalTime0 = pPtr->rxSnapShot1; // The local-time snapshot. pPtr->rxCronyTime0 = localTime; // The grand-master snapshot. 24 } 25 localDelay = (thatTxTime - pPtr->rxSnapShot1); // Looped-response delay. 26 cronyDelay = (localTime - thatRxTime); // Remote-response delay. 27 nextDelay = localDelay - (MultiplyHi(cronyDelay, pPtr->rxRated)); // Computed cable delay cableDelay = MIN(0, nextDelay); // is never negative. 28 grandTime = BigAddition(grandTime, LongToBig(cableDelay + error)); // Delay compensations. 29 hopCount = hopCount+1; // The GM distance. 30 pPtr->rxThisTxTime = localTime; // This link’s sampled values 31 pPtr->rxThisRxTime = pPtr->rxSnapShot1; // go-back on opposing link. BigToFrame(grandTime, txPtr, grandTime); // Compensated GM time. 32 LongToFrame(pPtr->rxSnapShot1, txPtr, localTime); // Observed rx-snapshot time. 33 LongToFrame(pPtr->portID, txPtr, frameCount); // Identifies the sending port. LongToFrame(hopCount+1, txPtr, hopCount); // The GM distance. 34 return(result); 35 } 36 Boolean 37 Contribution from: [email protected]. This is an unapproved working paper, subject to change. 67 JggDvj2005Apr16/D0.225, March 5, 2007 WHITE PAPER CONTRIBUTION TO AVB BRIDGING RelayToFrame(PortData *pPtr, TimeSync rxFrame) 1 { 2 Preference sentPreference, bestPreference; TimeSync *rxPtr; 3 Precedence precedence; 4 GrandTime grandTime; LocalTime localTime, errorTime; 5 uint16_t newCount; 6 uint8_t hopCount, hops, sourcePort; Boolean best, none, same; 7 8 assert(pPtr != NULL); rxPtr = &rxFrame; 9 10 sourcePort = FieldToUnsigned(rxPtr, frameCount).lower; // Source-port value hopCount = FieldToUnsigned(rxPtr, hopCount).lower; // Hop-count parameter 11 precedence = FieldToUnsigned(rxPtr, precedence); // GM precedence value 12 grandTime = FieldToUnsigned(rxPtr, grandTime); // Grand-master time value errorTime = FieldToUnsigned(rxPtr, errorTime).lower; // Grand-master error value 13 localTime = FieldToSigned(rxPtr, localTime).lower; // Neighbor-local time value 14 hops = PreferenceToHops(bestPreference); // Current hopCount value 15 newCount = (hopCount > hops) ? MIN(LAST_HOP, hopCount + 15) : hopCount; // Accelerated loop aging 16 sentPreference = FormPreference(precedence, newCount, sourcePort); // Receive port precedence bestPreference = pPtr->txPreference; // Previous best precedence 17 same = (PreferenceToPort(bestPreference) == sourcePort); // This was preferred port 18 best = (BigCompare(sentPreference, bestPreference) <= 0) && (hopCount != LAST_HOP); // This port is preferred none = (PreferenceToHops(bestPreference) == LAST_HOP); // Obsolete hop count 19 if (same || best || none) // Only the best are taken 20 { pPtr->txPreference = sentPreference; // Update the preference 21 pPtr->txGrandTimed = grandTime; // Save last recorded 22 pPtr->txLocalTimed = localTime; // relayed-frame resident pPtr->txErrorTimed = errorTime; // time and error values 23 return(TRUE); // An acceptance indication 24 } else { // is necessary to reset return(FALSE); // any pending timeouts 25 } 26 } 27 void 28 FrameToMac(PortData *pPtr, TimeSync *txPtr) { 29 GrandTime grandTime, grandTimer; 30 LocalTime moved, delta, grandDelta, grandRated; LocalTime validRated, errorRated, errorTime; 31 uint8_t frameCount; 32 assert(pPtr != NULL && txPtr != NULL); // Code-correctness check 33 moved = (pPtr->txSnapshot - DELAY) - pPtr->txLocalTimer; // Incremental movement 34 delta = pPtr->txLocalTimed - pPtr->txLocalTimer; // Past-to-relay localTime grandDelta = BigSubtract(pPtr->txGrandTimed, pPtr->txGrandTimer).lower; // Past-to-relay grandTime 35 grandRated = DivideHi(grandDelta, delta); // Past-to-relay rating 36 validRated = CLIP_RATE(grandRated, PPM250); // Valid rates within 250PPM grandTimer = (validRated == grandRated) ? // Valid rates can be 37 Contribution from: [email protected]. This is an unapproved working paper, subject to change. 68 JggDvj2005Apr16/D0.225, March 5, 2007 WHITE PAPER CONTRIBUTION TO AVB BRIDGING BigAddition(pPtr->txGrandTimer, LongToBig(MultiplyHi(grandRated, moved))) : // in-the-past interpolated 1 BigAddition(pPtr->txGrandTimed, LongToBig(MultiplyHi(validRated, delta))); // or forced-rate initialized grandTime = BigAddition(grandTimer, LongToBig(DELAY)); // For next transmission 2 errorRated = DivideHi((pPtr->txErrorTimed - pPtr->txErrorTimer), delta); // Past-to-relay rating 3 pPtr->txGrandTimer = grandTimer; // Next grandTimer value 4 pPtr->txLocalTimer = pPtr->txSnapshot - DELAY; // Next localTimer value 5 pPtr->txErrorTimer += MultiplyHi(errorRated, moved); // Next errorTimer value pPtr->txFrameCount = frameCount = pPtr->txFrameCount + 1; // Next sequence number 6 grandTime = BigAddition(grandTimer, LongToBig(DELAY)); // Transmitted grandTime 7 errorTime = pPtr->txErrorTimer + MultiplyHi(DELAY, errorRated - ONE); // Transmitted errorTime 8 LongToFrame(NEIGHBOR, txPtr, da); // Neighbor multicast address 9 LongToFrame(pPtr->macAddress, txPtr, sa); // This port’s MAC address LongToFrame(AVB_TYPE, txPtr, protocolType); // The AVB protocol 10 LongToFrame(TIME_SYNC, txPtr, function); // The timeSync frame in AVB 11 LongToFrame(VERSION_A, txPtr, version); // This version number LongToFrame(frameCount, txPtr, frameCount); // The sequence number 12 BigToFrame(grandTime, txPtr, grandTime); // grandTime at txSnapShot 13 LongToFrame(pPtr->txSnapshot, txPtr, localTime); // Transmitted frame time LongToFrame(errorTime, txPtr, errorTime); // Next errorTime value 14 LongToFrame(pPtr->rxThisTxTime, txPtr, thatTxTime); // Opposing transmit time 15 LongToFrame(pPtr->rxThisRxTime, txPtr, thatRxTime); // Opposing received time } 16 17 // ************************************************************************************* 18 // Alignment and endian-order independent frame-extraction routines. 19 // ************************************************************************************* 20 BigNumber // Extracts field of frame, 21 FrameToValue(TimeSync *fPtr, uint8_t *fieldPtr, uint16_t length, Boolean sign) // as signed or unsigned. { 22 BigNumber result; // The 128-bit signed result. 23 uint8_t *cPtr; int i; 24 25 cPtr = fieldPtr; // Start from first byte if (sign && (int8_t)(cPtr[0]) < 0) // Check for sign extension 26 result.upper = result.lower = (int64_t)-1; // 1’s extended if negative 27 else // otherwise, result.upper = result.lower = 0; // 0’s extended. 28 29 for (i = length - 1; i >= 0; i -= 1, cPtr += 1) // Step through bytes if (length >= 8) 30 result.upper |= *cPtr << (8 * ( i % 8)); // First bytes into upper 31 else result.lower |= *cPtr << (8 * ( i % 8)); // Final byes into lower 32 return(result); // Return BigNumber result 33 } 34 void // Place fields into frame, 35 ValueToFrame(BigNumber value, TimeSync *fPtr, uint8_t *fieldPtr, uint16_t length) // signed properties ignored. { 36 int i; 37 Contribution from: [email protected]. This is an unapproved working paper, subject to change. 69 JggDvj2005Apr16/D0.225, March 5, 2007 WHITE PAPER CONTRIBUTION TO AVB BRIDGING uint8_t *cPtr; 1 2 cPtr = fieldPtr; // First byte location for (i = length - 1; i >= 0; i -= 1, cPtr += 1) // Step through the bytes 3 if (length >= 8) 4 *cPtr = value.upper >> (8 * ( i % 8)); // First bytes from upper else // as well as the 5 *cPtr = value.lower >> (8 * ( i % 8)); // final bytes from lower. 6 } 7 8 // ************************************************************************************* // Supporting library-like routines. 9 // ************************************************************************************* 10 Hops 11 PreferenceToHops(BigNumber preference) 12 { Hops result; 13 14 result = (preference.lower >> BITS(Port)) & MASK(BITS(Hops)); return(result); 15 } 16 Port 17 PreferenceToPort(Precedence preference) 18 { Hops result; 19 20 result = (preference.lower & MASK(BITS(Port))); return(result); 21 } 22 Precedence 23 FieldsToPrecedence(uint8_t priority1, Class class, Variance variance, uint8_t priority2, uint64_t clockID) 24 { BigNumber result; 25 uint32_t fields; 26 fields = (priority1 & MASK(4)); 27 fields <<= BITS(class); 28 fields |= class & MASK(BITS(class)); fields <<= BITS(variance); 29 fields |= variance & MASK(BITS(variance)); 30 fields <<= 4; fields |= priority2 & MASK(4); 31 result.upper = fields; 32 result.lower = clockID; return(result); 33 } 34 BigNumber 35 LongToBig(int64_t number) 36 { BigNumber result; 37 Contribution from: [email protected]. This is an unapproved working paper, subject to change. 70 JggDvj2005Apr16/D0.225, March 5, 2007 WHITE PAPER CONTRIBUTION TO AVB BRIDGING 1 result.lower = number; result.upper = 0; 2 if (number< 0) 3 result.upper -= 1; return(result); 4 } 5 BigNumber 6 FormPreference(BigNumber precedence, Hops hopCount, Port port) 7 { BigNumber result; 8 9 result = BigShift(precedence, -8 * (int)(sizeof(Hops) + sizeof(Port)) ); // Left-shift precedence result.lower |= (hopCount << (8 * sizeof(Port))) | port; // Merge in hopCount&port 10 return(result); // Return the result 11 } 12 BigNumber // Addition of BigNumbers 13 BigAddition(BigNumber a, BigNumber b) { 14 BigNumber result; 15 uint32_t sum, carry; 16 result.lower = sum = a.lower + b.lower; // Addition of the LSBs 17 carry = (sum < a.lower) ? 1 : 0; // Determine the carry. result.upper += a.upper + b.upper + carry; // Addition of the MSBs 18 return(result); 19 } 20 BigNumber 21 BigSubtract(BigNumber a, BigNumber b) { 22 BigNumber result; 23 uint32_t sum, borrow; 24 result.upper = sum = a.lower - b.lower; // Addition of the LSBs 25 borrow = (sum > a.lower) ? 1 : 0; // Determine the borrow. result.upper += a.upper + b.upper - borrow; // Addition of the MSBs 26 return(result); 27 } 28 // Currently written assuming largest is best. 29 int BigCompare(BigNumber a, BigNumber b) 30 { 31 if (a.upper != b.upper) // More significant compare 32 return(a.upper > b.upper ? 1 : -1); 33 if (a.lower != b.lower) // Less significant compare return(a.lower > b.lower ? 1 : -1); 34 return(0); // Comparison returns equal 35 } 36 BigNumber 37 Contribution from: [email protected]. This is an unapproved working paper, subject to change. 71 JggDvj2005Apr16/D0.225, March 5, 2007 WHITE PAPER CONTRIBUTION TO AVB BRIDGING BigShift(BigNumber value, int8_t shift) 1 { 2 BigNumber result; int8_t rightShift, leftShift; 3 4 if (shift == 0) return(value); 5 if (shift > 0) 6 { rightShift = shift; 7 if (rightShift >= 64) 8 { result.lower = (value.upper >> (rightShift % 64)); 9 result.upper = (value.upper > 0 ? 0 : -1); 10 } else { result.lower = (value.upper << (64 - rightShift)) | (value.lower >> rightShift); 11 result.upper = (value.upper >> rightShift); 12 } } else { 13 leftShift = shift; 14 if (leftShift >= 64) { 15 result.upper = value.lower << (leftShift % 64); 16 result.lower = 0; } else { 17 result.upper = (value.upper << leftShift) | (value.lower >> (64 - leftShift)); 18 result.lower = (value.lower << leftShift); } 19 } 20 return(result); } 21 22 int64_t // x = (a * b) >> 40, MultiplyHi(uint64_t value2, int32_t value1) // for all (a,b). 23 { 24 int64_t upper, lower; 25 upper = (value2 >> 40) * value1; // Add the upper 26 lower = ((value2 & (uint64_t)0XFFFFFF) * value1) >> 40; // to the lower return(upper + lower); // for the result. 27 } 28 int64_t // x = (a << 32)/b, for 29 DivideHi(int64_t a, int64_t b) // for b < 2**48 30 { int64_t sum, rem; 31 Boolean flip; 32 flip = ((a ^ b) < 0); // Ensure positive args 33 a = (a < 0) ? -a : a; // for all possible 34 b = (b < 0) ? -b : b; // argument values. 35 sum = a / b; // The normal divide 36 rem = (a % b) << 16; // Prepare the remainder sum = (sum << 16) + rem / b; // Scaled by 2**16 37 Contribution from: [email protected]. This is an unapproved working paper, subject to change. 72 JggDvj2005Apr16/D0.225, March 5, 2007 WHITE PAPER CONTRIBUTION TO AVB BRIDGING rem = (rem % b) << 16; // Prepare the remainder 1 sum = (sum << 16) + rem / b; // Scaled by 2**32 rem = (rem % b) << 8; // Prepare the remainder 2 sum = (sum << 8) + rem / b; // Scaled by 2**40 3 return(flip ? -sum : sum); // Correctly signed result } 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 31 32 33 34 35 36 37 Contribution from: [email protected]. This is an unapproved working paper, subject to change. 73