Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [RPRWG] 802.17 MAC Ring Selection Mechanism



Title: RE: [RPRWG] 802.17 MAC Ring Selection Mechanism
Marc, et al,
 
Comments below in-line preceded with "jl: " (and in teal for those viewing this in HTML format).
 
jl
----- 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.