RE: [EFM] RE: Pause frame usage in transport networks
unsubscribe
-----Original Message-----
From: Kevin Daines [mailto:Kevin.Daines@xxxxxxxxxxxxxxxxxxxx]
Sent: Tuesday, March 04, 2003 3:11 PM
To: Shahram Davari; Ben Brown; Eric Lynskey
Cc: stds-802-3-efm@ieee.org
Subject: RE: [EFM] RE: Pause frame usage in transport networks
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
>-----------------------------------------
>