This is the equivalent of the ATM CES AAL1 specification but for synchronous interfaces running directly on top of an MPLS bearer. Much like the ATM CES specification it describes the mechanics of packing up a synchronous circuit to run emulated over a packet cloud. But there is no explicit definition here that states how switches in the network are to assign resources to this traffic, or what an acceptable level of quality is for the circuit.
For example, ATM CES mandates the use of the TM 4.X CBR.1 service category for CES transport across the ATM network. CBR has a very explicit definition for PCR, CDVT, CLR etc. each switch knows what these constraints are and assigns appropriate resources and priorities to the individual ATM VCC carrying the CES service to meet these criteria. It works, but is cumbersome, there is a lot of management or signaling overhead to setup the circuit - however each ATM switch in the path knows exactly what is expected of it.
My point is that the whole ethos of IP networking is that it should be simpler because it's IP, of course. But to get IP (or even MPLS) to mirror these capabilities some level of complexity must be added. All attempts to date to minimize this complexity (because that makes it easier to deploy and manage) have led to compromises in terms of real QoS support.
Show me an industry specification that explicitly defines different classes of service for an MPLS network and how services/applications map into these classes (without an underlying layer 2 ATM transport, if you please). Otherwise we are just left with the mantra of "we don't need to worry about QoS because there will be so much bandwidth it doesn't matter". The history of networking would tend to demand a different response, unless of course we're all happy with crossing our fingers that the application is going to work each and every time we turn it on.
kampar
(BTW - I like the Vivace product and its concept - these guys have the right product to my mind - but you still need a core MPLS network that understands the same QoS language they have at the edge. Otherwise, as the draft document above states reasonably clearly, you are going to have to traffic engineer every single path - probably by hand - through the MPLS cloud to guarantee it's going to work)
re: Marconi Adds 'c' to Its OC192Back before the turn of the century SONET/OC192c products could not easily be made to operate in SDH/STM64 mode, due to SDH legacy that allowed STM64 virtual concatination. (At 10G all those 'concatinated' STM payloads are allowed to be lined up anywhere in the 8Khz superframe, unlike SONET where they are all synched.)
Is this still an issue and can this 10G ATM card interoperate with the official Marconi SDH commitment?
re: Marconi Adds 'c' to Its OC192Network Mercenary wrote...
"I am extremely interested in seeing actual test results from a group like Tolly..."
Nothing against groups like Tolly and Mier Communications, but to go to them for "ATM Expertise" is like asking Home Depot to design a skyscraper. Hank Dardy and the Federal gov't know more about ATM than 99.99% of the rest of us so I would personally rather hear from the Fed's than Tolly. (did I just say you should trust the gov't? doh! Well, in this case that would actually be correct for a change).
Both Tolly and Mier are quite capable of testing IP, Ethernet, core/edge route and VoIP functionality, but if those skills are the rifles in their arsenal, their ATM expertise wouldn't even qualify as a spitball in a straw.
I've done testing with both companies and been at both of their locations [not the new Mier location] and found their ATM knowledge to extremely lacking....I saw an Adtech sitting on the floor of one of these places and asked hey why don't we use that?! ...and they looked at me sheepishly and basically said 'the ATM guy isn't here anymore' Oi!). Tolly had a senior engineer(non testing engineer) who knew something about connection-oriented/ATM detail, but their testing engineers knew next to nothing (granted there is probably a lot of turnover in those ranks).
Also, neither company actually owns their own test equipment (or at least very little) - companies like Spirent (Smartbits/Adtech) and Agilent loan all the gear for specific testing periods. Tolly then says hey we used yada-yada test set for this report....so the Tolly/Mier's of the world are pretty savvy at running their business (not underhanded, but savvy....although they do charge at a serious premium for their services). Maybe we should start our own testing/verification company :)
It seems vendors who want their ATM products verified/certified etc. occasionally use Tolly/Mier because of their name recognition, but personally I would rather use a univsersity lab like UNH, EANTC or even GMU/Isocore before going to drop change on Tolly or Mier's doorstep.
re: Marconi Adds 'c' to Its OC192There is no risk for the vendor when they buy these testing services, very unlike the lightreading sponsored comparison tests, where there is a big downside risk--remember Charlotte's Web? =================================
The only reason people remember Charlotte's web is that they themselves made it a huge negative and kept talking about it.
Everyone remembers them (and they didn't do all that bad), but nobody remembers the companies that no-showed or who did far worse.
re: Marconi Adds 'c' to Its OC192Kampar wrote: "I think this is exactly what will continue to happen; the products in the core of the network will be pushed further out to the edge and replaced with new, higher bandwidth ATM switches that promise an MPLS future path (note this is a strong statement that Marconi makes for its products)."
------------------------------------------
So now there is the promise of ATM nets that can match the fastest core routers, you have to ask whether MPLS still makes sense as a backbone for legacy "data" services--PL, Frame Relay and ATM.
But most carriers do not use Fore/Marconi in their data networks (I think Sprint is the exception); more likely you will find Cascade/Lucent, Stratcom/Cisco or Nortel gear. That begs the question, is anyone else ever going to deliver 10 Gig ATM for the majority of the installed base?
re: Marconi Adds 'c' to Its OC192My impression of those published test results is that they are bought and paid for, just like the so-called "analyst" reports we see that praise a particular company or box.
Can you imagine ever reading a public report that says "This thing is a piece of crap, it drops packets all over the floor once you get above 50% utilization, so don't waste your money on...?
There is no risk for the vendor when they buy these testing services, very unlike the lightreading sponsored comparison tests, where there is a big downside risk--remember Charlotte's Web?
re: Marconi Adds 'c' to Its OC192We're currently doing a test of multiservice ATM switches. It's being conducted by EANTC, which is writing the test plan, and the final report.
Well, not to slam Lightreading, but to be honest I'd trust them to do a an Edge/Core Router IP/MPLS test or optical switch bakeoff, but do they have the ATM expertise to do a real ATM/multiservice switch test or even write the test plan?
Again, I would put more trust into info coming from a UNH or EANTC lab, where the lab organized the event, wrote the test plan and wrote the final report/article (it would be great to somehow have major N. American and International carrier rep's involved as well).
I have a feeling (correct me if I'm wrong) that Lightreading would tend to focus on MPLS and what's "nifty"/new/"newsworthy" instead of what a carrier/RBOC network architect would truly be interested in.
Does Lightreading see "multiservice" as IP/MPLS w/ ATM thrown in or do they look at Multiservice Edge delivery/capability for customer-facing services such as Frame Relay, IMA, ATM, Circuit Emulation/TDM, VoATM applications - that is what an RBOC level customer would care about. Sure they'd want to know about the option (and I repeat Option) to migrate to MPLS, but they'll only go that route if it makes sense from their bottom line - not because it "cool" to do MPLS (imagine just the Back Office cost involved to switch something like their Frame Relay provisioning/trouble ticketing system from an ATM backbone to an MPLS core...new MIBs, Telcordia or internal development...Ouch, Batman!).
Hopefully, I'm wrong with respect to Lightreading's ATM abilities but let's just say it should definitely not be accredited to them by default, especially after I read a post here that said Lucent had withdrawn from Lightreading's Multiservice Switch bakeoff.
re: Marconi Adds 'c' to Its OC192So now there is the promise of ATM nets that can match the fastest core routers, you have to ask whether MPLS still makes sense as a backbone for legacy "data" services--PL, Frame Relay and ATM. -------------------------- It still makes sense for most people in the long run. There is still a need to consolidate down to fewer types of equipment in the network and to provide a migration strategy for doing so. MPLS is still the best way to do that.
-------------------------- But most carriers do not use Fore/Marconi in their data networks (I think Sprint is the exception); more likely you will find Cascade/Lucent, Stratcom/Cisco or Nortel gear. That begs the question, is anyone else ever going to deliver 10 Gig ATM for the majority of the installed base? ---------------------------
The visualization applications that NRL and the government are interested is not a mainstream sort of business. Its worth Marconi's time/effort to go after (and the government probably made it worth their while if it wasn't), but ultra high-definition real-time encrypted AAL-1 video isn't going to catch on outside of government/defense. And even there, its a limited market.
re: Marconi Adds 'c' to Its OC192Point taken about the testing facility and capabilities - I can't dispute, as I have no frame of reference personally to discuss that.
The NRL isn't going to make a statement about performance without due diligence. I'll hold to my original comments though that the BXR will make it to the core of SP's in time.
True as it may be that the Lucent boxes are more predominant in the SP's at this point, that won't be the case moving forward. There isn't the same R&D efforts invested. How can I say that? Quite simply because a lack of new blades and features. The SP's with sense will move to a new box - NM
Re: http://www.ietf.org/internet-d...
This is the equivalent of the ATM CES AAL1 specification but for synchronous interfaces running directly on top of an MPLS bearer. Much like the ATM CES specification it describes the mechanics of packing up a synchronous circuit to run emulated over a packet cloud. But there is no explicit definition here that states how switches in the network are to assign resources to this traffic, or what an acceptable level of quality is for the circuit.
For example, ATM CES mandates the use of the TM 4.X CBR.1 service category for CES transport across the ATM network. CBR has a very explicit definition for PCR, CDVT, CLR etc. each switch knows what these constraints are and assigns appropriate resources and priorities to the individual ATM VCC carrying the CES service to meet these criteria. It works, but is cumbersome, there is a lot of management or signaling overhead to setup the circuit - however each ATM switch in the path knows exactly what is expected of it.
My point is that the whole ethos of IP networking is that it should be simpler because it's IP, of course. But to get IP (or even MPLS) to mirror these capabilities some level of complexity must be added. All attempts to date to minimize this complexity (because that makes it easier to deploy and manage) have led to compromises in terms of real QoS support.
Show me an industry specification that explicitly defines different classes of service for an MPLS network and how services/applications map into these classes (without an underlying layer 2 ATM transport, if you please). Otherwise we are just left with the mantra of "we don't need to worry about QoS because there will be so much bandwidth it doesn't matter". The history of networking would tend to demand a different response, unless of course we're all happy with crossing our fingers that the application is going to work each and every time we turn it on.
kampar
(BTW - I like the Vivace product and its concept - these guys have the right product to my mind - but you still need a core MPLS network that understands the same QoS language they have at the edge. Otherwise, as the draft document above states reasonably clearly, you are going to have to traffic engineer every single path - probably by hand - through the MPLS cloud to guarantee it's going to work)