x
Routing

Redback Beefs Up Its Router

Ericsson AB (Nasdaq: ERIC) subsidiary Redback Networks Inc. is launching its most ambitious edge router yet, hoping a combination of increased density and subscriber-related features will give it an advantage over rivals Cisco Systems Inc. (Nasdaq: CSCO), Juniper Networks Inc. (NYSE: JNPR), and Alcatel-Lucent (NYSE: ALU).

The SmartEdge 1200, announced today and set for general availability in August, is Redback's highest-density box, with 480 Gbit/s of switching capacity (that is, 240 Gigabit Ethernet feeds supported) in one fourth of a telecom rack. On a full rack basis, that appears to outdo most edge platforms on the market, with Juniper's MX960 being the notable exception. (See Redback Adds SmartEdge 1200 and Juniper Antes Up on Ethernet (Finally).)

Table 1: Density Wars
Company Platform Capacity* Size
Alcatel-Lucent 7750 SR-12 400 Gbit/s 1/3 rack
Cisco 7613 720 Gbit/s 1/2 rack
Cisco 12810 800 Gbit/s 1/2 rack
Juniper M120 256 Gbit/s 1/4 rack
Juniper MX960 960 Gbit/s 1/3 rack
Redback SE 1200 480 Gbit/s 1/4 rack
Source: Company literature
* Full duplex. That is, divide by 2 to get the number of simultaneous Gigabit Ethernets supported.


Equally dramatic is the laundry list of functions integrated. The box includes: security features such as intrusion detection, IPSec, and a firewall; a session border controller; and deep packet inspection capabilities for detecting peer-to-peer traffic. The box also includes some mobility features -- along the lines of fixed/mobile convergence --- that Redback isn't fully disclosing yet.

This has all been added to a platform that already includes Ethernet aggregation and the functions of a broadband remote access server (B-RAS). The SE 1200 uses the same operating system as other SmartEdge boxes and can use the same blades as well.

The new release shows that Redback isn't stagnating after its acquisition by Ericsson, which was completed early this year. (See Ericsson Offers $2.1B for Redback , IPTV Drives Ericsson to Redback, and Ericsson Completes Offer.)

So far, Ericsson has made good on keeping Redback's name alive and has begun intertwining its engineering efforts with that of the IP equipment firm. Those unspecified mobility functions stem from Ericsson expertise, for instance.

"It's a great step for Redback and a big win for Ericsson -- proof that Ericsson hasn't slowed them down," says Eve Griliches, an analyst with IDC .

Redback says the SE 1200 is a reaction to the number of applications that now rely on IP. Routers are being tasked to handle more jobs at once -- security, VOIP, the throttling-down of P2P flows -- and in that complexity, Redback thinks it sees a chance to outdo the industry's giants.

"It opens up the largest IP services market we've ever seen," says Arpit Joshipura, Redback's vice president of product management.

The concept isn't lost on other companies. Session border controllers, for example, are finding their way into Cisco and Juniper routers, arguably siphoning some of the market from Acme Packet Inc. (Nasdaq: APKT) and Veraz Networks Inc. (Nasdaq: VRAZ). (See Cisco Integrates Session Control and Juniper Kills Its Session Controllers.)

Griliches points out that Redback's melting pot of features is reminiscent of CoSine Communications, which also touted feature integration with its IP-based subscription management box. But it didn't work out, and CoSine eventually became better known for its agonizingly slow shutdown. (See CoSine Terminates Merger Agreement, CoSine Seeks New Blood, and Fortinet Scoops Up CoSine IP.)

CoSine's main problem was that its box slowed down if all the features got turned on, Griliches says. By contrast, Redback is claiming that the SE 1200's functions, such as security and P2P detection, will run at 10 Gbit/s without degrading the performance of the router.

"All those features are processor and memory hogs, but Redback made sure there were separate ASICs, processors, and memory carved out for each of them," IDC's Griliches says. "It also made sure each of those features happen in a certain order in the router. It's making sure that where the stuff gets processed isn't a pull on the overall system processing."

One key point is that Redback doesn't use up router slots for most of these features -- its session border controller, for example, sits on the card that handles all control-plane functions. Security and P2P detection is housed on a separate blade, and once, for instance, a P2P flow is detected, the system can forward all other packets in that flow to the appropriate linecard.

Even bypassing the features, the raw density of the box is impressive and useful to carriers, analysts say. The new box gives Redback "a huge speed and feed argument," says Andy Buss of Canalys.com Ltd.

In addition to the increased capacity, the SE 1200 will handle eight times the subscribers of its predecessor, the SE 800 -- that is, more than 500,000 subscribers, compared with 48,000 for the older box, says Redback's Joshipura. "Subscriber" in this case refers to individual services, so that one busy household running video, VOIP, and P2P downloading all at once would count as several "subscribers" inside the router.

The SE 1200 is based on a new generation of Redback-designed ASICs. New I/O cards being built for the box include one with four ports of 10-Gbit/s Ethernet, and another for 20 lines of Gigabit Ethernet. The box has 12 slots for such cards and another two reserved for controller cards.

Redback says Taiwan's national carrier Chunghwa Telecom Co. Ltd. (NYSE: CHT), which has already deployed the SE 800, will be the first operator to use the new platform. (See Chunghwa Deploys Redback Gear .)

— Craig Matsumoto, West Coast Editor, Light Reading

ipLogic 12/5/2012 | 3:07:14 PM
re: Redback Beefs Up Its Router konafella,
also thanks for your opinon !
and I really donG«÷t mind; as said in that video G«£if you all agree, I have failedG«• :-)

but the gadgets you mentioned never really worked as promissed in the first couple of generations, and as you say they were terminal market;
people donG«÷t loose jobs if the integrated camera on the handy takes low-res pictures, but people do loose jobs if you drop 500.000 subscribers because there was bug when you updated the Signature database. (just the thought of it is creepy)

