JggDvj20050416 1 2007-09-26 2 (September 26, 2007) 3 4 5 6 7 8 9 10 11 12 DVJ Perspective on: 13 14 Timing and synchronization for 15 16 time-sensitive applications in bridges 17 18 local area networks 19 20 21 22 Draft 0.728 23 24 Contributors: 25 See page xx. 26 27 28 29 30 Abstract: This working paper provides background and introduces possible higher level concepts 31 for the development of Audio/Video bridges (AVB). 32 Keywords: audio, visual, bridge, , time-sensitive 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 JggDvj20050416/D0.728 WHITE PAPER CONTRIBUTION TO 2007-09-26

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 interpre- tation 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 JggDvj20050416/D0.728 2007-09-26

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 JggDvj20050416/D0.728 WHITE PAPER CONTRIBUTION TO 2007-09-26

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 2005-04-28 DVJ Updates based on 2005Apr27 meeting discussions 23 24 0.085 2005-05-11 DVJ – Updated list-of-contributors, page numbering, editorial fixes. 25 0.088 2005-06-03 DVJ – Application latency scenarios clarified. 26 27 0.090 2005-06-06 DVJ – Misc. editorials in bursting and bunching annex. 28 0.092 2005-06-10 DVJ – Extensive cleanup of Clause 5 subscription protocols. 29 30 0.121 2005-06-24 DVJ – Extensive cleanup of clock-synchronization protocols. 31 0.127 2005-07-04 DVJ – Pacing descriptions greatly enhanced. 32 33 0.200 2007-01-23 DVJ Removal of non time-sync related information, initial layering proposal. 34 0.207 2007-02-01 DVJ Updates based on feedback from Monterey 802.1 meeting. 35 – Common entity terminology; Ethernet type code expanded. 36 37 0.216 2007-02-17 DVJ Updates based on feedback from Chuck Harrison: – linkDelay based only on syntonization to one’s neighbor. 38 – Time adjustments based on observed grandMaster rate differences. 39 40 0.224 2007-03-03 DVJ Updates for whiplash free PLL cascading. 41 0.230 2007-03-05 DVJ Major changes: 42 – simplified back-interpolation 43 – first iteration on an Ethernet-PON interface 44 – client-level clock-master and clock-slave interfaces defined 45 0.243 2007-04-20 DVJ – Revised GrandSync entity illustrations 46 – General cleanup 47 48 0.708 2007-05-30 DVJ – Simulation results provided within an annex – Extensive code revisions for simplicity & clarity. 49 – Interpolation better described. 50 51 0.724 2007-08-11 DVJ Clause 5 updates for clarity. 52 Clause 6 updates include initialize-phase processing. 53 54

Contribution from: [email protected]. 4 This is an unapproved working paper, subject to change. AVB BRIDGING JggDvj20050416/D0.728 2007-09-26

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 TBDs 10 11 Further definitions are needed in the following areas: 12 13 a) Should low-rate leapSeconds occupy space in timeSync frames, if this information rarely changes? 14 15 b) What other (than leapSeconds) low-rate information should be transferred between stations? 16 c) When the grandmaster changes, how should the new grandmaster affect change: 17 1) Transition immediately to the rate of its reference clock. 18 2) Transition slowly (perhaps 1ppm/s) between previous and reference clock rates. 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. 5 JggDvj20050416/D0.728 WHITE PAPER CONTRIBUTION TO 2007-09-26

1 Contents 2 3 List of figures...... 8 4 5 List of tables...... 10 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 Network topologies ...... 26 37 5.4 Information parameters ...... 27 38 5.5 Grandmaster selection ...... 28 39 5.6 Synchronized time distribution...... 31 40 5.7 Comparison to IEEE Std 1588 ...... 36 41 5.8 Time-aware station possibilities...... 39 42 43 6. GrandSync operation ...... 45 44 45 6.1 Overview ...... 45 46 6.2 Service interface primitives...... 46 47 6.3 GrandSync state machine ...... 51 48 49 7. Attached-clock state machines ...... 54 50 51 7.1 Overview ...... 54 52 7.2 ClockMaster service interfaces...... 55 53 7.3 ClockMaster state machine...... 56 54 7.4 ClockSlave service interfaces...... 58

Contribution from: [email protected]. 6 This is an unapproved working paper, subject to change. AVB BRIDGING JggDvj20050416/D0.728 2007-09-26

7.5 ClockSlave state machine...... 60 1 2 8. Ethernet full duplex (EFDX) state machines...... 63 3 4 8.1 Overview ...... 63 5 8.2 efdxClockSync frame format ...... 65 6 8.3 EFDX TimeSync service interfaces ...... 66 7 8.4 TimeSyncRxEfdx state machine ...... 67 8 8.5 TimeSyncTxEfdx state machine...... 71 9 10 9. Wireless state machines...... 74 11 12 10. Ethernet passive optical network (EPON) state machines ...... 75 13 14 10.1 Overview ...... 75 15 10.2 timeSyncEpon frame format...... 77 16 10.3 TimeSyncRxEpon service interface primitives...... 78 17 10.4 TimeSyncRxEpon state machine...... 80 18 10.5 TimeSyncTxEpon state machine...... 82 19 10.6 TimeSyncTxEpon service interface primitives ...... 82 20 10.7 ClockSlave state machine...... 83 21 22 Annex A (informative) Bibliography...... 87 23 24 Annex B (informative) Time-scale conversions ...... 88 25 26 B.1 Overview ...... 88 27 B.2 TAI and UTC...... 88 28 B.3 NTP and GPS ...... 89 29 B.4 Time-scale conversions ...... 90 30 B.5 Time zones and GMT...... 91 31 32 Annex C (informative) Reclocked ClockSync requirements...... 92 33 34 C.1 Cascaded clock considerations...... 92 35 C.2 Sampling offset/rate conversion...... 93 36 37 Annex D (informative) Simulation results (preliminary)...... 96 38 39 D.1 Simulation environment ...... 96 40 D.2 Initialization transients ...... 97 41 D.3 Steady-state interpolation errors...... 98 42 D.4 Steady-state extrapolation errors ...... 99 43 44 Annex E (informative) Bridging to IEEE Std 1394...... 100 45 46 E.1 Hybrid network topologies...... 100 47 48 Annex F (informative) Time-of-day format considerations ...... 102 49 50 F.1 Possible time-of-day formats...... 102 51 52 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 7 JggDvj20050416/D0.728 WHITE PAPER CONTRIBUTION TO 2007-09-26

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—Synchronized-system topologies...... 26 15 16 Figure 5.4—GrandSync service-interface components...... 27 17 Figure 5.5—interval and flags parameters...... 28 18 Figure 5.6—Clock-time synchronization flows ...... 31 19 Figure 5.7—Intermediate-bridge responsibilities...... 33 20 21 Figure 5.8—CLOCK_SLAVE link-delay compensation ...... 34 22 Figure 5.9—CLOCK_MASTER time-sample interpolation ...... 35 23 Figure 5.10—Common snapshot hardware ...... 36 24 Figure 5.11—1588 grandmaster precedence ...... 37 25 26 Figure 5.12—grandTime formats ...... 37 27 Figure 5.13—Frame sequence comparison ...... 38 28 Figure 5.14—Time-aware end station possibilities ...... 39 29 Figure 5.15—Clock-attached time-aware bridge possibilities ...... 40 30 31 Figure 6.1—GrandSync interface model...... 45 32 Figure 6.2—GrandSync service-interface components...... 46 33 Figure 6.3—version subfield format...... 48 34 Figure 6.4—clockID as derived from a 48-bit MAC address...... 48 35 36 Figure 6.5—interval subfields ...... 48 37 Figure 6.6—flags parameters...... 49 38 Figure 6.7—grandTime subfields ...... 49 39 Figure 6.8—extraTime format...... 50 40 41 Figure 6.9—localTime format ...... 50 42 Figure 7.1—ClockMaster interface model...... 55 43 Figure 8.1—EFDX-link interface model...... 63 44 Figure 8.2—efdxClockSync frame format ...... 65 45 46 Figure 10.1—EPON topology ...... 75 47 Figure 10.2—EPON interface model ...... 76 48 Figure 10.3—Format of EPON-dependent times...... 76 49 Figure 10.4—timeSyncEpon frame format ...... 77 50 51 Figure 10.5—tickTime format...... 77 52 Figure C.1—Cascading causes sync-interval bunching ...... 92 53 Figure C.2—Reclocking eliminates sync-interval bunching...... 92 54

Contribution from: [email protected]. 8 This is an unapproved working paper, subject to change. AVB BRIDGING JggDvj20050416/D0.728 2007-09-26

Figure 3.3—Reclocking localizes sync-interval properties...... 93 1 Figure 3.4—Extrapolation for grandTime...... 93 2 3 Figure C.5—Extrapolation for grandTime ...... 94 4 Figure C.6—Interpolation for grandTimeA...... 94 5 Figure C.7—Interpolation of extraTimeD ...... 95 6 Figure D.1—Time-synchronization flows...... 96 7 8 Figure D.2—Startup transients with 8 stations...... 97 9 Figure D.3—Startup transients with 64 stations...... 97 10 Figure D.4—Time interpolation with 8 stations...... 98 11 Figure D.5—Time interpolation with 64 stations...... 98 12 13 Figure D.6—Time extrapolation with 8 stations ...... 99 14 Figure D.7—Time extrapolation with 64 stations ...... 99 15 Figure E.1—IEEE 1394 leaf domains ...... 100 16 Figure E.2—IEEE 802.3 leaf domains ...... 100 17 18 Figure E.3—Time-of-day format conversions...... 101 19 Figure E.4—Grandmaster precedence mapping...... 101 20 Figure F.1—Global-time subfield format...... 102 21 Figure F.2—IEEE 1394 timer format ...... 102 22 23 Figure F.3—IEEE 1588 timer format ...... 103 24 Figure F.4—EPON timer format ...... 103 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 JggDvj20050416 2007-09-26

1 List of tables 2 3 Table 3.1—State table notation example...... 16 4 Table 3.2—Special symbols and operators...... 17 5 6 Table 3.3—Names of fields and sub-fields ...... 18 7 Table 3.4—wrap field values ...... 19 8 Table 5.1—Possible time-aware station alternatives...... 41 9 Table 5.2—Viable time-aware station alternatives...... 42 10 11 Table 5.3—Distinct time-aware station alternatives...... 43 12 Table 5.4—Sufficient time-aware station alternatives ...... 43 13 Table 5.5—Necessary time-aware station alternatives...... 44 14 Table 6.1—GrandSync state table ...... 53 15 16 Table 7.1—ClockMaster state machine table ...... 57 17 Table 7.2—ClockSlave state table...... 62 18 Table 8.1—Clock-synchronization intervals ...... 64 19 Table 8.2—TimeSyncRxEfdx state machine table...... 69 20 21 Table 8.3—TimeSyncTxEfdx state machine table ...... 72 22 Table 10.1—TimeSyncRxEpon state machine table ...... 81 23 Table 10.2—TimeSyncTxEpon state machine table ...... 85 24 Table B.1—Time-scale parameters ...... 88 25 26 Table B.2—Time-scale conversions...... 90 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 JggDvj20050416/D0.728 2007-09-26

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 28 synchronization requirements for time-sensitive applications. This includes applications that involve 29 multiple streams delivered to multiple endpoints. To facilitate the widespread use of bridged LANs for these 30 applications, 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 32 standard leverages the work of the IEEE 1588 WG by developing the additional specifications needed to 33 address 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 JggDvj20050416/D0.728 WHITE PAPER CONTRIBUTION TO 2007-09-26

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 6: GrandSync operation 41 — Clause 7: Attached-clock state machines 42 — Clause 8: Ethernet full duplex (EFDX) state machines 43 — Clause 9: Wireless state machines 44 — Clause 10: Ethernet passive optical network (EPON) state machines 45 — Annex A: Bibliography 46 — Annex B: Time-scale conversions 47 — Annex C: Reclocked ClockSync requirements 48 — Annex D: Simulation results (preliminary) 49 — Annex E: Bridging to IEEE Std 1394 50 — Annex F: Time-of-day format considerations 51 — Annex G: C-code illustrations 52 53 54

Contribution from: [email protected]. 12 This is an unapproved working paper, subject to change. AVB BRIDGING JggDvj20050416/D0.728 2007-09-26

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 JggDvj20050416/D0.728 WHITE PAPER CONTRIBUTION TO 2007-09-26

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

Contribution from: [email protected]. 14 This is an unapproved working paper, subject to change. AVB BRIDGING JggDvj20050416/D0.728 2007-09-26

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 JggDvj20050416/D0.728 WHITE PAPER CONTRIBUTION TO 2007-09-26

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

Contribution from: [email protected]. 16 This is an unapproved working paper, subject to change. AVB BRIDGING JggDvj20050416/D0.728 2007-09-26

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 JggDvj20050416/D0.728 WHITE PAPER CONTRIBUTION TO 2007-09-26

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

Contribution from: [email protected]. 18 This is an unapproved working paper, subject to change. AVB BRIDGING JggDvj20050416/D0.728 2007-09-26

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 JggDvj20050416/D0.728 WHITE PAPER CONTRIBUTION TO 2007-09-26

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

Contribution from: [email protected]. 20 This is an unapproved working paper, subject to change. AVB BRIDGING JggDvj20050416/D0.728 2007-09-26

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

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 21 JggDvj20050416/D0.728 WHITE PAPER CONTRIBUTION TO 2007-09-26

1 To reduce the likelihood of error, the mapping of OUI values to the oui/dependentID fields are illustrated in 2 Figure 3.6. For the purposes of illustration, specific OUI and dependentID example values have been 3 assumed. The two shaded bits correspond to the locallyAdministered and groupAddress bit positions illus- 4 trated in Figure 3.5. 5 6 OUI value: AC-DE-48 7 Organization assigned extension: 23-45-67 8 9 MSB LSB

10 6 AC16 DE16 4816 2316 4516 6716 11 byte transmission order 12 13 Figure 3.6—48-bit MAC address format 14 15 16 3.11 Informative notes 17 18 Informative notes are used in this working paper to provide guidance to implementers and also to supply 19 useful background material. Such notes never contain normative information, and implementers are not 20 required to adhere to any of their provisions. An example of such a note follows. 21 22 NOTE—This is an example of an informative note. 23 24 3.12 Conventions for C code used in state machines 25 26 Many of the state machines contained in this working paper utilize C code functions, operators, expressions 27 and structures for the description of their functionality. Conventions for such C code can be found in 28 Annex G. 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]. 22 This is an unapproved working paper, subject to change. AVB BRIDGING JggDvj20050416/D0.728 2007-09-26

4. Abbreviations and acronyms 1 2 This working paper contains the following abbreviations and acronyms: 3 4 5 AP access point 6 AV audio/video 7 8 AVB audio/video bridging 9 AVB network audio/video bridged network 10 11 BER bit error ratio 12 BMC best master clock 13 14 BMCA best master clock algorithm 15 CRC cyclic redundancy check 16 17 EFDX Ethernet full duplex 18 EPON Ethernet passive optical network 19 20 FIFO first in first out 21 IEC International Electrotechnical Commission 22 23 IEEE Institute of Electrical and Electronics Engineers 24 IETF Internet Engineering Task Force 25 26 ISO International Organization for Standardization 27 ITU International Telecommunication Union 28 29 LAN local area network 30 LSB least significant bit 31 32 MAC medium access control 33 MAN metropolitan area network 34 35 MSB most significant bit 36 OSI open systems interconnect 37 38 PDU protocol data unit 39 PHY physical layer 40 41 PLL phase-locked loop 42 PPM parts per million 43 44 PTP 45 R11V radio 802.11v 46 47 RFC request for comment 48 RPR 49 50 TS time-synchronization 51 VOIP voice over internet protocol 52 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 23 JggDvj20050416/D0.728 WHITE PAPER CONTRIBUTION TO 2007-09-26

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

Contribution from: [email protected]. 24 This is an unapproved working paper, subject to change. AVB BRIDGING JggDvj20050416/D0.728 2007-09-26

5.1.2 Looping topologies 1 2 Bridged Ethernet networks currently have no loops, but bridging extensions are contemplating looping 3 topologies. The time-synchronization protocols assume that looping physical topologies could be present, as 4 illustrated by the dotted-line connection in Figure 5.2, but logical loops would be eliminated by invoking the 5 existing IEEE 802.1D rapid-spanning tree protocols. 6 7 AVB AVB AVB “cloud” 8 device device Peer device is 9 device not AVB capable AVB 10 bridge AVB 11 bridge AVB 12 Ethernet bridge 13 bridge AVB device 14 Half-duplex link 15 device can’t do AVB 16 AVB device 17 AVB Ethernet AVB device device hub 18 19 20 device 21 22 Figure 5.2—Possible looping topology 23 24 Grandmaster-selection, time-synchronization, and link-delay calibration information across the (illustrated 25 as solid lines) active spans. Only link-delay calibration information is assumed to flow across the (illustrated 26 as dotted lines) inactive spans; knowledge of these delays reduces clock-discontinuities in the event of 27 spanning-tree topology changes. 28 29 Separation of AVB devices is driven by the requirements of AVB bridges to support subscription (bandwidth 30 allocation) and pacing of time-sensitive transmissions, as well as time-of-day clock-synchronization. 31 32 33 5.2 Design methodology 34 35 5.2.1 Assumptions 36 37 This working paper specifies a protocol to synchronize independent timers running on separate stations of a 38 distributed networked system, based on concepts specified within IEEE Std 1588-2002. Although a high 39 degree of accuracy and precision is specified, the technology is applicable to low-cost consumer devices. 40 The protocols are based on the following design assumptions: 41 a) Each end station and intermediate bridges provide independent clocks. 42 b) All clocks are accurate, typically to within ±100PPM. 43 44 c) Details of the best time-synchronization protocols are physical-layer dependent. 45 46 5.2.2 Objectives 47 48 With these assumptions in mind, the time synchronization objectives include the following: 49 a) Precise. Multiple timers can be synchronized to within 10’s of nanoseconds. 50 b) Inexpensive. For consumer AVB devices, the costs of synchronized timers are minimal. 51 (GPS, atomic clocks, or 1 PPM clock accuracies would be inconsistent with this criteria.) 52 c) Scalable. The protocol is independent of the networking technology: 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 25 JggDvj20050416/D0.728 WHITE PAPER CONTRIBUTION TO 2007-09-26

1 1) Transmission intervals can be independently specified and optimized, on a per-link basis. 2 2) Long distance links (up to 2 kM) are allowed. 3 d) Plug-and-play. The system topology is self-configuring; no system administrator is required. 4 5 5.2.3 Strategies 6 7 Strategies used to meet these objectives include the following: 8 a) Precision is achieved by calibrating and adjusting grandTime clocks. 9 10 1) Offsets. Offset value adjustments eliminate immediate clock-value errors. 11 2) Rates. Rate value adjustments reduce long-term clock-drift errors. 12 b) Simplicity is achieved by the following: 13 1) Concurrence. Most configuration and adjustment operations are performed concurrently. 14 2) Firmware friendly. Clock offset and rate adjustments can be performed by low-rate firmware; 15 analog PLLs are unnecessary within bridges (although necessary within some applications). 16 3) Frequent. Frequent ~100 Hz interchanges eliminates needs for expensive/precise clocks. 17 18 19 5.3 Network topologies 20 21 Clock synchronization involves streaming of timing information from a grandmaster clock to one or more 22 slave clocks. The synchronization protocols assume a spanning-tree topology, but function correctly on 23 cyclical physical topologies, if spanning-tree protocols (802.1D) have activated only a non-cyclical subset of 24 the physical topology. 25 26 The grandmaster station (GM) provides a time reference to locally attached clock-slave station (S), as 27 illustrated in Figure 5.3a. Bridges synchronize their clock-master (M) ports to their clock-slave (S) port, via 28 internal communications. These clock-master (M) ports typically connect to another bridge’s clock-slave (S) 29 port, or to an attached end-station clock-slave station (ES). 30 31 32 33 (central selection) per-port selection ES M MMMS M ES 34 GrandSync 35 S P GM 36 TS TS ES M M ES LLC LLC 37 MAC relay 38 ES M S Bump Detection state 39 MAC MAC Scanner rxprecedence 40 PHY PHY Legend: rx tx Reject 41 GM grandmaster S slave port 42 M master port ES end-station port 43 primary path secondary path 44 a) Agents along the synchronization path b) Bridge processing 45 46 Figure 5.3—Synchronized-system topologies 47 48 49 In concept, network-wide clock-synchronization protocol starts with the selection of the reference-clock 50 station, called a grandmaster station (oftentimes abbreviated as grandmaster). Every AVB-capable station is 51 grandmaster capable, but only one is selected to become the grandmaster station within each network grand- 52 master selection involves the transmission of ClockSync messages between grandmaster capable stations. 53 54

Contribution from: [email protected]. 26 This is an unapproved working paper, subject to change. AVB BRIDGING JggDvj20050416/D0.728 2007-09-26

In the presence of redundant loops, a bridge port can also be placed in a passive (P) state, wherein it 1 monitors ClockSync messages but does not synchronize its clock to its associated clock-master port. 2 3 After grandmaster selection, time-reference information flows from this selected grandmaster station to 4 attached clock-slave stations. Thus, time-synchronization involve two subservices, as follows: 5 6 a) Selection. Topologies are pruned into spanning tree with the grandmaster at the root (see 5.5). 7 b) Distribution. Synchronized time is distributed through the spanning tree from the root (see 5.6). 8 9 10 5.4 Information parameters 11 12 Clock-synchronization information includes clock-selection parameters (for selecting the grandmaster) and 13 clock-synchronization parameters (for synchronizing between clock-master and clock-slave ports), as 14 illustrated in Figure 5.4. A portion of the clock-synchronization parameters are media-independent and pass 15 across the bridge-internal service interface; the remainder are link-media dependent and used for calibration 16 of clock-master to clock-slave port delays. 17 18 priority clockID precedence 19 20 hops interval flags utcOffset control 21 clock-selection 22 clock-synchronization seconds fraction grandTime 23 24 subfraction extraTime 25 26 secs fraction localTime media-independent service interface 27 media-dependent delay-calibration 28 secs fraction thisTxTime 29 30 secs fraction thatTxTime 31 32 secs fraction thatRxTime 33 34 Figure 5.4—GrandSync service-interface components 35 36 NOTE—Depending on the media specification, the clock-selection and clock-synchronization parameters could be a 37 single ClockSync packet (as currently assumed) or transmitted in distinct frames. The optimal partitioning into frames 38 types (hopefully, no more than two) is an outstanding topic of discussion. 39 The concatenation of priority and clockID values forms a precedence value for the selection of the preferred 40 grandmaster candidate. The concatenation of hops, interval, flags, and utcOffset values provide additional 41 information to the clock-slave devices. 42 43 The {grandTime,extraTime,localTime} triad percolates from the grand-master to the clock-slave stations, 44 with adjustments along the way, to provide clock-slave stations with estimates of the grandmaster’s clock 45 time. The grandTime represents a station’s estimate of the grandmaster’s clock sampled at that stations’s 46 localTime instant. The extraTime value represents a cumulative deviation error that (for the purposes of 47 accuracy and responsiveness) is maintained separately from the grandTime value. 48 49 The remaining media-dependent parameters allow a bridge’s receive-port to calibrate and compensate for 50 delays introduced by the receive link of the span connecting its neighbor. For full-duplex Ethernet, these 51 include thatTxTime and thatRxTime (snapshots taken on opposing-link frames), and thisTxTime (a 52 snapshot taken on the neighbor’s transmission). Different values are applicable to alternative media types. 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 27 JggDvj20050416/D0.728 WHITE PAPER CONTRIBUTION TO 2007-09-26

