| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi Wang,
It's important to note that when doing bridging over RPR, the bridge relay function sits above the RPR MAC. The RPR MAC is essentially a three-port device having two ring ports and client port. The bridge sits above the client port. The RPR MAC does not function as a bridge. It uses some fairly simple rules to determine when to copy a frame to its client port, and when to strip a frame. It also uses a flooding indicator to control when frames are to be stripped from the ring.
The persistent flooding issue refers to a condition where the bridge relay sitting above the 802.17 MAC has incomplete learning information in its FIB due to asymetric transmissions on the ring. This results in frames which should have remained on the ring, being flooded across all associated layer-2 networks. 802.17 addresses this issue by preserving symmetry by ensuring that bridge traffic is always flooded on the ring. This enables all bridges attached to the RPR ring to properly learn which MAC addresses are on the ring port side of the bridge and which MAC addresses are on the other ports of the bridge. Using the scenario depicted in http://www.ieee802.org/17/documents/presentations/nov2004/rc_SASehb_01.pdf page 3 as a reference, a couple examples should help clarify the issue and how it is addressed in 802.17b
If we look at the reference network in an 802.17 (non-SAS) scenario, stations 6 is an 802.17 bridge and station 1 is an 802.17 host. If host-X sends to host-1, station 6 will flood X traffic on the entire ring so it is received by all other stations on the ring (since station 6 is an 802.17 station). Any other bridges on the ring learn that station-X can be reached through the ring. In 802.17, we specify that if a host is sending a frame to an offring host, the frame must also be flooded on the ring. When host-1 sends to host-x it also floods to all stations on the ring. This ensures that host-1 is also learned by intermediate bridges to be associated with the ring. This is really important. Since host-1 is learned in the intermediate bridge tables, any traffic sent to host-1 on the RPR will be dropped by all the intermediate bridges. If host-1 is not learned in the intermediate bridge table, then any frames destined to host-1 must be flooded to all other ports on the bridge. If host-1 were to send a directed frame to 6, while 6 floods frames intended for 1, then host-1 would never be learned resulting in the persistent flooding condition.
802.17 also allows local hosts on the ring to send directed frames to each other. These frames are passed across the ring by the RPR MACs. Bridge clients associated with intermediate RPR stations never see these frames or learn these addresses. The reason for this is again related to symmetry. We found scenarios where if A sends to B in a clockwise direction, and B sends to A in a clockwise direction, then the intermediate bridges on the A to B path never learn B, and bridges on the B to A path never learn A, resulting in more persistent flooding. We decided it was actually simpler and better for bridges to not see any of the directed traffic between other stations on the ring.
The rules in 802.17 were established such that persistent flooding will not occur as long as symmetry is maintained.
802.17b preserves this symmetry by having a Spatial Aware Sublayer within the 802.17b MAC which interfaces to the bridge relay. The SAS layer is able to learn and distinguish between frames coming from SAS aware stations (802.17b) and SAS unaware stations (802.17). SAS maintains its own MAC address database (SDB) such that if SAS sees a frame with a MAC address coming from a SAS station it learns it. Frames with MAC addresses from SAS unaware stations aren't learned. During transmission the SAS sends directed frames which are in the SDB, and floods the frame if it is not in the SDB. This makes sense because frames which are not in the SDB need to be flooded on the ring anyway. By controlling which frames are learned in the SDB during reception is one method for maintaining symmetry. As long as the flooding or directed frames are symmetrical between the two stations which are sending to each other, persistent flooding is avoided.
I hope this helps.
robert
> -----Original Message-----
> From: Wang Chao (SW) [mailto:chwang@PHOTONICBRIDGES.COM]
> Sent: Wednesday, January 05, 2005 4:27 AM
> To: STDS-802-17@listserv.ieee.org
> Subject: [RPRWG] Concerns about 802.17b ideas.
>
>
> Hi all,
>
> I have read the recent 802.17 group meeting presentations
> about 802.17b.
>
> Here I bring out two concerns.
> (1) How dos SAS layer solve the persistent flooding at
> bridged 802.3 network problem, which is specified by
> 802.17-2004 standard's annex F.1.4.2.1?
> The recent presentations seemed not care about it,
> except for
> http://www.ieee802.org/17/documents/presentations/oct2004/ng_S
R_01.pdf page 4. I think the incomplete learning issue is the same as persistent flooding issue.
(2) Why SAS aware station can not do SAB update(learning) for remote frames sent by non-SAS station?
Alough http://www.ieee802.org/17/documents/presentations/nov2004/rc_SASehb_01.pdf page 3 gave an example for why, but I think this example is not convincing.
Because the persistent flooding is also exist when do learning between two SAS aware stations.
Would any experts be kind to make clear explaination about these two issues?
Best Regards,
Chao Wang
Photonic Bridges.
86-21-61101124