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

Re: Interface reality check




Rick,

True 64B/66B supports all of the "Ethernet packet signalling semantics"
BEFORE it encodes the 802.3 frames.  But quite simply, after it is encoded,
it is no longer octet aligned.  The WAN compatible PHY is octet aligned.
ANSI T1X1 and ITU standards are also octet aligned.  It has nothing to do
with control codes or any other issue.  For example your 1500 octet 802.3
Ethernet MAC frame becomes 1546.875 octets after it is encoded with 64B/66B.
This type of octet alignment failure may cause other problems in octet
aligned signaling schemes.  I noticed this octet alignment failure in
looking at the possibility of using IPG compression with 64B/66B to help
reduce the additional ~3% transfer bandwidth loss.

The octet alignment failure issue may also effect a LAN only PHY that would
use octet interleaved 4 channel WDM.  I am sure that someone who is working
on that would be able to determine if there is a problem.

Thank you,
Roy Bynum


----- Original Message -----
From: Rick Walker <walker@cutter.hpl.hp.com>
To: Paul Bottorff <pbottorf@nortelnetworks.com>
Cc: HSSG <stds-802-3-hssg@ieee.org>
Sent: Thursday, April 06, 2000 10:45 PM
Subject: Re: Interface reality check


>
>
> Dear Paul,
>
> > "Paul Bottorff" <pbottorf@nortelnetworks.com> writes:
> > It doesn't look like 64/66 can be extended to ANSI T1X1 systems.
> >
> > So how is 64/66 going to extend the header mappings?  The T1X1
> > proposals relay on the <length><type><crc> to provide other frame and
> > header types for extended environments.  In particular the CRC check
> > allows validation of the <type> field giving a broad range of format
> > extensions.  The header CRC in ANSI T1X1 formats become essential for
> > the extended header fields used to address ring networks.
>
> 64/66 transparently supports all Ethernet packet signalling semantics.
>
> Ethernet packets include a two-byte <length/type> field.  The
> <length/type> code is protected by CRC32 and is therefore quite
> reliable.
>
> The current mappings are:
>
>     L <= 1500     ; the frame is an LLC data frame
>     L = 34,824     ; the frame is a MAC control frame
>     L = 33,024     ; the frame is a VLAN-tagged frame
>   none of the above ; private use Type-frame
>
> This leaves a very large number of type indicators currently undefined
> by Ethernet.  I expect that they can be used to create ANSI T1X1 packet
> types if needed.
>
> Best regards,
> --
> Rick Walker