RE: [EFM] RE: Pause frame usage in transport networks
unsubscribe
-----Original Message-----
From: Roy Bynum [mailto:rabynum@xxxxxxxxxxxxxx]
Sent: Saturday, March 08, 2003 3: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
> >-----------------------------------------
> >