----- 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.
[LM] The ringlet selection should not
change except topology change due to protection by the MAC for
"steering" frames only. Change of ringlet selection due to bandwidth
availability is a traffic engineering task and should be performed at higher
layer, and should consider to enhance the overall network performance. A
local view from the MAC can not perform the task
properly.
* 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).
[LM]
The bridge relay request to transmit a packet on the ring by
dispatching a DATA.Request primitive to the 802.17 ISS, which can be part of
the MAC
* 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.
[LM] The
ringlet selection issue affecting the performance of the network but it
is relatively a local issue (i.e. does not affecting interworking of the
stations), and hence should not be overly restrictive on what it should do
in the normative text of the standardization, especially in reference
to detail design as location of the
database.
* 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).
[LM] Both options somehow excluded the
transparent bridging with spacial reuse case. We should invest in that topic
as well. The first is the promiscuous operation and the second is
encapsulation bridging, which would require a frame change or imbed the
original source/destiona MAC address in the payload (which can also be
viewed as a framer change).
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.
[LM] The
802.1D/Q Relay Entity to 802.17 ISS does not have those values but,
from the ISS to MAC those values can be added. By the way, it is the ISS which formats the
initial frame and that may be where the ringlet selection algorithm should
be located.
========
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.