IEEE P1722/D1.1 Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks 2008-08-25
IEEE P1722/Draft #1.1 1 2 Date: 2008-08-25 3 4 5 6 7 Draft Standard for Layer 2 Transport 8 9 Protocol for Time Sensitive Applications 10 11 12 in Bridged Local Area Networks 13 14 15 16 17 18 19 20 Sponsor: 21 Microprocessor Standards Committee (MSC) of the IEEE Society 22 23 Prepared by the Audio/Video Bridging Layer2 Transport Working Group of the IEEE Computer Society Microprocessors 24 and Microcomputers (C/MSC) 25 Abstract: 26 <
Copyright © 2007-2008 IEEE. All rights reserved i This is an unapproved IEEE Standards Draft, subject to change Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks IEEE P1722/D1.1 2008-08-25
1 2 3 Introduction 4 5 6 (This introduction is not part of IEEE P1722/D0.03 Draft Standard for Layer 2 Transport Protocol for Time Sensitive 7 Applications in Bridged Local Area Networks.) 8 9 <
ii Copyright © 2007-2008 IEEE. All rights reserved This is an unapproved IEEE Standards Draft, subject to change IEEE P1722/D1.1 Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks 2008-08-25
1 <
Copyright © 2007-2008 IEEE. All rights reserved iii This is an unapproved IEEE Standards Draft, subject to change Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks IEEE P1722/D1.1 2008-08-25
1 The following members of the balloting committee voted on this standard. Balloters may have voted for approval, 2 disapproval, or abstention. 3 4 5 6 (to be supplied by IEEE) 7 8 9 When the IEEE-SA Standards Board approved this standard on XX Month 200X, it had the following membership: 10 11 Name, Chair 12 name, Vice Chair 13 name, Secretary 14 15 16 (to be supplied by IEEE) 17 18 19 20 21 *Member Emeritus 22 23 24 25 Also included is the following nonvoting IEEE-SA Standards Board liaisons: 26 27 (To be supplied by IEEE) 28 29 Editor’s name here 30 IEEE Standards Project Editor 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56
iv Copyright © 2007-2008 IEEE. All rights reserved This is an unapproved IEEE Standards Draft, subject to change IEEE P1722/D1.1 Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks 2008-08-25
1 2 Revision history 3 4 The following table shows the change history for this specification. 5 6 Version Date Author Comments 7 8 0.01 2007-07-11 Alan K. First version based on IEEE templates, IEEE other specifications and work 9 Bartky to date from various contributions from http://www.avbtp.org 10 11 0.02 2007-07-13 Alan K. Changed to MSC template. Misc. cleanup 12 Bartky 13 14 0.03 2007-08-10 Alan K. Summary changes: 15 Bartky Edited in initial proposals for Fragmentation/Reassembly, Cross- 16 Timestamp functions. 17 Redesigned encapsulations to accommodate Fragmentation/Reassembly 18 with standardized fields for fragment and packet lengths 19 o Added additional quadlet to all stream data packets 20 o Made it so all even numbered subtypes indicate “standard 21 stream data header format, including 61883/IIDC and 22 Proprietary/Experimental; and made odd numbered subtypes 23 reserved for control 24 . With that, changed reserved subtype value for AV/C 25 control data from 2 to 3. 26 . Also changed proprietary control messages to be 27 subtype FF16 with subtype_data of zero (0). 28 Edited in changes based on comments from Cupertino face to face 29 meeting. 30 Copied line numbering format from latest MSC template. 31 Added hyperlink, table of contents, references, etc. to output PDF file. 32 33 0.04 2007-08-27 Alan K. Edited in changes based on discussions at Santa Clara face to face 34 Bartky meeting, 2007-08-23. 35 Added 64 bit Stream ID for all frames. Updated diagrams and text 36 accordingly. 37 Added Control/Data bit after Ethertype as MSB and changed subtype 38 field from 7 to 8 bits. Updated values, text and tables accordingly. 39 Edited in some of the changes for fragmentation and reassembly based 40 on emails and teleconference discussions. Still more work to go here, 41 but should be good enough to start discussing again. 42 Created new Annex Z for holding of issues and resolutions during 43 creation of this specification. 44 Started editing some text from initial cut and paste bullets from my 45 PowerPoint based contributions to be more “standard like”text. Still a 46 lot more to go on this, but again hopefully still good enough to discuss at 47 our meetings. 48 49 50 51 52 53 54 55 56
Copyright © 2007-2008 IEEE. All rights reserved v This is an unapproved IEEE Standards Draft, subject to change Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks IEEE P1722/D1.1 2008-08-25
1 2007-11-29 Alan K. David V. James edited in suggested style, syntax, and etc. type 2 0.05 Bartky changes. Editor reviewed all of them and chose which to accept 3 into the document (comments/question on those not accepted 4 welcome). 5 Edited multiple encapsulation changes to realign the AVBTP frame 6 to have the same quadlet alignment as IP packets (original 7 alignment was based on trying to align the AVBTP packet in the 8 same quadlet alignment as an Ethernet Frame, IP packets are 9 actually not quadlet aligned with the frame as the Ethernet header is 10 either 14 or 18 bytes long depending on if the frame is untagged 11 (14) or tagged (18) format. Basically added two additional bytes at 12 the start of each frame. 13 Changed control frame encapsulation to have a standard length and 14 status field (i.e. took advantage of the 2 new bytes added). 15 16 Incorporated initial cut and paste and some modifications to John 17 Nels Fuller’scontribution on AV/C Command Transport Protocol. 18 Misc. cleanup, rewording and clarification of Fragmentation section 19 (still more to work here). 20 Initial incorporation of Craig Gunther’scontribution on AVBTP 21 timestamp and 61883 SYT processing (mostly cut and paste, some 22 minor edit’s) 23 0.06 2008-03-07 Alan K. Edited in John’s Fuller’s contribution on Command Transport 24 Bartky Protocol and did some misc. editing and cleanup. Also, per group 25 consensus changed OPEN and CLOSE to OPEN and CLOSE 26 Edited in Dave Olsen’scontributions on Timing/Synchronization 27 and also MAC address allocation. For MAC address Allocation, 28 created a new normative Annex (note: this may move to another 29 IEEE 802 based standard in the future, but for now, we will keep 30 working on this in P1722). 31 o In process of editing the text in, did several changes from 32 “should”to “shall”based on my understanding of the text 33 and needs of the protocol as described by the text. The 34 editor kindly requests others review all uses of “should” 35 and “shall”throughout the document. 36 Updated AVBTP name list to be more reflective of those actually 37 working and contributing to the standard. 38 Moved fragmentation/reassembly details from main text to Annex B 39 as native AVBTP end stations will use CIP to do the breaking up of 40 source data into AVBTP packets and will not support CIP packets 41 42 that do not fit in a maximum size Ethernet frame. This work may 43 still be useful for IEEE 1394 to AVBTP interworking units, so 44 moving the text and diagrams there as a placeholder. 45 Added some placeholder text from some new assumptions as 46 discussed at the Sandy Utah face to face meeting and entered into 47 the draft assumptions document. 48 49 50 51 52 53 54 55 56
vi Copyright © 2007-2008 IEEE. All rights reserved This is an unapproved IEEE Standards Draft, subject to change IEEE P1722/D1.1 Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks 2008-08-25
2008-04-07 Alan K. Updated editor’scontact information 1 0.7 2 Bartky Updated Web page and email address info to official IEEE 1722 3 web site 4 Significantly updated Annex C based on discussions in IEEE 1722 5 and 802.1 AVB meetings. 6 Changed from “Multicast MAC address acquisition o 7 protocol”to “MAC address acquisition protocol”to reflect 8 request to allow protocol to be expanded to also allow 9 allocation of Source MAC addresses and to allow for a 10 future DHCP like server for allocating MAC addresses. 11 . Based on that added new proposed fields and 12 protocol operations 13 Added new tables and parameters to make it easier to tune. o 14 Per discussions from last face to face meeting and also on 15 teleconferences, Changed fields: 16 o gm_info to gm_discontinuity 17 o gm_generation to stream_reserved2 18 19 0.8 2008-05-18 Alan K. Removed Cross timestamp and Fragmentation from Annex B based Bartky on agreement to have 1394 to Ethernet AVBTP gateways use the 20 source cycle time in the gateway_info field and require that 1394 to 21 AVBTP gateways break up and reassemble as necessary on data 22 block boundaries (i.e. Break up large CIP packets into multiple 23 smaller CIP packets that fit on Ethernet and then reassemble as 24 necessary when sending back on 1394 networks). 25 Changed diagrams and data definition to look more like IETF 26 documents (bits 00-31, big endian format). Came up with a hybrid 27 format that hopefully should please those familiar with 1394 28 conventions and/or IETF conventions. 29 Changed format and some supporting text on MAAP protocol in 30 Annex C to: 31 32 o Use start and length instead of start and end 33 o Added renewal time field 34 Started some work on 61883 based timing and synchronization 35 sections by going through the 61883 series of documents and 36 putting in this document key sections that need to change to work in an AVBTP environment based on design needs and discussions to 37 date. 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56
Copyright © 2007-2008 IEEE. All rights reserved vii This is an unapproved IEEE Standards Draft, subject to change Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks IEEE P1722/D1.1 2008-08-25
1 2008-06-15 Alan K. Edited text based on editorial comments received from Kevin Gross 2 0.9 Bartky Misc. editing of some TBD and placeholder text into more 3 descriptive text. 4 Removed John Fuller’sCommand Transport Protocol (CTP) as we 5 now have consensus that for 61883 over AVBTP applications that 6 7 require AV/C, we will instead require the use of the new AV/C over 8 IP specification being developed by the 1394 Trade Association. 9 Added gateway_info_valid field based on recommendation from 10 Matt Mora and agreed to at AVBTP teleconferences. Created initial 11 draft text to describe the field and also updated all stream data 12 packet diagrams accordingly. 13 Misc. cleanup/clarification of bits within bytes for various fields in 14 AVBTP frames. 15 Added additional reference documents and referenced them within 16 the document as appropriate. 17 Added additional details (diagrams and text) for handling of CIP 18 packets with source packets (SPH==1) of 61883-4 and -7 (MPEG 19 over CIP). 20 2008-08-10 Alan K. Created version for intended for initial ballot. 21 1.0 Bartky o Removed sections not worked on 22 o Removed miscellaneous editors notes 23 o Removed service interface sections (consensus to remove 24 this was done at the last face to face meeting) 25 Added 802.11 encapsulation information from Ganesh 26 Added late presentation time bit as discussed at the last face to face 27 meeting in Fremont, California. 28 29 Cleaned up some of the text relating to presentation time and 30 synchronization, in particular to clean up text relating to 61883-4 31 and 61883-7 which uses the source packet header time instead of 32 the avbtp_timestamp field. 33 1.1 2008-08-25 Alan K. Edited in comments and suggestions from face to face meeting in 34 Bartky Santa Clara California on August 21, 2008 35 o Removed editor’snotes in section 1 36 o Removed contribution for 802.11 as it did not get 37 consensus to add and instead it was agreed to instead 38 specify requirements for wireless networks and let the 39 work proceed in groups such as 802.11v and 802.11aa to 40 get AVB working on AVBTP networks. 41 o Moved media specific for 802.3 and 802.11 to annexes 42 (new Annexes D and E) 43 o Fixed some typographical and grammatical errors 44 o Added additional editor’snotes based on comments taken 45 from the meeting. 46 o Changed bit values of “one”and “zero”to “one(1)”and 47 “zero(0)”for consistency throughout the document. 48 o Added new version number field for all AVBTP frames 49 and fixed or added new text and diagrams accordgingly 50 Submitted for initial ballot 51 52 53 54 55 56
viii Copyright © 2007-2008 IEEE. All rights reserved This is an unapproved IEEE Standards Draft, subject to change IEEE P1722/D1.1 Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks 2008-08-25
1 Table of contents 2 3 1. Overview ...... 13 4 1.1 Scope ...... 13 5 1.2 Purpose ...... 13 6 1.3 Clauses...... 14 7 8 2. References...... 15 9 10 3. Terms, definitions, and notation...... 17 11 3.1 Conformance levels ...... 17 12 3.2 Glossary of terms...... 18 13 3.3 Unimplemented locations...... 20 14 3.4 Numerical values ...... 20 15 3.5 Notation of fields and values taken from other documents ...... 20 16 3.5.1 Bit, byte, doublet, quadlet and octlet ordering ...... 21 17 3.5.2 Field value conventions...... 23 18 3.6 Informative notes...... 23 19 20 4. Abbreviations and acronyms...... 24 21 22 23 5. AVBTP base protocol...... 27 24 5.1 Overview...... 27 25 5.1.1 Link bandwidth utilization...... 27 5.1.2 Functional device type names...... 27 26 5.1.3 Interoperation with 802.1 AVB bridges ...... 27 27 28 5.1.4 Point to point operation ...... 27 29 5.2 AVBTP frame common header format ...... 28 30 5.2.1 cd (control/data indicator) field...... 29 31 5.2.2 subtype field ...... 30 32 5.2.3 sv field...... 30 33 5.2.4 version field...... 30 5.2.5 subtype_data1 field ...... 30 34 5.2.6 subtype_data2 field ...... 30 35 5.2.7 stream_id field ...... 30 36 5.3 AVBTP common control frame header format...... 32 37 5.3.1 control_data1 field ...... 33 38 5.3.2 status field...... 33 39 40 5.3.3 control_data_length field...... 33 41 5.4 AVBTP common stream data frame header format...... 34 5.4.1 subtype_data1 field subfields...... 35 42 5.4.2 r: (reserved) subfield ...... 35 43 5.4.3 lp: (late presentation) subfield ...... 35 44 5.4.4 gv: (gateway_info field valid) subfield...... 36 45 5.4.5 tv: (avbtp_timestamp field valid) subfield...... 36 46 5.4.6 gm_discontinuity field...... 36 47 5.4.7 h (holdover) field ...... 37 48 5.4.8 stream_id (802.1Qat stream identifier) field...... 37 49 5.4.9 avbtp_timestamp field...... 37 50 5.4.10 gateway_info field...... 37 51 5.4.11 packet_data_length field...... 37 52 5.4.12 protocol_specific_packet_header field ...... 38 53 5.4.13 stream_data_payload field ...... 38 54 5.5 Timing and synchronization...... 39 55 56
Copyright © 2007-2008 IEEE. All rights reserved ix This is an unapproved IEEE Standards Draft, subject to change Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks IEEE P1722/D1.1 2008-08-25
1 5.5.1 General ...... 39 2 5.5.2 AVBTP presentation time...... 39 3 5.5.3 gm_discontinuity...... 39 4 5.6 Protocol layering and other required protocols...... 41 5 6 6. 61883/IIDC over AVBTP protocol...... 42 7 6.1 Overview...... 42 8 6.2 Common 61883/IIDC Stream data encapsulation...... 43 9 6.2.1 tag field...... 44 10 6.2.2 channel field ...... 44 11 6.2.3 tcode (type code)...... 44 12 6.2.4 sy field...... 44 13 6.3 ”Data field unformatted”encapsulation (used by IIDC) ...... 45 14 6.4 IEC-61883 CIP encapsulation ...... 46 15 6.4.1 CIP header 1st quadlet indicator ...... 47 16 6.4.2 SID (source ID) field...... 47 17 6.4.3 Data Block Size (DBS)...... 48 18 6.4.4 QPC (quadlet Padding count) ...... 48 19 6.4.5 FN (fraction number) field...... 48 20 6.4.6 SPH (source packet header) field ...... 48 21 6.4.7 Rsv (reserved) field...... 48 22 6.4.8 DBC (data block count) field...... 48 23 6.4.9 CIP header 2nd quadlet indicator ...... 49 24 6.4.10 FMT (stream format), field...... 49 25 6.4.11 FDF (format dependent field) ...... 49 26 6.4.12 SYT (synchronization timing) field (1394 cycle time based presentation time for SPH field equals 0) 49 27 6.4.13 avbtp_source_packet_header_timestamp field (802.1AS time based presentation time for SPH field 28 equals 1)...... 49 29 6.5 61883 over AVBTP control frame format...... 50 30 6.6 Use of AV/C higher layer protocol in 61883 over AVBTP end stations...... 50 31 6.7 Session management...... 50 32 6.7.1 Overview ...... 50 33 6.8 Timing and Synchronization ...... 51 34 6.8.1 General ...... 51 35 6.8.2 61883-2 timing and synchronization ...... 52 36 6.8.3 61883-4 timing and synchronization ...... 52 37 6.8.4 61883-6 timing and synchronization ...... 53 38 6.8.5 61883-7 timing and synchronization ...... 54 39 6.8.6 61883-8 timing and synchronization ...... 54 40 41 7. Proprietary/Experimental subtype AVBTP protocol ...... 59 42 7.1 Overview...... 59 43 7.2 Proprietary/Experimental subtype stream data format ...... 59 44 7.3 Proprietary/Experimental subtype control format...... 60 45 46 Annex A (informative) Bibliography ...... 61 47 48 Annex B (normative) Interworking 61883 between AVBTP and IEEE 1394 networks...... 63 49 B.1 Introduction ...... 63 50 B.2 1394 to/from IEEE 802 AVBTP Interworking scenarios ...... 63 51 B.2.1 Encapsulation...... 64 52 B.2.2 Stream Sequencing, Fragmentation and Reassembly procedures...... 65 53 B.3 Timing and synchronization ...... 65 54 55 Annex C (normative) MAC Address Acquisition Protocol (MAAP) ...... 67 56 C.1 Overview ...... 67
x Copyright © 2007-2008 IEEE. All rights reserved This is an unapproved IEEE Standards Draft, subject to change IEEE P1722/D1.1 Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks 2008-08-25
C.2 Protocol Message Format ...... 67 1 C.3 Requesting an address range...... 70 2 C.4 Announcing an acquired MAC Address Range ...... 71 3 C.5 Defending a MAC Address Range...... 71 4 5 Annex D (informative)802.3 Media specific encapsulation...... 73 6 D.1 Introduction ...... 73 7 D.2 802.3 Fields...... 75 8 D.2.1 802.3 Destination MAC address field ...... 75 9 D.2.2 802.3 Source MAC address field ...... 75 10 D.2.3 802.1Q header field...... 76 11 12 Annex E (informative) 802.11 media encapsulation ...... 79 13 14 Annex Z (informative) COMMENTARY ...... 81 15 Z.1 Unicast Destination MAC address support for stream data frames? ...... 81 16 Z.2 Need mechanism for getting PCP value for Class A and Class B streams...... 81 17 Z.3 Does AV/C protocol need its own subtype? ...... 81 18 Z.4 Need to define more details on format and function of AVBTP source Timestamp and relationship to use of the 19 61883 SYT field...... 82 20 Z.5 Need to define how 802.1Qat stream IDs are used by AVBTP...... 83 21 Z.6 Need to define what happens if presentation time has passed and/or is out of range...... 83 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 55 56
Copyright © 2007-2008 IEEE. All rights reserved xi This is an unapproved IEEE Standards Draft, subject to change Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks IEEE P1722/D1.1 2008-08-25
1 List of figures 2 Figure 3.1 - Bit ordering within a byte ...... 21 3 Figure 3.2 - Byte ordering within a quadlet ...... 21 4 Figure 3.3 - Example 4 byte quadlet field diagram ...... 22 5 Figure 3.4 - Example 8 byte octlet field diagram ...... 22 6 Figure 5.4 — AVBTP frame common header fields ...... 29 7 Figure 5.5 - Control frame common fields...... 32 8 Figure 5.6 --AVBTP common stream data header format (cd field set to zero(0)) ...... 35 9 Figure 6.1 61883/IIDC common header fields...... 43 10 Figure 6.2 - 61883/IIDC frame header fields...... 45 11 Figure 6.3— CIP header and data fields, tag= 1, SPH = 0...... 46 12 Figure 6.4— CIP header and data fields, tag=1, SPH = 1...... 47 13 Figure 7.1 -- Proprietary/Experimental stream data format ...... 59 14 Figure 7.2— Proprietary/Experimental control escape subtype format...... 60 15 Figure D.1 - AVBTP control or stream data frame within an 802.3 frame with 802.1Q tag field...... 74 16 Figure D.2 - AVBTP control frame within an 802.3 frame without an 802.1Q Tag field ...... 75 17 18 19 List of tables 20 Table 3.1wrap field values...... 23 21 Table 5.1 -- AVBTP subtype values...... 30 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 55 56
xii Copyright © 2007-2008 IEEE. All rights reserved This is an unapproved IEEE Standards Draft, subject to change IEEE P1722/D1.1 Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks 2008-08-25
1 2 Draft Standard for Layer 2 Transport 3 4 Protocol for Time Sensitive Applications in 5 6 Bridged Local Area Networks 7 8 9 10 11 12 1. Overview 13 14 Increasingly, entertainment media is digitally transported. Streaming audio/video and interactive applications over 15 bridged LANs need to have comparable real-time performance with legacy analog distribution. There is significant end- 16 user and vendor interest in defining a simple yet common method for handling real-time audio/video suitable for 17 consumer electronics, professional A/V applications, etc. Technologies such as IEEE 1394, Bluetooth and USB exist 18 today but each has their own encapsulation, protocols, timing control, etc. such that building interworking functions is 19 difficult. The use of a common audio/video transport over multiple IEEE 802 network types will realize operational and 20 equipment cost benefits. By ensuring that all IEEE 802 wired and wireless devices share a common set of transport 21 mechanisms for time-sensitive audio/video streams, we lessen the effort of producing interworking units between IEEE 22 802 and other digital networks. 23 24 25 1.1 Scope 26 27 This standard specifies the protocol, data encapsulations, connection management and presentation time procedures used 28 to ensure interoperability between audio and video based end stations that use standard networking services provided by 29 all IEEE 802 networks meeting QoS requirements for time-sensitive applications by leveraging concepts of IEC 61883-1 30 through IEC 61883-8. 31 32 33 1.2 Purpose 34 35 This standard will facilitate interoperability between stations that stream time-sensitive audio and/or video across LANs 36 providing time synchronization and latency/bandwidth services by defining the packet format and stream setup, control, 37 and teardown protocols. 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56
Copyright © 2007-2008 IEEE. All rights reserved 13 This is an unapproved IEEE Standards Draft, subject to change Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks IEEE P1722/D1.1 2008-08-25
1 2 3 4 1.3 Clauses 5 6 Clauses in this document are as follows: 7 Clause 1. Overview. 8 9 Clause 2. References 10 Clause 3. Terms, definitions, and notation 11 12 Clause 4. Abbreviations and acronyms 13 Clause 5. AVBTP base protocol 14 15 Clause 6. 61883/IIDC over AVBTP protocol 16 17 Clause7. Proprietary/Experimental subtype AVBTP protocol 18 Annex A. (informative) Bibliography. 19 20 Annex B (normative) Interworking 61883 between AVBTP and IEEE 1394 networks 21 Annex C (normative) MAC address Acquisition protocol 22 23 Annex D (informative)802.3 Media specific encapsulation 24 Annex E (informative) 802.11 media encapsulation 25 26 Annex Z (informative) COMMENTARY 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 55 56
14 Copyright © 2007-2008 IEEE. All rights reserved This is an unapproved IEEE Standards Draft, subject to change IEEE P1722/D1.1 Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks 2008-08-25
2. References 1 2 The following standards contain provisions that, through reference in this document, constitute provisions of this 3 standard. All the standards listed are normative references. Informative references are given in Annex A. At the time of 4 publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on 5 this standard are encouraged to investigate the possibility of applying the most recent editions of the standards indicated 6 below. 7 8 [R1] IEEE Std 802®, IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture 1 9 10 [R2] IEC 61784-2:2007, Digital data communications for measurement and control –Part 2: Additional profiles for 11 ISO/IEC 8802-3 based communication networks in real-time applications2 12 13 [R3] IEEE 802.3-2005, IEEE Standards for Information technology –Telecommunications and information exchange 14 between systems –Local and metropolitan area networks –Specific requirements –Part 3: Carrier sense 15 multiple access with collision detection (CSMA/CD) access method and Physical Layer specifications 16 17 [R4] IEEE Std 802.1Q-2005, IEEE Standard for Local and Metropolitan Area Networks---Virtual Bridged Local Area 18 Networks; 19 20 21 [R5] IEEE P802.1AS, IEEE standard for Local and Metropolitan Area Networks: Timing and Synchronization for 22 Time-Sensitive Applications in Bridged Local Area Networks; 23 <
Copyright © 2007-2008 IEEE. All rights reserved 15 This is an unapproved IEEE Standards Draft, subject to change Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks IEEE P1722/D1.1 2008-08-25
1 [R12] IEC 61883-2 (2004-08) Consumer audio/video equipment - Digital interface - Part 2: SD-DVCR data 2 transmission; 3 4 [R13] IEC 61883-4 (2004-08) Consumer audio/video equipment - Digital interface - Part 4: MPEG2-TS data 5 transmission; 6 7 [R14] IEC 61883-6 (2005-10) Consumer audio/video equipment - Digital interface - Part 6: Audio and music data 8 transmission protocol; 9 10 [R15] IEC 61883-7 (2003-01) Consumer audio/video equipment –Digital interface - Part 7: Transmission of ITU-R 11 BO.1294 System B 12 13 [R16] IEC 61883-8 (work in progress) Consumer audio/video equipment - Digital interface - Part 8: Transmission of 14 ITU-RBt.601 style Digital Video Data 15 <
16 Copyright © 2007-2008 IEEE. All rights reserved This is an unapproved IEEE Standards Draft, subject to change IEEE P1722/D1.1 Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks 2008-08-25
New and revised IEEE standards and drafts are available for sale individually (http://shop.ieee.org/), and are also 1 available, via an online subscription (http://standards.ieee.org/catalog/olis/index.html). The Get IEEE 802™® program 2 (http://standards.ieee.org/getieee802/portfolio.html) grants public access to view and download current individual 3 electronic (PDF) IEEE Local and Metropolitan Area Network (IEEE 802®) standards at no charge twelve months after 4 publication. 5 6 IEC publications are available for sale individually, and are also available via an online subscription 7 (http://webstore.iec.ch/). 8 9 1394 Trade Association (1394TA) Members can download the 1394TA specifications for free from the members' 10 website. Please note, however, that the copy right for each specification belongs to the 1394TA. Membership information 11 can be found at: http://www.1394ta.org/About/Join/. For non-members, please contact [email protected] for 12 information on how to obtain a copy of the 1394TA specifications and Technical Bulletins. 13 14 Internet Requests for Comments (RFCs) are available on the World Wide Web at the following URL: 15 http://www.ietf.org/rfc.html. 16 17 18 3. Terms, definitions, and notation 19 20 21 3.1 Conformance levels 22 23 24 Several keywords are used to differentiate between different levels of requirements and optionality, as follows: 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 55 56
Copyright © 2007-2008 IEEE. All rights reserved 17 This is an unapproved IEEE Standards Draft, subject to change Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks IEEE P1722/D1.1 2008-08-25
1 3.1.1 expected: Describe the behavior of the hardware or software in the design models assumed by this specification. 2 Other hardware and software design models may also be implemented. 3 4 3.1.2 may: Indicates a course of action permissible within the limits of the standard with no implied preference (“may” 5 means “is permitted to”). 6 7 3.1.3 shall: Indicates mandatory requirements strictly to be followed in order to conform to the standard and from which 8 no deviation is permitted (“shall”means “is required to”). 9 10 3.1.4 should: An indication that among several possibilities, one is recommended as particularly suitable, without 11 mentioning or excluding others; or that a certain course of action is preferred but not necessarily required; or that (in the 12 negative form) a certain course of action is deprecated but not prohibited (“should”means “is recommended to”). 13 14 15 3.2 Glossary of terms 16 17 <
18 Copyright © 2007-2008 IEEE. All rights reserved This is an unapproved IEEE Standards Draft, subject to change IEEE P1722/D1.1 Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks 2008-08-25
3.2.15 grandmaster selection time: The maximum amount of time required by 802.1AS to elect and propagate new 1 grand master address. 2 3 3.2.16 holdover: A clock previously synchronized/syntonized to another clock (normally a primary reference or a master 4 clock) but now free-running based on its own internal oscillator, whose frequency is being adjusted using data acquired 5 while it had been synchronized/syntonized to the other clock, is said to be in holdover or in the holdover mode, as long as 6 it is within its accuracy requirements. 7 8 3.2.17 holdover mode: When the 802.1AS clock is currently known to be or possibly unstable due to a loss or change in 9 the grandmaster clock status. When detected and reported, the listener and talker shall revert to an internal holdover 10 timing mode, ignoring the 802.1AS clock until the 802.1AS clock has once again stabilized. 11 12 3.2.18 ingress time: Ingress time is when the sample is sent by the talker application to the AVBTP layer. For example, 13 on an I2S interface this is an 802.1AS timestamp of the word clock transition for the received sample. 14 15 3.2.19 link: A network segment between two IEEE 802 ports. 16 17 3.2.20 listener: A listener is a receiver of a stream. 18 19 3.2.21 maximum holdover time: The maximum time allowed for Grandmaster Selection plus clock stabilization on a 20 listener. 21 <
Copyright © 2007-2008 IEEE. All rights reserved 19 This is an unapproved IEEE Standards Draft, subject to change Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks IEEE P1722/D1.1 2008-08-25
1 2 3 3.3 Unimplemented locations 4 5 The capabilities of all reserved, ignored, and unused values are carefully defined, to minimize conflicts between current 6 implementations and future definitions. 7 8 3.3.1 reserved fields: A set of bits within a data structure that is defined in this specification as reserved, and is not 9 otherwise used. Implementations of this specification shall zero these fields. Future revisions of this specification, 10 however, may define their usage. 11 12 3.3.2 ignored location: Selected locations or portions of locations are partially implemented and are defined to be 13 ignored. An ignored value has an affiliated storage element, but the value in the storage elements has no side effect. 14 15 3.3.3 reserved location: Some locations or portions of locations are not implemented and are defined to be reserved. 16 When a reserved value is written, a zero values shall be assumed; when read, the returned value shall be ignored. 17 18 3.3.4 unused location: Selected locations or portions of locations may be not implemented or partially implemented and 19 are defined to be unused. For unused locations, the selection between reserved and ignored behaviors is implementation 20 dependent. 21 22 23 3.4 Numerical values 24 25 Decimal, hexadecimal, and binary numbers are used within this document. For clarity, decimal numbers are generally 26 used to represent counts, hexadecimal numbers are used to represent addresses, and binary numbers are used to describe 27 bit patterns within binary fields. 28 29 Decimal numbers are represented in their usual 0, 1, 2, … format. Hexadecimal numbers are represented by a string of 30 one or more hexadecimal (0-9,A-F) digits followed by the subscript 16. Binary numbers are represented by a string of one 31 or more binary (0,1) digits in left to right order where the left most bit is the most significant bit and the right most bit is 32 the least significant bit, followed by the subscript 2. Thus the decimal number “26”may also be represented as “1A16”or 33 “110102”. 34 35 These notational conventions have one exception: MAC addresses and OUI/EUI values are represented as strings of 8-bit 36 hexadecimal numbers separated by hyphens and without a subscript, as for example “01-80-C2-00-00-15”or 37 “AA-55-11”. 38 39 40 3.5 Notation of fields and values taken from other documents 41 42 This document uses fields and values defined in other documents with multiple methods of defining such things as usage 43 of upper and lower case, usage of underscore characters, italics, etc. As this document is intended to use these multiple 44 protocols, its additional intent is also to make it easier for readers and implementers of those documents by not using 45 different names and notation for those fields and values. So the following conventions are used for field names from other 46 documents to match the convention from those documents. 47 48 a) Fields from IEEE 802.1Q: Fields are in all uppercase, no underscores (examples: DA, SA, TPID, CFI, VID) 49 50 b) Fields from IEEE 1394: Fields in lower case except for acronyms within the field name with optional 51 underscores (examples: tcode, data_length, source_ID) 52 c) Fields from IEC 61883: Fields always starting in uppercase, acronyms in uppercase, abbreviations with 53 uppercase first followed by lowercase, no underscores (examples: DBC, DBS, Rsv). 54 55 56
20 Copyright © 2007-2008 IEEE. All rights reserved This is an unapproved IEEE Standards Draft, subject to change IEEE P1722/D1.1 Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks 2008-08-25
3.5.1 Bit, byte, doublet, quadlet and octlet ordering 1 2 Similar to IETF RFC 0791 [R17] Internet Protocol (IP), this protocol is agnostic to the underlying bit order used by layers 3 below it. Therefore all frame and packet formats contained within are specified as a series of 8 bit bytes where the actual 4 transmission, reception, storage and retrieval of bits within the bytes are machine and/or lower layer specific. 5 6 This document uses the same convention as IEEE 1394 for abbreviating the following terms: 7 8 a) lsb: least significant bit (bit 7) 9 b) msb: most significant bit (bit 0) 10 11 c) LSB: least significant byte 12 d) MSB: most significant byte 13 14 Like Internet Protocol, the actual ordering of multiple bytes to store larger numbers or arrays of data is specified in big- 15 endian order where the first byte of a multi-byte number is the most significant byte and the last byte is the least 16 significant byte. 17 18 The significance of the interior bits within a byte uniformly decreases in progression from msb to lsb where msb is 19 labeled as bit 0 and lsb is bit 7 and is shown in this document in a left to right order as follows. 20 21 22 23 0 1 2 3 4 5 6 7 24 25 0 0 0 0 0 0 0 1 26 27 msb lsb 28 29 30 Figure 3.1 - Bit ordering within a byte 31 32 For the above figure, this would represent a decimal value of 1, a hexadecimal value of 0116 and a binary value of 33 000000012 with the only bit in the byte set to one of the least significant bit, bit 7. 34 35 This protocol specifies that all data to be transmitted and received for control and data frames shall always be using an 36 integral number of 4 byte quadlets. A quadlet is a series of 4 bytes within a quadlet, the most significant byte is that 37 which is transmitted first and the least significant byte is that which is transmitted last, as shown below. 38 39 40 0 1 2 3 41 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 42 0 0 0 0 0 0 0 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 1 0 0 0 0 0 1 0 0 43 44 msb lsb msb lsb msb lsb msb lsb 45 46 Figure 3.2 - Byte ordering within a quadlet 47 48 For the above figure, this would represent a quadlet holding four byte array of 1, 2, 3, 4 decimal. Also the byte on the left 49 is the first transmitted, with subsequent bytes being transmitted from left to right. This specification does not specify 50 which bit within each byte is transmitted first as that is part of the lower layer LAN specification such as 802.3 or 802.11. 51 52 A quadlet may contain bit fields of any length between 1 and 32 bits transmitted or received as a series of bytes. When a 53 field spans more than one byte, the point where it spans the byte is shown as a large tick mark as follows: 54 55 56
Copyright © 2007-2008 IEEE. All rights reserved 21 This is an unapproved IEEE Standards Draft, subject to change Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks IEEE P1722/D1.1 2008-08-25
1 2 transmitted first 3 0 1 2 3 4 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 5 example_4_byte_quadlet_field 6 7 transmitted last 8 9 Figure 3.3 - Example 4 byte quadlet field diagram 10 11 For 64 bit fields that need to be contained in more than one quadlet, they are still transmitted and received as a series of 8 12 bytes, but for this document are shown in diagrams as follows: 13 14 15 transmitted first 16 0 1 2 3 17 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 18 19 20 example_8_byte_octlet_field 21 22 transmitted last 23 24 Figure 3.4 - Example 8 byte octlet field diagram 25 26 When block transfers take place that are not quadlet aligned or not an integral number of quadlets, no assumptions can be 27 made about the ordering (significance within a quadlet) of bytes at the unaligned beginning or fractional quadlet end of 28 such a block transfer, unless an application has knowledge (outside of the scope of this specification) of the ordering 29 conventions of the other bus. 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 55 56
22 Copyright © 2007-2008 IEEE. All rights reserved This is an unapproved IEEE Standards Draft, subject to change IEEE P1722/D1.1 Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks 2008-08-25
1 2 3.5.2 Field value conventions 3 4 This document describes values of fields. For clarity, names can be associated with each of these defined values, as 5 illustrated in Table 3.1. A symbolic name, consisting of upper case letters with underscore separators, allows other 6 portions of this document to reference the value by its symbolic name, rather than a numerical value. 7 8 Table 3.1wrap field values 9 10 Value Name Description 11 12 0 WRAP_AVOID Frame is discarded at the wrap point 13 1 WRAP_ALLOW Frame passes through wrap points. 14 15 2-3 — Reserved 16 17 Unless otherwise specified, reserved values are reserved for the purpose of allowing extended features to be defined in 18 future revisions of this standard. Devices conforming to this version of this standard do not generate reserved values for 19 fields, and process fields containing reserved values as though the field values were not supported. The intent is to ensure 20 default behaviors for future-specified features. 21 22 A field value of TRUE shall always be interpreted as being equivalent to a numeric value of 1 (one), unless otherwise 23 indicated. A field value of FALSE shall always be interpreted as being equivalent to a numeric value of 0 (zero), unless 24 otherwise indicated. 25 26 27 3.6 Informative notes 28 29 Informative notes are used in this standard to provide guidance to implementers and also to supply useful background 30 material. Such notes never contain normative information, and implementers are not required to adhere to any of their 31 provisions. An example of such a note follows. 32 33 NOTE— This is an example of an informative note. 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56
Copyright © 2007-2008 IEEE. All rights reserved 23 This is an unapproved IEEE Standards Draft, subject to change Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks IEEE P1722/D1.1 2008-08-25
1 4. Abbreviations and acronyms 2 3 <
24 Copyright © 2007-2008 IEEE. All rights reserved This is an unapproved IEEE Standards Draft, subject to change IEEE P1722/D1.1 Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks 2008-08-25
fc fragmentation control 1 2 GASP global asynchronous stream packet 3 GM grandmaster 4 5 GMT Greenwich mean time 6 GPS global positioning (satellite) system 7 8 HD high definition 9 hdr header 10 11 IEC International Electrotechnical Commission (www.iec.ch) 12 IEEE Institute of Electrical and Electronics Engineers (www.ieee.org) 13 14 IETF Internet Engineering Task Force (www.ietf.org) 15 IP Internet protocol 16 17 IS integration service 18 ISO International Organization for Standardization (www.iso.org) 19 20 IWU interworking unit 21 kHz kilohertz (thousand cycles per second) 22 23 LAN local area network 24 LLC IEEE 802.2 logical link control 25 26 LLDP IEEE link layer discovery protocol 27 lsb least significant bit 28 29 LSB least significant byte 30 LMI layer management interface 31 32 M mandatory 33 34 MAAP MAC address acquisition protocol 35 MAC media access control 36 37 MACsec media access control security 38 MHz megahertz (million cycles per second) 39 40 MPEG Moving Pictures Expert Group (http://www.chiariglione.org/mpeg/) 41 MS master to slave 42 43 msb most significant bit 44 MSB most significant byte 45 46 MTU maximum transmission unit size 47 N/A not applicable 48 49 NTP network time protocol (www.ietf.org/rfc/rfc1305.txt) 50 O optional 51 OC ordinary clock 52 53 OUI IEEE organizationally unique identifier 54 P preliminary 55 56
Copyright © 2007-2008 IEEE. All rights reserved 25 This is an unapproved IEEE Standards Draft, subject to change Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks IEEE P1722/D1.1 2008-08-25
1 P2P peer to peer 2 PAR project authorization request 3 4 PCP priority code point 5 PICS protocol implementation conformance statement 6 7 PLL phased lock loop 8 9 PTP precision time protocol 10 QoS quality of service 11 12 Rsv, res reserved 13 S Bridge IEEE 802.1AS bridge 14 15 SD standard definition 16 SI international system of units 17 18 SID source identifier 19 SM slave to master 20 21 src source 22 SRP stream reservation protocol 23 24 STA (wireless LAN) station 25 TAI temps atomique international (international atomic time) 26 27 TBD to be done (or determined) 28 TC transparent clock 29 30 TG task group 31 TLV type, length, value 32 33 TPID tagged protocol identifier (81-0016 as defined in standard IEEE 802.1Q) 34 TS timestamp 35 36 tv timestamp valid 37 UTC coordinated universal time 38 39 VID VLAN identifier 40 VLAN Virtual Local Area Network 41 42 WG working group 43 44 WLAN wireless local area network 45 X prohibited 46 47 XTS cross timestamp 48 49 50 51 52 53 54 55 56
26 Copyright © 2007-2008 IEEE. All rights reserved This is an unapproved IEEE Standards Draft, subject to change IEEE P1722/D1.1 Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks 2008-08-25
5. AVBTP base protocol 1 2 <
Copyright © 2007-2008 IEEE. All rights reserved 27 This is an unapproved IEEE Standards Draft, subject to change Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks IEEE P1722/D1.1 2008-08-25
1 << Editor’snote: At this point in previous versions of the document, it contained text for 802.3 and 802.11 2 encapsulation and misc. other rules. Per agreement at the last face to face meeting, this text has been moved to 3 the annex section and instead, it was requested that in clause 5 we only list common 802 AVB requirements to 4 AVB networks such as: 5 6 7 - Stream data frames packets shall always have an 802.1Q tag field (including both 802.3 and 802.11) 8 9 -Control frames may be 802.1Q tagged on transmit and all AVBTP end stations shall support receiving AVBTP 10 control frames with and without Q tags 11 12 etc. 13 14 Some of this text is in the text that was moved to the Annex section and may be moved and/or modified as 15 appropriate to Clause 5 in future versions of this specification. For now, please see Annex D and Annex E for 16 details on 802.1Q, 802.3 and 802.11>> 17 18 19 5.2 AVBTP frame common header format 20 21 This section documents the fields contained in the first 12 bytes of header that are common to all AVBTP stream data and 22 control frames. These 12 bytes consist of the following fields: 23 24 a) First byte: 25 cd (control/data) field (cd) indicator: most significant 1 bit (bit 0) 26 27 subtype field: remaining 7 bits 28 b) Second byte: 29 sv (Stream ID valid) indicator: most significant 1 bit (bit 0) 30 31 version: AVBTP version, second through fourth most significant bits (bits 1-3) 32 subtype_data1 field: remaining 4 bits 33 34 c) Third and fourth byte: 35 subtype_data2 field: 16 bits 36 37 d) Remaining eight bytes: 38 stream_id field: 64 bits 39 40 The following figure shows these fields with offset zero(00) shown as the first byte of the AVBTP frame which is the 41 first byte after the Ethertype field specifying AVBTP in the 802.3 or 802.11 frame: 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56
28 Copyright © 2007-2008 IEEE. All rights reserved This is an unapproved IEEE Standards Draft, subject to change IEEE P1722/D1.1 Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks 2008-08-25
Figure 5.1 — AVBTP frame common header fields 1 2 3 transmitted first 4 0 1 2 3 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 6 subtype data 00 cd subtype sv version subtype_data1 subtype_data2 7 8 802.1Qat 04 stream_id 9 Stream ID 08 10 12 11 12 13 14 Additional header, payload data and padding varies by subtype 15 16 17 18 As necessary,1-3 byte padding on last or only fragment to fill last quadlet 19 transmitted last 20 21 22 5.2.1 cd (control/data indicator) field 23 24 25 The cd bit indicates whether this AVBTP frame is a control or stream data frame 26 27 If the cd bit is zero(0), then this frame is an AVBTP stream data frame. See 5.4 below for additional encapsulation and 28 protocol rules when this bit is set to zero(0). Only AVBTP talkers can set this field to zero(0) as only talkers can send 29 AVBTP stream data frames. If this field is set to zero(0), then for 802.3 frames, the talker shall ensure the frame is sent 30 with an 802.1Q VLAN tag header present with the appropriate values for the TPID, PCP, CFI and VID fields. 31 32 If this field is set to one(1), then this frame is an AVBTP control frame. See 5.3 below for additional encapsulation and 33 protocol rules when this bit is set to one(1). Any AVBTP station that sends control frames may set this bit to one(1). 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56
Copyright © 2007-2008 IEEE. All rights reserved 29 This is an unapproved IEEE Standards Draft, subject to change Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks IEEE P1722/D1.1 2008-08-25
1 5.2.2 subtype field 2 3 The 7-bit subtype field is used to identify the protocol running over AVBTP. Each protocol defines its use of AVBTP 4 encapsulation within the rules established for common header formats for control and data frames. 5 6 Currently defined subtype values are listed in Table 5.1 below: 7 8 Table 5.1 -- AVBTP subtype values 9 10 Hexadecimal FUNCTION Meaning 11 Value 12 0016 61883_IIDC_SUBTYPE 61883/IIDC over AVBTP protocol 13 0116-7E16 - Reserved for future protocols 14 7F16 PROPRIETARY_SUBTYPE Proprietary/Experimental over AVBTP 15 16 Subsequent parsing of AVBTP frames shall be based on a combination of the values contained within the subtype and cd 17 fields. 18 19 5.2.3 sv field 20 21 The sv field is used to indicate whether the 64 bit stream_id field contains a valid IEEE 802.1Qat stream ID or not. 22 23 The bit is set to one(1) if the stream ID is a valid stream ID 24 25 The bit is set to zero(0) if the stream ID is not valid. 26 27 For more details on valid combinations of the stream_id and sv fields see 5.2.7 below. 28 29 5.2.4 version field 30 31 The version field is used to indicate what version of AVBTP this AVBTP frame is formatted for 32 33 This field is set to zero(0002) if the AVBTP frame is as specified by this version of the 1722 specification. 34 35 Values of one (0012) through seven(1112) are reserved for future versions of the AVBTP protocol. 36 37 38 5.2.5 subtype_data1 field 39 40 The subtype_data1 field consists of the remaining 4 bits of the byte containing the sv and version fields and is used to 41 carry protocol specific data based on the subtype and cd field values. 42 43 44 5.2.6 subtype_data2 field 45 The subtype_data2 field consists of the two bytes (16 bits) following the subtype_data1 field and is used to carry 46 protocol specific data based on the subtype and cd field values. 47 48 49 5.2.7 stream_id field 50 If the sv field is set to one(1), then the stream_id field shall contain the 64 bit IEEE 802.1Qat stream ID associated with 51 the frame.. This field shall be used for stream identification. The field shall be present in all AVBTP frames. 52 53 All AVBTP stream data frames shall contain a valid 64 bit IEEE 802.1Qat Stream ID in the stream_id field and shall set 54 the sv (Stream ID Valid) bit to one(1). 55 56
30 Copyright © 2007-2008 IEEE. All rights reserved This is an unapproved IEEE Standards Draft, subject to change IEEE P1722/D1.1 Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks 2008-08-25
AVBTP control frames relating to an individual stream shall contain a valid 64 bit IEEE 802.1Qat stream ID with the 1 with the sv bit set to one(1). 2 3 AVBTP control frames not related to an individual stream should set the stream_id field to the NULL_STREAM_ID 4 Value and shall set the sv bit to zero(0). 5 6 Note –Setting of the stream_id field to a consistent NULL_STREAM_ID is recommend instead of required as the 7 NULL_STREAM_ID is intended for consistency and to avoid confusion for users such as those debugging AVBTP 8 frame traces (i.e. so they don’tsee old data, or valid stream IDs, etc.). AVBTP end stations when receiving AVBTP 9 frames with the sv bit set to one(1) shall ignore the entire contents of the stream_id field regardless of its value. 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 55 56
Copyright © 2007-2008 IEEE. All rights reserved 31 This is an unapproved IEEE Standards Draft, subject to change Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks IEEE P1722/D1.1 2008-08-25
1 2 3 4 5.3 AVBTP common control frame header format 5 6 This section documents the fields contained in the first 12 bytes of header when the cd bit is set to one(1) indicating that 7 this AVBTP frame is an AVBTP control frame. These 12 bytes consist of the following fields: 8 a) First byte: 9 10 cd (control/data indicator) field as documented in 5.2.1 above: for AVBTP control frames, this 11 field is set to one(1) 12 subtype field: remaining 7 bits (bits 1-7) 13 14 b) Second byte: 15 sv (Stream ID valid) indicator: most significant 1 bit (bit 0) of the second byte(see 5.2.3 above) 16 17 version, second through fourth most significant 3 bits (bits 1-3) of the second byte(see 5.2.4 above) 18 control_data1 field: remaining 4 bits (bits 4-7) of the second byte 19 20 c) Third and fourth byte: 21 status field: most significant 5 bits of the third byte 22 control_frame_length field: 11 bits total consisting of the least significant 3 bits of the third byte 23 and all 8 bits of the fourth byte. 24 25 d) Remaining eight bytes: 26 stream_id field: 64 bits 27 28 The following figure shows these fields with offset zero(00) shown as the first byte of the AVBTP control frame which is 29 the first byte after the Ethertype field in an 802.3 or 802.11 frame: 30 31 32 33 Figure 5.2 - Control frame common fields 34 35 transmitted first 36 0 1 2 3 37 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 cd 38 subtype data 00 subtype sv version control_data1 status control_frame_length(bytes) 39 (1) 802.1Qat 04 40 stream_id 41 Stream ID 08 42 12 43 44 45 46 Controlframe additional headersand payload varies by subtype and subtype_data fields padded if necessaryto ensure an integral number of quadlets 47 48 49 50 As necessary,1-3 byte padding on last or only fragment to fill last quadlet 51 transmitted last 52 53 54 55 56
32 Copyright © 2007-2008 IEEE. All rights reserved This is an unapproved IEEE Standards Draft, subject to change IEEE P1722/D1.1 Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks 2008-08-25
5.3.1 control_data1 field 1 2 The 4 bit control_data1 is available for use by the given control protocol as specified by the subtype field. This field 3 may be used by the control protocol as it sees fit, but is recommended for use for data such as command codes, events, 4 etc. If not used by the given control frame, then this field shall be set to zero(0). 5 6 7 5.3.2 status field 8 9 The 5 bit status field is available for use by the given control protocol as specified by the subtype field. This field may 10 be used by the control protocol as it sees fit, but is recommended for use for data such as status values, flags, etc. If not 11 used by the given control frame, then this field shall be set to zero (0). 12 13 5.3.3 control_data_length field 14 15 The 11 bit control_data_length field is used to contain the unsigned control frame payload length in bytes of all valid 16 data bytes contained in the quadlets following the stream_id field in the AVBTP control frame header. 17 18 1 to 3 pad bytes shall be added at the end of the control frame payload area as necessary to ensure that an integral number 19 of quadlets are in the AVBTP control frame. 20 21 The maximum value for this field shall be 1488 decimal (372 quadlets) to allow all control frames to fit in a single 802.3 22 maximum size Ethernet frame. 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 55 56
Copyright © 2007-2008 IEEE. All rights reserved 33 This is an unapproved IEEE Standards Draft, subject to change Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks IEEE P1722/D1.1 2008-08-25
1 2 3 4 5.4 AVBTP common stream data frame header format. 5 6 AVBTP stream data is designed to standardize common use fields for source timestamping and for packet length. These 7 fields are standardized for all AVBTP frames where the cd field is set to zero(0). 8 9 The AVBTP common stream data header format consists of the following fields after the subtype and in the following 10 byte order: 11 a) subtype_data1 field: 8 bit byte with the following subfields defined when cd field equals zero(0): 12 13 sv (stream_id field valid) most significant 1 bit (bit 0) of this byte(see 5.2.3 above) 14 version, second through fourth most significant 3 bits (bits 1-3) of this byte(see 5.2.4 above) 15 16 r (reserved), fourth least significant 1 bit (bit 4) of this byte 17 lp (late presentation field), third least significant 1 bit (bit 5) of this byte 18 19 gv (gateway_info field valid), second least significant 1 bit (bit 6) of this byte 20 tv (avbtp_timestamp field valid): least significant 1 bit (bit 7)of this byte 21 b) subtype_data2 field: 16 bits with the following subfield defined when cd field equals zero(0): 22 23 sd_reserved2: 8 bits 24 gm_info field: 8 bit byte with the following subfields 25 26 i) gm_discontinuity: most significant 7 bits (bits 0 through 6) of this byte 27 ii) h: holdover: least significant 1 bit (bit 7) of this byte 28 c) stream_id field: 64 bits 29 30 d) avbtp_timestamp: 32 bits 31 e) gateway_info: 32 bits 32 33 f) packet_data_length: 16 bits 34 g) protocol_specific_packet_header: 16 bits 35 36 h) stream_payload_data: 0 to n quadlets (where n does not exceed maximum frame size allowed by the layer 2 37 LAN) 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56
34 Copyright © 2007-2008 IEEE. All rights reserved This is an unapproved IEEE Standards Draft, subject to change IEEE P1722/D1.1 Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks 2008-08-25
Figure 5.3 --AVBTP common stream data header format (cd field set to zero(0)) 1 2 3 transmitted first 4 0 1 2 3 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 6 subtype data cd 00 (0) subtype sv version r lp gv tv sd_reserved2 gm_discontinuity h 7 8 802.1Qat 04 stream_id 9 Stream ID 08 10 AVBTP Time 12 avbtp_timestamp 11 12 Gateway info 16 gateway_info 13 Packet info 20 packet_data_length (bytes) protocol_specific_packet_header 14 15 24 AVBTP payload 16 stream_data_payload 17 (additional protocol header, protocol payload data and padding varies by protocol) 18 19 As necessary, 1-3 byte padding on last or only fragment to fill last quadlet 20 transmitted last 21 22 23 5.4.1 subtype_data1 field subfields 24 The subtype_data1 field for AVBTP stream data (when the cd field is set to zero(0)) has the following subfields defined. 25 26 27 Most significant bit (bit 0) for sv (stream_id field valid) (see 5.2.3 above) 28 Second through fourth most significant bits (bits 1-3) for version(see 5.2.4 above) 29 Fourth least significant bit (bit 4) for r(reserved) bit 30 Third least significant bit (bit 5) for lp(late presentation field) bit 31 Second least significant bit (bit 6) for gv(gateway_info field valid) bit 32 Least significant bit (bit 7) for tv (avbtp_timestamp field valid ) bit 33 34 35 5.4.2 r:(reserved) subfield 36 37 The reserved bit field (r) is a one bit field reserved for future use in stream data frame headers as a single bit field. 38 39 Set this field to zero(0) on transmit and ignored on receive. 40 41 42 5.4.3 lp: (late presentation) subfield 43 44 The late presentation field (lp) field is a one bit field used to by the talker to indicate to listeners that they may process 45 received AVBTP stream data frames that arrive after the presentation time indicated in the frame has already passed. 46 47 This field allows talkers to indicate that it is acceptable or not from the talker application’sperspective for listeners to 48 process data that has arrived after the presentation time represented by the frame has already passed. 49 50 An example application is where a talker is sending audio data with an important announcement that all speakers should 51 play audio data, even if for some reason there is more network delay than anticipated. 52 53 A talker shall set this field to zero(0) for stream data that is important to play always in the correct timeframe and thus 54 requesting the listener(s) to not to deliver the stream data to the application if the data arrives late. 55 56
Copyright © 2007-2008 IEEE. All rights reserved 35 This is an unapproved IEEE Standards Draft, subject to change Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks IEEE P1722/D1.1 2008-08-25
1 A talker shall set this field to one(1) for stream data that it is not important to play always in the correct timeframe and 2 thus requesting the listener(s) to deliver the stream data to the application even if the data arrives late. 3 4 5 5.4.4 gv: (gateway_info field valid) subfield 6 7 The gateway_info field valid (gv) field is a one bit field used to indicate the validity of the gateway_info field. 8 9 This field and the gateway_info field are intended for use for AVBTP gateway to gateway communication. 10 11 AVBTP end stations that do not have an AVBTP gateway function shall set this field to zero(0) on transmit and ignore 12 this field on receive. 13 14 AVBTP end stations that have an AVBTP gateway function when acting as a talker shall: 15 16 Set this field to zero(0) on transmit if other gateways on the LAN segment are to ignore the gateway_info field 17 on reception of the stream data frame. 18 Set this field to one(1) on transmit if other gateways on the LAN segment are to process the gateway_info field 19 on reception of the stream data frame. 20 21 For an example of how the gv and gateway_info fields are processed, see Annex B below. 22 23 24 25 5.4.5 tv: (avbtp_timestamp field valid) subfield 26 The source timestamp valid (tv) field is a one bit field used to indicate the validity of the avbtp_timestamp field time 27 value. 28 29 If the timestamp valid bit is set to zero(0) by the AVBTP talker, then this field shall indicate that the avbtp_timestamp 30 field contains no data and therefore shall be ignored by an AVBTP listener. 31 32 If the timestamp valid bit is set to one(1) by the AVBTP talker, then this field shall indicate that the avbtp_timestamp 33 field is valid. 34 35 For how the avbtp_timestamp field is interpreted and processed see 5.4.9. 36 37 38 39 5.4.6 gm_discontinuity field 40 The gm_discontinuity field indicates a known or possible discontinuity in 802.1AS time. The gm_discontinuity field is 41 stream specific. On stream creation the gm_discontinuity field may be set to any value. During the life of a stream the 42 gm_discontinuity shall be incremented by 1 whenever a signaled or possible discontinuity is indicated from 802.1AS. 43 These indications include, but are not limited to: 44 a) Discontinuity in absolute time 45 b) Discontinuity in frequency 46 c) Loss of Grandmaster clock 47 d) Election of new Grandmaster clock 48 <
36 Copyright © 2007-2008 IEEE. All rights reserved This is an unapproved IEEE Standards Draft, subject to change IEEE P1722/D1.1 Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks 2008-08-25
5.4.7 h (holdover) field 1 2 The 1 bit h field shall be set by the talker anytime the AVBTP timestamp field in this stream is based off of some local 3 clock instead of the 802.1AS based clock (i.e. in holdover clock based on the 802.1AS time from the previously known 4 good grandmaster time). This is used by talkers to indicate that the timestamps may not globally synchronized with 5 network time and can be used by listeners to use this in conjunction with their knowledge of the status of the 802.1AS 6 clock to keep the listener media clock in synchronization with the talker. 7 8 9 5.4.8 stream_id (802.1Qat stream identifier) field 10 11 The stream ID field is the same field as specified in 5.2.7 above. For AVBTP stream data frames, it shall always contain a 12 valid 802.1Qat stream ID. 13 14 15 5.4.9 avbtp_timestamp field 16 17 The 32 bit avbtp_timestamp field shall express presentation time related to the 802.1AS Global Clock if the timestamp 18 valid bit is set to one(1). The avbtp_timestamp represents the low order 32 bits of 802.1AS time in nanoseconds. The 19 avbtp_timestamp rolls over approximately every 4 seconds. 20 21 If the source timestamp valid bit is zero(0), then the content of the avbtp_timestamp field is undefined and should be 22 ignored. 23 24 25 5.4.10 gateway_info field 26 27 28 The 32 bit gateway_info field is used by gateway and interworking units to allow conversion and transport of 29 audio/video data and control between AVBTP networks and other audio/video networks. This field and the gv field are 30 intended for AVBTP gateway to gateway communication. One use is described in Annex B of this document. 31 32 Native AVBTP end stations not participating in AVBTP gateway functions shall set this field to zero on transmit and 33 ignore this field on receive. 34 35 36 5.4.11 packet_data_length field 37 38 The 16 bit packet_data_length field is to indicate the unsigned count of stream frame payload length in bytes of all valid 39 data bytes contained in the quadlets following the protocol_specific_packet_header field in the AVBTP stream data 40 frame header. 41 42 1 to 3 pad bytes shall be added at the end of the stream data frame payload area as necessary to ensure that an integral 43 number of quadlets is in the AVBTP frame. 44 45 The maximum value for this field shall be 1476 decimal to allow all AVBTP stream data frames to fit within a maximum 46 size 802.3 Ethernet frame.. 47 48 Note –This field is sized at a full 16 bits to allow for easier frame size handling for AVBTP gateway functions for other 49 networks such as 1394 which allows larger frame sizes than is allowed on 802.3 networks and also matches the position 50 and function relative to other fields of the IEEE 1394 equivalent field for isochronous frames. As mentioned above, no 51 frame on an AVBTP networks may be larger than a single maximum frame as specified by the IEEE 802.3 LAN 52 standard. 53 54 55 56
Copyright © 2007-2008 IEEE. All rights reserved 37 This is an unapproved IEEE Standards Draft, subject to change Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks IEEE P1722/D1.1 2008-08-25
1 5.4.12 protocol_specific_packet_header field 2 The 16 bit protocol_specific_packet_header field is to carry 16 bits of protocol specific data as specified by the protocol 3 subtype. 4 5 For an example of how this field is used by the 61883 over AVBTP subtype see 6.2 below 6 7 8 9 5.4.13 stream_data_payload field 10 11 The stream_data_payload field consists of 0 to n quadlets of additional protocol specific data with the valid data length 12 is indicated by the packet_data_length field. 13 14 1 to 3 pad bytes shall be added at the end of the stream data frame payload area as necessary to ensure that the AVBTP 15 frame always consists of an integral number of quadlets. 16 17 The maximum byte length for this field shall be 1476 decimal (369 quadlets) to allow for all AVBTP stream data frames 18 to fit within a maximum size 802.3 Ethernet frame. 19 20 For an example of how this field is used by the 61883 over AVBTP subtype using CIP encapsulation see 6.4 below. 21 22 <
38 Copyright © 2007-2008 IEEE. All rights reserved This is an unapproved IEEE Standards Draft, subject to change IEEE P1722/D1.1 Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks 2008-08-25
1 2 3 5.5 Timing and synchronization 4 5 6 5.5.1 General 7 8 AVBTP defines a presentation time to achieve timing synchronization between talker and listener(s). The presentation 9 time represents in nanoseconds the IEEE 802.1AS wall clock time when the data contained in the packet is to be 10 presented to the AVBTP client at the listener(s). 11 12 AVBTP presentation time is used as a reference to synchronize any necessary media clocks and to determine when the 13 first sample of a stream is presented to the client. Because media clocks vary with audio/video types the exact usage of 14 the AVBTP presentation time is media format dependent. 15 16 17 18 5.5.2 AVBTP presentation time 19 The AVBTP presentation time is contained in the avbtp_timestamp field of AVBTP stream data frames. 20 The AVBTP presentation time may not be valid in every AVBTP packet. If an AVBTP packet contains a valid 21 timestamp then the tv (Timestamp Valid) bit shall be set to one(1). 22 23 The AVBTP presentation time represents the timestamp of the when the media sample was presented to AVBTP at the 24 talker plus a delay constant to compensate for network latency. Unless otherwise negotiated between the talker and the 25 listener the delay constant used to calculate the AVBTP presentation time is 2,000,000 nanoseconds (2 milliseconds). 26 27 The AVBTP presentation time as received by the listener(s) in avbtp_timestamp field should be utilized to synchronize 28 the media clock of the listener to the talker. Since the AVBTP presentation time is directly related to the IEEE 802.1AS 29 global time it may also be used to synchronize multiple talkers and listeners. 30 31 32 33 5.5.3 gm_discontinuity 34 35 Although the 802.1AS wall clock time is intended to be stable, it is possible for there to be discontinuities in the 802.1AS wall clock time. These could be due to events such as to changes the identity of the 802.1AS Grandmaster clock or 36 changes in the timing source of the Grandmaster clock. 37 38 To aid in compensating for discontinuities in the 802.1AS time, all AVBTP stream data frames contain a 39 40 gm_discontinuity field. The gm_discontinuity field is initialized to the random value on stream creation. The 41 gm_discontinuity field of every subsequent AVBTP stream data frame shall contain the same value until a discontinuity 42 is indicated by 802.1AS. When the actual or possible discontinuity occurs, the talker then increments the 43 gm_discontinuity field by 1, after which all subsequent packets shall contain the new gm_discontinuity field. This 44 process then repeats for every subsequent indication of an actual or possible discontinuity as indicated by IEEE 802.1AS. 45 46 When a talker detects a discontinuity, either from an 802.1AS indication or simple observation, it is required to increment the gm_discontinuity field by 1. This indicates to the listener(s) of the stream that the AVBTP presentation times 47 contained in the avbtp_timestamp field may for a limited period of time not correspond to the 802.1AS wall clock and 48 the listener should enter holdover mode. 49 50 51 When a listener detects that the gm_discontinuity field has changed or detects a discontinuity, either from an 802.1AS 52 indication or simple observation, it should stop attempting to correlate AVBTP presentation time to 802.1AS wall clock 53 time for one Maximum Holdover time. It is possible that the gm_discontinuity field could be incremented multiple 54 times during one 802.1AS Grandmaster selection cycle. The listener should enter holdover mode, and begin timing the 55 56
Copyright © 2007-2008 IEEE. All rights reserved 39 This is an unapproved IEEE Standards Draft, subject to change Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks IEEE P1722/D1.1 2008-08-25
1 maximum holdover time, on the first indication of a discontinuity. If other indications of discontinuity are detected 2 before maximum holdover time has expired, these indications shall be ignored until maximum holdover time has expired. 3 4 The listener should exit holdover mode after either maximum holdover time has expired or if the listener is able through 5 observation to determine that the 802.1AS time and presentation time in the stream data are consistent with each other. 6 7 The value of the gm_discontinuity field is only meaningful to a single talker and its associated listener(s). 8 9 <
40 Copyright © 2007-2008 IEEE. All rights reserved This is an unapproved IEEE Standards Draft, subject to change IEEE P1722/D1.1 Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks 2008-08-25
1 2 5.6 Protocol layering and other required protocols 3 This section documents other required protocols and standards required not specified in this transport level specification. 4 5 All AVBTP end stations shall support IEEE 802.1BA Audio Video Bridging (AVB) Systems [R23] which includes 6 mandatory support of all the following protocols 7 8 All AVBTP end stations shall support IEEE 802.1AS Precision Timing Protocol (PTP)[R5]. 9 10 All AVBTP end stations shall support IEEE 802.1ak Multiple Registration Protocol (MRP) and 11 Multiple MAC Address Registration Protocol (MMRP) [R8] as amended by IEEE 802.1ak 12 Corrigendum 1 [R9]. Support for Multiple VLAN Registration Protocol (MVRP) is optional. 13 14 All AVBTP end stations shall support IEEE 802.1Qat Stream Reservation Protocol (SRP) [R6]. 15 16 17 All AVBTP end stations shall support IEEE 802.1Qav [R7] 18 19 <
Copyright © 2007-2008 IEEE. All rights reserved 41 This is an unapproved IEEE Standards Draft, subject to change Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks IEEE P1722/D1.1 2008-08-25
1 6. 61883/IIDC over AVBTP protocol 2 3 4 6.1 Overview 5 6 << Editor’snote: text below for Overview for now just excerpts from our assumptions document. I have not 7 changed everything to language “proper”for a standard. >> 8 9 <
42 Copyright © 2007-2008 IEEE. All rights reserved This is an unapproved IEEE Standards Draft, subject to change IEEE P1722/D1.1 Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks 2008-08-25
1 2 3 6.2 Common 61883/IIDC Stream data encapsulation 4 The 61883/IIDC stream data encapsulation is used for carrying IEC 61883 and IIDC stream data traffic over AVBTP 5 networks. 6 7 This encapsulation uses a cd field of zero(0) and a subtype field of zero(0). 8 9 This encapsulation also uses the protocol_specific_packet_header to contain 4 fields that are common for both IIDC 10 and IEC-61883 frames. These fields are modeled after IEEE 1394 and consist of the following: 11 12 a) First byte: 13 14 tag field: most significant 2 bits of this byte 15 channel field: least significant 6 bits of this byte 16 17 b) Second byte: 18 tcode field: most significant 4 bits of this byte 19 20 sy field: least significant 4 bits of this byte 21 22 These fields are shown in the figure below: 23 24 Figure 6.1 61883/IIDC common header fields 25 26 transmitted first 27 0 1 2 3 28 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 29 cd 30 subtype data 00 subtype (0) sv version r lp gv tv sd_reserved2 gm_discontinuity h (0) 31 802.1Qat 04 32 stream_id Stream ID 08 33 34 AVBTP Time 12 avbtp_timestamp 35 Gateway info 16 gateway_info 36 37 20 packet_data_length (bytes) tag channel tcode (A ) sy Packet info 16 38 24 39 2quadlet IEC 61883-1 CIP header (if tag equals 1) 40 41 Remainingadditional payload data and padding varies by tag value (0 or 1) and CIP header 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56
Copyright © 2007-2008 IEEE. All rights reserved 43 This is an unapproved IEEE Standards Draft, subject to change Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks IEEE P1722/D1.1 2008-08-25
1 2 3 6.2.1 tag field 4 5 The 2-bit tag field follows the same meaning format and rules as specified by IEEE 1394. Of the four possible 6 combinations for this field, the following values are supported or not supported as specified below. 7 8 Supported by AVBTP: 9 002: “data field unformatted”(used by Instrumentation & Industrial Digital Camera (IIDC) 1394 trade 10 association specification) 11 012: CIP header is present 12 13 Not supported by AVBTP: 14 102: Reserved by IEEE 1394.1 clock adjustment 15 112: Global asynchronous stream packet (GASP) format (Used in 1394 for Serial Bus to Serial Bus bridges) 16 17 18 6.2.2 channel field 19 20 The 6-bit channel field follows the same meaning format and rules as specified by IEEE 1394. Of the four possible 21 combinations for this field, the following values are supported as specified below. 22 0-30 & 32-63: originating channel ID from 1394 network via 1394/61883 to 1722/61883 gateway (as specified 23 in Annex B below). 24 25 31: originating source is on AVB network (native AVB) 26 27 28 6.2.3 tcode (type code) 29 30 The 4-bit tcode field follows the same meaning format and rules as specified by IEEE 1394. For AVBTP, the only value 31 supported shall be a fixed value of 10102 binary (A16 hexadecimal, same as 1394 isochronous packet format) with the 32 following rules for talkers and receivers. 33 AVBTP talkers shall always set this field to A16 hexadecimal on transmit 34 AVBTP receivers shall always ignore this field on receive 35 36 37 6.2.4 sy field 38 39 Use of the 4-bit sy field is application specific and therefore beyond the scope of this standard. Known industry standards 40 that currently use this field are: 41 IIDC [R16] (used for video start of frame indicator) 42 Digital Transmission Content Protection (DTCP) (www.dtcp.com) [B3] [B4] 43 44 45 46 47 48 49 50 51 52 53 54 55 56
44 Copyright © 2007-2008 IEEE. All rights reserved This is an unapproved IEEE Standards Draft, subject to change IEEE P1722/D1.1 Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks 2008-08-25
1 2 6.3 ”Data field unformatted”encapsulation (used by IIDC) 3
<< Editor’snote: This section and sub sections describe the variant where the tag field is set to 012 binary 4 indicating that a CIP header follows. For tag value of 002 binary, the remaining data is format specific to IIDC (or 5 other uses of “unformatted”??).>> 6 7 << Editor’snote, this section is still cut and paste from my PowerPoint based contribution and will be re-worked 8 to put in an appropriate standards language and format in a future version of this specification>> 9 10 11 Figure 6.2 - 61883/IIDC frame header fields 12 13 transmitted first 14 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 15 cd 16 subtype data subtype (0) sv version r lp gv tv sd_reserved2 gm_discontinuity h 00 (0) 17 18 802.1Qat 04 stream_id Stream ID 19 08 20 AVBTP Time 12 avbtp_timestamp 21 Gateway info 16 gateway_info 22 23 Packet info 20 packet_data_length (bytes) tag(0) channel* (0-15) tcode (A16) sy (0 or 1) 24 24 25 26 Video payload data (see 1394TAdocument 2003017) 27 28 transmitted last 29 30 31 *Note: Current standard for IIDC restricts channel ID to 0-15 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56
Copyright © 2007-2008 IEEE. All rights reserved 45 This is an unapproved IEEE Standards Draft, subject to change Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks IEEE P1722/D1.1 2008-08-25
1 2 3 4 6.4 IEC-61883 CIP encapsulation 5 <
46 Copyright © 2007-2008 IEEE. All rights reserved This is an unapproved IEEE Standards Draft, subject to change IEEE P1722/D1.1 Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks 2008-08-25
1 2 Figure 6.4— CIP header and data fields, tag=1, SPH = 1 3 transmitted first 4 0 1 2 3 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 6 cd 7 subtype data 00 subtype (0) sv version r lp gv tv sd_reserved2 gm_discontinuity h (0) 8 802.1Qat 04 9 stream_id Stream ID 08 10 11 AVBTP Time 12 avbtp_timestamp 12 Gateway info 16 gateway_info 13 14 Packet info 20 packet_data_length (bytes) tag(1) channel (0-63) tcode (A16) sy 15 CIP #1 SPH 24 0 0 SID (0-63) DBS (size in quadlets) FN QPC (1) Rsv DBC 16 17 CIP #2 28 1 0 FMT FDF 18 1st Src Packet hdr 32 avbtp_source_packet_header_timestamp 19 1st Src Packet 20 36 1st Source Packet Data + optional additional Source Packets and their timestamps (see IEC 61883-4 and 61883-7) 21 22 transmitted last 23 24 25 26 6.4.1 CIP header 1st quadlet indicator 27 The 2 bit CIP header 1st quadlet indicator field has the same definition as defined in IEC 61883-1. AVBTP shall only 28 support a fixed value of 002 set by talkers and ignored by listeners. 29 30 31 32 6.4.2 SID (source ID) field 33 The 6 bit SID field has the same definition as defined in IEC 61883-1. For AVBTP, it shall use the following values. 34 35 a) 0-62: originating Source ID from IEEE 1394 network (frame originated from a 1394/61883 to 1722/61883 36 interworking unit). 37 b) 63: originating source is on AVB network 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56
Copyright © 2007-2008 IEEE. All rights reserved 47 This is an unapproved IEEE Standards Draft, subject to change Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks IEEE P1722/D1.1 2008-08-25
1 2 3 6.4.3 Data Block Size (DBS) 4 5 The 8-bit DBS field has the same definition as currently in 61883-1, size of Data Blocks in Quadlets 6 0: 256 quadlets 7 1-255: 1-255 quadlets 8 9 10 11 6.4.4 QPC (quadlet Padding count) 12 The 3-bit QPC field has the same definition as currently defined in 61883-1. For all types of 61883 as defined today, this 13 field is always zero. 14 15 16 17 6.4.5 FN (fraction number) field 18 The 2-bit FN field has the same definition as currently defined in 61883-1. This is currently only used in 61883-4 and 19 61883-7 (where also the SPH field is always set to one(1)). 20 21 22 23 6.4.6 SPH (source packet header) field 24 The SPH bit has the same definition as currently defined in 61883-1. 25 26 If set to one(1): 27 Then application packet contains 61883-4 or 61883-7 (or future) source packets with source packet headers. 28 29 If set to zero(0) 30 31 Then application packet does not contain source packets (contains integer number of Data Blocks) 32 33 34 6.4.7 Rsv (reserved) field 35 36 The 2-bit has the same definition as currently defined in IEC 61883-1. It is reserved (currently not used by 1394/61883), 37 set to zero(0) on transmit, ignore on receive. 38 39 40 6.4.8 DBC (data block count) field 41 42 The 8 bit DBC field has the same definition as currently defined in IEC 61883-1. It contains the sequence number of the 43 1st data block in the packet. 44 45 For AVBTP, The DBC field shall not be set to a value that would cause the AVBTP frame length to exceed a maximum 46 payload size 802.3 of 1500 bytes per frame. This limits the total size of an AVBTP frame header plus payload of no 47 more than 375 quadlets (1500 bytes). All frames of this format shall contain an integral number of data blocks as defined 48 in IEC 61883-1. 49 50 <
48 Copyright © 2007-2008 IEEE. All rights reserved This is an unapproved IEEE Standards Draft, subject to change IEEE P1722/D1.1 Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks 2008-08-25
6.4.9 CIP header 2nd quadlet indicator 1 2 The 2 bit CIP header 2nd quadlet indicator field has the same definition as defined in IEC 61883-1. For AVBTP it shall be 3 fixed at 10 binary 2 4 5 6.4.10 FMT (stream format), field 6 7 The 6 bit FMT field has the same definition as currently defined in IEC 61883-1. 8 9 6.4.11 FDF (format dependent field) 10 11 The FDF field has the same definition as defined in IEC 61883-1. If the SPH field is set to 0, then this field is 8 bits in 12 length. If the SPH field is set to 1, then this field is 24 bits in length. 13 14 6.4.12 SYT (synchronization timing) field (1394 cycle time based presentation time for SPH field equals 15 0) 16 17 The 24 bit SYT field is only present if the SPH field is set to a value of zero(0). This IEC 61883-1 defined field is present 18 but not used by AVBTP end stations, it is only used by 1394/61883 to 1722/61883 interworking units (see Annex B 19 below). AVBTP talker end stations shall set this field if present to FFFFFF16 (the IEC 61883 no data timestamp value) on 20 transmit and AVBTP listener end stations shall ignore this field on receive. 21 22 23 6.4.13 avbtp_source_packet_header_timestamp field (802.1AS time based presentation time for SPH 24 field equals 1) 25 26 If the SPH field is set to a value of one(1), then the AVBTP stream data frame contains one or more CIP source packets. 27 Each CIP source packet contains a 32 bit timestamp as the first quadlet of the source packet followed by an integral 28 number of quadlets as defined by the standard that defines the source packet format. 29 30 Currently defined supported formats that are supported by AVBTP are IEC 61883-4 and 61883-7. 31 32 IEC 61883-4 and 61883-7 as written define the source packet header quadlet to contain the presentation time of the 33 packet based on IEEE 1394 cycle time. 34 35 AVBTP uses the same formats as defined in IEC 61883-4 and 61883-7, but it uses an IEEE 802.1AS based presentation 36 time in the same format as defined for the avbtp_timestamp field which consist of presentation time as expressed as the 37 least significant 32 bits of 802.1AS time for the source packet header quadlet of each and every TS packet. For these 38 AVBTP frames the talker shall set the tv (Timestamp Valid) bit to zero(0) for all frames (i.e. the Source packet header is 39 used instead of the avbtp_timestamp field for these frames). 40 41 <
Copyright © 2007-2008 IEEE. All rights reserved 49 This is an unapproved IEEE Standards Draft, subject to change Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks IEEE P1722/D1.1 2008-08-25
1 2 3 6.5 61883 over AVBTP control frame format 4 5 Use of AVBTP frames with a subtype of zero(0) and a cd bit of one(1) is reserved for possible future versions of this 6 specification. 7 8 9 10 6.6 Use of AV/C higher layer protocol in 61883 over AVBTP end stations 11 For 61883 applications that require the use of AV/C protocol[R18] on AVBTP networks, those applications shall use the 12 AV/C over UDP/IP as specified by the 1394 Trade Association.[R19] 13 14 15 16 6.7 Session management 17 18 This section defines the minimum set of protocols that shall be used for session management of AVBTP streams. 19 Additional protocols may be used by AVBTP devices (such as Zeroconf) but how such protocols are used is outside of 20 the scope of this specification. 21 22 23 6.7.1 Overview 24 25 The 61883 over AVBTP session management protocols and procedures: 26 Shall use SRP (802.1Qat)[R6] 27 AV/C based applications shall use AV/C over UDP/IP as specified in 1394 Trade Association TA Document 28 2006021 Networking IEEE 1394 Clusters via UWB over Coaxial Cable - Part 3: FCP and CMP over IPv4 29 <
50 Copyright © 2007-2008 IEEE. All rights reserved This is an unapproved IEEE Standards Draft, subject to change IEEE P1722/D1.1 Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks 2008-08-25
1 2 6.8 Timing and Synchronization 3 4 5 6.8.1 General 6 7 Timing and synchronization for IEC 61883 over AVBTP is generally accomplished in the same manner as specified in 8 61883-1 through 61883-8 over IEEE 1394 for processing of presentation time. The main difference between running 9 61883 protocols over AVBTP versus IEEE 1394 is the use of 802.1AS based time expressed in 32 bits of nanoseconds 10 versus the use of 1394 time expressed in seconds, cycles and 24.576 MHz cycle offset values. 11 12 Usage of the timing and synchronization information included in the CIP header or Source Packet Header is generally 13 consistent with the definition in the 61883 series of standards where the main differences are: 14 15 The SYT field or Source Packet Header that are currently defined in the 61883 series of standards 16 as formatted in seconds, cycle and cycle offset is replaced by the avbtp_timestamp field or Source 17 Packet Header expressed in 802.1AS based nanoseconds.. 18 For protocols of 61883-4 and 61883-7 where the SPH field is set to one(1), then the 32 bit source 19 packet header field for each source packet contains the associated presentation time of the source 20 packet expressed in IEEE 802.1AS based nanoseconds instead of IEEE 1394 based seconds, cycle 21 and cycle offsets. 22 In the IEC 61883 series of specification the term “receiver”is used, whereas in this specification 23 the term “listener”is used. 24 25 In the IEC 61883 series of specification the term “transmitter”is used, whereas in this specification 26 the term “talker”is used. 27 IEEE 1394 on networks faster than 100 megabits per second allows CIP packets larger than can fit 28 in a standard single IEEE 802.3 Ethernet frame. This standard does not, if an application needs to 29 send more than data than can fit in a single Ethernet frame, it shall generate multiple correctly 30 formatted CIP packets each one that can fit in an 802.3 Ethernet frame. 31 32 <
Copyright © 2007-2008 IEEE. All rights reserved 51 This is an unapproved IEEE Standards Draft, subject to change Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks IEEE P1722/D1.1 2008-08-25
1 6.8.2 61883-2 timing and synchronization 2 61883-2 formatted frames shall follow the same timing and synchronization rules as defined in IEC 61883-2 section 6, 3 but using IEEE 802.1AS time in the avbtp_timestamp frame field instead of IEEE 1394 based cycle time in the SYT 4 field. AVBTP talkers shall set the CIP header SYT field to all ones for all transmitted CIP packets and AVBTP listeners 5 shall ignore the SYT field. 6 7 The talker shall transmit a valid time stamp value in the AVBTP timestamp field once every video frame 8 period. The time stamp shall be transmitted in an AVBTP frame that meets the following conditions: 9 10 - packet_arrival_time_L ≤ time stamp value 11 12 - time stamp value –transmission_delay_limit ≤packet_arrival_time_F 13 14 where: 15 16 packet_arrival_time_F is the IEEE 802.1AS time when the first bit of the packet which has the time 17 stamp has arrived at the listener; 18 19 packet_arrival_time_L is the IEEE 802.1AS time when the last bit of the packet which has the time 20 stamp has arrived at the listener; 21 22 transmission_delay_limit = default value of 2,000,000 nanoseconds (2 milliseconds). 23 24 In case of Hx (H = 1,2,4) transmission, KH data blocks are transmitted in a video frame period M using K isochronous 25 packets. Isochronous packet n contains H data blocks of nH, nH+1, ... and (n+1)H–1. 26 27 The isochronous packet n of a video frame period M shall be transmitted on the following conditions (n = 0, ... ,K–1): 28 29 - packet_arrival_time_L ≤ nominal timing for isochronous packet n 30 31 - nominal timing for isochronous packet n –transmission_delay_limit ≤ packet_arrival_time_F 32 33 where 34 35 packet_arrival_time_F is the cycle time when the first bit of the isochronous packet n has 36 arrived at the receiver; 37 38 packet_arrival_time_L is the cycle time when the last bit of the isochronous packet n has 39 arrived at the receiver; 40 41 K is the number of isochronous packets without empty packets in a video frame period. 42 K = 250 (525-60 system) 43 K = 300 (625-50 system) 44 45 Nominal timing for isochronous packet n = T + (T +1–T ) x n/K 46 M M M 47 T is the time stamp for video frame period M transmitted in the AVBTP timestamp field. 48 M 49 50 51 6.8.3 61883-4 timing and synchronization 52 53 The timing and synchronization of 61883-4 over AVBTP uses the same method as used in 61883-4 over IEEE 1394 54 networks in that the source packet header quadlet always contains a valid timestamp. In 61883-4 over AVBTP, this 55 quadlet contains nanosecond 802.1AS based time instead of IEEE 1394 seconds, cycle and cycle offset time. 56
52 Copyright © 2007-2008 IEEE. All rights reserved This is an unapproved IEEE Standards Draft, subject to change IEEE P1722/D1.1 Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks 2008-08-25
For 61883-4 formatted frames over AVBTP, section 4.3 of 61883-4 is replaced with the following: 1 2 The time stamp in the source packet header is used by listeners for reconstructing a correct timing of the TSPs at their 3 output. The time stamp indicates the intended delivery time of the first bit/byte of the TSP from the listener output to the 4 transport stream target decoder. The time stamp represents the 32 least significant bits of the IEEE 802.1AS at the talker 5 at the moment the first bit/byte of the TSP arrives from the application, plus some offset. The offset is equal to the overall 6 delay of the TSP between the moment of arriving (of the first bit) and the moment the TSP (first bit) is delivered by the 7 receiver to the application. The default value of this offset is equal to 2,000,000 nanoseconds (2 milliseconds). 8 9 10 6.8.4 61883-6 timing and synchronization 11 12 Replace Section 7.2 of 61883-6 with: 13 14 In the case where a CIP packet contains multiple data blocks, it is necessary to specify which data block of the 15 CIP corresponds to the IEEE 802.1AS based AVBTP time stamp. 16 17 The talker prepares the time stamp for the data block which meets this condition: 18 19 mod(data block count, SYT_INTERVAL) = 0 (1) 20 21 <
Copyright © 2007-2008 IEEE. All rights reserved 53 This is an unapproved IEEE Standards Draft, subject to change Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks IEEE P1722/D1.1 2008-08-25
1 2 A data block contains all data arriving at the talker within an audio sample period. The data block contains all 3 the data which make up an “event”. 4 5 The talker shall specify the presentation time of the event at the receiver. A receiver for shall have the capability 6 of presenting events at the time specified by the transmitter. 7 8 If a function block receives a CIP, processes it and subsequently re-transmits it, the AVBTP timestamp of 9 the outgoing CIP shall be the sum of the incoming AVBTP timestamp and the processing delay. 10 11 The transmitter shall add TRANSFER_DELAY to the quantized timing of an event to construct the AVBTP 12 timestamp. The TRANSER_DELAY value is initialized with the DEFAULT_TRANSFER_DELAY value. Note 13 that for all talkers, the TRANSFER_DELAY may be changed to achieve a shorter TRANSFER_DELAY value 14 to allow for a shorter time if the end to end delay in the AVB network can allow it. 15 16 The DEFAULT_TRANSFER_DELAY value is 2,000,000 nanoseconds (2 milliseconds) 17 18 19 20 6.8.5 61883-7 timing and synchronization 21 Replace IEC 61883-7 section 5.1.3 with: 22 23 The source packet header field is a one quadlet field (4 bytes) that represent an 802.1AS based time stamp. 24 25 The time stamp is used by 61883-7 capable AVBTP listeners for reconstructing a correct timing of the transport 26 stream packets at their output. The time stamp indicates the intended delivery time of the first bit/byte of the 27 transport stream packets from the receiver output to the T-STD (Transport Stream Target Decoder). The time 28 stamp represents the least significant 32 bit binary time of the IEEE 802.1AS based clock at the moment the first 29 bit/byte of the transport stream packet arrives from the application, plus an offset which is equal to the overall 30 delay of the transport stream packet between the moment of arriving (of the first bit) and the moment the 31 transport stream packet (first bit) is delivered by the receiver to the application. 32 33 The default value of this offset shall be 2,000,000 nanoseconds (2 milliseconds). 34 35 36 37 6.8.6 61883-8 timing and synchronization 38 <
54 Copyright © 2007-2008 IEEE. All rights reserved This is an unapproved IEEE Standards Draft, subject to change IEEE P1722/D1.1 Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks 2008-08-25
Change: 1 2 For a stream that conforms to this specification each IEEE-1394 isochronous packet consists of the CIP 3 header followed by zero or more source packets. 4 5 To: 6 7 For a stream that conforms to this specification each AVBTP frame consists of an AVBTP frame 8 header, followed by the CIP header followed by zero or more source packets. 9 10 For IEC 61883-8 section 5.4.2.5 Compression Mode 016 Video Data Packetization 11 12 Change: 13 14 An IEEE-1394 isochronous channel that is used to transmit data according to this specification shall 15 only transmit a single stream of video per 1394 isochronous channel. 16 To: 17 18 An AVBTP Stream (identified by a unique 64 bit stream ID) that is used to transmit data according to 19 this specification shall only transmit a single stream of video per that stream. 20 21 22 For IEC section 5.4.4 Type 216 Source Packet –Audio Source Packet 23 24 Change: 25 26 The specification of the transportation of audio data within the same 1394 stream as video data is a 27 likely update to this specification. Until such time as this has been specified it is recommended that 28 audio data be transmitted as a separate 1394 stream as described by IEC 61883-6, [<
Copyright © 2007-2008 IEEE. All rights reserved 55 This is an unapproved IEEE Standards Draft, subject to change Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks IEEE P1722/D1.1 2008-08-25
1 2. The condition of “anon-empty packet is ready to be transmitted”can also be defined as true when a fixed 2 number of data blocks have arrived. This transmission method is called Blocking Transmission, and is 3 described in section 5.5.1.3. of IEC 61883-8. 4 5 Since a there is no source packet header (SPH) there is only one time stamp and this is in the avbtp_timestamp field 6 of the ABTP frame header. If a CIP contains multiple Video Data source packets, it is necessary to specify which 7 source packet corresponds to the time stamp. Since the stream contains a SIM Source Packet at the frequency of 8 once per frame a mechanism is required to ensure that the AVBTP time stamp is generated at a regular interval of 9 Video Data Source Packets. The VDSPC (Video Data Source Packet Count) field in Video Data Source Packet is 10 used for this purpose. The transmitter prepares the time stamp for the Video Data Source Packet, which meets this 11 condition: 12 mod(VDSPC, SYT_INTERVAL) = 0 13 where: 14 15 VDSPC is the running count of transmitted video data source packets; 16 17 SYT_INTERVAL denotes the number of video data source packets between two successive valid SYT 18 timestamps, which includes one of the video data source packets with a valid SYT. For example, if there are 19 three video data source packets between two valid AVBTP timestamps, then the SYT_INTERVAL would 20 be 4. The SYT_INTERVAL is dependent upon the video mode and color space used. The values of 21 SYT_INTERVAL are given in Table 1 of 61883-8. 22 23 The receiver knows the video data source packet for which the SYT timestamp is valid since it is the source packet 24 whose VDSPC solve the following equation: 25 26 mod(VDSPC, SYT_INTERVAL) = 0 27 28 The receiver is responsible for estimating the timing of data blocks between valid time stamps. The method of timing 29 estimation is implementation-dependent. 30 31 The SYT timestamp specifies the presentation time of the video data source packet at the receiver. A receiver shall 32 have the capability of presenting events at the time specified by the transmitter. 33 34 The default TRANSFER_DELAY value is 2,500,000 nanoseconds (2.5 milliseconds), which accommodates the 35 IEEE 802.1BA required maximum latency time of 2 milliseconds for a 7 hop 100 MBPS Ethernet AVB network, 36 worst case packetization delay and provides scope for encryption/decryption that may be required. The derivation of 37 the TRANSFER_DELAY value is given in Annex G of IEC 61883-8 and where for this specification, the IEEE 1394 38 transmission worst case transmission delay is replaced with 2 milliseconds of delay for a 7 hop 100 MBPS Ethernet 39 AVB network. 40 The transmitter quantizes the timing of the "synchronization clock", for instance the rising edge of the video 41 clock, by referring to its own 802.1AS based time. It transmits the sum of this time and TRANSFER_DELAY in 42 the avbtp_timestamp field of the AVBTP header. If the timing information is not required for a CIP the 43 AVBTP timestamp valid (tv) field shall be set to zero(0). 44 45 46 47 48 49 50 51 52 53 54 55 56
56 Copyright © 2007-2008 IEEE. All rights reserved This is an unapproved IEEE Standards Draft, subject to change IEEE P1722/D1.1 Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks 2008-08-25
1 For IEC 61883-8, Replace 5.5.1.2 Non-Blocking transmission method with: 2 3 The transmitter shall construct one or more AVBTP stream data frames in every 802.1Qav measurement cycle. 4 Each frame shall comply with the format as specified in <
Copyright © 2007-2008 IEEE. All rights reserved 57 This is an unapproved IEEE Standards Draft, subject to change Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks IEEE P1722/D1.1 2008-08-25
1 2 For 61883-8, Replace ANNEX B: with: 3 4 Logical association of audio and video streams 5 6 For applications that are running AV/C, there is sufficient capability in the AV/C specifications, [<
58 Copyright © 2007-2008 IEEE. All rights reserved This is an unapproved IEEE Standards Draft, subject to change IEEE P1722/D1.1 Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks 2008-08-25
7. Proprietary/Experimental subtype AVBTP protocol 1 2 <
Copyright © 2007-2008 IEEE. All rights reserved 59 This is an unapproved IEEE Standards Draft, subject to change Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks IEEE P1722/D1.1 2008-08-25
1 2 3 7.3 Proprietary/Experimental subtype control format 4
5 For subtype 7F16 AVBTP control frames the subtype_data1 field is called the escape_type field and has the following 6 values: 7 a) A value of zero (0) in the subtype_data field is required for use by proprietary/experimental as this field 8 9 b) Values of 1 through 255 are reserved for future use by this standard. 10 11 12 Figure 7.2— Proprietary/Experimental control escape subtype format 13 14 15 transmitted first 0 1 2 3 16 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 17 cd subtype data escape_type (0) 18 00 (1) subtype(7F16) sv version status control_frame_length(bytes) 19 802.1Qat 04 stream_id 20 Stream ID 21 08 22 12 23 EUI-64 EUI-64 16 24 25 20 26 27 Remaining additional header, payload data and padding varies by EUI-64 and is not specified by 28 AVBTP. 29 30 As necessary, 1-3 byte padding to fill last quadlet 31 32 transmitted last 33 34 If the subtype is 7F16 and the subtype_data field is 0, then following the subtype_data field shall be a unique EUI-64 field 35 that identifies the proprietary/experimental protocol. 36 37 All data after the EUI-64 is available for use by the proprietary/experimental protocol and is beyond the scope of this 38 specification. 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56
60 Copyright © 2007-2008 IEEE. All rights reserved This is an unapproved IEEE Standards Draft, subject to change IEEE P1722/D1.1 Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks 2008-08-25
1 Annexes 2 3 Annex A (informative) Bibliography 4 5 6 [B1] IEEE 100, The Authoritative Dictionary of IEEE Standards Terms, Seventh Edition. 7 8 [B2] IEEE EUI-64, IEEE EUI-48, and IEEE MAC-48 assigned numbers may be obtained from the IEEE 9 Registration Authority, http://standards.ieee.org/regauth/. Tutorials on these assigned numbers may be 10 found on this web site. 11 12 [B3] Digital Transmission Content Protection Specification Volume 1 (Informational Version) 13 14 [B4] DTCP Volume 1 Supplement D DTCP use of IEEE1394 Similar Transports (Informational Version) 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 55 56
Copyright © 2007-2008 IEEE. All rights reserved 61 This is an unapproved IEEE Standards Draft, subject to change Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks IEEE P1722/D1.1 2008-08-25
1 THIS PAGE LEFT INTENTIONALLY BLANK 2 <
62 Copyright © 2007-2008 IEEE. All rights reserved This is an unapproved IEEE Standards Draft, subject to change IEEE P1722/D1.1 Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks 2008-08-25
Annex B (normative) Interworking 61883 between 1 AVBTP and IEEE 1394 networks 2 3 4 5 B.1 Introduction 6 This annex defines the methods and protocols for operation of interworking units (IWUs) used to interconnect 61883 7 compliant devices between IEEE 1394 and IEEE 802.3 or IEEE 802.11 AVBTP networks 8 9 10 11 B.2 1394 to/from IEEE 802 AVBTP Interworking scenarios 12 There are three scenarios defined for interworking by this annex. They are called scenarios A, B and C. 13 14 Scenario A is the case where you have a stream originated by a 1394 device using and AVB network to connect with 15 listeners on another 1394 bridged network: 16 17 1394 Talker -> 1394 Net- IWU1 -> AVB Net -> IWU2 -> 1394 Net -> 1394 Listener(s) 18 19 Scenario B adds AVBTP listeners to Scenario A so that listeners on both IEEE 802 networks and IEEE 1394 networks 20 can communicate as follows: 21 22 1394 Talker -> 1394 Net1- IWU1 -> AVB Net -> IWU2 -> 1394 Net2 -> 1394 Listener(s) 23 | 24 V AVBTP Listener(s) 25 26 Scenario C is where the talker is on an AVB network and needs to interoperate with both AVBTP and 1394 based 27 listeners: 28 29 AVBTP Talker -> AVB Net -> IWU2 -> 1394 net2 -> 1394 Listener(s) 30 | 31 V 32 AVBTP Listener(s) 33 The goal of this protocol is to ensure that all of the above scenarios work such that simpler applications of bridging 34 61883/1394 capable devices over an AVB network using scenario A and also more complex applications of full 35 connectivity of 61883 capable talkers and listeners can communicate via gateways regardless of the underlying network 36 topology. 37 38 To support these cases, AVBTP Interworking Units shall handle: 39 - Conversion and adaptation of timing and synchronization between those required by 1394/61883 and 40 1722/61883. 41 - Proper queuing and scheduling of CIP packets on each of the networks based on the requirements of those 42 networks. 43 - Fragmentation and reassembly of CIP packets between the two networks. 44 45 o This is especially important as 802.3 networks support a maximum of 1500 byte payload frames whereas on high speed 1394 networks, the isochronous packets may be much larger than can be support 46 on the Ethernet LAN. 47 48 <
Copyright © 2007-2008 IEEE. All rights reserved 63 This is an unapproved IEEE Standards Draft, subject to change Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks IEEE P1722/D1.1 2008-08-25
1 B.2.1 Encapsulation 2 3 IEEE 1394 to AVBTP interworking units shall use the same format of the AVBTP IIDC/61883 as specified in clause 6 4 above. 5 6 IIDC/61883 stream data frames shall use the gateway_info field as specified in 5.4.10 above. This section defines how 7 that field is formatted for IEEE 1394 to AVBTP interworking units. 8 9 For IEEE 1394 to AVBTP interworking units the gateway_info is formatted into the following fields: 10 11 12 a) source_seconds: most significant 7 bits of the quadlet 13 b) source_cycle: 13 bits with a value range of 0-7999 decimal indicating the source 1394 bus cycle of the frame 14 15 c) source_cycle_offset: 12 bits with a value range of 0-3071 indicating the source 1394 bus cycle offset of the 16 frame 17 18 transmitted first 19 0 1 2 3 20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 cd 21 subtype data sd_reserved1 00 (0) subtype (0) sv lp gv tv sd_reserved2 gm_discontinuity h 22 802.1Qat 04 23 stream_id 24 Stream ID 08 25 AVBTP Time 12 avbtp_timestamp 26 27 Gateway info 16 source_seconds source_cycle (0-7999) source_cycle_offset (0-3071)
28 Packet info 20 packet_data_length (0 or 2) tag channel tcode (A16) sy 29 24 30 2quadlet IEC 61883-1 CIP header (if tag equals 1) 31 32 Remainingadditional payload data and padding varies by tag value (0 or 1) and CIP header 33 34 35 36 transmitted last 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56
64 Copyright © 2007-2008 IEEE. All rights reserved This is an unapproved IEEE Standards Draft, subject to change IEEE P1722/D1.1 Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks 2008-08-25
1 2 3 B.2.2 Stream Sequencing, Fragmentation and Reassembly procedures 4 5 CIP packets on a 1394 network may be larger than can be accommodated on the AVBTP network which has a maximum 6 AVBTP frame size (header plus payload) of 375 quadlets (1500 bytes). 7 8 If a 1394 to Ethernet AVBTP gateway receives a CIP packet that will not fit on the AVBTP network, then the gateway 9 shall break up the large CIP packet into multiple smaller CIP packets prior to sending on the AVBTP network. 10 11 If an Ethernet AVBTP to IEEE 1394 gateway receives multiple packets for a given cycle and that 1394 network can 12 support large CIP packets, the 1394 gateway shall reassemble the smaller AVBTP based CIP packets into larger IEEE 13 1394 based CIP packets as necessary. 14 15 16 17 B.3 Timing and synchronization 18 19 <
Copyright © 2007-2008 IEEE. All rights reserved 65 This is an unapproved IEEE Standards Draft, subject to change Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks IEEE P1722/D1.1 2008-08-25
1 THIS PAGE LEFT INTENTIONALLY BLANK 2 <
66 Copyright © 2007-2008 IEEE. All rights reserved This is an unapproved IEEE Standards Draft, subject to change IEEE P1722/D1.1 Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks 2008-08-25
Annex C (normative) MAC Address Acquisition Protocol 1 (MAAP) 2 3 4 5 C.1 Overview 6 7 Multicast MAC addresses will be required by AVBTP for the transmission of media stream from one talker to multiple 8 listeners. As AVBTP runs directly on a layer 2 transport, there is no existing protocol to dynamically allocate multicast 9 MAC addresses for AVBTP. 10 11 A reserved block of Multicast MAC addresses has been reserved for the use of AVBTP these are from xx-xx-xx-xx-xx-xx 12 through yy-yy-yy-yy-yy-yy. <
Copyright © 2007-2008 IEEE. All rights reserved 67 This is an unapproved IEEE Standards Draft, subject to change Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks IEEE P1722/D1.1 2008-08-25
1 Figure C.1 –802.3 MAAP frame format 2 3 transmitted first 4 0 1 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 -18 00 Note: Asendingdevicemaysend 7 8 -16 DA (destination MAC address) 02 MAAPframesin an untagged formatbut it is recommended 9 -14 04 802.3 MAC 10 thatMAAPframesbe 802.1Q header -12 06 11 taggedwithPCPvalue set to 6. 12 -10 SA (source MAC address) 08 13 -08 10 14 15 802.1Q Tag -06 TPID (802.1P/Q = 810016) 12 16 CFI field* -04 PCP(6) VID (VLAN Identifier 0) 14 17 (0) 18 Ethertype -02 etype (MAAP = TBD value) 16 19 00 18 20 MAAP control frame data 21 22 Optional padding (to ensure minimum size 23 802.3 frame size) 24 25 42-1500 ethernet_crc 60-1518 26 27 28 transmitted last 29 30 The MAAP control frame data consists of the following fields in the following order: 31 32 a) version_and_flags: field: 8 bit byte with the following subfields defined: 33 34 ver (version) most significant 4 bits of this byte 35 flags: least significant 4 bits of this byte 36 37 b) message_type: 1 byte 38 c) requestor_address: 6 bytes 39 40 d) requested_start_address: 6 bytes 41 e) requested_count: 2 bytes 42 43 f) start_address: 6 bytes 44 g) count: 2 bytes 45 46 h) renew_timeout: 2 bytes 47 48 A diagram of the MAAP frame format is shown in the following figure 49 50 51 52 53 54 55 56
68 Copyright © 2007-2008 IEEE. All rights reserved This is an unapproved IEEE Standards Draft, subject to change IEEE P1722/D1.1 Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks 2008-08-25
Figure C.2 –802.3 MAAP frame format 1 2 transmitted first 3 0 1 4 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 5 00 ver flags message_type 6 7 02 8 04 requestor_address 9 06 10 11 08 12 10 requested_start_address 13 14 12 15 14 requested_count 16 16 17 18 18 start_address 19 20 20 21 22 count 22 24 renew_timeout (assign message only) 23 transmitted last 24 25 26 . The frame type is identified in the message_type field as follows: 27 28 Table C.1— MAC address Acquisition protocol message types 29 30 Value FUNCTION Meaning 31 (decimal) 32 0 -- Reserved 33 1 MAAP_PROBE Probe MAC address(es) frame 34 2 MAAP_DEFEND Defend address(es) response frame 35 3 MAAP_ANNOUNCE Announce MAC address(es) acquired frame 36 4 MAAP_RELEASE Release MAC acquired address(es) 37 5 MAAP_ASSIGN Assign MAC address(es) command 38 6 MAAP_UNASSIGN Unassign MAC address(es) command 39 40 All MAAP frames are sent with a multicast destination MAC address set to the reserved MAAP protocol Multicast 41 address of zz-zz-zz-zz-zz-zz. <
Copyright © 2007-2008 IEEE. All rights reserved 69 This is an unapproved IEEE Standards Draft, subject to change Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks IEEE P1722/D1.1 2008-08-25
1 2 The main Ethertype field shall be the MAAP reserved Ethertype of nn-nn16.<
70 Copyright © 2007-2008 IEEE. All rights reserved This is an unapproved IEEE Standards Draft, subject to change IEEE P1722/D1.1 Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks 2008-08-25
- If the maap_probe_counter is equal to zero, then the MAAP entity will inform the application that the Address 1 range has been acquired and the MAAP entity will start the announce process. 2 - If the maap_probe_counter is greater than zero, then the MAAP entity will retransmit the current address range, 3 decrement the maap_probe_counter by one and restart the maap_probe_timer to a new random value selected 4 from uniformly in the range between MAAP_PROBE_INTERVAL_BASE to 5 MAAP_PROBE_INTERVAL_BASE plus MAAP_PROBE_INTERVAL_VARIATION milliseconds, 6 7 8 9 C.4 Announcing an acquired MAC Address Range 10 Once an address range is acquired, the local MAAP entity shall announce to the network by sending announce messages 11 to the network. It does this by: 12 13 – Setting the maap_announce_counter to MAAP_ANNOUNCE_RETRANSMITS. 14 – Formatting a new announce frame with: 15 • requestor_start_address field set to Unicast MAC address associated with the MAAP entity 16 • requested_start_address field set to the start of the address range acquired 17 • requested_count field set to the number of addresses acquired 18 • start_address field set to the start of the address range acquired 19 • count field set to the number of addresses acquired 20 – Sending the frame to the network 21 – Decrementing the maap_announce_counter by 1 22 – Starting the maap_probe_timer setting it to a random value selected uniformly in the range between 23 MAAP_ANNOUNCE_INTERVAL_BASE to MAAP_ANNOUNCE_INTERVAL_BASE plus 24 MAAP_ANNOUNCE_INTERVAL_VARIATION milliseconds, 25 26 <
Copyright © 2007-2008 IEEE. All rights reserved 71 This is an unapproved IEEE Standards Draft, subject to change Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks IEEE P1722/D1.1 2008-08-25
1 2 THIS PAGE LEFT INTENTIONALLY BLANK 3 <
72 Copyright © 2007-2008 IEEE. All rights reserved This is an unapproved IEEE Standards Draft, subject to change IEEE P1722/D1.1 Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks 2008-08-25
Annex D (informative)802.3 Media specific 1 encapsulation 2 3 4 5 D.1 Introduction 6 7 <
Copyright © 2007-2008 IEEE. All rights reserved 73 This is an unapproved IEEE Standards Draft, subject to change Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks IEEE P1722/D1.1 2008-08-25
1 2 3 Figure D.3 shows an AVBTP frame encapsulated within an 802.3 frame with an 802.1Q header (also known as an 4 802.1Q VLAN Tag field). For 802.3 frames, this format is required for all AVBTP stream data frames and optional for 5 AVBTP control frames. 6 7 Figure D.3 - AVBTP control or stream data frame within an 802.3 frame with 802.1Q tag field 8 9 10 transmitted first 11 12 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 13 14 -18 00 AVBTP data stream frames must 15 -16 DA (destination MAC address) 02 always use this format. AVBTP 16 controlframesmay usethis -14 04 17 802.3 MAC formaton transmit. All AVBTP 18 header -12 06 devicesmustbe ableto receive 19 data or control frames in this -10 SA (source MAC address) 08 20 format. 21 -08 10 22 23 802.1Q Tag -06 TPID (802.1P/Q = 810016) 12 24 field* -04 PCP CFI VID (VLAN Identifier) 14 25 Ethertype 26 -02 etype (AVBTP = TBD value) 16 27 00 AVBTP data stream or control frame 18 28 (integral number of quadlets, 29 maximum 375 quadlets (1500 bytes)) 30 Optional padding (to ensure minimum size 31 802.3 frame size) 32 33 42-1500 ethernet_crc 60-1518 34 35 36 transmitted last 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56
74 Copyright © 2007-2008 IEEE. All rights reserved This is an unapproved IEEE Standards Draft, subject to change IEEE P1722/D1.1 Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks 2008-08-25
1 2 3 Figure D.4 shows an AVBTP frame encapsulated within an 802.3 frame without an 802.1Q header. This format is 4 optional for AVBTP control frames. This format is not allowed for AVBTP stream data frames as all stream data frames 5 shall be priority encoded for class A or class B traffic thus making the VLAN tag header mandatory. 6 Figure D.4 - AVBTP control frame within an 802.3 frame without an 802.1Q Tag field 7 8 9 10 transmitted first 11 0 1 12 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 13 -14 00 OnlyAVBTP controlframes may 14 -12 DA (destination MAC address) 02 use this format, stream data 15 frames shallalways have an 16 04 802.3 MAC -10 802.1Q tag field 17 header -08 06 18 19 -06 SA (source MAC address) 08 20 -04 10 21 22 Ethertype -02 etype (AVBTP = TBD value) 12 23 00 AVBTP control frame 14 24 (integral number of quadlets, 25 maximum 375 quadlets (1500 bytes)) 26 Optional padding (to ensure minimum size 27 802.3 frame size) 28 29 46-1500 ethernet_crc 60-1514 30 31 32 transmitted last 33 34 35 D.2 802.3 Fields 36 37 38 D.2.1 802.3 Destination MAC address field 39 40 For AVBTP stream data frames, MAC Destination Addresses shall be unique for the Layer 2 network and may either be 41 unicast or multicast addresses. IEEE 802.1Qat Stream Reservation Protocol (SRP) shall be used to manage the 42 destination MAC address and AVBTP stream ID of all stream data frames. Optionally, MAC Address Acquisition 43 Protocol (MAAP) may be used in conjunction with 802.1Qat in order to guarantee that the MAC address does not conflict 44 with another MAC address already in use by another AVBTP end station. 45 46 For AVBTP stream control frames, MAC Destination Address may be unicast, multicast or broadcast depending on the 47 specification of the usage of each AVBTP control frame. 48 49 D.2.2 802.3 Source MAC address field 50 51 For AVBTP stream data frames, MAC Source Addresses shall indicate the senders MAC address of the stream data or 52 control traffic. Per IEEE 802.3 rules, this address shall always be a unicast MAC address. 53 54 55 56
Copyright © 2007-2008 IEEE. All rights reserved 75 This is an unapproved IEEE Standards Draft, subject to change Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks IEEE P1722/D1.1 2008-08-25
1 D.2.3 802.1Q header field 2 Depending on the subtype of the AVBTP frame, the 802.1Q header may or not be required based on the following rules: 3 4 5 a) All talkers shall send AVBTP stream data frames with an 802.1Q header present. This is due to the fact that the 6 PCP field is required to indicate whether the stream is a Class A or Class B stream. 7 b) Talkers and controllers may send stream control frames with an 802.1Q header. 8 9 c) All AVBTP compliant devices (talkers, listeners and controllers) shall be able to receive and process AVBTP 10 stream data and control frames with an 802.1Q header present. 11 12 Additional rules for handling of 802.1Q headers may be listed in subsequent sections for current or future protocols that 13 use AVBTP in current or future versions of this standard, but they shall not violate the above general rules, nor shall they 14 violate any rules as established in standard IEEE 802.1Q. 15 16 The following rules shall apply for fields in the 802.1Q header if it is present: 17 18 19 D.2.3.1 802.1Q tagged protocol identifier (TPID) field
20 All frames with an 802.1Q header field shall set the TPID field to a value of 810016 hexadecimal as required by IEEE 21 802.1Q. 22 23 24 25 D.2.3.2 VLAN identifier (VID) field 26 The VLAN identifier field is used to indicate the 802.1Q VLAN that an AVBTP frame is to be processed on. 27 28 All AVBTP stations shall be able to support a VID field value of zero to send or receive AVBTP frames. 29 30 AVBTP stations are recommended to support other VLAN identifiers, but it is not required. 31 32 AVBTP stations not supporting VLANs shall still be able to process a received AVBTP frame with 802.1Q header. 33 34 If VLAN identification and knowledge is supported by an AVBTP station, it shall discard any received AVBTP frames 35 with a VLAN ID for which it is not a member of the specified VLAN. 36 37 38 39 D.2.3.3 Canonical Format Indicator (CFI) field 40 As of the time of the writing of this spec, IEEE 802.3 requires this bit to be zero(0). 41 42 43 D.2.3.4 Priority Code Point (PCP) field 44 For all stream data frames, AVBTP talkers shall set the PCP value to the 802.1Qav specified default or management 45 specified values for either stream class A traffic or stream class B traffic. 46 47 NOTE –802.1 bridges may change the value of the PCP field as it traverses the network. 48 49 AVBTP control traffic shall use the value as specified by the associated protocol specific value (e.g. 61883 over 50 AVBTP), but never shall use a value of assigned for class A or class B traffic. 51 52 53 54 55 56
76 Copyright © 2007-2008 IEEE. All rights reserved This is an unapproved IEEE Standards Draft, subject to change IEEE P1722/D1.1 Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks 2008-08-25
D.2.3.5 AVBTP Ethertype, 16 bits: 1 2 All AVBTP frames shall use an Ethertype value of XXXX . 16 3 4 << Editor’snote:. That value will be put in this document per IEEE Ethertype assignment procedures, and not 5 before then.>> 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 55 56
Copyright © 2007-2008 IEEE. All rights reserved 77 This is an unapproved IEEE Standards Draft, subject to change Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks IEEE P1722/D1.1 2008-08-25
1 2 THIS PAGE LEFT INTENTIONALLY BLANK 3 <
78 Copyright © 2007-2008 IEEE. All rights reserved This is an unapproved IEEE Standards Draft, subject to change IEEE P1722/D1.1 Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks 2008-08-25
Annex E (informative) 802.11 media encapsulation 1 2 3 This section documents generic requirements when running AVBTP over IEEE 802.11 Wireless Local Area Networks. 4 At the time of writing of this document, the adaptation of AVB protocols from 802.3 wired to 802.11 wireless 5 technologies with work being in done in draft work such as 802.11v and 802.11aa. 6 7 As this document is expected to complete prior to those works in progress, this annex specifies the minimum set of 8 requirements required by AVBTP to help guide those efforts to help ensure that when these standards are complete, they 9 will be usable for AVBTP. 10 11 <
Copyright © 2007-2008 IEEE. All rights reserved 79 This is an unapproved IEEE Standards Draft, subject to change Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks IEEE P1722/D1.1 2008-08-25
1 THIS PAGE LEFT INTENTIONALLY BLANK 2 <
80 Copyright © 2007-2008 IEEE. All rights reserved This is an unapproved IEEE Standards Draft, subject to change IEEE P1722/D1.1 Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks 2008-08-25
Annex Z(informative) COMMENTARY 1 2 3 This is a temporary Annex intended to record issues/resolutions thereof as the project proceeds. It will be removed prior 4 to Sponsor ballot, and should be ignored for the purposes of TG/WG ballot. 5 6 <
Copyright © 2007-2008 IEEE. All rights reserved 81 This is an unapproved IEEE Standards Draft, subject to change Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks IEEE P1722/D1.1 2008-08-25
1 Z.4 Need to define more details on format and function of AVBTP source Timestamp and 2 relationship to use of the 61883 SYT field 3 4 5 Current consensus high level definition is “Nominal launch time (launch to the network)”. 6 For fragments, needs to be the same value for each fragment. 61883 type packets will want to be launched in 7 125us intervals (8 kHz clock) 8 AVBTP will also need to deal with time changes in 802.1AS. 9 Alternate proposal is that it is not tied to an 8kHz clock and is instead tied to the media clock and can be used as 10 presentation time. 11 Format of field is TBD (based on decision from 802.1AS) 12 Full resolution target at ~1 second. 13 Discussions to date have been where this timestamp indicates the “desired transmit time”for egress frames (i.e. 14 when the frame is scheduled to be passed to 802.1Qav shaping for subsequent egress transmission). 15 Further discussions will hopefully clarify the use of this field as we get further in our work on Timing and 16 Synchronization details. 17 18 <
82 Copyright © 2007-2008 IEEE. All rights reserved This is an unapproved IEEE Standards Draft, subject to change IEEE P1722/D1.1 Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks 2008-08-25
Z.5 Need to define how 802.1Qat stream IDs are used by AVBTP 1 2 Need to define relationship of stream IDs with source and destination MAC addresses. 3 Need to have a standard Stream ID value that indicates that stream ID contains no data (perhaps all zeros or all 4 ones?) so we can have control frames that either relate to a single stream or to a protocol options for a protocol 5 (subtype). I would assume all zeros would be better as all ones in addresses are usually used for Broadcast. 6 Need to define how stream ID management ties into AVBTP session management. 7 < Copyright © 2007-2008 IEEE. All rights reserved 83 This is an unapproved IEEE Standards Draft, subject to change Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks IEEE P1722/D1.1 2008-08-25 1 Add a new Annex Z issue: Should we add an error reporting mechanism, late packet as first error code 2 3 Solicited errors 4 5 Unsolicited errors 6 7 8 9 < 84 Copyright © 2007-2008 IEEE. All rights reserved This is an unapproved IEEE Standards Draft, subject to change