(e.g., visualization and teleimmersion) as well as the emerging
importance of voice and video, especially voice and video operating
with lower bandwidth or voice and video co-mingled with data. One
perspective on this issue is to consider the effect of multiple drops
in a single RTT, which is catastrophic for TCP applications but may
be of no special significance for real-time traffic. Providing for
improved services can be accomplished through a variety of quality of
service (QoS) and class of service (CoS) mechanisms. The first IETF
model was the Integrated Services (IntServ) model, which used RSVP as
the signaling mechanism. Since this model requires state in every
router for every session and to manage the traffic flows, it is
generally recognized to have scaling limits. However, it is very
appropriate for certain situations.
Differentiated Services, or DiffServ, grew out of a reaction against
the perceived scalability problems with the IETF IntServ model.
DiffServ is an architecture for implementing scalable service
differentiation in the Internet. Scalability is achieved by
aggregating traffic through the use of IP-layer packet marking.
Packets are classified and marked to receive a particular per-hop
forwarding behavior on nodes along their path. Sophisticated
classification, marking, policing, and shaping operations need only
be implemented at network boundaries or hosts. Network resources are
allocated to traffic streams by service provisioning policies which
govern how traffic is marked and conditioned upon entry to a
differentiated services-capable network, and how that traffic is
forwarded within that network. These simple PHBs are combined with a
much larger number of policing policies enforced at the network edge
to provide a broad and flexible range of services, without requiring
state or complex forwarding decisions to be performed in the core and
distribution layers.
Recently, the idea of "tunneling" RSVP over a DiffServ-capable
network has generated significant interest. This attempts to combine
the best features of both IntServ and DiffServ while mitigating the
disadvantages of each. This in turn has led the IETF to study ways to
ensure that Differv and Inteserv can not only coexist, but are also
interoperable.
The practical realization of either or both architectures depends on
many middleware components, some of which are described in this
document. The workshop discussion mainly focused on DiffServ
mechanisms and on what effect such mechanisms would have on
middleware and its ability to monitor and manage the network
infrastructure for the benefit of the applications. Both IntServ and
DiffServ only fully make sense if linked to a policy mechanism. This
mechanism must be able to make policy decisions, detect and resolve
conflicts in policies, and enforce and monitor policies.
Workshop participants almost unanimously agreed that they also
required a scalable inter-domain resource manager (e.g., a bandwidth
broker). Currently, if an RSVP session is run, each router along a
path becomes involved, with flow policing at each hop. Bandwidth
Broker models include the bandwidth broker, a policy decision point
(which makes admission control and policy decisions) and the policy
enforcement points (i.e., edge routers) which provide for policing at
the first hop and for remarking aggregate flows so that subsequent
routers need only deal with the aggregate flows.
IETF protocols that could be used to implement a Bandwidth Broker
model (e.g., COPS, Diameter, and others) were also discussed. The
Diameter protocol is interesting in this context, because it provides
set up mechanisms for basic network resource allocations and
reallocations, as well as optional allocations.- All of these can be
used for various types of bandwidth broker implementations, including
those directed at QoS, using RSVP type information. Diameter
currently does not provide path information, but instead relies on
network pathway information established at ingress and egress nodes.
However, the status of Diameter is still open in the IETF.
COPS was initially developed as a mechanism for establishing RSVP
policy within a domain and remains intra-domain centric. It is a
useful intra-domain mechanism for allocating bandwidth resources
within a policy context. Work is now being conducted to use COPS for
establishing policy associated with a DiffServ-capable network. COPS
is designed to facilitate communication between the PDP and the PEP,
carrying policy decisions and other information.
To implement any type of Bandwidth Broker model, it is necessary to
establish a mechanism for policy exchanges. The Internet2's Qbone
working group is currently working to define a prototype inter-domain
bandwidth broker signaling protocol. This work is being coordinated
with IETF efforts.
Another mechanism is required for traffic shaping and SLA policing
and enforcement. One mechanism is fair queuing in its various forms,
which has been described as TDM emulation without the time and space
components. Techniques have been used for several years for fair
queuing for low speed lines. For DS-3 with 40 byte packets and OC-3c
speeds with 200-byte packets, weighted fair queuing uses a deficit
round-robin algorithm that allows it to scale. It is capable of flow
discrimination based on stochastically hashing the flows. An
additional expansion of this technique is to preface this technique
with class indicators. Currently, classification techniques are based
on IP precedence. However, classification will soon be achieved in
many routers using Diffserv code points (DSCPs) to specify the type
of conditioning to be applied. The complete requirements of policing
for DiffServ implementations, e.g., via bandwidth brokers, have not
yet been fully explored or defined.
Network monitoring capabilities (i.e., querying the network for state
information on a micro and macro level) that support middleware and
application services were identified as a core requirement. In fact,
a network instrumentation and measurement infrastructure, upon which
a set of intelligent network management middleware services can be
built, is absolutely critical.
Current mechanisms (e.g. ICMP, SNMP) were not deemed robust enough
for middleware and applications developers to determine the state of
the network, or to verify that they were receiving the specific type
of treatment they had requested. This was judged especially true of
a network providing QoS or CoS. Indeed, it is not at all clear that
SNMP, for example, is even the right architectural model for
middleware to use to enable applications to determine the state of
the network. Other capabilities, such as OcxMon, RTFM, new MIBs, and
active measurement techniques (e.g., IPPM one-way delay metrics) need
to be made available to middleware services and applications.
The provisioning of differentiated services takes the Internet one
step away from its "dumb" best effort status. As the complexity of
the network increases (e.g. VPNs, QoS, CoS, VoIP, etc.), more
attention must be paid to providing the end-user/customer or network
administrator with the tools they require to securely and dynamically
manage an adaptable network infrastructure. Differentiated services
means that theoretically some traffic gets better service than other
traffic; subsequently, one can expect to pay for better service,
which means that accounting and billing services will be one of the
important middleware core components that others will rely upon. The
model and protocols necessary to accomplish this are not developed
yet.
12.0 Authentication, Authorization, and Accounting
The IETF's AAA working group is focusing on the requirements for
supporting authentication, authorization, accounting, and auditing of
access to and services provided by network resource managers (e.g.,
bandwidth brokers). These processes constitute an important security
infrastructure that will be relied upon by middleware and
applications. However, these components are only basic security
components. A public key infrastructure (PKI) was identified as a
crucial security service infrastructure component. For example, the
PKI will be required to support the transitivity of authentication,
authorization, and access control and, where appropriate, accounting
and billing. It was noted that, except for issues dealing with group
security and possibly more efficient and simple management, there are
no real technical challenges preventing the wide scale deployment of
a PKI support structure at this time. Instead, the main obstacles to
overcome are mostly political and economic in nature. However,
additional middleware may be required to better facilitate a PKI.
That being said, some people believe that we do have some large
technical security challenges, revocation lists and security with
respect to changing group memberships being two examples.
Middleware and security support is also required for newer
applications (e.g., proxy agents that would act on a process or
application's behalf and gather the necessary certificates for access
and using resources). A particularly difficult example is remote
collaboration. Accessing a particular resource may require a user
and/or application to gather certificates from more than one policy-
controlling agent. It is also true that an entity may have various
identities that are dependent on the task they are performing (usage
or role based) or the context of the application. In order for the
PKI to become truly functional on a ubiquitous level, there needs to
exist a set of independent signing authorities that can vouch for the
top-level certificate authorities.
There are also higher-level middleware services which will build on
public key infrastructure, notary services and provenance
verification. As we move from a relatively dumb network (e.g. best
effort IP) to an Internet with embedded intelligence (e.g., DiffServ,
IntServ, bandwidth brokers, directory-enabled networks, etc.), the
secure exchange of information will become even more important. In
addition, as we start to provide differentiated services, accounting
and statistics gathering will become much more important. We also
need to provide for the integrity and security of collecting,
analyzing, and transporting network management and monitoring
information. And the issues of data privacy and integrity, along
with addressing denial of service and non-repudiation, cannot be
ignored.
13.0 Network Management, Performance, and Operations
Network management capabilities were identified as being paramount to
the success of middleware deployment, and subsequently to the success
of the application. Many of the issues addressed here are not part of
standard NOC operations. In a more complex world of QoS, CoS, and
micro prioritization, reactions to network failures must be handled
differently than current procedures. Allocations are more dynamic,
especially additions, deletions, and changes with additional sets of
requirements, such as priorities and new types of inter-domain
interactions. These will inevitably increase the complexity of
network management.
There are many microscopic and macroscopic network management
projects focusing on making both active and passive network
statistics and information available to end-users. Current visual
debugging and analysis capabilities (e.g., those developed by
NLANR/CAIDA) are crucial tools for network administrators and
designers for understanding their networks. In addition, current
network management techniques and mechanisms, which were designed for
network designers and managers, need to be adapted to provide a
dynamic and relevant set of information to the middleware or
application service software. This will allow the programs to
dynamically adapt to the changing state of the network infrastructure
while ensuring the integrity and security of the network and other
resources.
Another aspect of network management that has not received the
necessary attention, is the need for modeling and analysis tools for
network and middleware designers. CIM and DEN show great promise in
providing a common framework for modeling the management of network
elements and services as well as users, applications, and other
resources of the network. Undoubtedly, middleware designers will
place new requirements on CIM and DEN that will cause these
approaches to evolve.
14.0 Middleware to support multicast applications
IP multicast - that is, the routing and forwarding of mutlicast
packets in an IP-based network, is in the view of the workshop part
of the basic network infrastructure. The Internet Group Multicast
Protocol, which manages the joining and leaving of multicast groups,
could also be considered a basic network service. However, there is a
tremendous need for middleware services to make multicast useable for
various applications, much like TCP played a key role in making IP
applications useable. Specifically, one might reasonably want
middleware services to provide authenticated control of multicast
services. Examples of these services include the creation and joining
of multicast groups, multicast address management, multicast channel
directories (there has already been considerable work in this area),
various forms of reliable multicast services (this has been an IRTF
research area), and to secure multicast groups through various
cryptographic strategies. In addition, because of the large impact
that multicast can have on a network, multicast management middleware
services, particularly in conjunction with QoS, will be needed, as
will services to link together multicasting within various networks
that do not directly interchange multicast routing information. It
should be noted, however, that several security issues with
multicast, especially groups with dynamic membership policies, still
need to be resolved.
15.0 Java and Jini
Java was chosen as an example of a heterogeneous runtime support
system for the sake of discussion as to whether it could be qualified
as a development language particularly suitable for the development
of middleware. The consensus was that the Java language and compilers
are important in the current distributed model of the Internet and
for the support of middleware (i.e., middleware written using Java).
Also, a virtual Java machine located on a system can be considered
middleware as much as any operating system or network operating
systems would be considered middleware. Jini middleware technology
not only defines a set of protocols for discovery, join, and lookup,
but also a leasing and transaction mechanism to provide resilience in
a dynamic networked environment. Java and Jini will be dependent on
a functioning PKI, especially for signed applets. That being said,
there are security concerns with both Java and Jini that need to be
addressed, such as allowing the downloading of applets and servlets.
16.0 Security Considerations
This document is a report of a workshop in which security was a
common theme, as can be seen by the references to security through
out the document; but the workshop did not reach any specific
recommendations for new security-related terminology.
17.0 Summary
Middleware may have components and services that only exist in the
persistent infrastructure, but it will also have components that
enable and support end-to-end (i.e. application to application or
host to host) interaction across multiple autonomous administrative
domains. A set of core persistent middleware services is required to
support the development of a richer set of middleware services which
can be aggregated or upon which applications will be based (e.g., an
onion or layered model). This set of core middleware services will
help applications leverage the services and capabilities of the
underlying network infrastructure, along with enabling applications
to adjust in changes to the network. The particular set of such
services utilized by an application or process will be a function of
the requirements of the application field or affinity group (e.g.,
network management or high energy physics applications) wishing to
utilize the network or distributed data/computation infrastructure.
This document discusses some of the basic and core middleware
services, which include, but are not limited to: directories,
name/address resolution services, security services (i.e.,
authentication, authorization, accounting, and access control),
network management, network monitoring, time servers, and accounting.
Network level capabilities, such as multicast and DiffServ, are not
classified as middleware; rather, they are enabling infrastructure
services upon which middleware will be built or which middleware may
use and manage. A second level of important middleware services,
which builds upon these core set of services, may include
accounting/billing, resource managers, single sign-on services,
globally unique names, metadata servers, and locators.
A recognized goal is to provide a set of middleware services that
enable access to and management of the underlying network
infrastructure and support applications wishing to make use of that
network-based infrastructure. It appears necessary to agree to a
framework of services for the support, provisioning and operations,
and management of the network. Today, we have piecemeal activities
already being pursued in various standards organizations. These
include efforts in the IETF and DMTF (e.g., AAA, Policy Framework,
DiffServ, DEN, CIM, etc.), as well as in the advanced application
environments (e.g., Grid Forum, the PACIs, NGI, Internet2, etc.).
Both of these efforts require the integration and management of many
infrastructure components, not just networks; however, we have no
overall framework that pulls all of these together, or a mechanism to
coordinate all of these activities. We are just embarking on the
development of a rich plan of middleware services. Consequently, we
have a lot of work yet to be done. For instance, as we move into an
electronic persistent presence (EPP) environment where multiple
instances of an identity or person (or even their proxy agents) are
supported, we will require enhanced locator and brokering services.
The directory (e.g., DNS or X.500) and locator services of today may
not be appropriate for this task.
One goal of the workshop was to identify research and development
areas in middleware that federal agencies and industry may choose to
support. The workshop highlighted a few areas that may benefit from
additional R&D support. These areas include, but are not limited to:
- inter-domain resource management architecture and protocols (e.g.,
inter-domain bandwidth brokers)
- resource languages that describe and enable the management of a
wide variety of resources (e.g., networks, data bases, storage,
online facilities, etc.
- avoiding deadlock and ensuring efficiency with resource managers
- network management tools and APIs that provide macroscopic and
microscopic real-time infrastructure
- information to middleware services and applications (not just MIBs
and SNMP access)
- domain and inter-domain accounting and billing
- monitoring and verification services of contracted infrastructure
services
- enhanced locators that can locate resources and resource managers
- cross administrative policy negotiation and authentication
- middleware bypass (i.e. access to raw system or network resources
metadata (i.e., data that is used to describe data found in
directories or exchanged between services such as resource
managers, PDPs, PEPs, directories, accounting and billing
services, etc.)
- middleware support for mobile or nomadic use
- support for availability of resources (i.e. replication and load
balancing
This workshop was just one small step in identifying relevant
middleware topics, technologies and players. Even though this
workshop did not arrive at a consensual definition of middleware, it
did identify the need for additional work. Specifically, further work
is needed to identify and qualify middleware services for specific
affinity groups (e.g. Internet2, Education, the PACIs, Grids, etc.)
as well as to define a macroscopic framework that incorporates the
middleware work of the IETF, DMTF and other relevant organizations
such as the Grid Forum.
18.0 Participants
Deb Agarwal <deba@george.lbl.gov>, Bob Aiken <raiken@cisco.com>, Guy
Almes <almes@internet2.edu>, Chase Bailey <chase@cisco.com>, Fred
Baker <fred@cisco.com>, Pete Beckman <beckman@lanl.gov>, Javad
Boroumand <jborouma@nsf.gov>, Scott Bradner <sob@harvard.edu>, George
Brett <ghbrett@mindspring.com>, Rich Carlson <racarlson@anl.gov>,
Brian Carpenter <bcarpent@uk.ibm.com>, Charlie Catlett
<catlett@ncsa.uiuc.edu>, Bill Cheng <wtcheng@us.ibm.com>, Kim Claffy
<kc@caida.org>, Bill Decker <Wdecker@nsf.gov>, Christine Falsetti
<cfalsetti@arc.nasa.gov>, Ian Foster <foster@mcs.anl.gov>, Andrew
Grimshaw <grimshaw@cs.virginia.edu>, Ed Grossman
<egrossma@ncsa.uiuc.edu>, Ted Hanss <ted@internet2.edu>, Ron Hutchins
<ron@oit.gatech.edu>, Larry Jackson <jackson@ncsa.uiuc.edu>, Bill
Johnston <Wejohnston@lbl.gov>, Juerg von Kaenel <jvk@us.ibm.com>,
Miron Livny <miron@cs.wisc.edu>, Cliff Lynch <cliff@cni.org>, Joel
Mambretti <j-mambretti@nwu.edu>, Reagan Moore <moore@sdsc.edu>, Klara
Nahstedt <klara@cs.uiuc.edu>, Mike Nelson <mrn@us.ibm.com>, Bill
Nitzberg <nitzberg@nas.nasa.gov>, Hilarie Orman <ho@darpa.mil>, John
Schnizlein <jschnizl@cisco.com>, Rick Stevens <stevens@mcs.anl.gov>,
John Strassner <johns@cisco.com>, Ben Teitelbaum <ben@advanced.org>,
George Vanecek <g.vanecek@att.com>, Ken Klingenstein
<Ken.Klingenstein@Colorado.EDU>, Arvind Krishna
<akrishna@us.ibm.com>, Dilip Kandlur <kandlur@us.ibm.com
19.0 URLs/references
Please see http://www.mcs.anl.gov/middleware98 for copies of the
slides presented at the workshop as well as a list of related URLs on
applications, middleware and network services.
20.0 Authors' Addresses
Editor: Bob Aiken
EMail: raiken@cisco.com
Authors:
Bob Aiken
Cisco Systems, Inc.
6519 Debold Rd.
Sabillasville, Md. 21780 USA
Phone: +1 301 271 2919
EMail: raiken@cisco.com
John Strassner
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
Phone: +1 408 527 1069
EMail: johns@cisco.com
Brian E. Carpenter
IBM United Kingdom Laboratories
MP 185, Hursley Park
Winchester, Hampshire SO21 2JN, UK
EMail: brian@hursley.ibm.com
Ian Foster
Argonne National Laboratory
The University of Chicago
Argonne, IL 60439 USA
Phone: +1 630 252 4619
EMail: foster@mcs.anl.gov
Clifford Lynch
Coalition for Networked Information
21 Dupont Circle
Washington, DC 20036
Phone: +1 202 296 5098
EMail: cliff@cni.org
Joe Mambretti
International Center for Advanced Internet Research
1890 Maple, Suite 150
Northwestern University, Evanston, Illinois 60201
Phone: +1 847 467 3911
EMail: j-mambretti@nwu.edu
Reagan Moore
University of California, San Diego
NPACI/SDSC, MC 0505
9500 Gilman Drive
La Jolla, CA 92093-0505 USA
EMail: moore@sdsc.edu
Benjamin Teitelbaum
Advanced Networks & Services, Inc.
EMail: ben@internet2.edu
21.0 Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.