rfc2768.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,205 行 · 第 1/5 页

Aiken, et al.                Informational                     [Page 13]

RFC 2768          A Report of a Workshop on Middleware     February 2000


   CIM and DEN are conceptual information models for describing the
   management of entities ranging from network elements to protocols to
   hosts and services. CIM and DEN are platform- and technology-
   independent. DEN is an extension of CIM that, among other things,
   describes how to map CIM data into a form usable by LDAP.

   The CIM Specification describes the meta schema, information model,
   language, naming, and mapping techniques to other management models,
   such as SNMP MIBs and DMTF MIFs.  DEN provides a good start on a
   model that addresses the management of the network and its elements;
   DEN is an extension of CIM to include the management of networks as a
   whole and not just the individual elements. DEN addresses the
   requirements for abstracting a complex entity, such as a router, into
   multiple components that can be used to manage individual aspects of
   that complex entity. The DEN information model, like CIM,
   incorporates both static and dynamic information. DEN provides a
   mapping to directories for the storage and retrieval of data. DEN
   will also rely heavily on the use of AAA services in order to
   maintain the integrity of the directory and its policies as well as
   to manage the distribution of policies among the policy repositories,
   PDPs and PEPs.  Resource managers and applications will also rely
   heavily on directories for the storage of policy and security
   information necessary for the management and allocation of resources.

   Since much of the information associated with a person, agent or
   element is stored in a directory, and access to that information will
   be controlled with appropriate security mechanisms, many voiced the
   need for a single user/process sign on.

   Future advanced applications (e.g., NGI, Internet2, PACI, Grids) may
   require a variety of PDPs to manage a variety of resource types
   (i.e., QOS, security, etc.).  In this case, a general model would
   have to be developed that defines the protocols and mechanisms used
   by cooperating resource managers (i.e., PDPs) of different domains
   and different genres of resource (i.e., network, security, storage,
   proxy agents, online facility, etc.). For policies to be implemented
   in a coherent fashion, it is necessary to have a mechanism that
   discovers and tracks resources and utilization.

   There is an architectural issue of central importance, which has most
   recently surfaced in the directory area. Many applications, and many
   middleware components, need what is essentially a highly scalable,
   distributed database service. In other words, people want to take the
   best of what directories and databases have to offer. This would
   result in a distributed, replicated database that can use containment
   to effectively organize and scope its information. It would be able
   to have exceptional read response time, and also offer transactional
   and relational integrity. It would support simple and complex



Aiken, et al.                Informational                     [Page 14]

RFC 2768          A Report of a Workshop on Middleware     February 2000


   queries. Such a service has never been defined as a middleware
   component; the complexities involved in specifying and implementing
   such a service are certainly formidable. However, in the absence of
   such a general service, many middleware components have attempted to
   use the closest service available, which is deployed - historically
   first using DNS, and more recently, directory services.

   It will be important to clarify the limitations of the appropriate
   use of directory services, and to consider whether a more general
   data storage and retrieval service may be required, or whether
   directory services can be seamlessly integrated (from the point-of-
   view of the applications using them) with other forms of storage and
   retrieval (such as relational databases) in order to provide an
   integrated directory service with these capabilities.

9.0 Resource Management

   Policy implementation processes need to be linked to Resource
   Managers in a more sophisticated way than those that currently exist.
   Such processes must be dynamic, and able to reflect changes in their
   environment (e.g., adjust the quality of service provided to an
   application based on environmental changes, such as congestion or new
   users with higher priorities logging onto the system). We need to
   determine how different types of resource managers learn about one
   another and locate each other - as well as deal with associated
   cross-domain security issues.  Another aspect of this problem is
   developing a resource definition language that can describe the
   individual elements of the resource being utilized, whether that is a
   network, processor, agent, memory or storage. This will require
   developing an appropriate metadata representation and underlying meta
   schema that can be applied to multiple resource types.

   Some models of resource managers are currently being used to provide
   for the management of distributed computing and Grid environments
   (e.g., Condor, Globus, and Legion).  These resource managers provide
   languages, clients, and servers to support accessing various types of
   distributed computing resources (e.g. processors, memory, storage and
   network access).  There is a broad interest in the distributed and
   parallel computing communities in developing an automated access
   control architecture, using policies, to support the evolving IETF
   differentiated services architecture. However, this work has not yet
   been incorporated into any IETF working group charter. The term
   "bandwidth broker" has been used to refer to the agents that will
   implement this functionality through network resource management,
   policy control, and automated edge device configuration.  The IETF
   Policy Framework working group is currently working on a policy
   architecture framework, information model, and policy definition
   language that is targeted initially at policy management within a



Aiken, et al.                Informational                     [Page 15]

