Re: [EFM-P2MP] unicast/multicast MACs in Clause 65
Glen,
Thanks. Please submit a comment for this.
Ben
Glen Kramer wrote:
>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
>>-----------------------------------------
>>
>>
>
>
>
>
>
>
--
-----------------------------------------
Benjamin Brown
178 Bear Hill Road
Chichester, NH 03258
603-491-0296 - Cell
603-798-4115 - Fax
benjamin.brown@ieee.org
-----------------------------------------