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
-----------------------------------------