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



There you are! How the heck are you guys back at Nortel? When did you start
into the EFM stuff? I haven't seen you yet at a meeting (co-located with
10GE, which I'm an editor of).

Catch you later! 


-----Original Message-----
From: Bill Crick
To: 'Horne, David M'; 'Angeloni Cesare, IT'; '';
Sent: 11/23/01 7:59 AM
Subject: [EFM] RE: EDMA R-PON

How much time do you lose between when one end station stops
transmitting and the next to transmit detects 
this fact if they are max time of flight apart? 
assume a splitter 5km from Head end, T1, and T2. 
T1 stops. 10km later T2 detects this, and another 
10km of dark fiber until T2's signal gets to the head end. 
However in this case the head end only sees 10km worth of darkness 
Move the splitter closer to the head end and it gets worse? 

Pathological case is :Splitter at the head end, T1, T2 10 km each. 
Head End sees 20km worth of darkness which is the round trip time from
splitter to T2 

However if the splitters are close to the endstations, and far from the
HE, then its not too bad. 

Bill Crick 
Nortel Networks 

-----Original Message----- 
From: Horne, David M [ mailto:david.m.horne@xxxxxxxxx
<mailto:david.m.horne@xxxxxxxxx> ] 
Sent: Friday, November 23, 2001 1:37 AM 
To: 'Angeloni Cesare, IT'; ''; 
Subject: [EFM] RE: [EFM-P2MP] Point-to-Point plus Shared Media 

Cesare, what I had in mind would be contention-free/collision-free, yet 
simple to implement. It would be CSMA-like, but no CD (collision detect)
needed. In other words, it wouldn't be a transmit free-for-all. There
to be a predictable, bounded transmit scheme and some level of 
prioritization in order to accommodate quality of service requirements
the streams that pass through the EFM realm. 

Instead of being time-synchronized and filling pre-assigned time slots
on a precise time base, a la TDMA or DAMA, it would be
The event being the "end-of-transmit" for a given end station.
there is no requirement for a separate ranging protocol, or periodic 
re-ranging either. I can think of a couple ways ranging could be done 
though, if there was a reason for it. 

Unlike a pure LAN, there would be a master (e.g. the headend) that 
orchestrates the simple event-based transmit scheme. The headend sends a

