Technology & Standards Category Archives
April 28, 2008
Welcome to the Exabyte Era, part 2
In a previous post, I wrote about our Cisco IP Traffic Study, entitled “The Exabyte Era.” It’s getting a lot of attention now as its topic is being featured as one of the drivers of the need for new platforms such as our recently launched Cisco ASR 1000 and because the adoption of web 2.0 and “all-things video” is getting increasing relevance to the industry, the market, and our daily Connected Life, whether it be at home, at work or on the move. It is well worth a read and was even was featured on the front page of the New York Times, a few weeks ago.
Here are a few of the takeaways for those who like the Cliffnotes versions:
At Home, the story is video, video, video. Here are some video’s effects as a driver of bandwidth growth.
• Three years from now, Internet video will be six times what it is today, and twenty times what it was in 2006.
• In 2011, online video will generate 1 billion DVDs worth of traffic each month.
• Online video will drive 30% of consumer Internet traffic by 2011.
At Work, new business services and applications will drive the growth:
• By 2010, telepresence will generate more traffic than the entire US Internet backbone in 2000.
On the Move: the coming ubiquity of Mobile Data
• Mobile data traffic in 2011 will be sixteen times what it is today.
The next few years should be quite exciting for the industry, and, because providers are actively investing in their networks to get ahead of the end customer demand for bandwidth and value-added service, the next three years will have quite a beneficial impact to all aspects of our own Connected Lives as well.
Posted by Doug Webster at 12:51 PM Permalink | Comments (0) | TrackBacks (0)
April 24, 2008
What is an Exabyte?
“What comes after Petabyte?” was my question to Arielle Sumits, our lead researcher on the IP Traffic Study a few years ago, when we started the effort a few years ago. Even with a wide variety of very regional and granular market forecasts on topics such as “VoIP subscription growth in Western Europe” and “IPTV subscriber forecasts for AsiaPacific,” we didn’t have visibility on what these all mean to the network as a whole. And having a global focus with a global customer base, we needed a global view. Since the market didn’t offer one, we set off to create one (and from Arielle’s standpoint, she likely did it to cease the never ending questioning from me along the lines of “But what does this all mean?” Depending on my level of caffeine consumption, my questioning can often be a far too fast and quite annoying… as my wife, Annie, can firmly attest).
So in a quest to silence my questioning, Arielle went about a very extensive modeling effort, piecing together all of the more granular third party forecasts of subscription forecasts from analyst firms, such as (in alphabetical order) ABI, Dell’Oro, Gartner, IDC, Informa, Kagan, MRG, Ovum, Pyramid Research, ScreenDigest, Synergy Research, Telegeography and Yankee Group. She then factored in usage data and assumptions such as average amount of time a subscriber watches TV a day, if they have high definition, how much of their viewing does that entail, if they have a PVR, how much does that affect the streaming of video to the home even it the content is never viewed, etc. Finally, the model was worked back with Cisco engineers to determine the total sum of the impact of on the network.
The result we reached (and by we, I mean Arielle) was a sizable figure… one that was in excess of 1000 petabytes, which then caused me to ask my infamous “What comes after Petabyte?” question. The answer, courtesy of Wikipedia, was “Exabyte,” hence the “Exabyte era” was born.
Now, in its sixth iteration, our global IP Traffic Growth study is forecasting 29 exabytes of IP Traffic per month or nearly 350 exabytes per year by 2011, only three years from now. While that seems very aggressive to some, our CEO John Chambers has pointed out that, in this fast-moving industry, often seemingly aggressive forecasts can eventually prove to be conservative. This may very well be the case here, not just because we (and yes, I mean Arielle) intentionally based the forecasts on the lower end range of usage assumptions to maintain credibility of the project as research instead of marketing, but also because the growth of the applications and the rapid adoption of them by empowered consumers. For example, once my father began receiving high-definition television (a day that will always be cherished by him), he now does all that can to watch nothing but high-definition content, which takes up far, far more bandwidth than standard definition. And even at Cisco, when we (and by “we,” I really mean our incredible IT shop) launched its large deployment of TelePresence sites in our offices around the world (at my last count we were over 175 and reducing our travel expenditures by 20%, not to mention carbon emission reduction), our internal traffic grew not by 42% year over year but in the hundreds of percent.
So with nearly 350 exabytes forecast for 2011, I am faced with an interesting question as the seventh round of our study commences and the time frame is extended a bit further:
What comes after exabyte?
Posted by Doug Webster at 07:20 AM Permalink | Comments (0) | TrackBacks (0)
April 14, 2008
Ring vs Mesh topology in Carrier Ethernet networks
Network architects have debated over the best way to interconnect network elements. The ring camp believes that the best way to recover from a failure is to have a simple topology where all nodes have a similar access to the bandwidth. The mesh camp believes that the most scalable and flexible way to interconnect network elements is in meshes.
Service Providers are familiar with SONET rings and they expect Ethernet based rings in Carrier Ethernet networks to perform similarly. However, Ethernet rings are expected to behave like Ethernet networks with oversubscription, redundant access, node protection, link aggregation and so on. Thus, Ethernet ring requirements can be more complicated than SONET ring requirements.
Do we have to mandate a ring topology in Carrier Ethernet networks?
It will be very attractive if a protocol can support both ring and mesh topologies in Carrier Ethernet networks.
Posted by Rajiv Kapoor at 06:53 AM Permalink | Comments (0) | TrackBacks (0)
March 10, 2008
Towards IPv6
The topic of IPv6 is not new in the industry. In fact, IPv6 has been hotter now than ever, particularly around IPv4 address exhaustion and application readiness. Cisco’s Tony Hain is an IPv6 Forum Fellow.
Cisco IPv6 product manager and evangelist, Patrick Grossetet has been driving IPv6 development at Cisco.
Geoff Huston, Chief Scientist APNIC has been exploring IPv6 transit.
In fact, this past January 2008, Google held an IPv6 summit where both Tony and Patrick had been present.
Google’s Vint Cerf hosted the summit; and Vint facilitated the IPv6 discussion with industry thought leaders, architects.
Patrick spoke about planning for IPv6 integration. One can view the YouTube dialogue at: Google IPv6 Conference 2008.
- What will the IPv6 Internet look like?
- IPv6, Nokia, and Google
- Planning for the IPv6 Integration
- IPv6 and the DNS
- IPv6 on Windows
Conclusion, service providers will be pivotal in IPv6 implementation internationally. The industry is still grappling with the issues around IPv6 transition for infrastructure, applications and content. IPv6 implementation is not a matter of if rather, it is a matter of when.
IPv6 stay tuned!
Posted by Monique Morrow at 10:29 AM Permalink | Comments (0) | TrackBacks (0)
March 05, 2008
Introducing the World’s Most Powerful Compact Router… (And changing the notion of what’s possible in routing in the process)
Yesterday, we introduced the newest addition to the Cisco edge portfolio, the Cisco Aggregation Services Router 1000 series, which is a testament to innovation of our engineers, a foundational platform to help providers transform the edge of their networks, and a proofpoint to our IPNGN architectural vision. We have a massive amount of content that can provide quite a bit of detail on the product and Suraj has already highlighted the virtual, viral, and visual aspects of the marketing that went into this launch. For this forum though, I think there are three key aspects of this platform which will have particular ramifications for the providers business.
Establishes a new price/performance class at edge
Placed between the Cisco 7200 and 7600 series routers in the Cisco edge portfolio, one ASR is equivalent to 160 Cisco 7200 series routers. Compared to competitive, multivendor solutions, it costs less than half, requires only a third as much Opex annually, and uses just a fraction of the space. Synergy Research did a study of it before launch and wrote, “Not only offering a distinct capital expenditure advantage, owning a Cisco ASR Series router over a five-year period, in comparison to the competitors’ appliances, also constitutes a OpEx saving ranging from 1.6 to 4.7 times per year.”
Benefit to providers: Get much more for far less for faster return on their investment
Enables “Instant-on” service delivery
Embedded capabilities on every Cisco ASR 1000 permit new services to be activated with a keyboard versus a truck roll. Think about that – this is pretty amazing, because no appliances or even blades are needed if the provider wants to turn on a session border controller or firewall within the router – it fundamentally raises the bar as to how services will be delivered in the future.
Benefit to providers: Put customers on (and bill for) a service faster for less cost, not to mention reductions in sparing costs, increased customer satisfaction, and more.
Reduces carbon footprint
Compared to competitive solutions, a single ASR can save the equivalent carbon emissions of upwards 17 tons of coal annually (or upwards of 77 barrels of oil).
Benefit to providers: This high degree of energy efficiency is important not just from a social responsibility standpoint, but also, because power takes up such a large amount of operations expense, it directly affects a provider’s bottom line.
As you know, we usually don’t talk about such product detail in this forum. It’s important to do so today though. While we spend most of our time in this blog discussing high-level issues affecting the service provider industry, it’s important to note that we are constantly innovating to help our provider customers have as flexible, capable, and robust of an IPNGN as possible to make the most of their business. The Cisco ASR 1000 is a great and timely example of that continued commitment. So while some may look at this as another product, we look at it as much more -- another proofpoint towards our architectural vision, another proofpoint towards enabling our customers to succeed.
Posted by Doug Webster at 01:13 PM Permalink | Comments (0) | TrackBacks (0)
March 03, 2008
SP CTO Update
Since my last posting welcoming the Chinese New Year in January, I have been fairly busy and yes standards has been definitely top of mind. So in January 2008, the ITU-T SG 13 was hosted in Seoul, South Korea.
The crux of the meeting was around TMPLS OAM Requirements, draft G.8113 and TMPLS OAM Mechanisms, draft G.8114 in Question 5 of SG 13. IETF-IAB sent key leadership members to participate in the meeting as representatives of the Internet Society or ISOC. The IETF-IAB had expressed grave concerns around TMPLS, re-use of label 14 and interoperability overall with existing MPLS networks. The IETF-IAB had participated in an interim meeting held in, September 2007 jointly with ITU-T SG-15 leadership, where an agreement to collaborate in the form of a Joint Working Team, JWT-Ad Hoc team had been reached.
Study Group 13 approved to terminate the AAP (Alternative Approval Process) for two T-MPLS OAM draft Recommendations, G.8113 T-MPLS OAM Requirements and G.8114 T-MPLS OAM Mechanisms, which were consented in April 2007. At the subsequent SG-15 meeting in February 2008, there had been discussions around framing the JWT work in five work areas:
1. Forwarding Plane
2. OAM
3. Control Plane
4. Survivability
5. Network Management
The JWT-Ad Hoc team will be jointly lead by Malcolm Betts, ITU-T SG 15 Q.12 Rapporteur and David Ward, IETF.
So the work is just beginning….
Changing the topic, I will be participating in the Global Industry Leaders Forum on March 10 in Thailand, in a session on Universal Access to be chaired by CAT CEO, Mr Ph. Jorphochaudom.
This venue, will be followed by the Global Session of Regulators.
Cisco Sr. Director of Government Affairs will be participating in a panel discussion on March 11.
Stay tuned for disruptive technologies and business models in my next blog!
Posted by Monique Morrow at 08:02 AM Permalink | Comments (0) | TrackBacks (0)
February 27, 2008
IPSec
Co-authored with Shyam Kota, Product Manager at Cisco working towards a secure Internet infrastructure
With the advent of Web 2.0 applications, enterprises and their respective service providers are viewing the network as a service enabler that transports critical business applications. Doing so over the public internet is considered risky from an infosec perspective, prone to loss of data confidentiality to hackers and fraud. To ensure secure transport of data, various proprietary protocols were developed - however the scope of these were limited to the application they were designed to serve. To overcome such limitations and ensure a uniform end-to-end security framework, IPSec for IP was developed by IETF.
What makes this Possible?
Designed by the Internet Engineering Task Force (IETF) as the security architecture for the Internet Protocol, IPSec defines IP packet formats and related infrastructure for transporting IP traffic with end-to-end authentication, ensuring integrity and confidentiality for network traffic. IPSec protocol allows for negotiation of IPSec policies and security associations and transporting encrypted data over any network (public or private) between trusted peers/systems.
The Solution
For transport of data securely, two common approaches are available. For telecommuters and remote users, IPSec tunnel can start at the end user (PC) and terminated at the SP edge. The data from the user can be transported securely over the internet and decrypted at the SP edge and sent to the final destination over an IP/MPLS network.
The other approach is to create a IPSec tunnel between Enterprise edge and the SP edge, whereby all traffic is encrypted by default.
The first approach allows for secure remote access for all users and requires support for termination of potentially thousands of IPSec tunnels at the SP edge. The latter approach allows for secure data transport for enterprises between headquarters and branch offices via the SP core network.
For service providers, the ability to offer secure VPN service in the network is very appealing value add. This approach can also enable offering new services rapidly, in areas where the SP does not have a services footprint. Cisco has a complete portfolio of solutions that provide IPSec support. The workhorse of the service provider edge platforms - Cisco XR-12K - introduces this functionality via the IPSec shared port adapter - each of which can deliver up to 2 Gbps of AES and 3DES encrypted data traffic along with scaling up to 16,000 site-to-site or remote-access IPsec tunnels simultaneously.
Posted by Kelly Ahuja at 03:31 PM Permalink | Comments (0) | TrackBacks (0)
February 26, 2008
Welcome to The Exabyte Era
The next big wave of IP traffic growth is upon us, which will be having dramatic impacts on the providers and their networks. At the “Core” of it all (please forgive the pun and foreshadowing…) is the empowered consumer, who is using video and Web 2.0 networked-based applications in ways unforeseen just a few years ago and, in turn, is helping to inspire major changes at the business customers as well. Randall Stephenson, Chairman and CEO of ATT, recently made a comment that the bandwidth glut of the past is gone and, ironically, was exhausted by “primitive” applications (Click here for a Light Reading story of Mr. Stephenson’s comments) – as more sophisticated applications come about into the mainstream, such as telepresence and more high-definition video, the need for bandwidth will sky-rocket.
From Cisco’s perspective, we are projecting this surge in the amount of bandwidth required to be massive, growing from 6.6 exabytes a month in 2007 to nearly 29 exabytes per month -- more than quadrupling in less than a half decade.
To put this in context, 29 exabytes a month is equivalent to:
29,000,000,000 Gigabytes.
Or nearly 144 times all of the world’s printed matter.
Or nearly six times all the words spoken. Ever.
Or 7,250,000,000 DVDs streamed online.
Or 1160 times the amount supported by the U.S. Internet backbone in 2000.
These growth figures were gained from a modeling exercise we did using third party analyst forecasts on service growth and then, with the base assumptions on the use of those services, determined the resulting traffic impact on the network itself. Such insight helps both Cisco and our SP customers prepare for what’s ahead as implications are wide-ranging throughout the network including the hub of it all, the Core, which we’ll be talking about more soon.
I’ll cover this study further in a future post, and, if you just can’t wait, please check out the great whitepaper that Arielle Sumits, our lead researcher on this topic, put together on the study.
In the interim, don’t forget to register for the big announcement and launch event we have planned for March 4th. I’d very much welcome your thoughts on it.
Until then, thanks for reading,
Doug
Posted by Doug Webster at 05:25 PM Permalink | Comments (0) | TrackBacks (0)
January 15, 2008
Protecting the Perimeter
As the Internet and access to it becomes more and more prevalent around the world, service providers, enterprises as well as small and medium businesses are challenged to protect their internet infrastructure from hackers and malicious applications causing business disruption. One of the key applications that has evolved over the years is the firewall. Firewall acts as a regulator between networks at different trust levels. Typical examples of trust levels being the Internet and a corporate internal network.
How it works
Firewalls are used for packet inspection & filtering, application proxy & stateful inspections of packet flows through the network. It is typically positioned at the network perimeter or provider edge - where internet traffic come in or goes out of the network.
Packet filtering allows for inspecting individual packets against a set of parameters that allows for access control. This allows the system to filter out all unwanted traffic. However, this can break some of the applications running on a packet network. In order to ensure these applications run smoothly - firewall can act as a proxy or perform stateful inspection of packet.
What makes this possible?
For service providers, the protection starts at the perimeter of the network. This means fortifying the provider edge routers with FW functionality. This adaptive "single device, many uses" approach reduces the number of platforms that must be deployed and managed while offering a common operating and management environment across all of the network edge. This approach simplifies configuration, monitoring, troubleshooting, and security staff training. One of the popular provider edge platforms - The Cisco XR-12K - introduces this functionality via the Multi Service Blade, which can provide multiple Firewall contexts to enable service providers to leverage firewall virtualization to support and segregate multiple customers on a single physical device.
Posted by Kelly Ahuja at 09:21 AM Permalink | Comments (0) | TrackBacks (0)
December 03, 2007
The Gaming Explosion
In my last post, I explained how integrating IP and DWDM layers closer together helps providers to scale their core networks. Last week, the world’s largest computer festival got underway and proved the IPoDWDM technology’s ability to deliver on that promise.
DreamHack Winter 2007 just ended at Jönköping in Sweden with around 10,000 attendees plugging their own computers to the network specially setup for the event. It’s focused on everything you can do with computers, a lot of gaming and communication, but also programming, designing, music composing, plus a variety of other activities. The hunger of these bandwidth-gorging, network-gaming attendees knows no bounds. And thus, at the core of the network lies the world’s fastest router – Cisco CRS-1. TeliaSonera, the bandwidth provider for DreamHack, chose to deploy this router at the two locations of Jönköping and Stockholm interconnecting the 300 kilometers distance by 40Gbps IPoDWDM technology.
This event attracts die-hard gaming enthusiasts from Europe and further beyond. It is billed by the Guinness World Records as the world’s largest LAN party. In Sweden DreamHack has broken into the top 12 sporting events nationally. Players are looking to compete in the popular World of Warcraft championships, QuakeWorld and Counter-Strike tournaments.
A long time back it was Greece, and in this century Sweden. Is this the beginning of the new e-Olympics?
Posted by Kelly Ahuja at 07:59 AM Permalink | Comments (1) | TrackBacks (0)
November 13, 2007
Quo Vadis: MPLS?
The MPLS 2007 Conference, took place in Washington D.C. from October 28-31, and was advertised as:
“The year 2007 marks the 10th anniversary of MPLS International Conference and over the past 10 years, the conference has helped industry grow and have been the venue of the launch of new technologies that are driving the Internet towards next generation “
Approximately 500 participants internationally attended the conference mainly comprising the service provider and vendor community. Bruce Davie, Cisco, and Yakov Rekhter, Juniper highlighted the service modularity and extensibility that MPLS possesses in spite of approximately 10+ years of existence. Davie went on to discuss challenges to MPLS such as “different packet header” and forwarding paradigm; network management; asserted to, that challenging MPLS with no control plane and great network management seems like it begs the question of standards-based networking. Davie concluded that MPLS and IP remain entrenched because they enable valuable services such as L3VPN for MPLS; and that the rise of Ethernet is unlikely to change the fact that that the world depends on IP.
Yakov Rekhter highlighted differences between MPLS and Provider Backbone Transport or PBT and concluded with the following assertion:
“PBT is a new technology that promises to offer some of the same benefits that MPLS has been providing for years.
It is unclear if and when PBT will reach the level of maturity and sophistication comparable to what MPLS has today with respect to the features that are needed for packet-based transport point-to-point, point-to-multipoint, and multipoint-to-point connectivity, protection, traffic engineering, QoS (including deterministic quality of service and OAM.PBT in the transport layer still requires MPLS in the service layer and as a service layer technology, PBT is limited to just Ethernet.”
By the way, the arguments in these transport discussions are not skewed to Ethernet vs MPLS --- in fact both technologies have co-existed for years. If a purported technology offers somewhat identical benefits as one that is rather mature, does this premise constitute a leapfrog and/or, disruptive paradigm?
The service providers who presented at the conference like Telecom Italia, Verizon, FT-Orange, Sprint, NTT, KDDI acknowledged the adoption of MPLS as pivotal to their service architectures; and certainly did not articulate a desire to move to so called “PBT.”
Ok, you may ask, well “what did one expect at an MPLS Conference?” The vendor panel discussion was rather circular with 9 or so vendors each stating their obvious positions --- yawn, yawn – there were no fireworks here!
The more interesting opportunity in the industry is to move at the service and application level. Looking at the bigger picture in terms of trends and impact to architecture, massive quantities of data will be generated on small scales (RFIDs, sensors or so called pervasive computing etc); further, there is an explosion of new creators
or consumers of content, so called “prosumers” like perhaps some of us. Oh, yes, the promise of Web 2.0 is supposed to drive greater consumer choice, participation and control – social networking indeed.
You may wonder why the 2007 Time Magazine “Person of the Year” award was YOU!
Uhmm, MPLS vs PBT vs whatever – is there something wrong with this picture? With all of these dynamics, have we thought about the impact to the overall network? The Internet?
Ah, stay tuned!
Posted by Monique Morrow at 07:00 AM Permalink | Comments (1) | TrackBacks (0)
October 15, 2007
The Ultimate Transport
The unprecedented growth of IP based networks over the last decade or so has blurred the traditional distinctions often made between switching and transmission systems in SP networks. Many in today’s IP dominated businesses scarcely acknowledge there is a difference, and maybe what differences there are will eventually disappear, relegated to history’s dustbin.
Still, it would be foolhardy to design networks assuming that these two basic aspects of networking did not answer to quite different requirements, since they fulfill entirely different functions in SP networks. If so, does it make sense that one type of packet technology, e.g. IP/MPLS, can be pressed into service for both switching and transmission systems?
Conventional wisdom suggests this should be quite feasible. After all, a packet is a packet, so what if you switch it in routers located in San Jose, or transmit it from San Francisco to Boston over an optical fiber transmission system! But the reality is that transmission systems have traditionally dealt with a whole different problem set than switching/routing equipment need to deal with.
Many of these issues stem from the need to effectively manage long haul networks remotely using centralized OSS. And there is always the challenge of ensuring extremely high availability and survivability in the face of inevitable human and natural disasters to widely scattered outside plant. Conventional transport systems, such as those based on the ubiquitous SDH (or even ATM) technologies, have evolved complex network management and OAM mechanisms to handle these challenges.
As network operators evolve their transport systems from conventional SDH based equipment to packet based (IP/MPLS or Ethernet) transport in their drive for OPEX and CAPEX savings, these challenges remain. The question arises as to how these packet technologies, originally conceived for primarily switching/routing operations, should be adapted for long haul transport operations.
It seems how one does this depends on who you talk to! Many approaches are being pursued in the burgeoning market for packet based transport. But the nagging doubt remains as to whether these approaches, often adorned with hopeful acronyms like T-MPLS, PBT, PBB-TE and the like, really meet the stringent demands of carrier class packet transport technology? They seem like work-arounds, rather than solutions!
It has been tried before, and not so long ago. After all, ATM was designed as both a switching and a transmission system technology, with capabilities built-in to satisfy the demands of both worlds. It could even be conjectured that ATM’s brave attempt to be all things to all men resulted in an over-complex technology that had to make so many compromises that it satisfied no-one in the end!
Could such a fate befall other packet technologies that tried to satisfy both the diverse transmission and routing worlds? Yes, it’s possible, if we don’t learn from the lessons of history. But if we architect packet transport intelligently, bearing in mind the differing demands of transport and switching, there is no reason why it would not be possible to come up with the ultimate transport technology.
That’s a challenge I for one am willing to sign up to.
Posted by Rajiv Kapoor at 02:10 PM Permalink | Comments (0) | TrackBacks (0)
October 04, 2007
IP over DWDM (IPoDWDM)
Service Providers continue to look for the best economics for increasing network capacity to accommodate the continued growth in IP traffic driven by data, voice and primarily video traffic. The advantages of integration have already been witnessed at the transport layers through the integration of SONET/SDH and DWDM. This integration was realized in the form of native DWDM interfaces on SONET/SDH Add Drop Multiplexers (ADMs), cross connects and common management systems.
Why IPoDWDM?
The reason for integrating IP and DWDM are simply to deliver a significant reduction in capital expenditures and improve the operational efficiency of the network. The premise of IPoDWDM is to reduce the electrical transport layer as much as possible as this provides the highest bit-rate robustness, future protocol robustness and functional robustness. For example, moving an underlying SONET/SDH infrastructure from 10G to 40G requires significant redesign but using some novel modulation formats, accommodating 40G over existing 10G transmission infrastructure is possible. Additionally, modifying an electrical cross-connect from 10G SONET/SDH to Ethernet is not a simple task. Lastly, integration of the IP and DWDM layers can improve the overall reliability of the network by creating visibility of the optical layer into the IP layer enabling faster protection at Layer 3 instead of leaving un-used bandwidth in the network for protection as with SONET/SDH.
What makes this possible?
Given several advancements, the time has come for a level of integration between IP and DWDM elements to enable service providers to deploy cost effective, scalable networks. These include, but are not limited to:
- Development of terabit capacity routers capable of supporting tens of gigabits per second interfaces on a single line card
- Integration and form factor reduction of transponder technologies
- G.709 or Digital Wrapper function for providing a framing function for monitoring, error correction etc.
- Fast Re-Route (FRR) technology for MPLS and IP
Integrating IP and DWDM requires a much broader approach that must include:
- Element Integration: integration of DWDM interfaces in core routers as well as integration of photonic switching into the DWDM layer, allowing bypassing of transit points optically when there's no need of layer 3 processing
- Management Integration: integration of management functions from both the IP and DWDM layer into a single streamlined solution - still allowing different users to have views based on the role
- Control Integration: integrating control plane functions building on existing standards approach and extending them to the DWDM layer
Cisco believes this technology is going to be all the more necessary as the customers need for more and more bandwidth continues its dramatic rise. As a result, we'll continue to push innovative approaches of integrating IP and DWDM layers closer together introducing solutions that enable providers to scale their core networks at the best possible economics while providing efficient operations.
Posted by Kelly Ahuja at 08:12 AM Permalink | Comments (0) | TrackBacks (1)
September 13, 2007
IPNGN in a Cube
The IPNGN vision provides the SP community an architectural framework within which to rationalize networking solutions. The great thing about the IPNGN framework is its simplicity, neatly summarizing in a logically layered 3 dimensioned model all the functionality required for supporting NGN services.
But this apparent simplicity hides the intricate complexity of all the interfaces and protocols that need to be implemented to enable any specific IPNGN service. An inkling of this complexity can be gleaned from the NGN Protocol Reference Model (PRM), shown below. This is a “Rubik’s Cube” of Layers and Planes and, most importantly, the complex interplay between them. In effect, the PRM encapsulates ALL the essence of the IPNGN - in a cube!
Each Plane- Transport, Management, Control - is a world in itself, but relies on the others to be effective. The separations may be more virtual than real, but they help us understand the whole as more than the sum of its parts. Revenue generating services are created from the interplay of control and management messages, knitted together by applications embedded on either side of the user-to-network interfaces.
The IP suite of protocols forms the “common element” in the NGN PRM framework. The use of IP as the common packet transfer mode dictates how the desirable NGN attributes, such as QoS, Security, Survivability, etc., are implemented.
So how does this cubic NGN PRM abstraction help us build better networks, and by implication, more profitable services? Consider security for example. Every operator wants security as an essential element of their network. The IPNGN cube shows us that in order to deliver security in all its facets, we have to consider the security aspects in all the Layers and Planes of the IPNGN. The question is, if we disregard any one of these aspects, do we end up with a potential “Achilles heel”?
The same is true for the elusive notion of QoS, much talked about and desired, but hard to achieve in practical terms. In its broadest sense, QoS capabilities rely on functions that are spread over many Layers and Planes of the NGN PRM cube. A bottleneck in one Layer could lead to impairments elsewhere. The cube encourages us to take into account the complex inter-dependencies. Whoever said ubiquitous QoS was going to be easy!
As transport plane capabilities become increasingly commoditized, the IPNGN cube raises the question as to how we can more effectively leverage control and management plane capabilities to generate profitable services?
And what of the need to interwork with existing services and networks? How are the legacy services to be accommodated in this IPNGN vision?
The IPNGN vision provides a very useful tool to conceptualize networking solutions. The IPNGN cube helps get to a deeper understanding, another conceptual tool that illustrates inter-dependencies between the protocols we must rely on, and helps us build better networks.
Rajiv Kapoor
Director, Standards & Architectures Marketing
Cisco Systems, Inc.
Posted by Rajiv Kapoor at 12:28 PM Permalink | Comments (3) | TrackBacks (0)