1 5.5 Grandmaster selection 2 3 Intermediate bridge entities are responsible for providing standard/centralized precedence-selection and 4 media-specific/per-port rejection entities, as illustrated in Figure 5.3b. The central GrandSync prece- 5 dence-selection entity is responsible for selecting and echoing only the best ClockSync messages. The 6 per-port rejection entity is responsible for discarding (unnecessary) reverse-flow ClockSync messages. 7 8 As part of the grandmaster selection process, ClockSync messages are generated by clock-master capable 9 stations; the ClockSync messages transport clock-precedence values (see Figure 5.5) to other stations. Only 10 ClockSync messages with the best observed clock-precedence value are forwarded to neighbor stations, 11 allowing the overall best-precedence value to be ultimately selected and known by all. The station with that 12 best precedence value is called the grandmaster. 13 14 The grandmaster precedence is set to be the concatenation of priority and clockID fields. The value of each 15 station’s priority field can be set by the application, for the purposes of biasing the grandmaster precedence 16 in an application-specific manner. The clockID field is a globally unique number assigned to each station. 17 18 The hops field is incremented by each bridge and thus represents the distance from the grandmaster. The 19 following interval and flags fields consist of multiple components, as illustrated in Figure 5.5. 20 21 MSB 22 LSB interval flags 23 24 25 shift base reserved ––utcChange 26 27 running disruption 28 Figure 5.5—interval and flags parameters 29 30 The interval field specifies the source-station’s nominal interval between ClockSync frames, and is used for 31 timeout purposes. For compactness, its value is encoded as simple floating point value, as summarized 32 below (see 6.2.1.5). 33 value = base << shift; 34 35 The flags field (in conjunction with the utcOffset field) supports the management of leap-second updates and 36 timeouts. The two-bit value of utcChange specifies whether the utcOffset value should be unchanged, 37 incremented, or decremented at the stroke of midnight (see 6.2.1.6). 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54

Contribution from: [email protected]. 28 This is an unapproved working paper, subject to change. AVB BRIDGING JggDvj20050416/D0.728 2007-09-26

5.5.1 Central ClockSync-message processing 1 2 The central/standard GrandSync entity (see Figure 5.3b) is responsible for processing ClockSync PDUs 3 provided by attached ports, as summarized in Equation 5.1. If the ClockSync message precedence equals or 4 exceeds the previously saved sync.precedence value: sync.precedence is updated with the 5 ClockSync-message precedence, the ClockSync-message timeout is cleared, and the ClockSync message is 6 echoed to all bridge ports. A timeout clears the sync.precedence history in the absence of expected (normally 7 periodic) ClockSync messages. 8 9 // Performed by the GrandSync entity (5.1) 10 // Compare(x,y) operates on multiple-precision arguments x and y 11 // The returned integer result is: 1 if x-y > 0 12 0 if x-y == 0 13 -1 if x-y < 0 14 while (FOREVER) { // Check constantly 15 clockSync = Dequeue(GS_RX); // Get ClockSync message 16 if (clockSync != NULL) { // if one is available gsprecedence = Gsprecedence(clockSync); // Form precedence value 17 if (Compare(gsprecedence,sync.precedence) <= 0) { // The best precedence 18 sync.precedence = gsprecedence; // is observed and saved 19 Enqueue(GS_TX, clockSync); // Echoed the PDU to others 20 sync.lastTime = currentTime; // Restart the timeout 21 sync.timeout = GsTimeout(clockSync.interval); // Form precedence value } 22 } 23 if (currentTime >= sync.lastTime + sync.timeout) // Inactivity timeout; 24 grandprecedence = ONES; // clear saved precedence 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. 29 JggDvj20050416/D0.728 WHITE PAPER CONTRIBUTION TO 2007-09-26

1 5.5.2 Per-port received ClockSync-message processing 2 3 The per-port/media-dependent TS.rx entity (see Figure 5.3b) is responsible for processing rxClockSync 4 PDUs provided by attached ports, as summarized in Equation 5.2. If the rxClockSync-PDU precedence 5 equals or exceeds the previously saved port.precedence value: port.precedence is updated with the 6 rxClockSync-PDU precedence and the ClockSync-message timeout is cleared. Regardless, the (media 7 dependent) rxClockSync-PDU is converted to a generic clockSync-PDU and sent to the central GrandSync 8 entity. A timeout clears the port.precedence history in the absence of expected (normally periodic) 9 ClockSync messages. 10 11 // Performed by the TS.receive entity (5.2) 12 while (FOREVER) { // Check constantly clockSync = Dequeue(ES_RX); // Get a ClockSync 13 if (clockSync != NULL) { // if one is available 14 rxprecedence = Rxprecedence(clockSync); // Form precedence value 15 if (Compare(rxprecedence, port.precedence) < 0) { // The best precedence 16 port.precedence = rxprecedence; // is observed and saved 17 port.lastTime = currentTime; // Restart the timeout } 18 Enqueue(GS_RX, EsToGs(rxClockSync)); // Send PDU to GrandSync 19 } 20 if (currentTime >= port.lastTime + rxTimeout) // Inactivity timeout; 21 port.precedence = ONES; // clear saved precedence 22 } 23 24 5.5.3 Per-port transmit ClockSync-message processing 25 26 The per-port TS.rx entity (see Figure 5.3b) is responsible for setting the port state and selectively forwarding 27 clockSync PDUs provided by the GrandSync entity, as summarized in Equation 5.3. If port.precedence 28 compares favorably to the clockSync-PDU (indicating this is the best-precedence port), the port.state is set 29 to CLOCK_SLAVE and ClockSync messages are discard. Otherwise, port.state (and its associated behaviors) 30 are dependent on comparisons between port and to-be-transmitted PDU precedences. 31 // Performed by the TS.transmit entity (5.3) 32 while (FOREVER) { // Check constantly 33 clockSync = Dequeue(GS_TX); // Get received ClockSync 34 if (clockSync != NULL) { // if one is available 35 if (clockSync.hops == HOP_LIMIT) return; // Ignore aged frames 36 g0Precedence = Gsprecedence(clockSync); // Form precedence value gsClockSync.hops += 1; // Increment hop count 37 g1Precedence = Gsprecedence(clockSync); // Form precedence value 38 if (Compare(port.precedence, g0Precedence) <= 0) // Rx precedence is best; 39 port.state = CLOCK_SLAVE, return; // Rx ClockSync and time 40 switch (Compare(g1Precedence, port.precedence)) { // Tx precedence compare 41 case -1: port.state = CLOCK_PASSIVE, return; // Rx ClockSync, ignore time 42 case 1: 43 port.state = CLOCK_MASTER, break; // Tx ClockSync and time 44 case 0: 45 port.state = CLOCK_IDLED, break; // Tx ClockSync, block time 46 } Enqueue(ES_TX, GsToEs(clockSync)); // Transmit the ClockSync 47 } 48 } 49 50 51 52 53 54

Contribution from: [email protected]. 30 This is an unapproved working paper, subject to change. AVB BRIDGING JggDvj20050416/D0.728 2007-09-26

5.6 Synchronized time distribution 1 2 5.6.1 Clock-time synchronization flows 3 4 As background for understanding, consider the flow of clock-time synchronization information within a 5 simple/stable three-bridge topology, as illustrated in Figure 5.6. The clock-time information flows from the 6 selected application-level ClockSource entity (located on the grandmaster station), through intermediate 7 bridges (when present), and terminates at application-level ClockTarget entities. 8 9 10 ClockSource ClockTarget ClockTarget application 11 lower-levels ClockMaster GrandSync ClockSlave GrandSync GrandSync ClockSlave 12 (a) (k) 13 TS (b) TS TS (f) TS TS (j) TS 14 LLC LLC LLC LLC LLC LLC 15 MAC relay (c) (e) MAC relay (g) (i) MAC relay 16 17 MAC MAC MAC MAC MAC MAC 18 PHY PHY PHY PHY PHY PHY (d) (h) 19 LAN LAN span1 span2 20 grandmaster station Intermediate bridge Slave station 21 Figure 5.6—Clock-time synchronization flows 22 23 The clock-master station (containing the ClockSource entity) and the clock-slave station (containing the 24 ClockTarget entity) are illustrated as multipurpose bridges; either could also be end stations (not illustrated). 25 26 Time synchronization yields distributed but closely-matched grandTime values within stations and bridges. 27 No attempt is made to eliminate intermediate jitter with bridge-resident jitter-reducing phase-lock loops 28 (PLLs) but application-level phase locked loops are expected to filter high-frequency jitter from the supplied 29 grandTime values. 30 31 Maintaining an accurate time reference relies on the presence of accurate time-stamp hardware capabilities 32 in or near the media-dependent PHY. A bypass path (illustrated as hashed PHY-to-TS lines within 33 Figure 5.6) allows the time-stamp information to be affiliated with the arriving ClockSync-frame informa- 34 tion, before the PDU is processed by the time-synchronization (TS) entity above the MAC. A similar bypass 35 path is also required at the transmitter, so that an accurate time-stamp of a transmitted frame can be placed 36 into the next-transmitted ClockSync frame. 37 38 This grandmaster station comprises client-level ClockTarget as well as ClockSource entities. The 39 ClockTarget entity allows the application-level clock to be synchronized to the network clock, whenever 40 another station becomes the grandmaster station. (The ClockSource entity on the grandmaster station 41 provides the network-synchronized clock-time reference.) 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. 31 JggDvj20050416/D0.728 WHITE PAPER CONTRIBUTION TO 2007-09-26

1 5.6.2 Steps in the grandTime flow 2 3 Processing steps along the path of the time-synchronization flow of Figure 5.6 include the following: 4 5 a) The ClockSource’s time-reference parameters are converted into a standard format, supplemented 6 with additional parameters (such as the station-local arrival time), packaged into a PDU, and sent to 7 the GrandSync entity. 8 b) The GrandSync entity echoes the time-synchronization information from (what it determines to be) 9 the preferred port. Information from lower-precedence ports is continuously monitored to detect 10 precedence changes (typically due to attach or detach of clock-master capable stations). 11 Clock-time information in PDUs from lower-precedence ports is ignored. 12 c) Clock-time parameters within the echoed PDUs are saved in transmit-port time-value array. When 13 the next ClockSync frame is transmitted, the transmission time is computed based on these array 14 values. The computed transmission time is queued for inclusion in the following ClockSync trans- 15 mission. 16 17 d) The ClockSync frame travels over span1 to the intermediate bridge, incurring a media-dependent 18 transmission delay and arriving at (station-local) time rxTime. 19 e) The (station-local) frame-arrival snapshot value, rxTime, is compensated by subtracting the 20 estimated transmission delay to create an rcTime value, where: 21 rcTime=rxTime-delay0, where delay0 is an estimate of span delay. 22 The grandTime value is extracted from the arriving frame; the {grandTime,rcTime} time-pair 23 values are encapsulated within a PDU; that PDU is sent to the GrandSync entity. 24 f) The GrandSync entity echoes the ClockSync PDU provided by the preferred port, as in step (c). 25 g) Time parameters within the echoed PDUs are saved and eventually transmitted, as in step (d). 26 27 h) The ClockSync frame travels over span2 to the final bridge, incurring a media-dependent 28 transmission delay and arriving at (station-local) time rxTime. 29 i) The (station-local) frame-arrival snapshot value, rxTime, is compensated by subtracting the 30 estimated transmission delay to created an rcTime value, as in step (d). 31 The {grandTime,extraTime,rcTime} affiliations are placed in a PDU and sent to the GrandSync. 32 j) The GrandSync entity echoes the ClockSync PDU from the preferred port, as in step (c). 33 k) The GrandSync’s time-reference parameters are converted from the standard PDU format, 34 unnecessary parameters are discarded, and grandTime is communicated to the GrandSync entity. 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54

Contribution from: [email protected]. 32 This is an unapproved working paper, subject to change. AVB BRIDGING JggDvj20050416/D0.728 2007-09-26

5.6.3 Intermediate bridge entities 1 2 Entities within the intermediate bridge (see Figure 5.6) are responsible for performing three distinct (and 3 largely decoupled) functions, as illustrated in Figure 5.7. A port in the CLOCK_SLAVE state is responsible for 4 compensating for link-transmission delays between this station and its neighbor, as described in 5.6.4. The 5 GrandSync entity is responsible for selecting the ClockSync PDUs from the grandmaster station; only thus 6 selected PDUs are forwarded to transmitter ports. 7 8 b) grandmaster selection 9 10 11 GrandSync 12 13 TS TS LLC LLC 14 15 a) Link-delay compensation MAC relay c) Residence time compensation 16 MAC MAC 17 state == CLOCK_SLAVE state == CLOCK_MASTER PHY PHY 18 19 20 21 Figure 5.7—Intermediate-bridge responsibilities 22 23 Ports in the CLOCK_MASTER state are responsible for revising the GrandSync-supplied ClockSync PDUs to 24 supply the appropriate media-dependent service-interface parameters and/or frames. Since the transmission 25 times and rates may differ from those on the clock-slave port, the CLOCK_MASTER-state port is responsible 26 for interpolating/extrapolating between previously received time samples to generate parameters 27 corresponding to the recently observed transmit-snapshot, as described in 5.6.4 28 29 The concept of a residence time is based on a simplistic assumption that ClockSync frames are received, 30 pass through the station, and are then transmitted on the other port. However, the phase and/or frequency of 31 receive and transmit ClockSync frames may differ. A more general model of value resampling (see 5.6.5) is 32 therefore assumed within this document. 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 JggDvj20050416/D0.728 WHITE PAPER CONTRIBUTION TO 2007-09-26

1 5.6.4 CLOCK_SLAVE link-delay compensation 2 3 When a ClockSync frame is received at a CLOCK_SLAVE-state port, a snapshot of the local localTime is 4 saved. This snapshot time is compensated by the measured link delay. Although these time-delay adjust- 5 ments are media-dependent, the concepts described within this subclause are applicable to most 6 transmission media. 7 8 Processing of the rxTime snapshot to account for link-transmission delays involves the subtraction of a 9 precomputed link delay value, as illustrated in Figure 5.8a. In parallel with this subtraction, the received 10 grandTime value is extracted from the received ClockSync frame. The grandTime and rcTime (the 11 delay-compensated txTime) values provide an accurate time-affiliation pair that is packaged into the PDU 12 and sent to the GrandSync entity. 13 14 15 16 GrandSync that this 17 station station t0 (thatTxTime) 18 TS TS ClockSync[p] LLC LLC 19 {grandTime,rcTime} (thatRxTime)t1 MAC relay 20 grandTime rcTime (thisTxTime)t2 21 Extract ClockSync[q] MAC MAC 22 delay t3 (thisRxTime) 23 rx rxTime PHY PHY 24 receive-port thatTime increasing time thisTime CLOCK_SLAVE CLOCK_MASTER 25 compensation 26 a) Receive-time compensation b) Delay measurements 27 28 Figure 5.8—CLOCK_SLAVE link-delay compensation 29 30 31 Link delays can be accurately precomputed if the delays are constant, accurate time-snapshot values are 32 present, and the clocks are stable. The computations are based on time-stamp measurements performed on 33 distinct ClockSync[p] and following ClockSync[q] frame transmissions, as illustrated in Figure 5.8b. 34 35 These computations are based on the free-running station-local timers, illustrated as thisTime and thatTime. 36 For stability and accuracy, computations use time differences measured with respect to the local timers; 37 constant offset or frequency errors between local and neighbor timers thus have no effect on the accuracy of 38 the computations. 39 40 To improve accuracy, a ratio of local-to-neighbor clock-intervals is precomputed over N (perhaps 16) frame 41 transmissions, as specified in Equation 5.4. For hardware accuracy and simplicity, the t2 transmission-time 42 snapshot are held and transmitted in the following frame. Thus, the t2 snapshot for ClockSync[n] is 43 transmitted within the following ClockSync[n+1] frame. 44 45 #define N 16 // A typical value (5.4) 46 ratio = (t3[n+N]–t3[n]) / (t2[n+N]–t2[n]); // Neighbor’s rate ratio 47 48 For symmetry and accounting simplicity, the t0 transmission-time snapshot is also held and transmitted in 49 the following frame. Affiliated {t0,t1} pairs are then returned in following ClockSync[q] frame transmis- 50 sions. The process is symmetric and thus allows either station to (otherwise independently) compute the 51 average link transmission delay, as specified in Equation 5.5. 52 delay = ((t3[q]–t0[p]) – rateRatio*(t2[q]-t1[p]))/2; // Average link delay (5.5) 53 54

Contribution from: [email protected]. 34 This is an unapproved working paper, subject to change. AVB BRIDGING JggDvj20050416/D0.728 2007-09-26

5.6.5 CLOCK_MASTER time-sample interpolation 1 2 A port in the CLOCK_MASTER state receives the {grandTime,extraTime,rcTime} triads that are echoed by the 3 GrandSync entity. Since these (oftentimes) cannot be transmitted immediately, the received time-triads are 4 saved in a times[] array, for access after the next ClockSync frame transmission, as illustrated in Figure 5.9a. 5 6 7 8 GrandSync grandTime0 9 extraTimeB {grandTime,extraTime,rcTime} slope=1 10 TS TS 11 grandTime1 LLC LLC 12 grandTime MAC relay 13 times[K] backTime 14 MAC MAC Resample averaged 15 PHY PHY 16 txTime extraTimeA extraTime localTime 17 {grandTime1,extraTime1,txTime} rc[n-3] rc[n-2] rc[n-1] rc[n] tx[k] 18 19 a) Per-port resampler components b) Interpolation of saved times[] values 20 21 Figure 5.9—CLOCK_MASTER time-sample interpolation 22 23 24 NOTE—The distribution of distinct times[] storage entities is an architectural model; implementations could emulate the 25 specified behavior by providing access to shared storage and intermediate results. 26 During the next ClockSync frame transmission, a txTime snapshot is produced. The Resample logic operates 27 on the times[] array values to compute the {grandTime1,extraTime1,txTime} time-triad that is placed within 28 the following ClockSync frame transmission, based on interpolation and averaging strategies illustrated in 29 Figure 5.9b. Within Figure 5.9b, rc and tx are abbreviations for rcTime and txTime values, respectively. 30 31 To avoid traditional whiplash and gain-peaking problems associated with cascaded PLLs, an interpolation 32 (as opposed to extrapolation) strategy yields distinct grandTime1 and extraTime1 values. These two times 33 are forwarded independently but are recombined at the ClockTarget entity, so that a single time can be 34 passed to the higher-level application. 35 36 In concept, the computation of grandTime1 involves computing tbTime= txTime-backTime, using tbTime to 37 generate grandTime0 by interpolating between previously saved times[] values, and then generating 38 grandTime1 by extrapolating grandTime0 forward to time txTime (assuming a constant grandTime slope of 39 one). The value of extraTimeB is set to the difference between an extrapolated value (based on saved times[] 40 values) and the computed grandTime1 value. 41 42 Computation of the extraTime1 involves computing extraTimeA, the average of previously saved extraTime 43 values within the times[] array. The sum of extraTimeA (upstream station’s contributions) and extraTimeB 44 (this station’s contribution) yields the extraTime1 value, as summarized in Equation 5.6. 45 46 #define N 4 // Typical value (5.6) 47 rateRatio= // Relative rates 48 (grandTime[n] - grandTime[n-N]) / (rcTime[n] - rcTime[n-N]); // GM’s rate ratio 49 for (extraTimeA= i= 0; i < N; i += 1) // Use samples to 50 extraTimeA += extraTime[n-i]/N; // find an average extraTimeB = backTime * (rateRatio - 1.0); // Contributed value 51 grandTime1 = rc[n] + (txTime - rc[n]) * rateRatio - extraTimeB; // Tx grandTime value 52 extraTime1 = extraTimeA/N + extraTimeB; // Tx extraTime value 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 35 JggDvj20050416/D0.728 WHITE PAPER CONTRIBUTION TO 2007-09-26

1 5.7 Comparison to IEEE Std 1588 2 3 5.7.1 Distinction summary 4 5 Advantageous properties of this protocol that distinguish it from other protocols (including portions of 6 IEEE Std 1588) include the following: 7 a) Synchronization between grandmaster and local clocks occurs at each station: 8 9 1) All bridges have a lightly filtered synchronized image of the grandmaster time. 10 2) End-point stations have a heavily filtered synchronized image of the grandmaster time. 11 b) Time is uniformly represented as scaled integers: seconds and fractions-of-a-second. 12 c) Locally media-dependent synchronized networks don’t require extra time-snapshot hardware. 13 d) Error magnitudes are sublinear with hop distances; PLL-whiplash and O(n2) errors are avoided. 14 e) Multicast (one-to-many) services are not required; only adjacent-neighbor addressing is required. 15 16 f) A relatively frequent 100 Hz (as compared to 1 Hz) update frequency is assumed: 17 1) This rate can be readily implemented (in today’s technology) for minimal cost. 18 2) The more-frequent rate improves accuracy and reduces transient-recovery delays. 19 3) The more-frequent rate reduces transient-recovery delays. 20 g) Only one frame type simplifies the protocols and reduces transient-recovery times. Specifically: 21 1) Cable delay computations, based on local clocks, are unaffected by grandTime transients. 22 2) Rogue frames are quickly scrubbed (2.6 seconds maximum, for 256 stations). 23 3) Drift-induced errors are greatly reduced. 24 25 5.7.2 Common snapshot hardware 26 27 For precise clock tracking, both IEEE 802.1as and IEEE 1588 working groups have assumed the presence of 28 accurate timestamp hardware at their receive and transmit PHY ports. Through cooperative efforts, IEEE 29 802.1as and IEEE 1588 working groups have worked to ensure the same hardware can be used to support 30 both designs, as illustrated in Figure 5.10a. 31 32 33 34 da 35 TS sa 36 sideband PDU protocolID 37 MAC function 38 version bit=0 PHY timeStamp 39 … 40 localTime 41 decode tags tags 34-45 42 … 43 ClockSync or fcs 44 1588 sync frames 45 46 a) Receive-port timestamp HW model b) Common 1588/EFDX frame placement 47 48 Figure 5.10—Common snapshot hardware 49 50 51 In IEEE p1588, the timestamp hardware decodes the protocolID and a selected bit in the following version 52 field, as illustrated in Figure 5.10b (requirements on this bit are specified in 6.2.1.3). Because only one 53 time-stamped frame type (and its transmission rate) is specified, the use of special tags with a matching 54 frame-sequence placement is unnecessary.

