Comments on DRAFT AES51-xxxx, AES standard for digital audio Digital input-output interfacing Transmission of ATM cells over Ethernet physical layer, published 2005-11-09 for comment.
Comment received from Kevin Gross, 2005-11-29
Consider revision of the abstract to indicate AES51 carries ATM cells and real-time clock over Ethernet hardware. Suggested wording: "... of carrying asynchronous transfer mode (ATM) cells and real-time clock over hardware specified..."
Suggest addition of "Octet" to section 3. Audio professionals my not be familiar with this common networking term. Suggested wording, "a group of 8 bits. It can be expressed as a decimal integer in the range 0-255, or as a pair of hexadecimal digits such as 5E (=94)" source: http://en.wikipedia.org/wiki/Octet
Second paragraph of section 4.1 references annex C.2. I believe C.1 is the correct reference here.
Adding a diagram of the frame structure to 4.1 would improve clarity.
Second paragraph in section 4.3.2 references section 4.3. I believe section 4.3.1 is the more precise reference.
5.1.1 should clarify that reset is deasserted when Ethernet auto negotiation completes and the link enters the up state. Suggested wording: "...The reset signal shall be true at power-on and while the physical layer reports that the link is "down". Reset is false once the link enters the "up" state."
The document might read better if section 5.1.1 were moved to the beginning of section 5.2.
Regarding section 5.1.4, an alternative approach to packet time stamping is exemplified in IEEE 1588. Timing information pertaining to the present packet is transmitted in a follow-on packet. This pipelined approach avoids introducing an implied requirement that packets be generated or modified on the fly.
Adding a state transition diagram to section 5.2 would improve clarity.
With no requirement for ongoing transmission of link request packets in 5.2.4, it is unclear how a devices would establish link if they had been previously disconnected for an extended period of time. Suggestion: "5.2.4 Timeout. Timeout should only occur in the "requesting" state. On timeout, the "link request" packet shall be retransmitted and the timer set for at least 500ms. Note: The timer may be set for a longer interval on each attempt."
The uncertainty in timing field specified in 5.3.3 is specified in milliseconds. Subsequent discussion indicates that it may be more appropriate to specify this parameter in units of cells. Specifically the example given in the note in this section shows connection accept criteria based on the estimated number of cells that would need to be buffered for a given uncertainty in timing specification.
The committee may wish to consider specifying a measurement period for the cells per second metrics described in 5.3.5. The metric is somewhat ambiguous without this.
Section 5.4.1 introduces a useful term, "offered configuration." This appears to be the same as "supported configuration" used in earlier discussion.
The MAC ordering described in section 5.4.4 (b) is commonly referred to as "lexicographical".
5.4.5 implies that IEEE 802.3 specifies a maximum cell rate. The cited 802.3 section probably specifies a maximum frame rate.
Kevin Gross,
Director, Network Technology
Commercial Audio division, Cirrus Logic, Inc.
Reply from John Grant, chair SC-02-02, 2005-12-05
Dear Kevin,
Thank you for taking the time to review this document. It is a pity that, as a member of SC-02-02, you were not able to do so at an earlier stage, but better late than never.
Answering your points in the order in which they appear:
I agree with your suggestion to add "and real-time clock" to the Abstract.
I will leave it to the Secretariat to decide whether we should add "octet" to clause 3. If so, I would favour basing the definition on IEC 60027 (see (b) in Annex I to Part 2 of the IEC Directives (2004 edition).
The first reference to annex C.2 in 4.1 should indeed be to C.1.
The list in 4.1 is already in a very similar form to figure 3-1 of IEEE802.3-2002. However I would not object to the addition of a presentation in a format similar to Figure 7 of AES10-2003.
The reference to 4.3 in 4.3.2 should indeed be to 4.3.1.
We specify in 5.1.1 that "link down" shall reset the interface so that it is clear that in the case of a point-to-point link pulling the plug out will reset the link. We leave it to the implementor to decide how soon after the link comes up "reset" is negated and how soon after that it initiates the negotiation procedure. There could be many reasons why there may be an arbitrarily long delay between the link coming up and the rest of the system being ready to negotiate the use of AES50; for instance in the case of a PC it may not be until a particular program is run, and the sensible action for an ATM switch with several ports connected to an Ethernet network would be to negate reset on one port at a time and never actively initiate negotiation.
One of the states defined in 5.1.1 is referenced in 5.1.3. Note that (according to the definitions in the IEC Directives) 5 is a clause and 5.1 is a subclause, so "this clause" means the whole of 5.
My knowledge of IEEE 1588 is limited, but I believe it requires similar logic at the receiving end to detect the exact arrival time of packets. The wording "time at which the first bit of the octet following the Start Frame Delimiter for the packet was presented to the PHY" in 4.4 was intended to align the timing point with that used in IEEE 1588. On the sending end I think you are saying that IEEE 1588 puts the information collected in a separate Delay_Resp message which can then pass down the normal Ethernet stack. In our case, however, synchronised interfaces will already be generating the ATM-E data packets on the fly so inserting the timing information in those is not a problem. The timing field in other packets can be coded as FFFFFFFF if timing information cannot be conveniently inserted in them.
I will leave it to the Secretariat to decide whether we should add a state diagram to 5.2.
Once the interface has reverted to "passive" state, the management entity can request restarting the negotiation procedure at any time. As with 5.1.1, we leave it to the implementor to choose the exact behaviour.
AES47 permits a wide range of different formats with different cell rates. In the example in the Note to 5.3.3, the uncertainty in ms will be the same for every call (being a feature of how often the operating system can deliver timer tick events) but the number of cells will be different, e.g. twice as many for 96 kHz, 3 times as many for 6-channel surround sound.
The intention in 5.3.5 was that cells would be transmitted at nominally regular intervals, but collected together into packets of the maximum size indicated by 5.3.2; however, that may not be clear from the current wording. We should add an extra paragraph to 5.3.5: "Where the maximum cell rate is less than the capacity of the link, packets shall nominally be transmitted at regular intervals of c/n sec, where c is the maximum number of cells in a packet (see 5.3.2) and n the maximum cell rate; actual transmission times shall be subject to the uncertainty signalled in information element type 02[16] (see 5.3.3), and CBR traffic contracts shall be observed as if the cells after the first in each packet had been transmitted later than their actual transmission time, such that cells were transmitted at 1/n sec intervals."
5.4.1 states that the offered configuration is defined by the information in a received "link request" packet, which will reflect the supported configuration of the sender of the packet, i.e. the entity at the other end of the link.
Do you want to suggest wording for a note to be added after paragraph (b) in 5.4.4? Incidentally, I notice that the first line of 5.4.4 says "uncertainty in timing" when it should be "quality of timing".
The reference in 5.4.5 was intended to show which PHY registers indicate the link speed, but reading it more closely I find that "it is not necessary for bits 0.6 and 0.13 to reflect the operating speed of the link". The parenthesised text "(see 22.2.4.1.3 of IEEE 802.3)" should be replaced by "(which can be calculated from the link speed and the maximum number of cells per packet)".
Please let us know as soon as possible whether this reply is acceptable to you; if you do not reply by the end of the comment period we will assume that it is. You may also ask us to consider your comments again for the next revision of the document. You may also appeal our decision to the Standards Secretariat.
Reply from Kevin Gross, 2006-01-04
Sorry to have gone silent on that. I'm satisfied that my comments have been
heard and understood and, in most cases, acted upon. I don't feel further
discussion is required. I hope you feel this was a productive exercise. I
apologize for not involving myself in the standards process earlier.
Kevin Gross,
Director, Network Technology
Commercial Audio division, Cirrus Logic, Inc.
