Light Reading
Heavy Reading's Sterling Perrin discusses what he's seeing in the evolution of OTN and the packet-optical network
Video

OTN Inches Toward the Metro

50%
50%
Newest First  |  Oldest First  |  Threaded View
Page 1 / 2   >   >>
Pete Baldwin
50%
50%
Pete Baldwin,
User Rank: Light Beer
12/5/2012 | 4:49:21 PM
re: OTN Inches Toward the Metro


This video is basically Sterling Perrin's more measured view of Tuesday's "OTN Must Die" rant from Sten Nordell of Transmode.


As I think I said before, I think Sten was playing up to the cameras a bit, so to speak, and he might even agree with what Sterling is saying here.


So - OTN in the metro - anybody out there considering it? What are the most important pros and cons?

Jon B
50%
50%
Jon B,
User Rank: Light Beer
12/5/2012 | 4:49:19 PM
re: OTN Inches Toward the Metro


Hi Craig / Sterling - Just a quick post to clarify on the latency comments. Sten's point was that is an area of the network where you need to do Layer 2 Ethernet functionality (typicallty a Layer 2 Ethernet based aggregation/backhaul/metro network) then any OTN will add latency as the node will need to terminate the OTN to access the full Ethernet frame, do whatever processing/switching/aggregation was required and then recreate a new OTN signal. 3 steps which all add some latency. The Native Packet Optical approach uses standard Ethernet as the payload and only has one of these steps and therefore lower latency. So the comparision Sten was making isn't against an OTN switch which is only operating at the OTN level, it should be compared to a device that does this and the necessary Layer 2 functionality. Although I note you were referring to core and not metro devices.


Naturally, once the relevant pipe has been aggregated enough to get it full enough and the traffic is all going to the same location then futher layer 2 isn't necessary within the transport network and OTN (or other approaches) could be used to transport this data - such as in the core of a network, where OTN does make more sense.


Cheers


Jon (Transmode)

mvissers
50%
50%
mvissers,
User Rank: Light Beer
12/5/2012 | 4:49:19 PM
re: OTN Inches Toward the Metro


Ethernet frames are transported over a fiber inside a CBR stream. This CBR stream can be:

<ul>
<li>a 802.3 bit stream (1GE, nX1GE (LAG),&nbsp;10GE, nx10GE (LAG),&nbsp;40GE, 100GE) which is mapped into an OTN ODUk (k=0,2e,3,4) and then into an OTUk&nbsp;(k=2e,3,4) or into a HO ODUk/OTUk &nbsp;and then put onto a wavelength, or</li>
<li>a OTN ODUk/flex bit stream (nx1.25G) which is mapped into an OTUk (k=2e,3,4), or into a HO ODUk/OTUk and then put into a wavelength.</li>
</ul>

Mapping Ethernet frames directly into an ODUk/flex has fewer processes in its path, and thus less delay.


Maarten

mvissers
50%
50%
mvissers,
User Rank: Light Beer
12/5/2012 | 4:49:18 PM
re: OTN Inches Toward the Metro


Hi Jon,


Inefficiency is a separate issue. A number of operators have determined that it is more efficient (TCO wise) to bypass packet layer switches when the CIR bandwidth&nbsp;is exceeding 300-400 Mbit/s.


At bandwidths lower than this number it is more efficient to groom the packet traffic from multiple streams in a packet switch before putting it again in a CBR stream (e.g. ODUk/flex).


I am seeing that this is being done now at the edge of the aggregation/metro network for the broadband backhaul in EOTN edge devices. The ODU connections (e.g. 10G ODU2)&nbsp;terminates then at the Service Edge locations in EOTN core devices, and ethernet streams are handed to Service Edge nodes (of the different service providers).