Contribution from: [email protected]. 36 This is an unapproved working paper, subject to change. AVB BRIDGING JggDvj20050416/D0.728 2007-09-26

5.7.3 1588 grandmaster precedence 1 2 Within 1588, the grandmaster precedence is based on the concatenation of multiple fields, including 3 clock-master identifiers, as illustrated in Figure 5.11. The gray-shaded values are not supported in this 4 document. 5 6 clockAccuracy 7 clockClass offsetScaledLogVariance 8 priority1 priority2 stepsRemoved portNumber 9 MSB – – – – clockID sourceIdentifier – rxPort LSB 10 sourcePortIdentity 11 precedence resolver 12 precedence 13 14 Figure 5.11—1588 grandmaster precedence 15 16 The clockClass, clockAccuracy, and offsetScaledLogVariance values are sparsely-encoded and 17 application-dependent and thus not supported in this document. Similar functionality can be achieved by 18 higher-level conventions that specify the partitioning/assignment of distinct 16-bit priority values. 19 20 The sourceIdentifier, portNumber, and rxPort values are unnecessary in the presence of a spanning-tree 21 protocol and therefore are not supported within this document. 22 23 5.7.4 grandTime formats 24 25 Within this document, grandTime is represented as a scaled integer seconds value, consisting of 40-bit 26 signed integer (approximately 1,000 generations) and a precise binary fraction, as illustrated in the top of 27 Figure 5.12. All times are located in adjacent bytes, allowing their values to be readily extracted by 28 bridge-resident firmware. All times are represented as binary integers, so no (expensive/imprecise) 29 conversions are necessary before adding and/or multiplying these values. 30 31 ~34,800 years ~1 picosecond 32 seconds fraction grandTime 33 34 GrandSync frame fraction 35 extraTime 36 This proposal 37 Current 1588 38 ~8,900,000 years ~1 nanosecond 39 seconds ? nanoseconds originTimstamp 40 41 scaledNanoseconds correctionField 42 ~16 femptosecond 43 44 Figure 5.12—grandTime formats 45 46 Within 1588, (perceived) legacy compatibility requirements led to an interesting collection of formats, as 47 illustrated in the bottom of Figure 5.12. The originTimestamp has two unused bits in its center, which wastes 48 accuracy and complicates the processing of special-case values. The correctionField further complicates 49 processing requirements, due to its delayed availability and unique overflow-to-seconds behaviors. 50 51 52 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 37 JggDvj20050416/D0.728 WHITE PAPER CONTRIBUTION TO 2007-09-26

1 5.7.5 Frame sequence comparison 2 3 Within this document, all functional are encapsulated into a single slightly-greater-than-minimal frame, 4 slightly greater than the minimal frame size. Each station emits these frames at their link-dependent interval, 5 as illustrated in Figure 5.13. 6 7 8 9 master slave master slave master slave 10 ClockSync Announce select 11 (?flooding?) 12 13 ClockSync Sync 14 Follow_Up 15 Pdelay_Req 16 Delay_Req Pdelay_Resp ⇒delay ⇒delay 17 deltaB Delay_Req 18 Pdelay_Resp_Follow_Up 19 Delay_Resp 20 deltaB 21 Pdelay_Req Pdelay_Req 22 (ClockSync) 23 Pdelay_Resp Pdelay_Resp ⇐delay ⇐delay 24 (ClockSync) Pdelay_Resp_Follow_Up Pdelay_Resp_Follow_Up 25 26 increasing time increasing time increasing time 27 28 29 a) Document proposal b) 1588 asymmetric-active c) 1588 symmetric-inactive 30 31 Figure 5.13—Frame sequence comparison 32 33 34 Within 1588, a variety of function/direction specific frames are transmitted. For an asymmetric-active span, 35 this involves nine separate frame transmissions (as opposed to two), as illustrated in Figure 5.13b. For a 36 symmetric-inactive span, this involves six separate frame transmissions, as illustrated in Figure 5.13c. For 37 this illustration, we assume that both master and slave stations desire to calibrate link delays, to minimize 38 topology-change transients. 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54

Contribution from: [email protected]. 38 This is an unapproved working paper, subject to change. AVB BRIDGING JggDvj20050416/D0.728 2007-09-26

5.8 Time-aware station possibilities 1 2 NOTE—Recent 802.1AS meetings helped clarify the functionality of 802.1AS stations. DVJ has attempted to 3 summarize these findings, in the remainder of this subclause, in response to the 2007-09-18 request. This is highly 4 preliminary text and subject to change. 5 6 5.8.1 Time-aware end-station possibilities 7 8 A time-aware end station can have combinations of ClockSource and ClockTarget components, as illustrated 9 in Figure 5.14. A GPS receiver could have access to an application-level ClockSource resource, as 10 illustrated in Figure 5.14a. An inexpensive audio speaker could have access to an application-level 11 ClockTarget resource, from which the D/A converter clock is derived, as illustrated in Figure 5.14b. A 12 television or stereo receiver could provide both of application-level ClockSource and ClockTarget compo- 13 nents, as illustrated in Figure 5.14c and Figure 5.14d. 14 15 16 17 ClockSource ClockTarget ClockSource reference ClockTarget ClockSource ClockTarget 18 ClockMaster GrandSync GrandSync ClockSlave ClockMaster GrandSync ClockSlave ClockMaster GrandSync ClockSlave 19 20 TS TS TS TS 21 LLC LLC LLC LLC 22 23 24 MAC MAC MAC MAC 25 PHY PHY PHY PHY 26 LAN LAN LAN LAN 27 a) Clock-source b) Clock-target c) Traceable clock d) Not-traceable clock 28 29 Figure 5.14—Time-aware end station possibilities 30 31 32 A traceable ClockSource/ClockTarget station uses an external reference to drive its ClockSource entity, as 33 illustrated in Figure 5.14c. A VCR that derives its time from the sideband PBS signal is one such example. 34 Although its ClockSource is unaffected by the observed network time, its application clock is expected to be 35 derived from the network-supplied clock, so as to minimize timing drifts and errors between stations when 36 another station has been selected to become the grandmaster. 37 38 When not the grandmaster, a non-traceable ClockSource/ClockTarget station sets it ClockSource clock 39 reference based on the time observed at its ClockTarget, as illustrated in Figure 5.14d. A clock radio is one 40 such example. When (and if) this station becomes the grandmaster, its now free-running ClockSource entity 41 provides network time. 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. 39 AVB BRIDGING JggDvj20050416/D0.728 2007-09-26

5.8.2 Time-aware bridge possibilities 1 2 Within the consumer environment, wiring constraints could be simplified by allowing devices to be 3 cascaded. Consumer devices could thus include bridge-relay and end-station capabilities, as illustrated in 4 Figure 5.15. Any of the ClockSource, ClockTarget, and ClockSource/ClockTarget combinations are 5 possible, as illustrated in Figure 5.15a, Figure 5.15b, and Figure 5.15c respectively. A time-aware bridge 6 with neither ClockSource or ClockTarget capabilities (not illustrated) is also possible. 7 8 9 10 ClockSource ClockTarget ClockSource ClockTarget 11

ClockMaster GrandSync GrandSync ClockSlave ClockMaster GrandSync ClockSlave 12 13

TS TS TS TS TS TS 14 LLC LLC LLC LLC LLC LLC 15 MAC relay MAC relay MAC relay 16 17 MAC MAC MAC MAC MAC MAC 18 PHY PHY PHY PHY PHY PHY 19 LAN LAN LAN LAN LAN LAN 20 21 a) Clock source b) Clock target c) Clock source/target 22 23 Figure 5.15—Clock-attached time-aware bridge possibilities 24 25 26 5.8.3 Design option possibilities 27 28 A variety of design options are associated with a time-aware station, as listed below. The P1588 draft 29 currently restricts the subset of possibilities, with only certain allowed combinations of properties, as visible 30 in Table 5.1. 31 a) Ports. Either of the following are possible: 32 1) One. An end-station has only one network port. 33 2) More. A bridge station has two or more network ports. 34 35 b) Reports. Either of the following link-delay mechanisms are possible: 36 1) Peer-to-peer. Each master port calibrates delays to its directly attached slave port. 37 2) End-to-end. Each master port calibrates delays to each of its indirectly attaches slave ports. 38 c) Syncs. The transmission times of sync frames could depend on either of the following: 39 1) Triggered. The clock-slave port’s receipt of a sync frame triggers the transmissions. 40 2) Periodic. Sync frame transmissions occurs periodically, independent of sync-frame receptions. 41 42 d) Announce. Either of the following Announce-forwarding mechanism are possible: 43 1) Filtered. Announce packets are checked; only the best candidate is forwarded to others. 44 2) Periodic. Announce packets are flooded everywhere, regardless of need. 45 e) Source. Either of the following grandmaster-capable clock-source presence selections are possible: 46 1) Present. A ClockSource entity is present. 47 2) Absent. No ClockSource entity is present. 48 49 f) Target. Either of the following clock-target presence selections are possible: 50 1) Present. A ClockTarget entity is present. 51 2) Absent. No ClockTarget entity is present. 52 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 40 AVB BRIDGING JggDvj20050416/D0.728 2007-09-26

Table 5.1—Possible time-aware station alternatives 1 2 3 Relay Clock interfaces 4 Ports Slaves Sync Announce Clock- Clock- 5 reports timing routing Source Target 1588 name 6 Row 7 1 n/a n/a n/a present present 1 Ordinary clock 8 absent present 2 — 9 10 present absent 3 — 11 absent absent 4 (uninteresting) 12 13 >1 1 periodic filtered present present 5 Boundary clock 14 absent present 6 — 15 16 present absent 7 — 17 absent absent 8 — 18 19 flooded present present 9 — 20 absent present 10 — 21 22 present absent 11 — 23 absent absent 12 — 24 25 1 triggered filtered present present 13 — 26 absent present 14 — 27 28 present absent 15 — 29 absent absent 16 — 30 31 flooded present present 17 — 32 absent present 18 — 33 34 present absent 19 — 35 absent absent 20 Peer-to-peer transparent 36 37 >1 triggered filtered present present 21 — 38 absent present 22 — 39 40 present absent 23 — 41 absent absent 24 — 42 43 flooded present present 25 — 44 absent present 26 — 45 46 present absent 27 — 47 absent absent 28 End-to-end transparent 48 49 Notes: 50 n/a is an abbreviation for not applicable 51 52 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 41 AVB BRIDGING JggDvj20050416/D0.728 2007-09-26

Note that the IEEE P1588 design approach appears to constrain particular combinations of features. A 1 preferred 802.1AS design approach removes these application restrictions by eliminating impractical or 2 undesirable options, as discussed below. 3 4 The number of viable 802.1AS options can be quickly reduced by elimination of the uninteresting 5 end-station and non-scalable bridge rows, leaving fewer entries in Table 5.2. 6 7 Table 5.2—Viable time-aware station alternatives 8 9 Relay Clock interfaces 10 11 Ports Sync Announce Clock- Clock- 12 timing routing Source Target 1588 name Row 13 14 1 n/a n/a present present 1 Ordinary clock 15 n/a n/a absent present 2 — 16 17 n/a n/a present absent 3 — 18 >1 periodic filtered present present 4 Boundary clock 19 20 absent present 5 — 21 present absent 6 — 22 23 absent absent 7 — 24 flooded present present 8 — 25 26 absent present 9 — 27 present absent 10 — 28 29 absent absent 11 — 30 triggered filtered present present 12 — 31 32 absent present 13 — 33 present absent 14 — 34 35 absent absent 15 — 36 flooded present present 16 — 37 38 absent present 17 — 39 present absent 18 — 40 41 absent absent 19 Peer-to-peer transparent 42 Notes: 43 n/a is an abbreviation for not applicable 44 45 46 47 48 49 50 51 52 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 42 AVB BRIDGING JggDvj20050416/D0.728 2007-09-26

If the presence/absence of ClockSource and ClockTarget interfaces are recognized as an independent design 1 issues, the number of distinct 802.1AS options is further reduced by elimination of many rows, leaving 2 fewer entries in Table 5.3.. 3 4 Table 5.3—Distinct time-aware station alternatives 5 6 Relay 7 Ports 8 Sync timing Announce routing 802.1AS name 9 Row 10 1 n/a n/a 1 End-station clock 11 >1 periodic filtered 2 Boundary clock 12 13 flooded 3 — 14 triggered filtered 4 — 15 16 flooded 5 Transparent clock 17 Notes: 18 n/a is an abbreviation for not applicable 19 20 21 We recognize that the optimal sync-timing rate is media dependent and may differ for different technologies 22 (802.3 full duplex, 802.3 EPON, or wireless) or for different operating modes of the same technology 23 (normal vs. power-saving). Thus, a boundary-clock like design is necessary. 24 25 If this boundary-clock like design model meets our response-time and cumulative jitter requirements (as 26 initial simulations appear to indicate), then the number of sufficient design alternatives is reduced, leaving 27 fewer entries in Table 5.4.. 28 29 Table 5.4—Sufficient time-aware station alternatives 30 31 32 Relay 33 Ports 34 Sync timing Announce routing 802.1AS name Row 35 1 n/a n/a 1 End-station clock 36 37 >1 periodic filtered 2 Boundary clock 38 flooded 3 — 39 40 Notes: 41 n/a is an abbreviation for not applicable 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. 43 AVB BRIDGING JggDvj20050416/D0.728 2007-09-26

The desire for quick response time, while avoiding broadcast storms in large configurations, appears to favor 1 the use of filtered Announce-packet routing protocols. If the incremental costs filtering Announce packets 2 are confirmed to be insignificant within time-aware bridges, the number of desired 802.1AS design 3 alternatives is further reduced to an easily justifiable set, as illustrated in Table 5.5.. 4 5 Table 5.5—Necessary time-aware station alternatives 6 7 Relay 8 Ports 9 Sync timing Announce routing 802.1AS name 10 Row 11 1 n/a n/a 1 End-station clock. 12 >1 periodic filtered 2 Bridge clock. 13 14 Notes: 15 n/a is an abbreviation for not applicable 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. 44 AVB BRIDGING JggDvj20050416/D0.728 2007-09-26

6. GrandSync operation 1 2 3 6.1 Overview 4 5 6.1.1 GrandSync behavior 6 7 This clause specifies the state machines that specify GrandSync-entity processing. The operations are 8 described in an abstract way and do not imply any particular implementations or any exposed interfaces. 9 There is not necessarily a one-to-one correspondence between the primitives and formal procedures and the 10 interfaces in any particular implementation. 11 12 The GrandSync entity is responsible for monitoring time-sync PDUs via the CLOCK_SYNC.indication service 13 primitive, selectively echoing a subset of these PDUs via the CLOCK_SYNC.response service primitive, as 14 follows: 15 a) When a preferred time-sync related CLOCK_SYNC.indication arrives: 16 1) The grandmaster precedence and port-timeout parameters are saved. 17 2) CLOCK_SYNC.indication parameters are echoed in CLOCK_SYNC.response parameters. 18 3) The arrival time is recorded, for the purpose of monitoring port timeouts. 19 20 b) Arriving non-preferred CLOCK_SYNC.indications are discarded. 21 The intent is to echo only PDUs from the currently selected grandmaster port. 22 c) If the preferred-port timeout is exceeded, the preferred-port parameters are reset. 23 The intent is to restart grandmaster selection based on the remaining candidate ports. 24 25 6.1.2 GrandSync interface model 26 27 The time-synchronization service model assumes the presence of one or more time-synchronized AVB ports 28 communicating with a MAC relay, as illustrated in Figure 6.1. All components are assumed to have access 29 to a common free-running (not adjustable) localTime value. 30 31 GrandSync CLOCK_SYNC.response 32 CLOCK_SYNC.indication 33 34 35 TS TS ~localTime~ 36 LLC LLC MS MS 37 38 MAC relay 39 40 41 ISS ISS 802.n MAC 802.n MAC 42 43 PHY PHY 44 45 LAN LAN 46 Figure 6.1—GrandSync interface model 47 48 A received MAC frame is associated with link-dependent timing information, processed within the 49 TimeSync (TS) state machine, and passed to the GrandSync protocol entity. The GrandSync state machine 50 (illustrated with a darker boundary) is responsible for saving precedence parameters from observed 51 CLOCK_SYNC.indication PDUs and generating CLOCK_SYNC.response PDUs for delivery to other ports. 52 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 45 JggDvj20050416/D0.728 WHITE PAPER CONTRIBUTION TO 2007-09-26