now with L3 and L4-7 in the same box ??
I don't want to blamed being against progress :-)
maybe in 3-5(7) years things change, but now there is lack of manpower to cover it. First you talk to Mr.MPLS who gives you deep dive in VPNs, but cannot spell DPI, then you have Mr.IDS who spells correctly DPI, but doesnG«÷t know the meaning of G«£iG«• and G«£eG«• in iBGP and eBGP.

And you need them both (necessary evil),
but When your (integrated) network burns who do you talk to ?


ItG«÷s just separate people (still) and if G«£integrated peopleG«• doesnG«÷t work, how will the G«£integrated solutionsG«• work ?

Once (if) production of integrated Mr.MPLS/IDS starts, then we can speak integrated solutions. Would you comfortably claim yourself being Mr.MPLS/IDS ? Would someone volunteer and take this burden on his back to claim it ? it's quite a bit of learning and expertise dispersed from L3 up to L7, is it achievable for one guy ? how many of those experts you can produce ? they keep complaining that IP is complex, what will happen when L4-7 gets into the game ?

How many people you know are really experts in Sonet header, and could simultaneously comfortably chat BGP policy expressions ? versus how many people you know that are recognised experts in Only One of the above ?

And I still keep that technically L4-7 is different Hw/ASIC architecture than L3; and fully separate blades sharing just power supplies is Ok (no interaction, separate Sw releases, and no performance compromise), but nothing more than that. You just have to clearly know which one failed, and whether you call Mr.MPLS or Mr.IDS. (and the rest of the box must keep working while one of those gentlemen plays in your life network with his part of the blades)

And finally there should be one Big red G«£Firewall On/OffG«• button that really momentarily works when things go wrong.


Do you have the swiss knife ? do you really use it for your steak ? And be honest :-) have you thrown out your (non-integrated) camera and (non-integrated) mp-3 ? I haven't... I do beleive we all will, some day ?soon?

Cheers
konafella 12/5/2012 | 3:07:15 PM
re: Redback Beefs Up Its Router ipLogic, you are right on the mark. Loosely couple everything and focus each team on making the best (loosely coupled) individual widgets and you will have dominance with the best collection of widgets the market has to offer. But unfortunately you will be stuck conquering a dying market in each individual category as the larger market moves toward integration.

Who makes the best pager? The best standalone-PDA? Best pure-mp3 audio player? You get the picture. It's not about being the best. It's about offering the most integration for the best price and doing it well (e.g. RIM, Apple, etc).

Sure, the terminal market and the network market have different market forces and different needs, but you can't oppose the trend for too long.

The features that defined the so-called "god box" in optical networking (such as ethernet, MPLS, ADM, cross-connect, etc) from the bubble era are becoming the table stakes features of today.

Ideally, I respect your opinion. Practically, the business and market forces defeat good engineering practice time and time again :(

kf
ipLogic 12/5/2012 | 3:07:17 PM
re: Redback Beefs Up Its Router metroman, you touched very good point of G«£Loose couplingG«• of people/intellect/cultures and innovationG«™

e.g. G«£Did NetscreenG«÷s development team got better (innovative, faster developing, profitable, motivated etc) G«£Tightly CoupledG«• under Juniper management (and interdepependent with M/T development team), or whould Netscreen guys have been better (innovative, faster developing, profitable, motivated etc) as G«£Loosely CoupledG«• (partnership, or similar)G«£.

and as I understand it, seems Chambers (probably experienced with his long years m&a) is trying to solve this problem with his G«£Command/Control->Collaboration/CommunicationG«• philosphy, i.e. builds organisational-culture where he G«£wants them AllG«• G«£the Best of eachG«• under one roof/logo/(collect all profits) but still G«£Loose CoupleG«• them so that they can each Innovate/Scale/Develop in the best way without the burden (and without the limits they impose between each other) if G«£Tightly CouplingG«• them together;

(G«PChambers on the CouchG«£ http://www.lightreading.com/do...
http://www.interop.com/lasvega...

and if we assume: developer-team-quality(motivation/innovation)=product-quality->

-> there you have the conclusion if you want to buy Security from Router vendor, or Routing from Security vendor; where ChamberG«÷s phylosophy seems to be looking for a model to bring together G«£Networking vendorG«• by (as) loosely-coupling them together (as possible).

based on (the correctness of) this philosophy L3-Router and L4-7-Firewall should be as Loosely coupled as possible i.e. different boxes is good, or even if you put them in the same box they should Not share anything more than the Power Supply. (and even if possible let each one of them be developed by separate G«£Loosely coupledG«• development teams, if you want to have the best of both of them)
all for the benefit to get the best of their innovation (profitablity if youG«÷re telco, or better service if youG«÷re subscriber)

so it comes to two issues:
- on one side we have the G«£Loose CouplingG«• of people/cultures/intellect/innovaton;
- on the other side we have the G«£Loose CouplingG«• of Technologies/Paradigms in this case L3 with L4-7 in the same box;


The technical part (L3 and L4-7) was touched by metroman, chook (and Mark should run this through his Interdependece model chook's N**2 problem of sub-systems in the same box)


L3 and L4-7 are fundamentally different and it is a challenge (will be dangerous) bringing them together in the same box, although it is G«£necessary evilG«• to bring them somehow together to get the G«£fullySecure-fullConnectivityG«• i.e. the ultimate goal,


1) Hw point of view: can you reuse L3 chips to do L4-7, or opposite ?
L3=IP/FIB-lookup is something else than L4-7=DPI/TCP-UDP-flow-analysis/signature/anomaly-detection, and as metroman said, reusing L3 lookup hardware for L4-7 will always bring compromise in performance to the platform that tries to combine them;
different FIB-vs-Signature match algorithms, different memory access requirements, different tree-search, different buffer requirements, (L3 does by packet where L4-7 buffers to get the full stream), L3 hierarchical addressing vs per-Flow, etc.
Router summarizes N-users->1-FIB-entry;
Firewall expands N-users*M-flows/user->M*N-Flow-table;

2) L3=IP-Router/BRAS operations is completely different than L4-7=Firewall operations
- you upgrade L3-Router sw once on 6-9(12) months, only after G«£heavyG«• trials and tests (for 500.000 subscriber BRAS even G«£heavierG«•);
- you G«£upgradeG«• L4-7-Firewall Sw(signature/protocolanomaly-database) (more or less) daily, and you donG«÷t really have the time to test or trial, but rather you are in a hurry to put that update to the box as soon as possible, before the bad-guys get you.
(Can you really ever enough test behaviour of L4-7 signatrure/protocol-anomaly under 500,000 subscribers each subscriber doing something else)

so what is the $$ price (and stress, and operations guys nerve) with the (almost daily) risk for 500,000 BRAS subscribers loosing-connectivity, if, while upgrading the Signature-database on the Firewall there might be a bug in only one of the signatures ?

3) L3=Router/BRAS run wide/global communication, (OSPF from the whole network, or BGP from other side of the world, AAA with the Radius server), where L4-7=Firewall should be G«£invisibleG«• to the world (bump-in-the-wire);
What happens if some OSPF, BGP, DHCP, PPP bug G«£opens the doorG«• to the Firewall/DPI in the same box ?
suddenly you are not just in connectivity problem, but you also lost your security that G«£shouldG«• protect your box, and prevent the problem from increasing.