single control message downstream (broadcast to all stations since 1:N)
this purpose. In its simplest form, this message (e.g. for a 16:1 PON)
1) the transmit sequence for a transmit round (for example, say there
only 5 subscribers on this PON: 
station #1, then #2, then #5, then #14, then #16; repeat) and 

2) the maximum transmit size per station (for example, 10 Ethernet
frames of 
any size up to max, or, some max number of bytes without fragmenting

Once this control message is received, the stations begin transmitting,
sequence, based on the rules in the control message. These same rules
apply for seconds, minutes, hours, or days. It could potentially be days

before the headend sends a new transmit control message, since the
just cycle through the last set of rules sent. Very simple operation
little protocol overhead, and bounded cycle time. It is uniformly fair
all stations in the most basic form, but has the flexibility to allocate

bandwidth asymmetrically, and dynamically, if desired. 

All stations know their position in the transmit sequence for a given
so they know when it is about to be their turn. The "end-of-transmit"
from the prior station is the signaling mechanism. There are a number of

ways this could be implemented. At a high level it is similar to a
transmitting into an allocated time slot that the station is responsible
hitting accurately (as in TDMA), except in this case there is no 
time-base-dependence. It just detects events in this case, and reacts 
accordingly. This will only work with a reflective splitter/combiner,
and is 
really only practical in an optical P2MP network. 

There are lots of other operational details, and many possible ways to
them, but this is the essence of the operation. The basic idea needs to
clear first, before going into those details. It has great flexibility
the way the transmit rounds are defined by the headend. Only the most
is described above. So there is great latitude for vendor-specific 
value-adds. OAM could just be a control message type that drops right in
the overall scheme. 

So in summary, it is much lower complexity (both design and
and has higher bandwidth efficiency, than a TDMA PON. Efficiency-wise, 
compared to fixed-slot TDMA, this has variable and dynamically-adaptive 
transmit opportunities; compared to dynamic request/grant TDMA, there is
processing/scheduling delay for requests/grants at the headend, and no 
round-trip transit time delay due to the distribution fiber from headend

Any comments welcome. 

PS: How about I give it a name for discussion purposes: EDMA R-PON 
(Event-Driven-Multiple-Access Reflective PON) 

--Dave Horne 

-----Original Message----- 
From: Angeloni Cesare, IT [ mailto:cesare.angeloni@xxxxxxxxxxx
<mailto:cesare.angeloni@xxxxxxxxxxx> ] 
Sent: Thursday, November 22, 2001 2:01 AM 
To: 'Horne, David M'; '' 
Subject: RE: [EFM-P2MP] Point-to-Point plus Shared Media 

Horne, good point about reflection. 

Reflection is not the only way to implement a "true" Ethernet like PON.
matter of fact other start topology might meet cost target in a even
way. See the old 10BaseFP standard. 
The problem is the distance and the speed. 
For the Collisions to be detected there have to be only a # of Bytes out
the optical path not returned to the Carrier Sense of connected ONUs.
and the bit rate limits the distance to a great extent. 
TDMA allows for a point to point protocol such as the GE to share a
I'm sure you have in mind a way to solve this shortcoming. 

I'm puzzled. 
Let me know more. 


> -----Original Message----- 
> From: Horne, David M [SMTP:david.m.horne@xxxxxxxxx] 
> Sent: Wednesday 21 November 2001 17:27 
> To:   'John Pickens';; 
> Subject:      RE: [EFM-P2MP] Point-to-Point plus Shared Media 
> John, have you given any thought to the use of *reflective* 
> splitter/combiners, as opposed to the transmissive variety that is
> assumed for TDMA PON? It would be much more LAN-like; i.e. more true
> Ethernet operation. 
> In addition, the reflective splitter/combiner (tree coupler) would be 
> roughly half the cost of a transmissive coupler, since it has half as
> 2x2 sections, with essentially the same loss. 
> Silicon costs and development time would also be much lower, since the

> multiple access design complexity would be far lower (as would the 
> operational complexity of the overall network). The need for TDMA 
> complexity 
> essentially disappears, since the reflected signal serves essentially
> role of CSMA in traditional Ethernet. Variable-size frames could be 
> transmitted without any explicit size reservation, and without any of
> waste associated with fixed slot size.  
> As well, because there would be no request/grant protocol or 2-way 
> transit-time-delay wait time of the distribution fiber, transmission 
> efficiency is higher.  About 8 full-sized Ethernet frames of
> capacity can be recovered (between any 2 user transmissions) from the 
> 2-way 
> transit time of a 10km distribution fiber. This recovered capacity per

> user 
> is on par with the *allocated* capacity per user, for TDMA with fixed 
> slots 
> size that was being discussed.  Not to mention no need for the
> and scheduling delay for the request/grant at the headend, which
> even more of the capacity that is lost to the TDMA protocol overhead. 
> Overall, the idea is that changing out one passive component in the 
> outside 
> plant for another lower-cost passive component with the same signal
> would allow a high degree of simplification in the design and
operation of 
> PON, and an improvement in transmission efficiency. It would also be
> consistent with traditional Ethernet. 
> --dave horne 
> -----Original Message----- 
> From: John Pickens [ mailto:jpickens@xxxxxxxxx
<mailto:jpickens@xxxxxxxxx> ] 
> Sent: Tuesday, November 20, 2001 10:49 AM 
> To: Norman Finn;;

> Subject: Re: [EFM-P2MP] Point-to-Point plus Shared Media 
> Good clarification. 
> I would like to study one additional question related to this topic. 
> How can an operator offer the benefits (in the EPON link segment) of
> point to point AND point to multipoint to a single endpoint beyond the
> (e.g. personal computer concurrently a. viewing a 20Mbps HDTV video
and b. 
> engaging in a 400Kbps point to point instant messenger video/audio 
> session) 
> and also maintain the link efficiencies gained by point to point. 
> It is certainly possible to maintain separate networks to the end
point - 
> separate MAC in ONU, separate 100BT port in the ONU, separate ethernet

> LANs, and separate NICs in the personal computer (even better,
> personal computers).  What is less clear is how to converge the
networks - 
> and configure the networks (PC, LAN, ONU, OLT) so that the "right"
> traverses the "right" path (instant messenger traverses point to
> HDTV traverses shared media). 
> It is also possible to limit the options here and say that an ONU can
> either shared only or point to point only.  And to say that if 
> single-copy-broadcast attribute of the media needs to be accessed,
that it 
> is acceptable to operate in shared mode (up to 50% reduction in link 
> capacity if all ONUs require single-copy-broadcast). 
> I know there is a contingent within the working group that does not 
> consider it a requirement to access the single-copy-broadcast
attribute of 
> the media, so probably we should poll this question at some point. 
> J 
> At 11:58 AM 11/14/2001 -0800, Norman Finn wrote: 
> >To clarify my comments at the 802.3 EFM EPON meeting on November 14
> Austin: 
> > 
> > 
> >  1. Assume an EPON with an OLT and n ONUs. 
> > 
> >  2. In the simplest case, the OLT has n+1 logical MACs.  n of them
> point- 
> >     to-point MACs, and one of them is a shared medium MAC.  Each ONU
> 2 
> >     logical MACs.  One of them is a shared medium MAC, and one is a 
> point-to- 
> >     point MAC.  All of the ONU's shared medium MACs are on the same 
> emulated 
> >     shared medium as the OLT's shared media MAC.  The other n ONU
> form 
> >     point-to-point connections with the corresponding n OLT 
> point-to-point 
> >     MACs. 
> > 
> >  2. In more advanced configurations, an ONU may have more than one 
> point-to- 
> >     point logical MAC, which means that the OLT must have a 
> corresponding 
> >     number of point-to-point logical MACs.  There may be more than
> >     emulated shared media, each additional emulated shared medium 
> requiring 
> >     a logical MAC on each participant, OLT or ONU.  One may even
> >     emulated point-to-point or shared media which connect ONUs only,

> >     without a corresponding OLT logical MAC.  It all depends on how
> >     the committee wishes to take the ID/tag fields required to
> >     the various features. 
> > 
> > 
> >  3. In order to emulate a shared medium, (or a point-to-point medium

> >     between two ONU logical MACs), the OLT must reflect frames sent
> >     ONUs back downstream, so that the other ONUs can see them.  No
> >     reflection is needed for point-to-point ONU-OLT links.  If a
> >     is reflected back to the ONU that transmitted it, the ONU
> >     must discard that frame in order to maintain compatibility with 
> >     existing 802.3 devices, including routers, bridges, and end 
> stations. 
> > 
> >  4. In the absence additional higher-level protocols, beyond the
> >     802.1 bridging protocols, there is not enough information in an 
> >     Ethernet frame for an OLT or ONU to make filtering decisions
> will 
> >     both 1) filter unwanted data frames from the EPON stream, and 2)

