| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Chao.
Just back from the holidays ...
A bit of context is in order.
SAS (Spatially Aware Sublayer) is a sublayer of the RPR (802.17) MAC. It is not a (bridge) client of the MAC. SAS (amongst other things) will improve the spatial awareness (i.e., improve the bandwidth utilization) of traffic of the RPR media when bridge clients (as defined by IEEE 802.1) are involved.
Persistent flooding that may occur in a bridged network is an artifact of (IEEE 802.1) Bridge clients behavior/operation. Consequently, the issue of persistent flooding and SAS is a bit orthogonal.
That being said, the 802.17-2004 specifications attempted to deal with the potential persistent flooding issues. The RPR MAC will essentially flood frames being transmitted by a Bridged client over the RPR media in order to mitigate the resulting persistent flooding within the bridged network containing RPR. The obvious side-effect of this solution is that the bandwidth utilization over the RPR media is impacted in order to preserve the integrity of the network (by eliminating the potential persistent network flooding). What SAS will do is address the persistent flooding over the RPR media.
To re-iterate, there are two things to
consider:
1) Persistent flooding within a bridged
network (containing RPR), and
2) Persistent
flooding over the RPR media.
The 802.17-2004 specifications address the first issue. The SAS will address the second issue while maintaining the solution for the first issue.
Regarding your second point ...
The package that you referenced is one of the options currently being considered. The three options being considered are summarized by: http://www.ieee802.org/17/documents/presentations/nov2004/MH_SAS_interworking_options_01.pdf
The groups current position is that when SAS capable RPR MACs interact with non-SAS capable RPR MACs, the functional behavior will degenerate to no spatial aware improvements.
Persistent flooding over the RPR media does NOT occur when two SAS capable RPR MACs are involved in frame transmissions and receptions for a given session. A flood over the RPR media (i.e., undirected Tx) does occur for the first transmission, however once the RPR MAC "proxy" providing an attachment interface to the end client address is learnt, directed transmissions (i.e., unicast transmissions) over the RPR media will persistently occur. Consequently, persistent flooding over the RPR media does not exist between two SAS capable RPR stations.
In general, I think we need to clearly delineate the persistent flooding issues. One is over the RPR media, and the other is within a bridged network containing RPR. SAS addresses the former issue, while the 802.17-2004 MAC addresses the latter.
Marc Holness
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