So "same box" is Ok as long as they (L3, L4-7) share no more than the chassis itself, and would be good to be developed by different, Loosely-coupled teams.

Cheers
chook0 12/5/2012 | 3:07:19 PM
re: Redback Beefs Up Its Router Some very good discussion in this thread!

We don't seem to have touched on what is my single biggest problem with "God Boxes", which is that having all your functions in one piece of sheet metal synchonises all your version control operational issues.

If you have box A doing function A and box B doing function B, and you find a bug in A or need to upgrade A for some reason, then you only need to upgrade one set of functionality, only need to test and qualify the A functionality in the new code, and for most of the process at least, can forget about B functionality.

If you combine the two functions in a single box, software upgrades are more difficult from the point of view of finding the right release, qualifying and testing the release, etc. What's more it is much easier to get into a situation where no one release works for all functions. As you get more and more functionality into the box this can become an N**2 problem.

--chook
rodolg 12/5/2012 | 3:07:19 PM
re: Redback Beefs Up Its Router
in this table i only see Alcatel, Cisco , Juniper and Redback... but what about Huawei and Foundry?

In fact if we think of Smart Edge Routers we should consider the God Box of Huawei: ME60. Cisco does not have such a box like this neither Alcatel...
Have you heard about Cisco or Alcatel integrating DPI in the edge router?
StartupGrunt 12/5/2012 | 3:07:20 PM
re: Redback Beefs Up Its Router Does anyone have any comparison pricing on the set of products listed in the table?
ipLogic 12/5/2012 | 3:07:23 PM
re: Redback Beefs Up Its Router Ok, I see your point, but the decision how to transport long hold traffic might not be decided only on technological comparison, but rather which technology leads with the traffic (and gets most attention)

e.g.
(a) Broadband subscribers produce 40G backbone capacity over all-to-all automated, switched, short hold and no hold sessions aka IP.
(b) Business subscribers with value-add services (aka IP VPNs) produce 10G backbone traffic =>MPLS
(c) Business subscribers with long-hold sessions produce ?5?G backbone traffic over XXX (technology with least interdependencies)

Looking at 40G IP vs 10G MPLS vs 5G XXX, it looks most profitable to squeeze the 5G on top of the other 40+10 IP/MPLS...

Or you can say, our "well-behaved" business-day e-mails and attachments on our (monitored) company PCs and Notebooks are "peanuts" compared to the multimedia , downloads and other apps that we and our kids generate from our homes :-)

>>ItG«÷s interesting how the behaviour and generated-traffic of the subscribers will change with the new media, i.e. how often and how much we will generate information/data ? will the POTS user/traffic-statics be applicable to Internet user/traffic-statistics ?
And not just how much bps traffic but when and to/from where (dynamics, multicast, business vs residental, etc).

Cheers
Mark Seery 12/5/2012 | 3:07:24 PM
re: Redback Beefs Up Its Router Thanks ipLogic,

>> Only you're bit unfair
(a)- when considering Sonet/SDH transport: since this is One-to-One technology (point-to-point) withOut per-host-Granular Dynamic connectivity establishment capability <<

Perhaps with respect to voice services. But with respect to leased line services that do not go through SS7 controlled equipment, I would assert the comment is fair - but happy to get feedback.....

>> The keyword is "Distributed" (and bug-free of course).....<<

I would assert that the history of networking provides plenty of proof points that there are bugs / interdependencies that were not predicted acurately (and therefore avoided) by smart people; whether they be subtle timing relationships between SS7 switches or the behavior by having, or not, BGP dampening. Therefore interdependent systems are likely to always contain some inherent risk, even if it is the risk of unpredictable behavior under resource depletion conditions. The salient question then becomes when do you want to or need to accept this risk. For scaleable (millions of consumers), automated, switched, short hold and no hold sessions the risk appears to be unavoidable, today. For long hold sessions the risk is not unavoidable so then it simply becomes a question of preference - what are the cost/operations benefits/tradeoffs of additional protocol and/or equipment layers in the network. Different people answer that question differently due to opinion, organizational structure, business model, values, service mix, etc........in short, it is a market - and a market in transition at that.
paolo.franzoi 12/5/2012 | 3:07:25 PM
re: Redback Beefs Up Its Router
Integrating functions between what were previously separate products occurs all the time. It can be a good idea and is so generally when the 2 products are deployed together in a large application area 80% of the time (using the old 80/20 rule).

