Research firm, Heavy Reading, defines “P-OTS as a platform that combines SONET/SDH, connection-oriented Ethernet, DWDM and, depending on where the platform is used within the network, also optical transport network (OTN) switching and reconfigurable optical add-drop multiplexers (ROADMs)”
As per Heavy reading, there is a growing trend now, with more and more operators asking about IP/MPLS capabilities in P-OTS platform. Transport groups inside operators have expressed their interest to add layer 3 functionality to P-OTS platforms. Operators favor integrating L0 to L3 in P-OTS platform so that one platform can meet all their needs. This new requirement is addressed in P-OTS 2.0. According to Heavy Reading, there are four differentiating features of P-OTS 2.0 compared to legacy P-OTS.
- There is change of focus from TDM to packet functions.
- Pure packet implementation of P-OTS is ramping up.
- 100G is seeing more applications in metro area
- Switched OTN has entered Metro area, removing the need of SDH fabric in new network elements.
Looking at what is present in the market today; the P-OTS platforms leave a lot to be desired. It would be hard to find a product optimized for all layers. Legacy P-OTS platforms are optimized for certain applications but not for all. Depending on where the vendor is coming from, some P-OTS platforms are optimized for TDM applications but not for ethernet applications. Some are strong in DWDM but not in packet and TDM. Some vendors position to carry Ethernet over OTN; still others vouch that carrying Ethernet in native form is better and keeping OTN as option on P-OTS platform. P-OTS, thus, has become more of a marketing term rather than the platform that can address all the needs, desired for such platforms.
P-OTS 2.0, therefore, should be able to address all layers (layer 0 to 3) effectively and in optimized way. Operators would not like to have platforms (similar to P-OTS) that are geared and focused on few applications and leaving the others as just “supported on platform”. P-OTS platform shall be modular and platform based preferably supporting a family of platforms for applications from metro to core. Cards should be interchangeable between platforms. The platforms should support IP/MPLS but above all GMPLS across Layer-0 to Layer-3. Again it should be possible to run all layers independently or all layers run tightly together, seamlessly. The layers should communicate with one another, for example, for fault management. These are the needs of the operators today and vendors ought to rise to this occasion.
API is the most powerful feature of SDN- the programmable network. It will open a world of opportunities in terms of flexibilities and features for both operators and app developers. The current networks are rigid and make operators “lock in” to vendors. SDN will help avoid this lock in by making a network a flexible platform which will respond as operators desire. This will reduce OPEX that comes because of manual provisioning of services and will help in bringing innovation because the operators may develop new applications easily and flexibly.
SDN focuses on Network as a service or what is termed as “NaaS” in cloud computing. With Naas operators will have control over bandwidth, routing and QoS of their data. They will be able to give differentiated services. With SDN, operators can leverage the existing NaaS initiatives and build up their SDN infrastructure from there. The knowledge and skills gained with NaaS today will be and prove very useful to develop SDN ecosystem of apps. The experience of these operators can help the new comers into SDN to learn from them.
In cloud, lies opportunities for carriers. What traditional cloud has not been able to achieve, carrier cloud has all those ingredients to deliver. What makes carrier cloud different than traditional public and enterprise clouds?
First few words about what is public and enterprise cloud? Public Cloud are designed on the concept of “ Scale Out” i.e. as applications and users grow, more processing power and storage is needed, this necessitates adding more servers to cloud. These are commodity servers, so building and expanding network in this way is neither expansive nor time consuming. The resilience is always brought in by software and not hardware; in fact hardware is even dubbed as “Designed-for-failure”. Enterprise cloud, on the other hand, is built on the concept of “Scale up”. Processors and Storage capacity in cloud are upgraded rather than “added” as in public clouds. Since many enterprises are using legacy software which are not designed for the usual “Scale Out” concept of public clouds, therefore such enterprises opt for enterprise cloud which is least disrupting and does not need any forklift upgrades. Resilience, here, is based on hardware rather than software.
(more…)
In my last post, I had explained that it would be bandwidth in-efficient to carry TDM over Ethernet/IP links; today I came across an interesting white paper by Heavy Reading which indirectly does point to this fact and argues that it is better and efficient to keep TDM traffic completely over TDM network. The white paper can be found at
www.ecitele.com/CampaignDocuments/All–Native–Transport-HR.pdf
The white paper focuses on metro aggregation area and argues that in the foreseeable future, transport in this area ought to be “All Native” i.e. TDM carried as TDM transport and Packet in its native form most likely as MPLS-TP (All within one network element). It elaborates that it is still a far cry to have an All IP transport considering that the nature of traffic in today’s network is mostly mixed; that majority of revenue still comes from TDM circuits and most importantly considerable investments have already been done in TDM equipment by incumbent operators that they would like to protect. The paper points out that majority of products are either optimized for TDM or IP but not for both. The best approach, thus the paper maintains, would be to have the All-Native transport supported by one network element that carries both kinds of transports in what is called as P-OTS (Packet Optical Transport System). The P-OTS system is also called “Hybrid” network element by some vendors. According to Heavy reading predictions, by 2016 even though the majority of the traffic will be IP but the major revenues will still come from circuit switched traffic.
My take on this is (more…)
Let’s face it. As an operator, you are faced with a situation of deciding between circuit emulation over Ethernet and carrying TDM data as pure TDM transport; what would be your choice?
In fact! There seems to be some confusion regarding the extent of efficiency when circuit emulation is used to carry TDM data over Ethernet. I came across two application notes offering two different opinions about the efficiency. One from Vendor Orckit you can find the application note at the following link.
https://www.orckit.com/ptn_technologies/196.htm
The application note is titled “Circuit Emulation Bandwidth Efficiency”. The application note contends that Circuit emulation is highly bandwidth-efficient. It concludes that 4006 VC-12 can be transported in 10GE versus 4032 in STM-64. This gives an efficiency of 99 .4% they conclude.
My curiosity took me to another link where Fujitsu describes an efficiency of around 50% when using circuit emulation. The application note can be found at the following link
https://www.fujitsu.com/downloads/TEL/fnc/whitepapers/Fujitsu_Wireless_Backhaul.pdf
So what exactly is the true situation? And why are the calculations leading to such a big difference.
Let’s take Orckit white paper as an example.
The white paper compares the number of VC-12s that can be inserted in 10GE versus STM-64. Simple mathematics of having 63 x VC-12 in STM-1 leads to 4032 VC-12s in STM-64.
Let’s do the calculation for how many VC-12s can be carried inside one 10GE.
Single VC-12=36 Bytes
Overhead needed to carry a single VC-12 is calculated as following
Overhead for Ethernet Frame = 14 Bytes (6 Destination MAC + 6 Source MAC + 2 Ether type)
Checksum=4 Bytes
Interframe Gap = 12 Bytes
Preamble = 8 Bytes
MPLS+PW Label Bytes = 4+4=8 Bytes
CEP (RFC 4842) Overhead = 8 Bytes (Ignoring RTP bytes for this example)
Total Overhead = 54 Bytes
Calculating the number of VC-12 services in 10GE = 10,000,000/54*8*8000= 2893 Services
Comparing against SDH STM-64(4032), the bandwidth efficiency is around 72%
This is actually different then Orckit arrived figure. Looking deeper, I found out that Orckit combined 21 VC-12 as one service to arrive at the bandwidth efficiency of 99 %. However combining more VC-12 in one service will not be delay efficient. Since more real time services need to be buffered before transmission.
So the conclusion is that carrying TDM traffic inside Ethernet is not bandwidth efficient. While there might be ways to improve bandwidth efficiency by combing more TDM channels emulated in one Ethernet frame but that will not be delay-efficient for real time services. Operators need to be aware of these issues when going for circuit emulation. In my view, the circuit emulation would be beneficial in cases where there is a lot of Ethernet traffic but there is a requirement to carry a small amount of TDM data inside that Ethernet network. Using Ethernet to carry predominant TDM data is not a very good idea owing to the issues of bandwidth efficiency as discussed in this
post.
NFV is all about visualizing network as seen from the perspective of IT. It leverages standard IT industry virtualization concepts to consolidate many network elements onto industry high volume servers, switches and storage. The network is visualized as servers that will be able to deliver services to operators as they are given by today’s hardware based diverse platforms.
Routers and other Network elements will transform into servers. This will significantly reduce cost, complexity, inventory, space and power requirements of todays’ networks. Anything can be virtualized like routers, firewalls, SGSN/GGSN, Radio Access Network Nodes, eNodeB etc.
It includes the concept of multi-tenancy of a resource which will allow the use of single platform for various applications allowing operators to save costs
How the concept of NFV is different from SDN. NFV does not need SDN for its implementation and vice versa. Both can work independently. However they do have synergies. NFV can work without SDN on the concept used in today’s datacenters. But the concept of SDN in which the data and control plane are separated will greatly enhance performance and facilitate operation and maintenance procedures. The NFV’s focus is on the network element and combined with the forwarding concepts of SDN makes a good combination for deployment. NFV is closely aligned with the SDN concept of using commodity servers and switches.
Operators have already led an initiative and formed an Industry Specification Group (ISG) under ETSI to work for the standardization of NFV. The first meeting of ISG has taken place in January 2013; the group is working on developing broad consensus between Network and IT industries to have a consensus on developing standards related to NFV.
The past year was hectic in terms of discussions regarding what could the next client rate for Ethernet and at the same time discussions were going on to decide the next line rate. There was a debate on whether the industry should go for 400GE or jump straight to 1 Terabit. Earlier in the same year major optical vendors had already announced their plans for 400G chipset setting pace in the industry that 400G line rate might be something the industry could find consensus on. ALU showed back in May 2012 that it has seen as many as 20 customers interested in 400G line optics. Ciena unveiled around the same time the readiness of their chipset to support 400 G line rate. The major chipset vendors were of the view the cost and power requirements to develop 1 terabit line rate might simply be cost prohibitive. Infinera was a lone voice advocating 1 terabit line optics and had already unveiled that its 1 terabit chipset would be ready in a couple of years. Around the same time the Ethernet industry was working on understanding and defining the requirements for the next client rate beyond 100g. An adhoc committee was setup by IEEE chaired by John D ‘Ambrosia ( Chief Ethernet evangelist at Dell Inc.) to study the bandwidth assessment for the next client rate and put forward a proposal in this regard. While there were voices heard that 1 terabit should be the next client rate however the 1EEE ad hoc (more…)
Packets in MPLS are routed according to preconfigured label switched paths (LSPs). When packets are received, label lookup is performed from which it is identified to which LSP packets belong to and hence it identifies the next hop of the packet.
GMPLS generalizes the concept of MPLS. Instead of the concept of labels, GMPLS uses any other property like time slot in TDM, Wavelength in DWDM or (more…)