1 The ClockSync information exchanged with the GrandSync entity includes {priority,clockID} grandmas- 2 ter-precedence, {hops,interval,flags,utcOffset} control, and {grandTime,extraTime,localTime} clock-syn- 3 chronization information, as illustrated in Figure 6.2. A clock-slave end-point can filter the sum of 4 grandTime and extraTime values, thereby yielding a more accurate image of the globally synchronized 5 grandTime value. 6 7 priority clockID precedence 8 9 hops interval flags utcOffset control 10 selection parameters synchronization parameters 11 seconds fraction grandTime 12 13 subfraction extraTime 14 secs fraction 15 localTime 16 17 Figure 6.2—GrandSync service-interface components 18 19 6.2 Service interface primitives 20 21 6.2.1 CLOCK_SYNC.indication 22 23 6.2.1.1 Function 24 25 Provides the GrandSync protocol entity with clock-synchronization parameters derived from PDUs sent 26 from attached media-dependent ports. The information is sufficient to identify a single clock-slave port 27 (typically the closest-to-grandmaster port) and to disseminate grandmaster supplied clock-synchronization 28 information to other ports. 29 30 6.2.1.2 Semantics of the service primitive 31 32 The semantics of the primitives are as follows: 33 34 CLOCK_SYNC.indication { 35 destination_address, // Destination address 36 source_address, // Optional 37 priority, // Forwarding priority 38 service_data_unit, // Delivered content 39 { // Contents of the service_data_unit 40 protocolType, // Distinguishes AVB frames from others 41 function, // Distinguishes between ClockSync and other AVB frames 42 version, // Distinguishes between ClockSync frame versions 43 priority, // Precedence for grandmaster selection 44 clockID, // Precedence for grandmaster selection 45 hops, // Distance from the grandmaster station 46 interval, // Nominal ClockSync transmission interval 47 flags, // Control flags 48 utcOffset, // Difference between UTC and TAI timescales 49 grandTime, // Global-time snapshot (1-cycle delayed) 50 extraTime, // Accumulated grandTime error 51 localTime // Local-time snapshot (1-cycle delayed) 52 } 53 } 54

Contribution from: [email protected]. 46 This is an unapproved working paper, subject to change. AVB BRIDGING JggDvj20050416/D0.728 2007-09-26

NOTE—The grandTime field has a range of approximately 36,000 years, far exceeding expected equipment life-spans. 1 The localTime and linkTime fields have a range of 256 seconds, far exceeding the expected ClockSync frame 2 transmission interval. These fields have a 1 pico-second resolution, more precise than the expected hardware snapshot 3 capabilities. Future time-field extensions are therefore unlikely to be necessary in the future. 4 The parameters of the CLOCK_SYNC.indication are described as follows: 5 6 6.2.1.2.1 destination_address: A 48-bit field that allows the frame to be conveniently stripped by its 7 downstream neighbor. The destination_address field contains an otherwise-reserved group 48-bit MAC 8 address (TBD). 9 10 6.2.1.2.2 source_address: A 48-bit field that specifies the local station sending the frame. The 11 source_address field contains an individual 48-bit MAC address (see 3.10), as specified in 9.2 of IEEE Std 12 802-2001. 13 6.2.1.2.3 priority: Specifies the (802.3) priority associated with content delivery. 14 15 6.2.1.2.4 serviceDataUnit: A multi-byte field that provides information content. 16 17 For GrandSync-entity time-sync interchanges, the serviceDataUnit consists of the following subfields: 18 19 6.2.1.2.5 protocolType: A 16-bit field contained within the payload that identifies the format and function of 20 the following fields. 21 6.2.1.2.6 function: An 8-bit field that distinguishes the ClockSync frame from other AVB frame type. 22 23 6.2.1.2.7 version: An 8-bit field that identifies the version number associated with of the following fields. 24 TBD—A more exact definition of version is needed. 25 26 6.2.1.2.8 priority: A 16-bit field that can be configured by the user and overrides the remaining 27 precedence-group field value. 28 6.2.1.2.9 clockID: A 64-bit globally-unique field that ensures a unique precedence value for each potential 29 grandmaster, should the priority field have the same value (see 6.2.1.4). 30 31 6.2.1.2.10 hops: A 16-bit field that represents the number of hops from the grandmaster. 32 33 6.2.1.2.11 interval: An 8-bit pseudo floating-point field that specifies the nominal interval between 34 ClockSync frame transmissions (see 6.2.1.5). 35 6.2.1.2.12 flags: An 8-bit field that warns/triggers changes to the end-station utcOffset value. 36 37 6.2.1.2.13 utcOffset: A 16-bit field that represents the current leap-seconds value. 38 39 NOTE—Due to the reduced-value and non-time-sensitive nature of the utcOffset field, perhaps this could be considered 40 to be a value that is updated through infrequent TLV-like updates. 41 42 6.2.1.2.14 grandTime: An 80-bit field that specifies a grandmaster synchronized time (see 6.2.1.6). 43 6.2.1.2.15 extraTime: A 32-bit field that specifies the cumulative grandmaster synchronized-time error. 44 (Propagating extraTime and grandTime separately eliminates whiplash associated with cascaded PLLs.) 45 46 6.2.1.2.16 localTime: A 48-bit field that specifies the local free-running time within this station, when the 47 previous ClockSync frame was received (see 6.2.1.9). 48 49 50 51 52 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 47 JggDvj20050416/D0.728 WHITE PAPER CONTRIBUTION TO 2007-09-26

1 6.2.1.3 Version format 2 3 For compatibility with existing 1588 time-snapshot, a single bit within the version field is constrained to be 4 zero, as illustrated in Figure 6.3. The remaining versionHi and versionLo fields shall have the values of 0 5 and 1 respectively. 6 7 MSB LSB 8 versionHi0 versionLo 9 8 bits 10 11 Figure 6.3—version subfield format 12 13 6.2.1.4 clockID subfields 14 15 The 64-bit clockID field is a unique identifier. For stations that have a uniquely assigned 48-bit macAddress, 16 the 64-bit clockID field is derived from the 48-bit MAC address, as illustrated in Figure 6.4. 17 18 MSB LSB 19 48-bit MAC address oui ouiDependent 20

21 FFFE16 22 23 24 64-bit clockID ouiextension ouiDependent 25 26 27 Figure 6.4—clockID as derived from a 48-bit MAC address 28 29 6.2.1.4.1 oui: A 24-bit field assigned by the IEEE/RAC (see 3.10.1). 30 6.2.1.4.2 extension: A 16-bit field assigned to encapsulated EUI-48 values. 31 32 6.2.1.4.3 ouiDependent: A 24-bit field assigned by the owner of the oui field (see 3.10.2). 33 34 6.2.1.5 interval subfields 35 36 The interval field specifies the source-station’s nominal interval between ClockSync frames, and is used for 37 timeout purposes. The interval field consists of two subfields, as illustrated in Figure 6.5. 38 39 MSB LSB 40 shift base 41 42 Figure 6.5—interval subfields 43 44 The two subfields specify the interval duration as a simple floating-point like value: 45 value = (shift >= 0) ? (base << shift) : (base >> -shift); 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 JggDvj20050416/D0.728 2007-09-26

6.2.1.6 flags format 1 2 The flags field consists of multiple fields that support the warnings of change indications, as illustrated in 3 Figure 6.6. 4 5 MSB LSB 6 reserved running disruption utcChange 7 8 Figure 6.6—flags parameters 9 10 11 The running bit shall be set to 1 when a the receiver has been initialized (cable-length parameters are OK). 12 Otherwise, the running bit shall be 0. 13 14 The disruption bit shall be set to 1 when a disruption in distribution of the grandTime value is sensed, due to a discontinuity in the grandTime source or the selection of the grandTime source. Otherwise, the disruption 15 bit shall be 0. 16 17 18 The two-bit difference between utcChange and utcOffset, diff=(utcChange-utcOffset)%4, specifies the utcOffset properties, as follows: 19 20 Value Property 21 0 Known and stable 22 1 Increment at midnight UTC 23 2 Decrement at midnight UTC 24 3 Unknown 25 26 The utcOffset field represents the grand-master’s vision of the difference between UTC (wall clock) time 27 and TAI (continuous) times. 28 29 NOTE—When the value of utcOffset is decremented, the event of “midnight” can occur twice, one second apart. The 30 specified/idempotent utcChange encoding (that specifies the changed value, not the change amount), eliminates 31 undesirable effects that might otherwise occur due to such “double-clocking” events. 32 NOTE—To ensure correctness, an exact equation (not simply an English statement) should be provided to ensure 33 proper/consistent updating of UTC time. 34 35 6.2.1.7 grandTime subfields 36 37 The grandTime (time-of-day) field within a frame are based on seconds and fractions-of-second values, 38 consistent with IETF specified NTP[B7] and SNTP[B8] protocols, as illustrated in Figure 6.7. 39 40 MSB LSB 41 seconds fraction 42 40 bits 40 bits 43 44 Figure 6.7—grandTime subfields 45 46 The 40-bit signed seconds field that specifies time in seconds. The 40-bit unsigned fraction field that speci- 47 fies a time offset within each second, in units of 2-40 second. The concatenation of these fields specifies a 48 80-bit grandTime value, as specified by Equation 6.1. 49 grandTime = seconds + (fraction / 240)(6.1)50 51 52 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 49 JggDvj20050416/D0.728 WHITE PAPER CONTRIBUTION TO 2007-09-26

1 6.2.1.8 extraTime 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—extraTime format 12 13 6.2.1.9 localTime format 14 The localTime value within a frame is based on seconds and fractions-of-second field values, as illustrated in 15 -48 16 Figure 6.9. The 48-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 48 bits 21 Figure 6.9—localTime format 22 23 6.2.1.10 When generated 24 25 The CLOCK_SYNC.indication service primitive is generated when new grandmaster selection or clock 26 distribution information is available. Such information could change the selection of the grandmaster or 27 could provide a more-recent {grandTime, localTime} affiliation necessary for maintaining accurate 28 grandmaster synchronized time references. 29 30 6.2.1.11 Effect of receipt 31 32 Receipt of the service primitive by the GrandSync entity triggers an update of the grandmaster selection 33 information. If the grandmaster selection determines the source-port to be the preferred port, its provided 34 {grandTime,localTime} time affiliation is also echoed to the attached entities, via invocation of the 35 CLOCK_SYNC.response service primitive. 36 37 6.2.2 CLOCK_SYNC.response 38 39 6.2.2.1 Function 40 41 Communicates GrandSync protocol-entity supplied information to attached media-dependent ports. The 42 information is sufficient for attached ports to update/propagate grandmaster clock-synchronization 43 parameters. 44 45 6.2.2.2 Semantics of the service primitive 46 47 The semantics of the primitives are as specified for CLOCK_SYNC.indication (see 6.2.1). 48 49 6.2.2.3 When generated 50 51 Generated by the GrandSync entity upon receipt of a time-sync related CLOCK_SYNC.indication from a 52 preferred (by grandmaster selection protocol) source port. 53 54

Contribution from: [email protected]. 50 This is an unapproved working paper, subject to change. AVB BRIDGING JggDvj20050416/D0.728 2007-09-26

6.2.2.4 Effect of receipt 1 2 Receipt of the service primitive by a ClockSlave or TS entity updates entity storage. This storage update 3 allows the destination-port to provide accurate {grandTime,extraTime,localTime} affiliations during later 4 time-sync information transmissions. 5 6 7 6.3 GrandSync state machine 8 9 6.3.1 Function 10 11 The GrandSync state machine is responsible for observing CLOCK_SYNC.indication parameters, selecting 12 PDUs with preferred time-sync content, and echoing this content in following CLOCK_SYNC.response 13 parameters. 14 15 6.3.2 State machine definitions 16 17 6.3.2.1 AVB identifiers: Assigned constants used to specify AVB frame parameters. 18 6.3.2.1.1 AVB_FUNCTION: The function code that corresponds to a time-sync frame. 19 value—TBD. 20 21 6.3.2.1.2 AVB_MCAST: The multicast destination address corresponding to the adjacent neighbor. 22 value—TBD. 23 24 6.3.2.1.3 AVB_TYPE: The protocolType corresponding that uniquely identifies time-sync SDUs. 25 value—TBD. 26 6.3.2.1.4 AVB_VERSION: The number that uniquely identifies this version of time-sync SDUs. 27 value—TBD. 28 29 6.3.2.2 MAX_HOPS: A constant that specifies the largest possible hops value. 30 value—65536 31 32 6.3.2.3 NULL: A constant that (by design) cannot be confused with a valid value. 33 6.3.2.4 ONES: A large constant wherein all binary bits of the numerical representation are set to one. 34 35 6.3.2.5 Q_GS_RX: The queue identifier associated with PDUs sent to the GrandSync. 36 37 6.3.2.6 Q_GS_TX: The queue identifier associated with PDUs sent from the GrandSync. 38 39 6.3.3 State machine variables 40 41 6.3.3.1 ePtr: A pointer to entity-dependent storage, where that storage comprises the following: 42 lastTime—Time of the last best-precedence update, used for timeout purposes. 43 priority, clockID—Copies of like-named fields within the last best-precedence GrandSync PDU. 44 6.3.3.2 localTime: A shared value representing current time within each station. 45 Within the state machines of this standard, this is assumed to have two components, as follows: 46 seconds—An 8-bit unsigned value representing seconds. 47 fraction—An 40-bit unsigned value representing portions of a second, in units of 2-40 second. 48 49 6.3.3.3 new, old: Local variables consisting of concatenated precedence, hops, and port parameters. 50 51 6.3.3.4 rsPtr: A pointer to the service-data-unit portion of rxInfo storage. 52 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 51 JggDvj20050416/D0.728 WHITE PAPER CONTRIBUTION TO 2007-09-26

1 6.3.3.5 rxInfo: Parameters associated with an CLOCK_SYNC.indication (see 6.2.1.2), comprising: 2 destination_address, source_address, service_data_unit 3 Where service_data_unit comprises: 4 protocolType, function, version, priority, clockID, 5 hops, interval, flags, utcOffset, grandTime, extraTime, 6 7 6.3.3.6 rxPtr: A pointer to the rxInfo storage. 8 6.3.3.7 tsPtr: A pointer to the service-data-unit portion of txInfo storage. 9 10 6.3.3.8 txInfo: Parameters associated with an CLOCK_SYNC.response (see 6.2.1.2), comprising: 11 destination_address, source_address, service_data_unit 12 Where service_data_unit comprises: 13 protocolType, function, version, priority, clockID, hops, 14 interval, flags, utcOffset, grandTime, extraTime, 15 16 6.3.3.9 txPtr: A pointer to the txInfo storage. 17 18 6.3.4 State machine routines 19 20 6.3.4.1 ClockSyncSdu(info): Checks the frame contents to identify CLOCK_SYNC.indication frames. 21 TRUE—The frame is a ClockSync frame. 22 FALSE—Otherwise. 23 6.3.4.2 Dequeue(queue): Returns the next available frame from the specified queue. 24 info—The next available parameters. 25 NULL—No parameters available. 26 27 6.3.4.3 Enqueue(queue, info): Places the info parameters at the tail of the specified queue on all ports. 28 29 6.3.4.4 Expand(interval): Expands the 1-byte encoded interval argument into a scaled seconds value. 30 6.3.4.5 Precedence(priority, clockID): 31 Forms a 10-byte precedence by concatenating: 32 priority (2 bytes) 33 clockID (8 bytes) 34 35 6.3.4.6 StationTime(ePtr): Returns the value of the station’s shared local timer, encoded as follows: 36 seconds—A 2-byte unsigned value representing seconds. 37 fraction—A 6-byte unsigned value representing portions of a second, in units of 2-48 second. 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54

Contribution from: [email protected]. 52 This is an unapproved working paper, subject to change. AVB BRIDGING JggDvj20050416/D0.728 2007-09-26

6.3.5 GrandSync state table 1 2 The GrandSync state machine includes a media-dependent timeout, which effectively restarts the grandmas- 3 ter selection process in the absence of received ClockSync frames, as specified by Table 6.1. 4 5 Table 6.1—GrandSync state table 6 7 Current Next 8 9 state conditionRow action state 10 11 START (rxInfo = Dequeue(Q_GS_RX)) 1— TEST 12 != NULL 13 (localTime – ePtr->timer) 2 ePtr->lastTime = localTime; START 14 > 4 * ePtr->interval ePtr->priority = ONES; 15 ePtr->clockID = ONES; 16 — 3 localTime = StationTime(); 17 18 TEST ClockSyncSdu(rsPtr) 4 test = Precedence(rsPtr->priority, rsPtr->clockID); SERVE 19 last = Precedence(ePtr->priority, ePtr->clockID); 20 —5—START21 22 SERVE test <= last 6 ePtr->lastTime = localTime; START 23 ePtr->interval = Expand(rsPtr->interval); ePtr->priority = rsPtr->priority; 24 ePtr->clockID = rsPtr->clockID; 25 ePtr->hops = rsPtr->hops; 26 *txPtr = *rxPtr; 27 txPtr->destination_address = AVB_MCAST; 28 txPtr->source_address = MacAddress(ePtr); tsPtr->protocolType = AVB_TYPE; 29 tsPtr->function = AVB_FUNCTION; 30 tsPtr->version = AVB_VERSION; 31 Enqueue(Q_GS_TX, txPtr); 32 —7— 33 34 35 36 Row 6.1-1: Available indication parameters are processed. 37 Row 6.1-2: The absence of indications forces a timeout, after a entity-dependent delay 38 Row 6.1-3: Wait for changes of conditions. 39 40 Row 6.1-4: Still-active time-sync PDUs are processed further, based on grandmaster precedences. 41 The test and last precedence values consist of {priority,clockID} components. 42 Row 6.1-5: Other PDUs and over-aged indications are discarded. 43 44 Row 6.1-6: Reset the timeout timer; broadcast saved parameters to all ports (including the source). 45 Row 6.1-7: Lower precedence indications are ignored. 46 47 48 49 50 51 52 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 53 JggDvj20050416/D0.728 WHITE PAPER CONTRIBUTION TO 2007-09-26

1 7. Attached-clock state machines 2 3 4 7.1 Overview 5 6 This clause specifies the state machines that specify ClockMaster entity processing. 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 7.1.1 ClockMaster behaviors 12 13 The ClockMaster entity is responsible for forwarding the grandmaster time supplied by the ClockSource via 14 the CLOCK_MASTER.request service primitive, as follows: 15 a) A count value (that is incremented in sequential CLOCK_MASTER.request PDUs) is checked. 16 b) The grandmaster time parameter within the CLOCK_SYNC.response[n+1] PDU is associated with 17 the CLOCK_SYNC.response[n] PDU arrival time. 18 c) The CLOCK_SYNC.response parameters are supplemented to form a CLOCK_SYNC.response PDU, 19 which is then passed to the GrandSync entity. 20 21 7.1.2 ClockSlave behaviors 22 23 The ClockSlave entity is responsible for extracting the grandmaster time from CLOCK_SYNC.indications and 24 supplying the current value to the ClockTarget entity through the CLOCK_SLAVE service interfaces, as 25 follows: 26 27 a) Grandmaster time samples are extracted from GrandSync-supplied CLOCK_SYNC.response PDUs, 28 and saved for computing grandmaster times in following CLOCK_SLAVE.indication PDUs. 29 b) When triggered by a CLOCK_SLAVE.request indication, a CLOCK_SLAVE.indication PDU is 30 delivered to the ClockTarget state machine. That returned CLOCK_SLAVE.indication PDU supplies 31 the grandmaster time associated with the CLOCK_SLAVE.request invocation time. 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]. 54 This is an unapproved working paper, subject to change. AVB BRIDGING JggDvj20050416/D0.728 2007-09-26

7.1.3 ClockMaster interface model 1 2 The time-synchronization service model assumes the presence of one or more grandmaster capable entities 3 communicating with the GrandSync state machine, as illustrated on the left side of Figure 7.1. Most 4 grandmaster capable ports are expected to also provide clock-slave functionality, so that any non-selected 5 grandmaster-capable station can synchronize to the selected grandmaster station. However, a station may 6 have only ClockSlave (not ClockMaster) capabilities. 7 8 ClockSource ClockTarget 9 CLOCK_MASTER.request 10 CLOCK_SERVE.request CLOCK_SLAVE.request 11 CLOCK_SERVE.indication CLOCK_SLAVE.response 12 ClockMaster GrandSync ClockSlave 13 14 15 16 TS TS ~localTime~ 17 LLC LLC 18 MS MS 19 MAC relay 20 21 22 ISS ISS 23 802.n MAC 802.n MAC 24 PHY PHY 25 26 LAN LAN 27 28 Figure 7.1—ClockMaster interface model 29 30 The clock-master ClockMaster state machine (illustrated with an italics name and darker boundary) is 31 responsible for monitoring its port’s CLOCK_MASTER.request PDUs and sending CLOCK_SYNC.indication 32 PDUs. The sequencing of this state machine is specified by Table 7.1. 33 34 The ClockSlave state machine (illustrated with an italics name and darker boundary) is responsible for 35 saving time parameters from echoed CLOCK_SYNC.response frames and servicing CLOCK_MASTER.request 36 PDUs supplied by the associated clock-slave interface. The sequencing of this state machine is specified by 37 Table 7.2. 38 39 The time-synchronization service model assumes the presence of one or more clock-slave capable time-sync 40 entities communicating with a GrandSync protocol entity, as illustrated on the top-side of Figure 7.1. A 41 non-talker clock-slave capable entity is not required to be grandmaster capable. 42 43 7.2 ClockMaster service interfaces 44 45 7.2.1 Shared service interfaces 46 47 The ClockMaster entity is coupled to the bridge ports TS entities via the defined time-sync related 48 CLOCK_SYNC.indication service interface (see 6.2.1). 49 50 51 52 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 55 JggDvj20050416/D0.728 WHITE PAPER CONTRIBUTION TO 2007-09-26