Why large? Because the R&D costs of doing the work has to be covered.

Why application area? Because there may be multiple applications for a product and in some cases the 80/20 rule may not apply.

Why 80/20? Because it is lower cost to make 1 box than 2 and the gained margin can be shared in a lower price. This makes sense if the gain lowers the price of the bulk of the deployment, because it would likely increase the cost of the 20%.

By the way, the complexity is still there in separate boxes. The complexity is managed in a different way and by a different group of people. That is why the more applications you pile on a network the less simple it gets.

seven


metroman 12/5/2012 | 3:07:25 PM
re: Redback Beefs Up Its Router slickmitzy

I have met many many ISPs and operators of all shapes, sizes and markets around the world and I would say that you are in the minority.

While representing router vendors I have asked the question about integrated Firewll and DPI and they historically have been generally against the idea. The reasons given are that other than the small enterprise market people are not comfortable buying managed firewall services from their SP. They prefer to manage their own security.

I think that the issue is deeper and has been touched upon in these discussions.

1. If you build all of these great features with NO COMPROMIZE on quality and performance you need several sets of Network Processors or ASICs, making the device expensive.

2. If you compromise (this almost always the truth) then the marketing spin does not meet the performance - ever turned on a new feature and seen performance drop in another area?? (Netflow is a good example - somewhere between 5% and 30% packet forwarding hit on some Cisco platforms.)

3. Buying these functions in separate devices is possible and you will get a best of breed solution (with some operational headaches). Buying in one device????...Will Redback be the best in each of these areas? Probably not any time soon.

4. R&D funding is not limitless - when push comes to shove, IP/MPLS requirements will get the first cut.

5. Support people will be retrained IP/MPLS people not specialists. They cannot afford to have a new set of support people.


What you must do is step though it - you don't get something for nothing, so you either pay more or take hit. No single company is the best at everything so what do you really want?

I would think that the DPI element is probably the most uesful of the features, especially for Ericsson who might want to start using it for billing in a wireless or FMC solution for event based billing, Targeted Ads and DRM....

Metroman
ipLogic 12/5/2012 | 3:07:25 PM
re: Redback Beefs Up Its Router Mark,
Thanks for the link, and very good paper !

Only you're bit unfair
(a)- when considering Sonet/SDH transport: since this is One-to-One technology (point-to-point) withOut per-host-Granular Dynamic connectivity establishment capability; you should consider Sonet/SDH+Class4/5+SS7 (i.e. the 56/64kbps level of connectivity, and their combined influence in the interdependces architecture). IP router is able to provide this kind of "64kbps" granular "On-demand" Connectivity between the connected hosts, i.e. doing the job of Sonet(T1/T3/..)+Class4/5(64kbps)+SS7.

(b)- when considering Ethernet: there are some built-in fundamental limits in Ethernet due to its nature and way it is build (I have put them at the end)

>>Mark "By what argument would you state that IP (or any other control plane based approached to networking) makes nodes more or less independent of each other:"

The keyword is "Distributed" (and bug-free of course). I would put it this way: even if the whole world goes down in total catastrophy, and there is single router left and its connected hosts, the hosts will All be able to communicate with each other (dynamicall, on-demand). Of course this Assumes that the algorithm implementations of the protocols on the router are bug-free and will converge and stabilize at some point in time... (but this is not my worry I leave this to the Mathematicians and Code Developers do their jobs and achieve this G«£bug-freeG«• G«£any-situationG«• capable code and algorithms, I just look at the fundamental basics of the technology). Of course assumptions/limits that apply are:
- the hosts must have pre-configured IP addresses (or DHCP must Distributed on the router, if the hosts need to move (assuming that Central DHCP also failed in this catastrophic scenario))

(a) If you want to achieve this with Ethernet it would also workG«™ but scaling pure Ethernet network for G«£before the catastrophyG«• is limited (as explained at the bottom)

(b) If you want to achieve this with Sonet/Class4-5/SS7 you will need Sonet MUX-And-Class4/5 switch-And-SS7 intelligence distributed on each location (including the last location that survived the catastrophy) but then this would be reinventing IP under another name.


>>Mark: G«£Most of the loose coupling you describe is some kind of summarization which of course has some benefit with respect to scalability. However it is not the best case of summarization, just relatively better than some others so it is an argument about degrees.G«•

YouG«÷re right itG«÷s about G«£DegreeG«•, but no other technology offers better Degree, And on so many Points/Levels in the architecture; i.e. Ethernet does per-MAC address, SS7 makes per-64k-circuit states, ATM goes per-user-connectionG«™etc


==========
The part on Ethernet

Although I have nothing against Ethernet, and see it as very good plug-and-play technology, Ethernet will Never be able to G«£Replace the InternetG«• it just doesNot Scale enough for G«£GlobalG«• G«£All-to-AllG«• connectivity, ETHERnet was just not build for that purpose, as it was solving the LAN/Campus/Metro (limited number of hosts) problem, but not solving Global (Globally Scalable) problems. The following Limits of ETHERnet apply to G«£relativelyG«• high number of hosts, which again makes Ethernet suitable for G«£relativelyG«• limited size of implementation

