| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
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]
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]
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]
> 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".
========================================================