Re: [RPRWG] RE: payload length and padding and stuff
Pankaj K Jha <[email protected]> Tue, 03 Dec 2002 18:26:32 -0600
| Newsgroups | gmane.ietf.iporpr |
|---|---|
| Message-ID | <[email protected]> |
--------------090004090903040604070408 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Anoop/Necdet: And the same could be true of maximum size as far as RPR MAC is concerned - although maximum size can be negotiated for mixed links using path MTU discovery (rfc1191) protocol at L3. In general, I don't think RPR should preclude use of mixed media, as long as there is an external logic for rate-matching (how? - PHY people can possibly advise on it). RPR MAC wouldn't even know the difference. =Pankaj Necdet Uzun wrote: >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:[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 >>> >>> > > > > > --------------090004090903040604070408 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <title></title> </head> <body> Anoop/Necdet:<br> And the same could be true of maximum size as far as RPR MAC is concerned - although maximum size can be negotiated for mixed links using path MTU discovery (rfc1191) protocol at L3. In general, I don't think RPR should preclude use of mixed media, as long as there is an external logic for rate-matching (how? - PHY people can possibly advise on it). RPR MAC wouldn't even know the difference.<br> =Pankaj<br> <br> Necdet Uzun wrote:<br> <blockquote type="cite" cite="[email protected]"> <pre wrap="">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: </pre> <blockquote type="cite"> <pre wrap="">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 </pre> <blockquote type="cite"> <pre wrap="">-----Original Message----- From: Frank Kastenholz [<a class="moz-txt-link-freetext" href="mailto:[email protected]">mailto:[email protected]</a>] Sent: Tuesday, December 03, 2002 3:46 PM To: <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a> 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 </pre> </blockquote> </blockquote> <pre wrap=""><!----> </pre> </blockquote> <br> <br> </body> </html> --------------090004090903040604070408--