Blog

  • What makes a Cloud “Carrier Cloud”?

    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…)
  • Operators’ Options in choosing TDM/Packet based transport equipment

    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/AllNativeTransport-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…)

  • Is Circuit Emulation Bandwidth-Efficient?

    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 (Network Functions Virtualization) and its relation to SDN

    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.

  • 400G is decided to be the next rate after 100G

    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…)

  • RSVP-TE and OSPF-TE extensions for GMPLS

    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…)

  • Essentials of ASON GMPLS

    A presentation I created a while ago on basics of ASON GMPLS (more…)

  • Need for OSNR Testers for Pol Mux Modulations

    OSNR ( Optical Signal to Noise Ratio)  is a critical and important parameter in high speed DWDM links. If OSNR is not good it will seriously affect the distance reachability in DWDM systems before regeneration is required. OSNR testing is typically done with OSA (Optical Spectrum Analyzer).  There are standard test sets available to test OSNR of 10G lambdas; However when it comes to testing on high speed links at 40G and 100G based on Pol Mux-QPSK modulation techniques, OSNR testing in field leaves a lot to be desired. In fact there is no automated tool available today that can do OSNR testing for Pol Mux modulation.

    A POLMUX-QPSK transmitter consists of two quadrature (e.g. QPSK) modulators and a polarization beam splitter (PBS) to multiplex the two outputs on orthogonal projections. This is significantly different than conventional modulation schemes based on single polarized signal. An OSA is simply not designed to test OSNR on such dual polarized signals. There have been ways around methods suggested by leading T&M ( Test and Measurement)  vendors using manual methods of testing on existing OSA. But these methods are less accurate, complex and not repeatable. They are simply not aimed for field engineers and are very prone to human mistakes.

    The T&M vendors have plans to bring out OSA to test OSNR on Pol Mux signals; they are working on developing those solutions. However the progress has been very slow. It’s been a while now that we have been hearing of these plans. It is need of the hour to expedite these solutions since the industry need them badly today and without them accurate testing of OSNR would not be possible.

  • Soft Decision FEC ( SD FEC) versus Hard Decision FEC

    As data rates increase beyond 10G, the requirements for OSNR become stringent. This is because the advanced modulation techniques used at higher bit rates require higher OSNR performance. Low OSNR is directly related to poor BER performance in DWDM networks. FEC or Forward error connection is a method used to achieve coding gain for higher bit rates. It is a method of encoding optical signal with extra error detection and correction overhead bytes enabling optical receivers to detect errors and correct them. Thus FEC can reduce BER and effectively increases distances reachable by high speed signals without regeneration.

    Standard FEC and Enhanced FEC ( EFEC) are methods correctly used on 10G and 40G . Both call for adding extra 7% overhead information in traffic rate for the purpose of BER monitoring and correction. The standard FEC can result is 6 db coding gain ( which is infact quadrupling the distance) while Enhanced FEC can give an additional 2 to 3 % coding gain thus increasing distances further. Both Standard FEC and EFEC are called Hard Decision FECs-the decision rules for receiver are based  on two levels ( 1 or 0);  receiver decides between 1 or 0 depending on whether signal level is above or below a certain threshold level.  A new and more effective FEC is used by some vendors at  100G which is called Soft Decision FEC ( SD FEC).  SD FEC can additionally give a confidence factor in the decision used by receiver to decide between 1 and 0 meaning how far is the signal level from 1 or 0 this results in an additional coding gain of 1 to 2 db and hence resulting in overall improvement of 20% to 40% for distance reachability on 100G. Most vendors use SD FEC these days on transponders used for long haul applications while the metro transponders are still implemented with hard decision FEC to keep the price levels low. However  it should be kept in mind that SD FEC comes at the cost of adding 20% overhead information ( FEC bytes) resulting in slightly higher optical rates.

    Without  FEC these days, the distance on high speed links would be severly limited. While Hard Decision FEC is very effective in increasing distances on 10G and 40G; Soft Decision FEC can addtionally provide longer distances and few regenerators on 100G.

  • Optical ASON or Electrical ASON!

    The debate still lingers on. When it comes to protection and re-routing  on High speed links, what is the benefit of using Optical ASON versus Electrical ASON.

    The Optical ASON relates to lambda switching ( Also called WSON-Wavelength Switched Optical Network). This necessitates the need of using at  minimum Multi degree and directionless functionality. Using colorless functionality gives more degree of freedom and flexibility since in case of non-availability of a particular wavelength, ROADM has the functionality to change the color of wavelength also. When it comes to Electrical ASON, it is referred to as “ODU switching” at electrical layer of OTN switch. This necessitates the use of OTN switch along with ROADM. While Optical ASON gives one an advantage of lambda switching; the Eletcrial ASON gives advantage of control over more granular traffic at ODU level going as low as 1G traffic. In contrast, lambda switching can help to save on transponder resources because the same transponder can change direction or color thus there is no need to have multiple transponders for multiple restoration paths-a  benefit not available on electrical ASON which would need multiple lambda paths to be created from Day one. Electrical ASON on the other hand gives much faster restoration times compared to Optical ASON. So what is the verdict ?

    The rule of thumb is following: If traffic granularity is less and the lambda is not filled completely, Electrical ASON is much more optimized and cost efficient, on the other hand if lambda is filled with traffic ( multiple ODUs occupying complete lambda)  that needs same SLA of restoration ( Meaning complete Lamda needs to be switched) then Opitcal ASON is much more optimized and cost efficient and ends up saving on the number of transponders.