Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

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