> pass 
> >     data frames necessary for proper operation of a bridged network.

> This 
> >     is true for both shared media emulation and point-to-point 
> emulation. 
> > 
> >  5. In order to remedy this difficulty, one may use protocols above
> >     MAC layer.  Such higher layer protocols would allow bridges or
> >     devices to share information about their MAC address databases. 
> >     Such protocols would be extremely difficult to implement, and
> >     be likely to introduce significant delays in the delivery of
> >     Furthermore, no existing standard 802.1 bridge would work on an
> >     EFM link without such protocol augmentation. 
> > 
> >  6. Tags carried below the MAC layer solve the problem, as discussed

> >     by several presenters.  In their simplest form, a tag on 
> >     a point-to-point frame identifies the logical MAC which is to 
> >     receive the frame, and a tag on a shared media frame identifies 
> >     which logical MAC generated the frame, so that that logical MAC 
> >     can discard the frame if or when it receives it, again. 
> > 
> > 
> >If one implements the n+1 (OLT) + 2n (ONUs) logical PHY approach,
> >one gets: 
> > 
> >  a. The ability to do point-to-point communications without
> >     any extraneous waste of bandwidth. 
> > 
> >  b. The ability to do point-to-multipoint transmissions (on the
> >     media) without waste of bandwidth. 
> > 
> >  c. The ability to connect *existing* bridges with either point-to- 
> >     point or shared media -- or both. 
> > 
> >  d. Complete compatibility and interoperability with 802.1 and other

> >     802.3 media, and interoperability with all existing 802.1 and .3

> >     compatible devices, including hubs, bridges, routers, and end 
> >     stations. 
> > 
> >Additional complexity in the definition and use of the tags buys 
> >further flexibility in the point-to-point vs. shared media.  It is 
> >for further study to determine the best balance between complexity 
> >and flexibility. 
> > 
> >-- Norm Finn 

This message and its attachments (if any) may contain confidential, 
proprietary or legally privileged information and is intended only for 
the use of the addressee named above. No confidentiality or privilege 
is waived or lost by any mistransmission. 

If you are not the intended recipient of this message you are hereby 
notified that you must not use, disseminate, copy it in any form or take

any action in reliance on it. If you have received this message in error

please delete it and any copies of it and kindly inform the sender of
e-mail by replying or go to on "contact us".