Re: Interframe gap

[Rich Taborek <rtaborek@xxxxxxxxxxxxxxxx>]

Mark,

I don't believe that Drew was suggesting deleting the IPG. Instead, I'm
assuming that what is being proposed is a mapping of Ethernet to OC192
and STM64 whereby IPG exists on the Ethernet side, but not the OC192 and
STM64 side. The bridge between the two would delete/regenerate the IPG
as appropriate. 

Assuming that my interpretation above is true, I could think of a few
related issues in consideration of 1000BASE-X protocol. (Note that there
may be other similar issues with 1000BASE-T, I just don't know that
protocol well enough):

1) During 1 GbE Auto-Negotiation/Link Startup, the IPG as well as all
Ethernet Packets are replaced by Configuration words. The bridge could
handle this by operating as a link end, effectively responding as a
remote AN device on the Ethernet side and following OC192 and STM64
initialization procedures on that side.

2) The IPG may carry other link information when link status is OK and
Ethernet Packets are allowed to flow (AN is complete). This one is a
stretch: Architecturally, part of the End-of-Packet Delimiter (EPD) is
considered to be part of the IPG. The bridge has to be careful here. The
other is that VOID code-groups may replace normal IPG code groups. This
one is probably a don't care for bridging and VOID can be treated as
standard IPG. However, there is a boundary case when the VOID replaces
the Start-of-Packet Delimiter, which concludes IPG.

Hopefully I didn't do off on a tangent that will start another reflector
thread... to go off onto other tangents... to...

--

Gerhold, Mark wrote:
> 
> The interframe gap has been used on NICs and Switches to process the
> received packet and prepare for the next packet.  There are counters to be
> updated, buffers to be allocated.  For example, setting up the DMA for the
> next buffer takes a few clocks, and depends on whether the current packet
> had an error and should be discarded.
> 
> The interframe gap is a small price to pay.  And it's become more important
> over time, since comm bandwidth is increasing faster than processing.
> 
> Mark
> -----Original Message-----
> From: Drew Perkins [mailto:drew.perkins@xxxxxxxxxxxx]
> Sent: Friday, May 21, 1999 3:07 PM
> To: 'msalzman@xxxxxxxxxx'; 'stds-802-3-hssg@xxxxxxxxxxxxxxxxxx'
> Subject: RE: A telephony carrier industry perspective
> 
> I am assuming that we get rid of the Inter-Packet Gap. This should add a
> small amount of bandwidth, but I honestly haven't had a chance to work the
> math. It would be interesting if someone did this. If there is still a
> discrepancy, then you'd be forced to buffer and flow control in some manner.
> 
> Drew
> ---------------------------------------------------------
> Ciena Corporation                 Email: ddp@xxxxxxxxxxxx
> Core Switching Division                 Tel: 408-865-6202
> 10201 Bubb Road                         Fax: 408-865-6291
> Cupertino, CA 95014              Cell/Pager: 408-829-8298
> 
> -----Original Message-----
> From: owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
> [mailto:owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx]On Behalf Of Michael M.
> Salzman
> Sent: Friday, May 21, 1999 1:48 AM
> To: stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
> Subject: RE: A telephony carrier industry perspective
> 
> Hi Drew,
> 
> Someone earlier (Paul Bottorf I think) raised the issue of speed mismatch
> between OC192 and 10 Gig, a small matter of 0.4Gbps.  Are you proposing the
> use of precisely OC192 and STM64 as the underlying layer - if so, how do you
> propose to pack the frames?
> 
> ...stuff deleted

-- 

Best Regards,
Rich

------------------------------------------------------------- 
Richard Taborek Sr.    Tel: 650 210 8800 x101 or 408 370 9233       
Principal Architect         Fax: 650 940 1898 or 408 374 3645
Transcendata, Inc.           Email: rtaborek@xxxxxxxxxxxxxxxx 
1029 Corporation Way              http://www.transcendata.com 
Palo Alto, CA 94303-4305    Alt email: rtaborek@xxxxxxxxxxxxx