1 7.2.2 CLOCK_SOURCE.request service interface 2 3 7.2.2.1 Function 4 5 Provides the ClockMaster entity with clock-synchronization parameters derived from the reference clock. 6 The information is sufficient to provide the ClockMaster with accurate {grandTime,localTime} associations. 7 8 7.2.2.2 Semantics of the service primitive 9 10 The semantics of the primitives are as follows: 11 12 CLOCK_MASTER.request { 13 interval, // Nominal ClockSync transmission interval 14 flags, // Control flags 15 utcOffset, // Difference between UTC and TAI timescales 16 grandTime, // Global-time snapshot 17 } 18 19 The parameters of the CLOCK_MASTER.request service-interface primitive are described as follows: 20 21 7.2.2.2.1 interval: An 8-bit pseudo floating-point field that specifies the nominal interval between 22 ClockSync frame transmissions (see 6.2.1.5). 23 7.2.2.2.2 flags: An 8-bit field that warns/triggers changes to the end-station utcOffset value. 24 25 7.2.2.2.3 utcOffset: A 16-bit field that represents the current difference between UTC and TAI time scales 26 (leap-seconds). 27 28 7.2.2.2.4 grandTime: An 80-bit field that specifies the ClockSource provided grandmaster time when the 29 CLOCK_MASTER.request interface was invoked (see 6.2.1.7). 30 31 7.2.2.3 When generated 32 33 The CLOCK_MASTER.request service primitive is invoked by a client-resident ClockSource entity. The intent 34 is to provide the ClockMaster with continuous/accurate updates from a ClockSource-resident clock 35 reference. 36 37 7.2.2.4 Effect of receipt 38 39 Upon receipt by the ClockMaster entity, the encapsulated grandTime value is supplemented and affiliated 40 with a localTime snapshot; the resulting {grandTime,extraTime,localTime} affiliation is passed to the 41 GrandSync entity for redistribution to other ClockSlave and TS entities. 42 43 7.3 ClockMaster state machine 44 45 7.3.1 State machine definitions 46 47 7.3.1.1 AVB identifiers: Assigned constants used to specify AVB frame parameters (see 6.3.2). 48 AVB_FUNCTION, AVB_MCAST, AVB_TYPE, AVB_VERSION 49 50 7.3.1.2 NULL: A constant value that (by design) cannot be confused with a valid value. 51 7.3.1.3 Q_CM_RX: The queue identifier associated with PDUs sent to the ClockMaster. 52 53 7.3.1.4 Q_GS_RX: The queue identifier associated with PDUs sent to the GrandSync. 54

Contribution from: [email protected]. 56 This is an unapproved working paper, subject to change. AVB BRIDGING JggDvj20050416/D0.728 2007-09-26

7.3.2 State machine variables 1 2 7.3.2.1 localTime: See 6.3.3. 3 4 7.3.2.2 sxPtr: A pointer to the service-data-unit portion of the received PDU storage. 5 7.3.2.3 tsPtr: A pointer to the service-data-unit portion of txInfo storage. 6 7 7.3.2.4 txInfo: Storage for to-be-transmitted CLOCK_SYNC.response parameters (see 6.2.2.2), comprising: 8 destination_address, source_address, service_data_unit 9 Where service_data_unit comprises: 10 protocolType, function,version, priority, clockID, hops, 11 grandTime, extraTime, localTime, interval, flags, utcOffset 12 13 7.3.2.5 txPtr: A pointer to txInfo storage. 14 15 7.3.3 State machine routines 16 17 7.3.3.1 Dequeue(queue): See 6.3.4 18 7.3.3.2 Enqueue(queue, info): See 6.3.4 19 20 7.3.3.3 StationTime(entity): See 6.3.4 21 22 7.3.3.4 ClockSyncSdu(info): See 6.3.4. 23 24 7.3.4 ClockMaster state table 25 26 The ClockMaster state table encapsulates clock-provided sync information into a ClockSync PDU, as 27 illustrated in Table 7.1. 28 29 30 Table 7.1—ClockMaster state machine table 31 32 Current Next 33 34 Row state condition action state 35 36 START (rxInfo = Dequeue(Q_CM_RX)) 1 txPtr->destination_address = AVB_MCAST; START != NULL txPtr->source_address = MacAddress(ePtr); 37 tsPtr->prototolType = AVB_TYPE; 38 tsPtr->function = AVB_FUNCTION; 39 tsPtr->version = AVB_VERSION; 40 tsPtr->priority = ePtr->priority; 41 tsPtr->clockID = ePtr->clockID; tsPtr->hops = 0; 42 tsPtr->grandTime = sxPtr->grandTime; 43 tsPtr->extraTime = 0; 44 tsPtr->localTime = localTime; 45 tsPtr->interval = sxPtr->interval; 46 tsPtr->flags = sxPtr->flags; tsPtr->utcOffset = sxPtr->utcOffset; 47 Enqueue(Q_GS_RX, txInfo); 48 49 — 2 localTime = StationTime(ePtr); 50 51 52 Row 7.1-1: Supplement and retransmit on CLOCK_MASTER.request PDU arrival. 53 Row 7.1-2: Wait for the next change of state. 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 57 JggDvj20050416/D0.728 WHITE PAPER CONTRIBUTION TO 2007-09-26

1 7.4 ClockSlave service interfaces 2 3 7.4.1 Shared service interfaces 4 5 The ClockSlave entity is coupled to the GrandSync entity, via the defined CLOCK_SYNC.response service 6 interface (see 6.2.2). 7 8 7.4.2 CLOCK_SLAVE.request service interface 9 10 7.4.2.1 Function 11 12 Triggers the ClockSlave entity to provide the current grandTime value. 13 14 7.4.2.2 Semantics of the service primitive 15 16 The semantics of the primitives are as follows: 17 18 CLOCK_SLAVE.request { // The invocation has no parameters 19 } 20 21 7.4.2.3 When generated 22 23 The CLOCK_SLAVE.request service primitive is invoked by a client-resident ClockTarget entity. The intent is 24 to trigger the ClockSlave’s invocation of a following CLOCK_SLAVE.response primitive, thus providing the 25 ClockTarget entity with a recent grandTime value. 26 27 7.4.2.4 Effect of receipt 28 29 Upon receipt by a ClockSlave entity, a copy of the current grandTime value is returned. 30 31 7.4.3 CLOCK_SLAVE.response service interface 32 33 7.4.3.1 Function 34 35 Provides the ClockTarget entity with current grandTime value derived from the reference clock. 36 37 7.4.3.2 Semantics of the service primitive 38 39 The semantics of the primitives are as follows: 40 41 CLOCK_SLAVE.response { 42 interval, // Nominal ClockSync transmission interval 43 flags, // Control flags 44 utcOffset, // Difference between UTC and TAI timescales 45 grandTime // The grandmaster time, when the indication is sent. 46 } 47 48 The parameters of the CLOCK_SLAVE.response service-interface primitive are described as follows: 49 50 7.4.3.2.1 grandTime: An 80-bit field that specifies the grandmaster synchronized time within the 51 ClockSlave entity, when the previous CLOCK_SLAVE.request service-interface was invoked. 52 53 54

Contribution from: [email protected]. 58 This is an unapproved working paper, subject to change. AVB BRIDGING JggDvj20050416/D0.728 2007-09-26

7.4.3.3 When generated 1 2 The invocation of the CLOCK_SLAVE.response service primitive is invoked by the receipt of a ClockTarget 3 supplied CLOCK_SLAVE.request PDU. The intent is to provide the ClockTarget entity with a current 4 grandTime value. 5 6 7.4.3.4 Effect of receipt 7 8 Upon receipt by a ClockTarget entity, the {grandTime,localTime} affiliation is expected to be saved and 9 (along with previously saved copies) used to adjust the rate of the grandmaster synchronized 10 ClockTarget-resident clock. 11 12 7.4.4 CLOCK_SERVE.request service interface 13 14 NOTE—The details of the CLOCK_SERVE interface are highly preliminary and subject to change. 15 16 7.4.4.1 Function 17 18 Triggers the ClockSlave entity to provide the current grandTime value. 19 20 7.4.4.2 Semantics of the service primitive 21 22 The semantics of the primitives are as follows: 23 24 CLOCK_SERVE.request { 25 interval // Interval between returned indications 26 } 27 28 7.4.4.3 When generated 29 30 The CLOCK_SERVE.request service primitive is invoked by a client-resident ClockTarget entity. The intent is 31 to trigger the ClockSlave’s invocation of a following CLOCK_SERVE.indication primitive, thus providing the 32 ClockTarget entity with periodic samples of the current grandTime value. 33 34 7.4.4.4 Effect of receipt 35 36 Upon receipt by a ClockSlave entity, a copy of the current grandTime value is returned. 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. 59 JggDvj20050416/D0.728 WHITE PAPER CONTRIBUTION TO 2007-09-26

1 7.4.5 CLOCK_SERVE.indication service interface 2 3 7.4.5.1 Function 4 5 Provides the ClockTarget entity with periodic grandTime samples derived from the reference clock. 6 7 NOTE—Details of the CLOCK_SERVE interface are under discussion and subject to change. On possibility is the 8 ClockTarget could requests samples-per-second or seconds-per-sample to avoid arithmetic approximations, wherein 9 decimal/binary fractions do not have exact numerical equivalents. 10 7.4.5.2 Semantics of the service primitive 11 12 The semantics of the primitives are as follows: 13 14 CLOCK_SERVE.indication { 15 interval, // Nominal ClockSync transmission interval 16 flags, // Control flags 17 utcOffset, // Difference between UTC and TAI timescales 18 grandTime // The grandmaster time, when the indication is sent. 19 } 20 21 The parameters of the CLOCK_SLAVE.indication service-interface primitive are described as follows: 22 23 7.4.5.2.1 grandTime: An 80-bit field that specifies the grandmaster synchronized time within the 24 ClockSlave entity, when the previous CLOCK_SLAVE.request service-interface was invoked. 25 26 7.4.5.3 When generated 27 28 The invocation of the CLOCK_SLAVE.indication service primitive is invoked by the receipt of a ClockTarget 29 supplied CLOCK_SLAVE.request PDU. The intent is to provide the ClockTarget entity with a current 30 grandTime value. 31 32 7.4.5.4 Effect of receipt 33 34 Upon receipt by a ClockTarget entity, the {grandTime,localTime} affiliation is expected to be saved and 35 (along with previously saved copies) used to adjust the rate of the grandmaster synchronized 36 ClockTarget-resident clock. 37 38 39 7.5 ClockSlave state machine 40 41 7.5.1 Function 42 43 To provide time…TBD. 44 45 7.5.2 State machine definitions 46 47 7.5.2.1 NULL: A constant that (by design) cannot be confused with a valid value. 48 7.5.2.2 Q_CS_IND: The queue identifier associated with periodic PDUs sent from the ClockSlave. 49 50 7.5.2.3 Q_CS_REQ: The queue identifier associated with PDUs sent to the ClockSlave. 51 52 7.5.2.4 Q_CS_RES: The queue identifier associated with per-request PDUs sent from the ClockSlave. 53 7.5.2.5 Q_GS_TX: The queue identifier associated with PDUs sent from the GrandSync. 54

Contribution from: [email protected]. 60 This is an unapproved working paper, subject to change. AVB BRIDGING JggDvj20050416/D0.728 2007-09-26

7.5.3 State machine variables 1 2 7.5.3.1 ePtr: A pointer to entity-dependent information, including the following: 3 rxSaved—A copy of the GrandSync supplied MA_DATAUNIT.request value. 4 interval—The expected service rate of CLOCK_SLAVE.request services. 5 baseTimer—Recently saved time events, each consisting of the following: 6 index—Index into the timed[] array, where last times were stored. 7 range—Number of entries within the timed[] array 8 timed[range]—Recently saved time events, each consisting of the following: 9 grandTime—A previously sampled grandmaster synchronized time. 10 extraTime—The residual error associated with the sampled grandTime value. 11 localTime—The station-local time affiliated with the sampled grandTime value. 12 13 7.5.3.2 cxInfo: A contents of a higher-level supplied time-synchronization request, including the following: 14 frameCount—A value that increments on each CLOCK_MASTER.request PDU transfer. 15 7.5.3.3 nextTime: Storage representing grandTime and extraTime values returned from call to NextTimed(). 16 17 7.5.3.4 rsPtr: A pointer to the service-data-unit portion of rxInfo. 18 19 7.5.3.5 rxInfo: A contents of a GrandSync supplied CLOCK_SYNC.response (see 6.2.2), including: 20 destination_address, source_address, service_data_unit 21 Where service_data_unit comprises: 22 protocolType, function, version, priority, clockID, 23 hops, interval, flags, utcOffset, hops, grandTime, extraTime, localTime 24 7.5.3.6 rxPtr: A pointer to rxInfo. 25 26 7.5.3.7 intervalRx: The synchronization interval of this station’s GrandSync-selected clock-slave port. 27 28 7.5.3.8 localTime: See 6.3.3. 29 7.5.3.9 ssPtr: A pointer to the service-data-unit portion of the ePtr->rxSaved storage 30 31 7.5.3.10 sxPtr: A pointer to the ePtr->rxSaved storage 32 33 7.5.3.11 timePtr: A pointer to the ePtr->timed[] array storage 34 7.5.3.12 txInfo: A contents of a ClockSlave supplied CLOCK_SLAVE.indication (see 6.2.2), comprising: 35 frameCount—The saved value of the like named field from the previous CLOCK_SLAVE.request PDU. 36 grandTime—The grandmaster synchronized time sampled during the CLOCK_SLAVE.request transfer. 37 38 7.5.3.13 txPtr: A pointer to txInfo storage. 39 40 7.5.3.14 intervalTx: The synchronization interval of this ClockSlave entity. 41 42 7.5.4 State machine routines 43 44 7.5.4.1 Dequeue(queue): See 6.3.4. 45 7.5.4.2 Enqueue(queue, info): See 6.3.4. 46 47 7.5.4.3 NextSaved(btPtr, intervalRate, grandTime, extraTime, thisRxTime): 48 Saves grandTime, extraTime values associated with a snapshot taken at thisRxTime, with the saved values 49 spanning a intervalRate specified interval. 50 51 7.5.4.4 NextTimed(btPtr, localTime, intervalBack): 52 Returns grandTime and extraTime values associated with a snapshot taken at localTime, back-interpolated 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 61 JggDvj20050416/D0.728 WHITE PAPER CONTRIBUTION TO 2007-09-26

1 by a intervalBack time, based on previous received-time information saved in the btPtr referenced data 2 structure. 3 4 7.5.4.5 StationTime(entity): See 6.3.4. 5 7.5.4.6 ClockSyncSdu(info): See 7.3.3. 6 7 7.5.5 ClockSlave state table 8 9 NOTE—Details of CLOCK_SERVE interface are under discussion and thus this state machine is subject to change. 10 11 The ClockSlave state machine includes a media-dependent timeout, which effectively disconnects a 12 clock-slave port in the absence of received ClockSync frames, as illustrated in Table 7.2. 13 14 15 Table 7.2—ClockSlave state table 16 17 Current Next 18

19 state conditionRow action state 20 21 START (rxInfo = Dequeue(Q_GS_TX)) 1 — TEST 22 != NULL 23 ((cxInfo = 2 intervalRx = ssPtr->interval; START 24 Dequeue(Q_CS_RX)) != NULL intervalTx = ePtr->interval; 25 intervalBack = (3 * intervalRx + intervalTx) / 2; 26 nextTimes = 27 NextTimed(btPtr, localTime, intervalBack); txPtr->count = cxInfo.count; 28 txPtr->grandTime = 29 nextTimes.grandTime + nextTimes.extraTime; 30 Enqueue(Q_CS_IND, txInfo); 31 — 3 localTime = StationTime(ePtr); 32 33 TEST ClockSyncSdu(rsPtr) 4 *sxPtr = *rxPtr; START 34 NextSaved(btPtr, intervalRate, 35 rsPtr->grandTime; rsPtr->extraTime, rsPtr->localTime); 36 37 —5— 38 39 40 Row 7.2-1: The received CLOCK_SYNC.response parameters are dequeued for checking. 41 Row 7.2-2: A clock-slave request generates an affiliated information-providing indication. 42 The affiliated indication has the sequence-count information provided by the request. 43 The delivered end-point grandTime value is the sum of delivered grandTime and extraTime values. 44 The requested content is queued for delivery to the higher-level client. 45 Row 7.2-3: Wait for the next change-of-conditions. 46 47 Row 7.2-4: Validated GrandSync entity requests are accepted; its time parameters are saved. 48 The back-interpolation time is estimated from the interval times of the source and clock slave. 49 (This back-interpolation time is used by NextTimed( ), which provides transmission-time estimates.) 50 Row 7.2-5: Wait for the next change-of-conditions. 51 52 53 54

Contribution from: [email protected]. 62 This is an unapproved working paper, subject to change. AVB BRIDGING JggDvj20050416/D0.728 2007-09-26

8. Ethernet full duplex (EFDX) state machines 1 2 3 8.1 Overview 4 5 This clause specifies the state machines that support 802.3 Ethernet full duplex (EFDX) bridges. The 6 operations are described in an abstract way and do not imply any particular implementations or any exposed 7 interfaces. There is not necessarily a one-to-one correspondence between the formal specification and the 8 interfaces in any particular implementation. 9 10 8.1.1 EFDX link indications 11 12 The duplex-link TimeSyncRxEfdx state machines are provided with snapshots of ClockSync-frame recep- 13 tion and transmission times, as illustrated by the ports within Figure 8.1. These link-dependent indications 14 can be different for bridge ports attached to alternative media. 15 16 GrandSync CLOCK_SYNC.response 17 CLOCK_SYNC.indication 18 19 20 TS TS TimeSyncRxEfdx TimeSyncTxEfdx 21 ~localTime~ LLC LLC 22 MS MS 23 MAC relay rxSync txSync 24 25 26 ISS ISS 27 802.3 MAC 802.3 MAC 28 PHY PHY 29 30 LAN LAN 31 32 Figure 8.1—EFDX-link interface model 33 34 8.1.2 Link-delay compensation 35 36 Synchronization accuracies are affected by the transmission delays associated with transmissions over links 37 between bridges. To compensate for these transmission delays, the receive port is responsible for 38 compensating {grandTime,extraTime,localTime} affiliations by the (assumed to be constant) 39 frame-transmission delay. 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. 63 JggDvj20050416/D0.728 WHITE PAPER CONTRIBUTION TO 2007-09-26

1 8.1.3 Clock-synchronization intervals 2 3 Receive timestamp hardware is assumed to affiliate a thisRxTime (a localTime snapshot, sampled on frame 4 receipt) with an incoming frame, before that frame is passed to the receive-TS entity. In a similar fashion, 5 transmit timestamp hardware is assumed to save a thisTxTime value in the transmit-TS entity, after each 6 frame transmission. 7 8 The details of services interfaces that support these timestamp activities are under discussion and therefore 9 not included in this draft. Until these discussions converge, the protocols simply assume the availability of 10 the thisRxTime and thisTxTime values, without specifying how these values are updated. 11 12 8.1.4 Clock-synchronization intervals 13 14 Clock synchronization involves synchronizing the clock-slave clocks to the reference provided by the grand 15 clock master. Tight accuracy is possible with matched-length duplex links, since bidirectional frame 16 transmissions can cancel the cable-delay effects. 17 18 Clock synchronization involves the processing of periodic events. Multiple time periods are involved, as 19 listed in Table 8.1. The clock-period events trigger the update of free-running timer values; the period affects 20 the timer-synchronization accuracy and is therefore constrained to be small. 21 22 23 Table 8.1—Clock-synchronization intervals 24 25 Name Time Description 26 27 clock-period < 50 ns Resolution of timer-register value updates 28 send-period 10 ms Time between sending of periodic ClockSync frames between adjacent stations 29 30 slow-period 100 ms Time between computation of clock-master/clock-slave rate differences 31 32 33 The send-period events trigger the interchange of ClockSync frames between adjacent stations. While a 34 smaller period (1 ms or 100 µs) could improve accuracies, the larger value is intended to reduce costs by 35 allowing computations to be executed by inexpensive (but possibly slow) bridge-resident firmware. 36 37 The slow-period events trigger the computation of timer-rate differences. The timer-rate differences are 38 computed over two slow-period intervals, but recomputed every slow-period interval. The larger 100 ms (as 39 opposed to 10 ms) computation interval is intended to reduce errors associated with sampling of 40 clock-period-quantized slow-period-sized time intervals. 41 42 43 44 45 46 47 48 49 50 51 52 53 54

Contribution from: [email protected]. 64 This is an unapproved working paper, subject to change. AVB BRIDGING JggDvj20050416/D0.728 2007-09-26

8.2 efdxClockSync frame format 1 2 8.2.1 efdxClockSync fields 3 4 EFDX clock-synchronization (efdxClockSync) frames facilitate the synchronization of neighboring 5 clock-master and clock-slave stations. The frame, which is normally sent at 10ms intervals, includes 6 time-snapshot information and the identity of the network’s clock master, as illustrated in Figure 8.2. The 7 gray boxes represent physical layer encapsulation fields that are common across Ethernet frames. 8 9 10 6 da — Destination MAC address 11 12 6 sa — Source MAC address 13 2 protocolType — Distinguishes AVB frames from others 14 1 function — Distinguishes ClockSync from other AVB frames 15 1 version — Distinguishes between ClockSync frame versions 16 1 frameCount — A (sequence number) count of time-sync frames 17 1 reserved —Reserved for future definitions 18 2 priority — Priority for grandmaster selection 19 20 8 clockID — Identify of grandmaster station 21 22 — Hop count from the grandmaster 2 hops 23 — Specifies the ClockSync transmission interval 1 period 24 — Warnings of impending state changes 1 flags 25 2 utcOffset — Leap seconds value 26 27 10 grandTime — Transmitter grand-time snapshot (1 cycle delayed) 28 29 4 extraTime — Back-prediction error for grandTime computation 30 6 thisTxTime — Received link’s frame transmit time (1 cycle delayed) 31 32 6 thatTxTime — Opposing link’s frame transmit time 33 34 6 thatRxTime — Opposing link’s frame received time 35 4 fcs — Frame check sequence 36 37 68 bytes total 38 Figure 8.2—efdxClockSync frame format 39 40 NOTE— Existing 1588 time-snapshot hardware captures the values between byte-offset 34 and 45 (inclusive). The 41 location of the frameCount field (byte-offset 44) has been adjusted to ensure this field can be similarly captured for the 42 purpose of unambiguously associating ClockSync-packet snapshots (that bypass the MAC) and ClockSync-packet 43 contents (that pass through the MAC). 44 45 The 48-bit da (destination address), 48-bit sa (source address) field, 16-bit protocolType, 8-bit function, 46 8-bit version, 2-byte priority, 8-byte clockID, 2-byte hops, 1-byte priority, 1-byte flags, 2-byte utcOffset, 47 80-bit grandTime, and 32-bit extraTime field are specified in 6.2.1.2. 48 8.2.1.1 frameCount: An 8-bit field that is incremented by one between successive ClockSync frame 49 transmission. 50 51 8.2.1.2 thisTxTime: A 48-bit field that specifies the local free-running time within the neighbor station, 52 when the previous ClockSync frame was transmitted on the incoming link (see 6.2.1.9). 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 65 JggDvj20050416/D0.728 WHITE PAPER CONTRIBUTION TO 2007-09-26

1 8.2.1.3 thatTxTime: A 48-bit field that specifies the local free-running time within the source station, when 2 the previous ClockSync frame was transmitted on the opposing link (see 6.2.1.9). 3 4 8.2.1.4 thatRxTime: A 48-bit field that specifies the local free-running time within the target station, when 5 the previous ClockSync frame was received on the opposing link (see 6.2.1.9). 6 8.2.1.5 fcs: A 32-bit (frame check sequence) field that is a cyclic redundancy check (CRC) of the frame. 7 8 9 8.3 EFDX TimeSync service interfaces 10 11 8.3.1 Shared service interfaces 12 13 The per-port EFDX per-port interfaces are between the TS and frame-generation entities. 14 15 8.3.2 ES_UNITDATA .request service interface 16 17 8.3.2.1 Function 18 19 Provides the TS entity with grandmaster-selection and clock-synchronization parameters derived from a 20 received ClockSync frame. 21 22 8.3.2.2 Semantics of the service primitive 23 24 The semantics of the primitives are as follows: 25 26 ES_UNITDATA.indication { 27 destination_address, // Destination address 28 source_address, // Optional 29 priority, // Forwarding priority 30 this_rx_time, // A localTime snapshot, sampled on frame arrival 31 service_data_unit, // Delivered content 32 { // Contents of the service_data_unit 33 protocolType, // Distinguishes AVB frames from others 34 function, // Distinguishes between ClockSync and other AVB frames 35 version, // Distinguishes between ClockSync frame versions 36 priority, // Precedence for grandmaster selection 37 clockID, // Precedence for grandmaster selection 38 hops, // Distance from the grandmaster station 39 interval, // Nominal ClockSync transmission interval 40 flags, // Control flags 41 utcOffset, // Difference between UTC and TAI timescales 42 grandTime, // Global-time snapshot (1-cycle delayed) 43 extraTime, // Accumulated grandTime error 44 thisTxTime, // Opposing link’s frame transmit time 45 thatRxTime, // Opposing link’s frame received time 46 thatTxTime // Received link’s frame transmit time (1-cycle delayed) 47 } 48 } 49 50 The parameters of the ES_UNITDATA.indication are described as follows: 51 52 The 48-bit destination_address, 48-bit source_address, and 8-bit priority fields are specified in 6.2.1.2. 53 54 The 48-bit this_rx_time field is a copy of the localTime value, sampled upon frame arrival.

Contribution from: [email protected]. 66 This is an unapproved working paper, subject to change. AVB BRIDGING JggDvj20050416/D0.728 2007-09-26

The service_data_unit consists of subfields; for content exchanged with the GrandTime protocol entity, 1 these fields include the following. 2 3 The 16-bit protocolType, 8-bit function, 8-bit version, 2-byte priority, 8-byte clockID, 2-byte hops, 1-byte 4 interval, 1-byte flags, 2-byte utcOffset, 10-byte grandTime, and 4-byte extraTime fields are specified in 5 6.2.1.2. 6 7 The 6-byte thisTxTime, 6-byte thatRxTime, and 6-byte thatTxTime fields are specified in 8.2.1. 8 9 8.3.2.3 When generated 10 11 The ES_UNITDATA.indication service primitive is invoked by the receipt for a ClockSync frame. 12 13 8.3.2.4 Effect of receipt 14 15 Upon receipt by the TimeSync entity, the media-dependent fields (thisTxTime, this_rx_time, thatTxTime and 16 thatRxTime) are utilized to compute the link delay associated with the attached span. These are then stripped 17 from the PDU and replaced by a localTime value, providing the GrandSync entity with the link-delay 18 compensated {grandTime,extraTime,localTime} triad necessary for performing clock-clock synchronization 19 at other ports. 20 21 8.3.3 ES_UNITDATA.response service interface 22 23 8.3.3.1 Function 24 25 Provides the per-port transmit entity with grand-master selection and clock-synchronization parameters 26 derived from the GrandSync-echoed ClockSync PDU. 27 28 8.3.3.2 Semantics of the service primitive 29 30 The semantics of the ES_UNITDATA.response and the ES_UNITDATA.indications are the same (see 8.3.2.2). 31 32 8.3.3.3 When generated 33 34 The ES_UNITDATA.response service primitive is periodically invoked by the per-port TimeSync entity for the 35 purpose of transmitting a ClockSync frame to the adjacent station. 36 37 8.3.3.4 Effect of receipt 38 39 Upon receipt by the port-transmit entity, the contents are encapsulated into a GrandSync frame that is sent to 40 the neighbor station. 41 42 43 8.4 TimeSyncRxEfdx state machine 44 45 8.4.1 Function 46 47 The TimeSyncRxEfdx state machine is responsible for monitoring its port’s received MAC-supplied frames 48 and sending GrandSync PDUs. The sequencing of this state machine is specified by Table 8.2; details of the 49 computations are specified by the C-code of Annex G. 50 51 52 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 67 JggDvj20050416/D0.728 WHITE PAPER CONTRIBUTION TO 2007-09-26

1 8.4.2 State machine definitions 2 3 8.4.2.1 DC_DELAY: The default cable-length value, used before length-calibration completes. 4 value—10 ns (corresponds to an approximate 2 meter cable length) 5 6 8.4.2.2 MAX_HOPS: See 6.3.2.2. 7 8.4.2.3 MOD_FRAME: A constant representing the number of possible frame.frameCount values. 8 value—256. 9 10 8.4.2.4 MOD_RATE: A constant representing the number of possible time-array values. 11 default value—16. 12 13 8.4.2.5 NULL: A constant that (by design) cannot be confused with a valid value. 14 8.4.2.6 Q_ES_RX: The queue identifier associated with the received MAC frames. 15 16 8.4.2.7 Q_GS_RX: The queue identifier associated with MAC frames sent into GrandSync. 17 18 8.4.2.8 RX_PHASE: The number of received initialization phases. 19 value—2 20 21 8.4.3 State machine variables 22 23 8.4.3.1 count: A transient value representing the expected value of the next rxInfo.frameCount value. 24 8.4.3.2 cxInfo: A contents of a lower-level supplied time-synchronization poke indication, including: 25 frameCount—The value of the like-named field within the last ClockSync packet arrival. 26 localTime—The value of localTime associated with the last ClockSync packet arrival. 27 28 8.4.3.3 cxPtr: A pointer to cxInfo storage. 29 30 8.4.3.4 delay: Values (possibly scaled integers) representing cable-delay times. 31 8.4.3.5 ePtr: A pointer to a data structure that contains port-specific information comprising: 32 past—A storage-array index for the past saved value. 33 phase—A saturating integer that counts received GrandSync frames since initialization. 34 last—A storage-array index for the last saved value. 35 frameCount—The value of frameCount within the last received frame. 36 times[N]—An array of time groups, where each array elements consists of: 37 rxTime—The receive time associated with received time-sync frames. 38 txTime—The transmit time associated with received time-sync frames. 39 40 8.4.3.6 localTime: See 6.3.3. 41 42 8.4.3.7 ratio0, ratio: Variables representing the ratio of this station’s timer to this port’s neighbor timer. 43 8.4.3.8 roundTrip: The time between transmit-to-neighbor and receive-from-neighbor events. 44 45 8.4.3.9 rsPtr: A pointer to the service-data-unit portion of rxInfo storage. 46 47 8.4.3.10 rxInfo: Storage for received time-sync PDUs, comprising: 48 destination_address, source_address, service_data_unit 49 Where service_data_unit comprises: 50 protocolType, function, version, frameCount, priority, clockID, 51 hops, interval, flags, utcOffset, grandTime, extraTime, localTime, thatTxTime, thatRxTime 52 8.4.3.11 rxPtr: A pointer to the rxInfo storage. 53 54 8.4.3.12 timePtrA, timePtrB: Pointers to the past and last times[] array locations.

Contribution from: [email protected]. 68 This is an unapproved working paper, subject to change. AVB BRIDGING JggDvj20050416/D0.728 2007-09-26

8.4.3.13 timeRxA, timeRxB, timeRxA, timeRxB: Intermediate receive/transmit time variables. 1 2 8.4.3.14 tsPtr: A pointer to service-data-unit portion of txInfo storage. 3 8.4.3.15 turnRound: The time between receive-at-neighbor and transmit-from-neighbor events. 4 5 8.4.3.16 txInfo: Storage for information sent to the GrandSync entity, comprising: 6 destination_address, source_address, service_data_unit 7 Where service_data_unit comprises: 8 protocolType, function, version, priority, clockID, 9 hops, interval, flags, utcOffset, grandTime, extraTime, localTime 10 11 8.4.3.17 txPtr: A pointer to txInfo storage. 12 13 8.4.4 State machine routines 14 15 8.4.4.1 ClipRatio(ratio, deviation): Clips the ratio value to within 1.0+deviation and 1.0–deviation. 16 8.4.4.2 Dequeue(queue): See 6.3.4. 17 18 8.4.4.3 Enqueue(queue, info): See 6.3.4. 19 20 8.4.4.4 Min(x, y): Returns the minimum of x and y values. 21 8.4.4.5 StationTime(entity): See 7.3.3. 22 23 8.4.4.6 ClockSyncSdu(info): See 6.3.4. 24 25 8.4.5 TimeSyncRxEfdx state machine table 26 27 The TimeSyncRxEfdx state machine processes efdxClockSync PDUs and forwards revised ClockSync 28 PDUs to the GrandSync entity, as illustrated in Table 8.2. 29 30 Table 8.2—TimeSyncRxEfdx state machine table 31 32 Current Next 33 34 state conditionRow action state 35 36 START — 1 ePtr->phase = 0 FIRST 37 FIRST (rxInfo=Dequeue(Q_ES_RX)) 2 count = (ePtr->frameCount + 1) % MOD_FRAME; NEXT 38 != NULL ePtr->frameCount = rxPtr->frameCount; 39 40 — 3 localTime = StationTime(ePtr); FIRST 41 NEXT !ClockSyncSdu(rsPtr) 4 Enqueue(Q_ES_TX, rxPtr); FIRST 42 43 count != rxPtr->frameCount 5 — 44 ePtr->phase < RX_PHASE 6 ePtr->last = ePtr->past = 0; SAVE 45 46 —7— 47 SAVE — 8 thisRxTime = ePtr->thisRxTime0; PEEK 48 ePtr->thisRxTime0 = rxPtr->thisRxTime; 49 timePtrA = &(ePtr->times[ePtr->last]); 50 timePtrB = &(ePtr->times[ePtr->past]); 51 timeRxB = timePtrB->txTime; timeRxB = timePtrB->rxTime; 52 timePtrA->rxTime = timeRxA = thisRxTime; 53 timePtrA->txTime = timeTxA = rsPtr->thisTxTime; 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 69 JggDvj20050416/D0.728 WHITE PAPER CONTRIBUTION TO 2007-09-26

1 Table 8.2—TimeSyncRxEfdx state machine table 2 3 Current Next 4

5 state conditionRow action state 6 7 PEEK ePtr->phase < RX_PHASE 9 ePtr->phase = ePtr->phase +1; FIRST 8 rxPtr->hops >= MAX_HOPS 10 — 9 10 ePtr->past==ePtr->last 11 ePtr->past = (ePtr->past + 1) % MOD_RATE; SEND 11 —12— 12 13 SEND — 13 ePtr->last = (ePtr->last + 1) % MOD_RATE; FIRST 14 ratio0 = (timeTxA – timeTxB) / (timeRxA – timeRxB); 15 ratio = ClipRatio(ratio0, 200PPM); roundTrip = thisRxTime – rsPtr->thatTxTime; 16 turnRound = rsPtr->thisTxTime – rsPtr->thatRxTime; 17 delay = Min(0, roundTrip – (turnRound * ratio)); 18 txPtr->destination_address=rxPtr->destination_address; 19 txPtr->source_address = rxPtr->source_address; 20 tsPtr->protocolType = rsPtr->protocolType; tsPtr->function = rsPtr->function; 21 tsPtr->version = rsPtr->version; 22 tsPtr->grandTime = rsPtr->grandTime; 23 tsPtr->extraTime = rsPtr->extraTime; 24 tsPtr->localTime = thisRxTime – delay; 25 tsPtr->hops = rsPtr->hops; tsPtr->interval = ePtr->interval; 26 tsPtr->flags = ePtr->flags; 27 Enqueue(Q_GS_RX, txPtr); 28 29 30 Row 8.2-1: Initialization clears the initialization phase to zero, allowing unitialized times to be ignored. 31 Row 8.2-2: Initiate inspection of frames received from the lower-level MAC. 32 Row 8.2-3: Update times while waiting for the next change-of-state. 33 34 Row 8.2-4: The non-ClockSync frames are passed through. 35 Row 8.2-5: Non-sequential ClockSync frames are ignored. 36 Row 8.2-6: Until initialized, clear the circular-buffer index values. 37 Row 8.2-7: Otherwise, use previous circular-buffer index values. 38 Row 8.2-8: Save incoming clockSync information. 39 40 Row 8.2-9: Step through the initialization phases, based on received-frame count. 41 Row 8.2-10: Discard over-aged ClockSync frames. 42 Row 8.2-11: Update tail-index, to avoid circular-buffer overflow. 43 Row 8.2-12: Otherwise, allow the circular-buffer depth to grow. 44 Row 8.2-13: Send the revised PDU. 45 46 47 48 49 50 51 52 53 54

Contribution from: [email protected]. 70 This is an unapproved working paper, subject to change. AVB BRIDGING JggDvj20050416/D0.728 2007-09-26

8.5 TimeSyncTxEfdx state machine 1 2 8.5.1 Function 3 4 The TimeSyncTxEfdx state machine is responsible for saving time parameters from GrandSync-echoed 5 ClockSync PDUs and forming efdxClockSync PDUs for transmission through the MAC and over the 6 attached link. 7 8 8.5.2 State machine definitions 9 10 8.5.2.1 MAX_HOPS: See 6.3.2.2. 11 12 8.5.2.2 NULL: A constant that (by design) cannot be confused with a valid value. 13 14 8.5.2.3 Q_ES_TX: The queue identifier associated with frames sent to the MAC. 15 8.5.2.4 Q_GS_TX: The queue identifier associated with frames sent from the GrandSync. 16 17 8.5.2.5 T10ms: A constant the represents a 10 ms value. 18 19 8.5.3 State machine variables 20 21 8.5.3.1 active: A variable that indicates when initialization has completed. 22 8.5.3.2 intervalBack, intervalRate, intervalRx, intervalTx: 23 Internal variables that represents the intervals between sampled GransSync events. 24 25 8.5.3.3 dPtr: A pointer this port’s associated TimeSyncRxEfdx-entity storage. 26 27 8.5.3.4 ePtr: A pointer to a data structure that contains port-specific information comprising: 28 destination_address, source_address, protocolID, function, version, hops— 29 Copies of like-named fields from the GrandSync provided ClockSync PDU. 30 baseTimer—Recently saved time events, each consisting of the following: 31 index—Index into the timed[] array, where last times were stored. 32 range—Number of entries within the timed[] array 33 timed[range]—Recently saved time events, each consisting of the following: 34 grandTime—A previously sampled grandmaster synchronized time. 35 extraTime—The residual error associated with the sampled grandTime value. 36 localTime—The station-local time affiliated with the sampled grandTime value. 37 frameCount—A consistency-check identifier that is incremented on each transmission. 38 intervalRx—The expected receive-port interval between successive time-sync transmissions. 39 intervalTx—The configured transmit-port interval between successive time-sync transmissions. 40 lastTime—The last transmit time, saved for timeout purposes. 41 rxSaved—A copy of the last received GrandSync parameters. 42 thisTxTime—The localTime value associated with the last transmission. 43 8.5.3.5 localTime: See 6.3.3. 44 45 8.5.3.6 rxInfo: Storage for received GrandSync PDUs, comprising: 46 destination_address, source_address, service_data_unit 47 Where service_data_unit comprises: 48 protocolType, function, version, hops, clockID, 49 interval, flags, utcOffset, grandTime, extraTime, localTime 50 51 8.5.3.7 rsPtr: A pointer to service-data-unit portion of rxInfo storage. 52 8.5.3.8 rxPtr: A pointer to the rxInfo storage. 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 71 JggDvj20050416/D0.728 WHITE PAPER CONTRIBUTION TO 2007-09-26

1 8.5.3.9 intervalRx: Represents the sync-interval associated with this station’s clock-slave port. 2 3 8.5.3.10 thisTxTime: A variable that indicates when the last GrandSync frame was transmitted. 4 8.5.3.11 times: A variable pair consisting of the following components: 5 grandTIme—A time that is referenced to the grandmaster clock. 6 extraTime—A incremental time that should be added (at the endstation) to the grandmaster clock. 7 8 8.5.3.12 tsPtr: A pointer to service-data-unit portion of txInfo storage. 9 10 8.5.3.13 txInfo: Storage for to-be-transmitted time-sync PDUs, comprising: 11 destination_address, source_address, service_data_unit 12 Where service_data_unit comprises: 13 protocolType, function, version, hops, clockID, 14 interval, flags, utcOffset, grandTime, extraTime, thisTxTime, 15 thatRxTime, thatTxTime 16 8.5.3.14 txPtr: A pointer to txInfo storage. 17 18 8.5.3.15 intervalTx: A variable that represents the sync-interval associated with this clock-master port. 19 20 8.5.4 State machine routines 21 22 8.5.4.1 Dequeue(queue): See 6.3.4. 23 24 8.5.4.2 Enqueue(queue, info): See 6.3.4. 25 8.5.4.3 Enqueue(interval): Expand the compacted interval value to a scaled binary-integer seconds format. 26 27 8.5.4.4 NextSaved(btPtr, intervalRate, grandTime, extaTime, thisRxTime): See 7.5.4. 28 29 8.5.4.5 NextTimed(btPtr, localTime, intervalBack): See 7.5.4. 30 8.5.4.6 StationTime(entity): See 7.3.3. 31 32 8.5.4.7 ClockSyncSdu(info): See 6.3.4. 33 34 8.5.5 TimeSyncTxEfdx state machine table 35 36 The TimeSyncTxEfdx state machine includes a media-dependent timeout, which effectively disconnects a 37 clock-slave port in the absence of received ClockSync frames, as illustrated in Table 8.3. 38 39 Table 8.3—TimeSyncTxEfdx state machine table 40 41 Current Next 42 43 state conditionRow action state 44 45 START (localTime–ePtr->lastTime) 1 ePtr->lastTime = localTime; SEND 46 > T10ms 47 (rxInfo=Dequeue(Q_GS_TX)) 2— SINK 48 != NULL 49 — 3 intervalRx = ePtr->intervalRx; START 50 intervalTx = ePtr->intervalTx; 51 intervalBack = (3 * intervalRx + intervalTx) / 2; 52 intervalRate = intervalBack + (3 * intervalTx) / 2; 53 54

Contribution from: [email protected]. 72 This is an unapproved working paper, subject to change. AVB BRIDGING JggDvj20050416/D0.728 2007-09-26

Table 8.3—TimeSyncTxEfdx state machine table 1 2 3 Current Next 4

state conditionRow action state 5 6 SINK ClockSyncSdu(rsPtr) 4 ePtr->destination_address=rxPtr->destination_address; START 7 ePtr->source_address = rxPtr->source_address; 8 ePtr->protocolID = rsPtr->protocolID; 9 ePtr->function = rsPtr->function; ePtr->version = rsPtr->version; 10 ePtr->clockID = rsPtr->clockID; 11 ePtr->hops = rsPtr->hops; 12 ePtr->intervalRx = Expand(rsPtr->interval); 13 ePtr->flags = rsPtr->flags; 14 ePtr->utcOffset = rsPtr->utcOffset; NextSaved(btPtr, intervalRate, rsPtr->grandTime, 15 rsPtr->extraTime,rsPtr->localTime); 16 17 — 5 Enqueue(Q_ES_TX, rxPtr); 18 SEND sPtr->hops>=MAX_HOPS 6 — START 19 20 — 7 dPtr = PortPair(ePtr); 21 active = (dPtr->phase < RX_PHASE); thisTxTime = ePtr->thisTxTime; 22 times = NextTimed(btPtr, thisTxTime, intervalBack); 23 ePtr->txFrameCount += 1; 24 txPtr->destination_address=ePtr->destination_address; 25 txPtr->source_address = ePtr->source_address; 26 tsPtr->protocolID = ePtr->protocolID; tsPtr->function = ePtr->function; 27 tsPtr->version = ePtr->version; 28 tsPtr->clockID = ePtr->clockID; 29 tsPtr->hops = active ? (ePtr->hops+1) : MAX_HOPS; 30 tsPtr->flags = ePtr->flags; 31 tsPtr->flags.disruption |= !active; tsPtr->utcOffset = ePtr->utcOffset; 32 tsPtr->frameCount = (ePtr->frameCount%COUNT); 33 tsPtr->grandTime = times.grandTime; 34 tsPtr->extraTime = times.extraTime; 35 tsPtr->thisTxTime = thisTxTime; 36 tsPtr->thatTxTime = dPtr->thisTxTime; tsPtr->thatRxTime = dPtr->thisRxTime; 37 Enqueue(Q_ES_TX, txPtr); 38 39 40 Row 8.3-1: Transmit periodic ClockSync PDUs. 41 Row 8.3-2: Receive the GrandSync-echoed ClockSync PDUs. 42 Row 8.3-3: Update values while waiting for the next change-of-state. 43 44 Row 8.3-4: The ClockSync PDUs are checked further. 45 Row 8.3-5: The non-ClockSync PDUs are passed through. 46 47 Row 8.3-6: Overly aged ClockSync frames are discarded. 48 Row 8.3-7: ClockSync frames are formulated and transmitted. 49 50 51 52 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 73 JggDvj20050416/D0.728 WHITE PAPER CONTRIBUTION TO 2007-09-26

1 9. Wireless state machines 2 3 EDITOR DVJ NOTE—This clause is has not tracked recent modifications/improvements to 802.1as edited by Kevin 4 Stanton. The reviewer is referred to the most-recent revision of 802.1as, with the cautionary note that the GrandSync 5 service interface considerations are quite different and subject to change as the document content is harmonized. 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]. 74 This is an unapproved working paper, subject to change. AVB BRIDGING JggDvj20050416/D0.728 2007-09-26

10. Ethernet passive optical network (EPON) state machines 1 2 NOTE—This clause is based on indirect knowledge of the Ethernet-PON (EPON) specifications, as interpreted by the 3 author, and have not been reviewed by the 802.1 or 802.3 WGs. The intent was to provide a forum for evaluation of the 4 GrandSync interfaces, while also triggering discussion of EPON design details. As such, the contents are highly 5 preliminary and subject to change. 6 7 10.1 Overview 8 9 This clause specifies the state machines that support Ethernet passive optical network (EPON) based 10 bridges. The operations are described in an abstract way and do not imply any particular implementations or 11 any exposed interfaces. There is not necessarily a one-to-one correspondence between the formal specifica- 12 tion and the interfaces in any particular implementation. 13 14 A (simplified) EPON topology consists of a single optical line terminal (OLT) attached to multiple optical 15 network units (ONUs), as illustrated in Figure 10.1. 16 17 18 optical line terminal (OLT) 19 … (a) (e) … 20 21 (b) (d) 22 ONU[0] ONU[1] ONU[k] (c) ONU[N-2] ONU[N-1] 23 24 optical network units (ONU) 25 26 Figure 10.1—EPON topology 27 28 Time calibration (see 802.3, 64.2.1.1) involves operations performed at the transmission and reception of an 29 OLT-to-ONU request (illustrated at points (a) and (b)), as well as operations performed at the transmission 30 and reception of ONU-to-OLT response (illustrated at points (d) and (e)). 31 32 Both the OLT and the ONU have 32-bit counters that increment every 16 ns. At critical times, the current 33 value of these counters is saved in a timestamp register and/or frame location, as listed below. When com- 34 pleted with each OLU, the central OLT is aware of link delays associated with each of the attached ONUs. 35 a) OLT request transmit; the frame timestamp is set: 36 frame.timestamp = olt.counter 37 b) OLU request receipt; the local counter is set: 38 olu.counter = timestamp 39 40 c) The olu.counter continues to increments every 16 ns period. 41 d) OLU response transmit; frame timestamp is set: 42 frame.timeStamp = olu.counter 43 e) OLT response receipt; round-trip and per-link delays are then computed at the OLT, as follows: 44 roundTripTime = olt.counter – frame.timeStamp 45 linkDelay = roundTripTime / 2 46 47 The time-synchronization (TS) client uses this RTT for the link-delay compensation purposes. 48 49 50 51 52 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 75 JggDvj20050416/D0.728 WHITE PAPER CONTRIBUTION TO 2007-09-26

