Transcript Arquitetura da Internet atual

Arquitetura da Internet atual
Michael Stanton
22/8/2011
Fontes
• V. Cerf, and R. Kahn, "A Protocol for Packet Network
Intercommunication", IEEE Transactions on
Communications, Vol. 22, No. 5, May 1974, pp. 637-648.
• Saltzer, Reed e Clark, “End-To-End Arguments In System
Design”, ACM Transactions in Computer Systems 2, 4,
November, 1984, pages 277-288.
• Clark, “The Design Philosophy of the DARPA Internet
Protocols”, Proc. SIGCOMM ‘88, Computer Communication
Review Vol. 18, No. 4, August 1988, pp. 106–114.
• Carpenter, “Architectural Principles of the Internet”, RFC
1958, June 1996.
• Floyd, “General Architectural and Policy Considerations”,
RFC 3426, November 2002.
Cern e Kahn, 1974
• A Protocol for Packet Network Intercommunication
• Define uma interrede
– redes, interconectadas por gateways
– um protocolo de interredes, chamado TCP, que inclui as
funções de transporte confiável fim a fim entre sistemas
• Abstract — A protocol that supports the sharing of resources that
exist in different packet switching networks is presented. The
protocol provides for variation in individual network packet sizes,
transmission failures, sequencing, flow control, end-to-end error
checking, and the creation and destruction of logical process-toprocess connections. Some implementation issues are considered,
and problems such as internetwork routing, accounting, and
timeouts are exposed.
Saltzer, Reed e Clark, 1984
• End to End Arguments in System Design
• Justificativa por separação de IP e TCP – adotada em
1978 (entre outros assuntos)
• Abstract: This paper presents a design principle that helps guide
placement of functions among the modules of a distributed
computer system. The principle, called the end-to-end argument,
suggests that functions placed at low levels of a system may be
redundant or of little value when compared with the cost of
providing them at that low level. Examples discussed in the paper
include bit error recovery, security using encryption, duplicate
message suppression, recovery from system crashes, and delivery
acknowledgement. Low level mechanisms to support these
functions are justified only as performance enhancements.
Clark, 1988
• The Design Philosophy of the DARPA Internet Protocols
• Primeira formulação pública de uma arquitetura
• Abstract. The Internet protocol suite, TCP/IP, was first
proposed fifteen years ago. It was developed by the Defense
Advanced Research Projects Agency (DARPA), and has been
used widely in military and commercial systems. While there
have been papers and specifications that describe how the
protocols work, it is sometimes difficult to deduce from these
why the protocol is as it is. For example, the Internet protocol
is based on a connectionless or datagram mode of service.
The motivation for this has been greatly misunderstood. This
paper attempts to capture some of the early reasoning which
shaped the Internet protocols.
Carpenter, 1996
• RFC1958: Architectural Principles of the Internet
• Abstract: The Internet and its architecture have grown
in evolutionary fashion from modest beginnings, rather
than from a Grand Plan. While this process of evolution
is one of the main reasons for the technology’s success,
it nevertheless seems useful to record a snapshot of
the current principles of the Internet architecture. This
is intended for general guidance and general interest,
and is in no way intended to be a formal or invariant
reference model.
Carpenter 1996: mudança constante
1/2
• In searching for Internet architectural principles, we must
remember that technical change is continuous in the
information technology industry. The Internet reflects this.
• Over the 25 years since the ARPANET started, various
measures of the size of the Internet have increased by
factors between 1000 (backbone speed) and 1000000
(number of hosts).
• In this environment, some architectural principles
inevitably change. Principles that seemed inviolable a few
years ago are deprecated today. Principles that seem
sacred today will be deprecated tomorrow. The principle of
constant change is perhaps the only principle of the
Internet that should survive indefinitely.
Carpenter 1996: mudança constante
2/2
• The purpose of this document is not, therefore, to lay down
dogma about how Internet protocols should be designed,
or even about how they should fit together. Rather, it is to
convey various guidelines that have been found useful in
the past, and that may be useful to those designing new
protocols or evaluating such designs.
• Some current technical triggers for change include the
limits to the scaling of IPv4, the fact that gigabit/second
networks and multimedia present fundamentally new
challenges, and the need for quality of service and security
guarantees in the commercial Internet.
Carpenter 1996: assuntos tratados
•
•
•
•
•
Is there an Internet Architecture?
General Design Issues
Name and address issues
External Issues
Related to Confidentiality and Authentication
Carpenter 1996: existe uma
arquitetura da Internet?
• the [Internet] community believes that the goal is connectivity, the
tool is the Internet Protocol, and the intelligence is end to end
rather than hidden in the network.
• The key to global connectivity is the inter-networking layer. The key
to exploiting this layer over diverse hardware providing global
connectivity is the "end to end argument".
• It is generally felt that in an ideal situation there should be one, and
only one, protocol at the Internet level.
• It is also generally felt that end-to-end functions can best be
realised by end-to-end protocols.
• Nobody owns the Internet, there is no centralized control, and
nobody can turn it off. Its evolution depends on rough consensus
about technical proposals, and on running code. Engineering feedback from real implementations is more important than any
architectural principles.
Carpenter 1996: princípios gerais do
desenho 1/2
1.
2.
3.
4.
5.
6.
7.
8.
Heterogeneity is inevitable and must be supported by design.
If there are several ways of doing the same thing, choose one.
All designs must scale readily to very many nodes per site and to
many millions of sites.
Performance and cost must be considered as well as functionality.
Keep it simple. When in doubt during design, choose the simplest
solution.
Modularity is good. If you can keep things separate, do so.
In many cases it is better to adopt an almost complete solution
now, rather than to wait until a perfect solution can be found.
Avoid options and parameters whenever possible. Any options
and parameters should be configured or negotiated dynamically
rather than manually.
Carpenter 1996: princípios gerais do
desenho 2/2
9. Be strict when sending and tolerant when receiving.
10. Be parsimonious with unsolicited packets, especially
multicasts and broadcasts.
11. Circular dependencies must be avoided.
12. Objects should be self decribing (include type and size),
within reasonable limits. Only type codes and other magic
numbers assigned by the Internet Assigned Numbers
Authority (IANA) may be used.
13. All specifications should use the same terminology and
notation, and the same bit- and byte-order convention.
14. And perhaps most important: Nothing gets standardised
until there are multiple instances of running code.
Carpenter 1996: nomes e endereços
1.
2.
3.
4.
5.
Avoid any design that requires addresses to be hard coded or
stored on non-volatile storage (except of course where this is an
essential requirement as in a name server or configuration
server). In general, user applications should use names rather
than addresses.
A single naming structure should be used.
Public (i.e. widely visible) names should be in case-independent
ASCII. Specifically, this refers to DNS names, and to protocol
elements that are transmitted in text format.
Addresses must be unambiguous (unique within any scope where
they may appear).
Upper layer protocols must be able to identify end-points
unambiguously. In practice today, this means that addresses must
be the same at start and finish of transmission.
Carpenter 1996: assuntos externos
1.
2.
3.
4.
Prefer unpatented technology, but if the best technology is patented and
is available to all at reasonable terms, then incorporation of patented
technology is acceptable.
The existence of export controls on some aspects of Internet technology
is only of secondary importance in choosing which technology to adopt
into the standards. All of the technology required to implement Internet
standards can be fabricated in each country, so world wide deployment
of Internet technology does not depend on its exportability from any
particular country or countries.
Any implementation which does not include all of the required
components cannot claim conformance with the standard.
Designs should be fully international, with support for localisation
(adaptation to local character sets). In particular, there should be a
uniform approach to character set tagging for information content.
Carpenter 1996: confidencialidade e
autenticação
1.
2.
3.
4.
5.
All designs must fit into the IP security architecture.
It is highly desirable that Internet carriers protect the privacy and authenticity of
all traffic, but this is not a requirement of the architecture. Confidentiality and
authentication are the responsibility of end users and must be implemented in
the protocols used by the end users.
Wherever a cryptographic algorithm is called for in a protocol, the protocol
should be designed to permit alternative algorithms to be used and the specific
algorithm employed in a particular implementation should be explicitly labeled.
Official labels for algorithms are to be recorded by the IANA.
In choosing algorithms, the algorithm should be one which is widely regarded as
strong enough to serve the purpose. Among alternatives all of which are strong
enough, preference should be given to algorithms which have stood the test of
time and which are not unnecessarily inefficient.
To ensure interoperation between endpoints making use of security services,
one algorithm (or suite of algorithms) should be mandated to ensure the ability
to negotiate a secure context between implementations. Without this,
implementations might otherwise not have an algorithm in common and not be
able to communicate securely.
Floyd, 2002
• RFC 3426: General Architectural and Policy
Considerations
• Abstract: This document suggests general
architectural and policy questions that the IETF
community has to address when working on new
standards and protocols. We note that this
document contains questions to be addressed, as
opposed to guidelines or architectural principles
to be followed.
Floyd 2002: motivação
• This document is motivated in part by concerns about a growing
lack of coherence in the overall Internet architecture. We have
moved from a world of a single, coherent architecture designed by
a small group of people, to a world of complex, intricate
architecture to address a wide-spread and heterogeneous
environment.
• Because individual pieces of the architecture are often designed by
sub-communities, with each sub-community having its own set of
interests, it is necessary to pay increasing attention to how each
piece fits into the larger picture, and to consider how each piece is
chosen.
• For example, it is unavoidable that each of us is inclined to solve a
problem at the layer of the protocol stack and using the tools that
we understand the best; that does not necessarily mean that this is
the most appropriate layer or set of tools for solving this problem in
the long-term.
Floyd 2002: objetivo
• In contrast [to Carpenter, 1996] , this document serves a
slightly different purpose, by suggesting additional
architectural questions to be addressed.
• Thus, one question suggested in this document is the
following: "Is this proposal the best long-term solution to
the problem? If not, what are the long-term costs of this
solution, in terms of restrictions on future development, if
any?"
• This question could be translated to a roughly equivalent
architectural guideline, as follows: "Identify whether the
proposed protocol is a long-term solution or a short-term
solution, and identify the long-term costs and the exit
strategy for any short-term solutions.”
Floyd 2002: questões sobre desenho
•
Justifying the Solution:
– Why are you proposing this solution, instead of proposing something else, or instead of using
existing protocols and procedures?
•
Interactions between Layers:
– Why are you proposing a solution at this layer of the protocol stack, rather than at another
layer? Are there solutions at other layers of the protocol stack as well?
– Is this an appropriate layer in terms of correctness of function, data integrity, performance,
ease of deployment, the diagnosability of failures, and other concerns?
– What are the interactions between layers, if any?
•
Long-term vs. Short-term Solutions:
– Is this proposal the best long-term solution to the problem?
– If not, what are the long-term costs of this solution, in terms of restrictions on future
development, if any? What are the requirements for the development of longer-term
solutions?
•
The Whole Picture vs. Building Blocks:
– Have you considered the larger context, while appropriately restricting your own design
efforts to one part of the whole?
– Are there parts of the overall solution that will have to be provided by other IETF Working
Groups or by other standards bodies?
Floyd 2002: questões sobre avaliação
1/2
• Weighing Benefits against Costs:
– How do the architectural benefits of a proposed new protocol compare
against the architectural costs, if any? Have the architectural costs been
carefully considered?
• Robustness:
– How robust is the protocol, not just to the failure of nodes, but also to
compromised or malfunctioning components, imperfect or defective
implementations, etc?
– Does the protocol take into account the realistic conditions of the current or
future Internet (e.g., packet drops and packet corruption; packet reordering;
asymmetric routing; etc.)?
• Tragedy of the Commons:
– Is performance still robust if everyone is using this protocol? Are there other
potential impacts of widespread deployment that need to be considered?
• Protecting Competing Interests:
– Does the protocol protect the interests of competing parties (e.g., not only
end-users, but also ISPs, router vendors, software vendors, or other parties)?
Floyd 2002: questões sobre avaliação
2/2
• Designing for Choice vs. Avoiding Unnecessary Complexity:
– Is the protocol designed for choice, to allow different players to express their
preferences where appropriate? At the other extreme, does the protocol
provide so many choices that it threatens interoperability or introduces other
significant problems?
• Preserving Evolvability?
– Does the protocol protect the interests of the future, by preserving the
evolvability of the Internet? Does the protocol enable future developments?
– If an old protocol is overloaded with new functionality, or reused for new
purposes, have the possible complexities introduced been taken carefully into
account?
– For a protocol that introduces new complexity to the Internet architecture,
how does the protocol add robustness and preserve evolvability, and how
does it also introduce new fragilities to the system?
• Internationalization:
– Where protocols require elements in text format, have the possibly conflicting
requirements of global comprehensibility and the ability to represent local
text content been properly weighed against each other?
Floyd 2002: questão sobre
implantação
• Is the protocol deployable?
Floyd 2002: conclusão
•
•
•
•
This document suggests general architectural and policy questions to be addressed
when working on new protocols and standards in the IETF.
The case studies in this document have generally been short illustrations of how
the questions proposed in the document have been addressed in working groups
in the past. However, we have generally steered away from case studies of more
controversial issues, where there is not yet a consensus in the IETF community.
Thus, we side-stepped suggestions for adding a case study for IKE (Internet Key
Exchange) as an possible example of a protocol with too much negotiation, or of
adding a case study of network management protocols as illustrating the possible
costs of leaving things to the marketplace to decide.
We would encourage others to contribute case studies of these or any other issues
that may shed light on some of the questions in this document; any such case
studies could include a careful presentation of the architectural reasoning on both
sides.
We would conjecture that there is a lot to be learned, in terms of the range of
answers to the questions posed in this document, by studying the successes,
failures, and other struggles of the past.