Re: What is 802.3ae WAN-PHY?
Hi Osamu:
The semantics of SONET management can not be preserved by the 10GENIE
approach. Any transform performed by the ELTE will be approximate. Worse it
will become the IEEE's problem to determine how to perform the transformation.
IPG gaps do not occur at regular time intervals like SONET overheads. This
means the timing relations in any management procedures will not be
preserved. The results of timing shifts in the management information will
require very careful consideration not only against specifications, but
against implementations to assure they will work in practice.
Here are some thoughts on the problem areas:
B1- Just sending B1 to the WAN PHY does not help. How can the
WAN PHY check the number of errors? This means that the ELTE
will then need to report the number of errors to the WAN PHY
instead.
B3- Same problem as B1. ELTE needs to send the number of
errors to the WAN PHY.
G1- Who generates it? We want to terminate the PATH at the
WAN PHY. Therefore all the detected defects would need to be
reported to the WAN PHY, which would then send a G1 to
the ELTE. Note that the WAN PHY would also report Loss of Packet
delineation through G1. Loss of packet delineation can only
be detected by the WAN PHY.
J0, J1, C2, K1, K2, S1 - These octets have fixed values.
The WAN PHY simply sends them to the ELTE.
SONET timing considerations would need to be addressed
correctly.
2a- How often can these overheads be sent to the ELTE?
2b- Does the WAN PHY guarantee enough IPGs to satisfy
SONET timing requirements?
2c- Can G1 report the defects on the last SPE in time?
Path is no longer terminated end-to-end.
The WAN PHY should terminate the PATH and not the ELTE. Routing
the Path status through the WAN PHY does not make it the
Path Terminating Equipment. Faults at the links between the
WAN PHYs and ELTEs are not being covered by B1 and B3. The
path is not terminated end-to-end.
The solution using a SONET-format frame is easy. The management operations
of the ELTE simply follow SONET rules which are understood by the teams
developing the SONET sides.
Cheers,
Paul
At 09:02 PM 4/6/00 +0900, Osamu ISHIDA wrote:
>
>Dear Praveen,
>
>Your illumination on "preserving the notion of section, line & path"
>guided me to re-consider "How far 10GENIE can support SONET
>functionality and its overhead bytes?"
>
>The answer in my heart at present is "Everything, if you want".
>
>My careful consultation with ITU-T G.707(03/96) where SDH overhead
>bytes are defined, this was like a whole day reading of a myth
>written by Latin even to me, has now convinced me that 10GENIE can
>support almost all the OAM&P in the existing SONET/SDH infrastructure.
>In other words, if you want, the Ethernet LAN-PHY with 10GENIE can
>send/receive all the SONET/SDH OAM&P information or its equivalence
>without using SONET frame.
>
>Only exception is the B2 bytes in line overhead; bit interleaved
>parity (BIP) 1536 (= 8*192 bits). The B2 bytes enable us to monitor
>the Line bit-error-rate (BER) of 10^-3 or lower, whereas the B1 byte
>(Section BIP8) or B3 byte (Path BIP8) supports BER of 6*10^-6 or
>lower. I do not believe this sensitivity up-grade is worth consuming
>192 bytes per 100 Ethernet Packets.
>
>Of course I know we need some mapping or conversion in ELTE; one
>example is the bit-error-rate monitor that will be equivalently
>supported by the 8B/10B code violation or the 64/66 two-bit-header
>violation monitor. However, at present, I see no significance in
>these mapping/conversion issues if we remind the fact that LAN-PHY
>with 10GENIE is a real Uni-PHY; no physical WIS (SONET framer).....
>No, this is not true, we still need WIS for 10GENIE ordered-set
>insertion/removal, but I think this is much simpler than the SONET
>framer.
>
>As for the ratio of overhead to payload, I do not think it
>unpredictable. What Mr. Shimon Muller proposed in Albuquerque is
>that we have minimum guaranteed IPG bandwidth in the average, isn't
>it? Furthermore, if we carriers want, we can choke the MAC rate to
>steal the customer's bandwidth :-). What a nice system Shimon has
>invented!
>http://grouper.ieee.org/groups/802/3/ae/public/mar00/muller_1_0300.pdf
>
>Anyway, I greatly appreciate your interest on the 10GENIE approach.
>
>Best Regards,
>Osamu
>
>http://grouper.ieee.org/groups/802/3/10G_study/email/msg01965.html
> http://grouper.ieee.org/groups/802/3/10G_study/email/msg01968.html
> http://grouper.ieee.org/groups/802/3/10G_study/email/msg01971.html
>
>At 7:59 PM +0900 00.4.5, Osamu ISHIDA wrote:
>> Jonathan, Praveen,
>>
>> Thank you for your feedback.
>>
>> (1) I want to know "Why SONET framing" just for the short jumper to ELTE.
>> How it acieves "low cost" WAN access? What is its basis?
>> Any perspective on the SONET framer side would be greatly appreciated.
>>
>> (2) I do not see any critical issues regarding the amount of OAM&P data.
>> I do not expect full-SONET compatibility in 10GENIE, especially here
>> in 802.3ae. But even in full compatibility, SONET overhead bytes
>> defined for OAM&P are less than 30 bytes/125us(=155,520 bytes) if we
>> exclude the 192 bytes for B2 (Strong bit-interleaved parity for
Line).
>> This includes all section/line/path overhead bytes except the B2.
>> 30 bytes for every 100 Ethernet Packets (=100 IPG) sounds easy to me.
>>
>> Best Regards,
>> Osamu
>>
>> At 11:21 AM -0700 00.4.4, Praveen Kumar wrote:
>>>>Question: while the 1:1 logical connection is easy for me to make, would
>>>>there be any issue regarding the amount of data that could be carried
in the
>>>>SONET overhead compared to the amount of data that could be carried in the
>>>>IPG?
>>>
>>> I think there is still quite some work to be done with respect to mapping
>>> the SONET (or OAM&P) overhead onto the IPG. For example, even if we decide
>>> to use the IPG to carry the overhead, it would still be useful to preserve
>>> the notions of section,line & path. How is this layered overhead going
to be
>>> distributed. Also, it would still be useful to allow multiple 10G
signals to
>>> be multiplexed to a higher rate signal downstream. SONET framing does
all of
>>> this for us TODAY.
>>> Another issue associated with using IPG to carry overhead is that, the
ratio
>>> of overhead to payload is now a function of payload (packet) size. This
>>> means that the bandwidth consumed by the overhead channel (IPG) is now
>>> unpredictable and Iam not sure if carriers are going to like this.
>>>
>>> Nevertheless, I see some benefits associated with the 10GENIE approach. I
>>> think the question of "Why SONET framing" has not been convincingly
answered
>>> by the "WAN PHY" proposal. For example, SONET is not the only transport
>>> network. What if one needs to connect the 10G WAN link to an all-optical
>>> (non-SONET) wavelength switched transport network. Is the STS signal the
>>> most optimal in this scenario?
>>>
>>> -Praveen
>
>
Paul A. Bottorff, Director Switching Architecture
Enterprise Solutions Technology Center
Nortel Networks, Inc.
4401 Great America Parkway
Santa Clara, CA 95052-8185
Tel: 408 495 3365 Fax: 408 495 1299 ESN: 265 3365
email: pbottorf@xxxxxxxxxxxxxxxxxx