Silicon Solutions Enable Migration to Next Generation Networks

Moving from the multiplicity of technologies and protocols that make up today’s telecommunications networks to the integrated next generation networks requires a transition technology in the form of a Universal Gateway that can bring any-to-any connectivity.


  • Page 1 of 1
    Bookmark and Share

A Universal Gateway is a logic solution that can truly provide any port, service, functionality and interworking/translation capability from any protocol to any other protocol in layer one and two of the seven-layer model of communication. Such a Universal Gateway will provide the most efficient path to network, system and linecard convergence/consolidation, thus enabling and paving the path of the migration to Next Generation Networks (NGN). However, the related

complexity involved in such a Universal Gateway has made it impossible or at least impractical to try and implement it.

On the horizon, a new VLSI architecture is paving the way for emerging silicon solutions that are now capable of building this Universal Gateway. This will have a major impact on the migration to NGN.

Migrating to NGN: The Need & the Challenges

Figure 1 shows a high-level abstraction of a typical transport network. The figure demonstrates the major problems and shortcomings of these transport networks and the existing infrastructure, namely, complexity and inefficiency. This complexity is the result of the transport infrastructure which was built over years of changing services, technologies, systems and protocols. It was developed step-by-step through years of constant (though slow) changes, which were trying to accommodate new requirements, growing bandwidth, new customers and services while at the same time trying to reduce cost (CAPEX and OPEX), space and power consumption.

These all lead to NGN, which is all about convergence, consolidation and simplification. The main concept of NGN consists of moving away from today’s mixture of various transport networks into Ethernet and MPLS-based transport networks. This also implies moving away from all the legacy switching systems (X25, FR, ATM) into a single system based on the same Ethernet and MPLS.

While the concept may sound simple and straightforward, there are major challenges and obstacles. For one thing, there are many users who do not want to switch or compromise the existing services and interfaces they have today. Thus, any migration to Ethernet MPLS will have to support all the legacy protocols and interfaces of today’s layers one and two. And while any new network being installed might well be based on Ethernet and MPLS, it has to interconnect to the legacy network and support the same legacy services. And speaking of legacy in terms of existing lines and physical infrastructure, we would ideally have put fiber capable of at least 1GbE everywhere. The reality however is that T1 and E1 lines will be the major access infrastructure for years to come. There is also a technical need to compensate for the missing real time information (e.g. clocks) when serving applications like wireless backhauling, which need it.

Then, of course, there are the cost issues of migration. During transition, it is necessary to deal with the cost of supporting parallel networks and systems. And all of this will demand a huge amount of CAPEX & OPEX investment due to the need to purchase and install new systems and networks.

Given all these challenges, a new concept called “Universal Gateway” sounds like a solution, provided that it can be used to overcome these challenges. However, such a Universal Gateway has been considered not to be implementable by many experts.

Recent advances have shown how using a new VLSI architecture enables implementation of the Universal Gateway and one such implementation is now available for review and trial.

The Universal Gateway Framework

Figure 2 shows what we have in mind when discussing the desired solution. On the left side of the imaginary linecard or system shown in Figure 2, are the client or line side interfaces, while on the right side are the system or uplink network interfaces. This system or line card enables any type of access interfaces that are used today in transport networks including SONET/SDH, PDH and Ethernet.

More than this, this logic and circuitry can be part of any type of system regardless of it being a TDM system (e.g. MSPP, ADM) or router, multi-service switch, aggregator, MSTP and the like.

It provides any type of relevant client side, functionality and any-to-any interworking between legacy and new protocols and services. The client side includes ports for Ethernet, SONET/SDH and PDH along with any channelization. This side also has Layer 2 protocols including HDLC, PPP, LAPS, POS, ATM, GFP, PPP, Frame Relay and X.25 and bundles IMA, MLPPP, MLFR, VCAT and LCAS

The concept of interworking here involves any-to-any protocol conversion and packet editing along with all encapsulation schemes, PWE3, CES (all flavors) and QoS and traffic engineering. On the network and uplink sides there are Ethernet, SONET/SDH (any rate) and system interfaces that include a generic switch fabric interface, Ethernet switch and TDM (e.g. STS-1 cross connect) switch.

Obstacles & Challenges, Using the Universal Gateway

In the section above, we listed the major obstacles in migration to NGN. Assuming that the Universal Gateway functionality is implemented in whatever technology, one can easily see how these obstacles are overcome. Service continuation is trivially solved since we enable any legacy service to continue even if the whole transport network is changed from SONET/SDH to MPLS/Ethernet using PWE3 (anything over MPLS).

The interworking of networks is also achieved since the Universal Gateway enables any interworking between any Layer 1/Layer 2 combinations. Thus, regardless of which side of the two networks implements it, the Universal Gateway enables this side to interwork with the other network seamlessly. When it comes to clock and time distribution, having the CES and clock distribution mechanisms functionality in place, completely addresses this.

Next on our list is the issue of supporting multiple networks and systems. Having this functionality between different transport networks solves it by providing seamless interworking (the networks can be considered as one system) between the various networks. Additionally, the need to continue and utilize the huge copper (e.g. T1/E1) installed lines is addressed by the Universal Gateway, which enables us not only to continue utilizing T1/E1 as in today’s networks; it also enables us to move to Ethernet over T1/E1 using GFP and VCAT/LCAS.

