RE: [EFM-P2MP] EPON and PAUSE operation
Eric,
Good questions. I was among those arguing that we should not
state incompatibility with flow control, because with P2P
emulation it can be supported, and one can envision a
scenario where it even can be useful. Below I'll try to
address specific points that you raise:
> ... what would happen if a PAUSE frame is received by
> an OLT from ONU[j], assuming for now that both the OLT
> and ONU[j] support flow control.
Current model provides a separate instance of flow control
per LLID. The OLT will stop transmission only from the
channel (LLID) from which the PAUSE frame was received.
> Will this prevent all data frames from being
> transmitted to ONU[j]?
That will prevent all data frames from being transmitted
with given LLID value. Below emulation layer, the ONU[j]
would see all frames with all LLIDs. But since no LLID would
match that of ONU[j], all those frames will be filtered out.
AT MAC layer, ONU[j] will not see any frames.
> What about frames sent by the single copy broadcast
> MAC or other frames that may be sent in the shared LAN
> Emulation? If any data frame is sent to ONU[j], then it
> would seem that the PAUSE protocol has been compromised.
> Another problem would be if a single ONU was able to
> prevent other ONUs from receiving frames.
The annex 31B states that PAUSE should only be used with a
full-duplex MACs. I think the true intent was to say "only
on P2P links". (here we have a slight problem that EPON uses
only full-duplex MACs, yet it can emulate shared LAN as well
as point-to-point). The reason to use only P2P links is, I
believe, to prevent one station from shutting down entire
LAN by broadcasting PAUSE messages. Same with the shared LAN
emulation in EPON - flow control should not be used.
As I mentioned above, one can see a case when flow control
may be useful in EPON. Consider a server (Web cache, VOD,
streaming, etc.) collocated with the OLT. The server could
send more data than user's LAN could handle. That would
overflow ONUs Rx queues causing loss of data. As a result,
downstream bandwidth in EPON is wasted (frames are
transmitted by the OLT, but are dropped in the ONU). It is
reasonable for the ONU to send PAUSE to the associated MAC
Control in the OLT. This would leave more downstream
bandwidth for other ONUs.
On related note, does anyone know the status of 802.1 work
on defining a shared emulation (AKA selective broadcast)
layer for EPON?
Thanks,
Glen
> -----Original Message-----
> From: owner-stds-802-3-efm-p2mp@majordomo.ieee.org
> [mailto:owner-stds-802-3-efm-p2mp@majordomo.ieee.org] On
> Behalf Of Eric Lynskey
> Sent: Tuesday, September 02, 2003 12:12 PM
> To: stds-802-3-efm-p2mp@ieee.org
> Subject: [EFM-P2MP] EPON and PAUSE operation
>
>
> I'm having a little trouble seeing how MPCP is compatible
> with flow control,
> so before I submit a comment, I'd like some feedback from
> this forum.
>
> Subclause 64.3.3.1 states that "Even though MPCP is
> compatible with flow
> control, optional use of flow control may not be efficient
> in the case of
> large propagation delay." Figures 64-11 and 64-12 seem to
> show that any MAC
> Control frame can be transmitted from an OLT or ONU
> provided it has a
> supported opcode. Figures 64-9 and 64-10 seem to show
> that any MAC Control
> frame with a supported opcode will be received and acted
> upon in the
> appropriate manner.
>
> When a device does support and receives a validly formed
> PAUSE frame, it
> will then inhibit transmissions from the MAC Client for
> the specified amount
> of time. For a 1Gb/s ethernet system, this can be up to
> approximately 33ms.
>
> I'm confused about what would happen if a PAUSE frame is
> received by an OLT
> from ONU[j], assuming for now that both the OLT and ONU[j]
> support flow
> control. I would think that only client[j], associated
> with MAC[j] would be
> stopped from transmitting. Will this prevent all data
> frames from being
> transmitted to ONU[j]? What about frames sent by the
> single copy broadcast
> MAC or other frames that may be sent in the shared LAN
> Emulation? If any
> data frame is sent to ONU[j], then it would seem that the
> PAUSE protocol has
> been compromised. Another problem would be if a single
> ONU was able to
> prevent other ONUs from receiving frames.
>
> Does anyone have any comments on this? Would it be wise
> to put a sentence
> or two in 64.3.3.1 warning people that flow control may
> not only be
> inefficient, but could also have undesireable effects?
>
> -Eric