RE: [EFM] RE: Pause frame usage in transport networks
Kevin is correct that a device should not transmit a PAUSE frame with a
unicast destination address. However, according to 31B.3.3, a validly
received PAUSE frame with "the reserved multicast address specified in
31B.1, or the unique physical address associated with this station..."
should be acted upon. So, although the frame can't be transmitted without
violating the standard, it does need to be received.
-Eric Lynskey
> -----Original Message-----
> From: owner-stds-802-3-efm@majordomo.ieee.org
> [mailto:owner-stds-802-3-efm@majordomo.ieee.org]On Behalf Of Kevin
> Daines
> Sent: Tuesday, March 04, 2003 12:40 AM
> To: Ben Brown; Shahram Davari
> Cc: stds-802-3-efm@ieee.org
> Subject: RE: [EFM] RE: Pause frame usage in transport networks
>
>
>
> Shahram,
>
> I'll add two things to Ben's response.
>
> >From 31B.3.1, first sub-bullet (a) reads:
>
> "a) The destinationParam is set equal to the destination_address
> parameter of the MA_DATA.request
> primitive. This is currently restricted to the value specified in 31B.1."
>
> 31B.1 reads:
>
> "a) The globally assigned 48-bit multicast address 01-80-C2-00-00-01,"
>
> and further down in 31B.1 it reads:
>
> "The globally assigned 48-bit multicast address 01-80-C2-00-00-01
> has been reserved for use in MAC Control PAUSE frames for
> inhibiting transmission of data frames from a DTE in a full
> duplex mode IEEE 802.3 LAN. IEEE 802.1D-conformant bridges will
> not forward frames sent to this multicast destination address,
> regardless of the state of the bridge's ports, or whether or not
> the bridge implements the MAC Control sublayer."
>
>
> My reading of these sections leads me to conclude PAUSE frames
> shall _NOT_ have an individual MAC address. That would render the
> balance of your e-mail moot.
>
>
> kevind
>
>
>
> -----Original Message-----
> From: Ben Brown [mailto:bbrown@xxxxxxxx]
> Sent: Monday, March 03, 2003 1:09 PM
> To: Shahram Davari
> Cc: stds-802-3-efm@ieee.org
> Subject: Re: [EFM] RE: Pause frame usage in transport networks
>
>
>
>
> Shahram,
>
> >From 31.3: "Frames destined for the MAC Control sublayer (MAC
> Control frames) are distinguished from frames destined for MAC
> Control clients by a unique Length/Type field identifier."
>
> If OLT1 is indeed a true MAC with a bridging layer above it
> then it will see this as a MAC Control frame. If the DA doesn't
> match the multicast address or OLT1's SA, then OLT1 may discard
> the frame but it will not pass it up to the bridge.
>
> Regards,
> Ben
>
> Shahram Davari wrote:
> >
> > Hi all,
> >
> > Based on 802.3 standard, the PAUSE frames may have an
> individual or multicast MAC address (including broadcast).
> > It seems to me if the ONU1 sends PAUSE frames with Dest MAC
> address of ONU2, then the OLT1 would
> > relay that to ONU2 (no matter if OLT1 behaves as a transparent
> box or as a bridge), while if the ONU1
> > sends a PAUSE frame with Dest MAC address of OLT1 or a
> multicast MAC address then the PAUSE frames
> > would be terminated at OLT1 if OLT1 behaves like a bridge.
> >
> > ONU1---------OLT1/GFP-------GFP/OLT2------ONU2
> > Eth EOS Eth
> >
> > In other words for end-to-end OAM, if we know that OLT1 does
> not terminate any OAM frames, then ONU1 may use either
> > Dest MAC address of ONU2 or a multicast address, but if we know
> that OLT1 terminates MAC, then ONU1 should use Dest MAC address
> of ONU2. To be is safe side it seems that for end-to-end OAM, it
> is best if ONU1 always sets the Dest MAC address to that of ONU2.
> >
> > Correct?
> >
> > Yours,
> > -Shahram
>
>
> --
> -----------------------------------------
> Benjamin Brown
> AMCC
> 200 Minuteman Rd
> 3rd Floor
> Andover, MA 01810
> 978-247-8022 - Work
> 603-491-0296 - Cell
> 978-247-0024 - Fax
> 603-798-4115 - Home Office/Fax
> bbrown@xxxxxxxx
> -----------------------------------------