OTN Inches Toward the Metro

Page 1 / 2   >   >>
Pete Baldwin 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 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.


Jon (Transmode)

mvissers 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:

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

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


mvissers 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;


Jon B 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.



Pete Baldwin 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 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 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!


neyo 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^ 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.


Page 1 / 2   >   >>
Sign In