Re: [EFM] RE: Pause frame usage in transport networks
Shahram,
The Slow Protocol, as described in Clause 43, is different
than the MAC Control. Slow Protocol passes frames without
the Slow_Protocols_Multicast DA or with an unrecognized
subtype in the range of 1-10 to the collector (essentially
to the superior sublayer). Slow Protocol frames with the
proper DA but with a subtype outside the range 1-10 are
discarded. See figure 43-5.
Regards,
Ben
Shahram Davari wrote:
>
> 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@worldwidepackets.com]
> >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@pmc-sierra.com]
> >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@worldwidepackets.com]
> >>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@amcc.com]
> >>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@amcc.com
> >>-----------------------------------------
> >>
> >
--
-----------------------------------------
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@amcc.com
-----------------------------------------