According to an article written by Robert Braden, David Clark, Scott Shenker, and John Wroclawski, the architectural design of today’s Internet technology was based from an Internet architecture that was developed in the 1970s, under the Internet research program of the Defense Advanced Research Projects Agency (DARPA) of the US Department of Defense.
Computer scientist all over the world believe that it is now time to revisit the Internet architecture, to determine whether it can be changed to align better with current and future requirements. Many of the new requirements, present and future, are beginning to be apparent. Researchers predict that a combination of abstract reasoning and practical experimentation can bring a new clarity to the architectural architectural issues of the Internet.
For instance, a new layout for next generation of internet architecture might be designed to create greater functionality, generality, adaptability, and/or robustness in the future Internet. On the other hand, without a new long-term technical road map the Internet is likely to become decreasingly effective, often failing to meet the demands placed on it by applications.
The goal of a new-arch research program should be to define and prototype a future architecture towards which the Internet technology can evolve. A new-arch research program would differ from most other network research in the breadth of its viewpoint and in its relatively long time scale. Many Internet R&D projects are building upon the original Internet architecture, but few are looking at the basic architecture and requirements for a future Internet. The next generation of internet architecture normally defines the problem space, exploring the meaning of “network architecture” and the gap between the original Internet architecture and current reality. It also discussing the issues to be considered in the development of a new architecture, initial thoughts about the changing requirements and the design of a new architecture, respectively.
A new network architecture must typically specify:
1. Where and how state is maintained and how it is removed.
2. What entities are named
3. How naming, addressing, and routing functions inter-relate and how they are performed.
4. How communication functions are modularized, e.g., into “layers” to form a “protocol stack”.
5. How network resources are divided between flows and how end-systems react to this division, i.e., fairness and congestion control.
6. Where security boundaries are drawn and how they are enforced.
7. How management boundaries are drawn and selectively pierced. 8. How differing QoS is requested and achieved
.
Source: ERM Blog
