RE: 9.584640 (framing issue)
Perhaps this was explained at one of the meetings that I missed. I do not
understand how the 9.584640 rate can work. This might be the correct rate of
the OC-192 payload, but this does not account for the byte stuffing used
with PPP/HDLC (POS). That will reduce the rate in a difficult-to-predict
manner unless the LAN side uses the same encoding mechanisms.
Has there been some proposal for a non-POS encoding that doesn't byte-stuff?
Can anyone explain this? Paul?
CIENA Corporation Email: ddp@xxxxxxxxx
Core Switching Division Tel: 408-865-6202
10201 Bubb Road Fax: 408-865-6291
Cupertino, CA 95014 Cell/Pager: 408-829-8298
[mailto:owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx]On Behalf Of Paul
Sent: Tuesday, July 20, 1999 10:17 PM
To: rtaborek@xxxxxxxxxxxxxxxx; Toshio Ooka; HSSG
Subject: Re: 9.584640 (framing issue)
Sorry for dropping in a little late, but I'm supposed to be on vacation.
The 9.584640 is the exact rate of a OC-192 payload. Running at this rate
will allow the data to be encoded onto an OC-192 directly at rate. In
addition, this data rate allows running over the installed base of 10 G
DWDM regenerator networks.
To encode a 9.584640 G Ethernet steam on an OC-192 the encoding system must
not expand the data like 8b/10b does. Both the Nortel and the Lucent
proposals are capable of providing an encode which can be transported a
9.584640 G Ethernet data stream over OC-192.
At 02:29 PM 7/20/99 -0700, Rich Taborek wrote:
>I believe that the framing solution is a second-order task and that the
>order task is to determine if there is any possibility of supporting an
>Ethernet stream, consisting of variable sized packets at ANY MAC/PLS data
>which would eliminate any flow control requirements between Ethernet and
>Is 9.584640 Gbps this data rate? If not, is there any data rate that meets
>above requirement? If not, the HSSG speed objective should be 10.0 Gbps.
>Toshio Ooka wrote:
>> > I have assumed that the proponents of the 9.584640 Gbps MAC/PLS
>> > payload rate have selected that rate specifically to allow a SONET
>> > accept Ethernet payload at full rate as indicated in my #5a (below).
>> I believe that the rate specifically to allow a SONET links to accept
>> Ethernet payload
>> is great idea.
>> But to realize this idea, I think we need to have some framing solution.
>> After framing process, the length of the data on SONET will not affected
>> the content of the Ethernet payload data. POS solution is not suitable
>> Send Ethernet 10B code to SONET may be to fit SONET byte stream world.
>> Thank you for your prompt reply.
>> Best Regards,
>> Toshio Ooka @Sumitomo Electric U.S.A., Inc.
>> 3235 Kifer Rd, #150, Santa Clara, CA 95051-0185
>> Phone:(408)737-8517x232 Fax(408)737-0134
>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
Paul A. Bottorff, Director Switching Architecture
Bay Architecture Laboratory
Nortel Networks, Inc.
4401 Great America Parkway
Santa Clara, CA 95052-8185
Tel: 408 495 3365 Fax: 408 495 1299 ESN: 265 3365