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
> > >-----------------------------------------
> > >