When it comes to multiple systems, it can be shown that a Universal Gateway, which supports any type of system backplane and internal interface, can easily be added to any type of system. This is true for any type of MSPP, MSTP, router, switch and multiservice switch. Therefore, assuming the system vendors add it to their existing and new systems–any NGN can be built using minimal (ideally one) types of systems without compromising services and any interworking with legacy networks that might be required.

The same argument is also valid for the obstacle/challenge involving expenses. Given that this functionality can be added to any type of system, this will significantly reduce the CAPEX/OPEX associated with migrating to NGN. The same systems used today can be utilized for building NGN, since if the Universal Gateway is added to them, the same system can be part of SONET/SDH legacy transport network and/or an NGN Ethernet/MPLS network. Therefore, a carrier can perform this transition without any investment in new systems just by adding Universal Gateway linecards to its already deployed systems.

If a carrier selects to buy new types of transport systems, having the Universal Gateway functionality as part of them will enable the carrier to continue the deployment of all its deployed systems and networks, while adding new systems (and networks) only where and when it makes sense for it.

Implementing the Universal Gateway Using Silicon

The problem with the Universal Gateway approach is that implementing so many protocols and functionality for large bandwidth is perceived as impractical and undoable by many. Indeed, we also believe that this is true when trying to apply conventional VLSI architecture and circuitry. New and out-of-the-box thinking is what’s needed to overcome this problem.

One successful attempt was made by Siverge Networks when creating the Matrix architecture. This new architecture is a web of logic and memories that are connected to each other in a broadcast Matrix (Figure 3). The basic concept here is to create a very efficient memory structure in which data, control, status and block interconnect information can reside for all the functional blocks and interconnection between them.

Thus, a web of interconnects and logic is created, which broadcasts the content of the memory (one channel every cycle) to all functional blocks. Each logic unit can look for and modify any portion of the broadcasted bits. The Matrix provides many desirable features that differentiate it from all conventional VLSI architectures.

First is to maximize memory and logic sharing by having one memory for all the logic blocks, and also implementing logic such that any mechanism or circuitry that is the same or similar between any two (or more) functional units need be implemented only once. This also minimizes interconnectivity overhead because the only communication is done through the Matrix memory.

To further optimize connectivity, each unit gets the data path width ideal for it. Thus, if certain logic is better dealing with bits while another is better dealing with bytes or long-words–each gets what it needs. The Matrix is built around a content switching concept; therefore it may process any number of different (or similar) channels, thus enabling the processing of any channelization level.

The logic is transparent such that one may decide to implement any protocol, service or functionality around it and the basic architecture stays untouched. This enables the addition of protocols and functionality very easily. The architecture provides enormous flexibility because any number of bits processed by any unit can be modified and reassigned dynamically. So, if some changes and enhancements are needed in the field–it is easy to implement.

The architecture of the Matrix described above was used to implement the SV36x0, which provides in essence a single device implementation of the most difficult part of the Universal Gateway. Figure 4 shows the needed logical units around the Matrix web of interconnects and memories. The red block shows the common logic that implements generic functions needed by two or more units. Function-specific logic is implemented separately in the units surrounding the Matrix.

The logical units in Figure 4 include most of the protocols, channelization levels and functionality relevant to the Universal Gateway. Using Siverge’s Matrix it was possible to embed all of them in a single monolithic device. We believe that this was doable only through using the unique features and optimization provided by the Matrix and discussed above. While Figure 4 is the real physical implementation of the SV364x device, a more conventional block diagram of this device when it comes to its functionality is given in Figure 5.

To complete the Universal Gateway functionality, a complementary FPGA is also provided that implements the interfaces to the Ethernet/MPLS world. The complete solution is shown in Figure 6. Given the circuitry in Figure 6, the task of actually incorporating the Universal Gateway functionality in any type of system is now very easy if not to say trivial.

In a stand-alone system such as a pizza-box, we use the Ethernet interface on the left side and now this is a Universal Gateway that provides any possible interworking between any two networks and underlying protocols. In an MSPP/MSTP system, the left SONET/SDH side can be connected to the TDM switch fabric while the left side can be connected to an Ethernet (MPLS) network and thus provide the any-to-any interworking between any TDM interface and a new Ethernet (MPLS) network. Alternatively we can use it in a closed loop mode where it is a server card without external interfaces. In this mode we perform the Universal Gateway functionality between any two linecards that are connected to the TDM switch fabric of the system.

In all other systems, whether based on packets/cells or switch fabric, the right side is connected to the packets/cells switch fabric and the TDM side is connected to a SONET/SDH/PDH line. The Universal Gateway functionality is now provided between this linecard and any other linecard connected to the system and thus provides the complete interworking capability between any network and the SONET/SDH/PDH network.

Migration to NGN is probably the most important transition for most, if not all, carriers and service providers. This is what they are expecting will dramatically change their CAPEX, OPEX and revenues for years to come. Yet, this migration encounters many obstacles and challenges that considerably slow it down and in some cases stop it altogether.

These obstacles can be completely overcome with the implementation of the Transport Universal Gateway, a functionality that enables interworking for any interface, protocol and service in Layers 1 and 2. While for many years it was considered impossible (or at least impractical) to implement, this is no longer true. New breakthrough VLSI architecture enables building this type of functionality in a cost-effective implementation.

Siverge Networks
Herzliya Pituah, Israel.
+972 9 9526600.