Re: [RPRWG] More comments on preemption
Through this thread of discussion, I sense the confusion between
the Ethernet PHY and Ethernet MAC.
RPR MAC is required to be interoperable with GigE and 10GigE
phys, but it is NOT Ethernet MAC.
If there is preemption, it should exist in the RPR MAC layer, and be
transparent to any PHY it is connected with.
William Dai
----- Original Message -----
From: "Nader Vijeh" <nader@xxxxxxxxxxxxxx>
To: <stds-802-17@xxxxxxxx>
Sent: Monday, May 07, 2001 11:46 AM
Subject: RE: [RPRWG] More comments on preemption
>
> We have already passed two objectives that require the RPR MAC to be
> interoperable with GigE and 10GigE phys. Please see line items 15 & 16 in:
>
>
http://www.ieee802.org/rprsg/public/presentations/may2001/master_list_01.xls
>
> -----Original Message-----
> From: jeanlou.dupont@xxxxxxxxxxx [mailto:jeanlou.dupont@xxxxxxxxxxx]
> Sent: Monday, May 07, 2001 11:37 AM
> To: Uyeshiro, Robin
> Cc: 'Raman Venkataraman'; Devendra Tripathi; William Dai;
> stds-802-17@xxxxxxxx
> Subject: RE: [RPRWG] More comments on preemption
>
>
>
>
>
> Hi;
>
> Could you emphasize on what you mean by: "Interoperability or usage of
> existing
> plant may be compromised." ?
>
> jld.
>
> Disclaimer: I am also not in favor of any preemption mechanism.
>
>
>
>
>
>
> To: "'Raman Venkataraman'" <kvraman@xxxxxxxxxxxxxxxx>, Devendra Tripathi
> <tripathi@xxxxxxxxxxxx>, Jeanlou Dupont/MAIN/MC1@MCMAIN
> cc: William Dai <wdai@xxxxxxxxxxxx>, stds-802-17@xxxxxxxx
>
> Subject: RE: [RPRWG] More comments on preemption
>
>
>
>
>
> Sorry to interject, but I feel this may be relevant:
>
> Preemption without retransmission requires stuff in a phy layer that may
not
> be there. It may mean that this limits which phy layers can be used, or
it
> may use a phy in ways for which it was not designed. Interoperability or
> usage of existing plant may be comprimised. One should be very careful
> about doing this.
>
> Thanks, I feel better now.
>
> Regards,
> Robin Uyeshiro
>
>
>
> -----Original Message-----
> From: Raman Venkataraman [mailto:kvraman@xxxxxxxxxxxxxxxx]
> Sent: Saturday, May 05, 2001 4:35 AM
> To: Devendra Tripathi; jeanlou.dupont@xxxxxxxxxxx
> Cc: William Dai; stds-802-17@xxxxxxxx
> Subject: Re: [RPRWG] More comments on preemption
>
>
>
> Hi Devendra,
> You are correct about the Ethernet requirement. That is exactly my point.
> Any preemption scheme that we propose should not have any implication on
the
> layers (encapsulation & transport) below 802.17 MAC. With this reference
to
> POS, the only advantage is that packet encapusulation may be considered to
> be
> within the 802.17 MAC layer; otherwise, embedding ESC sequence is not
> providing
> any significant advantage for preemption. In any case, I am not in favor
> of
> using ESC sequence for preemption.
>
> Regards
> Raman
>
> ----- Original Message -----
> From: Devendra Tripathi <tripathi@xxxxxxxxxxxx>
> To: Raman Venkataraman <kvraman@xxxxxxxxxxxxxxxx>;
> <jeanlou.dupont@xxxxxxxxxxx>
> Cc: William Dai <wdai@xxxxxxxxxxxx>; <stds-802-17@xxxxxxxx>
> Sent: Friday, May 04, 2001 11:16 AM
> Subject: RE: [RPRWG] More comments on preemption
>
>
> > Hi Raman,
> >
> > >From my Ethernet background, the control symbols are differentiated
only
> > by PCS layer (or a small sub layer of MAC marked as re-conciliation
> layer).
> This is because in Ethernet there is no concept of extensive header per
> > packet. Since RPR MAC is expected to operate with Ethernet PHYs, it is
> > important to consider the implications there. Could you clarify how ESC
> will
> > be
> > embedded by POS ?
> >
> > Regards,
> > Devendra Tripathi
> > VidyaWeb Inc.
> > Pune, India
> > Tel: +91-20-433-1362
> >
> > > -----Original Message-----
> > > From: Raman Venkataraman [mailto:kvraman@xxxxxxxxxxxxxxxx]
> > > Sent: Friday, May 04, 2001 7:14 AM
> > > To: Devendra Tripathi; jeanlou.dupont@xxxxxxxxxxx
> > > Cc: William Dai; stds-802-17@xxxxxxxx
> > > Subject: Re: [RPRWG] More comments on preemption
> > >
> > >
> > > Hi,
> > > My understanding of William's proposal for the IDLE/Escape marking is
> > > in the 802.17 MAC level and it is not clear to me why PCS layer is
> getting involved. It looks to me that if we use the POS transport, the
> special
> ESC sequence can be used for detecting the special markings. However, if
we
> use
> the
> > > GFP for the transport, the escape sequences will be stripped before
> encapsulating the packets into the GFP. So, it looks like this method will
> work
> if we use the POS.
>
> > > Regards
> > > Raman
> > > ----- Original Message -----
> > > From: Devendra Tripathi <tripathi@xxxxxxxxxxxx>
> > > To: <jeanlou.dupont@xxxxxxxxxxx>
> > > Cc: William Dai <wdai@xxxxxxxxxxxx>; <stds-802-17@xxxxxxxx>
> > > Sent: Thursday, May 03, 2001 6:17 PM
> > > Subject: RE: [RPRWG] More comments on preemption
> > >
> > >
> > > >
> > > > Hi William,
> > > >
> > > > Actually, it is not just a question of symbol. The PCS layer of 1/10
G
> > > > Ethernet PHY makes quite a few assumtions on where an IDLE can come.
> IDLE
> is also used to decide on clock compensation. In all likelyhood such a
> > > packet will be declared erroneous ( I need to look this more seriously
> to be
> > > > conclusive).
> > > > If we decide to use the reserve symbol to mark Escape, there may be
> > > > compatibility (of PHY devices) issues.
> > > >
> > > > The other issue is related to frame format change at gateway
(LAN/MAN)
> > > > points.
> > > > The default understanding which I had was that when a Packet from
LAN
> > > comes to Metro area, it requires add/delete of header and that is
about
> it
> (as for as frame format is concerned). But this may not be strong issue
> though.
> > > >
> > > > Regards,
> > > > Devendra Tripathi
> > > > VidyaWeb Inc.
> > > > Pune, India
> > > > Tel: +91-20-433-1362
> > > >
> > > > > -----Original Message-----
> > > > > From: jeanlou.dupont@xxxxxxxxxxx [mailto:jeanlou.dupont@xxxxxxxxxx
m]
> > > > > Sent: Friday, May 04, 2001 4:53 AM
> > > > > To: Devendra Tripathi
> > > > > Cc: William Dai; stds-802-17@xxxxxxxx
> > > > > Subject: RE: [RPRWG] More comments on preemption
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Could you clarify your statement "... definitely takes us away
> > > > > from Ethernet"?
> > > > >
> > > > > If you are targeting your comment at the Ethernet PHY layer: the
> > > > > Ethernet (100
> > > > > & 1000) uses 8B/10B encoding.
> > > > > There are some "spare symbols" not used (if I am not mistaken)
> > > > > that could be
> > > > > redefined to mean "IDLE/Escape".
> > > > >
> > > > > Jean-Lou Dupont
> > > > > Marconi Networks.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > To: "William Dai" <wdai@xxxxxxxxxxxx>, stds-802-17@xxxxxxxx
> > > > > cc: (bcc: Jeanlou Dupont/MAIN/MC1)
> > > > >
> > > > > Subject: RE: [RPRWG] More comments on preemption
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > > 3. Each M and L packet transfer will be inserted an
"IDLE/Escape"
> > > > > > word for every 256 byte (for the sake of alignment/padding
> > > concern)
> > > > > > as the preemptive insertion point.
> > > > >
> > > > > This is very good idea to manage pre-emption and other QOS related
> > > > > considerations but this definitely takes us away from Ethernet.
> > > > >
> > > > > Regards,
> > > > > Devendra Tripathi
> > > > > VidyaWeb Inc
>
>
>