RE: [RPRWG] Frame Formats in Draft 2.0
Hi Robert,
My comments in line.
Leon
-----Original Message-----
From: Castellano, Robert [mailto:RCastellano@xxxxxxxxx]
Sent: Monday, December 16, 2002 7:22 PM
To: 'Leon Bruckman'; 'John Lemon'
Cc: stds-802-17@xxxxxxxx
Subject: RE: [RPRWG] Frame Formats in Draft 2.0
Hi Leon,
The mh_frame_transmission frame format proposal defined the protocol
type to follow the HEC to provide space for the extended
ring control field prior to the HEC. This field is required
for all frames (both strict / relaxed). In fact, the
strict/relaxed mode indicator is identified within the
extRingControl field.
lb] My interpretation is that in strict mode the bit indicates
strict/relaxed, but the user may select to use only relaxed mode in which
case the frame format will remain as defined in D1.1. In my opinion the text
supports this interpretation, as noted in my email to Marc
There is one common frame format that accommodates both
strict/relaxed mode traffic, rather than having two
frame formats, one optimized for each.
lb] There is a 2 bytes tax for this, and our overhead is already large.
The WH proposal, "White Horse" was the only proposal which
supported the D1.1 frame format (some control bit encoding
was required in the rprcontrol field to support).
robert
> -----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
>