(the below also probably explains why PBT is in fact Not Ethernet, and should not be called or associated with ETHERnet or Bridging (I consider the term Bride to be tightly coupled with ETHERnet/Broadcast/Flooding/Learning paradigm):

Before the part below i would like to put this view not to be missunderstood as unfrendly towards Ethernet; For comparison IP is not as G«£plug-and-playG«• capable as Ethernet since it doesnG«÷t have the broadcasting/flooding/learning character, but rather it requires pre-configured (and matching) IP addresses on the hosts, and on the Routers/Interfaces. (this could be solved via DHCP, but then it looses it fully Distributed character if doing centralized DHCP management, so eventually we could distribute DHCP to the routers).

Again, I want to say below that Ethernet is not worse than IP, but it is just Different, Uncomparable, and "relatively" Limited in Size.

Note: VLANs are not considered since they are not All-to-All technology, but rather Grouped(All)-to-Grouped(All), which limits their use. (e.g. people canNot dial 911 over VLANedEthernet if the 911 operator happens to be in another VLAN than the caller is) Not to mention that this is why VLANs can not replace the Global Internet.

1.Ethernet has fundamental (built-in) scalablity limit due to its dependence on the statistical probability of hostG«÷s traffic generation (e.g. you come to a point where too many hosts are connected to the ETHERnet, and statistically at any point in time there are too many hosts that want to send a packed and CSMA/CD with its random waiting time to re-send will Not be able to help due to statistical probability that at least two of the hosts will keep trying using the medium at same moment/point-in-time, and always pool back, and no one will ever manage to send a frame on the network, or better said all sent packets will collide) (Of course increase of CSMA/CD waiting time to re-send increases the size of the network (increases number of acceptable hosts) where this statistical probability applies to bigger number of hosts, but this Waiting-Time increase in the same time reduces the efficient use of the network under lower traffic and lower host loads since statistically some hosts will wait unnecessraly (randomly) long time after collision)

2.SwitchedEthernet has build-in scalability limit due to MAC learning (kind of StateFull behaviour) and depends on statistics of user behaviour (new flow establishment) (e.g. if you have too many hosts statistically at some point in time the switches will not have enough processing power to learn MAC addresses because (statistically) too many hosts will in the same time try to establish commincation with someone else and the L2 Control Plane will have to run the Learning algorithm). Of course we could disable re-Learning in SwitchedEthernet network, and configure the switches to never clear/flush the MAC-addresses from their tables, but this will limit the network size to the size of MAC-Table of the smallest switch. (of course, the non-Hierarchical nature of MAC addresses also has its influence here) This non-flushing will also take away the Plug-and-Play nature and Disable "plug-and-play" moving of Hosts.

3.HubEthernet(broadcast-based) is more scalable for the prevoius switchedEthernet MAC-learning-limit case, and either (1) it MUST NOT be Looped (no Redundancy and 2nd path allowed), and base the complete communication on nothing more than Broadcasts (which is then Not efficient for link resources, and this is why we need SwitchedEthernet which than again has its own weakness mentioned above). or (2) if Looped (2nd path/Redundancy) it must run (at least) Spanning Tree to block the loops and avoid G«£Flood/Broadcast-to-deathG«• scenario (where Spanning Tree is not as optimal as SPF due due no topology awareness, more comments below)

4.HubCoaxEthernet has another build-in scalability limit in Physical size due to relationship between collision-detection, medium-propagation-time, and minimum frame-length. (Of course you can change/increase the max physical Size with longer minmum-allowed frames, but this introduces other innefficiencies)

5.Spanning Tree establishes Tree topology (also known as hub-and-spoke, or star) topology which are not Efficient in Meshed environments (e.g. all traffic between NY and Washington travels over Dallas (if Dallas is the Root) (note there can not be more than One Root unless using VLANs but this was mentioned on the beginning))

Cheers
slickmitzy 12/5/2012 | 3:07:26 PM
re: Redback Beefs Up Its Router
As a network manager for a medium size SP I can tell you that at least two of the features offered by Redback are ones that we have been requesting for years now.

Firewall - to be sold as value added service, as more and more people are aware of security these days, but still not technical enough to operate their host based/home router based firewall.
We have very good experience (meaning commercial success) with a similar service that is filtering application layer malware for broadband users.

DPI - P2P file sharing counts for more then 60% of our transit traffic. our statistics show that most of it is coming from about 10-15 percent of our users.
Those applications are hard to detect at the network/transport level, and a DPI device seems like a good option to control this traffic.

There are of course other solutions to achieve the same goals, but most of them have a lot of operational limitations.

Cheers
ipLogic 12/5/2012 | 3:07:26 PM
re: Redback Beefs Up Its Router materialgirl, you use "complex" as adjective, I used "complexity" as synonym with (basic/needed) functionality... like even drawing a line on paper is more complex than doing nothing, but if you need to draw that line that you must perform the function and this implies "complexity" compared to doing nothing.

So my point was Necessary vs UNnecessary functionality to achieve a goal
G«Ű Complexity is coupled with functionalityG«™ i.e. (rfc3439) G«£Complexity ..is driven by the need for robustness to Uncertainty...G«•

The question is which Level of Uncertanity you decide your system need to be robust against ?

IG«÷m not proponent of PBT since I donG«÷t see any new Concepts or value-add in PBT (other than pressure on core router vendors prices)
- plus negative of PBT is inefficient wasting of node Fabric capacity because it pools 20+ Byte MAC-in-MAC L2 header per packet through the Fabric;
- and it adds Layers in the architecture since it is not self-contained (no Hierarchical addressing, and Global routing capability i.e. very limited) PBT is kind of new pair of shoes to IP, where IP does all the running (Global reachability, etc)

PBT is nothing new... you can as well do IP-in-IP with ToS-in-ToS with Label-in-Label (same stuff, bits & bytes with different names) with:
(a)- pair active and backup Static-route per core node IP-address, (PBTG«÷s current approach as I understood, due lack of Control Plane), or
(b)- manage all from Centralized System,

Since (a) is not very serious solution, and is not robust enough (impliying its preached un"complexity"), only (b) is worth talking about.

So the main Concept question with PBT vs IP is G«£Where the Control Plane should beG«• and whether it should be Centralized (Tightly coupled) or Distributed (Loosely coupled).

(A) Based on (rfc3439) G«£Tightly coupled systems systems with Complex Interactions and tight coupling are likely to have unforeseen failure states (of course, complex interactions permit more complications to develop and make the system hard to understand and predict)G«•...

i.e. bug on Central Routing System will kill the whole Network, but bug on a Router kill just the router and other routers can then reroute around it.
Not to mention that Centralized Control implies another network between the network nodes and the control itself (like SS7's STP/SSP/SCP network) which is then "Additional Layer" and additional complexity (avoided being mentioned in PBT).

With IMS as QoS-mechanism I see the situation is bit different since it is not as tightly coupled with the network i.e. even if IMS has total brake down, the network can still keep working (without QoS but still working). So IMS is additional functionality (value-add, only I don't know much about it) but still in its own separate domain.

p.s. Can someone tell me what is found "complex" about IP, from point of view of Necessary vs Unnecessary functionality ? I don't see which algorithm used with routing is over-kill, and doesn't have a reason for being there ?

I see IP as Concept has build-in many Concepts of G«£Loose couplingG«•
1- Routes and Summaries instead of per-Flow (aka circuit, aka per single MAC address) approach, decoupling number of hosts to Network routing-table Scalability
2- Distributed intelligence/protocols decouple and make Nodes more or less independent of each other.
3- Areas in OSPF (ISIS) decouple the spf algorithm and Not disturb each other with topology details and changes
4- BGP on top of AS not to bother with topology and IGP
5- CoS decoupled from per-Flow (user application) states

Cheers
rodolg 12/5/2012 | 3:07:26 PM
re: Redback Beefs Up Its Router Is interesting the PBT case...

PBT puts the intelligence in the network management system, similar to SDH. In the PBT case the decision was to put the intelligence outside the box, in order to provide a more simple hardware.

Is a way to address the question:
were to put the complexity?

PBT seems like a return to the SDH point of view, were the equipment only did crossconnections and the Management had the intelligence to do the service provisioning.

Is also interesting to mention that the new generation Tx equipments are now using intelligence in the box and not only in the management system.

Look at the case of ASON Networks, ASON is a Tx equipment using protocols such as OSPF, RSVP-TE in order to provide more intelligence to the equipment.

So is interesting that PBT promotes an old idea of the Tx equipment, while the Tx equiment has abandon it.

I think is important to provide simple solutions, but simple does not mean dumb, again the point is where to put the complexity:

we could add a posible answer:
outside the Network equipment?



Mark Seery 12/5/2012 | 3:07:26 PM
re: Redback Beefs Up Its Router iplogic,

>> 2- Distributed intelligence/protocols decouple and make Nodes more or less independent of each other. <<

By what argument would you state that IP (or any other control plane based approached to networking) makes nodes more or less independent of each other:

http://www.interflect.com/docu...

FYI, the convention I have been using is:

1) complicated = not simple
2) complex = interdependent

not saying that convention is absolutely correct, just one I have been using.

>> I see IP as Concept has build-in many Concepts of G«£Loose couplingG«• <<

Most of the loose coupling you describe is some kind of summarization which of course has some benefit with respect to scalability. However it is not the best case of summarization, just relatively better than some others so it is an argument about degrees.

>> p.s. Can someone tell me what is found "complex" about IP, from point of view of Necessary vs Unnecessary functionality ? I don't see which algorithm used with routing is over-kill, and doesn't have a reason for being there ? <<

if you are talking about an IP router with one IGP and one EGP doing "connectionless" IP routing then I would say nothing I can think of. it is a respected implementation of a mode of networking that has produced many benefits. it is in fact one of the points of RFC3439 to highlight this (the other to not complicate IP by trying to get it to do something else). it is not complicated in and of itself, but it may be still complex (by the definition I previously provided). complex is of course a word which is interpreted in multiple ways by different people, so would be handy for people to provide a definition when using it.
Pete Baldwin 12/5/2012 | 3:07:28 PM
re: Redback Beefs Up Its Router Couple things ... Redback did, indeed, use a software partner for all the security features. They say they'll be disclosing more details later.

And not every features eats up cards -- jepovic, I had the same initial reaction as you, in that regard! The story notes the SBC case in particular.
materialgirl 12/5/2012 | 3:07:28 PM
re: Redback Beefs Up Its Router rodolg says:
"I agree, the point is where to put the complexity."

Then, on the other hand we have the emergence of PBT. What does that say about BT's thinking on this subject? Operations think MPLS is too complex. How will they ever deal with even more intelligent networks? And to what end, since they have no idea what services they intend to provide?

Just curious.
rodolg 12/5/2012 | 3:07:29 PM
re: Redback Beefs Up Its Router I agree, the point is where to put the complexity.

It is clear that an all IP network requires more than just simple core routers and carrier ethernet switches, the telecom network needs more intelligence to satisfy service providers and subscribers demands. For example the IMS arquitecture is a complex one, and it adds session management intelligence, and requires that the service control layer communicates with the network layer.

Is is important that the IP Network must be service aware, it cannot just forward IP packets according to its priority, and this requires more than routing. The IP network must know and understand the service it is carrying and adapt to it.

The big question is of course were to put the intelligence in order to do this? And this is a tough one, because it should be answered in such a way that it can be cost effective and easy to operate. In one box? , in multiple boxes?, in the edge? In the access ? etc..,

Some in the industry believe that the intelligence of the network should be put in the Edge router, because is the first IP Hop. This makes sense because it will reduce the number of elements with intelligence in the network meaning less expensive complex boxes and less configuration and troubleshooting, but the normal reaction is to worry about one complex box and its realibility. So there is much debate in the industry about it. Some propose to put the intelligence in the edge in a distributed way, more than one box

Redback is not the only one doing one Intelligent Edge Router, Cisco added SBC Functions, Huawei has a god box called ME60 which also integrates DPI, SBC, Firewall, BRAS and routing functions in one box. This type of Intelligent Edge Routers are very new in the market, and only time will tell if they will be accepted or not.

Something that is clear, that the evolution of the IP network will somehow force more intelligent features in routers and carrier ethernet switches,they cannot only forward packets. The question will be which ones ?








ipLogic 12/5/2012 | 3:07:29 PM
re: Redback Beefs Up Its Router Confusing is solving problems on the Wrong/Right place (also to decide what is the Right Place)... Its all about puting the Right Functionality/complexity on the Right Place. So both are right G«£it should be simpleG«• and G«£sometimes it has to be complexG«•, the problem is G«£Where?G«•.

rjmcmahon: "Is a hybrid car or the human body agglutinating problems by using multiple energy stores to create motion, i.e... "

You are right, there are functions/complexities of a Human body in the body itself, but this Body-Specific functions/complexities are Not either in the cars/buses/airplanes, nor in the highway-system. In this case of networking, our Application/P2P/IPSec functions/complexities are on our own owned PCs(e.g. bodies) and (seems) shouldNot be either on our access-links(e.g. cars/flights), Nor the network(e.g. highway-system). (It also influences our Privacy)
- although they still depend on each other (loosely coupled) e.g. you need (functioning) Car & (non-congested) Highway when need to get your Body to the Hosptial or the Supermarket :-)

