Re: [802.3ae] Clarification of the 10GBASE-W ELTE function
Gary,
I hate to burst your balloon. "PJCs" do cause data errors. The PJC is in
response to the buildup of data block alignment offset. That means that
somewhere between PJCs, the data starts to get "bit" errors. The more of
them that there, the more that the data will be unreliable. This was seen
in the early POS interfaces (OC3/STM1) interfaces that I deployed before
the vendor has "loop" timing working properly.
Repeatedly, the 802.3ae Task Force has stated that the 10G Ethernet WAN
PHY was not intended to be a "client" signal on an ADM. Trying to "shoe
horn" it into an ADM is in violation of the purposes and intentions that
the Task Force had for the WAN PHY. The only recognized and supported use
of the 10G WAN PHY was to be a "peer" on an optical network though the
"ELTE". The "ELTE" is reflected in part by the T1X1.5 contribution of the
non-isosynchronous "path relay".
Thank you,
Roy Bynum
At 04:23 PM 1/18/2002 -0500, Gary Nicholl wrote:
>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