1 10.1.1 Link-dependent indications 2 3 The TimeSyncEpon state machines have knowledge of network-local synchronized ticksTime timers. With 4 this knowledge, the TimeSyncEpon state machines can operated on frames received from the LLC, as 5 illustrated in Figure 10.2. Link-dependent indications could be required for bridge ports attached to 6 alternative media (not illustrated). 7

8 GrandSync CLOCK_SYNC.response 9 CLOCK_SYNC.indication 10 11 12 TS TS TimeSyncRxEpon TimeSyncTxEpo ~localTime~ 13 LLC LLC 14 MS MS 15 MAC relay 16 17 18 ISS ISS 19 EPON MAC ~ticksTime~ EPON MAC 20 PHY PHY 21 22 LAN LAN 23 24 Figure 10.2—EPON interface model 25 26 The ticksTime values are represented as timers that are incremented once every 16 ns interval, as illustrated 27 on the left side of Figure 10.3. Each synchronized local timer is roughly equivalent to a 6-bit sec (seconds) 28 field and a 26-bit fraction (fractions of second) field timer, as illustrated on the right side of Figure 10.3. 29 30 nanoseconds16 sec fraction 31 ticksTime (approximate equivalent) 32 33 Figure 10.3—Format of EPON-dependent times 34 35 The EPON MAC is supplied with frame transmit/receive snapshots, but these are transparent-to and 36 not-used-by the clock-synchronization state machine. Instead, these are used to synchronize the ticksTime 37 values in associated MACs and the TimeSyncEpon state machines have access to these synchronized 38 ticksTime values. 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54

Contribution from: [email protected]. 76 This is an unapproved working paper, subject to change. AVB BRIDGING JggDvj20050416/D0.728 2007-09-26

10.2 timeSyncEpon frame format 1 2 The timeSyncEpon frames facilitate the synchronization of neighboring clock-master and clock-slave sta- 3 tions. The frame, which is normally sent at 10 ms intervals, includes time-snapshot information and the 4 identity of the network’s clock master, as illustrated in Figure 10.4. The gray boxes represent physical layer 5 encapsulation fields that are common across Ethernet frames. 6 7 8 6 da — Destination MAC address 9 10 6 sa — Source MAC address 11 2 protocolType — Distinguishes AVB frames from others 12 13 1 function — Distinguishes ClockSync from other AVB frames 14 1 version — Distinguishes between ClockSync frame versions 15 —Reserved for future definitions 2 reserved 16 2 priority — Priority for grandmaster selection 17