This approach split and keeps orthogonal relations between functions/complexity of each entity/system, i.e. the complexities/functionalities are Independent (and can Grow/Scale Independently if/when needed) of each-other. (see rfc1958(2.1) and rfc3439 (2.2.2. Loosely coupled vs Tightly coupled systems flexibility)). This means that KISS applies (in some form), and as result as benefit of this it Should be (more) Scalable, (more) Robust and High-Available (less prone to failures), ?Cheap(er)?,...; (I donG«÷t know the formulas that prove all this, only cite the theories, and experiences)

In the case of Internet the PC takes functions/complexity of the G«£ApplicationsG«•, and the Network takes functions/complexity of G«£Connectivty and Global reachG«•, and each one (should be) as much independent from each other as possible. Otherwise mixing the above could be unnecessary and creates the confusion (e.g. our Home-gateway doesNot need full BGP routing table, and SPG«÷s networks/routers shouldNot care about our Applications and flows, because this would make them more Tightly-Coupled, which should be Avoided for the sake of Scalability, Robustness, ?Price?, etc. and also hurts our Privacy).

So the question is which Function/complexity belongs to whom; And depending on this you will see if G«£complexG«• edge routers are really necessary or not, or better said G«£complex for Which functionsG«•; and finally which choice is better & cheaper for the Subscribers (since this is all directly connected with SPG«÷s market penetration, revenues, success, etc, and with Ours usersG«÷s experience, cheap service, etc.);
So the principle G«£as simple as possible, but not simplerG«• is coupled with the question G«£which functions go whereG«• (and this "Where?" is the confusion)


