Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Kevin,
(referencing the two figures shown in this reflector post: https://www.ieee1904.org/2/email/msg00289.html)
>> After looking at this again, and starting to write text around one of these figures, it seems that the second figure is easier to
In the second figure, there is only a single MAC instance, so in the receive direction there is no MAC address sharing. However, in the transmit direction, the OAMPDU.request primitive includes the source_address parameter. When any of the multiple OAM entities generates an OAMPDU, it should insert the single common MAC address. So, in the second figure, OAM entities all share the same MAC address.
In the first figure, each OAM entity sits on top of its own MAC instance, and these MAC instances all share the same MAC address. This is how the 802.3 solved this exact problem (see the highlighted text). I suggest we discuss these two approaches on the next socialization call.
-Glen
From: Lists <lists@xxxxxxxxxxxxxxx>
After looking at this again, and starting to write text around one of these figures, it seems that the second figure is easier to explain simply from the point of view that the mechanism to share the MAC address is obvious vs. the first figure we would need to explain the magic involved in sharing the MAC address... or just leave it unexplained (not my preference).
Thoughts?
Sent from my mobile device
To unsubscribe from the STDS-1904-2-TF list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-1904-2-TF&A=1 |
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature