IEEE 1722:2011 pdf free download – IEEE Standard for Layer 2 Transport Protocol for Time-Sensitive Applications in Bridged Local Area Networks
3.3 Reserved fields
Any field within a data structure that is defined in this specification as reserved is reserved for futurestandardization.All reserved fields specified in this standard shall be set to a value of zero (0) on transmit.All reserved fields specified in this standard shall be ignored on receive.
3.4 Numerical values
Decimal, hexadecimal, and binary numbers are used within this document. For clarity, decimal numbers aregenerally used to represent counts，hexadecimal numbers are used to represent addresses，and binarynumbers are used to describe bit patterns within binary fields.
Decimal numbers are represented in their usual 0, 1,2, … format. Hexadecimal numbers are represented bya string of one or more hexadecimal (0 to 9 and A to F) digits followed by the subscript 16. Binary numbersare represented by a string of one or more binary(0,1) digits in left to right order where the left-most bit isthe most significant bit and the right-most bit is the least significant bit, followed by the subscript 2.Thus,the decimal number “26″ may also be represented as “1Ay6”or “110102.”
These notational conventions have one exception:MAC addresses and IEEE Organizationally Uniqueldentifier(OUIyIEEE Extended Unique ldentifier(EUI) valucs are represented as strings of 8 bithexadecimal numbers separated by hyphens and without a subscript as,for example, “01-80-C2-00-00-15″”or “AA-55-11.”
3.5 Notation of fields and values taken from other documents
This document uses fields and values defined in other documents with multiple methods of defining suchthings as usage of uppercase and lowercase, usage of underscore characters, italics, etc.As this document isintended to use these multiple protocols，its additional intent is also to make it easier for readers andimplementers of those documents by not using different names and notation for those fields and values. So,the following conventions are used for field names from other documents to match the convention fromthose documents:
a) Fields from IEEE Std 802.1Q-2005: Ficelds are in all uppercase,no underscores (examples:destination MAC address [DA], source MAC address [SAj, tagged protocol identifier [TPID],canonical format indicator [CFI], and VLAN identifier [VID]).
b) Fields from IEEE Std 1394-2008:Ficlds in lowercase except for acronyms within the field name with optional underscores (examples: tcode, data_length, and source_ID).
5.4.7 tu (timestamp_uncertain) field
The 1 bit tu field shall be set by the Talker when the attached gPTP system reports any significant problemwith its synchronization system. Examples might be the invocation of the best master clock aigorithmbecause of a Sync Timeout or detection of an unacceptable phase transient by circuitry independent of thegPTP state machine. Thus,it is used by Talkers to indicate that the timestamps may not be globallysynchronized with network time.The bit may be used by Listeners， possibly in conjunction with theirknowledge of the status of the gPTP clock, to prevent unacceptable disturbances in the recovered mediastreams.
The AVTP presentation time represents the timestamp of when the media sample was presented to AVTPat the Talker plus a constant, Max Transit Time, to compensate for network latency. Network latency isdependent on the network configuration and speed.Max Transit Time represents the worst-case networklatency assumed for a given configuration. It is possible for a Talker and a Listener to determine the MaxTransit Time value to use in a given stream. The mechanism for a Talker and a Listener to negotiate MaxTransit Time is outside the scope of this standard.Unless otherwise negotiated between the Talker and theListener,the Max Transit Time to calculate the AVTP presentation time is defined by the Default MaxTransit Time in Table 5.3.