re: Marconi Adds 'c' to Its OC192bond... Lets say it did offer POS. Now how would the switch know that it has to SAR the 0C-48 inputs and send it over POS interface? is there a command that tells the switch that this is a routing interface? ------------------------
If I've understood your question properly, no there probably isn't a command that designates the entire interface to SAR / switch. This would normally be done on a per VC basis, I'll try to elaborate. ATM switch architecture could be of the form:
PHY - TRAFF_MGMT - SWITCH_CORE - TRAFF_MGMT - PHY
The PHY chips convert from WAN protocol format say SONET or DSL, to ATM UTOPIA format. The TRAFF_MGMT chips handle policing of connections, buffer management, shaping, etc. The SWITCH_CORE just routes the cells based on VPI, or VPI and VCI between its multiple ports.
So for an ATM switch with a routing engine, one of the ports on the switch core would connect to the SAR / router device (maybe a network processor,) while the other ports would be used to drive the ATM interfaces. With this configuration, you could either just switch the ATM straight through PHY to PHY as a VPC or VCC, or terminate the VCC's straight onto the SAR / router. The second option requires an IP address to VCC reference aka ATM-ARP.
re: Marconi Adds 'c' to Its OC192Marconi has been mortally wounded by an ATM company in Pennsylvania (I am forgetting the name).
Marconi, as I remember paid over $5 Billion, to acquire this company. This company was a total fraud with no significant products. Marconi would be paying, for the money it borrowed to acuire this useless company, forever.Given the current cpondition of the UK economy, it is somewhat surprising that Marconi is still in business.
re: Marconi Adds 'c' to Its OC192To answer an early question, the BXR does not SAR at 10Gbps. As I remember the fastest SAR in the Marconi inventory runs at 622Mbps (OC-12c/STM-4c). A typical SP would need to feed in a number of 620Mbps streams from router blades. You can bet that Ciscon and Juniper aren't spending too many R&D dollars on ATM SAR, and Marconi are still figuring out how to spell IP, so that leaves folks like Laurel who might be interested in getting good, high performance SAR for their edge boxes.
To answer another question, Marconi does have POS blades for the BXR, and for the ASX-4000 (a 40Gbps ATM switch). I don't know how fast these are claimed to SAR, but I would be (pleasantly) surprised if it was anywhere near OC-48c speeds.
One clue to the current product priority for the BXR is the person quoted in the article from NRL - Hank Dardy. Apparently Hank was the guy at NRL who awarded FORE systems their first contract in the early 90s. I guess the FORE guys even named a meeting room after him in their campus (you get the spiel on this if you're shown around FORE's Pittsburgh plant).
The US military loves ATM - as a fixed payload technology they can build real-time encryption boxes for 2.5Gbps streams of ATM that just aren't possible with packet based protocols.
A lot of three letter agencies run their stuff on ATM networks, and I guess their purchasing folks must have been pretty worried about all this talk of Marconi going Chapter 11.
re: Marconi Adds 'c' to Its OC192Statistical multiplexing/queueing theory shows that the bigger the size of a single pipe the better statistical gain you are going to get out of it. This is one of the reasons ATM IMA is around .... put four T1's together as a 'single' logical ATM pipe and you get a higher 'equivalent bandwidth' than four discrete T1 ATM UNI's, even when you take into account the slight IMA overhead (by the way, the equivalent is true for any packet-based technology).
The effects are similar at an OC192 vs OC48 (or OC-192c vs OC-48c!) level.
What is important here is the fact that you can now drive ATM at native OC-192 speeds. I assume the Fore guys did this using proprietary, internally developed switching/queueing technology, maybe funded by the DoD ... this is exactly how they were the first to provide OC-48c interfaces several years back.
The importance of ATM line interfaces at OC-192c is that for years, the POS/MPLS camp has been saying that ATM tops out at OC-48 so it cannot possibly be used for "next-generation" capable network backbones. At OC-192 there is still a significant cell tax penalty, but it becomes less important due to the fact that you can now provide very high bandwidth backbone networks with (and this is the important bit) a very well defined QoS per flow (VCC).
While i'm not an ATM bigot (even though I admit I was one once!), I am still yet to see the two following capabilities in a pure packet environment:
(1) An MPLS standard that provides per flow explicit QoS mechanisms (because I think the packet industry is reluctantly beginning to understand that we need them, rather than diffserv-like algorithms), and
(2) An MPLS switch product that supports that (non-existent) standard
All credit to the boys in Pittsburgh if they have this up and running (although I hate to think what the price of the card is - my first guess would be in the $130,000 per port range).
re: Marconi Adds 'c' to Its OC192If I've understood your question properly, no there probably isn't a command that designates the entire interface to SAR / switch. This would normally be done on a per VC basis, I'll try to elaborate. ATM switch architecture could be of the form:
PHY - TRAFF_MGMT - SWITCH_CORE - TRAFF_MGMT - PHY
The PHY chips convert from WAN protocol format say SONET or DSL, to ATM UTOPIA format. The TRAFF_MGMT chips handle policing of connections, buffer management, shaping, etc. The SWITCH_CORE just routes the cells based on VPI, or VPI and VCI between its multiple ports.
So for an ATM switch with a routing engine, one of the ports on the switch core would connect to the SAR / router device (maybe a network processor,) while the other ports would be used to drive the ATM interfaces. With this configuration, you could either just switch the ATM straight through PHY to PHY as a VPC or VCC, or terminate the VCC's straight onto the SAR / router. The second option requires an IP address to VCC reference aka ATM-ARP. -------------------------------------------
MP_UK,
The original poster (belzebutt) gave an example of a router with OC-48 ATM interface connecting to a "multiservice" switch. Switch also has a POS interface that connects to another router.
Now following is my understanding of how things **should** work -- somebody has create a bunch of PVCs from the router (with oc48 interface) to whatever routers that it wants the "IP" connectivity through the ATM cloud. Lets say the switch is the penultimate node in the cloud. That somebody who is creating the PVCs must somehow figure out that he has to create the PVC to an ATM switch and not the ultimate router because that router does not have an ATM interface and is connected to ATM cloud through POS interface. true?
Note that in this question ATM-ARP won't help. Somehow in switch's TCP/IP stack that VCI should appear as a logical IP interface. And since VCs are created semi-dynamically how do you bind a VC to an IP interface in an ATM switch?
re: Marconi Adds 'c' to Its OC192With ATM OC192c links will SPs utilize this to grow ATM nets with and postpone implementation of MPLS? Some router vendors have been pushing OC192 POS links - now ATM matches them.
A question on the cell tax - with MPLS used in voice networks wouldn't the layer 2 header be up to 26 bytes? If the average payload is 128 bytes or less (voice tends to have very small packet sizes) wouldn't IP/MPLS have higher overhead than ATM?? My calcuations (am I am sure someone will correct them) show almost twice as much overhead for L2 MPLS as L2 ATM.
re: Marconi Adds 'c' to Its OC192Firstly, from reading your previous posts, I'm aware you know what you're talking about - so if I state the obvious, I'm not being patronising! Comments in-line...
---------------
The original poster (belzebutt) gave an example of a router with OC-48 ATM interface connecting to a "multiservice" switch. Switch also has a POS interface that connects to another router.
Now following is my understanding of how things **should** work -- somebody has create a bunch of PVCs from the router (with oc48 interface) to whatever routers that it wants the "IP" connectivity through the ATM cloud.
>> I assume that's 1 PVC to each router, and that each PVC is manualy configured with a static IP address bound to it.
Lets say the switch is the penultimate node in the cloud.
>> The router connected via PoS being the last node...?
That somebody who is creating the PVCs must somehow figure out that he has to create the PVC to an ATM switch and not the ultimate router because that router does not have an ATM interface and is connected to ATM cloud through POS interface. true?
>> So are you assuming that the switch is not capable of routing? If so and we're just talking a swap of layer 2 protocol (ATM - SAR - PoS) then being as PoS is point to point and so is a VCC, I guess you'd have to map a *single* VCC to the PoS interface and ignore any IP layer stuff at the switch. In such a case the layer 2 conversion should be transparent to the routers, how to configure that I'm not sure.
Note that in this question ATM-ARP won't help. Somehow in switch's TCP/IP stack that VCI should appear as a logical IP interface. And since VCs are created semi-dynamically how do you bind a VC to an IP interface in an ATM switch?
>> So if one assumes the switch is routing on IP address - the only reason for a VC to IP address binding I can think of - the binding is setup either manualy or via signaling. If one assumes that the switch is IP capable (i.e. a router,) then the switch should count as a layer 3 hop. If the assumption is that no routing happens on the switch, and it's just a case of swapping the layer 2 format, perhaps it's not usefull to think of the PoS link as an 'IP interface' on the switch.
re: Marconi Adds 'c' to Its OC192MP_UK: So if one assumes the switch is routing on IP address - the only reason for a VC to IP address binding I can think of - the binding is setup either manualy or via signaling. If one assumes that the switch is IP capable (i.e. a router,) then the switch should count as a layer 3 hop. -------------------------
Agreed. I realized it after I hit "PostMessage". But it still sorts of breaks the "ATM cloud with IP network overlaid on top" type of model.
re: Marconi Adds 'c' to Its OC192Re: ATM OC192 and ATM nets
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).
Re: Voice and IP/MPLS and ATM
The short answer is yes .... small voice packets are notoriously inefficient in IP networks compared to say an AAL2 service (I remember the claims about the 8K voice over IP compression in early enterprise networking ... they were true except you required an additional 16Kbps for each call to handle the encapsulation in IP).
There are, however, ways of making voice over IP or voice over MPLS more efficient that are making their way through various standards bodies (well, the IETF and MPLS Forum). The big question as always is still ... "once I have more efficient voice traffic, how do I make sure it stays prioritized through an end-to-end, multi-vendor packet network?"
Lets say it did offer POS. Now how would the switch know that it has to SAR the 0C-48 inputs and send it over POS interface? is there a command that tells the switch that this is a routing interface?
------------------------
If I've understood your question properly, no there probably isn't a command that designates the entire interface to SAR / switch. This would normally be done on a per VC basis, I'll try to elaborate.
ATM switch architecture could be of the form:
PHY - TRAFF_MGMT - SWITCH_CORE - TRAFF_MGMT - PHY
The PHY chips convert from WAN protocol format say SONET or DSL, to ATM UTOPIA format.
The TRAFF_MGMT chips handle policing of connections, buffer management, shaping, etc.
The SWITCH_CORE just routes the cells based on VPI, or VPI and VCI between its multiple ports.
So for an ATM switch with a routing engine, one of the ports on the switch core would connect to the SAR / router device (maybe a network processor,) while the other ports would be used to drive the ATM interfaces. With this configuration, you could either just switch the ATM straight through PHY to PHY as a VPC or VCC, or terminate the VCC's straight onto the SAR / router. The second option requires an IP address to VCC reference aka ATM-ARP.