From the History (and split of opinions on G«£Where?G«•):
(A) POTS: Subscribers just own simple telephone (i.e. Audio-Electrical converter) --and-- Network owns Intelligence (Dialing tone, Dialed-number-analysis, IN/SS7, QoS, Centrex, etc) - maybe the technological development (price of Hw) at that time (19/20th century) this was the right for that approach.
(B) INTERNET: subscribers own fancy(complex) (own property, privacy) PC, mobiles, TV sets, and the networks provides simple connectivity - maybe the technological development (price of Hw) this days this fits better to this approach.

ItG«÷s interesting how the behaviour and generated-traffic of the subscribers will change with the new media, i.e. how often and how much we will generate information/data ? will the POTS user/traffic-statics be applicable to Internet user/traffic-statistics ?
And not just how much bps traffic but when and to/from where (dynamics, multicast, business vs residental, etc).

Cheers
jepovic 12/5/2012 | 3:07:29 PM
re: Redback Beefs Up Its Router Very good point!

Another associated problem is that noone will use all of the features, which means that the useless features are just adding complexity.

E.g., if Redback integrates an only half-decent firewall, very few customers will use it but everyone will suffer from the complexity.

In this case though, my first thought was: That's a lot of cards! Will there be any space left for interface cards?
rjmcmahon 12/5/2012 | 3:07:30 PM
re: Redback Beefs Up Its Router Hmm. Pretty scone-hot reply to something which was a light-hearted statement in the first place. Hit a nerve, have we?

Yep, hit a nerve. I'm tired of the hearing engineers use reductionist "truths" in the midst of complexity. It doesn't work for modeling my neurotransmitters as you might guess.

Thanks for the reference to RFC3439. I'll give it a read.
chook0 12/5/2012 | 3:07:30 PM
re: Redback Beefs Up Its Router Hmm. Pretty scone-hot reply to something which was a light-hearted statement in the first place. Hit a nerve, have we?

But more seriously, the statement to some extent responds to one thing I see a lot in the industry - the neverending search for the one-box solution to all your problems.

I don't think anybody is disputing the fact that, at a given level of price, reliability and manageability, a single box that does everything is better than more than one box that together perform the same function.

The problem is that it usually isn't what you get. Typically you end up with a solution which is more expensive, less reliable, lower-performance or less manageable because compromises have to be made in order to squash everything into the same box. Furthermore, if you look at the network as a whole you end up with stranded resource because the boxes always have too much of one thing and too little of another for your specific needs. That's not a problem in itself, except that typically you end up paying for the stranded resource.

That said, if Redback can get the swiss-army knife to perform well and reliably they will clean up in the marketplace. In my view, we are still a ways away from having the perfect edge box.

For an attempt at a more serious codification of architectural principles, try reading RFC3439. You may disagree with some of it, but every architect should read this.

--chook

