RE: [EFM] RE: Pause frame usage in transport networks
Virtually all of the implementations that I've seen do send their Pause
frames with the reserved multicast address as the DA. A large percentage of
implementations do not, in fact, react to pause frames that don't have the
reserved multicast address, even though they should.
-Eric Lynskey
> -----Original Message-----
> From: Kevin Daines [mailto:Kevin.Daines@xxxxxxxxxxxxxxxxxxxx]
> Sent: Monday, March 10, 2003 10:23 PM
> To: fongliaw@xxxxxxxxx; Roy Bynum; Shahram Davari; Ben Brown; Eric
> Lynskey
> Cc: stds-802-3-efm@ieee.org
> Subject: RE: [EFM] RE: Pause frame usage in transport networks
>
>
> Fong,
>
> Annex 31B states that the transmitting device must use the
> reserved multicast address as the DA. However, the receive state
> machine allows _either_ the reserved multicast address OR the
> station's unicast address. In other words, a compliant device
> (compliant with the PICS in Annex 31B before anyone asks) must
> only send the reserved multicast address.
>
> I have not heard of anyone using anything other than the reserved
> multicast address. But, I can't say I've sampled a large portion
> of existing implementations either.
>
> kevind
>
>
> -----Original Message-----
> From: Fong Liaw [mailto:fongliaw@xxxxxxxxx]
> Sent: Monday, March 10, 2003 12:32 PM
> To: Kevin Daines; 'Roy Bynum'; 'Shahram Davari'; 'Ben Brown'; 'Eric
> Lynskey'
> Cc: stds-802-3-efm@ieee.org
> Subject: RE: [EFM] RE: Pause frame usage in transport networks
>
>
> Kevin
>
> This is probably off-topic to EFM, but since we are at it already.
>
> According to David's text on PAUSE processing, a PAUSE frame that
> carries a station's individual MAC address will trigger PAUSE action.
> But this seem to conflict with 31B.1.
>
> Can you clarify if:
>
> 1) In theory (according to 802.1/3), can a PAUSE Frame carry a
> (destination) station's individual MAC address?
> 2) If yes on (1), in practice, any chip/vendor send PAUSE frame with
> individual address at all?
>
> Thanks in advance.
> -Fong
>
> > -----Original Message-----
> > From: owner-stds-802-3-efm@majordomo.ieee.org
> [mailto:owner-stds-802-3-
> > efm@xxxxxxxxxxxxxxxxxx] On Behalf Of Kevin Daines
> > Sent: Saturday, March 08, 2003 4:30 PM
> > To: Roy Bynum; Shahram Davari; Ben Brown; Eric Lynskey
> > Cc: stds-802-3-efm@ieee.org
> > Subject: RE: [EFM] RE: Pause frame usage in transport networks
> >
> >
> > Roy,
> >
> > Please see Shahram's original e-mail which used language such as
> "Based on
> > 802.3 standard" and "if OLT1 behaves like a bridge". I gathered from
> those
> > phrases, that Shahram's intent was to get an interpretation of the
> > relevant portions of the 802.1/3 specs.
> >
> > kevind
> >
> >
> >
> > -----Original Message-----
> > From: Roy Bynum [mailto:rabynum@xxxxxxxxxxxxxx]
> > Sent: Saturday, March 08, 2003 12:09 PM
> > To: Kevin Daines; Shahram Davari; Ben Brown; Eric Lynskey
> > Cc: stds-802-3-efm@ieee.org
> > Subject: RE: [EFM] RE: Pause frame usage in transport networks
> >
> >
> > Keven,
> >
> > Compliant with what? What if the transmission facility was not an
> 802.1
> > bridge with an 802.3MAC Client?
> >
> > Thank you,
> > Roy Bynum
> >
> >
> > At 12:11 PM 3/4/2003 -0800, Kevin Daines wrote:
> >
> >
> > >Shahram,
> > >
> > >A compliant implementation would sink your example frame along with
> all
> > >other MAC Control frames. MAC Control frames are only distinguished
> by
> > the
> > >Length/Type field.
> > >
> > >References from IEEE Std 802.3-2002:
> > >
> > >31.3 - "MAC Control sublayer functions shall always sink MAC Control
> > frames."
> > >
> > >31.4 - "MAC Control frames are distinguished from other MAC frames
> only
> > by
> > >their Length/Type ?eld identi?er."
> > >
> > >31.8.3.3 PICS item SD2 - "Sink MAC Control frames" Mandatory
> > >
> > >Note, I haven't mentioned PAUSE. All of the above references are
> protocol
> > >independent. Hope this helps.
> > >
> > >kevind
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >-----Original Message-----
> > >From: Shahram Davari [mailto:Shahram_Davari@xxxxxxxxxxxxxx]
> > >Sent: Tuesday, March 04, 2003 11:48 AM
> > >To: Kevin Daines; Ben Brown; 'Eric Lynskey'
> > >Cc: stds-802-3-efm@ieee.org
> > >Subject: RE: [EFM] RE: Pause frame usage in transport networks
> > >
> > >
> > >Kevin,
> > >
> > >What happens to a frame that has an individual MAC address, which is
> not
> > the
> > >MAC address of a receiving node, but has the Type = 88-08?
> > >
> > >Yours,
> > >-Shahram
> > >
> > > >-----Original Message-----
> > > >From: Kevin Daines [mailto:Kevin.Daines@xxxxxxxxxxxxxxxxxxxx]
> > > >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
> > > >-----------------------------------------
> > > >
>
>