-----Original Message-----
From:
Holness, Marc [CAR:OM3H:EXCH]
Sent: Wednesday, March
20, 2002 9:10 AM
To: dot17
Subject: [RPRWG] 802.17 MAC Ring Selection Mechanism
Good day.
Some initial discussions during the BAH team meeting have
hi-lited the need for us to specify a Ring Selection mechanism. Proper
802.17 Client behavior and Network behavior is dependent on this.
========
Consider the following (high level) proposal:
* Firstly, the Ring Selection mechanism cannot change
dynamically due to reception of packets.
[Anoop] I think you
mean "...due to packet reordering that may occur when
changing the ringlet selection
dynamically."
* 802.17 Client (Bridge Relay, Host, Router, Server, etc)
indicates request to transmit a packet on the Ring, by dispatching a
DATA.Request primitive to the 802.17 MAC (or MAC Control sublayer).
* In general, the 802.17 MAC using the Topology Image DB
will choose the correct Ringlet to dispatch on using shortest path (smallest
hop count metrics).
I think there should be flexability here.
Client should have a choice of explicitly stating the direction on the
perhaps on available bandwidth usage in each ringlet. Now it is up to
client to decide to switch the ring direction if bw metrix changes. It
depends if client is sensitive to packet reordering. If MAC chooses a
direction it should be based on the cost metrix like hop length as surrent
bw usage is a transient state.
* If the DA found in the DATA.Request primitive is found in
the Topology Image DB, then packet gets dispatched over Ringlet with
shortest path metrics.
* If the DA found in the DATA.Request primitive is NOT found
in the Topology Image DB (usually the case when the DA is not found on the
local Ring), then the MAC needs to do one of the following:
1) Flood the
packet over the Ring. The exact flooding technique has not been agreed upon
yet. Two mechanisms to date have been discussed: (i) Use the TTL to scope
the travel of the packet, and dispatch over both Ringlets. TTL is set to
ensure that Stations on the Ring do not get multiple copies of the packet;
(ii) Dispatch a single copy of the packet over one of the Ringlet, and use
source stripping to remove the packet from the Ring. This particular
technique may have some 802.17 Frame structure impacts.
[Anoop] There's
also option (iii) which is to dispatch a single copy of the packet over
one ringlet and use TTL stripping/scoping to remove the packet from the
ring.
2) Index into
some sort of DB (e.g., StationDB) that associated RPR Station MAC address
with unknow/off-Ring MAC addresses (and corresponding VLAN). If an RPR
Station MAC address is found in the DB, then this address is used to
encapsulate the packet prior to dispatch. NOTE: Procedures are need to
de-encapsulate the packet before it gets dispatched outside of the 802.17
LAN segment. If the DB does not have an DA entry, then flooding would occur
(refer to item #1 above).
Further analysis
is required. The BAH team will be looking into this.
Some 802.17 Clients may have the ability to indicate things
like Ringlet_Id and even RPR Header values. An 802.1D/Q Relay Entity
(Client) does not have these parameters defined in the Request primitive
parameter list. Consequently, a 802.1D/Q defined Bridge Relay Entity will
not specify Ringlet_Id nor RPR Header information. It will be up to the
802.17 MAC to do Ringlet selection in this case. NOTE: There is the
possibility that the ISS (Internal Sublay Service) provided by the 802.17
MAC to the Bridge Relay Entity may do some sort of Ringlet
Selection.
[Anoop] The problem with leaving the
entire job of ringlet selection to the MAC are
two-fold. (i) It's no longer
possible for clients to load-balance traffic by sending traffic both
ways around the ring. (ii) If the client doesn't know which
ringlet the traffic is going to use, then how does it do
its shaping/policing?
========
Bottom Line: The exact mechanism needs to be hashed out and
agreed upon. This is not exclusively an issue to Bridging. This is really a
802.17 MAC Client to 802.17 MAC (Ring Selection) behavior that needs to be
explicitly specified.
What should the 802.17 MAC do when the DA (or SA) found in
the Request primitive is NOT found in the Topology Image DB?
Comments?
Marc.