Re: [RPRWG] Concerns about 802.17b ideas.
Hi Mike,
Mike Takefman wrote:
> Wang, I am sorry but I'm confused as to whether A is SAS capable or not.
> Also, you make a statement that the SAS compatibility check
> did not apply. I don't understand why you are making that assumption.
In scenario B, A is SAS un-aware. I'm sorry for unclear description.
The purpose I made the assumption that SAS compatibility check did not apply is to question what's the reason for compatibility check.
My reasoning logic is:
-- Provided that the compatibility check is to avoid persistent flooding, so if we do not use compatibility check, persistent flooding will occur.
-- Then I tried to find which cases will be thought as persistent flooding and found scenarioB.3 and scenarioB.4.
-- I originally thought both scenarioB.3 and scenarioB.4 should be treat as persistent flooding, but also found scenarioB.3 case will occur too even between to SAS aware bridges.
-- So I brought out my questions: what is the real defination of persistent flooding? and how to improve scenarioA.3 anb scenarioB.3 problem?
From your mail, I'm clear now. ScenarioA.3 and ScenrioB.3 are not persistent flooding.
Thanks very much.
Wang.
-----Original Message-----
From: Mike Takefman [mailto:tak@cisco.com]
Sent: 2005年1月12日 0:03
To: Wang Chao (SW)
Cc: STDS-802-17@LISTSERV.IEEE.ORG
Subject: Re: [RPRWG] Concerns about 802.17b ideas.
Wang,
Wang Chao (SW) wrote:
> Hi Robert and Holness,
>
> Thanks for your patient explanation.
>
> Anyway, I want futher explain my original point. let's
> consider following scenarios:
> [Scenario A]
> Five SAS aware RPR station attached bridges A, B, C, D, E on a RPR ring.
> The following secquence of traffic applies:
> 1. A send un-direct frame dest to B by RPR flooding.Then A's MAC address
> is learnt by all bridges(B,C,D,E)
> 2. Then B send direct frame to A by RPR unicast. B's MAC address is
> learnt by A, but not by C,D,E.
> 3. Then when C, D, E send frames dest to B, they always using un-direct
> mode. When these frames travel by C, D, E, the are always foolding to
> the attached 802.3 network.I originally think this is also a persistent
> flooding caused by B never sending frames dest to C, D, E.
>
You are correct that the first time C, D, E send to B they will
flood, and then B will uni-cast back to them and learning
completes. So the flooding is not really persistent, as the
learning will occur as conversations occur.
The cost of making this learning happen immediately would
be for B to broadcast the *first* response to A. This requires
an additional update operation to the SAS FDB that occurs as
part of the DA lookup (within the output datapath in the SAS
layer in the MAC).
One of the goals for SAS is to keep the operation of the SAS
FDB similar to 802.1D/Q. Currently, bridges don't do any updates
based on the DA lookup, only as part of the SA learn.
Given the fact that the flooding is self-limiting, I don't see
the need to deviate from standard bridge operation.
> [Scenario B]
> SAS bridge A attached to SAS unaware station, bridges B, C, D,
> E attached to four SAS aware stations, they attached to one RPR ring.
> The following secquence of traffic applies:
> 1. A send un-direct frame dest to B by RPR flooding.Then A's MAC address
> is learnt by all bridges(B,C,D,E)(supposed SAS compatiable check not apply)
> 2. B send direct frame to A by RPR unicast. B's MAC address is learned
> by A, but not by C,D,E.
> 3. Then when C, D, E send frames dest to B, they always using un-direct
> mode. When these frames travel by C, D, E, the are always flooding to
> the attached 802.3 network.
> 4. When A send frames dest to B again, it always use flooding because it
> is SAS un-aware, even A is learnt by B, causing persistent flooding on
> C, D, E attached 802.3 network.
>
Wang, I am sorry but I'm confused as to whether A is SAS capable or not.
Also, you make a statement that the SAS compatibility check
did not apply. I don't understand why you are making that assumption.
Right now if a non-SAS station in on the ring, SAS stations will not
send directed transmissions to it.
The group has discussed the idea of asymmetric SAS, i.e. SAS does direct
unicast traffic to non-SAS stations, and one could probably make it work
but at a cost and it is not clear for what value.
> The ScenarioA.3 and ScenrioB.3 are the same phenomenon no matter A is
> attached to a SAS aware or un-aware station So I think maybe these is
> not considered to be a persistent flooding. Only ScenrioB.4 is
> considered to be a real persistent flooding which is the reason of SAS
> compatiable check rules in 802.17b draft. Am I right?
>
> My point is,
> 1. Persistent flooding definition should made clear.
> 2. If ScenarioA.3 and ScenrioB.3's flooding can be improved by some
> special extentension to 802.17b, such as proposal in
> http://www.ieee802.org/17/documents/presentations/oct2004/ng_SR_01.pdf
> page 4, 802.17b maybe more useful.
>
These extensions have been discussed in the context of optional capability.
cheers,
mike
>
> Best Regards,
>
> Chao Wang
>
>
> -----Original Message-----
> *From:* owner-stds-802-17@LISTSERV.IEEE.ORG
> [mailto:owner-stds-802-17@LISTSERV.IEEE.ORG]*On Behalf Of *Marc Holness
> *Sent:* 2005年1月11日 7:45
> *To:* STDS-802-17@LISTSERV.IEEE.ORG
> *Subject:* Re: [RPRWG] Concerns about 802.17b ideas.
>
>
> 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
>
> -----Original Message-----
> *From:* Castellano, Robert [mailto:RCastellano@c-cor.net]
> *Sent:* 2005年1月6日 1:56
> *To:* Wang Chao (SW); STDS-802-17@listserv.ieee.org
> *Subject:* RE: [RPRWG] Concerns about 802.17b ideas.
>
> 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
>
--
Michael Takefman tak@cisco.com
Distinguished Engineer, Cisco Systems
Chair IEEE 802.17 Stds WG
3000 Innovation Dr, Ottawa, Canada, K2K 3E8
voice: 613-254-3399 cell:613-220-6991