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:
>Colleagues,
>
>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
>http://norseth.org/ietf/hubmib/ietf52wisMibPresentation.PDF)
>illustrating a 10GBASE-W interface on a SONET ADM.
>
>Regards,
>
>Mike Heard
>
>CONTRIBUTION#: T1X1.5/2002-027 (2X150270)
>LINK: http://www.t1.org/FileMgr/GetOneFile.taf?FileName=2X150270&NW=Y
>TITLE: Clarification of the 10GBASE-W Ethernet Line Terminating
>Equipment (ELTE) function and its realization within existing SONET
>equipment
>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
>network.
>CONTACT(S): Steve Gorshe (Steve_Gorshe@xxxxxxxxxxxxxx (503) 431-7440)
>SOURCE: Nortel Networks, PMC-Sierra