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

RE: [RPRWG] Frame Formats in Draft 2.0

Title: RE: [RPRWG] Frame Formats in Draft 2.0
Marc,
This may be your intention, but while reading the contribution for relaxed mode it says (A.1.1): "The associated frame format is outlined in Clause 8.0", and then for strict mode it says (A.1.2): "The remaining of this clause will outline the mechanisms required to support strict frame transmission" and as part of this "mechanisms" it defines the new frame format.
 
At the time of voting the only clause 8.0 available was the one from D1.1, so from the text (and that is all we voted to accept) I don't see why the relaxed mode frame format has to be changed.
 
Leon
 
-----Original Message-----
From: Marc Holness [mailto:holness@xxxxxxxxxxxxxxxxxx]
Sent: Monday, December 16, 2002 6:55 PM
To: Leon Bruckman; 'John Lemon'
Cc: stds-802-17@xxxxxxxx
Subject: RE: [RPRWG] Frame Formats in Draft 2.0


There is one data frame format. The RPR data frame format is the same for both strict and relaxed transmissions. The data frame format as illustrated in Draft 2.0 represents the contribution (mh_frame-transmission_text_01.pdf).

Marc.


-----Original Message-----
From: Leon Bruckman [mailto:leonb@xxxxxxxxxxxxx]
Sent: Monday, December 16, 2002 11:20 AM
To: 'John Lemon'
Cc: stds-802-17@xxxxxxxx
Subject: RE: [RPRWG] Frame Formats in Draft 2.0



John,
In Marc Holness proposal (mh_frame_transmission_text_01.pdf), that we passed in Hawaii, there are two modes of operation:

- relaxed
- strict

According to my understanding of A.1.1 in that document, the RPR data frame format for relaxed mode should remain the same as in D1.1 (no ttlBase and extRingControl fields). The data frame format should be modified only for strict mode of operation. How to select relaxed/strict mode is not defined, but I assumed some management operation.

I was surprised to see that the only data frame format defined in D2.0 is the strict mode. Can you or anyone else comment ?

Leon

-----Original Message-----
From: John Lemon [mailto:JLemon@xxxxxxxxxxxx]
Sent: Thursday, December 12, 2002 3:27 AM
To: Paritosh Kulkarni
Cc: stds-802-17@xxxxxxxx
Subject: RE: [RPRWG] Frame Formats in Draft 2.0



Paritosh,

Mea culpa. I made an editing mistake. The controlType and controlVersion fields should have been placed before the HEC, keeping the HEC in the same position for both data and control frames. I'll file a comment against this to have it corrected. Thanks for catching this.

John Lemon

-----Original Message-----
From: Paritosh Kulkarni [mailto:paritosh@xxxxxxxxxxxxxxx]
Sent: Wednesday, December 11, 2002 4:25 PM
To: stds-802-17@xxxxxxxx
Subject: [RPRWG] Frame Formats in Draft 2.0




I see that the frame format for Control Frames is different in Draft 2.0 as compared to Draft 1.1.

Specifically, the control version and control type fields have been moved to after the header checksum in Draft 2.0 (Page 150) and the header checksum does NOT cover these fields. Also, looking at one of Marc Holness's bridging proposals made in Nov 2002 meeting titled "mh_frame_transmission_text_01.pdf" on Page 3 Section A.2 titled Frame Format, it says pretty clearly in the Editor's Notes that NO changes are being suggested to the P802.17 D1.1 control frame. The control frame in D1.1 has the control type and control version fields before the header checksum and the header checksum covered these fields (D1.1, Page 112 Section 8.3).

This makes the offsets for header checksum different for Data Vs Control frames leading to unnecessary complexity and awkwardness in implementations.

Could someone clarify when this changed ?

Thanks,

-Paritosh