RE: [EFM-P2MP] Point-to-Point plus Shared Media
Thoughtful questions.
For the larger audience this is my summary of what was discussed in the
joint 802.1/802.3ah meeting. I think this summary is needed prior
to my responses in the text below. (Also, do we want to continue
this discussion in both email lists or contract to the p2mp
list?)
Three objectives/tradeoffs/issues (presented by MAN P2MP media) were
presented to the combined 802.3/802.1 group:
- maximizing link efficiency for unicast (mostly) traffic (upstream
offnet traffic is not reflected downstream)
- utilization of single-copy downstream broadcast mode (another link
efficiency parameter)
- offering of both attributes concurrently for traffic destined to/from
stations beyond the ONU (within the subscriber's extended
network)
The goal I presented was to meet all three objectives (though the 3rd was
as not strongly articulated until after the meeting).
After the presentation the following opinions were expressed from the
floor:
a. since it has been demonstrated that it is possible to achieve shared
media mode using root-reflection techniques, and since shared media meets
all 802 MAC layer requirements, shared media mode is
sufficient.
b. since it has been demonstrated that it is possible to achieve point to
point media mode using MAC/PHY layer tagging techniques, and since point
to point media meets all 802 MAC layer requirements, point to point media
mode is sufficient.
c. Using separate MACs in the leaf (ONU) it is possible to concurrently
implement the two modes as separate networks. It is a reasonable
requirement to partition the networks (details to be determined - see one
of my recent emails posted to the general P2MP exploder). Since a point
to point network meets the link efficiency requirement, and a shared
media network meets the single-copy broadcast requirement, sufficient
systemic functionality seems present in the current proposed mechanisms
(albeit requiring network segmentation).
d. not recommended to tackle this new P2MP media as a separate type of
media - rather recommend the media's physical layer behavior be
augmented/modified (don't care what detailed mechanisms are used) to
appear as one of the two well-known modalities - point-to-point or shared
- so as to not require modification of any upper layer services
(including .1D bridging).
Note: the consequence of this recommendation is that to fully (sic)
achieve the requirements above extra network segmentation is required -
i.e. the "traffic flows" that are benefiting from the
single-copy broadcast must flow over a separate logical network (separate
MAC on the P2MP link, and probably independent PLAN or VLAN on all other
links). This introduces complexity that needs to be
studied.
Note: 802.1 attendees expressed a strong opinion that the selective
filtering option (shared media with mechanisms to meet the link
efficiency requirement) is infeasible and is not scaleable (perhaps
leading to future 802.1 liason work with other P2MP working groups such
as 802.16 - outside the continuing scope of this dialog).
Note: there is a subset of the workgroup that considers it sufficient to
meet the link efficiency requirement for unicast, but does not consider
it a requirement to meet the single-copy downstream broadcast
requirement.
Therefore there seemed to be continuing interest in refining the dual
shared/point-to-point proposals which seem to deliver points a, b, and c
above.
Now some responses to your questions.
At 11:31 PM 11/25/2001 -0800, gerry.pesavento@xxxxxxxxxxxx wrote:
A few P2MP comments.............
> Emulation Sub-Layer and Protocol
No need to consider these "emulations". They are well
known modes which are well understood and accommodated in current 802
architecture.
The emulation sublayer using a logical PHY ID
approach allows for compatibility and interoperability with 802.1.
So far, so good... but there are several open questions:
- There are 2 emulation choices being
discussed: point-to-point P2PE and shared SE. Will one of
these be defined, or will both be defined so that the vendor decides on
whether to implement P2PE, SE, or P2P+SE. Example: one may choose
for business P2PE, for inter-campus - SE, for residential - P2P+SE.
I would propose both modes be defined in the layering, and it be a
configuration parameter which mode(s) is(are) active in a given layering
instance.
- Will
the emulation sub-layer be independent of the protocol layer? So
far it looks that way, that each layer will do its job without the other
one.
Not sure about this one. See below.
- Can P2MP Ethernet be deployed without the emulation sub-layer and
achieve multi-vendor compatibility, or will EPON require the PHY ID even
if it is not used?
No, this is an issue with the fundamental media itself and was the reason
for the presentation to 802.1. A raw P2MP ethernet is a broken
ethernet (leaf to leaf forwarding is broken). Plus there is no way
to determine to which leaf a frame is destined without resorting to
"bridging" tables.
-
If implementing both P2P+Shared emulation, the ONU has to have two
logical MACs. Does a 2-logical MAC ONU unduly increase the ONU
complexity?
I think not. It adds another logical "port" to upper
layer services. Plus probably it may not be required that all
implementations support dual mode (let it be a point of cost
differentiation). 802 standards say nothing about how many ports or
modes are implemented in real products.
But one man's "complexity" is another man's "basic
requirement", so I suspect this will be hotly debated. I
looked up "unduly" in my 802 glossary and could not find
it. :-)
- Without
the emulation sublayer, one can not have layer-2 ONU-to-ONU
communication, but one can do single frame broadcast and point to point
OLT-ONU communication using VLAN. Is this a tradeoff/decision (to
use, or not to use, the emulation layer) that the system implementer will
decide on?
VLAN suffers the same issues as MAC addresses. How does one
determine which ONU receives a frame. How does one determine the
VLAN membership of a frame? One could perhaps use VLAN tagging for
this media but to do it properly you would need to add a stacked VLAN tag
mechanism in which the inner tag is used by the media and stripped off
before being delivered to upper layers. Seems not
recommended.
- In
which layer below the MAC will this sub-layer occur?
I think immediately above the PHY (or in the PHY). The next level
of layering is very interesting. For the point to point mode in the
OLT a single PHY layer would present 64 (1:64 splitting) logical PHY
interfaces to 64 MAC instances. The shared mode would present a
65th interface (unless multiple shared networks were offered, such as one
might want for independent multicast groups, in which case there would be
more MAC instances).
I would appreciate hearing comments/opinions on
the above questions. So far the impression I have is that most are
proposing that both P2PE and SE be defined in a below-MAC sublayer, they
operate independent of the P2MP control-frame protocol, with
implementation decided by the vendor. Do I have that
right....
I think so. Though the timings and latencies of the MAN might
complicate things a bit (just instinct).
As a reminder, if you want to get involved in
the group Protocol/Emulation framework details, please contact one of the
leads below who are coordinating conference calls, etc..
Protocol Framework
Ryan Hirth:
RHirth@xxxxxxxxxxxx
Ajay Gummalla:
ajay@xxxxxxxxxxxx
Onn Haran:
onn.haran@xxxxxxxxxxx
Emulation Framework
Hiroshi Suzuki:
hsuzuki@xxxxxxxxx
John Pickens:
jpickens@xxxxxxxxx
Some of the initial draft work is being done
off the reflector.... I will do my best to encourage these
drafts/discussions to be posted on the P2MP reflector, as these are
the two paramount topics for P2MP track... but not getting enough air
time on the P2MP reflector.
> Cost of deploying fiber
Ron: Where you got your $/ft fiber
deployment cost numbers? The reason I am asking is they look very
different from what was presented in July:
http://www.ieee802.org/3/efm/public/jul01/presentations/shaneman_1_0701.pdf
(I like your numbers better;).
> Requirements (Roy wrote):
> I think that the "service
providers" need to get together and make
> a presentation at the next meeting that would include the
"services"
> and the functional requirements of those
"services".
You would think that after a year we would have that figured out, but we
probably don't - I think everyone would welcome more service provider
presentations. Also, I would encourage you to give input to the
"Requirements III" presentation that Dolors
(dolors@xxxxxxxxxxxx) is
leading. This is a clean-up of the first two group Requirements
presentations from the previous two meetings, and it covers (to an
extent) functional requirements. Thanks.
_________________________
Gerry Pesavento
_________________________