RE: [EFM] RE: Pause frame usage in transport networks
Hi Shahram,
As Kevin and Ben have both stated, a frame that has an individual MAC address,
which is not the MAC address of a receiving node, but has the Type = 88-08, will
be discarded. I however wanted to clarify why that will occur since Kevin and
Ben gave two different - but nonetheless correct - reason. Kevin and Ben - I
hope you do mind this clarification.
I believe there two different reasons for discarding are depended on the
Promiscuous mode of the MAC (See 30.3.1.1.16).
When the MAC is not in Promiscuous mode:
The unicast address would not match the MAC's address filter so the packet would
be discarded in the MAC and never make it to MAC Control. (See
LayerMgmtRecognizeAddress in subclause 4.2.9 and 5.2.4.3).
Summary: The MAC will discard the frame.
When the MAC is in Promiscuous mode:
The MAC will not filter based on the Destination MAC address hence the packet
contents are passed to the MAC Control sublayer. In the MAC Control sublayer the
packet will pass the (lengthOrType = 802.3_MAC_Control) test in Figure 31-4
'Generic MAC Control Receive state diagram' and the state machine will move to
the CHECK OPCODE state. This means that the packet will be processed in the MAC
Control sublayer and not passed to higher sublayers (as stated in subclause 31.3
- MAC Control sublayer functions shall always sink MAC Control frames). Now in
the CHECK OPCODE state one of two transitions can happen dependent on the
opcode:
1. opcode equal to PAUSE opcode
If the opcode is the PAUSE opcode, the only opcode that can be supported at the
moment as it is the only one defined (see Annex 31A), the state machine
transitions to the state INITIATE MAC CONTROL FUNCTION and the PAUSE Operation
Receive state diagram in Figure 31B-2 will then is called by the 'Perform
opcode-specific operation, per annex' statement to further process the frame
contents. When called, the PAUSE Operation Receive state diagram in Figure 31B-2
will transition directly from the state WAIT FOR TRANSMISSION COMPLETION to END
PAUSE due to the fact that the MAC address is neither the Reserved Multicast
Address nor the unicast address of station. The result is that no action is
taken on the contents of the packet.
Summary: The MAC Control sublayer discards the frame without taking any action.
2. opcode not equal to PAUSE opcode
If the opcode is not the PAUSE opcode the state machine transitions directly
from the CHECK OPCODE to the WAIT FOR ENABLE state to wait for the next frame
without taking any further action on the contents of the frame. The result is
that no action is taken on the contents of the packet.
Summary: The MAC Control sublayer discards the frame without taking any action.
Shahram Davari <Shahram_Davari@xxxxxxxxxxxxxx> on 04/03/2003 19:47:49
Sent by: Shahram Davari <Shahram_Davari@xxxxxxxxxxxxxx>
To: "'Kevin Daines'" <Kevin.Daines@xxxxxxxxxxxxxxxxxxxx>, Ben Brown
<bbrown@xxxxxxxx>, "'Eric Lynskey'" <elynskey@xxxxxxxxxxx>
cc: stds-802-3-efm@ieee.org (David Law/GB/3Com)
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
>-----------------------------------------
>