RE: [RPRWG] 802.17 MAC Ring Selection Mechanism

["Li Mo" <limo01@xxxxxxxxx>]

Title: RE: [RPRWG] 802.17 MAC Ring Selection Mechanism

Further comments on ringlet selection

 

Ringlet selection, in the context of bridging, only applies to the spacial reuse case. In promiscuous case, the ringlet selection does not apply (protection algorithm may change the ringlet but should be discussed separately)

 

Regarding the referenced MAC/station database. It should be noted that the 802.17 MAC is essentially a two ports device. In other technologies (MPLS or Ethernet), those two ports will be modelled as two diffferent router/bridge ports. The forwarding rules will be governed by the bridge/router database. This is how the spacial reuse is to be achieved.

 

In RPR, the forwarding has rules to itself. Hence there are two options in order to achieve spacial reuse:

 

1. Forward the frames between those two ports (on the same RPR MAC) by consulting the MAC/station database on a per frame/packet bases on the transit/transmit path.

    The MACs for both the source and destination in the current RPR frame header may be off-ring addresses. This can be classified as transparent bridging

2. Encapsulate the original Ethernet frame onto anther layer-2 frame which has RPR MAC on it (station ID or MAC address of the stations on the ring).

    This can be classified as encapsulation bridging.

 

One of the concerns for solution 1. is the lookup speed in the RPR MAC for line rate operations because the destination address match is not a simple direct match anymore. It would be a database search (a CAM like operation). Considering the whole system, we have:

 

1. In promiscuous mode, the database search in Bridge Relay/ISS is for every frame. Hence this does not pose anymore speed requirement for database lookup

2. In the destination of the frame, such database search is also required to figure out the egress port.

 

By encapsulation bridging (i.e. encapsulate a station ID inside), we will still require the look up somewhere inside the system anyway.

 

Before we have the encapsulation algorithm, it is hard to judge its merit. But from the high level, the overall operation (i.e. from the source to destination) can be compared:

 

1.  MAC Address learning: Encapsulation bridging and transparent bridging will be the same (once per-frame on the transit path for the source MAC address),

     operating at the same rate. For encapsulation bridge, it need to associate the source MAC address with the source RPR station address.

     The MAC address information will be used differently by those two mechanisms.

2. Encapsulate the packet at the source (before transmission to RPR ring) based on the MAC address information. This step is not required in transparent bridging

3. At each RPR station receiving from the transit path, check if the Source address for striping purposes. For encapsulation bridging, this will be a simple direct MAC address

     match. For address learning, the encapsulation bridge will also need to get the source address (original source MAC which could be off-ring) and update the MAC address

    database (a database lookup). For transparent bridging, this would be a database lookup, which both determines the source striping and for learning purposes.

4. At each RPR station receiving from the transit path, check the destination address.

    4a. for encapsulation bridge, perform a direct MAC address match. If it succeed, perform a database lookup for the real destination address encapsulated to determine

          the egress port

    4b. for transparent bridge, perform a database lookup for the destination MAC address, as if the direct MAC addrss match succeed in the encapsulation bridging case.

 

Before we get into details of how encapsulation bridge is to be structureed and how the bits is to be assigned, frame structures to be modified, we need to highlight the advantage of encapsulation bridge in order to persue it. Yes, it simplfies the 802.17 MAC, but may introduce a more complicated overall system. In step 3, the encapsulation bridge is actually doing more work than transparent bridge. In step 4, the encapsulation bridge is doing less work for most of the time but more work on the destination. The point is, if we do not have issues doing the more work at the destination, we definitly will not have issues doing slightly less work everywhere because everywhere is to be able to process it at the line rate.

 

The presences of routers/end stations will not affect the above because their MAC address will be used, which will be on the ring.

 

Comments?

 

Li...

 

 

 

 

 -----Original Message-----
From: owner-stds-802-17@xxxxxxxxxxxxxxxxxx [mailto:owner-stds-802-17@xxxxxxxxxxxxxxxxxx]On Behalf Of John Lemon
Sent: Wednesday, March 20, 2002 8:05 PM
To: Marc Holness; dot17
Subject: 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 -----

From: Marc Holness

To: Marc Holness ; dot17

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.