----- Original Message -----
Sent: Wednesday, March 20, 2002 3:07
PM
Subject: RE: [RPRWG] 802.17 MAC Ring
Selection Mechanism
Re-Send. Problems with my E-mail.
-----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.
jl: General Comment 1: Please correct every
occurence of "Ring Selection" with "Ringlet Selection".
jl: General Comment 2: As I've argued before the WG, I believe strongly
that we need to allow the client to do ringlet selection (overriding only if
an impossible choice is made), and provide a default ringlet selection for
those clients unable or unwilling to make a selection. I plan to create a
submission for such an interface and mechanism after some more important
actions have been completed by the WG. Some more specific comments
follow.
========
Consider the following (high level) proposal:
* Firstly, the Ring Selection mechanism cannot change
dynamically due to reception of packets.
jl: What is meant by this? It could change due
to reception of control packets indicating a protection event, a change in
link bandwidth availability, or a change in topology.
* 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).
jl: Firstly, this would be true only when the
client did not specify a ringlet selection. And, while I agree this would
likely be the default case when ringlet is unspecified, I don't know if we
want to force this, as some implementation could do something more
intelligent.
* 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.
jl: See above comment.
* 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.
jl: The only reason I can think of where you
would want to send in both directions is in a steering protection case.
Otherwise, I think a single ringlet should always be chosen.
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.
jl: Mostly agree. Not sure I agree that a client
can specify their own header values, except for a few select choices such as
DA, and ringlet.
========
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.