RE: [RPRWG] RE: payload length and padding and stuff

Agreed, Tom,

In any case that was just a discussion point for mixed media case. If it had
to be done, there would be more complicated things than rate matching (like
slicing, padding and may be even re-assembly).

Regards,
Devendra.

> -----Original Message-----
> From: Tom Alexander [mailto:[email protected]]
> Sent: Wednesday, December 04, 2002 3:00 PM
> To: 'Devendra Tripathi'; 'Anoop Ghanwani'; 'Frank Kastenholz';
> [email protected]; [email protected]
> Subject: RE: [RPRWG] RE: [IPORPR] payload length and padding and stuff
>
>
> Devendra,
>
> One clarification: the slowing down of the XGMII data rate to match the
> OC-192 rate of 10GBASE-W is done entirely within the 802.3 MAC.
> There is no
> provision to do this within the 10GBASE-W PHY. 802.17 defines its own MAC
> and only uses the 10GBASE-W PHY; hence the rate pacing mechanisms of 10G
> Ethernet do not apply.
>
> Best regards,
>
> - Tom Alexander
> Former WIS (10GBASE-W) Scribe
>
>
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of Devendra
> Tripathi
> Sent: Wednesday, December 04, 2002 10:26 AM
> To: Anoop Ghanwani; 'Frank Kastenholz'; [email protected];
> [email protected]
> 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: [email protected]
> > [mailto:[email protected]]On Behalf Of Anoop Ghanwani
> > Sent: Tuesday, December 03, 2002 4:03 PM
> > To: 'Frank Kastenholz'; [email protected]; '[email protected]'
> > 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:[email protected]]
> > > Sent: Tuesday, December 03, 2002 3:46 PM
> > > To: [email protected]
> > > 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]
>
> ---
> [This E-mail scanned for viruses by Declude Virus]
>
>

---
[This E-mail scanned for viruses by Declude Virus]