Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

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




I think this requires additional work as 802.17 needs to comply with the
specifications for Phys that are adopted. Less than 64 bytes minimum frame
size precedence for Ethernet phys needs to be investigated. This may be
resolved through liaison with 802.3.

The max frame size may be extended beyond 802.3 1522 bytes limit as there is
precedence in 802.3 community. However, it needs to be configurable to be
lower, in order to comply with transparent bridging requirements. 

Whether SONET/SDH phys or 802.3 phys are used, 802.17 frames need to pass
through 802.1 relay, without source MAC knowledge of the destination's MAC
frame size capability. I don't believe there are any 802.1 protocols for
negotiating MAC max frame size. 

Nader

-----Original Message-----
From: Necdet Uzun [mailto:nuzun@xxxxxxxxx]
Sent: Tuesday, December 03, 2002 5:14 PM
To: Anoop Ghanwani
Cc: 'Frank Kastenholz'; iporpr@xxxxxxxx; 'stds-802-17@xxxxxxxx'
Subject: Re: [RPRWG] RE: [IPORPR] payload length and padding and stuff



Anoop,

Another thing to note that RPR over Ethernet does not require padding of
RPR frames as we do not have the same 64 byte minimum packet size
requirement as Ethernet.

Thanks.

Necdet

Anoop Ghanwani wrote:

> 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
>