-----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.
[Anoop] I don't think the MAC should
override what the client provides in terms of ringlet selection. If
it can't send it on the ringlet specified by the client (due to a
protection event), then the MAC should just discard the packet.
If the client is intelligent enough to know which ringlet it wants to use,
it should also be aware of protection events. That way, if client
chooses to do ringlet selection, the burden of maintaining packet
ordering within a flow stays with the
client.
* 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.