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
 
See below for comments.
-----Original Message-----
From: Sanjay K. Agrawal [mailto:sagrawal@xxxxxxxxxxxxxxxxxx]
Sent: Wednesday, March 20, 2002 4:49 PM
To: Anoop Ghanwani; 'Marc Holness'; dot17
Subject: Re: [RPRWG] 802.17 MAC Ring Selection Mechanism

Please see my comment in green.
----- Original Message -----
Sent: Wednesday, March 20, 2002 3:45 PM
Subject: RE: [RPRWG] 802.17 MAC Ring Selection Mechanism

Marc, See comments/clarifications below. -Anoop

-----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.