Re: [RPRWG] More comments on preemption
Hi;
The PCS layer acts as a "server layer" for the RPR "client layer". We can
impose requirements from an RPR MAC point of view on the PHY layer IF we
want to support preemption.
We have two (2) choices (assuming we want to support preemption):
- controlled artefacts (or fragments if we like);
- arbitrary artefacts.
* Controlled artefacts seem to be easy to do with an HDLC like (or 8B/10B like
encoding) framing because these layers augment the symbol space and thus we can
"borrow" codes from these layers to express preemption.
* Arbitrary artefacts: this type of artefact can be supported by the same
framing methods (HDLC, 8B/10B). The HDLC layer has an "ABORT" code standardized
for example.
It looks like GFP is less friendly to arbitrary changes in the datapath. We
will need to be creative if we want to support preemption with this framing
method...
-------
Snippet of a proposal to support preemption on GFP:
* have fixed preemption opportunities in a GFP frame;
* a receiving entity continuously calculates a CRC on the frame and if it finds
this CRC in the fixed preemption opportunities in the GFP frame, it aborts this
current frame.
What do you think?
jld.
marconi networks.
To: "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
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@xxxxxxxxxxx]
> > 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