| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
fyi ...
Find below a file refernce provided by Norm Finn (member of 802.1 group), hi-liting some RPR Bridging issues.
The RPRWG-BAH team will be analyzing these issues.
Marc.
-----Original Message-----
From: Tony Jeffree [mailto:tony@xxxxxxxxxxxxx]
Sent: Monday, March 18, 2002 10:14 AM
To: stds-802-1@xxxxxxxx
Subject: Files related to EFM & RPR Bridging issues
I have posted the following files on the website:
http://www.ieee802.org/1/mirror/8021/docs2002/steering-issues.pdf
This is a short paper by Norm Finn looking at the potential problems with
"steering" in RPR. Please let Norm know if you have any
comments/additional observations.
and:
http://www.ieee802.org/1/mirror/8021/docs2002/Bridging%20&%20Broadcast%20Scenarios.ppt
This is a set of slides by Carlos Ribeiro (carlosal@xxxxxxxxxxxxxxxxxx)
regarding potential ways of addressing Bridging in conjunction with "single
copy broadcast" in EPONs. If you have any feedback with regard to these
slides, I suggest that you also copy it to the EFM point-to-multipoint
exploder (stds-802-3-efm-p2mp@xxxxxxxx), which was where Carlos originally
posted this. I have attached a copy of the text of Carlos's Email below.
Regards,
Tony
----------------------------------------
Frank,
I've been talking to Dolors about some possible simplifications of the P2MP
broadcast emulation, aiming to support "single copy broadcast" and full
bridging compliance. I've prepared a presentation about it, that is
attached to this message. It's open to comments and discussion, as it is
not thoroughly checked yet.
The main point is that we're not comfortable with the requirement to have a
router to use the 'shared emulation' port, because of bridging limitations.
This assumes that the only application for single-copy-broadcast
applications will be IP-multicast based, which is a very good idea in
itself, but should not be absolutely required by a 802.3-based network. In
our vision, it is possible to implement single-copy-broadcast, requiring
only small modifications to the ONU behavior to keep it fully compliant
with 802.1D.
1. Assume that all ONUs and the OLT implement standard 802.1D bridging.
2. All units connected to the EPON will negotiate 802.1D. The logical
topology is a star, where the OLT is at the center.
3. The logical link between any given ONU and the OLT will have two
possible states: 'UP' or 'DISABLED', depending on the outcome of the STP
renegotiation. An ONU can be said to be 'UP' if, after 802.1D negotiation,
it's link to the OLT is still enabled.
4. Two types of frame can be sent by the OLT downstream: unicast and
multi/broadcast frames. Unicast frames are always associated with a unique
ONU, and will only be sent if the logical link is 'UP'.
5. Broadcast frames are sent downstream using single-copy-broadcast. All
ONUs can listen to the frame, with a single exception: if the logical link
between the ONU and the OLT is 'DISABLED', then the broadcast frame will be
discarded.
6. On the upstream, all frames - including broadcast - are sent using the
P2PE link. Of course, this requires the logical link to be up, which
guarantees compliance with the spanning tree topology.
The assumptions above guarantee that the P2PE framework will be compliant
with 802.1D, and also support single-copy-broadcast, and do not require any
of the 'Shared Emulation' stuff. Of course, I may be missing something
here; let us discuss it to see if every case is covered.
Carlos Ribeiro
CTBC Telecom