Jon....

It started as Plain Old Telephone Service and was co-opted for some strange reason by Optical people. :)

seven

Hi Sailboat,

:-) Thanks, that did make me chuckle. Marketing department for me, and within that "Technical Marketing". I did start out my working life as an Engineer though, SDH Management Systems.

Re Misleading terms - I'll tell you term that annoys me the most (and it certainly wasn't started by us) "Packet Optical". We use it a lot, as the whole industry now does, but most POTS systems are Layer 0+1+2, i.e Frames at best, not packets. Some now (very recently) do some Layer 3 (new ECI announcement and some vendors have specific Layer 3 functions - e.g. we do IGMPv3 - intended as an example, not a marketing plug) and some POTS systems are only really Ethernet friendly Layer 1 systems. But they all still use the POTS name. The phrase has been kicking round for years and I have no idea where it originally started. Ho hum.

Cheers

Jon

Jon,

I take my definitions from those who pay the bills: the carriers.  In the end, they pay for all of this as they sit at the top of the food chain and drive the ecology of telecom networks.

Yes, there are lots of misleading terms out there.  Most of them coined and driven by marketing departments of OEM vendors.  

So I listen to the source.  The carriers.

By the way, which department of transmode do you work for?  Marketing?  Product Management? (also marketing) Business Development? (also marketing) Sales? (also marketing) or Engineering?  you do pretty good work as a marketer.  Might want to hire you one day!

sailboat

I really dislike blatant vendor posts on chat threads like this.  go buy an ad on LR and do it up front and legitimately.  Or buy and sponsor a LR Webinar.

show some bit of style.  

Sure, very small posts from vendors, OK.   But long dissertations from vendors that read like a excerpts from vendor whitepapers without stating clearly at the top of the post that "THIS IS MARKETING / ADVERTISING" really bugs me.

I don't like it when Infinera does it.  Don't like it when Huawei does it.  Don't like it when Tellabs does it.  Don't like ti when Transmode does it.

sailboat.

Hi Sailboat,

Yes this whole discussion is riddled with terms that have different meanings to different people and I think this has lead to some misunderstanding.

When talking about optical networks there are a few ways to define them. By equipment type/reach etc - i.e. Metro Vs Long Haul or by function aggregation/backhaul/metro Vs Core. Both are of course very simplistic ways to describe the huge range of networks out there.

I've been using metro in the functional sense in these 2 threads and I've tried to indicate this by sometimes using the phrase aggregation/backhaul/metro instead of just metro (although that could have been on the other thread). Abnd yes access/edge could be another way of describing the same thing.

So with this in mind, if you are thinking of metro as in the type of equipment used or the physical network then absolutely, some of these could be carrying core traffic from a functional sense.

Hope that clarifies my comments that you were referring to.

Cheers

Jon

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.  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.  in the minds of most carriers I know (and I know a lot of them), CORE NETWORKS include Metro transport and switching!  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.  

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

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

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.  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.  almost none of these services have enough bandwidth to justify a full wavelength, even after local aggregation.  only when aggregated up to a much higher level do you pack a full 10gig, or 40gig, or 100gig wavelength.  

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

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.  There is simply not enough to pack the pipe until you get into the core.  And core is inclusive of metro.  

hence carrier interest in OTN.

sailboat

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/messages.asp?piddl_msgthreadid=238443) 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!

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