----------
(5) It is always possible to agglutinate multiple separate problems into a single complex interdependent solution. In most cases this is a bad idea.
--------------
While I can't speak to the specifics of this device I think these types of statements are nearly useless. They give little insights towards solving real world problems, most of which are complex.
[........]
Archinet 12/5/2012 | 3:07:30 PM
re: Redback Beefs Up Its Router I am not worrying about the one box or multiple box solution. In modern chassis you practically have network inside, so this does not make a lot of difference.
I am suspicious about the ability to provide cutting edge expertise for all applications: Firewall, DPI, Session Border Control, IPS/IDS and so on. I have not heard about any significant acquisitions made by Redback/Ericson in all these areas, like Cisco and Juniper did. May be they OEMed these technologies from other companies - may be, but is not likely.
May be Redback assumes that residential subscriber management does not need the highest level of DPI or security. I doubt. These are the things like anitvirus - where or you are providing the best of bread or you are meaningless
xornix 12/5/2012 | 3:07:31 PM
re: Redback Beefs Up Its Router "Customers are asking for these features (Firewall/Security, DPI, SBC, etc.) in an edge router because it makes sense to apply these in one device at the edge where they face the customer/subscriber."

I think the boxes facing the customer are rather the so called "IP" DSLAM/OLT of this world. Actually, you may envision quite a lot of traffic being switched before the "edge router" (whatever it means) and not even flowing through it.

The only place where you are really sure to get all customer traffic is the first physical connection point, namely the DSLAM/OLT.

Obviously, the economic equation then changes with a lighter loads on a much higher number of nodes.

Regards
mr zippy 12/5/2012 | 3:07:31 PM
re: Redback Beefs Up Its Router More seriously: The idea of mashing all these features together isn't new or patentable. The question is whether it's a good idea. Anybody have an opinion on that?

"Complex = more things that can break", Anonymous, slashdot.org
databoy12 12/5/2012 | 3:07:31 PM
re: Redback Beefs Up Its Router That's a pretty petty knock on Redback's SE platform and an incorrect one Lightheaded. The SE does forward minimum sized ethernet packets at 10 Gig/sec, it just can't do it in all slots. And how much traffic is really minimum packet sized, especially since the new wave application seems to be video? If you want to forward minimum sized ethernet packets in every single slot, then Redback now offers an SE1200 that will do this at 20 Gig/sec. Yes, you did point out probably the one weakness the SE800 does have, but does this stat actually matter in the real world with real world traffic? Probably not.
light-headed 12/5/2012 | 3:07:32 PM
re: Redback Beefs Up Its Router Customers are asking for these features (Firewall/Security, DPI, SBC, etc.) in an edge router because it makes sense to apply these in one device at the edge where they face the customer/subscriber.

If you can offer these features and they work fairly well and have good performance then it is of value. This is easier said than done and it remains to be seen how well redback can do this when the SE with PPA2 cannot even forward minimum sized ethernet packets at anywhere near linerate 10 Gigabit.

These high-touch features that cannot be baked into ASIC/NPU are the ones that cause heartburn. They require a lot of general processing power. The more that can be put into silicon the better.
GreenBall 12/5/2012 | 3:07:32 PM
re: Redback Beefs Up Its Router On the link bellow is the heritage list of the patents Fortinet got by buying Cosine IP:
http://www.fortinet.com/news/p...
Mostly they are related to the Virtual Routers...
So, the infringement in tha case applies to all vendor using Virtual Routers like Juniper, Cisco ...
rjmcmahon 12/5/2012 | 3:07:33 PM
re: Redback Beefs Up Its Router (5) It is always possible to agglutinate multiple separate problems into a single complex interdependent solution. In most cases this is a bad idea.

While I can't speak to the specifics of this device I think these types of statements are nearly useless. They give little insights towards solving real world problems, most of which are complex.

What defines a problem as separate? Is a hybrid car or the human body agglutinating problems by using multiple energy stores to create motion, i.e. should the motion be sub classified so that the "solutions" can be kept orthogonal? Defining the problem as converting energy to motion seems overly broad to a reductionist.

Is a PC be considered as agglutinating multiple problems into one complex solution? Or compare windows vs. unix where windows tightly integrated separate solutions and easily won market share over the "independent" solutions presented by unix.

A network acting as a platform is a lot more complex than one acting as a medium for a specific problem and hence a single application. Paying for such a platform is even more complex.

So these types of statements really aren't very helpful in my opinion. If one sees problems in the solution presented it would better to point them out specifically rather than fall back on silly statements advocating blind reductionism.
Pete Baldwin 12/5/2012 | 3:07:34 PM
re: Redback Beefs Up Its Router The RFC chook referred to is here:

http://www.ietf.org/rfc/rfc192...
materialgirl 12/5/2012 | 3:07:34 PM
re: Redback Beefs Up Its Router chook says:
"---
Number 5 of the 12 Networking Truths: (RFC1925)
-----------------------------------------------"
That was good. Can you point us to the other 11?

Separately, perhaps this means that complex networks are a bad idea. If it is bad to put X functions on one box, isn't it worse to put one on each of X boxes?
chook0 12/5/2012 | 3:07:34 PM
re: Redback Beefs Up Its Router "More seriously: The idea of mashing all these features together isn't new or patentable. The question is whether it's a good idea. Anybody have an opinion on that?"

---
Number 5 of the 12 Networking Truths: (RFC1925)
-----------------------------------------------

(5) It is always possible to agglutenate multiple separate problems into a single complex interdependent solution. In most cases this is a bad idea.
-------------------
Pete Baldwin 12/5/2012 | 3:07:35 PM
re: Redback Beefs Up Its Router This is gonna sound more sarcastic than its meant to, but ....... If the Redback box actually works, doesn't that imply they aren't using CoSine's intellectual property?

More seriously: The idea of mashing all these features together isn't new or patentable. The question is whether it's a good idea. Anybody have an opinion on that?
WillLiteFiber4Food 12/5/2012 | 3:07:35 PM
re: Redback Beefs Up Its Router ... if I remember correctly, a number of the ex-CoSine engineers ended up landing at RedBack. Is it just a coincidence that CoSine like features are now showing up in RedBack's products? Was CoSine onto something, but they were just too far ahead of the curve? Should Fortinet be filing IP infrigment claims?
HOME
Sign In
SEARCH
CLOSE
MORE
CLOSE