Re: [802.3_MAINT] summary of MAC interface issues
Jeff,
Thanks for the information. I apologize for not having been more
involved in this discussion.
My interpretation of a .request or .indicate is that they are a trigger
to indicate that the variables contained within are ready and valid. It
is also my interpretation that this trigger has no frequency associated
with it except by the function that decides to make the .request or
.indicate message. The value in this is that it removes any time
dependency from the interface between the MAC Client and the MAC;
therefore, as we change Ethernet speeds, we do not need to redefine the
MAC-MAC Client interface.
The GENERATE_TRANSMIT_FRAME state performs an instantaneous transfer for
the variables in the MA_DATA.request to the TransmitFrame function. The
state has no time; therefore, there is an immediate transfer back to
WAIT_FOR_TRANSMIT. The call to TransmitFrame in the
GENERATE_TRANSMIT_FRAME is a transition from a timeless state to a
function bounded by time. In implementations, this is where buffering
would need to occur.
At this point in time, it appears there is consideration for changing
the existing operation of the MAC in Clause 4 or in the definition of
its use; therefore, I do not feel comfortable supporting either option.
Thanks,
Brad
-----Original Message-----
From: owner-stds-802-3-maint@xxxxxxxx
[mailto:owner-stds-802-3-maint@xxxxxxxx] On Behalf Of Jeff Mandin
Sent: Tuesday, August 12, 2008 12:26 PM
To: STDS-802-3-MAINT@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_MAINT] summary of MAC interface issues
Brad hi,
You might want to take a look at the original slides from the telecon,
which are here: http://www.ieee802.org/3/maint/email/msg00017.html .
Also the telecon notes are at
http://www.ieee802.org/3/maint/email/msg00018.html and
http://www.ieee802.org/3/maint/email/msg00019.html .
As you can see from the notes and ensuing discussion, the MAC interface
for an extra primitive (aka "3 arrow") was talked about in the adhoc -
however it was not regarded as viable for reasons including some that
you list - as well as compatibility with 802.1. The approaches
considered til now include:
a) creating a precise definition of MA_DATA.Request() interaction with
the MAC
b) writing some text that explains that the MAC client is expected to
somehow ensure that it doesn't invoke the MA_DATA.Request() for the
subsequent frame too soon.
You seem to lean to option b), correct?
Regards,
- Jeff Mandin
MAC interface Maintenance adhoc chair
-----Original Message-----
From: owner-stds-802-3-maint@xxxxxxxx
[mailto:owner-stds-802-3-maint@xxxxxxxx] On Behalf Of Brad Booth
Sent: Tuesday, August 12, 2008 7:19 PM
To: STDS-802-3-MAINT@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_MAINT] summary of MAC interface issues
Glen,
Thanks for providing the slides. I was unable to attend the meeting in
Denver, so the slides are helpful in getting up to speed on this.
Here's some feedback on the problems you highlight in slide 2:
1) I don't understand how this is a problem. From what I can see, the
existing state machine and function call look fine. As a matter of
fact, I believe the changes being proposed would break the existing
standard. The goal of the state machine is to queue up incoming data
for the TransmitFrame function. Waiting for the TransmitFrame function
to complete before waiting for the next frame would be assuming that no
other MA_DATA.requests are received. If the upper layer protocol is
transmitting MA_DATA.requests faster than the frames are being
transmitted, then an implementer must be prepared to buffer those frames
until the TransmitFrame function can perform the requested operation.
The TransmitFrame function is not an instantaneous action, but rather a
queued routine.
2) The MA_DATA.request can be generated instantaneously after the
current MA_DATA.request is completed. You are correct that the MAC
Client is unaware of the status of the request. If, and that's a big
if, the 802.3 WG felt that an indication of the status of the request
was required, then the MAC and the MAC Client would need to exchange a
unique identify for each frame to track the status of that frame. This
would be required due to the fact that in problem #1, the interaction
between 4.2.8 and the TransmitFrame function results in a queue;
therefore, the status response to the MA_DATA.request may be delayed
relative to the original request.
Thoughts?
Thanks,
Brad
-----Original Message-----
From: owner-stds-802-3-maint@xxxxxxxx
[mailto:owner-stds-802-3-maint@xxxxxxxx] On Behalf Of Glen Kramer
Sent: Monday, August 11, 2008 5:56 PM
To: STDS-802-3-MAINT@xxxxxxxxxxxxxxxxx
Subject: [802.3_MAINT] summary of MAC interface issues
All,
In the attached slides, I tried to summarize the MAC interface issues
that were discussed in Denver and on the reflector, as well as outline
various options to resolve them. I could not join the conference call,
so if some other options were discussed, please let me know and I'll add
those.
I am looking forward to everyone's feedback.
Thanks,
Glen