What is Network
architecture?
It is important to understand what the term “architecture”
term means. The notion
of network architecture was introduced during the
Internet research phase by
the research community that had developed the
ARPAnet protocols. This community
brought to bear on the computer communication
problem the kind of abstract
thinking about resources and relationships that came
naturally to computer scientists
who had designed hardware architectures and/or
computer software systems.
This resulted in the development of an overarching “design
philosophy” to accompany
the design of the algorithms and protocols for the
Internet (see for example
[CerfKahn74, CerfKirs78, E2Earg81]). This philosophy
was elaborated over time
to create the complete original architecture of the
Internet protocol suite [Clark88].
Network architecture is a set of high-level design
principles that guides the technical
design of the network, especially the engineering of
its protocols and algorithms.
To flesh out this simple definition, we have
examples of the constituents
of the architecture and how it is applied. A network
architecture must typically
specify:
_ Where and how state is maintained
and how it is removed.
_ What entities are named
_ How naming, addressing, and
routing functions inter-relate and how they are
performed.
_ How communication functions are
modularized, e.g., into “layers” to form a
“protocol stack”.
_ How network resources are divided
between flows and how end-systems react
to this division, i.e., fairness and congestion
control.
_ Where security boundaries are
drawn and how they are enforced.
_ How management boundaries are
drawn and selectively pierced.
_ How differing QoS is requested
and achieved.
Ideally one would would like to imagine using the
architecture to “generate” the
technical design, but making such a mapping in a
mechanical fashion is clearly
impossible. The architecture can only provide a set
of abstract principles against
which we can check each decision about the technical
design. The role of the
architecture is to ensure that the resulting
technical design will be consistent and
coherent – the pieces will fit together smoothly –
and that the design will satisfy
the requirements on network function associated with
the architecture.
An architecture is more general than a particular
conformant technical design. The
technical design derived from a particular
architecture is far from unique, and it
may evolve over time in response to detailed changes
in requirements; however,
the same architecture may be maintained. Crucially,
an architecture is expected to
be relatively long-lived, applicable to more than
one generation of the technology.
A trivial example of this is IPv6, which represents
a later generation of technology
than IPv4 although both conform to the same Internet
architecture.
An example of architectural thinking (which was,
however, a speculative alternative
to aspects of the current Internet architecture) was
contained in the Application
Level Framing (ALF) proposal of Clark and
Tennenhouse [ALF90]. ALF was not
a complete architecture, only an architectural
component with specific goals: lower
cost and more flexible implementation, more
efficient operation over diverse infrastructure
(packet and ATM), and effective support for a wider
range of application
requirements, and so on. ALF illustrates the
practical short-term benefit of longterm
architectural thinking. While the ALF idea as
proposed was not cast as in
incremental modification to the Internet but rather
as a new and different approach,
other researchers used the ALF idea as the basis for
the implementation of new
applications over the existing network.
Example: the
Internet Architecture
To further clarify the meaning of “architecture”, we
can consider the Internet architecture.
The important features of the original Internet
architecture [BCarp96]
included:
_ A connectionless packet-forwarding
infrastructure (“dumb network”) that
positioned higher-level functionality at the edge of
the network for robustness
(“fate-sharing”)
4
_ A single least-common-denominator
data delivery service at the internetwork
layer, with different end-to-end services
implemented in the transport
(or application) layer above. This design supports
both reliable stream
and (unreliable) datagram service across the same
connectionless infrastructure.
_ Addresses that are fixed-size numerical
quantities, with a simple (net, host)
hierarchy
_ Addresses that are applied to
physical network interfaces, which can therefore
be overloaded for both naming a node and for routing
to it.
This Internet architecture evolved during the
research phase, and it has continued
to evolve.
_ The most important change during
the 1974 - 1980 research period was
the separation of TCP into an inter-network (IP)
layer and a transport layer
(TCP), in version 4 of the protocols.
_ Several important features were
added to the architecture during the early
1980s, especially subnetting, autonomous systems,
and the domain name
system (DNS). All of these changes reflecting an
increasing understanding
and respect for the issues of scale, imposed
hierarchical design on the architecture.
Subnetting was the first step towards making
addresses hierarchical,
and this was extended later with the addition of
classless addressing
(CIDR). Autonomous systems made the organization of
routing hierarchical,
by distinguishing EGPs from IGPs. Finally, the DNS
introduced hierarchical
naming.
_ Later, IP multicasting added
logical addressing and multi-destination delivery
fundamental parts of the architecture.
_ Congestion control using packet
loss as a congestion signal and an additive
increase/multiplicative decrease algorithm at the
end-systems was added in
the late 1980s in response to congestion collapse
events.
Why is
Architecture Important?
Architecture sets a sense of direction. It provides
a basis for individual technical
decisions, as opposed to a random walk starting from
today’s design. An architec-
ture represents not just an abstract goal, but a
bias that is applied to every decision
made day-to-day. While architecture is long-term, it
will often invariably have
short-term implications. In general, long- range
research usually has short-term
spinoffs, but short-range research with no long view
of where it is going cannot
have a long-term impact.
Because design done in the presence of architectural
guidelines tends to produce
more general solutions, it can result in “platform”
solutions – service layers that
are able to support a range of applications. This
generality has the potential to
reduce overall the level of investment, since
investment in a platform solution can
be reused. However, architecture has to be sustained
and grown. Left to itself,
it erodes and atrophies. “Platform” solutions tend
over time to be supplanted by
“overlays” that supplant the nominal interface for
emerging classes of applications.
This point is clear to commercial entities that
support interfaces that they view as
“platform” solutions. The Microsoft Windows API is a
good example of a “platform”
interface that tries to support a range of
applications over a common interface.
Microsoft commits a lot of resources to sustaining
their interface, to attempt
to get new applications to run over it directly, as
opposed to running over some
application-specific overlay. The Internet, if it is
to survive as a platform, has to
make the same kind of investment; for the Internet,
this investment is in design of
the architecture.
The Internet architecture is of particular
importance to the military. In order that
the DoD be able to use COTS technology for military
needs, there must be a degree
of generality in the devices, so that the
differences between military and commercial
objectives can be accommodated. To the extent that
an overall architecture
facilitates more general solutions, it directly
enhances the COTS procurement objective.
Architecture guides technical development such as
protocol design in a consistent
direction; without adequate architectural
principles, designers with short-term
goals often implement point solutions. In general,
an increasing collection of point
solutions leads over time leads to a design that is
complex, tangled, and inflexible.
The Internet is exhibiting this technical
arteriosclerosis today. Extensions to the
technical design of the Internet have been developed
are being developed in the
IETF at increasing rate. Examples include integrated
service (IntServ) and differentiated
service (DiffServ), IP Security (IPSEC), firewalls,
mobile IP, Network
Address Translator (NAT) devices, label switching,
VPNs, andWeb caches. We believe
that certain of these extensions were created with
some architectural sensitiv-
ity; IntServ [IntServ94], and DiffServ
[DiffServ98XX], and IPSEC [IPSEC98XX]
are examples. However, many of the recent extensions
have been developed as
point solutions for specific requirements of
particular subsets of the Internet community
– vendors, users, or ISPs – and largely in the
absence of architectural thinking.
They do not represent enhancements of the architecture,
even though they
were developed to meet legitimate short-term needs
and requirements. Viewed as
a whole, this situation demonstrates two types of
negative effects: those that arise
when technical development does not follow an
architectural framework, and those
that arise when an architecture becomes “tired” and
requires rethinking in response
to new requirements..
We can pick some illustrative examples from this
list of extra-architectural extensions.
_ IPSEC
IP Security (IPSEC) seems to be fully consistent
with the original architectural
model with respect to information hiding: it
encrypts the transport-layer
(UDP or TCP) headers that, which contain only
end-to-end information, in
principle of concern only to end hosts. However,
network providers are very
unhappy about losing the ability to “snoop” at port
numbers and higher-layer
protocol headers. This suggests that the original
layering model was not in
fact the right one, or at least it is no longer
fully adequate for today’s requirements.
Nobody owns the job of revisiting the general
principle here,
to provide a clean solution combining end-to-end
security with the management
information needed by the providers.
_ NAT Devices
An architectural principle of the Internet was that
addresses in packets are
carried unchanged from source to destination. This
principle is directly violated
by the Network Address Translation (NAT) devices
that have become
popular. These devices were conceived to deal with
exhaustion of the IP
address space (an issue never considered in the
original design), as a means
to reduce the effort of address reassignment, and as
a possible security enhancement.
However, NAT devices have significant high-level
implications. Among the
strongest of these is to move the Internet fundamentally
away from a peer-topeer
model (in which any host is theoretically
addressable) towards a clientserver
model (in which only “selected” hosts are
addressable from the global
network). This change appears relatively innocuous
with today’s emphasis
on web applications, but has tremendous impact on
the Internet’s ability to
support future applications and devices. This is an
example of an “effective”
solution to a point problem greatly restricting
generality and future usability.
The example also demonstrates the difficulty of
adapting an architecture “on
the fly” to new circumstances. There is no accepted
resolution of the architectural
implications of NAT devices. At the same time that
purists who
defend the “old architecture” decry these devices as
tasteless and destructive,
advocates call them the wave of the future. Even
after an ad hoc committee
tried to catalog all the implications of address
rewriting, there was still no
community consensus about the correct set of design
principles.
_ Firewalls
Security firewalls have been introduced into the
Internet design to protect
regions of the network from outside attack.
Firewalls violate the original
architecture, and firewall design occurs in an
undefined space of ad hoc evolution.
There has been no overall agreement on the
assumptions an end-node
can or must make about what a firewall may do – what
sorts of actions are
acceptable. As a result, firewalls often result in a
loss of end-to-end (i.e.,
user to server) functionality.
More important from the network perspective,
firewalls and similar nonarchitectural
changes often lead to unfortunate unintended
consequences in
precisely the functional areas they are attempting
to address. A recent example
arose when certain host vendors, acting in response to
sites deploying
overly aggressive firewalls that broke the standard
TCP “MTU Discovery”
protocol, developed and deployed a new version of
MTU discovery that unwittingly
enabled a serious network wide denial of service
attack.
_ Label Switching
Label switching represents an attempt to extend the
architectural thinking to
some extent, by asking what sort of layer two
technology is actually needed
to support the IP interface. But we should ask
whether, given MPLS and
IPSEC, the function of the IP layer needs
rethinking.
In addition to their direct consequences, these
recent extensions have problems
with “feature interactions”. They have complex
interactions with each other and
with the rest of the architecture, leading to
increasingly complex and baroque protocol
engineering. Neither the technical nor the
architectural implications of these
design extensions re fully understood today. Here
are some examples of such undesirable
feature interactions.
1. NAT devices are incompatible with IPSEC
encryption. This makes deployment
of good network security at an appropriate level
almost impossible.
2. Transparent web caches are incompatible with
Secure Sockets Layer (SSL)
or IPSEC authentication.
3. Diagnostic tools such as traceroute often give
misleading results because
some traffic is being intercepted by transparent
network entities such as web
caches.
4. NAT devices need to look inside control protocols
such as the FTP control
channel to modify addresses and ports that are
specified.
5. Deployment of new application protocols is made
difficult by firewalls, with
the result that new protocols are sometimes tunneled
over inappropriate existing
protocols to allow firewall traversal.
As a result, current IETF protocol engineering is in
a conceptual and technical
muddle that will continue to lead to increasingly
complex and costly engineering
as well as loss of functionality. The only way to
avoid this degeneration will be to
restore coherence to the architecture, and that will
happen only as the result of a
deliberate effort to create a new architecture for
the future.
The cause of the IETF’s muddle is not that its
members do not believe in the architecture
abstraction. Basic Internet architecture concepts
like the end-to-end argument,
connectionless protocols, and universal connectivity
are often cited in IETF
discussions. IETF members accept and support the
idea of architecture. Indeed,
there are IETF efforts to define complete
sub-architectures – the “security architecture”,
the “routing architecture”, the “addressing
architecture”, etc. The problem
with these well-intentioned and often high-quality
efforts is that they are piecemeal.
The union of these sub-architectures does not form
an Internet architecture,
which is greater than the union of its parts. A
decomposition may be useful, but it
is insufficient; the requirements and principles
need to be combined into a coherent
whole. Finally, the IETF is unsuited by membership,
organization, or mission to
attempt a major overhaul of the overall
architecture.
0 komentar:
Posting Komentar