RE: [EFM-P2MP] unicast/multicast MACs in Clause 65
Ben,
Yes, this is what I would do.
Thanks,
Glen
> -----Original Message-----
> From: owner-stds-802-3-efm-p2mp@majordomo.ieee.org
> [mailto:owner-stds-802-3-efm-p2mp@majordomo.ieee.org] On
> Behalf Of Benjamin Brown
> Sent: Saturday, April 26, 2003 4:53 AM
> To: Glen Kramer
> Cc: benjamin.brown@ieee.org; rdg@lucent.com; stds-802-3-
> efm-p2mp@ieee.org; t.ishida@ansl.ntt.co.jp
> Subject: Re: [EFM-P2MP] unicast/multicast MACs in Clause
> 65
>
>
>
> Glen,
>
> So, in this clause, just say there is a MODE bit and an
> LLID value
> associated
> with each MAC and say nothing else. Is that it? I just
> looked back to D1.1,
> when this clause was a copy of Clause 35, and it didn't go
> into the MAC
> labels.
> This was something I added as a result of discussions held
> at the
> meeting when
> I began editing this clause. Removing these labels would
> make it closer
> to the
> idea of the original.
>
> I'm away on Monday. I'll need to submit my comments no
> later than tonight.
> If I don't hear from you, I'll expect you to submit the
> comment for this
> change.
>
> Regards,
> Ben
>
> Glen Kramer wrote:
>
> >Ben,
> >
> >It seems we create problems ourselves and than struggle
> to
> >find a nice solution.
> >
> >
> >
> >>For each registered ONU, 2 logical links are
> established,
> >>a Point-to-Point logical link and a Shared logical link.
> >>The MACs associated with these links are referred to as
> >>the P2P-MAC and the S-MAC, respectively.
> >>
> >>
> >
> >I don't think this is a correct statement. An EPON with
> only
> >P2P logical links is perfectly compliant with .1D.
> Second
> >MAC instance per ONU is only needed when a ULSLE layer is
> >implemented to do selective broadcast.
> >
> >I don't think the said paragraph even belongs to Clause
> 65.
> >All the clause 65 should do is just mentioning the two
> modes
> >of operation as determined by the mode bit. It should say
> >that ONE LLID IS ALWAYS ASSOCIATED WITH ONE MAC, without
> >going into discussion on how many MACs there should be.
> >
> >
> >
> >>The MACs associated with these links are referred to as
> >>the P2P-MAC and the S-MAC, respectively.
> >>
> >>
> >
> >The paragraph in question is the only place in clause 65
> >where we mention P2P-MAC and S-MAC (or unicast MAC and
> >multicast MAC in D1.414). If we remove this paragraph
> then
> >we don't need to talk about P2P-MAC and S-MAC.
> >
> >The layer that knows how to properly direct frames into
> >different MACs (i.e. P2P-MAC and S-MAC) should contain
> the
> >description of those MACs and explain that P2P-MAC can
> >receive and transmit, but S-MAC can only transmit. This
> >layer is ULSLE, not the RS. From RS-layer perspective,
> all
> >the MACs are the same; the only difference is in the
> >filtering function (positive vs. negative filtering).
> Don't
> >you agree?
> >
> >I did not submit a comment yet. I really would like to
> have
> >one more conference call before the deadline.
> >
> >Bob -- is it possible to reserve a phone bridge on
> Monday?
> >
> >Glen
> >
> >
> >
> >
> >>Glen,
> >>
> >>Thanks for your response. Let me address each of your
> >>ideas:
> >>
> >>1) Apply a name to the link rather than the MAC.
> >>There are times when the MAC needs to have a label. I'm
> >>okay with your
> >>suggestion but I think the name needs to cover the MAC
> as
> >>well.
> >>
> >>2) Combine the MODE bit with the LLID value when
> >>describing the MAC.
> >>This can work in some places but when talking about the
> >>filtering, it is
> >>convenient to have the MODE and LLID values separate.
> I'd
> >>rather not
> >>combine them.
> >>
> >>I like your suggestion of point-to-point and shared
> >>logical link. Mostly
> >>because it corresponds to another response from T.
> Ishida,
> >>who suggested
> >>point-to-point emulation MAC and shared emulation MAC.
> >>This is how
> >>the last paragraph in page 419 might change:
> >>
> >>... In an OLT, multiple MACs exist to support the
> multiple
> >>logical
> >>links. There
> >>is one MAC to support the Single Copy Broadcast logical
> >>link. This MAC
> >>is referred to as the SCB-MAC. For each registered ONU,
> 2
> >>logical links
> >>are established, a Point-to-Point logical link and a
> >>Shared logical
> >>link. The
> >>MACs associated with these links are referred to as the
> >>P2P-MAC and the
> >>S-MAC, respectively. Packets are transmitted to and
> >>received from the
> >>Single Copy Broadcast and Point-to-Point logical links.
> >>Packets are only
> >>transmitted to the Shared logical link, never received.
> >>
> >>Thoughts from anyone?
> >>
> >>Glen, do you plan to submit this comment? Remember, we
> >>need complete
> >>replacement text for all sections. If you'd rather, I'll
> >>take a stab at
> >>putting
> >>the comment together.
> >>
> >>Regards,
> >>Ben
> >>
> >>Glen Kramer wrote:
> >>
> >>
> >>
> >>>Ben,
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>At the last meeting, there was much discussion around
> >>>>
> >>>>
> >>the
> >>
> >>
> >>>>names "unicast" and "multicast" when describing the
> MACs
> >>>>in the OLT associated with a single LLID.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>I think we should not tie the mode of operation with
> MAC.
> >>>MAC operation remains the same no matter what the mode
> >>>
> >>>
> >>bit
> >>
> >>
> >>>is. "unicast" and "multicast" are attributes of the
> >>>
> >>>
> >>logical
> >>
> >>
> >>>(virtual) links.
> >>>
> >>>Here are some naming options:
> >>>
> >>>Unicast logical link
> >>>multicast logical link
> >>>
> >>>point-to-point logical link
> >>>shared logical link
> >>>
> >>>private logical link
> >>>shared logical link
> >>>
> >>>Finally when we talk about LLID filtering in the RS we
> >>>
> >>>
> >>can
> >>
> >>
> >>>distinguish "positive filtering" (accept if LLID
> matched)
> >>>vs. "negative filtering" (accept if not matched).
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>The RS has no mechanism to differentiate packets from
> a
> >>>>single MAC in order to apply different values of the
> >>>>MODE bit to them.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>I don't think I can follow the logic why we should
> change
> >>>the mode bit for different packets coming from the same
> >>>
> >>>
> >>MAC.
> >>
> >>
> >>>I believe every MAC should be associated with one and
> >>>
> >>>
> >>only
> >>
> >>
> >>>one LLID (including the mode bit). This LLID can be
> >>>
> >>>
> >>either
> >>
> >>
> >>>unicast or multicast. But the mode remains the same for
> >>>
> >>>
> >>all
> >>
> >>
> >>>the packets sent by the MAC attached to it.
> >>>Is my understanding wrong?
> >>>
> >>>
> >>>Regards,
> >>>Glen
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>-----Original Message-----
> >>>>From: owner-stds-802-3-efm-p2mp@majordomo.ieee.org
> >>>>[mailto:owner-stds-802-3-efm-p2mp@majordomo.ieee.org]
> On
> >>>>Behalf Of ΓcY
> >>>>Sent: Thursday, April 24, 2003 6:55 PM
> >>>>To: stds-802-3-efm-p2mp@ieee.org
> >>>>Subject: Re: [EFM-P2MP] unicast/multicast MACs in
> Clause
> >>>>65
> >>>>
> >>>>
> >>>>Dear Mr.Brown,
> >>>>
> >>>>I have an idea for new name of "unicast MAC" and
> >>>>"multicast MAC".
> >>>>It is "point to point emulation MAC(P2PE MAC)" and
> >>>>"shared emulation
> >>>>MAC(SE MAC)".
> >>>>
> >>>>They seem to be familiar technical terms in this
> draft.
> >>>>I can submit a comment about this idea.
> >>>>
> >>>>Truly yours.
> >>>>
> >>>>===
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>If someone has ideas for new names, please respond to
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>this email
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>so we can get some agreement before the meeing. If
> you
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>want me
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>to submit the comment, please tell me or I'll expect
> >>>>>
> >>>>>
> >>that
> >>
> >>
> >>>>>
> >>>>>
> >>>>you will be
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>doing it.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>--
> >>-----------------------------------------
> >>Benjamin Brown
> >>178 Bear Hill Road
> >>Chichester, NH 03258
> >>603-491-0296 - Cell
> >>603-798-4115 - Fax
> >>benjamin.brown@ieee.org
> >>-----------------------------------------
> >>
> >>
> >>
> >
> >
> >
> >
> >
> >
>
> --
> -----------------------------------------
> Benjamin Brown
> 178 Bear Hill Road
> Chichester, NH 03258
> 603-491-0296 - Cell
> 603-798-4115 - Fax
> benjamin.brown@ieee.org
> -----------------------------------------