The Uptime Institute (UI) is an IT industry research firm best known for certifying that data centers meet industry standards. UI issues an annual report that analyzes the cause of data center outages. The causes for data center outages are relevant to the broadband industry because the same kinds of issues shut down switching hubs and Network Operations Centers.
Interested in learning more about routing security? How it can affect your connectivity supply chain? What are best practices for enterprises and organizations? What is the role of CSIRTs in securing routing? What are governments doing now, and planning to do in the future around routing security?
ome 50 years ago, at the Palo Alto Research Centre of that renowned photocopier company Xerox, a revolutionary approach to local digital networks was born. On the 22nd of May 1973, Bob Metcalf authored a memo that described "X-Wire," a 3Mbps common bus office network system developed at Xerox's Palo Alto Research Center (PARC).
Project Liberty's Institute sat down with Dave Clark, an early contributor to the TCP/IP protocols that built and run the Internet, and one of the expert advisors on DSNP, the Decentralized Social Networking Protocol. Dave Clark is Senior Research Scientist at MIT's Computer Science and Artificial Intelligence Laboratory (CSAIL) and Fellow of the National Academy of Engineering and the American Academy of Arts and Sciences.
The idea for Ethernet was born fifty years ago in May 1973 when Robert Metcalf coined the word Ethernet. He had been studying ALOHAnet, developed at the University of Hawaii in 1971 and was the first public demonstration of a wireless packet data network. Metcalf used the work Ethernet as a reference to luminiferous aether, a concept postulated in the 17th century to explain how light could be transmitted through a vacuum.
At Verisign, we believe that continuous improvements to the safety and security of the global routing system are critical for the reliability of the internet. As such, we've recently embarked on a path to implement Resource Public Key Infrastructure (RPKI) within our technology ecosystem as a step toward building a more secure routing system. In this blog, we share our ongoing journey toward RPKI adoption and the lessons we've learned as an operator of critical internet infrastructure.
Change is hard, and the larger the system, the slower the pace of change. There are just so many systems that need to change their behaviors, and the motivations of users, vendors, service providers, content generators and many others all vary. Getting all of us to change some aspect of our technology, platform or application set is hard, if not impossible, to orchestrate such that it happens at the same time.
A little appreciated aspect of our digital infrastructure is just how dependent we are on access to time. Disrupting the time base can not only lead to disruption in communications but can result in various forms of compromise of the integrity of communications. Accurate time was all but unobtainable for centuries, and then, as we spent significant sums devising even more accurate timekeeping instruments, accurate time became a specialized service.
Rudolph van der Berg presented on the latest updates from the ongoing tensions in the Internet industry between carriage infrastructure providers and content providers, with a European perspective. The carriage providers in the EU region are asserting that they're making major capital investments in augmenting the access network infrastructure to carry gigabit traffic volumes, which is largely streaming content, while at the same time the content providers were getting a free ride, or so goes the argument.
In a recent workshop, I attended, reflecting on the evolution of the Internet over the past 40 years, one of the takeaways for me is how we've managed to surprise ourselves in both the unanticipated successes we've encountered and in the instances of failure when technology has stubbornly resisted to be deployed despite our confident expectations to the contrary! What have we learned from these lessons about our inability to predict technology outcomes?