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

Re: [802.3ae] Clarification of the 10GBASE-W ELTE function

Here are some of my thoughts on the T1X1 contribution.

Gary Nicholl

I would argue that the synchronization requirements and associated ELTE 
functionality are different depending on whether the 10GBASE-W is connected 
to an OC192c tributary port on a SONET ADM or to an OC192c transponder port 
on a DWDM system.

The T1X1 contribution focuses on the first of these, i.e. connecting to an 
OC192c port on an ADM. Such a port is actually section/line terminating and 
includes a full pointer processor. In this case I agree with the argument 
in the contribution that the necessary 'ELTE path relay function' 
essentially comes for free. It should therefore be possible to directly 
connect a 10GBASE-W interface to an  OC-192c port on a sonet ADM, and it 
should pass traffic error free.

But even here there is one wrinkle that is not addressed in the 
contribution. The 10GBASE-W uses a 20ppm clock source (not in itself an 
issue as this complies with the sonet minimum system clock specification, 
and is what has been used successfully on POS interfaces in the past) . 
However, unlike POS, the 10GBASE-W specification does not allow loop (i.e. 
line) timing. So the only option is to configure the interface for 
'internal' timing using the free-running 20ppm clock source. If you connect 
such an interface to an OC-192c port on a sonet ADM then, although the 
traffic will still pass error free (as described above and in the 
contribution),  you will get continuous pointer adjustments (PJCs) at a 
rate equal to the difference in frequency between the 10GBASE-W interface 
clock and the sonet network clock (likely to be Stratum 1). These PJCs will 
be detected and reported at every node in the network that the OC192c 
signal passes through. While the PJCs in themselves are not a major issue 
(i.e. do not cause any bit errors), they do represent an operational 
challenge for the network operator. In a synchronous sonet network the 
operator would not expect to see continuous PJCs reported from any node. 
Continuous PJCs in such a network are usually an indication of a 
synchronization failure and that one of the nodes has lost traceability to 
the Startum 1 network clock. As such monitoring PJCs is one of the few 
tools available to the operator to detect and isolate synchronization 
failures in the network.  A network operator would find it difficult (if 
not impossible) to distinguish between PJCs resulting from a true 
synchronization failure and those from a free-running 10GBASE-W interface 
connected to the network. For these reasons I find it hard to believe that 
any operator would allow a free running 20ppm 10GBASE-W interface to be 
connected to the network. I think if 10GBASE-W is ever to be widely adopted 
then 802.3 will eventually have to give in and support loop (line) timing.

Now connecting to a OC192c transponder port on a DWDM system is a little 
different. An OC192c transponder port is not the same as an  OC192c port on 
an ADM. It is not section/line terminating. It does not provide any pointer 
processing. It is really a simple 3R (OEO) regenerator. In this case the 
free running 20ppm clock is not the issue, as all DWDM systems are designed 
to lock onto and track to a sonet minimum clock, which is also 20ppm (note 
that this would have been a big issue with the original 802.3 plan to use a 
100ppm clock for the 10GBASE-W). The potential issue this time is related 
to jitter. The transponder interface is a simple OEO converter, and as such 
the jitter on the output (which is ultimately fed into the long haul dwdm 
network) is directly related to the jitter on the input (i.e. unlike an ADM 
the transponder interface on a dwdm system does not 'reset' the jitter 
budget). All OC192c transponder interfaces that I am aware of are designed 
under the assumption that the OC192 client signal (be it from an ADM or a 
POS interface on a router) complies with standard sonet jitter 
specifications (as defined in GR253 and whatever the equivalent ITU 
document is).  However the 10GBASE-W interface is based on ethernet jitter 
specifications and this might ultimately limit the performance of the DWDM 
System (note that the 10G ethernet specs allow up to 3X the jitter of an 
OC192 interface).

I am not saying that  it is impossible to  directly connect a 10GBASE-W 
interface to an existing OC192 DWDM system, but it is certainly not a 'no 
brainer' and would require some analysis to understand the impact of the 
ethernet jitter specs on the overall dwdm network design (i.e the 
additional jitter from the ethernet interface may be what ultimately limits 
the transmission distance).

The other approach would be to design a new 10GBASE-W transponder interface 
that 'cleans up' the jitter on the input and presents the line side of the 
dwdm system with similar specs to those from a standard OC-192 signal. 
However this obviously requires a new plug in card specific  to the 10GBASE-W.

At 01:27 PM 1/16/2002, C. M. Heard wrote:

>FYI: the following contribution to T1X1.5 (written by Tom
>Alexander, David Martin, and Steve Gorshe) may be of interest,
>as it presents a detailed argument that ELTE can be
>realized within existing NEs -- e.g. as a 10GBASE-W line
>card -- and does not require a separate external piece of
>equipment.  That was exactly the message of the last slide
>in the WIS MIB design team's IETF52 presentation (see
>illustrating a 10GBASE-W interface on a SONET ADM.
>Mike Heard
>CONTRIBUTION#: T1X1.5/2002-027 (2X150270)
>TITLE: Clarification of the 10GBASE-W Ethernet Line Terminating
>Equipment (ELTE) function and its realization within existing SONET
>DESC: This contribution clarifies the issues that have been raised with
>regards to the proposed ELTE function, needed to adapt a 10GBASE-W
>Ethernet WAN-PHY signal to a SONET/SDH STS-192c/VC-4-64c signal. In
>particular, we demonstrate that such adaptation does not need
>additional NEs; that is, the ELTE function can be realized by existing
>NEs, and does not require new equipment to be added to a SONET/SDH
>CONTACT(S): Steve Gorshe (Steve_Gorshe@xxxxxxxxxxxxxx (503) 431-7440)
>SOURCE: Nortel Networks, PMC-Sierra