RE: [EFM] RE: Pause frame usage in transport networks
What about 802.3ah OAM frames? Are they treated the same? meaning that:
All frames with Type/Length =88-09 are terminated
All frames with Type/Length =88-09 and DA=01-08-C2-00-00-02 are sent to OAM layer
All frames with Type/Length =88-09 and DA!=01-08-C2-00-00-02 are discarded
Yours,
-Shahram
>-----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
>>-----------------------------------------
>>
>