RFC 2768          A Report of a Workshop on Middleware     February 2000


   single domain. However, this work is fundamental in defining inter-
   domain policy management issues, such as those that are required in
   implementing a network resource manager / bandwidth broker.  Many
   resource managers being deployed today rely on directory services for
   storing policy information as well as X.509 for certificate-based
   authentication and authorization to these resources. Middleware will
   be required to translate the needs of distributed and parallel
   computing applications within and across different policy domains. It
   is crucial that a standard means for representing and using resource
   management be developed.

   Advance reservation of resources, as well as dynamic requests for
   resources, is a crucial aspect of any resource management system.
   Advance reservations are more of a policy issue than a provisioning
   issue; however, the mechanisms for exchanging and propagating such
   requests between resource managers located within different
   administrative domains is a currently unsolved problem that needs to
   be addressed. In addition, it is important to address the issue of
   possible deadlock and/or the inefficient use of resources (i.e., the
   time period between a request, or set of requests, being initiated
   and honored and resources being allocated). There is also a need for
   rendezvous management in resource allocation services, where an
   application must gather resource reservations involving multiple
   sites and services.

   A mesh of cooperating resource managers, which interact with each
   other using standards based protocols (e.g. COPS), could be the model
   for a resource management infrastructure. Each of these may manage
   different sets of resources. For example, one may be a bandwidth
   broker that only manages network bandwidth, while another may be a
   general-purpose resource manager that manages security, IP address
   allocation, storage, processors, agents, and other network resources.
   There are already plans for middleware resource managers that not
   only allocate the resources but also manage the composition of a
   group of services that may include security services, billing
   services, shaping of multimedia composite images, etc.). Another form
   of resource manager may provide mapping between a set of related
   services (i.e., mapping an IP based RSVP request to an ATM SVC, as
   was demonstrated in a pilot project on the vBNS).

   Resource managers depend on the use of locator services to find other
   resource managers as well as to locate the AAA server(s) for the
   requestor and the associated directories containing applicable policy
   information. They may also need to query the network to determine if
   a policy request for bandwidth can be satisfied. It is essential that
   these (and other) different uses of resource management be integrated
   to provide an end-to-end service for applications and users alike.




Aiken, et al.                Informational                     [Page 16]

RFC 2768          A Report of a Workshop on Middleware     February 2000


10.0 Networked Information Discovery and Retrieval Services

   There are a wide range of middleware services broadly related to the
   discovery and retrieval of networked information. Because such a
   broad range of applications (and not just high-performance,
   distributed, or parallel applications) requires these services, this
   area is under very active development and new requirements are
   constantly emerging.

   Perhaps the most basic service in this area is persistent naming and
   location services (and infrastructure) that can resolve names to
   locations (i.e., URLs). The IETF has done considerable work in
   defining a syntax for Uniform Resource Identifiers (URIs), which are
   intended to be persistent name spaces administered by a wide range of
   agencies. URIs are resolved to URLs using resolver services; there
   are a number of different proposals for such resolver services, and
   some implementations exist such as the CNRI Handler Service.  Many
   organizations are beginning to establish and manage URI namespaces,
   notably the publishing community with their Digital Object Identifier
   (DOI). however, there are many unresolved questions, such as how to
   most effectively deal with the situation where the resource named by
   a URI exists in multiple places on the network (e.g., find the
   "closest" mirror in terms of network connectivity and resource
   availability). There is a need for an extensive set of infrastructure
   around resolvers, including how resources are registered and
   identifiers are assigned, the ongoing management of data about the
   current location of resources that are identified by a specific URI,
   and the operation of sets of resolvers for various name spaces.
   Finally, given a URI, one needs to locate the resolver services that
   are connected with that namespace; the IETF has done initial work on
   resolution service location for URI namespaces.

   URIs are intended to be processed primarily by machines; they are not
   intended to necessarily be easy to remember, though they are intended
   to be robust under transcription (not sensitive to whitespace, for
   example). More recently, the IETF has begun work on defining
   requirements for human friendly identifier systems that might be used
   to register and resolve mnemonic names.

   Another set of issues revolves around various types of metadata -
   descriptive, ratings, provenance, rights management, and the like,
   that may be associated with objects on the network. The Resource
   Description Framework (RDF) from the Worldwide Web Consortium (W3C)
   provides a syntax for attaching such descriptions to network objects
   and for encoding  the descriptions; additional middleware work is
   needed to locate metadata associated with objects that may be stored
   in repositories, and to retrieve such  metadata. Validation of
   metadata is a key issue, and both IETF and W3C are working on XML



Aiken, et al.                Informational                     [Page 17]

RFC 2768          A Report of a Workshop on Middleware     February 2000


   canonicalization algorithms that can be used in conjunction with
   public key infrastructure to sign metadata assertions. However, such
   an approach implies a complex set of trust relationships and
   hierarchies that will need to be managed, and policies that will need
   to be specified for the use of these trust relationships in
   retrieval.