8 clockID — Identify of grandmaster station 18 19 2 hops — Hop count from the grandmaster 20 1 period — Specifies the ClockSync transmission interval 21 1 flags — Warnings of impending state changes 22 2 utcOffset — Leap seconds value 23 24 10 grandTime — Transmitter grand-time snapshot (1 cycle delayed) 25 26 4 extraTime — Back-prediction error for grandTime computation 27 28 4 ticksTime — Transmitter local-time snapshot (1 cycle delayed) 29 8 reserved — Reserved for future extensions to this standard 30 31 4 fcs — Frame check sequence 32 64 bytes total 33 34 Figure 10.4—timeSyncEpon frame format 35 36 The 48-bit da (destination address), 48-bit sa (source address) field, 16-bit protocolType, 8-bit function, 37 8-bit version, 2-byte priority, 8-byte clockID, 2-byte hops, 1-byte priority, 1-byte flags, 2-byte utcOffset, 38 80-bit grandTime, and 32-bit extraTime field are specified in 6.2.1.2. 39 40 10.2.1 ticksTime: A value representing local time in units of a 16 ns timer ticks, as illustrated in Figure 10.5. 41 42 MSB LSB 43 ticks 44 32 bits 45 46 Figure 10.5—tickTime format 47 48 49 50 51 52 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 77 JggDvj20050416/D0.728 WHITE PAPER CONTRIBUTION TO 2007-09-26

1 10.3 TimeSyncRxEpon service interface primitives 2 3 10.3.1 ES_UNITDATA.indication 4 5 10.3.1.1 Function 6 7 Provides the TimeSyncRxEpon entity with clock-synchronization parameters derived from arriving 8 time-sync frames. 9 10 10.3.1.2 Semantics of the service primitive 11 12 The semantics of the primitives are as follows: 13 14 ES_UNITDATA.indication { 15 destination_address, // Destination address 16 source_address, // Optional 17 priority, // Forwarding priority 18 service_data_unit, // Delivered content 19 { // Contents of the service_data_unit 20 protocolType, // Distinguishes AVB frames from others 21 function, // Distinguishes between ClockSync and other AVB frames 22 version, // Distinguishes between ClockSync frame versions 23 priority, // Precedence for grandmaster selection 24 clockID, // Precedence for grandmaster selection 25 hops, // Distance from the grandmaster station 26 interval, // Nominal ClockSync transmission interval 27 flags, // Control flags 28 utcOffset, // Difference between UTC and TAI timescales 29 grandTime, // Global-time snapshot (1-cycle delayed) 30 extraTime, // Accumulated grandTime error 31 ticksTime // Local-time snapshot (1-cycle delayed) 32 } 33 } 34 35 The parameters of the ES_UNITDATA.indication are described as follows: 36 37 The 48-bit destination_address, 48-bit source_address, and 8-bit priority field are specified in 6.2.1.2. 38 39 The service_data_unit consists of subfields; for content exchanged with the GrandTime protocol entity, 40 these fields include the following. 41 42 The 16-bit protocolType, 8-bit function, 8-bit version, 2-byte priority, 8-byte clockID, 2-byte hops, 1-byte 43 interval, 1-byte flags, 2-byte utcOffset, 10-byte grandTime, and 4-byte extraTime fields are specified in 44 6.2.1.2. 45 46 10.3.1.2.1 ticksTime: A 32-bit field that specifies the local free-running time within this subnet, when the 47 previous ClockSync frame was received (see 10.2.1). 48 49 10.3.1.3 When generated 50 51 The service primitive is generated upon the receipt of a time-sync related frame delivered from the MAC. 52 The intent is to facilitate reformatting and snapshot-time adjustment before the content of that frame is 53 delivered to the ClockMaster and TS entities. 54

Contribution from: [email protected]. 78 This is an unapproved working paper, subject to change. AVB BRIDGING JggDvj20050416/D0.728 2007-09-26

10.3.1.4 Effect of receipt 1 2 The service primitive invokes processing of time-sync related content and forwarding of unrelated content. 3 For time-sync related content, the processing included reformatting and compensation for receive-link 4 transmission delays. 5 6 10.3.2 ES_UNITDATA.response 7 8 10.3.2.1 Function 9 10 Provides the TimeSyncRxEpon entity with clock-synchronization parameters derived from arriving 11 time-sync frames. 12 13 10.3.2.2 Semantics of the service primitive 14 15 The semantics of the primitives are as follows: 16 17 ES_UNITDATA.indication { 18 destination_address, // Destination address 19 source_address, // Optional 20 priority, // Forwarding priority 21 service_data_unit, // Delivered content 22 { // Contents of the service_data_unit 23 protocolType, // Distinguishes AVB frames from others 24 function, // Distinguishes between ClockSync and other AVB frames 25 version, // Distinguishes between ClockSync frame versions 26 priority, // Precedence for grandmaster selection 27 clockID, // Precedence for grandmaster selection 28 hops, // Distance from the grandmaster station 29 interval, // Nominal ClockSync transmission interval 30 flags, // Control flags 31 utcOffset, // Difference between UTC and TAI timescales 32 grandTime, // Global-time snapshot (1-cycle delayed) 33 extraTime, // Accumulated grandTime error 34 ticksTime // Local-time snapshot (1-cycle delayed) 35 } 36 } 37 38 The parameter definitions for the ES_UNITDATA.response and the ES_UNITDATA.indication are the same 39 (see 10.3.1.2). 40 41 10.3.2.3 When generated 42 43 The service primitive is generated upon the receipt of a time-sync related frame delivered from the MAC. 44 The intent is to facilitate reformatting and snapshot-time adjustment before the content of that frame is 45 delivered to the ClockMaster and TS entities. 46 47 10.3.2.4 Effect of receipt 48 49 The service primitive invokes processing of time-sync related content and forwarding of unrelated content. 50 For time-sync related content, the processing included reformatting and compensation for receive-link 51 transmission delays. 52 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 79 JggDvj20050416/D0.728 WHITE PAPER CONTRIBUTION TO 2007-09-26

1 10.4 TimeSyncRxEpon state machine 2 3 10.4.1 Function 4 5 The TimeSyncRxEpon state machine is responsible for receiving MAC-supplied ClockSyncRxEpon PDUs, 6 converting their media-dependent parameters, and sending normalized GrandSync PDUs. The sequencing of 7 this state machine is specified by Table 10.1; details of the computations are specified by the C-code of 8 Annex G. 9 10 10.4.2 State machine definitions 11 12 10.4.2.1 MAX_HOPS: See 6.3.2.2. 13 14 10.4.2.2 NULL: A value that (by design) cannot be confused with a valid value. 15 10.4.2.3 Q_GS_RX: The queue identifier associated with PDUs sent to the GrandSync. 16 17 10.4.2.4 Q_ES_TX: The queue identifier associated with frames received by the MAC. 18 19 10.4.3 State machine variables 20 21 10.4.3.1 ePtr: A pointer to a entity-specific data structure comprising: 22 interval—The expected interval between time-sync frame transmissions. 23 24 10.4.3.2 backTime: Represents the time lapse between transmission of reception of the ClockSync frame. 25 10.4.3.3 rsPtr: A pointer to the service-data-unit portion of the rxInfo storage. 26 27 10.4.3.4 rxInfo: A storage location for received service-interface parameters, comprising: 28 destination_address, source_address, service_data_unit 29 Where service_data_unit comprises: 30 extraTime, function, grandTime, hops, 31 precedence, protocolType, ticksTime, version 32 33 10.4.3.5 rxPtr: A pointer to the rxInfo storage location. 34 10.4.3.6 tsPtr: A pointer to the service-data-unit portion of the txInfo storage. 35 36 10.4.3.7 txInfo: A storage location for to-be-transmitted CLOCK_SYNC.indication parameters, comprising: 37 destination_address, source_address, service_data_unit 38 Where service_data_unit comprises: 39 extraTime, function, grandTime, hops, precedence, 40 protocolType, localTime, ticksTime, version 41 42 10.4.3.8 txPtr: A pointer to the txInfo storage location. 43 44 10.4.4 State machine routines 45 46 10.4.4.1 Dequeue(queue): See 6.3.4. 47 10.4.4.2 Enqueue(queue, info): See 6.3.4. 48 49 10.4.4.3 StationTimes(entityPointer): Returns the station’s generic localTime and media-dependent 50 subnet-synchronized tickTime values. 51 52 10.4.4.4 TicksToTime(ticks): Returns the localTime duration corresponding to the argument time duration. 53 10.4.4.5 ClockSyncSdu(info): See 6.3.4. 54

Contribution from: [email protected]. 80 This is an unapproved working paper, subject to change. AVB BRIDGING JggDvj20050416/D0.728 2007-09-26

10.4.5 TimeSyncRxEpon state machine table 1 2 The TimeSyncRxEpon state machine processes arriving media-dependent ClockSyncRxEpon PDUs and 3 sends standard ClockSync PDUs to the GrandSync entity, as illustrated in Table 10.1. 4 5 6 Table 10.1—TimeSyncRxEpon state machine table 7 8 Current Next 9 10 state conditionRow action state 11 12 START (rxInfo = 1— TEST 13 Dequeue(Q_RX_MAC))!=NULL 14 — 2 times = StationTime(ePtr); START 15 16 TEST !ClockSyncSdu(rsPtr) 3 Enqueue(Q_ES_RX, rxInfo); START 17 rsPtr->hops >= MAX_HOPS 4 — START 18 19 ePtr->type == OLT 5 baseTime = –ePtr->roundTripDelay/2; SEND 20 —6baseTime = 0; 21 22 SEND — 7 diffTime = times.ticksTime – rsPtr->ticksTime; START 23 localTime = times.localTime – TicksToTime(baseTime + diffTime); 24 txPtr->destination_address = 25 rxPtr->destination_address; 26 txPtr->source_address = rxPtr->source_address; 27 tsPtr->protocolType = rsPtr->protocolType; 28 tsPtr->function = rsPtr->function; tsPtr->version = rsPtr->version; 29 tsPtr->priority = rsPtr->priority; 30 tsPtr->clockID = rsPtr->clockID; 31 tsPtr->hops = rsPtr->hops; 32 tsPtr->interval = rsPtr->interval; 33 tsPtr->flags = rsPtr->flags; tsPtr->utcOffset = rsPtr->utcOffset; 34 tsPtr->grandTime = rsPtr->grandTime; 35 tsPtr->extraTime = rsPtr->extraTime; 36 tsPtr->localTime = localTime; 37 Enqueue(Q_GS_RX, txInfo); 38 39 40 Row 10.1-1: Initiate inspection of frames received from the lower-level MAC. 41 Row 10.1-2: Wait for the next frame to arrive. 42 43 Row 10.1-3: The non-ClockSync frames are passed through. 44 Row 10.1-4: Overly aged ClockSync frames are discarded. 45 Row 10.1-5: Received OLT frames are compensated for the link-delay. 46 Row 10.1-6: Received ONU frames are not link-delay compensated (this is done at the OLT). 47 48 Row 10.1-7: Active ClockSync frames are adjusted for transfer delays and passed through. 49 50 51 52 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 81 JggDvj20050416/D0.728 WHITE PAPER CONTRIBUTION TO 2007-09-26

1 10.5 TimeSyncTxEpon state machine 2 3 4 10.6 TimeSyncTxEpon service interface primitives 5 6 10.6.1 ES_UNITDATA.request 7 8 10.6.1.1 Function 9 10 Provides the EPON entity with clock-synchronization parameters for constructing departing time-sync 11 frames. 12 13 10.6.1.2 Semantics of the service primitive 14 15 The semantics of the primitives are as follows: 16 17 ES_UNITDATA.request 18 { 19 destination_address, // Destination address 20 source_address, // Optional 21 priority, // Forwarding priority 22 service_data_unit, // Delivered content 23 { // Contents of the service_data_unit 24 protocolType, // Distinguishes AVB frames from others 25 function, // Distinguishes between ClockSync and other frames 26 version, // Distinguishes between ClockSync frame versions 27 priority, // Bias for grandmaster precedence 28 clockID, // Tie-breaker for grandmaster precedence 29 hops, // Distance from the grandmaster station 30 grandTime, // Global-time snapshot (1-cycle delayed) 31 extraTime, // Accumulated grandTime error 32 ticksTime // Local-time snapshot 33 } 34 } 35 36 The parameters of the MA_UNITDATA.request are described in 10.3.1.2. 37 38 10.6.1.3 When generated 39 40 The service primitive is generated at a periodic rate, for the purposes of synchronizing the grandTime values 41 resident in other stations. 42 43 10.6.1.4 Effect of receipt 44 45 The service primitive triggers the transmission of a ClockSync frame on the affiliated port. 46 47 48 49 50 51 52 53 54

Contribution from: [email protected]. 82 This is an unapproved working paper, subject to change. AVB BRIDGING JggDvj20050416/D0.728 2007-09-26

10.7 ClockSlave state machine 1 2 10.7.1 Function 3 4 The TimeSyncTxEpon state machine is responsible for modifying time-sync CLOCK_SYNC.response 5 parameters to form ClockSync frames for transmission over the attached link. 6 7 10.7.2 State machine definitions 8 9 10.7.2.1 MAX_HOPS: See 6.3.2.2. 10 11 10.7.2.2 NULL: A value that (by design) cannot be confused with a valid value. 12 13 10.7.2.3 Q_ES_RX: The queue identifier associated with PDUs sent for transmission by the MAC. 14 10.7.2.4 Q_GS_TX: The queue identifier associated with PDUs sent for transmission from the GrandSync. 15 16 10.7.2.5 T10ms: A constant the represents a 10 ms value. 17 18 10.7.3 State machine variables 19 20 10.7.3.1 intervalBack: Represents the back-interpolation interval for transmit-time affiliations. 21 10.7.3.2 ePtr: A pointer to a entity-specific data structure comprising: 22 baseTimer—Recently saved time events, each consisting of the following: 23 index—Index into the timed[] array, where last times were stored. 24 range—Number of entries within the timed[] array 25 timed[range]—Recently saved time events, each consisting of the following: 26 grandTime—A previously sampled grandmaster synchronized time. 27 extraTime—The residual error associated with the sampled grandTime value. 28 localTime—The station-local time affiliated with the sampled grandTime value. 29 lastTime—The last PDU-transmit time; used to space periodic transmissions. 30 rxSaved—A copy of the last received GrandSync parameters. 31 interval—The expected interval between time-sync frame transmissions. 32 33 10.7.3.3 rsPtr: A pointer to the service-data-unit portion of rxInfo storage. 34 35 10.7.3.4 rxInfo: Storage for the contents of GrandSync PDUs, comprising: 36 destination_address, source_address, service_data_unit 37 Where service_data_unit comprises: 38 protocolType, function, version, priority, clockID, hops, 39 interval, flags, utcOffset, grandTime, extraTime 40 10.7.3.5 rxPtr: A pointer to the rxInfo storage. 41 42 10.7.3.6 intervalRx: Represents the sync-interval associated with this station’s clock-slave port. 43 44 10.7.3.7 localTime: See 6.3.3. 45 10.7.3.8 ssPtr: A pointer to the service-data-unit portion of the ePtr->rxSaved storage 46 47 10.7.3.9 sxPtr: A pointer to the ePtr->rxSaved storage. 48 49 10.7.3.10 tsPtr: A pointer to the service-data-unit portion of txInfo storage. 50 10.7.3.11 txInfo: Storage for a to-be-transmitted MAC frame, comprising: 51 destination_address, source_address, service_data_unit 52 Where service_data_unit comprises: 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 83 JggDvj20050416/D0.728 WHITE PAPER CONTRIBUTION TO 2007-09-26

1 extraTime, function, grandTime, hops, 2 protocolType, precedence, ticksTime, version 3 4 10.7.3.12 txPtr: A pointer to the txInfo storage. 5 10.7.3.13 ticksTime: A 32-bit shared EPON media-dependent time value; incremented every 16 ns. 6 7 10.7.4 State machine routines 8 9 10.7.4.1 Dequeue(queue): See 6.3.4. 10 11 10.7.4.2 Enqueue(queue, info): See 6.3.4. 12 13 10.7.4.3 NextTimed(btPtr, localTime, intervalBack): See 7.5.4. 14 10.7.4.4 StationTime(entity): See 6.3.4. 15 16 10.7.4.5 TicksTime(entity): See 10.4.4. 17 18 10.7.4.6 ClockSyncSdu(info): See 6.3.4. 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]. 84 This is an unapproved working paper, subject to change. AVB BRIDGING JggDvj20050416/D0.728 2007-09-26

10.7.5 TimeSyncTxEpon state machine table 1 2 The TimeSyncTxEpon state machine includes a media-dependent timeout, which effectively disconnects a 3 clock-slave port in the absence of received timeSyncEpon frames, as illustrated in Table 10.2. 4 5 6 Table 10.2—TimeSyncTxEpon state machine table 7 8 Current Next 9 10 state conditionRow action state 11 12 START (rxInfo = Dequeue(Q_GS_TX)) 1 — TEST 13 != NULL 14 (localTime – ePtr->lastTime) 2 ePtr->lastTime = localTime; SEND 15 > T10ms 16 17 — 3 times = StationTime(ePtr); START 18 TEST !ClockSyncSdu(rsPtr) 4 Enqueue(Q_ES_TX, rxPtr); START 19 20 ssPtr->hops >= MAX_HOPS 5 — 21 ePtr->type == OLT 6 baseTime = –ePtr->roundTripDelay/2; SEND 22 23 —7baseTime = 0; 24 SEND — 8 intervalRx = ssPtr->interval; START 25 intervalTx = ePtr->interval; 26 intervalBack = 27 (3 * intervalRx + intervalTx) / 2; localTime= 28 times.localTime + TicksToTime(baseTime); 29 nextTimes = 30 NextTimed(btPtr, localTime, intervalBack); 31 txPtr->destination_address = 32 sxPtr->destination_address; txPtr->source_address = sxPtr->source_address; 33 tsPtr->protocolType = ssPtr->protocolType; 34 tsPtr->function = ssPtr->function; 35 tsPtr->version = ssPtr->version; 36 tsPtr->precedence = ssPtr->precedence; 37 tsPtr->hops = ssPtr->hops; tsPtr->grandTime = nextTimes.grandTime; 38 tsPtr->extraTime = nextTimes.extraTime; 39 tsPtr->ticksTime = ticksTime; 40 Enqueue(Q_ES_TX, txPtr); 41 42 43 Row 10.2-1: Accepted PDUs are further checked before being processed. 44 Row 10.2-2: Transmit periodic ClockSync frames. 45 Row 10.2-3: Wait for the next change-of-state. 46 47 Row 10.2-4: Non-ClockSync PDUs are retransmitted in the standard fashion. 48 Row 10.2-5: Overly aged ClockSync PDUs are not transmitted. 49 Row 10.2-6: Transmitted OLT frames are compensated for the link-delay. 50 Row 10.2-7: Transmitted ONU frames are not link-delay compensated (this is done at the OLT). 51 52 Row 10.2-8: Format and transmit the media-specific ClockSync frame. 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 85 JggDvj20050416/D0.728 WHITE PAPER CONTRIBUTION TO 2007-09-26

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]. 86 This is an unapproved working paper, subject to change. AVB BRIDGING JggDvj20050416/D0.728 2007-09-26

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. 87 JggDvj20050416/D0.728 WHITE PAPER CONTRIBUTION TO 2007-09-26

1 Annex B 2 3 (informative) 4 5 6 Time-scale conversions 7 8 9 B.1 Overview 10 11 For historical reasons, time is specified in a variety of ways as listed in Table B.1. GPS, PTP, and TAI times 12 are based on values yielded by atomic clocks and advance on each second. NTP and UTC times are similar, 13 but are occasionally adjusted by one leap-second, to account for differences between the atomic clocks and 14 the rotation time of the earth. 15 16 17 Table B.1—Time-scale parameters 18 19 Time scale 20 21 Parameter GPS PTP TAI NTP UTC 22 23 approximate 1980-01-06 1970-01-01 1972-01-01* 1900-01-01 1972-01-01* 24 epoch 1999-08-22 25 representation weeks.seconds seconds YYYY-MM-DD seconds YYYY-MM-DD 26 hh:mm:ss hh:mm:ss 27 rollover (years) 19.7 8,925,513 10,000 136.19 10,000 28 29 leapSeconds no yes 30 Notes: 31 * The TAI time when TAI and UTC were first specified to deviate by only integer seconds. 32 (There is no true epoch for the TAI and UTC time scales.) 33 GPS global positioning satellite 34 NTP Network Time Protocol 35 PTP Precision Time Protocol (commonly used in POSIX) TAI International Atomic Time (from the French term Temps Atomique International) 36 UTC Coordinated Universal Time (a compromise between the English and French): 37 English speakers wanted the initials of their language: CUT for "coordinated universal time" 38 French speakers wanted the initials of their language: TUC for "temps universel coordonné". 39 40 41 B.2 TAI and UTC 42 43 TAI and UTC are international standards for time based on the SI second; both are expressed in days, hours, 44 minutes and seconds. TAI is implemented by a suite of atomic clocks and forms the timekeeping basis for 45 other time scales in common use. The rate at which UTC time advances is normally identical to the rate of 46 TAI. An exception is an occasion when UTC is modified by adding or subtracting leap seconds. 47 48 Prior to 1972-01-01, corrections to the offset between UTC and TAI were made in fractions of a second. 49 After 1972-01-01, leap-second corrections are applied to UTC preferably following second 23:59:59 of the 50 last day of June or December. As of 2006-01-01, TAI and UTC times differed by +33 seconds. 51 52 In POSIX based computer systems, the common time conversion algorithms can produce the correct 53 ISO 8601-2004 printed representation format “YYYY-MM-DD hh:mm:ss” for both TAI and UTC. 54

Contribution from: [email protected]. 88 This is an unapproved working paper, subject to change. AVB BRIDGING JggDvj20050416/D0.728 2007-09-26

The PTP epoch is set such that a direct application of the POSIX algorithm to a PTP time-scale timestamp 1 yields the ISO 8601-2004 printed representation of TAI. Subtracting the current leapSeconds value from a 2 PTP timestamp prior to applying the POSIX algorithm yields the ISO 8601-2004 printed representation of 3 UTC. Conversely, applying the inverse POSIX algorithm and adding leapSeconds converts from the ISO 4 8601-2004 printed form of UTC to the form convenient for generating a PTP timestamp. 5 6 Example: The POSIX algorithm applied to a PTP timestamp value of 8 seconds yields 1970-01-01 00:00:08 7 (eight seconds after midnight on 1970-01-01 TAI). At this time the value of leapSeconds was approximately 8 8 seconds. Subtracting this 8 seconds from this time yields 1970-01-01 00:00:00 UTC. 9 10 Example: The POSIX algorithm applied to a PTP timestamp value of 0 seconds yields 1970-01-01 00:00:00 11 TAI. At this time the value of leapSeconds was approximately 8 seconds. Subtracting this 8 seconds from 12 this time yields 1969-12-31 23:59:52 UTC. 13 14 15 B.3 NTP and GPS 16 17 Two standard time sources of particular interest in implementing PTP systems: NTP and GPS. Both NTP 18 and GPS systems are expected to provide time references for calibration of the grandmaster supplied PTP 19 time. 20 21 32 NTP represents seconds as a 32 bit unsigned integer that rolls-over every 2 seconds ≈ 136 years, with the 22 first such rollover occurring in the year 2036. The precision of NTP systems is usually in the millisecond 23 range. 24 25 NTP is a widely used protocol for synchronizing computer systems. NTP is based on sets of servers, to 26 which NTP clients synchronize. These servers themselves are synchronized to time servers that are traceable 27 to international standards. 28 29 NTP provides the current time. In NTP version 4, the current leapSeconds value and warning flags marking 30 indicating when a leapSecond will be inserted at the end of the current UTC day. The NTP clock effectively 31 stops for one second when the leap second is inserted. 32 33 GPS time comes from a global positioning satellite system, GPS, maintained by the U.S. Department of 34 Defense. The precision of GPS system is usually in the 10-100 ns range. GPS system transmissions 35 represent the time as {weeks, secondsInWeek}, the number of weeks since the GPS epoch and the number of 36 seconds since the beginning of the current week. 37 38 GPS also provides the current leapSeconds value, and warning flags marking the introduction of a leap 39 second correction. UTC and TAI times can be computed solely based the information contained in the GPS 40 transmissions. 41 42 GPS timing receivers generally manage the epoch transitions (1024-week rollovers), providing the correct 43 time (YYYY-MM-DD hh:mm:ss) in TAI and/or UTC time scales, and often also local time; in addition to 44 providing the raw GPS week, second of week, and leap second information. 45 46 47 48 49 50 51 52 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 89 JggDvj20050416/D0.728 WHITE PAPER CONTRIBUTION TO 2007-09-26

1 B.4 Time-scale conversions 2 3 Previously discussed representations of time can be readily converted to/from PTP time based on a constant 4 offsets and the distributed leapSeconds value, as specified in Table B.2. Within Table B.2, all variables 5 represent integers; ‘/’ and ‘%’ represent a integer divide and remainder operation, respectively. 6 7 8 Table B.2—Time-scale conversions 9 10 ta 11 12 name format PTP value tb: 13 14 GPS weeks:seconds tb = ta.seconds + 315 964 819 + 15 (gpsRollovers * 1024 + ta.weeks) * (7 * DAYSECS); 16 ta.weeks = (tb – 315 964 819) / (7 * DAYSECS); 17 ta.days = (tb – 315 964 819) % (7 * DAYSECS); 18 19 TAI date{YYYY,MM,DD}:time{hh,mm,ss} tb = DateToDays(“1970-01-01”, ta.date) * DAYSECS + ((ta.time.hh * 24) + ta.time.mm) *60) + ta.time.ss; 20 21 secs = tb % DAYSECS; 22 ta.date = DaysToDate(“1970-01-01”, tb / DAYSECS); 23 ta.time.hh = secs / 3600; ta.time.mm = (secs % 3600)/60; 24 ta.time.ss = (secs % 60); 25 26 NTP seconds tb = (ta +leapSeconds)–2208988800; 27 ta = (ta–leapSeconds) +2208988800; 28 29 UTC date{YYYY,MM,DD}:time{hh,mm,ss} tb = DateToDays(“1970-01-01”, ta.date) * DAYSECS + 30 ((ta.time.hh * 24) + ta.time.mm) *60) + ta.time.ss + leapSeconds; 31 32 tc = tb – leapSeconds; 33 secs = tc % DAYSECS; 34 ta.date = DaysToDate(“1970-01-01”, tc/DAYSECS); ta.time.hh = secs / 3600; 35 ta.time.mm = (secs % 3600)/60; 36 ta.time.ss = (secs % 60); 37 38 Note: gpsRollovers Currently equals 1; changed from 0 to 1 between 1999-08-15 and 1999-08-22. 39 DAYSECS The number of seconds within a day: (60*60*24). 40 leapSeconds Extra seconds to account for variations in the earth-rotation times: 33 on 2006-01-01. 41 DateToDays For arguments DateToDays(past, present), returns days between past and present dates. 42 DaysToDate For arguments DaysToDate(past, days), returns the current date, days after the past date. 43 44 45 46 47 48 49 50 51 52 53 54

