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

RE: [RPRWG] Fairness messages and use of the ringlet ID fairness frame field




Fredrik,

The fairness message is actually created in the opposing ringlet's datapath, and therefore takes the value of myRIngletId from that opposing ringlet. Therefore, technically, everything works correctly. However, it certainly could be stated more explicitly, and Tables 9.8, 9.9, and 9.11 all should be modified accordingly.

Since ri indicates the ringlet on which a message is sent, I would not support a change such as suggestion 1. Suggestion 2 is one possible means of clarifying that the message is actually generated in the opposing ringlet, and I would support something of this sort.

I assume you will be submitting a comment with the current ballot to address this clarification.

jl

-----Original Message-----
From: Fredrik Davik [mailto:bjornfd@xxxxxxxxx]
Sent: Friday, June 27, 2003 6:25 AM
To: stds-802-17@xxxxxxxx
Cc: steing@xxxxxxxxx; petterte@xxxxxxxxxx; bjoernal@xxxxxxxxxx
Subject: [RPRWG] Fairness messages and use of the ringlet ID fairness
frame field



There seems to be a problem with the use of the ri field for fairness messages.

Fairness messages are sent upstream on ringlet opposite of that
which they regulate traffic for.

FCU0 monitors and regulates fairness eligible traffic on ringlet 0 and
sends fairness messages to upstream station on ringlet 1.

FCU1 monitors and regulates fairness eligible traffic on ringlet 1 and
sends fairness messages to upstream station on ringlet 0.

In the transmitted fairness message, the ri field is set to myRingletId or rcvdRi(Table 9.8, page 240).

For FCU0, myRingletId should be 0 (according to definition on page 219)
For FCU1, myRingletId should be 1

When a fairness message transmitted by either of the downstream FCUs
are received by an upstream station, the fairness frame will not
fulfill any of the conditions in state table 6.20 (Filter select, page
135), and the frame will not be passed on to the fcu...

There seems to be two feasible solutions to this problem: 

1. Add a row to the filter select state table between rows 3 and 4
   which does an test for 

   rxFrame.ft == FT_FAIRNESS && SameSide(rxFrame) == 0 
   with next state = FINAL

2. Change state tables 9.8 and 9.11

   9.8 changes:  change assignment 
     frame.ri = myRingletID" to 
     frame.ri = 1 - myRingletID" in lines 20, 33 and 45

   9.11 changes: change test

    change "if (frame.ri == myRingletID)" to 
           "if (frame.ri != myRingletID)" in lines 16, 19, 38.

    change "if (rcvdRi != myRingletID)" to 
           "if (rcvdRi == myRingletID)" line 28.
 
Solution 1 seems to be the simpler and cleaner solution. This way, the
ri field always denotes the ringlet id for which the fairness message
contents apply (even during protection events?). Based on this, it is
easy to forward a received fairness message to the appropriate FCU.

Best Regards, 
Fredrik 
---------------------------------------------
Fredrik Davik
                 Phone:       +47 67 82 83 88
                 Mobile:      +47 45 24 91 88
                 Fax:         +47 67 82 82 01
                 Switchboard: +47 67 82 82 00

mailto:bjornfd@xxxxxxxxx

http://heim.ifi.uio.no/~bjornfd
http://www.simula.no/people_one.php?people_id=22

Simula Research Laboratory
P.O.Box 134, Lysaker
N-1325 Lysaker
Norway