[EFM-P2MP] RE: [EFM] RE: EDMA R-PON
Bill:
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!
Dave
-----Original Message-----
From: Bill Crick
To: 'Horne, David M'; 'Angeloni Cesare, IT'; 'stds-802-3-efm-p2mp@ieee.org';
'stds-802-3-efm@ieee.org'
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'; 'stds-802-3-efm-p2mp@ieee.org';
'stds-802-3-efm@ieee.org'
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)
is
needed. In other words, it wouldn't be a transmit free-for-all. There
needs
to be a predictable, bounded transmit scheme and some level of
prioritization in order to accommodate quality of service requirements
for
the streams that pass through the EFM realm.
Instead of being time-synchronized and filling pre-assigned time slots
based
on a precise time base, a la TDMA or DAMA, it would be
event-synchronized.
The event being the "end-of-transmit" for a given end station.
Consequently,
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)
for
this purpose. In its simplest form, this message (e.g. for a 16:1 PON)
would
include:
1) the transmit sequence for a transmit round (for example, say there
are
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
frames)
Once this control message is received, the stations begin transmitting,
in
sequence, based on the rules in the control message. These same rules
could
apply for seconds, minutes, hours, or days. It could potentially be days
before the headend sends a new transmit control message, since the
stations
just cycle through the last set of rules sent. Very simple operation
with
little protocol overhead, and bounded cycle time. It is uniformly fair
to
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
round,
so they know when it is about to be their turn. The "end-of-transmit"
event
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
station
transmitting into an allocated time slot that the station is responsible
for
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
do
them, but this is the essence of the operation. The basic idea needs to
be
clear first, before going into those details. It has great flexibility
in
the way the transmit rounds are defined by the headend. Only the most
simple
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
to
the overall scheme.
So in summary, it is much lower complexity (both design and
operationally),
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
no
processing/scheduling delay for requests/grants at the headend, and no
round-trip transit time delay due to the distribution fiber from headend
to
splitter.
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'; 'stds-802-3-efm-p2mp@ieee.org'
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.
As
matter of fact other start topology might meet cost target in a even
better
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
on
the optical path not returned to the Carrier Sense of connected ONUs.
This
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
fiber
segment.
I'm sure you have in mind a way to solve this shortcoming.
I'm puzzled.
Let me know more.
Cesare
> -----Original Message-----
> From: Horne, David M [SMTP:david.m.horne@xxxxxxxxx]
> Sent: Wednesday 21 November 2001 17:27
> To: 'John Pickens'; stds-802-3-efm@ieee.org;
> stds-802-3-efm-p2mp@ieee.org
> 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
being
> assumed for TDMA PON? It would be much more LAN-like; i.e. more true
to
> 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
many
> 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
the
> role of CSMA in traditional Ethernet. Variable-size frames could be
> transmitted without any explicit size reservation, and without any of
the
> 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
additional
> 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
processing
> and scheduling delay for the request/grant at the headend, which
recovers
> 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
loss
> would allow a high degree of simplification in the design and
operation of
> PON, and an improvement in transmission efficiency. It would also be
more
> 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; stds-802-3-efm@ieee.org; stds-802-3-efm-p2mp@ieee.org
> 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
both
> point to point AND point to multipoint to a single endpoint beyond the
ONU
>
> (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,
separate
> personal computers). What is less clear is how to converge the
networks -
>
> and configure the networks (PC, LAN, ONU, OLT) so that the "right"
traffic
>
> traverses the "right" path (instant messenger traverses point to
point;
> HDTV traverses shared media).
>
> It is also possible to limit the options here and say that an ONU can
be
> 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
in
> Austin:
> >
> >ENDPOINTS: LOGICAL MACS AND MEDIA
> >
> > 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
are
> point-
> > to-point MACs, and one of them is a shared medium MAC. Each ONU
has
> 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
MACs
> 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
one
> > emulated shared media, each additional emulated shared medium
> requiring
> > a logical MAC on each participant, OLT or ONU. One may even
define
> > emulated point-to-point or shared media which connect ONUs only,
> > without a corresponding OLT logical MAC. It all depends on how
far
> > the committee wishes to take the ID/tag fields required to
implement
> > the various features.
> >
> >ACCOMPLISHING THE EMULATION:
> >
> > 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
by
> > ONUs back downstream, so that the other ONUs can see them. No
such
> > reflection is needed for point-to-point ONU-OLT links. If a
frame
> > is reflected back to the ONU that transmitted it, the ONU
absolutely
> > 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
current
> > 802.1 bridging protocols, there is not enough information in an
> > Ethernet frame for an OLT or ONU to make filtering decisions
that
> 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
the
> > MAC layer. Such higher layer protocols would allow bridges or
other
> > devices to share information about their MAC address databases.
> > Such protocols would be extremely difficult to implement, and
would
> > be likely to introduce significant delays in the delivery of
frames.
> > Furthermore, no existing standard 802.1 bridge would work on an
EPON
> > 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.
> >
> >NET RESULT:
> >
> >If one implements the n+1 (OLT) + 2n (ONUs) logical PHY approach,
then
> >one gets:
> >
> > a. The ability to do point-to-point communications without
incurring
> > any extraneous waste of bandwidth.
> >
> > b. The ability to do point-to-multipoint transmissions (on the
shared
> > 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
>
========================================================
CONFIDENTIALITY NOTICE
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
this
e-mail by replying or go to www.pirelli.com on "contact us".
========================================================