[EFM-P2MP] FW: question on clause 64
If there is time, I will be raising this issue during Thursday's meeting:
I'm looking over clause 64, and I'm trying to figure out what prevents an
unregistered ONU from transmitting a MAC Client frame during the discovery
process. Here are my observations:
Figure 64-12 ONU Control Multiplexer state diagram will transmit any frame
that it is passed as long as transmitAllowed is TRUE. It is possible that
multiple TransmitFrame function calls have been made by any number of MAC
Control blocks or the MAC Client. This state diagram does not appear to
prioritize these in any way or deal with what happens if more than one frame
wants to be sent at the same time. There is text 64.2.1 that says "Frames
generated in the MAC Control are given priority over MAC Client frames..."
but the state diagram doesn't seem to deal with this.
Anyway, Figure 64-12 will hold the ONU until the opening of a grant happens.
The transmitAllowed variable is controlled by the Gate Processing block in
Figure 64-27. This variable will bet set to TRUE when the START TX state is
entered. If this were during the discovery process, this state diagram
would also have the ONU wait a random amount of time before transmitting.
Basically, this diagram tells the multiplexer when it can start transmitting
the frame.
Figure 64-20, the ONU Discovery processing state diagram, generates the
necessary TransmitFrame function calls during the discovery process. For
the most part, it moves from state to state upon the reception of MACR
messages from the MAC Control client.
Looking at these three diagrams, I can't find anything that will necessarily
prevent the MAC from transmitting a MAC Client frame during the discovery
process. That being said, there are a couple of implications:
First, if the ONU isn't registered, it will send all frames with the
broadcast LLID in the preamble. Figure 64-18, discovery processing at the
OLT, seems to indicate that it would discard all of these frames should they
be received, because it is only looking for MAC Control frames, specifically
a REGISTER_REQ frame. So, this doesn't seem to be too bad.
The second implication is that an unregistered ONU can send maximum sized
MAC Client frames to the OLT during the discovery process. Since
REGISTER_REQ frames are supposed to be 64 bytes in length, a 1518 byte frame
sent during this process could significantly increase the likelihood that a
collision would occur between this and another ONU. It could become
slightly worse if it were a tagged frame that also had the FEC overhead.
Now I will pose a few questions:
1. Is this a problem?
2. If so, how do we fix it?
I think a fairly minor modification could be made that will not allow
anything but MAC Control frames to be sent until the ONU is registered. I
also think some text should be put in there to discuss what happens within
the multiplexer when multiple MAC Control frames arrive at the same time.
Also, perhaps stronger wording is needed to explicitly allow the multiplexer
to give priority to MAC Control frames over MAC Client frames.
-Eric