For business services, the ethernet streams in the EOTN core devices are either send to the core network (inside ODUk/flex) or back into the aggregation/metro network (inside ODUk/flex). EOTN edge and core devices provide the flexibility to support Ethernet services edge-to-edge via an ODUk as an EPL service, or via a&nbsp;Ethernet Connection (carried over shared ODUk/flex) as an EVPL, EVPT, EVPLAN&nbsp;service. Also possible is to provide private E-Tree/E-LAN services via an Ethernet Connection carried over dedicated ODUk/flex connections between EOTN edge/core devices.&nbsp;


Maarten

Jon B
50%
50%
Jon B,
User Rank: Light Beer
12/5/2012 | 4:49:18 PM
re: OTN Inches Toward the Metro


Hi Maarten,


There are also other options for carrying 10G LAN etc directly over fiber without OTN :-)


But the main point that Sten was addressing in his presentation (which I won't go into too much depth here as I also mentioned this on another post for Criag's other article) is that Sten is referring to nodes that need Layer 2 processing - e.g. an aggregation point that aggregates a load of GbE circuits that are carrying say 200-400 Mbit/s for mobile backhaul. Mapping the full GbE into any layer 1 solution (OTN or the other methods I'm referring to above) will be inefficient if layer 2 aggregation isn't done too. As these nodes need layer 2 processing, OTN transport would have to terminated, then layer 2 operations performed and then a new OTN signal started and that was the point Sten was bringing up - it's not just the method of layer 1 mapping a signal to a wavelenth. In the NPO approach as the payload is native ethernet then some of these processing steps are missed totally.


However, I fully see your point that if you were looking into just layer 1 mapping of an Ethernet signal then the flex approach would involve less operations and could therefore have less latency.


Cheers


Jon

Pete Baldwin
50%
50%
Pete Baldwin,
User Rank: Light Beer
12/5/2012 | 4:49:15 PM
re: OTN Inches Toward the Metro


Jon -- Thanks for chiming in here, and for making the point about the latency comparisons. Always good to see vendors openly joining the discussion.

rhr
50%
50%
rhr,
User Rank: Light Beer
12/5/2012 | 4:49:14 PM
re: OTN Inches Toward the Metro
If OTN is so established in the core, isn't it a given that it will migrate, as 100G will migrate, to the metro? And Jon, can't Transmode just support Ethernet over DWDM where it makes sense wherever the industry does? Or is Sten's point that Transmode will also need to support OTN even if it is not needed?
Jon B
50%
50%
Jon B,
User Rank: Light Beer
12/5/2012 | 4:49:13 PM
re: OTN Inches Toward the Metro



Hi All,


One last post on this thread from me (along with another final one on the Is OTN Overkill thread) to hopefully wrap all this up.


Maarten - Firstly, we fully agree that packet layer switches are too expensive for these applications. the architecture that we are using here integrates the necessary layer2 functions into the transport platform which gives totally different economics to deploying switches in addition to a layer1 only transport network. Aggregation was just one example of the layer2 functions that might be needed in a network-switching, service awareness, OAM etc. I think we are just going to have to agree to disagree on how best to achieve all this functionality - we have plenty of customers deploying this native packet optical architecture in metro networks (that could well be feeding nicely filled pipes into an OTN core of course) and I'm sure you guys at Huawei have plenty of customers for a more OTN-centric architecture too. No two networks are the same and no solution is going to be the right one for every network in the world. In our view, those that are dealing with a lot of Ethernet traffic need to look at more packet friendly approaches than OTN within the aggregation/backhaul/metro portion of the network.


Craig - No worries about joining the conversation! There isn't much time to get this concept across at the event and there is some misunderstanding about what we are trying to convey, so happy to try and clarify it for hopefully some of the folks here.


rhr - The challenges in metro and core networks are very different - services differ, capacity levels differ, the physical architecture differs etc. The point is that while a network is still dealing with layer2 issues (aggregation, switching, service awareness etc) then we don't think OTN helps and we believe this architecture is more appropriate. Once a pipe is full (enough) and all the traffic is going to the same place and no longer needs any layer2 interaction then simple layer1 (possibly OTN) is the right thing to do. Core networks typically deal with this type of traffic and for sure some of the more heavily loaded parts of metro networks will too but lots of other networks do and will need layer2. Metro/Core is a very simple way to differentiate between these two and it's not a clear cut demarcation - as mentioned above - all networks are different. We do support OTN transport and over time we will continue to also develop OTN products but we use these for transporting full pipes closer to ,or in, core networks, not for the type of network traffic that Sten was referring to. Oh, and our 100G is OTN framed - this fits the "big fat and full pipe" criteria!


In the other thread on all this (http://www.lightreading.com/me... menahemk gets the point and says "layers need to be there for scalability because flat networks (or flat anything) do not scale. OTN is an essential part in that layering, just don't stretch it where it doesn't fit." - that was the point Sten was making - don't stretch OTN from the core to every application and network, as it just doesn't fit everywhere.



OK - hopefully that's enough from me on this thread!


&nbsp;




neyo
50%
50%
neyo,
User Rank: Light Beer
12/5/2012 | 4:49:12 PM
re: OTN Inches Toward the Metro
Jon, I tend to agree with you. OTN is not required in the metro when 100% of the traffic is packet-based. It is only required in the core. Thanks for clarifying.
^Eagle^
50%
50%
^Eagle^,
User Rank: Light Beer
12/5/2012 | 4:49:07 PM
re: OTN Inches Toward the Metro


I think too many people are trying to make modern network arguements by appling "old" network terms.


This leads to great fallacies.


To wit: Core Networks. &nbsp;Jon of Transmode keeps trying to say Core Networks are essentially long haul transport networks and metro is not a part of the core network.


I think this leads to some of the statements made by all parties on these two chat boards.


So, let us be more clear. &nbsp;in the minds of most carriers I know (and I know a lot of them), CORE NETWORKS include Metro transport and switching! &nbsp;LH and Metro might use slightly different platforms, but from the carrier point of view, they are both part of the "CORE"!


So the arguements are a bit disingenuous. &nbsp;


edge / access / aggregation to get things up to the point of true metro systems is a different space. &nbsp;&nbsp;


I think this arguement needs to be stated in terms of access / edge vs Core. &nbsp;Not Metro vs "Core" as Metro is PART OF THE CORE from any sensible point of view. &nbsp;Metro is for interoffice traffice, carrier interconnect, transport between small cities and towns near larger city cores, etc. &nbsp;


This is distinct from access / edge where services originate and where low bit rates prevail which leads to the need for aggregation to hand off to the core. &nbsp;Remember folks, most of us, including businesses, are still served by relatively low bit rate services from T1/E1 to DSL to cable modem systems to wireless backhaul. &nbsp;almost none of these services have enough bandwidth to justify a full wavelength, even after local aggregation. &nbsp;only when aggregated up to a much higher level do you pack a full 10gig, or 40gig, or 100gig wavelength. &nbsp;


you might look at core as wavelengths at "x" bit rate, and edge access as all user interface services. &nbsp;


In that space, transmode's arguements might have a place, but not at the level of needing a separate wavelength for those TDM services and other non wavelength based services. &nbsp;There is simply not enough to pack the pipe until you get into the core. &nbsp;And core is inclusive of metro. &nbsp;


hence carrier interest in OTN.


sailboat

Page 1 / 2   >   >>
Flash Poll
LRTV Custom TV
A New Security Paradigm in SDN/NFV

7|28|14   |   02:54   |   (0) comments


Paul Shaneck, Global Director Network Solutions for Symantec, discusses the evolving virtualized network, explaining how Symantec is leading the security discussion as it relates to SDN and NFV, and helping to ensure the network is protected and compliant.
LRTV Documentaries
Sprint's Network Evolution

7|24|14   |   14:59   |   (0) comments


Sprint's Jay Bluhm gives a keynote speech at the Big Telecom Event (BTE) about Sprint's network and services evolution strategy, including Spark.
LRTV Documentaries
BTE Keynote: The Software-Defined Operator

7|24|14   |   18:43   |   (1) comment


Deutsche Telekom's Axel Clauberg explains the concept of the software-defined operator to the Big Telecom Event (BTE) crowd.
Light Reedy
Numbers Are In: LR's 2014 Salary Survey

7|24|14   |   1:25   |   (7) comments


Our fourth annual Salary Survey paints a picture of who's hiring, firing, earning, and yearning for a change in the telecom industry.
LRTV Custom TV
Driving the Network Transformation

7|23|14   |   4:29   |   (0) comments


Intel's Sandra Rivera discusses network transformation and how Intel technologies, programs, and standards body efforts have helped the industry migration to SDN and NFV.
LRTV Custom TV
Distributed NFV-Based Business Services by RAD

7|18|14   |   5:38   |   (0) comments


With the ETSI-approved Distributed NFV PoC running in the background, RAD's CEO, Dror Bin, talks about why D-NFV makes compelling sense for service providers, and about the dollars and cents RAD is putting behind D-NFV.
LRTV Custom TV
MRV – Accelerating Packet Optical Convergence

7|15|14   |   6:06   |   (0) comments


Giving you network insight to make your network smarter.
LRTV Custom TV
NFV-Enabled Ethernet for Generating New Revenues

7|15|14   |   5:49   |   (0) comments


Cyan's Planet Orchestrate allows service providers and their end-customers to activate software-based capabilities such as firewalls and encryption on top of existing Ethernet services in just minutes.
LRTV Custom TV
Symkloud NVF-Ready Video Transcoding, Big Data

7|9|14   |   3:41   |   (0) comments


Kontron and ISV partner Vantrix demonstrate high-performance video transcoding and data analytic solutions on same 2U standard platform that is ready for SDN and NFV deployments made by mobile, cable and cloud operators.
LRTV Huawei Video Resource Center
The Evolving Role of Hybrid Video for Competitive Success

7|4|14   |   4:09   |   (0) comments


At Huawei's Global Analysts Summit in Shenzhen, China, Steven C. Hawley from TV Strategies speaks to us about the evolving role of hybrid video for competitive success.
LRTV Huawei Video Resource Center
How CSPs Leverage Big Data in the Digital Economy

7|4|14   |   4:48   |   (2) comments


Justin van der Lande from Analysys Mason shares with us his views on how telecom operators can leverage customer asset monetization with big data. His discusses the current status of big data applications and the challenges and opportunities for telecom operators in the digital economy era.
LRTV Huawei Video Resource Center
Accelerator for Digital Business – Future Oriented BSS

7|4|14   |   3:08   |   (0) comments


Mobile and internet are becoming intertwined; IT and CT are integrating; and leading CSPs have begun to transform to information service and entertainment providers. How should the BSS system evolve to enable this transformation? Karl Whitelock, an analyst at Frost & Sullivan, shares his views.
Upcoming Live Events!!
September 16, 2014, Santa Clara, CA
September 16, 2014, Santa Clara, CA
October 29, 2014, New York City
November 6, 2014, Santa Clara
November 11, 2014, Atlanta, GA
December 9-10, 2014, Reykjavik, Iceland
June 9-10, 2015, Chicago, IL
Infographics
Packet Design asks network professionals how they handle the cloud, SDN, and network management.
Today's Cartoon
Vacation Special Caption Competition Click Here
Latest Comment
Hot Topics
Is Windstream Boldly Setting a New Trend?
Carol Wilson, Editor-at-large, 7/29/2014
Sprint, T-Mobile: The Price War's On
Sarah Reedy, Senior Editor, 7/30/2014
Pics From Comic-Con -- Honest!
Mitch Wagner, West Coast Bureau Chief, Light Reading, 7/30/2014
If Not Muni Networks, Then What?
Carol Wilson, Editor-at-large, 7/28/2014
Verizon Applies 3G Throttling Policy to LTE
Sarah Reedy, Senior Editor, 7/25/2014
Like Us on Facebook
Twitter Feed