[RPRWG] [Fwd: BOUNCE stds-802-17@xxxxxxxxxxxxxxxxxx: Non-member submission from [Vinay Bannai <bannai@xxxxxxxxxxx>]]
Date: Thu, 05 Dec 2002 07:19:34 -0800
From: Vinay Bannai <bannai@xxxxxxxxxxx>
Subject: RE: [RPRWG] RE: [IPORPR] payload length and padding and stuff
In-reply-to:
<58BE468BAC66D511AFE6000347251A2D01A166AB@xxxxxxxxxxxxxxxxxxxxxxx>
To: Anoop Ghanwani <anoop@xxxxxxxxxxxxxx>,
"'Frank Kastenholz'" <fkastenholz@xxxxxxxxxxx>, iporpr@xxxxxxxx,
stds-802-17@xxxxxxxx
Message-id: <KHEJKCLHOKOEBOBHALFLGEIMCEAA.bannai@xxxxxxxxxxx>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
I agree with Anoop. You start mixing different PHY's you are opening up
a
Pandora's box that has not yet been resolved satisfactorily in my
opinion.
For instance, it is not just OC-192 that we need to worry about. We have
to
also account for GFP or POS for the reasons pointed out by Anoop.
I would steer clear of mixed PHY's atleast for the time being.
Vinay
-----Original Message-----
From: iporpr-admin@xxxxxxxx [mailto:iporpr-admin@xxxxxxxx]On Behalf Of
Anoop Ghanwani
Sent: Wednesday, December 04, 2002 11:48 AM
To: 'Devendra Tripathi'; Anoop Ghanwani; 'Frank Kastenholz';
iporpr@xxxxxxxx; stds-802-17@xxxxxxxx
Subject: RE: [RPRWG] RE: [IPORPR] payload length and padding and stuff
Even with a suitable rate match logic, the problem is not
trivial. There was an interesting issue that was brought
up a couple of meetings ago which is the following:
+--+ +--+ +--+
|N1|==========|N2|==========|N3|
+--+ 10GE +--+ OC-192 +--+
Depending on the type of framing used on the OC-192
span, one might need to do byte-stuffing. The amount
of byte-stuffing that needs to be done depends
on the contents of frames as they are
received from the 10GE link and, in the worst case,
it can reduce the actual bandwidth on the OC-192
link quite significantly. This could easily lead to
overflow of the primary transit queue, which is
undesirable and unaccounted for in the current draft.
-Anoop
> -----Original Message-----
> From: Devendra Tripathi [mailto:tripathi@xxxxxxxxxxxxx]
> Sent: Wednesday, December 04, 2002 10:26 AM
> To: Anoop Ghanwani; 'Frank Kastenholz'; iporpr@xxxxxxxx;
> stds-802-17@xxxxxxxx
> Subject: RE: [RPRWG] RE: [IPORPR] payload length and padding and stuff
>
>
> Actually, basic data rate may not be an issue here as one can suitable
> slowdown the 10G to match OC192 rate (there is protocol
> defined in 10G for
> that). The device which will interface to two different media
> should take
> care of translation of frames to and from the different
> media. Accordingly a
> frame from Sonet (which could be <64 bytes to ~64KB long) may need be
> sliced/padded into packets of suitable sizes. If there is
> stream of small (<
> 64B) packets, naturally the effective data rate on 10G will go down
> significantly and in that case one will have to resort to
> some sort of flow
> control.
>
> However, I agree with Anup that we should keep the standard
> based on uniform
> media. Any mixing of media should be left to bridges.
>
> Regards,
> Devendra.
>
> > -----Original Message-----
> > From: owner-stds-802-17@xxxxxxxxxxxxxxxxxx
> > [mailto:owner-stds-802-17@xxxxxxxxxxxxxxxxxx]On Behalf Of
> Anoop Ghanwani
> > Sent: Tuesday, December 03, 2002 4:03 PM
> > To: 'Frank Kastenholz'; iporpr@xxxxxxxx; 'stds-802-17@xxxxxxxx'
> > Subject: [RPRWG] RE: [IPORPR] payload length and padding and stuff
> >
> >
> >
> > Frank,
> >
> > We shouldn't be trying to mix different PHYs,
> > e.g. 10GE and OC-192, since they are in fact running
> > at different data rates, and having PHYs with different
> > data rates on the same ring is not allowed by the
> > current version of the draft. I think the draft
> > is silent on this specific issue, though.
> >
> > I'm cc.-ing the 802.17 list since this is an interesting
> > issue that has come up there as well. Maybe someone
> > else might be able to shed some light on this
> > (PHY people??).
> >
> > -Anoop
> >
> > > -----Original Message-----
> > > From: Frank Kastenholz [mailto:fkastenholz@xxxxxxxxxxx]
> > > Sent: Tuesday, December 03, 2002 3:46 PM
> > > To: iporpr@xxxxxxxx
> > > Subject: [IPORPR] payload length and padding and stuff
> > >
> > >
> > > i'm editing the iporpr document and have come across a question...
> > >
> > > suppose i have an 802.17 ring comprised of both gig-e and sonet
> > > sections. gig-e, i assume, has the usual ethernet min frame
> > > size rules, so if a dataframe is transmitted onto gig-e and
> > > the payload is too short, it gets padded so that the frame
> > > is 64 bytes. if a frame is transmitted onto a sonet section,
> > > no such padding is needed, since there are no min frame length
> > > rules for sonet. so what happens when a frame that was initially
> > > transmitted on a sonet section reaches a gig-e section of
> > > the ring:
> > >
> > > +-----------+ +-----------+ +-----------+
> > > | Station 1 | | Station 2 | | Station 3 |
> > > +-----------+ +-----------+ +-----------+
> > > / \ / \ / \
> > > ...___/ \________/ \________/ \___...
> > > sonet gig-e
> > >
> > > A frame generated at station-1 that has, let's say, only a 20 byte
> > > payload, would be 42 bytes long. This is fine for sonet. What
> > > happens when the frame reaches the gig-e section between
> stations 2
> > > and 3?
> > > - is the frame padded by the mac/phy layers in station 2?
> > > - is the frame dropped?
> > > - are the min-frame rules dropped for gig-e when it's being used
> > > for .17?
> > > - is it illegal to mix sonet and gig-e in the same ring?
> > > - am i very confused and is the answer obvious to all but me?
> > >
> > > thanks
> > >
> > > frank kastenholz
> >
> > ---
> > [This E-mail scanned for viruses by Declude Virus]
> >
> >
>
> ---
> [This E-mail scanned for viruses by Declude Virus]
>
_______________________________________________
IPORPR mailing list
IPORPR@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/iporpr