Contribution from: [email protected]. 90 This is an unapproved working paper, subject to change. AVB BRIDGING JggDvj20050416/D0.728 2007-09-26

B.5 Time zones and GMT 1 2 The term Greenwich Mean Time (GMT) once referred to mean solar time at the Royal Observatory in 3 Greenwich, England. GMT now commonly refers to the time scale UTC; or the UK winter time zone 4 (Western European Time, WET). Such GMT references are strictly speaking incorrect; but nevertheless 5 quite common. The following representations correspond to the same instant of time: 6 7 18:07:00 (GMT), commonplace usage 13:07:00 (Eastern Standard Time, EST) 8 18:07:00 (UTC) 1:07 PM (Eastern Standard Time, EST) 9 18:07:00 (Western European Time, WET) 10:07:00 (Pacific Standard Time, PST) 10 6:07 PM (Western European Time, WET) 10:07 AM (Pacific Standard Time, PST) 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. 91 JggDvj20050416/D0.728 WHITE PAPER CONTRIBUTION TO 2007-09-26

1 Annex C 2 3 (informative) 4 5 6 Reclocked ClockSync requirements 7 8 9 C.1 Cascaded clock considerations 10 11 12 C.1.1 Cascading causes sync-interval bunching 13 14 The naive approach towards forwarding time-synchronization information is to quickly propagate 15 time-reference snapshots through successive stations. Unfortunately, relatively small (¼ interval) 16 residence-time delays per station can cause significant bunching, as illustrated in Figure C.1. 17 10 ms 0.0-2.5 ms degraded 18 intervals …delays… intervals 19 20 21 ☺ 22 23 24 7.5 – 12.5 ms 0.0 – 27.5 ms 25 intervals intervals 26 27 Figure C.1—Cascading causes sync-interval bunching 28 29 Techniques for avoiding such bunching are well known and practiced in the form of reclocked synchronous 30 circuits. For example, Ethernet stations accept (baud-rate) information at a closely matched input clock rate, 31 reclock the data with a local reference, and regenerate information without degraded jitter performance. 32 33 34 C.1.2 Reclocking eliminates sync-interval bunching 35 36 Applying these techniques to clock-sync transmission is straightforward. Rather than quickly forwarding 37 these frames, their information is saved. That saved information is then forwarded in the same periodic 38 fashion, based on local-station timing, as illustrated in Figure C.2. While such reclocked systems more 39 susceptible to gain-peaking/whiplash effects, inherent design and verification simplicities favor their use. 40 41 10 ms degraded 42 intervals intervals 43 44 ☺☺☺ 45 46 47 48 7.5 – 12.5 ms 7.5 – 12.5 ms 49 intervals intervals 50 51 Figure C.2—Reclocking eliminates sync-interval bunching 52 53 54

Contribution from: [email protected]. 92 This is an unapproved working paper, subject to change. AVB BRIDGING JggDvj20050416/D0.728 2007-09-26

C.1.3 Reclocking localizes sync-interval properties 1 2 The reclocked sync-interval strategy is compatible with bridged mixed-media systems. The persistent or 3 transient sync-interval rate of an intermediate (perhaps longer or more power sensitive) link could be less 4 than the rate assumed for the clock-master, as illustrated in the center of Figure 3.3. Similarly, wireless links 5 could base their timing events on triggers initiated by the clock-slave station, as illustrated in the right side 6 of Figure 3.3. 7 8 10 ms degraded 9 intervals intervals 10 11 12 13 14 15 7.5 – 12.5 ms 37.5 – 42.5 ms 7.5 – 12.5 ms 16 master intervals long intervals slave intervals 17 18 Figure 3.3—Reclocking localizes sync-interval properties 19 20 Other flow-through clocking designs would require special “boundary clock” architectures to support such 21 mixed systems. With the interval reclocking strategy, the additional (specification and implementation) 22 complexities of such boundary-clock architectures are easily avoided. 23 24 25 C.2 Sampling offset/rate conversion 26 27 Each clock-master port is responsible for using its received {grandTime,extraTime,rcTime} affiliations to 28 derive distinct {grandTime1,extraTime1,txTime} affiliations that are transmitted to its neighbor. Since the 29 values of rcTime and txTime are (by convention) coupled to the receive and transmit times, this update 30 involves generation of {grandTime,extraTime,rcTime} triads by resampling within the array of previously 31 saved {grandTime,extraTime,rcTime} triads. 32 33 34 C.2.1 Forward extrapolation inaccuracies 35 36 A typical design approach (and that used by IEEE Std 1588) views the received {grandTime,rcTime} 37 affiliations as points on a curve, sampled at received-snapshot times rc[n]. The objective is to generate the 38 distinct set of {grandTime1,txTime} affiliations by extrapolating from a distinct set of receive-snapshot 39 times rc[n], as illustrated in Figure 3.4. 40 41 42 grandTime 43 44 45 46 47 48 49 rc[n-N] rc[n] txTime stationTime 50 51 Figure 3.4—Extrapolation for grandTime 52 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 93 JggDvj20050416/D0.728 WHITE PAPER CONTRIBUTION TO 2007-09-26

1 Extrapolation techniques exhibit gain peaking at frequencies whose wavelength is twice the {rc[n-N],rc[n]} 2 slope-averaging interval, because the extrapolated value can exceed what would have been the sampled time 3 value. A cascade of multiple stations emphasizes the gain-peaking inaccuracies, allowing errors to 4 accumulate in an O(N2) fashion. 5 6 C.2.2 Forward interpolation inaccuracies 7 8 9 To reduce gain-peaking effects, the resampling computation can be migrated to a safe-interpolation domain. backTime txTime tbTime 10 This involves subtracting a constant from , yielding a new time , for which a less 11 gain-peaking sensitive interpolation is viable, as illustrated in Figure C.5. In concept, the stale (but not grandTime rcTime 12 incorrect) { , } affiliations could be passed to the terminal clock-slave stations, wherein a 13 single extrapolation-to-the-future accumulation could be performed. A preferred technique is to compensate 14 the interpolation result on an per-station basis as the time-reference flows towards the clock-slave station, as discussed in the following subclauses. 15 16 17 18 grandTime 19 safe interpolation domain 20 21 22 23 backTime 24 rc[n-N] tbTime rc[n] txTime stationTime 25 26 27 Figure C.5—Extrapolation for grandTime 28 29 30 C.2.3 Backward grandTime interpolation 31 32 A more-scalable backward-interpolation approach also views the received {grandTime,rcTime} affiliations 33 as points on a curve. The objective is to generate the distinct set of {grandTime1,txTime} affiliations by 34 interpolating within a distinct set of {grandTime, rcTime} points on the curve, as illustrated in Figure C.6. 35 36 extraTimeB 37 grandTime 38 39 ↑backTIme 40 slope = 1.0 grandTime1 41 ←backTime 42 slope = rateRatio 43 rc[n-(N-1)] tbTime rc[n] txTime 44 stationTime 45 46 Figure C.6—Interpolation for grandTimeA 47 48 rateRatio = (grandTime[n] – grandTime[n-N]) / (rc[n] – rc[n-N]) (3.1) 49 50 grandTime1[m] = grandTime[n] + rateRatio * ((txTime – backTime) – rc[n]) + backTime;(3.2) backTime is a constant (sync-interval dependent) value. 51 52 extraTime1[m] = (rateRatio – ONE) * backTime;(3.3) 53 54

Contribution from: [email protected]. 94 This is an unapproved working paper, subject to change. AVB BRIDGING JggDvj20050416/D0.728 2007-09-26

The advantage of this technique is the separation of grandTime[m] and extra[m] components. The 1 interpolation process eliminates gain-peaking for the grandTime[m] value, thus reducing error effects when 2 passing through multiple bridges. The sideband extraTime signal remains significant, and is therefore carried 3 through bridges, so that the cumulative grandTimed[m]+extraTime[m] value can be passed to the end-point 4 application. 5 6 From an intuitive perspective, the whiplash-free nature of the back-in-time interpolation is attributed to the 7 use of interpolation (as opposed to extrapolation) protocols. Interpolation between input values never 8 produces a larger output value, as would be implied by a gain-peaking (larger-than-unity gain) algorithm. A 9 disadvantage of back-in-time interpolation is the requirement for a side-band extraTime communication 10 channel, over which the difference between nominal and rate-normalized backTime values can be 11 transmitted. 12 13 14 C.2.4 Backward extraTime Averaging 15 16 An averaging (rather than backward-interpolation) approach is applied to the received {extraTime, rcTime} 17 affiliations as points on a curve, sampled at received-snapshot times rc[n]. The {extraTime,tx[m]} affilia- 18 tions are produced by averaging recently observed extraTime values, as illustrated in Figure C.7. 19 20 extraTime 21 22 23 averageValue 24 25 extraTimeA 26 N values 27 28 rc[n-(N-1)] rc[n] tx[m] stationTime 29 30 Figure C.7—Interpolation of extraTimeD 31 32 33 extraTimeA[m] = (extraTime[n–(N–1)] + … extraTime[n]) / N (3.4) 34 extraTime1[m] = extraTimeA[m]+ extraTimeB[m]; (3.5) 35 36 The to-be-transmitted value of extraTime1[m] consists of a contribution extraTimeA (accumulated from pre- 37 vious stations’s grandTime interpolations) and a contribution errorTimeB (coming from this station’s 38 grandTime interpolation). Note that the averaging of extraA values is effectively a low-pass filtering process 39 that removes noise without causing a gain-peaking frequency response. 40 41 NOTE—For simplicity and scalability, the computed extraTime1 time is based on N, a fixed number of samples, where 42 N is a convenient power-of-two in size. 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. 95 JggDvj20050416/D0.728 WHITE PAPER CONTRIBUTION TO 2007-09-26

1 Annex D 2 3 (informative) 4 5 6 Simulation results (preliminary) 7 8 9 D.1 Simulation environment 10 11 This annex describes several simulations performed with the intent of comparing time-extrapolation and 12 time-interpolation algorithms. To reduce possibilities of code-conversion errors, the simulation model 13 executes the C code of Annex G. Simulation time is based on a 128-bit systemTime, represented by 14 64-bit seconds and fractions-of-second components, to ensure that precision and range are not constraining 15 factors. 16 17 The simulation consists of bridgeCount identical super-bridge components, as illustrated in Figure D.1. For 18 generality and uniformity, each bridge includes ClockMaster and ClockSlave entities. The smallest MAC 19 address is assigned to the left-most station; for other stations, the address is incremented for each sequential 20 right-side bridge. The simulations assumed bridgeCount values of 8 (the assumed AVB diameter) and 64 21 (a reasonable IEEE 802.17 ring diameter). 22 23 bridgeCount = 8, 64 24 25 10ms tick 10ms samples 26 ClockSource ClockTarget ClockSource ClockTarget ClockSource ClockTarget 27 28 ClockMaster GrandSync ClockSlave ClockMaster GrandSync ClockSlave ClockMaster GrandSync ClockSlave 29 max TS TS 2.5ms TS TS TS TS 30 LLC LLC delay LLC LLC LLC LLC 31 MAC relay MAC relay MAC relay 32 33 MAC MAC 40ns MAC MAC MAC MAC 34 (PHY) (PHY) ticks (PHY) (PHY) (PHY) (PHY)

35 LAN … LAN 36 delay = 500ns a) Clock master b) Clock bridge… c) Clock slave 37 38 Figure D.1—Time-synchronization flows 39 40 The transmit portion of the TS component (emulated by the DuplexTxExec routine) introduces a random 41 delay of no more than 2.5 ms, thus emulating delays consistent with the 10 ms sync-frame transmission rate. 42 A 20 ns sampling clock ambiguity (corresponding to 25 MHz) is incorporated into the MAC component 43 (emulated by the DupMacTxExec routine). 44 45 The cable is modeled as a symmetric 500ns delay, corresponding to a cable length of approximately 100 46 meters. 47 48 Station clock accuracies are assigned randomly/uniformly within the range of the allowed ±100 PPM 49 deviation from the simulation’s emulated/exact systemTime reference. 50 51 NOTE—Please be tolerant of the editor of this document, who just downloaded the gnuplot application and fft4 library 52 today. These initial cut-and-paste of plots are primitive (to be improved, when EPS or other formats are understood) and 53 no noise-spectrum plots (to better illustrate gain peaking) are currently available. Improvements expected soon… 54

Contribution from: [email protected]. 96 This is an unapproved working paper, subject to change. AVB BRIDGING JggDvj20050416/D0.728 2007-09-26

D.2 Initialization transients 1 2 3 D.2.1 Cascaded 8 stations 4 5 A significant expected initialization transient is observed when all stations simultaneously start operations, 6 as illustrated in Figure D.2. This can be contributed to inaccurate initial estimates of receiver’s link-delay 7 and transmitter’s rate estimations. The transient delays (although significant) are much less than expected 8 from designs based on many-sample grandmaster rate-syntonization delays within bridges. 9 10 11 4e-06 "valueInt8b" 12 3e-06 13 14 2e-06 15 1e-06 16 17 0 18 -1e-06 19 20 -2e-06 21 -3e-06 22 0 0.5 1 1.5 2 2.5 3 3.5 4 23 24 Figure D.2—Startup transients with 8 stations 25 26 D.2.2 Cascaded 64 stations 27 28 The length of the initialization transient increases when the number of bridges is increased to 64, as 29 illustrated in Figure D.3. The much-longer duration of such transients is perhaps tolerable, but illustrates the 30 desire to avoid extrapolation-based on many-sample grandmaster rate-syntonization delays within bridges. 31 32 33 1e-05 34 "valueInt64b" 35 5e-06 36 37 0 38

-5e-06 39 40 -1e-05 41 42 -1.5e-05 43

-2e-05 44 0 0.5 1 1.5 2 2.5 3 3.5 4 45 46 Figure D.3—Startup transients with 64 stations 47 48 49 50 51 52 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 97 JggDvj20050416/D0.728 WHITE PAPER CONTRIBUTION TO 2007-09-26

1 D.3 Steady-state interpolation errors 2 3 4 D.3.1 Time interpolation with 8 stations 5 6 Simulations indicate modest peak-to-peak errors for 8-bridge topologies when interpolation-based protocols 7 are used, as illustrated in Figure D.4. 8 9 1.5e-07 10 "valueInt8b"

11 1e-07 12 13 5e-08 14 15 0

16 -5e-08 17 18 -1e-07 19 -1.5e-07 20 50 60 70 80 90 100 21 22 Figure D.4—Time interpolation with 8 stations 23 24 25 D.3.2 Time interpolation with 64 stations 26 27 Simulations indicate modest peak-to-peak error increases for 64-bridge topologies (as expected to 8-bridge 28 topologies) when interpolation-based protocols are used, as illustrated in Figure D.5. The data is consistent 29 with less-than-linear expectations, due to statistical averaging and intermediate interpolation filtering. 30 31 32 4e-07 "valueInt64b" 33 3e-07 34 35 2e-07

36 1e-07 37 38 0

39 -1e-07 40 41 -2e-07

42 -3e-07 43 50 60 70 80 90 100 44 45 Figure D.5—Time interpolation with 64 stations 46 47 48 49 50 51 52 53 54

Contribution from: [email protected]. 98 This is an unapproved working paper, subject to change. AVB BRIDGING JggDvj20050416/D0.728 2007-09-26

D.4 Steady-state extrapolation errors 1 2 3 D.4.1 Time extrapolation with 8 stations 4 5 Simulations indicate approximately twice the errors for 8-bridge topologies when extrapolation-based 6 protocols (as opposed to interpolation-based protocols) are used, as illustrated in Figure D.6. 7 8 9 4e-07 "valueExt8b" 10 3e-07 11 2e-07 12

1e-07 13 14 0 15 -1e-07 16

-2e-07 17 18 -3e-07 19 -4e-07 50 60 70 80 90 100 20 21 22 Figure D.6—Time extrapolation with 8 stations 23 24 D.4.2 Time extrapolation with 64 stations 25 26 Simulations indicate significantly larger peak-to-peak errors for 64-bridge topologies when 27 extrapolation-based protocols (as opposed to interpolation-based protocols) are used, as illustrated in 28 Figure D.7. 29 30 31 8e-05 32 "valueExt64b" 6e-05 33 34 4e-05 35 2e-05 36 0 37

-2e-05 38 39 -4e-05 40 -6e-05 41

-8e-05 42 50 60 70 80 90 100 43 44 Figure D.7—Time extrapolation with 64 stations 45 46 47 48 49 50 51 52 53 54

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 99 JggDvj20050416/D0.728 WHITE PAPER CONTRIBUTION TO 2007-09-26

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

Contribution from: [email protected]. 100 This is an unapproved working paper, subject to change. AVB BRIDGING JggDvj20050416/D0.728 2007-09-26

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

Contribution from: [email protected]. This is an unapproved working paper, subject to change. 101 JggDvj20050416/D0.728 WHITE PAPER CONTRIBUTION TO 2007-09-26

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

Contribution from: [email protected]. 102 This is an unapproved working paper, subject to change. AVB BRIDGING JggDvj20050416/D0.728 2007-09-26

F.1.3 IEEE 1588 timer format 1 2 IEEE Std 1588-2002 timer format consists of seconds and nanoseconds fields components, as illustrated in 3 Figure F.3. The nanoseconds field must be less than 109; a distinct sign bit indicates whether the time repre- 4 sents before or after the epoch duration. 5 6 MSB LSB 7 seconds s nanoSeconds 8 9 Legend: s: sign 10 11 Figure F.3—IEEE 1588 timer format 12 13 14 F.1.4 EPON timer format 15 16 The IEEE 802.3 EPON timer format consists of a 32-bit scaled nanosecond value, as illustrated in 17 Figure F.4. This clock is logically incremented once each 16 ns interval. 18 19 MSB LSB 20 nanoTicks 21 seconds = nanoTicks/62500000 22 23 Figure F.4—EPON timer format 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. 103