1U Converged Switch Proposal

The telecommunication operators are investigating and verifying the Metro Ethernet Technology (such as BT's 21CN programme), and proving that ethernet can provide a viable alternative to SDH/SONET in the lab and in limited live deployments. The transition to Metro Ethernet PSN is starting to happen now.

As the core network is updated from SDH/SONET to a Metro Ethernet PSN, the customer equipment connected to the network via a TDM link, such as PBXs, will also need to be maintained. There is a huge installed base of TDM equipment worldwide, and the equipment will not be updated immediately. Low cost converged switches are needed to allow the customers to keep their existing equipment by providing the interface between the legacy TDM equipment and the Metro Ethernet PSN.

In parallel, the mobile operators are also looking to reduce their dependence on the SDH operators to provide their backhaul, and move to install their own Metro Ethernet PSN. A large percentage of their Opex goes to the SDH operators to provide a few E1/T1 TDM links to each mobile base-station. As the mobile data requirements increase, more TDM links will be required, and the Opex escalates. Replacing the backhaul with their own Metro Ethernet PSN is estimated to reduce the mobile operators Opex by more than 70% per year.

The transition to Metro Ethernet PSNs will be dependant on geography, and will take many years to complete. Eventually the world will be Metro Ethernet PSN-based, but it could take more than 20 years. In the meantime, equipment to enable the transition with both TDM and Ethernet interfaces will be required.

Business Opportunity

The transition to Metro Ethernet PSN has started. Any location with TDM-based equipment will need a converged switch with both TDM and Ethernet interfaces to enable connectivity into the Metro Ethernet PSN. This includes business customers and multi-tenant residential buildings, as well as the mobile operators interested in backhaul. The key difference between the different applications is the quality of the recovered clock. Network synchronisation is required regardless, and a key challenge today is in reducing the cost of the synchronisation.

IEEE 1588-2008 will offer this capability at a price affordable to the network operators for widespread deployment.

What Product Is Needed?

A product providing the interface between TDM and the Metro Ethernet PSN needs to perform four functions:

Metro Ethernet Switch
Ethernet Switching is defined primarily by the IEEE, with the ethernet Layer 1 and Layer 2 defined by IEEE 802.3 and IEEE 802.1, and the IETF, through RFCs. The ITU and MEF are building on these standards to make ethernet suitable for use in the Metro environment.
Circuit Emulation of the TDM Circuits over Ethernet PSN, Pseudowire setup (across the Metro Ethernet PSN) and control
Circuit Emulation and Pseudowires and defined by the IETF, through the PWE3 (Pseudo Wire Emulation Edge to Edge) working group. They call on other IETF groups, specifically L2TPEXT, L2VPN and MPLS to provide the control plane and tunnelling features. The ITU and MEF are building on these standards to make Circuit Emulation Services (CES) suitable for use in the Metro environment.
The TDM Interfaces are defined by the ITU, defining the physical, electrical and timing characteristics of the E1 and T1 interfaces. The Japanese have their own requirements for the J1 interfaces.
Clock Distribution across the Ethernet PSN
Clock synchronisation is implicit in the SDH interface requirements, and therefore not explicitly defined. Clock recovery defines the method used at the receiver to recover a clock at the transmission frequency, and either adaptive or differential methods are used. To ensure synchronisation across a PSN network a common reference clock is needed, and several methods (including GPS) are currently used. The IEEE are defining the Timing over Packet standard in IEEE1588 that is intended to provide a low cost alternative to common reference clock distribution.

CES Processor

A CES Processor Subsystem consists of the TDM connectors (RJ-45 or BNC), the line terminations and protection, the Line Interface Unit (LIU) and Framer (for structured frame support), and the CES Processor for the data plane processing. A separate CPU may also be required for the control plane.

Three approaches have been identified to perform the CES Processor Function:

OPTION A: 3rd party module containing the CES Processor, Transceiver (Framer & LIU), clock recovery and a high stability oscillator. Module is provided with the data plane software pre-loaded. Module plugs onto the ethernet switch module to provide CES capability. It offers the most expensive option compared to the other solutions.
OPTION B: Dedicated CES Processor with embedded clock recovery. Requires external transceiver CPU and high stability oscillator. Drivers are provided by the vendors, and they offer an API-type interface to the host CPU. It offers the lowest cost option compared to the other solutions.
OPTION C: Generic Network Processor, with separate clock recovery. Requires external transceiver and high stability oscillator. The CPU may or may not be embedded within the Network Processor. The data plane software is provided by the vendor to perform the CES and Pseudowire functionality. Drivers are provided by the vendors, and they offer an API-type interface to the host CPU. The cost is between the fixed and modular solutions, but it does offer additional flexibility.

Clock Distribution and Recovery

Clock synchronisation across a telecommunications network is critical as it ensures that no data is lost due to buffer slips and overruns. Lost data on a voice call is a minor inconvenience, with occasional clicks reducing the quality of the call. Lost data during a data transfer can cause retransmissions, increases the transfer time, or can cause connected devices to fail to operate. Synchronisation ensures that all receivers are operating at the same frequency as the transmitters, and no data is lost due to clock frequency mismatches.

The CES Processor provides the data plane processing to enable constant bit rate E1/T1 streams to be carried over a packet switched IP or MPLS ethernet network. The packets containing the TDM data are transparently carried over the Metro Ethernet PSN so that the TDM streams can be reconstructed at the far end. The TDM interfaces at both ends need to be synchronised to meet the requirements defined in the G.823 (E1) and G.824 (T1) timing standards.

An ethernet network is asynchronous; there is no link between the frequency used to transmit and receive data on two different devices and the packet delay between two devices is not constant. Therefore, unless there is an external means of clock distribution, the receiver is required to recover the frequency of the transmit clock.

The two main methods of clock recovery are Differential and Adaptive. Differential clock recovery uses a Common Reference Clock at both ends to synchronise the transmit and receive clocks. If a Common Reference Clock is not available, adaptive clock recovery must be used, where the rate of received packets is used to calculate the transmit clock frequency.

The other key aspect of clock distribution is the source of the Common Reference Clock. There are established methods of delivering the Common Reference Clock, for example from GPS, but the emerging IEEE 1588-2008 standard appears to offer a much lower cost and more versatile alternative.

For more information about Clock recovery see the Clock Recovery White Paper.

Xentech Solutions Converged Switch Solution

The Xentech Solutions product is a 1U converged switch with integrated IEEE1588 Slave support

The clock recovery FPGA allows for the Reference Clock selected from IEEE1588-2008, recovered receive clock from the TDM ports, the local oscillator or external clock input. Differential and Adaptive clock recovery schemes supported within the FPGA, and the TDM Transmit clock per port and System clock are selectable from adaptive, differential or Reference Clock sources.