{"id":626,"date":"2014-06-19T15:20:25","date_gmt":"2014-06-19T12:20:25","guid":{"rendered":"https:\/\/telcocloudbridge.com\/?p=626"},"modified":"2014-06-19T15:20:25","modified_gmt":"2014-06-19T12:20:25","slug":"the-marriage-of-ip-with-otndwdm","status":"publish","type":"post","link":"https:\/\/telecomlighthouse.com\/?p=626","title":{"rendered":"The Marriage of IP with OTN\/DWDM !"},"content":{"rendered":"

When revenue per bit starts falling and cost per bit starts increasing, it\u2019s time to think about alternative strategies to expand\u00a0Transmission\/IP network.<\/p>\n

As IP is predominant\u00a0traffic in Transmission networks, therefore any expansion strategy on Transmission should be driven by IP demands. Indeed, both IP and Transmission departments need to work for a joint and synergetic expansion strategy, in this regard.<\/p>\n

Hence, I intend to share with you some insights and tips that will enable you to plan the expansion of\u00a0IP and Transmission network in a holistic and synergetic\u00a0way. If you stay till the end, you will see how IP can live with lower layers of Transmission (DWDM, OTN, SDH, and L2) through a successful marriage.<\/p>\n

Whether you belong to IP department (responsible\u00a0for the IP\/MPLS domain) or Transmission department (responsible to run SDH, DWDM, OTN\u00a0and most recently Ethernet), there is some food for thought for you in this article. More specifically, I will show you how to put your traffic on the right layer that will reduce the TCO (Total Cost of Ownership) of your Core network.<\/p>\n

So let\u2019s see where is the problem?<\/p>\n

Problem#1<\/strong><\/h4>\n

The Problem#1 is that of treating both IP and Transmission as two different entities\u00a0\u00a0 in terms of any expansion strategy. There is a reason for that: classically, both IP and Transmission are run by separate departments. \u00a0Transmission (lower layer) is treated as a resource to serve IP layer (upper layer) without the need for Transmission to understand or help upper layer ( except connectivity).<\/p>\n

I will give you one example:<\/p>\n

Have you heard of the \u201cDumb Pipe\u201d approach?<\/p>\n

An approach, in which IP uses Transmission as transparent pipe. In other words, shifting complete aggregation, protection and intelligence to IP layer, thus keeping Transmission as dumb and non-intelligent pipe.<\/p>\n

For obvious reasons, this strategy is simple and easy to implement. As Transmission does not need to provide any other service except connectivity, therefore there is little or no interaction needed between IP and Transmission folks.<\/p>\n

But there is another side of this approach:<\/span><\/p>\n

More CAPEX and OPEX spending!<\/p>\n

How?<\/p>\n

Such operators need to consistently build up two layers in parallel: the IP layer and the Transmission layer.<\/p>\n

I call it \u201cGrow-Routers-Fast, Grow-Lower-Layers-Fast” (GRF-GLF) approach.<\/p>\n

In GRF-GLF\u00a0approach, Transmission is\u00a0participating\u00a0neither in aggregation, nor in protection or any intelligence for IP packets. Therefore, IP layer takes complete burden to\u00a0achieve\u00a0these objectives<\/a>. More specifically,\u00a0the bits, after entering into IP core, need to touch every core router\/IP layer on its way to destination. All this because, IP is the only layer that can aggregate, protect or route the traffic.<\/p>\n

As, all bits have to pass through the transit routers as well, so we end up building interfaces for three layers:<\/p>\n

    \n
  1. \u00a0Originating Core Router<\/li>\n
  2. Terminating Core Router<\/li>\n
  3. All Intermediate\/Transit Core Routers<\/li>\n<\/ol>\n

    Isn’t it unfortunate that the intermediate router has to take the burden of the bits that are not dropped or added by it?<\/p>\n

    Worst still:<\/p>\n

    With every scale of routers, there would be a need to\u00a0corresponding\u00a0scale the Transmission\u00a0resource. So indeed, we are constantly building routers and building Transmission with fast pace-\u00a0a GRF-GLF Strategy!<\/p>\n

    Problem# 2<\/b><\/h4>\n

    Secondly and in contrast to above, there is another approach that calls for “Router Offload\u201d. The term \u201cRouter Offload”\u00a0has been abused\u00a0a lot by opponents and\u00a0proponents\u00a0on both sides. “Router offload” in its simplest definition mean that any transit traffic at any intermediate core router should be offloaded to lower layer like SDH\/OTN\/ DWDM.<\/p>\n

    Therefore, core routers at any intermediate site do not need to be scaled for transit traffic. This will result in huge cost savings.<\/p>\n

    However, terms like \u201cRouter offload” and \u201cIP offload” are\u00a0pitched\u00a0in a sense that gives out a massage\u00a0that core routers are not needed at all. They go to the extent of even calling it \u201chollow core” designs with no core router in a network at all. Indeed, a wrong perception. Later on, I can show you that \u201cRouter offload” for some traffic does make sense but not for all kind of traffic.<\/p>\n

    It will also become apparent that Router offload is part of a solution but not a complete solution, if applied to all traffic.<\/p>\n

    What is the solution? How can IP and Transmission live through a successful marriage?<\/b><\/p>\n

    Having presented the problem, let\u2019s see how we can solve these issues.<\/p>\n

    I would call upon some statistics that will support me to solve these problems.<\/p>\n

    Some stats form\u00a0Cisco VNI-2013: (Annual report on future global data; following excerpts are from the updated report of June 2014)<\/p>\n

      \n
    1. Fixed internet data will rise at CAGR of 20% annually up to 2018<\/li>\n
    2. \u00a0Mobile data (includes Mobile data and Internet traffic) will rise at CAGR of 61% annually up to 2018<\/li>\n
    3. By 2018,Consumer Internet will represent two thirds of all IP traffic followed by managed IP at 20%<\/li>\n<\/ol>\n

      The key message here is that internet data will rise considerably (at CAGR 20%) more than any other data (e.g. enterprise data) in networks. And by 2018,\u00a0consumer\u00a0Internet\u00a0will be two thirds of all data carried over networks.<\/p>\n

      I repeat the key message is, \u201cInternet data\u201d ( Also called HSI:” High Speed Internet”) is\/will be the pre-dominant traffic in networks”.<\/p>\n

      The direct corollary is; “The nature of “Internet data\/ HSI data” should drive any plan for network expansion”.<\/p>\n

      So what is the nature of the Internet data? The Internet data flows to fixed destination in network: towards internet gateways from originating routers. In fact this is a \u201cpoint to point\u201d data .This very nature is quite different than any other layer 3 VPN data \u00a0that has to follow any to any\/ mesh\u00a0connectivity and needs to stop at every core router.<\/p>\n

      In other words, for the Internet data, the destination is fixed and known to an operator.<\/span><\/p>\n

      This nature of Internet data, as probably you have guessed, is similar to the point to point\u00a0behavior of lower layers of Transmission. Wouldn\u2019t it be appropriate to push this date to lower layers and take advantage of the lower layers?<\/p>\n

      This works on the principle that \u201c\u201cCost to carry data on the lower layers is less than carrying it over IP layer”<\/p>\n

      By intelligently designing core network, routers can take help of the lower layers (L2, SDH, OTN or DWDM) to carry the traffic to the Internet Gateway site.<\/p>\n

      This means, the data does not need to touch IP layer at every intermediate core router because of transit router bypass.<\/p>\n

      Wouldn\u2019t it result in slow down of core routers build up?<\/p>\n

      In fact, core routers do not need to grow as fast as lower layers need to, thus bringing significant cost savings for Operators. This strategy would result in “Grow-Routers-Slowly, Grow-Lower-Layers-Fast” (let\u2019s call it GRS-GLF strategy). For Obvious reasons this will bring the TCO of the network lower.<\/p>\n

      Going to the earlier debate I can now say that GRS-GLF\u00a0strategy neither makes the Transmission dumb as lower layers are helping the routers in aggregation (in addition to protection also but that is a subject for another day), neither makes a complete offload of core routers (as we are talking about the Internet data only) as the proponents of ” Router Offload” would sometimes want you to believe.<\/p>\n

      Having explained why the GRS-GLF\u00a0strategy makes sense, let me now share some guidelines on how this can be implemented in networks.<\/p>\n

      (PS: While the discussion would refer to \u201cOTN\u201d. The data applies\u00a0equally to SDH. Note that OTN\u00a0here means OTN switch, not the OTN mapper in DWDM)<\/p>\n

      TIP #1 Know the nature of your Traffic very well<\/b><\/h4>\n

      Meaning you should know what kind of traffic is carried over routers. What is the mix of layer 3 VPN versus Internet data? In other words, what is the ratio of traffic for enterprise\/business connectivity versus internet data? Perhaps the biggest mistake the planners do is designing the network for one pattern and one type of traffic.<\/p>\n

      Let\u2019s say the Internet data is 60% (which is a decent estimate) compared to other data. This means you can start zooming on this 60% of data to be\u00a0offloaded\u00a0to lower layers.<\/p>\n

      TIP #2\u00a0 Know the Origin and Destination of your Internet Data <\/b><\/h4>\n

      An easy way to look is the IP destination of the traffic. The IP destination will tell you whether the traffic is destined for Internet Gateways or not. The best point would be the aggregation points in your network where you are collecting the Internet data.<\/p>\n

      Here you can ask this question. Can I send this traffic directly to the Internet Gateway bypassing the intermediate core routers?<\/p>\n

      If the answer is yes, you need to answer the question in TIP 3.<\/p>\n

      TIP #3 \u00a0Select Suitable Lower Layer to take the traffic to Destination (DWDM or OTN\u00a0or L2 Switch?)<\/b><\/h4>\n

      You need to take important decision here. Which layer to offload to?<\/p>\n

      If the up-link pipe of router is congested\u00a0and already filled with internet data and up-link rate is same as DWDM lambda rate, the best would be to go to DWDM layer directly as OTN is not adding any benefit of its aggregation capabilities. Let the DWDM take the traffic directly to Internet Gateway.<\/p>\n

      If the uplink pipe of the router is partially\u00a0filled, there would be a need for a lower layer that has aggregation\/statistical multiplexing capabilities, both low layers like Layer 2 Switch and OTN can help here. (See next point also)<\/p>\n

      Interestingly these days, layer 2 switch and OTN\u00a0are packaged\u00a0in the same switch thus operators can take advantage of\u00a0such switches for grooming capabilities. Remember we are talking about GRS-GLF strategy, so we are building lower layers fast but not the IP layer at same pace.<\/p>\n

      TIP #4 \u00a0Keep Router Up-Link rate to OTN, lower compared to DWDM lambda rate!<\/b><\/h4>\n

      (I am assuming that you already own OTN\u00a0switch, if not you can still offload traffic to lower layers like DWDM and L2 Switch as TIP 3 tells).<\/p>\n

      Why would use an OTN\u00a0switch ( in between router and DWDM) and then keep the up-link of the router at same rate as DWDM rate. This is in fact more CAPEX. We are now growing higher layers and lower layers at the same time.<\/p>\n

      If you are using an OTN\u00a0switch, it is recommended\u00a0to keep the uplink of the routers low compared to DWDM lambda rate. For example if you are using 100G lambdas, recommended uplink rate for router to OTN\u00a0should be 10G. This would enable you to use the grooming functionality of the OTN\u00a0in the intermediate sites. One of the mistakes I see is that some service providers keep both rates same. This would deprive the operator of using the grooming functionality of the OTN layer.<\/p>\n

      TIP #5 Use Color\/DWDM Interfaces on OTN <\/b><\/h4>\n

      If you are using OTN\u00a0switch and DWDM from same vendor, it would make sense to explore the use of color DWDM interfaces that can give traffic directly over the DWDM instead of using a lot of back to back grey interfaces between OTN\u00a0and DWDM. This will result in a lot of CAPEX\/ OPEX saving.<\/p>\n

      If you are using OTN\u00a0switch and DWDM system from different vendors, you would need to run interoperability tests to use the color interface of the OTN of one vendor over the DWDM system of the other.<\/p>\n

      TIP #6 \u00a0The IP and Transmission Departments need to Handshake<\/b><\/h4>\n

      Last but not the least!<\/p>\n

      If the IP and Transmission departments are different ( as usually in Tier 1 Operators) , it would need a good coordination between the two in order understand from each other on how best to expand both IP and Transmission layer that can bring total cost savings for operators. They would need to plan\u00a0together\u00a0on how to use all layers intelligently\u00a0bringing\u00a0the Transmission cost per bit down.<\/p>\n

      If there is one\u00a0department\u00a0that plans both the above networks, this is ideal as there will be combined strategy for IP and Transmission expansion.<\/p>\n

      Conclusion:<\/b><\/h4>\n

      As you can see that all the above tips apply to using lower layers of Transmission to support efficient and cheapest transport of IP data. These apply in particular to Internet\/HSI\u00a0data and I repeat by using selective offloading of IP traffic, an operator can get considerable cost benefits.<\/p>\n

      I can bet that by exploring these out of box approaches, the IP and OTN\/DWDM can live happily together through a successful marriage.<\/p>\n

      While this article is mainly looking at how Transmission pipes can help the upper layers in terms of cheap transport of data by using aggregation intelligently, I can write at same later time on how the lower layers protection options can further help the MPLS layer in bringing down the cost of protection at upper layers.<\/p>\n

      Now it\u2019s your turn!<\/p>\n

      I would love to listen to \u00a0what do you think about the arguments and Tips in this blog and further,how you are coping with the tremendous expansion in the IP data in your network.<\/p>\n

       <\/p>\n","protected":false},"excerpt":{"rendered":"

      When revenue per bit starts falling and cost per bit starts increasing, it\u2019s time to think about alternative strategies to expand\u00a0Transmission\/IP network. As IP is predominant\u00a0traffic in Transmission networks, therefore any expansion strategy on Transmission should be driven by IP demands. Indeed, both IP and Transmission departments need to work for a joint and synergetic […]<\/p>\n","protected":false},"author":2,"featured_media":756,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[13],"tags":[],"class_list":["post-626","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-transport"],"_links":{"self":[{"href":"https:\/\/telecomlighthouse.com\/index.php?rest_route=\/wp\/v2\/posts\/626","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/telecomlighthouse.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/telecomlighthouse.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/telecomlighthouse.com\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/telecomlighthouse.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=626"}],"version-history":[{"count":0,"href":"https:\/\/telecomlighthouse.com\/index.php?rest_route=\/wp\/v2\/posts\/626\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/telecomlighthouse.com\/index.php?rest_route=\/wp\/v2\/media\/756"}],"wp:attachment":[{"href":"https:\/\/telecomlighthouse.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=626"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/telecomlighthouse.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=626"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/telecomlighthouse.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=626"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}