Re: [EFM] RE: Pause frame usage in transport networks
On Friday 21 February 2003 17:06, Roy Bynum wrote:
> The "link" that you are referring to is, from the data communications view,
> is at the transmission convergence sublayer of the Physical Media layer, a
> part of what 802.3 would refer to as the PHY. What was being discussed
> here is the functionality that exists at the Data Link layer which is part
> of the customer's data link frame traffic.
Sure - it was a simplification of mine. Bad choice of words, I think. I used
the term 'link' to refer in generic terms to the point-to-point entity that
connects the ONU to the OLT. My intention was to point out that OAM is
limited to 'link management' functions, where 'link' is roughly defined as
described above, and so is restricted to the access space.
> In the case of 802.3ah OAM it functions at the Data Link layer, not the
> transmission convergence sublayer. As such it is available to the service
> provider only for "packet" type services. And for "packet" services the
> OAM frames should be for the use of and controlled by the service
> provider. For all other services, the OAM frames belong only to the
> customer and are not accessible to the service provider.
What happens is that OAM 'shares' the same space occupied by user traffic
(dedicated for frame-based traffic, in this case). So it's easy to see where
did the confusion start: although both types of traffic are frames, only one
of them is seen by the customer, and the other one is reserved for the
operator. This separation must be made clear, to avoid people to mistakenly
assume that OAM frames can be seen/used by the customer for whatever purpose.
[btw, coming from a similar background I think I understand why you are always
so cautious when refering to definitions such as 'OAM', 'leased line
services', 'packet based services', etc. But my intention was to refer to the
'link level' as a generic entity, in opposition to the 'user traffic'; it was
a generalization, and I assumed that no precise definitions were needed.]
> Thank you.
> Roy Bynum
Best regards,
Carlos Ribeiro
cribeiro@xxxxxxxxxxxxxxxx